Nutanix Disaster Recovery – Restore (Teil 3)


Nachdem wir die Grundlagen und deren Konfiguration betrachtet haben, werden wir nun die im Ernstfall bereitstehenden Restore-Mechanismus aufzeigen.

Dabei ist zwischen drei grundsätzlichen Szenarien, welche auftreten können, zu unterscheiden.

Szenario 1 – Snapshot Restore
– Ausfall/Datenverlust einzelner VMs/Objekte
– Datacenter weiterhin im Normalbetrieb

Szenario 2 – Migration

– Geplante zukünftige Downtime eines Datacenters
– Migration des Workloads

Szenario 3 – Failover
– Ausfall eines Datacenters
– Disaster Recovery am zweiten Standort

Bei allen drei Szenarien kann es zu Downtime und/oder Datenverlust kommen, daher sollte vorher immer abgewogen werden, ob das gewählte Vorgehen der aktuellen Situation zutreffend und angemessen ist. Mehr zu diesem Thema wird im Detail der einzelnen Szenarien beschrieben.

 

Szenario 1 – Snapshot Restore

Ausgangssituation:
Das GuestOS einer einzelne VM wurde z. B. durch Updates beschädigt oder es kam innerhalb der VM zu einem Datenverlust.

Vorgehen:
Zurückspielen und Überschreiben der kompletten VM aus einem vorherigen Snapshot.
Alternativ kann die VM auch parallel zu der Live VM wiederhergestellt werden. Dies ist sinnvoll, falls nur User-Daten, welche nicht relevant für das OS sind, gelöscht wurden oder zur Sicherheit die Original-VM bestehen bleiben soll.

Impact:
Bei einem Überschreiben kommt es zu einer Downtime der VM und zusätzlich zu einem Datenverlust des einzelnen Objektes seit dem letzten Snapshot. Das Datum kann in der GUI eingesehen werden und somit der Impact kalkuliert werden.

Der Restore-Prozess wird dabei über den Menüpunkt Local Snapshots ausgeführt.
In diesem werden alle lokal vorhandenen Snapshots mit entsprechendem Timestamp aufgelistet, der Restore ist direkt über den Button Restore möglich.

 

Anschließend kann/können eine oder mehre VMs ausgewählt werden und über den Punkt Overwrite existing entities direkt die original VM(s) überschrieben werden.
Nach dem Bestätigen wird die entsprechende VM ausgeschaltet und auf den Zeitpunkt des Snapshots zurückgerollt.

Die VM muss danach von Hand gestartet werden, dies geschieht nicht automatisch.
Der gesamte Prozess dauert <1min pro VM, unabhängig der jeweiligen Größe.

Alternativ kann die VM, wie bereits angesprochen, parallel betrieben werden, was über die Option Create new entities möglich ist.
Dabei muss ein Prefix für den Restore angegeben werden, damit die neu erstellten VMs nicht den identischen Namen der Liveumgebung tragen.

Bei einem ESXi Cluster muss noch der Path im Datastore mitgegeben werden, bei AHV ist dies nicht nötig.
Die ursprüngliche VM bleibt von diesem Prozess vollkommen unangetastet und ist weiterhin dauerhaft online.

Auch hierbei wird die neu erstellte VM anschließend im vCenter/Prism registriert, bleibt allerdings ebenfalls ausgeschaltet.
Als nächstes könnte die VM angeschaltet werden, dabei ist es empfehlenswert die NIC zu deaktivieren, um eventuelle IP-Adresskonflikte zu verhindern.
Danach könnten über die Konsole entsprechende Restore-Mechanismen ausgeführt werden.

Ist der benötigte Snapshot nicht mehr auf dem lokalen System vorhanden, sondern wird nur noch von einer DR-Seite gehalten, muss dieser vorher erst auf das lokale System kopiert werden.
Dies ist direkt in dem Reiter Remote Snapshots über den Button Retrieve möglich.

 

 

Szenario 2 – Migration

Ausgangssituation:
Eine komplette Seite/Cluster soll einer Wartung unterzogen werden und alle darauf befindlichen Objekte sollen vorübergehend oder dauerhaft auf den sekundären Standort migriert werden.

Vorgehen:
Die Async DR Protection Domain wird auf das sekundäre Cluster migriert, anschließend wird der Spiegel automatisch umgedreht und es kann eine Replikation in die andere Richtung erfolgen.

Impact:
Downtime aller Objekte innerhalb der entsprechenden Protection Domain, es kommt zu keinem Datenverlust da die Daten nach dem Herunterfahren der VMs noch einmal repliziert werden.
Wurde der Prozess einmal angestoßen, kann dieser bis zur Vollendung nicht unterbrochen werden.

 

Wir loggen uns auf dem Cluster ein, welcher die Gruppe aktuell aktiv betreibt.
Im Menüpunkt Async DR wählen wir die entsprechende Protection Domain aus, der grüne Punkt zeigt uns an dass diese Gruppe aktiv ist. Sollte dieser Punkt ausgegraut sein, befinden wir uns auf dem falschen Cluster.

Als nächstes klicken wir auf den Knopf Migrate.

Im nächsten Fenster müssen wir die entsprechende Seite als Zielcluster auswählen und erneut mit Migrate bestätigen.

Achtung: Es erfolgt anschließend keine Abfragebestätigung mehr, der Prozess wird direkt gestartet.

Folgende Schritte werden anschließend vom Cluster automatisch durchgeführt.

– Snapshot erstellen + Replikation
– VMs herunterfahren (GuestOS Shutdown wenn VM Tools installiert)
– Snapshot 2 erstellen + Replikation
– Protection Domain auf zweitem Cluster aktiv schalten
– VMs auf Hypervisor-Plattform registrieren
– Protection Domain auf Quellcluster deaktivieren
– Scheduler umdrehen und wieder aktivieren

Durch das Anlegen von zwei Snapshots, einer vor dem Herunterfahren und einer danach, wird die Downtime so gering wie möglich gehalten und zusätzlich ein Datenverlust/Beschädigung gänzlich ausgeschlossen.

Anschließend können die VMs auf dem Zielcluster eingeschaltet werden. Dies erfolgt auch in diesem Szenario nicht automatisch, es sollte daher vorher eine Liste erstellt werden, welche VMs vor der Migration eingeschaltet waren.

Im Interface ist die Gruppe nun deaktiviert (grau), alle weiteren Änderungen an dieser Replikation müssen nun auf dem Zielcluster durchgeführt werden.
Die Dauer des Umschaltprozesses ist dabei abhängig von der Anzahl der VMs und deren Änderungsrate seit dem letzten Snapshot.

 

 

Szenario 3 – Failover

Ausgangssituation:
Eine komplette Seite/Cluster ist unvorhergesehen offline und kann auch nicht innerhalb einer akzeptablen Zeit wieder online gebracht werden.

Vorgehen:
Die Replikation wird vom Zielcluster aus unterbrochen und anschließend aktiv geschaltet.

Impact:
Datenverlust seit der letzten Replikation

Achtung: Bei diesem Szenario sollte besonders abgewogen werden, ob es nicht doch möglich und sinnvoll ist, die ausgefallene Seite wieder online zu bringen, da der Impact/Datenverlust einer Umschaltung und der damit teilweise verbundene sehr hohe Recovery-Aufwand überwiegen können.

Es sollte im allerersten Schritt sichergestellt werden, dass die aktive Seite wirklich offline ist und zusätzlich daran gehindert werden, unvorhergesehen wieder online zu gehen. Gerade bei Strom- oder Netzwerkausfällen kann dieser Fall eintreten und hohen Schaden anrichten, wenn plötzlich unterschiedliche Zustände mit gleichen IP-Adressen im Netzwerk aktiv sind.

Ist dies sichergestellt, wird über die sekundäre Seite im Reiter Data Protection die entsprechende Gruppe markiert und über den Knopf Activate auf diesem Cluster aktiv geschaltet.
Achtung: Auch hier erfolgt nur noch eine einzige Abfrage, die mit Yes bestätigt werden muss.

Anschließend wird die Replikation aufgebrochen und der letzte Snapshot automatisch aktiv geschaltet. Des Weiteren werden die VMs an den entsprechenden Hypervisor gemappt und müssen anschließend wie in allen Szenarien mit der Hand manuell gestartet werden.

Dabei kommt es gezwungenermaßen zu einem Datenverlust von allen Daten, die nach dem Erstellen des Snapshots geändert/erstellt wurden.

Im Nachgang, nachdem die ausgefallene Seite kontrolliert wieder hochgefahren wurde, muss auf dieser noch die komplette Async DR Gruppe inkl. aller Snapshots gelöscht werden.
Anschließend kann auf der neuen Primärseite ein Scheduler erstellt werden, welcher dann wieder eine inaktive Protection Domain auf der ehemaligen Primärseite erstellt und die VMs repliziert.

 

Ich hoffe, wir konnten Ihnen die Einfachheit einer Replikation und der Disaster-Recovery-Szenarien auf Nutanix 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 ein solches Szenario vorführen können.


Related Posts