Entwurf für die Notfallwiederherstellung mit privatem ExpressRoute-Peering

  • 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. Entwurfsüberlegungen zum Maximieren der Verfügbarkeit einer ExpressRoute-Verbindung finden Sie unter Entwerfen für Hochverfügbarkeit mit ExpressRoute und Well-Architectured Framework (Framework mit guter Architektur).

Wir wollen jedoch Murphys populäres Sprichwort nicht vergessen: Alles, was schiefgehen kann, wird auch schiefgehen. Konzentrieren wir uns in diesem Artikel also auf Lösungen, die über Fehler hinausgehen, die mit einer einzigen ExpressRoute-Verbindung behoben werden können. Wir werden Überlegungen zur Netzwerkarchitektur anstellen, um eine robuste Back-End-Netzwerkverbindung für die Notfallwiederherstellung mit georedundanten ExpressRoute-Verbindungen aufzubauen.

Hinweis

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

Erfordernis einer redundanten Konnektivitätslösung

Es gibt Möglichkeiten und Fälle, in denen ein ExpressRoute-Peering-Standort oder ein ganzer regionaler Dienst beeinträchtigt wird. Die Hauptursache für solche flächendeckenden Dienstausfälle sind Naturkatastrophen. Daher ist es für die Geschäftskontinuität und unternehmenskritische Anwendungen wichtig, die Notfallwiederherstellung zu planen.

Hinweis

Wenn Sie einen Entwurf für die Notfallwiederherstellung in einer zeitkritischen Situation implementieren müssen, z. B. um die Geschäftskontinuität während einer Naturkatastrophe aufrechtzuerhalten, sollten Sie die folgenden Faktoren berücksichtigen:

  • Dieses Dokument enthält Anleitungen zum Implementieren eines robusten Entwurfs für die Notfallwiederherstellung für mehrere ExpressRoute-Verbindungen, die über verschiedene Peeringstandorte konfiguriert sind. In diesem Szenario wird davon ausgegangen, dass Sie über ausreichend Zeit und Ressourcen verfügen, um die ExpressRoute-Verbindung einzurichten.
  • Wenn Sie schnell einen Notfallwiederherstellungsentwurf für eine einzelne ExpressRoute-Verbindung konfigurieren müssen, die nicht georedundant ist, können Sie die folgenden Alternativen verwenden:
    • Verwenden Sie ein Site-to-Site-VPN als Sicherung für privaten Peeringdatenverkehr.
    • Verwenden Sie Internetkonnektivität als Sicherung für Microsoft-Peeringdatenverkehr.

Unabhängig davon, ob Sie Ihre unternehmenskritischen Anwendungen in einer Azure-Region, lokal oder anderswo ausführen, können Sie eine andere Azure-Region als Failoverstandort verwenden. Die folgenden Artikel behandeln Notfallwiederherstellung aus Anwendungs- und Front-End-Zugriffsperspektiven:

Wenn Sie auf die ExpressRoute-Konnektivität zwischen Ihrem lokalen Netzwerk und Microsoft setzen, müssen Sie folgendes berücksichtigen, um Notfallwiederherstellung über ExpressRoute zu planen:

Herausforderungen beim Verwenden mehrerer ExpressRoute-Verbindungen

Wenn Sie dieselbe Gruppe von Netzwerken über mehrere Verbindungen miteinander verbinden, führen Sie parallele Pfade zwischen den Netzwerken ein. Parallele Pfade können, wenn sie nicht richtig entworfen werden, zu asymmetrischem Routing führen. Wenn Sie zustandsbehaftete Entitäten (z. B. NAT, Firewall) im Pfad haben, kann asymmetrisches Routing den Datenverkehrsfluss blockieren. In der Regel werden Sie über den privaten ExpressRoute-Peeringpfad auf keine zustandsbehafteten Entitäten wie NAT oder Firewalls treffen. Daher blockiert asymmetrisches Routing über privates ExpressRoute-Peering nicht unbedingt den Datenverkehrsfluss.

Wenn Sie jedoch für Datenverkehr einen Lastenausgleich über georedundante parallele Pfade durchführen, würden Sie unabhängig davon, ob zustandsbehaftete Entitäten vorhanden sind, eine inkonsistente Netzwerkleistung feststellen. Diese georedundanten parallelen Pfade können über dieselbe Metropolregion oder eine andere Metropolregion auf der Seite Anbieter nach Standort gefunden werden.

Redundanz mit ExpressRoute-Verbindungen in derselben Metropolregion

