Rassco - Fotolia

vSphere High Availability: Neuerungen in vSphere 6.5 zum Ressourcen-Management

Mit vSphere 6.5 aktualisiert VMware auch vorhandene Funktionen zum Ressourcen-Management. Davon profitiert vor allem vSphere High Availability.

Neben einigen neuen Funktionen in vSphere 6.5 hat VMware seiner Virtualisierungs-Lösung mit dem kleinen Versionssprung auch Updates bestehender Features spendiert. Darunter fällt auch eine Überarbeitung des Ressourcen-Managements mit vSphere, etwa beim Distributed Resource Scheduler (DRS) oder bei vSphere High Availability (HA).

Neue Standardeinstellungen für die HA-Zugangssteuerung

Bis zu vSphere 6 bestand die Standardeinstellung der Zugangssteuerung (Admission Control) für vSphere High Availability in der Slot-Berechnung, um so die Anzahl tolerierbarer Host-Ausfälle zu bestimmen. Die Slot-Berechnung führt allerdings zu Problemen, wenn sehr heterogene VM-Reservierungen vorliegen. Wenn man beispielsweise einige virtuelle Maschinen ohne Ressourcenreservierung hat und einige mit Reservierungen von 8 GB RAM, dann führt das dazu, dass virtuelle Maschinen mit 4 GB RAM einen 8-GB-Slot beanspruchen.

In früheren vSphere-Versionen ließ sich auch eine prozentbasierte Einstellung verwenden, was aber oft zu einem Overcommitment des Clusters führte, weil Administratoren die Prozentzahlen zu niedrig wählten. In noch schlimmeren Fällen kam es auch vor, dass die Richtlinie zur Zugangssteuerung ein Fehlen freier Ressourcen meldete, was viele Administratoren die Funktion schlicht deaktivieren ließ.

Wie Abbildung 1 zeigt, wurde die Standardeinstellung mit vSphere 6.5 so verändert, dass vSphere auf Basis der maximal tolerierbaren Host-Ausfälle automatisch den Prozentwert vorgibt. In einer Cluster-Konfiguration mit vier Knoten würde der Prozentsatz demnach bei 25 Prozent liegen, womit also ein Host ausfallen könnte, ohne hierdurch die Verfügbarkeit des Clusters zu gefährden.

Abbildung 1: Konfiguration der High-Availability-Einstellung.

VM-Startreihenfolge nach einem Host-Ausfall

Sobald in einer Cluster-Konfiguration ein ESXi-Host ausfällt, werden die dort ausgeführten virtuellen Maschinen automatisch auf einem anderen Host neu gestartet. An sich ist das natürlich genau das gewünschte Verhalten in einem Failover-Cluster, aber wenn eine virtuelle Maschine von einer anderen abhängig ist, dann könnte das Starten einer Applikation fehlschlagen und der Dienstausfall anhalten.

Mit vSphere 6.5 kann hier eine Liste an gegenseitigen Abhängigkeiten für virtuelle Maschinen hinterlegt werden, wodurch sich die Startreihenfolge festlegen lässt. Die Funktion nennt sich Orchestrated Restart und richtet sich an Anwendungsfälle wie Multi-Tier-Anwendungen. Ein Datenbankserver beispielsweise muss vor dem Anwendungsserver online sein, damit letzterer während des Startens auf die Datenbank zugreifen kann. Wenn der Applikations-Server vollständig geladen wurde, ist es schließlich an der Zeit, den Webserver hochzufahren.

Ein weiteres Beispiel wäre die geordnete Startreihenfolge von Infrastruktur-VMs, etwa Domänen-Controller, DNS- oder DHCP-Server (Domain Name System und Dynamic Host Configuration Protocol). Diese Funktion gab es auch bisher bereits mit der Restart Priority, allerdings gab es hierbei keine so exakten Kontrollmöglichkeiten über den Startzeitpunkt und Verzögerungen.

Mit der neuen Funktion in vSphere 6.5 lassen sich diese VM-Abhängigkeiten mit einer neuen VM/Host-Regel definieren, die Virtual Machines to Virtual Machines heißt. Das Beispiel aus Abbildung 2 zeigt eine Regel, die zunächst virtuelle Maschinen der VM-Gruppe Infrastructure VMs startet, und erst dann VMs der Gruppe Database.

