Die Online-Migration eines standalone ESXi Hosts mit verteiltem virtuellem Switch aus einem vCenter Version 4 in ein vCenter Version 5 ist notwendig geworden. Denn bei uns haben sich mehrere Anforderungen (Betriebssystem und Datenbank) an das vCenter System geändert, wodurch ein Update des vorhandenen vCenter in Version 4 nicht möglich war.
Standalone ESXi Hosts bei der ADACOR
Bei der ADACOR gibt es unterschiedliche vServer (VM) Produkte. Einmal mit Hochverfügbarkeit und einmal ohne Hochverfügbarkeit. Im ersten Fall laufen die VMs auf einem ESXi Verbund mit VMware HA wobei die VM-Daten (z.B. virtuelle Festplatte) auf Netzwerkspeicher gespeichert werden. Im zweiten Fall kommen die standalone ESXi Hosts ins Spiel. Die Daten der VMs sind jeweils auf dem lokalen Speicher des ESXi Host (Host) gespeichert und VMware HA wird nicht verwendet.
In beiden Umgebungen werden die Portgruppen/VLANs (pro Kunde/Projekt ein eigenes VLAN) über ein verteiltes virtuelles Switch (dvSwitch) verwaltet. Das dvSwitch hat pro Host mindestens zwei physikalische Uplinkports (Abbildung 1).
Abb. 1: Standalone ESXi Hosts bei der ADACOR .
Problemstellung
Knackpunkt bei allem ist das dvSwitch, über den die Virtuellen Maschinen (VM) mit der Außenwelt kommunizieren. Dieser Switch ist fest an ein vCenter gebunden, denn hierüber wird es zentral verwaltet. Das bedeutet, dass sobald man einen solchen Host mit dem neuen vCenter verbindet, der Host keinerlei Informationen mehr über die Netzwerke der VMs hat und diese dadurch nicht mehr erreichbar sind.
Vorraussetzungen für eine unterbrechungsfreie Migration
Um den Host in das neue vCenter migrieren zu können, wird ein weiterer leerer Host und temporärer Shared-Storage benötigt. In diesem Beispiel eine Network-Attached-Storage (NAS), welcher auf beiden Hosts verfügbar ist. Um im neuen vCenter den migrierten Host wieder an das dvSwitch anbinden zu können, muss die Version des ESXi mindestens Version 5 betragen. Auf dem migrierten Host wird im besten Falle die aktuellste ESXi Version des vierer Releases laufen und muss somit aktualisiert werden. Damit bei diesem Schritt die VMs weiterhin verfügbar sind, müssen diese erst via Datastore-Migration auf den NAS und dann via Host-Migration auf den weiteren Host verschoben werden. Dazu später mehr.
Vorbereitungen
Zunächst legen wir auf dem Host der migriert werden soll (nennen wir ihn Host A) ein normales standard vSwitch an und fügen hier alle Portgruppen mit entsprechendem VLAN-Tag hinzu, so wie sie im dvSwitch existieren. Dieses vSwitch benötigt nun noch einen physikalischen Uplink. Sofern der Host noch freie Netzwerkports hat, kann einer davon dem neuen vSwitch zugewiesen werden. Sollten jedoch alle Ports in Verwendung sein, nehmen wir einen Uplinkport aus dem dvSwitch heraus und benutzen diesen im neuen vSwitch. Die Portgruppen auf diesem Host sind nun nicht mehr redundant am restlichen Netzwerk angebunden. Ein mögliches Ausfallrisiko nehmen wir für den Zeitraum der Migration in Kauf, da die Wahrscheinlichkeit dafür eher gering ist.
Nun muss jede Netzwerkschnittstelle der VMs die auf Host A liegen mit der entsprechenden Portgruppe auf dem neuen vSwitch verbunden werden. Z.B. VM web01 besitzt eine Netzwerkschnittstelle zur Portgruppe „DEV (dvSwitch)“, die Zuordnung wird nun zur Portgruppe „DEV“ geändert, wobei diese Portgruppe dem vorher angelegten vSwitch angegliedert ist. Die Erreichbarkeit der VMs ist hierbei nicht beeinträchtigt (Abbildung 2).
Abb. 2: Die Erreichbarkeit der VMs ist nicht beeinträchtigt.
Migration
Nun sollten alle VMs über ein standard vSwitch mit dem restlichen Netzwerk verbunden sein. Ein solches Standard vSwitch wird von dem jeweiligen Host verwaltet und ist somit auch bei einem Umzug des Hosts in ein anderes vCenter weiterhin verfügbar. Das heißt: wir können an dieser Stelle Host A im vCenter der Version 4 trennen und ins vCenter der Version 5 verbinden. Nun ist der Host schon einmal ins neue vCenter eingebunden, die VMs sind allerdings weiterhin über das standard vSwitch mit nur einem physikalischen Uplink mit der Außenwelt verbunden (Abbildung 3).
Abb. 3: VMs sind weiterhin über das Standard vSwitch mit nur einem physikalischen Uplink mit der Außenwelt verbunden.
Damit wir Host A wieder einem dvSwitch zuweisen können, muss dieser wie bereits erwähnt aktualisiert werden. Denn im vCenter der Version 5 setzt ein dvSwitch auch mindestens die Version 5 beim Hosts voraus.
Bevor wir allerdings Host A aktualisieren führen wir eine Datastore-Migration für alle VMs durch und verschieben alle Daten auf den NAS (Abbildung 4).
Abb. 4: Datastore-Migration für alle VMs und Verschieben aller Daten auf den NAS.
Jetzt können wir mit einer Host-Migration die VMs auf den freien Host (Host B) aus dem Abschnitt „Vorraussetzungen“ verschieben. Wichtig ist hierbei, dass dieser Host auch über ein vSwitch verfügt, dem alle benötigten Portgruppen zugeordnet sind. Bei der ADACOR haben wir an dieser Stelle direkt einen neuen Host mit ESXi5 verwendet und neben dem vSwitch schon mit einem Uplink dem dvSwitch zugeordnet (Abbildung 5).
Abb. 5: Ein neuer Host mit ESXi5 und neben dem vSwitch schon mit einem Uplink dem dvSwitch zugeordnet.
Wenn alle VMs auf Host B verschoben sind können wir wieder pro VM die Portgruppenzuordnung der jeweiligen Netzwerkschnittstelle auf die Portgruppe des dvSwitches ändern. Wenn dies erledigt ist, kann das vorher genutzte vSwitch entfernt werden und der dadurch freigewordene Uplinkport ebenfalls dem dvSwitch hinzugefügt werden. Abschließend verschieben wir wieder per Datastore-Migration die VM-Daten vom NAS auf den lokalen Storage von Host B.
Abb. 6: Datastore-Migration der VM-Daten vom NAS auf den lokalen Storage von Host B.
Nacharbeiten
Mit Hilfe des VMware Update Manager kann Host A auf ESXi5 gepatcht werden, in VMware Sprache heißt das dann „Standardisieren“. Im Update Manager gibt es bereits eine vordefinierte Baseline für solch eine Standardisierung, die wir nun anwenden. Sobald der Host in Version 5 neu gestartet hat, wird die „freie’’ physikalische Netzwerkschnittstelle, die zuletzt dem dvSwitch im vCenter der Version 4 zugeordnet war, dem neuen dvSwitch hinzugefügt.
Host B hat nun Host A vollständig abgelöst und Host A ist für die nächste Migration vorbereitet, so dass Host A den nächsten Host vollständig ablösen wird.