[DE] Nutanix Metro Availability auf VMware vSphere


Dieser Beitrag beschreibt das Feature „Metro Availability“, also wie ein raumübergreifendes Cluster Design auf Basis der Nutanix Plattform zusammen mit VMware vSphere aussieht und wie einfach dies zu konfigurieren ist.

Da in einer Hyper-Converged Lösung der Hypervisor und Storage in einem Server vereint werden, muss für ein besseres Verständnis geklärt sein, dass hier trotz dieser Konvergenz zwei Ebenen separat voneinander betrachtet werden müssen:

  • Hypervisor Ebene: Hier beziehe ich mich tatsächlich rein auf den Hypervisor, im Folgenden einfach Hosts genannt, also wie die einzelnen Hosts z.B. in Form eines vSphere Clusters konfiguriert werden.
  • Storage Ebene: Hier wiederum beziehe ich mich auf die Nutanix Plattform, welche alle nötigten Storage-Funktionalitäten der Lösung zur Verfügung stellt. Gebildet wird dies durch das Zusammenspiel mehrere physischer Server, im Folgenden als Nodes bezeichnet.

Die Nutanix Metro Availability Implementierung sieht vor, dass in beiden Seiten jeweils ein eigenständiges Nutanix Cluster betrieben wird. Das ist wie gesagt jedoch zunächst unabhängig davon zu sehen, wie letztlich die einzelnen Hosts zusammenspielen. Ein Nutanix Cluster besteht dabei aus mindesten drei Nodes, die gemeinsam die bei Nutanix so genannte Distributed Storage Fabric kurz DSF bilden. Dabei werden alle physikalischen Ressourcen aller beteiligten Nodes in einem Storage Pool zusammengefasst. Aus diesem Pool werden wiederum so genannte Container erstellt, welche dann den Hosts in Form von NFS Datastores präsentiert werden.

Auf Ebene der Container werden letztlich Einstellungen wie beispielsweise des Replication Factor (RF), also das Level an Fehlertoleranz des Nutanix Clusters, oder aber auch ob die Capacity Optimization Engine (COE) Technologien wie Compression, De-Dupe oder Erasure Coding auf die darin gespeicherten Objekte anwenden soll.

Das heißt zusammengefasst, dass in jeder der beiden Seiten je ein Nutanix Cluster bestehend aus mindesten drei Nodes betrieben werden muss.

Tipp: Für kleinere Umgebungen ist es auch möglich zwei herkömmliche Nodes mit einem „Storage Only“ Node pro Seite zu kombinieren, um so die minimale Konfiguration von drei Nodes zu erreichen. Der Storage Only Node tritt dann nur in der Storage Ebene in Erscheinung und auf Hypervisor Ebene laufen dann tatsächlich nur zwei Hosts pro Seite.

Aber wie werden jetzt aus zwei Nutanix Clustern, die in sich bereits redundant und voll Funktionsfähig sind, eine Metro Lösung?

 

Nutanix / Storage Ebene

Aus zwei Nutanix Clustern wird eine Metro Lösung, wenn man folgende Schritte durchführt:

  1. Die beiden Cluster gegenseitig bekannt machen, dazu wird in beiden Clustern das jeweils andere Cluster als Remote Site eingerichtet.
  2. Die Container erstellen, welche synchron gespiegelt werden sollen.
  3. Danach kann man eine Protection Domain (PD) für die Metro Availability einrichten, welche primär definiert, welche Container synchron gespiegelt werden sollen.

 

Prism Element >> Data Protection >> + Remote Site >> Physical Cluster

Über das Hinzufügen der jeweils anderen Remote Site, werden die beiden Cluster bidirektional miteinander verbunden. Als IP Adresse wird jeweils die „Cluster Virtual IP Address“ sowie Name der jeweils anderen Seite verwendet.

Im zweiten Schritt können weitere Eigenschaften der Cluster zu Cluster Kommunikation definiert werden. Dabei gilt zu beachten:

  • Compression on Wire sollte deaktiviert sein.
  • Das VStore Name Mapping wird nicht benötigt, dieses kommt nur bei der asynchronen Spiegelung zum Einsatz.

Danach sollte die jeweils andere Remote Site beziehungsweise das jeweils andere Nutanix Cluster in der Liste der Remote Sites auftauchen.

Im nächsten Schritt werden die synchron zu spiegelnden Container erstellt. Dabei ist es möglich, gleichzeitig synchron gespiegelte, asynchron oder auch nicht gespiegelte Container zu verwenden, die Entscheidung in welchem Container eine Applikation betrieben werden soll, hängt letztlich von deren Anforderungen hinsichtlich SLAS/RPO/RTO ab.

 

Prism Element >> Storage >> Tab Container >> + Container

