Notfallwiederherstellungsentwurf

  • Artikel

Mit Virtual WAN können Sie alle Ihre globalen Bereitstellungen aggregieren, verbinden, zentral verwalten und schützen. Ihre globalen Bereitstellungen können beliebige Kombinationen aus verschiedenen Zweigstellen, POP-Standorten (Point of Presence), privaten Benutzern, Niederlassungen, virtuellen Azure-Netzwerken und anderen Bereitstellungen mit mehreren Clouds umfassen. Sie können SD-WAN, Site-to-Site-VPN, Point-to-Site-VPN und ExpressRoute verwenden, um Ihre verschiedenen Standorte mit einem virtuellen Hub zu verbinden. Wenn Sie über mehrere virtuelle Hubs verfügen, werden alle Hubs in Form einer Full-Mesh-Topologie in einer Virtual WAN-Standardbereitstellung verbunden.

In diesem Artikel erfahren Sie, wie Sie verschiedene Optionen der Network-as-a-Service-Konnektivität einrichten, die von Virtual WAN für die Notfallwiederherstellung unterstützt werden.

Optionen für die Network-as-a-Service-Konnektivität von Virtual WAN

Von Virtual WAN werden folgende Back-End-Konnektivitätsoptionen unterstützt:

  • Remotebenutzerkonnektivität
  • Branch/Office/SD-WAN/Site-to-Site-VPN
  • Private Konnektivität (privates ExpressRoute-Peering)

Für jede dieser Konnektivitätsoptionen wird von Virtual WAN ein separater Satz von Gatewayinstanzen innerhalb eines virtuellen Hubs bereitgestellt.

Virtual WAN ist von Grund auf als hochverfügbare Netzwerkaggregationslösung auf Netzbetreiberniveau konzipiert. Um Hochverfügbarkeit zu erreichen, werden von Virtual WAN jeweils mehrere Instanzen instanziiert, wenn die verschiedenen Arten von Gateways innerhalb eines Virtual WAN-Hubs bereitgestellt werden. Weitere Informationen zur Hochverfügbarkeit von ExpressRoute finden Sie unter Entwurf für Hochverfügbarkeit mit ExpressRoute.

Bei einem Point-to-Site-VPN-Gateway werden mindestens zwei Instanzen bereitgestellt. Beim Point-to-Site-VPN-Gateway wählen Sie die aggregierte Durchsatzkapazität von Point-to-Site-Gateways aus. Es werden dann mehrere Instanzen automatisch für Sie bereitgestellt. Die aggregierte Kapazität wird gemäß der Anzahl von Clients oder Benutzer*innen ausgewählt, die mit dem virtuellen Hub verbunden werden sollen. Aus der Perspektive der Clientkonnektivität sind die Point-to-Site-VPN-Gatewayinstanzen hinter dem vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Gateways verborgen.

Für das Site-to-Site-VPN-Gateway werden zwei Instanzen des Gateways innerhalb eines virtuellen Hubs bereitgestellt. Jede der Gatewayinstanzen wird mit eigenen öffentlichen und privaten IP-Adressen bereitgestellt. Der folgende Screenshot zeigt die IP-Adressen, die den beiden Instanzen einer Beispielkonfiguration eines Site-to-Site-VPN-Gateways zugeordnet sind. Anders ausgedrückt: Von den beiden Instanzen werden zwei unabhängige Tunnelendpunkte bereitgestellt, um Site-to-Site-VPN-Konnektivität von Ihren Zweigstellen aus zu ermöglichen. Informationen zum Maximieren von Hochverfügbarkeit finden Sie unter Azure-Pfadauswahl über mehrere ISP-Links.

Screenshot: Beispiel für die Konfiguration des Site-to-Site-V PN-Gateways.

Die Maximierung der Hochverfügbarkeit Ihrer Netzwerkarchitektur ist ein wichtiger erster Schritt für Business Continuity & Disaster Recovery (BCDR). Der restliche Teil dieses Artikels geht wie bereits erwähnt über Hochverfügbarkeit hinaus und enthält Informationen zur Einrichtung Ihres Virtual WAN-Konnektivitätsnetzwerks für BCDR.

Grund für einen Notfallwiederherstellungsentwurf

