Share via

Netzwerküberlegungen für Azure VMware Solution-Bereitstellungen mit zwei Regionen

  • Artikel

In diesem Artikel wird beschrieben, wie Sie die Netzwerkkonnektivität konfigurieren, wenn private Azure VMware Solution-Clouds in zwei Azure-Regionen zu Zwecken der Ausfallsicherheit bereitgestellt werden. Bei teilweisen oder vollständigen regionalen Ausfällen ermöglicht die Netzwerktopologie in diesem Artikel den überlebenden Komponenten (private Clouds, native Azure-Ressourcen und lokale Sites), die Konnektivität untereinander und mit dem Internet aufrechtzuerhalten.

Szenario mit zwei Regionen

Dieser Artikel konzentriert sich auf ein typisches Szenario mit zwei Regionen, das in der folgenden Abbildung 1 dargestellt ist:

  • In jeder Region ist ein Azure Hub-and-Spoke-Netzwerk vorhanden.
  • Eine ausfallsichere Konfiguration für ExpressRoute (zwei Leitungen an zwei verschiedenen Peering-Standorten, wobei jede Leitung mit virtuellen Hub-Netzwerken in beiden Regionen verbunden ist) wurde eingerichtet. Die Anleitung in den folgenden Abschnitten bleibt unverändert, falls die Fallback-VPN-Konnektivität konfiguriert ist.
  • Eine private Azure VMware Solution-Cloud wurde in jeder Region bereitgestellt.

Diagramm der Abbildung 1, die das in diesem Artikel vorgestellte Szenario mit zwei Regionen zeigt.

Hinweis

Im Referenzszenario der Abbildung 1 sind die beiden virtuellen Netzwerke des regionalen Hubs über globales VNET-Peering verbunden. Obwohl dies nicht unbedingt erforderlich ist, da der Datenverkehr zwischen den virtuellen Azure-Netzwerken in den beiden Regionen über ExpressRoute-Verbindungen geleitet werden könnte, wird diese Konfiguration dringend empfohlen. VNET-Peering minimiert die Wartezeit und maximiert den Durchsatz, da es nicht mehr erforderlich ist, den Datenverkehr über die ExpressRoute-Meet-Me-Edgerouter zu verarbeiten.

Kommunikationsmuster mit zwei Regionen

In den nächsten Abschnitten wird die Azure VMware Solution-Netzwerkkonfiguration beschrieben, die erforderlich ist, um im Referenzszenario mit zwei Regionen die folgenden Kommunikationsmuster zu aktivieren:

Regionsübergreifende Azure VMware Solution-Konnektivität

Wenn mehrere private Azure VMware Solution-Clouds vorhanden sind, ist die Layer-3-Konnektivität zwischen ihnen häufig eine Voraussetzung für Aufgaben wie die Unterstützung der Datenreplikation.

Azure VMware Solution unterstützt nativ die direkte Konnektivität zwischen zwei privaten Clouds, die in verschiedenen Azure-Regionen bereitgestellt sind. Private Clouds stellen eine Verbindung mit dem Azure-Netzwerk in ihrer eigenen Region über ExpressRoute-Leitungen her, die von der Plattform verwaltet und an dedizierten ExpressRoute-Meet-Me-Standorten beendet werden. In diesem gesamten Artikel werden diese Leitungen als verwaltete Azure VMware Solution-Leitungen bezeichnet. Verwaltete Azure VMware Solution-Leitungen sollten nicht mit den normalen Leitungen verwechselt werden, die Kunden bereitstellen, um ihre lokalen Sites mit Azure zu verbinden. Die normalen Leitungen, die Kunden bereitstellen, sind kundenseitig verwaltete Leitungen (siehe Abbildung 2).

Die direkte Konnektivität zwischen privaten Clouds basiert auf ExpressRoute Global Reach-Verbindungen zwischen verwalteten Azure VMware Solution-Leitungen, wie die grüne Linie im folgenden Diagramm zeigt. Weitere Informationen finden Sie unter Tutorial: Peering lokaler Umgebungen mit Azure VMware Solution. Der Artikel beschreibt das Verfahren zum Verbinden einer verwalteten Azure VMware Solution-Leitung mit einer kundenseitig verwalteten Leitung. Das gleiche Verfahren gilt für das Verbinden von zwei verwalteten Azure VMware Solution-Leitungen.

Diagramm der Abbildung 2, das private Clouds in verschiedenen Regionen zeigt, die über eine Global Reach-Verbindung zwischen verwalteten ExpressRoute-Leitungen verbunden sind.

Hybridkonnektivität

Die empfohlene Option zum Verbinden von privaten Azure VMware Solution-Clouds mit lokalen Sites ist ExpressRoute Global Reach. Global Reach-Verbindungen können zwischen kundenseitig verwalteten ExpressRoute-Leitungen und verwalteten Azure VMware Solution ExpressRoute-Leitungen hergestellt werden. Global Reach-Verbindungen sind nicht transitiv, daher ist ein vollständiges Gittermodell (jede verwaltete Azure VMware Solution-Leitung, die mit jeder vom Kunden verwalteten Verbindung verbunden ist) für die Ausfallsicherheit erforderlich, wie in der folgenden Abbildung 3 (dargestellt durch orange Linien) gezeigt.

