Netzkonnektivität konfigurieren

HCX muss das öffentliche Internet und Privatleitungen traversieren sowie Verbindungen zu Rechenzentrumskomponenten wie Netze, Switches und Portgruppen herstellen.

• Weitere Informationen zu den Ports, die geöffnet werden müssen, damit die virtuellen HCX-Einheiten erfolgreich installiert werden können, finden Sie unter Portzugriffsanforderungen.
• Sowohl die lokale vSphere-Umgebung als auch die VMware Cloud Foundation for Classic – Automated HCX Cloud-Umgebung müssen die Synchronisierung der NTP-Uhr (Network Time Protocol) zwischen lokalen vSphere-Geräten und VCF for Classic – Automated HCX-Geräten ermöglichen. UDP-Port 123 muss für virtuelle HCX-Appliances und -Netze zugänglich sein.

Lokale Umgebung

Stellen Sie vor der Installation von HCX sicher, dass Ihre Umgebung die Tasks unterstützen kann, die Sie ausführen möchten. Die lokale Umgebung muss die folgenden Tasks unterstützen, damit HCX installiert werden kann.

• Virtual Center mit vSphere 5.5 Update 3 oder 6.0u2.
• vMotion und Funktionen für die Richtlinienmigration erfordern NSX Version 6.2.2 oder höher.
• Ein vSphere-Dienstkonto mit der ihm zugewiesenen Systemrolle Administrator.
• In vCenter ausreichend Plattenspeicherplatz für die zu installierenden HCX-Appliances.
• Ausreichende IP-Adressen für die bei der Installation bereitgestellten lokalen VMs.
• Die Ports und Firewalls sind wie in den Portzugriffsvoraussetzungen beschrieben geöffnet.
• Wenn der SSO-Server (Single Sign-on) ein ferner Server ist, muss die URL von vCenter, dem externen SSO-Server oder dem Platform Services Controller (PSC), auf dem der externe Suchservice ausgeführt wird, angegeben werden. Wenn der HCX-Manager bei vCenter registriert ist, muss diese URL angegeben werden.
• Wenn eine VMware vCenter® keine eigene interne Instanz des Suchdienstes hat, kann dies einen der folgenden Gründe haben.
  • vCenter 6.0u2 führt einen externen Platform Services Controller aus.
  • vCenter ist im verknüpften Modus (wobei die sekundäre vCenter den SSO-Dienst der primären vCenter oder einen externen SSO-Dienst verwendet).

Layer-2-Installationsumgebung überprüfen

Für die Erweiterung des Layer-2-Netzes müssen folgende Voraussetzungen erfüllt sein:

• vSphere Enterprise Plus Edition
• Die vSphere vCenter muss die folgenden Anforderungen erfüllen, um die Layer-2-Erweiterung zu unterstützen:
  • vSphere Enterprise Plus Lizenz.
  • Muss über einen vSphere Distributed Switch (vDS) verfügen. Der verteilte Switch ist mit vSphere Enterprise Plus Edition verfügbar.
  • Nach der Installation muss die lokale Service-Appliance für den Layer-2-Konzentrator über Zugriff auf einen vNIC-Port und eventuell zu erweiternde VLANs verfügen.
  • Wenn das Netzwerk über das öffentliche Internet oder ein VPN (auf einem alternativen Pfad) erweitert werden soll, benötigt die L2C VM in VCF for Classic – Automated eine IP-Adresse. Die ferne IP-Adresse ist erforderlich, um den Layer-2-Konzentrator zu konfigurieren.
  • Wenn mehrere Layer-2-Konzentratoren gewünscht sind, muss jeder über eine IP-Adresse verfügen, lokal wie auch in der Cloud.

Vorplanung für die Bereitstellung

Ein Großteil der Zeit, die eine Bereitstellung von HCX erfordert, wird für die Phase vor der Bereitstellung benötigt. Es ist typisch für Migrationsprojekte für Informationssysteme, die Monate und sogar Jahre abgeschlossen werden müssen. HCX ermöglicht es jedoch, eine kurze Zeit zu migrieren und die Netzkonnektivität zu der Cloud unverzüglich nach der Implementierung zu starten.

Da die Bereitstellung von HCX für einen Kunden auf Unternehmensebene in der Regel Teams für Sicherheit, Netz, Speicher und vSphere-Infrastruktur umfasst, ist es sinnvoll, diese Teams nach Möglichkeit in den PoC einzubinden. Ein effektives Projektmanagement und die frühzeitige Einbeziehung der Interessengruppen sind entscheidend, um eine schnelle Bereitstellung und Inbetriebnahme von HCX zu gewährleisten.

Vermeidung von übermäßigem Analyseaufwand

Viele der Hürden und Zeit, die die Migration einer virtuellen Maschine (VM) oder einer Gruppe von VMs in Anspruch nimmt, sind darauf zurückzuführen, dass Teile der Anwendungsumgebung geändert werden müssen. Auch das Design dieser Änderungen und die Planung der Ausfallzeiten, die zur Durchführung dieser Änderungen erforderlich sind, können kompliziert sein. Nachdem diese Änderungen vorgenommen wurden, lässt sich die Migration kaum noch abbrechen, weil dies zusätzlich zu übermäßigem Analyseaufwand führen würde. Der Versuch, alle Aspekte der Migration zu erfassen, die Teams zu koordinieren und die Unterstützung wichtiger Stakeholder zu gewinnen, kann das Projekt verzögern.

HCX ermöglicht die vSphere-übergreifende Instanzmigration einer VM oder Gruppe von VMs, die eine Teil- oder vollständige Verbundanwendung darstellen, ohne Änderungen an der Anwendung. Ein Zurückziehen der Migration bedeutet daher, die VMs zurückzuschieben oder die Netzwerke neu zu strecken. Daher entfällt ein großer Teil der Migrationsplanung und es kann zu einer gewissen Parallelität im Planungsprozess kommen. Nachdem Sie die zu verschiebenden Anwendungen ausgewählt und ein Netzwerkdesign auf hoher Ebene erstellt haben, können die Anwendungen mit einer minimalen Konfiguration auf der Cloud-Instanz mit der Migration beginnen, während die endgültige Netzwerkkonnektivität und das endgültige Netzwerkdesign ausgearbeitet werden.

Erweiterte Netze

Die Streckenkomponenten des Netzwerks der HCX-Flotte sind stabil. Ein Kunde hat mehr als 20 VLANs, die in das IBM Cloud® über ein 1-Gbit/s-WAN gestreckt werden, das mit anderem Datenverkehr und HCX-Migrationstunneln geteilt wird. Bei dieser Konfiguration gibt es keine Anwendungsprobleme, die auf das Netz zurückzuführen sind. Die Netzverbindungen haben auf diese Weise eine Lebensdauer von mehr als 6 Monaten.

Weitere erweiterte Netze wurden ohne Probleme hinzugefügt und entfernt. Die Auswahl eines nahegelegenen IBM Cloud-Rechenzentrums (<6 ms Latenzzeit für diesen bestimmten Kunden) spielt auch für die Netzstabilität des erweiterten Netzbetriebs eine Rolle. Die gestreckten Netzwerke langfristig zu belassen, ist kein negativer Faktor in Ihrem Entwurf, vorausgesetzt, Sie verfügen über genügend Bandbreite und eine ausreichend geringe Latenz für Ihre Anwendungen.

Migrationslebenszyklus

In den folgenden Abschnitten werden die Phasen innerhalb eines typischen HCX-Migrationslebenszyklus beschrieben, mit Hinweisen darauf, an welchen Punkten die Arbeitsabläufe parallel ausgeführt werden können.

vSphere-Bestand

• Allgemeine Bewertung von VMs innerhalb einer zu migrierenden Anwendung. "Allgemein" impliziert die Kenntnis der an einer Anwendung beteiligten VMs, ohne sich in Details zu verlieren.
• Wenn Sie vorhaben, eine Vielzahl von VMs zu migrieren, und die Netzbandbreite zwischen Quellen- und Cloudstandorten begrenzt ist, gruppieren Sie die VMs weiter nach VLAN bzw. VXLAN, wenn an der Quelle NSX eingesetzt wird. Dies ermöglicht einen kaskadierenden HCX-Migrationsplan, der vorsieht, dass die VM-Gruppen nach VLAN migriert werden und die L2-Netze, in denen sie sich befinden, nur bis zu dem Punkt erweitert werden, an dem die VLANs freigegeben werden.

Das bedeutet, dass die anfängliche Gruppe zusammengehöriger ausgedehnter L2-Netze erst dann freigegeben werden kann, wenn das Netzdesign auf der Cloudseite abgeschlossen und implementiert ist. Das Rückgängigmachen der Erweiterung impliziert, dass ein Swing dieses VXLAN-Datenverkehrs jetzt zu einer Weiterleitung durch die NSX-Infrastruktur der Cloud-Instanz führt.

Baseline-Netzkonfiguration

Erstellen Sie ein gesichertes Perimeternetzwerk innerhalb der Cloud-seitigen vSphere-Instanz. Diese besteht in der Regel aus einem NSX-DLR oder einem Edge-Gerät. Wenn Sie HCX Proximity Routing verwenden, müssen Sie keine Firewall-Regeln oder Uplink-Topologie erstellen, da dies später oder gleichzeitig erfolgen kann, ohne dass der gestreckte L2-Verkehr beeinträchtigt wird.

Netzerweiterung

Das Erweitern des Netzes bedeutet lediglich, dass vorhandene VLANs oder VXLANs aus der vSphere-Quelllenumgebung, dargestellt durch eine virtuelle Switch-Port-Gruppe (vDS), auf ein NSX-VXLAN auf der Cloudseite von HCX erweitert werden.

