Dienstnetzwerk für verteilte Anwendungen im Cross-Cloud Network

Last reviewed 2024-05-31 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 Ihnen, das gesamte Dokument durchzulesen, bevor Sie mit den Schritten fortfahren.

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 in keiner der beiden Umgebungen genutzt wird.
  • Ob Sie über ein VPC mit freigegebenen Diensten auf den Dienstendpunkt zugreifen oder die Endpunkte über alle relevanten Anwendungs-VPCs verteilen

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

  1. Festlegen, 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 entweder im freigegebenen oder dedizierten Modus einrichten
  4. Die 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 eingeschränkten 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

Ermitteln Sie, ob die Kunden der von Ihnen erstellten Anwendung einen regionalen oder globalen Bereitstellungsarchetyp benötigen. Sie können die regionale Ausfallsicherheit erhöhen, indem Sie die Lasten auf die Zonen einer Region verteilen. Sie können die globale Ausfallsicherheit erhöhen, indem Sie die Last auf mehrere Regionen verteilen.

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

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

Weitere Informationen finden Sie unter Google Cloud-Bereitstellungsmuster.

In diesem Designleitfaden wird beschrieben, wie die folgenden Bereitstellungsmuster unterstützt werden:

In einer cloudübergreifenden verteilten Anwendung können verschiedene Dienste dieser Anwendung von verschiedenen Cloud-Serviceanbietern (Cloud Service Providers, CSPs) oder privaten Rechenzentren bereitgestellt werden. Um eine einheitliche Resilienzstruktur zu gewährleisten, sollten Sie Dienste, die bei verschiedenen Cloud-Dienstanbietern gehostet werden, in Rechenzentren des jeweiligen Anbieters platzieren, die sich geografisch nahe beieinander befinden.

Das folgende Diagramm zeigt einen globalen Anwendungsstack, der über mehrere Clouds verteilt ist und verschiedene Anwendungsdienste in verschiedenen Cloud-Serviceanbietern bereitgestellt werden. Jeder globale Anwendungsservice hat Arbeitslastinstanzen in verschiedenen Regionen desselben Cloud-Serviceanbieters.

Globaler Anwendungs-Stack, der über mehrere Clouds verteilt ist.

Anwendungsdienste definieren und darauf zugreifen

Sie können vorhandene verwaltete Dienste von Drittanbietern verwenden, Ihre eigenen Anwendungsdienste erstellen und hosten oder eine Kombination aus beiden verwenden.

Vorhandene verwaltete Dienste von Drittanbietern verwenden

Entscheiden Sie, welche verwalteten Dienste von Drittanbietern Sie für Ihre Anwendung verwenden können. Ermitteln Sie, welche als regionale oder globale Dienste ausgeführt werden. Außerdem sollten Sie herausfinden, welche Optionen für den privaten Zugriff die einzelnen Dienste unterstützen.

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 Anwendungsservice 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 Gruppe von Back-Ends organisiert, die einem Load Balancer zugeordnet sind.

Das folgende Diagramm zeigt einen generischen Load Balancer mit mehreren Back-Ends.

Load Balancer mit Back-Ends

Um die ausgewä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. Je nach Anforderungen des Anwendungsdienstes kann der Load Balancer außerdem 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 über Knoten hinweg unterstützen, die über Regionen verteilt sind. Wenn Ihre Anwendung global ist, sollten auch die sie unterstützenden Dienste global sein. Wenn für Ihren Dienst jedoch eine Synchronisierung zwischen den Instanzen erforderlich ist, um einen Failover zu unterstützen, müssen Sie die Latenz zwischen den Regionen berücksichtigen. In Ihrem Fall müssen Sie möglicherweise regionale Dienste mit Redundanz in derselben oder in einer nahe gelegenen Region verwenden, 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 über Regionen verteilt werden. So können Sie eine globale kundenorientierte Schicht erstellen, die mit globalen, regionalen oder hybriden Dienstschichten kommuniziert. Wählen Sie Ihre Dienstbereitstellungen so aus, dass das dynamische Netzwerk-Failover (oder das Load Balancing über Regionen hinweg) mit dem Ausfallsicherheitsstatus 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 regionenübergreifendes Failover ermöglicht. In diesem Beispiel ist die Anwendungslogik global und das ausgewählte Backend unterstützt die regionsübergreifende Synchronisierung. Jeder Load Balancer sendet Anfragen in erster Linie an die lokale Region, kann aber ein Failover auf Remote-Regionen ausführen.

Load Balancer mit Back-Ends in verschiedenen Regionen

  • Ein globales Back-End ist eine Sammlung regionaler Back-Ends, auf die über einen oder mehrere Load Balancer zugegriffen wird.
  • Die Back-Ends sind zwar global, das Frontend jedes Load Balancers ist jedoch regional.
  • Bei diesem Architekturmuster verteilen Load Balancer den Traffic hauptsächlich nur innerhalb ihrer Region, können aber auch den Traffic auf andere Regionen ausgleichen, wenn die Ressourcen in der lokalen Region nicht verfügbar sind.
  • Eine Reihe regionaler Load Balancer-Frontends, auf die jeweils von anderen Regionen aus zugegriffen werden kann und die jeweils Back-Ends in anderen Regionen erreichen können, bilden einen 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 über andere Regionen mit globalem Zugriff zugegriffen werden (nicht im Diagramm dargestellt).

Mit demselben Muster können Sie veröffentlichte Dienste mit globalem Failover einschließen. Das folgende Diagramm zeigt einen veröffentlichten Dienst, der globale Back-Ends verwendet.

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

Im Diagramm ist zu sehen, dass für den veröffentlichten Dienst in der Produktionsumgebung ein globaler Failover implementiert ist. Durch das Hinzufügen eines globalen Failover in der Kundenumgebung wird die Resilienz gegenüber regionalen Ausfällen in der Load Balancing-Infrastruktur des Kunden erhöht. Der regionsübergreifende Failover des Dienstes muss sowohl in der Logik der Dienstanwendung als auch im Load Balancing-Design des Diensterstellers implementiert werden. Andere Mechanismen können von den Dienstanbietern 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-Netzwerk-Load Balancer für TCP-Traffic, der nicht HTTP(S) ist. Dieser Proxy-Load Balancer unterstützt auch TLS-Offload.
  • 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 detaillierte Anleitung zur Auswahl des für Ihren Anwendungsfall am besten geeigneten Load Balancers 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 Produktionsumgebung 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 mit dem Frontend des Load Balancers des Diensterstellers verknüpft 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 Functions-Umgebungen 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 und Diensten bestehen, die von Ihrem Team entwickelt werden. Auf einige dieser Dienste kann möglicherweise über das Internet mit öffentlichen IP-Adressen zugegriffen werden. In diesem Abschnitt werden die Methoden beschrieben, mit denen Sie über das private Netzwerk auf diese Dienste zugreifen können. Es gibt folgende Diensttypen:

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

Berücksichtigen Sie diese Optionen beim Lesen der folgenden Abschnitte. 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 Dienstanbieter 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 Konnektivität und VPC-Netzwerk empfohlenen Netzwerkdesigns sind für Dienste geeignet, die mit dem Zugriff auf private Dienste 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.

Wir empfehlen, wann immer möglich, Private Service Connect für die Verbindung zu verwalteten Diensten zu verwenden. 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 beruhen auf der Authentifizierung und Ausfallsicherheit, die vom Dienstanbieter bereitgestellt wird. Wenn Sie die Dienstauthentifizierung und -ausfallsicherheit weiter steuern möchten, können Sie Private Service Connect-Back-Ends verwenden, um eine Load Balancing-Ebene für Authentifizierung und Ausfallsicherheit im Kundennetzwerk hinzuzufügen.

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

Zugriff auf Dienste über Private Service Connect-Endpunkte

Das Diagramm zeigt das folgende Muster:

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

Im vorherigen Diagramm sind Endpunkte als regionale Ressourcen dargestellt. Endpunkte sind dank 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:

  • 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, über das die Kommunikation mit dem Dienstanbieter hergestellt wird. 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 der Nutzer initiiert. Wenn Dienste Verbindungen vom Ersteller initiieren müssen, verwenden Sie Private Service Connect-Schnittstellen.

