Wenn ein Host ausfällt und seine virtuellen Maschinen neu gestartet werden müssen, können Sie mit der Einstellung für die VM-Neustartpriorität festlegen, in welcher Reihenfolge die virtuellen Maschinen neu gestartet werden. Mit der Einstellung für die Hostisolierungsreaktion können Sie auch konfigurieren, wie vSphere HA reagiert, wenn Hosts die Verwaltungsnetzwerkkonnektivität mit anderen Hosts verlieren. Beim Neustart einer virtuellen Maschine durch vSphere HA nach einem Fehler werden noch weitere Faktoren berücksichtigt.

Die folgenden Einstellungen gelten für alle virtuellen Maschinen im Cluster im Falle eines Hostausfalls oder einer Hostisolation.D Sie können zudem Ausnahmen für bestimmte virtuelle Maschinen konfigurieren. Siehe Anpassen einer einzelnen virtuellen Maschine.

VM-Neustartpriorität

Mithilfe der VM-Neustartpriorität legen Sie die relative Reihenfolge fest, in der den virtuellen Maschinen nach einem Hostausfall Ressourcen zugeordnet werden. Diese virtuellen Maschinen werden Hosts mit nicht reservierter Kapazität zugewiesen. Virtuelle Maschinen mit der höchsten Priorität kommen an erster Stelle, dann wird mit VMs mit geringerer Priorität fortgefahren, bis alle virtuellen Maschinen platziert sind oder keine Cluster-Kapazität mehr verfügbar ist, um die Reservierungen oder den Arbeitsspeicher-Overhead der virtuellen Maschinen zu erfüllen. Dann startet der Host die zugewiesenen virtuellen Maschinen in der Reihenfolge ihrer Priorität neu. Wenn nicht ausreichend Ressourcen vorhanden sind, wartet vSphere HA, bis weitere nicht reservierte Kapazität verfügbar wird, zum Beispiel, wenn ein Host wieder online ist, und versucht dann erneut, diese virtuellen Maschinen zu platzieren. Um die Möglichkeit einer solchen Situation zu verringern, sollten Sie die vSphere HA-Zugangssteuerung so konfigurieren, dass mehr Ressourcen für Ausfälle reserviert werden. Mit der Zugangssteuerung kann gesteuert werden, welche Cluster-Kapazität von virtuellen Maschinen reserviert wird und Reservierungen und den Arbeitsspeicher-Overhead anderer virtueller Maschinen bei einem Ausfall nicht bedienen kann.

Die Werte für diese Einstellung sind: „Deaktiviert“, „Niedrig“, „Mittel“ (Standardeinstellung) und „Hoch“. Die Einstellung „Deaktiviert“ wird von der VM/Anwendungsüberwachungsfunktion von vSphere HA ignoriert, da diese Funktion virtuelle Maschinen vor Ausfällen der Betriebssystem-Ebene und nicht vor Ausfällen virtueller Maschinen schützt. Wenn ein Fehler auf Betriebssystemebene auftritt, wird das Betriebssystem von vSphere HA neu gestartet und die virtuelle Maschine wird weiterhin auf demselben Host ausgeführt. Diese Einstellung kann für einzelne virtuelle Maschinen geändert werden.

Anmerkung:

Das Zurücksetzen einer virtuellen Maschine führt zu einem harten Neustart des Gastbetriebssystems, aber nicht zu einem Ein-/Ausschalten der virtuellen Maschine.

Die Neustartprioritätseinstellungen für virtuelle Maschinen sind je nach Benutzererfordnissen unterschiedlich. Weisen Sie den virtuellen Maschinen, die die wichtigsten Dienste verrichten, eine höhere Neustartpriorität zu.

Im Falle einer Multi-Tier-Anwendung könnten Sie beispielsweise die Prioritäten abhängig von den auf den virtuellen Maschinen gehosteten Funktionen festlegen:

  • Hoch Datenbankserver, die Daten für Anwendungen bereitstellen.

  • Mittel Anwendungsserver, die in der Datenbank Daten konsumieren und die Ergebnisse auf Webseiten präsentieren.

  • Niedrig Webserver, die Benutzeranforderungen empfangen, Abfragen an Anwendungsserver übertragen und die Ergebnisse an die Benutzer zurücksenden.

