vSphere-Hochverfügbarkeit: Fehlertypen für Host-Protection erkennen

    Kostenloser Leitfaden: Deployment und Konfiguration von Windows 10. Image-Management mit ADK und MDT, Installation in VHDX, u.v.m. Zum Download »

    (Anzeige)

    VMware vSphere HABei vSphere HA muss der Master-Host die verschie­denen Ausfall-Szenarien zuver­lässig erkennen, um ange­messen auf die jeweilige Situ­ation reagieren zu können. Dazu prüft der zuständige Algo­rithmus eine Reihe von Signalen und Kriterien, um einen versehent­lichen Neustart von virtu­ellen Maschinen zu vermeiden.

    Bei einem ausgefallenen Slave-Host (oder Master-Host) ist die Sache relativ klar, denn dann können und müssen die virtuellen Maschinen in jedem Fall auf einem anderen Host neu hochgefahren werden. Dies darf aber nicht passieren, weil nur die Taktsignale ausbleiben.

    Dies könnte zu einer Split-Brain-Situation führen, wenn die Heartbeats nur wegen Problemen im Management-Netzwerk nicht ankommen, der Host aber noch lebt. In diesem Fall wäre es möglicher­weise fatal, die VMs noch einmal auf einem anderen Host zu starten. Daher sollte das Management-Netzwerk möglichst redundant ausgelegt sein.

    Fehler-Szenarien für Host-Monitoring

    VMware hat darüber hinaus eine Reihe zusätzlicher Maßnahmen eingeführt, um die Erkennungs­sicherheit zu erhöhen. So besteht etwa die Möglichkeit, eine zweite Art von Taktsignalen zusätzlich über das Storage-Fabric auszutauschen (Datastore Heartbeats).

    Erst wenn auch diese ausbleiben, ist die Wahrscheinlichkeit für einen Host-Ausfall (im Vergleich zu einem Netzwerkausfall) relativ hoch. Darüber hinaus gibt es noch so genannte Isolationsadressen, die im Ernstfall ge-pingt werden, um eine Netzwerk-Partitionierung von einer Host-Isolierung zu unterscheiden.

    Folgende Tabelle, die aus dem frei zugänglichen vSphere-HA-Deepdive von Duncan Epping (dem federführenden Entwickler des Fault Domain Manager (FDM)) stammt, erläutert die Zusammenhänge.

    Übersicht über die Signale zu Erkennung von Fehlertypen in vSphere HA

    Der HA-Status ist bei aktiviertem HA-Cluster im Normalfall Running, das heißt, die Network-Heatbeats (über den VMKernel-Adapter Management-Netzwerk) kommen an. Dann spielen alle weiteren Erkennungs­kriterien keine Rolle.

    Kommen weder Network- noch Storage-Heartbeats an, aber der betreffende Host kann vom Master über dessen Management-Adresse gepingt werden, dann ist der FDM-Agent nicht aktiv und muss ggf. neu gestartet werden. Dies kann im Web-Client mit Hilfe des Kontextmenü-Eintrages Für vSphere HA neu konfigurieren erfolgen.

    Agenten des Fault Domain Manager neu starten über den vSphere Web Client

    Fehlertypen

    Dem FDM-Master kommt eine besondere Rolle zu, muss er doch zwischen einem ausgefallenen und einem Host unterscheiden, der sich in einer Netzwerk­partition befindet oder der netzwerk­isoliert ist. Der Algorithmus zur Erkennung, welche Art von HA-Fehler vorliegt (Fehler, Isolierung, Partition), arbeitet dann gemäß obiger Tabelle wie folgt:

    Allgemein überwacht der Master-Host, ob die Slave-Hosts im Cluster noch aktiv sind. Kommen die im Sekundentakt generierten Heartbeat-Signale vom Slave-Host über das Management-Netzwerk nicht an, deklariert der Master den Slave nicht sofort als ausgefallen, sondern überprüft zunächst, ob der Slave-Host noch aktiv ist.

    Dazu ermittelt der Master, ob der Slave Taktsignale mit seinem Datenspeicher austauscht. Außerdem überprüft er, ob der betreffende Host auf ICMP-Pings reagiert, die er direkt an dessen Management-IP absetzt.

    Reagiert dieser nicht auf die ICMP-Pings, kann der Master auch nicht mit dem Management-Agent des Slaves kommunizieren und er kann ihn dann zuverlässig als failed einstufen. In diesem Fall kommt die konfigurierte Standard-Response für fehlgeschlagene Hosts (Restart VMs) zum Einsatz.

    Tauscht aber der Slave-Host noch Heartbeats mit einem Datenspeicher aus, dann geht der Master-Host davon aus, dass sich der Slave-Host in einer Netzwerk­partition befindet oder netzwerk­isoliert ist. Den Unterschied skizziert folgende Abbildung:

    Unterschied zwischen einer Isolierung und Netzwerkpartionierung bei Nicht-Erreichbarkeit eines Hosts.

    Der Master-Host fährt dann aber mit dem Überwachen des Hosts und seiner virtuellen Maschinen fort. Eine Hostnetzwerk­isolierung liegt vor, wenn ein Host noch ausgeführt wird, jedoch keinen Datenverkehr von den vSphere HA-Agenten im Verwaltungs­netzwerk beobachten kann.

    Ist das der Fall, dann versucht der Host seine konfigurierten Cluster-Isolierungsadressen zu pingen. Schlägt der ping-Befehl ebenfalls fehl, erklärt sich der Host als vom Netzwerk isoliert. Der Master-Host überwacht dann weiter die virtuellen Maschinen, die auf einem isolierten Host ausgeführt werden. Stellt er fest, dass die VMs ausgeschaltet werden (weil das beispielsweise die konfigurierte Response für Host-Isolation ist), dann startet er die VMs ggf. neu.

    Überwachung von VMs

    Der Master hat aber neben der Überwachung des Zustands von Slave-Hosts noch weitere Aufgaben:

    • Er identifiziert die VMs, die neu gestartet werden müssen.
    • Der Master überwacht den Betriebs­zustand aller geschützten VMs. Fällt eine VM aus (VM Monitoring via VMware Tools), startet er die VM neu.
    • Mithilfe einer Engine für die lokale Platzierung bestimmt der Master-Host auch den Ort, an der der Neustart erfolgen soll.
    • Zudem verwaltet der Master die Listen der Cluster-Hosts und der geschützten virtuellen Maschinen.
    • Und er dient dem vCenter-Server als Verwaltungs­schnittstelle für den Cluster und meldet den Zustand des Clusters.

    Keine Kommentare