Case Studies
Das Unternehmen SETAO
Verantwortlich für den städtischen Transport betreibt SETAO das Bahn- und Busnetz im Stadtgebiet von Orleans, Frankreich. Mehr als 100.000 Passagiere nutzen pro Tag das Verkehrsnetz von SETAO, weshalb ein hoch verfügbares System zwingend benötigt wird. In Bezug auf Rechenressourcen verlässt sich das Unternehmen auf ein MAN (Metropolitan Area Network) mit 24 km Glas-basiertem Netzwerk mit Cisco Komponenten, 60 Access Points, und vier Rechenzentren, welche über die Stadt verteilt sind. Über dieses Netzwerk läuft der Verkehrsfunk, die Bezahlsysteme, Videoüberwachung (14 Tage Aufbewahrung), das Ampelsystem usw.
Um den Transport von Passagieren zu bewerkstelligen und diese immer in Echtzeit über die Verkehrssituation zu informieren, wird eine Anwendung namens Support System Operations (Produktabkürzung SAE) verwendet, eine spezielle Geschäftsanwendung. Diese fundamentelle Software ist äußerst leistungsfähig und kann das Verkehrssystem in Echtzeit verwalten. Sie dient außerdem dazu, Kunden in Echtzeit über die 24 Straßenbahn-Stationen, 22 Straßenbahnen, 220 Busse u. a. über Mobiltelefon zu informieren.
Was hat dazu geführt, dass wir über Virtualisierung nachdachten?
2004 standen wir vor der Situation, die Hardwareplattform der SETAO Anwendungen aktualisieren zu müssen, ohne die Windows NT4 Betriebssysteme des SAE zu beeinträchtigen. Eine der Optionen war zwar, auf Windows 2000 zu aktualisieren, aber das verlangte eine erneute Zertifizierung und Neukompilierung der Software. Die Kosten wurden auf 240.000,00 € geschätzt. Schließlich entschloss man sich, die Lösung zu virtualisieren und die Umgebung wurde damals mit der VMware Workstation Version 4.5 aufgesetzt, der damals einzigen Lösung für Windows NT4 Unterstützung. Diese Lösung wurde auf allen Servern der Gesellschaft eingesetzt, wenn diese erneuert werden mussten
Sicheres Informationssystem
2006 erwarb die SETAO ein Bandsystem Quantum PX720 LTO III und die Software Symantec (Veritas) Netbackup 6.5, um die beiden bisherigen Systeme ADIC SKALAR 100 und Arkeia Network Backup zu ersetzen. VMware Workstation wurde schnell durch den VMware GSX mit 30 physischen Hosts ersetzt, welche auf Linux basierten und 67 virtuelle Maschinen betrieben. Ein neues Problem trat auf: ein durchgängiges Konzept zur zentralisierten Administration und Betrieb dieser VMs wurde benötigt.
Nach der Analyse der funktionellen und finanziellen Pläne fiel die Wahl auf VMware VI 3.5 mit VirtualCenter, HA, DRS, VMotion und VMware Consolidate Backup. Diese Infrastruktur wird auf zwei Clusterfarmen betrieben, deren Basis Systeme mit Dual-Xeon QuadCore CPUs und 32 GB RAM ausgestattet sind.
2008, entschied man sich zur synchronen Replikation. Daher wurden die Adaptec SNAP 18000 (NFS und iSCSI) durch zwei Pillar Data Systems AXIOM 500 (FC) ersetzt, welche mittels FalconStor NSS IPSTOR repliziert wird. Um die Hochverfügbarkeit weiter auszubauen, wurde im November 2008 VMware Site Recovery Manager eingeführt.
Die Zukunft
Um die gleichen Leistungs- und Redundanzvorteile des Rechenzentrums auf die Client-Seite zu übertragen, wird VMware View 3 als sichere Client Infrastruktur im ersten Quartal 2009 eingeführt.
Damit wir für die Zukunft gewappnet sind, werden LAN und SAN auf der gleichen 10 Gigabit Ethernet Netzwerkstruktur mit Cisco VSS Catalyst Switchen eingeführt, sowohl physikalisch als auch virtuell (NEXUS) unter Nutzung des FCoE Protokolls.
Außerdem wurde Ende 2008 der Aufbau einer zweiten Tram Linie begonnen. Diese soll 2012 in den normalen Betrieb übergehen.
Das MAN wird bis auf 40 km ausgebaut und sich über 120 Access Points ausstrecken. Das CCTV System wird auf 500 Kameras erweitert und die Speicheranforderungen werden dementsprechend anwachsen.
Die Praxis
Während meiner Arbeit bin ich auf einige Hindernisse gestoßen, die ich hier erwähnen möchte.
Zu Anfang hatten wir noch kein Fiber Channel SAN im Einsatz und nutzten daher iSCSI mit Gigabit Ethernet. Um den Durchsatz zu steigern nutzten wir Jumbo Frames, welche allerdings auf eine Frame Größe von 4096 Bytes gesetzt werden mussten, um kompatibel mit allen Netzwerkkarten 3Com, Broadcom, Intel und den Cisco 9509 Switchen zu sein.
Dazu ist auch ein Artikel auf Französisch erschienen: http://www.indexel.net/1_6_4638 __ 3_/2/9/1/Parier_sur_l_iSCSI_pour_optimiser_la_restauration_de_donnees.htm.
NFS Optimierung
Allerdings fanden wir die Bedienung und Verwaltung der virtuellen Maschinen mit iSCSI sehr aufwändig und wir wechselten auf eine Anbindung der Datastores über NFS. Bei NFS stellten wir auch sehr schnell fest, dass die Zugriffsgeschwindigkeit sich gegenüber iSCSI verbesserte. Dies kann übrigens noch weiter verbessert werden, indem man mittels des /sbin/hdparm –a 512 (= 512 cylinder im Voraus lesen) Kommandos die Leistung von VMs um 50% steigern kann.
Die erhöhte Performance half uns natürlich auch bei der Migration zu VMware VI 3.5 und wir konnten 67 VMs an nur einem Wochenende erfolgreich umziehen.
Am folgenden Montag bemerkten die Nutzer weiterhin eine wesentliche Beschleunigung der Anwendungen, da die VMware VI 3.5 Systeme mit neuen QuadCore CPUs ausgestattet waren.
Pillar Data Systems Storage Architektur
Unsere Wahl fiel für den SAN Storage auf Pillar Data Systems, da dieses System das erste - und nach unseren Untersuchungen - das einzige war, welches aufgrund der Architektur in jeder Platteneinheit zwei Storage Controller (Backend Controller) besitzt. Je mehr Bricks (Platteneinheiten) hinzugefügt werden, desto mehr Leistung besitzt das System. Dadurch wird eine lineare Skalierbarkeit gewährleistet.
Ein weiterer interessanter Punkt war für uns die Nutzbarkeit von 1 MB wide stripes, welche in Verbindung mit des VMFS3 sogar weitreichendere Performancevorteile bieten als die 24GB Cache des Axiom Controllers".
Während unserer Tests mit NetApp FAS3120 und EMC CX-4, war die Axiom 500 das einzige System, welches uns die volle Ausnutzung des Fiber Channel Netz erlaubte und dabei auch noch energieeffizienter war.
Wir konnten einen Durchsatz von 160 MB/s auf einem einzigen Slammer (Front Controller – ähnlich Köpfe/Heads bei anderen Storage Systemen) messen und das sogar mit GBit und Jumbo Frames.
Nichtzuletzt ist auch die Verwaltung des Axiom sehr einfach und intuitiv und erlaubt es auch Nicht-Storage Spezialisten diese zu bedienen: Eine befreundete Journalistin (Virtuanews.fr) war sogar in der Lage innerhalb der ersten 3 Minuten nach dem ersten Anschauen des Managements eine LUN anzulegen.
Der Umzug unserer bestehenden Infrastruktur auf das Pillar System gestaltete sich ebenfalls sehr einfach. Ich erstellte 4 LUNs mit unterschiedlichen Quality of Service levels (High, Low, Medium, Archive) mit jeweils 2 TB. Die 2 TB LUNs wurden gegen die FalconStor IPStor gemappt, welche kleinere LUNs an die VMware Umgebung weitergaben. FalconStor IPStor dient dabei als weitere Virtualisierung des SANs und erledigt die u.a. Replizierung.
Danach plante ich, welche virtuellen Maschinen auf die jeweilige Klasse sollte, um die entsprechende Performance zu gewährleisten (bzw. die Performance nicht zu verschwenden). Diese Zuordnung legte ich anhand VMware Pools im VirtualCenter auch an.
Dank Storage VMotion konnte ich die Virtuellen Maschinen während des laufenden Betriebs ohne Ausfall von den alten Storage Systemen auf die IPStor LUNs, welche im Backend auf die Axiom zeigten, migrieren. Die Replication zwischen den beiden RZs mittels IPStor wurde ebenfalls ohne Unterbrechung der Produktion eingerichtet.
Bis auf den bekannten Bug in VI 3.5 U2 (Lizenzfehler) letzten Sommer, hatten wir lediglich einen Fehler bei der Implementierung von VMware Site Recovery Manager mit den SRA FalconStor Adaptern. SRA sah die LUNs zur Integration in die Protection Groups nicht und lief auf einen Fehler.
Dies konnte allerdings bis 1 Uhr morgens mittels WebEx Session durch FalconStor Support und VMware SRM Integratoren behoben werden. Bei dem Problem handelte es sich um eine Inkompatibilität zwischen der Perl.exe von Oracle (unsere SRM DB liegt auf Oracle Datenbanken) und VMware. Durch einfaches umbenennen der Perl.exe in Perl.old konnte das Problem jedoch umgangen werden.
Bisher testeten wir viele Failover Situationen mit VMware SRM (Simulation). Unser RPO Recovery Point Objective) war dabei etwas 3 Minuten, der RTO (Recovery Time Objective) ungefähr 7 Minuten. Ich erhoffe mir für zukünftige SRM Versionen einen Schutz 1:n (1 Rechenzentrum – mehrere Ausfall-RZ) im Stern Verbund und nicht nur 1:1 wie derzeit möglich. Außerdem fehlt mir ein automatischer Failback als Option, da die Backup Seite im Fehlerfall zur Produktionsseite wird. Daher ist es sehr schwer wieder von der Backup Seite in den Normalbetrieb zu kommen.
