Teilen über

Anycastrouting mit Azure Route Server

  • Artikel

Sie können Ihre Anwendung über Verfügbarkeitszonen hinweg in einer einzigen Azure-Region bereitstellen, um eine höhere Verfügbarkeit zu erreichen. Manchmal müssen Sie Ihre Anwendungen jedoch in mehreren Regionen bereitstellen, um entweder eine höhere Resilienz, eine bessere Leistung für Benutzer*innen auf der ganzen Welt oder eine bessere Geschäftskontinuität zu erreichen. Es gibt verschiedene Ansätze, wie Benutzer an einen der Speicherorte geleitet werden können, an denen eine Anwendung für mehreren Regionen bereitgestellt ist: DNS-basierte Ansätze wie Azure Traffic Manager, routingbasierte Dienste wie Azure Front Door oder der regionsübergreifende Azure Load Balancer.

Die bisherigen Azure-Dienste werden empfohlen, um Benutzer mithilfe der öffentlichen IP-Adressierung über das öffentliche Internet zum besten Anwendungsspeicherort zu bringen, unterstützen jedoch keine privaten Netzwerke und IP-Adressen. In diesem Artikel wird die Verwendung eines routenbasierten Ansatzes (IP-Anycast) zur Bereitstellung multiregionaler Anwendungen mit privaten Netzwerken.

IP-Anycast besteht im Wesentlichen aus der Ankündigung genau derselben IP-Adresse von mehreren Speicherorten aus, sodass Pakete von den Anwendungsbenutzern an die nächstgelegene Region (im Bezug auf das Routing) weitergeleitet werden. Die Bereitstellung von Erreichbarkeit in mehreren Regionen über Anycast bietet einige Vorteile gegenüber DNS-basierten Ansätzen, z. B. dass Clients sich nicht darauf verlassen müssen, dass ihre DNS-Antworten nicht zwischengespeichert werden und der DNS-Entwurf für die Anwendung nicht geändert werden muss.

Topologie

Im Entwurf für dieses Szenario wird dieselbe IP-Adresse von virtuellen Netzwerken in verschiedenen Azure-Regionen angekündigt, wobei virtuelle Netzwerkgeräte (Network Virtual Appliances, NVAs) die IP-Adresse der Anwendung über Azure Route Server ankündigen. Das folgende Diagramm zeigt zwei einfache Hub-and-Spoke-Topologien, die sich jeweils in einer anderen Azure-Region befinden. Ein NVA in jeder Region kündigt die gleiche Route (a.b.c.d/32 in diesem Beispiel) für seinen lokalen Azure Route Server an (das Routenpräfix darf sich nicht mit Azure- und lokalen Netzwerken überschneiden). Die Routen werden über ExpressRoute weiter an das lokale Netzwerk geleitet. Wenn Anwendungsbenutzer lokal auf die Anwendung zugreifen möchten, löst die DNS-Infrastruktur (in diesem Dokument nicht behandelt) den DNS-Namen der Anwendung in die Anycast-IP-Adresse (a.b.c.d) auf, welche die lokalen Netzwerkgeräte an eine der beiden Regionen weiterleiten.

Diagram shows an example of using IP anycast with Azure Route Server.

Die Entscheidung, welche der verfügbaren Regionen ausgewählt wird, basiert vollständig auf Routingattributen. Wenn die Routen aus beiden Regionen identisch sind, verwendet das lokale Netzwerk in der Regel ECMP (Equal-Cost Multi-Path)-Routing, um jeden Anwendungsfluss an jede Region zu senden. Es ist auch möglich, die von jedem NVA in Azure erzeugten Ankündigungen zu ändern, um eine der Regionen zu bevorzugen. Beispielsweise verwenden Sie „BGP AS Path“ vorangestellt, um einen deterministischen Pfad von der lokalen Umgebung zur Azure-Workload einzurichten.

Wichtig

Die NVAs, die die Routen ankündigen, sollten einen Mechanismus zur Integritätsprüfung enthalten, um die Ankündigung der Route zu beenden, wenn die Anwendung in ihren jeweiligen Regionen nicht verfügbar ist, um Blackhole-Datenverkehr zu vermeiden.

Rückgabe-Datenverkehr

Wenn der Anwendungsdatenverkehr vom lokalen Client zu einer der NVAs in Azure gelangt, führt das NVA entweder einen Reverseproxy für die Verbindung oder die Ziel-Netzwerkadressenübersetzung (Destination Network Address Translation, DNAT) aus. Anschließend werden die Pakete an die tatsächliche Anwendung gesendet, die sich in der Regel in einem virtuellen Spoke-Netzwerk befindet, das mit dem virtuellen Hubnetzwerk verbunden ist, in dem das NVA bereitgestellt wird. Rückdatenverkehr von der Anwendung wird über das NVA geleitet. Dies würde auf natürliche Weise geschehen, wenn das NVA als Reverseproxy für die Verbindung fungiert (oder Quell-NAT zusätzlich zur Ziel-NAT durchführt).

Andernfalls stammt der bei der Anwendung eingehende Datenverkehr weiterhin von der IP-Adresse des ursprünglichen lokalen Clients. In diesem Fall können Pakete mit benutzerdefinierten Routen (User-Defined Routes, UDRs) zurück an das NVA geleitet werden. Besondere Vorsicht ist erforderlich, wenn in jeder Region mehrere NVA-Instanzen vorhanden sind, da der Datenverkehr asymmetrisch sein könnte (der eingehende und ausgehende Datenverkehr durchlaufen verschiedene NVA-Instanzen). Asymmetrischer Datenverkehr ist in der Regel kein Problem, wenn NVAs zustandslos sind, führt jedoch zu Fehlern, wenn die NVAs Verbindungszustände wie z. B. Firewalls nachverfolgen.

Zugehöriger Inhalt