Hochverfügbarkeit

Die XenServer®-Funktion für Hochverfügbarkeit (HA) stellt sicher, dass Ihre VMs mit minimalen Ausfallzeiten und ohne Datenbeschädigung weiterlaufen. Wenn Probleme wie Host-Hardwarefehler und Netzwerkunterbrechungen auftreten, reagiert der XenServer-Pool, indem er betroffene VMs auf stabilen Hosts im Pool neu startet. Diese Funktion ermöglicht es Ihnen, Ihre VMs am Laufen zu halten, bis Sie Hardwareprobleme beheben können.

XenServer gewährleistet die Hochverfügbarkeit von VMs auf folgende Weise:

• Verwendung eines Netzwerk-Heartbeats zur Überprüfung der Konnektivität zwischen Hosts im Pool.
• Verwendung eines Speicher-Heartbeats zur Überprüfung der Konnektivität zwischen den Hosts und dem freigegebenen Speicher.
• Erkennung, ob ein Host ausgefallen ist.
• Erkennung, ob ein Host oder Hosts unerreichbar geworden sind.
• Abschotten von Hosts, die nicht mit der größten Partition von Hosts im Pool kommunizieren können. Ein abgeschotteter Host startet sofort neu, wodurch alle darauf laufenden VMs gestoppt werden. Nach dem Neustart versucht er, dem Ressourcenpool wieder beizutreten. Diese Vorsichtsmaßnahme verhindert, dass VMs auf zwei Hosts gleichzeitig laufen und Datenbeschädigungen riskieren.
• Markieren eines ausgefallenen, abgeschotteten oder unerreichbaren Hosts als nicht mehr Teil des aktiven Satzes von Hosts im Pool.
• Markieren aller VMs, die auf diesem Host liefen, als angehalten.
• Wenn der ausgefallene, abgeschottete oder unerreichbare Host der Pool-Koordinator ist, wird die Koordinatorrolle einem anderen Host im Pool neu zugewiesen.
• Neustart aller angehaltenen VMs gemäß dem von Ihnen konfigurierten Failover-Plan.
• Überwachung von Änderungen an der Poolkonfiguration, um zu überprüfen, ob der konfigurierte Failover-Plan umgesetzt werden kann.

Da die HA-Funktion VMs automatisch auf anderen Hosts im Pool neu startet, muss XenServer sicherstellen, dass der ursprüngliche (ausgefallene oder unerreichbare) Host der VM die VM nicht mehr ausführt. Zwei Instanzen derselben VM, die gleichzeitig ausgeführt werden, können zu einer Beschädigung der VM-Daten führen. Um dies zu verhindern, schotten sich XenServer-Hosts in einem HA-fähigen Pool proaktiv selbst ab, wenn sie sich in Situationen befinden, die dazu führen könnten, dass zwei Instanzen derselben VM ausgeführt werden.

Die HA-Funktion hält Ihre wichtigen VMs am Laufen, bis Sie das zugrunde liegende Hardware- oder Netzwerkproblem beheben können. Wenn Sie feststellen, dass ein HA-Ereignis aufgetreten ist, untersuchen und beheben Sie den zugrunde liegenden Fehler, um Ihren Pool wieder voll funktionsfähig zu machen.

Dieser Artikel beschreibt Konzepte, Anforderungen und erwartetes Verhalten der Hochverfügbarkeit. Informationen zum Konfigurieren und Verwalten der Hochverfügbarkeit finden Sie unter Hochverfügbarkeit konfigurieren.

Anforderungen

Um die Hochverfügbarkeitsfunktion nutzen zu können, benötigen Sie die folgenden Elemente in Ihrer Umgebung:

• Ein XenServer-Pool: Die HA-Funktion arbeitet innerhalb eines einzelnen Ressourcenpools.

  • Wir empfehlen, dass der Pool homogen ist. Jeder Host im Pool stellt den VMs dieselben CPU-Funktionen zur Verfügung und erleichtert so das Neustarten der VMs an beliebiger Stelle im Pool.
  • Damit der Heartbeat-Mechanismus effektiv funktioniert, empfehlen wir, dass der Pool mindestens 3 Hosts hat.
  • Stellen Sie sicher, dass alle Hosts im Pool online sind, bevor Sie HA aktivieren.

