VMware Cloud on AWS verwendet NSX zum Erstellen und Verwalten von SDDC-Netzwerken. NSX bietet eine agile softwaredefinierte Infrastruktur zum Erstellen Cloud-nativer Anwendungsumgebungen.

Im Handbuch VMware Cloud on AWS – Netzwerk und Sicherheit wird erläutert, wie Sie die Registerkarte Netzwerk und Sicherheit in der VMware Cloud-Konsole verwenden, um Ihre SDDC-Netzwerke zu verwalten. Sie können auch die NSX Manager-Web-Benutzeroberfläche verwenden, um diese Netzwerke zu verwalten. Und ab SDDC-Version 1.22 können Sie unter Verwenden des Dashboards „Netzwerk und Sicherheit“ nachlesen, wo eine vereinfachte Ansicht des SDDC-Netzwerks mit Links zu relevanten NSX Manager-Funktionen bereitgestellt wird.

NSX Manager unterstützt eine Obermenge der Funktionen auf der Registerkarte Netzwerk und Sicherheit. Weitere Informationen zur Verwendung von NSX Manager finden Sie unter NSX Manager im Administratorhandbuch zu NSX Data Center. Der Zugriff auf den NSX Manager in Ihrem VMware Cloud on AWS-SDDC ist über eine öffentliche IP-Adresse möglich, die von jedem Browser erreicht werden kann, der eine Verbindung zum Internet herstellen kann. Sie können auch von Ihrem internen Netzwerk aus über ein VPN oder AWS Direct Connect darauf zugreifen. Weitere Informationen dazu finden Sie unter NSX Manager öffnen.

Das Layout und die Navigation in der NSX Manager-Web-Benutzeroberfläche ähneln denen auf der VMware Cloud-Konsole-Registerkarte Netzwerk und Sicherheit, und Sie können beide Tools verwenden, um die meisten Verfahren in diesem Dokument durchzuführen. Auf der Registerkarte Netzwerk und Sicherheit werden NSX-Funktionen für das Netzwerk (wie VPN, NAT und DHCP) mit NSX-Funktionen für Sicherheit (wie Firewalls) kombiniert. Wenn Sie in einem Verfahren NSX Manager verwenden müssen, weisen wir in den Voraussetzungen für das Verfahren darauf hin.

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 Server-, NSX- sowie 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. Informationen zu aktuellen Grenzwerten für logische Segmente finden Sie unter VMware Configuration Maximums. 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. Entsprechende Grenzwerte finden Sie unter VMware Configuration Maximums.

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). In der Standardkonfiguration verfügt jedes SDDC über einen einzelnen Tier-0-Router. Wenn ein SDDC Mitglied einer SDDC-Gruppe ist, können Sie das SDDC neu konfigurieren, um Tier-0-Router hinzuzufügen, die den Datenverkehr der SDDC-Gruppe verarbeiten. Siehe Konfigurieren eines Multi-Edge-SDDC mit Datenverkehrsgruppen.
  • Tier 1 verarbeitet Ost-West-Datenverkehr (Datenverkehr zwischen gerouteten Netzwerksegmenten innerhalb des SDDC). In der Standardkonfiguration verfügt jedes SDDC über einen einzelnen Tier-1-Router. Sie können bei Bedarf zusätzliche Tier-1-Gateways erstellen und konfigurieren. Weitere Informationen hierzu finden Sie unter Hinzufügen eines benutzerdefinierten Tier-1-Gateways zu einem VMware Cloud on AWS-SDDC.
Abbildung 1. SDDC-Netzwerktopologie
Ein Diagramm eines SDDC-Netzwerks, das über ein VPN und AWS Direct Connect mit einem lokalen Netzwerk verbunden ist.
NSX Edge Appliance

