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 von ausgewählten oder erstellten Komponentendiensten zusammenstellen. Wir empfehlen Ihnen, das gesamte Dokument einmal durchzulesen, bevor Sie die Schritte ausführen.

In diesem Dokument werden die folgenden Entscheidungen beschrieben:

  • Ob Sie den einzelnen Dienst selbst erstellen oder einen Drittanbieterdienst in Anspruch nehmen
  • Ob der Dienst global oder regional verfügbar ist
  • Ob der Dienst lokal, aus anderen Clouds oder von beiden Quellen genutzt wird
  • Ob Sie über eine VPC mit freigegebenen Diensten auf den Dienstendpunkt zugreifen oder die Endpunkte über alle relevanten Anwendungs-VPCs verteilen

Dieses Dokument führt Sie durch die folgenden Schritte:

  1. Entscheiden, ob Ihre Anwendung global oder regional ist
  2. Von Drittanbietern verwaltete Dienste auswählen oder eigene Dienste erstellen und veröffentlichen
  3. Privaten Zugriff auf die Dienstendpunkte im freigegebenen oder dedizierten Modus einrichten
  4. Dienste in Anwendungen zusammenstellen, 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 einer eingeschränkten VPC-übergreifenden Transitivität auf. 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 Archetyp für regionale oder globale Bereitstellungen benötigen. Sie können regionale Ausfallsicherheit erreichen, indem Sie Lasten auf die Zonen einer Region verteilen. Sie können globale Ausfallsicherheit erreichen, indem Sie die Lasten auf 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 Archetypen für Bereitstellungen in Google Cloud.

In dieser Designanleitung wird erläutert, wie die folgenden Bereitstellungs-Archetypen unterstützt werden:

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. Platzieren Sie Dienste, die von verschiedenen CSPs gehostet werden, in CSP-Rechenzentren, die geografisch nahe beieinander liegen, um für eine konsistente Ausfallsicherheitsstruktur zu sorgen.

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

Globales Anwendungspaket, verteilt auf Clouds

Anwendungsdienste definieren und darauf zugreifen

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

Vorhandene von Drittanbietern verwaltete Dienste verwenden

Entscheiden Sie, welche verwalteten Drittanbieterdienste Sie für Ihre Anwendung verwenden können. Bestimmen Sie, welche als regionale oder globale Dienste erstellt werden. Ermitteln Sie außerdem, welche privaten Zugriffsoptionen jeder Dienst unterstützt.

Wenn Sie wissen, welche verwalteten Dienste Sie verwenden können, können Sie bestimmen, 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 kann 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 Frontend-Load-Balancer, um die ausgewählte Lastverteilung zu erreichen und Failovers zu automatisieren. Mithilfe verwalteter 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, automatisch. Abhängig von den Anforderungen des Anwendungsdienstes kann der Load-Balancer auch Authentifizierung, TLS-Beendigung und andere verbindungsspezifische Dienste bereitstellen.

Umfang des Dienstes festlegen – regional oder global

Entscheiden Sie, ob Ihr Dienst regionale oder globale Ausfallsicherheit unterstützen kann. Ein regionaler Softwaredienst kann für die Synchronisierung innerhalb eines regionalen Latenzbudgets entwickelt werden. Ein globaler Anwendungsdienst kann synchrone Failovers über Knoten hinweg unterstützen, die über Regionen verteilt sind. Wenn Ihre Anwendung global ist, sollten Sie möglicherweise auch die Dienste, die sie unterstützen, global sein. Wenn Ihr Dienst jedoch für ein Failover eine Synchronisierung zwischen den Instanzen benötigt, müssen Sie die Latenz zwischen den Regionen berücksichtigen. In Ihrer Situation müssen Sie sich möglicherweise auf regionale Dienste mit Redundanz in der gleichen oder in einer nahe gelegenen Region verlassen, damit eine Synchronisierung mit niedriger Latenz für ein Failover unterstützt wird.

