vSphere-HA: Antworten auf Fehler im Cluster konfigurieren

Reaktion bei Ausfall eines (Master-)Hosts

Nur bei Host-Fehlern (Master oder Slave) ist die gewünschte Response in aller Regel VMs neu starten, was ja auch dem eigentlichen Sinn von vSphere HA entspricht. Der einzige Unterschied zwischen dem Ausfall eines Master- oder Slave-Hosts besteht darin, dass bei Ausfall des Masters unter den verbleibenden Slaves ein neuer Master gewählt wird. Der Election-Prozess bzw. das Election-Protokoll wird ebenfalls über das Management-Netzwerk abgewickelt.

Im Normalfall gewinnt der Slave, welcher die meisten Datastores verbunden hat. Bei Gleichstand zählt die MOID (Managed Object-ID), die man zum Beispiel mit dem Managed Object Browser (MOB) unter der URL https://<vCenter-FQDN>/mob ermitteln kann. Die Zählweise ist lexikalisch, d. h., 10 ist zwar größer als 9, 100 aber kleiner als 99. Wer aktuell Master ist, erkennt man im Reiter Übersicht bei markiertem Cluster auf dem Tab vSphere HA im Abschnitt Hosts.

Konfiguration der Host-Isolation-Response

Bei Host-Ausfällen ist also die vorgegebene Reaktion VMs neu starten, so dass die Anwendungen über andere Knoten verfügbar sind. Schwieriger ist es, eine allgemein gültige Antwort auf eine Host-Isolierung zu finden, ohne dass man die Verkabelung des Netzwerks und des Storage genau kennt.

Hier drei Beispiele, bei denen es nicht um den Ausfall eines Hosts geht:

Fall 1

In diesen Fall ist durch die angedeutete Unterbrechung lediglich die Kommuni­kation zwischen den Hosts über den mittleren Management-Switch unter­brochen.

Alle Nutzer können aber über den rechten Switch noch auf ihre VMs zugreifen und der linke Host kann weiterhin seine VMDKs erreichen. Das korrekte Antwort­verhalten wäre hier, die VMs eingeschaltet zu lassen (Option Deaktiviert für die Einstellung VMs neu starten).

Fall 2

In diesem Beispiel mit nur zwei Switches laufen die VMs zwar auch weiter, die Benutzer kommen an ihre VMs aber nicht mehr heran, weil die Kommunikation zum LAN unterbrochen ist. Die korrekte Reaktion wäre in diesem Fall entweder Herunterfahren oder Ausschalten.

Ersteres ist immer die bessere Wahl, erfordert aber installierte VMware Tools. Der Fault Domain Manager (FDM) bzw. HA-Master veranlasst dabei, dass in der jeweiligen VM-Konfigurationsdatei (.vmx) ein Eintrag der Form

CleanShutdown = False

hinterlassen wird. Er erlaubt es nach angemessenem Timeout einem anderen Host im Cluster, die auf dem isolierten Host herunter­gefahrenen VMs neu zu starten.

Der korrekte Response für Reaktion bei Hostisolierung wäre im Konfigurations­abschnitt Fehler und Reaktionen der Eintrag VMs herunterfahren und neu starten oder VMs ausschalten und neu starten.

Fall 3

Komplizierter ist Fall 3. Hier geht den VMs durch die Isolierung offensichtlich der Zugriff auf ihre VMDKs verloren und die VMs können nicht mehr vom Nutzer herunter­gefahren werden. Wie VMs darauf reagieren, ist unterschiedlich und hängt von Betriebssystem ab. Die meisten Systeme würden sich aufhängen oder mit 100 Prozent CPU- oder Netzlast weiterlaufen.

Zudem geht der Lock auf die VM-Dateien verloren, weil ja der ESXi-Host selbst ebenfalls vom Storage abgeschnitten ist. Daher werden die VMs durch HA auf einem anderen Host neu gestartet, was aber unweigerlich zu einer Split-Brain-Situation führt, nachdem die virtuellen Maschinen ja dann doppelt im System laufen.

Es ist jedoch immer nur eine Instanz in der Lage, die virtuellen Festplatten der VMs zu lesen oder darauf zu schreiben. Um einen solchen Split-Brain-Zustand zu verhindern, kann man ab vSphere 6.0 den sogenannten VM-Komponenten­schutz (VMCP) aktivieren. Dabei überwacht HA die Verbindung der VMs zu ihren Daten­speichern. Bei Verlust derselben starten die VMs auf einem anderen Host neu, der noch über nutzbare Pfade zum Datenspeicher verfügt.