Viele Metropolregionen verfügen über zwei ExpressRoute-Standorte. Ein Beispiel hierfür ist Amsterdam und Amsterdam2. Beim Entwerfen der Redundanz können Sie zwei parallele Pfade zu Azure erstellen, die beide Standorte in derselben Metropolregion haben. Sie können dies mit demselben Anbieter tun oder sich für einen anderen Dienstanbieter entscheiden, um die Resilienz zu verbessern. Ein weiterer Vorteil dieses Entwurfs liegt darin, dass im Fall eines Anwendungs-Failovers die End-to-End-Latenz zwischen Ihren lokalen Anwendungen und Microsoft ungefähr gleich bleibt. Wenn jedoch eine Naturkatastrophe wie ein Erdbeben eintritt, ist die Konnektivität für beide Pfade möglicherweise nicht mehr verfügbar.

Redundanz mit ExpressRoute-Verbindungen in verschiedenen Metros

Wenn Sie unterschiedliche Metros für Redundanz verwenden, sollten Sie den sekundären Standort in derselben Region für die georedundante Regionauswählen. Um einen Standort außerhalb der geopolitischen Region zu wählen, müssen Sie Premium SKU für beide Verbindungen in den Parallelpfaden verwenden. Der Vorteil dieser Konfiguration besteht darin, dass eine Naturkatastrophe, bei der es zu einem Ausfall kommt, zu beiden Verknüpfungen weitaus geringer ist, aber auf Kosten einer erhöhten End-to-End-Latenz.

Hinweis

Das Aktivieren von BFD für die ExpressRoute-Verbindungen hilft bei der schnelleren Erkennung von Verbindungsausfällen zwischen MSEE-Geräten (Microsoft Enterprise Edge) und den Kunden/Partner-Edge-Routern. Failover und Konvergenz zur redundanten Site können jedoch unter einigen Fehlerbedingungen insgesamt bis zu 180 Sekunden in Anspruch nehmen, und während dieser Zeit können eine höhere Wartezeit oder Leistungsbeeinträchtigung auftreten.

In diesem Artikel wird erläutert, wie Sie Probleme beheben, die bei der Konfiguration von georedundanten Pfaden auftreten können.

Überlegungen zu kleinen bis mittelgroßen lokalen Netzwerken

Sehen Sie sich das Beispielnetzwerk an, das in der folgenden Abbildung dargestellt wird. Im Beispiel wird die georedundante ExpressRoute-Konnektivität zwischen einem lokalen Standort von Contoso und dem VNET von Contoso in einer Azure-Region hergestellt. In der Abbildung zeigt eine durchgehende blaue Linie den bevorzugten Pfad (über ExpressRoute 1) und die gestrichelte Linie den Standbypfad (über ExpressRoute 2) an.

Diagramm mit Überlegungen für kleine bis mittelgroße lokale Netzwerke.

Wenn Sie Routen über alle ExpressRoute-Pfade identisch ankündigen, führt Azure standardmäßig den Lastenausgleich für lokal gebundenen Datenverkehr über alle ExpressRoute-Pfade hinweg mit ECMP (Equal-Cost Multi-Path)-Routing durch.

Bei den georedundanten ExpressRoute-Verbindungen müssen wir jedoch unterschiedliche Netzwerkleistungen mit unterschiedlichen Netzwerkpfaden (insbesondere für die Netzwerklatenz) berücksichtigen. Um eine konsistentere Netzwerkleistung im normalen Betrieb zu erreichen, sollten Sie die ExpressRoute-Verbindung bevorzugen, die die geringste Latenzzeit bietet.

Sie können Azure so beeinflussen, dass eine ExpressRoute-Verbindung einer anderen vorgezogen wird, indem Sie eine der folgenden Techniken verwenden (in der Reihenfolge ihrer Effektivität):

  • Ankündigen der spezifischeren Route vor der bevorzugten ExpressRoute-Verbindung im Vergleich zu anderen ExpressRoute-Verbindungen
  • Konfigurieren einer höheren Verbindungsgewichtung für die Verbindung, die das virtuelle Netzwerk mit der bevorzugten ExpressRoute-Verbindung verbindet
  • Ankündigen der Routen über weniger bevorzugte ExpressRoute-Verbindungen mit einem längeren AS-Pfad (Voranstellen des AS-Pfads)

Spezifischere Route

Die folgende Abbildung veranschaulicht die Beeinflussung der ExpressRoute-Pfadauswahl durch eine spezifischere Routenankündigung. Im dargestellten Beispiel wird der lokale /24-IP-Bereich von Contoso als zwei /25-Adressbereiche über den bevorzugten Pfad (ExpressRoute 1) und als /24 über den Standbypfad (ExpressRoute 2) angekündigt.

Diagramm: Einfluss auf die Pfadauswahl mithilfe von spezifischeren Routen.

