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


    Tags: , ,

    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.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Thomas Drilling

    Thomas Drilling arbeitet seit mehr als 20 Jahren selb­ständig als Redakteur und Autor für viele ehe­malige und aktuelle IT-Magazine sowie Blogs. Thomas ist zudem Buch­autor und IT-Consultant.

    Seit 5 Jahren ist Thomas neben seiner journa­listischen Tätig­keit haupt­beruflicher, selb­ständiger IT-Trainer für VMware und Microsoft.

    Seine Themen­schwer­punkte sind Virtua­lisierung und Cloud Com­puting, speziell VMware, Amazon Web Services, Google Cloud und Microsoft Azure. Thomas ist zerti­fi­zierter VMware Professional, Advanced Professional und wurde von VMware in den Jahren 2016, 2017, 2018, 2019 und 2020 mit dem Blogger-Status vExpert ausge­zeichnet.

    Thomas ist außerdem zertifi­zierter AWS Solu­tions Archi­tect, Sysops Engineer und Devops Engineer sowie Microsoft Certified Azure Admini­strator.

    Thomas führt aktuell jeden zwei­ten Mon­tag einen 4-tägigen Grund­lagenkurs in Cloud Computing mit AWS via Zoom-Meeting durch. Weitere Infor­mationen und Anmel­dung über sein AWS-Blog.

    Ähnliche Beiträge

    Weitere Links