Notfallwiederherstellung (DR)
Mit der Disaster Recovery-Funktion (Disaster Recovery, DR) können Sie VMs und vApps nach einem katastrophalen Hardwareausfall wiederherstellen, der einen gesamten Pool oder eine Site deaktiviert oder zerstört.
Zum Schutz vor Ausfällen einzelner Server können Sie Hohe Verfügbarkeit. Bei der Hochverfügbarkeit werden VMs auf einem alternativen Server im selben Pool neu gestartet.
DR verstehen
Bei der Notfallwiederherstellung werden alle Informationen, die für die Wiederherstellung Ihrer geschäftskritischen VMs und vApps erforderlich sind, in Speicher-Repositories (SRs) gespeichert. Diese Speicher-Repositories werden dann von Ihrer primären (Produktions-)Umgebung in eine Backup-Umgebung repliziert. Wenn ein geschützter Pool an Ihrer primären Site ausfällt, können die VMs und vApps in diesem Pool aus dem replizierten Speicher wiederhergestellt und auf einer sekundären Site (DR) neu erstellt werden. Das Ergebnis sind minimale Ausfallzeiten für Anwendungen oder Benutzer.
Nachdem die wiederhergestellten VMs im DR-Pool ausgeführt wurden, müssen die Metadaten des DR-Pools auch auf dem replizierten Speicher gespeichert werden. Mit dieser Aktion können wiederhergestellte VMs und vApps auf der primären Site wiederhergestellt werden, wenn diese 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 Datenträger, die von der VM verwendet werden und in konfigurierten Speicherrepositorys (SRs) in dem 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 geschrieben, wenn die VM erstellt wird, und werden 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 Site (DR) aus den Poolmetadaten neu erstellt, d. h. aus Konfigurationsinformationen zu allen VMs und vApps im Pool. Zu den Metadaten für jede VM gehören der Name, die Beschreibung und die UUID (Universal Unique Identifier) sowie der Arbeitsspeicher, die virtuelle CPU, das Netzwerk und die Speicherkonfiguration. Sie 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. Bei der Wiederherstellung von VMs werden beispielsweise die VMs innerhalb einer vApp im DR-Pool in der Reihenfolge und mit den in den Metadaten angegebenen Verzögerungsintervallen neu gestartet.
Hinweis:
Um die Notfallwiederherstellung verwenden zu können, müssen Sie als root angemeldet sein oder die Rolle Pool-Operator oder höher haben.
Terminologie der Notfallwiederherstellung
vApp: Eine logische Gruppe zusammengehöriger VMs, die als eine Einheit verwaltet werden.
Platz: Eine physische Gruppe von XenServer-Ressourcenpools, Speicher und Hardwaregeräten.
Primärer Standort: Eine physische Site, auf der VMs oder vApps ausgeführt werden, die im Katastrophenfall geschützt werden müssen.
Sekundärer Standort, DR-Standort: Ein physischer Standort, dessen Zweck es ist, im Falle eines Notfalls als Wiederherstellungsort für den primären Standort zu dienen.
Ausfall: Wiederherstellung von VMs und vApps auf einer sekundären (Wiederherstellungs-)Site im Falle einer Katastrophe an der primären Site.
Ausfall: Wiederherstellung von VMs und vApps von einer sekundären (Wiederherstellungs-)Site auf der primären Site.
Testen des Failovers: Ein “Probelauf”-Failover, bei dem VMs und vApps aus repliziertem Speicher in einem Pool auf einer sekundären (Wiederherstellungs-)Site wiederhergestellt, aber nicht gestartet werden. Testfailover können ausgeführt werden, um zu überprüfen, ob die Notfallwiederherstellung ordnungsgemäß konfiguriert ist und ob Ihre Prozesse effektiv sind.
Pool-Metadaten: Informationen zu den VMs und vApps im Pool, z. B. Name und Beschreibung. Für VMs umfassen die Konfigurationsinformationen UUID, Arbeitsspeicher, virtuelle CPU, Netzwerk- und Speicherkonfiguration sowie Startoptionen. Pool-Metadaten werden in der DR verwendet, um die VMs und vApps von der primären Site in einem Wiederherstellungspool auf der sekundären Site neu zu erstellen.
Infrastruktur für die Notfallwiederherstellung
Um die Notfallwiederherstellung 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 von den VMs verwendeten virtuellen Datenträger verwendet wird, muss aus Ihrer primären (Produktions-)Umgebung in eine Sicherungsumgebung repliziert werden. Die Speicherreplikation, z. B. mithilfe von Spiegelung, ist von Gerät zu Gerät unterschiedlich. Es wird empfohlen, Ihre Speicherlösung für die Speicherreplikation zu verwenden.
- Nachdem wiederhergestellte VMs und vApps in einem Pool auf Ihrer DR-Site ausgeführt wurden, replizieren Sie die SRs, die die Metadaten des DR-Pools und die virtuellen Festplatten enthalten. Mit dieser Aktion können die wiederhergestellten VMs und vApps auf der primären Site wiederhergestellt werden (Failback), sobald die primäre Site wieder online ist.
- Die Hardwareinfrastruktur an Ihrem DR-Standort muss nicht mit der primären Site übereinstimmen. Die XenServer-Umgebung muss sich jedoch auf demselben Release- und Patch-Level befinden. Außerdem müssen im Zielpool ausreichend Ressourcen konfiguriert werden, damit alle VMs, für die ein Failover ausgeführt wurde, neu erstellt und gestartet werden können.
Wichtig:
XenCenter und die Notfallwiederherstellung Wizard steuert keine Speicher-Array-Funktionalität. Stellen Sie sicher, dass die Pool-Metadaten und der Speicher, der von den VMs verwendet wird, die im Falle eines Notfalls neu gestartet werden sollen, an einen Sicherungsstandort repliziert werden. Einige Speicher-Arrays enthalten Spiegelungsfunktionen, um den Kopiervorgang automatisch durchzuführen. Wenn diese Funktionen verwendet werden, deaktivieren Sie die Spiegelungsfunktion, bevor VMs auf der Wiederherstellungs-Site neu gestartet werden.
Failover, Failback und Testfailover mit dem Notfallwiederherstellung Zauberer
Das Notfallwiederherstellung Der Assistent vereinfacht Failover und Failback. Die Schritte, die in diesen Prozessen ablaufen, werden hier beschrieben:
Ausfall
-
Wählen Sie einen Zielpool auf Ihrer sekundären DR-Site 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 aus, die die Metadaten und virtuellen Festplatten für die VMs und vApps enthalten, 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 warten und sie selbst 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. Der Assistent überprüft beispielsweise, ob der gesamte von den ausgewählten VMs und vApps benötigte Speicher verfügbar ist.
Wenn die Vorabüberprü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.
Ausfall
-
Wählen Sie den Zielpool auf Ihrer primären Site aus, in dem Sie die VMs und vApps wiederherstellen möchten, die derzeit auf der DR-Site ausgeführt werden.
-
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 aus, die die Metadaten und virtuellen Festplatten für die VMs und vApps enthalten, 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 warten und sie selbst 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. Der Assistent überprüft beispielsweise, ob der gesamte von den ausgewählten VMs und vApps benötigte Speicher verfügbar ist.
Wenn die Vorabüberprüfungen abgeschlossen sind und alle Probleme behoben sind, beginnt der Failback-Prozess. Die ausgewählten VMs und vApps, die auf Ihrer DR-Site ausgeführt werden, werden aus dem replizierten Speicher zurück in den ausgewählten Pool an Ihrer primären Site exportiert.
Das Failback ist nun abgeschlossen.
Wenn die Option Notfallwiederherstellung Der Assistent findet Informationen für dieselbe VM an zwei oder mehr Stellen, wobei nur die neuesten Informationen pro VM verwendet werden. Die Informationen können z. B. im primären Standortspeicher, im Speicher des DR-Standorts und in dem 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 auch die Funktion Notfallwiederherstellung Assistent zum Ausführen von Test-Failovers für unterbrechungsfreie Tests Ihres Disaster-Recovery-Systems. Bei einem Test-Failover sind die Schritte die gleichen wie bei einem Failover, aber wiederhergestellte VMs und vApps werden in einem angehaltenen Zustand auf der DR-Site 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.