Entwurf für Hochverfügbarkeit mit ExpressRoute

  • Artikel

ExpressRoute wurde für Hochverfügbarkeit entwickelt, um Konnektivität für private Netzwerke mit Microsoft-Ressourcen auf Netzbetreiberniveau bereitzustellen. Das heißt, gibt es keine einzelne Fehlerquelle im ExpressRoute-Pfad im Microsoft-Netzwerk. Um die Verfügbarkeit zu maximieren, sollten auch das Kunden- und das Dienstanbietersegment Ihrer ExpressRoute-Verbindung auf Hochverfügbarkeit ausgelegt sein. In diesem Artikel werden zunächst Überlegungen zur Netzwerkarchitektur für den Aufbau einer robusten Netzwerkverbindung mit einer ExpressRoute-Verbindung angestellt, dann werden die Optimierungsmöglichkeiten untersucht, die Ihnen helfen, die Hochverfügbarkeit Ihrer ExpressRoute-Verbindung zu verbessern.

Hinweis

Die in diesem Artikel beschriebenen Konzepte gelten gleichermaßen, wenn eine ExpressRoute-Leitung innerhalb oder außerhalb eine Virtual WAN erstellt wird.

Überlegungen zur Architektur

Die folgende Abbildung veranschaulicht die empfohlene Methode zum Herstellen einer Verbindung mit einer ExpressRoute-Verbindung zum Maximieren der Verfügbarkeit einer ExpressRoute-Verbindung.

1

Für Hochverfügbarkeit ist es wichtig, die Redundanz der ExpressRoute-Verbindung im gesamten End-to-End-Netzwerk beizubehalten. Das heißt, Sie müssen die Redundanz in Ihrem lokalen Netzwerk beibehalten und dürfen die Redundanz in Ihrem Dienstanbieternetzwerk nicht gefährden. Die Aufrechterhaltung der Redundanz bedeutet mindestens die Vermeidung einer einzelnen Fehlerquelle im Netzwerk. 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ären als auch die sekundären Verbindungen einer ExpressRoute-Verbindung auf demselben CPE (Customer Premises Equipment) beenden, gefährden Sie die Hochverfügbarkeit in Ihrem lokalen Netzwerk. Wenn Sie außerdem sowohl die primäre als auch die sekundäre Verbindung über denselben Port eines CPE konfigurieren, zwingen Sie den Partner, die Hochverfügbarkeit in seinem Netzwerksegment ebenfalls zu gefährden. Dieses Ereignis kann auftreten, indem entweder die beiden Verbindungen unter verschiedenen Unterschnittstellen beendet oder die beiden Verbindungen innerhalb des Partnernetzwerks zusammengeführt werden. Diese Beeinträchtigung wird in der folgenden Abbildung dargestellt.

2

Wenn Sie hingegen die primären und sekundären Verbindungen einer ExpressRoute-Verbindung an verschiedenen geografischen Standorten beenden, könnten Sie die Netzwerkleistung der Konnektivität beeinträchtigen. Wenn für den Datenverkehr ein aktiver Lastausgleich zwischen der primären Verbindung und den sekundären Verbindungen besteht, die an verschiedenen geografischen Standorten beendet werden, würde ein potenzieller wesentlicher Unterschied in der Netzwerklatenz zwischen den beiden Pfaden zu einer suboptimalen Netzwerkleistung führen.

Weitere Informationen zu georedundanten Entwurfsüberlegungen finden Sie unter Entwurf für die Notfallwiederherstellung mit ExpressRoute.

Aktiv/Aktiv-Verbindungen

Das Microsoft-Netzwerk ist so konfiguriert, dass es die primären und sekundären Verbindungen der ExpressRoute-Verbindungen im Aktiv/Aktiv-Modus betreibt. Durch Ihre Routenankündigungen können Sie jedoch die redundanten Verbindungen einer ExpressRoute-Verbindung zwingen, den Aktiv/Passiv-Modus zu nutzen. Die Ankündigung spezifischerer Routen und das Voranstellen von BGP-AS-Pfaden sind die gebräuchlichsten Techniken, um einen Pfad dem anderen vorzuziehen.

Um die Hochverfügbarkeit zu verbessern, wird empfohlen, beide Verbindungen einer ExpressRoute-Verbindung im Aktiv-Aktiv-Modus zu betreiben. Wenn Sie die Verbindungen im Aktiv-Aktiv-Modus arbeiten lassen, führt das Microsoft-Netzwerk einen Lastenausgleich des Datenverkehrs über die Verbindungen hinweg auf einer Pro-Datenfluss-Basis durch.

Wenn die primären und sekundären Verbindungen einer ExpressRoute-Verbindung im Aktiv-Passiv-Modus ausgeführt werden, besteht die Gefahr, dass beide Verbindungen nach einem Fehler im aktiven Pfad ausfallen. Die häufigsten Ursachen für einen Ausfall beim Umschalten sind mangelnde aktive Verwaltung der passiven Verbindung und passive Verbindungsankündigung veralteter Routen.

Alternativ führt das Betreiben der primären und sekundären Verbindungen einer ExpressRoute-Verbindung im Aktiv-Aktiv-Modus dazu, dass nur etwa die Hälfte der Datenflüsse fehlschlägt und umleitet wird. Daher trägt eine Aktiv-Aktiv-Verbindung erheblich zur Verbesserung der mittleren Wiederherstellungszeit (Mean Time To Recovery, MTTR) bei.

Hinweis

Während einer Wartungsaktivität oder bei ungeplanten Ereignissen, die sich auf eine der Verbindungen auswirken, bevorzugt Microsoft die AS-Pfadpräfigierung, um Datenverkehr zum Ausgleich auf die fehlerfreie Verbindung umzuleiten. Sie müssen sicherstellen, dass der Datenverkehr über den fehlerfreien Pfad geleitet werden kann, wenn Microsoft die Pfadpräfigierung konfiguriert hat, und dass erforderliche Umleitungsankündigungen entsprechend konfiguriert sind, um Dienstunterbrechungen zu vermeiden.

NAT für Microsoft-Peering

Microsoft-Peering dient der Kommunikation zwischen öffentlichen Endpunkten. So sind lokale private Endpunkte häufig netzwerkadressenübersetzt (Network Address Translated, NATed) mit öffentlicher IP-Adresse für das Kunden- oder Partnernetzwerk, bevor sie über Microsoft-Peering kommunizieren. Es wird angenommen, dass Sie sowohl die primäre als auch die sekundäre Verbindung in einem Aktiv-Aktiv-Setup verwenden. Der Ort und die Art Ihres NAT hat Auswirkungen darauf, wie schnell nach einem Ausfall einer der ExpressRoute-Verbindungen eine Wiederherstellung erfolgt. Zwei verschiedene NAT-Optionen werden in der folgenden Abbildung gezeigt:

3

Option 1:

NAT wird angewendet, nachdem der Datenverkehr zwischen der primären Verbindung und den sekundären Verbindungen der ExpressRoute-Leitung aufgeteilt wurde. Um die zustandsbehafteten Anforderungen von NAT zu erfüllen, werden unabhängige NAT-Pools für die primären und sekundären Geräte verwendet. Der zurückgegebene Datenverkehr trifft auf demselben Edgegerät ein, über das der Datenfluss ausgegangen ist.

Wenn bei der ExpressRoute-Verbindung ein Fehler auftritt, ist die Erreichbarkeit des entsprechenden NAT-Pools unterbrochen. Deshalb müssen alle unterbrochenen Netzwerkdatenflüsse entweder durch TCP oder über die Anwendungsschicht nach dem entsprechenden Fenstertimeout erneut eingerichtet werden. Während des Fehlers kann Azure die lokalen Server nicht über die entsprechende NAT erreichen, bis die Konnektivität für die primären oder sekundären Verbindungen der ExpressRoute-Leitung wiederhergestellt wurde.

Option 2:

Es wird ein allgemeiner NAT-Pool verwendet, bevor der Datenverkehr zwischen der primären Verbindung und den sekundären Verbindungen der ExpressRoute-Leitung aufgeteilt wird. Es ist wichtig zu unterscheiden, dass der gemeinsame NAT-Pool vor der Aufteilung des Datenverkehrs nicht die Einführung einer einzelnen Fehlerquelle bedeutet und damit die Hochverfügbarkeit beeinträchtigt.

Der NAT-Pool ist auch nach einem Fehler bei der primären oder sekundären Verbindung erreichbar. Die Netzwerkebene kann also selbst die Pakete umleiten und bei der schnelleren Wiederherstellung nach einem Fehler helfen.

Hinweis

  • Wenn Sie NAT-Option 1 (unabhängige NAT-Pools für primäre und sekundäre ExpressRoute-Verbindungen) verwenden und einen Port einer IP-Adresse von einem der NAT-Pools einem lokalen Server zuordnen, ist der Server über die ExpressRoute-Verbindung nicht erreichbar, wenn die entsprechende Verbindung ausfällt.
  • Das Beenden von ExpressRoute-BGP-Verbindungen auf zustandsbehafteten Geräten kann bei geplanten oder ungeplanten Wartungen durch Microsoft oder Ihren ExpressRoute-Anbieter zu Problemen beim Failover führen. Sie sollten Ihre Einrichtung testen, um das ordnungsgemäße Failover Ihres Datenverkehrs sicherzustellen, und nach Möglichkeit BGP-Sitzungen auf zustandslosen Geräten beenden.

Optimieren von Funktionen für privates Peering

In diesem Abschnitt erläutern wir optionale Funktionen (abhängig von Ihrer Azure-Bereitstellung und der Empfindlichkeit hinsichtlich der MTTR), die zur Verbesserung der Hochverfügbarkeit Ihrer ExpressRoute-Verbindung beitragen. Befassen wir uns also insbesondere mit der zonenfähigen Bereitstellung von virtuellen ExpressRoute-Netzwerkgateways und der bidirektionalen Weiterleitungserkennung (Bidirectional Forwarding Detection, BFD).

Verfügbarkeitszonenfähige ExpressRoute-Gateways für virtuelle Netzwerke

Eine Verfügbarkeitszone in einer Azure-Region ist eine Kombination aus einer Fehlerdomäne und einer Updatedomäne. Um die höchste Ausfallsicherheit und Verfügbarkeit zu erreichen, sollten Sie ein zonenredundantes virtuelles ExpressRoute-Netzwerkgateway konfigurieren. Mehr dazu erfahren Sie unter Informationen zu zonenredundanten Gateways für das virtuelle Netzwerk 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

ExpressRoute unterstützt BFD über privates Peering. BFD reduziert 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 Ausfallerkennungszeit hilft dabei, die Wiederherstellung nach einem Fehler zu beschleunigen. Weitere Informationen finden Sie unter Konfigurieren von BFD über ExpressRoute.

Nächste Schritte

In diesem Artikel haben wir erläutert, wie Sie die Hochverfügbarkeit der Konnektivität einer ExpressRoute-Verbindung konzipieren können. Ein Peeringpunkt einer ExpressRoute-Verbindung ist an einen geografischen Standort gebunden und ist daher von einem katastrophenbedingten Ausfall betroffen, der sich auf den gesamten Standort auswirkt.

Ü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 ExpressRoute-Peering.