Schlagwort: EVC

Veröffentlicht am

ESXi Host Recovery mit Hindernissen

Verbindung mit EVC Cluster scheitert nach ESXi Host Restore

Der Austausch von defekten ESXi Bootmedien wurde inzwischen leider zur Routine. Der Gund sind Flashmedien von schlechter Qualität und daher kurzer Lebensdauer. Man muss hier allerdings fairerweise anfügen, daß einige Kunden günstige USB-Sticks als Bootmedium verwenden. Im Homelab ist das praktisch, im Produktivcluster eine schlechte Idee.

Die übliche Prozedur dafür ist recht einfach:

  • Host Konfiguration exportieren
  • Host räumen und herunterfahren
  • Neues Bootmedium vorbereiten mit einem ISO, das den selben oder einen niedrigeren Patchlevel hat, als die ursprüngliche Installation.
  • Frisch installierten Host booten
  • IP Adresse (temporär) vergeben, falls kein DHCP Server erreichbar ist
  • Hostkonfiguration wiederherstellen
  • Mit Cluster verbinden
  • Fehlende Patches nachinstallieren

So weit, so gut. Aber letzte Woche wurde die Routineaufgabe zur Herausforderung.

„ESXi Host Recovery mit Hindernissen“ weiterlesen

Veröffentlicht am

VM Template in Clustern mit heterogenen CPU Generationen

Probleme bei der Ableitung vom Template

Ich konnte in der Vergangenheit immer wieder beobachten, dass die Ableitung vom Template gelegentlich scheiterte und die neue VM in einem endlosen Sysprep fest hing. Eine erneute Ableitung führte oftmals zum Erfolg, aber die Hintergründe waren mir bislang unklar. Nur durch Zufall bin ich heute auf die Ursache des gestoßen. Die VM war für automatische Anmeldung als Administrator konfiguriert und ich konnte sehen was unmittelbar vor dem Sysprep Versuch passierte. Es wurde ein Treiber für die CPU installiert und der Anwender zu einem Neustart aufgefordert.

sysprepCPU03Dies ist erstaunlich, da das Template der VM zuvor intensiv mit Updates versorgt und mehrfach neu gestartet wurde. Warum also wird nach dem Ableiten ein neuer CPU Treiber installiert?

Dazu muss man verstehen, dass sich der der beschriebene Cluster aus zwei unterschiedlichen Typen von Intel Servern zusammensetzt.

  • Xeon E5-2640 – Dual Socket Hexa-Core
  • Xeon E5-2690 v3 – Dual Socket Dodeca-Core

Durch EVC wurde die vMotion Komaptibilität zwischen den Hosts sichergestellt, dennoch muss das Template jeden Host Typ einmal “sehen”, um den passenden CPU Treiber zu installieren. Passiert dies erstmalig nach dem ableiten, so ist der Sysprep Vorgang gestört und scheitert.

Prevention

Es zeigt sich, daß es eine gute Praxis ist, ein Template auf jedem Host Typ im Cluster mindestens einmal zu booten. Sind erst alle Treiber installiert gibt es auch keine Probleme mehr bei der Ableitung.

 

Veröffentlicht am

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.