Nutanix Disaster Recovery – Konfiguration (Teil 2)


Im ersten Teil haben wir uns den logischen Aufbau eines Disaster-Recovery-Szenarios angeschaut, heute beleuchten wir dessen Konfiguration im PRISM Webinterface.

Benötigt werden zwei eigenständige Nutanix Cluster, der verwendete Hypervisor entscheidet dabei über den möglichen Funktionsumfang der Disaster-Recovery-Möglichkeiten.
Kommt auf beiden Clustern ein identischer Hypervisor zum Einsatz, ist eine Failover-Möglichkeit immer gegeben.

Zusätzlich bietet ein Konstrukt aus AHV und ESXi ebenfalls einen nahtlosen Failover ohne Konvertierung der VMs an.
Ein Hyper-V Cluster kann hingegen nur als Backup Target für Snapshots dienen, welche anschließend auf einen AHV oder ESXi Cluster wiederhergestellt werden können.


Bei der Verwendung von Hyper-V in einem Mischbetrieb können alle anderen Lösungen lediglich als Backup only Target verwendet werden.

Die Konfiguration in der PRISM-Oberfläche ist bei allen drei Virtualisierungslösungen nahezu identisch und wird daher in diesem Beispiel hypervisor-unabhängig dargestellt.

 

1. Schritt: Cluster verknüpfen

Im ersten Schritt müssen sich beide Cluster bekannt machen, um zukünftige Replikationen zu ermöglichen. Dazu wechseln wir auf der Startseite in die Kategorie Data Protection, wo auch alle weiteren in diesem Guide erwähnten Schritte ausgeführt werden.


In diesem Reiter springen wir auf das Untermenü Table -> Remote Site, welches einen Überblick über bereits konfigurierte Clusterverbindungen anzeigt.
Über den Button + Remote Site -> Physical Cluster kann eine neue Verbindung aufgebaut werden.


Anschließend muss für die Remote Site ein Name und deren Cluster IP angegeben werden.
In unserem Beispiel verwenden wir eine Hypervisor-Konstellation mit Failover-Möglichkeit und wählen daher Disaster Recovery anstelle von Backup aus.


Auf der nächsten Seite können noch diverse Optionen gesetzt werden:


Bandwidth Throttling

Dies dient zur Begrenzung der Bandbreite, um LAN/WAN-Strecken nicht zu 100 % durch die Replikation auszulasten.
Es können zusätzlich Policies erstellt werden, welche die Bandbreite abhängig von Tag und Uhrzeit begrenzen um z. B. die Bandbreite nur tagsüber oder während eines Backupfensters zu begrenzen.

Compression on wire
Dies bietet sich besonders bei niedrigen Bandbreiten von WAN-Verbindungen an – Daten werden auf Kosten von mehr CPU Overhead vor der Übertragung komprimiert und können so deutlich schneller übertragen werden.

Network Mapping
Meist sind beide Standorte nicht mit einem Layer2-Netzwerk verbunden, wodurch nach der Umschaltung andere VLANs/Portgruppen an die VMs gemappt werden müssen.
Nutanix bietet eine einfache Boardfunktion, um genau dies durchzuführen. Diese Option hat keine Auswirkung auf die IP-Konfiguration innerhalb der VM.

vStore Name Mapping
Replizierte Objekte müssen einem Storage Container zugewiesen werden. Wird diese Option leer gelassen, muss auf der Gegenseite ein Storage Container mit identischem Namen existieren oder die Replikation schlägt fehl.
Ist dies nicht gewünscht bzw. haben beide Seiten ein einzigartiges Namensschema, können über diese Option die beiden Container verknüpft werden.

 

Achtung: Als nächstes muss der identische Prozess auf der sekundären Seite durchgeführt werden und entsprechend die IP-Adresse des primären Clusters als Ziel angegeben werden.

Eine Connection muss immer auf beiden Seiten erstellt werden. Dies dient auch als Authentifizierungsbestätigung, es sind sonst keine zusätzlichen Login-Daten nötig.

 

2. Schritt: Protection Domain anlegen

Sobald beide Seiten erfolgreich hinzugefügt wurden und sich erreichen, können wir nun die Replikation der einzelnen Objekte erstellen.
Die asynchrone Replizierung erfolgt direkt auf Ebene der VM-Objekte und kann so sehr granular eingerichtet werden.

Dazu wechseln wir in den Reiter Async DR und klicken auf den Button + Protection Domain -> Async DR.


Im nächsten Schritt muss zuerst ein Name für die Protection Domain vergeben werden.
Die Protection Domain bezeichnet dabei eine Gruppierung von VM-Objekten, welche anschließend im gleichen Job repliziert werden können.