Die standardmäßige NSX Edge-Appliance wird als Paar von 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 standardmäßigen Tier-0-Router. Um zu verhindern, dass Ost-West-Datenverkehr durch die Appliance geleitet wird, wird auf jedem ESXi-Host, der das Routing für Ziele innerhalb des SDDC verarbeitet, eine Komponente jedes Tier-1-Routers ausgeführt.

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, an HCX Service Mesh oder an die verbundene VPC weitergeleitet wird, können Sie Ihr SDDC neu konfigurieren als SDDC mit mehreren Edges 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 einer 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 standardmäßigen T0-Router ausgeführt werden, können zusätzliche T0-Router keinen Datenverkehr verarbeiten, der NAT-Regeln unterliegt. 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 vCenter Server und andere Verwaltung-Appliances, die im SDDC ausgeführt werden, das Routing und die Firewall-Ausführung übernimmt. Firewallregeln des Verwaltungs-Gateways werden auf dem MGW ausgeführt und steuern den Zugriff auf Verwaltungs-VMs. In einem neuen SDDC wird die Internetverbindung als Nicht verbunden auf der Registerkarte Übersicht gekennzeichnet und bleibt blockiert, bis Sie eine Firewallregel für das Verwaltungs-Gateway erstellen, die Zugriff über eine vertrauenswürdige Quelle zulässt. 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

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. Der ENI, auf der 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 im SDDC und nativen AWS-Instanzen und -Diensten mit Adressen im primären CIDR-Block der verbundenen VPC. Beim Erstellen oder Löschen von gerouteten Netzwerksegmenten, die mit dem Standard-CGW verbunden sind, wird die Hauptroutentabelle automatisch aktualisiert. Wenn der Modus für verwaltete Präfixliste für die verbundene VPC aktiviert ist, werden die Hauptroutentabellen und alle benutzerdefinierten Routentabellen, denen Sie die verwaltete Präfixliste hinzugefügt haben, ebenfalls aktualisiert.

Die Schnittstelle der verbundenen VPC (oder DIENSTE) wird für sämtlichen Datenverkehr zu Zielen innerhalb des primären CIDR der verbundenen VPC verwendet. AWS-Dienste oder -Instanzen, die mit dem SDDC kommunizieren, müssen sich bei Verwendung der Standardkonfiguration in Subnetzen befinden, die mit der Hauptroutentabelle der verbundenen VPC verknüpft sind. Wenn der Modus für verwaltete AWS-Präfixliste aktiviert ist (siehe Aktivieren des Modus für verwaltete AWS-Präfixliste für die verbundene Amazon-VPC), können Sie die Verwaltete Präfixliste jeder benutzerdefinierten Routentabelle innerhalb der verbundenen VPC manuell hinzufügen, wenn AWS-Dienste und -Instanzen, die diese benutzerdefinierten Routentabellen verwenden, mit SDDC-Arbeitslasten über die DIENSTE-Schnittstelle kommunizieren sollen.

Wenn die NSX Edge-Appliance in Ihrem SDDC entweder zur Wiederherstellung nach einem Fehler oder während der SDDC-Wartung auf einen anderen Host verschoben wird, wird die der Appliance zugewiesene IP-Adresse in die neue ENI (auf dem neuen Host) verschoben, und die Hauptroutentabelle wird zusammen mit allen benutzerdefinierten Routentabellen, die eine verwaltete Präfixliste verwenden, aktualisiert, damit die Änderung widergespiegelt wird. Wenn Sie die Hauptroutentabelle ausgetauscht haben oder eine benutzerdefinierte Routentabelle verwenden, den Modus für verwaltete Präfixliste jedoch nicht aktiviert haben, schlägt diese Aktualisierung fehl, und der Netzwerkdatenverkehr kann nicht mehr zwischen SDDC-Netzwerken und dem verbundenen VPC umgeleitet werden. Unter Anzeigen von Informationen zur verbundenen VPC und Beheben von Problemen mit der verbundenen VPC finden Sie weitere Informationen, wie Sie die VMware Cloud-Konsole verwenden, um die Details Ihrer verbundenen VPC anzuzeigen.

VMware Cloud on AWS bietet mehrere Funktionen, mit denen Sie Routen zur verbundenen VPC, zu anderen VPCs und zu Ihren VMware Managed Transit Gateways aggregieren können. Weitere Informationen finden Sie unter Aktivieren des Modus für verwaltete AWS-Präfixliste für die verbundene Amazon-VPC.

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.
  • 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.
