Disaster Recovery und Backup
Wichtig:
Citrix Hypervisor 8.2 Kumulatives Update 1 wird am 25. Juni 2025 End of Life. Planen Sie jetzt Ihr Upgrade auf XenServer 8, um einen reibungslosen Übergang und kontinuierlichen Support zu gewährleisten. Weitere Informationen finden Sie unter Upgrade.
Wenn Sie Ihre Citrix Virtual Apps and Desktops-Lizenzdateien verwenden, um Ihre Citrix Hypervisor 8.2 Cumulative Update 1-Hosts zu lizenzieren, sind diese Lizenzdateien nicht mit XenServer 8 kompatibel. Vor dem Upgrade müssen Sie XenServer Premium Edition-Socket-Lizenzdateien für die Verwendung mit XenServer 8 erwerben. Diese Socket-Lizenzdateien sind als Berechtigung für die Abonnements Citrix für Private Cloud, Citrix Universal Hybrid Multi-Cloud, Citrix Universal MSP und Citrix Platform License für die Ausführung Ihrer Citrix-Workloads verfügbar. Citrix-Kunden, die noch nicht auf diese neuen Abonnements umgestiegen sind, können die Teilnahme an einer kostenlosen Aktion für 10.000 XenServer Premium Edition-Socket-Lizenzen anfordern. Weitere Informationen finden Sie unter XenServer (Englisch).
Wenn Sie vor dem Upgrade keine kompatible Lizenz für XenServer 8 erhalten, werden Ihre Hosts beim Upgrade auf die 90-Tage-Testversion zurückgesetzt. Die Testversion bietet die gleichen Funktionen wie die Premium Edition, jedoch mit einigen Einschränkungen. Weitere Informationen finden Sie unter Übersicht über die XenServer 8-Lizenzierung.
Mit der Citrix Hypervisor Disaster Recovery (DR)-Funktion können Sie virtuelle Maschinen (VMs) und vApps nach einem Hardwareausfall wiederherstellen, der einen gesamten Pool oder eine Site zerstört. Informationen zum Schutz vor Ausfällen einzelner Server finden Sie unter Hohe Verfügbarkeit.
Hinweis:
Sie müssen mit Ihrem wurzel Konto oder haben die Rolle eines Pool-Betreiber oder höher, um die DR-Funktion zu verwenden.
Grundlegendes zu Citrix Hypervisor DR
Citrix Hypervisor DR speichert alle Informationen, die zum Wiederherstellen Ihrer geschäftskritischen VMs und vApps in Speicher-Repositories (SRs) erforderlich sind. Die SRs 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 Sie die VMs und vApps in diesem Pool aus dem replizierten Speicher wiederherstellen, der auf einer sekundären Site (DR) mit minimaler Ausfallzeit für Anwendungen oder Benutzer neu erstellt wurde.
Das Notfallwiederherstellung Die Einstellungen 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 Poolmetadaten ermöglicht es, dass alle Ä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 in dem 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. Informationen zu CLI-Befehlen finden Sie unter Befehle zur Notfallwiederherstellung.
Tipp:
Sie können auch die Disaster Recovery-Einstellungen verwenden, um Test-Failover für unterbrechungsfreie Tests Ihres Disaster Recovery-Systems auszuführen. Bei einem Testfailover sind alle Schritte mit denen eines Failovers identisch. Die VMs und vApps werden jedoch nicht gestartet, nachdem sie an der Disaster Recovery-Site wiederhergestellt wurden. Wenn der Test abgeschlossen ist, wird eine Bereinigung durchgeführt, um alle VMs, vApps und Speicher zu löschen, die auf der DR-Site neu erstellt wurden.
Citrix Hypervisor-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. 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 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 neu erstellt, wobei die Poolmetadaten und Konfigurationsinformationen zu allen VMs und vApps im Pool verwendet werden. 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 sowie die Netzwerk- und Speicherkonfiguration. Es enthält 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 Sie beispielsweise VMs während der Notfallwiederherstellung wiederherstellen, 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 Citrix Hypervisor DR zu verwenden.
-
Für Pool-Metadaten verwendeter Speicher und Die von den VMs verwendeten virtuellen Festplatten müssen aus der primären (Produktions-)Umgebung in eine Sicherungsumgebung repliziert werden. Die Speicherreplikation, z. B. die Verwendung von Spiegelung, variiert je nach Gerät. Wenden Sie sich daher an den Anbieter Ihrer Speicherlösung, um die Speicherreplikation durchzuführen.
-
Nachdem die VMs und vApps, die Sie in einem Pool auf Ihrer DR-Site wiederhergestellt haben, betriebsbereit sind, müssen die SRs, die die Metadaten des DR-Pools und die virtuellen Festplatten enthalten, repliziert werden. Mit der Replizierung können die wiederhergestellten VMs und vApps auf der primären Site wiederhergestellt werden. (fehlgeschlagen) wenn der primäre Standort wieder online ist.
-
Die Hardwareinfrastruktur an Ihrem DR-Standort muss nicht mit der primären Site übereinstimmen. Die Citrix Hypervisor-Umgebung muss sich jedoch auf demselben Release- und Patch-Level befinden.
-
Die Server und Pools am sekundären Standort müssen über die gleiche Lizenzedition verfügen wie die Server am primären Standort. Diese Citrix Hypervisor-Lizenzen gelten zusätzlich zu denen, die Servern am primären Standort zugewiesen sind.
Wenn Sie über eine Citrix Virtual Apps and Desktops-Berechtigung oder eine Citrix DaaS-Berechtigung verfügen, können Sie dieselbe Berechtigung sowohl für Ihre primäre als auch für Ihre sekundäre Site verwenden.
-
Im Zielpool müssen ausreichend Ressourcen konfiguriert werden, damit alle VMs, für die ein Failover ausgeführt wurde, neu erstellt und gestartet werden können.
Warnung:
Die Einstellungen für die Notfallwiederherstellung steuern keine Speicher-Array-Funktionen.
Benutzer der Notfallwiederherstellungsfunktion müssen sicherstellen, dass der Metadatenspeicher in irgendeiner Weise zwischen den beiden Standorten repliziert wird. Einige Speicher-Arrays enthalten “Spiegelungs”-Funktionen, um die Replikation automatisch durchzuführen. Wenn Sie diese Funktionen verwenden, müssen Sie die Spiegelungsfunktion deaktivieren (“Spiegel ist defekt”), bevor Sie VMs auf der Wiederherstellungs-Site neu starten.
Überlegungen zur Bereitstellung
Überprüfen Sie die folgenden Schritte, bevor Sie die Notfallwiederherstellung aktivieren.
Schritte, die vor einer Katastrophe zu unternehmen sind
Im folgenden Abschnitt werden die Schritte beschrieben, die vor einer Katastrophe ausgeführt werden müssen.
-
Konfigurieren Sie Ihre VMs und vApps.
-
Beachten Sie, wie Ihre VMs und vApps SRs und die SRs LUNs zugeordnet werden. Achten Sie besonders auf die Benennung der
name_labelundname_descriptionParameter. Die Wiederherstellung 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. -
Organisieren Sie die Replikation der LUNs.
-
Aktivieren Sie die Replikation von Poolmetadaten zu einer oder mehreren SRs auf diesen LUNs.
-
Stellen Sie sicher, dass die SRs, auf die Sie die Metadaten des primären Pools replizieren, nur an einen Pool angehängt sind.
Schritte nach einer Katastrophe
Im folgenden Abschnitt werden die Schritte beschrieben, die nach einem Notfall ausgeführt werden müssen.
-
Unterbrechen Sie alle vorhandenen Speicherspiegel, sodass die Wiederherstellungs-Site 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 es sonst zu Beschädigungen kommen kann.
-
Wenn Sie die Genesung Site nach einem Notfall müssen Sie die Replikation von Pool-Metadaten auf eine oder mehrere SRs auf der Wiederherstellungs-Site aktivieren.
Schritte, die nach einer Wiederherstellung zu unternehmen sind
Im folgenden Abschnitt werden die Schritte beschrieben, die nach einer erfolgreichen Wiederherstellung von Daten ausgeführt werden müssen.
-
Synchronisieren Sie alle Speicherspiegelungen neu.
-
Fahren Sie auf der Wiederherstellungs-Site die VMs oder vApps, die Sie zurück zur primären Site verschieben möchten, ordnungsgemäß herunter.
-
Gehen Sie auf der primären Site genauso vor wie für das Failover im vorherigen Abschnitt, um ein Failback ausgewählter VMs oder vApps auf die primäre Site durchzuführen
-
Um den primären Standort vor zukünftigen Katastrophen zu schützen, müssen Sie die Replikation von Poolmetadaten auf eine oder mehrere SRs auf den replizierten LUNs erneut aktivieren.