Dienstnetzwerk für verteilte Anwendungen im Cross-Cloud Network

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 Ihnen, das gesamte Dokument einmal zu lesen, bevor Sie die Schritte ausführen.

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

  • Unabhängig davon, ob Sie den einzelnen Dienst selbst erstellen oder einen Drittanbieterdienst nutzen
  • Ob der Dienst global oder regional verfügbar ist
  • Ob der Dienst lokal, von anderen Clouds oder von keinem der beiden Dienste genutzt wird
  • Ob Sie über eine VPC mit freigegebenen Diensten auf den Dienstendpunkt zugreifen oder die Endpunkte über alle relevanten Anwendungs-VPCs verteilen

In diesem Dokument werden die folgenden Schritte beschrieben:

  1. Entscheiden, ob Ihre Anwendung global oder regional ist
  2. Verwaltete Dienste von Drittanbietern auswählen oder eigene Dienste erstellen und veröffentlichen
  3. Privaten Zugriff auf die Dienstendpunkte über einen freigegebenen oder den dedizierten Modus einrichten
  4. Zusammenstellung der Dienste zu Anwendungen, die entweder einem globalen oder 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 treten Einschränkungen aufgrund eingeschränkter VPC-übergreifender Transitivität auf. Wir beschreiben diese Einschränkungen, wenn sie sich auf Designentscheidungen auswirken können.

Legen Sie fest, ob Ihre Anwendung regional oder global ist

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

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

  • Die Verfügbarkeitsanforderungen der Anwendung
  • Der Standort, an dem die Anwendung genutzt wird
  • Kosten

Weitere Informationen finden Sie unter Google Cloud Archetypen für die Bereitstellung.

In dieser Designanleitung wird erläutert, wie die folgenden Bereitstellungsarchetypen unterstützt werden können:

In 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 Ausfallsicherheitsstruktur zu gewährleisten, sollten Sie Dienste, die in verschiedenen CSPs gehostet werden, in CSP-Rechenzentren platzieren, die geografisch beieinander liegen.

Das folgende Diagramm zeigt einen globalen Anwendungs-Stack, der auf Clouds verteilt ist. In verschiedenen CSPs werden verschiedene Anwendungsdienste bereitgestellt. Jeder globale Anwendungsdienst hat Arbeitslastinstanzen in verschiedenen Regionen desselben CSP.

Globaler Anwendungs-Stack, der auf mehrere Clouds verteilt ist

Anwendungsdienste definieren und darauf zugreifen

Zum Zusammenstellen Ihrer Anwendung können Sie vorhandene verwaltete Dienste von Drittanbietern verwenden, eigene Anwendungsdienste erstellen und hosten oder eine Kombination aus beidem verwenden.

Vorhandene verwaltete Dienste von Drittanbietern verwenden

Entscheiden Sie, welche verwalteten Dienste von Drittanbietern für Ihre Anwendung verwendet werden können. Legen Sie fest, welche Dienste als regionale oder globale Dienste erstellt werden. Legen Sie außerdem fest, welche privaten Zugriffsoptionen von jedem Dienst 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 für eine Sammlung von Arbeitslastinstanzen bereitgestellt. (In diesem Fall könnte eine Arbeitslastinstanz eine Compute Engine-VM, ein GKE-Cluster (Google Kubernetes Engine) oder ein anderes Back-End sein, das Code ausführt.) Die Arbeitslastinstanzen sind als eine Reihe von Back-Ends 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.

Diese Gruppen von Endpunkten verwenden einen Front-End-Load-Balancer, um die gewählte Lastverteilung zu erreichen und Failovers zu automatisieren. Mit verwalteten Instanzgruppen (Managed Instance Groups, MIGs) können Sie die Kapazität des Dienstes elastisch erhöhen oder verringern. Dazu skalieren Sie die Endpunkte, die das Back-End des Load-Balancers bilden. Darüber hinaus kann der Load-Balancer abhängig von den Anforderungen des Anwendungsdienstes auch Authentifizierung, TLS-Beendigung und andere verbindungsspezifische Dienste bereitstellen.

