Azure VMware Solution – Netzwerk- und Interkonnektivitätskonzepte
Azure VMware Solution stellt eine private Cloudumgebung bereit, die über lokale Standorte und Azure-basierte Ressourcen zugänglich ist. Die Konnektivität wird über Dienste wie Azure ExpressRoute, über VPN-Verbindungen oder über Azure Virtual WAN bereitgestellt. Diese Dienste benötigen jedoch bestimmte Netzwerkadressbereiche und Firewallports für die Aktivierung der Dienste.
Wenn Sie eine private Cloud bereitstellen, werden private Netzwerke für Verwaltung, Bereitstellung und vMotion erstellt. Sie verwenden diese privaten Netzwerke, um auf VMware vCenter Server und VMware NSX-Manager sowie auf VM-vMotion oder -Bereitstellung zuzugreifen.
ExpressRoute Global Reach wird verwendet, um private Clouds mit lokalen Umgebungen zu verbinden. Leitungen werden direkt auf der Microsoft Edge-Ebene verbunden. Die Verbindung erfordert ein virtuelles Netzwerk (VNet) mit einer ExpressRoute-Leitung zur lokalen Umgebung in Ihrem Abonnement. Der Grund dafür: VNet-Gateways (ExpressRoute-Gateways) können keinen Datenverkehr übertragen. Das bedeutet, dass Sie zwar zwei Verbindungen an das gleiche Gateway anfügen können, der Datenverkehr aber nicht von einer Verbindung an die andere gesendet wird.
Jede Azure VMware Solution-Umgebung ist eine eigene ExpressRoute-Region (ein eigenes virtuelles MSEE-Gerät), mit der Sie Global Reach mit dem „lokalen“ Peeringstandort verbinden können. Es ermöglicht Ihnen, mehrere Azure VMware Solution-Instanzen in einer Region mit demselben Peeringstandort zu verbinden.
Hinweis
Für Standorte, an denen ExpressRoute Global Reach nicht aktiviert ist (beispielsweise aufgrund örtlicher Bestimmungen), muss eine Routinglösung mit Azure-IaaS-VMs erstellt werden. Einige Beispiele finden Sie unter Azure Cloud Adoption Framework – Netzwerktopologie und -konnektivität für Azure VMware Solution.
In der privaten Cloud bereitgestellte virtuelle Computer sind vom Internet aus über die öffentliche IP-Adresse von Azure Virtual WAN zugänglich. Bei neuen privaten Clouds ist der Internetzugriff standardmäßig deaktiviert.
Private Cloudangebote für Azure VMware Solution bieten zwei Typen von Konnektivität:
Die allgemeine reine Azure-Interkonnektivität ermöglicht Ihnen die Verwaltung und Nutzung Ihrer privaten Cloud mit nur einem einzelnen virtuellen Netzwerk in Azure. Dieses Setup eignet sich ideal für Auswertungen oder Implementierungen, die keinen Zugriff aus lokalen Umgebungen erfordern.
Vollständige Interkonnektivität zwischen lokalen und privaten Clouds erweitert die allgemeine reine Azure-Implementierung um die Interkonnektivität zwischen lokalen und privaten Azure VMware Solution-Clouds.
In diesem Artikel werden wichtige Netzwerk- und Konnektivitätskonzepte erläutert, einschließlich Anforderungen und Einschränkungen. Außerdem werden Informationen bereitgestellt, die Sie zum Konfigurieren Ihres Netzwerks mit Azure VMware Solution benötigen.
Anwendungsfälle für private Azure VMware Solution-Clouds
Die Anwendungsfälle für private Azure VMware Solution-Clouds umfassen:
- Neue VMware vSphere-VM-Workloads in der Cloud
- Bursting von VM-Workloads in die Cloud (nur lokal zu Azure VMware Solution)
- Migration von VM-Workloads in die Cloud (nur lokal zu Azure VMware Solution)
- Notfallwiederherstellung (Azure VMware Solution zu Azure VMware Solution oder lokal zu Azure VMware Solution)
- Nutzung von Azure-Diensten
Tipp
Bei allen Anwendungsfällen für den Azure VMware Solution-Dienst bestehen Verbindungen zwischen lokalen Standorten und privaten Clouds.
Azure Virtual Network-Interkonnektivität
Sie können Ihr virtuelles Azure-Netzwerk mit der Implementierung der privaten Azure VMware Solution-Cloud verbinden. Diese Verbindung ermöglicht Ihnen, Ihre private Azure VMware Solution-Cloud zu verwalten, Workloads in Ihrer privaten Cloud zu nutzen und auf weitere Azure-Dienste zugreifen.
Die folgende Abbildung veranschaulicht die grundlegende Netzwerkkonnektivität, die während der Bereitstellung einer privaten Cloud eingerichtet wird. Die Abbildung zeigt logische Netzwerkverbindungen zwischen einem virtuellen Netzwerk in Azure und einer privaten Cloud. Diese Verbindung wird über ein ExpressRoute-Back-End hergestellt, das Teil des Azure VMware Solution-Diensts ist. Die Konnektivität unterstützt die folgenden drei primären Anwendungsfälle:
- Eingehender Zugriff auf vCenter Server und NSX Manager von VMs in Ihrem Azure-Abonnement
- Ausgehender Zugriff von VMs in der privaten Cloud auf Azure-Dienste.
- Eingehender Zugriff von Workloads, die in der privaten Cloud ausgeführt werden
Wichtig
Wenn Sie private Azure VMware Solution-Clouds in einer Produktionsumgebung mit einem virtuellen Azure-Netzwerk verbinden, verwenden Sie ein virtuelles ExpressRoute-Netzwerkgateway mit der SKU „Ultra Performance Gateway“ und aktivieren FastPath, um eine Konnektivität mit 10 GBit/s zu erzielen. Verwenden Sie für weniger kritische Umgebungen die SKUs „Standard“ oder „High Performance Gateway“ für eine geringere Netzwerkleistung.
Hinweis
Wenn Sie mehr als vier private Azure VMware Solution-Clouds in derselben Azure-Region mit demselben virtuellen Azure-Netzwerk verbinden müssen, verwenden Sie AVS Interconnect, um private Cloudkonnektivität innerhalb der Azure-Region zusammenzufassen.
Lokale Interkonnektivität
Im vollständig vernetzten Szenario können Sie über Ihre virtuellen Azure-Netzwerke und lokal auf Azure VMware Solution zugreifen. Diese Implementierung erweitert die grundlegende Implementierung, die im vorherigen Abschnitt beschrieben wurde. Um aus lokalen Umgebungen eine Verbindung mit Ihrer privaten Azure VMware Solution-Cloud herzustellen, ist eine ExpressRoute-Verbindung erforderlich.
Die nachstehende Abbildung zeigt die Konnektivität von lokalen mit privaten Clouds, die die folgenden Anwendungsfälle ermöglicht:
- Heiße/Kalte Migration mit vSphere vMotion zwischen lokalen Umgebungen und Azure VMware Solution.
- Verwaltungszugriff von der lokalen Umgebung auf die private Azure VMware Solution-Cloud.
Für eine vollständige Interkonnektivität mit Ihrer privaten Cloud aktivieren Sie ExpressRoute Global Reach und fordern dann einen Autorisierungsschlüssel und eine private Peering-ID für Global Reach im Azure-Portal an. Der Autorisierungsschlüssel und die Peering-ID dienen dazu, Global Reach zwischen einer ExpressRoute-Leitung in Ihrem Abonnement und der ExpressRoute-Leitung für Ihre private Cloud zu aktivieren. Nachdem die beiden ExpressRoute-Leitungen verknüpft wurden, wird der Netzwerkdatenverkehr zwischen Ihren lokalen Umgebungen und der privaten Cloud darüber geleitet. Weitere Informationen zu diesen Verfahren finden Sie im Tutorial zum Erstellen eines ExpressRoute Global Reach-Peerings mit einer privaten Cloud.
Wichtig
Kündigen Sie keine falschen Routen über ExpressRoute aus Ihren lokalen oder Azure VNet-Umgebungen an. Beispiele für falsche Routen sind 0.0.0.0/5 oder 192.0.0.0/3.
Weiterleiten von Ankündigungsrichtlinien zu Azure VMware Solution
Befolgen Sie die folgenden Richtlinien, wenn Sie Routen von Ihrem lokalen und Ihrem virtuellen Azure-Netzwerk zu Azure VMware Solution über ExpressRoute ankündigen:
| Unterstützt | Nicht unterstützt |
|---|---|
| Standardroute: 0.0.0.0/0* | Falsche Routen Beispiele: 0.0.0.0/1, 128.0.0.0/1 0.0.0.0/5 oder 192.0.0.0/3. |
RFC-1918-Adressblöcke Beispiel: (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) oder seine Subnetze (10.1.0.0/16, 172.24.0.0/16, 192.168.1.0/24) |
Spezieller von IANA reservierter Adressblock Beispiel: RFC 6598-100.64.0.0/10 und seine Subnetze |
| Öffentlicher IP-CIDR-Block im Kundenbesitz und die zugehörigen Subnetze |
Hinweis
Die kundenseitig angekündigte Standardroute zu Azure VMware Solution kann nicht verwendet werden, um den Datenverkehr zurückzuleiten, wenn die Kunden/Kundinnen auf Azure VMware Solution-Verwaltungsappliances zugreifen (vCenter Server, NSX Manager, HCX Manager). Die Kunden oder Kundinnen müssen eine spezifischere Route zu Azure VMware Solution ankündigen, damit dieser Datenverkehr zurückgeleitet werden kann.
Begrenzungen
In der nachstehenden Tabelle werden die maximalen Grenzwerte für Azure VMware Solution beschrieben.
| Ressource | Begrenzung |
|---|---|
| vSphere-Cluster pro privater Cloud | 12 |
| Mindestanzahl von ESXi-Hosts pro Cluster | 3 (harte Grenze) |
| Maximale Anzahl von ESXi-Hosts pro Cluster | 16 (harte Grenze) |
| Maximale Anzahl von ESXi-Hosts pro privater Cloud | 96 |
| Maximale Anzahl von vCenter Servern pro privater Cloud | 1 (harte Grenze) |
| Maximale Anzahl von HCX-Standortpaaren | 25 (beliebige Edition) |
| Maximale Anzahl von HCX-Dienstmeshes | 10 (alle Editionen) |
| Maximale Anzahl von mit Azure VMware Solution ExpressRoute verknüpften privaten Clouds von einem einzelnen Standort mit einem einzelnen Gateway für virtuelle Netzwerk | 4 Das verwendete Gateway für virtuelle Netzwerke bestimmt die tatsächliche maximale Anzahl von verknüpften privaten Clouds. Weitere Informationen finden Sie unter Informationen zu ExpressRoute-Gateways für virtuelle Netzwerke. Wenn Sie diesen Schwellenwert überschreiten, verwenden Sie Azure VMware Solution Interconnect, um die Konnektivität der privaten Cloud innerhalb der Azure-Region zu aggregieren. |
| Azure VMware Solution ExpressRoute: Maximaler Durchsatz | 10 Gbit/s (verwenden der Ultra Performance Gateway-SKU mit aktiviertem FastPath)** Das verwendete virtuelle Netzwerkgateway bestimmt die tatsächliche Bandbreite. Weitere Informationen finden Sie unter Informationen zu ExpressRoute-Gateways für virtuelle Netzwerke. Azure VMware Solution ExpressRoutes haben keine Portgeschwindigkeitseinschränkungen und bieten eine Leistung von mehr als 10 Gbit/s. Die Preise für über 10 GBit/s sind jedoch aufgrund von QoS nicht garantiert. |
| Maximale Anzahl von Azure Public IPv4-Adressen, die dem NSX zugewiesen sind | 2\.000 |
| Maximale Anzahl von Azure VMware Solution Interconnects pro privater Cloud | 10 |
| Maximale Anzahl von Azure ExpressRoute Global Reach-Verbindungen pro privater Azure VMware Solution-Cloud | 8 |
| vSAN-Kapazitätsgrenzen | 75 Prozent der insgesamt nutzbaren Kapazität (25 Prozent werden für die SLA vorgehalten) |
| VMware Site Recovery Manager – Maximale Anzahl geschützter VMs | 3,000 |
| VMware Site Recovery Manager – Maximale Anzahl von VMs pro Wiederherstellungsplan | 2\.000 |
| VMware Site Recovery Manager – Maximale Anzahl von Schutzgruppen pro Wiederherstellungsplan | 250 |
| VMware Site Recovery Manager – RPO-Werte | 5 Minuten oder mehr * (harte Grenze) |
| VMware Site Recovery Manager – Maximale Anzahl von VMs pro Schutzgruppe | 500 |
| VMware Site Recovery Manager – Maximale Anzahl von Wiederherstellungsplänen | 250 |
* Informationen zu der Recovery Point Objective (RPO) von weniger als 15 Minuten finden Sie unter How the 5 Minute Recovery Point Objective Works im Verwaltungsleitfaden zu vSphere Replication.
** Dies ist der weiche und empfohlene Grenzwert. Basierend auf dem Szenario kann jedoch ein höherer Durchsatz unterstützt werden.
Verwenden Sie für andere VMware-spezifische Grenzwerte das Tool VMware von Broadcom-Konfigurationsmaximum.
Nächste Schritte
Nachdem Sie nun mit Konzepten von Azure VMware Solution-Netzwerken und -Verbindungen vertraut sind, sollten Sie sich über Folgendes informieren: