Disaster Recovery und Backup

Mit der HASH (0x2c1a078) Disaster Recovery (DR) können Sie virtuelle Maschinen (VMs) und vApps aus einem Hardwarefehler wiederherstellen, der einen ganzen Pool oder eine Site zerstört. Informationen zum Schutz vor Ausfällen einzelner Server finden Sie unterHohe Verfügbarkeit.

Hinweis:

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

Grundlegendes zu HASH (0x2c1a078) DR

Die HASH (0x2c1a078) DR speichert alle Informationen, die erforderlich sind, um Ihre geschäftskritischen VMs und vApps in Speicher-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 einem sekundären Standort (DR) neu erstellt wurde, mit minimalen Ausfallzeiten von Anwendungen oder Benutzern.

Die Einstellungen für die Notfallwiederherstellung in HASH (0x2e6c8e8) können verwendet werden, um den Speicher abzufragen und ausgewählte VMs und vApps während eines Notfalls in einen Wiederherstellungspool zu importieren. Wenn die VMs im Wiederherstellungspool ausgeführt werden, werden auch die Metadaten des Wiederherstellungspools repliziert. Durch die Replikation der Pool-Metadaten können Änderungen der VM-Einstellungen wieder in den primären Pool aufgefüllt 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 von der Disaster Recovery-Site und auch im Pool, in den die Daten importiert werden sollen. Wenn HASH (0x2e6c8e8) feststellt, dass die VM-Informationen an zwei oder mehr Stellen vorhanden sind, stellt es sicher, dass nur die neuesten Informationen verwendet werden.

Die Disaster Recovery-Funktion kann mit HASH (0x2e6c8e8) und der xe-CLI verwendet werden. Informationen zu CLI-Befehlen finden Sie unterDisaster Recovery-Befehle.

Tipp:

Sie können auch die Einstellungen für die Notfallwiederherstellung 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 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.

HASH (0x2c1a078) VMs bestehen aus zwei Komponenten:

  • Virtuelle Laufwerke, die von der VM verwendet werden und in konfigurierten Speicher-Repositories (SRs) im Pool gespeichert werden, 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 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 mithilfe der Pool-Metadaten und Konfigurationsinformationen zu allen VMs und vApps im Pool neu erstellt. Die Metadaten für jede VM enthalten den Namen, die Beschreibung und die UUID (Universal Unique Identifier) sowie den Arbeitsspeicher, die virtuelle CPU sowie die Netzwerk- und Speicherkonfiguration. Es umfasst auch Startoptionen für VM — Startreihenfolge, Verzögerungsintervall, Hochverfügbarkeit und Neustartpriorität. Die Startoptionen für VM werden beim Neustart der VM in einer Hochverfügbarkeits- oder DR-Umgebung verwendet. Wenn beispielsweise VMs während der Notfallwiederherstellung wiederhergestellt werden, werden VMs innerhalb einer vApp in der in den VM-Metadaten angegebenen Reihenfolge und unter Verwendung der angegebenen Verzögerungsintervalle im DR-Pool neu gestartet.

Anforderungen an die Notfallinfrastruktur

Richten Sie die geeignete DR-Infrastruktur sowohl am primären als auch am sekundären Standort ein, um HASH (0x2c1a078) DR.

  • Der Speicher, der für Pool-Metadaten 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 wie die Verwendung von Spiegelung variiert je nach Gerät. Wenden Sie sich daher an Ihren Anbieter von Speicherlösungen, um die Speicherreplikation zu handhaben.

  • Nachdem die VMs und vApps, die Sie in einem Pool auf der DR-Site wiederhergestellt haben, ausgeführt wurden, müssen die SRs mit den Metadaten des DR-Pools und den virtuellen Laufwerken repliziert werden. Durch die 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 an Ihrem Notfall-Standort muss nicht mit dem primären Standort übereinstimmen. Die HASH-Umgebung (0x2c1a078) muss jedoch auf derselben Release- und Patch-Ebene liegen. Darüber hinaus müssen im Zielpool genügend Ressourcen konfiguriert werden, damit alle Failover-VMs neu erstellt und gestartet werden können.

Achtung:

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

Benutzer der Disaster Recovery-Funktion müssen sicherstellen, dass der Metadatenspeicher in irgendeiner Weise zwischen den beiden Standorten repliziert wird. Einige Speicher-Arrays enthalten „Mirroring“ -Funktionen, um die Replikation automatisch zu erreichen. Wenn Sie diese Funktionen verwenden, müssen Sie vor dem Neustart von VMs auf der Wiederherstellungs-Site die Spiegelfunktion deaktivieren („Spiegelung ist defekt“).

Ü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 einem Notfall 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 zu LUNs zugeordnet werden.

  • Ordnen Sie die Replikation der LUNs an.

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

  • Stellen Sie sicher, dass die SRs, in 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 vorhandener 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 angeschlossen sind, oder es kann zu einer Beschädigung kommen.

  • Wenn Sie die Wiederherstellungs -Site vor einem Notfall schützen möchten, müssen Sie die Pool-Metadatenreplikation auf eine oder mehrere 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 Wiederherstellung von Daten durchgeführt werden müssen.

  • Speichern Sie alle Spiegeln neu synchronisieren.

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

  • Führen Sie am primären Standort dasselbe Verfahren wie für das Failover im vorherigen Abschnitt aus, um ausgewählte VMs oder vApps auf den primären

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