Cloud Load Balancing unterstützt Endpunkte, die entweder in einer einzelnen Region gehostet oder über Regionen verteilt werden. Auf diese Weise können Sie eine globale kundenseitige Ebene erstellen, die globale, regionale oder hybride Dienstebenen anspricht. Wählen Sie Ihre Dienstbereitstellungen aus, um sicherzustellen, dass das dynamische Netzwerk-Failover (oder das regionenübergreifende Load-Balancing) dem Ausfallsicherheitsstatus und den Funktionen Ihrer Anwendungslogik entspricht.

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

Load-Balancer mit Back-Ends in verschiedenen Regionen.

  • Ein globales Backend ist eine Sammlung regionaler Backends, 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 hauptsächlich nur innerhalb ihrer Region. Sie können den Traffic 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 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 Front-Ends des Load-Balancers sind selbst von anderen Regionen aus über globalen Zugriff zugänglich (nicht im Diagramm dargestellt).

Dasselbe Muster kann verwendet werden, um veröffentlichte Dienste mit globalem Failover einzubeziehen. 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 erkennen, dass für den veröffentlichten Dienst ein globales Failover in der Producer-Umgebung implementiert ist. Das zusätzliche globale Failover in der Nutzerumgebung ermöglicht Widerstandsfähigkeit gegen regionale Ausfälle in der Load-Balancing-Infrastruktur des Nutzers. Der regionenübergreifende Failover des Dienstes muss sowohl in der Dienstanwendungslogik 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-Auslagerung.
  • 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 Nutzerumgebung kann in einer serverlosen NEG als Back-End zu einem Load-Balancer organisiert werden. Um diesen Dienst mit Private Service Connect zu veröffentlichen, erstellen Sie einen Dienstanhang, der dem Frontend des Ersteller-Load-Balancers 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 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, Diensten von Drittanbietern von externen Anbietern oder Gruppen ähnlicher Apps in Ihrer Organisation und 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 folgende Diensttypen:

  • Öffentliche Google APIs
  • Serverlose Google APIs
  • Veröffentlichte verwaltete Dienste von Google
  • Veröffentlichte verwaltete Dienste von Anbietern und ähnlichen Anbietern
  • 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 mit dem Zugriff auf private Dienste veröffentlicht. Die unter Interne Verbindungen 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 Verbindungen 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. Die verschiedenen Dienste können als jeder Typ 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 die Authentifizierung und Ausfallsicherheit des Dienstes zusätzlich steuern möchten, können Sie mit Private Service Connect-Back-Ends eine Load-Balancing-Ebene für die Authentifizierung und Ausfallsicherheit im Nutzernetzwerk hinzufü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:

  • In der Nutzer-VPC wird ein Private Service Connect-Endpunkt bereitgestellt, wodurch der Erstellerdienst für VMs und GKE-Knoten verfügbar ist.
  • Die Nutzer- und Erstellernetzwerke müssen in derselben Region bereitgestellt werden.

Das obige Diagramm zeigt Endpunkte als regionale Ressourcen. Endpunkte sind aufgrund des globalen Zugriffs von 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-Backends können Sie die folgenden Backend-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, der eine Netzwerk-Endpunktgruppe verwendet.

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

Ein wichtiger Faktor bei der Bereitstellung des Zugriffs auf private Dienste oder von Private Service Connect ist die Transitivität. Veröffentlichte Dienste sind im Allgemeinen nicht über eine VPC-Netzwerk-Peering-Verbindung oder über das Network Connectivity Center erreichbar. Der Standort des Dienstzugriffssubnetzes oder der Endpunkte in der VPC-Topologie bestimmt, ob Sie das Netzwerk für die freigegebene oder dedizierte Bereitstellung von Diensten entwerfen.

Optionen wie HA-VPN und vom Kunden verwaltete Proxys bieten Methoden für die transitive Kommunikation zwischen VPCs.

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