Ein Notfall kann jederzeit und überall eintreten – in Regionen oder im Netzwerk eines Cloudanbieters, innerhalb eines Dienstanbieternetzwerks oder innerhalb eines lokalen Netzwerks. Regionale Auswirkungen eines Cloud- oder Netzwerkdiensts, die sich aufgrund bestimmter Faktoren wie Naturkatastrophen, menschlicher Fehler, Krieg, Terrorismus oder Fehlkonfigurationen ergeben, lassen sich nur schwer ausschließen. Für die Kontinuität Ihrer unternehmenskritischen Anwendungen benötigen Sie daher einen Notfallwiederherstellungsentwurf. Ein umfassender Notfallwiederherstellungsentwurf erfordert die Identifizierung aller Abhängigkeiten, die in Ihrem End-to-End-Kommunikationspfad ausfallen können, und die Schaffung von Redundanz ohne Überschneidungen für jede der Abhängigkeiten.

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

Herausforderungen bei der Verwendung redundanter Konnektivität

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 Datenfluss blockieren. Bei privater Konnektivität sind in der Regel keine zustandsbehafteten Entitäten wie NAT oder Firewalls vorhanden oder relevant. Daher blockiert asymmetrisches Routing über private Konnektivität nicht unbedingt den Datenfluss.

Wenn Sie jedoch für Datenverkehr einen Lastenausgleich über georedundante parallele Pfade hinweg durchführen, führt dies aufgrund der Unterschiede beim physischen Pfad der parallelen Verbindungen zu inkonsistenter Netzwerkleistung. Daher muss für den Notfallwiederherstellungsentwurf die Leistung des Netzwerkdatenverkehrs sowohl während des stabilen (fehlerfreien) Zustands als auch während eines Ausfalls berücksichtigt werden.

Redundanz der Zugriffsnetzwerke

Die meisten SD-WAN-Dienste (sowohl verwaltete als auch andere Lösungen) bieten Netzwerkkonnektivität über mehrere Transporttypen wie Breitbandinternet, MPLS oder LTE. Nutzen Sie für die Konnektivität mehrere Transportnetzwerke, um sich gegen den Ausfall eines Transportnetzwerks abzusichern. In Szenarien mit Privatbenutzern kann die Verwendung des mobilen Netzwerks als Ausweichlösung für das Breitbandinternet in Betracht gezogen werden.

Sollte keine Netzwerkkonnektivität über einen anderen Transporttyp möglich sein, entscheiden Sie sich für Netzwerkkonnektivität über mehrere Dienstanbieter. Achten Sie bei der Verwendung von Konnektivität über mehrere Dienstanbieter darauf, dass die Dienstanbieter über unabhängige Zugriffsnetzwerke ohne Überschneidungen verfügen.

Überlegungen zur Remotebenutzerkonnektivität

Die Remotebenutzerkonnektivität wird über ein Point-to-Site VPN zwischen einem Endbenutzergerät und einem Netzwerk eingerichtet. Nach einem Netzwerkfehler verwirft das Endgerät den VPN-Tunnel und versucht anschließend, den VPN-Tunnel wieder einzurichten. Daher sollte Ihr Notfallwiederherstellungsentwurf bei einem Point-to-Site-VPN darauf abzielen, die Wiederherstellungszeit nach einem Fehler zu minimieren. Die folgende Netzwerkredundanz trägt zur Minimierung der Wiederherstellungszeit bei. Je nachdem, wie kritisch die Verbindungen sind, können Sie einige oder alle dieser Optionen auswählen.

  • Redundanz der Zugriffsnetzwerke (wie oben beschrieben)
  • Verwalten redundanter virtueller Hubs für die Point-to-Site-VPN-Terminierung. Wenn Sie über mehrere virtuelle Hubs mit Point-to-Site-Gateways verfügen, wird von Virtual WAN ein globales Profil mit allen Point-to-Site-Endpunkten bereitgestellt. Dank des globalen Profils können Ihre Geräte eine Verbindung mit dem nächstgelegenen verfügbaren virtuellen Hub herstellen, der die beste Netzwerkleistung bietet. Wenn alle Ihre Azure-Bereitstellungen in einer einzelnen Region vorhanden sind und die Endgeräte, von denen eine Verbindung hergestellt wird, sich in der Nähe der Region befinden, können Sie über redundante virtuelle Hubs innerhalb der Region verfügen. Wenn Ihre Bereitstellung und Ihre Geräte auf mehrere Regionen verteilt sind, können Sie in jeder Ihrer ausgewählten Regionen einen virtuellen Hub mit Point-to-Site-Gateway bereitstellen. Virtual WAN verfügt über einen integrierten Datenverkehrs-Manager, der automatisch den besten Hub für die Remotebenutzerkonnektivität auswählt.

Im folgenden Diagramm wird das Konzept der Verwaltung redundanter virtueller Hubs mit jeweils zugehörigem Point-to-Site-Gateway innerhalb einer Region veranschaulicht:

