Notfallwiederherstellung (DR)
Die Funktion zur Notfallwiederherstellung (DR) ermöglicht es Ihnen, VMs und vApps nach einem katastrophalen Hardwareausfall wiederherzustellen, der einen ganzen Pool oder Standort deaktiviert oder zerstört.
Zum Schutz vor Ausfällen einzelner Server können Sie (/de-de/xencenter/current-release/pools-ha.html) verwenden. Die Hochverfügbarkeit startet VMs auf einem alternativen Server im selben Pool neu.
DR verstehen
Die Notfallwiederherstellung speichert alle Informationen, die zur Wiederherstellung Ihrer geschäftskritischen VMs und vApps erforderlich sind, auf Speicher-Repositorys (SRs). Diese Speicher-Repositorys werden dann von Ihrer primären (Produktions-)Umgebung in eine Sicherungsumgebung repliziert. Wenn ein geschützter Pool an Ihrem primären Standort ausfällt, können die VMs und vApps in diesem Pool aus dem replizierten Speicher wiederhergestellt und an einem sekundären (DR-)Standort neu erstellt werden. Das Ergebnis ist eine minimale Anwendungs- oder Benutzer-Ausfallzeit.
Nachdem die wiederhergestellten VMs im DR-Pool betriebsbereit sind, müssen die Metadaten des DR-Pools auch auf einem replizierten Speicher gespeichert werden. Diese Aktion ermöglicht es, wiederhergestellte VMs und vApps auf den primären Standort zurückzuspielen, sobald dieser wieder online ist.
Hinweis:
Die Notfallwiederherstellung kann nur mit Speichertypen LVM über HBA oder LVM über iSCSI verwendet werden.
XenServer® VMs bestehen aus zwei Komponenten:
- Virtuelle Festplatten, die von der VM verwendet werden und auf konfigurierten Speicher-Repositorys (SRs) in dem Pool gespeichert sind, in dem sich die VMs befinden.
- Metadaten, die die VM-Umgebung beschreiben. Die Metadaten enthalten alle Informationen, die zur Neuerstellung der VM erforderlich sind, falls die ursprüngliche VM nicht verfügbar oder beschädigt ist. Die meisten Metadaten werden beim Erstellen der VM geschrieben und nur aktualisiert, wenn Sie die VM-Konfiguration ändern. Für VMs in einem Pool wird eine Kopie dieser Metadaten auf jedem Server im Pool gespeichert.
In einer DR-Umgebung werden VMs an einem sekundären (DR-)Standort aus den Pool-Metadaten neu erstellt – Konfigurationsinformationen über alle VMs und vApps im Pool. Die Metadaten für jede VM umfassen ihren Namen, ihre Beschreibung und die Universal Unique Identifier (UUID) sowie ihre Speicher-, virtuelle CPU-, Netzwerk- und Speicherkonfiguration. Sie umfassen auch die VM-Startoptionen, die beim Neustart der VM in einer Hochverfügbarkeits- oder DR-Umgebung verwendet werden: Startreihenfolge, Verzögerungsintervall und Neustartpriorität. Wenn beispielsweise VMs wiederhergestellt werden, starten die VMs innerhalb einer vApp im DR-Pool in der Reihenfolge und mit den in den Metadaten angegebenen Verzögerungsintervallen neu.
Hinweis:
Um die Notfallwiederherstellung zu verwenden, müssen Sie als Root angemeldet sein oder eine Rolle als Pool-Operator oder höher haben.
Terminologie der Notfallwiederherstellung
vApp: Eine logische Gruppe verwandter VMs, die als einzelne Entität verwaltet werden.
Site: Eine physische Gruppe von XenServer-Ressourcenpools, Speicher und Hardware-Ausrüstung.
Primäre Site: Eine physische Site, die VMs oder vApps ausführt, die im Katastrophenfall geschützt werden müssen.
Sekundäre Site, DR-Site: Eine physische Site, deren Zweck es ist, im Katastrophenfall als Wiederherstellungsort für die primäre Site zu dienen.
Failover: Wiederherstellung von VMs und vApps auf einer sekundären (Wiederherstellungs-)Site im Katastrophenfall auf der primären Site.
Failback: Wiederherstellung von VMs und vApps von einer sekundären (Wiederherstellungs-)Site zurück zur primären Site.
Test-Failover: Ein „Trockenlauf“-Failover, bei dem VMs und vApps von repliziertem Speicher auf einen Pool auf einer sekundären (Wiederherstellungs-)Site wiederhergestellt, aber nicht gestartet werden. Test-Failover können durchgeführt werden, um zu überprüfen, ob DR korrekt konfiguriert ist und Ihre Prozesse effektiv sind.
Pool-Metadaten: Informationen über die VMs und vApps im Pool, wie deren Name und Beschreibung. Für VMs umfassen die Konfigurationsinformationen UUID, Arbeitsspeicher, virtuelle CPU, Netzwerk- und Speicherkonfiguration sowie Startoptionen. Pool-Metadaten werden in DR verwendet, um die VMs und vApps von der primären Site in einem Wiederherstellungspool auf der sekundären Site neu zu erstellen.
Infrastruktur für die Notfallwiederherstellung
Um die Notfallwiederherstellung zu verwenden, richten Sie die entsprechende DR-Infrastruktur sowohl an der primären als auch an der sekundären Site ein:
- Der Speicher, der sowohl für die Pool-Metadaten als auch für die von den VMs verwendeten virtuellen Festplatten verwendet wird, muss von Ihrer primären (Produktions-)Umgebung in eine Sicherungsumgebung repliziert werden. Die Speicherreplikation, beispielsweise mittels Spiegelung, variiert von Gerät zu Gerät. Wir empfehlen Ihnen, Ihre Speicherlösung für die Speicherreplikation zu verwenden.
- Nachdem wiederhergestellte VMs und vApps auf einem Pool auf Ihrer DR-Site betriebsbereit sind, replizieren Sie die SRs, die die DR-Pool-Metadaten und virtuellen Festplatten enthalten. Diese Aktion ermöglicht es, die wiederhergestellten VMs und vApps auf die primäre Site zurückzuspielen (Failback), sobald die primäre Site wieder online ist.
- Die Hardware-Infrastruktur an Ihrer DR-Site muss nicht mit der primären Site übereinstimmen. Die XenServer-Umgebung muss jedoch denselben Release- und Patch-Level aufweisen. Außerdem müssen im Zielpool ausreichend Ressourcen konfiguriert sein, damit alle ausgefallenen VMs neu erstellt und gestartet werden können.
Wichtig:
XenCenter® und der Assistent für die Notfallwiederherstellung steuern keine Funktionen von Speicher-Arrays. Stellen Sie sicher, dass die Pool-Metadaten und der von den VMs verwendete Speicher, die im Katastrophenfall neu gestartet werden sollen, auf eine Sicherungs-Site repliziert werden. Einige Speicher-Arrays verfügen über Spiegelungsfunktionen, um die Kopie automatisch zu erstellen. Wenn diese Funktionen verwendet werden, deaktivieren Sie die Spiegelungsfunktion, bevor VMs auf der Wiederherstellungs-Site neu gestartet werden.
Failover, Failback und Test-Failover mit dem Assistenten für Disaster Recovery
Der Assistent für Disaster Recovery vereinfacht Failover und Failback. Die Schritte dieser Prozesse sind hier beschrieben:
Failover
-
Wählen Sie einen Ziel-Pool auf Ihrem sekundären DR-Standort, auf dem Sie Ihre VMs und vApps wiederherstellen möchten.
-
Geben Sie Details zu den Speicherzielen an, die die replizierten SRs von Ihrem primären Standort enthalten. Der Assistent scannt die Ziele und listet alle dort gefundenen SRs auf.
-
Wählen Sie die SRs aus, die die Metadaten und virtuellen Festplatten für die VMs und vApps enthalten, die Sie wiederherstellen möchten. Der Assistent scannt die SRs und listet alle gefundenen VMs und vApps auf.
-
Wählen Sie aus, welche VMs und vApps Sie auf dem DR-Standort wiederherstellen möchten. Geben Sie an, ob der Assistent sie nach der Wiederherstellung automatisch starten soll oder ob Sie lieber warten und sie manuell selbst starten möchten.
Der Assistent führt Vorabprüfungen durch, um sicherzustellen, dass die ausgewählten VMs und vApps im Ziel-DR-Pool wiederhergestellt werden können. Zum Beispiel prüft der Assistent, ob der gesamte von den ausgewählten VMs und vApps benötigte Speicherplatz verfügbar ist.
Wenn die Vorabprüfungen abgeschlossen und alle Probleme behoben sind, beginnt der Failover-Prozess. Die ausgewählten VMs und vApps werden aus dem replizierten Speicher in den DR-Pool exportiert. Das Failover ist nun abgeschlossen.
Failback
-
Wählen Sie den Ziel-Pool auf Ihrem primären Standort, auf dem Sie die VMs und vApps wiederherstellen möchten, die derzeit auf dem DR-Standort ausgeführt werden.
-
Geben Sie Details zu den Speicherzielen an, die die replizierten SRs von Ihrem DR-Standort enthalten. Der Assistent scannt die Ziele und listet alle gefundenen SRs auf.
-
Wählen Sie die SRs aus, die die Metadaten und virtuellen Festplatten für die VMs und vApps enthalten, die Sie wiederherstellen möchten. Der Assistent scannt die SRs und listet alle gefundenen VMs und vApps auf.
-
Wählen Sie aus, welche VMs und vApps Sie auf dem primären Standort wiederherstellen möchten. Geben Sie an, ob der Assistent sie nach der Wiederherstellung automatisch starten soll oder ob Sie lieber warten und sie manuell selbst starten möchten.
Der Assistent führt dann Vorabprüfungen durch, um sicherzustellen, dass die ausgewählten VMs und vApps im Ziel-Pool auf dem primären Standort wiederhergestellt werden können. Zum Beispiel prüft der Assistent, ob der gesamte von den ausgewählten VMs und vApps benötigte Speicherplatz verfügbar ist.
Wenn die Vorabprüfungen abgeschlossen und alle Probleme behoben sind, beginnt der Failback-Prozess. Die ausgewählten VMs und vApps, die auf Ihrem DR-Standort ausgeführt werden, werden vom replizierten Speicher zurück in den ausgewählten Pool an Ihrem primären Standort exportiert.
Der Failback ist nun abgeschlossen.
Wenn der Assistent für Notfallwiederherstellung Informationen für dieselbe VM an zwei oder mehr Stellen findet, verwendet er nur die aktuellsten Informationen pro VM. Die Informationen könnten beispielsweise auf dem Speicher des primären Standorts, dem Speicher des DR-Standorts und in dem Pool, in den die Daten importiert werden, gespeichert sein.
Tipp:
Um die Wiederherstellung von VMs und vApps zu erleichtern, benennen Sie Ihre SRs so, dass sie anzeigen, wie Ihre VMs und vApps SRs zugeordnet sind und die SRs LUNs zugeordnet sind.
Sie können den Assistenten für Notfallwiederherstellung auch verwenden, um Test-Failover für nicht-unterbrechende Tests Ihres Notfallwiederherstellungssystems durchzuführen. Bei einem Test-Failover sind die Schritte dieselben wie bei einem Failover, aber wiederhergestellte VMs und vApps werden auf dem DR-Standort in einem angehaltenen Zustand gestartet. Nach Abschluss des Tests wird eine Bereinigung durchgeführt, um alle VMs, vApps und den auf dem DR-Standort neu erstellten Speicher zu entfernen. Weitere Informationen finden Sie unter Test-Failover.