• Gemeinsamer Speicher für alle Hosts im Pool: Damit jede VM im Pool nach einem Ausfall auf jedem Host im Pool neu gestartet werden kann, müssen alle Hosts im Pool Zugriff auf den SR haben, auf dem die VM-Festplatten gespeichert sind.

• Ein Heartbeat-SR: Dieser SR kann derselbe SR sein, auf dem die VM-Festplatten gespeichert sind. Der Pool speichert Informationen, die es dem Pool ermöglichen, die Fehlererkennung und -wiederherstellung im Falle eines Ausfalls zu koordinieren.

  • Der Heartbeat-SR muss sich auf einem iSCSI-, NFS- oder Fibre Channel-LUN befinden. Speicher, der über SMB oder iSCSI mit CHAP-Authentifizierung angeschlossen ist, kann nicht als Heartbeat-SR verwendet werden. Wir empfehlen, dass dieser SR hochzuverlässig und latenzarm ist.

  • XenServer 8.4 benötigt 4 GB für den Heartbeat-SR.

    Die auf dem Heartbeat-SR gespeicherten Informationen umfassen:

    • 4 MB Heartbeat-Volume: Bietet den Speicher-Heartbeat, der überprüft, ob Hosts im Pool Zugriff auf den Speicher haben.
    • Das Metadaten-Volume: Speichert die Metadaten des Pool-Koordinators, die verwendet werden, wenn ein Failover des Pool-Koordinators stattfindet. Dieses Volume belegt den restlichen erforderlichen Speicherplatz.

• Zuverlässige und redundante Speicherkonnektivität für den Heartbeat-SR: Damit die HA-Funktion die genaueste Ansicht darüber hat, welche Hosts auf den gemeinsam genutzten Speicher zugreifen können, konfigurieren Sie Ihre Umgebung so, dass der Speicherverkehr zuverlässig ist. Konfigurieren Sie für iSCSI- und Fibre Channel-SRs Multipathing. Verwenden Sie für NFS-SRs ein widerstandsfähiges gebündeltes Netzwerk als Speichernetzwerk.

• Statische IP-Adressen für alle Hosts: HA behandelt eine Änderung der Host-IP-Adresse als Verbindungsverlust des Hosts und geht davon aus, dass das Netzwerk des Hosts ausgefallen ist. Infolgedessen kann der Host abgeschottet werden (fence). Vermeiden Sie dies, indem Sie in Ihrem Pool nur statische IPs verwenden.

• Eine dedizierte gebündelte Schnittstelle im Management-Netzwerk: Damit die HA-Funktion den Pool-Status so genau wie möglich anzeigen kann, benötigen Sie eine zuverlässige und redundante Netzwerkkommunikation zwischen den Hosts.

• Das Management-Netzwerk erlaubt UDP-Heartbeat-Verkehr über Port 694: Der Netzwerk-Heartbeat überprüft, ob die Hosts im Pool aktiv sind und sich gegenseitig erreichen können.

• Konnektivität in unmittelbarer Nähe zwischen allen Pool-Hosts: Alle Hosts im Pool müssen mit einer Roundtrip-Latenz von weniger als 5 ms und einem Netzwerkdurchsatz von mindestens 10 Gbit/s verbunden sein. Hosts, die über mehrere Rechenzentren verteilt sind, können einen Pool nur dann gemeinsam nutzen, wenn diese Rechenzentren die Definition der unmittelbaren Nähe erfüllen. Eine hohe Latenz zwischen Hosts erhöht das Risiko einer fehlerhaften Abschottung (fencing) durch verpasste Heartbeats.

Hinweis:

HA hat keine Kenntnis von Rechenzentrumsgrenzen. Beim Neustart von VMs nach einem Host-Ausfall platziert HA diese auf jedem verfügbaren Host im Pool, basierend auf dem verfügbaren Speicher, ohne Konzept von Rechenzentrumsaffinität oder -präferenz. Wenn Sie einen Pool über zwei Rechenzentren in unmittelbarer Nähe verteilen und ein gesamtes Rechenzentrum ausfällt, versucht HA, betroffene VMs auf überlebenden Hosts neu zu starten – das Ergebnis hängt jedoch von der verfügbaren Kapazität ab und davon, ob der gemeinsame Speicher von diesen Hosts aus weiterhin zugänglich ist. Dies stellt kein kontrolliertes Failover auf Rechenzentrumsebene dar. Für Ausfallsicherheit gegen einen vollständigen Rechenzentrumsausfall verwenden Sie Disaster Recovery.

