VMware Cloud on AWS verwendet NSX-T, um interne SDDC-Netzwerke zu erstellen und zu verwalten und Endpoints für VPN-Verbindungen von Ihrer lokalen Netzwerkinfrastruktur bereitzustellen.

SDDC-Netzwerktopologie

Wenn Sie ein SDDC erstellen, umfasst dieses ein Verwaltungsnetzwerk. Test-SDDCs mit einem einzelnen Host enthalten auch ein kleines Computing-Netzwerk. Den CIDR-Block des Verwaltungsnetzwerks geben Sie an, wenn Sie das SDDC erstellen. Nach der Erstellung des SDDC kann diese Auswahl nicht mehr geändert werden. Weitere Informationen finden Sie unter Bereitstellen eines SDDC von der VMC-Konsole. Das Verwaltungsnetzwerk verfügt über zwei Subnetze:
Appliance-Subnetz
Dieses Subnetz wird von den vCenter-, NSX- und HCX-Appliances im SDDC verwendet. Wenn Sie Appliance-basierte Dienste wie SRM zum SDDC hinzufügen, stellen diese ebenfalls eine Verbindung mit diesem Subnetz her.
Infrastruktur-Subnetz
Dieses Subnetz wird von den ESXi-Hosts im SDDC verwendet.

Das Computing-Netzwerk enthält eine beliebige Anzahl logischer Segmente für Ihre Arbeitslast-VMs. Aktuelle Grenzwerte für logische Segmente finden Sie in den Maximalwerte für die VMware-Konfiguration. In einer Einzelhost-SDDC-Startkonfiguration erstellen Sie ein Computing-Netzwerk mit einem einzelnen gerouteten Segment. In SDDC-Konfigurationen mit mehreren Hosts müssen Sie Computing-Netzwerksegmente entsprechend Ihren Anforderungen erstellen. Die entsprechenden Grenzwerte finden Sie im Tool für die Maximalwerte für die VMware-Konfiguration.

Ein SDDC-Netzwerk verfügt über zwei abstrakte Ebenen:
  • Tier 0 verarbeitet den Nord-Süd-Verkehr (Verkehr, der das SDDC verlässt oder in ihm eingeht oder zwischen den Management- und Computing-Gateways).
  • Tier 1 verarbeitet Ost-West-Datenverkehr (Datenverkehr zwischen gerouteten Netzwerksegmenten innerhalb des SDDC).
Abbildung 1. SDDC-Netzwerktopologie
NSX Edge-Appliance

Die standardmäßige NSX Edge Appliance wird als paar VMs implementiert, die im Aktiv/Standby-Modus ausgeführt werden. Diese Appliance stellt die Plattform zur Verfügung, auf der die standardmäßigen Tier-0- und Tier-1-Router ausgeführt werden, sowie die IPsec-VPN-Verbindungen und deren BGP-Routing-Maschinen. Der gesamte Nord-Süd-Datenverkehr führt durch den Tier-0-Router. Um zu verhindern, dass Ost-West-Datenverkehr durch die Edge-Appliance geleitet wird, wird auf jedem ESXi-Host eine Komponente jedes Tier-1-Routers ausgeführt, der das Routing für Ziele innerhalb des SDDC verarbeitet.

Wenn Sie zusätzliche Bandbreite für die Teilmenge dieses Datenverkehrs benötigen, der an SDDC-Gruppenmitglieder, an ein Direct Connect-Gateway, das an eine SDDC-Gruppe angehängt ist, HCX Service Mesh oder an die verbundene VPC weitergeleitet wird, können Sie Ihr SDDC als Multi-Edge rekonfigurieren und dazu Datenverkehrsgruppen erstellen, die jeweils einen zusätzlichen T0-Router erstellen. Weitere Informationen dazu finden Sie unter Konfigurieren eines Multi-Edge-SDDC mit Datenverkehrsgruppen.

Hinweis:

VPN-Datenverkehr sowie DX-Datenverkehr zu einem privaten VIF müssen den Standard-T0 passieren und können nicht an eine nicht standardmäßige Datenverkehrsgruppe weitergeleitet werden. Da NAT-Regeln außerdem immer auf dem Standard-T0-Router ausgeführt werden, können zusätzliche T0-Router den von SNAT- oder DNAT-Regeln betroffenen Datenverkehr nicht verarbeiten. Dazu gehört der Datenverkehr zur und von der nativen Internetverbindung des SDDC. Dies umfasst auch Datenverkehr zum Amazon S3-Dienst, der eine NAT-Regel verwendet und den Standard-T0 durchlaufen muss.

