Hub-and-Spoke-Netzwerkarchitektur

In diesem Dokument werden zwei Architekturoptionen zum Einrichten einer Hub-and-Spoke-Netzwerktopologie in Google Cloud vorgestellt. Eine Option nutzt die Netzwerk-Peering-Funktion der Virtual Private Cloud (VPC) und die andere verwendet Cloud VPN.

Übersicht

Was ist ein Hub-and-Spoke-Netzwerk und wann ist es nützlich? Wenn Sie als Unternehmensarchitekt oder Netzwerkadministrator die Google Cloud-Topologie für ein großes Unternehmen entwerfen, müssen Sie möglicherweise die Isolierung von Ressourcen auf Netzwerkebene planen, die von verschiedenen Geschäftseinheiten, Arbeitslasten oder Umgebungen verwendet werden. Eine solche Isolation ermöglicht eine detaillierte Kontrolle über den Netzwerk-Traffic für jede Gruppe von Ressourcen. Sie kann auch helfen, rechtliche und behördliche Anforderungen für die Datentrennung zu erfüllen.

Sie können Ressourcen auf Netzwerkebene in Google Cloud isolieren. Stellen Sie dazu die Ressourcen in separaten VPC-Netzwerken bereit. Damit die Ressourcen in diesen VPC-Netzwerken gemeinsame Dienste nutzen können (z. B. Firewalls oder Konfigurationsmetadaten) und für einen zentralen Zugriff auf die Cloud von Ihrem lokalen Netzwerk aus, können Sie jedes VPC-Netzwerk mit einem zentralen Hub-VPC-Netzwerk verbinden. Das folgende Diagramm zeigt ein Beispiel für das resultierende Hub-and-Spoke-Netzwerk, das manchmal auch als Star-Topologie bezeichnet wird.

Hub-and-Spoke-Netzwerkschema.

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

Architektur mit VPC-Netzwerk-Peering

Das folgende Diagramm zeigt ein Hub-and-Spoke-Netzwerk mit VPC-Netzwerk-Peering, das eine sichere Kommunikation zwischen Ressourcen in separaten VPC-Netzwerken über das interne Netzwerk von Google mithilfe privater IP-Adressen ermöglicht, ohne dass der Traffic zwischen VPC-Netzwerken das öffentliche Internet durchquert.

Hub-and-Spoke-Architektur mit VPC-Netzwerk-Peering
  • in dieser Architektur verwenden die Ressourcen, die eine Isolierung auf Netzwerkebene benötigen, separate Spoke-VPC-Netzwerke. Beispielsweise zeigt die Architektur eine Compute Engine-VM im Spoke-1-VPC-Netzwerk. Das Spoke-2-VPC-Netzwerk hat eine Compute Engine-VM und einen Google Kubernetes Engine-Cluster (GKE-Cluster).

  • Jedes Spoke-VPC-Netzwerk in dieser Architektur hat eine Peering-Beziehung zu einem zentralen Hub-VPC-Netzwerk.

  • Jedes Spoke-VPC-Netzwerk hat ein Cloud NAT-Gateway für die ausgehende Kommunikation mit dem Internet.

  • Die Peering-Verbindungen zwischen den Spoke-VPC-Netzwerken und dem Hub-VPC-Netzwerk lassen keinen transitiven Traffic zu. Das heißt, die Kommunikation zwischen den Spokes über den Hub ist nicht möglich. Ressourcen wie private GKE-Knoten und Cloud SQL-Instanzen mit privaten IP-Adressen erfordern einen Proxy für den Zugriff von außerhalb ihres VPC-Netzwerks.

    Die Architektur zeigt die Möglichkeit der Verwendung von Cloud-VPN, um die Einschränkung der Nicht-Transitivität von VPC-Netzwerk-Peering zu umgehen. In diesem Beispiel ermöglicht ein VPN-Tunnel zwischen dem Spoke-VPC-Netzwerk und dem Hub-VPC-Netzwerk die Konnektivität vom Spoke-2-VPC-Netzwerk zu den anderen Spokes. Wenn Sie eine Verbindung zwischen nur wenigen bestimmten Spokes benötigen, können Sie diese VPC-Netzwerkpaare direkt verbinden.

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
  • Auch in dieser Architektur verwenden die Ressourcen, die eine Isolierung auf Netzwerkebene benötigen, separate Spoke-VPC-Netzwerke.
  • Ein IPSec-VPN-Tunnel verbindet jedes Spoke-VPC-Netzwerk mit einem Hub-VPC-Netzwerk.
  • Jedes Spoke-VPC-Netzwerk hat ein Cloud NAT-Gateway für die ausgehende Kommunikation mit dem öffentlichen Internet.

Berücksichtigen Sie bei der Wahl zwischen den beiden bisher erläuterten Architekturen die relativen Merkmale von VPC-Netzwerk-Peering und Cloud VPN:

  • Das VPC-Netzwerk-Peering hat die Einschränkung der Nicht-Transitivität, unterstützt aber die volle Bandbreite, die durch den Maschinentyp der VMs und andere Faktoren definiert ist, die die Netzwerkbandbreite bestimmen.
  • Cloud VPN ermöglicht transitives Routing, wobei die Gesamtbandbreite (eingehender und ausgehender Traffic) jedes VPN-Tunnels auf 3 Gbit/s begrenzt ist.

Designalternativen

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

Verbindungen zwischen Spokes mithilfe eines Gateways im Hub-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 Hub-VPC-Netzwerk bereitstellen, die als Gateway für den Traffic von Spoke zu Spoke dient. Zentralisierte Netzwerkanwendungen in Google Cloud.
VPC-Netzwerk-Peering ohne Hub
Wenn Sie keine zentralisierte Kontrolle über lokale Konnektivität oder das Teilen von Diensten in verschiedenen VPC-Netzwerken benötigen, ist ein Hub-VPC-Netzwerk nicht erforderlich. Sie können Peering für die VPC-Netzwerkpaare einrichten, die Konnektivität benötigen, und die Verbindungen einzeln verwalten. Beachten Sie die Limits für die Anzahl der Peering-Beziehungen pro VPC-Netzwerk.
Mehrere freigegebene VPC-Netzwerke

Erstellen Sie ein freigegebenes 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 freigegebenes VPC-Netzwerk für die Produktion und ein weiteres freigegebenes VPC-Netzwerk für die Entwicklung. Anschließend verbinden Sie die beiden VPC-Netzwerke miteinander, um die Kommunikation zwischen VPCs zu ermöglichen. Ressourcen in einzelnen Projekten für jede Anwendung oder Abteilung können Dienste aus dem entsprechenden freigegebenen 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