Abbildung 2: Beispiel einer VM/Host-Regel in vSphere 6.5.

Bei einzelnen virtuellen Maschinen mag es noch nicht wichtig sein, sie in Gruppen anzuordnen. Wenn es aber um dutzende oder mehr virtuelle Maschinen geht und komplexe Abhängigkeiten bestehen, dann empfiehlt sich dringend der Einsatz entsprechender App-Gruppen. Andernfalls werden virtuelle Maschinen, die keiner Gruppe angehören, einfach zufällig gestartet. Eine Anordnung mit drei Gruppen könnte wie in Abbildung 3 aussehen. Nachdem die Infrastruktur-VMs gestartet wurden, wird zunächst der Datenbankserver hochgefahren. Im Anschluss daran starten die Anwendungs-Server in Phase 2 und die Webserver in Phase 3.

Abbildung 3: Eingerichtete VM/Host-Regeln.

Eine weitere Einstellung muss allerdings noch konfiguriert werden, bevor die Funktion genutzt werden kann. Bei einem Ausfall wird der nächste Schritt nur dann eingeleitet, wenn die virtuellen Maschinen in der vorherigen Stufe alle hochgefahren sind und die nötigen Ressourcen zugewiesen bekommen haben. Dieses Verhalten gilt auch, wenn die Priority-Einstellung verwendet wird: Erst wenn alle virtuellen Maschinen mit hoher Priorität gestartet wurden, wandert vSphere High Availability ein Level tiefer und startet die VMs mit mittlerer Priorität.

Nur weil eine virtuelle Maschine hochgefahren ist, bedeutet das aber nicht, dass Betriebssystem oder virtuelle Maschinen auch bereit sind. Daher ist es wichtig, die neue Einstellung zur VM-Abhängigkeit so zu konfigurieren, dass vSphere High Availability erst dann zur nächsten Phase übergeht, wenn bestimmte Bedingungen erfüllt sind. Wie Abbildung 4 zeigt, lässt sich hier die Option Guest Heartbeats detected auswählen. Diese Bedingung wird ausgelöst, sobald die VMware-Tools der virtuellen Maschine starten. Damit wird aber immer noch nicht sichergestellt, dass eine Applikation auch vollständig läuft. Hierfür sollte also besser die Option App Heartbeats detected ausgewählt werden.

Diese Restart-Bedingungen werden ebenfalls verwendet, wenn vSphere High Availability von einer Prioritätsebene auf eine andere wechselt. Auch ohne jede Regel zur VM-Abhängigkeit ist es also in jedem Hochverfügbarkeits-Cluster wichtig, diese Option zu konfigurieren. 

Abbildung 4: Restart-Bedingungen in vSphere 6.5.

Die Funktion zur Überwachung des Anwendungsstatus wird in der Praxis allerdings kaum verwendet, vor allem, nachdem VMware vSphere App HA 2015 abgekündigt hat. Die Programmierschnittstelle für dieses Feature wurde allerdings trotzdem aktualisiert, um auch mit vSphere 6.5 zu funktionieren.

Veritas ApplicationHA ist eines der wenigen Produkte, die hierauf aufbauen. Die meisten VMware-Kunden nutzen allerdings keines der hierfür noch erhältlichen Produkte. Zudem liefert dieser Abhängigkeits-Check nicht vollständig, was er verspricht. Für Datenbankserver ist es beispielsweise nicht ungewöhnlich, länger für das Starten zu benötigen als die VMware Tools. Damit wird im High-Availability-Prozess die nächste Phase ausgelöst, bevor die hierfür eigentlich benötigte virtuelle Maschine wieder verfügbar ist. Als Lösung für dieses Problem sind manche Administratoren dazu übergangen, eigene Skripte zu schreiben, um die Verfügbarkeit wichtiger Services vor dem Starten davon abhängiger Maschinen sicherzustellen.

Folgen Sie SearchDataCenter.de auch auf Twitter, Google+, Xing und Facebook!

Artikel wurde zuletzt im Januar 2017 aktualisiert

Erfahren Sie mehr über Containervirtualisierung

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close