vSphere-HA: Antworten auf Fehler im Cluster konfigurieren

    Kostenloses eHandbook: Überblick und Praxistipps zu vSphere 6.5. Scripting mit PowerCLI 6.5, neue HA-Features und FT nutzen, u.v.m. Download »

    (Anzeige)

    VMware vSphere HAWie vSphere HA auf die Host-Über­wachung (Failure, Isolation, Partition), das VM-Monitoring (VM only oder VM+App) oder auf Daten­speicher­fehler (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.

    Konfiguration der Antworten von HA auf vorgegebene Fehlertypen

    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.

    Aktuellen Master-Host eines HA-Clusters anzeigen im vSphere Web-Client

    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.

    Szenario mit Unterbrechung des Management-Netzwerks

    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.

    Benutzer können ihre Anwendungen nicht mehr erreichen, weil die Verbindung zum LAN unterbrochen ist.

    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.

    Reaktionen bei Host-Isolierung

    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.

    Fehler, bei dem die Hosts von den VMDKs getrennt sind

    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.

    Keine Kommentare