Erreichbarkeit mithilfe von NEGs

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 Ausfallsicherheit und zertifikatbasierte 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 Endpunktinstanzen in mehreren VPCs vorhanden sind, wie im folgenden Diagramm dargestellt:

Private Service Connect mit Google APIs

Dienstverbrauchsmuster definieren

Dienste können an einer Vielzahl von 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, z. B. einen der folgenden:

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

Die Nutzerzugriffspunkte können für mehrere Netzwerke verwendet oder einem einzelnen Netzwerk zugeordnet werden. Entscheiden Sie, ob gemeinsame oder dedizierte Nutzerzugriffspunkte erstellt werden sollen, je nachdem, ob Ihre Organisation die Aufgabe der Erstellung von Nutzerdienst-Zugangspunkten an jede Anwendungsgruppe delegiert oder den Zugriff auf Dienste konsolidiert verwaltet.

Die Verwaltung des Dienstzugriffs umfasst die folgenden Aktivitäten:

  • Zugangspunkte erstellen
  • Zugangspunkte in einer VPC mit der entsprechenden Erreichbarkeit bereitstellen
  • IP-Adressen und URLs der Nutzerzugriffspunkte im DNS registrieren
  • Verwalten von Sicherheitszertifikaten und Ausfallsicherheit für den Dienst im Nutzerbereich, 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 so strukturiert sind, dass jedem Nutzer- oder Anwendungsteam mehr Unabhängigkeit geboten wird. Ein Nebenprodukt des Arbeitens im dedizierten Modus besteht darin, dass einige der Elemente repliziert werden. Beispielsweise wird ein Dienst 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 einem cloudübergreifende Netzwerk beschriebene VPC-Design ermöglicht die Bereitstellung von Dienstzugriffspunkten entweder im freigegebenen oder im dedizierten Modus. finden Sie weitere Informationen. Freigegebene Zugangspunkte für Nutzer werden in Dienst-VPCs bereitgestellt, auf die über jede andere VPC oder ein externes Netzwerk zugegriffen werden kann. Dedizierte Nutzerzugriffspunkte 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 transitiven Konnektivität des Dienstzugriffspunkts, die eine Dienst-VPC ermöglicht. Dienst-VPCs sind nicht auf das Hosting von Nutzerzugriffspunkten beschränkt. Eine VPC kann Anwendungsressourcen sowie gemeinsam genutzte Nutzerzugriffspunkte hosten. In einem solchen Fall sollte die VPC als Dienst-VPC konfiguriert und gehandhabt werden.

Zugriff auf gemeinsam genutzte verwaltete Dienste

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

  • Die Zugangspunkte für Dienstnutzer in einer Dienst-VPC bereitstellen. Dienst-VPCs sind vorübergehend zu anderen VPCs erreichbar.
  • Bieten Sie das Subnetz für den Nutzer-Zugangspunkt als benutzerdefiniertes Route Advertisement vom Cloud Router an, das ü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 das Subnetz für den Zugriff auf private Dienste zuzulassen.

Insbesondere für den Zugriff auf private Dienste müssen die folgenden zusätzlichen Anforderungen erfüllt werden:

  • Exportieren Sie benutzerdefinierte Routen zum 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 den Zugriff auf das Subnetz in die Anwendungs-VPCs zu ermöglichen
  • Erstellen Sie Firewallregeln für eingehenden Traffic, um dem Subnetz der privaten Dienste den Zugriff auf die Dienst-VPC zu ermöglichen.

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

  • Für den Zugriffs-Connector ist ein dediziertes /28-Subnetz erforderlich
  • Cloud Router bewirbt standardmäßig reguläre Subnetze
  • Erstellen Sie Firewallregeln für eingehenden Traffic für alle zulässigen VPC-Zugriffssubnetze innerhalb der VPC(s)
  • Multi-Cloud-Firewallregeln aktualisieren, um das Connector-Subnetz für VPC-Zugriff zuzulassen
  • Erstellen Sie eine oder mehrere Firewallregeln für eingehenden Traffic, um den Zugriff der privaten Dienste auf das Subnetz in die Anwendungs-VPC(s) 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 Zugangspunkt zu erstellen.
  • Erstellen Sie für den Zugriff auf private Dienste Firewallregeln für eingehenden Traffic, um den Zugriff der privaten Dienste auf das Subnetz für den Zugriff auf die Anwendungs-VPCs zuzulassen.

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

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