Hinweis: Die SDDC-Versionen 1.20 und früher reservieren auch 100.64.0.0/16 für Carrier-Grade-NAT gemäß RFC 6598. Vermeiden Sie die Verwendung von Adressen in diesem Bereich in SDDC-Versionen vor 1.22. Eine detaillierte Aufschlüsselung dazu, wie ältere SDDC-Netzwerke den Adressbereich 100.64.0.0/16 verwenden, finden Sie im VMware Knowledgebase-Artikel 76022 und weitere Informationen zu Änderungen bei reservierten Adressbereichen in SDDC-Version 1.22 finden Sie im VMware Knowledgebase-Artikel 92322.
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 , ein VPN, das AWS Direct Connect verwendet, oder nur alleinige Verwendung von AWS Direct Connect. Sie können SDDC-Gruppen auch nutzen, um mit VMware Transit Connect und einem AWS Direct Connect-Gateway eine zentrale Verbindung zwischen einer Gruppe von VMware Cloud on AWS-SDDCs und einem lokalen SDDC herzustellen. Weitere Informationen finden Sie unter Erstellen und Verwalten von SDDC-Bereitstellungsgruppen.
Abbildung 2. SDDC-Verbindungen zu Ihrem lokalen Datencenter
Ein Diagramm, das zeigt, wie ein SDDC-Netzwerk über ein VPN, HCX und AWS Direct Connect mit einem lokalen Netzwerk verbunden werden kann.
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. Für den lokalen Endpoint können Sie jedes Gerät verwenden, das die in IPsec-VPN-Einstellungen - Referenz 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 eine Verbindung Ihres lokalen Datencenters mit dem SDDC herstellen. Dies geschieht über das öffentliche Internet oder AWS Direct Connect.
AWS Direct Connect (DX)
AWS Direct Connect ist ein von AWS bereitgestellter Dienst, der eine Hochgeschwindigkeitsverbindung mit geringer Latenz zwischen Ihrem lokalen Datencenter und den AWS-Diensten herstellt. Wenn Sie AWS Direct Connect konfigurieren, können VPNs den Datenverkehr über DX statt über das öffentliche Internet weiterleiten. Da DX das BGP-Routing (Border Gateway Protocol) implementiert, ist beim Konfigurieren von DX die Verwendung eines L3VPN für das Verwaltungsnetzwerk optional. DX-Datenverkehr ist nicht verschlüsselt. Wenn Sie diesen Datenverkehr verschlüsseln möchten, konfigurieren Sie ein IPsec-VPN, das DX und eine private IP-Adresse 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.

Überlegungen zur MTU für internen und externen Datenverkehr

Der interne Netzwerkdatenverkehr im SDDC (einschließlich des Datenverkehrs zur und von der verbundenen VPC) unterstützt eine MTU von maximal 8.900 Byte. Der Datenverkehr zum MGW ist in der Regel auf 1.500 Byte begrenzt, da die Schnittstellen der Verwaltungs-Appliance eine MTU von 1.500 verwenden. Weitere MTU-Standardwerte sind unter Maximalwerte für VMware-Konfiguration aufgeführt. Die folgenden Richtlinien gelten für MTU-Werte im gesamten SDDC-Netzwerk:
  • SDDC-Gruppe und DX nutzen dieselbe Schnittstelle und müssen daher den niedrigeren MTU-Wert (8.500 Byte) verwenden, wenn beide Verbindungen in Gebrauch sind.
  • Alle VM-Netzwerkkarten und -Schnittstellen im selben Segment müssen dieselbe MTU aufweisen.
  • Die MTU kann zwischen Segmenten unterschiedlich sein, solange die Endpoints PMTUD unterstützen und alle Firewalls im Pfad ICMP-Datenverkehr zulassen.
  • Die Schicht-3-MTU (IP) muss kleiner oder gleich der maximal unterstützten Paketgröße (MTU) der zugrunde liegenden Schicht-2-Verbindung abzüglich des Protokoll-Overheads sein. In VMware Cloud on AWS ist dies das NSX-Segment, das Schicht-3-Pakete mit einer MTU von bis zu 8.900 Byte unterstützt.

Grundlegendes zur SDDC-Netzwerkleistung

Eine ausführliche Erläuterung der SDDC-Netzwerkleistung finden Sie im VMware Cloud Tech Zone Designlet Understanding VMware Cloud on AWS Network Performance.