Netzwerk mit mehreren Regionen mit Azure Route Server

  • Artikel

Anwendungen mit anspruchsvollen Hochverfügbarkeits- oder Notfallwiederherstellungsanforderungen müssen häufig in mehr als einer Azure-Region bereitgestellt werden. In solchen Fällen müssen virtuelle Spoke-Netzwerke (VNets) in verschiedenen Regionen miteinander kommunizieren können. Eine Möglichkeit, diese Kommunikation zu ermöglichen, besteht darin, ein Peering zwischen allen erforderlichen Spoke-VNets einzurichten. Dieser Ansatz würde jedoch alle zentralen virtuellen Netzwerkgeräte (Network Virtual Appliances, NVAs) wie Firewalls in den Hubs umgehen. Eine Alternative besteht darin, benutzerdefinierte Routen (User-Defined Routes, UDRs) in den Subnetzen zu verwenden, in denen Hub-NVAs bereitgestellt werden, aber die Verwaltung von UDRs kann herausfordernd sein. Azure Route Server bietet eine dynamische Alternative, die sich automatisch an Topologieänderungen anpasst, ohne dass ein manueller Eingriff erforderlich ist.

Topologie

Das folgende Diagramm zeigt eine Architektur mit zwei Regionen und einer Hub-Spoke-Topologie in jeder Region. Die Hub-VNets sind über globales VNet-Peering miteinander verknüpft:

Diagram showing multi-region design with Azure Route Server.

Das NVA in jeder Region lernt die Präfixe der lokalen Hub- und Spoke-VNets über den Azure Route Server und teilt sie mittels BGP mit dem NVA in der anderen Region. Um Routingschleifen zu vermeiden, ist es wichtig, diese Kommunikation zwischen den NVAs mithilfe einer Kapselungstechnologie wie IPsec oder Virtual eXtensible LAN (VXLAN) herzustellen.

Damit Azure Route Server die Präfixe der Spoke-VNets für die lokalen NVAs ankündigen und die gelernten Routen wieder in die Spoke-VNets einschleusen kann, ist es wichtig, die Einstellung Gateway oder Route Server des virtuellen Remotenetzwerks verwenden für das Peering zwischen den Spoke-VNets und dem Hub-VNet zu verwenden.

Die NVAs kündigen die aus der Remoteregion gelernten Routen an ihren lokalen Route Server an, der diese Routen dann in den lokalen Spoke-VNets konfiguriert und entsprechend Datenverkehr anzieht. In Fällen, in denen sich mehrere NVAs in der gleichen Region befinden (der Route Server unterstützt bis zu acht BGP-Peers), kann das Voranstellen von AS PATH verwendet werden, um eine der NVAs zu bevorzugen, um effektiv eine Aktiv/Standby-NVA-Topologie zu etablieren.

Wichtig

Um sicherzustellen, dass der lokale Route Server die vom NVA angekündigten Routen aus der Remoteregion erlernen kann, muss das NVA die autonome Systemnummer (ASN) 65515 aus dem AS PATH der Routen entfernen. Diese Technik wird auf bestimmten BGP-Plattformen manchmal als „AS-Überschreibung“ oder „AS PATH-Neugenerierung“ bezeichnet. Andernfalls verhindert der BGP-Schleifenverhinderungsmechanismus, dass der lokale Route Server diese Routen lernt, da er das Lernen von Routen verbietet, die bereits die lokale ASN enthalten.

ExpressRoute

Dieser Entwurf für mehrere Regionen kann mit ExpressRoute- oder VPN-Gateways kombiniert werden. Das folgende Diagramm zeigt eine Topologie mit einem ExpressRoute-Gateway, das mit einem lokalen Netzwerk in einer der Azure-Regionen verbunden ist. In diesem Fall hilft ein Überlagerungsnetzwerk über die ExpressRoute-Leitung bei der Vereinfachung des Netzwerks, sodass lokale Präfixe nur gemäß Ankündigung der NVA in Azure angezeigt werden (und nicht vom ExpressRoute-Gateway).

Diagram showing multi-region design with Route Server and ExpressRoute.

Entwurf ohne Überlagerungen

Die regionsübergreifenden Tunnel zwischen den NVAs sind erforderlich, da andernfalls eine Routingschleife entsteht. Betrachten Sie beispielsweise die NVA in Region 1:

  • Die NVA in der Region 1 lernt die Präfixe aus der Region 2 und kündigt sie dem Route Server in der Region 1 an.
  • Der Route Server in der Region 1 fügt Routen für diese Präfixe in alle Subnetze in der Region 1 ein und verwendet die NVA in der Region 1 als den nächsten Hop.
  • Für Datenverkehr von Region 1 zu Region 2 gilt: Wenn die NVA in Region 1 Datenverkehr an die andere NVA sendet, erbt das eigene Subnetz auch die vom Routenserver programmierten Routen, die auf die NVA selbst verweisen. Das Paket wird somit an die NVA zurückgegeben, und eine Routingschleife entsteht.

Wenn UDRs eine Option sind, könnten Sie die BGP-Routenweitergabe in den Subnetzen der NVAs deaktivieren und anstelle einer Überlagerung statische UDRs konfigurieren, sodass Azure den Datenverkehr an die Remote-Spoke-VNets weiterleiten kann.

Zugehöriger Inhalt