Dienstnetzwerk für verteilte Anwendungen im Cross-Cloud Network

Last reviewed 2025-01-30 UTC

Dieses Dokument ist Teil einer Designanleitungsreihe für Cross-Cloud Network.

Die Reihe besteht aus folgenden Teilen:

In diesem Dokument wird beschrieben, wie Sie eine Anwendung aus einer Reihe ausgewählter oder erstellter Komponentendienste zusammenstellen. Wir empfehlen, das gesamte Dokument einmal durchzulesen, bevor Sie die Schritte ausführen.

In diesem Dokument werden Sie durch die folgenden Entscheidungen geführt:

  • Ob Sie den einzelnen Dienst selbst erstellen oder einen Drittanbieterdienst nutzen
  • Ob der Dienst global oder regional verfügbar ist
  • Gibt an, ob der Dienst lokal, in anderen Clouds oder weder noch genutzt wird.
  • Ob Sie über eine VPC mit freigegebenen Diensten auf den Dienstendpunkt zugreifen oder die Endpunkte auf alle relevanten Anwendungs-VPCs verteilen

In diesem Dokument werden Sie durch die folgenden Schritte geführt:

  1. Entscheiden, ob Ihre Anwendung global oder regional ist
  2. Verwaltete Dienste von Drittanbietern auswählen oder eigene Dienste erstellen und veröffentlichen
  3. Richten Sie den privaten Zugriff auf die Dienstendpunkte entweder im freigegebenen oder im dedizierten Modus ein.
  4. Dienste in Anwendungen zusammenstellen, die entweder einem globalen oder einem regionalen Archetyp entsprechen

Entwickler definieren die Dienstnetzwerkebene für Cross-Cloud Network. In dieser Phase haben Administratoren eine Verbindungsschicht für Cross-Cloud Network entwickelt, die Flexibilität bei den in diesem Dokument beschriebenen Dienstnetzwerkoptionen ermöglicht. In einigen Fällen gibt es Einschränkungen aufgrund der begrenzten VPC-übergreifenden Transitivität. Wir beschreiben diese Einschränkungen, wenn sie sich auf Designentscheidungen auswirken können.

Entscheiden, ob Ihre Anwendung regional oder global ist

Stellen Sie fest, ob die Kunden der Anwendung, die Sie erstellen, einen regionalen oder globalen Bereitstellungsarchetyp benötigen. Sie können regionale Ausfallsicherheit erreichen, indem Sie Lasten auf die Zonen einer Region verteilen. Sie können die globale Resilienz erreichen, indem Sie die Lasten auf Regionen verteilen.

Berücksichtigen Sie bei der Auswahl eines Archetyps die folgenden Faktoren:

  • Verfügbarkeitsanforderungen der Anwendung
  • Der Ort, an dem die Anwendung verwendet wird
  • Kosten

Weitere Informationen finden Sie unter Google Cloud -Bereitstellungsarchetypen.

In diesem Designleitfaden wird beschrieben, wie Sie die folgenden Bereitstellungstypen unterstützen:

Bei einer cloudübergreifenden verteilten Anwendung können verschiedene Dienste dieser Anwendung von verschiedenen Cloud-Dienstanbietern (Cloud Service Providers, CSPs) oder privaten Rechenzentren bereitgestellt werden. Um eine konsistente Resilienzstruktur zu gewährleisten, sollten Sie Dienste, die bei verschiedenen CSPs gehostet werden, in CSP-Rechenzentren unterbringen, die geografisch nah beieinander liegen.

Das folgende Diagramm zeigt einen globalen Anwendungsstack, der über Clouds verteilt ist. Verschiedene Anwendungsdienste werden bei verschiedenen CSPs bereitgestellt. Jeder globale Anwendungsdienst hat Arbeitslastinstanzen in verschiedenen Regionen desselben CSP.

Globales Anwendungspaket, das auf mehrere Clouds verteilt ist.

Anwendungsdienste definieren und darauf zugreifen

Sie können Ihre Anwendung aus vorhandenen verwalteten Drittanbieterdiensten zusammenstellen, eigene Anwendungsdienste erstellen und hosten oder eine Kombination aus beidem verwenden.

Vorhandene verwaltete Drittanbieterdienste verwenden

Entscheiden Sie, welche verwalteten Drittanbieterdienste Sie für Ihre Anwendung verwenden können. Ermitteln Sie, welche als regionale oder globale Dienste konzipiert sind. Außerdem müssen Sie festlegen, welche Optionen für den privaten Zugriff von den einzelnen Diensten unterstützt werden.

Wenn Sie wissen, welche verwalteten Dienste Sie verwenden können, können Sie festlegen, welche Dienste Sie erstellen müssen.

Anwendungsdienste erstellen und darauf zugreifen

Jeder Dienst wird von einer oder mehreren Arbeitslastinstanzen gehostet, auf die als einzelner Endpunkt oder als Gruppe von Endpunkten zugegriffen werden kann.

