Schlagwort: vMotion

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.

Veröffentlicht am

PowerCLI: Easy Migration Script

Einen Datastore leeren kann eine sehr mühsame Arbeit sein. Man kann zwar mehrere VMs gleichzeitig auswählen, aber diese müssen im selben Ressourcepool sein damit man sie gemeinsam verschieben kann. Das ganze wird zum Klickdrama. Viel schöner wäre es, wenn man diesen Vorgang mittels PowerCLI automatisieren könnte. Zu meiner Freude fand ich genau so ein Skript. Es basiert auf einer Programmierung von ict-freak.nl und wurde von Richard Yaw erweitert. Die Programmierung basiert auf der PowerCLI und wurde mit einer einfachen GUI ausgestattet.

Download

Easy Migration Tool v2.1 by Richard Yaw

Folgende vMotion Operationen können durchgeführt werden:

  • Host to Host
  • VM to Host
  • Datastore to Datastore
  • VM to Datastore

Bei der Datastore to Datastore Migration kommt als erfreulicher Nebeneffekt hinzu, daß die VMs nacheinander migriert werden und somit das Plattensubsystem nicht unnötig belasten.

Man startet das Skript über die PowerCLI. Es öffnet sich die GUI und man muß nur den vCenter Hostnamen eingeben, den Cluster auswählen und den vMotion Modus festlegen (vgl. oben).

Die Version ist schon etwas älter, funktioniert aber auch unter vSphere 5.1 noch zuverlässig.

So kann man auch größere Datastores über Nacht oder über das Wochenende leeren lassen. 🙂

Links

Veröffentlicht am

vSphere5: Multi NIC vMotion

Betrachtet man vSphere Cluster im produktiven Einsatz, so fällt auf daß immer noch sehr wenige davon mit 10 GB Uplinks ausgestattet sind. Und das meist aus gutem Grund, denn die Hardware ist sehr teuer und auch die Infrastruktur zwischen den ESX-Knoten (Switches, Router, etc.) muß 10 Gbit unterstützen. In der Regel kann man mit mehreren 1Gbit Uplinks sehr gut auskommen und es bedarf schon einiger Mühe einen 1 Gbit NIC zu sättigen. Einzig bei vMotion kann es gelegentlich zu Engpässen kommen, weswegen von mir in der Vergangenheit der Management Traffic vom VM-Network logisch getrennt wurde und die Adapter nur wechselseitig als Standby zur Verfügung standen.

Eine wirklich tolle Eigenschaft von vSphere5 ist mir aber bis vor kurzem entgangen: Multi-NIC vMotion. Hierbei wird der Datenverkehr über mehrere physische NICs geleitet. Es bedarf mindestens zweier NICs mit je einer VM-Kernel Portgruppe und ähnelt dem Verfahren zum Aufbau einer iSCSI-Portgruppe. Nur daß sich hier beide vmk Portgruppen im selben IP Subnetz befinden. Diese Funktion ist nicht nur bei mehreren gleichzeitigen vMotion Transaktionen nützlich, sonder auch schon bei einer einzelnen.

Manuelle Einrichtung

Wir brauchen dazu entweder zwei vSwitches mit je einem vmnic und je einer vmkernel Portgruppe, oder wir verwenden einen vSwitch mit zwei vmnics und zwei Portgruppen. Letztere Variante gefällt mir persönlich besser.

  • Einen vSwitch erstellen und diesem zwei NICs zuordnen (Bsp: vmnic1, vmnic2)
  • zwei vmkernel Portgruppen erstellen (Bsp: vMotion1, vMotion2), mit IP Adressen aus dem gleichen Subnetz.
  • Switch failover-order umgehen.
  • vMotion1 mit vmnic1 (active), vmnic2 (standby)
  • vMotion2 mit vmnic2 (active), vmnic1 (standby)

Achtung Bug!: Derzeit existiert noch ein Problem in vSphere5, wenn zwei Kernelports auf dem selben Virtual Standard Switch vorhanden sind. Das Problem wurde ausführlich im Blogartikel von VMtoday beschrieben und ist ab vSphere5 U1 behoben.

Skriptgesteuerte Einrichtung

Bei mehreren Hosts ist eine Automatisierung wichtig. Die manuelle Einrichtung ist nicht nur mühsam, sondern auch fehleranfällig. Im Diskussionsbereich des Artikels zum Thema Multiple-NIC-vMotion auf Yellow-Bricks werden Skripte in unterschiedlichen Skriptsprachen gelistet. Darunter auch vSphereCLI und PowerCLI.

Links

Frankdenneman.nl: Multi-NIC vMotion support in vSphere5
VMtoday: vSphere 5 Networking Bug #2 Affects Management Network Connectivity
Yellow-Bricks: Multiple-NIC vMotion in vSphere 5
VMware Pubs [PDF]: Networking-Guide