Wenn ein Host ausfällt, versucht vSphere HA, die betroffenen virtuellen Maschinen, die eingeschaltet waren und deren Neustartpriorität auf „Deaktiviert“ eingestellt ist bzw. die ausgeschaltet waren, bei einem aktiven Host zu registrieren.

Hostisolierungsreaktion

Die Hostisolierungsreaktion legt fest, was geschieht, wenn die Verbindungen des Hosts in einem vSphere HA-Cluster zum Verwaltungsnetzwerk verloren gehen, dieser aber weiter ausgeführt wird. Mit der Isolierungsreaktion können Sie vSphere HA so konfigurieren, dass virtuelle Maschinen, die auf einem isolierten Host ausgeführt werden, ausgeschaltet und auf einem nicht isolierten Host neu gestartet werden. Hostisolierungsreaktionen setzen voraus, dass der Hostüberwachungsstatus aktiviert ist. Wenn der Hostüberwachungsstatus deaktiviert ist, werden die Hostisolierungsreaktionen ebenfalls angehalten. Ein Host stellt fest, dass er isoliert ist, wenn er nicht mit den Agenten, die auf anderen Hosts ausgeführt werden, kommunizieren und seine Isolierungsadressen nicht anpingen kann. Der Host führt dann seine Isolierungsreaktion aus. Die Reaktionen sind „VMs ausschalten und neu starten“ bzw. „VMs herunterfahren und neu starten“. Diese Eigenschaft kann für einzelne virtuelle Maschinen geändert werden.

Anmerkung:

Wenn eine virtuelle Maschine eine Neustartprioritätseinstellung „Deaktiviert“ hat, wird keine Hostisolierungsreaktion vorgenommen.

Sie müssen zum Verwenden der Einstellung „VMs herunterfahren und neu starten“ VMware Tools auf dem Gastbetriebssystem der virtuellen Maschine installieren. Das Herunterfahren der virtuellen Maschine hat den Vorteil, dass ihr Zustand beibehalten wird. Es ist besser, die virtuelle Maschine herunterzufahren als sie auszuschalten, da beim Ausschalten die neuesten Änderungen nicht auf die Festplatte geschrieben und Transaktionen nicht übernommen werden. Virtuelle Maschinen, die heruntergefahren werden, benötigen während der Zeit des Herunterfahrens länger für ein Failover. Virtuelle Maschinen, die nicht innerhalb von 300 Sekunden oder in dem Zeitraum, der in der erweiterten Option das.isolationShutdownTimeout angegeben ist, heruntergefahren werden, werden ausgeschaltet.

Nach dem Erstellen eines vSphere HA-Clusters können Sie für bestimmte virtuelle Maschinen die Standardclustereinstellungen „Neustartpriorität“ und „Isolierungsreaktion“ überschreiben. Dies ist nützlich bei virtuellen Maschinen, die zu speziellen Zwecken eingesetzt werden. Virtuelle Maschinen, die beispielsweise Infrastrukturdienste wie DNS oder DHCP bereitstellen, müssen möglicherweise vor anderen virtuellen Maschinen im Cluster eingeschaltet werden.

Es kann zu einer „Split-Brain“-Situation für die virtuelle Maschine kommen, wenn ein Host von einem Master-Host isoliert oder partitioniert wird und der Master-Host nicht über Taktsignal-Datenspeicher mit ihm kommunizieren kann. In dieser Situation kann der Master-Host nicht feststellen, ob der Host läuft, und erklärt ihn daher für ausgefallen. Der Master-Host versucht dann, die virtuellen Maschinen, die auf dem isolierten oder partitionierten Host ausgeführt werden, neu zu starten. Dieser Versuch ist erfolgreich, wenn die virtuellen Maschinen auf dem isolierten/partitionierten Host weiter ausgeführt werden und der Host den Zugriff auf die Datenspeicher der virtuellen Maschinen verlor, als er isoliert oder partitioniert wurde. Dann liegt ein „Split-Brain“-Zustand vor, weil zwei Instanzen der virtuellen Maschine vorhanden sind. Es ist jedoch nur eine Instanz in der Lage, die virtuellen Festplatten der virtuellen Maschine zu lesen oder darauf zu schreiben. Um diesen Split-Brain-Zustand zu verhindern, kann der VM-Komponentenschutz verwendet werden. Wenn Sie die aggressive Einstellung des VM-Komponentenschutzes aktivieren, wird der Zugriff auf Datenspeicher für eingeschaltete virtuelle Maschinen überwacht, und virtuelle Maschinen, die den Zugriff auf ihre Datenspeicher verlieren, werden heruntergefahren.

Um dieses Problem zu beheben, generiert ESXi eine Frage auf der virtuellen Maschine, die die Festplattensperren verloren hat, für den Fall, dass der Host die Isolation verlässt und feststellt, dass er die Festplattensperren nicht mehr wiederherstellen kann. vSphere HA beantwortet diese Frage automatisch und ermöglicht der Instanz der virtuellen Maschine, die die Festplattensperren verloren hat, sich auszuschalten. Übrig bleibt die Instanz, die über Festplattensperren verfügt.

Berücksichtigte Faktoren für den Neustart von virtuellen Maschinen

Nach einem Ausfall versucht der Master-Host des Clusters, die betroffenen virtuellen Maschinen neu zu starten, indem ein Host identifiziert wird, der sie einschalten kann. Bei der Auswahl eines derartigen Hosts berücksichtigt der Master-Host eine Reihe von Faktoren.

Zugriffsfähigkeit auf Dateien

Bevor eine virtuelle Maschine gestartet werden kann, muss auf ihre Dateien von einem der aktiven Cluster-Hosts, mit dem der Master über das Netzwerk kommunizieren kann, zugegriffen werden können.

Virtuelle Maschine und Hostkompatibilität

Wenn Hosts vorhanden sind, auf die zugegriffen werden kann, muss die virtuelle Maschine mit mindestens einem der Hosts kompatibel sein. Zur für eine virtuelle Maschine festgelegten Kompatibilität zählt die Wirkung aller erforderlichen VM-Host-Affinitätsregeln. Wenn z. B. eine Regel nur die Ausführung der virtuellen Maschine auf zwei Hosts zulässt, wird sie für die Platzierung auf diesen beiden Hosts berücksichtigt.

Ressourcenreservierungen

Mindestens einer der Hosts, auf denen die virtuelle Maschine ausgeführt werden kann, muss über ausreichend nicht reservierte Kapazität verfügen, um den Arbeitsspeicher-Overhead der virtuellen Maschine und etwaige Ressourcenreservierungen zu erfüllen. Es kommen vier Reservierungstypen in Betracht: CPU, Arbeitsspeicher, vNIC und virtueller Flash. Zudem müssen genügend Netzwerkports verfügbar sein, um die virtuelle Maschine einzuschalten.

Hostgrenzwerte

Zusätzlich zu den Ressourcenreservierungen kann eine virtuelle Maschine nur auf einem Host platziert werden, wenn dadurch nicht die maximale Anzahl zulässiger virtueller Maschinen oder die Anzahl der verwendeten vCPUs überschritten wird.

Funktionsbeschränkungen

Wenn die erweiterte Option festgelegt wird, in der vSphere HA Anti-Affinitätsregeln von VM zu VM durchsetzen muss, dann wird diese Regel durch vSphere HA nicht verletzt. Zudem verletzt vSphere HA keine pro Host konfigurierten Limits für fehlertolerante virtuelle Maschinen.

Wenn kein Host die obigen Bedingungen erfüllt, gibt der Master-Host ein Ereignis aus, das besagt, dass nicht genügend Ressourcen vorhanden sind, damit vSphere HA die VM starten kann, und versucht es erneut, nachdem sich die Clusterbedingungen geändert haben. Wenn zum Beispiel die virtuelle Maschine nicht zugänglich ist, versucht der Master-Host es erneut, nachdem sich die Dateizugänglichkeit geändert hat.

Limits für Neustartversuche der virtuellen Maschinen

Wenn der Master-Agent von vSphere HA versucht, eine VM neu zu starten (was deren Registrierung und Einschaltung umfasst) und der Versuch fehlschlägt, wird der Neustart nach einer Verzögerung erneut versucht. vSphere HA unternimmt eine maximale Anzahl Versuche (standardmäßig 6), die VM neu zu starten. Bei diesem Höchstwert zählen jedoch nicht alle Neustartfehler.

So besteht z. B. der wahrscheinlichste Grund für einen fehlgeschlagenen Neustart darin, dass die VM entweder auf einem anderen Host noch ausgeführt wird, oder dass vSphere HA zu früh versucht hat, die VM nach einem Ausfall neu zu starten. In dieser Situation verzögert der Master-Agent den erneuten Versuch um das Doppelte der Verzögerung nach dem letzten Versuch (mindestens 1 und höchstens 30 Minuten). Wenn also die Verzögerung auf 1 Minute festgelegt ist, wird ein erster Versuch bei T=0 gemacht. Weitere Versuche finden bei T=1 (1 Minute), T=3 (3 Minuten), T=7 (7 Minuten), T=15 (15 Minuten) und T=30 (30 Minuten) statt. Jeder dieser Versuche zählt für das Limit, und standardmäßig finden nur sechs Versuche statt.

Weitere Neustartfehler führen zu zählbaren erneuten Versuchen, aber mit einem anderen Verzögerungsintervall. Ein Beispiel dafür ist ein Szenario, in dem der für den Neustart der virtuellen Maschine ausgewählte Host den Zugriff auf einen der Datenspeicher der VM verliert, nachdem die Auswahl durch den Master-Agent getroffen wurde. In diesem Fall wird nach einer Standardverzögerung von 2 Minuten ein erneuter Versuch gestartet. Dieser Versuch zählt ebenfalls für das Limit.

Schließlich gibt es noch Versuche, die nicht zählen. Das ist beispielsweise der Fall, wenn der Host, auf dem die virtuelle Maschine neu gestartet werden sollte, ausfällt, bevor der Master-Agent die Neustartanforderung ausgibt. Der Versuch wird nach 2 Minuten wiederholt, aber dieser Fehler zählt nicht bei der maximalen Anzahl der Versuche.

Benachrichtigungen über Neustart der virtuellen Maschine

vSphere HA generiert ein Clusterereignis, wenn ein Failover-Vorgang für virtuelle Maschinen im Cluster läuft. Durch das Ereignis wird auch ein Konfigurationsproblem auf der Registerkarte Cluster-Übersicht angezeigt. Dort wird die Anzahl der virtuellen Maschinen angegeben, die neu gestartet werden. Es gibt vier verschiedene Kategorien für diese VMs.

  • VMs, die platziert werden: vSphere HA versucht derzeit, diese VMs neu zu starten

  • VMs, für die auf einen neuen Versuch gewartet wird: Ein vorheriger Neustartversuch ist fehlgeschlagen, und vSphere HA wartet, bis ein Zeitintervall abgelaufen ist, bevor ein weiterer Versuch unternommen wird.

  • VMs, die zusätzliche Ressourcen benötigen: Es sind nicht ausreichend Ressourcen für den Neustart dieser VMs vorhanden. vSphere HA wiederholt den Versuch, wenn neue Ressourcen verfügbar werden, z. B. wenn ein Host wieder online ist.

  • Virtual SAN-VMs, auf die kein Zugriff möglich ist: vSphere HA kann diese Virtual SAN-VMs nicht neu starten, weil kein Zugriff darauf möglich ist. Der Versuch wird wiederholt, sobald sich die Zugriffsfähigkeit ändert.

Die Anzahl der virtuellen Maschinen wird dynamisch aktualisiert, sobald eine Änderung an der Anzahl der VMs beobachtet wird, für die ein Neustartvorgang läuft. Das Konfigurationsproblem wird gelöscht, wenn vSphere HA alle VMs neu gestartet oder die Versuche eingestellt hat.

In vSphere 5.5 oder früher wird ein Ereignis pro VM ausgegeben, wenn ein erfolgloser Versuch zum Neustarten der virtuellen Maschine unternommen wurde. Dieses Ereignis ist in vSphere 6.x standardmäßig deaktiviert. Es kann aktiviert werden, indem die erweiterte vSphere HA-Option das.config.fdm.reportfailoverfailevent auf „1“ festgelegt wird.