Ein wichtiger Aspekt bei der Bereitstellung des Zugriffs auf private Dienste oder Private Service Connect ist die Transitivität. Veröffentlichte Dienste sind in der Regel nicht über eine VPC-Netzwerk-Peering-Verbindung oder über das Network Connectivity Center erreichbar. Die Position des Subnetzes oder der Endpunkte für den Dienstzugriff in der VPC-Topologie bestimmt, ob Sie das Netzwerk für die gemeinsame oder die dedikierte Bereitstellung von Diensten entwerfen.

Mit Optionen wie HA-VPN und vom Kunden verwalteten Proxys können Sie die transitive Kommunikation zwischen VPCs ermöglichen.

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

NEGs zur Erreichbarkeit verwenden

Der Zugriff auf Google APIs kann über Private Service Connect-Endpunkte und ‑Back-Ends privat erfolgen. Die Verwendung von Endpunkten wird generell empfohlen, da der Google API-Produzent Resilienz und eine 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 Dienste definieren

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 Zugriffspunkt, z. B. einen der folgenden:

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

Die Zugangspunkte für Endnutzer können für mehrere Netzwerke freigegeben oder einem einzelnen Netzwerk zugewiesen werden. Entscheiden Sie, ob Sie freigegebene oder spezielle Zugriffspunkte für Endnutzer erstellen möchten, je nachdem, ob Ihre Organisation die Aufgabe zum Erstellen von Zugriffspunkten für Endnutzerdienste an jede Anwendungsgruppe delegiert oder den Zugriff auf Dienste zentral verwaltet.

Die Verwaltung des Dienstzugriffs umfasst die folgenden Aktivitäten:

  • Zugangspunkte erstellen
  • Die Zugangspunkte in einem VPC mit der entsprechenden Erreichbarkeit bereitstellen
  • IP-Adressen und URLs der Kundenzugangspunkte im DNS registrieren
  • Verwaltung von Sicherheitszertifikaten und Ausfallsicherheit für den Dienst im Nutzerbereich, wenn vor den Zugriffspunkten der Nutzer ein Load Balancing hinzugefügt wird

Für einige Organisationen kann es sinnvoll sein, die Verwaltung des Dienstzugriffs einem zentralen Team zuzuweisen, während andere so strukturiert sein können, dass jedem Nutzer- oder Anwendungsteam mehr Unabhängigkeit gegeben wird. Ein Nebeneffekt des Betriebs im dedizierten Modus ist, dass einige der Elemente repliziert werden. Beispiel: Ein Dienst wird von jeder Anwendungsgruppe mit mehreren DNS-Namen registriert und verwaltet mehrere TLS-Zertifikate.

Das VPC-Design, das im Artikel Netzwerksegmentierung und ‑verbindung für verteilte Anwendungen im Cross-Cloud Network beschrieben wird, ermöglicht die Erreichbarkeit für die Bereitstellung von Dienstzugangspunkten entweder im freigegebenen oder im dedizierten Modus. Freigegebene Zugangspunkte für Endnutzer werden in Dienst-VPCs bereitgestellt, auf die von jeder anderen VPC oder jedem externen Netzwerk aus zugegriffen werden kann. Spezielle Kundenzugangspunkte werden in Anwendungs-VPCs bereitgestellt, auf die nur von Ressourcen innerhalb dieser Anwendungs-VPC zugegriffen werden kann.

Der Hauptunterschied zwischen einer Dienst-VPC und einer Anwendungs-VPC besteht in der Dienstzugriffspunkt-transitiven Konnektivität, die eine Dienst-VPC ermöglicht. Dienst-VPCs sind nicht auf das Hosten von Kundenzugangspunkten beschränkt. Eine VPC kann Anwendungsressourcen sowie freigegebene Kundenzugangspunkte hosten. In einem solchen Fall sollte die VPC als Dienst-VPC konfiguriert und behandelt werden.

Gemeinsam genutzter Zugriff auf verwaltete Dienste

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

  • Stellen Sie die Nutzerzugriffspunkte für die Dienste in einer Dienst-VPC bereit. Dienst-VPCs haben eine transitive Erreichbarkeit zu anderen VPCs.
  • Bieten Sie das Subnetz für den Kundenzugangspunkt als benutzerdefiniertes Route Advertisement vom Cloud Router an, der über HA VPN mit anderen Netzwerken verbunden ist. Geben Sie für Google APIs die Host-IP-Adresse der API an.
  • Aktualisieren Sie die Multi-Cloud-Firewallregeln, um dem Subnetz für den Zugriff auf private Dienste den Zugriff zu erlauben.

Für den Zugriff auf private Dienste müssen Sie außerdem die folgenden zusätzlichen Anforderungen erfüllen:

  • 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 den Eingang, um dem Subnetz für den Zugriff auf private Dienste den Zugriff auf die VPCs der Anwendung zu ermöglichen.
  • Erstellen Sie Eingangs-Firewallregeln, um dem Subnetz für den Zugriff auf private Dienste den Zugriff auf das VPC der Dienste zu ermöglichen.

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

  • Für den Zugriffs-Connector ist ein eigenes reguläres /28-Subnetz erforderlich
  • Cloud Router bietet standardmäßig reguläre Subnetze an
  • Erstellen Sie Firewallregeln für den eingehenden Traffic, um den Zugriff auf das VPC-Subnetz innerhalb der VPCs zuzulassen.
  • Aktualisieren Sie die Multi-Cloud-Firewallregeln, um dem VPC-Zugriffs-Connector-Subnetz den Zugriff zu erlauben.
  • Erstellen Sie Eingangs-Firewallregeln, um dem Subnetz für den Zugriff auf private Dienste den Zugriff auf die VPCs der Anwendung zu ermöglichen.

Spezieller Zugriff auf verwaltete Dienste

Führen Sie die folgenden Aufgaben aus:

  • Implementieren Sie in jeder Anwendungs-VPC, in der Zugriff erforderlich ist, eine Weiterleitungsregel für den Dienst, um einen Zugriffspunkt zu erstellen.
  • Erstellen Sie für den Zugriff auf private Dienste Firewallregeln für den eingehenden Traffic, um den privaten Diensten den Zugriff auf das Subnetz in den VPCs der Anwendung zu ermöglichen.

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

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

Anwendungs-Stack zusammenstellen

In diesem Abschnitt wird beschrieben, wie Sie einen regionalen oder globalen Anwendungsstack 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 Anwendungsdienstebene verwendet Load Balancer, um den Traffic auf die Endpunkte der Ebene in dieser Region zu verteilen. Die Zuverlässigkeit wird durch die Verteilung der Backend-Ressourcen auf drei oder mehr Zonen in der Region erreicht.

Anwendungsdienstebenen in anderen Cloud-Dienstanbietern oder Rechenzentren vor Ort sollten in entsprechenden Regionen in den externen Netzwerken bereitgestellt werden. Außerdem müssen Sie veröffentlichte Dienste in der Region des Stacks verfügbar machen. 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 für jeden Anwendungsdienst in der entsprechenden DNS-Zone registriert.

Das folgende Diagramm zeigt einen regionalen Stack mit Ausfallsicherheit durch Aktiv-Standby:

Regionaler Stack mit Aktiv-Standby-Ausfallsicherheit

In jeder Region wird eine vollständige Instanz des Anwendungsstacks in den verschiedenen Cloud-Rechenzentren bereitgestellt. Wenn in einer der Anwendungsserviceebenen ein regionaler Fehler 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 Anwendungsserviceebenen.

Wenn für eine der Dienstebenen ein Fehler gemeldet wird, wird das Frontend der Anwendung wieder an den Sicherungsstack angedockt. Die Anwendung ist so geschrieben, dass sie auf eine Reihe regionaler Namenseinträge verweist, die den regionalen IP‑Adress-Stack im DNS widerspiegeln, sodass jede Schicht der Anwendung ihre Verbindungen innerhalb derselben Region aufrechterhält.

Globale Anwendungs-Stacks entwerfen

Wenn eine Anwendung dem Archetyp für die globale Anwendungsbereitstellung folgt, umfasst jede Anwendungsdienstebene Backends in mehreren Regionen. Wenn Sie Backends in mehreren Regionen einbeziehen, wird der Resilienzpool für die Anwendungsserviceebene über eine einzelne Region hinaus erweitert und es wird eine automatische Failover-Erkennung und -Wiederherstellung ermöglicht.

Das folgende Diagramm zeigt einen globalen Anwendungsstack:

Globaler Stack mit einem Hub- 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-Zugangspunkte sind über Cloud Interconnect vom Transit-VPC aus erreichbar.
  • Eine Transit-VPC hostet Hybridverbindungen zwischen dem externen Rechenzentrum und der Anwendungs-VPC.
  • Eine Anwendungs-VPC, die die Kernanwendung hostet, 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, die Zugriffspunkte für Dienste hostet, die an anderen Orten ausgeführt werden, z. B. in VPCs von Drittanbietern. Diese Dienstzugangspunkte sind über die HA-VPN-Verbindung zwischen der Dienst-VPC und der Transit-VPC erreichbar.
  • VPCs von Dienstausstellern, die von anderen Organisationen oder der Hauptorganisation 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 im 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).

Zur Unterstützung eines globalen Anwendungsstapels haben wir für jede Anwendungsebene globale Back-Ends verwendet. So ist eine Wiederherstellung nach einem Ausfall aller Backend-Endpunkte in einer Region möglich. Jede Region hat ein regionales Load Balancer-Front-End für jede Anwendungsdienstebene. Bei einem regionalen Failover können die internen regionalen Load Balancer-Front-Ends regionsübergreifend erreicht werden, da sie den 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. Bei einem Frontend-Ausfall 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 über Private Service Connect. Mit dieser Funktion kann ein Private Service Connect-Backend von jeder Region aus erreicht werden. Außerdem werden Unterbrechungen durch Ausfälle der Anwendungsdienstebene verringert. Das bedeutet, dass Private Service Connect-Back-Ends wie unter Umfang des Dienstes – regional oder global beschrieben als globale Back-Ends verwendet werden können.

Privaten Zugriff auf in externen Netzwerken gehostete Dienste gewähren

Sie möchten möglicherweise 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 hybriden NEGs verwenden. Sie können einen Dienst erstellen, der lokal oder in anderen Cloud-Umgebungen gehostet wird und für Clients in Ihrem VPC-Netzwerk verfügbar ist, wie im folgenden Diagramm dargestellt:

Lokaler Zugangspunkt mit Hybrid-NEGs

Wenn Sie den Hybriddienst in einem anderen VPC-Netzwerk als dem veröffentlichen möchten, in dem der Load Balancer gehostet wird, 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 einer hybriden NEG eine sichere Kommunikation zwischen Anwendungen.

Wenn eine andere Organisation einen Anwendungsdienst veröffentlicht, verwenden Sie eine hybride NEG, um die Abstraktion des privaten Zugriffs für diesen Dienst zu erweitern. Dieses Szenario wird im folgenden Diagramm veranschaulicht:

Hybrid-NEGs vor Diensten in anderen Netzwerken

Im vorherigen Diagramm ist die Anwendungsdienstebene vollständig im benachbarten CSP zusammengesetzt, was in den nicht ausgegrauten Bereichen des Diagramms hervorgehoben wird. Die Hybrid Load Balancer werden in Verbindung mit Private Service Connect-Dienstanhängen als Mechanismus verwendet, um den externen Anwendungsdienst für den privaten Verbrauch innerhalb von Google Cloud zu veröffentlichen. Die Hybrid Load Balancer mit Hybrid-NEGs und Private Service Connect-Dienstanhängen befinden sich in einer VPC, die zu einem Diensterstellerprojekt gehört. Dieses Dienstanbieterprojekt ist in der Regel ein anderes VPC als das Transit-VPC, da es in den Verwaltungsbereich der Erstellerorganisation oder des Erstellerprojekts fällt und daher von den gemeinsamen Transit-Diensten getrennt ist. Die Producer-VPC muss nicht über VPC-Peering oder HA-VPN mit der Nutzer-VPC verbunden sein (im Diagramm die freigegebene VPC für Dienste).

Zugriff auf Dienste zentralisieren

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

VPC für spezielle Dienste.

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

VPC für dedizierte Dienste mit zentralen Load Balancern

Wenn Dienste mit Application Load Balancern vorangestellt sind, können Sie weniger Load Balancer verwenden, indem Sie mithilfe von URL-Zuordnungen den Traffic für verschiedene Dienst-Backends steuern, anstatt für jeden Dienst einen anderen Load Balancer zu verwenden. Im Prinzip kann ein Anwendungsstack vollständig aus einem einzigen Application Load Balancer sowie Dienst-Back-Ends und entsprechenden URL-Zuordnungen bestehen.

Bei dieser Implementierung müssen Sie für die meisten Back-End-Typen Hybrid-NEGs in VPCs verwenden. Eine Ausnahme bilden Private Service Connect-NEGs oder ‑Back-Ends, wie unter Ausdrückliche Verknüpfung von Google Cloud L7 Load Balancern mit Private Service Connect beschrieben.

Die Verwendung hybrider NEGs in VPCs geht zu Lasten der automatischen Fehlerbehebung und des Autoscalings für die Backends. Veröffentlichte Dienste haben bereits einen Load Balancer im Ersteller-Tenant, der das Autoscaling bereitstellt. Daher treten die Einschränkungen der hybriden NEGs nur auf, wenn Sie die Load Balancing-Funktion für Dienstebenen zentralisieren, die nativ erstellt und nicht aus der Veröffentlichung bezogen werden.

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

Mit Proxy-Load Balancing können Sie die Vorteile der VPC-Spoke-Konnektivität des Network Connectivity Center über VPCs hinweg nutzen und gleichzeitig eine transitive Konnektivität zu veröffentlichten Diensten über die Proxy-Load Balancer bereitstellen.

Private Service Connect-Dienstendpunkte und Weiterleitungsregeln für den Zugriff auf private Dienste sind über VPCs von Network Connectivity Center-Spokes nicht erreichbar. Ebenso sind Netzwerke hinter Hybridverbindungen (Cloud Interconnect oder HA-VPN) nicht über VPCs von Network Connectivity Center erreichbar, da dynamische Routen nicht über Network Connectivity Center weitergegeben werden.

Dieser Mangel an Transitivität kann durch die Bereitstellung von Proxy-Load Balancern mit nicht transitiven Ressourcen als Hybrid-NEGs überwunden werden. So können wir Proxy-Load Balancer vor den Dienst-Frontends und vor den Arbeitslasten bereitstellen, die über die Hybridverbindungen erreichbar sind.

Die Proxy-Front-Ends des Load Balancers werden in VPC-Subnetzen bereitgestellt, die über Spoke-VPCs des Network Connectivity Center weitergegeben werden. Diese Weiterleitung ermöglicht die Erreichbarkeit der nicht transitiven Ressourcen über das Network Connectivity Center über die Proxy-Load Balancer.

Im zentralen Modus wird eine Load Balancing-Ebene auf der Kundenseite des Dienstes 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 ausdrücklich behandelt werden.

GKE-Steuerungsebene

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

Bei der Auswahl von GKE-Designoptionen wie zentral oder dezentral ist der direkte Zugriff auf die Steuerungsebene aus Multi-Cloud-Quellen ein wichtiger Aspekt. Wenn GKE in einer zentralen VPC bereitgestellt wird, ist der Zugriff auf die Steuerungsebene in allen Clouds und in Google Cloud verfügbar. Wenn GKE jedoch in dezentralisierten VPCs bereitgestellt wird, ist keine direkte Kommunikation mit der Steuerungsebene möglich. Wenn die Anforderungen einer Organisation neben der Verwendung des dezentralen Designmusters auch Zugriff auf die GKE-Steuerungsebene erfordern, können Netzwerkadministratoren einen Connect-Agenten bereitstellen, der als Proxy dient. So wird die Einschränkung des nichttransitiven Peerings zur 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 den Regeln für ein- und ausgehenden Traffic von VPC Service Controls können Sie die Kommunikation zwischen Projekten und Diensten in verschiedenen Dienstperimetern zulassen, einschließlich VPC-Netzwerken, die sich nicht innerhalb des Perimeters befinden.

Empfohlene Bereitstellungsarchitekturen, einen umfassenden Onboarding-Prozess und Best Practices für den Betrieb finden Sie unter Best Practices für VPC Service Controls für Unternehmen und 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: