DRS Cluster im Ungleichgewicht

Versetzt man einen ESXi Host im DRS Cluster in den Wartungsmodus, so wird die Last (VMs) auf die verbleibenden Hosts verteilt. Wird der Wartungsmodus beendet, kann man häufig beobachten, daß der jetzt frei ESXi Host nicht mit VMs befüllt wird. Auch nach Stunden, oder gar Tagen ist die Last immer noch stark ungleich verteilt. Ich habe mich schon oft gefragt, ob das DRS vielleicht falsch konfiguriert, oder gar defekt ist.

Es ist alles in Ordnung

Die Aufgabe von DRS besteht nicht darin, alle Hosts gleichmäßig auszulasten, sondern VMs die Ressourcen zu bieten, die sie benötigen. Das bedeutet: Wenn ein einziger Host genügend Ressourcen bereit stellt, um die Bedürfnisse aller VMs im Cluster zu bedienen, so besteht kein Grund VMs auf andere Hosts zu verschieben. Denn jede vMotion-Aktion kostet Ressourcen. Steht am Ende der Verschiebung kein Gewinn für die VMs, so ist dies als Verschwendung zu betrachten. Frank Denneman, der als Spezialist in DRS Fragen gilt, erklärt in seinem Artikel “Disabling MinGoodness and CostBenefit” dieses Phänomen und warum man die Parameter MinGoodness und CostBenefit besser nicht manipulieren sollte.

MinGoodness und CostBenefit

Ein VMware KB Artikel erklärt, wie man die obigen Parameter außer Betrieb setzen kann. Doch was ist deren Aufgabe?

CostBenefit

vCenter überwacht das Verhalten aller VMs. Es berechnet, wieviele Ressourcen notwendig sind eine VM von HostA nach HostB zu verschieben. Je nach Last dieser VM können hierfür erhebliche CPU Ressourcen während des Verschiebevorgangs von Nöten sein. Das ist der “Cost” Anteil in CostBenefit. Dem gegenüber steht der Nutzen durch frei werdenden Ressourcen auf dem Quell-Host nach der Verschiebung.

MinGoodness

vCenter wird normalerweise nur VMs auf Hosts verschieben, wenn diese eine geringere mittlere Auslastung haben als der urprüngliche Host. MinGoodness gibt DRS Auskunft, inwieweit die Verschiebung sich auf die Auslastung des Clusters auswirkt.

Setzt man beide Parameter in den erweiterten Eigenschaften des DSR Clusters auf Null, so vermittelt man dem DRS Algorithmus, vMotion Aktionen seien “kostenfrei” und nach dem Umzug muss der Nutzen für Host und VM nicht signifikant höher sein als zuvor.

vCenter neu starten?

Ein billiger Trick, um vCenter zum Ausgleich des Clusters zu bewegen, war bisher der Neustart von vCenter. Der Grund, warum DRS danach bereitwilliger vMotion Aktionen auslöst ist recht einfach erklärt. Durch den Neustart “vergisst” vCenter wie teuer ein vMotion einer bestimmten VM sein könnte, da historische Daten früherer Migrationen dieser VM verloren gehen. Man kann sagen, vCenter lässt sich nur aus Unwissenheit auf eine teure Verschiebung ein.

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.