Da /25 im Vergleich zu /24 spezifischer ist, würde Azure den für 10.1.11.11.0/24 bestimmten Datenverkehr im Normalzustand über ExpressRoute 1 senden. Wenn beide Verbindungen von ExpressRoute 1 unterbrochen werden, würde das VNET die 10.1.11.11.0/24-Routenankündigung nur über ExpressRoute 2 erkennen. Daher wird in diesem Fehlerzustand die Standbyverbindung verwendet.

Verbindungsgewichtung

Der folgende Screenshot zeigt das Konfigurieren der Gewichtung einer ExpressRoute-Verbindung über das Azure-Portal.

Screenshot: Konfigurieren der Verbindungsgewichtung über das Azure-Portal.

Die folgende Abbildung veranschaulicht die Beeinflussung der ExpressRoute-Pfadauswahl durch eine Verbindungsgewichtung. Die Standardverbindungsgewichtung ist 0. Im folgenden Beispiel wird die Gewichtung der Verbindung für ExpressRoute 1 als 100 konfiguriert. Wenn ein VNet ein Routenpräfix empfängt, das über mehrere ExpressRoute-Verbindungen angekündigt wird, bevorzugt das VNet die Verbindung mit der höchsten Gewichtung.

Diagramm: Einfluss auf die Pfadauswahl mithilfe von Verbindungsgewichtung.

Wenn beide Verbindungen von ExpressRoute 1 unterbrochen werden, würde das VNET die 10.1.11.11.0/24-Routenankündigung nur über ExpressRoute 2 erkennen. Daher wird in diesem Fehlerzustand die Standbyverbindung verwendet.

Vorangestellter AS-Pfad

Die folgende Abbildung veranschaulicht die Beeinflussung der ExpressRoute-Pfadauswahl durch einen vorangestellten AS-Pfad. In der Abbildung gibt die Routenankündigung über ExpressRoute 1 das Standardverhalten von eBGP an. Für die Ankündigung der Route über ExpressRoute 2 wird die ASN des lokalen Netzwerks außerdem dem AS-Pfad der Route vorangestellt. Wenn die gleiche Route über mehrere ExpressRoute-Verbindungen empfangen wird, würde das VNET über das eBGP-Routenauswahlverfahren die Route mit dem kürzesten AS-Pfad bevorzugen.

Diagramm: Einfluss auf die Pfadauswahl durch AS-Pfadvoranstellung.

Wenn beide Verbindungen von ExpressRoute 1 ausfallen, würde das VNET die 10.1.11.11.0/24-Routenankündigung nur über ExpressRoute 2 erkennen. Folglich würde der längere AS-Pfad irrelevant werden. Aus diesem Grund würde die Standbyverbindung in diesem Fehlerzustand verwendet.

Wenn Sie Azure mithilfe einer dieser Techniken so beeinflussen, dass eine Ihrer ExpressRoute-Verbindungen gegenüber anderen bevorzugt wird, müssen Sie außerdem sicherstellen, dass auch das lokale Netzwerk den gleichen ExpressRoute-Pfad für Azure-gebundenen Datenverkehr bevorzugt, um asymmetrische Datenflüsse zu vermeiden. In der Regel wird der Wert für die lokale Einstellung verwendet, um das lokale Netzwerk so zu beeinflussen, dass es eine ExpressRoute-Verbindung gegenüber anderen bevorzugt. Die lokale Einstellung ist eine interne BGP-Metrik (iBGP). Die BGP-Route mit dem höchsten Wert für die lokale Einstellung wird bevorzugt.

Wichtig

Wenn Sie bestimmte ExpressRoute-Verbindungen als Standby verwenden, müssen Sie diese aktiv verwalten und den Failovervorgang in regelmäßigen Abständen testen.

Großes verteiltes Unternehmensnetzwerk

Wenn Sie über ein großes verteiltes Unternehmensnetzwerk verfügen, verwenden Sie wahrscheinlich mehrere ExpressRoute-Verbindungen. In diesem Abschnitt sehen wir uns an, wie eine Notfallwiederherstellung mithilfe der Aktiv-Aktiv-ExpressRoute-Verbindungen entworfen wird, ohne dass zusätzliche Standbyverbindungen benötigt werden.

Sehen Sie sich das Beispiel an, das in der folgenden Abbildung dargestellt wird. Im Beispiel verfügt Contoso über zwei lokale Standorte, die mit zwei Contoso-IaaS-Bereitstellungen in zwei verschiedenen Azure-Regionen über ExpressRoute-Verbindungen an zwei verschiedenen Peeringstandorten verbunden sind.

Diagramm: Überlegungen zu großen verteilten lokalen Netzwerken.

Die Art und Weise, wie wir die Notfallwiederherstellung planen, hat Einfluss darauf, wie regionsübergreifender Datenverkehr an standortübergreifenden Datenverkehr (/region1/region2 an location2/location1) weitergeleitet wird. Betrachten wir zwei verschiedene Notfallarchitekturen, die regions-/standortübergreifenden Datenverkehr auf verschiedene Weise weiterleiten.

Szenario 1

Im ersten Szenario entwerfen wir die Notfallwiederherstellung so, dass der gesamte Datenverkehr zwischen einer Azure-Region und dem lokalen Netzwerk im stabilen Zustand über die lokale ExpressRoute-Verbindung fließt. Wenn die lokale ExpressRoute-Verbindung ausfällt, wird die ExpressRoute-Remoteverbindung für alle Datenströme zwischen Azure und dem lokalen Netzwerk verwendet.

Szenario 1 wird in der folgenden Abbildung gezeigt. In der Abbildung geben grüne Linien Pfade für den Datenverkehrsfluss zwischen VNet1 und lokalen Netzwerken an. Die blauen Linien geben Pfade für den Datenverkehrsfluss zwischen VNet2 und lokalen Netzwerken an. Durchgehende Linien zeigen den gewünschten Pfad im stabilen Zustand an, und die gestrichelten Linien zeigen den Datenverkehrspfad beim Ausfall der entsprechenden ExpressRoute-Verbindung an, die den stabilen Datenverkehrsfluss übernimmt.

Diagramm: Datenverkehrsfluss für das erste Szenario.

Sie können das Szenario mithilfe der Verbindungsgewichtung entwerfen, um VNETs so zu beeinflussen, dass sie die Verbindung mit dem lokalen Peeringstandort ExpressRoute für den lokalen netzwerkgebundenen Datenverkehr vorziehen. Um die Lösung zu vervollständigen, müssen Sie symmetrischen umgekehrten Datenverkehr sicherstellen. Sie können die lokale Einstellung für die iBGP-Sitzung zwischen Ihren BGP-Routern (auf denen ExpressRoute-Verbindungen auf der lokalen Seite beendet werden) verwenden, um eine ExpressRoute-Verbindung zu bevorzugen. Die Lösung wird in der folgenden Abbildung dargestellt.

Diagramm: Aktiv/Aktiv-ExpressRoute-Verbindungen: Lösung 1.

Szenario 2

Szenario 2 wird in der folgenden Abbildung dargestellt. In der Abbildung geben grüne Linien Pfade für den Datenverkehrsfluss zwischen VNet1 und lokalen Netzwerken an. Die blauen Linien geben Pfade für den Datenverkehrsfluss zwischen VNet2 und lokalen Netzwerken an. Im stabilen Zustand (durchgezogene Linien in der Abbildung) fließt der gesamte Datenverkehr zwischen VNets und lokalen Standorten größtenteils über einen Microsoft-Backbone und durchläuft die Verbindung zwischen lokalen Standorten nur im Fehlerzustand (gestrichelte Linien im Diagramm) einer ExpressRoute-Verbindung.

Diagramm: Datenverkehrsfluss für das zweite Szenario.

Die Lösung wird in der folgenden Abbildung dargestellt. Wie gezeigt, können Sie das Szenario entweder mit einer spezifischeren Route (Option 1) oder einem vorangestellten AS-Pfad (Option 2) entwerfen, um die VNET-Pfadauswahl zu beeinflussen. Um die lokale Netzwerkroutenauswahl für den Azure-gebundenen Datenverkehr zu beeinflussen, müssen Sie die Verbindung zwischen dem lokalen Standort als weniger bevorzugt konfigurieren. Wie Sie die Verbindung als bevorzugt konfigurieren, hängt vom Routingprotokoll ab, das innerhalb des lokalen Netzwerks verwendet wird. Sie können die lokale Einstellung mit iBGP oder die Metrik mit IGP (OSPF oder IS-IS) verwenden.

Diagramm: Aktiv/Aktiv-ExpressRoute-Verbindungen: Lösung 2.

Wichtig

Wenn eine oder mehrere ExpressRoute-Verbindungen mit mehreren virtuellen Netzwerken verbunden sind, kann der Datenverkehr von virtuellen Netzwerken mit anderen virtuellen Netzwerken über ExpressRoute weitergeleitet werden. Dies ist wird jedoch nicht empfohlen. Wenn Sie Konnektivität zwischen virtuellen Netzwerken ermöglichen möchten, konfigurieren Sie das Peering virtueller Netzwerke.

Nächste Schritte

In diesem Artikel haben wir erläutert, wie Sie die Notfallwiederherstellung einer privaten Peeringkonnektivität einer ExpressRoute-Verbindung konzipieren können. Die folgenden Artikel behandeln Notfallwiederherstellung aus Anwendungs- und Front-End-Zugriffsperspektiven: