NSX Public Cloud Gateway: Architektur und Bereitstellungsmodi

Das NSX Public Cloud Gateway (PCG) ermöglicht Nord-Süd-Konnektivität zwischen der Public Cloud und den lokalen Verwaltungskomponenten von NSX.

Machen Sie sich mit der folgenden Terminologie vertraut, in der die Architektur und die Bereitstellungsmodi von PCG für die Arbeitslast-VM-Verwaltung erläutert werden.

Hinweis: PCG wird für jede unterstützte Public Cloud in einer einzelnen Standardgröße bereitgestellt:

Public Cloud	PCG-Instanztyp
AWS	c5.xlarge. In einigen Regionen wird dieser Instanztyp möglicherweise nicht unterstützt. Einzelheiten finden Sie in der AWS-Dokumentation. Hinweis: Wenn Sie bei diesem Instanztyp Warnungen über eine hohe CPU-Auslastung sehen, ändern Sie die Größe von PCG-Instanzen in c5.2xlarge. Wenn Sie ein Hochverfügbarkeits-Paar von PCG-Instanzen haben, ändern Sie zuerst die Größe des Standby-PCG, indem Sie es anhalten, die Größe ändern und neu starten. Halten Sie das aktuell aktive PCG als nächstes an und warten Sie, bis das Standby-PCG aktiv wird. Das PCG wird nach dem Ändern und Neustarten erneut aktiv. Einzelheiten zum Ändern von Instanztypen finden Sie in der Dokumentation zu AWS.
Microsoft Azure	Standard DS3 v.2

Architektur

Das PCG kann entweder eine eigenständige-Gateway-Appliance sein oder von Ihren Public Cloud-VPCs oder -VNets gemeinsam genutzt werden, um eine Hub-and-Spoke-Topologie zu erhalten.

Bereitstellungsmodi

Selbstverwaltete(s) VPC/VNet: Wenn Sie das PCG in einer VPC oder einem VNet bereitstellen, wird die VPC oder das VNet als selbstverwaltet qualifiziert, d. h. Sie können VMs, die in dieser VPC oder diesem VNet gehostet werden, unter NSX-Verwaltung stellen.

Transit-VPC/VNet: Eine selbstverwaltete VPC/ein selbstverwaltetes VNet wird zu einer bzw. einem Transit-VPC/VNet, wenn Sie Computing-VPCs/VNets damit verknüpfen.

Computing-VPC/VNet: VPCs/VNets, auf denen das PCG nicht bereitgestellt ist, die jedoch über eine Verknüpfung zu einer Transit-VPC/einem Transit-VNet verfügen, werden als Computing-VPCs/VNets bezeichnet.

AWS Transit Gateway mit PCG: Ab NSX 3.1.1 können Sie AWS Transit Gateway verwenden, um eine Transit-VPC mit Computing-VPCs zu verbinden. Einzelheiten dazu finden Sie unter Verwenden PCG mit AWS Transit Gateway.

In Ihrer VPC/Ihrem VNet erforderliche Subnetze für die Bereitstellung von PCG

Das PCG nutzt die folgenden Subnetze, die Sie in Ihrem VPC/VNet eingerichtet haben. Siehe Verbinden von Microsoft Azure mit dem lokalen NSX oder Verbinden von AWS mit dem lokalen NSX.

• Management-Subnetz: Dieses Subnetz wird für das Management des Datenverkehrs zwischen lokalen NSX und PCG verwendet. Beispiel für den Bereich: /28.
• Uplink-Subnetz: Dieses Subnetz wird für den Nord-Süd-Internetverkehr genutzt. Beispiel für den Bereich: /24.
• Downlink-Subnetz: Dieses Subnetz umfasst den IP-Adressbereich der Arbeitslast-VM. Beachten Sie beim Festlegen der Größe des Subnetzes, dass Sie auf den Arbeitslast-VMs möglicherweise zusätzliche Schnittstellen für das Debugging benötigen.

