Netzwerkdesign für Ihre Google Cloud-Landing-Zone festlegen

Last reviewed 2023-09-11 UTC

Wenn Sie Ihre Landing-Zone entwerfen, müssen Sie ein Netzwerkdesign auswählen, das für Ihre Organisation funktioniert. In diesem Dokument werden vier gängige Netzwerkdesigns beschrieben. Außerdem erfahren Sie, wie Sie die Option auswählen, die den Anforderungen Ihrer Organisation am besten entspricht, sowie die Präferenz Ihrer Organisation für eine zentrale oder dezentrale Steuerung. Es richtet sich an Netzwerkentwickler, Architekten und technische Fachkräfte, die an der Erstellung des Netzwerkdesigns für die Landing-Zone Ihres Unternehmens beteiligt sind.

Dieser Artikel ist Teil einer Reihe über Landing-Zonen.

Netzwerkdesign auswählen

Das ausgewählte Netzwerkdesign hängt hauptsächlich von den folgenden Faktoren ab:

  • Zentrale oder dezentralisierte Steuerung: Wählen Sie je nach den Einstellungen Ihrer Organisation eine der folgenden Optionen aus:
    • Zentralisieren Sie die Kontrolle über das Netzwerk, einschließlich IP-Adressierung, Routing und Firewalls zwischen verschiedenen Arbeitslasten.
    • Ermöglichen Sie Ihren Teams eine größere Autonomie, wenn sie ihre eigenen Umgebungen ausführen und Netzwerkelemente in ihren Umgebungen selbst erstellen.
  • Lokale oder hybride Cloud-Verbindungsoptionen: Alle in diesem Dokument beschriebenen Netzwerkdesigns bieten Zugriff auf lokale und Cloud-Umgebungen über Cloud VPN oderCloud Interconnect. Bei einigen Designs müssen Sie jedoch mehrere Verbindungen parallel einrichten, während andere die gleiche Verbindung für alle Arbeitslasten verwenden.
  • Sicherheitsanforderungen: Ihre Organisation benötigt möglicherweise Traffic zwischen verschiedenen Arbeitslasten in Google Cloud, um zentralisierte Netzwerk-Appliances wie etwaFirewalls der nächsten Generation (NGFW) weiterzugeben. Diese Einschränkung wirkt sich auf das VPC-Netzwerkdesign (Virtual Private Cloud) aus.
  • Skalierbarkeit: Einige Designs sind für Ihre Organisation möglicherweise besser als andere. Dies hängt von der Anzahl der Arbeitslasten, die Sie bereitstellen möchten, und von der Anzahl der virtuellen Maschinen (VMs), internen Load Balancers und anderen Ressourcen, die diese verbrauchen werden ab.

Entscheidungspunkte für das Netzwerkdesign

Das folgende Flussdiagramm zeigt die Entscheidungen, die Sie treffen müssen, um das beste Netzwerkdesign für Ihre Organisation auszuwählen.

Entscheidungen für Netzwerkdesigns.

Das obige Diagramm führt Sie durch die folgenden Fragen:

  1. Benötigen Sie eine Ebene-7-Prüfung mit Netzwerk-Appliances zwischen verschiedenen Arbeitslasten in Google Cloud?
  2. Benötigen viele Ihrer Arbeitslasten lokale Verbindungen?
    • Falls ja, fahren Sie mit Schritt 4 fort.
    • Falls nein, fahren Sie mit der nächsten Frage fort.
  3. Können Ihre Arbeitslasten in einem Dienstersteller- und Nutzermodell über private Endpunkte kommunizieren?
  4. Möchten Sie Firewalls und Routing zentral verwalten?

Das Diagramm soll Ihnen bei der Entscheidung helfen. Es kann jedoch oft sein, dass mehrere Designs für Ihr Unternehmen geeignet sind. In diesen Instanzen sollten Sie das Design wählen, das am besten zu Ihrem Anwendungsfall passt.

Optionen für das Netzwerkdesign

In den folgenden Abschnitten werden vier gängige Designoptionen beschrieben. Wir empfehlen Option 1 für die meisten Anwendungsfälle. Die anderen in diesem Abschnitt beschriebenen Designs sind Alternativen, die für bestimmte organisatorische Grenzanforderungen gelten.

Die beste Eignung für Ihren Anwendungsfall könnte auch ein Netzwerk sein, das Elemente aus mehreren Designoptionen kombiniert, die in diesem Abschnitt erläutert werden. Sie können beispielsweise freigegebene VPC-Netzwerke in Hub-and-Spoke-Topologien verwenden, um die Zusammenarbeit zu verbessern, die zentrale Steuerung zu ermöglichen und die Anzahl der VPC-Spokes zu begrenzen. Alternativ können Sie die meisten Arbeitslasten in einer freigegebenen VPC-Topologie entwerfen, dabei aber eine kleine Anzahl von Arbeitslasten in separaten VPC-Netzwerken isolieren, die Dienste nur über einige definierte Endpunkte über Private Service Connect bereitstellen.

Option 1: Freigegebenes VPC-Netzwerk für jede Umgebung

Wir empfehlen dieses Netzwerkdesign für die meisten Anwendungsfälle. Bei diesem Design werden für jede Bereitstellungsumgebung, die Sie in Google Cloud haben (Entwicklung, Test und Produktion), separate freigegebene VPC-Netzwerke verwendet. Mit diesem Design können Sie Netzwerkressourcen in einem gemeinsamen Netzwerk zentral verwalten und die Netzwerkisolation zwischen den verschiedenen Umgebungen bereitstellen.

Verwenden Sie dieses Design, wenn Folgendes zutrifft:

  • Sie möchten die zentrale Kontrolle über Firewall- und Routingregeln haben.
  • Sie benötigen eine einfache, skalierbare Infrastruktur.
  • Sie benötigen eine zentrale Verwaltung des IP-Adressbereichs.

Vermeiden Sie dieses Design, wenn Folgendes zutrifft:

  • Sie möchten, dass Entwicklerteams die vollständige Autonomie haben, einschließlich der Möglichkeit, ihre eigenen Firewallregeln, das Routing und das Peering für andere Teamnetzwerke zu verwalten.
  • Sie benötigen eine Ebene-7-Prüfung mit NGFW-Appliances.

Das folgende Diagramm zeigt eine beispielhafte Implementierung dieses Designs.

Diagramm Option 1

Das obige Diagramm zeigt Folgendes:

  • Das lokale Netzwerk ist auf zwei geografische Standorte verteilt.
  • Das lokale Netzwerk stellt über redundante Cloud Interconnect-Instanzen eine Verbindung zu zwei separaten freigegebenen VPC-Netzwerken her, eines für die Produktion und eines für die Entwicklung.
  • Die Produktions- und Entwicklungsumgebungen sind mit beiden Cloud Interconnect-Instanzen mit unterschiedlichen VLAN-Anhängen verbunden.
  • Jede freigegebene VPC hat Dienstprojekte, die die Arbeitslasten hosten.
  • Firewallregeln werden im Hostprojekt zentral verwaltet.
  • Die Entwicklungsumgebung hat dieselbe VPC-Struktur wie die Produktionsumgebung.

Der Traffic aus einer Umgebung kann standardmäßig nicht in eine andere Umgebung geleitet werden. Wenn jedoch bestimmte Arbeitslasten miteinander kommunizieren müssen, können Sie die Datenübertragung lokal über kontrollierte Kanäle zulassen oder Daten zwischen Anwendungen für Google Cloud-Dienste wie Cloud Storage oder Pub/Sub freigeben. Wir empfehlen, separate Umgebungen nicht direkt über VPC-Netzwerk-Peering zu verbinden, da dies das Risiko einer versehentlichen Vermischung von Daten zwischen den Umgebungen erhöht. Durch die Verwendung von VPC-Netzwerk-Peering zwischen großen Umgebungen erhöht sich außerdem das Risiko, VPC-Kontingente um Peering- und Peering-Gruppen zu überschreiten.

Hier finden Sie weitere Informationen:

Informationen zur Implementierung dieser Designoption finden Sie unter Option 1 erstellen: Freigegebenes VPC-Netzwerk für jede Umgebung

Option 2: Hub-and-Spoke-Topologie mit zentralisierten Appliances

