Überlegungen zum Netzwerkentwurf 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. Netzwerkdienste wie Azure ExpressRoute und VPN-Verbindungen (virtuelles privates Netzwerk) stellen die Konnektivität bereit.
Vor dem Einrichten Ihrer Azure VMware Solution-Umgebung sollten Sie eine Reihe wichtiger Überlegungen im Zusammenhang mit dem Netzwerk berücksichtigen. Dieser Artikel enthält Lösungen für Anwendungsfälle, die möglicherweise auftreten, wenn Sie Azure VMware Solution zum Konfigurieren Ihrer Netzwerke verwenden.
Kompatibilität von Azure VMware Solution mit vorangestelltem AS-Pfad
Beim Netzwerkentwurf für Azure VMware Solution sind einige Punkte bezüglich der Verwendung von vorangestellten AS-Pfaden für redundante ExpressRoute-Konfigurationen zu beachten. Wenn Sie zwei oder mehr ExpressRoute-Pfade zwischen dem lokalen Netzwerk und Azure haben, können Sie den folgenden Leitfaden befolgen, um zu beeinflussen, wie Datenverkehr aus Azure VMware Solution über ExpressRoute GlobalReach zum lokalen Standort geleitet wird.
Durch asymmetrisches Routing können Konnektivitätsprobleme auftreten, wenn Azure VMware Solution den vorangestellten AS-Pfad nicht berücksichtigt und daher ECMP-Routing (Equal Cost Multi-Pathing) verwendet, um Datenverkehr über beide ExpressRoute-Leitungen an Ihre Umgebung zu senden. Dieses Verhalten kann zu Problemen mit zustandsbehafteten Firewalluntersuchungsgeräten führen, die sich hinter vorhandenen ExpressRoute-Leitungen befinden.
Voraussetzungen
Für die Verwendung von vorangestellten AS-Pfaden gelten die folgenden Voraussetzungen:
- Der wichtigste Punkt ist, dass Sie öffentliche ASN-Nummern voranstellen müssen, um zu beeinflussen, wie Azure VMware Solution den Datenverkehr zum lokalen Netzwerk zurückleitet. Wenn Sie eine private ASN voranstellen, ignoriert Azure VMware Solution den vorangestellten Pfad, und das zuvor erwähnte ECMP-Verhalten tritt auf. Selbst wenn Sie lokal eine private BGP-ASN verwenden, ist es möglich, Ihre lokalen Geräte so zu konfigurieren, dass ausgehenden Routen eine öffentliche ASN vorangestellt wird, um die Kompatibilität mit Azure VMware Solution sicherzustellen.
- Entwerfen Sie Ihren Datenverkehrspfad für private ASNs nach der öffentlichen ASN, die von Azure VMware Solution berücksichtigt werden soll. Die ExpressRoute-Leitung von Azure VMware Solution entfernt keine privaten ASNs, die im Pfad vorhanden sind, nachdem die öffentliche ASN verarbeitet wurde.
- Beide oder alle Leitungen sind mit Azure VMware Solution über ExpressRoute Global Reach verbunden.
- Die gleichen Netzwerkbereiche werden von zwei oder mehr Verbindungen angekündigt.
- Sie möchten einen vorangestellten AS-Pfad verwenden, um zu erzwingen, dass Azure VMware Solution einer Leitung Vorzug vor einer anderen gibt.
- Verwenden Sie öffentliche 2-Byte- oder 4-Byte-ASN-Nummern.
Verwaltungs-VMs und Standardrouten aus der lokalen Umgebung
Wichtig
Die Verwaltungs-VMs von Azure VMware Solution berücksichtigen für RFC1918-Ziele keine Standardroute aus der lokalen Umgebung.
Wenn Sie Datenverkehr ausschließlich über eine für Azure angekündigte Standardroute zurück an Ihre lokalen Netzwerke leiten, folgt Datenverkehr von vCenter Server- und NSX Manager-VMs für lokale Ziele mit privaten IP-Adressen nicht dieser Route.
Um vCenter Server und NSX Manager über das lokale Netzwerk zu erreichen, stellen Sie spezifischere Routen bereit, die einen Rückgabepfad zu diesen Netzwerken bieten. Kündigen Sie beispielsweise die RFC1918-Zusammenfassungen an (10.0.0.0/8, 172.16.0.0/12 und 192.168.0.0/16).
Standardroute zu Azure VMware Solution für die Überprüfung des Internetdatenverkehrs
Für bestimmte Bereitstellungen muss der gesamte ausgehende Datenverkehr von Azure VMware Solution ins Internet überprüft werden. Es ist zwar möglich, virtuelle Netzwerkgeräte (Network Virtual Appliances, NVAs) in Azure VMware Solution zu erstellen, es gibt jedoch Anwendungsfälle, wenn diese Appliances bereits in Azure vorhanden sind, die angewendet werden können, um den Internetdatenverkehr von Azure VMware Solution zu überprüfen. In diesem Fall kann eine Standardroute von der NVA in Azure injiziert werden, um den Datenverkehr von Azure VMware Solution anzuziehen und zu überprüfen, bevor er an das öffentliche Internet gesendet wird.
Das folgende Diagramm beschreibt eine grundlegende Hub-and-Spoke-Topologie, die mit einer Azure VMware Solution-Cloud und über ExpressRoute mit einem lokalen Netzwerk verbunden ist. Das Diagramm zeigt, wie die NVA in Azure die Standardroute (0.0.0.0/0) erstellt. Azure Route Server gibt die Route über ExpressRoute an Azure VMware Solution weiter.
Wichtig
Die vom virtuellen Netzwerkgerät (NVA) angekündigte Standardroute wird auch an das lokale Netzwerk weitergegeben. Sie müssen benutzerdefinierte Routen (UDRs) hinzufügen, um sicherzustellen, dass Datenverkehr von Azure VMware Solution durch die NVA geleitet wird.
Die Kommunikation zwischen Azure VMware Solution und dem lokalen Netzwerk findet in der Regel über ExpressRoute Global Reach statt, wie unter Peering lokaler Umgebungen mit Azure VMware Solution beschrieben.
Konnektivität zwischen Azure VMware Solution und einem lokalen Netzwerk
Es gibt zwei Hauptszenarien für die Konnektivität zwischen Azure VMware Solution und einem lokalen Netzwerk über einen Drittanbieter-NVA:
- Organisationen müssen den Datenverkehr zwischen Azure VMware Solution und dem lokalen Netzwerk über ein virtuelles Netzwerkgerät (NVA; in der Regel eine Firewall) senden.
- ExpressRoute Global Reach ist in einer bestimmten Region nicht verfügbar, um die ExpressRoute-Leitungen von Azure VMware Solution und das lokale Netzwerk zu verbinden.
Es gibt zwei Topologien, die Sie anwenden können, um alle Anforderungen für diese Szenarien zu erfüllen: supernet und transit spoke virtual network.
Wichtig
Die bevorzugte Option zum Verbinden von Azure VMware Solution mit lokalen Umgebungen ist eine direkte ExpressRoute Global Reach-Verbindung. Die in diesem Dokument beschriebenen Muster erhöhen die Komplexität der Umgebung beträchtlich.
Topologie mit Supernetzentwurf
Wenn beide ExpressRoute-Leitungen (zu Azure VMware Solution und zum lokalen Netzwerk) in demselben ExpressRoute-Gateway beendet werden, kann man annehmen, dass das Gateway Pakete über sie weiterleiten wird. Ein ExpressRoute-Gateway ist jedoch nicht darauf ausgelegt. Sie müssen den Datenverkehr zurück an eine NVA umleiten („hairpin“), die den Datenverkehr weiterleiten kann.
Es gibt zwei Anforderungen, um Netzwerkdatenverkehr zurück an eine NVA umleiten („hairpin“) zu können:
Die NVA sollte ein Supernetz für die Azure VMware Solution- und lokalen Präfixe ankündigen.
Sie können ein Supernet verwenden, das sowohl Azure VMware Solution als auch lokale Präfixe enthält. Oder Sie könnten individuelle Präfixe für Azure VMware Solution und lokal verwenden (immer weniger spezifisch als die tatsächlichen Präfixe, die über ExpressRoute beworben werden). Denken Sie daran, dass alle für Route Server angekündigten Supernetzpräfixe sowohl an Azure VMware Solution als auch lokal weitergegeben werden.
UDRs (User Defined Route, benutzerdefinierte Route) im Gatewaysubnetz, die genau mit den Präfixen übereinstimmen, die von Azure VMware Solution und lokal angekündigt werden, führen dazu, dass Datenverkehr vom Gatewaysubnetz zurück zum virtuellen Netzwerkgerät (Network Virtual Appliance, NVA) umgeleitet wird (Haarnadel-Datenverkehr).
Diese Topologie führt zu einem hohen Verwaltungsaufwand für große Netzwerke, die sich im Laufe der Zeit ändern. Beachten Sie die folgenden Einschränkungen:
- Bei jedem Erstellen eines Workloadsegments in Azure VMware Solution müssen möglicherweise UDRs hinzugefügt werden, um sicherzustellen, dass Datenverkehr von Azure VMware Solution durch die NVA geleitet wird.
- Wenn Ihre lokale Umgebung eine große Anzahl von Routen aufweist, die sich ändern, müssen die Border Gateway Protocol (BGP)- und UDR-Konfiguration im Supernetz möglicherweise aktualisiert werden.
- Da es ein einzelnes ExpressRoute-Gateway gibt, das Netzwerkdatenverkehr in beide Richtungen verarbeitet, kann die Leistung eingeschränkt sein.
- Es gibt einen Grenzwert für Azure Virtual Network von 400 UDRs.
Das folgende Diagramm demonstriert, wie die NVA stärker generische (weniger spezifische) Präfixe ankündigen muss, die die lokalen Netzwerke sowie die Netzwerke von Azure VMware Solution enthalten. Verwenden Sie diese Vorgehensweise mit Bedacht. Die NVA könnte möglicherweise unerwünschten Datenverkehr anziehen (da des größere Reichweiten ankündigt, z. B. das gesamte 10.0.0.0/8-Netzwerk).
Virtuelle Transit-Spoke-Netzwerktopologie
Hinweis
Wenn weniger spezifische Werbepräfixe aufgrund der zuvor beschriebenen Grenzwerte nicht möglich sind, können Sie einen alternativen Entwurf implementieren, der zwei separate virtuelle Netzwerke verwendet.
In dieser Topologie, anstatt weniger spezifische Routen weiterzugeben, damit das ExpressRoute-Gateway Datenverkehr anzieht, können zwei unterschiedliche NVAs in separaten virtuellen Netzwerken Routen untereinander austauschen. Die virtuellen Netzwerke können diese Routen über BGP und Azure Route Server an ihre jeweiligen ExpressRoute-Leitungen weitergeben. Jede NVA verfügt über vollständige Kontrolle darüber, welche Präfixe an jede ExpressRoute-Leitung weitergegeben werden.
Die folgende Abbildung demonstriert, wie eine einzelne 0.0.0.0/0-Route für Azure VMware Solution angekündigt wird. Sie zeigt ferner, wie die einzelnen Azure VMware Solution-Präfixe an das lokale Netzwerk weitergegeben werden.
Wichtig
Zwischen den NVAs ist ein Kapselungsprotokoll wie VXLAN oder IPsec erforderlich. Die Kapselung ist erforderlich, weil die NVA-Netzwerkadapter die Routen von Azure Route Server mit der NVA als nächstem Hop lernen und eine Routingschleife erzeugen würden.
Es gibt eine Alternative zur Verwendung einer Überlagerung. Wenden Sie sekundäre Netzwerkschnittstellenkarten (Network Interface Card, NIC) im virtuellen Netzwerkgerät an, die die Routen nicht von Azure Route Server lernen. Konfigurieren Sie dann UDRs, damit Azure den Datenverkehr über diese NICs an die Remote-Umgebung weiterleiten kann. Weitere Informationen finden Sie unter Netzwerktopologie und -konnektivität für Azure VMware Solution.
Für diese Topologie ist eine komplexe Ersteinrichtung erforderlich. Die Topologie funktioniert dann wie erwartet mit minimalem Verwaltungsaufwand. Die Einrichtungskomplexität umfasst Folgendes:
- Es fallen zusätzliche Kosten für ein zusätzliches virtuelles Transitnetzwerk an, das Azure Route Server, ein ExpressRoute-Gateway und ein weiteres virtuelles Netzwerkgerät umfasst. Die NVAs müssen möglicherweise auch große VM-Größen verwenden, um die Durchsatzanforderungen zu erfüllen.
- Zwischen den beiden NVAs ist IPSec- oder VxLAN-Tunnelung erforderlich, was bedeutet, dass sich die NVAs auch im Datenpfad befinden. Abhängig vom Typ der verwendeten NVA kann dies zu einer benutzerdefinierten und komplexen Konfiguration dieser NVAs führen.
Nächste Schritte
Nachdem Sie nun mehr über die Überlegungen zum Netzwerkentwurf für Azure VMware Solution erfahren haben, könnten die folgenden Artikel für Sie interessant sein: