Notfallwiederherstellung und Sicherung
Die XenServer Disaster Recovery (DR)-Funktion ermöglicht es Ihnen, virtuelle Maschinen (VMs) und vApps nach einem Hardwarefehler, der einen ganzen Pool oder Standort zerstört, wiederherzustellen. Informationen zum Schutz vor einzelnen Host-Ausfällen finden Sie unter Hochverfügbarkeit.
Hinweis:
Sie müssen mit Ihrem root-Konto angemeldet sein oder die Rolle des Pool-Operators oder höher innehaben, um die DR-Funktion nutzen zu können.
XenServer® DR verstehen
Hinweis:
DR ist der geeignete Resilienzmechanismus, wenn Ihre Standorte geografisch verteilt sind. Wenn Ihre Rechenzentren mit weniger als 5 ms Round-Trip-Latenz und mindestens 10 Gbit/s Netzwerkdurchsatz verbunden sind – was der Definition der räumlichen Nähe entspricht – können sie als ein einziger Ressourcenpool betrieben werden, ohne dass DR erforderlich ist. Ein gemeinsam genutzter Pool bietet jedoch allein keine Resilienz gegen einen vollständigen Rechenzentrumsausfall. Ob DR ebenfalls erforderlich ist, hängt von Ihrer Pool-Topologie, Speicherkonfiguration und Ihren Wiederherstellungszielen ab.
XenServer DR funktioniert, indem alle Informationen, die zur Wiederherstellung Ihrer geschäftskritischen VMs und vApps erforderlich sind, auf Speicher-Repositories (SRs) gespeichert werden. Die SRs 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 Sie die VMs und vApps in diesem Pool aus dem replizierten Speicher wiederherstellen, der an einem sekundären (DR-)Standort mit minimaler Anwendungs- oder Benutzer-Ausfallzeit neu erstellt wurde.
Die Einstellungen für die Notfallwiederherstellung in XenCenter® 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. Die Replikation der Pool-Metadaten ermöglicht es, dass Änderungen an den VM-Einstellungen in den primären Pool zurückgespielt werden, wenn der primäre Pool wiederhergestellt wird. Manchmal können Informationen für dieselbe VM an mehreren Stellen vorhanden sein. Zum 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, stellt es sicher, dass nur die aktuellsten Informationen verwendet werden.
Die Funktion zur Notfallwiederherstellung kann mit XenCenter und der xe-CLI verwendet werden. CLI-Befehle finden Sie unter Befehle zur Notfallwiederherstellung.
Tipp:
Sie können die Einstellungen für die Notfallwiederherstellung auch verwenden, um Test-Failovers für eine unterbrechungsfreie Prüfung Ihres Notfallwiederherstellungssystems durchzuführen. Bei einem Test-Failover sind alle Schritte dieselben wie bei einem Failover. Die VMs und vApps werden jedoch nicht gestartet, nachdem sie am Notfallwiederherstellungsstandort wiederhergestellt wurden. Nach Abschluss des Tests wird eine Bereinigung durchgeführt, um alle VMs, vApps und den am DR-Standort neu erstellten Speicher zu löschen.
XenServer-VMs bestehen aus zwei Komponenten:
-
Virtuelle Festplatten, die von der VM verwendet werden und auf konfigurierten Speicher-Repositories (SRs) im Pool, in dem sich die VMs befinden, gespeichert sind.
-
Metadaten, die die VM-Umgebung beschreiben. Diese Informationen sind erforderlich, um die VM neu zu erstellen, falls 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. 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 unter Verwendung der Pool-Metadaten und Konfigurationsinformationen über alle VMs und vApps im Pool neu erstellt. Die Metadaten für jede VM umfassen ihren Namen, ihre Beschreibung und ihre universelle eindeutige Kennung (UUID) sowie ihre Speicher-, virtuellen CPU- und Netzwerk- und Speicherkonfiguration. Sie umfassen auch die VM-Startoptionen – Startreihenfolge, Verzögerungsintervall, Hochverfügbarkeit und Neustartpriorität. Die VM-Startoptionen 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 im DR-Pool in der in den VM-Metadaten angegebenen Reihenfolge und unter Verwendung der angegebenen Verzögerungsintervalle 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 Pool-Metadaten und die von den VMs verwendeten virtuellen Festplatten genutzte Speicher muss von der primären (Produktions-)Umgebung in eine Backup-Umgebung repliziert werden. Die Speicherreplikation, z. B. durch Spiegelung, variiert je nach Gerät. Wenden Sie sich daher an Ihren Anbieter der Speicherlösung, um die Speicherreplikation zu handhaben.
-
Nachdem die VMs und vApps, die Sie auf einem Pool an Ihrem DR-Standort wiederhergestellt haben, betriebsbereit sind, müssen die SRs, die die DR-Pool-Metadaten und virtuellen Festplatten enthalten, repliziert werden. Die Replikation ermöglicht es, die wiederhergestellten VMs und vApps auf den primären Standort zurückzuspielen (zurückgesetzt), wenn der primäre Standort wieder online ist.
-
Die Hardware-Infrastruktur an Ihrem DR-Standort muss nicht mit der des primären Standorts übereinstimmen. Die XenServer-Umgebung muss jedoch denselben Release- und Patch-Level aufweisen.
-
Die Hosts und Pools am sekundären Standort müssen dieselbe Lizenzedition wie die am primären Standort haben. Diese XenServer-Lizenzen sind zusätzlich zu denen, die den Hosts am primären Standort zugewiesen sind.
-
Im Zielpool müssen ausreichend Ressourcen konfiguriert sein, damit alle ausgefallenen VMs neu erstellt und gestartet werden können.
Warnung:
Die Einstellungen für die Notfallwiederherstellung steuern keine Funktionalität des Speicher-Arrays.
Benutzer der Notfallwiederherstellungsfunktion müssen sicherstellen, dass der Metadaten-Speicher in irgendeiner Weise zwischen den beiden Standorten repliziert wird. Einige Speicher-Arrays enthalten „Spiegelungs“-Funktionen, um die Replikation automatisch zu erreichen. Wenn Sie diese Funktionen verwenden, müssen Sie die Spiegelungsfunktion („Spiegelung ist unterbrochen“) deaktivieren, bevor Sie VMs am Wiederherstellungsstandort neu starten.
Überlegungen zur Bereitstellung
Überprüfen Sie die folgenden Schritte, bevor Sie die Notfallwiederherstellung aktivieren.
Schritte, die vor einer Katastrophe zu unternehmen sind
Der folgende Abschnitt beschreibt die Schritte, die vor einer Katastrophe zu unternehmen sind.
-
Konfigurieren Sie Ihre VMs und vApps.
-
Beachten Sie, wie Ihre VMs und vApps SRs zugeordnet sind und die SRs LUNs zugeordnet sind. Achten Sie besonders auf die Benennung der Parameter
name_labelundname_description. Die Wiederherstellung von VMs und vApps aus repliziertem Speicher ist einfacher, wenn die Namen der SRs erfassen, wie VMs und vApps SRs zugeordnet sind und SRs LUNs zugeordnet sind. -
Organisieren Sie die Replikation der LUNs.
-
Aktivieren Sie die Replikation von Pool-Metadaten auf einen oder mehrere SRs auf diesen LUNs.
-
Stellen Sie sicher, dass die SRs, auf die Sie die primären Pool-Metadaten replizieren, nur an einen Pool angehängt sind.
Schritte nach einem Notfall
Der folgende Abschnitt beschreibt die Schritte, die nach einem Notfall zu unternehmen sind.
-
Brechen Sie alle vorhandenen Speicherspiegelungen auf, damit der Wiederherstellungsstandort Lese-/Schreibzugriff auf den freigegebenen Speicher hat.
-
Stellen Sie sicher, dass die LUNs, von denen Sie VM-Daten wiederherstellen möchten, nicht an einen anderen Pool angehängt sind, da sonst Datenbeschädigungen auftreten können.
-
Wenn Sie den Wiederherstellungsstandort vor einem Notfall schützen möchten, müssen Sie die Replikation von Pool-Metadaten auf einen oder mehrere SRs am Wiederherstellungsstandort aktivieren.
Schritte nach einer Wiederherstellung
Der folgende Abschnitt beschreibt die Schritte, die nach einer erfolgreichen Datenwiederherstellung zu unternehmen sind.
-
Synchronisieren Sie alle Speicherspiegelungen erneut.
-
Fahren Sie am Wiederherstellungsstandort 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 für das Failover im vorherigen Abschnitt aus, um ausgewählte VMs oder vApps auf den primären Standort zurückzuführen.
-
Um den primären Standort vor zukünftigen Katastrophen zu schützen, müssen Sie die Pool-Metadaten-Replikation auf einen oder mehrere SRs auf den replizierten LUNs wieder aktivieren.