Spoke-to-Spoke Netzwerke

Bei den gängigsten Netzwerkdesignmustern in Azure werden virtuelle Hub-and-Spoke-Netzwerktopologien in einer oder mehreren Azure-Regionen erstellt, die optional über Azure ExpressRoute oder Site-to-Site-VPN-Tunnel (Virtual Private Network) über das öffentliche Internet mit lokalen Netzwerken verbunden sind.

Die meisten Entwurfsleitfäden konzentrieren sich auf den Datenverkehr von Anwendungen in diesen virtuellen Netzwerken, die von Benutzern in internen, lokalen Netzwerken oder aus dem Internet stammen (was in der Branche typischerweise als Nord-Süd-Datenverkehr bezeichnet wird, da er in Netzwerkdiagrammen häufig durch vertikale Linien dargestellt wird). Dieser Artikel befasst sich mit verschiedenen Mustern, die für den Datenverkehr in Ost-West-Richtung verfügbar sind. Das heißt, die Kommunikation fließt zwischen Workloads, die in virtuellen Azure-Netzwerken bereitgestellt werden, entweder innerhalb einer Region oder in verschiedenen Regionen.

Um die Leistung, Skalierbarkeit und Ausfallsicherheit Ihrer Anwendungen, die in Azure ausgeführt werden, zu gewährleisten, müssen Sie sicherstellen, dass Ihr Netzwerk die Anforderungen für den Datenverkehr von Ost nach West erfüllt.

Mögliche Anwendungsfälle

Der Spoke-to-Spoke-Datenverkehr kann in verschiedenen Szenarien wichtig sein:

• Verschiedene Ebenen einer Anwendung befinden sich in separaten virtuellen Netzwerken. Beispielsweise kommunizieren Umkreisnetzwerkserver (auch DMZ-Server genannt) in einem virtuellen Umkreisnetzwerk mit Anwendungsdiensten in einem internen virtuellen Netzwerk.
• Anwendungsworkloads in verschiedenen Umgebungen (Entwicklung, Staging, Produktion) müssen Daten untereinander replizieren.
• Verschiedene Anwendungen oder Microservices müssen miteinander kommunizieren.
• Datenbanken müssen Daten überregional replizieren, um die Geschäftskontinuität im Falle eines Notfalls zu gewährleisten.
• Die Benutzer befinden sich in den virtuellen Azure-Netzwerken. Sie verwenden z. B. Azure Virtual Desktop.

Muster und Topologien für die Inter-Spoke-Kommunikation

Es gibt zwei Haupttopologien, die Sie in Azure-Entwürfen verwenden können, die mehrere virtuelle Netzwerke umfassen: traditionelles Hub-and-Spoke und Azure Virtual WAN. In einer Virtual WAN-Umgebung verwaltet Microsoft das virtuelle Hubnetzwerk und sämtliche Inhalte. In einer traditionellen Hub-and-Spoke-Umgebung verwalten Sie das virtuelle Hubnetzwerk.

Virtual WAN- und Hub-and-Spoke-Topologien sind beides Beispiele für Architekturen, bei denen die Workloads in virtuellen Spoke-Netzwerken ausgeführt werden und die Konnektivität zu lokalen Standorten in einem virtuellen Hubnetzwerk zentralisiert ist. Viele der in diesem Artikel erläuterten Konzepte gelten daher sowohl für Hub-and-Spoke- als auch für Virtual WAN-Entwürfe.

Es gibt zwei Hauptmuster für die Verbindung von virtuellen Spoke-Netzwerken untereinander:

• Direkt miteinander verbundene Spoke-Instanzen. Peerings virtueller Netzwerke oder VPN-Tunnel werden zwischen den virtuellen Spoke-Netzwerken erstellt, um eine direkte Konnektivität zu ermöglichen, ohne das virtuelle Hubnetzwerk zu durchqueren.
• Spokes kommunizieren über ein Netzwerkgerät. Jedes virtuelle Spoke-Netzwerk verfügt über ein Peering zum Virtual WAN oder zu einem virtuellen Hubnetzwerk. Eine Appliance leitet den Datenverkehr von Spoke zu Spoke weiter. Die Appliance kann von Microsoft (wie bei Virtual WAN) oder von Ihnen selbst verwaltet werden.

Muster 1: Direkt miteinander verbundene Spoke-Instanzen.

Direkte Verbindungen zwischen Spokes bieten in der Regel einen besseren Durchsatz, eine kürzere Wartezeit und eine bessere Skalierbarkeit als Verbindungen, die über ein virtuelles Netzwerkgerät (NVA) über einen Hub verlaufen. Das Senden von Datenverkehr über NVAs kann zu zusätzlichen Wartezeiten führen, wenn die NVAs in einer anderen Verfügbarkeitszone liegen und mindestens zwei Peerings virtueller Netzwerke durchlaufen werden müssen, wenn der Datenverkehr über den Hub gesendet wird. Es gibt mehrere Möglichkeiten, zwei virtuelle Spoke-Netzwerke direkt miteinander zu verbinden: Peering virtueller Netzwerke, Azure Virtual Network Manager und VPN-Tunnel.

• Peering virtueller Netzwerke. Die Vorteile von direkten Peerings virtueller Netzwerke gegenüber Spokes sind:

  • Geringere Kosten, da weniger Hops für das Peering virtueller Netzwerke erforderlich sind.
  • Bessere Leistung, da der Datenverkehr kein Netzwerkgerät durchlaufen muss, das Wartezeiten oder potenzielle Engpässe verursacht.

  Andere Szenarien umfassen mandantenübergreifende Konnektivität. Es kann jedoch sein, dass Sie den Datenverkehr zwischen virtuellen Spoke-Netzwerken überprüfen müssen, was es erforderlich machen könnte, den Datenverkehr über zentralisierte Netzwerkgeräte im virtuellen Hubnetzwerk zu leiten.

• Azure Virtual Network Manager. Zusätzlich zu den Vorteilen, die das Peering virtueller Netzwerke bietet, stellt Azure Virtual Network Manager einen Dienst zur Verfügung, mit dem Sie virtuelle Netzwerkumgebungen verwalten und Netzwerkkonnektivität im großem Stil erstellen können. Mithilfe von Azure Virtual Network Manager können Sie drei Arten von Topologien über Abonnements hinweg erstellen, sowohl für bestehende als auch für neue virtuelle Netzwerke:

  • Hub-and-Spoke mit Spokes, die nicht miteinander verbunden sind.

  • Hub-and-Spoke mit Spokes, die direkt miteinander verbunden sind, ohne Hop in der Mitte.

  • Eine vermaschte Gruppe von virtuellen Netzwerken, die miteinander verbunden sind.

    

    Laden Sie alle Visio-Diagramme in diesem Artikel herunter.

    Wenn Sie mit Azure Virtual Network Manager eine Hub-and-Spoke-Topologie erstellen, in der Spokes miteinander verbunden sind, wird automatisch eine direkte bidirektionale Konnektivität zwischen virtuellen Spoke-Netzwerken in derselben Netzwerkgruppe erstellt. Mithilfe von Azure Virtual Network Manager können Sie virtuelle Spoke-Netzwerke statisch oder dynamisch zu Mitgliedern einer bestimmten Netzwerkgruppe machen, die automatisch die Konnektivität für ein beliebiges virtuelles Netzwerk erstellt.

    Sie können mehrere Netzwerkgruppen erstellen, um Cluster von virtuellen Spoke-Netzwerken von der direkten Konnektivität zu isolieren. Jede Netzwerkgruppe bietet dieselbe Region und die Unterstützung mehrerer Regionen für Spoke-to-Spoke-Konnektivität. Achten Sie darauf, dass Sie die Höchstgrenzen für Azure Virtual Network Manager, die in den Häufig gestellten Fragen zu Azure Virtual Network Manager beschrieben sind, nicht überschreiten.