Wie in Teil 1 bereits aufgezeigt, ist es somit möglich, einzelne Workloads oder Servergruppen in eine dedizierte Gruppe zu verpacken Dabei gilt aber immer die Empfehlung, es so einfach wie möglich zu definieren und lieber einen Kompromiss zu Gunsten des Verwaltungsaufwand zu finden.


Anschließend können diesem Job einzelne Objekte hinzugefügt werden. Dazu können diese über die Filter by-Funktion entsprechend einfacher gefunden werden.


Sind die gewünschten VMs mit einem Häkchen versehen, muss noch eine Consistency Group gewählt werden.
Dabei handelt es sich um eine Gruppierung von Objekten, von welchen der Snapshot zur exakt gleichen Zeit erfolgen soll, um mögliche zusammenhängende Applikationen wie Frontend und Datenbanken in einem konsistenten gleichen Datenbestand einzufrieren.

Use Entity Name
Hierbei handelt es sich um das Default Setting, wenn keine Anforderungen an das oben genannte Thema besteht. Es wird für jede VM eine separate CG erstellt, welche den VM-Namen trägt.

Use an existing CG
VMs können bereits erstellten CGs hinzugefügt werden.

Create a new CG
Alle markierten Objekte werden einer neuer CG hinzugefügt, der Name muss eingegeben werden.

Use Application Consistent Snapshots
Unabhängig davon, ob ein Objekt in einer separaten oder mit andern VMs zusammen in einer Gruppe ist, können applikations-konsistente Snapshots erstellt werden.
Dazu ist es nötig, die Nutanix Guest Tools (NGT) vorher in den ausgewählten VMs zu installieren.

Auto Protect Related Entities
Werden inGuest iSCSI Volumes über die Acropolis Block Services (ABS) verwendet, werden diese Volumes über diese Option automatisch mit gesichert.

Über einen Klick auf Protect Selected Entities werden die Objekte der Liste auf der rechten Seite hinzugefügt und somit in die Async DR Gruppe aufgenommen.


Auf der nächsten und letzten Seite wird dem Job noch ein oder mehrere Scheduler hinzugefügt über den Knopf New Schedule.


Auf der linken Hälfte wird die Zeit und Häufigkeit der Replikation ausgewählt, die rechte Hälfte bildet das Snapshotziel ab.
Dabei muss immer mindestens ein Snapshot lokal vorgehalten werden, nach oben hin sind ausschließlich Limits durch die maximale Cluster-Kapazität gesetzt. Unterschiedliche Snapshot-Hierarchien bzw. -Mengen pro Seite sind dabei ein fester Bestandteil der Nutanix-Software.

Über Create Schedule wird der entsprechende Datensatz übernommen. Es können pro Job mehrere Scheduler erstellt werden, um beispielweise stündliche, tägliche und wöchentliche Snapshots zu kombinieren.


Sobald der Scheduler bestätigt wurde über einen Klick auf Close, startet die erste initiale Übertragung. Falls ein Scheduler erstellt wurde, der nur an bestimmten Tagen durchgeführt wird, kann diese Übertragung verzögert starten.
Der aktuelle Prozess ist nach einem Klick auf die Protection Domain unter Replications -> Total Ongoing zu sehen.


Direkt nach dem Starten der Replikation ist der lokale Snapshot auf dem aktuellen Cluster im Reiter Local Snapshots verfügbar. Sobald die Replikation abgeschlossen wurde, taucht dieser auch als direkte Kopie unter Remote Snapshots auf.

Auf unserer zweiten Seite wurde nun automatisch die identische Async DR Gruppe im Read Only Modus erstellt. Auf welcher Seite eine Gruppe aktiv ist, kann direkt über den Mode Inactive/Active eingesehen werden.
Betrachtet von der sekundären Seite haben wir nun eine Incoming Replikation und die Local/Remote-Snapshot-Reiter sind entsprechend verdreht.


Dies war bereits die Konfiguration einer einfachen asynchronen Replizierung mit den wichtigsten Grundfunktionalitäten.

Im nächsten Teil werden wir die entsprechenden Disaster Recovery Szenarien betrachten welche diese Lösung bietet.

Ich hoffe, wir konnten Ihnen die einfache Einrichtung einer Replikation auf Nutanix Systemen etwas näher bringen.
Nehmen Sie gerne Kontakt mit uns auf, wenn Disaster Recovery ein Thema für Sie ist.
Als Nutanix Elite Partner stehen uns diverse Nutanix Laborumgebungen zur Verfügung, wo wir Ihnen gerne auch live eine solche Konfiguration vorführen können.


Related Posts