Virtualisierung braucht hohe Verfügbarkeit
Automatisches Failover für virtuelle Maschinen
Ausfallsicherheit ist in einer konsolidierten Infrastruktur Pflicht. Hochverfügbarkeitslösungen auf der Basis von Fibre Channel haben sich in den Rechenzentren auch für den Einsatz mit virtuellen Maschinen bewährt. Durch Speichervirtualisierung können Auto- Failover und -Failback für VM auch über iSCSI ablaufen, wie das Beispiel der Datacore-Lösung zeigt.
Die aktuellen Hypervisoren von VMware, Citrix, Microsoft und Co. bieten eigene
Hochverfügbarkeitsfunktionen für virtuelle Maschinen (VM). Dienste wie Xenmotion oder VMotion
verschieben VMs auf der Hardware. Bei einem unvorhergesehenen Ausfall lassen sich VMs mit der
HA-Option automatisch auf eine andere Hardware migrieren. Der DRS (Distributed Resource Scheduler)
bewegt die VMs zwischen der Hardware, um eine optimal Hardwareausnutzung zu erreichen.
Dafür benötigt die Virtualisierung speicherseitig "Shared Storage", das heißt eine
Speicherinfrastruktur, die den virtuellen Maschinen den parallelen Zugriff auf eine LUN (Logical
Unit Number) ermöglicht. In der Regel wird dies in einem Storage Area Network über Fibre Channel
(FC) realisiert, auch weil es den hohen Leistungsanforderungen in der virtualisierten
Server-Umgebung genügt. FC-SAN-Storage ist schnell, sicher und durch Mirroring auch als DR-Konzept
einsetzbar. Jedoch sind FC-Komplexität und Kosten ein Hemmschuh bei der Einführung der "
Einspartechnik" Virtualisierung.
Virtueller Storage für VMs
Folgende wesentliche Grundvoraussetzungen für "echte" High Availability (HA) in virtuellen
Umgebungen gilt es zu beachten:
HA bedeutet komplette Ausfallsicherheit,
HA umfasst Server, Storage und Infrastruktur,
HA basiert auf physischer Redundanz, und
HA bedeutet automatisches Failover und automatisches Failback.
Im Zuge der Server-Virtualisierung etabliert sich die softwarebasierende Storage-Virtualisierung
zunehmend, weil sie die SAN-Funktionalität ähnlich wie die Host-Virtualisierung mit
Standardkomponenten realisiert. So unterstützen ESX 3.x, Hyper-V und Xenserver 5 alle gängigen
Speichertechniken und -protokolle von NFS, DAS, NAS und SAN-Funktionen via FC und iSCSI, also etwa
Fast Clones, Snapshots oder Thin Provisioning von Drittanbietern. Erst mit der
Storage-Virtualisierung können sie aber übergreifend für alle darunter liegende Storage-Hardware
genutzt und über offene APIs in die Management-Center der Hypervisoren als Virtual Disk Storage
eingebunden werden.
Einzig das Auto-Failover über iSCSI scheint den Entwicklern bislang Probleme bereitet zu haben,
sodass LUNs nach einem Systemausfall händisch nachgereicht werden mussten. Der
Storage-Virtualisierungspezialist Datacore liefert eine Lösung, die das Failover und das Failback
nach der Wiederherstellung automatisch über Fibre Channel, iSCSI und in gemischten Umgebungen
realisiert.
HA-SAN als VM einrichten
Sanmelody wird auf Standard-i86-Hardware installiert und liefert physischen wie virtuellen Hosts
virtuelle Disk-Volumes aus einem Pool aller angeschlossenen Disk-Systeme unabhängig von Technik,
Protokoll oder Anbieter. In den aktuellen Version 2.0 können die Storage Domain Server selbst als
virtuelle Maschine unter Vmware, Citrix, Parallels, Microsoft etc. eingerichtet werden. Dieser
nächste Schritt der Konsolidierung "schiebt" Server und Storage auch physisch zusammen und kann
deshalb auf Hochverfügbarkeitstechniken gar nicht mehr verzichten. Zu beachten ist jedoch, dass
Sanmelody bei der Installation als VM heute ausschließlich iSCSI unterstützt, da die virtuellen
HBAs von Emulex und Qlogic erst in Beta-Fassungen vorliegen.
In der Minimalvariante lässt sich die hochverfügbare Server-/SAN-Lösung auf zwei
Standard-Servern mit Sanmelody 2.0 und beispielsweise VMware ESX 3.5 aufsetzen. Dabei wird der
Storage Domain Server als virtuelle Maschine mit dem VMware VMFS eingerichtet und unter Windows
2003 Server auf jedem ESX-Server installiert.
Die Server sollen mit zwei Dual-Core-Prozessoren ausgestattet sein, weil einer von vier Kernen
für die Datacore-Anwendung zur Verfügung stehen muss. Über den internen RAID-Controller des Servers
sollten zudem vor dem Aufsetzen der Virtualisierungs-Layer zwei RAID-Gruppen für ESX (zwei
RAID-1-Disks) und für den Storage Pool eingerichtet werden.
Je nach Anzahl und Art der VMs sollte ausreichend Arbeitsspeicher vorhanden sein, weil die
Storage-Virtualisierung bis zu 80 Prozent des zugewiesenen RAMs für das Caching und damit die
Beschleunigung der I/O-Zugriffe nutzt. In die Server können alle gängigen Plattentechniken (SATA,
SAS, 10K, 15K, LFF, SFF etc.) integriert oder externe RAID-Controller angeschlossen sein.
Für einen performanten Datenverkehr sollten eigene virtuelle Netzwerk bereit stehen. Dazu werden
die Server mit 4-GbE-NICs ausgestattet, um dem VM-Netzwerk, dem iSCSI-SAN, dem iSCSI-Spiegel sowie
der Service-Konsole mit VMotion je eine Verbindung zu reservieren. Dann erfolgt die
Standardinstallation der ESX-Server-Software sowie des Virtual Centers (auf einer
Windows-Maschine). Über den Virtual Infrastructure Client werden die ESX-Server geclustert und die
Optionen "VMware HA" und "VMware DRS" in den Spezifikationen aktiviert. Bei der Kombination mit der
Storage-Virtualisierung muss jedoch das "Memory Ballooning" ausgeschaltet sein. Dies sorgt in der
Standardeinstellung dafür, das gleiche Memory-Inhalte unterschiedlicher VMs in einer physischen
Adresse gespeichert sind. Für den HA-Storage mit Sanmelody ist dies nicht empfohlen.
Für den Storage Domain Server (SDS) ist im Virtual Center eine neue VM mit einem Prozessor und
Windows 2003 Server zu konfigurieren. Sie soll über mindestens 1024 MByte RAM und zwei virtuellen
NICs verfügen. Schließlich wird eine RAID-5-LUN als Raw Device zugeordnet, die sie mit dem SAN-Pool
verbindet. Nun lassen sich Sanmelody und ein iSCSI-Initiator (kostenlos zum Beispiel von Microsoft)
installieren. Bei der standardmäßigen Sanmelody-Installation platziert die Software ihre
iSCSI-Target-Treiber auf allen verfügbaren Disk-Systemen und nimmt sie als virtueller
SAN-Controller "in Besitz".
Zwischen den SDS muss zunächst eine Partnerschaft ("Add Partner") hergestellt und ein
iSCSI-Mirror-Kanal eingerichtet werden, dann gleichen sie ihre Konfigurationsinformationen wie
Storage-Prozessoren in einem traditionellen SAN miteinander ab. Nach Abschluss der Installation
erreichen Administratoren die SDS über mehrere Snap-ins in der Microsoft Management Console (MMC)
oder im VMware Virtual Center, darunter den iSCSI-Manager, über den SDS und ESX-Server einander "
kennen".
Im Normalbetrieb sind beide SDS aktive Controller und stellen den VMs virtuelle LUNs bereit, die
mit wenigen Mausklicks einzurichten sind. Die LUNs werden synchron auf den Partner-SDS gespiegelt
und über beide SDS an die ESX-Server präsentiert. So lässt sich neben einem synchronen Spiegel eine
Pfadtoleranz mit automatischem Failover und Failback erreichen. Bei Ausfall einer Seite schalten
die ESX vollautomatisch auf den zweiten SDS um, sodass es zu keiner Downtime kommt. Ist der Fehler
behoben, synchronisieren sich die Spiegel automatisch, und die ESX Server können wieder
zurückschalten (Auto-Failback). So sind alle Enterprise-Funktionen wie etwa VMotion, HA etc. ohne
eine SAN-Infrastruktur nutzbar. Regeln zur Priorität und Nutzung von iSCSI-Pfaden können dabei im
Virtual Center eingestellt werden. Auch Hardware-SANs der Enterprise-Klasse leisten dies heute
nicht vollautomatisch.
Die virtuellen Laufwerke richtet man in der Standardeinstellung mit Thin Provisioning ein. Der
Applikation suggeriert dies stets die vom Betriebssystem maximal unterstützte Plattengröße von 2
TByte. Durch diese Überbuchung erreichen virtuelle SANs eine höhere Verfügbarkeit und eine
Hardwareauslastung von 75 bis 85 Prozent. Eine Überschreitungskontrolle warnt den Administrator,
wenn Platten nachzurüsten sind. Daten in Thin-Provisioning-Pools können auch zwischen physischen
Festplatten wandern.
Lesen Sie mehr zum Thema
