Disaster Recovery und Backup

Mit der Citrix Hypervisor Disaster Recovery (DR) -Funktion können Sie virtuelle Maschinen (VMs) und vApps von einem Hardwarefehler wiederherstellen, der einen ganzen Pool oder eine Site zerstört. Informationen zum Schutz vor Ausfällen einzelner Server finden Sie unter Hohe Verfügbarkeit.

Hinweis:

Sie müssen mit Ihrem Root-Konto angemeldet sein oder die Rolle Pool Operator oder höher haben, um die DR-Funktion verwenden zu können.

Grundlegendes zu Citrix Hypervisor DR

Citrix Hypervisor DR speichert alle Informationen, die erforderlich sind, um Ihre geschäftskritischen VMs und vApps auf Storage Repositories (SRs) wiederherzustellen. Die SRs werden dann von Ihrer primären (Produktions-) Umgebung in eine Backup-Umgebung repliziert. Wenn ein geschützter Pool am primären Standort ausfällt, können Sie die VMs und vApps in diesem Pool aus dem replizierten Speicher wiederherstellen, der auf einer sekundären Site (DR) mit minimaler Ausfallzeit für Anwendungen oder Benutzer neu erstellt wurde.

Mit den Einstellungen für die Notfallwiederherstellung in XenCenter können Sie den Speicher abfragen und ausgewählte VMs und vApps während eines Notfalls in einen Wiederherstellungspool importieren. Wenn die VMs im Wiederherstellungspool ausgeführt werden, werden die Metadaten des Wiederherstellungspools ebenfalls repliziert. Durch die Replikation der Poolmetadaten können Änderungen an den VM-Einstellungen wieder in den primären Pool übernommen werden, wenn der primäre Pool wiederhergestellt wird. Manchmal können Informationen für dieselbe VM an mehreren Stellen vorliegen. Beispiel: Speicher vom primären Standort, Speicher vom Notfallwiederherstellungsstandort und auch im Pool, in den die Daten importiert werden sollen. Wenn XenCenter feststellt, dass die VM-Informationen an zwei oder mehr Stellen vorhanden sind, wird sichergestellt, dass nur die neuesten Informationen verwendet werden.

Die Notfallwiederherstellung kann mit XenCenter und der xe CLI verwendet werden. Informationen zu CLI-Befehlen finden Sie unter Befehle zur Notfallwiederherstellung.

Tipp:

Sie können auch die Einstellungen für die Notfallwiederherstellung verwenden, um Test-Failovers für unterbrechungsfreie Tests Ihres Disaster Recovery-Systems auszuführen. In einem Test-Failover sind alle Schritte identisch mit dem Failover. Die VMs und vApps werden jedoch nicht gestartet, nachdem sie auf der Notfallwiederherstellungs-Site wiederhergestellt wurden. Wenn der Test abgeschlossen ist, wird eine Bereinigung durchgeführt, um alle VMs, vApps und Speicher zu löschen, die auf der DR-Site neu erstellt wurden.

Citrix Hypervisor VMs bestehen aus zwei Komponenten:

  • Virtuelle Laufwerke, die von der VM verwendet werden, die in konfigurierten Speicher-Repositories (SRs) im Pool gespeichert sind, in dem sich die VMs befinden.

  • Metadaten, die die VM-Umgebung beschreiben. Diese Informationen sind erforderlich, um die VM neu zu erstellen, wenn die ursprüngliche VM nicht verfügbar oder beschädigt ist. Die meisten Metadatenkonfigurationsdaten werden beim Erstellen der VM geschrieben und werden nur aktualisiert, wenn Sie die VM-Konfiguration ändern. Bei 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 Standort mit der Poolmetadaten und Konfigurationsinformationen zu allen VMs und vApps im Pool neu erstellt. Die Metadaten für jede VM umfassen den Namen, die Beschreibung und die UUID (Universal Unique Identifier) sowie den Arbeitsspeicher, die virtuelle CPU sowie die Netzwerk- und Speicherkonfiguration. Sie umfasst auch VM-Startoptionen — Startreihenfolge, Verzögerungsintervall, hohe Verfügbarkeit und Neustartpriorität. Die Startoptionen der VM werden verwendet, wenn die VM in einer Hochverfügbarkeits- oder DR-Umgebung neu gestartet wird. Wenn beispielsweise VMs während der Notfallwiederherstellung wiederhergestellt werden, werden VMs innerhalb einer vApp in der Reihenfolge neu gestartet, die in den VM-Metadaten angegeben ist und die angegebenen Verzögerungsintervalle verwendet werden.

Anforderungen an die DR-Infrastruktur