Um eine VM, die in Ihrem Hochverfügbarkeitspool läuft, zu schützen, richten Sie Ihre VM mit der folgenden Konfiguration ein:

• Speichern Sie die VM-Festplatten auf gemeinsamem Speicher, der allen Hosts im Pool zur Verfügung steht.
• Richten Sie die virtuellen Netzwerkschnittstellen in poolweiten Netzwerken ein.
• Stellen Sie sicher, dass die VM Live-Migration verwenden kann. Weitere Informationen finden Sie unter Anforderungen an die Migrationskompatibilität.
• Verbinden Sie die VM nicht mit einem lokalen DVD-Laufwerk.

Eine VM, die all diese Kriterien erfüllt, wird als agil bezeichnet.

Eine VM, die NVIDIA vGPU oder GPU-Passthrough verwendet, kann nicht durch HA geschützt werden. Der HA-Mechanismus kann jedoch versuchen, diese VM auf Best-Effort-Basis neu zu starten.

Anforderungen für GFS2-Cluster-Pools

Das Hochverfügbarkeitsverhalten für GFS2-Cluster-Pools verwendet einen anderen zugrunde liegenden Mechanismus und hat daher einige andere Anforderungen und Verhaltensweisen. Weitere Informationen finden Sie unter GFS2-Cluster-Pools.

HA-Failover-Plan

Der HA-Mechanismus berechnet einen poolweiten Failover-Plan basierend auf den folgenden Kriterien:

• VM-Wiederherstellungsanforderungen: Jede VM kann eine Neustartpriorität und eine Startreihenfolge haben.
• Verfügbare Pool-Ressourcen: Die wichtigste Ressource, die berücksichtigt wird, ist der Host-Speicher.
• Die Anzahl der zu tolerierenden Host-Ausfälle: Nachdem Sie HA in Ihrem Pool aktiviert haben, kann XenServer die maximale Anzahl von Hosts berechnen, die im Pool ausfallen können, bevor geschützte VMs nicht neu gestartet werden können. Sie können die Anzahl der zu tolerierenden Host-Ausfälle auf einen Wert kleiner oder gleich diesem Wert einstellen.

Wenn ein Failover-Plan, der diese Kriterien erfüllt, nicht berechnet werden kann, gilt der Pool als überbelegt. Wenn die geschützten VMs im Pool nicht neu gestartet werden können, löst XenServer eine Systemwarnung aus. Diese Warnung wird auch im XenCenter®-Panel Benachrichtigungen angezeigt.

Für jede VM in Ihrem Pool können Sie deren Wiederherstellungsverhalten definieren.

Neustartpriorität

Sie können einer VM eine der folgenden Neustartprioritäten zuweisen:

• Geschützt: Wenn die VM oder ihr Host unerwartet offline geht, startet HA die VM auf einem anderen Host neu. Dieser Neustart ist garantiert, vorausgesetzt, der Pool ist nicht überbelegt und die VM ist agil. Wenn der VM-Neustart fehlschlägt, versucht HA, die VM zu starten, wenn zusätzliche Kapazität im Pool vorhanden ist. Dieser Wert ist restart in der xe CLI und Neustart in XenCenter.
• Best-Effort: Wenn der Host, auf dem die VM läuft, unerwartet offline geht, versucht HA, die VM auf einem anderen Host neu zu starten. Dies wird nur versucht, nachdem alle geschützten VMs erfolgreich neu gestartet wurden. Hochverfügbarkeit unternimmt nur einen Versuch, eine Best-Effort-VM neu zu starten. Wenn dieser Versuch fehlschlägt, unternimmt die Hochverfügbarkeit keine weiteren Versuche, die VM neu zu starten. Dieser Wert ist best-effort in der xe CLI und Neustart, falls möglich in XenCenter.
• Ungeschützt: Wenn die VM oder ihr Host unerwartet offline geht, versucht HA nicht, die VM neu zu starten. Dies ist die Standardeinstellung. Dieser Wert ist ein leerer String in der xe CLI und Nicht neu starten in XenCenter.

Hochverfügbarkeit stoppt oder migriert niemals eine laufende VM, um Ressourcen für den Neustart einer VM mit höherer Neustartpriorität freizugeben.