Vor-Tests

Bei den Vor-Tests wird eine HCX-Migration sowohl mit vMotion als auch mit der Massenmigrationsfunktion durchgeführt, um eine Basis-Übertragungsrate zu ermitteln.

Migration von nicht produktiven Anwendungen

Die Migration von virtuellen Maschinen beginnt mit den geplanten Stadien für weniger kritische virtuelle Maschinen. Entwicklungs- und Testteams verwenden die Internetkonnektivität für Migration und erweiterten L2-Datenverkehr.

Cloud-Netzdesign und -bereitstellung beginnen

Während die Migrationen fortgesetzt werden, werden die Cloud-seitigen Netzwerkentwürfe fertiggestellt und in der Cloud-seitigen vSphere-Instanz implementiert.

Weitere Aspekte zur Netzkonnektivität

Während die Migration läuft, wird die private WAN-Netzkonnektivität bestellt, da es in der Regel einige Wochen bis Monate dauert, bis sie beim Cloud-Provider aufgebaut ist. Nach Abschluss der Konnektivität des privaten Netzwerks kann HCX so konfiguriert werden, dass sowohl die dedizierte private Netzwerkverbindung als auch das Internet für die Migration und den erweiterten L2-Verkehr genutzt werden.

Physische Server

Wenn das Ziel die Migration des Rechenzentrums in die Cloud ist, können alle physischen Server, die mit den VMs interagieren, daraufhin beurteilt werden, ob sie als VM (P2V) oder als Bare-Metal-VMs nach IBM Cloud migriert werden oder ob sie an der Quelle verbleiben. Wenn der physische Server an der Quelle verbleiben soll und HCX nur während der Migration verwendet wird, bis ein dediziertes Netzwerk eingerichtet ist, ist es wichtig zu wissen, ob er sich in einem Netzwerk befindet, das mit HCX in die Cloud gestreckt wird. In diesem Szenario lässt HCX die Migration nicht nur der virtuellen Maschinen, sondern auch des gesamten Teilnetzes in die Cloud zu.

Um HCX am Ende der Migration zu entfernen, darf das Teilnetz in der Quelle und im Ziel nicht vorhanden sein, wenn die Verbindung zwischen physischen Einheiten und den migrierten VMs beibehalten werden soll. Dies impliziert, dass alle physischen Einheiten, die am Quellenstandort verbleiben und in erweiterten L2-Netzen vorhanden sind, in ein anderes Netzteilnetz migriert werden müssen, das an die Cloudseite weitergeleitet werden kann. Eine Ausnahme ist es, wenn eine andere erweiterte L2-Technologie verwendet wird, wie zum Beispiel NSX-L2-VPN, um HCX-erweiterte L2-Endpunkte zu ersetzen.

Produktions- und komplexe Anwendungen migrieren

VMs mit gemeinsam genutzten Multi-Writer-VMDKs, wie z. B. Oracle RAC oder MS Exchange/SQL-Cluster oder VMs mit Roheinheiten-Zuordnungen, sind Beispiele für VMs, die vor der Migration zusätzlicher Aufmerksamkeit bedürfen.

Netz-Swing

Der Netz-Swing erfolgt, nachdem die Evakuierung der VMs auf den quellenseitigen Netzwerken abgeschlossen ist und das Netzdesign und die Implementierung auf der Cloudseite abgeschlossen sind. Durch die Konfiguration von HCX zur Entdrosselung der Netzwerke, die mit den abgeschlossenen VMs innerhalb von Migrationswellen verbunden sind, können die migrierten VMs den Netzwerkverkehr über die cloudseitige NSX-Infrastruktur leiten.

Unterstützte Clientplattformen

Für Netzerweiterungen werden nur solche Portgruppen unterstützt, die über einen virtuellen verteilten vSphere-Switch (virtual distributed switch, vDS) verfügen. Dies bedeutet auch, dass eigenständige ESXi-Hosts nicht unterstützt werden, da Sie nur dann über einen vDS verfügen können, wenn ESXi-Hosts von vCenter verwaltet werden.

• vSphere 5.1 (Befehlszeile nur für vCenter 5.1 über API)
• vSphere 5.5 ( VMware vSphere Web Client unterstützt auf vCenter 5.5u3 und früher)
• vSphere 6.0
• vSphere 6.5 (vDS muss auf Version 6.0 vorhanden sein)

Unterstützte Cloudplattformen

Die HCX-Cloudseite wird von der IBM Cloud-Automatisierung bereitgestellt.

Konnektivitätsoptionen

Verwandte Links

• Glossar der HCX-Komponenten und -Begriffe
• Lokales HCX-Servicenetz
• VMware Hybrid Cloud-Migrationen
• Überwachung von Parametern und Komponenten
• Fehlerbehebung für HCX