Die kleine vSphere-6.5-Schule, Teil 2 - Text und Video

vSphere HA wird intelligenter

| Autor / Redakteur: Thomas Drilling / Ulrike Ostler

Die weitaus meisten Neuerungen der Version 6.5 im ESXi-Hypervisor verbergen sich in der Cluster-Konfiguration.
Die weitaus meisten Neuerungen der Version 6.5 im ESXi-Hypervisor verbergen sich in der Cluster-Konfiguration. (Bild: VMware)

Die Neuerungen in „VMware vSphere 6.5“ verteilen sich auf alle Komponenten der Produkt-Suite, „ESXi-Hypervisor“, „vCenter Server“, „PowerCLI“ und „vSAN“. Dieser Beitrag befasst sich mit den Neuerungen in vSphere 6.5, speziell den Cluster-Features.

Zu den herausragenden Neuerungen des ESXi-Hypervisors gehören jene im Bereich der „Cluster-Features“ an erster Stelle die klassische High Availability Funktion, nicht zu verwechseln mit dem „vCenter-High-Availability-Feature“, das ebenfalls neu in vSphere 6.5 ist.

Die Neuerungen im Bereich HA sind in erster Linie funktionaler Natur und ziehen daher automatisch eine Erweiterung/Anpassung der zugehörigen GUI-Dialoge im Web-Client nach sich. VMware hat seinen Web-Client was die Logik und „Dramaturgie“ vieler Dialoge angeht aber auch grundsätzlich überarbeitet, was die gesamte HA-Konfiguration übersichtlicher macht.

Folgendes Video demonstriert die wichtigsten HA-Neuerungen in vSphere 6.5.

vSphere Admission Control

Die interessantesten HA-Erweiterung finden sich im Bereich der so genannten Zugriffssteuerung. Hierbei geht es darum, wie ESXi die benötigte Failover-Kapazität auf den einzelnen Hosts berechnet. Das können Admins mit einer Reihe von Policies steuern, sofern sie nicht einen ESXi-Host explizit und ausschließlich als Failover-Host betreiben möchten. Aufgrund der Architektur eines vSphere-HA-Cluster-Modells ist dies jedoch nicht zwingend und sie können jeden ESXi-Host im Cluster auch für tägliche Aufgaben nutzen, sofern die Failover-Kapazität berücksichtigt wird.

Hier hat VMware die zugrundliegenden Algorithmen erweitert und die zugehörigen GUI-Dialoge vereinfacht. So erleichtert der Dialog zur Cluster-Konfiguration im Bereich „vSphere Availability” jetzt unter dem Link/Untermenü „Admission Control“ sämtliche Einstellungen zur Failover-Kapazität. Diese untergliedern sich nun übersichtlich in die drei Sektionen „Host failures cluster tolerates”, „Define host failover capacity by” und „Performance degradation VMs tolerate”. Die Default-Einstellung bei „Define host failover capacity by” ist „Cluster resource percentage”.

Optional stehen im entsprechenden Listenmenü „Disabled”, „Slot-Policy” oder „Dedicated Failover Host” zur Verfügung, während die erste und dritte Einstellungen lediglich einen numerischen Wert erfordert, wie die Anzahl der Hosts im ersten Fall oder der prozentuale Wert im dritten Fall. Die führt zum von der Vorgängerversionen bekannten Verhalten von Admission Control.

Allerdings wird der Wert für „Define host failover capacity by” jetzt automatisch errechnet, was ein altbekanntes Problem löst: Hatte man nämlich „vor“ vSphere 6.5 den 2-Node-Cluster um einen dritten Host erweitert, dabei aber vergessen, die Prozentregel zu ändern (zum Beispiel 50 Prozent), führte dies zu einer Verschwendung von Ressourcen. In vSphere 6.5 hingegen wird die hierzu benötigte Failover-Kapazität automatisch errechnet.

VM resource reduction event threshold

Neu hingegen ist die Admission-Control-Policy „Performance degradation VMs tolerate”. Diese Erweiterung basiert auf einem bereits im vergangenen Jahr unter Mitwirkung von Duncan Epping (Chief Technologist - Storage und Availability bei VMware und Autor des HA Deepdive) veröffentlichen Flings namens „vm resource and availability service“. Es ermöglicht im Rahmen der Planung der Failover-Kapazität eine Art „Was-wäre-wenn-Analyse“ in Bezug auf etwaige eintretende Host-Ausfälle. Das Feature simuliert den Ausfall von einem oder mehreren Hosts im Cluster, um herausfinden, ...

  • welche VMs sich sicher auf anderen Hosts neu starten lassen
  • welche VMs nicht sicher auf anderen Hosts neu gestartet werden können
  • welche VMs nach dem Neustart auf einem anderen Host mit reduzierter Performance laufen.

Die Einstellung erlaubt Ihnen das Angeben eines Performance-Verlustes, den Administratoren beim Neustarten von VMs auf einem anderen Host im Fehlerfall zu akzeptieren bereit ist. Der Default-Wert ist 100 Prozent. Sie können aber auch 30 Prozent oder 0 Prozent einstellen. Haben sie zum Beispiel in einem 3-Node-Cluster mit 96 GB RAM (3x32GB) bei „Host failures cluster tolerates“ eine „1“ eingetragen, konsumieren alle laufenden VM aktuell 70 Gigabyte RAM und der Wert bei “ Performance degradation VMs tolerate” steht auf 0 Prozent, generiert ESXi eine Warnung, dass die Failover-Kapazität nicht ausreichet.

Warum dies so ist, lässt sich leicht nachvollziehen: Beim Ausfall „eines Hosts” wären im Cluster noch 64 GB RAM verfügbar (96GB -32 GB). Es werden aber 70 GB für laufenden VMs benötigt, wenn diese auf den verbleibenden 2 Hosts neu gestartet werden, weil per Definition (0 Prozent) keine Performance-Verluste in Kauf genommen werden sollen. Die Konsequenz ist, dass sich die verfügbare Failover-Kapazität erhöhen muss, wenn keine Performance-Einbußen im Fehlerfall hinnehmbar wären.

Unter „Admission-Control“ versteht VMware Richtlinien zur Berechnung der Failover-Kapazität in eine, ESXI-Cluster (Thomas Drilling).
Unter „Admission-Control“ versteht VMware Richtlinien zur Berechnung der Failover-Kapazität in eine, ESXI-Cluster (Thomas Drilling). (Bild: Thomas Drilling)

Orchestrated VM Restart

Neu in der HA-Implementation ist auch ein Feature namens „Orchestrated VM Restart“. Es erlaubt in Version 6.5 nicht nur, VMs nach einem Ausfall oder bevor ein Server zur Wartung in den Maintenance-Mode genommen wird, auf einem anderen Host neu starten, sondern auch deren Start-Reihenfolge durch relativ komplexe Regeln zu steuern.

Mit „Orchestrated VM Restart“ können Administratoren „Ketten“ voneinander abhängiger virtueller Maschinen oder Gruppen solcher VMs festlegen und dann die Reihenfolge bestimmen, in der die einzelnen VMs neu gestartet werden. Sie können sogar einstellen, dass ausgewählte VMs mit dem Booten warten, bis der VM sämtliche von ihr durch andere VMs bereitgestellte Dienste tatsächlich zur Verfügung stehen.

In der bisherigen HA-Implementation (bis vSphere 6) gab es hingegen nur die „VM Restart Priority“, die Sie mehr oder weniger prophylaktisch auf „high“, „medium“ oder „low“ setzen konnten. Bei vSphere 6.5 kommen hingegen noch die Optionen „Lowest“ und „Highest“ hinzu. Die Einstellungen finden sich im Dialog „Failures und Responses“, in dem das Verhalten von vSphere HA in Bezug auf bestimmte Fehlerszenarien einstellbar ist, die vSphere-HA erkennen und „behandeln“ kann.

Hier ist der Schutz vor Host-Ausfällen das bei weitem wichtigste Szenario und entspricht der eigentlich HA-Implementation auf Basis von Fault Domain Manager (FDM). VMware vSphere kann optional aber auch Ausfälle von VMs, Applikationen und Storage-Devices erkennen. Mit der VM-Restart-Priority stellen Sie dann ein, welche VMs bei einem Host-Ausfall bevorzugt neu gestartet werden.

Die „VM-Restart-Priority“ entscheidet darüber, wie agressiv vSphere-HA VMs neu startet.
Die „VM-Restart-Priority“ entscheidet darüber, wie agressiv vSphere-HA VMs neu startet. (Bild: Thomas Drilling)

Das neue Feature „Orchestrated VM Restart“ konfigurieren Sie dagegen nicht bei “Failures and Responses”, sondern bei „VM Overrides“ in den allgemeinen Cluster-Setting. Mit „Add“ und einem Klick auf das grüne Plus-Symbol lassen sich dann einzelne VMs hinzufügen und mit individuellen Cluster-Einstellungen versehen, welche die auf HA-Cluster-Level konfigurierten Voreinstellungen überschreiben. Eine der hier anpassbaren Einstellungen ist zum Beispiel die erwähnte „VM restart priority“, die Sie an dieser Stelle VM-spezifisch einrichten können, wenn dem Dialog mehrere VMs hinzugefügt werden.

Direkt darunter finden sich drei in vSphere 6.5 neue Einträge „Start next priority VMs when“, „Additional delay“ und „or after timeout occours at“. Mit „Start next priority VMs when“ können Admins etwa durch Auswahl eines der Einträge „Ressource Allocated“, „Powered On“ „Guest Heartbeat dedected“ oder „App Heartbeats detected“ einstellen, ”wodurch” oder “durch was” der Start der nächsten Priority-Gruppe getriggert wird. Dies erlaubt ein granulares Steuern, wann die jeweils nächst höher priorisierte VM/VM-Gruppe startet. Die beiden letztgenannten Optionen setzen allerdings die VMware Tools voraus.

Das Feature „Orchestrated VM-Restart“ erlaubt ein granulares Steuern, welche VMs in welcher Reihenfolge im Failover-Fall neu gestartet werden.
Das Feature „Orchestrated VM-Restart“ erlaubt ein granulares Steuern, welche VMs in welcher Reihenfolge im Failover-Fall neu gestartet werden. (Bild: Thomas Drilling)

Ist die Start-Priorität an sich festgelegt, lässt sich unter „Additional Boot-Delay“ bei Bedarf einstellen, wie lange HA auf den Start des nächsten Batch wartet. Unter „resources allocated” versteht VMware das pure Scheduling des Batch-Vorgangs selbst, während „Powered On” das Vervollständigen des Power-On-Events als Trigger verwendet oder die Guest- beziehungsweise App-Heartbeat-Erkennung nach dem vollständigen Start der VM samt VMware-Tools und/oder der Anwendung.

Letzteres setzt voraus, dass App-HA aktiviert ist, was wiederum eine „App-HA-awareApplikation benötigt, während „VM-Monitoring“ (Guest-HA) nur das Aktivieren der Funktion in den HA-Settings braucht. Allerdings benötigen beide Funktionen die VMware-Tools für das Austauschen von Guest- beziehungsweise App-Heartbeats zwischen VM und Host.

Proactive HA

Ein weiteres neues Feature in vSphere 6.5 ist „Proactive HA“. Diese Erweiterung für High Availability kann Daten über den Zustand der Server-Hardware (System-Health) verwenden, um VMs via „vMotion“ auf einen anderen Host zu verlagern, noch „bevor“ der betreffende Cluster-Knoten ausfällt.

Das neue Feature „Proactive-HA“ kann VMs per vMotion aus der Gefahrenzone bringen, bevor ein Host ausfällt.
Das neue Feature „Proactive-HA“ kann VMs per vMotion aus der Gefahrenzone bringen, bevor ein Host ausfällt. (Bild: Thomas Drilling)

Auf diese Weise lassen sich Server mit aktuell problematischen Health-Indikatoren per Default in einen Quarantäne-Status versetzen. Optional können Sie im Zusammenhang mit Proactive-HA den Maintenance-Modus antriggern. Proactive HA ist also streng genommen gar kein HA-Feature, sondern eher eine DRS-Funktion, da ja die VM ja gar nicht ausfällt, sondern gegebenenfalls rechtzeitig per vMotion verschoben wird.

Wir erläutern Proactive HA zusammen mit dem ebenfalls neuen Feature „Predictive DRS“ im nächsten Teil dieser Reihe.

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 44566507 / Virtualisierung)