Das allgemeine Muster für einen Anwendungsdienst ist im folgenden Diagramm dargestellt. Der Anwendungsdienst wird auf einer Sammlung von Arbeitslastinstanzen bereitgestellt. In diesem Fall kann eine Arbeitslastinstanz eine Compute Engine-VM, ein Google Kubernetes Engine-Cluster (GKE) oder ein anderes Back-End sein, auf dem Code ausgeführt wird. Die Arbeitslastinstanzen sind als eine Reihe von Backends organisiert, die einem Load-Balancer zugeordnet sind.

Das folgende Diagramm zeigt einen generischen Load-Balancer mit einer Reihe von Back-Ends.

Load-Balancer mit Back-Ends.

Um die gewählte Lastverteilung zu erreichen und Failover zu automatisieren, verwenden diese Endpunktgruppen einen Frontend-Load-Balancer. Mit verwalteten Instanzgruppen (MIGs) können Sie die Kapazität des Dienstes elastisch erhöhen oder verringern, indem Sie die Endpunkte, die das Back-End des Load-Balancers bilden, automatisch skalieren. Abhängig von den Anforderungen des Anwendungsdienstes kann der Load Balancer auch Authentifizierung, TLS-Terminierung und andere verbindungsspezifische Dienste bereitstellen.

Umfang des Dienstes festlegen – regional oder global

Entscheiden Sie, ob Ihr Dienst regionale oder globale Ausfallsicherheit benötigt und unterstützen kann. Ein regionaler Softwaredienst kann für die Synchronisierung innerhalb eines regionalen Latenzbudgets konzipiert werden. Ein globaler Anwendungsdienst kann synchrone Failover zwischen Knoten unterstützen, die über Regionen hinweg verteilt sind. Wenn Ihre Anwendung global ist, sollten auch die Dienste, die sie unterstützen, global sein. Wenn für Ihren Dienst jedoch eine Synchronisierung zwischen den Instanzen erforderlich ist, um Failover zu unterstützen, müssen Sie die Latenz zwischen den Regionen berücksichtigen. In Ihrem Fall müssen Sie möglicherweise auf regionale Dienste mit Redundanz in derselben oder in nahegelegenen Regionen zurückgreifen, um eine Synchronisierung mit niedriger Latenz für das Failover zu ermöglichen.

Cloud Load Balancing unterstützt Endpunkte, die entweder in einer einzelnen Region gehostet oder auf mehrere Regionen verteilt sind. Sie können also eine globale, kundenorientierte Ebene erstellen, die mit globalen, regionalen oder hybriden Serviceebenen kommuniziert. Wählen Sie Ihre Dienstbereitstellungen so aus, dass das dynamische Netzwerk-Failover (oder das Load-Balancing über Regionen hinweg) mit dem Resilienzstatus und den Funktionen Ihrer Anwendungslogik übereinstimmt.

Das folgende Diagramm zeigt, wie ein globaler Dienst, der aus regionalen Load-Balancern besteht, Backends in anderen Regionen erreichen kann und so ein automatisches Failover über Regionen hinweg ermöglicht. In diesem Beispiel ist die Anwendungslogik global und das ausgewählte Backend unterstützt die Synchronisierung über Regionen hinweg. Jeder Load Balancer leitet Anfragen in erster Linie an die lokale Region weiter, kann aber ein Failover auf Remote-Regionen durchführen.

Load Balancer mit Back-Ends in verschiedenen Regionen.

  • Ein globales Backend ist eine Sammlung regionaler Backends, auf die von einem oder mehreren Load-Balancern zugegriffen wird.
  • Obwohl die Back-Ends global sind, ist das Frontend jedes Load Balancers regional.
  • Bei diesem Architekturmuster verteilen Load Balancer den Traffic in erster Linie nur innerhalb ihrer Region, können aber auch Traffic auf andere Regionen verteilen, wenn die Ressourcen in der lokalen Region nicht verfügbar sind.
  • Eine Reihe von regionalen Load-Balancer-Frontends, die jeweils von anderen Regionen aus zugänglich sind und jeweils Back-Ends in anderen Regionen erreichen können, bilden einen aggregierten globalen Dienst.
  • Zum Zusammenstellen eines globalen Anwendungspakets, wie unter Globale Anwendungs-Stacks entwerfen erläutert, können Sie DNS-Routing und Systemdiagnosen verwenden, um ein regionsübergreifendes Failover der Front-Ends zu erreichen.
  • Die Load-Balancer-Front-Ends sind selbst über globalen Zugriff aus anderen Regionen zugänglich (nicht im Diagramm dargestellt).

Dasselbe Muster kann verwendet werden, um veröffentlichte Dienste mit globalem Failover einzuschließen. Das folgende Diagramm zeigt einen veröffentlichten Dienst, der globale Back-Ends verwendet.

Load Balancer, auf die von verschiedenen Regionen aus zugegriffen werden kann.

Beachten Sie im Diagramm, dass für den veröffentlichten Dienst ein globales Failover in der Producer-Umgebung implementiert ist. Durch das Hinzufügen von globalem Failover in der Consumer-Umgebung wird die Resilienz gegenüber regionalen Ausfällen in der Consumer-Load-Balancing-Infrastruktur erhöht. Das regionsübergreifende Failover des Dienstes muss sowohl in der Anwendungslogik des Dienstes als auch im Load-Balancing-Design des Diensterstellers implementiert werden. Andere Mechanismen können von den Diensterstellern implementiert werden.

Um zu bestimmen, welches Cloud Load Balancing-Produkt verwendet werden soll, müssen Sie erst einmal festlegen, welche Art von Traffic Ihre Load-Balancer verarbeiten müssen. Beachten Sie die folgenden allgemeinen Regeln:

  • Verwenden Sie einen Application Load Balancer für HTTP(S)-Traffic.
  • Verwenden Sie einen Proxy-Network Load Balancer für Nicht-HTTP(S)-TCP-Traffic. Dieser Proxy-Load-Balancer unterstützt auch TLS-Offloading.
  • Verwenden Sie einen Passthrough-Network-Load-Balancer, um die Client-Quell-IP-Adresse im Header beizubehalten oder zusätzliche Protokolle wie UDP, ESP und ICMP zu unterstützen.

Eine detaillierte Anleitung zur Auswahl des besten Load-Balancers für Ihren Anwendungsfall finden Sie unter Load-Balancer auswählen.

Dienste mit serverlosen Back-Ends

Ein Dienst kann mit serverlosen Back-Ends definiert werden. Das Back-End in der Producer-Umgebung kann in einer serverlosen NEG als Back-End für einen Load-Balancer organisiert werden. Dieser Dienst kann mit Private Service Connect veröffentlicht werden, indem ein Dienstanhang erstellt wird, der dem Frontend des Load-Balancers des Anbieters zugeordnet ist. Der veröffentlichte Dienst kann über Private Service Connect-Endpunkte oder Private Service Connect-Back-Ends genutzt werden. Wenn für den Dienst vom Ersteller initiierte Verbindungen erforderlich sind, können Sie einen Connector für serverlosen VPC-Zugriff verwenden, damit Cloud Run-, App Engine-Standard- und Cloud Run-Funktionsumgebungen Pakete an den internen IPv4-Adressen von Ressourcen in einem VPC-Netzwerk senden. Der serverlose VPC-Zugriff unterstützt auch das Senden von Paketen an andere Netzwerke, die mit dem ausgewählten VPC-Netzwerk verbunden sind.

Methoden für den privaten Zugriff auf Dienste

Ihre Anwendung kann aus verwalteten Diensten von Google, Drittanbieterdiensten von externen Anbietern oder Peer-Gruppen in Ihrer Organisation sowie aus Diensten bestehen, die Ihr Team entwickelt. Einige dieser Dienste sind möglicherweise über das Internet mit öffentlichen IP-Adressen zugänglich. In diesem Abschnitt werden die Methoden beschrieben, mit denen Sie über das private Netzwerk auf diese Dienste zugreifen können. Es gibt die folgenden Diensttypen:

  • Öffentliche Google-APIs
  • Serverlose Google-APIs
  • Veröffentlichte verwaltete Dienste von Google
  • Veröffentlichte verwaltete Dienste von Anbietern und Kollegen
  • Ihre veröffentlichten Dienste

Behalten Sie diese Optionen im Hinterkopf, wenn Sie die folgenden Abschnitte lesen. Je nachdem, wie Sie Ihre Dienste zuweisen, können Sie eine oder mehrere der beschriebenen Optionen für den privaten Zugriff verwenden.

Die Organisation (oder Gruppe innerhalb einer Organisation), die einen Dienst zusammenstellt, veröffentlicht und verwaltet, wird als Dienstersteller bezeichnet. Sie und Ihre Anwendung werden als Dienstnutzer bezeichnet.

Einige verwaltete Dienste werden ausschließlich über den Zugriff auf private Dienste veröffentlicht. Die in Interne Verbindung und VPC-Netzwerk empfohlenen Netzwerkdesigns berücksichtigen Dienste, die mit privatem Dienstzugriff und Private Service Connect veröffentlicht werden.

Eine Übersicht über die Optionen für den privaten Zugriff auf Dienste finden Sie unter Optionen für den privaten Zugriff auf Dienste.

Wir empfehlen, nach Möglichkeit Private Service Connect zu verwenden, um eine Verbindung zu verwalteten Diensten herzustellen. Weitere Informationen zu Bereitstellungsmustern für Private Service Connect finden Sie unter Bereitstellungsmuster für Private Service Connect.

Es gibt zwei Arten von Private Service Connect, und die verschiedenen Dienste können als einer der beiden Typen veröffentlicht werden:

Dienste, die als Private Service Connect-Endpunkte veröffentlicht werden, können direkt von anderen Arbeitslasten genutzt werden. Die Dienste sind auf die Authentifizierung und Resilienz angewiesen, die vom Dienstersteller bereitgestellt werden. Wenn Sie zusätzliche Kontrolle über die Dienstauthentifizierung und ‑ausfallsicherheit wünschen, können Sie Private Service Connect-Back-Ends verwenden, um eine Load-Balancing-Ebene für die Authentifizierung und Ausfallsicherheit im Consumernetzwerk hinzuzufügen.

Das folgende Diagramm zeigt den Zugriff auf Dienste über Private Service Connect-Endpunkte:

Zugriff auf Dienste über Private Service Connect-Endpunkte

Das Diagramm zeigt das folgende Muster:

  • Ein Private Service Connect-Endpunkt wird in der VPC des Nutzers bereitgestellt, wodurch der Dienst des Erstellers für VMs und GKE-Knoten verfügbar ist.
  • Sowohl das Verbraucher- als auch das Produzentennetzwerk müssen in derselben Region bereitgestellt werden.

Im obigen Diagramm sind Endpunkte als regionale Ressourcen dargestellt. Endpunkte sind aufgrund des globalen Zugriffs aus anderen Regionen erreichbar.

Weitere Informationen zu Bereitstellungsmustern finden Sie unter Bereitstellungsmuster für Private Service Connect.

Private Service Connect-Back-Ends verwenden einen Load Balancer, der mit Private Service Connect-NEG-Back-Ends (Netzwerk-Endpunktgruppe) konfiguriert ist. Eine Liste der unterstützten Load Balancer finden Sie unter Private Service Connect-Back-Ends.

Mit Private Service Connect-Back-Ends können Sie die folgenden Back-End-Konfigurationen erstellen:

  • Vom Kunden verwaltete Domains und Zertifikate vor verwalteten Diensten
  • Nutzergesteuertes Failover zwischen verwalteten Diensten in verschiedenen Regionen
  • Zentrale Sicherheitskonfiguration und Zugriffssteuerung für verwaltete Dienste

Im folgenden Diagramm verwendet der globale Load-Balancer eine Private Service Connect-NEG als Backend, um die Kommunikation mit dem Dienstanbieter herzustellen. Es ist keine weitere Netzwerkkonfiguration erforderlich und die Daten werden über das SDN-Fabric von Google übertragen.

Globaler Load-Balancer mit Netzwerk-Endpunktgruppe.

Die meisten Dienste sind für Verbindungen konzipiert, die vom Nutzer initiiert werden. Wenn Dienste Verbindungen vom Dienstersteller aus initiieren müssen, verwenden Sie Private Service Connect-Schnittstellen.

Ein wichtiger Aspekt bei der Bereitstellung des Zugriffs auf private Dienste oder von Private Service Connect ist die Transitivität. Private Service Connect-Nutzerzugriffspunkte sind über Network Connectivity Center erreichbar. Veröffentlichte Dienste sind über eine VPC-Netzwerk-Peering-Verbindung für Consumer-Zugriffspunkte von Private Service Connect oder den Zugriff auf private Dienste nicht erreichbar. Da es keine VPC-übergreifende Transitivität für alle Zugriffspunkte für Dienstnutzer gibt, bestimmt der Ort des Dienstzugriffs-Subnetzes oder der Endpunkte in der VPC-Topologie, ob Sie das Netzwerk für die gemeinsame oder dedizierte Dienstbereitstellung konzipieren.

Optionen wie HA VPN und vom Kunden verwaltete Proxys bieten Methoden, um die transitive Kommunikation zwischen VPCs zu ermöglichen.

Private Service Connect-Endpunkte sind über VPC-Netzwerk-Peering nicht erreichbar. Wenn Sie diese Art von Verbindung benötigen, stellen Sie einen internen Load Balancer und eine Private Service Connect-NEG als Backend bereit, wie im folgenden Diagramm dargestellt:

NEGs verwenden, um Erreichbarkeit zu ermöglichen.

Auf Google APIs kann privat über Private Service Connect-Endpunkte und -Back-Ends zugegriffen werden. Die Verwendung von Endpunkten wird im Allgemeinen empfohlen, da der Google-API-Ersteller Resilienz und zertifikatbasierte Authentifizierung bietet.

Erstellen Sie in jeder VPC, in der auf den Dienst zugegriffen werden muss, einen Private Service Connect-Endpunkt. Da die IP-Adresse des Nutzers eine private globale IP-Adresse ist, ist für jeden Dienst eine einzelne DNS-Zuordnung erforderlich, auch wenn es Endpunktinstanzen in mehreren VPCs gibt, wie im folgenden Diagramm dargestellt:

Private Service Connect mit Google APIs.

Verbrauchsmuster für veröffentlichte Dienste definieren

Veröffentlichte Dienste können an verschiedenen Orten ausgeführt werden: in Ihrem VPC-Netzwerk, in einem anderen VPC-Netzwerk, in einem lokalen Rechenzentrum oder in der Cloud. Unabhängig davon, wo die Dienstarbeitslast ausgeführt wird, greift Ihre Anwendung über einen Zugriffspunkt auf diese Dienste zu, z. B. über einen der folgenden:

  • Eine IP-Adresse in einem Subnetz für den Zugriff auf private Dienste
  • Ein Private Service Connect-Endpunkt
  • Eine VIP für einen Load Balancer, der Private Service Connect-NEGs verwendet

Die Verbraucherzugangspunkte können netzwerkübergreifend freigegeben oder einem einzelnen Netzwerk zugewiesen werden. Entscheiden Sie, ob Sie gemeinsame oder dedizierte Zugriffspunkte für Verbraucher erstellen möchten. Das hängt davon ab, ob Ihre Organisation die Aufgabe, Zugriffspunkte für Verbraucherdienste zu erstellen, an jede Anwendungsgruppe delegiert oder den Zugriff auf Dienste konsolidiert verwaltet.

Die Verwaltung des Dienstzugriffs umfasst die folgenden Aktivitäten:

  • Zugangspunkte erstellen
  • Bereitstellung der Zugangspunkte in einer VPC für den Dienstzugriff, die den entsprechenden Erreichbarkeitstyp hat
  • IP-Adressen und URLs der Consumer-Zugriffspunkte in DNS registrieren
  • Verwalten von Sicherheitszertifikaten und Resilienz für den Dienst im Verbraucherbereich beim Hinzufügen von Load-Balancing vor den Zugriffspunkten für Verbraucher

Für einige Organisationen kann es sinnvoll sein, die Verwaltung des Dienstzugriffs einem zentralen Team zuzuweisen. Andere sind möglicherweise so strukturiert, dass jedes Nutzer- oder Anwendungsteam mehr Unabhängigkeit hat. Ein Nebeneffekt des dedizierten Modus ist, dass einige Elemente repliziert werden. Beispielsweise ist ein Dienst mit mehreren DNS-Namen für jede Anwendungsgruppe registriert und verwaltet mehrere Sätze von TLS-Zertifikaten.

Das in Netzwerksegmentierung und -verbindung für verteilte Anwendungen im Cross-Cloud Network beschriebene VPC-Design ermöglicht die Erreichbarkeit für die Bereitstellung von Dienstzugangspunkten im freigegebenen oder dedizierten Modus. Gemeinsame Zugriffspunkte für Nutzer werden in VPCs für den Dienstzugriff bereitgestellt, auf die von jedem anderen VPC- oder externen Netzwerk aus zugegriffen werden kann. In den Anwendungs-VPCs werden dedizierte Zugriffspunkte für Nutzer bereitgestellt, auf die nur von Ressourcen innerhalb dieser Anwendungs-VPC zugegriffen werden kann.

Der Hauptunterschied zwischen einer VPC für den Dienstzugriff und einer Anwendungs-VPC ist die transitive Konnektivität des Dienstzugriffspunkts, die eine VPC für den Dienstzugriff ermöglicht. VPCs für den Dienstzugriff sind nicht auf das Hosting von Nutzerzugriffspunkten beschränkt. In einer VPC können Anwendungsressourcen sowie gemeinsame Zugriffspunkte für Nutzer gehostet werden. In diesem Fall sollte die VPC als Dienst-VPC konfiguriert und behandelt werden.

Gemeinsamer Zugriff auf verwaltete Dienste

Achten Sie bei allen Methoden für die Dienstnutzung, einschließlich Private Service Connect, darauf, dass Sie die folgenden Aufgaben ausführen:

  • Stellen Sie die Nutzerzugriffspunkte für die Dienste in einer Dienst-VPC bereit. Dienst-VPCs haben eine transitive Erreichbarkeit für andere VPCs.
  • Wenn die VPC für den Dienstzugriff mit HA VPN verbunden ist, bewerben Sie das Subnetz für den Zugriffspunkt des Nutzers als benutzerdefinierte Routenankündigung vom Cloud Router, der über HA VPN mit anderen Netzwerken verbunden ist. Bei Google-APIs werben Sie für die Host-IP-Adresse der API.
  • Aktualisieren Sie die Multicloud-Firewallregeln, um das Subnetz für den Zugriff auf private Dienste zuzulassen.

Achten Sie beim Zugriff auf private Dienste darauf, dass Sie die folgenden zusätzlichen Anforderungen erfüllen können:

  • Benutzerdefinierte Routen in das Netzwerk des Diensterstellers exportieren. Weitere Informationen finden Sie unter Lokale Hosts können nicht mit dem Netzwerk des Diensterstellers kommunizieren.
  • Firewallregeln für eingehenden Traffic erstellen, um das Subnetz für den Zugriff auf private Dienste in den Anwendungs-VPCs zuzulassen
  • Eingehende Firewallregeln erstellen, um das Subnetz für den Zugriff auf private Dienste in der VPC der Dienste zuzulassen

Für den Zugriff auf serverlose Dienste müssen Sie die folgenden Anforderungen erfüllen:

  • Für den Access Connector ist ein dediziertes reguläres /28-Subnetz erforderlich.
  • Cloud Router bietet standardmäßig reguläre Subnetze an
  • Firewallregeln für eingehenden Traffic für alle Subnetze mit VPC-Zugriff in der/den VPC(s) erstellen
  • Multicloud-Firewallregeln aktualisieren, um das Subnetz des VPC-Zugriffs-Connectors zuzulassen
  • Eingangs-Firewallregeln erstellen, um das Subnetz für den Zugriff auf private Dienste in den Anwendungs-VPCs zuzulassen

Zugriff auf dedizierte verwaltete Dienste

Führen Sie die folgenden Aufgaben aus:

  • Stellen Sie in jeder Anwendungs-VPC, in der Zugriff erforderlich ist, eine Weiterleitungsregel für den Dienst bereit, um einen Zugriffspunkt zu erstellen.
  • Erstellen Sie für den Zugriff auf private Dienste Firewallregeln für eingehenden Traffic, um das Subnetz für den Zugriff auf private Dienste in den Anwendungs-VPCs zuzulassen.

Für den Zugriff auf serverlose Dienste müssen Sie die folgenden Anforderungen erfüllen:

  • Für den Access Connector ist ein dediziertes reguläres /28-Subnetz erforderlich.
  • Firewallregeln für eingehenden Traffic erstellen, um das VPC Access Connector-Subnetz in den VPCs der Anwendung zuzulassen

Anwendungs-Stack zusammenstellen

In diesem Abschnitt wird beschrieben, wie Sie ein regionales oder globales Anwendungspaket zusammenstellen.

Regionale Anwendungsstacks entwerfen

Wenn eine Anwendung den Archetypen für regionale oder multiregionale Bereitstellungen folgt, verwenden Sie regionale Anwendungs-Stacks. Regionale Anwendungs-Stacks können als Verkettung regionaler Anwendungsdienstebenen betrachtet werden. Beispiel: Eine regionale Webdienstebene, die mit einer Anwendungsebene in derselben Region kommuniziert, die wiederum mit einer Datenbankebene in derselben Region kommuniziert, ist ein regionales Anwendungs-Stack.

Jede regionale Anwendungsserviceschicht verwendet Load Balancer, um den Traffic auf die Endpunkte der Schicht in dieser Region zu verteilen. Die Zuverlässigkeit wird durch die Verteilung der Backend-Ressourcen auf drei oder mehr Zonen in der Region erreicht.

Anwendungsserviceschichten in anderen CSPs oder in lokalen Rechenzentren sollten in entsprechenden Regionen in den externen Netzwerken bereitgestellt werden. Stellen Sie außerdem veröffentlichte Dienste in der Region des Stacks zur Verfügung. Zum Ausrichten des Anwendungs-Stacks innerhalb einer Region müssen die URLs der Anwendungsdienstebene zu der spezifischen regionalen IP-Adresse des Load-Balancer-Front-Ends aufgelöst werden. Diese DNS-Zuordnungen werden in der entsprechenden DNS-Zone für jeden Anwendungsdienst registriert.

Das folgende Diagramm zeigt einen regionalen Stack mit Active-Standby-Resilienz:

Regionaler Stack mit Active-Standby-Resilienz.

In jeder Region wird in den verschiedenen Cloud-Rechenzentren eine vollständige Instanz des Anwendungsstacks bereitgestellt. Wenn in einer der Anwendungsserviceschichten ein regionaler Fehler auftritt, übernimmt der Stack in der anderen Region die Bereitstellung der gesamten Anwendung. Dieses Failover erfolgt als Reaktion auf die Out-of-Band-Überwachung der verschiedenen Anwendungsserviceebenen.

Wenn für eine der Dienstebenen ein Fehler gemeldet wird, wird das Frontend der Anwendung neu am Backup-Stack verankert. Die Anwendung ist so geschrieben, dass sie auf eine Reihe von regionalen Namenseinträgen verweist, die den regionalen IP-Adressstapel im DNS widerspiegeln. So werden die Verbindungen jeder Ebene der Anwendung in derselben Region aufrechterhalten.

Globale Anwendungs-Stacks entwerfen

Wenn eine Anwendung dem Archetyp für globale Anwendungsbereitstellungen folgt, enthält jede Anwendungsserviceschicht Backends in mehreren Regionen. Wenn Sie Backends in mehreren Regionen einbeziehen, wird der Resilienzpool für die Anwendungsserviceschicht über eine einzelne Region hinaus erweitert. Außerdem werden automatisierte Failover-Erkennung und ‑Reconvergence ermöglicht.

Das folgende Diagramm zeigt einen globalen Anwendungsstack:

Globaler Stack mit einem Hub-Projekt und einem Anwendungsprojekt.

Das obige Diagramm zeigt eine globale Anwendung, die aus den folgenden Komponenten besteht:

  • Dienste, die in lokalen Rechenzentren mit Load-Balancer-Frontends ausgeführt werden. Die Load-Balancer-Zugriffspunkte sind über Cloud Interconnect von der Transit-VPC aus erreichbar.
  • In einer Transit-VPC werden Hybridverbindungen zwischen dem externen Rechenzentrum und der Anwendungs-VPC gehostet.
  • Eine Anwendungs-VPC, in der die Kernanwendung gehostet wird, die auf Arbeitslastinstanzen ausgeführt wird. Diese Arbeitslastinstanzen befinden sich hinter Load-Balancern. Die Load Balancer sind von jeder Region im Netzwerk aus erreichbar und können Back-Ends in jeder Region im Netzwerk erreichen.
  • Eine Dienst-VPC, in der Zugriffspunkte für Dienste gehostet werden, die an anderen Orten ausgeführt werden, z. B. in VPCs von Drittanbietern. Diese Dienstzugriffspunkte sind über die HA VPN-Verbindung zwischen der Dienst-VPC und der Transit-VPC erreichbar.
  • Dienstersteller-VPCs, die von anderen Organisationen oder der primären Organisation gehostet werden, und Anwendungen, die an anderen Standorten ausgeführt werden. Die relevanten Dienste werden über Private Service Connect-Back-Ends erreichbar gemacht, die als globale Back-Ends für regionale Load Balancer bereitgestellt werden, die in der VPC der Dienste gehostet werden. Die regionalen Load Balancer sind von jeder anderen Region aus erreichbar.

Wenn die erstellte Anwendung über das Internet erreichbar sein soll, können Sie einen globalen externen Application Load Balancer hinzufügen, der auf die Anwendungsarbeitslasten in der Anwendungs-VPC verweist (nicht in der Abbildung).

Um ein globales Anwendungspaket zu unterstützen, haben wir globale Back-Ends für jede Anwendungsebene verwendet. So kann die Wiederherstellung nach einem Ausfall aller Backend-Endpunkte in einer Region erfolgen. Jede Region hat ein regionales Load-Balancer-Front-End für jede Anwendungsdienstebene. Wenn ein regionales Failover auftritt, sind die internen regionalen Load-Balancer-Front-Ends regionsübergreifend erreichbar, da sie globalen Zugriff verwenden. Da der Anwendungs-Stack global ist, werden DNS-Routingrichtlinien für die Standortbestimmung verwendet, um das am besten geeignete regionale Frontend für eine bestimmte Anfrage oder einen bestimmten Ablauf auszuwählen. Im Falle eines Frontend-Fehlers können DNS-Systemdiagnosen verwendet werden, um das Failover von einem Frontend zu einem anderen zu automatisieren.

Dienste, die mit Private Service Connect-Back-Ends veröffentlicht werden, profitieren vom globalen Zugriff auf Private Service Connect. Mit dieser Funktion kann ein Private Service Connect-Backend von jeder Region aus erreicht werden. Außerdem werden Unterbrechungen durch Fehler in der Anwendungsserviceschicht verringert. Das bedeutet, dass die Private Service Connect-Back-Ends als globale Back-Ends verwendet werden können, wie unter Umfang des Dienstes festlegen – regional oder global beschrieben.

Privaten Zugriff auf Dienste ermöglichen, die in externen Netzwerken gehostet werden

Möglicherweise möchten Sie einen lokalen Zugriffspunkt für einen Dienst veröffentlichen, der in einem anderen Netzwerk gehostet wird. In diesen Fällen können Sie einen internen regionalen TCP-Proxy-Load-Balancer mit hybriden NEGs verwenden. Sie können einen Dienstersteller erstellen, der lokal oder in anderen Cloud-Umgebungen gehostet wird und für Dienstnutzer (Clients) in Ihrem VPC-Netzwerk verfügbar ist, wie im folgenden Diagramm dargestellt:

Lokaler Zugriffspunkt mit Hybrid-NEGs.

Wenn Sie den Hybriddienst in einem anderen VPC-Netzwerk als dem, in dem der Load Balancer gehostet wird, verfügbar machen möchten, können Sie den Dienst mit Private Service Connect veröffentlichen. Wenn Sie einen Dienstanhang vor Ihrem internen regionalen TCP-Proxy-Load-Balancer platzieren, können Sie Clients in anderen VPC-Netzwerken den Zugriff auf die Hybriddienste ermöglichen, die lokal oder in anderen Cloud-Umgebungen ausgeführt werden.

In einer Cloud-übergreifenden Umgebung ermöglicht die Verwendung eines Hybrid-NEG eine sichere Kommunikation zwischen Anwendungen.

Wenn eine andere Organisation einen Anwendungsdienst veröffentlicht, verwenden Sie eine Hybrid-NEG, um die Abstraktionen für den privaten Zugriff für diesen Dienst zu erweitern. Dieses Szenario wird im folgenden Diagramm veranschaulicht:

Hybrid-NEGs vor Diensten in anderen Netzwerken.

Im obigen Diagramm befindet sich die Anwendungsserviceebene vollständig im benachbarten CSP, der in den nicht ausgegrauten Teilen des Diagramms hervorgehoben ist. Die Hybrid-Load-Balancer werden in Verbindung mit Private Service Connect-Dienstanhängen verwendet, um den externen Anwendungsdienst für die private Nutzung inGoogle Cloudzu veröffentlichen. Die Hybrid-Load Balancer mit Hybrid-NEGs und Private Service Connect-Dienstanhängen befinden sich in einer VPC, die Teil eines Diensterstellerprojekts ist. Dieses Dienstproduzentenprojekt ist in der Regel eine andere VPC als die Transit-VPC, da es sich im administrativen Bereich der Erstellerorganisation oder des Erstellerprojekts befindet und daher von den gemeinsamen Transitdiensten getrennt ist. Die Ersteller-VPC muss nicht über VPC-Peering oder HA VPN mit der Nutzer-VPC (im Diagramm die freigegebene VPC für Dienste) verbunden sein.

Dienstzugriff zentralisieren

Der Dienstzugriff kann in einem VPC-Netzwerk zentralisiert und von anderen Anwendungsnetzwerken aus aufgerufen werden. Das folgende Diagramm zeigt das gängige Muster, das die Zentralisierung der Zugriffspunkte ermöglicht:

Dedizierte VPC für Dienste.

Das folgende Diagramm zeigt alle Dienste, auf die über eine dedizierte Dienst-VPC zugegriffen wird:

Dedizierte VPC für Dienste mit zentralen Load-Balancern.