• VPN-Tunnel, die virtuelle Netzwerke verbinden. Sie können VPN-Dienste konfigurieren, um virtuelle Spoke-Netzwerke direkt zu verbinden, indem Sie Microsoft VPN-Gateways oder VPN-NVAs von Drittanbietern verwenden. Der Vorteil dieser Option ist, dass virtuelle Spoke-Netzwerke über kommerzielle und Sovereign Clouds innerhalb desselben Cloudanbieters oder über cloudanbieterübergreifende Konnektivität verbunden sind. Wenn in jedem virtuellen Spoke-Netzwerk softwaredefinierte Wide Area Network-NVAs (SD-WAN) vorhanden sind, kann diese Konfiguration außerdem die Verwendung der Steuerungsebene und der Featuregruppe des Drittanbieters zur Verwaltung der virtuellen Netzwerkkonnektivität erleichtern.

  Mit dieser Option können Sie auch die Complianceanforderungen für die Verschlüsselung des Datenverkehrs über virtuelle Netzwerke in einem einzelnen Azure-Rechenzentrum erfüllen, die nicht bereits durch die MACsec-Verschlüsselung bereitgestellt werden. Diese Option bringt jedoch aufgrund der Bandbreitenbegrenzungen von IPsec-Tunneln (1,25 Gbit/s pro Tunnel) und der Entwurfseinschränkungen, dass VNET-Gateways sowohl in virtuellen Hub- als auch Spoke-Netzwerken vorhanden sein müssen, eine Reihe von Herausforderungen mit sich: Wenn das virtuelle Spoke-Netzwerk über ein VNET-Gateway verfügt, kann es nicht mit der Virtual WAN-Instanz verbunden werden oder das VNET-Gateway eines Hubs verwenden, um die Verbindung mit lokalen Netzwerken herzustellen.

Muster 1: Einzelne Region

Unabhängig von der Technologie, die Sie verwenden, um virtuelle Spoke-Netzwerke miteinander zu verbinden, würden die Netzwerktopologien für eine einzelne Region wie folgt aussehen:

Muster 1: Mehrere Regionen

Entwürfe, die alle virtuellen Spoke-Netzwerke miteinander verbinden, können auch auf mehrere Regionen ausgeweitet werden. In dieser Topologie ist Azure Virtual Network Manager sogar noch wichtiger, um den Verwaltungsaufwand für die Pflege der erforderlichen großen Anzahl von Verbindungen zu reduzieren.

Wenn Sie virtuelle Spoke-Netzwerke in einer vollständig vermaschten Topologie direkt miteinander verbinden, müssen Sie die potenziell hohe Anzahl der erforderlichen Peerings virtueller Netzwerke berücksichtigen. Das folgende Diagramm veranschaulicht dieses Problem. In diesem Szenario wird Azure Virtual Network Manager dringend empfohlen, sodass Sie automatisch virtuelle Netzwerkverbindungen erstellen können.

Muster 2: Spoke-Kommunikation über ein Netzwerkgerät

Anstatt virtuelle Spoke-Netzwerke direkt miteinander zu verbinden, können Sie Netzwerkgeräte zur Weiterleitung des Datenverkehrs zwischen Spokes verwenden. Netzwerkgeräte bieten zusätzliche Dienste im Netzwerk wie eingehende Paketuntersuchung und Segmentierung oder Überwachung des Datenverkehrs, können aber Wartezeiten und Leistungsengpässe verursachen, wenn sie nicht richtig dimensioniert sind. Diese Geräte befinden sich in der Regel in einem virtuellen Hubnetzwerk, mit dem die Spokes verbunden sind. Es gibt mehrere Möglichkeiten, ein Netzwerkgerät zur Weiterleitung des Datenverkehrs zwischen Spokes zu verwenden:

