Aktivieren der Konnektivität aus Azure VMware Solution

Einführung

In diesem Entwurfsmuster verfügt der Datenverkehr über einen dedizierten Pfad über den Microsoft-Backbone vom lokalen Rechenzentrum zur privaten AVS-Cloud (Azure VMware Solution). Diese Verbindung erfolgt über 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 Global Reach nicht unterstützt wird, ist der Übergang von der lokalen zur privaten AVS-Cloud möglich, indem Sie ein ExpressRoute-Gateway in Azure bereitstellen. Für die Bereitstellung einer End-to-End-Transitivität ist eine virtuelle Appliance im Hub Virtual Network (VNET) erforderlich. Weitere Informationen finden Sie im Abschnitt Untersuchung von Datenverkehr und Standardroutenanzeige.

Kundenprofil

Diese Architektur eignet sich ideal für:

• Nativen ausgehenden Datenverkehr mit geringer Latenz von den softwaredefinierten Rechenzentren (SDDC) von Azure VMware Solution ins Internet
• Direkten 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-Netzwerken
• Azure VMware Solution ins Internet
• Azure VMware Solution in lokale Rechenzentren

Komponenten der Architektur

Implementieren Sie dieses Szenario mit folgenden Komponenten:

• Einen 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)

Hinweis

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.

Grundlegende Entscheidung

Dieses Dokument empfiehlt die Standardroutenanzeige entweder von einem lokalen Rechenzentrum oder von AVS und geht von im Folgenden von diesem Entwurf aus. Wenn es erforderlich ist, dass die Standardroute aus Azure stammt, lesen Sie den Abschnitt Untersuchung von Datenverkehr und Standardroutenanzeige.

Überlegungen

• Aktivieren Sie öffentliche IP-Adressen bis zum NSX Edge im Azure-Portal. Dies ermöglicht direkte Verbindungen zu Azure VMware Solution mit geringer Latenz. Darüber hinaus kann die Anzahl ausgehender Verbindungen skaliert werden.
• 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 den Hochwasserschutz (verteilt und Gateway).

Ausgehend von AVS mithilfe von NSX-T oder NVA

Abdeckung der Untersuchung von Datenverkehr	Empfohlenes Lösungsdesign	Überlegungen	Internet-Breakout
– Internet Eingang – Internet Ausgang – Datenverkehr zum lokalen Rechenzentrum – Datenverkehr zu Azure Virtual Network – Datenverkehr innerhalb Azure VMware Solution	Verwenden Sie NSX-T oder eine NVA-Firewall eines Drittanbieters in Azure VMware Solution. Verwenden Sie den NSX-T Advanced Load Balancer für HTTPs oder NSX-T Firewall für Nicht-HTTPs-Datenverkehr. Öffentliche IP-Adresse für Internet-Breakout aus Azure VMware Solution, SNAT und DNAT.	Wählen Sie diese Option aus, um 0.0.0.0/0 die Route von der privaten Azure VMware Solution-Cloud die Aktivierung der öffentlichen IP bis zum NSX Edge in Azure-Portal anzukündigen. Diese Option ermöglicht Verbindungen mit geringer Latenz mit Azure sowie die Möglichkeit, die Anzahl ausgehender Verbindungen zu skalieren.	Azure VMware Solution

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 Eingang – Internet Ausgang - Lokales Rechenzentrum (eingehend)	Verwenden Sie lokal eine virtuelle Appliance 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 Sie die öffentliche 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-Appliances verwenden die Diensteinbindung, um Appliances auf dem Router der Ebene 0 zu platzieren. Router der Ebene 0 werden von Microsoft bereitgestellt und verwaltet und sind nicht für Endbenutzer verfügbar. Alle Netzwerkgeräte und Load Balancer müssen auf Ebene 1 platziert werden. Im nächsten Abschnitt wird die Standardroutenweitergabe von einem Drittanbietergerät in AVS erläutert.

NVA-Integration von Drittanbietern in AVS

Die Integration mithilfe von Appliances von Drittanbietern ist nach sorgfältiger Abwägung 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 bereitzustellen und alle nativen Funktionen für Hochverfügbarkeit für das Gerät zu implementieren.

Beachten Sie die Grenzwerte, wenn Sie sich für diese Implementierung entscheiden. Beispielsweise gibt es ein Limit von höchstens acht Virtuellen Netzwerkschnittstellenkarten (Network Interface Cards, NICs) auf einem virtuellen Computer. Weitere Informationen zum Platzieren von NVAs in AVS finden Sie hier: NSX-T-Firewallmuster

Hinweis

