Hub-and-Spoke-Netzwerkarchitektur

In diesem Dokument werden drei Architekturoptionen zum Einrichten einer Hub-and-Spoke-Netzwerktopologie in Google Cloudvorgestellt. Bei der ersten Option wird Network Connectivity Center verwendet, bei der zweiten VPC-Netzwerk-Peering und bei der dritten Cloud VPN.

Unternehmen können Arbeitslasten zur Abrechnung, Umgebungsisolation und für andere Aspekte in einzelne VPC-Netzwerke aufteilen. Das Unternehmen muss jedoch eventuell auch bestimmte Ressourcen für diese Netzwerke freigeben, z. B. gemeinsam genutzte Dienste oder lokale Verbindungen. In solchen Fällen kann es hilfreich sein, die gemeinsam genutzte Ressource in einem Hub-Netzwerk (im restlichen Teil dieses Dokuments als Routing-Netzwerk bezeichnet) zu platzieren und die anderen VPC-Netzwerke als Spoke-Netzwerke (im restlichen Teil dieses Dokuments als Arbeitslast-Netzwerke bezeichnet) anzuhängen. Das folgende Diagramm zeigt ein Hub-and-Spoke-Netzwerk mit zwei Arbeitslast-VPCs. Es können jedoch weitere Arbeitslast-VPCs hinzugefügt werden.

Hub-and-Spoke-Netzwerkschema.

In diesem Beispiel werden separate VPC-Netzwerke für die Arbeitslasten einzelner Geschäftseinheiten innerhalb eines großen Unternehmens verwendet. Jedes VPC-Netzwerk für Arbeitslasten ist mit einem zentralen Routing-VPC-Netzwerk verbunden, das freigegebene Dienste enthält und als einziger Einstiegspunkt in die Cloud vom lokalen Netzwerk des Unternehmens dienen kann.

Zusammenfassung der Optionen

Berücksichtigen Sie bei der Auswahl einer der in diesem Dokument beschriebenen Architekturen die relativen Vorteile von Network Connectivity Center, VPC-Netzwerk-Peering und Cloud VPN:

  • Network Connectivity Center bietet volle Bandbreite zwischen VPCs für Arbeitslasten und Transitivität zwischen VPCs für Arbeitslasten.
  • VPC-Netzwerk-Peering bietet die volle Bandbreite zwischen Arbeitslast-VPCs und der Routing-VPC. Es bietet keine Transitivität zwischen VPCs für Arbeitslasten. VPC-Netzwerk-Peering unterstützt das Routing zu NVAs in anderen VPCs.
  • Cloud VPN lässt transitives Routing zu, aber die Gesamtbandbreite (eingehender Traffic plus ausgehender Traffic) zwischen Netzwerken ist auf die Bandbreiten der Tunnel beschränkt. Weitere Tunnel können hinzugefügt werden, um die Bandbreite zu erhöhen.

Architektur mit Network Connectivity Center

Das folgende Diagramm zeigt ein Hub-and-Spoke-Netzwerk, in dem Network Connectivity Center verwendet wird.

Hub-and-Spoke-Architektur mit dem Network Connectivity Center.

Network Connectivity Center hat eine Hub-Ressource, die die Verwaltung der Steuerungsebene ermöglicht, aber kein Hub-Netzwerk für die Datenebene ist.

  • Mit dem Network Connectivity Center können die Netzwerke über eine Stern- (Hub-and-Spoke-) oder Mesh-Topologie verbunden werden. Bei einer Sterntopologie wird die Kommunikation zwischen VPC-Spokes (Arbeitslast-VPC) verhindert, bei einer Mesh-Topologie nicht.
  • Das Routing-VPC-Netzwerk (Hub) ist über Cloud VPN- oder Cloud Interconnect-Verbindungen mit der lokalen Umgebung verbunden.
  • Dynamische Routen können über VPC-Netzwerke hinweg weitergegeben werden.
  • Private Service Connect-Routen sind zwischen VPCs für Arbeitslasten transitiv.
  • Routen für den Zugriff auf private Dienste sind zwischen VPCs für Arbeitslasten transitiv, wenn Ersteller-Spokes für viele von Google bereitgestellte Dienste verwendet werden. Bei Diensten, bei denen Routen nicht transitiv sind, können Sie das VPC-Netzwerk des Nutzers mit dem Routing-VPC-Netzwerk über Cloud VPN anstelle von Network Connectivity Center verbinden.
  • Alle VMs in den Peering-Netzwerken können mit der vollen Bandbreite der VMs kommunizieren.
  • Jede Arbeitslast-VPC und das Routing-VPC-Netzwerk haben ein Cloud NAT-Gateway für die ausgehende Kommunikation mit dem Internet.
  • DNS-Peering und -Weiterleitung sind so eingerichtet, dass Arbeitslasten in Arbeitslast-VPCs von der lokalen Umgebung aus erreichbar sind.

Architektur mit VPC-Netzwerk-Peering

Das folgende Diagramm zeigt ein Hub-and-Spoke-Netzwerk mit VPC-Netzwerk-Peering. Das VPC-Netzwerk-Peering ermöglicht die Kommunikation über interne IP-Adressen zwischen Ressourcen in separaten VPC-Netzwerken. Der Traffic verbleibt im internen Netzwerk von Google und durchläuft nicht das öffentliche Internet.