Bestimmen Sie den Umfang des Dienstes – regional oder global.

Entscheiden Sie, ob Ihr Dienst regionale oder globale Ausfallsicherheit erfordert und unterstützen kann. Ein regionaler Softwaredienst kann für die Synchronisierung innerhalb eines regionalen Latenzbudgets entwickelt werden. Ein globaler Anwendungsdienst kann synchrone Failovers auf Knoten unterstützen, die über Regionen verteilt sind. Wenn Ihre Anwendung global ist, sollten die Dienste, die sie unterstützen, auch global sein. Wenn Ihr Dienst jedoch die Synchronisierung seiner Instanzen benötigt, um Failover zu unterstützen, müssen Sie die Latenz zwischen Regionen berücksichtigen. In Ihrer Situation müssen Sie sich möglicherweise auf regionale Dienste mit Redundanz in der gleichen oder in der Nähe von Regionen verlassen, um so die Synchronisierung mit niedriger Latenz für den Failover zu unterstützen.

Cloud Load Balancing unterstützt Endpunkte, die entweder in einer einzelnen Region gehostet oder über Regionen verteilt sind. So können Sie eine globale kundenseitige Schicht erstellen, die globale, regionale oder hybride Dienstebenen anspricht. Wählen Sie Ihre Dienstbereitstellungen aus, damit der dynamische Netzwerk-Failover (oder regionsübergreifendes Load-Balancing) auf den Ausfallsicherheitsstatus und die Funktionen Ihrer Anwendungslogik abgestimmt ist.

Das folgende Diagramm zeigt, wie ein globaler Dienst, der aus regionalen Load-Balancern erstellt wird, Back-Ends in anderen Regionen erreichen kann, um auf diese Weise automatisches Failover über Regionen hinweg bereitzustellen. In diesem Beispiel ist die Anwendungslogik global und das ausgewählte Back-End unterstützt die regionsübergreifende Synchronisierung. Jeder Load-Balancer sendet Anfragen in erster Linie an die lokale Region, ein Failover kann jedoch an entfernte Regionen gesendet werden.

Load-Balancer mit Back-Ends in verschiedenen Regionen

  • Ein globales Back-End ist eine Sammlung regionaler Back-Ends, auf die ein oder mehrere Load-Balancer zugreifen.
  • Obwohl die Back-Ends global sind, ist das Front-End jedes Load-Balancers regional.
  • In diesem Architekturmuster verteilen Load-Balancer den Traffic primär nur innerhalb ihrer Region, können ihn aber auch auf andere Regionen ausgleichen, wenn die Ressourcen in der lokalen Region nicht verfügbar sind.
  • Eine Reihe regionaler Load-Balancer-Front-Ends, 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.
  • Auf die Load-Balancer-Front-Ends kann selbst aus anderen Regionen über globalen Zugriff zugegriffen werden (nicht im Diagramm dargestellt).

Mit demselben Muster können auch veröffentlichte Dienste mit globalem Failover eingeschlossen werden. Das folgende Diagramm zeigt einen veröffentlichten Dienst, der globale Back-Ends verwendet.

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

Beachten Sie im Diagramm, dass für den veröffentlichten Dienst ein globales Failover in der Produzentenumgebung implementiert ist. Durch den zusätzlichen globalen Failover in der Nutzerumgebung sind Sie gegen regionale Ausfälle in der Load-Balancing-Infrastruktur des Nutzers geschützt. Der regionsübergreifende Failover des Dienstes muss sowohl in der Dienstanwendungslogik als auch im Load-Balancing-Design des Diensterstellers implementiert werden. Die Dienstersteller können andere Mechanismen implementieren.

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:

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

