VMware Virtual SAN 6.6: 2-Node-Cluster einrichten, Witness konfigurieren

Um diesen nicht über einen physischen ESXi-Host als Teil des vSAN-Clusters bereitstellen zu müssen, bietet VMware eine virtuelle Witness-Appliance zum Download an (hinter dem Reiter Drivers & Tools im Abschnitt VMware vSAN Tools, Plug-ins and Appliances).

Dabei handelt es sich um einen verschachtelten ESXi-Host. Eine separate Lizenz ist dafür nicht erforderlich. Die Witness-Appliance von VMware ist aber kein gewöhnlicher Nested ESXi-Host. Sie ist nämlich nicht dafür vorgesehen, VMs auszuführen und besitzt kein HA, DRS oder verwandte Funktionen. Sie fungiert einfach nur als vSAN-Zeuge und hat sonst keine andere Aufgabe.

Deployment-Optionen für den Zeugen

Sie sollten aber in Ihrer Planung bedenken, dass Sie diese Virtual Appliance nicht auf einem Host bereit­stellen können, der bereits Teil des geplanten vSAN-Clusters ist. Sie müssen vielmehr den Witness immer an einer dritten Site ausführen.

Dies kann ein anderer Host in Ihrer aktuellen vCenter-Umgebung (L2), ein ESXi-Host einer weiteren Site (L3) - dies erforderte bis vSAN 6.5 einen externen 10GB-Switch - oder die Cloud (L3) in Form von vCloudAir sein.

Das Vorgehen ist aber grundsätzlich immer gleich. Der virtuelle ESXi-Host muss nach dem OVA-Import und seiner Konfiguration in vCenter aufgenommen werden. Dann legt man den Cluster mit 2 physischen Hosts an und wählt die vSAN-Option 2-Knoten-Cluster. Schließlich gibt man im vSAN-Deploy-Assistenten das Witness-Appliance an, sobald er danach fragt.

Appliance importieren

Achtung bei den Netzwerk­einstellungen im Verlauf des OVA-Deployments: Die Appliance ist mit einem Management-Adapter und einem Kernel-Adapter für das vSAN-Netzwerk namens witnessPG vorkon­figuriert.

Sie können daher die Appliance mit den vom Assistenten vorgeschlagenen Netzwerken zwar ausrollen. Aber anschließend müssen Sie ggf. das Management-Netzwerk des verschachtelten ESXi-Hosts sowie seinen Kernel-Adapter für vSAN an die Adress­einstellungen anpassen, die Sie in Ihrer äußeren ESXi-Umgebung verwenden.

Witness-Appliance anpassen

Nach dem Import starten Sie die Appliance und passen zunächst an der Konsole (DCUI) des Nested ESXi das Management-Netzwerk so an, dass Daten-Site und Witness-Site miteinander kommu­nizieren können.

Ist das geschehen, folgt der eigentliche Clou des Virtual-Witness-Deployments: Fügen Sie nun die Appliance-VM Ihrem Datacenter als Host hinzu, wobei spätestens jetzt die Management-IP der Appliance mit dem Netzwerk­einstellungen der unterliegenden physischen ESXi-Umgebung korres­pondieren muss. Die Appliance bringt eine eigene Lizenz mit, die lediglich im Verlauf des Add-Host-Assistenten eingegbene werden muss.

Dass es sich tatsächlich um die spezielle Witness-Appliance von VMware handelt, erkennen Sie nach dem Hinzufügen sofort im Tab Erste Schritte.

Danach müssen Sie nur noch das vSAN-Netzwerk für den Witness-Node konfigurieren, also überprüfen bzw. dafür sorgen, dass der VMKernel-Adapter vmk1 existiert und für vSAN konfiguriert ist. Das sollte aber durch die im OVA vorkonfigurierte Portgruppe witnessPG der Fall sein.

Denken Sie daran, dass der Witness-Host in der Lage sein muss, mit dem vSAN-Netzwerk zu kommunizieren. Nötigenfalls ergänzen Sie je nach Design Ihrer Data-Site die passende VLAN-ID für den witnessSwitch oder die witnessPg portgroup.

Implikationen verschachtelter Virtualisierung

Wie erwähnt, handelt es sich bei der Virtual Witness Appliance um einen verschachtelten ESXi-Host. Würden Sie auf diesem VMs ausführen und müssten diese mit VMs der äußeren Umgebung kommunizieren, dann wäre Folgendes zu beachten: Der Virtual Standard Switch, als auch der VDS (vSphere Distributed Switch) lernen keine MAC-Adressen, wie es ein herkömmlicher physischer Switch tut, weil ESXi ja bereits "weiß" (aus den vmx-Dateien), welche MAC-Adressen einer bestimmten virtuellen Maschine zugeordnet sind.

Dies bedeutet, dass der virtuelle Switch nur Netzwerkpakete an eine virtuelle Maschine weiterleitet, wenn die Ziel-MAC-Adresse mit der MAC-Adresse des ESXi vmnic übereinstimmt. In einer verschachtelten ESXi-Umgebung unterscheidet sich aber die Ziel-MAC-Adresse für Netzwerk­pakete, die für äußere virtuellen Maschinen bestimmt sind, von der MAC-Adresse des vmnic des Nested ESXi.

Der virtuelle Switch des physischen ESXi-Hosts wird daher das Paket fallen lassen, wenn nicht der Promiscuous Mode für den Switch oder für die Port-Gruppe, an der der genesteten ESXi-Host hängt, aktiviert ist. In diesem Modus kann der vmnic der Nested-ESXi-VM den gesamten Datenverkehr des virtuellen Switches überwachen, mit dem er verbunden ist.

Allerdings handelt es sich bei der Witness-Appliance um einen Spezialfall, da diese ja keine VMs hostet. Es muss nur sichergestellt sein, dass der ESXi-Host der Witness-Site sowohl das Management-Netzwerk als auch das VSA-Netzwerk der Data-Site erreichen kann.

Und genau darin besteht auch der Hauptzweck, das Netzwerk im OVA mit einer Portgruppe vorzu­konfigurieren, nämlich u. a. damit die MAC-Adressen der VM-NICs mit der vmnic-MAC-Adresse des verschachtelten ESXi-Hosts überein­stimmen. Ist das der Fall (innen wie außen sozusagen), übergibt der vSwitch den Traffic an den verschachtelten Witness-ESXi.

2-Node-Cluster einschalten

Jetzt existiert der virtuelle ESXi-Host zwar in vCenter, muss aber im Verlauf des vSAN-Deployments noch dem zu erstellenden vSAN-Cluster hinzugefügt werden. Der einzige Unterschied zu einem normalen vSAN-Deployment besteht dabei darin, dass Sie im ersten Schritt des vSAN-Cluster-Assistenten im Bereich Fehlerdomänen und Ausgeweiteten Cluster die Option Virtual SAN-Cluster mit zwei Hosts konfigurieren wählen müssen.

Der Wizard passt dadurch den vom 3-Node-Cluster bekannten Ablauf des Setups geringfügig an. So wählen Sie auch hier zunächst die vSAN-Kernel-Adapter und dann das Disk-Claiming im Schritt 3 aus. Dann aber im zusätzlichen Schritt 4 müssen Sie den Zeugenhost (Witness)  auswählen.

Anschließend rüsten Sie diesen in Schritt 5 ebenfalls mit einer Disk-Gruppe aus, wofür je eine emulierte SSD und eine HDD zur Verfügung stehen. Einen SSD-Datastore braucht der ESX-Host nicht.

Nach dem Prüfen der Zusammenfassung kann der 2-Node-Cluster mit Finish erstellt werden.