Für die Integration mit vRealize Automation unterstützte Topologien

Sie können eine NSX-V-Umgebung mit vRealize Automation (vRA) migrieren, wenn die Topologie für die Migration unterstützt wird.

Die mithilfe von vRA erstellten folgenden Ressourcen werden unterstützt:

• Bedarfsgesteuerte geroutete Netzwerke ohne Dienste
• Bedarfsgesteuerte geroutete Netzwerke mit DHCP-Server
• Bedarfsgesteuerte private Netzwerke (isolierte Netzwerke)
• Bedarfsgesteuerte Sicherheitsgruppen
• Nur bedarfsgesteuerte ausgehende Netzwerke mit NAT
• Bedarfsgesteuerte ausgehende Netzwerke mit DHCP, NAT, einarmigem Load Balancer
• Bedarfsgesteuerte ausgehende Netzwerke mit DHCP, NAT, Inline-Load Balancer
• Bedarfsgesteuerte ausgehende Netzwerke mit DHCP, NAT, einarmigem Load Balancer, Inline-Load Balancer
• Bedarfsgesteuerter einarmiger Load Balancer in vorhandenen Netzwerken
• Bedarfsgesteuerte Sicherheitsgruppen oder vorhandene Sicherheitsgruppen mit Load Balancer
• Vorhandene Sicherheitsgruppen

Darüber hinaus werden die folgenden vorab erstellten Objekte in NSX-V, die in vRA-Bereitstellungen verwendet werden, für die Migration unterstützt:

• Vorhandene Netzwerke (logische Switches, verteilte virtuelle VLAN-Portgruppen)
• Vorhandene Sicherheitsgruppen
• Distributed Logical Router (DLR)

Die vRA-Version, die Sie in Ihrer integrierten Umgebung verwenden, muss die unten erwähnten Topologien für die Migration unterstützen. Informationen zu Topologien, die vRA für die Migration unterstützt, finden Sie in der vRealize-Dokumentation zum Migrieren von NSX-V zu NSX-T.

Vorsicht: In Topologien, die ein von vRA erstelltes Edge Services Gateway (ESG) enthalten, werden die Firewallregeln während der Migration nicht auf das NSX-T Gateway migriert. Dies entspricht dem Verhalten von vRA , wenn ähnliche Topologien direkt in einer NSX-T-Umgebung erstellt werden.

In NSX-V besteht die Standardaktion für Edge-Firewallregeln darin, den gesamten Datenverkehr zu verweigern, und dann werden bestimmte Regeln von vRA auf dem Edge hinzugefügt, um Datenverkehr für die Dienste zuzulassen, die er konfiguriert. In NSX-T ist das Standardverhalten auf dem Gateway jedoch, den gesamten Datenverkehr zuzulassen.

In den Diagrammen für die Netzwerktopologie, auf die später in diesem Thema eingegangen wird, werden die folgenden Richtlinien verwendet:

Topologie vor der Migration

Vorab erstellte oder in NSX-V vorhandene Objekte werden in dunkelgrauer Farbe angezeigt. Die vorab erstellte Topologie in NSX-V kann einer der folgenden vier NSX-V-Topologien entsprechen, die für die Migration unterstützt werden:

• ESG mit Hochverfügbarkeit und L4-L7-Diensten (Topologie 1)
• ESG ohne L4-L7-Dienste (Topologie 2)
• Zwei Ebenen des ESG mit L4-L7-Diensten auf dem ESG der zweiten Ebene (Topologie 3)
• Einarmiger Load Balancer (Topologie 4)

Einzelheiten zu diesen unterstützten Topologien finden Sie unter Feste Topologien für End-to-End-Migration.

Die bedarfsgesteuerten gerouteten Netzwerke, ausgehenden Netzwerke und privaten Netzwerke, die in orange angezeigt werden, repräsentieren die in vRealize Automation erstellten Ressourcen.

Topologie nach der Migration

Die vorhandenen oder vorab erstellten Objekte in der NSX-V-Topologie werden den NSX-T-Objekt in mit dunkelgrauer Farbe zugeordnet. Die bedarfsgesteuerten in vRealize Automation erstellten Ressourcen werden den NSX-T-Objekten mit orangener Farbe zugeordnet.

Hinweis:

• In allen unterstützten Topologien erstellt vRealize Automation weder Distributed Logical Router (DLR) noch nach Norden weisende Edge-Dienst-Gateways (ESG). vRealize Automation kann nur einen vorhandenen DLR im zugehörigen Netzwerkprofil nutzen und zum Erstellen der bedarfsgesteuerten gerouteten Netzwerke verwenden.
• In allen unterstützten Topologien werden sowohl BGP als auch OSPF zwischen nach Norden weisenden Edge Services Gateways und physischen ToR-Switches unterstützt.

Bedarfsgesteuerte geroutete Netzwerke ohne Dienste (Topologie A)

