Konzepte und bewährte Verfahren für vMotion

HCX ist im Wesentlichen ein vMotion-Zweiwege-Proxy. Jede HCX-Instanz emuliert einen einzelnen VMware ESXi™-Host innerhalb des vSphere Rechenzentrums, außerhalb von Clustern. Die HCX-Instanz ist eine "Front" für die Cloud-Gateway-Flottenkomponente (CGW). Für jeden HCX-Standort wird ein Proxy-Host angezeigt, der mit dem aktuell angezeigten Standort verknüpft ist. Wenn eine vMotion auf einen fernen Host eingeleitet wird, migriert der lokale ESXi-Host diese VM auf den ESXi-Host des lokalen Proxy-Hosts.

Eine vMotion-Migration wird vom fernen ESXi-Proxy-Host zu dem physischen ESXi-Zielhost von vSphere initialisiert, während Daten vom Quell-CGW über den Tunnel empfangen werden. Wenn vMotion verwendet wird, wird im Gegensatz zur Massenmigrationsoption nur eine einzige VM-Migrationsoperation ausgeführt. Bei vielen zu migrierenden VMs wird daher empfohlen, vMotion nur dann zu verwenden, wenn eine Ausfallzeit nicht in Frage kommt oder wenn das Risiko eines Neustarts der VM besteht. Allerdings kann die VM wie bei der Standard-vMotion während des Prozesses aktiv sein.

Eine einzelne vMotion erreicht ihre Höchstgrenze bei etwa 1.7 Gbps im LAN und 300 - 400 Mbps im WAN durch den WAN Optimizer. Dies bedeutet nicht, dass 1,7 Gb/s im LAN 400 Mb/s im WAN über das WAN-Optimierungsprogramm entsprechen, sondern dies sind die festgestellten Maximalwerte in bestimmten Umgebungen. Eine solche Umgebung bestand aus einem vMotion-Netz mit 10-GB-LAN und einem Internet-Uplink mit 1 GB, die gemeinsam mit dem Webdatenverkehr der Produktionsumgebung genutzt wurden.

Verwenden Sie vMotion in den folgenden Fällen:

• Wenn die VM schwer herunterzufahren oder zu starten ist oder wenn die Betriebszeit lang ist und Risiken durch das Herunterfahren der VM entstehen können.
• Für jede clusterartige Anwendung, die Festplatten-UUIDs benötigt, wie Oracle RAC-Cluster. vMotion ändert die Festplatten-UUIDs am Zielort nicht.
• Wenn Sie eine einzelne VM so schnell wie möglich versetzen möchten.
• Wenn eine geplante Migration nicht erforderlich ist.

Konzepte und bewährte Verfahren für die Massenmigration

Die Massenmigrationsfunktion von HCX verwendet die vSphere-Replikation, um Plattendaten zu migrieren, während die VM auf der Zielinstanz von vSphere HCX neu erstellt wird. Bei der Migration einer VM wird der folgende Workflow verwendet:

• Erstellung einer neuen VM auf der Zielseite und den entsprechenden virtuellen Platten.
• Replikation der VM-Daten auf der neuen VM. Die Replikation beginnt, sobald der Assistent abgeschlossen ist, unabhängig von der Zeitplanung für die Umschaltung.
• Abschalten der ursprünglichen VM.
• Während des Abschaltzeitraums erfolgt die endgültige Replikation aller Datenänderungen.
• Einschalten der neuen VM auf der Zielseite.
• Umbenennen und Verschieben der ursprünglichen VM in den Cloudordner, in den sie verschoben wurde.

Die Massenmigration bietet gegenüber vMotion folgende Vorteile:

• Gleichzeitige Migration mehrerer VMs.
• Konsistentere Bandbreitennutzung. vMotion kann Schwankungen bei der Bandbreitennutzung generieren, die als Spitzen und Täler innerhalb der Netzwerküberwachungstools oder der WAN-Opt-UI sichtbar wären.
• Verwenden Sie Massenmigration, um eine Gesamtnutzung einer Netzbandbreitenkapazität zu erzielen, die höher ist, als wenn Sie eine einzelne vMotion verwenden.
• Die Massenmigration kann geplant werden, um während eines geplanten Ausfallfensters zu den neu migrierten VMs umzuschalten.
• Migration von VMs zulassen, die derzeit virtuelle CPU-Features verwenden, die sich von der Cloudseite unterscheiden. In diesen Fällen kann die vMotion-Migration fehlschlagen.

Folgende Nachteile hat die Massenmigration gegenüber vMotion:

• Einzelne VMs werden sehr viel langsamer migriert als mit vMotion.
• Die VM erfährt eine kurze Ausfallzeit, während die neue Klon-VM auf der Zielseite erstellt wird.
• VMs, die von der Plattenbestellung und von Platten-UUIDs (Oracle RAC) abhängig sind, können Probleme aufweisen und ihre Platten werden möglicherweise anders angezeigt, wenn die UUIDs geändert werden, wodurch sich die Betriebssystempfade in die Einheiten der virtuellen Platte ändern können.

Cluster mit gemeinsam genutzter Platte

Oracle RAC-, MS Exchange- und MS-SQL-Cluster sind Beispiele für Anwendungen, in denen zwei oder mehr VMs an einem Cluster teilnehmen, der eine gemeinsam genutzte Platte für alle VMs oder Clusterknoten erfordert. Das VMware® Multi-Writer-Flag muss auf allen VM-Knoten für Festplatten aktiviert werden, die Teil des Anwendungsclusters sind (virtuelle Festplatten ohne Betriebssystem). VMs, bei denen das Multiwriter-Flag für eine virtuelle Festplatte aktiviert ist, werden nicht unterstützt.

Lesen Sie die folgenden Informationen zur Migration eines Cluster mit aktivierter virtueller Multi-Writer-Platte:

• vMotion wird verwendet, da die ursprünglichen VM-Platten- und UUID-Zuordnungen beibehalten werden.
• Der Cluster bleibt während der Migration in einem herabgesetzten Zustand (Einzelknoten).
• Der Cluster erfährt eine Ausfallzeit vor dem Start der Migration und nach Abschluss der Migration, um die Multi-Writer-Konfiguration über die Cluster-VMs hinweg neu zu erstellen.

Führen Sie die folgenden Schritte aus, um einen Cluster mit aktivierter Multi-Writer-Platte zu migrieren:

1. Schalten Sie den Cluster und alle Knoten gemäß dem bewährten Verfahren für die jeweilige Anwendung aus.
2. Vermerken Sie die Plattenreihenfolge, wenn die Anwendung dies erfordert, in jeder Knoten-VM für die für Multi-Writer konfigurierten virtuellen Platten.
3. Bei Oracle und jeder anderen Anwendung, die die UUID-Funktion der virtuellen Platte verwendet, melden Sie sich bei einem ESXi-Host an und führen Sie den Befehl vmkfstools -J getuuid /vmfs/volumes/datastore/VM/vm.vmdk aus. Mit diesem Befehl wird die UUID jeder virtuellen Plattendatei abgerufen, für die das Flag 'multi-writer' für den Cluster eingestellt ist. Dieser Schritt ist erforderlich, wenn das bewährte Verfahren Plattenbestellungen an der Art und Weise ausrichtet, wie der Pfad im Betriebssystem angezeigt wird. vMotion kann die Reihenfolge der Platten (disk1, disk2, disk3) ändern, aber die UUIDs bleiben unverändert. Wenn die Migration abgeschlossen ist, verwenden Sie die angegebene UUID, um die Platteninformationen zuzuordnen, um die Plattenbenennungsbestellung und die SCSI-ID bei Bedarf erneut zu erstellen. Diese Informationen können bei der Fehlerbehebung hilfreich sein, wenn eine Oracle-Instanz über viele zugeordnete virtuelle Platten verfügt.
4. Entfernen Sie die virtuellen Platten aus allen Cluster-VMs mit Ausnahme der als primär erachteten VM.
5. Entfernen Sie das Multiwriter-Flag von der primären Cluster-VM (die einzige, die Eigentümerin der Cluster-Festplatten ist).
6. Schalten Sie den primären Cluster ein, falls dies für die minimale Ausfallzeit erforderlich ist.
7. Migrieren Sie alle Clusterknoten mit vMotion. Migrieren Sie zuerst den primären Cluster. Migrieren Sie alle anderen Knoten, nachdem sie ausgeschaltet wurden.
8. Nachdem der primäre Knoten, der Eigner der Platten ist, die Migration abgeschlossen hat, schalten Sie ihn aus.
9. Falls erforderlich, ordnen Sie die Plattenreihenfolge mit der richtigen Platten-UUID und iSCSI-ID erneut zu. Für die Funktion der Anwendung ist keine erneute Zuordnung erforderlich.
10. Aktivieren Sie das Flag "multi-writer" auf dem Primärknoten wieder.
11. Starten Sie den primären Knoten und überprüfen Sie den Betrieb.
12. Ordnen Sie die Platte zu oder aktivieren Sie das Flad 'multi-writer' auf allen anderen Cluster-VMs und schalten Sie sie ein.
13. Überprüfen Sie die Funktionsfähigkeit der übrigen Cluster.

Allgemeine VMs

Nachdem die Zuverlässigkeit der Funktion von HCX gesichert ist, muss die Massenmigration verwendet werden. Für redundante Anwendungen ist eine Massenmigration erforderlich. Ein Beispiel sind Web-Server sowie Fälle, wo viele Hunderte oder Tausende VMs migriert werden sollen.

VMs, die direkt angeschlossenen NAS verwenden

NFS wird in der Regel für die gemeinsame Nutzung von Daten auf vielen Servern verwendet, z. B. Web-Server-Inhalt. iSCSI kann auf allen VM-Knoten eingesetzt werden, die aus einem Anwendungscluster wie E-Mail oder RDBMS bestehen und ist in der Regel latenzsensibler als NFS.

In beiden Fällen gilt Folgendes: Wenn die Latenzzeit für das IBM Cloud-Rechenzentrum (< ~ 7 ms für iSCSI und was auch immer die Anwendung für NFS toleriert) niedrig gehalten werden kann und die Anwendung mit einer Bandbreite von ~ 1 Gb/s oder weniger betrieben werden kann, kann das NAS-Netz mit HCX an einen IBM Cloud-Standort erweitert werden. Anschließend können die VMs mit HCX migriert oder vMotioned werden.

Nach der Migration können iSCSI-Datenträger mit dem Betriebssystem in eine andere lokale Cloudspeicherlösung gespiegelt werden und NFS-Daten können in jede beliebige Cloudlösung repliziert werden. Beachten Sie die folgenden Hinweise:

• Latenzzeit (iSCSI oder Anwendungstoleranz für NFS)
• Bandbreite (ca. 1 Gb/s pro erweitertes Netz)
• Underlay-Verbindungsbandbreite

Nach dem Migrationslebenszyklus können Sie Entwicklungs- oder Staging-Anwendungen testen, bevor Sie versuchen, die Migration auf die Produktion durchzuführen. QoS kann für den Underlay-Tunnelverkehr ('UDP' 500/4500) zwischen den L2C-HCX-Appliances eingesetzt werden, die latenzsensitive erweiterte L2-Netze unterstützen.