Startreihenfolge

Die Startreihenfolge ist die Reihenfolge, in der die XenServer-Hochverfügbarkeit versucht, geschützte VMs bei einem Fehler neu zu starten. Dieser Wert wird nur für geschützte VMs verwendet. Der Standardwert ist 0, was die höchste Priorität darstellt. Geschützte VMs mit einem Startreihenfolgewert von 0 werden zuerst neu gestartet. Je höher der Startreihenfolgewert, desto später in der Sequenz wird die VM neu gestartet.

Pool-Verhalten

Nachdem Sie HA in Ihrem XenServer-Pool aktiviert haben, zeigt der Pool die folgenden Verhaltensweisen.

Verhalten während der Einrichtung

Wenn Sie HA in einem Pool aktivieren, führt der Pool-Koordinator die folgende Einrichtung durch:

• Berechnet den anfänglichen Failover-Plan.
• Konfiguriert die Datenbank so, dass Updates auf das Heartbeat-SR geschrieben werden. Diese Einstellung stellt sicher, dass VM-Konfigurationsänderungen bei einem Host-Ausfall nicht verloren gehen.
• Richtet die Metadaten des Pool-Koordinators auf dem Heartbeat-SR ein.

Alle Pool-Mitglieder:

• Senden sich gegenseitig Netzwerk-Heartbeats. Dies führt zu einem geringfügigen Anstieg des Management-Netzwerkverkehrs, da die Hosts im Pool überprüfen, ob sie miteinander kommunizieren können. Dieser Netzwerkverkehr wird fortgesetzt, solange HA aktiviert ist.

Verhalten während des normalen Betriebs

Während des normalen Betriebs führt der Pool-Koordinator eines HA-Pools die folgenden Aktionen aus (zusätzlich zu seinen üblichen Funktionen):

• Pflegt dynamisch einen Failover-Plan. Dieser Plan beschreibt, was zu tun ist, wenn eine Reihe von Hosts in einem Pool zu einem bestimmten Zeitpunkt ausfällt. Dieser Plan berücksichtigt die maximale Anzahl tolerierbarer Host-Ausfälle und stellt sicher, dass alle geschützten VMs neu gestartet werden können. Der Plan wird dynamisch basierend auf VM-Lebenszyklusoperationen und -bewegungen neu berechnet. Wenn Änderungen (z. B. das Hinzufügen neuer VMs zum Pool) dazu führen, dass alle geschützten VMs nach der maximalen Anzahl von Host-Ausfällen nicht mehr neu gestartet werden können, kann kein Plan berechnet werden und der Pool ist überbelegt. Wenn der Pool überbelegt wird, löst XenServer einen Alarm über XenCenter, E-Mail, SNMP-Trap oder NRPE-Alarm aus.

Während des normalen Betriebs führt jedes Mitglied eines HA-Pools die folgenden Aktionen aus (zusätzlich zu seinen üblichen Funktionen):

• Überprüft, ob der Pool-Koordinator aktiv ist. Der Host tut dies, indem er versucht, eine „Master-Sperre“ auf dem freigegebenen Speicher zu erwerben. Wenn bereits ein Pool-Koordinator existiert, schlägt dieser Versuch fehl.
• Sendet einen Netzwerk-Heartbeat. Dieser Netzwerk-Heartbeat wird über UDP auf Port 694 im Management-Netzwerk an alle anderen Hosts im Pool gesendet.
• Führt ein Protokoll des Livesets der Hosts im Pool. Das Liveset der Hosts ist nach Ansicht jedes einzelnen Hosts die Menge der anderen Hosts, die er für aktiv hält. Wenn ein Host innerhalb des durch das HA-Timeout (standardmäßig 60 Sekunden) angegebenen Zeitraums keinen Netzwerk-Heartbeat von einem anderen Host empfangen hat, kommuniziert er mit den anderen Hosts im Pool, um zu vereinbaren, ob das Liveset aktualisiert werden muss.
• Schreibt in die Statusdatei auf dem Speicher-Heartbeat-Volume. Diese Aktion überprüft, ob der Host weiterhin Zugriff auf den Speicher hat. Sie ermöglicht es den Hosts auch, ihren Status untereinander zu kommunizieren (zusätzlich zur Kommunikation mit dem Netzwerk-Heartbeat).
• Aktualisiert die Datenbank auf dem Heartbeat-SR. Der Host zeichnet alle Änderungen an den VM-Konfigurationen für die von ihm gehosteten VMs auf.