• Virtual WAN-Hubrouter. Virtual WAN, das vollständig von Microsoft verwaltet wird, enthält einen virtuellen Router, der den Datenverkehr von Spokes aufnimmt und ihn entweder an ein anderes virtuelles Netzwerk weiterleitet, das mit Virtual WAN verbunden ist, oder an lokale Netzwerke über ExpressRoute oder Site-to-Site- oder Point-to-Site-VPN-Tunnel. Der Virtual WAN-Router skaliert automatisch hoch oder herunter, sodass Sie nur dafür sorgen müssen, dass der Datenverkehr zwischen den Spokes innerhalb der Virtual WAN-Grenzwerte bleibt.

• Azure Firewall.Azure Firewall ist ein von Microsoft verwaltetes Netzwerkgerät, das in von Ihnen verwalteten virtuellen Hubnetzwerken oder in Virtual WAN-Hubs bereitgestellt werden kann. Es kann IP-Pakete weiterleiten, sie untersuchen und Regeln zur Segmentierung des Datenverkehrs anwenden, die in Richtlinien definiert sind. Es bietet eine automatische Skalierung bis zu den Grenzen von Azure Firewall, sodass sie nicht zum Engpass wird. Beachten Sie, dass Azure Firewall nur bei Verwendung von Virtual WAN sofortige Funktionen für mehrere Regionen bietet. Ohne Virtual WAN müssen Sie benutzerdefinierte Routen implementieren, um eine regionsübergreifende Spoke-to-Spoke-Kommunikation zu erreichen.

• Virtuelle Netzwerkgeräte von Drittanbietern. Wenn Sie es vorziehen, ein virtuelles Gerät eines Microsoft-Partners für das Routing und die Segmentierung des Netzwerks zu verwenden, können Sie virtuelle Netzwerkgeräte entweder in einer Hub-and-Spoke- oder einer Virtual WAN-Topologie bereitstellen. Weitere Informationen finden Sie unter Bereitstellen von hochgradig verfügbaren NVAs oder NVAs in einem Virtual WAN-Hub. Sie müssen sicher sein, dass das virtuelle Netzwerkgerät die Bandbreite unterstützt, die von der Inter-Spoke-Kommunikation generiert wird.

• Azure VPN-Gateway. Sie können ein Azure VPN-Gateway als nächsten Hoptyp einer benutzerdefinierten Route verwenden, aber Microsoft empfiehlt nicht, virtuelle VPN-Netzwerkgateways zum Routen von Spoke-to-Spoke-Datenverkehr zu verwenden. Sie sind für die Verschlüsselung des Datenverkehrs zu lokalen Standorten oder VPN-Benutzern gedacht. Es gibt z. B. keine Garantie für die Bandbreite zwischen Spokes, die ein VPN-Gateway weiterleiten kann.

• ExpressRoute. In bestimmten Konfigurationen kann ein ExpressRoute-Gateway Routen ankündigen, die eine Spoke-to-Spoke-Kommunikation anziehen und den Datenverkehr an den Microsoft Edge-Router senden, wo er an den Zielspoke weitergeleitet wird. Microsoft rät dringend von diesem Szenario ab, da es zu Wartezeiten führt, da der Datenverkehr zum Microsoft-Backbone-Edge und zurück gesendet wird. Darüber hinaus empfiehlt Microsoft diesen Ansatz aufgrund des Single Point of Failure und des hohen Auswirkungsgrads nicht. Dieses Szenario bringt auch mehrere Probleme mit sich, da es die ExpressRoute-Infrastruktur (das Gateway und die physischen Router) zusätzlich belastet. Dieser zusätzliche Druck kann zu Paketverlusten führen.

In Hub-and-Spoke-Netzwerken mit zentralisierten NVAs befindet sich das Gerät normalerweise im Hub. Peerings virtueller Netzwerke zwischen virtuellen Hub-and-Spoke-Netzwerken müssen manuell oder automatisch mit Azure Virtual Network Manager erstellt werden:

