Notfallwiederherstellung und Backup
Mit der XenServer Disaster Recovery (DR) -Funktion können Sie virtuelle Maschinen (VMs) und vApps nach einem Hardwarefehler wiederherstellen, der einen ganzen Pool oder eine ganze Site zerstört. Informationen zum Schutz vor Ausfällen einzelner Hosts finden Sie unter Hochverfü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 nutzen zu können.
Grundlegendes zu XenServer DR
XenServer DR speichert alle Informationen, die für die Wiederherstellung Ihrer geschäftskritischen VMs und vApps erforderlich sind, in Speicherrepositorien (SRs). Die SRs werden dann von Ihrer primären (Produktions-) Umgebung in eine Backup-Umgebung repliziert. Wenn ein geschützter Pool an Ihrem 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 (DR) -Site mit minimalen Anwendungs- oder Benutzerausfallzeiten 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 einer Katastrophe in einen Wiederherstellungspool zu importieren. Wenn die VMs im Wiederherstellungspool ausgeführt werden, werden auch die Metadaten des Wiederherstellungspool 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 sich Informationen für dieselbe VM an mehreren Stellen befinden. Zum Beispiel Speicher vom primären Standort, Speicher vom Disaster Recovery-Standort 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 Disaster Recovery-Funktion kann mit XenCenter und der xe CLI verwendet werden. CLI-Befehle finden Sie unter Disaster Recovery-Befehle.
Tipp:
Sie können die Disaster Recovery-Einstellungen auch verwenden, um Testfailover für unterbrechungsfreie Tests Ihres Disaster Recovery-Systems durchzuführen. Bei einem Test-Failover sind alle Schritte identisch mit einem Failover. Die VMs und vApps werden jedoch nicht gestartet, nachdem sie auf der Disaster Recovery-Site wiederhergestellt wurden. Wenn der Test abgeschlossen ist, wird eine Bereinigung durchgeführt, um alle virtuellen Maschinen, vApps und Speicher zu löschen, die auf der DR-Site neu erstellt wurden.
XenServer-VMs bestehen aus zwei Komponenten:
-
Virtuelle Laufwerke, die von der VM verwendet werden, die in konfigurierten Speicherrepositories (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 nur aktualisiert, wenn Sie die VM-Konfiguration ändern. Für VMs in einem Pool wird eine Kopie dieser Metadaten auf jedem Host im Pool gespeichert.
In einer DR-Umgebung werden VMs auf einem sekundären Standort mithilfe der Poolmetadaten und Konfigurationsinformationen zu allen VMs und vApps im Pool neu erstellt. Die Metadaten für jede VM enthalten ihren Namen, ihre Beschreibung und den Universal Unique Identifier (UUID) sowie ihren Speicher, ihre virtuelle CPU sowie die Netzwerk- und Speicherkonfiguration. Es umfasst auch VM-Startoptionen — Startreihenfolge, Verzögerungsintervall, Hochverfügbarkeit und Neustartpriorität. Die VM-Startoptionen 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 in den VM-Metadaten angegebenen Reihenfolge und unter Verwendung der angegebenen Verzögerungsintervalle im DR-Pool neu gestartet.
Anforderungen an die DR-Infrastruktur
Richten Sie die entsprechende DR-Infrastruktur sowohl am primären als auch am sekundären Standort ein, um XenServer DR zu verwenden.
-
Der für Poolmetadaten verwendete Speicher und die von den VMs verwendeten virtuellen Laufwerke müssen von der primären (Produktions-) Umgebung in eine Backupumgebung repliziert werden. Die Speicherreplikation wie die Verwendung der Spiegelung variiert je nach Gerät. Wenden Sie sich daher an Ihren Anbieter von Speicherlösungen, um die Speicherreplikation zu
-
Nachdem die VMs und vApps, die Sie in einem Pool auf Ihrer DR-Site wiederhergestellt haben, betriebsbereit sind, müssen die SRs, die die DR-Poolmetadaten und virtuellen Datenträger enthalten, repliziert werden. 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 Hardware-Infrastruktur an Ihrem DR-Standort muss nicht mit dem primären Standort übereinstimmen. Die XenServer-Umgebung muss sich jedoch auf derselben Version- und Patch-Ebene befinden.
-
Die Hosts und Pools am sekundären Standort müssen dieselbe Lizenzedition wie die am primären Standort haben. Diese XenServer-Lizenzen gelten zusätzlich zu denen, die Hosts am primären Standort zugewiesen wurden.
-
Im Zielpool müssen ausreichende Ressourcen konfiguriert werden, damit alle Failover-VMs neu erstellt und gestartet werden können.
Warnung:
Die Disaster Recovery-Einstellungen steuern keine Storage-Array-Funktionen.
Benutzer der Disaster Recovery-Funktion müssen sicherstellen, dass der Metadatenspeicher auf irgendeine 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 die Spiegelfunktion deaktivieren (“Spiegelung ist defekt”), bevor Sie VMs auf der Wiederherstellungs-Site neu starten.
Überlegungen zur Bereitstellung
Lesen Sie die folgenden Schritte, bevor Sie Disaster Recovery aktivieren.
Schritte vor einer Katastrophe
Im folgenden Abschnitt werden die Schritte beschrieben, die vor einer Katastrophe zu ergreifen sind.
-
Konfigurieren Sie Ihre virtuellen Maschinen und vApps.
-
Beachten Sie, wie Ihre VMs und vApps SRs und SRs LUNs zugeordnet werden. Achten Sie besonders auf die Benennung der Parameter
name_labelundname_description. Das Wiederherstellen von VMs und vApps aus repliziertem Speicher ist einfacher, wenn die Namen der SRs erfassen, wie VMs und vApps SRs und SRs LUNs zugeordnet werden. -
Vereinbaren Sie die Replikation der LUNs.
-
Aktivieren Sie die Replikation der Poolmetadaten auf eine oder mehrere SRs auf diesen LUNs.
-
Stellen Sie sicher, dass die SRs, für die Sie die primären Poolmetadaten replizieren, nur an einen Pool angehängt sind.
Schritte, die nach einer Katastrophe zu unternehmen sind
Im folgenden Abschnitt werden die Schritte beschrieben, die nach einer Katastrophe zu ergreifen sind.
-
Brechen Sie alle vorhandenen Speicherspiegel auf, sodass die Wiederherstellungs-Site Lese-/Schreibzugriff auf den freigegebenen Speicher hat.
-
Stellen Sie sicher, dass die LUNs, aus denen Sie VM-Daten wiederherstellen möchten, nicht an einen anderen Pool angehängt sind, da sonst eine Beschädigung auftreten kann.
-
Wenn Sie die Wiederherstellungs-Site vor einem Notfall schützen möchten, müssen Sie die Poolmetadatenreplikation auf eine oder mehrere SRs auf der Wiederherstellungs-Site aktivieren.
Schritte nach einer Erholung
Im folgenden Abschnitt werden die Schritte beschrieben, die nach einer erfolgreichen Datenwiederherstellung ausgeführt werden müssen.
-
Synchronisieren Sie alle Speicherspiegel neu.
-
Fahren Sie auf der Wiederherstellungs-Site die VMs oder vApps, die Sie zurück zur primären Site verschieben möchten, sauber herunter.
-
Gehen Sie auf dem primären Standort genauso vor wie beim Failover im vorherigen Abschnitt, um ausgewählte VMs oder vApps auf den primären Standort zurückzusenden
-
Um den primären Standort vor zukünftigen Katastrophen zu schützen, müssen Sie die Replikation der Poolmetadaten auf eine oder mehrere SRs auf den replizierten LUNs erneut aktivieren.