Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure-VMware-Lösung bietet eine private VMware-Cloudumgebung, auf die Benutzer und Anwendungen von lokalen und Azure-basierten Umgebungen oder Ressourcen aus zugreifen können. Die Konnektivität wird mithilfe von Netzwerkdiensten wie Azure ExpressRoute- und VPN-Verbindungen bereitgestellt. Zum Aktivieren dieser Dienste sind bestimmte Netzwerkadressbereiche und Firewallports erforderlich. Dieser Artikel hilft Ihnen, Ihr Netzwerk so zu konfigurieren, dass es mit der Azure-VMware-Lösung funktioniert.
In diesem Tutorial erfahren Sie mehr über:
- Überlegungen zum virtuellen Netzwerk und zur ExpressRoute-Leitung
- Anforderungen an Routing und Subnetz
- Erforderliche Netzwerkports für die Kommunikation mit den Diensten
- Überlegungen zu DHCP und DNS in Azure-VMware-Lösung
Voraussetzungen
Sie stellen sicher, dass alle Gateways, einschließlich des Diensts des ExpressRoute-Anbieters, eine ASN (Autonomous System Number, autonome Systemnummer) mit 4 Byte unterstützen. Azure-VMware-Lösung verwendet öffentliche ASNs mit 4 Bytes zum Ankündigen von Routen.
Überlegungen zum virtuellen Netzwerk und zur ExpressRoute-Leitung
Wenn Sie eine Verbindung virtueller Netzwerke in Ihrem Abonnement erstellen, wird die ExpressRoute-Leitung über Peering eingerichtet. Sie verwendet einen Autorisierungsschlüssel und eine Peering-ID, die Sie im Azure-Portal anfordern. Das Peering ist eine private 1:1-Verbindung zwischen Ihrer privaten Cloud und dem virtuellen Netzwerk.
Hinweis
Die ExpressRoute-Leitung ist nicht Teil einer privaten Cloudbereitstellung. Die Erläuterung der lokalen ExpressRoute-Leitung geht über den Rahmen dieses Dokuments hinaus. Wenn Sie eine lokale Verbindung mit Ihrer privaten Cloud benötigen, können Sie eine Ihrer vorhandenen ExpressRoute-Leitungen verwenden oder eine im Azure-Portal erwerben.
Wenn Sie eine private Cloud bereitstellen, erhalten Sie IP-Adressen für vCenter Server und NSX Manager. Um auf diese Verwaltungsschnittstellen zuzugreifen, erstellen Sie weitere Ressourcen im virtuellen Netzwerk Ihres Abonnements. Die Schritte zum Erstellen dieser Ressourcen und zum Einrichten des privaten Peerings mit ExpressRoute sind in den Tutorials beschrieben.
Das logische Netzwerk der privaten Cloud wird mit einer vorab bereitgestellten NSX-Konfiguration bereitgestellt. Ein Tier-0-Gateway und ein Tier-1-Gateway werden für Sie vorab bereitgestellt. Sie können ein Segment erstellen und an das vorhandene Tier-1-Gateway anfügen oder ein neues Tier-1-Gateway definieren und das Segment daran anfügen. Die logischen NSX-Netzwerkkomponenten unterstützen eine Ost-West-Konnektivität zwischen Workloads und eine Nord-Süd-Konnektivität mit dem Internet und Azure-Diensten.
Wichtig
Wenn Sie planen, Ihre Azure-VMware-Lösung-Hosts mithilfe von Azure NetApp Files-Datenspeichern zu skalieren, ist die Bereitstellung des VNet in der Nähe Ihrer Hosts mit einem virtuellen ExpressRoute-Netzwerkgateway von entscheidender Bedeutung. Je näher der Speicher sich an Ihren Hosts befindet, desto besser ist die Leistung.
Überlegungen zu Routing und Subnetz
Die private Azure-VMware-Lösung-Cloud wird über eine Azure ExpressRoute-Verbindung mit Ihrem virtuellen Azure-Netzwerk verbunden. Über diese Verbindung mit hoher Bandbreite und geringer Wartezeit können Sie von Ihrer privaten Cloudumgebung aus auf Dienste zugreifen, die in Ihrem Azure-Abonnement ausgeführt werden. Das Routing ist BGP-basiert (Border Gateway Protocol), das automatisch erfolgt und standardmäßig für jede Bereitstellung einer privaten Cloud aktiviert wird.
Für private Clouds von Azure-VMware-Lösung ist mindestens ein CIDR-Netzwerkadressblock vom Typ /22 für Subnetze erforderlich. Dieses Netzwerk ergänzt Ihre lokalen Netzwerke. Daher sollte sich der Adressblock nicht mit Adressblöcken überschneiden, die in anderen virtuellen Netzwerken in Ihrem Abonnement und Ihren lokalen Netzwerken verwendet werden. Verwaltungs-, vMotion- und Replikationsnetzwerke werden automatisch innerhalb dieses Adressblocks bereitgestellt.
Hinweis
Zulässige Bereiche für Ihren Adressblock sind die privaten RFC 1918-Adressräume (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) mit Ausnahme von 172.17.0.0/16. Das Replikationsnetzwerk gilt nicht für AV64-Knoten und ist für die allgemeine Deaktivierung zu einem zukünftigen Datum vorgesehen.
Wichtig
Vermeiden Sie die Verwendung der folgenden IP-Schemas, die für die Verwendung von NSX reserviert sind:
- 169.254.0.0/24: für das interne Transitnetz
- 169.254.2.0/23: für das Transitnetzwerk zwischen VRF-Instanzen
- 100.64.0.0/16: zum internen Verbinden von T1- und T0-Gateways
Beispiel für einen CIDR-Netzwerkadressblock vom Typ /22: 10.10.0.0/22
Subnetze:
| Verwendung des Netzwerks | Beschreibung | Subnetz | Beispiel |
|---|---|---|---|
| Verwaltung von privaten Clouds | Verwaltungsnetzwerk (wie beispielsweise vCenter, NSX) | /26 |
10.10.0.0/26 |
| Migrationen der HCX-Verwaltung | Lokale Konnektivität für HCX-Appliances (Downlinks) | /26 |
10.10.0.64/26 |
| Global Reach vorbehalten | Ausgehende Schnittstelle für ExpressRoute | /26 |
10.10.0.128/26 |
| NSX-DNS-Dienst | Integrierter NSX-DNS-Dienst | /32 |
10.10.0.192/32 |
| Reserviert | Reserviert | /32 |
10.10.0.193/32 |
| Reserviert | Reserviert | /32 |
10.10.0.194/32 |
| Reserviert | Reserviert | /32 |
10.10.0.195/32 |
| Reserviert | Reserviert | /30 |
10.10.0.196/30 |
| Reserviert | Reserviert | /29 |
10.10.0.200/29 |
| Reserviert | Reserviert | /28 |
10.10.0.208/28 |
| ExpressRoute-Peering | ExpressRoute-Peering | /27 |
10.10.0.224/27 |
| ESXi-Verwaltung | VMkernel-Schnittstellen für ESXi-Verwaltung | /25 |
10.10.1.0/25 |
| vMotion-Netzwerk | VMkernel-Schnittstellen für vMotion | /25 |
10.10.1.128/25 |
| Replikationsnetzwerk | Replikationsschnittstellen für vSphere | /25 |
10.10.2.0/25 |
| vSAN | VMkernel-Schnittstellen und Knotenkommunikation für vSAN | /25 |
10.10.2.128/25 |
| HCX-Uplink | Uplinks für HCX-IX- und NE-Appliances zu Remote-Peers | /26 |
10.10.3.0/26 |
| Reserviert | Reserviert | /26 |
10.10.3.64/26 |
| Reserviert | Reserviert | /26 |
10.10.3.128/26 |
| Reserviert | Reserviert | /26 |
10.10.3.192/26 |
Hinweis
Die ESXi-Netzwerke „management“, „vmotion“ und „replication“ sind technisch in der Lage, 125 Hosts zu unterstützen, unterstützen jedoch maximal 96, da 29 für „replacements/maintenance“ (19) und „HCX“ (10) reserviert sind.
Erforderliche Netzwerkports
| Quelle | Ziel | Protokoll | Port | Beschreibung |
|---|---|---|---|---|
| DNS-Server für die private Cloud | Lokaler DNS-Server | UDP | 53 | DNS-Client – Weiterleiten von Anfragen vom vCenter Server der Private Cloud für beliebige lokale DNS-Abfragen (siehe DNS-Abschnitt). |
| Lokaler DNS-Server | DNS-Server für die private Cloud | UDP | 53 | DNS-Client: Weiterleitung von Anforderungen lokaler Dienste an DNS-Server für die private Cloud (siehe DNS-Abschnitt) |
| Lokales Netzwerk | vCenter Server für die private Cloud | TCP (HTTP) | 80 | Von vCenter Server wird Port 80 für direkte HTTP-Verbindungen benötigt. Vom Port 80 werden Anforderungen an den HTTPS-Port 443 umgeleitet. Diese Umleitung ist hilfreich, wenn Sie http://server anstelle von https://server verwenden. |
| Verwaltungsnetzwerk für die private Cloud | Lokales Active Directory | TCP | 389/636 | Aktivieren Sie Azure VMware Solutions vCenter Server für die Kommunikation mit lokalen Active Directory/LDAP-Servern. Optional für die Konfiguration von lokalem AD als Identitätsquelle auf dem Private Cloud vCenter. Aus Sicherheitsgründen wird Port 636 empfohlen. |
| Verwaltungsnetzwerk für die private Cloud | Globaler Katalog des lokalen Active Directory | TCP | 3268/3269 | Aktivieren Sie den vCenter Server von Azure VMware Solution, damit er mit lokalen Active Directory-/LDAP-Globalkatalogservern kommunizieren kann. Optional für die Konfiguration von On-Premises AD als Identitätsquelle auf dem Private Cloud vCenter Server. Verwenden Sie Port 3269 für die Sicherheit. |
| Lokales Netzwerk | vCenter Server für die private Cloud | TCP (HTTPS) | 443 | Greifen Sie über ein lokales Netzwerk auf vCenter Server zu. Standardport für vCenter Server zum Lauschen auf vSphere Client-Verbindungen. Öffnen Sie den Port 443 in der Firewall, damit das vCenter Server-System Daten vom vSphere-Client empfangen kann. Das vCenter Server-System verwendet den Port 443 auch zur Überwachung der Datenübertragung von SDK-Clients. |
| Lokales Netzwerk | HCX Cloud Manager | TCP (HTTPS) | 9443 | Verwaltungsschnittstelle der virtuellen HCX Cloud Manager-Appliance für die HCX-Systemkonfiguration. |
| Lokales Administratornetzwerk | HCX Cloud Manager | SSH | 22 | SSH-Administratorzugriff auf das virtuelle HCX Cloud Manager-Gerät. |
| HCX-Manager | Interconnect (HCX-IX) | TCP (HTTPS) | 8123 | HCX-Massenmigrationssteuerung. |
| HCX-Manager | Interconnect (HCX-IX), Netzwerkerweiterung (HCX-NE) | TCP (HTTPS) | 9443 | Senden von Verwaltungsanweisungen an die lokale HCX Interconnect-Instanz mit der REST-API. |
| Interconnect (HCX-IX) | L2C | TCP (HTTPS) | 443 | Senden von Verwaltungsanweisungen von Interconnect an L2C, wenn L2C den gleichen Pfad verwendet wie Interconnect. |
| HCX-Manager, Interconnect (HCX-IX) | ESXi-Hosts | TCP | 80 443 902 | Verwaltung und OVF-Bereitstellung. |
| Interconnect (HCX-IX), Netzwerkerweiterung (HCX-NE) an der Quelle | Interconnect (HCX-IX), Netzwerkerweiterung (HCX-NE) am Zielstandort | UDP | 4500 | Erforderlich für IPsec Internetschlüsselaustausch (IKEv2) zur Kapselung von Workloads für den bidirektionalen Tunnel. Unterstützt Netzwerkadressen-Translation-Traversal (NAT-T). |
| Interconnect (HCX-IX) / Netzwerkerweiterung (HCX-NE) | Remote Interconnect (HCX-IX) / Netzwerkerweiterung (HCX-NE) | TCP,UDP | 5201 | Erforderlich für Diagnosen im Service-Mesh beim Perftest-Uplink-Test. (Von Port 4500 mithilfe von HCX 4.8 verschoben). |
| On-Premises-Interconnect (HCX-IX) | Cloud-Interconnect (HCX-IX) | UDP | 4500 | Erforderlich für IPsec Internetschlüsselaustausch (ISAKMP) für den bidirektionalen Tunnel. |
| Lokales vCenter Server-Netzwerk | Verwaltungsnetzwerk für die private Cloud | TCP | 8.000 | vMotion für VMs aus der lokalen vCenter Server-Instanz zur vCenter Server-Instanz in der privaten Cloud |
| HCX Connector | connect.hcx.vmware.com hybridity.depot.vmware.com |
TCP | 443 |
connect wird zum Überprüfen des Lizenzschlüssels benötigt.hybridity wird für Updates benötigt. |
Diese Tabelle enthält allgemeine Firewallregeln für typische Szenarien. Möglicherweise müssen Sie jedoch beim Konfigurieren von Firewallregeln weitere Elemente berücksichtigen. Beachten Sie, dass wenn als Quelle und Ziel „lokal“ angegeben ist, diese Informationen nur dann relevant sind, wenn Ihr Rechenzentrum über eine Firewall verfügt, die Flows überprüft. Wenn Ihre lokalen Komponenten nicht über eine Firewall zur Überprüfung verfügen, können Sie diese Regeln ignorieren.
Weitere Informationen finden Sie in der vollständigen Liste der VMware HCX-Portanforderungen.
Überlegungen zu DHCP und DNS-Namensauflösung
Anwendungen und Workloads, die in einer privaten Cloudumgebung ausgeführt werden, erfordern Namensauflösung und DHCP-Dienste zum Nachschlagen und für die IP-Adresszuweisung. Zur Bereitstellung dieser Dienste ist eine ordnungsgemäße DHCP- und DNS-Infrastruktur erforderlich. Sie können einen virtuellen Computer konfigurieren, um diese Dienste in Ihrer privaten Cloudumgebung bereitzustellen.
Verwenden Sie den im NSX-T-Rechenzentrum integrierten DHCP-Dienst oder einen lokalen DHCP-Server in der privaten Cloud, anstatt DHCP-Broadcastdatenverkehr über das WAN in den lokalen Standort zurückzuleiten.
Wichtig
Wenn Sie eine Standardroute für die Azure-VMware-Lösung ankündigen, müssen Sie zulassen, dass die DNS-Weiterleitung die konfigurierten DNS-Server erreicht, und diese müssen die Auflösung öffentlicher Namen unterstützen.
Festgelegte IP-Bereiche für Arc-fähige AVS
Wenn Sie beabsichtigen, Ihre Azure-VMware-Lösung Umgebung zu aktivieren, dürfen ihre SDDC- und Verwaltungs-CIDRs nicht mit den IP-Bereichen überlappen, die von der Arc-Ressourcenbrücke reserviert sind. Nachdem Sie Ihren SDDC bereitgestellt haben, können Sie den CIDR nicht mehr ändern. Vergewissern Sie sich, dass es vor der Bereitstellung keine Überlappung gibt. Informationen zu den reservierten IP-Bereichen finden Sie unter "Designated IP ranges for Arc resource bridge".
Nächste Schritte
In diesem Tutorial haben Sie mehr über die Überlegungen und Anforderungen im Zusammenhang mit der Bereitstellung einer privaten Azure-VMware-Lösung-Cloud erfahren. Nach der ordnungsgemäßen Einrichtung des Netzwerks können Sie im nächsten Tutorial Ihre private Azure-VMware-Lösung-Cloud erstellen.