Hub-and-Spoke-Netzwerktopologie

Hub-and-Spoke ist ein Netzwerkmodell für die effiziente Verwaltung verbreiteter Kommunikations- oder Sicherheitsanforderungen. Es hilft auch dabei, Azure-Abonnementeinschränkungen zu vermeiden. Dieses Modell berücksichtigt die folgenden Punkte:

• Kosteneinsparungen und effiziente Verwaltung: Zentralisierung von Diensten, die von mehreren Workloads, z. B. Network Virtual Appliances (NVAs) und DNS-Servern, gemeinsam genutzt werden können. Somit kann die IT-Abteilung mit einem einzigen zentralen Ort für Dienste redundante Ressourcen und den Verwaltungsaufwand für mehrere Workloads minimieren.

• Überwindung der Abonnementgrenzen: Große cloudbasierte Workloads können den Einsatz von mehr Ressourcen erfordern, als in einem einzelnen Azure-Abonnement enthalten sind. Durch ein Peering virtueller Netzwerke für eine Workload aus verschiedenen Abonnements zu einem zentralen Hub können diese Grenzwerte umgangen werden. Weitere Informationen finden Sie unter Grenzwerte für Azure-Abonnements.

• Einrichten einer Trennung der Interessen: Sie können einzelne Workloads zwischen den zentralen IT-Teams und den für die Workloads zuständige Teams bereitstellen.

Kleinere Cloudumgebungen profitieren möglicherweise nicht von der zusätzlichen Struktur und den Funktionen, die dieses Modell bietet. Für größere Cloudeinführungsaktivitäten sollte jedoch die Implementierung einer Hub-and-Spoke-Architektur in Erwägung gezogen werden, wenn für sie bereits die oben aufgeführten Bedenken gelten.

Übersicht

Abbildung 1: Ein Beispiel für eine Hub-and-Spoke-Netzwerktopologie.

Wie in der Abbildung gezeigt, unterstützt Azure zwei Arten von Hub-and-Spoke-Entwürfen. Der erste Typ unterstützt Kommunikation, freigegebene Ressourcen und zentralisierte Sicherheitsrichtlinien. Dieser Typ wird im Diagramm als VNet-Hub bezeichnet. Der zweite Typ basiert auf Azure Virtual WAN und wird im Diagramm als Virtual WAN bezeichnet. Dieser Typ ist für umfangreiche Kommunikation zwischen Zweigstellen sowie zwischen Zweigstelle und Azure gedacht.

Ein Hub ist eine zentrale Netzwerkzone, die den ein- oder ausgehenden Datenverkehr zwischen Zonen steuert und überprüft: im Internet, lokal und in den Spokes. Die Hub-and-Spoke-Topologie stellt für Ihre IT-Abteilung eine effektive Möglichkeit zum Erzwingen von Sicherheitsrichtlinien an einem zentralen Ort dar. Außerdem verringert sie das Risiko von Fehlkonfigurationen und Offenlegungen.

Der Hub enthält oft die allgemeinen Dienstkomponenten, die von den Spokes genutzt werden. Beispiele für gängige zentrale Dienste sind:

• Ein DNS-Dienst, mit dem die Namen der Workloads in den Spokes aufgelöst werden, um lokal und über das Internet auf Ressourcen zuzugreifen, wenn Azure DNS nicht verwendet wird.
• Eine öffentlich Schlüssel-Infrastruktur implementiert einmaliges Anmelden für die Workloads.
• Der TCP- und UDP-Datenverkehr zwischen den Spoke-Netzwerkzonen und dem Internet wird gesteuert.
• Der Fluss zwischen den Spokes und dem lokalen Netzwerk wird gesteuert.
• Der Fluss wird bei Bedarf zwischen einem Spoke und einem anderen gesteuert.

Sie können Redundanzen minimieren, die Verwaltung vereinfachen und die Gesamtkosten senken, indem Sie die gemeinsame Hubinfrastruktur zur Unterstützung mehrerer Spokes nutzen.

Die Rolle eines jeden Spokes kann über verschiedene Arten von Workloads gehostet werden. Die Spokes können auch einen modularen Ansatz für wiederholbare Bereitstellungen der gleichen Workloads bieten. Beispiele hierfür sind Dev/Test, Benutzerakzeptanztests, Staging und Produktion.

Mit den Spokes können auch verschiedene Gruppen in Ihrer Organisation getrennt und aktiviert werden. Ein Beispiel hierfür sind Azure DevOps-Gruppen. Innerhalb eines Spokes ist es möglich, eine einfache Workload oder komplexe Workloads mit mehreren Ebenen mit einer Datenverkehrssteuerung zwischen den Ebenen bereitzustellen.

