Disaster Recovery (DR)
Hinweis:
XenCenter yyyy.x.x wird noch nicht für die Verwendung mit Citrix Hypervisor 8.2 CU1 in Produktionsumgebungen unterstützt. Verwenden Sie XenCenter 8.2.7, um Ihre Citrix Hypervisor 8.2 CU1-Produktionsumgebung zu verwalten. Weitere Informationen finden Sie in der XenCenter 8.2.7-Dokumentation.
Sie können XenCenter 8.2.7 und XenCenter yyyy.x.x auf demselben System installieren. Die Installation von XenCenter yyyy.x.x überschreibt Ihre XenCenter 8.2.7-Installation nicht.
Mit der Disaster Recovery (DR) -Funktion können Sie VMs und vApps von einem katastrophalen Ausfall der Hardware wiederherstellen, die einen ganzen Pool oder Standort deaktiviert oder zerstört.
Zum Schutz vor Ausfällen einzelner Server können Sie Hochverfügbarkeitverwenden. Hochverfügbarkeit startet VMs auf einem alternativen Server im selben Pool neu.
DR verstehen
Bei der Notfallwiederherstellung werden alle Informationen gespeichert, die für die Wiederherstellung geschäftskritischer VMs und vApps in Speicherrepositories (SRs) erforderlich sind. Diese Speicher-Repositories 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 die VMs und vApps in diesem Pool aus dem replizierten Speicher wiederhergestellt und auf einer sekundären (DR) -Site neu erstellt werden. Das Ergebnis sind minimale Anwendungs- oder Benutzerausfälle.
Nachdem die wiederhergestellten VMs im DR-Pool eingerichtet und ausgeführt werden, müssen die DR-Pool -Metadaten auch im replizierten Speicher gespeichert werden. Mit dieser Aktion können wiederhergestellte VMs und vApps wieder am primären Standort wiederhergestellt werden, wenn dieser wieder online ist.
Hinweis:
Disaster Recovery kann nur mit den Speichertypen LVM über HBA oder LVM über iSCSI verwendet werden.
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. Die Metadaten enthalten alle Informationen, die zum erneuten Erstellen der VM erforderlich sind, wenn die ursprüngliche VM nicht verfügbar oder beschädigt ist. Die meisten Metadaten 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 auf einer sekundären (DR) -Site aus den Poolmetadaten - Konfigurationsinformationen zu allen VMs und vApps im Pool - neu erstellt. Die Metadaten für jede VM umfassen ihren Namen, ihre Beschreibung und die Universal Unique Identifier (UUID) sowie ihre Speicher-, virtuelle CPU-, Netzwerk- und Speicherkonfiguration. Es enthält auch die VM-Startoptionen, die beim Neustart der VM in einer Hochverfügbarkeits- oder DR-Umgebung verwendet werden: Startreihenfolge, Verzögerungsintervall und Neustartpriorität. Wenn Sie beispielsweise VMs wiederherstellen, werden die VMs innerhalb einer vApp im DR-Pool in der Reihenfolge und mit den in den Metadaten angegebenen Verzögerungsintervallen neu gestartet.
Hinweis:
Um Disaster Recovery verwenden zu können, müssen Sie als root angemeldet sein oder die Rolle des Pool-Operators oder höher haben.
Terminologie der Notfall-Wiederherstellung
vApp: Eine logische Gruppe verwandter VMs, die als eine Einheit verwaltet werden.
Standort: Eine physische Gruppe von XenServer-Ressourcenpools, Speicher- und Hardwareausrüstung.
Primärer Standort: Ein physischer Standort, auf dem VMs oder vApps ausgeführt werden, die im Katastrophenfall geschützt werden müssen.
Sekundärer Standort, DR-Standort: Ein physischer Standort, dessen Zweck darin besteht, im Katastrophenfall als Wiederherstellungsstandort für den primären Standort zu dienen.
Failover: Wiederherstellung von VMs und vApps auf einem sekundären (Wiederherstellungs-) Standort bei einem Notfall am primären Standort.
Failback: Wiederherstellung von VMs und vApps zurück zum primären Standort von einer sekundären (Wiederherstellungs-) Site.
Test-Failover: Ein “Dry Run” -Failover, bei dem VMs und vApps aus repliziertem Speicher in einen Pool an einem sekundären (Wiederherstellungs-) Standort wiederhergestellt, aber nicht gestartet werden. Test-Failover können ausgeführt werden, um zu überprüfen, ob DR korrekt konfiguriert ist und Ihre Prozesse effektiv sind.
Poolmetadaten: Informationen zu den VMs und vApps im Pool, z. B. deren Name und Beschreibung. Bei VMs umfassen die Konfigurationsinformationen UUID, Arbeitsspeicher, virtuelle CPU, Netzwerk- und Speicherkonfiguration sowie Startoptionen. Poolmetadaten werden in der Notfallwiederherstellung verwendet, um die VMs und vApps vom primären Standort in einem Wiederherstellungspool am sekundären Standort neu zu erstellen.
Infrastruktur für Notfall-Wiederherstellung
Um Disaster Recovery zu verwenden, richten Sie die entsprechende DR-Infrastruktur sowohl am primären als auch am sekundären Standort ein:
- Der Speicher, der sowohl für die Poolmetadaten als auch für die virtuellen Datenträger der VM verwendet wird, muss von der primären (Produktions-) Umgebung in eine Backupumgebung repliziert werden. Die Speicherreplikation, z. B. mithilfe von Spiegelung, ist von Gerät zu Gerät unterschiedlich. Wir empfehlen Ihnen, Ihre Speicherlösung für die Speicherreplikation zu verwenden.
- Nachdem wiederhergestellte VMs und vApps in einem Pool auf Ihrem DR-Standort ausgeführt wurden, replizieren Sie die SRs, die die Metadaten des DR-Pool und die virtuellen Laufwerke enthalten. Durch diese Aktion können die wiederhergestellten VMs und vApps wieder am primären Standort wiederhergestellt werden (Failback), sobald 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. Außerdem müssen ausreichende Ressourcen im Zielpool konfiguriert werden, damit alle Failover-VMs neu erstellt und gestartet werden können.
Wichtig:
XenCenter und der Disaster Recovery-Assistent steuern keine Speicher-Array-Funktionen. Stellen Sie sicher, dass die Poolmetadaten und der von den VMs verwendete Speicher, die im Notfall neu gestartet werden sollen, auf eine Backupsite repliziert werden. Einige Speicher-Arrays enthalten Spiegelungsfunktionen, um die Kopie automatisch zu erstellen. Wenn diese Funktionen verwendet werden, deaktivieren Sie die Spiegelungsfunktion, bevor VMs auf der Wiederherstellungs-Site neu gestartet werden.
Failover, Failback und Test-Failover mit dem Disaster Recovery-Assistenten
Der Disaster Recovery-Assistent vereinfacht Failover und Failback. Die Schritte, die bei diesen Prozessen erforderlich sind, werden hier beschrieben:
Failover
-
Wählen Sie einen Zielpool auf Ihrem sekundären DR-Standort aus, in dem Sie Ihre VMs und vApps wiederherstellen möchten.
-
Geben Sie Details zu den Speicherzielen an, die die replizierten SRs von Ihrem primären Standort enthalten. Der Assistent scannt die Ziele und listet alle dort gefundenen SRs auf.
-
Wählen Sie die SRs mit den Metadaten und virtuellen Laufwerken für die VMs und vApps aus, die Sie wiederherstellen möchten. Der Assistent scannt die SRs und listet alle gefundenen VMs und vApps auf.
-
Wählen Sie aus, welche VMs und vApps Sie auf der DR-Site wiederherstellen möchten. Geben Sie an, ob der Assistent sie automatisch starten soll, wenn sie wiederhergestellt wurden, oder ob Sie sie lieber selbst warten und manuell starten möchten.
Der Assistent führt Vorabprüfungen durch, um sicherzustellen, dass die ausgewählten VMs und vApps im Ziel-DR-Pool wiederhergestellt werden können. Beispielsweise überprüft der Assistent, ob der gesamte von den ausgewählten VMs und vApps benötigte Speicher verfügbar ist.
Wenn die Vorprüfungen abgeschlossen sind und alle Probleme behoben sind, beginnt der Failover-Prozess. Die ausgewählten VMs und vApps werden aus dem replizierten Speicher in den DR-Pool exportiert. Das Failover ist jetzt abgeschlossen.
Failback
-
Wählen Sie den Zielpool auf Ihrem primären Standort aus, in dem Sie die derzeit auf der DR-Site ausgeführten VMs und vApps wiederherstellen möchten.
-
Geben Sie Details zu den Speicherzielen an, die die replizierten SRs von Ihrem DR-Standort enthalten. Der Assistent scannt die Ziele und listet alle gefundenen SRs auf.
-
Wählen Sie die SRs mit den Metadaten und virtuellen Laufwerken für die VMs und vApps aus, die Sie wiederherstellen möchten. Der Assistent scannt die SRs und listet alle gefundenen VMs und vApps auf.
-
Wählen Sie aus, welche VMs und vApps Sie auf der primären Site wiederherstellen möchten. Geben Sie an, ob der Assistent sie automatisch starten soll, wenn sie wiederhergestellt wurden, oder ob Sie sie lieber selbst warten und manuell starten möchten.
Der Assistent führt dann Vorabprüfungen durch, um sicherzustellen, dass die ausgewählten VMs und vApps im Zielpool auf der primären Site wiederhergestellt werden können. Beispielsweise überprüft der Assistent, ob der gesamte von den ausgewählten VMs und vApps benötigte Speicher verfügbar ist.
Wenn die Vorprüfungen abgeschlossen sind und alle Probleme behoben sind, beginnt der Failback-Prozess. Die ausgewählten VMs und vApps, die auf Ihrem DR-Standort ausgeführt werden, werden aus dem replizierten Speicher zurück in den ausgewählten Pool an Ihrem primären Standort exportiert.
Das Failback ist jetzt abgeschlossen.
Wenn der Disaster Recovery-Assistent Informationen für dieselbe VM an zwei oder mehr Orten findet, verwendet er nur die neuesten Informationen pro VM. Die Informationen können beispielsweise im primären Standortspeicher, im DR-Standortspeicher und im Pool gespeichert werden, in den die Daten importiert werden.
Tipp:
Um die Wiederherstellung von VMs und vApps zu vereinfachen, benennen Sie Ihre SRs, um anzugeben, wie Ihre VMs und vApps SRs und die SRs LUNs zugeordnet werden.
Sie können den Disaster Recovery-Assistenten auch verwenden, um Test-Failover für unterbrechungsfreie Tests Ihres Disaster Recovery-Systems auszuführen. Bei einem Test-Failover sind die Schritte dieselben wie beim Failover, wiederhergestellte VMs und vApps werden jedoch in einem angehaltenen Zustand auf der DR-Website gestartet. Die Bereinigung wird durchgeführt, wenn der Test abgeschlossen ist, um alle VMs, vApps und Speicher zu entfernen, die auf der DR-Site neu erstellt wurden. Weitere Informationen finden Sie unter Testen des Failovers.