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.

NTFS Sicherheit: Ersteller Besitzer Objekt

Ein Verzeichnis soll für zwei Benutzergruppen zugänglich sein. Gruppe „Edit“ soll lesen, schreiben und verändern dürfen. Die zweite Gruppe „Public“ soll nur lesen dürfen, aber keine Daten verändern. Klingt einfach – und ist es eigentlich auch. Dennoch zeigt der Ordner ein eigenwilliges Verhalten: Jeder in der Gruppe Public konnte Dateien erstellen und diese auch ändern. Ursache war, daß es neben den Gruppen Public und Edit noch die Gruppe „Ersteller Besitzer“ gab.

Die Gruppe „Ersteller Besitzer“ kann problemlos entfernt werden. Sobald dies erfolgt ist, greifen die Zugriffsrechte wie oben geplant.

Links

 

vSphere5.1: IODM mit esxcli

I/O Device Management (IODM)

Mit vSphere 5.1 kamen neue Funktionen zum Monitoring von Storage Adaptern zur esxcli hinzu. Der Namespace storage san hilft bei der Überwachung von iSCSI, FC, FCoE und SAS Protokollen. Der namespace

Verbindung zum Server

Zunächst muss dem Befehl eine Verbindungsinformation übergeben werden. Nach absenden des Befehls fragt der ESXi nach Nutzer und Kennwort. Diese können wahlweise auch direkt übergeben werden.

  • –username=<myuser>  | -u=<myuser>
  • –password=<mypassword> | -p=<mypassword>
esxcli --server <ESXi Hostname> storage san <protocol> <cmd> <options>

Mit Übergabe der Zugangsdaten:

esxcli --server myESX.domain.com --user=root --password=mypassword storage san FC list
  • protocol: [FC | iSCSI | FCoE | SAS]
  • cmd: list, stats get, events get, reset
  • options: [–adapter | -A] vmhba<nummer>

Zeige Adapter

esxcli --server myESX.domain.com storage san FC list

esxcli_san01Selektive Auswahl nur eines speziellen Adapters:

esxcli --server myESX.domain.com storage san FC list --adapter vmhba4

esxcli_san02

Zeige Adapter Statistiken

esxcli --server myESX.domain.com storage san FC stats get

esxcli_san03Auch hier lässt sich die Auswahl mit der (–adapter) Option wieder auf einen speziellen vmhba begrenzen.

 

Links

VSphere5.1: VMDK oder RDM?

Eine Diskussion, die immer wieder geführt werden muss, ist die Entscheidung ob für spezielle Anwendungen ein Raw Device Mapping (RDM) anstatt vDisk Containern (vmdk) eingesetzt werden soll. Die Debatte bekommt nun neue Argumente zugunsten der VMDK. Tatsächlich sieht ein neuer Benchmark im vSphere-Blog beide Alternativen auf Augenhöhe, jedoch gewinnt der vmdk Container wegen seiner höheren Flexibilität.

blogged somewhere in time…