Dieses Netzwerkdesign verwendet Hub-and-Spoke-Topologie. Ein Hub-VPC-Netzwerk enthält eine Reihe von Appliance-VMs wie NGFWs, die mit den Spoke-VPC-Netzwerken verbunden sind, die die Arbeitslasten enthalten. Der Traffic zwischen den Arbeitslasten, lokalen Netzwerken oder dem Internet wird über Appliance-VMs zur Prüfung und Filterung weitergeleitet.

Verwenden Sie dieses Design, wenn Folgendes zutrifft:

  • Sie benötigen eine Layer-7-Prüfung zwischen verschiedenen Arbeitslasten oder Anwendungen.
  • Sie haben eine Unternehmensanforderung, die den Anbieter der Sicherheits-Appliance für den gesamten Traffic festlegt.

Vermeiden Sie dieses Design, wenn Folgendes zutrifft:

Das folgende Diagramm zeigt ein Beispiel für eine Implementierung dieses Musters.

Diagramm Option 2

Das obige Diagramm zeigt Folgendes:

  • Eine Produktionsumgebung, die ein Hub-VPC-Netzwerk und mehrere Spoke-VPC-Netzwerke umfasst, in denen die Arbeitslasten enthalten sind.
  • Die Spoke-VPC-Netzwerke sind über VPC-Netzwerk-Peering mit dem Hub-VPC-Netzwerk verbunden.
  • Das Hub-VPC-Netzwerk hat mehrere Instanzen einer virtuellen Appliance in einer verwalteten Instanzgruppe. Der Traffic zur verwalteten Instanzgruppe läuft über einen internen Passthrough-Network Load Balancer.
  • Die Spoke-VPC-Netzwerke kommunizieren über die virtuellen Appliances miteinander über statische Routen mit dem internen Load-Balancer als nächsten Hop.
  • Cloud Interconnect verbindet die Transit-VPC-Netzwerke mit lokalen Standorten.
  • Lokale Netzwerke sind über dieselben Cloud Interconnects mit separaten VLAN-Anhängen verbunden.
  • Die Transit-VPC-Netzwerke sind mit einer separaten Netzwerkschnittstelle auf den virtuellen Appliances verbunden, sodass Sie den gesamten Traffic zu und von diesen Netzwerken mithilfe Ihrer Appliance prüfen und filtern können.
  • Die Entwicklungsumgebung hat dieselbe VPC-Struktur wie die Produktionsumgebung.
  • Bei dieser Konfiguration wird keine Übersetzung der Quellnetzwerkadresse (SNAT, Source Network Address Translation) verwendet. SNAT ist nicht erforderlich, da Google Cloud symmetrisches Hashing verwendet. Weitere Informationen finden Sie unter Symmetrisches Hashing.

Traffic von einem Spoke-Netzwerk kann standardmäßig kein anderes Spoke-Netzwerk erreichen. Wenn jedoch bestimmte Arbeitslasten miteinander kommunizieren müssen, können Sie direktes Peering zwischen den Spoke-Netzwerken per VPC-Netzwerk-Peering einrichten oder Daten zwischen Anwendungen für Google Cloud-Dienste wie Cloud Storage oder Pub/Sub austauschen.

Die Appliance muss sich in derselben Region wie die Arbeitslasten befinden, um eine niedrige Latenz zu gewährleisten, wenn die Appliance zwischen Arbeitslasten kommuniziert. Wenn Sie in Ihrer Cloudbereitstellung mehrere Regionen verwenden, können Sie für jede Umgebung in jeder Region eine Reihe von Appliances und eine Hub-VPC haben. Alternativ können Sie Netzwerk-Tags mit Routen verwenden, damit alle Instanzen mit der nächstgelegenen Appliance kommunizieren können.

Firewallregeln können die Verbindungen in den Spoke-VPC-Netzwerken einschränken, die Arbeitslasten enthalten. Häufig verwalten Teams, die die Arbeitslasten verwalten, auch diese Firewallregeln. Für zentrale Richtlinien können Sie hierarchische Firewallrichtlinien verwenden. Wenn ein zentrales Netzwerkteam die vollständige Kontrolle über Firewallregeln haben soll, sollten Sie diese Regeln in allen VPC-Netzwerken mithilfe eines GitOps-Ansatz bereitstellen: Beschränken Sie in diesem Fall die IAM-Berechtigungen auf die Administratoren, die die Firewallregeln ändern können. Spoke-VPC-Netzwerke können auch freigegebene VPC-Netzwerke sein, wenn mehrere Teams in den Spokes bereitgestellt werden.