Verwaltungs-Gateway (MGW)
Das MGW ist ein Tier-1-Router, der für den vCenter Server und andere Verwaltung-Appliances, die im SDDC ausgeführt werden, Routing und Firewall-Ausführung übernimmt. Firewallregeln des Verwaltungs-Gateways werden auf dem MGW ausgeführt und steuern den Zugriff auf Verwaltungs-VMs. In der Standardkonfiguration blockieren diese Regeln den gesamten eingehenden Datenverkehr zum Verwaltungsnetzwerk (siehe Hinzufügen oder Ändern von Firewallregeln für das Verwaltungs-Gateway).
Computing-Gateway (CGW)
Das CGW ist ein Tier-1-Router, der den Netzwerkdatenverkehr für Arbeitslast-VMs übernimmt, die mit gerouteten Computing-Netzwerksegmenten verbunden sind. Computing-Gateway-Firewallregeln werden zusammen mit NAT-Regeln auf dem Tier-0-Router ausgeführt. In der Standardkonfiguration blockieren diese Regeln den gesamten Datenverkehr zu und von Computing-Netzwerksegmenten (siehe Konfigurieren des Computing-Gateway-Netzwerks und der Sicherheit).

Routing zwischen Ihrem SDDC und der verbundenen VPC

Wichtig:

Alle VPC-Subnetze, auf denen AWS-Dienste oder -Instanzen mit dem SDDC kommunizieren, müssen der Hauptroutentabelle der verbundenen VPC zugeordnet werden. Die Verwendung einer benutzerdefinierten Routentabelle oder der Austausch der Hauptroutentabelle wird nicht unterstützt.

Wenn Sie ein SDDC erstellen, weisen wir vorab 17 elastische AWS-Netzwerkschnittstellen (Elastic Network Interfaces, ENIs) im ausgewählten VPC zu, die sich im Besitz des AWS-Kontos befinden, das Sie bei der SDDC-Erstellung angegeben haben. Wir weisen jeder dieser ENIs eine IP-Adresse aus dem Subnetz zu, das Sie bei der SDDC-Erstellung angeben, und hängen anschließend jeden der Hosts im SDDC-Cluster Cluster-1 an eine dieser ENIs an. Dem ENI, auf dem die aktive NSX Edge Appliance ausgeführt wird, wird eine zusätzliche IP-Adresse zugewiesen.

Diese als „Verbundene VPC“ bezeichnete Konfiguration unterstützt den Netzwerkdatenverkehr zwischen VMs in den SDDC- und AWS-Instanzen sowie den nativen AWS-Dienstendpunkten im verbundenen VPC. Die Hauptroutentabelle des verbundenen VPC kennt das primäre Subnetz des VPC sowie alle SDDC (NSX-T-Netzwerksegment)-Subnetze. Beim Erstellen oder Löschen von gerouteten Netzwerksegmenten auf dem SDDC wird die Hauptroutentabelle automatisch aktualisiert. Wenn die NSX Edge-Appliance in Ihrem SDDC auf einen anderen Host verschoben wird, entweder zur Wiederherstellung nach einem Fehler oder während der SDDC-Wartung, wird die der Edge-Appliance zugewiesene IP-Adresse in den neuen ENI (auf den neuen Host) verschoben und die Hauptroutentabelle wird aktualisiert, um die Änderung widerzuspiegeln. Wenn Sie die Hauptroutentabelle ausgetauscht haben oder eine benutzerdefinierte Routentabelle verwenden, schlägt diese Aktualisierung fehl, und der Netzwerkdatenverkehr kann nicht mehr zwischen SDDC-Netzwerken und dem verbundenen VPC umgeleitet werden. Unter Anzeigen der Informationen zur verbundenen VPC finden Sie weitere Informationen, wie Sie die VMC Console verwenden, um die Details Ihrer verbundenen VPC anzuzeigen.

Eine ausführliche Besprechung der SDDC-Netzwerkarchitektur und der AWS-Netzwerkobjekte, die diese unterstützen, finden Sie im VMware Cloud Tech Zone-Artikel VMware Cloud on AWS: SDDC-Netzwerkarchitektur.

Reservierte Netzwerkadressen

Bestimmte IPv4-Adressbereiche können in SDDC-Computing-Netzwerken nicht verwendet werden. Einige Bereiche werden intern durch SDDC-Netzwerkkomponenten verwendet. Die meisten sind durch Konventionen auch in anderen Netzwerken reserviert.
Tabelle 1. Reservierte Adressbereiche in SDDC-Netzwerken
  • 10.0.0.0/15
  • 172.31.0.0/16
Diese Bereiche sind innerhalb des SDDC-Verwaltungssubnetzes reserviert, können aber in Ihren lokalen Netzwerken oder in SDDC-Computing-Netzwerksegmenten verwendet werden.
100.64.0.0/16 Reserviert für Carrier-Grade-NAT gemäß RFC 6598.) Verwenden Sie Adressen in diesem Bereich möglichst nicht SDDC- und anderen Netzwerken. Sie sind wahrscheinlich weder innerhalb des SDDC noch von außen erreichbar. Eine detaillierte Aufschlüsselung, wie SDDC-Netzwerke diesen Adressbereich verwenden, finden Sie im VMware Knowledgebase-Artikel 76022.
  • 169.254.0.0/19
  • 169.254.64.0/24
  • 169.254.101.0/30
  • 169.254.105.0/24
  • 169.254.106.0/24
GemäßRFC 3927 ist 169.254.0.0/16 ein link-local-Bereich, der nicht über ein einzelnes Subnetz hinaus geroutet werden kann. Mit Ausnahme dieser CIDR-Blöcke können Sie jedoch 169.254.0.0/16-Adressen für Ihre virtuellen Tunnelschnittstellen verwenden. Weitere Informationen hierzu finden Sie unter Erstellen eines routenbasierten VPN.
192.168.1.0/24 Dies ist das Standard-Computing-Segment-CIDR für ein Starter-SDDC mit einem Host. In anderen Konfigurationen ist es nicht reserviert.
SDDC-Netzwerke beachten auch die Konventionen für IPv4-Adressbereiche zur besonderen Verwendung, die in RFC 3330 aufgezählt sind.

Multicast-Unterstützung in SDDC-Netzwerken

In SDDC-Netzwerken wird Multicast-Datenverkehr der Ebene 2 als Broadcast-Datenverkehr im Netzwerksegment behandelt, in dem der Datenverkehr seinen Ursprung hat. Er wird nicht über dieses Segment hinaus geroutet. Optimierungsfunktionen für Multicast-Datenverkehr der Ebene 2, wie zum Beispiel IGMP-Snooping, werden nicht unterstützt. Multicast der Ebene 3 (wie zum Beispiel protokollunabhängiger Multicast) wird in VMware Cloud on AWS nicht unterstützt.

Verbinden Ihres lokalen SDDCs mit Ihrem Cloud-SDDC

Um Ihr lokales Datencenter mit Ihrem VMware Cloud on AWS-SDDC zu verbinden, können Sie ein VPN erstellen, das das öffentliche Internet verwendet, ein VPN, das AWS Direct Connect verwendet, oder nur AWS Direct Connect allein verwenden. Sie können SDDC-Gruppen auch nutzen, um mit VMware Transit Connect™ und einem AWS Direct Connect-Gateway eine zentralisierte Konnektivität zwischen einer Gruppe von VMware Cloud on AWS-SDDCs und einem lokalen SDDC bereitzustellen. Weitere Informationen finden Sie unter Erstellen und Verwalten von SDDC-Bereitstellungsgruppen im VMware Cloud on AWS Operations Guide.
Abbildung 2. SDDC-Verbindungen zu Ihrem lokalen Datencenter
Layer-3(L3)-VPN
Ein Layer 3-VPN bietet eine sichere Verbindung zwischen Ihrem lokalen Datencenter und Ihrem VMware Cloud on AWS-SDDC über das öffentliche Internet oder AWS Direct Connect. Diese IPSec-VPNs können entweder routenbasiert oder richtlinienbasiert sein. Sie können bis zu sechzehn VPNs jedes Typs erstellen, indem Sie einen beliebigen lokalen Router verwenden, der die in IPsec-VPN-Einstellungen - Referenz als lokale Endpoints aufgeführten Einstellungen unterstützt.
Layer-2-VPN (L2)
Ein Layer-2-VPN ist ein erweitertes oder ausgedehntes Netzwerk mit einem einzelnen IP-Adressbereich, der sich über Ihr lokales Datencenter und Ihr SDDC erstreckt und eine Hot- oder Cold-Migration von lokalen Arbeitslasten zum SDDC ermöglicht. Sie können in jedem SDDC nur einen einzelnen L2VPN-Tunnel erstellen. Das lokale Ende des Tunnels erfordert NSX. Wenn Sie NSX nicht bereits in Ihrem lokalen Datencenter verwenden, können Sie eine eigenständige NSX Edge-Appliance herunterladen, um die erforderlichen Funktionen bereitzustellen. Ein L2-VPN kann über das öffentliche Internet oder über AWS Direct Connect eine Verbindung Ihres lokalen Datencenters mit dem SDDC herstellen.
AWS Direct Connect (DX)
AWS Direct Connect ist ein von AWS bereitgestellter Dienst, der es Ihnen ermöglicht, eine Hochgeschwindigkeitsverbindung mit geringer Latenz zwischen Ihrem lokalen Datencenter und den AWS-Diensten zu erstellen. Wenn Sie AWS Direct Connect konfigurieren, können VPNs es verwenden, anstatt den Datenverkehr über das öffentliche Internet zu leiten. Da Direct Connect das BGP-Routing (Border Gateway Protocol) implementiert, ist beim Konfigurieren von Direct Connect die Verwendung eines L3VPN für das Verwaltungsnetzwerk optional. Der Datenverkehr über Direct Connect ist nicht verschlüsselt. Wenn Sie diesen Datenverkehr verschlüsseln möchten, können Sie ein IPsec-VPN konfigurieren, das private IP-Adressen und Direct Connect verwendet.
VMware HCX
VMware HCX, eine Multi-Cloud-App-Mobilitätslösung, wird allen SDDCs kostenlos zur Verfügung gestellt und erleichtert die Migration von Arbeitslast-VMs zu und von Ihrem lokalen Datencenter zu Ihrem SDDC. Weitere Informationen zum Installieren, Konfigurieren und Verwenden von HCX finden Sie unter Checkliste für Hybrid-Migration mit HCX.