Diagramm von Abbildung 3, das Global Reach-Verbindungen zeigt, die vom Kunden verwaltete ExpressRoute-Leitungen und VMware Solution ExpressRoute-Leitungen verbinden.

Azure VNet-Konnektivität

Azure Virtual Network kann über Verbindungen zwischen ExpressRoute-Gateways und verwalteten Azure VMware Solution-Leitungen mit privaten Azure VMware Solution-Clouds verbunden werden. Diese Verbindung entspricht genau der Art und Weise, wie Azure Virtual Network über kundenseitig verwaltete ExpressRoute-Leitungen mit lokalen Sites verbunden werden kann. Konfigurationsanweisungen finden Sie unter Manuelles Herstellen einer Verbindung mit der privaten Cloud.

In Szenarien mit zwei Regionen wird ein vollständiges Gittermodell für die ExpressRoute-Verbindungen zwischen den beiden regionalen Virtual Network-Hubs und privaten Clouds empfohlen, wie in Abbildung 4 (dargestellt durch gelbe Linien) gezeigt.

Diagramm der Abbildung 4, das zeigt, dass die nativen Azure-Ressourcen in jeder Region über eine direkte L3-Konnektivität zu den privaten Azure VMware Solution-Clouds verfügen.

Internetkonnektivität

Bei der Bereitstellung von privaten Azure VMware Solution-Clouds in mehreren Regionen empfehlen wir native Optionen für die Internetkonnektivität (verwaltete SNAT (Source Network Address Translation) oder öffentliche IP-Adressen bis hin zum NSX-T). Alle Optionen können zur Bereitstellungszeit über das Azure-Portal (oder über PowerShell, CLI oder ARM/Bicep-Vorlagen) konfiguriert werden, wie in der folgenden Abbildung 5 gezeigt.

Diagramm der Abbildung 5, das die nativen Azure VMware Solution-Optionen für die Internetkonnektivität im Azure-Portal zeigt.

Beide in Abbildung 5 hervorgehobenen Optionen bieten jeder privaten Cloud ein direktes Internet-Breakout in ihrer eigenen Region. Die folgenden Überlegungen sollten die Entscheidung darüber beeinflussen, welche Option für die native Internetkonnektivität verwendet werden sollte:

  • Verwaltetes SNAT sollte in Szenarien mit einfachen und nur ausgehenden Anforderungen verwendet werden (geringe Mengen ausgehender Verbindungen und kein Bedarf an einer granularen Kontrolle über den SNAT-Pool).
  • Öffentliche IP-Adressen bis hin zum NSX-T-Edge sollten in Szenarien mit großen Mengen ausgehender Verbindungen bevorzugt werden, oder wenn Sie eine granulare Kontrolle über NAT-IP-Adressen benötigen. Beispiel: Welche Azure VMware Solution-VMs verwenden SNAT hinter welchen IP-Adressen. Öffentliche IP-Adressen bis hin zum NSX-T-Edge unterstützen auch eingehende Konnektivität über DNAT. Eingehende Internetkonnektivität wird in diesem Artikel nicht behandelt.

Das Ändern der Konfiguration der Internetkonnektivität einer privaten Cloud nach der ersten Bereitstellung ist möglich. Die private Cloud verliert jedoch die Konnektivität mit dem Internet, Azure Virtual Network und lokalen Sites, während die Konfiguration aktualisiert wird. Wenn eine der Optionen für die native Internetkonnektivität in der vorstehenden Abbildung 5 verwendet wird, ist in Szenarien mit zwei Regionen keine zusätzliche Konfiguration erforderlich (die Topologie bleibt identisch mit der in Abbildung 4 dargestellten). Weitere Informationen zur Internetkonnektivität für Azure VMware Solution finden Sie unter Entwurfsüberlegungen zur Internetkonnektivität.

Azure-natives Internet-Breakout

Wenn in Azure Virtual Network vor der Azure VMware Solution-Einführung ein sicherer Internet-Edge erstellt wurde, kann es erforderlich sein, ihn für den Internetzugriff für private Azure VMware Solution-Clouds zu verwenden. Die Verwendung eines sicheren Internet-Edge auf diese Weise ist für die zentrale Verwaltung von Netzwerksicherheitsrichtlinien, die Kostenoptimierung und vieles mehr erforderlich. Internetsicherheitsedges in Azure Virtual Network können mithilfe von Azure Firewall oder einer Drittanbieter-Firewall und virtuellen Proxynetzwerkgeräten (Network Virtual Appliances, NVAs) implementiert werden, die auf der Azure Marketplace verfügbar sind.

Internetgebundener Datenverkehr, der von Azure VMware Solution-VMs ausgegeben wird, kann an ein Azure-VNet gelockt werden, indem eine Standardroute erstellt und über das Border Gateway Protocol (BGP) an die verwaltete ExpressRoute-Leitung der privaten Cloud gesendet wird. Diese Option der Internetkonnektivität kann zur Bereitstellungszeit über das Azure-Portal (oder über PowerShell, CLI oder ARM/Bicep-Vorlagen) konfiguriert werden, wie in der folgenden Abbildung 6 dargestellt. Weitere Informationen finden Sie unter Deaktivieren des Internetzugriffs oder Aktivieren einer Standardroute.

Diagramm der Abbildung 6, welche die Azure VMware Solution-Konfiguration zeigt, um die Internetkonnektivität über Internet-Edges in Azure Virtual Network zu ermöglichen.

Die Internet-Edge-NVAs können die Standardroute erstellen, wenn sie BGP unterstützen. Andernfalls müssen Sie andere BGP-fähige NVAs bereitstellen. Weitere Informationen zum Implementieren ausgehender Internetkonnektivität für Azure VMware Solution in einer einzelnen Region finden Sie unter Implementieren der Internetkonnektivität für Azure VMware Solution mit Azure-NVAs. In dem in diesem Artikel beschriebenen Szenario mit zwei Regionen muss dieselbe Konfiguration auf beide Regionen angewendet werden.

Der wichtigste Überlegung in Szenarien mit zwei Regionen ist, dass die Standardroute, die aus jeder Region stammt, über ExpressRoute nur an die private Azure VMware Solution-Cloud in derselben Region weitergegeben werden sollte. Diese Weitergabe ermöglicht Azure VMware Solution-Workloads den Zugriff auf das Internet über einen lokalen (regionsinternen) Breakout. Wenn Sie jedoch die in Abbildung 4 gezeigte Topologie verwenden, empfängt jede private Azure VMware Solution-Cloud auch eine Standardroute mit gleichen Kosten aus der Remoteregion über die regionsübergreifenden ExpressRoute-Verbindungen. Die roten gestrichelten Linien stellen diese unerwünschte regionsübergreifende Standardroutenweitergabe in Abbildung 7 dar.

Diagramm der Abbildung 7, das zeigt, dass die regionsübergreifenden Verbindungen zwischen ExpressRoute-Gateways und von VMware Solution verwalteten ExpressRoute-Leitungen entfernt werden müssen.

Durch das Entfernen der regionsübergreifenden Azure VMware Solution ExpressRoute-Verbindungen wird das Ziel erreicht, in jede private Cloud eine Standardroute einzufügen, um internetgebundene Verbindungen an den Azure-Internet-Edge in der lokalen Region weiterzuleiten.

Beachten Sie, dass beim Entfernen der regionsübergreifenden ExpressRoute-Verbindungen (rote gestrichelte Linien in Abbildung 7) weiterhin regionsübergreifende Weitergabe der Standardroute über Global Reach erfolgt. Routen, die über Global Reach weitergegeben werden, weisen jedoch einen längeren AS-Pfad auf als die lokal erstellten Routen und werden vom BGP-Routenauswahlprozess verworfen.

Die regionsübergreifende Weitergabe über Global Reach einer weniger bevorzugten Standardroute bietet Resilienz gegen Fehler des lokalen Internet-Edges. Wenn der Internet-Edge einer Region offline geht, wird die Standardroute nicht mehr erstellt. In diesem Fall wird die weniger bevorzugte Standardroute, die von der Remoteregion gelernt wurde, in der privaten Azure VMware Solution-Cloud installiert, sodass internetgebundener Datenverkehr über den Breakout der Remoteregion weitergeleitet wird.

Die empfohlene Topologie für Bereitstellungen mit zwei Regionen mit Internet-Breakouts in Azure VNets ist in der folgenden Abbildung 8 dargestellt.

Diagramm der Abbildung 8, das die empfohlene Topologie für Bereitstellungen in zwei Regionen mit ausgehendem Internetzugriff über Internet-Edges zeigt.

Wenn Sie Standardrouten aus Azure erstellen, muss besonders darauf geachtet werden, dass eine Weitergabe an lokale Sites vermieden wird, es sei denn, es besteht die Anforderung, den Internetzugriff auf lokale Sites über einen Internet-Edge in Azure bereitzustellen. Die vom Kunden betriebenen Geräte, welche die vom Kunden verwalteten ExpressRoute-Leitungen beenden, müssen so konfiguriert werden, dass die von Azure empfangenen Standardrouten gefiltert werden, wie in Abbildung 9 dargestellt. Diese Konfiguration ist erforderlich, um eine Unterbrechung des Internetzugriffs für die lokalen Sites zu vermeiden.

Diagramm der Abbildung 9, das zeigt, dass die BGP-Lautsprecher, welche die vom Kunden verwalteten ExpressRoute-Leitungen beenden, die Standardrouten der Azure NVAs filtern.

Nächste Schritte