Cross-vCenter und Long-Distance vMotion in VMware vSphere

Darüber hinaus kann der Admin auch eine Ressource in einem verknüpften vCenter als Ziel wählen. Sind bestimmte Voraus­setzungen erfüllt, dann können die vCenter auch über eine WAN-Verbindung angebunden sein.

Cross vCenter vMotion

Um VMs in ein anderes  vCenter verschieben zu können, ist es erforderlich, dass diese entweder im Enhanced Linked Mode oder Embedded Linked Mode (ELM) verknüpft sind (siehe dazu: vCenter verknüpfen: Enhanced vs. Embedded Linked Mode, externer oder eingebetteter PSC).

Beide vCenter-Systeme müssen dabei nicht unbedingt auf der gleichen Version laufen, auch wenn VMware das dringend empfiehlt. Allerdings wird die Funktion erst ab vSphere 6 unterstützt.

In unserem Beispiel sind beide vCenter auf Version 6.7U3, allerdings läuft nur ein Host-Cluster unter dieser Version, der andere auf Version 6.5 U3. Eine weitere Bedingung besteht darin, dass beide vCenter zeitsynchron sind.

Für die zu verschiebende VM gilt lediglich, dass der für die virtuellen Disks verwendete Datastore über beide vCenter erreichbar ist und dass die Port-Gruppe im Ziel-vCenter existiert bzw. ent­sprechend angepasst wird. Die generellen Voraus­setzungen für das vMotion-Netzwerk gelten natürlich ebenfalls.

Folgende Abbildung zeigt, dass als Ziel-Host ESXi-Maschinen aus beiden verknüpften vCenter angeboten werden.

Natürlich muss sich der VM-Kernel-Adapter auf dem Ziel-Host auch hier im gleichen Layer-2-Segment (VLAN) und im gleichen Layer-3-Subnetz befinden.

Long Distance vMotion

Long Distance vMotion ist eine ab vSphere 6.0 verfügbare Erweiterung der Cross vCenter vMotion. Allerdings empfiehlt VMware ausdrücklich, das Feature erst ab Version 6.5 einzusetzen, weil vorher eine Verschlüsselung nicht unterstützt wird.

Diese Migration eignet sich für Umgebungen, in denen sich vCenter-Server über große geografische Entfernungen verteilen und die Latenzzeit zwischen Standorten hoch ist.

Typische Anwendungs­fälle für vSphere Long Distance vMotion sind beispiels­weise permanente Migrationen, Desaster Recovery und VMware Site Recovery Manager, Lastausgleich an mehreren Standorten oder die Unter­stützung für Follow-the-Sun-Szenarien.

Ein "Follow the Sun" kommt häufig bei der Software-Entwicklung vor, wenn Teams an mehreren Standorten weltweit in verschiedenen Zeit­zonen am gleichen Projekt arbeiten. Jedes Team übergibt mit Long Distance vMotion die Arbeit am Ende eines Tages an ein anderes, indem es die benötigten VMs an den nächsten Standort migriert.

Die Voraus­setzungen, um Long Distance vMotion sinnvoll nutzen zu können, sind allerdings nicht unbeträchtlich,  da sich das vMotion-Netzwerk hier über eine Layer 3-Verbindung erstreckt. Neben der generell für vMotion benötigten Mindest­bandbreite von 250 Mbit/s pro vMotion-Vorgang, die hier über eine WAN-Verbindung zu gewähr­leisten ist, darf auch die Roundtrip-Time im vMotion-Netzwerk nicht größer als 150 Millisekunden sein.

Doch auch für das Netzwerk der virtuellen Maschine, welches natürlich eine ganz normale Layer-2-Verbindung bleibt, gelten bestimmte Bedingungen. So muss es zum Beispiel an der Ziellokation für die virtuelle Maschine die gleiche IP-Adresse geben.

Dazu führt jedes vCenter bei einem vMotion-Vorgang stets mehrere Netzwerk­kompatibilitäts­prüfungen aus. Sie sollen etwa Konflikte mit der MAC-Adresse auf dem Zielhost erkennen, Migration von einem verteilten vSwitch zu einem Standard-vSwitch oder zwischen verteilten vSwitches verschiedener Versionen verhindern. Außerdem soll dadurch die Migration in ein internes Netzwerk, also etwa eines ohne physische Netzwerk­karte, vermieden werden.