Verschiedene Anwendungsfälle und Applikationen erfordern unterschiedliche Grade der Verfügbarkeit. Daher gibt es im Umfeld von »vSphere 5« auf mehrere Varianten der Ausfallsicherheit: »vSphere Fault Tolerance« (vSphere FT) und »vSphere High Availability« (vSphere HA).

Ausfallsicherheit, Fehlertoleranz und Hochverfügbarkeit werden häufig als Synonyme verwendet. Doch das ist keine korrekte Betrachtungsweise: Je nachdem wie kritisch eine Applikation oder ein Dienst für ein Unternehmen ist, muss eine andere Art von Ausfallsicherheit zum Einsatz kommen. Dabei gilt wie so oft im Leben: Je höher die Anforderungen, umso höher wird der Aufwand, um diese Herausforderungen zu erfüllen.

In diesem Beitrag geht es um die Infrastruktur in einer ESX-Umgebung – die Aspekte auf der Ebene der Verwaltungsarbeiten und der Applikationsverfügbarkeit sind bereits im Beitrag Verfügbarkeit für Verwaltung und Applikationen diskutiert worden.

Aufgrund der Vielzahl von Installationen der ESX-Umgebung im Virtualisierungs-Umfeld hat man bei VMware schnell gelernt, dass die Anwender in Bezug auf die Ausfallsicherheit ihrer Systeme  nicht alle über einen Kamm geschert werden können. Daher bringt der Marktführer im Virtualisierungsbereich auch verschiedene Ansätze für diese Aufgabenstellung. Dazu gehört zum einen»vSphere Fault Tolerance« (vSphere FT) und zum anderen »vSphere High Availability« (vSphere HA).

Fehlertoleranz vermeidet Ausfälle komplett

Wer eine lückenlose Ausfallsicherheit benötigt, der muss auf Fehlertoleranz setzen. Früher war das bei sehr teuren Systemen wie Tandems (mittlerweile von HP aufgekauft) »Himalaya«-Serie gut aufgehoben. Dabei wurde auf Einzelbefehlsebene der CPU eine Applikation auf zwei Einheiten vollkommen im Gleichklang betrieben. Fällt eines der Systeme aus, kann das andere an exakt derselben Stelle die Anwendung weiter laufen lassen, es gehen dabei keine Transaktionen verloren. Dieser Ansatz erfordert spezielle Mechanismen bis in die CPU hinein: Sie muss einen »Lockstep-Mechanismus« beherrschen, bei dem eine Operation »ununterbrechbar« ausgeführt wird, so dass daraus ein jederzeit deterministischer Betrieb resultiert.

Ein ähnliches Konzept verfolgt Vmware mit Vsphere FT. Ist diese Funktionalität aktiviert, legt das System eine exakte Kopie einer virtuellen Maschine (VM) an, und hält dieses Replikat absolut synchron und in einem Standby-Modus. Sollte die primäre VM mit der Applikation ausfallen, übernimmt das Replikat an genau derselben Stelle die Ausführung. Doch diese Synchronisationsaufgabe erweist sich als sehr aufwändig. Daher ist eine Vereinfachung nötig: In jeder derart geschützten VM darf nur eine virtuelle CPU im Einsatz sein.

Bei Vsphere 5.0 bringt die FT-Funktion Unterstützung für weitere CPU-Architekturen und Gastbetriebssysteme. Die aktuellen Infos dazu sind auf der Vmware-Webseite nachzulesen. Nur die hier angegebenen Prozessoren und Gastbetriebssysteme können in einer FT-Umgebung eingesetzt werden.

Hochverfügbarkeit neu definiert

Weniger aufwändig und auch für einen breiteren Einsatzbereich geeignet ist die Vsphere HA. In der Version von Vsphere 5.0 hat VMware diese HA-Funktionalität komplett neu geschrieben. Ziel war es, die Skalierbarkeit, die Zuverlässigkeit und auch die Usability von Vsphere HA zu verbessern. Dabei ist der wichtigste Aspekt die Überwachung zum einen der VMs und zum anderen der physischen Hosts, auf denen die VMs laufen.

