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 einen ganzen Standort zerstört. Informationen zum Schutz vor Ausfällen eines einzelnen Servers finden Sie unterHohe Verfügbarkeit.

Hinweis:

Sie müssen mit Ihrem Root-Konto angemeldet sein oder die Rolle des 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 für die Wiederherstellung geschäftskritischer VMs und vApps in Speicher-Repositories (SRs) erforderlich sind. 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 an einem sekundären Standort (DR) mit minimaler Anwendungs- oder Benutzerausfallzeit neu erstellt wurde.

Die Disaster Recovery-Einstellungen in XenCenter können verwendet werden, um den Speicher abzufragen und ausgewählte VMs und vApps während eines Disasters in einen Wiederherstellungspool zu importieren. Wenn die VMs im Wiederherstellungspool ausgeführt werden, werden auch die Metadaten des Wiederherstellungspool repliziert. Durch die Replikation der Pool-Metadaten können alle Änderungen der VM-Einstellungen wieder in den primären Pool aufgefüllt werden, wenn der primäre Pool wiederhergestellt wird. Manchmal können sich Informationen für dieselbe VM an mehreren Stellen befinden. Beispielsweise Speicher vom primären Standort, Speicher vom Disaster Recovery-Standort und auch in dem Pool, in den die Daten importiert werden sollen. Wenn XenCenter feststellt, dass die VM-Informationen an zwei oder mehr Orten vorhanden sind, wird sichergestellt, dass nur die neuesten Informationen verwendet werden.

Die Disaster Recovery-Funktion kann mit XenCenter und der xe CLI verwendet werden. Informationen zu CLI-Befehlen finden Sie unterDisaster Recovery-Befehle.

Tipp:

Sie können auch die Disaster Recovery-Einstellungen verwenden, um Test-Failover für unterbrechungsfreie Tests Ihres Disaster Recovery-Systems auszuführen. Bei einem Test-Failover sind alle Schritte identisch mit dem Failover. Die VMs und vApps werden jedoch nicht gestartet, nachdem sie an der Disaster Recovery-Site wiederhergestellt wurden. Nach Abschluss des Tests 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 Metadaten-Konfigurationsdaten werden beim Erstellen der VM geschrieben und 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 Notfall-Umgebung werden VMs an einem sekundären Standort mithilfe der Pool-Metadaten und Konfigurationsinformationen zu allen VMs und vApps im Pool neu erstellt. Die Metadaten für jede VM umfassen den Namen, die Beschreibung und die Universal Unique Identifier (UUID) sowie den Arbeitsspeicher, die virtuelle CPU sowie die Netzwerk- und Speicherkonfiguration. Es umfasst auch VM-Startoptionen — Startreihenfolge, Verzögerungsintervall, hohe Verfügbarkeit und Neustartpriorität. Die VM-Startoptionen werden beim Neustart der VM in einer Umgebung mit hoher Verfügbarkeit oder Notfallwiederherstellung verwendet. Wenn Sie beispielsweise VMs während der Notfallwiederherstellung wiederherstellen, werden VMs innerhalb einer vApp in der in den VM-Metadaten angegebenen Reihenfolge neu gestartet und die angegebenen Verzögerungsintervalle verwendet.

Anforderungen an die DR-Infrastruktur

Richten Sie die entsprechende DR-Infrastruktur sowohl am primären als auch am sekundären Standort ein, um Citrix Hypervisor DR.

  • Speicher, der für Pool-Metadaten verwendet wird, und die virtuellen Laufwerke, die von den VMs verwendet werden, müssen von der primären (Produktions-) Umgebung in eine Sicherungsumgebung repliziert werden. Die Speicherreplikation, z. B. die Verwendung der Spiegelung, variiert je nach Gerät. Wenden Sie sich daher an den Anbieter von Speicherlösungen, um die Speicherreplikation zu verarbeiten.

  • Nachdem die VMs und vApps, die Sie in einem Pool auf der DR-Site wiederhergestellt haben, ausgeführt und ausgeführt wurden, müssen die SRs repliziert werden, die die Metadaten des Notfall-Pools und die virtuellen Laufwerke enthalten. Durch die Replikation können die wiederhergestellten VMs und vApps wieder am primären Standort wiederhergestellt werden (fehlgeschlagen) , 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.

Warnhinweis:

Die Disaster Recovery-Einstellungen steuern keine Speicher-Array-Funktionen.

Benutzer der Disaster Recovery-Funktion 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 defekt“), bevor Sie VMs auf der Wiederherstellungs-Site neu starten.

Überlegungen zur Bereitstellung

Überprüfen Sie die folgenden Schritte, bevor Sie die Disaster Recovery 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 dername_label Parametername_description und. Das Wiederherstellen von VMs und vApps aus repliziertem Speicher ist einfacher, wenn die Namen von SRs erfassen, wie VMs und vApps SRs und 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 Ausfall durchgeführt werden müssen.

  • Unterbrechen Sie alle vorhandenen Speicherspiegelungen, sodass die Wiederherstellungs-Site Lese-/Schreibzugriff auf den freigegebenen Speicher hat.

  • Stellen Sie sicher, dass die LUNs, von denen Sie VM-Daten wiederherstellen möchten, nicht mit einem anderen Pool verbunden sind, oder es kann zu einer Beschädigung kommen.

  • Wenn Sie die Wiederherstellungs-Site vor einer Katastrophe schützen möchten, müssen Sie die Pool-Metadatenreplikation auf einen oder mehrere SRs auf der Wiederherstellungs-Site aktivieren.

Schritte nach einer Wiederherstellung

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

  • Alle Speicherspiegelungen neu synchronisieren.

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

  • Befolgen Sie auf dem primären Standort das gleiche Verfahren wie für das Failover im vorherigen Abschnitt, um ausgewählte VMs oder vApps auf die primäre

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