Klicken Sie im primären vCenter auf "Configure" und wählen Sie den Tabulator "vCenter HA" aus. Entscheiden Sie sich dann für "Set Up vCenter HA". Der Klick startet einen Assistenten, der Sie bei der weiteren Einrichtung unterstützt. Dieses Beispiel geht davon aus, dass das vCenter wie beschrieben "self-managed" ist – dass also die Instanz mit dem vCenter selbst auf einem ESXi-Host läuft, den dasselbe vCenter verwaltet. Im nächsten Schritt zeigt der Assistent Ihnen ein Fenster mit dem Titel "Resource Settings" an. Hierin wählen Sie das frisch angelegte HA-Netzwerk für Hochverfügbarkeit aus, das Sie zuvor für den primären Knoten eingerichtet haben.

vCenter konfigurieren

Danach geht es um eine zentrale Einstellung: vCenter betrachtet die Instanzen für den sekundären und den Witness Node nämlich grundsätzlich als Klon des originalen vCenter. Diese Konfiguration aktiviert im Hintergrund etliche Automatismen, was die Verwaltung der virtuellen Instanzen angeht. Der Assistent bietet Ihnen im folgenden Dialog die Möglichkeit, die benötigten Instanzen komplett automatisch als Klon zu erstellen. Diesen Schritt müssten Sie andernfalls später manuell erledigen, und es spricht nichts dagegen, dies den Assistenten machen zu lassen. Setzen Sie also den Haken bei der Checkbox für das automatische Anlegen der beiden Klone.

Dann gilt es, die beiden Klone passend zu konfigurieren. Klicken Sie zunächst für den passiven Knoten auf "Edit". Weisen Sie ihm einen eindeutigen Namen, einen Zielort sowie ein Deployment-Ziel und einen Datenspeicher zu. Wählen Sie beim Netzwerk beide Netzwerke aus, also das VMware-Management-Netzwerk, aber auch das frisch konfigurierte HA-Netz. Klicken Sie auf "Finish". Wiederholen Sie für den Witness-Knoten den gesamten Vorgang. Achten Sie hier erneut auf eindeutige Bezeichnungen und die korrekte Netzwerkkonfiguration. Klicken Sie einmal mehr auf "Finish" und fahren Sie im Assistenten fort. Danach geht es um die IP-Konfiguration der beiden Klone.

Alle drei Knoten brauchen statische IP-Adressen im HA-Netz. Wählen Sie dazu zunächst die IP-Version aus, also ob die Instanzen IPv4 oder IPv6 nutzen sollen, und geben Sie danach die entsprechenden Werte ein oder überprüfen Sie die Voreinstellungen. Klicken Sie schließlich auf "Finish". vCenter legt die Klone nun an und richtet auf der vCenter-Ebene Hochverfügbarkeit so ein, dass sowohl die Instanzen selbst als auch die darin laufenden Dienste überwacht werden. Am Ende des Vorgangs ist die vCenter HA-Konfiguration abgeschlossen (Bild 3).

Storage richtig planen

Nicht unter den Tisch fallen sollten im HA-Kontext Überlegungen zum Thema Speicher. Sie haben als Administrator schließlich nichts von der gesamten HA-Konfiguration, wenn letztlich alle Instanzen auf demselben Storage liegen und dessen Ausfall das gesamte Setup in den Abgrund reißt. Hier stoßen Sie wie so oft im HA-Kontext an die Kreuzung zwischen Investitionskosten und dem nötigen Maß an Redundanz.

Viele vCenter dürften mittlerweile vSAN einsetzen, jenes virtuelle SAN von VMware, das eine Art Vermittlerschicht zwischen VMware und physischer Hardware in Form eines Software-defined Storage implementiert. Das ist aber nicht die einzige Möglichkeit. Wenn Ihnen nur ein vCenter mit einem physischen Speicher zur Verfügung steht, ist das Thema der Redundanz schnell abgehandelt – denn hier besteht die theoretische Option erst gar nicht.

Anders sieht die Sache aus, wenn beispielsweise zwei NAS- oder SAN-Geräte verfügbar sind. Denn in diesem Fall gibt es mehr Gestaltungsspielraum. Dessen Details richten sich allerdings streng nach der Konfiguration vor Ort. Viele NAS-Appliances haben eingebaute Redundanzfunktionen und kümmern sich mehr oder weniger autark um ihre Verfügbarkeit. Sie wirken nach außen hin deshalb wie ein einzelnes Gerät. Ein solcher Ansatz lässt sich in vCenter zwar als vSAN einrichten. Hier muss die Virtualisierung aber darauf vertrauen, dass das Speichergerät genau weiß, was es tut, und etwa ausgefallene Dienste wie iSCSI-Targets automatisch und transparent auf dem Clusterpartner erneut startet. Entsprechende Features lassen die Hersteller sich teuer bezahlen.