Microsoft unterstützt die Verwendung von Mobility Optimized Networking nicht, wenn NVAs von Drittanbietern verwendet werden.

Überlegungen zu Zielzonen

In diesem Abschnitt werden bewährte Methoden für die Integration von AVS in Ihre Azure-Zielzone beschrieben.

Azure Route Server

Der Azure Route Server (ARS) wird verwendet, um gelernte Routen von AVS dynamisch zu verteilen und Branch-to-Branch-Konnektivität für 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. Zu den Anwendungsfällen für den Azure Route Server gehören:

Dynamische Routenverteilung:

• Erlernen bestimmter Routen von AVS zu lokalen VNETs über das BGP (Border Gateway Protocol). 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 des Firewallübertragungsmechanismus 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 verwenden zu können, 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 Server

• Peer-NVA mit spezifischen, nicht Azure-ASNs. Da ARS beispielsweise 65515 verwendet, kann keine andere Appliance im VNET diese ASN (Autonomous System Number) verwenden.

• Unterstützung für IPv6

Integration in Azure NetApp Files

Azure NetApp Files (ANF) stellt über das NFS-Protokoll einen Network Attached Storage (NAS) bereit. ANF wird in einem Azure-VNET ausgeführt und stellt eine Verbindung mit Workloads in AVS her. Durch die Verwendung von NFS-Datenspeichern, die durch 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.
• Aktuell wird nur NFS v3 unterstützt.

Wenn unerwartete Wartezeiten auftreten, stellen Sie sicher, dass Ihre private AVS-Cloud und die ANF-Bereitstellung an dieselben AZs (Azure Availability Zones, Azure Verfügbarkeitszonen) angeheftet sind. Erstellen Sie für Hochverfügbarkeit ANF-Volumes in separaten AZs, und aktivieren Sie Cross Zone Replication

Wichtig

Microsoft unterstützt das Fastpath for Secured Azure VWAN-Hub nicht, bei dem die maximale Portgeschwindigkeit 20 GBit/s beträgt. Erwägen Sie die Verwendung von Hub- und Spoke-VNETs, wenn ein höherer Durchsatz erforderlich ist. Weitere Informationen zum Anfügen von Azure NetApp Files-Datenspeichern an Azure VMware Solution-Hosts finden Sie hier

VPN-Konnektivität aus einem lokalen Rechenzentrum

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. Für dieses Szenario sind ein VPN-Gateway und Azure Route Server erforderlich. Wie bereits erwähnt, aktiviert Azure Route Server die Übertragung zwischen dem VPN- und dem AVS ExpressRoute-Gateway.

Untersuchung von Datenverkehr

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 NVA-Drittanbietern in einem Hub-VNET oder bei Verwendung von Azure vWAN möglich. In einer Hub- und Spoke-Bereitstellung ist Azure Firewall jedoch nicht verfügbar, da es das BGP nicht beherrscht. Die Verwendung eines BGP-fähigen Geräts eines Drittanbieters ist jedoch möglich. Dieses Szenario funktioniert für die Überprüfung des Datenverkehrs von

• Lokal zu Azure
• Azure ins 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 Eingang – Internet Ausgang – Zu lokalem Rechenzentrum – Azure Virtual Network	Verwenden Sie Firewall-Lösungen von Drittanbietern in einem virtuellen Netzwerk des Hubs mit Azure Route Server. Verwenden Sie für HTTP/S-Datenverkehr das Azure Application Gateway. Verwenden Sie für nicht-HTTP/S-Datenverkehr eine Firewall von Drittanbietern in Azure. Verwenden Sie eine lokale Firewall-NVA von Drittanbietern. Stellen Sie Firewall-Lösungen von Drittanbietern in einem virtuellen Hub-Netzwerk mit Azure Route Server bereit.	Wählen Sie diese Option aus, um die 0.0.0.0/0 Route von einem NVA in Ihrem virtuellen Azure Hub-Netzwerk an eine Azure VMware Solution anzukündigen.	Azure

Zusätzliche Informationen

• 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 443 eingeben
• DNS-Überlegungen: Nutzen Sie bei Verwendung privater Endpunkte die hier verfügbare Anleitung: DNS-Konfiguration des privaten Azure-Endpunkts | 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-and-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 von NSX-T Data Center-Netzwerkkomponenten mit Azure VMware Solution.
• Weitere Informationen zu Azure Router Server finden Sie in der Produktübersicht Was ist Azure Route Server?

Sehen Sie sich als Nächstes andere Entwurfsmuster zum Herstellen der Konnektivität mit Azure VMware Solution an

Netzwerktopologie für mehrere Regionen