Testreihe Disaster Recovery, Teil 2: Zerto 8.0
DR mit intelligenter Replikation
Fortsetzung des Artikels von Teil 1
VM-Replikation mit Virtual Protection Groups
Für die Replikation von VMs verwendet Zerto sogenannte Virtual Protection Groups (VPG), in denen sich mehrere VMs zusammenfassen lassen. Bei der Erstellung einer VPG legt der Administrator unter anderem die Boot-Reihenfolge der VMs, die Anzahl der Recovery-Checkpoints und die Größe der Journal-History fest. In der Netzkonfiguration lässt sich eine Re-IP-Aktion konfigurieren, indem man für die Recovery-VMs andere IP-Adressen eingibt. Hier ist es zudem möglich, zusätzliche IP-Adressen für die Sandbox-Testfunktion von Zerto einzutragen.
Zerto kann die Replikationsdaten auf dem produktiven Storage-System bis zu 30 Tage speichern. Mit der Long-Term Retention (LTR) ist es zudem möglich, die Recovery Checkpoints in wöchentlichen, monatlichen oder jährlichen Abständen über beliebig viele Jahre hinweg auf einem kostengünstigen Speichersystem vorzuhalten. Zerto unterstützt auch eine One-to-many-Replikation, die von einer Quell-VM mehrere Replicas auf unterschiedlichen Zielsystemen erstellt. Für Windows-VMs bietet Zerto einen VSS-Agenten an, mit dem sich applikationskonsistente Replica-Backups erzeugen lassen. Standardmäßig repliziert Zerto die VMs in einem crash-konsistenten Zustand. Beim Einsatz mit vSphere unterstützt Zerto 8.0 nun auch Virtual Volumes (VVOL). Die Datenübertragungen zur DR-Site optimiert Zerto durch eine integrierte WAN-Beschleunigung. Eine Einbindung von Dritthersteller-Lösungen ist über APIs möglich.
Für den LANline-Test erstellten wir auf den zwei ZVM-Systemen jeweils eine neue VPG und fügten die WS2019-VM und die Ubuntu-VM hinzu. Als Recovery-Site trugen wir den ESXi- beziehungsweise Hyper-V-Standalone-Host ein, auf dem wir zuvor eine lokale Platte als Repository konfiguriert hatten.
Recovery-Tests mit DR-Site
Der Administrator kann über die Zerto-Konsole sowohl für einzelne VMs als auch für komplette VPGs einen Failover anstoßen. Mit der Restore-Funktion ist es zudem möglich, VMs aus der Replica-Kopie wiederherzustellen. Die Rücksicherung einzelner Dateien und Verzeichnisse unterstützt das System ebenfalls.
Zerto eignet sich auch für den Desaster-schutz von größeren Umgebungen mit mehreren Tausend virtuellen Maschinen. Die Cloud-Anbindung erfolgt über die Zerto Cloud Appliance, die in der jeweiligen Cloud-Umgebung läuft. Für Service-Provider bietet Zerto die mandantenfähige DRaaS-Lösung Zerto Cloud Manager an.
Über die Site-Pairing-Funktion von Zerto lassen sich die ZVM-Server von mehreren Standorten sowie Cloud-ZCA-Systeme miteinander verbinden. Für den LANline Test verzichteten wir zunächst auf das Site Pairing der lokalen Hosts, da die jeweils drei Server über dasselbe vCenter oder VMM-System verwaltet wurden. In diesem Fall ist die Replikation auch innerhalb einer Site möglich.
Als erstes führten wir auf beiden Plattformen einen Test-Failover der VPG mit den zwei VMs durch. Nach dem Klick auf den Test-Button legt Zerto auf dem DR-Site-Host die VM-Hüllen an, verknüpft sie mit dem replizierten Datenbestand und fährt die VMs in der Sandbox-Umgebung hoch. Die Original-VM läuft ganz normal weiter. Anschließend überprüft der Administrator, ob die VMs fehlerfrei arbeiten. Sobald der Test beendet wurde, entfernt Zerto die VM-Hüllen wieder. Bei dem Sandbox-Test konnten wir uns an allen vier Replica-VMs nach dem Hochfahren auf dem DR-System über die lokale vCenter- oder Hyper-V-Konsole anmelden. Anschließend stoppten wir den Test und Zerto entfernte die VM-Hüllen wieder von den DR-Hosts. Das Testergebnis lässt sich im CSV-Format oder als PDF abspeichern.
Unter dem Menüpunkt Reports findet sich eine Handvoll Standardberichte zu VPG-Performance, Recovery-Kennzahlen und Ressourcennutzung. Hinter dem Menüpunkt Analytics verbirgt sich eine Cloud-Anwendung von Zerto, die historische Daten analysiert und mit Forecasting-Funktionen eine Ressourcenplanung ermöglicht.
Um den Live-Failover zu testen, löschten wir die aktive WS2019-VM vom ESXi- und vom Hyper-V-Cluster. Die ZVM-Konsole zeigte sofort an, dass diese VMs nicht mehr online sind. Wir klickten auf den Menüpunkt Live-Failover, wählten die VPG mit der fehlenden VM aus und führten dann den Failover auf die Replica-VM in der DR-Site aus. ZVM hat die Ersatz-VM auf dem DR-Host angelegt und Windows erfolgreich gestartet. Standardmäßig wartet die Software 60 Minuten, bevor die Replica-VM zur neuen produktiven VM deklariert wird. Der Administrator kann jedoch auch einstellen, dass diese VM sofort zum Produktivsystem wird. Für Migrationen oder zu Wartungsarbeiten ist es auch möglich, nach einem Failover die Replikationsrichtung umzudrehen. Zerto unterstützt zudem ein Cloning von VMs, zum Bespiel um Testkopien zu erzeugen.
Bei der auf dem Hyper-V-Cluster gelöschten VM hatten wir in den VPG-Settings für den Failover ein anderes IP-Subnetz konfiguriert. Zerto fuhr die Recovery-VM automatisch mit den veränderten IP-Adressdaten hoch. Wir konnten uns über die neue IP-Adresse erfolgreich per RDP an der in der DR-Site wiederhergestellten VM anmelden. Zerto unterstützt auch eine Cross-Hypervisor-Replikation von VMware zu Hyper-V oder in der umgekehrten Richtung. Um dies zu testen, fügten wir zur primären VMware-vSphere-Site die Hyper-V-Recovery-Site per Site Pairing hinzu. Dann replizierten wir die WS2019-VM vom ESXi-Host auf den Hyper-V-DR-Site-Host. Nachdem die initiale Synchronisierung abgeschlossen war, führten wir einen Failover vom ESXi-Host auf den Hyper-V-Host durch. Zerto legte in der DR-Site eine Hyper-V-VM an und fuhr die WS2019-VM anschließend erfolgreich hoch.
Eine Replikation von VMs in die Cloud zu AWS, Azure oder Google ist ebenfalls möglich, wenn in der Cloud eine Zerto Cloud Appliance als Recovery-Site konfiguriert und per Site Pairing mit dem ZVM-System im Unternehmens-RZ verbunden wurde.
Einzelne Dateien und Verzeichnisse von VMs lassen sich über den Menüpunkt Re-store zurücksichern. Zerto mountet dazu die VM-Disk und öffnet ein Browser-Fenster, um die gewünschten Objekte auszuwählen. Wir testeten dies mit einer Linux-VM und sicherten ein Home-Verzeichnis zurück. Die Dateien speichert Zerto im Download-Verzeichnis des Rechners, auf dem die ZVM-Konsole ausgeführt wird.
Wie bereits erwähnt, konnten wir wegen der fehlenden netztechnischen Voraussetzungen ein Site-Recovery zwischen dem LANline-Testlab und der AWS-Cloud nicht testen. Um zumindest die LTR-Replikation von Zerto zu AWS S3 zu testen, legten wir in unserer AWS-Konsole eine neue E2C-Instanz an und wählten das Image mit AWS Storage Gateway aus.
Die File-Variante des Gateways stellt den S3-Speicher als NFS-Share bereit. Wir legten im S3-Bereich von AWS einen neuen S3-Storage-Bucket an und fügten diesen zum AWS-Storage-Gateway hinzu. Für die E2C-Instanz richteten wir eine neue Security-Group mit den für NFS-Zugriffe benötigten Firewall-Regeln ein. Anschließend konnten wir in der ZVM-GUI unserer lokalen Hyper-V-Plattform den S3-Storage als neues NFS-Repository hinzufügen. Das Share war vom ZVM-Server aus über das Internet per IP-Adresse:/<S3bucketname> erreichbar. Im nächsten Schritt konfigurierten wir eine neue VPG mit einer Linux-VM und wählten bei den LTR-Settings das S3-Share als Repository aus. Dann starteten wir den ersten Retention-Vorgang, der die VM-Daten zu AWS übertrug.
Rücksicherung aus der Cloud
Nachdem dies abgeschlossen war, testeten wir die Rücksicherung der virtuellen Maschine aus der AWS-Cloud auf den Hauptstandort. Hierfür löschten wir die virtuelle Disk der Linux-VM vom Hyper-V-Host. Dann wählten wir Restore VM/VPG, markierten das AWS-Backup der VM und starteten den Restore. Nach knapp 20 Minuten war die Rücksicherung aus der Cloud abgeschlossen und wir konnten die Linux-VM erfolgreich starten.
- DR mit intelligenter Replikation
- VM-Replikation mit Virtual Protection Groups
Lesen Sie mehr zum Thema