Setzt ein Unternehmen umfangreich auf vSAN, dürften einige der Überlegungen in Sachen Redundanz aus diesem Artikel den Administratoren der jeweiligen Umgebungen bereits bekannt vorkommen. Auch ein vSAN setzt VMware-seitig nämlich auf mindestens drei Knoten. Es nutzt die normalen Speichergeräte handelsüblicher Software und ahmt damit Lösungen wie Ceph nach, selbst wenn es unter der Haube völlig anders funktioniert. Implizit ist vSAN redundant. Fällt ein Host eines vSAN-Clusters aus, bedeutet das also nicht den Ausfall des gesamten vSAN-Clusters. Die gute Nachricht ist: Ist auf der VMware-Seite bereits vSAN eingerichtet, lässt sich dieses recht problemlos als redundanter Speicher für vCenter HA nutzen. Die schlechte Nachricht ist, dass vSAN mit einem eigenen Preis ausgestattet ist und kein grundsätzlicher Bestandteil von vSphere.

Damit gilt: Wer klassische NAS- oder SAN-Anwendungen verwendet, sollte darauf achten, seinen primären und seinen sekundären vCenter-Host auf unterschiedlichen Speichern zu platzieren. Wer vSAN nutzt, hat diese Probleme im Kern nicht.

vSphere Fault Tolerance

Am Ende kehren wir einmal mehr zum ursprünglichen Thema der Redundanz für virtuelle Instanzen zurück. Die lässt sich grundsätzlich mit vSphere HA erreichen, wie der Artikel eingangs beschrieben hat. Denn vSphere HA kann neben den vCenter-Instanzen auch beliebige andere Instanzen auf die beschriebene Art und Weise redundant bereitstellen.

Alternativ zu vSphere HA steht noch vSphere Fault Tolerance (Bild 4) als HA-Option zur Verfügung. Die ist deutlich leichter einzurichten und verschiebt – wie vSphere HA – Instanzen von einem ausgefallenen Host auf einen anderen. Dabei kommt die Anwendung allerdings mit Einschränkungen daher. Das Konzept unterstützt keine Instanzen mit mehr als acht vCPUs. Obendrein schützt Fault Tolerance im Vergleich mit vSphere HA und vCenter HA die Umgebung am wenigsten gegen spezifische Arten von Ausfällen. Lediglich den Ausfall eines ganzen Compute-Systems kann die Technologie abfangen. Geht in Instanzen etwa auf Seiten des Betriebssystems oder auf Dienstebene etwas schief, bemerkt Fault Tolerance das erst gar nicht. Schutz gegen Betriebssystemprobleme bietet vSphere HA, wenn es entsprechend konfiguriert ist. vCenter HA bietet wie beschrieben ebenfalls Schutz gegen den Ausfall einzelner Dienste in den vCenter-VMs.

Im Gegenzug benötigt Fault Tolerance abgesehen von einem dicken Netz keine spezifischen Voraussetzungen und ist in wenigen Klicks eingerichtet. In der Realität muss der Admin zwischen den verschiedenen HA-Optionen weise wählen. Wer die Einschränkungen bei den Managementfunktionen in Kauf zu nehmen bereit ist, wird sein vCenter jedenfalls mit vCenter HA absichern. Ob einzelne VMs besser mittels Fault Tolerance oder vSphere HA abzusichern sind, entscheidet der Einzelfall.

Fazit

VMware bietet zahlreiche Herangehensweisen, um sowohl sich selbst als auch die von ihm betriebenen virtuellen Instanzen hochverfügbar zu machen. vSphere HA und vSphere Fault Tolerance beziehen sich dabei vorrangig auf die virtuellen Instanzen; vCenter HA klont ein ganzes vCenter und betreibt es als Aktiv-Passiv-Cluster. Als einziger Ansatz ist vCenter HA in der Lage, bis auf die Ebene einzelner Dienste hinab den Gesundheitszustand eines vCenter adäquat zu bewerten und auf dieser Basis Aktionen einzuleiten. Der Administrator erkauft sich diese Redundanz aber durch ein zum Teil deutlich komplexeres Netzwerksetup, mehr Konfigurationsarbeit und einer anteiligen Einschränkung im Hinblick auf die nutzbaren vCenter-Funktionen. Welche Methode sinnvoll ist oder ob eine Kombination aus verschiedenen der vorgestellten Mechanismen der Weisheit letzter Schluss ist, hängt deutlich von den Begebenheiten vor Ort ab. (ln)

Im ersten Teil haben wir uns angeschaut, welche Möglichkeiten es für HA in vSphere und vCenter überhaupt gibt und wie Sie mit "vSphere HA" für einen Basisschutz sorgen. Im zweiten Teil gingen wir darauf ein, warum Sie in komplexeren Umgebungen auf "vCenter HA" setzen sollten und wie dabei die Voraussetzungen und ersten Schritte aussehen.

Über den Autor: Martin Loschwitz ist Gründer und Geschäftsführer der True West IT Services GmbH. Nebenberuflich schreibt er als freier Journalist zu Themen wie Cloud Computing, Virtualisierung und Container.