Baut keine Frankencluster!

Zu meinen regelmäßigen Lektüren gehört u.a. Duncan Eppings Blog Yellow-Bricks.com. Seinen heutigen Artikel zum Thema “Don’t create a Frankencluster just because you can” möchte ich hier wärmstens empfehlen.

In diesem Kontext geht es auch um das Pinning von VMs auf einen Teil der Hardware Resourcen, um damit Lizenzgebühren zu sparen.Mit einigen Oracle Lizenz-Mythen räumt der Blog Defined by Software im Artikel “Oracle ‘Soft Partitioning’ and vSphere DRS Clusters” auf.

Beide Artikel ein must-read!

HA mit PowerCLI steuern

HA ist ein sehr hilfreiches Cluster Feature von vSphere. Es gibt aber Situationen, da muß man es abschalten oder deaktivieren. Ein Beispiel ist die skriptgesteuerte Abschaltung eines Clusters. Hierbei werden alle VMs beendet und die ESXi Hosts abgeschaltet. Ist dann HA noch aktiv, passieren wilde Dinge. Der letzte ESXi Host versucht alle (inzwischen ausgeschalteten) VMs zu übernehmen, aber diese sind noch auf den anderen Hosts registriert. Dabei ist alles in Ordnung und geplant. Für Notabschaltungen und geplante Wartungen empfiehlt es sich daher HA ganz abzuschalten. Solange ein Admin an der GUI sitzt ist dies kein Problem. Wenn aber die Notabschaltung automatisch ausserhalb der Geschäftszeiten erfolgt, muss HA per Skript deaktiviert werden.

HA deaktivieren

Folgendes Kommando schaltet HA auf allen Clustern ab ohne Rückfrage

Get-Cluster | Set-Cluster -HAEnabled:$false -Confirm:$false

Möchte man HA nur gezielt für einen Cluster (Name MYCLUSTER entsprechend anpassen) abschalten, so ist der Befehl etwas zu modifizieren.

Get-Cluster MYCLUSTER | Set-Cluster -HAEnabled:$false -Confirm:$false

Host Monitoring abschalten

Eine Variante zur Abschaltung von HA ist die Deaktivierung des Host-Monitoring. Dabei bleiben die HA-Agenten auf den ESX Hosts installiert, werden aber inaktiv gesetzt.

Die Steuerung mittels PowerCLI ist etwas umständlicher, aber möglich. In einem Blogbeitrag von ICT-Freak.nl gibt es hierfür ein kleines Script.

Project ONYX

Ein sehr hilfreiches Tool zur Erstellung von Powershell Skripten bietet Project-Onyx. Hiermit kann man Vorgänge an der GUI aufzeichnen und erhält die entsprechenden Powershell Kommandos für die Aktion zurück.

Cluster Migration – EVC Modus

Dies ist ein häufig vorkommendes Szenario: Die ESXi Server eines bestehenden ESX-Clusters sollen durch neue Server ersetzt werden. Dank Techniken wie vMotion ist dies prinzipiell im laufenden Betrieb möglich.

EVC Modus

Der Enhanced vMotion Compatibility (EVC) Mode ermöglicht vMotion Vorgänge zwischen ESXi Hosts mit unterschiedlichen CPU Generationen. Dabei werden Funktionen der moderneren CPU maskiert, um eine einheitliche Basis aller Server im Cluster zu gewährleisten.

Das Szenario

  • ESXi mit intel Generation Penryn, die abzulösen sind
  • ESXi mit intel Ivy Bridge als neue Server
  • EVC im Cluster nicht aktiviert
  • VM Downtime schwierig

Was aber tun, wenn im bestehenden Cluster kein EVC aktiviert ist? Ein Beitritt eines neuen ESXi ist zwar möglich, aber vMotion von den alten ESXi zum neuen wird verweigert wegen CPU Differenzen. Das ist zunächst erstaunlich, den die neue CPU sollte alle Funktionen der alten CPU bieten. Eine Aktivierung des EVC Modus im bestehenden Cluster war nicht möglich, da sich laufende VMs darin befanden. Welche Optionen hat man nun?

Kalte Migration

Eine Möglichkeit die immer besteht, ist die kalte Migration. Das heisst: alle VMs abschalten und dann den EVC Modus aktivieren auf Basis der ältesten CPU im Cluster. Wenn man so weit ist, kann man auch gleich die Server kalt ersetzen und benötigt keinen EVC Modus. In Produktivumgebungen besteht diese Möglichkeit in der Regel nicht.

Live Migration

Die Live Migration ist das Mittel der Wahl in etwa 99% aller Szenarien. Genau an diesem Punkt scheitert man aber, wenn der EVC Modus nicht aktiviert war. Die Lösung ist die Erzeugung eines zweiten Clusters. Diesem treten die neuen Server bei und der EVC Modus wird auf den aktuellen Stand der neuen Server gesetzt (hier: Ivy Bridge i7). Nun kann man die VMs aus dem alten Cluster in den neuen migrieren. Regeln für HA und DRS müssen manuell angepasst werden.

  • Pro: keine Downtime
  • Contra: Clustereinstellungen und Regeln (DRS, HA) gehen verloren

Dabei ist zu beachten, daß alle mit vMotion migrierten VMs weiterhin mit ihren alten CPU Einstellungen laufen. Dies ändern sie erst bei einem Kaltstart (kein Reboot!).

Es ist empfehlenswert alle VMs im neuen Cluster zum nächstmöglichen Zeitpunkt zu beenden und danach neu zu starten. Ein Warmstart (reboot) genügt nicht! Erst dann nutzen die VMs die erweiterten Funktionen der neuen CPU des Hosts.

Der EVC Modus des Clusters sollte auch dann aktiv bleiben, wenn alle Hosts identisch sind. Wenn zu späterem Zeitpunkt ein Host der nächsten Generation zugefügt werden soll, ist das durch direkten Clusterbeitritt möglich.