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

Sie können eine NSX-V-Umgebung mit Aria Automation mithilfe der Option „Feste Topologie“ migrieren, wenn Ihre Topologie mit einer der unten beschriebenen Identisch ist.

Die mithilfe von Aria Automation 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 Aria Automation-Bereitstellungen verwendet werden, für die Migration unterstützt:

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

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

Vorsicht: In Topologien, die ein von Aria Automation erstelltes Edge Services Gateway (ESG) enthalten, werden die Firewallregeln während der Migration nicht auf das NSX-Gateway migriert. Dies entspricht dem Verhalten von Aria Automation, wenn ähnliche Topologien direkt in einer NSX-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 Aria Automation auf dem Edge hinzugefügt, um Datenverkehr für die Dienste zuzulassen, die er konfiguriert. In NSX 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 Aria Automation erstellten Ressourcen.

Topologie nach der Migration

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

Hinweis:

• In allen unterstützten Topologien erstellt Aria Automation weder Distributed Logical Router (DLR) noch nach Norden weisende Edge-Dienst-Gateways (ESG). Aria 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 Aria Automation erstellte logische Switches stellen eine Verbindung zu einem vorhandenen verteilten logischen Router in NSX-V her.
• Arbeitslast-VMs, die mit Aria Automation erstellt wurden, werden an die in Aria Automation erstellten logischen Switches angehängt.

Die Konfigurationen werden wie folgt zu NSX migriert:

• Es wird ein Tier-1-Gateway für jeden von Aria 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-Segment für jeden von Aria Automation erstellten logischen Switch erstellt.
• In Aria Automation erstellte Arbeitslast-VMs werden an die NSX-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 Aria 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 Aria Automation erstellt.
• Das Edge-Dienst-Gateway ist an den von Aria Automation erstellten logischen Switch angehängt.

Die Konfigurationen werden wie folgt zu NSX migriert:

• Es wird ein Tier-1-Gateway für jeden von Aria 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-Segment für jeden von Aria Automation erstellten logischen Switch erstellt.
• In Aria Automation erstellte Arbeitslast-VMs werden an die NSX-Segmente angehängt.
• Die DHCP-Serverkonfiguration auf dem Edge-Dienst-Gateway wird zu einer lokalen DHCP-Serverkonfiguration im NSX-Segment migriert.
• DHCP-Leases der Arbeitslast-VMs, die an den mit Aria Automation erstellten logischen Switch angehängt sind, werden zu NSX migriert.

Abbildung 2. Topologie B: vor und nach der Migration

Bedarfsgesteuerte private Netzwerke (Topologie C)

Diese Topologie enthält von Aria 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 Aria Automation erstellt und an die in Aria Automation erstellten logischen Switches angehängt.
• Optional: ein Edge-Dienst-Gateway wird in Aria Automation erstellt und DHCP Server ist auf diesem ESG konfiguriert. Das ESG ist an den in Aria Automation erstellten logischen Switch angehängt.

Die Konfigurationen werden wie folgt zu NSX migriert:

• Es wird ein NSX-Segment für jeden von Aria Automation erstellten logischen Switch erstellt.
• In Aria Automation erstellte Arbeitslast-VMs werden an das NSX-Segment angehängt.
• Der lokale DHCP-Server ist im NSX-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 Aria Automation. Über Aria 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 Aria Automation erstellten Sicherheitsgruppen an.

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

Nach der Migration werden die von Aria Automation erstellten Sicherheitsgruppen den Gruppen in NSX zugeordnet. Eine L4-Anwendung in der Firewallregel in NSX-V wird einem L4-Dienst in der NSX-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-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-Firewallregel zugeordnet.

Vorhandene Sicherheitsgruppen (Topologie E)

In dieser Topologie nutzt Aria 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 Aria 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 Aria Automation und deren Anwendung auf vorhandene Sicherheitsgruppen ist nicht möglich.

