vSphere HA Features in der Zukunft: Restart Order

Auf der Seite Yellow-Bricks ist eine interessante Diskussion über ein mögliches neues Feature des HA Clusters entstanden. Duncan Epping von Yellow-Bricks ist selbst VMware Mitarbeiter. Er und einige seiner Kollegen diskutieren im Kommentarbereich mit Anwendern über eine mögliche neue Funktion und deren Gestaltung.

  • Definition von Abhängigkeiten (Ketten) zwischen VMs
  • Definition von Restart-Gruppen
  • Clusterweite Shutdown und Restart Richtlinien

Die Diskussion ist offen und jeder kann Anregungen zum Thema einbringen.

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.