Diese Topologie unterstützt die folgenden Konfigurationen:

• In vRealize Automation erstellte logische Switches stellen eine Verbindung zu einem vorhandenen verteilten logischen Router in NSX-V her.
• Arbeitslast-VMs, die mit vRealize Automation erstellt wurden, werden an die in vRealize Automation erstellten logischen Switches angehängt.

Die Konfigurationen werden wie folgt zu NSX-T migriert:

• Es wird ein Tier-1-Gateway für jeden von vRealize Automation erstellten logischen Switch erstellt, der mit dem Distributed Logical Router verbunden ist.
• Die Downlink-Schnittstellen des Distributed Logical Routers werden den Downlink-Schnittstellen des Tier-1-Gateways zugeordnet.
• Es wird ein NSX-T-Segment für jeden von vRealize Automation erstellten logischen Switch erstellt.
• In vRealize Automation erstellte Arbeitslast-VMs werden an die NSX-T-Segmente angehängt.

Abbildung 1. Topologie A: vor und nach der Migration

Bedarfsgesteuerte geroutete Netzwerke mit ausschließlich DHCP Server (Topologie B)

Diese Topologie unterstützt die folgenden Konfigurationen:

• In vRealize Automation erstellte logische Switches stellen eine Verbindung zu einem vorhandenen verteilten logischen Router in NSX-V her.
• Ein Edge-Dienst-Gateway mit einer DHCP-Serverkonfiguration wird mithilfe von vRealize Automation erstellt.
• Das Edge-Dienst-Gateway ist an den von vRealize Automation erstellten logischen Switch angehängt.

Die Konfigurationen werden wie folgt zu NSX-T migriert:

• Es wird ein Tier-1-Gateway für jeden von vRealize Automation erstellten logischen Switch erstellt, der mit dem Distributed Logical Router verbunden ist.
• Die Downlink-Schnittstellen des Distributed Logical Routers werden den Downlink-Schnittstellen des Tier-1-Gateways zugeordnet.
• Es wird ein NSX-T-Segment für jeden von vRealize Automation erstellten logischen Switch erstellt.
• In vRealize Automation erstellte Arbeitslast-VMs werden an die NSX-T-Segmente angehängt.
• Die DHCP-Serverkonfiguration auf dem Edge-Dienst-Gateway wird zu einer lokalen DHCP-Serverkonfiguration im NSX-T-Segment migriert.
• DHCP-Leases der Arbeitslast-VMs, die an den mit vRealize Automation erstellten logischen Switch angehängt sind, werden zu NSX-T migriert.

Abbildung 2. Topologie B: vor und nach der Migration

Bedarfsgesteuerte private Netzwerke (Topologie C)

Diese Topologie enthält von vRealize Automation erstellte logische Switches, die weder mit dem Distributed Logical Router noch mit dem Edge-Dienst-Gateway verbunden sind. Demnach gibt es in dieser Topologie kein Routing. Die isolierten, bedarfsgesteuerten privaten Netzwerke ermöglichen die Schicht-2-Konnektivität zwischen Arbeitslast-VMs auf demselben logischen Switch. Diese Topologie unterstützt die folgenden Konfigurationen:

• Arbeitslast-VMs werden in vRealize Automation erstellt und an die in vRealize Automation erstellten logischen Switches angehängt.
• Optional: ein Edge-Dienst-Gateway wird in vRealize Automation erstellt und DHCP Server ist auf diesem ESG konfiguriert. Das ESG ist an den in vRealize Automation erstellten logischen Switch angehängt.

Die Konfigurationen werden wie folgt zu NSX-T migriert:

• Es wird ein NSX-T-Segment für jeden von vRealize Automation erstellten logischen Switch erstellt.
• In vRealize Automation erstellte Arbeitslast-VMs werden an das NSX-T-Segment angehängt.
• Der lokale DHCP-Server ist im NSX-T-Segment konfiguriert.

Abbildung 3. Topologie C: vor und nach der Migration

Bedarfsgesteuerte Sicherheitsgruppen (Topologie D)

Diese Topologie unterstützt das Erstellen von Sicherheitsgruppen mithilfe von vRealize Automation. Über vRealize Automation können Sie die folgenden Konfigurationen in den Sicherheitsgruppen vornehmen:

• Fügen Sie nur VM-vNICs als statische Mitglieder hinzu.
• Fügen Sie Sicherheitsrichtlinien hinzu.
• Fügen Sie Firewallregeln in der Sicherheitsrichtlinie hinzu. Die Regeln können eine Kombination aus IP-Adressen und Anwendungen mit oder ohne Kombination aus Port und Protokoll aufweisen.
• Wenden Sie Sicherheitsrichtlinien auf die von vRealize Automation erstellten Sicherheitsgruppen an.