Mit der Version 5.0 von Vsphere hat Vmware vor allem den Einsatz dieser Virtualisierungs-Plattform in großen Rechenzentren im Fokus. Daher war das Thema Skalierbarkeit für Vsphere HA ein wichtiges Designkriterium. In den früheren Versionen von Vsphere HA gab es die Aufteilung in primäre und sekundäre Knoten. Doch dieses Modell wurde zugunsten eines flexibleren Master-Slave-Konzepts innerhalb der Knoten eines Clusters aufgegeben. Dabei wird einer der Knoten zu Master gemacht, die anderen agieren als Slaves.

Aufgabe des Master-Knotens ist die Koordination aller Verfügbarkeitsaktionen mit den anderen Knoten. Dazu gehört auch die Verantwortung für den Zustand des vCenter Servers. Eine wesentliche Erleichterung durch diesen neuen Ansatz liegt auf der Hand: Der Administrator muss deutlich weniger Aufwand in das Architekturdesign seiner hochverfügbaren Umgebung stecken. Denn er muss sich nicht mehr darum sorgen, welche Host-Systeme als primäre Knoten fungieren und wo sie am besten liegen sollen. Es sind Vorteile zu verzeichnen, wenn man Vsphere HA in einer Blade-Umgebung einsetzt oder bei ausgedehnten Cluster-Umgebungen.

Mit der Unterstützung von IP-Adressen nach der Spezifikation IPv6 wird vor allem bei umfangreicheren Umgebungen die Frage nach den – üblicherweise knappen – IPv4-Adressen nicht mehr auftreten. Aber auch beim Einsatz der Vsphere HA ergibt sich ab Vsphere 5.0 eine Erleichterung: Ein Administrator kann dadurch in nur einem Bruchteil der Zeit die notwendigen Aktionen im Bereich des Deployments ausführen – verglichen mit der Vorgängerversion von HA. Dazu gehören auch das Verteilen der Vsphere HA Agents, das Konfigurieren, Umkonfigurieren und Neukonfigurieren von Vsphere HA.

Alles eine Frage der Zuverlässigkeit

Tritt ein unerwarteter Ausfall auf, möchte kein Administrator der Welt sich darüber Sorgen machen, ob die von ihm installierte HA-Umgebung auch sauber arbeitet. Aufgrund des Anwender-Feedbacks im Supportbereich hat Vmware Funktionalitäten vorgesehen, die das Vertrauen in die HA-Lösung stärken. Eine Verbesserung in diesem Kontext war das Vermeiden von Abhängigkeiten, die externe Komponenten betreffen. So hat Vsphere HA nun keinerlei Abhängigkeit mehr auf die DNS-Namensauflösung durch jeden Host im Cluster. Damit hat auch der Ausfall von externen Komponenten keine Auswirkung mehr auf die Funktionsfähigkeit von Vsphere HA.

Eine andere Optimierung betrifft die Kommunikation der Knoten im Cluster über das Speicher-Subsystem. In der neuen Version nutzt Vsphere HA mehrere Pfade für diese Kommunikation – einmal über das normale Netzwerk und einmal über die Speicheranbindung. Damit ergibt sich zum einen generell ein höherer Grad an Redundanz  und zum anderen ist ein besseres Erkennen das »Gesundheitszustands« eines Knotens  und der darauf agieren VMs machbar.

Auch wenn die meisten der Verbesserungen bei Vsphere HA in der neuen Version vom Anwender gar nicht zu sehen sind, so wurde trotzdem ein hohes Augenmerk auf die Usability der Software gelegt. Dabei kann nun ein Anwender recht schnell sehen, welche Rolle ein Knoten im Cluster übernommen hat sowie seinen »Gesundheitszustand«. Die Nachrichten mit den Hinweisen über eventuelle Fehlerzustände sind nun auch leichter zu verstehen und somit ist auch eine schnellere Reaktion darauf machbar.

Tritt ein Fehler auf, muss der Administrator nur noch eine Protokolldatei »durchwühlen« – auch das trägt dazu bei, dass dieser Fehler schneller beseitigt werden kann.