• Manuelle Peerings virtueller Netzwerke. Dieser Ansatz ist ausreichend, wenn Sie über eine geringe Anzahl von virtuellen Spoke-Netzwerken verfügen, aber er erzeugt einen Verwaltungsmehraufwand im großen Stil.

• Azure Virtual Network Manager. Wie bereits erwähnt, bietet Azure Virtual Network Manager Features zur Verwaltung virtueller Netzwerkumgebungen und Peerings im großen Stil. Peeringkonfigurationen zwischen virtuellen Hub-and-Spoke-Netzwerken werden automatisch bidirektional für Netzwerkgruppen konfiguriert.

  Azure Virtual Network Manager bietet die Möglichkeit, Mitgliedschaften in virtuellen Spoke-Netzwerken statisch oder dynamisch zu einer bestimmten Netzwerkgruppe hinzuzufügen, die automatisch die Peeringverbindung für neue Mitglieder erstellt. Virtuelle Spoke-Netzwerke in Netzwerkgruppen können die Hub-VPN- oder ExpressRoute-Gateways für die Konnektivität verwenden. Achten Sie darauf, dass Sie die Höchstgrenzen für Azure Virtual Network Manager nicht überschreiten.

Muster 2: Einzelne Region

Das folgende Diagramm zeigt eine Hub-and-Spoke-Topologie für eine einzelne Region, bei der der Datenverkehr zwischen den Spokes durch eine Azure-Firewall geleitet wird, die im virtuellen Hubnetzwerk bereitgestellt wird. Der Datenverkehr wird über benutzerdefinierte Routen, die auf die Spoke-Subnetze angewendet werden, an das zentrale Gerät im Hub weitergeleitet.

Unter bestimmten Umständen kann es aus Gründen der Skalierbarkeit von Vorteil sein, die virtuellen Geräte für das Netzwerk, die den Spoke-to-Spoke- und den Internetdatenverkehr abwickeln, zu trennen. Sie können diese Trennung erreichen, indem Sie wie folgt vorgehen:

• Die Optimierung der Routingtabellen in den Spokes, um private Adressen (die über eine Route für RFC 1918-Präfixe verfügen) an eine NVA zu senden, die für den Datenverkehr zwischen Azure-zu-Azure sowie zwischen Azure und lokalen Standorten zuständig ist (auch als Ost-West-Datenverkehr).
• Die Optimierung des Datenverkehrs aus dem Internet (der die Route 0.0.0.0/0 aufweist) zu einer zweiten NVA. Diese NVA ist für den Datenverkehr zwischen Azure und dem Internet zuständig (auch als Nord-Süd-Datenverkehr bezeichnet).

Auf der folgenden Abbildung wird diese Konfiguration veranschaulicht:

Muster 2: Mehrere Regionen

Sie können dieselbe Konfiguration auf mehrere Regionen erweitern. Beispielsweise sollten Sie in einem Hub-and-Spoke-Entwurf, der Azure Firewall verwendet, zusätzliche Routingtabellen für die Subnetze der Azure Firewall in jedem Hub für die Spokes in der Remoteregion anwenden. Diese Konfiguration stellt sicher, dass der Datenverkehr zwischen den Azure-Firewalls in jedem virtuellen Hubnetzwerk weitergeleitet werden kann. Der regionsübergreifende Datenverkehr zwischen virtuellen Spoke-Netzwerken durchläuft dann beide Azure-Firewalls. Weitere Informationen finden Sie unter Azure Firewall zum Weiterleiten einer Multi-Hub-and-Spoke-Topologie:

Die Entwurfsvariante mit separaten Azure-Firewalls oder virtuellen Netzwerkgeräten für den Nord-Süd- und Ost-West-Datenverkehr ist auch in einer Hub-and-Spoke-Topologie für mehrere Regionen möglich:

Virtual WAN erstellt eine ähnliche Topologie und übernimmt die Routingkomplexität. Dies gilt sowohl für die Hubs (die von Microsoft verwaltet werden) als auch für die Spokes (wo Routen eingeschleust werden können und nicht manuell in Routingtabellen definiert werden müssen). So muss der Netzwerkadministrator nur die virtuellen Spoke-Netzwerke mit einem virtuellen WAN-Hub verbinden und sich nicht um die Weiterleitung des Datenverkehrs zwischen den Regionen kümmern.

Hybridmuster

Viele Situationen erfordern einen Hybridansatz, der die beiden zuvor beschriebenen Muster kombiniert. Bei diesem Ansatz muss der Datenverkehr zwischen bestimmten Spokes über direkte Verbindungen abgewickelt werden, während der Rest der Spokes über ein zentrales Netzwerkgerät kommuniziert. Beispielsweise können Sie in einer virtuellen WAN-Umgebung zwei bestimmte Spokes, die eine hohe Bandbreite und eine geringe Wartezeit erfordern, direkt miteinander verbinden. Ein anderes Szenario betrifft virtuelle Spoke-Netzwerke, die Teil einer einzelnen Umgebung sind. Sie können z. B. zulassen, dass ein virtuelles Spoke-Entwicklungsnetzwerk direkt mit einem anderen virtuellen Spoke-Entwicklungsnetzwerk verbunden wird, aber die Workloads für Entwicklung und Produktion müssen über das zentrale Gerät kommunizieren.

Ein weiteres gängiges Muster besteht darin, Spokes in einer Region über direkte Peerings virtueller Netzwerke oder mit dem Azure Virtual Network Manager verbundene Gruppen zu verbinden, aber den Datenverkehr zwischen den Regionen über NVAs hinweg zuzulassen. Die Hauptmotivation für dieses Modell besteht in der Regel darin, die Anzahl der Peerings virtueller Netzwerke in der Architektur zu reduzieren. Im Vergleich zum ersten Modell (direkte Konnektivität zwischen Spokes) besteht ein Nachteil dieses Modells jedoch darin, dass es mehr Peering virtueller Netzwerke für den Datenverkehr zwischen den Regionen gibt. Diese Hops erhöhen die Kosten, da mehrere Peerings virtueller Netzwerke durchquert werden müssen. Ein weiterer Nachteil ist die zusätzliche Belastung der Hub-NVAs, um den gesamten regionsübergreifenden Datenverkehr zu ermöglichen.

Die gleichen Entwürfe sind auch für Virtual WAN anwendbar. Eine Überlegung ist jedoch, dass die direkte Konnektivität zwischen virtuellen Spoke-Netzwerken manuell direkt zwischen den virtuellen Netzwerken und nicht über die Virtual WAN-Ressource konfiguriert werden muss. Azure Virtual Network Manager unterstützt derzeit keine Architekturen, die auf Virtual WAN basieren. Beispiel:

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

• Jay Li | Senior Product Manager
• Jose Moreno | Principal Customer Engineer
• Alejandra Palacios | Senior Azure Infrastructure Customer Engineer

Andere Mitwirkende:

• Mick Alberts | Technical Writer
• Mohamed Hassan | Principal PM Manager
• Andrea Michael | Program Manager
• Yasukuni Morishima | Customer Engineer II
• Jithin PP| Customer Engineer

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

• Cloud Adoption Framework: Netzwerktopologie und Konnektivität der Zielzone
• Peering von virtuellen Netzwerken
• Azure Virtual Network Manager
• Virtual WAN
• Azure Firewall
• Sichere Netzwerkkonnektivität in Azure
• Einführung in virtuelle Azure-Netzwerke

Zugehörige Ressourcen

• Hub-Spoke-Netzwerktopologie in Azure
• Hub-Spoke-Netzwerktopologie mit Azure Virtual WAN
• Herkömmliche Azure-Netzwerktopologie