Richten Sie die entsprechende DR-Infrastruktur sowohl am primären als auch am sekundären Standort für die Verwendung von Citrix Hypervisor DR. ein.

  • Speicher, der für Poolmetadaten und die von den VMs verwendeten virtuellen Laufwerke verwendet wird, muss von der primären (Produktions-) Umgebung in eine Backup-Umgebung repliziert werden. Die Speicherreplikation, z. B. die Verwendung von Spiegelung, variiert zwischen den Geräten. Wenden Sie sich daher an den Anbieter von Speicherlösungen, um die Speicherreplikation zu handhaben.

  • Nachdem die VMs und vApps, die Sie in einem Pool auf Ihrer DR-Site wiederhergestellt haben, ausgeführt wurden, müssen die SRs, die die Metadaten des DR-Pool und die virtuellen Laufwerke enthalten, repliziert werden. Mit der Replikation können die wiederhergestellten VMs und vApps wieder am primären Standort wiederhergestellt werden (Failback), wenn der primäre Standort wieder online ist.

  • Die Hardwareinfrastruktur am DR-Standort muss nicht mit dem primären Standort übereinstimmen. Die Citrix Hypervisor Umgebung muss jedoch auf der gleichen Release- und Patch-Ebene sein. Darüber hinaus müssen ausreichende Ressourcen im Zielpool konfiguriert werden, damit alle ausgefallenen VMs neu erstellt und gestartet werden können.

Warnung:

Die Einstellungen für die Notfallwiederherstellung steuern keine Speicher-Array-Funktionen.

Benutzer der Notfallwiederherstellungsfunktion müssen sicherstellen, dass der Metadatenspeicher in gewisser Weise zwischen den beiden Standorten repliziert wird. Einige Speicher-Arrays enthalten “Spiegelung” -Funktionen, um die Replikation automatisch zu erreichen. Wenn Sie diese Funktionen verwenden, müssen Sie die Spiegelfunktion deaktivieren (“Mirror is broken”), bevor Sie VMs auf der Wiederherstellungs-Site neu starten.

Überlegungen zur Bereitstellung

Überprüfen Sie die folgenden Schritte, bevor Sie die Notfallwiederherstellung aktivieren.

Schritte vor einer Katastrophe

Im folgenden Abschnitt werden die Schritte beschrieben, die vor einer Katastrophe durchgeführt werden müssen.

  • Konfigurieren Sie Ihre VMs und vApps.

  • Beachten Sie, wie Ihre VMs und vApps SRs und die SRs LUNs zugeordnet sind. Achten Sie besonders auf die Benennung der Parameter name_label und name_description. Das Wiederherstellen von VMs und vApps aus repliziertem Speicher ist einfacher, wenn die Namen von SRs erfassen, wie VMs und vApps SRs und SRs LUNs zugeordnet werden.

  • Ordnen Sie die Replikation der LUNs an.

  • Aktivieren Sie die Pool-Metadatenreplikation auf einen oder mehrere SRs auf diesen LUNs.

  • Stellen Sie sicher, dass die SRs, auf die Sie die primären Pool-Metadaten replizieren, nur einem Pool zugeordnet sind.

Schritte nach einer Katastrophe

Im folgenden Abschnitt werden die Schritte beschrieben, die nach einem Notfall ausgeführt werden müssen.

  • Unterbrechen Sie alle vorhandenen Speicherspiegel, sodass die Wiederherstellungs-Site Lese-/Schreibzugriff auf den gemeinsam genutzten Speicher hat.

  • Stellen Sie sicher, dass die LUNs, von denen Sie VM-Daten wiederherstellen möchten, nicht an einen anderen Pool angehängt sind oder dass eine Beschädigung auftreten kann.

  • Wenn Sie die Wiederherstellungs-Site vor einem Notfall schützen möchten, müssen Sie die Pool-Metadatenreplikation auf einem oder mehreren SRs auf der Wiederherstellungs-Site aktivieren.

Schritte, die nach einer Wiederherstellung durchgeführt werden müssen

Im folgenden Abschnitt werden die Schritte beschrieben, die nach einer erfolgreichen Datenwiederherstellung durchgeführt werden müssen.

  • Synchronisieren Sie alle Speicherspiegel neu.

  • Fahren Sie auf der Wiederherstellungs-Site die VMs oder vApps, die Sie zum primären Standort zurückverschieben möchten, sauber herunter.

  • Führen Sie am primären Standort das gleiche Verfahren wie beim Failover im vorherigen Abschnitt aus, um ausgewählte VMs oder vApps auf die primäre

  • Um den primären Standort vor zukünftigen Notfällen zu schützen, müssen Sie die Pool-Metadatenreplikation auf einen oder mehrere SRs auf den replizierten LUNs erneut aktivieren.