Checkliste für die Netzwerkplanung für Azure VMware Solution
Azure VMware Solution 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 Solution 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 Solution
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 Solution 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 ebenfalls vorab für Sie 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 Solution-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 Solution-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 Solution 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 Transitnetz 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 | Subnet | Beispiel |
|---|---|---|---|
| Verwaltung von privaten Clouds | Verwaltungsnetzwerk (wie beispielsweise vCenter, NSX) | /26 |
10.10.0.0/26 |
| HCX-Verwaltungsmigrationen | Lokale Konnektivität für HCX-Appliances (Downlinks) | /26 |
10.10.0.64/26 |
| Global Reach reserviert | 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 mit Remote-Peerknoten | /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
| `Source` | Ziel | Protokoll | Port | Beschreibung |
|---|---|---|---|---|
| DNS-Server für die private Cloud | Lokaler DNS-Server | UDP | 53 | DNS-Client: Weiterleitung von Anforderungen der vCenter Server-Instanz der privaten 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. Dieser Port ist optional und dient dazu, eine lokale AD-Instanz als Identitätsquelle für die vCenter-Instanz der privaten Cloud zu konfigurieren. Aus Sicherheitsgründen wird Port 636 empfohlen. |
| Verwaltungsnetzwerk für die private Cloud | Globaler Katalog für lokales Active Directory | TCP | 3268/3269 | Aktivieren Sie Azure VMware Solutions vCenter Server für die Kommunikation mit lokalen Active Directory/LDAP-Servern. 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 für virtuelle HCX Cloud Manager-Geräte 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 | Steuerung der HCX-Massenmigration. |
| 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 Ziel | 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). |
| Lokales 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.
Aspekte zu DHCP- und DNS-Auflö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 Solution 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.
Nächste Schritte
In diesem Tutorial haben Sie mehr über die Überlegungen und Anforderungen im Zusammenhang mit der Bereitstellung einer privaten Azure VMware Solution-Cloud erfahren. Nach der ordnungsgemäßen Einrichtung des Netzwerks können Sie im nächsten Tutorial Ihre private Azure VMware Solution-Cloud erstellen.