Eine ausführliche 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. Dazu wird ein Dienstanhang erstellt, der dem Front-End des Producer-Load-Balancers zugeordnet ist. Der veröffentlichte Dienst kann über Private Service Connect-Endpunkte oder Private Service Connect-Back-Ends genutzt werden. Wenn der Dienst vom Ersteller initiierte Verbindungen erfordert, können Sie einen Connector für den serverlosen VPC-Zugriff verwenden, damit Cloud Run-, App Engine-Standard- und Cloud Run-Funktionsumgebungen Pakete an die internen IPv4-Adressen von Ressourcen in einem VPC-Netzwerk senden können. 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 bestehen, die von Google bereitgestellt werden, aus Drittanbieterdiensten, die von externen Anbietern oder ähnlichen Gruppen in Ihrer Organisation bereitgestellt werden, und aus Diensten, die Ihr Team entwickelt. Einige dieser Dienste sind möglicherweise über das Internet mithilfe von ö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
  • Von Google veröffentlichte verwaltete Dienste
  • Verwaltete Dienste von Anbietern und ähnlichen Anbietern veröffentlicht
  • Meine veröffentlichten Dienste

Behalten Sie diese Optionen im Hinterkopf, wenn Sie die nachfolgenden Abschnitte lesen. Je nachdem, wie Sie Ihre Dienste zuweisen, können Sie eine oder mehrere der beschriebenen privaten Zugriffsoptionen 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 mithilfe des Zugriffs auf private Dienste veröffentlicht. Die unter Interne Konnektivität und VPC-Netzwerke empfohlenen Netzwerkdesigns unterstützen 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 Private Zugriffsoptionen für 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 beide Typen veröffentlicht werden:

Als Private Service Connect-Endpunkte veröffentlichte Dienste können direkt von anderen Arbeitslasten genutzt werden. Die Dienste basieren auf der Authentifizierung und Ausfallsicherheit, die vom Ersteller des Dienstes 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 Nutzernetzwerk hinzuzufügen.

Das folgende Diagramm zeigt Dienste, auf die über Private Service Connect-Endpunkte zugegriffen wird:

Auf Dienste über Private Service Connect-Endpunkte zugreifen

Das Diagramm zeigt das folgende Muster:

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

Das obige Diagramm zeigt Endpunkte als regionale Ressourcen. Endpunkte sind aufgrund des globalen Zugriffs von anderen Regionen aus 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:

  • Kundeneigene 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 Back-End, das die Kommunikation mit dem Dienstanbieter herstellt. 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 ausgelegt, die vom Nutzer initiiert werden. Wenn Dienste Verbindungen vom Producer aus initiieren müssen, verwenden Sie Private Service Connect-Schnittstellen.

Ein wichtiger Aspekt bei der Bereitstellung des privaten Dienstzugriffs 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 weder für Private Service Connect noch für Zugriffspunkte privater Dienste erreichbar. Wenn keine Inter-VPC-Transitivität für alle Zugangspunkte von Dienstnutzern vorhanden ist, bestimmt der Standort des Dienstzugriffssubnetzes oder der Endpunkte in der VPC-Topologie, ob Sie das Netzwerk für eine freigegebene oder dedizierte Dienstbereitstellung entwerfen.

Optionen wie HA VPN und vom Kunden verwaltete Proxys bieten Methoden für eine transitive Kommunikation zwischen VPC.

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

Erreichbarkeit mithilfe von NEGs bereitstellen

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

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

Private Service Connect mit Google APIs

Nutzungsmuster 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, nutzt Ihre Anwendung diese Dienste über einen Zugangspunkt wie einen der folgenden:

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

