vSphere: Anzahl HA Hearbeat Datastores zu klein

Unter vSphere5 sorgt der HA Datastore Heartbeat für robustere Überwachung einzelner VMs mit HA. Was früher nur über LAN Heartbeats funktionierte, wird nun auch über den Datastore geprüft. Das sogt für geringere Fehleranfälligkeit durch z.B. Isolation bei Ausfall der LAN Verbindung. Voraussetzung für den HA Datastore Heartbeat sind minimum 2 gemeinsame Datastores (shared volumes). In Testumgebungen hat man gelegentlich aber nur ein gemeinsames Volume für VMs. Das führt zu folgender Fehlermeldung:

The number of vSphere HA heartbeat datastores for this host is 1 which is less than required 2

Letztlich eine kosmetische Sache, aber ich mag keine Fehlermeldungen, die dauerhaft sichtbar sind. Man übersieht dann leicht echte Fehler.  Man kann diese Meldung dauerhaft unterdrücken, indem man in den erweiterten Eigenschaften des HA-Clusters folgende Option eingibt:

das.ignoreInsufficientHbDatastore = true

Den Hinweis zur Lösung fand ich (wie so oft) bei Yellow-Bricks.

Die Eingabe erfolgt natürlich ohne Gleichheitszeichen.

Weiterführende Links

Mehr Info zum Thema Heartbeating bei Yellow-Bricks.

VM restart priority vs. startup order

Ein reales Szenario:

Eine defekte USV soll getauscht werden. Alle Komponenten sind redundant mit Strom versorgt (ein Netzteil an USV, das andere direkt am Stromnetz). Vor der Abschaltung der USV kommt es zu einem kurzen Ausfall im Stromnetz. Die USV ist zu schwach um auch nur diese kleine Schwankung abzufangen. Die Folge: Ein Blackout der vSphere Infrastruktur (ESXi, Storage, Fabric, LAN). Prinzipiell ärgerlich, aber kein Problem. Denn auf allen ESXi Knoten waren zuvor Startreihenfolgen definiert, die genau regeln sollten wann welche VM startet. Leider starteten die ESXi Knoten alle vorher laufenden VMs praktisch zeitgleich, was zu einer erheblichen Belastung der Storage führte (Boot-Storm).

Was war passiert?

Man muss hier zwei unterschiedliche Szenarien unterscheiden:

  • Ordentlicher Kaltstart einer vSphere Infrastruktur nach vorherigen Shutdown aller laufenden VMs
  • Clusterneustart nach Blackout

Letzteres trifft auf den oben beschriebenen Fall zu. D.h. HA bemerkt hier, daß es zu einem Crash kam und versucht alle zuvor aktiven VMs neu zu starten. Die Startreihenfolge auf ESX Ebene ist hier ohne Belang. Alleine HA ist jetzt für den Neustart verantwortlich. Den Ablauf der Ereignisse unter vSphere 5 hat Duncan Epping kurz in einem Artikel skizziert.

Wie kann man steuern, daß nach einem solchen Ausfall nur die Kerndienste neu starten? Eine vor dem Crash zufällig laufende Test-VM sollte z.B. auf keinen Fall unnötig Last auf die Storage bringen und ausgeschaltet bleiben bis sie jemand manuell startet. Die Lösung liegt in den HA Clustereinstellungen.

Unter VM restart priority gibt es vier Optionen:

  • Disabled
  • Low
  • Medium
  • High

Ein möglicher Ansatz

  • Man setzt die VM Neustartpriorität clusterweit auf “Low”.
  • Test-VM und unwichtige VM auf “Disabled”. D.h. selbst wenn sie zum Zeitpunkt des Blackouts liefen, würden sie von HA nicht neu gestartet werden. Das schafft Luft für die elementaren Kerndienste.
  • Unter “High” könnte man z.B. Domaincontroller, DNS/DHCP Server und VirtualCenter (falls virtuell) ansiedeln.
  • Mit Priorität “Medium” kämen weitere wichtige Server, die von Servern der “High”-Klasse direkt abhängig sind. Z.B. Exchange-, Sharepoint- oder SQL-Server.
  • Der ganze Rest, der keine explizite Regel bekam, erhält die Clustereinstellung mit “Low”, also in der dritten Startwelle.

 

 

HA und DRS Audit: der Praxistest

Kürzlich habe ich hier eine Kurzmeldung zum HA und DRS Audit geschrieben. Heute hatte ich endlich einen Moment Zeit, dieses Skript (Version 1.1) zu testen. Ich war überrascht, wie einfach es ist: Skript herunterladen, PowerCLI öffnen, Skript starten, Server und Login eingeben, fertig! 🙂

Die Ausgabe erfolgt in HTML und erinnert stark an vCheck. Kein Wunder – es kommt vom selben Autor Alan Renouf alias Virtu-Al. Die Anwendung ist noch deutlich einfacher geworden. Server und Logindaten können in einer GUI-Maske (vgl. Bild) eingegeben werden.

Danach untersucht das Skript eine Virtuelle Infrastruktur nach Kriterien, die im Buch “HA and DRS Technical Deepdive” von Frank Denneman und Duncan Epping diskutiert werden. Die Ergebnisabschnitte enthalten Empfehlungen und direkte Referenzen auf die entsprechenden Buchseiten zum Thema. Im Bild unten ist beispielhaft ein solcher Verweis dargestellt. Meine Wertung: Daumen hoch! 🙂