Hub-Spoke-Netzwerk-Topologie in Azure

Diese Referenzarchitektur beschreibt eine Hub-Spoke-Topologie in Azure. Das virtuelle Hub-Netzwerk fungiert als zentraler Punkt für die Konnektivität zu vielen virtuellen Spoke-Netzwerken. Der Hub kann auch als Konnektivitätspunkt für Ihre lokalen Netzwerke verwendet werden. Die virtuellen Spoke-Netzwerke sind mit dem Hub verbunden und können zur Isolierung von Workloads verwendet werden.

Zu den Vorteilen einer Hub-and-Spoke-Konfiguration gehören Kosteneinsparungen, die Überwindung von Abonnementbeschränkungen und die Isolierung von Workloads.

Referenzbereitstellung

Diese Bereitstellung umfasst ein virtuelles Hub-Netzwerk und zwei Spokes mit Peering. Eine Azure Firewall und ein Azure Bastion-Host werden ebenfalls bereitgestellt. Optional kann die Bereitstellung virtuelle Maschinen im ersten Spoke-Netzwerk und ein VPN-Gateway umfassen.

az group create --name hub-spoke --location eastus

az deployment group create --resource-group hub-spoke \ --template-uri https://raw.githubusercontent.com/mspnp/samples/master/solutions/azure-hub-spoke/azuredeploy.json

New-AzResourceGroup -Name hub-spoke -Location eastus