Die Zugangspunkte für Nutzer können von mehreren Netzwerken gemeinsam genutzt oder einem einzelnen Netzwerk zugeordnet werden. Entscheiden Sie, ob Sie freigegebene oder dedizierte Zugangspunkte für Nutzer erstellen möchten. Dabei ist es wichtig, ob Ihre Organisation die Aufgabe, Zugangspunkte für private Dienste zu erstellen, an die einzelnen Anwendungsgruppen delegiert oder den Zugriff auf Dienste konsolidiert verwaltet.

Die Verwaltung des Dienstzugriffs umfasst die folgenden Aktivitäten:

  • Zugangspunkte erstellen
  • Die Zugangspunkte in einer Dienstzugriffs-VPC bereitstellen. Dabei handelt es sich um eine VPC mit dem entsprechenden Erreichbarkeitstyp.
  • IP-Adressen und URLs der Nutzerzugriffspunkte im DNS registrieren
  • Sicherheitszertifikate und Ausfallsicherheit des Dienstes im Nutzerbereich verwalten, wenn Load-Balancing vor den Nutzerzugriffspunkten hinzugefügt wird

Für einige Organisationen kann es sinnvoll sein, die Dienstzugriffsverwaltung einem zentralen Team zuzuweisen, während andere möglicherweise strukturiert sind, um jedem Nutzer oder Anwendungsteam mehr Unabhängigkeit zu geben. Ein Nebeneffekt des Betriebs im dedizierten Modus ist, dass einige der Elemente repliziert werden. Ein Dienst wird beispielsweise von jeder Anwendungsgruppe mit mehreren DNS-Namen registriert und verwaltet mehrere Sätze von TLS-Zertifikaten.

Das unter Netzwerksegmentierung und Konnektivität für verteilte Anwendungen in Cross-Cloud-Netzwerken beschriebene VPC-Design ermöglicht die Erreichbarkeit für die Bereitstellung von Dienstzugriffspunkten in einem freigegebenen oder im dedizierten Modus. Zugangspunkte für freigegebene Nutzer werden in Dienstzugriffs-VPCs bereitgestellt, auf die von jeder anderen VPC oder jedem externen Netzwerk aus zugegriffen werden kann. Dedizierte Nutzerzugriffspunkte werden in Anwendungs-VPCs bereitgestellt, auf die nur über Ressourcen innerhalb dieser Anwendungs-VPC zugegriffen werden kann.

Der Hauptunterschied zwischen einer Dienstzugriffs-VPC und einer Anwendungs-VPC ist die transitive Konnektivität des Dienstzugriffspunkts, die eine Dienstzugriffs-VPC ermöglicht. VPCs für den Dienstzugriff sind nicht auf das Hosten von Zugangspunkten für Nutzer beschränkt. Eine VPC kann Anwendungsressourcen sowie freigegebene Zugangspunkte für Nutzer hosten. In einem solchen Fall sollte die VPC als Dienst-VPC konfiguriert und verwaltet werden.

Zugriff auf freigegebene verwaltete Dienste

Führen Sie für alle Methoden zur Dienstnutzung, einschließlich Private Service Connect, die folgenden Aufgaben aus:

  • Stellen Sie die Zugangspunkte der Dienstnutzer in einer Dienst-VPC bereit. Dienst-VPCs haben vorübergehende Erreichbarkeit zu anderen VPCs.
  • Wenn die Dienstzugriffs-VPC mit HA VPN verbunden ist, bewerben Sie das Subnetz für den Nutzerzugriffspunkt als benutzerdefiniertes Route Advertising vom Cloud Router, der über HA VPN mit anderen Netzwerken verbunden ist. Bieten Sie bei Google APIs die Host-IP-Adresse der API an.
  • Aktualisieren Sie Multi-Cloud-Firewallregeln, um den privaten Diensten Zugriff auf das Subnetz zu gewähren.

