Ungleich leistungsfähiger und deutlich komplexer kommt vCenter HA (VCHA) daher. Die Funktion ist relativ neu; sie steht erst seit vCenter 6.5 zur Verfügung und ersetzt den vCenter Server Heartbeat im Gespann mit dem vCenter Self-Monitoring Agent. Bei VCHA bekommt der Administrator es mit einem waschechten Cluster zu tun. Grundbaustein sind mindestens drei parallel laufende vCenter-Instanzen. Der "Active Node" ist dabei die gerade aktive vCenter-Instanz, der "Passive Node" ist der sekundäre Knoten, der automatisch zum Active Node wird, wenn der aktuell aktive Knoten ausfällt. Hinzu kommt ein "Witness node". Der überwacht sowohl den aktiven als auch den passiven Knoten und betreibt selbst keine Instanzen. Er bietet aber den beiden laufenden Instanzen ein Quorum, um katastrophale Fälle von Datenverlust durch Split-Brain-Situationen zu vermeiden.

vCenter HA kann mehr

Wer mit den Begriffen Quorum und Split Brain nichts anfangen kann: Beide Begriffe entstammen der Konzeption verteilter Umgebungen, wie ein kleiner HA-Cluster es bereits ist. Nicht umsonst gelten verteilte Systeme als eine der Königsdisziplinen der modernen IT. Mit zu den gefährlichsten Aspekten solcher Systeme gilt seit jeher die Datenhaltung. Denn grundsätzlich gilt: Wenn Daten an zwei Orten vorzuhalten sind, muss eine schlaue Software dafür sorgen, dass diese einerseits synchron sind und bleiben und dass andererseits keine Situation entsteht, in der voneinander unkoordiniert auf die beiden Instanzen eines Datensatzes schreibend zugegriffen wird. Genau das wäre nämlich ein Split Brain, und ein eben solcher führt in der absoluten Mehrzahl der Fälle zu Datenverlust. Einen der beiden Datensätze muss der Administrator üblicherweise nämlich komplett verwerfen. Das händische Zusammenfügen der Einträge ergibt nur in sehr wenigen Szenarien Sinn, zumal der Dienst in der Zeit, in der dieser Vorgang stattfindet, nicht produktiv zu nutzen ist.

Wie entstehen solche Situationen? Der neuralgische Punkt ist regelmäßig das Netzwerk. Klar: Wenn von den zwei Instanzen, die Daten synchronisieren und hochverfügbar halten, eine einfach ausfällt, kann auf diese kein schreibender Zugriff mehr stattfinden. Hier sind üblicherweise Clustermanager am Werk, die dafür sorgen, dass alle benötigten Dienste auf dem verbliebenen Knoten laufen und die zugreifenden Clients die angeforderten Daten auch tatsächlich bekommen. Ungleich schwieriger ist die Situation, wenn beide datenhaltenden Instanzen zwar noch laufen, ihre Netzwerkverbindung aber getrennt ist. Dann könnte die jeweils eine Instanz von der anderen glauben, diese sei ausgefallen, und selbst alle Dienste aktivieren. Das ermöglicht den berühmt wie berüchtigten unkoordinierten Zugriff durch verschiedene Clients auf beiden Seiten, der letztlich zum Split Brain und zum Datenverlust führt.

Quorum ist das Werkzeug, das dieses Szenario unterbindet. Damit ein Knoten, quasi die Partition eines Clusters – also eines verteilten Systems –, als quorumsfähig gilt, muss sie stets mehr als die Hälfte der ausschlaggebenden Knoten auf ihrer Seite wissen. Der Witness Node in VHCA macht aus dem eigentlichen Zwei-Knoten- einen Drei-Knoten-Cluster: Einer der beiden eigentlichen vCenter-Knoten zusammen mit der Witness Node haben stets die Mehrheit im System, bilden also ein Quorum – selbst dann, wenn einer der beiden Knoten zwar nicht ausfällt, die vCenter-Knoten ihre Verbindung zueinander aber verlieren. Im Fachjargon ist vom "Tiebreaker Node" die Rede, weil er das spezifische Quorumsproblem eines Zwei-Knoten-Clusters auflöst.

Voraussetzungen und erste Schritte

Die Voraussetzungen, die für einen vCenter-HA-Aufbau wie in Bild 2 zu sehen, erfüllt sein müssen, sind mithin schnell geklärt. Sie benötigen drei Serversysteme mit vergleichbaren Ressourcen, die Sie im nächsten Schritt dann als Cluster konfigurieren. Hinzu kommt, dass es für vCenter HA einer separaten Netzwerkverbindung zusätzlich zur ohnehin anliegenden bedarf, die der HA-Cluster später als Kommunikationswerkzeug nutzt. Es empfiehlt sich dringend, für diese Verbindung eine vom Rest der Umgebung separierte Infrastruktur zu nutzen. Keinesfalls sollte der Link also dieselben Switches verwenden. Denn fällt dieser aus, wäre nicht nur der Haupt-Kommunikationslink der Systeme betroffen, sondern der Backup-Link erneut gleich mit.

Bevor Sie mit vCenter HA loslegen, gilt es also, entsprechende Arbeitsschritte hinter sich zu bringen, die das HA-Szenario vorbereiten. Installieren Sie zunächst das vCenter, das als Keimzelle des Aufbaus fungiert, das also über die gewünschte Konfiguration verfügt. Es bekommt später gewissermaßen einen gleichwertigen Cluster-Partner zur Seite gestellt. Damit das funktioniert, ist aber auch das Netzwerk adäquat einzurichten.

Loggen Sie sich dazu auf dem laufenden primären vCenter ein und identifizieren Sie darin den ESXi-Host, auf dem das vCenter aktuell läuft. Fügen Sie diesem ESXi-System eine Portgruppe zu jener hinzu, die dort bereits aktiv ist. Diese kann zu einem existierenden virtuellen Switch gehören. Besser ist es wie beschrieben jedoch, hier auf komplett autarke Kommunikationspfade zurückzugreifen, die in vSphere entsprechend als eigener Pfad, also als eigener virtueller Switch, angelegt sind.

Wählen Sie im Anschluss die ESXi-Systeme aus, die als sekundärer und als Witness-Knoten fungieren sollen, und fügen Sie die Portgruppe dort ebenfalls hinzu. Verteilen Sie statische IP-Adressen an alle drei Systeme. Sie haben die Wahl zwischen einer IPv4- oder IPv6-Adresse, Umgebungen mit einem Mix aus IPv4 und IPv6 sind nicht möglich. Es gilt also das Prinzip "Entweder-oder". Stellen Sie zudem sicher, dass auf dem vCenter-Server der SSH-Zugang aktiviert ist.

Wichtig: vCenter HA funktioniert nur, wenn das vCenter, das hochverfügbar werden soll, die ESXi-Hosts selbst managt, auf denen es potenziell laufen kann. Die Rede ist dann von einem "self-managed vCenter". Wer mehrere vCenter-Instanzen betreibt, kann entsprechend nicht die ESXi-Hosts aus dem ersten Bereich für die Hochverfügbarkeit von Szenario zwei verwenden.

Ist das separate Netzwerk für die Cluster-Kommunikation eingerichtet, geht es mit dem Einstellen von vCenter für Hochverfügbarkeit weiter. Dazu sind weitere Arbeitsschritte im vCenter Client nötig, loggen Sie sich also nötigenfalls erneut in dieses ein. (ln)

Im dritten Teil zeigen wir, wie Sie vCenter richtig für HA konfigurieren und wie der Storage in hochverfügbaren Umgebungen aussehen sollte. Im ersten Teil haben wir uns angeschaut, welche Möglichkeiten es für HA in vSphere und vCenter überhaupt gibt und wie Sie mit "vSphere HA" für einen Basisschutz sorgen.

Über den Autor: Martin Loschwitz ist Gründer und Geschäftsführer der True West IT Services GmbH. Nebenberuflich schreibt er als freier Journalist zu Themen wie Cloud Computing, Virtualisierung und Container.