Abbildung: Point-to-Site-Aggregation mit mehreren Hubs.

Im obigen Diagramm stellen die durchgehenden grünen Linien die primären Point-to-Site-VPN-Verbindungen und die gestrichelten gelben Linien die Ausweichverbindungen im Standbymodus dar. Durch das globale Point-to-Site-Profil von Virtual WAN werden Haupt- und Ausweichverbindungen auf der Grundlage der Netzwerkleistung ausgewählt. Weitere Informationen zum globalen Profil finden Sie unter Herunterladen eines globalen oder hubbasierten Profils für Benutzer-VPN-Clients.

Überlegungen zum Site-to-Site-VPN

Sehen Sie sich als Nächstes das im folgenden Diagramm gezeigte Site-to-Site-VPN-Verbindungsbeispiel an. Informationen zum Herstellen einer Site-to-Site-VPN-Verbindung mit hochverfügbaren Aktiv-Aktiv-Tunneln finden Sie unter Tutorial: Erstellen einer Site-to-Site-Verbindung per Azure Virtual WAN.

Abbildung: Verbinden eines lokalen Branch mit virtual WAN über Site-to-Site-VPN.

Hinweis

Zur besseren Übersichtlichkeit des Abschnitts gehen wir hier nicht noch einmal auf das Hochverfügbarkeitsfeature des Site-to-Site-VPN-Gateways ein, das es Ihnen ermöglicht, bei jeder von Ihnen konfigurierten VPN-Verbindung zwei Tunnel zu zwei verschiedenen Endpunkten zu erstellen. Denken Sie jedoch beim Bereitstellen einer der in diesem Abschnitt vorgeschlagenen Architekturen daran, zwei Tunnel für jede von Ihnen eingerichtete Verbindung zu konfigurieren.

Zum Schutz vor Ausfällen von VPN-CPE (Customer Premises Equipment, Geräte in der Kundenumgebung) einer Zweigstelle können Sie parallele VPN-Verbindungen mit einem VPN-Gateway über parallele CPE-Geräte der Zweigstelle konfigurieren. Darüber hinaus können Sie zum Schutz vor Netzwerkausfällen eines Dienstanbieters der letzten Meile für die Filiale verschiedene VPN-Verbindungen über ein anderes Dienstanbieternetzwerk konfigurieren. Das folgende Diagramm zeigt mehrere VPN-Verbindungen, die von zwei verschiedenen CPE-Geräten einer Zweigstelle ausgehen und am gleichen VPN-Gateway enden:

Abbildung: Redundante Site-to-Site-VPN-Verbindungen mit einem Zweigstellenstandort.

Von einem VPN-Gateway eines virtuellen Hubs aus können bis zu vier Verbindungen mit einer Zweigstelle konfiguriert werden. Beim Konfigurieren einer Verbindung mit einer Zweigstelle können Sie den Dienstanbieter sowie die Durchsatzgeschwindigkeit für die Verbindung angeben. Wenn Sie parallele Verbindungen zwischen einer Zweigstelle und einem virtuellen Hub konfigurieren, wird vom VPN-Gateway standardmäßig ein Lastenausgleich für den Datenverkehr über die parallelen Verbindungen durchgeführt. Der Lastenausgleich des Datenverkehrs erfolgt gemäß ECMP (Equal-Cost Multi Path) pro Datenfluss.

Die Topologie mit mehreren Verbindungen schützt vor CPE-Geräteausfällen sowie vor dem Ausfall eines Dienstanbieternetzwerks am lokalen Standort der Zweigstelle. Eine Topologie mit mehreren Hubs und Verbindungen kann zudem zum Schutz vor Downtime eines VPN-Gateways für virtuelle Hubs beitragen. Das folgende Diagramm zeigt die Topologie, in der mehrere virtuelle Hubs unter einer Virtual WAN-Instanz in einer Region konfiguriert sind:

Abbildung: Site-to-Site-VPN-Verbindungen mit mehreren Hubs mit einem Zweigstellenstandort.

Da in der obigen Topologie die Wartezeit innerhalb der Azure-Region über die Verbindung zwischen den Hubs vernachlässigbar ist, können Sie alle Site-to-Site-VPN-Verbindungen zwischen der lokalen Umgebung und den beiden virtuellen Hubs im Aktiv-Aktiv-Zustand verwenden, indem Sie die Spoke-VNets auf die Hubs verteilen. In der Topologie durchläuft Datenverkehr zwischen der lokalen Umgebung und einem Spoke-VNet standardmäßig direkt den virtuellen Hub, mit dem das Spoke-VNet während des stabilen Zustands verbunden ist. Ein anderer virtueller Hub wird nur während eines Fehlerzustands als Ausweichlösung verwendet. Im stabilen Zustand durchläuft Datenverkehr den direkt verbundenen Hub, da die vom direkt verbundenen Hub angekündigten BGP-Routen verglichen mit dem Ausweichhub einen kürzeren AS-Pfad aufweisen.

Die Topologie mit mehreren Hubs und Verbindungen bietet Schutz und Geschäftskontinuität für die meisten Ausfallszenarien. Sollte jedoch aufgrund einer Katastrophe die gesamte Azure-Region ausfallen, ist zur Absicherung eine Topologie mit mehreren Regionen und Verbindungen erforderlich.

Eine Topologie mit mehreren Regionen und Verbindungen bietet neben dem Schutz der zuvor erläuterten Topologie mit mehreren Hubs und Verbindungen auch Schutz vor einem katastrophenbedingten Ausfall einer gesamten Region. Das folgende Diagramm zeigt die Topologie mit mehreren Regionen und Verbindungen: Die virtuellen Hubs in unterschiedlichen Regionen können unter derselben Virtual WAN-Instanz konfiguriert werden.

Abbildung: Site-to-Site-VPN-Verbindungen mit mehreren Regionen mit einem Zweigstellenstandort.

Hinsichtlich des Datenverkehrs gibt es einen wesentlichen Unterschied zwischen redundanten Hubs innerhalb einer Region und einem Ausweichhub in einer anderen Region: die Wartezeit, die sich durch die physische Entfernung zwischen der primären und sekundären Region ergibt. Daher empfiehlt es sich, die Dienstressourcen im stabilen Zustand in der Region bereitstellen, die Ihrer Zweigstelle/Ihren Endbenutzern am nächsten ist, und die weiter entfernte Region nur als Ausweichregion zu verwenden.

Wenn Ihre lokalen Zweigstellen über zwei oder mehr Azure-Regionen verteilt sind, kann die Topologie mit mehreren Regionen und Verbindungen die Last im stabilen Zustand effektiver verteilen und die Netzwerkleistung verbessern. Das folgende Diagramm zeigt die Topologie mit mehreren Regionen und Verbindungen mit Zweigstellen in verschiedenen Regionen. In einem solchen Szenario bietet die Topologie zudem effektive Geschäftskontinuität und Notfallwiederherstellung (Business Continuity & Disaster Recovery, BCDR).

Abbildung: Site-to-Site-VPN-Verbindungen mit mehreren Branches mit einem Zweigstellenstandort.

Überlegungen zu ExpressRoute

Überlegungen zur Notfallwiederherstellung im Zusammenhang mit privatem ExpressRoute-Peering finden Sie im Artikel „Entwurf für die Notfallwiederherstellung mit privatem ExpressRoute-Peering“ unter Überlegungen zu kleinen bis mittelgroßen lokalen Netzwerken. Wie in dem Artikel erwähnt, gelten die in diesem Artikel beschriebenen Konzepte auch für ExpressRoute-Gateways, die in einem virtuellen Hub erstellt werden. Die Verwendung eines redundanten virtuellen Hubs innerhalb der Region (wie im folgenden Diagramm dargestellt) ist die einzige empfohlene Topologieerweiterung für kleine bis mittelgroße lokale Netzwerke.

Abbildung: ExpressRoute-Konnektivität mit mehreren Hubs.

Im obigen Diagramm endet „ExpressRoute 2“ in einem separaten ExpressRoute-Gateway innerhalb eines zweiten virtuellen Hubs innerhalb der Region.

Nächste Schritte

In diesem Artikel wurde der Notfallwiederherstellungsentwurf für Virtual WAN behandelt. Die folgenden Artikel behandeln Notfallwiederherstellung aus Anwendungs- und Front-End-Zugriffsperspektiven:

Informationen zum Einrichten von Point-to-Site-Konnektivität mit Virtual WAN finden Sie unter Tutorial: Erstellen einer Benutzer-VPN-Verbindung per Azure Virtual WAN. Informationen zum Einrichten von Site-to-Site-Konnektivität mit Virtual WAN finden Sie unter Tutorial: Erstellen einer Benutzer-VPN-Verbindung per Azure Virtual WAN. Informationen zum Zuordnen einer ExpressRoute-Leitung zu Virtual WAN finden Sie unter Tutorial: Erstellen einer ExpressRoute-Zuordnung mithilfe von Azure Virtual WAN.