Insbesondere für den privaten Dienstzugriff müssen die folgenden zusätzlichen Anforderungen erfüllt sein:

  • Exportieren Sie benutzerdefinierte Routen in das Netzwerk des Diensterstellers. Weitere Informationen finden Sie unter Lokale Hosts können nicht mit dem Netzwerk des Diensterstellers kommunizieren.
  • Erstellen Sie Firewallregeln für eingehenden Traffic, um den privaten Diensten Zugriff auf das Subnetz in den Anwendungs-VPCs zu gewähren.
  • Erstellen Sie Firewallregeln für eingehenden Traffic, damit die privaten Dienste auf das Subnetz der Dienst-VPC zugreifen können

Für den serverlosen Dienstzugriff müssen die folgenden Anforderungen erfüllt sein:

  • Für den Zugriffs-Connector ist ein dediziertes reguläres /28-Subnetz erforderlich
  • Cloud Router bietet reguläre Subnetze standardmäßig an
  • Firewallregeln für eingehenden Traffic erstellen, um alle Subnetze zum Zulassen von VPC-Zugriff in den VPCs zu erstellen
  • Multi-Cloud-Firewallregeln aktualisieren, um das Subnetz des VPC-Zugriffs des Connectors zuzulassen
  • Erstellen Sie Firewallregeln für eingehenden Traffic, um den privaten Diensten Zugriff auf das Subnetz in die Anwendungs-VPC(s) zu gewähren.

Zugriff auf dedizierte verwaltete Dienste

Führen Sie die folgenden Aufgaben aus:

  • Stellen Sie in jeder Anwendungs-VPC, für die Zugriff erforderlich ist, eine Weiterleitungsregel für den Dienst bereit, um einen Zugangspunkt zu erstellen.
  • Erstellen Sie für den privaten Dienstzugriff eine oder mehrere Firewallregeln für eingehenden Traffic, die den Zugriff der privaten Dienste auf das Subnetz in den Anwendungs-VPCs zulassen.

Für den serverlosen Dienstzugriff müssen die folgenden Anforderungen erfüllt sein:

  • Für den Zugriffs-Connector ist ein dediziertes reguläres /28-Subnetz erforderlich
  • Erstellen Sie Firewallregeln für eingehenden Traffic, um das Subnetz des VPC-Zugriffs-Connectors in den Anwendungs-VPCs zuzulassen.

Anwendungs-Stack zusammenstellen

In diesem Abschnitt wird das Zusammenstellen eines regionalen oder globalen Anwendungsstacks beschrieben.

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 Anwendungsdienstebene verwendet Load-Balancer, um den Traffic auf die Endpunkte der Ebene in dieser Region zu verteilen. Zuverlässigkeit wird durch Verteilung der Back-End-Ressourcen auf drei oder mehr Zonen in der Region erreicht.

Anwendungsdienstebenen in anderen CSPs oder 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 aktiver Standby-Resilienz:

Regionaler Stack mit aktiver Standby-Resilienz.

In jeder Region wird in den verschiedenen Cloud-Rechenzentren eine vollständige Instanz des Anwendungspakets bereitgestellt. Wenn auf einer der Anwendungsdienstebenen ein regionaler Ausfall auftritt, übernimmt der Stack in der anderen Region die Bereitstellung der gesamten Anwendung. Dieses Failover erfolgt als Reaktion auf das Out-of-Band-Monitoring der verschiedenen Anwendungsdienstebenen.

Wenn für eine der Dienstebenen ein Fehler gemeldet wird, wird das Front-End der Anwendung wieder im Sicherungsstapel verankert. Die Anwendung wird so geschrieben, dass sie auf eine Reihe regionaler Namenseinträge verweist, die den regionalen IP-Adressstack im DNS widerspiegeln. Dadurch hält jede Ebene der Anwendung ihre Verbindungen innerhalb derselben Region aufrecht.

Globale Anwendungs-Stacks entwerfen

Wenn eine Anwendung dem Archetyp für die globale Anwendungsbereitstellung folgt, umfasst jede Anwendungsdienstebene Back-Ends in mehreren Regionen. Durch das Einbeziehen von Back-Ends in mehreren Regionen wird der Ausfallsicherheitspool für die Anwendungsdienstebene über eine einzelne Region hinaus erweitert. Außerdem wird die automatische Failover-Erkennung und -Rekonvergenz ermöglicht.

Das folgende Diagramm zeigt einen globalen Anwendungsstack:

Globaler Stack mit Hub- und Anwendungsprojekt

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

  • Dienste, die in lokalen Rechenzentren mit Load-Balancer-Front-Ends ausgeführt werden Die Load-Balancer-Zugangspunkte sind über Cloud Interconnect von der Transit-VPC aus erreichbar.
  • Eine Transit-VPC hostet Hybridverbindungen zwischen dem externen Rechenzentrum und der Anwendungs-VPC.
  • Eine Anwendungs-VPC, die die auf Arbeitslastinstanzen ausgeführte Kernanwendung hostet. 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, die Zugangspunkte für Dienste hostet, die an anderen Standorten 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.
  • VPCs der Dienstersteller, die von anderen Organisationen oder der primären Organisation sowie von Anwendungen gehostet werden, die an anderen Standorten ausgeführt werden. Die relevanten Dienste sind über Private Service Connect-Back-Ends erreichbar, die als globale Back-Ends für regionale Load-Balancer bereitgestellt werden, die in der Dienst-VPC 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).

Zur Unterstützung eines globalen Anwendungs-Stacks haben wir globale Back-Ends für jede Anwendungsschicht verwendet. Dies ermöglicht die Wiederherstellung nach einem Ausfall aller Back-End-Endpunkte in einer Region. Jede Region hat ein regionales Load-Balancer-Front-End für jede Anwendungsdienstebene. Bei einem regionalen Failover können die Front-Ends des internen regionalen Load-Balancers regionsübergreifend erreicht werden, da sie globalen Zugriff verwenden. Da das Anwendungspaket global ist, werden Richtlinien für das DNS-Standortrouting verwendet, um das am besten geeignete regionale Frontend für eine bestimmte Anfrage oder einen bestimmten Ablauf auszuwählen. Bei einem Front-End-Fehler können DNS-Systemdiagnosen verwendet werden, um das Failover von einem Front-End 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-Back-End von jeder Region aus erreichbar sein und Störungen durch Ausfälle der Anwendungsdienstebene werden verringert. Das bedeutet, dass die Private Service Connect-Back-Ends als globale Back-Ends genutzt werden können, wie unter Bereich des Dienstes bestimmen – regional oder global beschrieben.

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

Sie können einen lokalen Zugangspunkt 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 Hybrid-NEGs verwenden. Sie können einen Dienstersteller erstellen, der lokal oder in anderen Cloudumgebungen gehostet wird, die für Dienstnutzer (Clients) in Ihrem VPC-Netzwerk verfügbar sind, wie im folgenden Diagramm dargestellt:

Lokaler Zugangspunkt 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 Private Service Connect verwenden, um den Dienst zu 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 einer hybriden NEG eine sichere Kommunikation zwischen Anwendungen.

Wenn eine andere Organisation einen Anwendungsdienst veröffentlicht, verwenden Sie eine Hybrid-NEG, um Abstraktionen für 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 besteht die Anwendungsdienstschicht vollständig aus dem benachbarten CSP, der in den nicht ausgegrauten Teilen des Diagramms hervorgehoben ist. Die Hybrid-Load-Balancer werden in Verbindung mit Anhängen des Private Service Connect-Dienstes als Mechanismus verwendet, um den externen Anwendungsdienst für den privaten Gebrauch innerhalb vonGoogle 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 Diensterstellerprojekt kann in der Regel eine andere VPC als die Transit-VPC sein, da es innerhalb des administrativen Geltungsbereichs der Erstellerorganisation oder des Projekts liegt und daher von den allgemeinen Transit-Diensten getrennt ist. Die Producer-VPC muss nicht über VPC-Peering oder HA VPN mit der Nutzer-VPC verbunden sein (die im Diagramm die freigegebene VPC der Dienste ist).

Dienstzugriff zentralisieren

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

VPC mit dedizierten Diensten

Das folgende Diagramm zeigt alle Dienste, auf die über eine VPC mit dedizierten Diensten zugegriffen wird:

VPC mit dedizierten Diensten mit zentralisierten Load-Balancern

Wenn Dienste ein Frontend mit Application Load Balancern haben, können Sie auf weniger Load Balancer konsolidieren, indem Sie URL-Zuordnungen verwenden, um den Traffic für verschiedene Dienst-Backends zu steuern, anstatt für jeden Dienst unterschiedliche Load Balancer zu verwenden. Prinzipiell kann ein Anwendungspaket vollständig aus einem einzelnen Application Load Balancer sowie Dienst-Back-Ends und entsprechenden URL-Zuordnungen bestehen.

In dieser Implementierung müssen Sie für die meisten Back-End-Typen Hybrid-NEGs in VPCs verwenden. Die Ausnahme ist eine Private Service Connect-NEG oder ein Private Service Connect-Back-End, wie unter Explizite Verkettung von Google Cloud L7-Load-Balancern mit Private Service Connect beschrieben.

Die Verwendung von Hybrid-NEGs in verschiedenen VPCs geht auf Kosten der weggefallenen automatischen Reparatur und des Autoscalings für die Back-Ends ein. Veröffentlichte Dienste haben bereits einen Load-Balancer im Producer-Mandanten, der Autoscaling bereitstellt. Daher stoßen Sie nur dann auf die Einschränkungen der hybriden NEGs, wenn Sie die Load-Balancing-Funktion für Dienstebenen zentralisieren, die nativ zusammengesetzt sind, anstatt sie aus der Veröffentlichung zu nutzen.

Denken Sie bei Verwendung dieses Dienstnetzwerkmusters daran, dass die Dienste über eine zusätzliche Load-Balancing-Ebene genutzt werden.

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

Der zentralisierte Modus fügt dem Dienst eine Load-Balancing-Ebene auf der Nutzerseite hinzu. Wenn Sie diesen Modus verwenden, müssen Sie auch Zertifikate, Ausfallsicherheit und zusätzliche DNS-Zuordnungen im Nutzerprojekt 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 der VPC des Kunden verbunden ist. Da 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 Berücksichtigung von GKE-Designoptionen wie einem zentralen oder dezentralisierten Zugriff auf die Steuerungsebene von Multi-Cloud-Quellen ist ein wichtiger Aspekt. Wenn GKE in einer zentralisierten VPC bereitgestellt wird, ist der Zugriff auf die Steuerungsebene cloudübergreifend und innerhalb vonGoogle Cloudverfügbar. Wenn GKE jedoch in dezentralisierten VPCs bereitgestellt wird, ist keine direkte Kommunikation mit der Steuerungsebene möglich. Wenn die Anforderungen einer Organisation neben dem dezentralisierten Designmuster auch Zugriff auf die GKE-Steuerungsebene erfordern, können Netzwerkadministratoren einen Verbindungs-Agent bereitstellen, der als Proxy fungiert. Dadurch wird die Einschränkung des nicht transitiven Peerings für die GKE-Steuerungsebene aufgehoben.

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 VPC Service Controls-Regeln für eingehenden und ausgehenden Traffic können Projekte und Dienste in verschiedenen Dienstperimetern kommunizieren (einschließlich VPC-Netzwerke, die sich nicht innerhalb des Perimeters befinden).

Empfohlene Bereitstellungsarchitekturen, einen umfassenden Onboardingprozess und Best Practices für den Betrieb finden Sie unter Best Practices für VPC Service Controls für Unternehmen und Blueprint zu Sicherheitsgrundlagen.

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: