Maschinenausfälle bewältigen
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.
In diesem Abschnitt erfahren Sie, wie Sie nach verschiedenen Fehlerszenarien eine Wiederherstellung durchführen können. Für alle Wiederherstellungsszenarien nach einem Fehler ist die Verwendung eines oder mehrerer der Sicherungstypen erforderlich, die in Sicherungskopie.
Ausfälle von Elementen
Wenn keine Hochverfügbarkeit vorhanden ist, erkennen Master-Knoten die Fehler von Membern, indem sie regelmäßige Heartbeat-Nachrichten empfangen. Wenn 600 Sekunden lang kein Takt empfangen wurde, geht der Master davon aus, dass das Element inaktiv ist. Es gibt zwei Möglichkeiten, dieses Problem zu beheben:
-
Reparieren Sie den toten Host (z. B. durch physischen Neustart). Wenn die Verbindung zum Stab wiederhergestellt ist, markiert der Master den Stab wieder als lebendig.
-
Fahren Sie den Host herunter und weisen Sie den Master an, den Mitgliedsknoten mit dem
xe host-vergessenCLI-Befehl. Sobald das Mitglied vergessen wurde, werden alle VMs, die dort ausgeführt wurden, als offline markiert und können auf anderen Citrix Hypervisor-Servern neu gestartet werden.Es ist wichtig sicherzustellen, dass der Citrix Hypervisor-Server tatsächlich offline ist, da sonst VM-Datenbeschädigungen auftreten können.
Teilen Sie Ihren Pool nicht in mehrere Pools eines einzelnen Hosts auf, indem Sie
xe host-vergessen. Diese Aktion kann dazu führen, dass alle denselben freigegebenen Speicher zuordnen und VM-Daten beschädigt werden.
Warnung:
- Wenn Sie den vergessenen Host wieder als aktiven Host verwenden möchten, führen Sie eine Neuinstallation der Citrix Hypervisor-Software durch.
- Nicht verwenden
xe host-vergessen, wenn HA im Pool aktiviert ist. Deaktivieren Sie zuerst HA, vergessen Sie dann den Host und aktivieren Sie dann HA erneut.
Wenn ein Citrix Hypervisor-Server ausfällt, sind möglicherweise noch VMs im Ausgeführte Zustand. Wenn Sie sicher sind, dass der Citrix Hypervisor-Server des Mitglieds definitiv ausgefallen ist, verwenden Sie die xe vm-reset-powerstate CLI-Befehl zum Festlegen des Energiestatus der VMs auf gestoppt. Siehe vm-reset-powerstate für weitere Details.
Warnung:
Die falsche Verwendung dieses Befehls kann zu Datenbeschädigungen führen. Verwenden Sie diesen Befehl nur bei Bedarf.
Bevor Sie VMs auf einem anderen Citrix Hypervisor-Server starten können, müssen Sie auch die Sperren für den VM-Speicher freigeben. Jeder Datenträger in einer SR kann jeweils nur auf einem Host verwendet werden. Es ist wichtig, den Datenträger für andere Citrix Hypervisor-Server zugänglich zu machen, sobald ein Host ausgefallen ist. Führen Sie dazu das folgende Skript auf dem Poolmaster für jede SR aus, die Datenträger betroffener VMs enthält: /opt/xensource/sm/resetvdis.py host_UUID SR_UUID Meister
Sie müssen nur den dritten String (“master”) angeben, wenn der ausgefallene Host zum Zeitpunkt des Absturzes der SR-Master war. (Der SR-Master ist der Poolmaster oder ein Citrix Hypervisor-Server, der lokalen Speicher verwendet.)
Warnung:
Stellen Sie sicher, dass der Host ausgefallen ist, bevor Sie diesen Befehl ausführen. Die falsche Verwendung dieses Befehls kann zu Datenbeschädigungen führen.
Wenn Sie versuchen, eine VM auf einem anderen Citrix Hypervisor-Server zu starten, bevor Sie die resetvdis.py Skript, dann erhalten Sie die folgende Fehlermeldung: VDI <UUID> Bereits angehängtes RW.
Master-Fehler
Jedes Mitglied eines Ressourcenpools enthält alle Informationen, die erforderlich sind, um bei Bedarf die Rolle des Masters zu übernehmen. Wenn ein Master-Knoten ausfällt, tritt die folgende Abfolge von Ereignissen auf:
-
Wenn HA aktiviert ist, wird automatisch ein anderer Master gewählt.
-
Wenn HA nicht aktiviert ist, wartet jedes Mitglied auf die Rückkehr des Masters.
Wenn der Master zu diesem Zeitpunkt wieder hochgefahren wird, stellt er die Kommunikation mit seinen Mitgliedern wieder her, und der Betrieb kehrt zum Normalzustand zurück.
Wenn der Master tot ist, wählen Sie eines der Mitglieder aus und führen Sie den Befehl xe pool-notfall-übergang-zu-master darauf. Sobald es zum Master geworden ist, führen Sie den Befehl xe pool-recover-slaves Und die Mitglieder zeigen nun auf den neuen Meister.
Wenn Sie den Server reparieren oder ersetzen, der der ursprüngliche Master war, können Sie ihn einfach hochfahren, die Citrix Hypervisor-Software installieren und dem Pool hinzufügen. Da die Homogenität der Citrix Hypervisor-Server im Pool erzwungen wird, besteht keine wirkliche Notwendigkeit, den ersetzten Server zum Master zu machen.
Wenn ein Citrix Hypervisor-Mitgliedsserver in einen Master umgewandelt wird, überprüfen Sie, ob das standardmäßige Poolspeicher-Repository auf einen entsprechenden Wert festgelegt ist. Diese Prüfung kann mit der Funktion xe pool-param-liste und überprüfen, ob die Vorgabe-SR auf ein gültiges Speicherrepository verweist.
Pool-Ausfälle
In dem unglücklichen Fall, dass Ihr gesamter Ressourcenpool ausfällt, müssen Sie die Pooldatenbank von Grund auf neu erstellen. Stellen Sie sicher, dass Sie Ihre Pool-Metadaten regelmäßig mit dem xe pool-dump-datenbank CLI-Befehl (siehe pool-dump-datenbank).
So stellen Sie einen vollständig fehlgeschlagenen Pool wieder her:
-
Installieren Sie einen neuen Satz von Hosts. Fassen Sie sie zu diesem Zeitpunkt nicht zusammen.
-
Stellen Sie für den Host, der als Master benannt wurde, die Pooldatenbank aus Ihrer Sicherung mit dem Befehl
xe pool-restore-database(siehe pool-restore-database). -
Verbinden Sie sich mit XenCenter mit dem Masterhost und stellen Sie sicher, dass alle Ihre freigegebenen Speicher und VMs wieder verfügbar sind.
-
Führen Sie einen Poolbeitrittsvorgang auf den verbleibenden neu installierten Mitgliedshosts durch, und starten Sie Ihre VMs auf den entsprechenden Hosts.
Bewältigen Sie Fehler aufgrund von Konfigurationsfehlern
Wenn der physische Hostcomputer betriebsbereit ist, aber die Software oder Hostkonfiguration beschädigt ist:
-
Führen Sie den folgenden Befehl aus, um die Hostsoftware und -konfiguration wiederherzustellen:
xe host-restore host=host file-name=hostbackup <!--NeedCopy--> -
Starten Sie die Installations-CD des Hosts neu und wählen Sie Wiederherstellen aus Sicherung.
Ausfall der physischen Maschine
Wenn der physische Hostcomputer ausgefallen ist, verwenden Sie das entsprechende Verfahren aus der folgenden Liste für die Wiederherstellung.
Warnung:
Alle VMs, die auf einem vorherigen Mitglied (oder dem vorherigen Host) ausgeführt wurden und ausgefallen sind, werden weiterhin als markiert
Ausgeführtein der Datenbank. Dieses Verhalten dient der Sicherheit. Das gleichzeitige Starten einer VM auf zwei verschiedenen Hosts würde zu schwerwiegenden Festplattenbeschädigungen führen. Wenn Sie sicher sind, dass die Maschinen (und VMs) offline sind, können Sie den Energiestatus der VM aufGestoppt:
xe vm-reset-powerstate vm=vm_uuid --forceVMs können dann mit XenCenter oder der CLI neu gestartet werden.
So ersetzen Sie einen ausgefallenen Master durch einen noch aktiven Mitglied:
-
Führen Sie die folgenden Befehle aus:
xe pool-emergency-transition-to-master xe pool-recover-slaves <!--NeedCopy--> -
Wenn die Befehle erfolgreich ausgeführt werden, starten Sie die VMs neu.
So stellen Sie einen Pool wieder her, bei dem alle Hosts fehlgeschlagen sind:
-
Führen Sie den Befehl aus:
xe pool-restore-database file-name=backup <!--NeedCopy-->Warnung:
Dieser Befehl ist nur erfolgreich, wenn der Zielcomputer über eine entsprechende Anzahl von entsprechend benannten Netzwerkkarten verfügt.
-
Wenn der Zielcomputer eine andere Ansicht des Speichers hat als der ursprüngliche Computer, ändern Sie die Speicherkonfiguration mit dem
pbd-zerstörenBefehl. Verwenden Sie als Nächstes diepbd-create, um Speicherkonfigurationen neu zu erstellen. Siehe PBD-Befehle zur Dokumentation dieser Befehle. -
Wenn Sie eine Speicherkonfiguration erstellt haben, verwenden Sie
PBD-Steckeroder Lagerung > Reparieren des Speicher-Repositorys Menüpunkt in XenCenter, um die neue Konfiguration zu verwenden. -
Starten Sie alle VMs neu.
So stellen Sie eine VM wieder her, wenn der VM-Speicher nicht verfügbar ist:
-
Führen Sie den folgenden Befehl aus:
xe vm-import filename=backup metadata=true <!--NeedCopy--> -
Wenn der Metadatenimport fehlschlägt, führen Sie den folgenden Befehl aus:
xe vm-import filename=backup metadata=true --force <!--NeedCopy-->Mit diesem Befehl wird versucht, die VM-Metadaten nach bestem Wissen und Gewissen wiederherzustellen.
-
Starten Sie alle VMs neu.