Die PCG-Bereitstellung orientiert sich an Ihrem Netzwerkadressierungsplan mit FQDNs für die NSX-Komponenten und einem DNS-Server, der diese FQDNs auflösen kann.

Hinweis: Es wird nicht empfohlen, IP-Adressen für die Verbindung der Public Cloud mit NSX unter Verwendung eines PCGs zu verwenden. Sollten Sie diese Option jedoch auswählen, ändern Sie bitte nicht Ihre IP-Adressen.

Auswirkungen der Entdeckung von CSM durch PCG auf den lokalen Konnektivitätsmodus und den Public Cloud-Konnektivitätsmodus

Nachdem PCG in Ihrer Public Cloud bereitgestellt wurde, muss es mit CSM als Verwaltungsschnittstelle für Ihre Public Cloud-Bestandsliste interagieren. Um sicherzustellen, dass PCG die IP-Adresse von CSM erreichen kann, müssen Sie die folgenden Richtlinien beachten:

• Wenn PCG im privaten IP-Modus (VGW) bereitgestellt ist: PCG erkennt CSM an der tatsächlichen CSM-IP-Adresse oder an einer IP-Adresse im angegebenen Subnetzbereich.

  Abbildung 1. NSX Public Cloud Gateway-Architektur mit VGW-Konnektivität

  

• Wenn PCG im öffentlichen IP-Modus (IGW) bereitgestellt wird: PCG kann CSM mithilfe der von NAT übersetzten IP-Adresse von CSM ermitteln, die den Zugriff auf die reale IP-Adresse oder den Subnetzbereich für CSM ermöglicht.

  Abbildung 2. NSX Public Cloud Gateway-Architektur mit IGW-Konnektivität

  

Modi der VM-Verwaltung

NSX-erzwungener Modus: In diesem Modus werden Arbeitslast-VMs unter NSX-Verwaltung gebracht, indem NSX Tools auf jeder Arbeitslast-VM installiert wird, auf der Sie das Tag nsx.network=default in Ihrer Public Cloud anwenden.

Native Cloud-erzwungener Modus : In diesem Modus können Ihre Arbeitslast-VMs ohne Verwendung von NSX Tools unter NSX-Verwaltung gestellt werden.

Quarantäne-Richtlinie

Quarantäne-Richtlinie: Die Bedrohungserkennungsfunktion von NSX Cloud, die mit Ihren Public Cloud-Sicherheitsgruppen funktioniert.

• Im NSX-erzwungener Modus können Sie die Quarantäne-Richtlinie aktivieren oder deaktivieren. Es hat sich bewährt, die Quarantäne-Richtlinie zu deaktivieren und Ihre VMs der Liste Benutzerverwaltet hinzuzufügen, wenn das Onboarding von Arbeitslast-VMs durchgeführt wird.
• Im Native Cloud-erzwungener Modus ist die Quarantäne-Richtlinie immer aktiviert und kann nicht deaktiviert werden.

Designoptionen

Unabhängig vom Modus, in dem Sie PCG bereitstellen, können Sie eine bzw. ein Computing-VPC/VNet in einem der beiden Modi damit verknüpfen.

Tabelle 1. Designoptionen für PCG-Bereitstellungsmodi

PCG-Bereitstellungsmodus bei Transit-VPC/VNet	Unterstützte Modi beim Verknüpfen von Computing-VPCs/VNets mit dieser bzw. diesem Transit-VPC/VNet
NSX-erzwungener Modus	NSX-erzwungener Modus Native Cloud-erzwungener Modus
Native Cloud-erzwungener Modus	NSX-erzwungener Modus Native Cloud-erzwungener Modus

Hinweis:

Sobald ein Modus für eine bzw. ein Transit- oder Computing-VPC/VNet ausgewählt wurde, können Sie den Modus nicht ändern. Wenn Sie den Modus wechseln möchten, müssen Sie die Bereitstellung von PCG aufheben und im gewünschten Modus eine erneute Bereitstellung durchführen.