Das im obigen Diagramm gezeigte Application Gateway kann sich mit der Anwendung, die es versorgt, in einem Spoke befinden, um Verwaltung und Skalierung zu verbessern. Die Unternehmensrichtlinie könnte jedoch vorschreiben, dass Sie das Application Gateway im Hub platzieren, um die Verwaltung zu zentralisieren und Verantwortlichkeiten zu trennen.

Abonnementlimit und mehrere Hubs

In Azure wird jeder Komponententyp in einem Azure-Abonnement bereitgestellt. Die Isolation von Azure-Komponenten in verschiedenen Azure-Abonnements kann die Anforderungen verschiedener Branchenanwendungen erfüllen, z.B. das Einrichten unterschiedlicher Zugriffs- und Autorisierungsebenen.

Ein einzelne Hub-and-Spoke-Implementierung kann auf eine große Anzahl von Spokes hochskaliert werden, wobei aber wie bei jedem IT-System gewisse Plattformbeschränkungen gelten. Die Hub-Bereitstellung ist an ein bestimmtes Azure-Abonnement gebunden. Beispielsweise kann eine maximale Anzahl von Peerings in virtuellen Netzwerken gelten. Weitere Informationen finden Sie unter Einschränkungen für Azure-Abonnements und Dienste, Kontingente und Einschränkungen.

Wenn Grenzwerte ein Problem darstellen können, können Sie die Architektur hochskalieren, indem Sie das Modell auf einen Cluster von Hubs und Spokes erweitern. Sie können mit folgenden Methoden mehrere Hubs in einer oder mehreren Azure-Regionen miteinander verbinden:

• Peering in virtuellen Netzwerken
• Azure ExpressRoute
• Azure Virtual WAN
• Site-to-Site-VPN-Verbindung

Abbildung 2: Ein Cluster mit Hubs und Spokes

Die Einführung von mehreren Hubs erhöht die Kosten und den Verwaltungsaufwand für das System. Diese Erhöhung wird nur gerechtfertigt durch:

• Skalierbarkeit
• Systemgrenzwerte
• Redundanz und regionale Replikation für Benutzerleistung oder Notfallwiederherstellung

In Szenarien, die mehrere Hubs erfordern, sollten alle Hubs die gleichen Dienste anbieten, um die Vorgänge nicht zu erschweren.

Verbindung zwischen Spokes

Innerhalb eines einzelnen Spokes ist es möglich, komplexe Workloads mit mehreren Ebenen zu implementieren. Sie können Konfigurationen mit mehreren Ebenen implementieren, indem Sie Subnetze (eines für jede Ebene) im selben virtuellen Netzwerk verwenden und Netzwerksicherheitsgruppen einsetzen, um die Datenflüsse zu filtern.

Ein Architekt möchte vielleicht eine Workload mit mehreren Ebenen in mehreren virtuellen Netzwerken bereitstellen. Mittels Peering in virtuellen Netzwerken können Spokes Verbindungen mit anderen Spokes im gleichen Hub oder in anderen Hubs herstellen.

Ein typisches Beispiel für dieses Szenario ist die Platzierung von Anwendungsverarbeitungsservern in einem Spoke oder virtuellen Netzwerk. Die Datenbank wird dann in einem anderen Spoke oder virtuellen Netzwerk bereitgestellt. In diesem Fall ist es einfach, die Spokes mittels Peering in virtuellen Netzwerken zu verbinden und das Durchlaufen des Hubs dabei zu vermeiden. Führen Sie eine sorgfältige Überprüfung der Architektur und Sicherheit durch, um sicherzustellen, dass bei der Umgehung des Hubs keine wichtigen Sicherheits- oder Überwachungspunkte umgangen werden, die nur im Hub vorhanden sind.

Abbildung 3: Ein Beispiel wie Sie Spokes untereinander und mit einem Hub verbinden.

Spokes können auch mit einem Spoke verbunden werden, der als Hub fungiert. Bei diesem Ansatz wird eine Hierarchie mit zwei Ebenen erstellt: Der Spoke auf der höheren Ebene (Ebene 0) wird der Hub der unteren Spokes (Stufe 1) in der Hierarchie. Die Spokes sind erforderlich, um den Datenverkehr an den zentralen Hub weiterzuleiten. Diese Anforderung besteht dahingehend, dass der Datenverkehr entweder im lokalen Netzwerk oder im öffentlichen Internet an sein Ziel übertragen werden kann. Eine Architektur mit zwei Hubebenen führt komplexes Routing ein, das die Vorteile einer einfachen Hub-and-Spoke-Beziehung aufhebt.

Nächste Schritte

Nachdem Sie nun die bewährten Methoden für Netzwerke erkundet haben, erfahren Sie, wie Sie mit Identitäts- und Zugriffssteuerungen verfahren.