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 Cloudmigrieren.

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.

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

Abbildung 2. Die Konfiguration des Network Connectivity Center 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 von 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. Cloud 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 Cloudbereitgestellt wird .

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

Unternehmen können Cloud Service Mesh für cloudübergreifende Bereitstellungen verwenden. Zur Bewältigung von Herausforderungen bei der Verwaltung von Identität und Zertifikaten über Cloud-Anbietern hinweg stellt Cloud Service Mesh Workload Identity und eine zwischengeschaltete clusterinterne Zertifizierungsstelle (Certificate Authority, CA) bereit, die CA Service nutzt. 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. Cloud 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 Identität und Autorisierung mit Cloud Service Mesh verwaltet werden.

Dienste im Mesh-Netzwerk können über die Workload Identity-Föderation auf Google Cloud -Dienste zugreifen. Mit dieser Funktion 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 Cloud Service Mesh verwenden, um Traffic vom Mesh an eine lokale oder eine beliebige andere Cloud zu übertragen.

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

Traffic, der von einem Service Mesh mit Cloud Service Mesh gesteuert wird.

Abbildung 7. Traffic, der von einem Service Mesh mit Cloud 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. Cloud Service Mesh dient als vielseitige, global verwaltete Steuerungsebene für Ihre Service Meshes.

Gewichteter Traffic, der mit Cloud Service Mesh gesteuert wird.

Abbildung 8. Gewichteter Traffic, der mit Cloud Service Mesh gesteuert wird.

Nächste Schritte