VMware Virtual SAN 6.6: Stretched Cluster und Fault Domains

Egal ob 2-Node-Mini-vSAN oder Two-Site-vSAN-Cluster, beide Konzepte arbeiten stets mit zwei aktiven Data-Sites und einer Witness-Site, die in beiden Fällen lediglich den Zeugen-Host enthält. Allerdings besteht jede einzelne Data-Site beim Stretched Cluster wiederum aus einem eigenen 2-Node-Cluster.

So lassen sich Daten und Applikationen nicht nur durch einen Failover zwischen zwei Standorten absichern, sondern zusätzlich auch lokal innerhalb eines Rechen­zentrums per RAID 1. Somit bleiben Informationen auch dann verfügbar, wenn ein komplettes Datacenter ausfällt.

Anwendungsfälle

Der zweite Standort dient im Stretched-Cluster-Konzept von VMware aber nicht nur dem Failover, sollte es zu technischen Ausfällen oder Naturkatastrophen kommen. Die Active/Active-Konfiguration sorgt in Zusammen­arbeit mit HA und DRS auch dafür, dass sich virtuelle Maschinen gleichzeitig auf beiden Seiten ausführen lassen, da vSAN auch mit FT kompatibel ist.

Wie bei einem Host-Cluster sorgt zudem HA auch im Storage-Cluster dafür, dass VMs auf einem anderen Host neu gestartet werden, wenn ein einzelner ESXi-Server ausfällt. Und nach wie vor kümmert sich DRS um die Lastverteilung im Cluster unter Zuhilfenahme von vMotion. Damit sind mehrere Szenarien für den Stretched Cluster denkbar:

• Planbare Wartungsfenster: Unter­nehmen könnten wechselseitig je eine komplette Site in Wartung nehmen, ohne dass es zu Ausfall­zeiten für Services kommt. Applikationen lassen sich nach Belieben und transparent für die Anwender von der einen zur anderen Site hin- und zurück­migrieren.
• Disaster-Vermeidung: Schutz von Applikationen vor Downtime durch Katastrophen. Das Stretched-Cluster-Konzept ermöglicht somit eine echte Vermeidung von Ausfallzeiten und nicht nur ein Desaster Recovery.
• Automatisierte Wiederherstellung: vSAN ist eng mit HA verzahnt, was sehr niedrige RTOs in DR-Szenarien erlaubt.

Technische Voraussetzungen

Es gibt allerdings einige Voraus­setzungen hinsichtlich der Bandbreite, die zwischen Data-Site/Data-Site bzw. Data-Site /Witness-Site garantiert sein muss. Erstere setzt mindestens eine 10Gb/s-Netzwerk­verbindung und eine minimale Roundtrip-Time von 5ms voraus. Ist Multicast-Support gewährleistet, darf die Verbindung inzwischen auch geroutet über eine Layer3-Strecke erfolgen.

Die Anbindung der Witness-Site konnte immer schon über eine geroutete Verbindung erfolgen, wobei eine maximale Roundtrip-Time von 200ms und eine Latenz von 100ms nicht überschritten werden dürfen. Die Netzwerk­bandbreite muss hier mindestens 100Mb/s betragen. Details dazu finden sich auf VMwares Storage Hub und in den vSAN Guidelines.

Fehlerdomänen

Im engen Zusammen­hang mit dem Entwurf eines Stretched Clusters steht das Konzept der vSAN Fault-Domains. Dieses minimiert Ausfall­zeiten der im vSAN gespeicherten virtuellen Maschinen, wenn zum Beispiel innerhalb eines vSAN-Clusters ein komplettes Rack ausfällt.

Daher verteilt man idealer­weise alle Hosts, die zu einem vSAN-Cluster beitragen, über mehrere Racks und konfiguriert dann eine Fehler­domäne für jedes Rack. vSAN sorgt dann dafür, dass beispielsweise sämtliche Replikate einer VM (normalerweise arbeitet ein vSAN-Cluster im RAID 1) stets in getrennten Fehlerdomänen platziert werden. Dies erhöht die Verfügbarkeit von Komponenten im Falle eines Rack-Fehlers.

Das Einrichten von Fehler­domänen und das Gruppieren der verfügbaren Hosts zu bestehenden Fault-Domains gelingt wie fast alles bei vSAN intuitiv und selbsterklärend.

Stretched Cluster einrichten

Das Konfigurieren eines ausgeweiteten vSAN-Clusters funktioniert vom Ablauf her nicht viel anders als das Einrichten eines 2-Node-Clusters. Auch hier benötigen Sie den virtuellen Witness-Host, die vSAN-Kernel-Adapter sowie eine gerade Anzahl von physischen Nodes für jede Site.

Das Deployment und die Konfiguration der Witness-Appliance sowie das Hinzufügen des Zeugen als Host funktioniert so, wie im Artikel zum 2-Node-Cluster gezeigt (siehe VMware Virtual SAN 6.6: 2-Node-Cluster einrichten, Witness konfigurieren).

Danach konfigurieren bzw. kontrollieren Sie das vSAN-Netzwerk für die Witness-Appliance. Im abgebildeten Beispiel liegt sie in einem komplett anderen Layer-3-Netz 11.11.11.0/24.

Da der Witness-Host jetzt in einem anderem Layer-3 liegt, müssen wir auf ihm eine statische Route ergänzen, die dem Witness-Host Zugriff auf das vSAN-Netzwerk der Data-Site ermöglicht. Das geschieht am einfachsten via SSH auf der Kommando­zeile. So zeigt zunächst

esxcli network ip route ipv4 list

die vorhandenen Routen an. Das Hinzufügen einer neuen statischen Route erfolgt dann mit

esxcli network ip route ipv4 add --gateway <Gateway> --network <Netzwerk-Adresse>

Das Ergebnis sollte dann so aussehen:

Das Gleiche wiederholen Sie dann auch für die 2x2 physischen ESXi-Hosts.

Damit sind die Vorbereitungen getroffen, um den ausgeweiteten Cluster zu aktvieren. Legen Sie das benötigte Cluster-Objekt an, ohne vSAN zu aktiveren und platzieren anschließend 2 x 2 ESXi-Hosts (je zwei von jeder Site) im Cluster.

Anschließend aktivieren Sie in den Cluster-Einstellungen das vSAN-Feature und wählen im ersten Schritt des Assistenten Ausgeweiteten Cluster konfigurieren aus.

Nach der Auswahl des vSAN-Kernel-Adapters landen Sie im wichtigen Schritt 3 Fehlerdomänen erstellen. Übernehmen Sie hier jeweils die zwei Hosts der einen Seite in die Bevorzugte Domäne und die beiden anderen in die Sekundäre Domäne.

Im Schritt 4 des Konfigurations­assistenten wählen Sie dann erneut die Witness-Appliance als Zeuge aus (wie im Beitrag über 2-Knoten-Cluster beschrieben) und schließen dann die Konfiguration des Ausgeweiteten Clusters ab.

Sie können die erfolgreiche Konfiguration dann unter <Cluster> => Verwalten => Fehlerdomänen & Ausgeweiteten Cluster überprüfen.