Anwendungs-Stack zusammenstellen

In diesem Abschnitt wird die Erstellung 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. Die Zuverlässigkeit wird erreicht, indem die Back-End-Ressourcen auf drei oder mehr Zonen in der Region verteilt werden.

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 Aktiv-Standby-Ausfallsicherheit:

Regionaler Stack mit Aktiv-Standby-Ausfallsicherheit.

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

Wird ein Fehler für eine der Dienstebenen gemeldet, wird das Frontend der Anwendung wieder im Sicherungsstack verankert. Die Anwendung wird so geschrieben, dass sie auf eine Reihe von regionalen Namenseinträgen verweist, die den regionalen IP-Adressstack im DNS widerspiegeln. So behält jede Ebene der Anwendung ihre Verbindungen in derselben Region bei.

Globale Anwendungs-Stacks entwerfen

Wenn eine Anwendung dem Archetyp für globale Anwendungsbereitstellungen folgt, enthält jede Anwendungsdienstebene Back-Ends in mehreren Regionen. Wenn Sie Back-Ends in mehreren Regionen einschließen, wird der Ausfallsicherheitspool für die Anwendungsdienstebene über eine einzelne Region hinaus erweitert und eine automatische Failover-Erkennung und Rekonvergenz ermöglicht.

Das folgende Diagramm zeigt ein globales Anwendungspaket:

Globaler Stack mit einem Hub-Projekt und Anwendungsprojekt.

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

  • Dienste, die in lokalen Rechenzentren mit Load-Balancer-Front-Ends ausgeführt werden. Die Zugangspunkte des Load-Balancers 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 aus jeder Region im Netzwerk 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.
  • Dienstersteller-VPCs, die von anderen Organisationen oder der primären Organisation und Anwendungen gehostet werden, die an anderen Standorten ausgeführt werden. Die relevanten Dienste werden ü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 Anwendungspakets haben wir globale Back-Ends für jede Anwendungsebene verwendet. Dies ermöglicht die Wiederherstellung nach einem Ausfall aller Back-End-Endpunkte in einer Region. Jede Region hat ein regionales Load-Balancer-Frontend für jede Anwendungsdienstebene. Bei einem regionalen Failover können die Front-Ends des internen regionalen Load-Balancers regionsübergreifend erreicht werden, da sie den globalen Zugriff verwenden. Da das Anwendungspaket global ist, werden Routingrichtlinien für die DNS-Standortbestimmung verwendet, um das am besten geeignete regionale Frontend für eine bestimmte Anfrage oder einen bestimmten Ablauf auszuwählen. Bei einem Frontend-Fehler können DNS-Systemdiagnosen verwendet werden, um den 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 diesem Feature kann ein Private Service Connect-Backend von jeder Region aus erreichbar sein und Unterbrechungen durch Ausfälle der Anwendungsdienstebene werden verringert. Dies bedeutet, dass die Private Service Connect-Back-Ends als globale Back-Ends genutzt werden können, wie unter Umfang des Dienstes bestimmen – regional oder global beschrieben.

Privaten Zugriff auf Dienste gewähren, die in externen Netzwerken gehostet werden

Vielleicht möchten Sie 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 mithilfe von Hybrid-NEGs verwenden. Sie können einen Dienst erstellen, der lokal oder in anderen Cloud-Umgebungen gehostet wird, die Clients in Ihrem VPC-Netzwerk zur Verfügung stehen. Dies ist im folgenden Diagramm dargestellt:

Lokaler Zugangspunkt mit Hybrid-NEGs.

Wenn Sie den Hybriddienst in einem anderen VPC-Netzwerk als dem VPC-Netzwerk verfügbar machen möchten, das den Load Balancer hostet, 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 Hybrid-NEG eine sichere Kommunikation zwischen Anwendungen.

Wenn eine andere Organisation einen Anwendungsdienst veröffentlicht, verwenden Sie eine hybride NEG, um die Abstraktionen 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 besteht die Anwendungsdienstebene vollständig im benachbarten CSP, was in den nicht ausgegrauten Teilen des Diagramms hervorgehoben ist. 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 in Google Cloud zu 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 sein als die Transit-VPC, da sie im Verwaltungsbereich der Erstellerorganisation oder des Erstellerprojekts liegt und daher von den gemeinsamen Transitdiensten getrennt ist. Die Producer-VPC muss nicht über VPC-Peering oder HA-VPN mit der Nutzer-VPC verbunden sein (im Diagramm die freigegebene Services-VPC).

Dienstzugriff zentralisieren

Der Zugriff auf Dienste kann in einem VPC-Netzwerk zentralisiert und von anderen Anwendungsnetzwerken aus aufgerufen werden. Das folgende Diagramm zeigt das allgemeine 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 mit Anwendungs-Load-Balancern bereitgestellt werden, können Sie auf weniger Load-Balancer konsolidieren. Dazu verwenden Sie URL-Zuordnungen, um den Traffic für verschiedene Dienst-Back-Ends zu steuern, anstatt für jeden Dienst verschiedene Load-Balancer zu verwenden. Prinzipiell könnte ein Anwendungsstack vollständig aus einem einzelnen Anwendungs-Load-Balancer plus Dienst-Back-Ends und entsprechenden URL-Zuordnungen bestehen.

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

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

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

Verwenden Sie das Proxy-Load-Balancing, um die Skalierungsvorteile der Spoke-VPC-Konnektivität des Network Connectivity Centers über VPCs zu nutzen und gleichzeitig eine transitive Konnektivität zu veröffentlichten Diensten über die Proxy-Load-Balancer zu bieten.

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

Diese mangelnde Transitivität kann durch die Bereitstellung von Proxy-Load-Balancern mit den nicht transitiven Ressourcen, die als Hybrid-NEGs verarbeitet werden, überwindet werden. Auf diese Weise können wir Proxy-Load-Balancer vor den Dienst-Front-Ends 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 Centers weitergegeben werden. Diese Weitergabe ermöglicht die Erreichbarkeit über das Network Connectivity Center der nicht transitiven Ressourcen über die Proxy-Load-Balancer.

Der zentralisierte Modus fügt eine Load-Balancing-Ebene auf der Nutzerseite des Dienstes 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 das VPC-Netzwerk-Peering nicht transitiv ist, ist die direkte Kommunikation mit der Steuerungsebene über eine Hub-and-Spoke-VPC-Peering-Netzwerktopologie nicht möglich.

Wenn Sie GKE-Designoptionen wie zentralisierte oder dezentralisierte GKE-Designoptionen in Betracht ziehen, ist der direkte Zugriff von Multi-Cloud-Quellen auf die Steuerungsebene ein wichtiger Faktor. Wenn GKE in einer zentralisierten VPC bereitgestellt wird, ist der Zugriff auf die Steuerungsebene cloudübergreifend und innerhalb von 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 Übernahme des dezentralisierten Designmusters auch Zugriff auf die GKE-Steuerungsebene erfordern, können Netzwerkadministratoren einen Connect-Agent bereitstellen, der als Proxy und damit 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 den Regeln für eingehenden und ausgehenden Traffic von VPC Service Controls können Projekte und Dienste in verschiedenen Dienstperimetern kommunizieren (einschließlich VPC-Netzwerken, die sich nicht innerhalb der Perimeter).

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 Security Foundations. Entwurf.

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: