Cluster konfigurieren
Zum Einleiten der Cluster-Konfiguration im Cluster-Schnellstart klicken Sie unter "3. Cluster konfigurieren" auf die Schaltfläche "Konfigurieren". Ein Assistent leitet Sie dann – angenommen Sie haben unter "1. Cluster-Grundlagen" HA und DRS aktiviert – durch die drei Abschnitte "Distributed Switche", "vMotion-Datenverkehr" und "Erweiterte Optionen". So können Sie beispielsweise bis zu drei verteilte Switches auswählen. Der Quickstart achtet beim Erstellen eines verteilten Switches zum Beispiel auch darauf, dass jedem mindestens ein physischer Adapter zugewiesen ist. Alternativ lässt sich aber auch das Kontrollkästchen "Netzwerkeinstellungen später konfigurieren" aktivieren, um die Standardeinstellungen nur für die Cluster-Dienste zu konfigurieren und alle Optionen auszublenden, die sich auf das Hostnetzwerk beziehen. Entscheiden Sie sich dafür, können Sie die Netzwerkkonfiguration jedoch nicht mithilfe des Assistenten zum Konfigurieren von Clustern durchführen.

Im Abschnitt "Erweiterte Optionen" lassen sich die konkreten Einstellungen für "vSphere HA" und "vSphere DRS" vornehmen, wobei die Default-Werte so gewählt sind, dass beide Funktionen out-of-the-box ohne jede weitere Konfiguration gut funktionieren. Das HA-Feature überwacht in der Standardkonfiguration zum Beispiel "nur" den Ausfall von ESXi-Hosts und startet betroffene VMs wie erwähnt auf dem oder den verbleibenden Host(s) neu. Die aktivierte "Zugangssteuerung" stellt sicher, dass auf allen beteiligten Hosts genügend Kapazität freigehalten wird. Somit sind sämtliche zum Zeitpunkt der Aktivierung des HA-Clusters laufenden virtuellen Maschinen auch tatsächlich geschützt. Sie finden also im Notfall auch genügend Kapazität auf den verbleibenden Hosts, um einen Neustart durchzuführen. Das ist insbesondere dann wichtig, wenn die VMs über CPU- oder Memory-Reservierung verfügen, die ja beim Neustart zur Verfügung stehen muss. Die Konsequenz einer aktivierten Zugangssteuerung kann dann zum Beispiel in eher kleinen Clustern (Minimum sind zwei Hosts) sein, dass sich im regulären Betrieb trotz offenbar ausreichender Ressourcen keine neuen VMs starten lassen.

Die Standardeinstellung für vSphere DRS ist die "vollautomatisierte" Automatisierungsstufe. vMotion verschiebt VMs dann selbständig auf einen anderen Host im Cluster, wenn der eingestellte Migrationsschwellenwert erreicht ist. Bei den Hostoptionen können Sie für alle Hosts im Cluster prüfen lassen, ob beispielsweise für DRS der Sperrmodus aktiviert ist oder die angegebenen NTP-Server existieren.

Der Abschnitt "Erweiterte vMotion-Kompatibilität" bezieht sich auf das eingangs erwähnte Cluster-Feature "EVC". Ist es aktiviert, lassen sich virtuelle Maschinen auch dann per vMotion zwischen Quell- und Ziel-Host verschieben, wenn deren CPUs nicht identisch sind. Sie können dazu eine gemeinsame Chipset-Baseline definieren – in Bild 2 "Haswell" für Intel-CPUs – die per CPUID für die jeweils "bessere" CPU erzwungen wird, damit die auf den betreffenden VMs laufenden Anwendungen identische CPU-Instruction-Sets vorfinden. Natürlich können Sie die vom Cluster-Schnellstart getroffenen Einstellungen später immer noch manuell ändern. Bei dieser Gelegenheit möchten wir weitere Aspekte im Kontext von DRS und HA erläutern.

Einrichten von vSphere High Availablity
Wie erwähnt stattet das Feature "vSphere HA" virtuelle Maschinen mit Hochverfügbarkeit aus, indem es per Default die Hosts überwacht, auf denen die VMs laufen und optional auch die virtuellen Maschinen selbst. Dazu müssen die Hosts Teil des HA-Clusters sein.

Nach dem Aktivieren von High Availability im Cluster und dem Aufnehmen der Hosts startet vSphere HA dazu auf jedem einzelnen einen zuständigen Managementagent (FDM = Fault Domain Manager). Voraussetzung ist das Vorhandensein eines VMkernel-Adapters, auf dem der Dienst "Management" aktiviert ist. Wie erwähnt ist das zwar per Default so, VMware empfiehlt für eine zuverlässige HA-Konfiguration aber mindestens zwei davon. Der Agent veranlasst das genannte Heartbeating zwischen den beteiligten Hosts. Sollte der Agent einmal nicht laufen, können Sie ihn über das Kontextmenü des Hosts in der Bestandsliste mit "Für vSphere HA neu konfigurieren" neu starten. In diesem Konstrukt gibt es genau einen Host, der die Rolle primär innehat, alle anderen sind sekundär.

Beim Erstellen des Clusters nehmen alle zu dem Zeitpunkt aktiven Hosts an der Wahl des primären Hosts für den Cluster teil. Es gewinnt derjenige, der die meisten Datenspeicher verbunden hat. Sofern es nicht durch einen Netzwerkfehler zu einer Split-Brain-Situation kommt, gibt es immer nur einen primären Host pro Cluster. Fällt der primäre aus oder Sie fahren ihn zu Wartungszwecken herunter, wird unter den verbleibenden sekundären Hosts ein neuer primärer gewählt. Welcher Host aktuell die Rolle "primärer Host" hat, ob die Managementagenten korrekt laufen, wie viele sekundäre Hosts mit dem Cluster verbunden sind, wie viele VMs aktuell geschützt sind und vieles mehr, erfahren Sie in der Bestandsliste bei markiertem Host im Registereiter "Überwachen" im Abschnitt "HA / Übersicht".