Einige Pool-Operationen sind blockiert oder nicht ratsam, wenn HA aktiviert ist. Deaktivieren Sie die Hochverfügbarkeit vorübergehend, um diese Operationen durchzuführen:

• Hinzufügen eines Hosts zum Pool.
• Entfernen eines Hosts aus dem Pool. Blockiert, wenn diese Aktion dazu führen kann, dass der Pool überbelegt wird.
• Herunterfahren eines Hosts im Pool. Blockiert, wenn diese Aktion dazu führen kann, dass der Pool überbelegt wird.
• Ändern des Management-Netzwerks.
• Ändern des an den Pool angeschlossenen SR.
• Aktivieren von Clustering. Einige Verhaltensweisen und Anforderungen der Hochverfügbarkeit unterscheiden sich für geclusterte Pools. Weitere Informationen finden Sie unter Geclusterte Pools.

Während des normalen Betriebs aktivieren die folgenden Aktionen im Pool den HA-Failover-Plan nicht:

• Sauberes Herunterfahren einer VM über XenCenter oder die xe CLI. Der HA-Mechanismus betrachtet diese VM nicht als ausgefallen und versucht nicht, sie neu zu starten. Weitere Informationen zu dieser Aktion finden Sie unter Herunterfahren einer durch Hochverfügbarkeit geschützten VM
• VM-Absturz oder sauberes Herunterfahren innerhalb des Gastbetriebssystems, wenn HA so konfiguriert wurde, dass VMs bei internem Herunterfahren nicht automatisch neu gestartet werden. In diesem Fall betrachtet der HA-Mechanismus die VM nicht als ausgefallen und versucht nicht, sie neu zu starten. Weitere Informationen zu dieser Einstellung finden Sie unter Konfigurieren des Neustartverhaltens für intern heruntergefahrene VMs
• Sauberes Herunterfahren eines Hosts über XenCenter oder die xe CLI. Der HA-Mechanismus betrachtet diesen Host nicht als ausgefallen und versucht nicht, auf ihm gehostete VMs neu zu starten. Wenn diese Aktion jedoch dazu führt, dass der Pool überbelegt wird, wird sie von XenServer blockiert. Weitere Informationen zu dieser Aktion finden Sie unter Herunterfahren eines Hosts bei aktivierter Hochverfügbarkeit

Verhalten bei Hardwarefehlern oder Instabilität der Infrastruktur

In dieser Phase sind alle Hosts im Pool dafür verantwortlich, den eigenen Konnektivitätsstatus zu erkennen und den Konnektivitätsstatus anderer Hosts im Pool abzustimmen.

XenServer HA erkennt und behandelt die folgenden Fehlertypen:

• Ausgefallener Host oder Hosts: In dieser Situation bemerken alle verbleibenden Hosts sehr schnell, dass der ausgefallene Host oder die Hosts die Aktualisierung der Statusdatei eingestellt haben und keine Netzwerk-Heartbeats mehr senden. Nach einer angemessenen Verzögerung werden diese Hosts aus dem Liveset entfernt.
• Netzwerkpartition: In dieser Situation können ein oder mehrere Hosts nicht mit einem oder mehreren anderen Hosts kommunizieren. Ein Host bemerkt, dass er innerhalb des definierten Timeouts keine Netzwerk-Heartbeats von einem oder mehreren anderen Hosts erhalten hat, und startet einen Fehlerhandler. Dieser Fehlerhandlerprozess kommuniziert über die Statusdatei und den funktionierenden Netzwerk-Heartbeat und verwendet diese Informationen, um zu bestimmen, welche Netzwerkpartitionen (Gruppen von Hosts, die miteinander kommunizieren können) existieren. Die Hosts in der größten Partition bilden das Liveset und überleben. Wenn es Partitionen gleicher Größe gibt, überleben die Hosts in der Partition, die den Host mit der niedrigsten Host-UUID enthält.
• Fehlgeschlagene Speicherverbindung: In dieser Situation bemerkt ein Host, dass er den Speicher nicht erreichen kann, oder andere Hosts bemerken, dass seine Updates nicht auf dem Speicher vorhanden sind. Die Hosts kommunizieren über die Netzwerk-Heartbeat-Kommunikation, um zu überprüfen, ob andere Hosts den Speicherzugriff verloren haben:
  • Wenn alle Hosts den Speicher, aber nicht das Netzwerk verloren haben, wird dies als vorübergehender Speicherverlust betrachtet und die Hosts bleiben aktiv, um auf die Wiederherstellung des Speichers zu warten. Bei weiteren Ausfällen werden alle Hosts im Pool abgeschottet (fence). Diese Regel verhindert, dass der Speicher einen Single Point of Failure darstellt.
  • Wenn nur einige Hosts den Speicherzugriff verloren haben, aber alle Hosts noch Netzwerkzugriff haben, werden diese Hosts aus dem Liveset entfernt.

Wenn ein Host weiß, dass er für die Mehrheit des Pools als ausgefallen oder unerreichbar erscheint, schottet sich dieser Host selbst ab (self-fences). Fencing ist ein erwartetes Verhalten, das als Schutzmaßnahme für VM-Daten konzipiert wurde. Es stellt sicher, dass eine VM nicht gleichzeitig an zwei Orten ausgeführt wird. Ein Host verwendet die folgenden Kriterien, um zu entscheiden, dass er sich selbst abschotten muss:

• Wenn der Toolstack des Hosts nicht läuft und nicht neu gestartet werden kann, schottet sich der Host selbst ab.
• Wenn der Host sowohl die Netzwerk- als auch die Speicher-Heartbeats verloren hat, betrachtet sich der Host als unerreichbar und schottet sich selbst ab.
• Wenn der Host den Speicher-Heartbeat verloren hat, aber immer noch Netzwerk-Heartbeats empfängt:
  • Wenn der Host noch alle anderen Poolmitglieder kontaktieren kann und alle diese Mitglieder ebenfalls den Speicher-Heartbeat verloren haben, bleibt der Host aktiv. Dieser Fall verhindert, dass der Speicher als Single Point of Failure fungiert und den gesamten Pool abschottet.
  • Wenn der Host einen oder mehrere andere Hosts im Pool nicht kontaktieren kann, schottet er sich selbst ab.
• Wenn der Host Netzwerk-Heartbeats verloren hat, aber immer noch den Speicher-Heartbeat besitzt, bestimmt er, ob er sich in der größten Netzwerkpartition befindet. Wenn nicht, schottet sich der Host selbst ab.
• Es besteht die Möglichkeit, dass ein Netzwerkausfall den Pool in Partitionen gleicher Größe aufteilt. Wenn ein Host anhand der Informationen in der Statusdatei auf dem Heartbeat-SR weiß, dass er sich in einer solchen Netzwerkpartition befindet:
  • Wenn die Partition den Host mit der niedrigsten UUID enthält, bleibt der Host aktiv.
  • Wenn die Partition den Host mit der niedrigsten UUID nicht enthält, isoliert sich der Host selbst (self-fences).

Wenn eine Isolierungsaktion (fence action) durchgeführt wird, startet der Host sofort und abrupt neu, wodurch alle darauf laufenden VMs gestoppt werden. Der isolierte Host durchläuft eine Neustartsequenz, und wenn er neu gestartet ist, versucht er, dem Ressourcenpool wieder beizutreten.

Verhalten während der Wiederherstellung

Wenn der Pool-Koordinator der Host ist, der ausgefallen, isoliert oder unerreichbar geworden ist, versuchen andere Hosts, die Master-Sperre zu erhalten. Der Host, dem dies gelingt, wird der neue Koordinator.

Hosts, die sich selbst isoliert haben, starten neu und versuchen, dem Pool wieder beizutreten.

Wenn ein Host als tot markiert und seine VMs angehalten werden, ist der Pool-Koordinator für die folgenden Wiederherstellungsaktionen verantwortlich.

• Alle geschützten VMs gemäß dem Failover-Plan neu starten.
• Wenn nicht genügend Ressourcen vorhanden sind, um alle geschützten VMs zu starten, wartet der Pool-Koordinator, bis Ressourcen verfügbar werden (z. B. wenn zuvor isolierte Hosts dem Pool wieder beitreten), und versucht dann, die geschützten VMs zu starten.
• Nachdem alle geschützten VMs erfolgreich gestartet wurden, unternimmt der Pool-Koordinator einen Versuch, jede Best-Effort-VM neu zu starten.