Die Metro Implementierung empfiehlt mindestens zwei Container pro Seite, um eine parallele Nutzung beider Cluster zu ermöglichen. Dabei läuft Container 1 aktiv in Seite 1 und ist gleichzeitig passiv in Seite 2, während Container 2 in Seite 2 aktiv ist und dafür passiv in Seite 1. Wichtig dabei ist, dass die Container auf beiden Seiten identisch benannt sein müssen, denn der Name des Containers entspricht 1:1 den Namen des an die Hosts präsentierten Datastores und diese müssen unbedingt an allen Hosts identisch sein.

Für diesen Post gehe ich nicht weiter auf die COE ein und lasse alle Features deaktiviert. Nach der Erstellung der Container werden diese automatisch an alle Hosts des jeweils lokalen Cluster gemountet.

Jetzt muss beiden Clustern noch beigebracht werden, welcher Container von Seite 1 auf welchen Container in Seite 2 gespiegelt wird und wie sich die Cluster verhalten soll, wenn die Kommunikation unterbrochen wird.

 

Prism Element >> Data Protection >> + Protection Domain >> Metro Availability

An dieser Stelle noch eine kurze Erklärung zu den Failure Handling Optionen:

  • Witness: Eingeführt mit AOS 5.0, ermöglicht durch eine weitere Nutanix Instanz in Form einer virtuelle Appliancen in einer unabhänigen dritten Seite, die Failover Entscheidung zu automatisieren.
  • Automatic Resume: Standardmäßig wird nach 30 Sekunden unterbrocher Kommunkation zwischen beiden Clustern die Replizierung gestoppt, sodass die VMs lokal weiter laufen können, ohne das es zu einem permantenen Stopp des I/O Flusses kommt. Erfordert jedoch ein manuelles eingreifen wenn eine Seite ausfällt, um die Container in der verbleibenden Seite zu aktivieren.
  • Manual: Keinerlei Automatisierung. Die Replizierung muss zugunsten des I/O Flusses manuell gestoppt, beziehungsweise die Container in der verbleibenden Seite aktiv geschaltet werden.

Hinweis: Der dargestellte Schedule mit 7 täglichen Snapshots ist exemplarisch und optional. Standardmäßig wird alle 4 Stunden ein Snapshot erstellt und bis zum nächsten Snapshot aufbewahrt. Dies dient dazu, das wenn die Daten re-synchronisiert werden, nur die Differenz zum letzten Snapshot übertragen werden muss. Daher übernimmt der Schedule auch automatisch die angegebene Anzahl der Snapshots für die Remote Seite, +1 für den Snapshot der grundsätzlich immer erstellt wird. In diesem Beispiel also 8.

Die Einrichtung erfolgt dabei Bi-Direktional, sprich die Einrichtung für den Container VMW-Metro01 erfolgt in der Prism Element UI von Cluster 1 („VMW01“) Richtung Cluster 2 („VMW02“) und entsprechend umgekehrt, sodass dies am Ende wie folgt aussehen sollte. Dabei können natürlich mehrere Container pro Seite erstellt werden.

Damit existiert jetzt in jeder Seite ein aktiver Container, auf dem die virtuellen Maschinen entsprechend aktiv zugreifen und ein passiver Container, welcher den Datenstrom des aktiven Containers der anderen Seite entgegennimmt.

Danach bietet die UI grundsätzlich zwei Optionen an:

  • Disable / Re-Enable: De- oder reaktiviert die Protection Domain und damit die synchrone Replizierung.
  • Promote (nur auf der Standby PD): Schaltet eine standby (passive) Protection Domain aktiv, sodass diese auf dem aktivierten Cluster entsprechend I/Os entgehen nehmen kann.
  • Take Snapshot: Erstellt einen Snapshot des gesamten Containers und damit auch aller darin gespeicherten Objekte.

 

Hypervisors Ebene

Cluster & Datastores

Alle Hosts werden dann in ein gemeinsames strechted Cluster konfiguriert, in dem dann entsprechend auch VMware HA, DRS, etc. genutzt werden kann.

Aus der Sicht des Hypervisors sehen alle Hosts jetzt zwei Datastores. “VMW-Metro01” und “VM-Metro02”. Obwohl diese ihren Ursprung in unterschiedlichen Nutanix Clustern haben, sieht es auf Grund des gleichen Namens, für alle Hosts wie zwei herkömmliche shared Datastores aus. So lassen sich auch VMs per vMotion problemlos zwischen den beiden Seiten hin und her bewegen. Jedoch gibt es dann zu beachten, dass der I/O Traffic dann gegebenenfalls auf den passiven Container trifft und dieser erst zum aktiven Container weitergeleitet werden muss, was zu einer Erhöhung der Latenzen beiträgt.

DRS Regeln

Es sollte generell sichergestellt werden, dass alle VMs die aktiv in Seite 1 laufen, auch auf einem Datastore (Container) liegen, der auf dem Cluster 1 beziehungsweise in Seite 1aktiv ist. Umgekehrt gilt dies natürlich auch für alle VMs in Seite 2, die über Cluster 2 zugreifen sollen. So lassen sich die VMs einfach gesagt 50/50 auf die beiden Seiten verteilen. Dazu braucht es je zwei DRS Host- und VM-Gruppen.