Primärer Host überwacht sekundäre Hosts
Der primäre Host ist für das Überwachen des Zustands von allen sekundären Hosts zuständig, wozu er die erwähnten Taktsignale initiiert und auf Antwort wartet. Fällt ein sekundärer Host aus oder ist aus anderen Gründen nicht erreichbar, ermittelt der primäre Host die virtuellen Maschinen, die neu gestartet werden müssen. Haben Sie neben der Hostüberwachung das Monitoring des Betriebszustands aller geschützten virtuellen Maschinen aktiviert, kümmert sich der primäre Host auch um den Neustart einer VM, die nicht auf die über die VM-Tools verteilten VM-Heartbeats antwortet. Der primäre Host bestimmt den sekundären Host, auf dem der Neustart der betroffenen VM erfolgt. Dazu verwaltet er auch eine Liste sämtlicher Cluster-Hosts und aller geschützten virtuellen Maschinen. Nicht zuletzt dient der primäre Host auch als vCenter-Server-Verwaltungsschnittstelle für den Cluster und meldet dessen Zustand.

Das bedeutet, dass die HA an sich auch bei ausgefallenem vCenter weiterläuft und VMs schützt, da der Fault-Domain-Manager-Service als Dienst auf dem Host läuft. Zum Einrichten und Überwachen von HA brauchen Sie aber selbstverständlich das vCenter. Die Taktsignale (Heartbeats) mit denen der primäre Host erkennt, ob die sekundären Hosts noch antworten, werden zur Sicherheit nicht nur über zwei redundante Managementnetzwerke im LAN verschickt, sondern zusätzlich auch noch über das Speichernetzwerk (Datastore-Heartbeats). Dies erhöht für den primären Host die Erkennungssicherheit, ob tatsächlich ein Host-Fehler oder vielleicht nur eine Host-Isolierung im Netzwerk vorliegt. Schließlich bleiben die Heartbeats aus Sicht des primären Host auch dann aus, wenn Netzwerkfehler vorliegen. Für das korrekt Funktionieren von HA ist es aber entscheidend, dass der primäre Host treffsicher beurteilen kann, ob der sekundäre Host, vom dem die Taktsignale ausbleiben, tatsächlich ausgefallen ist oder nicht.

Die ganze HA-Strategie von VMware beruht darauf, dass der Speicher der virtuellen Maschinen (*.VMDK) auf einem Shared Storage liegt, auf dem alle Hosts im Cluster Zugriff haben und was die Voraussetzung dafür ist, dass sich die betreffenden VMs überhaupt neu starten lassen. Bootet aber der primäre Host VMs neu, die gar nicht ausgefallen sind, nur weil er wegen eines Netzwerkfehlers keine Taktsignale über das Managementnetzwerk empfängt, laufen die VMs doppelt. Das kann zu den unterschiedlichsten Phänomenen oder Konflikten führen. Allerdings ist der HA-Algorithmus, der für die Erkennung eines Hostausfalls oder Netzwerkfehlers zuständig ist, sehr intelligent und treffsicher. Er versucht nämlich bei ausbleibenden Taktsignalen zunächst einen Liveness-Ping. Wird der beantwortet, aber das Taktsignal bleibt aus, läuft schlicht der HA-Agent nicht. Kommen Netzwerktaktsignale an, liegt kein Host-Fehler vor. Kommen Netzwerktaktsignale nicht an, wohl aber die Taktsignale über das Speichernetzwerk, kann kein Host-Fehler vorliegen. Es muss also ein Netzwerkfehler sein. Beim diesem kann der Algorithmus sogar noch zwischen einer Hostisolierung und einer Netzwerkpartitionierung unterscheiden. Letztere liegt vor, wenn Sie die konfigurierbare Isolationsadresse (in der Regel das Default-Gateway) nicht erreichen.

Übrigens ist das Standardverhalten von vSphere HA für einen Hostausfall das Neustarten der VMs. Für andere von vSphere HA behandelte Fehlerarten, wie eine Hostisolierung, einen Datastore-Zugriffsfehler (die VM ist von ihren Disks/VMDKs abgeschnitten), einen VM-Fehler oder einen Applikationsfehler, ist das Antwortverhalten von vSphere HA bei markiertem Cluster in der Bestandsliste im Reiter "Konfigurieren" im Abschnitt "Dienste / vSphere HA" unter "Fehlerbedingungen und Reaktionen" einsehbar. Möchten Sie die Einstellungen ändern, müssen Sie rechts neben "vSphere HA ist eingeschaltet" auf die Schaltfläche "Bearbeiten" klicken und dann zum Reiter "Fehler und Reaktionen" navigieren.

jm/ln/Thomas Drilling

Im ersten Teil des Workshops erklären wir, was vSphere 7 überhaupt unter einem Cluster versteht und wie Sie mithilfe des Schnellstart-Assistenten die Erstkonfiguration vornehmen. Im zweiten Teil schließen wir die Erstkonfiguration ab und schildern das Einrichten von vSphere HA. Im dritten und letzten Teil des Workshops geht es vor allem um Failover-Kapazität und Lastausgleich mit vSphere DRS.