Wenn die Firewallregeln in der von vRealize Automation erstellten Sicherheitsrichtlinie IP-Adressen enthalten, erstellt vRealize Automation ein IP Set. Wenn die Regel Kombinationen aus Ports und Protokollen enthält, erstellt vRealize Automation die erforderlichen Anwendungen in der Firewallregel.

Nach der Migration werden die von vRealize Automation erstellten Sicherheitsgruppen den Gruppen in NSX-T zugeordnet. Eine L4-Anwendung in der Firewallregel in NSX-V wird einem L4-Dienst in der NSX-T-Firewallregel zugeordnet. Wenn die Regel jedoch eine L7-Anwendung enthält, kann die Zuordnung wie folgt lauten:

• Eine L7-Anwendung ohne Kombination aus Ports und Protokollen in einer NSX-V-Firewallregel wird einem einzelnen Kontextprofil in einer NSX-T-Firewallregel zugeordnet.
• Eine L7-Anwendung mit Kombination aus Ports und Protokollen in einer NSX-V-Firewallregel wird einem einzelnen Kontextprofil und einem L4-Dienst in einer NSX-T-Firewallregel zugeordnet.

Vorhandene Sicherheitsgruppen (Topologie E)

In dieser Topologie nutzt vRealize Automation vorhandene oder vorab erstellte Sicherheitsgruppen in der NSX-V-Umgebung oder verweist darauf. Allerdings ist bei vorhandenen Sicherheitsgruppen die unterstützte Funktionalität eingeschränkt. Mit vRealize Automation können Sie nur vNICs von Arbeitslast-VMs als statische Mitglieder in den vorhandenen Sicherheitsgruppen hinzufügen. Das Erstellen von Regeln für verteilte Firewalls in vRealize Automation und deren Anwendung auf vorhandene Sicherheitsgruppen ist nicht möglich.

Nach der Migration werden die Sicherheitsgruppen in NSX-V den Gruppen in NSX-T zugeordnet. Über vRealize Automation erstellte Sicherheits-Tags werden für die Migration zu NSX-T nicht unterstützt. Wenn Sie den Arbeitslast-VMs vorab erstellte NSX-V-Sicherheits-Tags zugewiesen haben, werden diese Tags zu NSX-T migriert, aber diese Informationen werden in vRealize Automation nicht aktualisiert.

Nur bedarfsgesteuerte ausgehende Netzwerke mit NAT (Topologie F)

Diese Topologie unterstützt die folgenden Konfigurationen:

• Bedarfsgesteuerte eingehende Netzwerke (logische Switches) werden mithilfe von vRealize Automation erstellt. Beispielsweise stellen die Netzwerke 2 und 3 in der Topologie vor der Migration die bedarfsgesteuerten ausgehenden Netzwerke dar.
• Die Uplink-Schnittstelle der in vRealize Automation erstellten Edge Services Gateways (ESG-3 und ESG-4) sind mit einem vorhandenen logischen Transit-Switch (192.178.14.0/24) verbunden.
• Die in vRealize Automation erstellten VMs in den bedarfsgesteuerten ausgehenden Netzwerken verfügen über eine statische IP-Adresse.
• Regeln für die Netzwerkadressübersetzung (NAT, Network Address Translation) werden mithilfe von vRealize Automation erstellt. Die SNAT-Aktion ist auf der Uplink-Schnittstelle von ESG-3 und ESG-4 konfiguriert. Die SNAT-Regeln lassen nur ausgehenden Datenverkehr von den VMs in den ausgehenden Netzwerken bis zu den externen Clients im öffentlichen Netzwerk zu. Die Portweiterleitung wird in den für vRealize Automation erstellten SNAT-Regeln nicht unterstützt.

  Beispiel: NAT-Regelkonfiguration auf ESG-3 und ESG-4.

  ESG-3	ESG-4
  Ursprünglich Aktion: SNAT Angewendet auf: vNIC (Uplink-Schnittstelle) Protokoll: beliebig IP des Quellbereichs: 192.168.200.1-192.168.200.14 Quellports: beliebig IP des Zielspeicherbereichs: beliebig Zielports: beliebig	Ursprünglich Aktion: SNAT Angewendet auf: vNIC (Uplink-Schnittstelle) Protokoll: beliebig IP des Quellbereichs: 192.168.210.1-192.168.210.14 Quellports: beliebig IP des Zielspeicherbereichs: beliebig Zielports: beliebig
  Übersetzt IP-Adresse: 192.178.14.4 Portbereich: beliebig	Übersetzt IP-Adresse: 192.178.14.5 Portbereich: beliebig

Abbildung 4. Topologie F: vor der Migration

Die Konfigurationen werden wie folgt zu NSX-T migriert:

• Für jedes von der vRealize Automation erstellte ausgehende Netzwerk, das mit einem ESG verbunden ist, wird ein Tier-1-Gateway erstellt und ein NSX-T-Overlay-Segment wird an den Downlink dieses Tier-1-Gateways angehängt.
• NAT-Regeln mit SNAT-Aktion sind auf den Tier-1-Gateways konfiguriert. Diese SNAT-Regeln haben die gleiche Konfiguration wie die SNAT-Regeln auf den mit vRealize Automation erstellten ESGs.
• Tier-1-Gateways werden in demselben Edge-Cluster erstellt, in dem auch das Tier-0-Gateway erstellt wird.

Abbildung 5. Topologie F: nach der Migration

Bedarfsgesteuerte ausgehende Netzwerke mit DHCP, NAT, einarmigem Load Balancer (Topologie G)

Diese Topologie unterstützt die folgenden Konfigurationen:

• Bedarfsgesteuerte eingehende Netzwerke (logische Switches) werden mithilfe von vRealize Automation erstellt. Beispielsweise stellen die Netzwerke 2 und 3 im Topologiediagramm vor der Migration die bedarfsgesteuerten ausgehenden Netzwerke dar.
• Die Uplink-Schnittstelle der in vRealize Automation erstellten Edge Services Gateways (ESG-3 und ESG-4) sind mit einem vorhandenen logischen Transit-Switch in NSX-V verbunden (zum Beispiel 192.178.14.0/24).
• ESG-3 ist mit einem einarmigen Load Balancer und NAT-Regeln (SNAT-Aktion) konfiguriert.
• ESG-4 ist mit einem DHCP-Server und NAT-Regeln (SNAT-Aktion) konfiguriert.
• Die in vRealize Automation erstellten VMs im bedarfsgesteuerten ausgehenden Netzwerk 2 verfügen über zwei statische IP-Adresse.
• Die in vRealize Automation erstellten Arbeitslast-VMs im ausgehenden Netzwerk 3 wird vom DHCP-Server eine IP-Adresse zugewiesen.
• Regeln für die Netzwerkadressübersetzung (NAT, Network Address Translation) werden mithilfe von vRealize Automation erstellt. Die SNAT-Aktion ist auf der Uplink-Schnittstelle von ESG-3 und ESG-4 konfiguriert. SNAT-Regeln erlauben nur den ausgehenden Verkehr von den VMs in den ausgehenden Netzwerken zu den externen Clients im öffentlichen Netzwerk.
  Beispiel: NAT-Regelkonfiguration auf ESG-3 und ESG-4.

  ESG-3	ESG-4
  Ursprünglich Aktion: SNAT Angewendet auf: vNIC (Uplink-Schnittstelle) Protokoll: beliebig IP des Quellbereichs: 192.168.200.1-192.168.200.14 Quellports: beliebig IP des Zielspeicherbereichs: beliebig Zielports: beliebig	Ursprünglich Aktion: SNAT Angewendet auf: vNIC (Uplink-Schnittstelle) Protokoll: beliebig IP des Quellbereichs: 192.168.210.1-192.168.210.14 Quellports: beliebig IP des Zielspeicherbereichs: beliebig Zielports: beliebig
  Übersetzt IP-Adresse: 192.178.14.4 Portbereich: beliebig	Übersetzt IP-Adresse: 192.178.14.5 Portbereich: beliebig

• Beispiel: Konfiguration des einarmigen Load Balancer auf ESG-3:
  • IP des virtuellen Servers: 192.168.200.14
  • Standardpool: Pool-1
  • Pool-1 verfügt über drei VMs: 192.168.200.10/24, 192.168.200.11/24, 192.168.200.12/24

  Die anderen Einstellungen der Load Balancer-Konfiguration sind hier nicht aufgeführt, da sie in diesem Migrationsbeispiel nicht von Interesse sind.

• Beispiel: Die interne Schnittstelle von ESG-3 hat zwei IP-Adressen konfiguriert: primäre IP-Adresse und sekundäre IP-Adresse.
  • Primäre IP-Adresse: 192.168.200.1/24. Sie verbindet das ausgehende Netzwerk mit der (internen) Downlink-Schnittstelle des ESG-3.
  • Sekundäre IP-Adresse: 192.168.200.14/24. Sie wird als IP des virtuellen Servers verwendet.

  Falls erforderlich, können Sie eine einzelne IP-Adresse auf der internen Schnittstelle des ESG-3 konfigurieren. In diesem Fall ist die IP des virtuellen Servers die gleiche wie die primäre IP-Adresse.

• Beispiel: Konfiguration des DHCP-Servers auf ESG-4:
  • DHCP-Poolbereich: 192.168.210.20-192.168.210.40
  • Standard-Gateway: 192.168.210.1

  Die anderen DHCP-Server werden hier nicht aufgelistet, da sie in diesem Migrationsbeispiel nicht von Interesse sind.

Abbildung 6. Topologie G: vor der Migration

Die Konfigurationen werden wie folgt zu NSX-T migriert:

• Für jedes von der vRealize Automation erstellte ausgehende Netzwerk, das mit einem ESG verbunden ist, wird ein Tier-1-Gateway erstellt und ein NSX-T-Overlay-Segment wird an den Downlink dieses Tier-1-Gateways angehängt.
• NAT-Regeln mit SNAT-Aktion sind auf den Tier-1-Gateways konfiguriert. Diese SNAT-Regeln haben die gleiche Konfiguration wie die SNAT-Regeln auf den mit vRealize Automation erstellten ESGs.
• Tier-1-Gateways werden in demselben Edge-Cluster erstellt, in dem auch das Tier-0-Gateway erstellt wird.
• Die Konfiguration des Load Balancer-Diensts auf ESG-3 wird in eine Konfiguration des Load Balancer-Diensts auf dem Tier-1-Gateway migriert. Dieses Tier-1-Gateway ist im Downlink mit dem NSX-T-Overlay-Segment 2 verbunden.
• Die Konfiguration des DHCP-Diensts auf ESG-4 wird in eine Konfiguration des Gateway-DHCP-Servers auf dem Tier-1-Gateway migriert. Dieses Tier-1-Gateway ist im Downlink mit dem NSX-T-Overlay-Segment 3 verbunden.

  Der Migrationskoordinator verwendet eine standardmäßige IP-Adresse für den DHCP-Server zur Konfiguration des Gateway-DHCP-Servers in NSX-T. Bei Bedarf können Sie während des Schritts Konfiguration auflösen der Migration eine andere Server-IP-Adresse eingeben. Befolgen Sie die Anweisungen, die auf der Seite Eingabe übermitteln der Benutzeroberfläche des Migrationskoordinators angezeigt werden, um eine andere Server-IP-Adresse anzugeben.

• In NSX-V wird die Lease-Dauer auf der Ebene des DHCP-IP-Pools konfiguriert, während in NSX-T die Lease-Dauer auf der Ebene der einzelnen Segmente konfigurierbar ist. Wenn der DHCP-Dienst in einem NSX-V-Netzwerk mit mehreren DHCP-IP-Pools konfiguriert ist, nimmt der Migrationskoordinator die höchste Lease-Dauer aus allen DHCP-IP-Pools und konfiguriert sie auf dem NSX-T-Segment.
• DHCP-Leases der Arbeitslast-VMs, die mit dem in vRealize Automation erstellten ausgehenden Netzwerk 3 verbunden sind, werden auf NSX-T migriert.

Abbildung 7. Topologie G: nach der Migration

Bedarfsgesteuerte ausgehende Netzwerke mit DHCP, NAT, Inline-Load Balancer (Topologie H)

Diese Topologie unterstützt die folgenden Konfigurationen:

• Bedarfsgesteuerte eingehende Netzwerke (logische Switches) werden mithilfe von vRealize Automation erstellt. Beispielsweise stellen die Netzwerke 2 und 3 im Topologiediagramm vor der Migration die bedarfsgesteuerten ausgehenden Netzwerke dar.
• Die Uplink-Schnittstellen in vRealize Automation erstellten Edge Services Gateways (ESG-3 und ESG-4) sind mit einem vorhandenen logischen Transit-Switch in NSX-V verbunden (zum Beispiel 192.178.14.0/24).
• ESG-3 ist mit einem Inline-Load Balancer, einem DHCP-Server und NAT-Regeln (SNAT-Aktion) konfiguriert.
• ESG-4 ist nur mit NAT-Regeln konfiguriert (SNAT-Aktion).
• Den in vRealize Automation erstellten VMs im bedarfsgesteuerten ausgehenden Netzwerk 2 werden vom DHCP-Server eine IP-Adresse zugewiesen.
• Die in vRealize Automation erstellten VMs im bedarfsgesteuerten ausgehenden Netzwerke 3 verfügen über zwei statische IP-Adresse.
• Regeln für die Netzwerkadressübersetzung (NAT, Network Address Translation) werden mithilfe von vRealize Automation erstellt. Die SNAT-Aktion ist auf der Uplink-Schnittstelle von ESG-3 und ESG-4 konfiguriert. SNAT-Regeln erlauben nur den ausgehenden Verkehr von den VMs in den ausgehenden Netzwerken zu den externen Clients im öffentlichen Netzwerk.

  Ein Beispiel für die Konfiguration von NAT-Regeln auf ESG-3 und ESG-4 finden Sie in der Beschreibung der Topologie vor der Migration von Topologie G, die weiter oben in diesem Thema erläutert wird.

• Beispiel: Konfiguration des Inline-Load Balancer auf ESG-3:
  • IP des virtuellen Servers: 192.178.14.6
  • Standardpool: Pool-1
  • Pool-1 verfügt über zwei VMs: 192.168.200.10/24, 192.168.200.11/24

  Die anderen Einstellungen der Load Balancer-Konfiguration sind hier nicht aufgeführt, da sie in diesem Migrationsbeispiel nicht von Interesse sind.

• Beispiel: Die Uplink-Schnittstelle von ESG-3 hat zwei IP-Adressen konfiguriert: primäre IP-Adresse und sekundäre IP-Adresse.
  • Primäre IP-Adresse: 192.178.14.4/24. verbindet ESG-3 mit dem logischen Transit-Switch.
  • Sekundäre IP-Adresse: 192.178.14.6/24. Sie wird als IP des virtuellen Servers verwendet.
• Beispiel: Konfiguration des DHCP-Servers auf ESG-3:
  • DHCP-Poolbereich: 192.168.200.20 192.168.200.40
  • Standard-Gateway: 192.168.200.1

  Die anderen DHCP-Server werden hier nicht aufgelistet, da sie in diesem Migrationsbeispiel nicht von Interesse sind.

Abbildung 8. Topologie H: vor der Migration

Die Konfigurationen werden wie folgt zu NSX-T migriert:

• Für jedes von der vRealize Automation erstellte ausgehende Netzwerk, das mit einem ESG verbunden ist, wird ein Tier-1-Gateway erstellt und ein NSX-T-Overlay-Segment wird an den Downlink dieses Tier-1-Gateways angehängt.
• NAT-Regeln mit SNAT-Aktion sind auf den Tier-1-Gateways konfiguriert. Diese SNAT-Regeln haben die gleiche Konfiguration wie die SNAT-Regeln auf den mit vRealize Automation erstellten ESGs.
• Tier-1-Gateways werden in demselben Edge-Cluster erstellt, in dem auch das Tier-0-Gateway erstellt wird.
• Der Load Balancer-Dienst auf ESG-3 wird in einen Load Balancer-Dienst auf dem Tier-1-Gateway migriert. Dieses Tier-1-Gateway ist im Downlink mit dem NSX-T-Overlay-Segment 2 verbunden.
• Die Konfiguration des DHCP-Diensts auf ESG-3 wird auf einen Gateway-DHCP-Server auf dem Tier-1-Gateway migriert.

  Der Migrationskoordinator verwendet eine standardmäßige IP-Adresse für den DHCP-Server zur Konfiguration des Gateway-DHCP-Servers in NSX-T. Bei Bedarf können Sie während des Schritts Konfiguration auflösen der Migration eine andere Server-IP-Adresse eingeben. Befolgen Sie die Anweisungen, die auf der Seite Eingabe übermitteln der Benutzeroberfläche des Migrationskoordinators angezeigt werden, um eine andere Server-IP-Adresse anzugeben.

• In NSX-V wird die Lease-Dauer auf der Ebene des DHCP-IP-Pools konfiguriert, während in NSX-T die Lease-Dauer auf der Ebene der einzelnen Segmente konfigurierbar ist. Wenn der DHCP-Dienst in einem NSX-V-Netzwerk mit mehreren DHCP-IP-Pools konfiguriert ist, nimmt der Migrationskoordinator die höchste Lease-Dauer aus allen DHCP-IP-Pools und konfiguriert sie auf dem NSX-T-Segment.
• DHCP-Leases der Arbeitslast-VMs, die mit dem in vRealize Automation erstellten ausgehenden Netzwerk 2 verbunden sind, werden auf NSX-T migriert.

Abbildung 9. Topologie H: nach der Migration

Bedarfsgesteuerte ausgehende Netzwerke mit DHCP, NAT, einarmigem Load Balancer, Inline-Load Balancer (Topologie I)

Diese Topologie unterstützt die folgenden Konfigurationen:

• Bedarfsgesteuerte eingehende Netzwerke (logische Switches) werden mithilfe von vRealize Automation erstellt. Beispielsweise stellen die Netzwerke 2 und 3 im Topologiediagramm vor der Migration die bedarfsgesteuerten ausgehenden Netzwerke dar.
• Beide ausgehenden Netzwerke sind mit den Downlink-Schnittstellen eines einzelnen, in vRealize Automation erstellten Edge Services Gateway (ESG-3) verbunden. Dieses Topologie-Diagramm zeigt zwei ausgehende Netzwerke, die mit ESG-3 verbunden sind. Es können jedoch mehr als zwei ausgehende Netzwerke mit demselben ESG verbunden sein.
• Die Uplink-Schnittstelle von ESG-3 ist mit einem vorhandenen logischen Transit-Switch in NSX-V verbunden (z. B. 192.178.14.0/24).
• Die folgenden Dienste sind auf dem ESG-3 konfiguriert:
  • NAT-Regeln mit SNAT- und DNAT-Aktion.
  • DHCP-Server
  • Einarmiger Load Balancer
  • Inline-Load Balancer
• Den in vRealize Automation erstellten VMs in den bedarfsgesteuerten ausgehenden Netzwerken 2 und 3 werden vom DHCP-Server eine IP-Adresse zugewiesen.
• Beispiel: Konfiguration des Inline-Load Balancer auf ESG-3. Er sorgt für einen Lastausgleich des Datenverkehrs im Netzwerk 2:
  • IP des virtuellen Servers: 192.178.14.5
  • Standardpool: Pool-1
  • Pool-1 verfügt über zwei VMs: 192.168.200.10/24, 192.168.200.11/24

  Die anderen Einstellungen der Load Balancer-Konfiguration sind hier nicht aufgeführt, da sie in diesem Migrationsbeispiel nicht von Interesse sind.

• Beispiel: Konfiguration des einarmigen Load Balancer auf ESG-3. Er sorgt für einen Lastausgleich des Datenverkehrs im Netzwerk 3:
  • IP des virtuellen Servers: 192.168.210.2
  • Standardpool: Pool-2
  • Pool-2 verfügt über zwei VMs: 192.168.210.11/24, 192.168.210.12/24
• NAT-Regeln mit SNAT-Aktion und DNAT-Aktion sind auf ESG-3 konfiguriert. Portweiterleitung wird sowohl für SNAT- als auch für DNAT-Regeln unterstützt.
• Beispiel: Konfiguration der SNAT-Regeln auf dem ESG-3.

  SNAT-Regel 1	SNAT-Regel 2
  Ursprünglich Angewendet auf: vNIC (Uplink-Schnittstelle) Protokoll: beliebig IP des Quellbereichs: 192.168.200.1-192.168.200.14 Quellports: beliebig IP des Zielspeicherbereichs: beliebig Zielports: beliebig	Ursprünglich Angewendet auf: vNIC (Uplink-Schnittstelle) Protokoll: beliebig IP des Quellbereichs: 192.168.210.1-192.168.210.14 Quellports: beliebig IP des Zielspeicherbereichs: beliebig Zielports: beliebig
  Übersetzt IP-Adresse: 192.178.14.5 Portbereich: beliebig	Übersetzt IP-Adresse: 192.178.14.4 Portbereich: beliebig

• Beispiel: Konfiguration der DNAT-Regel auf ESG-3.

  Ursprünglich Protokoll: beliebig IP des Quellbereichs: beliebig Quellports: beliebig IP des Zielbereichs: 192.178.14.5 Zielports: 100

  Übersetzt IP-Adresse: 192.178.200.35 Portbereich: 80

• Beispiel: Die Konfiguration des DHCP-Servers auf ESG-3 verfügt über zwei IP-Adressen:
  • DHCP-IP-Pool 1: 192.168.200.20-192.168.200.40
  • Standard-Gateway für Pool 1: 192.168.200.1
  • DHCP-IP-Pool 2: 192.168.210.20-192.168.210.40
  • Standard-Gateway für Pool 2: 192.168.210.1

  Die anderen DHCP-Server werden hier nicht aufgelistet, da sie in diesem Migrationsbeispiel nicht von Interesse sind.

Abbildung 10. Topologie I: vor der Migration

Die Konfigurationen werden wie folgt zu NSX-T migriert:

• Für die in vRealize Automation erstellten ausgehenden Netzwerke, die mit einem einzelnen ESG verbunden sind, wird ein Tier-1-Gateway erstellt und NSX-T-Overlay-Segmente werden mit dem Downlink dieses Tier-1-Gateways verbunden.
• SNAT- und DNAT-Regeln werden auf dem Tier-1-Gateway konfiguriert. Diese Regeln haben die gleiche Konfiguration wie die SNAT- und DNAT-Regeln auf dem in vRealize Automation erstellten ESG-3.
• Tier-1-Gateway wird in demselben Edge-Cluster erstellt, in dem auch das Tier-0-Gateway erstellt wird.
• Konfigurationen des Load Balancer-Diensts auf ESG-3 werden zu den Konfigurationen des Load Balancer-Diensts auf dem Tier-1-Gateway migriert.
• Die Konfiguration des DHCP-Diensts auf ESG-3 wird auf einen Gateway-DHCP-Server auf dem Tier-1-Gateway migriert.

  Der Migrationskoordinator verwendet eine standardmäßige IP-Adresse für den DHCP-Server zur Konfiguration des Gateway-DHCP-Servers in NSX-T. Bei Bedarf können Sie während des Schritts Konfiguration auflösen der Migration eine andere Server-IP-Adresse eingeben. Befolgen Sie die Anweisungen, die auf der Seite Eingabe übermitteln der Benutzeroberfläche des Migrationskoordinators angezeigt werden, um eine andere Server-IP-Adresse anzugeben.

• In NSX-V wird die Lease-Dauer auf der Ebene des DHCP-IP-Pools konfiguriert, während in NSX-T die Lease-Dauer auf der Ebene der einzelnen Segmente konfigurierbar ist. Wenn der DHCP-Dienst in einem NSX-V-Netzwerk mit mehreren DHCP-IP-Pools konfiguriert ist, nimmt der Migrationskoordinator die höchste Lease-Dauer aus allen DHCP-IP-Pools und konfiguriert sie auf dem NSX-T-Segment.
• DHCP-Leases der Arbeitslast-VMs, die mit dem in vRealize Automation erstellten ausgehenden Netzwerke verbunden sind, werden auf NSX-T migriert.

Abbildung 11. Topologie I: nach der Migration

Bedarfsgesteuerter einarmiger Load Balancer auf vorhandenen Netzwerken (Topologie J)

Diese Topologie verfügt über die folgenden Konfigurationen:

• Ein einarmiger Load Balancer wird auf einem in vRealize Automation erstellten ESG konfiguriert. Dieses ESG ist mit einem vorhandenen Netzwerk in NSX-V verbunden. Das vorhandene Netzwerk kann entweder ein VLAN oder ein logischer Switch sein.
  Das Topologie-Diagramm „vor der Migration“ zeigt einen einzelnen einarmigen Load Balancer in einem vorhandenen Netzwerk 1. Für die Zwecke dieser Topologiebeschreibung wird ein einzelner einarmiger Load Balancer auf einem in vRealize Automation erstellten ESG betrachtet. Diese Topologie unterstützt jedoch auch die folgenden Konfigurationen:

  • Mehrere in vRealize Automation erstellte einarmige Load Balancer, die mit einem einzelnen vorhandenen Netzwerk verbunden sind. Ein Load Balancer wird auf jedem in vRealize Automation erstellten ESG konfiguriert. Alle ESGs werden als Teil einer einzelnen vRealize Automation-Bereitstellung bereitgestellt.
  • Mehrere in vRealize Automation erstellte einarmige Load Balancer, wobei jeweils ein Load Balancer mit einem anderen vorhandenen Netzwerk verbunden ist. Ein Load Balancer wird auf jedem in vRealize Automation erstellten ESG konfiguriert. Alle ESGs werden als Teil einer einzelnen vRealize Automation-Bereitstellung bereitgestellt.
• Die in vRealize Automation erstellten Arbeitslast-VMs, die mit einem vorhandenen Netzwerk verbunden sind, verfügen über eine statische IP-Adresse.
• Beispiel: Konfiguration des einarmigen Load Balancer auf ESG-3.
  • IP des virtuellen Servers: 192.168.100.2
  • Standardpool: Pool-1
  • Pool-1 verfügt über zwei VMs: 192.168.100.10/24, 192.168.100.11/24

Abbildung 12. Topologie J: vor der Migration

Die Konfigurationen werden wie folgt zu NSX-T migriert:

• ESG-3 in der NSX-V-Topologie wird zu einem eigenständigen Tier-1-Gateway in der NSX-T-Topologie migriert. Das Tier-1-Gateway ist nicht mit dem Tier-0-Gateway verbunden.
• Die Load Balancer-Konfiguration auf ESG-3 wird in eine Load Balancer-Konfiguration auf dem Tier-1-Gateway migriert.

Abbildung 13. Topologie J: nach der Migration

Bedarfsgesteuerte Sicherheitsgruppen oder vorhandene Sicherheitsgruppen mit Load Balancer (Topologie K)

Diese Topologie unterstützt ein in vRealize Automation erstelltes ESG, auf dem ein einzelner Load Balancer konfiguriert ist. Das ESG kann entweder mit einem vorhandenen Netzwerk verbunden werden oder mit einem bedarfsgesteuerten Netzwerk, das über vRealize Automation erstellt wird.

Eine vorhandene Sicherheitsgruppe ist Teil des vRealize Automation-Netzwerkprofils, oder eine bedarfsgesteuerte/vorhandene Sicherheitsgruppe ist in der vRealize Automation-Bereitstellung vorhanden, die bedarfsgesteuerte Netzwerke enthält.

In der Konfigurationsdatei für die Eingangsbereitstellung fügt vRealize Automation automatisch die virtuelle Server-IP des Load Balancer innerhalb eines IP Set-Objekts hinzu. Dieses IP Set-Objekt wird als Mitglied der Sicherheitsgruppe im vRealize Automation-Netzwerkprofil hinzugefügt. Oder der IP Set-Objekt wird als Mitglied der bedarfsgesteuerten oder vorhandenen Sicherheitsgruppe aus dem Blueprint hinzugefügt, der mit den Mitgliedern des Load Balancer-Pools verknüpft ist.

Wenn eine solche Topologie auf NSX-T migriert wird, wird das ESG einem Tier-1-Gateway in der NSX-T-Topologie zugeordnet. Die Konfiguration des Load Balancer-Diensts auf ESG wird in eine Konfiguration des Load Balancer-Diensts auf dem Tier-1-Gateway migriert. Die Sicherheitsgruppe in NSX-V wird einer Gruppe in NSX-T zugeordnet. Diese NSX-T-Gruppe enthält eine verschachtelte Gruppe, die die virtuelle Server-IP des Load Balancer enthält.