Bei der vSAN Witness Appliance handelt es sich um einen Nested ESXi, der als Tie Breaker für vSAN-Cluster mit 2 Knoten bzw. für vSAN Stretched Cluster dient. Die folgenden Ausführungen erläutern, inwiefern die Appliance Teil des Clusters ist und in welcher Version und auf welchen Hosts sie ausgeführt werden sollte.
Die vSAN Witness Appliance beseitigt die Notwendigkeit für die Bereitstellung eines dritten physischen vSAN-Knotens in einem Single-Site-Cluster. Damit ist sie also eher für kleine Unternehmen gedacht, für die ein vSAN einen nicht unerheblichen Kostenfaktor darstellt. Daneben ist ein dritter, rein virtueller vSAN-Knoten mit reduzierten Latenzanforderungen für den Witness-Traffic eine Voraussetzung für den Aufbau eines Stretched Clusters.
vSAN Witness – Begrifflichkeiten
Beim Konzept des vSAN Witness ist es wichtig, sich über die Bedeutung der einzelnen Witness-Komponenten absolut im Klaren zu sein. Die bisher ausschließlich erwähnte Witness Appliance ist eine kostenlose VM, in dem ein ESXi läuft. Ebenso zulässig wäre aber ein physischer ESXi-Host ohne Datastores und mit nur einem vSAN-Kernel-Adapter. Beide müssen manuell dem vCenter bzw. Datacenter hinzugefügt werden. Der virtuelle oder physische Witness-Host wird nur zum Speichern von Unterbrechungsmetadaten für Verbindungen (Tie Breaker Meta Data) in einer Stretched-Cluster- oder 2-Node-vSAN-Konfiguration benötigt.
Die vSAN Witness-Komponente hingegen speichert die Unterbrechungsmetadaten von Verbindungen für vSAN-Datenkomponenten, die sich auf verschiedenen Fehlerdomänen oder -Hosts befinden. Beim Bereitstellen, Konfigurieren oder Verwalten eines Stretched Clusters bzw. eines 2-Node-vSAN ist es wichtig, diese Unterschiede zu kennen.
Cluster-Mitgliedschaft
Ein Witness-Host ist sowohl für Stretched vSAN-Cluster als auch für 2-Knoten-vSAN erforderlich und nimmt damit quasi am vSAN-Cluster teil. Die Formulierung ist allerdings mit Vorsicht zu genießen, weil der Witness-Host kein Mitglied des Host-Clusters, sondern lediglich des vSAN-Clusters ist, was auch an der Objekthierarchie im vSphere Client leicht zu erkennen ist.
Die allgemeine Empfehlung von VMware besteht darin, den vSAN-Witness-Host in einem separaten Datencenter zu platzieren, etwa einem, das man extra dafür anlegt. Dabei möchte ich noch mal betonen, dass der vSAN-Witness-Host kein Mitglied des vSphere-Host-Clusters sein darf.
In der Datenträgerverwaltung der vSAN-Konfiguration ist die Disk Group des vSAN-Witness-Host allerdings ein „beitragendes“ Mitglied des vSAN-Clusters.
Dazu noch eine sehr wichtige Warnung: Es ist nicht möglich, einen Cluster aus mehreren vSAN-Witness-Hosts zu erstellen, denn diese können per Definition keine Mitglieder eines vSphere-Clusters sein. Für ein besseres Organisieren von Witness-Hosts lässt sich stattdessen der Folder Host- und-Cluster gut nutzen.
Versionen
Wichtig ist außerdem, dass für einen 2-Knoten-Cluster beide Daten-Nodes die gleiche Build-Version haben sollten.
Obwohl der vSAN-Witness-Host nicht Teil des vSphere-Clusters ist, trägt er Festplatten zum vSAN-Cluster bei. Daher sollte auch er dasselbe Build aufweisen wie die vSAN-Daten-Knoten. Auf jeden Fall aber sollte es sich aber um die dieselbe Version von vSAN handeln.
Dabei ist zu bedenken, dass der vSAN-Zeugenhost eine ganz normale ESXi-Instanz ist, egal ob physisch oder virtuell. Er kann bzw. muss daher genau wie jeder andere ESXi-Host gepatcht werden, typischerweise via VUM.