Info zu XenServer DR

Mit der XenServer Disaster Recovery (DR) können Sie virtuelle Maschinen (VMs) und vApps nach einem katastrophalen Hardwarefehler wiederherstellen, der einen ganzen Pool oder eine Site deaktiviert oder zerstört. Zum Schutz vor Ausfällen einzelner Server könnenXenServer HochverfügbarkeitSie VMs auf einem alternativen Server im selben Pool neu starten lassen.

Grundlegendes zu XenServer DR

XenServer DR speichert alle Informationen, die für die Wiederherstellung Ihrer geschäftskritischen VMs und vApps in Speicher-Repositories (SRs) benötigt werden, die anschließend aus Ihrer primären (Produktions-) Umgebung in eine Backup-Umgebung repliziert werden. Wenn ein geschützter Pool am primären Standort ausfällt, können die VMs und vApps in diesem Pool aus dem replizierten Speicher wiederhergestellt und auf einem sekundären Standort (DR) mit minimalen Ausfallzeiten für Anwendungen oder Benutzer neu erstellt werden.

Sobald die wiederhergestellten VMs im DR-Pool ausgeführt werden und ausgeführt werden, müssen die Metadaten des DR-Pools auch auf dem replizierten Speicher gespeichert werden, sodass wiederhergestellte VMs und vApps wieder auf dem primären Standort wiederhergestellt werden können, wenn sie wieder online sind.

Hinweis: XenServer DR kann nur mit LVM over HBA oder LVM über iSCSI-Speichertypen verwendet werden.

XenServer-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. Dies sind alle Informationen, die benötigt werden, 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 Änderungen an der VM-Konfiguration vornehmen. 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 neu erstellt - Konfigurationsinformationen zu allen VMs und vApps im Pool. 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 enthält auch die Startoptionen der VM - Startreihenfolge, Verzögerungsintervall und HA-Neustartpriorität - , die beim Neustart der VM in einer HA- oder DR-Umgebung verwendet werden. Wenn beispielsweise VMs während der Notfallwiederherstellung wiederhergestellt werden, werden die VMs in einer vApp in der Reihenfolge, die in den VM-Metadaten angegeben ist, und in den angegebenen Verzögerungsintervallen neu gestartet.

Anforderungen für XenServer DR

   
Softwareversion XenServer Version 6.0 oder höher
Zugang Sie müssen als root angemeldet sein oder eine Rolle von Pool Operator oder höher haben.

Infrastruktur für Notfallwiederherstellung

Um die XenServer-DR verwenden zu können, muss die entsprechende Wiederherstellungsinfrastruktur sowohl am primären als auch am sekundären Standort eingerichtet werden:

  • Der Speicher, der sowohl für die Pool-Metadaten als auch für die von den VMs verwendeten virtuellen Laufwerke verwendet wird, muss von Ihrer primären (Produktions-) Umgebung in eine Backup-Umgebung repliziert werden. Die Speicherreplikation, beispielsweise mithilfe von Spiegelungen, wird am besten von Ihrer Speicherlösung abgewickelt und variiert von Gerät zu Gerät.
  • Nachdem VMs und vApps in einem Pool auf Ihrer DR-Site wiederhergestellt und ausgeführt wurden, müssen die SRs, die die Metadaten des DR-Pools und die virtuellen Laufwerke enthalten, ebenfalls repliziert werden, damit die wiederhergestellten VMs und vApps wieder am primären Standort wiederhergestellt werden können (Failback), sobald der primäre Standort wieder online ist.
  • Die Hardwareinfrastruktur am Standort der Notfallwiederherstellung muss nicht mit dem primären Standort übereinstimmen, aber die XenServer-Umgebung muss auf derselben Release- und Patch-Ebene liegen. Im Zielpool sollten ausreichende Ressourcen konfiguriert werden, damit alle Failover-VMs neu erstellt und gestartet werden können.

Wichtig: XenCenter und der Disaster Recovery Wizard steuern keine Speicher-Array-Funktionen. Benutzer der Disaster Recovery-Funktion müssen sicherstellen, dass die Pool-Metadaten und der Speicher, der von den VMs verwendet wird, die im Falle eines Notfalls neu gestartet werden sollen, auf einen Sicherungsstandort repliziert werden. Einige Speicher-Arrays enthalten Spiegelungsfunktionen, um die Kopie automatisch zu erreichen: Wenn diese Features verwendet werden, ist es wichtig, dass die Spiegelfunktion deaktiviert ist (die Spiegelung ist kaputt), bevor VMs auf der Wiederherstellungs-Site neu gestartet werden.

Failover, Failback und Test-Failover mit dem Assistenten für die Notfallwiederherstellung

Der Disaster Recovery Wizard vereinfacht Failover (Wiederherstellung geschützter VMs und vApps auf einem sekundären Standort) und Failback (Wiederherstellung von VMs und vApps zurück zum primären Standort). Die Schritte, die in den beiden Prozessen involviert sind, werden hier beschrieben:

Failover

  1. Zuerst wählen Sie einen Zielpool auf der sekundären Notfallwiederherstellungs-Site aus, in dem Sie Ihre VMs und vApps wiederherstellen möchten.
  2. Als Nächstes geben Sie Details zu den Speicherzielen an, die die replizierten SRs vom primären Standort enthalten.
  3. Der Assistent scannt die Ziele und listet alle dort gefundenen SRs auf.

    Jetzt wählen Sie die SRs aus, die die Metadaten und virtuellen Laufwerke für die VMs und vApps enthalten, die Sie wiederherstellen möchten.

  4. Der Assistent scannt die SRs und listet alle gefundenen VMs und vApps auf.

    Nun wählen Sie aus, welche VMs und vApps Sie auf der Notfall-Site wiederherstellen möchten, und geben an, ob der Assistent sie automatisch starten soll, sobald sie wiederhergestellt wurden, oder ob Sie es vorziehen, selbst zu warten und manuell zu starten.

  5. Der Assistent führt dann eine Reihe von Vorprüfungen durch, um sicherzustellen, dass die ausgewählten VMs und vApps im Ziel-DR-Pool wiederhergestellt werden können. So wird beispielsweise überprüft, ob der gesamte für die ausgewählten VMs und vApps erforderliche Speicher verfügbar ist.
  6. Wenn die Vorabprüfungen abgeschlossen sind und alle Probleme behoben sind, beginnt der Failoverprozess. Die ausgewählten VMs und vApps werden aus dem replizierten Speicher in den DR-Pool exportiert.

    Failover ist jetzt abgeschlossen.

Failback

  1. Zuerst 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.
  2. Als Nächstes geben Sie Details zu den Speicherzielen an, die die replizierten SRs von Ihrer Notfall-Site enthalten.
  3. Der Assistent scannt die Ziele und listet alle gefundenen SRs auf.

    Jetzt wählen Sie die SRs aus, die die Metadaten und virtuellen Laufwerke für die VMs und vApps enthalten, die Sie wiederherstellen möchten.

  4. Der Assistent scannt die SRs und listet alle gefundenen VMs und vApps auf.

    Nun wählen Sie aus, welche VMs und vApps Sie auf dem primären Standort wiederherstellen möchten, und geben an, ob der Assistent sie automatisch starten soll, sobald sie wiederhergestellt wurden, oder ob Sie es vorziehen, selbst zu warten und manuell zu starten.

  5. Der Assistent führt dann eine Reihe von Vorprüfungen durch, um sicherzustellen, dass die ausgewählten VMs und vApps im Zielpool am primären Standort wiederhergestellt werden können. So wird beispielsweise überprüft, ob der gesamte für die ausgewählten VMs und vApps erforderliche Speicher verfügbar ist.
  6. Wenn die Vorabprü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 am primären Standort exportiert.

    Failback ist jetzt abgeschlossen.

Wenn der Assistent für die Notfallwiederherstellung Informationen für dieselbe VM findet, die an zwei oder mehr Stellen vorhanden sind (z. B. Speicher vom primären Standort, Speicher vom Notfall-Standort und auch im Pool, in den die Daten importiert werden sollen), stellt er sicher, dass nur die neuesten Informationen pro VM verwendet.

Tipp: Das Wiederherstellen von VMs und vApps aus repliziertem Speicher ist einfacher, wenn Ihre SRs so benannt sind, dass erfasst wird, wie Ihre VMs und vApps SRs und die SRs LUNs zugeordnet werden.

Sie können auch den Assistenten für die Notfallwiederherstellung verwenden, um Test-Failover für unterbrechungsfreie Tests Ihres Disaster Recovery-Systems auszuführen. In einem Test-Failover sind alle Schritte identisch mit dem Failover, aber die VMs und vApps werden in einem angehaltenen Zustand gestartet, nachdem sie auf der DR-Site wiederhergestellt wurden. Nach Abschluss des Tests wird die Bereinigung durchgeführt, um alle VMs, vApps und Speicher zu entfernen, die auf der DR-Site neu erstellt wurden. Siehst duTest-Failover.

XenServer DR-Terminologie

vApp
Eine logische Gruppe verwandter VMs, die als einzelne Entität verwaltet werden.
Site
Eine physische Gruppe von XenServer-Ressourcenpools, Speicher- und Hardwarekomponenten.
Primärer Standort
Ein physischer Standort, auf dem VMs oder vApps ausgeführt werden, der im Notfall geschützt werden muss.
Sekundärer Standort, Notfallstandort
Ein physischer Standort, dessen Zweck es ist, im Falle eines Notfalls als Wiederherstellungsort für den primären Standort zu dienen.
Failover
Wiederherstellung von VMs und vApps auf einem sekundären (Wiederherstellungs-) Standort im Falle eines Notfalls am primären Standort.
Failback
Wiederherstellung von VMs und vApps auf dem primären Standort von einem sekundären (Wiederherstellungs-) Standort.
Test-Failover
Ein „Trockenlauf“ -Failover, bei dem VMs und vApps vom replizierten Speicher in einen Pool auf einem sekundären (Wiederherstellungs-) Standort wiederhergestellt werden, aber nicht tatsächlich gestartet werden. Test-Failover können ausgeführt werden, um zu überprüfen, ob DR korrekt konfiguriert ist und ob Ihre Prozesse wirksam sind.
Pool-Metadaten
Informationen zu den VMs und vApps im Pool, wie Name und Beschreibung, und für VMs Konfigurationsinformationen wie UUID, Arbeitsspeicher, virtuelle CPU, Netzwerk- und Speicherkonfiguration sowie Startoptionen - Startreihenfolge, Verzögerungsintervall und HA-Neustartpriorität. Poolmetadaten werden in der DR verwendet, um die VMs und vApps vom primären Standort in einem Wiederherstellungspool am sekundären Standort neu zu erstellen.