Befürworter des Cloud-Ready-Ansatzes argumentieren gern, dass der Themenkomplex Hochverfügbarkeit heute eigentlich keiner mehr sei. In der schönen neuen Welt kümmert sich jedes Programm um die eigene Verfügbarkeit: Anwendungen synchronisieren persistente Daten im Hintergrund, erledigen die Konsensfindung komplett automatisch und sind an jeder Ecke beliebig um neue Instanzen einzelner Dienste erweiterbar. Ebenso problemlos verläuft der Wegfall einer Instanz eines Dienstes, ganz gleich, ob dieser wegen eines Problems eintritt oder weil der Administrator das Setup einer Schrumpfkur unterzieht. Service-Meshes sorgen autark dafür, dass eingehende Clients automatisch bei den richtigen Diensten landen, und auch sonst geschieht alles vollautomatisch.

Blöd nur, dass die Prinzipien von "Cloud Ready" fast ausschließlich auf Anwendungen neueren Datums anwendbar sind. Legacy-Software will von Cluster-Magie und Automatismen meist nichts wissen. Hier ist die Erwartung an den Administrator stattdessen, dass er Hochverfügbarkeit auf der Ebene der Infrastruktur einzieht. Bei einer vSphere-Umgebung ergeben sich hier mehrere Möglichkeiten: In virtuellen Instanzen etwa lässt sich problemlos ein Clustermanager installieren, der dann auf der Ebene der VMs für einzelne Anwendungen Hochverfügbarkeit gewährleistet – Pacemaker und der Linux-HA-Cluster-Stack lassen grüßen.

Elegant ist so etwas nach allgemeiner Auffassung aber nicht, gerade dann, wenn Unternehmen viel Geld in die Hand nehmen, um sich die mannigfaltigen Optionen eines kommerziellen Produkts wie vSphere ins Haus zu holen. Gefragt ist stattdessen eine Lösung "out of the box". Und VMware liefert hier: Gleich auf zwei Ebenen bietet der Hersteller umfassende HA-Möglichkeiten.

Ausfallsicher in zwei Dimensionen

Es schadet an dieser Stelle nicht, sich zunächst mit den zwei Möglichkeiten der Hochverfügbarkeit zu befassen, die es bei VMware grundsätzlich gibt. Denn die spaltet sich in zwei Teile auf: Die erste bezieht sich vor allem auf die Hochverfügbarkeit der Verwaltung selbst. Das betrifft bei VMware vor allem das vCenter, also die zentrale Steuerinstanz der Virtualisierungsumgebung. Fällt diese aus, führt das nicht automatisch in allen Szenarien zu einem "Loss of Functionality" auf Seiten der virtuellen Maschinen, ganz sicher aber zu einem "Loss of Control". Es ist dann nicht möglich, bestehende Instanzen zu verändern oder neue zu starten. Verhindern lässt sich dieses Szenario nur, indem vCenter selbst mit allen benötigten Zusatzkomponenten hochverfügbar wird.

Die andere Dimension der Hochverfügbarkeit betrifft die virtuellen Instanzen selbst. Ein Dienst wie vCenter legt sich ja quasi um VMs herum, bekommt aus der Umgebung, innerhalb derer vCenter läuft, also Informationen etwa zu Ereignissen, die den Programmen in den VMs nicht zur Verfügung stehen. Merkt vCenter, dass ein Compute-Knoten ausgefallen ist, kann es die dortigen Instanzen ohne Probleme woanders erneut starten, falls diese auf persistentem Speicher liegen. Das dürfte in den allermeisten virtuellen Umgebungen auf vSphere-Basis der Fall sein.

Die Herausforderung aus Sicht des Administrators besteht nun darin, die beiden – doch deutlich unterschiedlichen – Dimensionen von HA in VMware sinnvoll unter einen Hut zu bringen. So viel sei schon jetzt verraten: Mehrere Wege führen nach Rom – oder eher zu umfassender VMware-Hochverfügbarkeit.

Basisschutz durch vSphere HA

Der simpelste Weg zur Hochverfügbarkeit auf vCenter-Ebene ist die Nutzung von vSphere HA (Bild 1). Dabei beschränkt sich vSphere HA gar nicht auf das vCenter – stattdessen bietet es eine einfache Möglichkeit, ausgefallene VMs von ESXi-Hosts auf anderen Systemen automatisiert neu zu starten. Weil auch vCenter selbst in einer virtuellen Instanz läuft, deckt vSphere HA die Verfügbarkeit von vCenter quasi automatisch mit ab. Um diesen Effekt zu erreichen, kombiniert VMware mehrere Instanzen.

So lassen sich die virtuellen Instanzen einerseits von außen über Werkzeuge wie die VMware Tools steuern. Andererseits bietet die "vCenter Server und VM Component Protection" (VMCP) grundlegenden Schutz für die eingesetzten Datenspeicher in VMware. VMCP ist auch die Komponente, die beim Ausfall eines ESXi-Systems den Neustart auf einem anderen physischen System initiiert. Hierzu betreibt vSphere HA einen Dienst namens "Fault Tolerance Manager", der ebenso wie die Instanzen selbst hin- und herwandert.

Das Problem dieses Ansatzes ist, dass er nicht "application-aware" ist, von den laufenden Anwendungen innerhalb etwa des vCenter also nichts weiß. vSphere HA schaufelt stumpf ausgefallene Instanzen zwischen den ESXi-Systemen hin und her, hat dadurch aber auch keine Kenntnis vom Zustand der Anwendungen beispielsweise in einer vCenter-Instanz. Das ist allerdings durchaus relevant: Teil von vCenter ist ja beispielsweise eine Datenbank (vPostgreSQL), und längst hat sich in der Industrie die Maxime durchgesetzt, dass datenverarbeitende Dienste ihre Hochverfügbarkeit idealerweise selbst abwickeln, statt dabei von außen Hilfe zu bekommen.

Für sehr grundlegende Umgebungen, die möglichst wenig Aufwand bei der Anschaffung und im Betrieb hervorrufen sollen, ist vSphere HA insofern geeignet. Wer eine umfassendere Lösung benötigt, fährt mit der dedizierten Option für Hochverfügbarkeit in vCenter besser. (ln)

Im zweiten Teil der Workshopserie gehen wir darauf ein, warum Sie in komplexeren Umgebungen auf vCenter HA setzen sollten und wie dabei die Voraussetzungen und ersten Schritte aussehen. Im dritten und letzten Teil erklären wir, wie Sie VCenter richtig für HA konfigurieren und wie der Storage in hochverfügbaren Umgebungen aussehen sollte.

Ü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.