Nach der Migration werden die Sicherheitsgruppen in NSX-V den Gruppen in NSX zugeordnet. Über Aria Automation erstellte Sicherheits-Tags werden für die Migration zu NSX nicht unterstützt. Wenn Sie den Arbeitslast-VMs vorab erstellte NSX-V-Sicherheits-Tags zugewiesen haben, werden diese Tags zu NSX migriert, aber diese Informationen werden in Aria 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 Aria 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 Aria 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 Aria 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 Aria 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 Aria 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 migriert:

• Für jedes von der Aria Automation erstellte ausgehende Netzwerk, das mit einem ESG verbunden ist, wird ein Tier-1-Gateway erstellt und ein NSX-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 Aria 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 Aria Automation erstellt. Beispielsweise stellen die Netzwerke 2 und 3 im Topologiediagramm vor der Migration die bedarfsgesteuerten ausgehenden Netzwerke dar.
• Die Uplink-Schnittstelle der in Aria 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 Aria Automation erstellten VMs im bedarfsgesteuerten ausgehenden Netzwerk 2 verfügen über zwei statische IP-Adresse.
• Die in Aria 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 Aria 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 migriert:

• Für jedes von der Aria Automation erstellte ausgehende Netzwerk, das mit einem ESG verbunden ist, wird ein Tier-1-Gateway erstellt und ein NSX-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 Aria 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-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-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. 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 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-Segment.
• DHCP-Leases der Arbeitslast-VMs, die mit dem in Aria Automation erstellten ausgehenden Netzwerk 3 verbunden sind, werden auf NSX 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 Aria Automation erstellt. Beispielsweise stellen die Netzwerke 2 und 3 im Topologiediagramm vor der Migration die bedarfsgesteuerten ausgehenden Netzwerke dar.
• Die Uplink-Schnittstellen in Aria 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 Aria Automation erstellten VMs im bedarfsgesteuerten ausgehenden Netzwerk 2 werden vom DHCP-Server eine IP-Adresse zugewiesen.
• Die in Aria 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 Aria 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 migriert:

• Für jedes von der Aria Automation erstellte ausgehende Netzwerk, das mit einem ESG verbunden ist, wird ein Tier-1-Gateway erstellt und ein NSX-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 Aria 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-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. 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 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-Segment.
• DHCP-Leases der Arbeitslast-VMs, die mit dem in Aria Automation erstellten ausgehenden Netzwerk 2 verbunden sind, werden auf NSX 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 Aria 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 Aria 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 Aria 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 migriert:

• Für die in Aria Automation erstellten ausgehenden Netzwerke, die mit einem einzelnen ESG verbunden sind, wird ein Tier-1-Gateway erstellt und NSX-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 Aria 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. 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 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-Segment.
• DHCP-Leases der Arbeitslast-VMs, die mit dem in Aria Automation erstellten ausgehenden Netzwerke verbunden sind, werden auf NSX 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 Aria 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 Aria Automation erstellten ESG betrachtet. Diese Topologie unterstützt jedoch auch die folgenden Konfigurationen:

  • Mehrere in Aria Automation erstellte einarmige Load Balancer, die mit einem einzelnen vorhandenen Netzwerk verbunden sind. Ein Load Balancer wird auf jedem in Aria Automation erstellten ESG konfiguriert. Alle ESGs werden als Teil einer einzelnen Aria Automation-Bereitstellung bereitgestellt.
  • Mehrere in Aria Automation erstellte einarmige Load Balancer, wobei jeweils ein Load Balancer mit einem anderen vorhandenen Netzwerk verbunden ist. Ein Load Balancer wird auf jedem in Aria Automation erstellten ESG konfiguriert. Alle ESGs werden als Teil einer einzelnen Aria Automation-Bereitstellung bereitgestellt.
• Die in Aria 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 migriert:

• ESG-3 in der NSX-V-Topologie wird zu einem eigenständigen Tier-1-Gateway in der NSX-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 Aria 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 Aria Automation erstellt wird.

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

In der Konfigurationsdatei für die Eingangsbereitstellung fügt Aria 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 Aria 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 migriert wird, wird das ESG einem Tier-1-Gateway in der NSX-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 zugeordnet. Diese NSX-Gruppe enthält eine verschachtelte Gruppe, die die virtuelle Server-IP des Load Balancer enthält.