Aktivieren der Konnektivität über die Azure VMware-Lösung
Einleitung
In diesem Designmuster verläuft der Datenverkehr über einen dedizierten Pfad über das Microsoft-Backbone vom lokalen Rechenzentrum zur privaten Azure VMware Solution (AVS)-Cloud. Diese Verbindung erfolgt über die ExpressRoute Global Reach, einen Mechanismus, der einen direkten Pfad zum verwalteten Kunden bereitstellt, der dann eine Verbindung mit den AVS-dedizierten ExpressRoute-Verbindungen herstellen kann. Die private Cloud verfügt auch über einen separaten, isolierten Breakout vom NSX Edge zum Internet, sodass dieser Datenverkehr nicht über ExpressRoute geleitet wird.
Wichtig
Wenn Sie sich heute in einer Region befinden, in der die globale Reichweite nicht unterstützt wird, ist die Übertragung von der lokalen zu der privaten AVS-Cloud möglich, indem Sie ein Expressroute-Gateway in Azure bereitstellen. Für die Bereitstellung einer End-to-End-Transitivität ist ein virtuelles Gerät im virtuellen Netzwerks (VNET) des Hubs erforderlich. Weitere Informationen finden Sie im Abschnitt Untersuchung von Datenverkehr und Standardroutenanzeige.
Kundenprofil
Diese Architektur eignet sich ideal für:
- Niedrig latenter, nativ ausgehender Datenverkehr von SDDCs (softwaredefinierten Rechenzentren) von Azure VMware Solution ins Internet.
- Direkter Datenverkehr von lokalen Standorten zu Azure über ExpressRoute oder VPN.
- Eingehende L4/L7-Dienste für Workloads im SDDC, z. B. HTTPS.
Der Datenverkehr, der über die AVS NSX-Router fließt, umfasst in diesem Entwurf Folgendes:
- Azure VMware Solution in native virtuelle Azure-Netzwerke
- Azure VMware-Lösung im Internet
- Azure VMware-Lösung für lokale Rechenzentren
Architekturkomponenten
Implementieren Sie dieses Szenario mit:
- Ein NSX Advanced Load Balancer
- Eine öffentliche IP für den Internet-Breakout von Azure VMware Solution für die Quell- und Zieladressenübersetzung (SNAT/DNAT)
Anmerkung
Während der NSX Advanced Load Balancer (Avi) eingehende Funktionen direkt in NSX bereitstellt, ist diese Funktionalität auch mit WAF oder App Gateway v2 in Azure möglich.
Wichtige Entscheidung
Dieses Dokument empfiehlt die Standardroutenanzeige entweder lokal oder von AVS und geht diesem Entwurf aus. Wenn es erforderlich ist, dass die Standardroute aus Azure stammt, finden Sie weitere Informationen dazu unter Untersuchung von Datenverkehr und Standardroutenanzeige.
Überlegungen
- Aktivieren Sie öffentliche IP-Adressen bis zu NSX Edge im Azure-Portal. Dies ermöglicht direkte Verbindungen mit geringer Latenz zu Azure VMware Solution und die Möglichkeit, die Anzahl ausgehender Verbindungen zu skalieren.
- Wenden Sie die Regelerstellung der NSX-Firewall an.
- Verwenden Sie den NSX Advanced Load Balancer, um den Datenverkehr gleichmäßig an Workloads zu verteilen.
- Aktivieren Sie Flood-Schutz (Verteilt und Gateway).
Ausgehend von AVS mithilfe von NSX-T oder NVA
| Abdeckung der Untersuchung von Datenverkehr | Empfohlenes Lösungsdesign | Überlegungen | Internet-Ausbruch |
|---|---|---|---|
| – Internet (eingehend) – Internet (ausgehend) – Datenverkehr zum lokalen Rechenzentrum – Datenverkehr zum virtuellen Azure-Netzwerk – Datenverkehr innerhalb der Azure VMware-Lösung |
Verwenden Sie NSX-T oder eine NVA-Firewall eines Drittanbieters in der Azure VMware-Lösung. Verwenden Sie NSX-T Advanced Load Balancer für HTTPS oder NSX-T Firewall für Nicht-HTTP/S-Verkehr. Öffentliche IP-Adresse für den Internet-Breakout aus Azure VMware Solution, SNAT und DNAT. |
Wählen Sie diese Option, um die Route 0.0.0.0/0 aus der Azure VMware Solution Private Cloud bekanntzumachen. Aktivieren Sie öffentliche IP-Adressen bis zu NSX Edge im Azure-Portal. Diese Option ermöglicht Verbindungen mit geringer Latenz zu Azure und die Möglichkeit, die Anzahl der ausgehenden Verbindungen zu skalieren. |
Azure VMware-Lösung |
Ausgehender Datenfluss aus Azure VMware Solution über eine 0.0.0.0/0-Anzeige aus der lokalen Umgebung
| Abdeckung der Untersuchung von Datenverkehr | Empfohlenes Lösungsdesign | Überlegungen | Internet-Breakout |
|---|---|---|---|
| – Internet (eingehend) – Internet (ausgehend) – Ins lokale Rechenzentrum |
Verwenden Sie lokal ein virtuelles Gerät Für HTTP/S-Datenverkehr verwenden Sie den NSX Advanced Load Balancer oder Application Gateway in Azure. Verwenden Sie für Nicht-HTTP/S-Datenverkehr die NSX Distributed Firewall. Aktivieren einer öffentlichen IP-Adresse in Azure VMware Solution. |
Wählen Sie diese Option, um die Route 0.0.0.0/0 aus lokalen Rechenzentren anzukündigen. |
Lokal |
Wichtig
Einige herkömmliche VMware-Geräte verwenden die Diensteinfügung, um Geräte auf dem Router der Ebene 0 zu platzieren. Die Router der Stufe 0 werden von Microsoft bereitgestellt und verwaltet und werden nicht von Endbenutzern verwendet. Alle Netzwerkgeräte und Load Balancer müssen auf Stufe 1 platziert werden. Im nächsten Abschnitt wird die Standardroutenverteilung von einem Drittanbietergerät in AVS erläutert.
NVA-Integration von Drittanbietern in AVS
Die Integration mit Drittanbietergeräten ist mit sorgfältiger Berücksichtigung möglich. In diesem Entwurf liegen NVAs von Drittanbietern hinter einem oder mehreren Edgeroutern der Ebene 1.
Es liegt in der Verantwortung der Benutzer, eine Lizenz mitzubringen und alle Funktionen zur hohen Verfügbarkeit, die im Gerät integriert sind, zu implementieren.
Beachten Sie die Grenzwerte bei der Auswahl dieser Implementierung. Beispielsweise gibt es eine Grenze von bis zu acht virtuellen Netzwerkschnittstellenkarten (VIRTUAL Network Interface Cards, NICs) auf einem virtuellen Computer. Weitere Informationen zum Platzieren von NVAs in AVS finden Sie hier: NSX-T-Firewallmuster
Anmerkung
Microsoft unterstützt die Verwendung von Mobility Optimized Networking nicht, wenn NVAs von Drittanbietern verwendet werden.
Überlegungen zur Landezone
In diesem Abschnitt werden bewährte Methoden für die Integration von AVS in Ihre Azure Landing Zone beschrieben.
Azure Route Server
Azure Route Server (ARS) wird verwendet, um gelernte Routen von AVS dynamisch zu verteilen und Filiale-zu-Filiale-Konnektivität zu VPN-Gateways bereitzustellen. VNETs, die mit dem VNET verbunden sind, in dem sich der ARS befindet, lernen die Routen auch dynamisch. Das bedeutet, dass es in Azure möglich ist, Routen von AVS zu Hub- und Spoke-Umgebungen zu lernen. Anwendungsfälle für Azure Route Server umfassen:
Dynamische Routenverteilung:
- Lernen Sie spezifische Routen von AVS zu lokalen VNETs über BGP (Border Gateway Protocol) kennen. Auch die mithilfe von Peering verknüpften VNETs können dann die Routen lernen.
- NVA-Integration von Drittanbietern
- Peeren Sie ARS mit NVAs, sodass Sie keine UDRs für jedes AVS-Segment benötigen, um Datenverkehr zu filtern.
- Zurückgeben von Datenverkehr von gepeerten VNETs erfordert UDRs (User Defined Routes, benutzerdefinierte Routen) zurück an die lokale Schnittstelle der Firewall
- Transitmechanismus von Expressroute zu VPN-Gateways
- VPN Gateway muss vom Typ „Site-to-Site“ sein und für den Modus „Aktiv/Aktiv“ konfiguriert sein
Um Azure Route Server zu verwenden, müssen Sie:
Branch-to-Branch aktivieren
Verwenden Sie die Routenzusammenfassung für > 1.000 Routen oder
NO_ADVERTISE BGP communities„flag refenced“ in den häufig gestellten Fragen (FAQs) zu Azure Route ServerPeer-NVA mit spezifischen, nicht Azure-ASNs. Da ARS beispielsweise 65515 verwendet, kann keine andere Appliance im VNET diese ASN (Autonome Systemnummer) verwenden.
Keine Unterstützung für IPV6
Integration mit Azure NetApp Files
Azure NetApp Files (ANF) bietet Ihnen über das NFS-Protokoll einen netzwerkgebundenen Speicher. ANF befindet sich in einem Azure VNET und verbindet sich mit Workloads in AVS. Mithilfe von NFS-Datenspeichern, die von Azure NetApp Files unterstützt werden, können Sie Ihren Speicher erweitern, anstatt die Cluster zu skalieren.
- Erstellen von Azure NetApp Files-Volumes mit Standardnetzwerkfunktionen, um optimierte Konnektivität aus der privaten AVS-Cloud über ExpressRoute FastPath zu ermöglichen
- Bereitstellen von ANF in einem delegierten Subnetz
- Hub- und Spoke-Bereitstellung unterstützt ER-GW-SKU von bis zu 10 Gbit/s
- Ultra- und ErGw3AZ-SKU ist erforderlich, um die Geschwindigkeitsgrenzwerte des Gatewayports zu umgehen
- Eingehender Lesedatenverkehr und ausgehender Schreibdatenverkehr erfolgt über ExpressRoute. Ausgehender Datenverkehr über ExpressRoute-Leitungen umgeht das Gateway und geht direkt an den Edgerouter.
- Eingehende/ausgehende Gebühren werden von AVS unterdrückt, es gibt jedoch eine Gebühr für ausgehenden Datenverkehr, wenn Daten über gepeerte VNETs gehen.
- Verwenden Sie ein dediziertes ExpressRoute-Gateway für Azure Netapp-Dateien, verwenden Sie kein freigegebenes/zentralisiertes ExpressRoute-Gateway.
- Platzieren Sie keine Firewall oder NVA im Datenpfad zwischen Azure NetApp Files und Azure VMware Solution.
- Nur NFS v3 wird heute unterstützt.
Wenn unerwartete Latenz auftritt, stellen Sie sicher, dass Ihre AVS Private Cloud und die ANF-Bereitstellung der gleichen AZ (Azure-Verfügbarkeitszone) zugewiesen sind. Erstellen Sie für Hochverfügbarkeit ANF-Volumes in separaten VZs, und aktivieren Sie Cross Zone Replication
Wichtig
Microsoft unterstützt Fastpath nicht für gesicherte Azure VWAN-Hubs, bei denen die maximale Portgeschwindigkeit 20 Gbps beträgt. Erwägen Sie die Verwendung von Hub- und Spoke-VNETs, wenn ein höherer Durchsatz erforderlich ist. Erfahren Sie, wie Sie Azure NetApp Files-Datenspeicher an Azure VMware Solution Hosts anhängen hier
Lokal ausgehende VPN-Konnektivität
Es wird zwar eine ExpressRoute-Verbindung empfohlen, es ist aber auch eine Verbindung von einem lokalen Rechenzentrum aus mithilfe von IPSEC über ein TransitHub-VNET in Azure möglich. Dieses Szenario erfordert ein VPN-Gateway und einen Azure Route-Server. Wie bereits erwähnt, ermöglicht Azure Route Server die Transitivität zwischen dem VPN-Gateway und dem AVS Expressroute-Gateway.
Verkehrskontrolle
Wie bereits erwähnt, erfolgt die Standardroutenanzeige von AVS mit der öffentlichen IP-Adresse bis zur NSX Edge-Option. Es ist aber auch möglich, weiterhin die Standardroute von der lokalen Seite aus anzuzeigen. Die End-to-End-Datenverkehrsfilterung von einem lokalen Rechenzentrum zu AVS ist möglich, wenn die Firewall an einem dieser Endpunkte platziert wird.
Die Standardroutenanzeige von Azure ist mit einem Drittanbieter-NVA entweder in einem Hub-VNET oder bei Verwendung von Azure vWAN möglich. In einer Hub-and-Spoke-Bereitstellung kann Azure Firewall nicht verwendet werden, da es nicht mit BGP kompatibel ist. Sie können jedoch ein BGP-fähiges Gerät eines Drittanbieters verwenden. Dieses Szenario funktioniert für die Überprüfung des Datenverkehrs von:
- Lokal zu Azure
- Azure im Internet
- AVS ins Internet
- AVS zu Azure
Ein Drittanbieter-NVA im Hub-VNet prüft den Datenverkehr zwischen AVS und dem Internet und zwischen AVS und Azure VNets
| Anforderungen bezüglich der Untersuchung von Datenverkehr | Empfohlenes Lösungsdesign | Überlegungen | Internet-Breakout |
|---|---|---|---|
| – Internet (eingehend) - Internetausgang – Zum lokalen Rechenzentrum – Zum virtuellen Azure-Netzwerk |
Verwenden Sie Firewalllösungen von Drittanbietern in einem virtuellen Hubnetzwerk mit Azure Route Server. Für HTTP/S-Datenverkehr verwenden Sie das Azure Application Gateway. Verwenden Sie für nicht-HTTP/S-Datenverkehr eine Firewall von Drittanbietern in Azure. Verwenden Sie eine lokale Firewall-NVA eines Drittanbieters. Bereitstellen von Firewalllösungen von Drittanbietern in einem virtuellen Hubnetzwerk mit Azure Route Server. |
Wählen Sie diese Option aus, um die Route 0.0.0.0/0 von einem NVA in Ihrem virtuellen Azure Hub-Netzwerk an eine Azure VMware Solution anzukündigen. |
Azure |
Zusatzinformation
- Zugreifen auf vCenter mithilfe von Bastion + Jumpbox-VM: Wenn Sie von einem lokalen Rechenzentrum aus auf vCenter zugreifen, stellen Sie sicher, dass Sie eine Route von Ihren lokalen Netzwerken zum /22-AVS-Verwaltungsnetzwerk haben. Überprüfen Sie die Route in der CLI, in dem Sie
Test-NetConnection x.x.x.2 -port 443eingeben - DNS-Überlegungen – Wenn Private Endpunkte verwendet werden, befolgen Sie die hier beschriebenen Anleitungen: Azure Private Endpoint DNS-Konfiguration | Microsoft Learn
Nächste Schritte
- Weitere Informationen zur Übertragung von einem lokalen VPN zu Azure VMware Solution finden Sie im folgenden Artikel zur Übertragung von einem VPN zu ExR:
- Weitere Informationen zu Azure VMware Solution in Hub- und Spoke-Netzwerken finden Sie unter Integration von Azure VMware Solution in eine Hub-and-Spoke-Architektur.
- Weitere Informationen zu VMware NSX-T Data Center-Netzwerksegmenten finden Sie unter Konfigurieren NSX-T Data Center-Netzwerkkomponenten mithilfe von Azure VMware Solution.
- Weitere Informationen zu Azure Router Server finden Sie in der Produktübersicht Was ist Azure Route Server?
Betrachten Sie als Nächstes andere Entwurfsmuster für den Aufbau der Konnektivität für die Azure VMware-Lösung.