Wenn Dienste mit Application Load Balancern bereitgestellt werden, können Sie die Anzahl der Load Balancer reduzieren. Verwenden Sie dazu URL-Zuordnungen, um Traffic für verschiedene Dienst-Backends zu steuern, anstatt für jeden Dienst einen anderen Load Balancer zu verwenden. Grundsätzlich könnte ein Anwendungs-Stack vollständig aus einem einzelnen Application Load Balancer plus Dienst-Backends und entsprechenden URL-Zuordnungen bestehen.

Bei dieser Implementierung müssen Sie für die meisten Backend-Typen Hybrid-NEGs in VPCs verwenden. Eine Ausnahme bildet ein Private Service Connect-NEG oder -Backend, wie unter Explizite Verkettung von Google Cloud L7-Load Balancern mit Private Service Connect beschrieben.

Die Verwendung von hybriden NEGs in mehreren VPCs hat den Nachteil, dass für die Backends kein Autohealing und Autoscaling möglich ist. Veröffentlichte Dienste haben bereits einen Load Balancer im Ersteller-Tenant, der Autoscaling bietet. Daher treten die Einschränkungen der hybriden NEGs nur auf, wenn Sie die Load-Balancing-Funktion für Dienstebenen zentralisieren, die nativ zusammengesetzt und nicht aus der Veröffentlichung genutzt werden.

Wenn Sie dieses Dienstnetzwerkmuster verwenden, denken Sie daran, dass die Dienste über eine zusätzliche Load-Balancing-Ebene genutzt werden.

Private Service Connect-Dienstendpunkte sind über VPCs mit Network Connectivity Center-Spokes erreichbar.

Im zentralisierten Modus wird auf der Kundenseite des Dienstes eine zusätzliche Ebene für den Lastenausgleich hinzugefügt. Wenn Sie diesen Modus verwenden, müssen Sie auch Zertifikate, Ausfallsicherheit und zusätzliche DNS-Zuordnungen im Verbraucherprojekt verwalten.

Weitere Hinweise

Dieser Abschnitt enthält Überlegungen zu gängigen Produkten und Diensten, die in diesem Dokument nicht explizit behandelt werden.

Überlegungen zur GKE-Steuerungsebene

Die GKE-Steuerungsebene wird in einem von Google verwalteten Mandantenprojekt bereitgestellt, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Kunden verbunden ist. Da das VPC-Netzwerk-Peering nicht transitiv ist, ist eine direkte Kommunikation mit der Steuerungsebene über eine Hub-and-Spoke-VPC-Peering-Netzwerktopologie nicht möglich.

Bei der Auswahl von GKE-Designoptionen wie zentralisiert oder dezentralisiert ist der direkte Zugriff auf die Steuerungsebene aus Multicloud-Quellen ein wichtiger Aspekt. Wenn GKE in einer zentralen VPC bereitgestellt wird, ist der Zugriff auf die Steuerungsebene cloudübergreifend und innerhalb vonGoogle Cloudmöglich. Wenn GKE jedoch in dezentralen VPCs bereitgestellt wird, ist keine direkte Kommunikation mit der Steuerungsebene möglich. Wenn die Anforderungen einer Organisation zusätzlich zur Übernahme des dezentralen Designmusters den Zugriff auf die GKE-Steuerungsebene erfordern, können Netzwerkadministratoren einen Connect-Agent bereitstellen, der als Proxy fungiert und so die nicht transitive Peering-Beschränkung für die GKE-Steuerungsebene überwindet.

Sicherheit - VPC Service Controls

Bei Arbeitslasten, die sensible Daten involvieren, können Sie mithilfe von VPC Service Controls Dienstperimeter für Ihre VPC-Ressourcen und die von Google verwalteten Dienste konfigurieren und Datenbewegungen über die Perimetergrenze hinweg steuern. VPC Service Controls bietet Ihnen die Möglichkeit, Projekte und Ihr lokales Netzwerk innerhalb eines Perimeters zusammenzufassen, um den Datenzugriff über von Google verwaltete Dienste zu verhindern. Mit Regeln für ein- und ausgehenden Traffic von VPC Service Controls können Sie die Kommunikation zwischen Projekten und Diensten in verschiedenen Dienstperimetern ermöglichen, einschließlich VPC-Netzwerken, die sich nicht innerhalb des Perimeters befinden.

Empfohlene Bereitstellungsarchitekturen, ein umfassender Onboarding-Prozess und Best Practices für den Betrieb finden Sie unter Best Practices für VPC Service Controls für Unternehmen und im Sicherheitsgrundlagen-Blueprint.

DNS für APIs/Dienste

Dienstersteller können Dienste mit Private Service Connect veröffentlichen. Der Dienstersteller kann optional einen DNS-Domainnamen konfigurieren, der dem Dienst zugeordnet werden soll. Wenn ein Domainname konfiguriert ist und ein Dienstnutzer einen Endpunkt erstellt, der auf diesen Dienst abzielt, erstellen Private Service Connect und Service Directory automatisch DNS-Einträge für die in einer privaten DNS-Zone im VPC-Netzwerk des Dienstnutzers.

Nächste Schritte

Beitragende

Autoren:

Weitere Beitragende: