vSphere HA

Tuesday, 25 October 2011 10:48:05 (W. Europe Daylight Time, UTC+02:00)
Bis zur Version 4.1 verwendete VMware die Bezeichnung VMware HA für seine "Hochverfügbarkeitslösung" auf Cluster Ebene. Die verwendete Software war dabei eine Dringabe von der Mutter EMC.
Der HA Agent basierte auf dem Legato AAM <-- Advanced Availability Manager. Dieser wurde durch VMware angepasst und dann für die Clusterumgebung eingesetzt. Dabei besteht die Lösung aus einem Agentensystem, bei dem es Primary und secondary Nodes (Agenten) gibt. Nur die primary Nodes sind dabei fähig HA Fälle zu erkennen und VM-Operationen auszulösen (kurz gesagt).
In der Vergangenheit gab es öfter Probleme mit der HA Konfiguration, da die Funktionsweise des AAM Agenten, eigentlich nicht zu dem Einsatzzweck unter VMware vSphere passte.

Beispiel:

Wenn ein Kunde ein HA Cluster mit acht oder zehn Knoten besitzt und dieses Cluster auf zwei Brandabschnitten liegt <-- innerhalb eines LANs, dann kann es dazu kommen, dass alle funktionsbereiten HA Primary Nodes auf einer Seite sind, da die Auswahl der Primary Nodes einem Automatismus unterlag, analog zu der Master-Browser-Election unter Microsoft Windows Systemen. Das heisst die Primäre Ordnung der HA Agenten passt eventuell nie zu der Lokalisierung der physischen Hosts. Ist kein HA Primary Node verfügbar, dann kann HA nicht reagieren!
Somit kann bei Ausfall eines (Brand-)Abschnitts die skurile Situation entstehen, dass KEINE VM neu gestartet wird!

Mit VMware vSphere HA wurde das gesamte Agentensystem umgeschrieben. Nachwievor gibt es Agenten, die auf den ESXi Knoten installiert werden, allerdings gibt es jetzt eine Master-Slave Situation, bei der es immer nur EINEN Master pro Cluster gibt. Ist der Master nicht erreichbar, wird umgehend eine Wahl / Promotion innerhalb des Clusters durchgeführt, so dass ein Master wieder zur Verfügung steht. Die Slave-Hosts tragen in erster Linie zum Cluster bei, indem sie virtuelle Maschinen lokal ausführen, ihren Laufzeitstatus überwachen und Zustand-Updates an den Master-Host melden. Ein Master-Host kann auch virtuelle Maschinen ausführen und überwachen. Sowohl Slave-Hosts als auch Master-Hosts implementieren die VM- und Anwendungsüberwachungsfunktionen.

Eine der vom Master-Host ausgeführten Funktionen ist das Schützen von virtuellen Maschinen. Wenn eine virtuelle Maschine geschützt ist, garantiert vSphere HA, dass versucht wird, sie nach einem Ausfall erneut zu starten. Ein Master-Host verpflichtet sich, eine virtuelle Maschine zu schützen, wenn erkannt wird, dass als Reaktion auf eine Benutzeraktion der Betriebszustand der virtuellen Maschine von „Ausgeschaltet“ in „Eingeschaltet“ geändert wurde. Wenn ein Failover durchgeführt wird, muss der Master-Host die geschützten virtuellen Maschinen, für die er verantwortlich ist, neu starten. Diese Verantwortung wird dem Master-Host auferlegt, der eine vom System definierte Datei auf dem Datenspeicher exklusiv gesperrt hat, auf dem sich die Konfigurationsdatei der virtuellen Maschine befindet.

vCenter Server meldet anhand des vSphere HA-Hostzustands, ob es sich bei einem Host um einen Master-Host oder einen Slave-Host handelt. Dieser wird auf der Registerkarte Übersicht des Hosts im vSphere-Client und in der Ansicht „Hostliste“ für einen Cluster oder ein Datacenter gemeldet, wenn die Spalte „HA-Status“ aktiviert wurde. Der HA-Status „Wird ausgeführt (Master)“ gibt an, dass der Host als vSphere HA Master-Host dient. Der Zustand „Verbunden (Slave)“ gibt an, dass der Host als vSphere HA-Slave-Host dient. Es gibt weitere Statuszustände, um anzugeben, wann eine Wahl stattfindet oder ein Fehler aufgetreten ist. Die Registerkarte Übersicht des Hosts bietet einen Link neben dem vSphere HA-Zustand des Hosts, der den aktuellen Zustand erläutert

VMware vSphere 4.0 und das HA Cluster