Bei diesem Design empfehlen wir die Verwendung von VPC-Netzwerk-Peering, um das Hub-VPC- und Spoke-VPC-Netzwerk zu verbinden, da dies die Komplexität erhöht. Die maximale Anzahl der Spokes ist jedoch so begrenzt:

  • Das Limit für VPC-Netzwerk-Peering-Verbindungen aus einem einzelnen VPC-Netzwerk.
  • Peering-Gruppenlimits, z. B. die maximale Anzahl von Weiterleitungsregeln für das interne TCP/UDP-Load-Balancing für jede Peering-Gruppe.

Wenn Sie diese Limits erreichen, können Sie die Spoke-Netzwerke über Cloud VPN verbinden. Die Verwendung von Cloud VPN erhöht die Kosten und Komplexität und jeder Cloud VPN-Tunnel hat ein Bandbreitenlimit.

Hier finden Sie weitere Informationen:

Informationen zur Implementierung dieser Designoption finden Sie unter Option 2 erstellen: Hub-and-Spoke-Topologie mit zentralisierten Appliances.

Option 3: Hub-and-Spoke-Topologie ohne Appliances

Dieses Netzwerkdesign verwendet auch eine Hub-and-Spoke-Topologie mit einem Hub-VPC-Netzwerk, das eine Verbindung zu lokalen Netzwerken und Spoke-VPC-Netzwerken herstellt, die die Arbeitslasten enthalten. Da das VPC-Netzwerk-Peering nicht transitiv ist, können Spoke-Netzwerke nicht direkt miteinander kommunizieren.

Verwenden Sie dieses Design, wenn Folgendes zutrifft:

  • Sie möchten, dass Arbeitslasten oder Umgebungen in Google Cloud nicht über interne IP-Adressen miteinander kommunizieren, aber die lokalen Verbindungen freigeben.
  • Sie möchten den Teams Autonomie bei der Verwaltung ihrer eigenen Firewall- und Routingregeln geben.

Vermeiden Sie dieses Design, wenn Folgendes zutrifft:

  • Sie benötigen eine Ebene-7-Prüfung zwischen Arbeitslasten.
  • Sie möchten Routing- und Firewallregeln zentral verwalten.
  • Sie benötigen die Kommunikation von lokalen Diensten zu verwalteten Diensten, die über ein anderes VPC-Netzwerk-Peering mit den Spokes verbunden sind, da VPC-Netzwerk-Peering nicht transitiv ist.

Das folgende Diagramm zeigt eine beispielhafte Implementierung dieses Designs.

Diagramm Option 3

Das obige Diagramm zeigt Folgendes:

  • Eine Produktionsumgebung, die ein Hub-VPC-Netzwerk und mehrere Spoke-VPC-Netzwerke umfasst, in denen die Arbeitslasten enthalten sind.
  • Die Spoke-VPC-Netzwerke sind über VPC-Netzwerk-Peering mit dem Hub-VPC-Netzwerk verbunden.
  • Die Verbindung zu lokalen Standorten erfolgt über Cloud Interconnect-Verbindungen im Hub-VPC-Netzwerk.
  • Lokale Netzwerke werden über eigene Cloud Interconnect-Instanzen mit separaten VLAN-Anhängen verbunden.
  • Die Entwicklungsumgebung hat dieselbe VPC-Struktur wie die Produktionsumgebung.

Traffic von einem Spoke-Netzwerk kann standardmäßig kein anderes Spoke-Netzwerk erreichen. Wenn jedoch bestimmte Arbeitslasten miteinander kommunizieren müssen, können Sie direktes Peering zwischen den Spoke-Netzwerken per VPC-Netzwerk-Peering einrichten oder Daten zwischen Anwendungen für Google Cloud-Dienste wie Cloud Storage oder Pub/Sub austauschen.

Dieses Netzwerkdesign wird häufig in Umgebungen verwendet, in denen Teams autonom arbeiten und keine zentralisierte Kontrolle über Firewall- und Routingregeln haben. Der Umfang dieses Designs ist jedoch durch folgende Faktoren begrenzt:

Daher wird dieses Design in der Regel nicht in großen Organisationen verwendet, die viele separate Arbeitslasten in Google Cloud haben.

Sie können das Cloud VPN anstelle des VPC-Netzwerk-Peerings verwenden. Mit Cloud VPN können Sie die Anzahl der Spokes erhöhen, aber für die einzelnen Tunnel ein Bandbreitenlimit hinzufügen und die Komplexität und Kosten erhöhen. Wenn Sie benutzerdefinierte beworbene Routen verwenden, ermöglicht Cloud VPN auch die Übertragung zwischen den Spokes, ohne dass Sie alle Spoke-Netzwerke direkt verbinden müssen.

Hier finden Sie weitere Informationen:

Informationen zur Implementierung dieser Designoption finden Sie unter Option 3 erstellen: Hub-and-Spoke-Topologie ohne Appliances.

Option 4: Dienste in einem Nutzer-Ersteller-Modell mit Private Service Connect verfügbar machen

Bei diesem Netzwerkdesign erhält jedes Team oder jede Arbeitslast ein eigenes VPC-Netzwerk. Dieses kann auch ein freigegebenes VPC-Netzwerk sein. Jedes VPC-Netzwerk wird unabhängig verwaltet und verwendet Private Service Connect, um alle Dienste verfügbar zu machen, auf die von außerhalb des VPC-Netzwerks zugegriffen werden muss.

Verwenden Sie dieses Design, wenn Folgendes zutrifft:

  • Arbeitslasten kommunizieren nur über definierte Endpunkte miteinander und mit der lokalen Umgebung.
  • Sie möchten, dass Teams unabhängig voneinander sind und ihren eigenen IP-Adressbereich, ihre Firewalls und Routingregeln verwalten.

Vermeiden Sie dieses Design, wenn Folgendes zutrifft:

  • Die Kommunikation zwischen Diensten und Anwendungen verwendet viele verschiedene Ports oder Kanäle oder Ports und Kanäle ändern sich häufig.
  • Die Kommunikation zwischen Arbeitslasten verwendet andere Protokolle als TCP oder UDP.
  • Sie benötigen eine Ebene-7-Prüfung zwischen Arbeitslasten.

Das folgende Diagramm zeigt ein Beispiel für eine Implementierung dieses Musters.

Diagramm Option 4

Das obige Diagramm zeigt Folgendes:

  • Separate Arbeitslasten befinden sich in separaten Projekten und VPC-Netzwerken.
  • Eine Client-VM in einem VPC-Netzwerk kann über einen Private Service Connect-Endpunkt eine Verbindung zu einem Workload in einem anderen VPC-Netzwerk herstellen.
  • Der Endpunkt ist mit einem Dienstanhang im VPC-Netzwerk verknüpft, in dem sich der Dienst befindet. Der Dienstanhang kann sich in einer anderen Region als der Endpunkt befinden, wenn er für globalen Zugriff konfiguriert ist.
  • Der Dienstanhang stellt über Cloud Load Balancing eine Verbindung zur Arbeitslast her.
  • Clients in der Arbeitslast-VPC können lokale Arbeitslasten so erreichen:
    • Der Endpunkt ist mit einem Dienstanhang in einem Transit-VPC-Netzwerk verbunden.
    • Der Dienstanhang ist über Cloud Interconnect mit dem lokalen Netzwerk verbunden.
  • Ein interner Anwendungs-Load-Balancer ist an den Dienstanhang angehängt und verwendet eine Hybridnetzwerk-Endpunktgruppe, um die Trafficlast zwischen den lokalen Endpunkten auszugleichen.
  • Lokale Clients können auch Endpunkte im Transit-VPC-Netzwerk erreichen, die eine Verbindung zu Dienstanhängen in den VPC-Netzwerken der Arbeitslast herstellen.

Hier finden Sie weitere Informationen:

Informationen zum Implementieren dieser Designoption finden Sie unter Option 4 erstellen: Dienste in einem Nutzer-Produzent-Modell mit Private Service Connect verfügbar machen.

Best Practices für die Netzwerkbereitstellung

Nachdem Sie das beste Netzwerkdesign für Ihren Anwendungsfall ausgewählt haben, sollten Sie die folgenden Best Practices implementieren:

Weitere Informationen finden Sie unter Best Practices und Referenzarchitekturen für das VPC-Design.

Nächste Schritte