Netzwerke für Hybrid- und Multi-Cloud-Arbeitslasten: Referenzarchitekturen

Last reviewed 2023-11-13 UTC

Dieses Dokument ist Teil einer Reihe, in der Netzwerk- und Sicherheitsarchitekturen für Unternehmen beschrieben werden, die Arbeitslasten von Rechenzentren zu Google Cloud migrieren.

Die Reihe besteht aus folgenden Dokumenten:

In diesem Dokument werden Netzwerke für ein Szenario erläutert, in dem Arbeitslasten an mehr als einem Ort ausgeführt werden, z. B. lokal und in der Cloud, oder in mehreren Cloudumgebungen.

Lift-and-Shift-Architektur

Das erste hybride Arbeitslastzugriffsszenario ist eine Lift-and-Shift-Architektur.

Private Verbindung herstellen

Sie können Verbindungen zu lokalen Netzwerken entweder über Dedicated Interconnect oder Partner Interconnect herstellen. Die in Abbildung 1 dargestellte Topologie zeigt, wie Sie mit vier Dedicated Interconnect-Verbindungen in zwei verschiedenen Metropolregionen und verschiedenen Edge-Verfügbarkeitsdomains eine Verfügbarkeit von 99,99 % mit Dedicated Interconnect verwenden können. Weitere Informationen und detaillierte Empfehlungen finden Sie im Abschnitt zu den Unternehmensgrundlagen unter Hybridkonnektivität zwischen einer lokalen Umgebung und Google Cloud.

Konfiguration redundanter Cloud Interconnect-Verbindungen für eine Verfügbarkeit von 99,99 %

Abbildung 1. Konfiguration redundanter Cloud Interconnect-Verbindungen für eine Verfügbarkeit von 99,99 %

Mit dem Network Connectivity Center können Sie das Google-Netzwerk für die Datenübertragung zwischen mehreren lokalen oder in der Cloud gehosteten Standorten verwenden. Mit diesem Ansatz können Sie die Reichweite und Zuverlässigkeit des Google-Netzwerks nutzen, wenn Sie Daten verschieben müssen. Sie können Ihre vorhandenen Cloud VPN-, Cloud Interconnect- und SD-WAN-Router-Appliances als Network Connectivity Center-Spokes verwenden, um die Datenübertragung zwischen den lokalen Netzwerken und dem Zweig zu unterstützen, wie in Abbildung 2 dargestellt.

Screenshot: Network Connectivity Center-Konfiguration, die verschiedene lokale Unternehmensnetzwerke außerhalb von Google Cloud über das Backbonenetzwerk von Google verbindet

Abbildung 2. Die Konfiguration des Network Connectivity Centers verbindet verschiedene lokale Unternehmen und andere Cloud-Netzwerke außerhalb von Google Cloud über das Google-Backbonenetzwerk.

Weitere Informationen zum Einrichten des Network Connectivity Center finden Sie unter Überlegungen in der Network Connectivity Center-Dokumentation.

SD-WAN-Appliances

Mit dem Network Connectivity Center können Sie eine virtuelle Appliance des Netzwerks als Network Connectivity Center-Spoke verwenden, um eine Verbindung zwischen einem externen Standort und Ihren VPC-Netzwerkressourcen herzustellen. Eine Router-Appliance kann ein von einem unserer Partner unterstützter SD-WAN-Router eines Drittanbieters oder eine andere virtuelle Appliance sein, mit der Sie Routen mit der Cloud Routerinstanz austauschen können. Diese Appliance-basierten Lösungen ergänzen die aktuellen Site-to-Cloud-Konnektivitätsoptionen, die mit Cloud VPN und Cloud Interconnect als Spokes verfügbar sind. Abbildung 3 zeigt eine Topologie, die SD-WAN-Appliances verwendet.

Screenshot: Konfiguration des Network Connectivity Centers mit Router-Appliance zur Einbindung der SD-WAN-Implementierung in das Google-Netzwerk

Abbildung 3. Screenshot: Konfiguration des Network Connectivity Centers mit Router-Appliance zur Einbindung der SD-WAN-Implementierung in das Google-Netzwerk.

Sie können Appliances von Drittanbietern verwenden, um Sicherheitsfunktionen auszuführen. Die Sicherheitsfunktionen der Appliance können in die Router-Appliance integriert sein, wie in Abbildung 3 dargestellt. Es ist auch üblich, eine virtuelle Netzwerk-Appliance zu verwenden, wobei der Traffic vom lokalen Netzwerk in ein Transit-VPC-Netzwerk eingeht und die Appliance die Verbindung mit dem VPC-Netzwerk der Arbeitslast herstellt, wie in der Abbildung 4 dargestellt.

Weitere Informationen zum Einrichten des Network Connectivity Center finden Sie unter Überlegungen in der Network Connectivity Center-Dokumentation.

Hybriddienstarchitektur

Wie im Intra-Cloud-Anwendungsfall, das unter Netzwerk für sicheren Intra-Cloud-Zugriff: Referenzarchitekturen erläutert wird, ermöglicht das Network Connectivity Center die Konnektivität von Ihren Zweigstandorten und lokalen Netzwerken zu Google Cloud. Private Service Connect bietet privaten Zugriff auf von Google verwaltete Dienste oder ermöglicht die Nutzung anderer Dienste, die in der Cloud erstellt und bereitgestellt werden.

Sie können die Netzwerksicherheit auch mithilfe einer Kombination aus VPC Service Controls, Google Cloud-Firewalls und virtuellen Netzwerk-Appliances implementieren, wie in Abbildung 4 dargestellt.

Netzwerke mit einer Architektur, die sowohl ein Lift-and-Shift-Muster als auch ein Hybriddienst-Designmuster verwendet, bieten eine sichere Datenebene

Abbildung 4. Netzwerke mit einer Architektur, die sowohl ein Lift-and-Shift-Muster als auch ein Hybriddienst-Designmuster verwendet, bieten eine sichere Datenebene.

Verteilte Zero-Trust-Architektur

In einer Hybridumgebung werden Mikrodienste in Service Meshes ausgeführt, die in verschiedenen Cloud-Anbietern und lokalen Umgebungen bereitgestellt werden. Sie können die Kommunikation zwischen den Mikrodiensten mithilfe von mTLS und Autorisierungsrichtlinien sichern. Üblicherweise erstellen Unternehmen Mesh-Netzwerke in der Cloud und erweitern diese lokal. Abbildung 5 zeigt ein Beispiel, in dem Dienste, die lokal bereitgestellt werden, auf die Dienste in der Cloud zugreifen. End-to-End-mTLS zwischen den Diensten wird über das east-west-Gateway und SNI-basiertes Routing aktiviert. Anthos Service Mesh hilft Ihnen, die Dienst-zu-Dienst-Kommunikation zu sichern, sodass Sie Autorisierungsrichtlinien für die Dienste konfigurieren und Zertifikate und Schlüssel bereitstellen können, die von einer verwalteten Zertifizierungsstelle bereitgestellt werden.

Hybridumgebungen enthalten in der Regel mehrere Mesh-Deployments, z. B. mehrere GKE-Cluster. Eine wichtige Komponente in diesem Ablauf ist das SNI-Routing, das im GKE-east-west-Gateway für jeden Cluster verwendet wird. Diese Konfiguration ermöglicht direktes Routing des mTLS-Routings durch das Gateway unter Beibehaltung der End-to-End-mTLS-Konnektivität.

Zero-Trust-Service Mesh, das in einer lokalen Umgebung und in Google Cloud bereitgestellt wird

Abbildung 5. Zero-Trust-Service Mesh, das in einer lokalen Umgebung und in Google Cloud bereitgestellt wird.

Unternehmen können Anthos Service Mesh für eine cloudübergreifende Bereitstellung verwenden. Zur Bewältigung von Herausforderungen bei der Verwaltung von Identität und Zertifikaten bei Cloud-Anbietern bietet Anthos Service Mesh Workload Identity und eine mittlere clusterinterne Zertifizierungsstelle (Certificate Authority, CA), die Folgendes verwendet: CA Service (CA Service). Die dazwischenliegende CA kann mit einer externen Zertifizierungsstelle verkettet oder in Google gehostet werden. Sie können CA-Attribute wie die Region und den Signaturalgorithmus mithilfe von unternehmenseigenen HSMs und Cloud HSM anpassen.

Mit Workload Identity können Sie jedem Mikrodienst in Ihrem Cluster separate, detaillierte Identitäten und Autorisierungen zuweisen. Anthos Service Mesh verwaltet den Prozess der Ausstellung von Zertifikaten und der automatischen Rotation von Schlüsseln und Zertifikaten, ohne die Kommunikation zu unterbrechen. Es bietet auch eine einzige Root of Trust für alle GKE-Cluster.

Abbildung 6 zeigt eine Architektur, bei der die Identität und Autorisierung mit Anthos Service Mesh verwaltet werden.

Dienste im Mesh-Netzwerk können über die Workload Identity-Föderation auf Google Cloud-Dienste zugreifen. Mit diesem Feature können Dienste beim Aufrufen von Google Cloud APIs mit der Berechtigung eines Google-Dienstkontos agieren. Mit der Workload Identity-Föderation kann das Service Mesh, das bei anderen Cloudanbietern installiert ist, auch auf die Google Cloud APIs zugreifen.

Zero-Trust-Service Mesh, das über mehrere Clouds hinweg bereitgestellt wird

Abbildung 6. Zero-Trust-Service Mesh, das über mehrere Clouds hinweg bereitgestellt wird.

Sie können mit Traffic Director den Traffic vom Mesh-Netzwerk an eine lokale oder eine andere Cloud weiterleiten.

Beispielsweise können Sie Dienste in Traffic Director mit den Namen on-prem-service und other-cloud-service erstellen und Netzwerk-Endpunktgruppen (NEGs) mit Hybridkonnektivität hinzufügen, die die Endpunkte 10.1.0.1:80 und 10.2.0.1:80 haben. Traffic Director sendet den Traffic dann an seine Clients, die Mesh-Sidecar-Proxys sind, und zusammen mit Ihren Anwendungen ausgeführt werden. Wenn Ihre Anwendung eine Anfrage an den Dienst on-prem-service sendet, prüft der Traffic Director-Client die Anfrage und leitet sie an den Endpunkt 10.0.0.1:80 weiter. Diese Konfiguration wird in Abbildung 7 dargestellt.

Traffic, der mit Traffic Director aus einem Service Mesh gesteuert wird.

Abbildung 7. Traffic, der mit Traffic Director aus einem Service Mesh gesteuert wird.

Sie können auch erweiterte Funktionen wie die gewichtete Trafficsteuerung verwenden, wie in Abbildung 8 dargestellt. Mit dieser Funktion können Sie kritische Unternehmensanforderungen wie die Cloud-Migration erfüllen. Traffic Director dient als vielseitige, global verwaltete Steuerungsebene für Ihre Service Meshes.

Gewichteter Traffic mit Traffic Director.

Abbildung 8. Gewichteter Traffic mit Traffic Director.

Nächste Schritte