Die VM-Gruppen werden dann über DRS Affinity “Should” Rules, zu deutsch “Sollte”-Regeln, den passenden Host-Gruppen zugewiesen werden.

Das Ergebnis sollte wie folgt aussehen.

 

Failover Szenarien

Annahme: Seite1 und Seite 2 betreiben beide aktiv VMs, sprich jede Seite verfügt über aktive und passive Protection Domains.

Szenario Witness Automatic Resume Manual
Ausfall von Seite 1 oder kompletter Netzwerkausfall in Seite 1 Metro Availability wird gestoppt.

Automatischer Failover zu Seite 2.

VMs in Seite 2 laufen weiter.

 

Metro Availability wird gestoppt.

Admin muss PDs in Seite 2 aktivieren und VMs manuell starten.

VMs in Seite 2 laufen weiter.

Admin muss passive PDs in Seite 2 aktivieren und VMs manuell starten.

VMs in Seite 2 laufen weiter.

Ausfall von Seite 2 oder kompletter Netzwerkausfall in Seite 2 Metro Availability wird gestoppt.

Automatischer Failover zu Seite 1.

VMs in Seite 1 laufen weiter.

Admin muss PDs in Seite 1 aktivieren und VMs manuell starten.

VMs in Seite 1 laufen weiter.

Admin muss passive PDs in Seite 2 aktivieren und VMs manuell starten.

VMs in Seite 1 laufen weiter.

Split-Brain – Netzwerkausfall zwischen Seite 1 und 2 Metro Availability wird gestoppt.

VMs laufen in ihrer ursprünglichen Seite weiter.

Metro Availability wird gestoppt.

I/O läuft nach Timeout (Default 30 Sek.) weiter.

VMs laufen in ihrer ursprünglichen Seite weiter.

I/O Pausiert bis Admin eingreift.
Witness Ausfall Keine Auswirkungen. Trifft nicht zu. Trifft nicht zu.
Netzwerkausfall zwischen Seite 1 und Witness VMs laufen in ihrer ursprünglichen Seite weiter. Trifft nicht zu. Trifft nicht zu.
Netzwerkausfall zwischen Seite 2 und Witness VMs laufen in ihrer ursprünglichen Seite weiter. Trifft nicht zu. Trifft nicht zu.
Netzwerkausfall zwischen Seite 1 und Witness sowie Seite 2 und Witness VMs laufen in ihrer ursprünglichen Seite weiter. Trifft nicht zu. Trifft nicht zu.
Ausfall Seite 1 und Seite 2 Metro Availability wird gestoppt.

Admin Eingriff notwendig.

Metro Availability wird gestoppt.

Admin Eingriff notwendig.

Metro Availability wird gestoppt.

Admin Eingriff notwendig.

Split-Brain – Netzwerkausfall zwischen Seite 1 und Seite 2 sowie zwischen Seite 1 und Witness I/O in Seite 1 pausiert.

Parallel Failover zu Seite 2. VMs werden durch HA dort neugestartet.

Alle VMs in Seite 1 müssen heruntergefahren werden.

Trifft nicht zu. Trifft nicht zu.

 

 

Einrichtung der Witness Appliance

Dieser Prozess ist denkbar einfach:

  • Download der Appliance für den Ziel Hypervisor (AHV/Hyper-V/ESXi) aus dem Download Portal. Z.B. im Fall von ESXi, Deployment via OVF.
  • Booten der VM und öffnen der Konsole
  • Login: nutanix & nutanix/4u
  • Ausführen der folgenden Schritte
    • $ sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
      • NETMASK=xxx.xxx.xxx.xxx
      • IPADDR=xxx.xxx.xxx.xxx
      • BOOTPROTO=”none”
      • GATEWAY=xxx.xxx.xxx.xxx
    • cluster -s <Witness VM IP> –cluster_function_list=witness_vm create
    • Optional kann ein extra User angelegt werden: nuclei
  • Registrierung der Witness Appliance in beiden Nutanix Clustern (Login: admin & nutanix/4u)

Wichtige Punkte bei der Verwendung der Witness Appliance:

  • Die Verbindungen der beiden Seiten zum dritten Standort sollten unabhängig von der Verbindung zwischen den beiden Clustern sein.
  • Latenz für Witness Anbindung < 200ms RTT
  • Latenz für Cluster zu Cluster Kommunikation < 5ms RTT
  • Witness VM muss nicht auf Nutanix Hardware laufen
  • Unterstützt bis zu 50 Protection Domains pro Witness
  • vHardware Anforderungen:
    • 2 vCPUs
    • 4 GB RAM
    • 25 GB Storage

Tipp: Die Witness Appliance bietet ein via Browser erreichbares Dashbaord, um den Status der einzelnen Protection Domains / Container zu prüfen.

Print Friendly

Related Post

It's only fair to share...Tweet about this on TwitterShare on LinkedInEmail this to someone

Leave a comment

Your email address will not be published. Required fields are marked *