Friday, 31 July 2009 08:31:27 (W. Europe Daylight Time, UTC+02:00)
Mit VMware vSphere 4.0 hat VMware auch die HA (High Availability) Funktion überarbeitet.
Neben der neuen Version des HA Agenten wurden neue Funktionen in das HA Cluster integriert. Neben der nützlichen Funktion, dass man einen Standard Failover Host über die GUI setzen kann, kann man nun auch die Überhang Ressourcen in Prozentwerten definieren, um zum Beispiel nur 15% der Ressourcen für HA zu reservieren. Unter der Haube hat sich einiges geändert, die Berechnung der HA Cluster Failover Quoten und der Cluster-Health (grün ist schön :-D) erfolgt jetzt auf Basis von so genannten Slots. Dabei werden die Cluster-Ressourcen in kleinere Einheiten, den Slots, eingeteilt auf Basis eines Algorithmus, die Slotgröße definiert. Danach wird die Slot Gesamtanzahl umgelegt auf das Cluster und die Slots werden "verteilt". Wie das Ganze abläuft und welche Optionen neu sind demnächst hier...

VMware HA Konfiguration und Fehlermeldungen

Saturday, 07 February 2009 11:42:17 (W. Europe Standard Time, UTC+01:00)
Hier ist er der zweite Teil zum Thema HA Konfigurationen. Immer wieder melden sich Kunden bei mir, dass die HA Konfiguration ihrer Cluster nicht konsistent funktioniert, ESX Server einen Fehler in der HA Agentenkonfiguration melden oder das HA Cluster anscheinend Warnungen ausgeben, da nicht genügend "FailOver"-Kapazitäten vorhanden sind. Im ersten Teil des Berichts bin ich näher auf die einzelnen Parameter der HA Konfiguration zu sprechen gekommen. In diesem zweiten Teil dreht sich alles rund um die Fehleranalyse und Behebung.

VMware HA Konfiguration und Fehlermeldungen

Wednesday, 26 November 2008 21:55:25 (W. Europe Standard Time, UTC+01:00)
Ich dachte zu dem Thema sei alles erklärt und die Karten lägen offen auf dem Tisch, aber weit gefehlt! In meinen Dokumenten habe ich zwar meine Erfahrungen und Empfehlungen zum Thema HA und Fehlermeldungen mit meinem Team ausgetauscht, aber leider hatte ich bis jetzt noch nicht die Gelegenheit alle Funktionsweisen, Parameter und Tipps zu veröffentlichen, ich gelobe Besserung und fange direkt mal mit den "un-"dokumentierten Parametern für VMware an. Parameter für VMware HA Auf der Website von der Niederländischen VMUG bin ich fündig geworden

VMware Virtual Center 2.5.0 Update 3 ist da!

Saturday, 04 October 2008 07:46:08 (W. Europe Daylight Time, UTC+02:00)
Das jüngste Update Paket für das VirtualCenter beseitigt unter anderem Probleme mit dem Wartungsmodus & dem UpdateManager!



Wie immer im Verborgenen erblickte das neueste Kind von VMware das Licht der Welt. Das Update 3 ist da!
Da es in der bisherigen Version erhebliche Probleme mit der Berechnung der HA Kapazitäten in Verbindung mit dem UpdateManager und der benötigten vMotion Technologie gab, hat VMware diesen Schritt vorgezogen. Aber erstmal alles Schritt für Schritt:

Problem:
Insbesondere in kleineren Umgebungen mit zwei oder drei ESX Servern kann man einen produktiven ESX Server nicht mehr so einfach in den Wartungsmodus versetzen, insbesondere dann, wenn auch noch VMware HA auf Clusterebene eingestellt worden ist. Der Server startet mit dem Wartungsmodus und bleibt bei genau 2% stehen, bricht mit Fehler ab.
Betrachtet man af der Zusammenfassungseite die Clusterkonfiguration stellt man fest, dass die konfigurierte Failover Quote für HA auf ein Host eingestellt ist und die verfügbare Clusterkapazität den Ausfall von "NULL" Hosts erlaubt?!
Der kluge Administrator baut vor und hat extra für das kleine Cluster eingestellt, dass auch dann im HA Fall VMs neu gestartet werden, wenn die Kapazitätsgarantien für die VMs auf "erlaubt" gestellt.
Zusätzlich wurden die das.VmMemoryMinMB und das.VmCpuMinMHz gesetzt und trotzdem nix Wartungsmodus!?

Workaround:
Temporär die Clusterfunktion HA ausschalten. Die Konfiguration des Clusters geht dabei NICHT verloren (liegt in der VCDB) und im Anschluss an die Updateeinspielung wieder einschalten. Dabei wierden zunächst die Konfiguration und Pakete vom ESX Server deinstalliert und entfernt und im Anschluss wieder neu installiert.

Lösung:
Das Update 3 für VMware VirtualCenter behebt dieses Problem, auch in kleinen Clustern mit zwei bis drei Hosts klappt das einstellen des Wartungsmodus jetzt wieder problemlos und man kann auch über den UpdateManager wieder Patches einspielen.

demnächst mehr zum Thema VI 3.5 Update 3 hier!