Tags: vSphere, Troubleshooting, Cluster, Hochverfügbarkeit
Wie vSphere HA auf die Host-Überwachung (Failure, Isolation, Partition), das VM-Monitoring (VM only oder VM+App) oder auf Datenspeicherfehler (VMCP) reagieren soll, muss der Admin selbst festlegen. Allgemeine Regeln lassen sich dafür nur schwer aufstellen, weil die Antwort von der Vernetzung des Clusters und des Speichers abhängt.
Die Antwort von vSphere HA auf erwartbare Probleme lässt sich im Dialog Clustereinstellungen bearbeiten unter dem Abschnitt Fehler und Reaktionen konfigurieren, wenn man zuvor den betreffenden Cluster im Inventar markiert hat.
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 Kommunikation zwischen den Hosts über den mittleren Management-Switch unterbrochen.
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 Antwortverhalten 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 heruntergefahrenen VMs neu zu starten.
Der korrekte Response für Reaktion bei Hostisolierung wäre im Konfigurationsabschnitt 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 heruntergefahren 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-Komponentenschutz (VMCP) aktivieren. Dabei überwacht HA die Verbindung der VMs zu ihren Datenspeichern. Bei Verlust derselben starten die VMs auf einem anderen Host neu, der noch über nutzbare Pfade zum Datenspeicher verfügt.
Täglich Know-how für IT-Pros mit unserem Newsletter
Thomas Drilling arbeitet ist seit fast 30 Jahren selbständig in der IT-Welt sowohl als Consultant, als auch als Redakteur, Buchautor und Journalist für viele ehemalige und aktuelle IT-Magazine sowie Blogs.
Aktuell bestätigt sich Thomas schwerpunktmäßig als IT-Trainer für Cloud-Computing in den Bereichen Microsoft Azure, Amazon Web Services und VMware.
Thomas ist zertifizierter Microsoft-Trainer für nahe das gesamte Portfolio an Microsoft Azure Trainings. Thomas ist außerdem zertifizierter Microsoft Azure Solutions Architect Expert sowie VMware Certified Professional und wurde von VMware in den Jahren 2016 bis 2022 mit dem Blogger-Status vExpert ausgezeichnet.
Thomas führt aktuell jeden Monat zwei selbstkonziperte 4-tägigen Grundlagenkurse in Cloud Computing mit Azure durch, die sich inhaltlich bewusst von den Microsft-Kursen abheben und vorzuweise als Bootcamp in eine besonderen Lokation stattfinden. Optional kann aber aber auch remote via Microsoft Teams teilgenommen werden.
Das aktuelle Trainingsprogramm findet sich unter Azure-Trainings. Weitere Informationen und Anmeldung über sein Azure-Blog.
Verwandte Beiträge
- VMs bei Absturz des Gast-OS über vSphere HA Application Monitoring neu starten
- VMware vSphere DRS: Affinitätsregeln
- vSphere-Hochverfügbarkeit: Fehlertypen für Host-Protection erkennen
- Anleitung: Cluster für High Availability (HA) in VMware vSphere erstellen
- Hochverfügbarkeit für virtuelle Maschinen: Was ist vSphere HA?
Weitere Links