Hub-and-Spoke-Architektur mit VPC-Netzwerk-Peering

  • Jedes Arbeitslast-VPC-Netzwerk (Spoke) in dieser Architektur hat eine Peering-Beziehung zu einem zentralen Routing-VPC-Netzwerk (Hub).
  • Das Routing-VPC-Netzwerk ist über Cloud VPN- oder Cloud Interconnect-Verbindungen mit dem lokalen Netzwerk verbunden.
  • Alle VMs in den Peering-Netzwerken können mit der vollen Bandbreite der VMs kommunizieren.
  • VPC-Netzwerk-Peering-Verbindungen sind nicht transitiv. In dieser Architektur können das lokale VPC-Netzwerk und die VPC-Netzwerke für Arbeitslasten Traffic mit dem Routing-Netzwerk, aber nicht miteinander austauschen. Wenn Sie freigegebene Dienste bereitstellen möchten, müssen Sie sie entweder in das Routing-Netzwerk einfügen oder über Cloud VPN mit dem Routing-Netzwerk verbinden.
  • Jede Arbeitslast-VPC und das Routing-VPC-Netzwerk haben ein Cloud NAT-Gateway für die ausgehende Kommunikation mit dem Internet.
  • DNS-Peering und -Weiterleitung sind so eingerichtet, dass Arbeitslasten in Arbeitslast-VPCs von der lokalen Umgebung aus erreichbar sind.

Architektur mit Cloud VPN

Die Skalierbarkeit einer Hub-and-Spoke-Topologie, die VPC-Netzwerk-Peering verwendet, unterliegt den Limits für VPC-Netzwerk-Peering. Wie bereits erwähnt, erlauben VPC-Netzwerk-Peering-Verbindungen keinen transitiven Traffic über die beiden VPC-Netzwerke hinaus, die sich in einer Peering-Beziehung befinden. Das folgende Diagramm zeigt eine alternative Hub-and-Spoke-Netzwerkarchitektur, die Cloud VPN verwendet, um die Einschränkungen des VPC-Netzwerk-Peerings zu umgehen.

Hub-and-Spoke-Architektur mit Cloud VPN

  • IPSec-VPN-Tunnel verbinden die einzelnen Arbeitslast-VPC-Netzwerke (Spokes) mit einem Routing-VPC-Netzwerk (Hub).
  • Im Routing-Netzwerk ist eine private DNS-Zone vorhanden und in jedem Arbeitslastnetzwerk gibt es eine DNS-Peering-Zone und eine private Zone.
  • Verbindungen sind transitiv. Das lokale Netzwerk und die Spoke-VPC-Netzwerke können über das Routing-Netzwerk aufeinander zugreifen. Dies kann jedoch eingeschränkt werden.
  • Die Bandbreite zwischen Netzwerken ist durch die Gesamt-Bandbreiten der Tunnel begrenzt.
  • Jede Arbeitslast-VPC (Spoke) und das Routing-VPC-Netzwerk haben ein Cloud NAT-Gateway für die ausgehende Kommunikation mit dem Internet.
  • Das VPC-Netzwerk-Peering bietet keine transitiven Routenankündigungen.
  • DNS-Peering und -Weiterleitung sind so eingerichtet, dass Arbeitslasten in Arbeitslast-VPCs von der lokalen Umgebung aus erreichbar sind.

Designalternativen

Sehen Sie sich die folgenden Architekturalternativen für Interconnect-Verbindungen von Ressourcen an, die in separaten VPC-Netzwerken in Google Cloudbereitgestellt werden:

Verbindungen zwischen Spokes mithilfe eines Gateways im Routing-VPC-Netzwerk herstellen

Für die Kommunikation zwischen den Spokes können Sie eine Network Virtual Appliance (NVA) oder eine Next Generation Firewall (NGFW) im Routing-VPC-Netzwerk bereitstellen, die als Gateway für den Traffic von Spoke zu Spoke dient.

Mehrere freigegebene VPC-Netzwerke

Erstellen Sie ein freigegebene VPC-Netzwerk für jede Gruppe von Ressourcen, die Sie auf Netzwerkebene isolieren möchten. Wenn Sie beispielsweise die Ressourcen trennen möchten, die für Produktions- und Entwicklungsumgebungen verwendet werden, erstellen Sie ein freigegebene VPC-Netzwerk für die Produktion und ein weiteres freigegebene VPC-Netzwerk für die Entwicklung. Anschließend verbinden Sie die beiden VPC-Netzwerke miteinander, um die Kommunikation zwischen VPC-Netzwerk zu ermöglichen. Ressourcen in einzelnen Projekten für jede Anwendung oder Abteilung können Dienste aus dem entsprechenden freigegebene VPC-Netzwerk nutzen.

Für Verbindungen zwischen den VPC-Netzwerken und Ihrem lokalen Netzwerk können Sie entweder separate VPN-Tunnel für jedes VPC-Netzwerk oder separate VLAN-Anhänge in derselben Dedicated Interconnect-Verbindung verwenden.

Nächste Schritte