Entwurf für Hochverfügbarkeit mit Azure ExpressRoute
Azure ExpressRoute wurde für Hochverfügbarkeit entwickelt und stellt Konnektivität für private Netzwerke mit Microsoft-Ressourcen auf Netzbetreiberniveau bereit. Das heißt, es gibt keine einzelne Fehlerquelle im Microsoft-Netzwerk. Um die Verfügbarkeit zu maximieren, sollten auch sowohl die Kunden- als auch die Dienstanbietersegmente Ihrer Azure ExpressRoute-Leitung auf Hochverfügbarkeit ausgelegt sein. In diesem Artikel werden Überlegungen zur Netzwerkarchitektur für den Aufbau einer robusten Verbindung mit einer Azure ExpressRoute-Leitung angestellt und Optimierungsmöglichkeiten behandelt, mit denen Sie die Hochverfügbarkeit Ihrer Azure ExpressRoute-Leitung verbessern können.
Hinweis
Die in diesem Artikel beschriebenen Konzepte gelten gleichermaßen, ob nun eine Azure ExpressRoute-Leitung innerhalb oder außerhalb eines Virtual WAN erstellt wird.
Überlegungen zur Architektur
Die folgende Abbildung veranschaulicht die empfohlene Methode zum Herstellen einer Verbindung mit einer Azure ExpressRoute-Leitung zum Maximieren der Verfügbarkeit.
Für Hochverfügbarkeit ist es wichtig, die Redundanz im gesamten End-to-End-Netzwerk beizubehalten. Das heißt, dass die Redundanz innerhalb Ihres lokalen Netzwerks aufrechterhalten werden muss und die Redundanz innerhalb Ihres Dienstanbieternetzwerks nicht gefährdet werden darf. Dies bedeutet zumindest, dass einzelne Netzwerkfehlerquellen vermieden werden müssen. Eine redundante Stromversorgung und Kühlung der Netzwerkgeräte verbessert die Hochverfügbarkeit weiter.
Überlegungen zum Entwurf der physikalischen Schicht auf der ersten Meile
Wenn Sie sowohl die primäre als auch die sekundäre Verbindung einer Azure ExpressRoute-Leitung auf demselben CPE (Customer Premises Equipment) beenden, gefährden Sie die Hochverfügbarkeit in Ihrem lokalen Netzwerk. Wenn außerdem beide Verbindungen über denselben Port eines CPE konfiguriert werden, wird der Partner gezwungen, die Hochverfügbarkeit in seinem Netzwerksegment zu gefährden. Dies kann auftreten, indem die beiden Verbindungen unter verschiedenen Unterschnittstellen beendet oder die beiden Verbindungen innerhalb des Partnernetzwerks zusammengeführt werden, wie unten dargestellt.
Das Beenden der primären und sekundären Verbindung einer Azure ExpressRoute-Leitung an verschiedenen geografischen Standorten kann die Netzwerkleistung beeinträchtigen. Wenn der Datenverkehr zum Lastenausgleich aktiv über Verbindungen verteilt wird, die an verschiedenen Standorten enden, können erhebliche Unterschiede in der Netzwerklatenz zwischen den beiden Pfaden zu einer suboptimalen Leistung führen.
Weitere Informationen zu georedundanten Entwurfsüberlegungen finden Sie unter Entwurf für die Notfallwiederherstellung mit Azure ExpressRoute.
Aktiv/Aktiv-Verbindungen
Das Microsoft-Netzwerk betreibt die primären und sekundären Verbindungen der ExpressRoute-Verbindungen im Aktiv/Aktiv-Modus. Sie können jedoch die redundanten Verbindungen zwingen, durch Ihre Routenankündigungen den Aktiv-Passiv-Modus zu nutzen. Die Ankündigung spezifischerer Routen und das Voranstellen von BGP-AS-Pfaden sind gebräuchliche Techniken, um einen Pfad dem anderen vorzuziehen.
Um die Hochverfügbarkeit zu verbessern, wird empfohlen, beide Verbindungen im Aktiv-Aktiv-Modus zu betreiben. Dadurch kann das Microsoft-Netzwerk den Datenverkehr auf einer Pro-Flow-Basis per Lastenausgleich über die Verbindungen verteilen.
Beim Betreiben von Verbindungen im Aktiv-Passiv-Modus besteht die Gefahr, dass beide Verbindungen fehlschlagen, wenn der aktive Pfad fehlschlägt. Häufige Ursachen für einen Ausfall sind unter anderem mangelnde aktive Verwaltung der passiven Verbindung und passive Verbindungsankündigung veralteter Routen.
Alternativ führt das Betreiben von Verbindungen im Aktiv-Aktiv-Modus dazu, dass nur etwa die Hälfte der Datenflüsse fehlschlägt und umgeleitet wird, wodurch die Mean Time To Recover (MTTR, mittlere Wiederherstellungszeit) deutlich verbessert wird.
Hinweis
Während der Wartung oder bei ungeplanten Ereignissen, die sich auf eine Verbindung auswirken, nutzt Microsoft die AS-Pfadpräfigierung, um Datenverkehr zum Ausgleich zur fehlerfreien Verbindung umzuleiten. Stellen Sie sicher, dass der Datenverkehr zum fehlerfreien Pfad umgeleitet werden kann, wenn Microsoft die Pfadpräfigierung konfiguriert hat, und dass erforderliche Routenankündigungen entsprechend festgelegt sind, um Dienstunterbrechungen zu vermeiden.
NAT für Microsoft-Peering
Microsoft-Peering dient der Kommunikation zwischen öffentlichen Endpunkten. In der Regel sind lokale private Endpunkte netzwerkadressenübersetzt (Network Address Translated, NATed) mit öffentlichen IP-Adressen für das Kunden- oder Partnernetzwerk, bevor sie über Microsoft-Peering kommunizieren. Die Verwendung einer primären und sekundären Verbindung in einer Aktiv-Aktiv-Konfiguration wirkt sich darauf aus, wie schnell Sie sich von einem Ausfall einer der Verbindungen erholen. Zwei verschiedene NAT-Optionen werden unten dargestellt:
Option 1:
NAT wird angewendet, nachdem der Datenverkehr zwischen der primären und sekundären Verbindung aufgeteilt wurde. Es werden unabhängige NAT-Pools für die primären und sekundären Geräte verwendet, um die zustandsbehafteten NAT-Anforderungen zu erfüllen. Der zurückgegebene Datenverkehr trifft auf demselben Edgegerät ein, über das der Datenfluss ausgegangen ist.
Wenn eine Azure ExpressRoute-Verbindung fehlschlägt, ist der entsprechende NAT-Pool nicht mehr erreichbar, wodurch alle Netzwerkdatenflüsse unterbrochen werden. Diese Datenströme müssen von TCP oder der Anwendungsschicht nach dem Fenstertimeout wiederhergestellt werden. Während des Ausfalls kann Azure lokale Server nicht mithilfe der entsprechenden NAT erreichen, bis die Verbindung wiederhergestellt wird.
Option 2:
Es wird ein allgemeiner NAT-Pool verwendet, bevor der Datenverkehr zwischen der primären und sekundären Verbindung aufgeteilt wird. Dadurch wird keine einzelne Fehlerquelle verursacht, sodass eine hohe Verfügbarkeit gewährleistet ist.
Der NAT-Pool bleibt erreichbar, auch wenn die primäre oder sekundäre Verbindung fehlschlägt, sodass die Vermittlungsschicht Pakete umleiten und schneller wiederherstellen kann.
Hinweis
- Bei Verwendung von NAT-Option 1 (unabhängige NAT-Pools für primäre und sekundäre Verbindung) und Zuordnung eines Ports einer IP-Adresse von einem NAT-Pool zu einem lokalen Server ist der Server über die Azure ExpressRoute-Leitung nicht erreichbar, wenn die entsprechende Verbindung ausfällt.
- Das Beenden von Azure ExpressRoute-BGP-Verbindungen auf zustandsbehafteten Geräten kann bei geplanten oder ungeplanten Wartungen durch Microsoft oder Ihren Azure ExpressRoute-Anbieter zu Problemen beim Failover führen. Testen Sie Ihre Einrichtung, um das ordnungsgemäße Failover sicherzustellen, und beenden Sie nach Möglichkeit BGP-Sitzungen auf zustandslosen Geräten.
Optimieren von Funktionen für privates Peering
In diesem Abschnitt werden optionale Features erläutert, die zur Verbesserung der Hochverfügbarkeit Ihrer Azure ExpressRoute-Leitung beitragen, abhängig von Ihrer Azure-Bereitstellung und der Empfindlichkeit hinsichtlich der MTTR. Insbesondere wird die zonenfähige Bereitstellung von virtuellen Azure ExpressRoute-Netzwerkgateways und die bidirektionale Weiterleitungserkennung (Bidirectional Forwarding Detection, BFD) behandelt.
Verfügbarkeitszonenfähige virtuelle Azure ExpressRoute-Netzwerkgateways
Eine Verfügbarkeitszone in einer Azure-Region vereint eine Fehlerdomäne und eine Upgradedomäne. Um die höchste Ausfallsicherheit und Verfügbarkeit zu erreichen, sollten Sie ein zonenredundantes virtuelles Azure ExpressRoute-Netzwerkgateway konfigurieren. Weitere Informationen finden Sie unter Informationen zu zonenredundanten Gateways für virtuelle Netzwerke in Azure-Verfügbarkeitszonen. Informationen zum Konfigurieren eines zonenredundanten Gateways für das virtuelle Netzwerk finden Sie unter Erstellen eines zonenredundanten Gateways für das virtuelle Netzwerk in Azure-Verfügbarkeitszonen.
Verbessern des Zeitpunkts der Fehlererkennung
Azure ExpressRoute unterstützt BFD über privates Peering und reduziert damit die Erkennungszeit von Ausfällen über das Layer-2-Netzwerk zwischen Microsoft Enterprise Edge (MSEEs) und deren BGP-Nachbarn auf der lokalen Seite von etwa 3 Minuten (Standard) auf weniger als eine Sekunde. Eine schnelle Fehlererkennung beschleunigt die Wiederherstellung. Weitere Informationen finden Sie unter Konfigurieren von BFD über Azure ExpressRoute.
Nächste Schritte
In diesem Artikel wurde der Entwurf für Hochverfügbarkeit einer Azure ExpressRoute-Leitung erläutert. Ein Peeringpunkt einer Azure ExpressRoute-Leitung ist an einen geografischen Standort gebunden und kann von katastrophenbedingten Ausfällen betroffen sein, die sich auf den gesamten Standort auswirken.
Überlegungen zum Entwurf einer georedundanten Netzwerkverbindung zum Microsoft-Backbone, die katastrophenbedingten Ausfällen standhalten kann, die eine ganze Region betreffen, finden Sie unter Entwurf für die Notfallwiederherstellung mit privatem Azure ExpressRoute-Peering.