New-AzResourceGroupDeployment -ResourceGroupName hub-spoke ` -TemplateUri https://raw.githubusercontent.com/mspnp/samples/master/solutions/azure-hub-spoke/azuredeploy.json

Detaillierte Informationen und zusätzliche Bereitstellungsoptionen finden Sie in den ARM-Vorlagen, die für die Bereitstellung dieser Lösung verwendet werden.

Verwendungszwecke

Typische Verwendungszwecke für diese Architektur sind:

• Workloads, die in verschiedenen Umgebungen wie Entwicklung, Tests und Produktion bereitgestellt werden und gemeinsame Dienste wie DNS, IDS, NTP oder AD DS erfordern. Gemeinsam genutzte Dienste werden im virtuellen Netzwerk des Hubs platziert, während jede Umgebung in einem Spoke bereitgestellt wird, um die Isolierung aufrechtzuerhalten.
• Workloads, die keine Konnektivität zueinander benötigen, aber Zugriff auf gemeinsam genutzte Dienste benötigen.
• Unternehmen, die eine zentrale Kontrolle über Sicherheitsaspekte benötigen, z. B. eine Firewall im Hub als DMZ, und eine getrennte Verwaltung für die Workloads in den einzelnen Spokes.

Architektur

Die Architektur besteht aus den folgenden Komponenten.

Hub virtual network: Das virtuelle Hub-Netzwerk ist der zentrale Punkt für die Konnektivität zu Ihrem lokalen Netzwerk und ein Ort, an dem Dienste gehostet werden, die von den verschiedenen Workloads in den virtuellen Spoke-Netzwerken genutzt werden können.

Virtuelle Spoke-Netzwerke: Virtuelle Speichen-Netzwerke werden verwendet, um Workloads in ihren eigenen virtuellen Netzwerken zu isolieren, die getrennt von anderen Speichen verwaltet werden. Jeder Workload kann mehrere Ebenen mit mehreren Subnetzen umfassen, die über Azure Load Balancer verbunden sind.

Virtuelles Netzwerk-Peering: Zwei virtuelle Netzwerke können über eine Peering-Verbindung verbunden werden. Peering-Verbindungen sind nicht-transitive Verbindungen mit geringer Latenz zwischen virtuellen Netzwerken. Nach dem Peering tauschen die virtuellen Netzwerke den Datenverkehr über das Azure-Backbone aus, ohne dass ein Router erforderlich ist.

Bastion Host: Mit Azure Bastion können Sie sich über Ihren Browser und das Azure-Portal sicher mit einer virtuellen Maschine verbinden. Ein Azure Bastion-Host wird innerhalb eines Azure Virtual Network bereitgestellt und kann auf virtuelle Maschinen im VNet oder auf virtuelle Maschinen in gepeerten VNets zugreifen.

Azure Firewall: Azure Firewall ist eine verwaltete Firewall als Dienst. Die Firewall-Instanz befindet sich in einem eigenen Subnetz.

VPN-Gateway für virtuelle Netzwerke oder ExpressRoute-Gateway. Das virtuelle Netzwerk-Gateway ermöglicht die Verbindung des virtuellen Netzwerks mit dem VPN-Gerät oder der ExpressRoute-Schaltung, die für die Konnektivität mit Ihrem lokalen Netzwerk verwendet wird. Weitere Informationen finden Sie unter Verbinden eines lokalen Netzwerks mit einem virtuellen Microsoft Azure-Netzwerk.

VPN-Gerät. Ein Gerät oder Dienst, der externe Konnektivität mit dem lokalen Netzwerk bereitstellt. Das VPN-Gerät kann ein Hardwaregerät oder eine Softwarelösung wie der Routing- und Remotezugriffsdienst (RRAS) in Windows Server 2012 sein. Weitere Informationen finden Sie unter Über VPN-Geräte für Site-to-Site-VPN-Gateway-Verbindungen.

Empfehlungen

Die folgenden Empfehlungen gelten für die meisten Szenarien. Befolgen Sie diese Empfehlungen, es sei denn, Sie haben eine spezielle Anforderung, die sie außer Kraft setzt.

Ressourcengruppen

Die in diesem Dokument enthaltene Beispiellösung verwendet eine einzelne Azure-Ressourcengruppe. In der Praxis können der Hub und jede Speiche in verschiedenen Ressourcengruppen und sogar in verschiedenen Abonnements implementiert werden. Wenn Sie virtuelle Netzwerke in verschiedenen Abonnements gruppieren, können beide Abonnements mit demselben oder einem anderen Azure Active Directory-Mandanten verknüpft werden. Dies ermöglicht eine dezentrale Verwaltung der einzelnen Workloads bei gleichzeitiger gemeinsamer Nutzung von Diensten, die im Hub verwaltet werden.

Virtuelles Netzwerk und GatewaySubnet

Erstellen Sie ein Subnetz namens GatewaySubnet mit einem Adressbereich von /27. Das virtuelle Netzwerk-Gateway benötigt dieses Subnetz. Wenn Sie diesem Subnetz 32 Adressen zuweisen, können Sie verhindern, dass Sie in Zukunft an die Größenbeschränkungen für Gateways stoßen.

Weitere Informationen zum Einrichten des Gateways finden Sie je nach Verbindungstyp in den folgenden Referenzarchitekturen:

• Hybridnetzwerk mit ExpressRoute
• Hybridnetzwerk mit einem VPN-Gateway

Für eine höhere Verfügbarkeit können Sie ExpressRoute plus ein VPN für die Ausfallsicherung verwenden. Siehe Verbinden eines lokalen Netzwerks mit Azure unter Verwendung von ExpressRoute mit VPN-Failover.

Eine Hub-Spoke-Topologie kann auch ohne ein Gateway verwendet werden, wenn Sie keine Konnektivität mit Ihrem lokalen Netzwerk benötigen.

Virtuelles Netzwerk-Peering

Virtuelles Netzwerk-Peering ist eine nicht-transitive Beziehung zwischen zwei virtuellen Netzwerken. Wenn Sie eine Verbindung zwischen den Speichen benötigen, sollten Sie eine separate Peering-Verbindung zwischen diesen Speichen einrichten.

Angenommen, Sie haben mehrere Speichen, die miteinander verbunden werden müssen. In diesem Fall gehen Ihnen die möglichen Peering-Verbindungen sehr schnell aus, da die Anzahl der virtuellen Netzwerk-Peerings pro virtuellem Netzwerk begrenzt ist. (Weitere Informationen finden Sie unter Netzwerkgrenzen. Ziehen Sie in diesem Szenario die Verwendung von benutzerdefinierten Routen (UDRs) in Betracht, um zu erzwingen, dass der für einen Spoke bestimmte Datenverkehr an Azure Firewall oder eine virtuelle Netzwerk-Appliance gesendet wird, die als Router am Hub fungiert. Auf diese Weise können die Speichen miteinander verbunden werden.

Sie können Speichen auch so konfigurieren, dass sie das Hub-Gateway für die Kommunikation mit Remote-Netzwerken verwenden. Damit der Gateway-Verkehr von der Speiche zum Hub fließen und eine Verbindung zu entfernten Netzwerken herstellen kann, müssen Sie:

• die Peering-Verbindung im Hub so konfigurieren, dass der Gateway-Transit zugelassen wird.
• die Peering-Verbindung in jeder Speiche so konfigurieren, dass entfernte Gateways verwendet werden.
• alle Peering-Verbindungen so konfigurieren, dass weitergeleiteter Verkehr zugelassen wird.

Weitere Informationen zum Erstellen von virtuellen Netzwerk-Peerings finden Sie unter Erstellen von VNet-Peerings.

Spoke-Konnektivität

Wenn Sie Konnektivität zwischen Speichen benötigen, sollten Sie die Bereitstellung einer Azure Firewall oder einer anderen virtuellen Netzwerk-Appliance in Betracht ziehen und Routen erstellen, um den Datenverkehr von der Speiche an die Firewall/virtuelle Netzwerk-Appliance weiterzuleiten, die dann an die zweite Speiche weiterleiten kann. In diesem Szenario müssen Sie die Peering-Verbindungen so konfigurieren, dass sie die Weiterleitung des Datenverkehrs zulassen.

Sie können auch ein VPN-Gateway verwenden, um den Datenverkehr zwischen den Speichen zu leiten, obwohl dies Auswirkungen auf die Latenz und den Durchsatz hat. Einzelheiten zur Konfiguration finden Sie unter Konfigurieren des VPN-Gateway-Transits für virtuelles Netzwerk-Peering.

Überlegen Sie, welche Services im Hub gemeinsam genutzt werden, um sicherzustellen, dass der Hub für eine größere Anzahl von Speichen skaliert. Wenn Ihr Hub beispielsweise Firewall-Services anbietet, sollten Sie beim Hinzufügen mehrerer Speichen die Bandbreitenbeschränkungen Ihrer Firewall-Lösung berücksichtigen. Möglicherweise möchten Sie einige dieser gemeinsam genutzten Dienste auf eine zweite Ebene von Hubs verschieben.

Betriebliche Überlegungen

Beachten Sie bei der Bereitstellung und Verwaltung von Hub- und Spoke-Netzwerken Folgendes.

Netzwerküberwachung

Nutzen Sie Azure Network Watcher, um die Netzwerkkomponenten zu überwachen und Fehler zu beheben. Tools wie Traffic Analytics zeigen Ihnen die Systeme in Ihren virtuellen Netzwerken, die den meisten Datenverkehr erzeugen, sodass Sie Engpässe visuell erkennen können, bevor sie zu Problemen ausarten. Der Network Performance Manager ist das richtige Tool, um Informationen über Microsoft ExpressRoute-Schaltungen zu überwachen. Die VPN-Diagnose ist ein weiteres Tool, das bei der Fehlerbehebung von Site-to-Site-VPN-Verbindungen helfen kann, die Ihre Anwendungen mit Benutzern vor Ort verbinden.

Weitere Informationen finden Sie unter Azure Network Watcher im Azure Well-Architected Framework.

Kostenüberlegungen

Berücksichtigen Sie bei der Bereitstellung und Verwaltung von Hub- und Spoke-Netzwerken die folgenden kostenbezogenen Elemente.

Azure Firewall

In dieser Architektur wird eine Azure Firewall im Hub-Netzwerk bereitgestellt. Wenn sie als gemeinsam genutzte Lösung eingesetzt und von mehreren Workloads genutzt wird, kann eine Azure Firewall im Vergleich zu anderen virtuellen Netzwerk-Appliances bis zu 30-50 % einsparen. Weitere Informationen finden Sie unter Azure Firewall vs. virtuelle Netzwerk-Appliance.

Virtuelles Netzwerk-Peering

Sie können virtuelles Netzwerk-Peering verwenden, um den Datenverkehr zwischen virtuellen Netzwerken unter Verwendung privater IP-Adressen zu routen. Hier sind einige Punkte:

• Eingangs- und Ausgangsverkehr wird an beiden Enden der gepeerten Netzwerke berechnet.
• Unterschiedliche Zonen haben unterschiedliche Übertragungsraten.

Beim Datentransfer von einem virtuellen Netzwerk in Zone 1 zu einem anderen virtuellen Netzwerk in Zone 2 fallen beispielsweise die Übertragungsraten für ausgehende Verbindungen in Zone 1 und für eingehende Verbindungen in Zone 2 an. Weitere Informationen finden Sie unter Preise für virtuelle Netzwerke.