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

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.

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.

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:

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.