Übersicht über Netzwerk-Endpunktgruppen mit Hybridkonnektivität

Cloud Load Balancing unterstützt Load-Balancing-Traffic zu Endpunkten, die über Google Cloud hinausgehen, z. B. lokale Rechenzentren und andere öffentliche Clouds, die Sie über Hybridkonnektivität erreichen können.

Eine Hybridstrategie ist eine pragmatische Lösung, mit der Sie Ihr Unternehmen an wechselnde Marktbedürfnisse anpassen und Ihre Anwendungen schrittweise modernisieren können. Dies kann eine temporäre Hybridbereitstellung sein, um die Migration zu einer modernen cloudbasierten Lösung zu ermöglichen, oder eine dauerhafte Bereitstellung der IT-Infrastruktur Ihres Unternehmens.

Mit der Einrichtung des Hybrid-Load-Balancings können Sie außerdem die Vorteile der Netzwerkfunktionen von Cloud Load Balancing für Dienste nutzen, die in Ihrer vorhandenen Infrastruktur außerhalb von Google Cloud ausgeführt werden.

Hybrid-Load-Balancing wird auf den folgenden Google Cloud-Load-Balancern unterstützt:

Die Konfiguration von lokalen und anderen Cloud-Diensten entspricht grundsätzlich dem anderer Cloud Load Balancing-Back-Ends. Der Hauptunterschied besteht darin, dass Sie für die Konfiguration der Endpunkte dieser Back-Ends eine Hybridkonnektivitäts-NEG verwenden. Die Endpunkte müssen gültige IP:port-Kombinationen sein, die Ihr Load Balancer mithilfe von Hybridkonnektivitätsprodukten wie Cloud VPN oder Cloud Interconnect erreichen kann.

Anwendungsfall: Traffic an einen lokalen Standort oder eine andere Cloud weiterleiten

Der einfachste Anwendungsfall für die Verwendung von Hybrid-NEGs ist das Routing von Traffic von einem Google Cloud-Load-Balancer zu einem lokalen Standort oder zu einer anderen Cloud-Umgebung. Clients können Traffic entweder aus dem öffentlichen Internet, von Google Cloud oder von einem lokalen Client aus generieren.

Öffentliche Clients

Sie können einen externen Application Load Balancer mit einem Hybrid-NEG-Backend verwenden, um den Traffic von externen Clients an ein Backend lokal oder in einem anderen Cloud-Netzwerk weiterzuleiten. Sie können auch die folgenden Mehrwert-Netzwerkfunktionen für Ihre Dienste lokal oder in anderen Cloud-Netzwerken aktivieren:

  • Mit dem globalen externen Application Load Balancer und dem klassischen Application Load Balancer können Sie:

    • Verwenden Sie die globale Edge-Infrastruktur von Google, um Nutzerverbindungen näher am Nutzer zu beenden und somit die Latenz zu verringern.
    • Schützen Sie Ihren Dienst mit Google Cloud Armor, einem Edge-DDoS-Sicherheitsprodukt für alle Dienste, auf die über einen externen Application Load Balancer zugegriffen wird.
    • Aktivieren Sie Ihren Dienst, um die Zustellung mithilfe von Cloud CDN zu optimieren. Mit Cloud CDN können Sie Inhalte in der Nähe Ihrer Nutzer im Cache speichern. Cloud CDN bietet Funktionen wie Cache-Entwertung und Cloud CDN-signierte URLs.
    • Verwenden Sie von Google verwaltete SSL-Zertifikate. Sie können Zertifikate und private Schlüssel wiederverwenden, die Sie bereits für andere Google Cloud-Produkte verwenden. Sie müssen somit keine separaten Zertifikate verwalten.

    Das folgende Diagramm zeigt eine Hybridbereitstellung mit einem externen Application Load Balancer.

    Hybridkonnektivität mit einem globalen externen Application Load Balancer.
    Hybridkonnektivität mit einem globalen externen Application Load Balancer (zum Vergrößern klicken)

    In diesem Diagramm gelangt Traffic von Clients im öffentlichen Internet über einen Load Balancer von Google Cloud wie den externen Application Load Balancer in Ihr privates lokales Netzwerk oder in ein Cloud-Netzwerk. Sobald der Traffic den Load-Balancer erreicht, können Sie Edge-Netzwerkdienste wie den DDoS-Schutz von Google Cloud Armor oder die IAP-Nutzerauthentifizierung (Identity-Aware Proxy) anwenden.

  • Mit dem regionalen externen Application Load Balancer können Sie externen Traffic an Endpunkte weiterleiten, die sich in derselben Google Cloud-Region wie die Ressourcen des Load Balancers befinden. Verwenden Sie diesen Load-Balancer, wenn Sie Inhalte nur über eine bestimmte Standortbestimmung bereitstellen müssen, um beispielsweise Compliance-Bestimmungen zu erfüllen, oder wenn die Standard-Netzwerkdienststufe gewünscht wird.

Wie die Anfrage weitergeleitet wird (ob an ein Google Cloud-Backend oder an einen lokalen/Cloud-Endpunkt) hängt davon ab, wie Ihre URL-Zuordnung konfiguriert ist. Abhängig von Ihrer URL-Zuordnung wählt der Load-Balancer einen Backend-Dienst für die Anfrage aus. Wenn der ausgewählte Backend-Dienst mit einer Hybridkonnektivitäts-NEG konfiguriert wurde (nur für Endpunkte außerhalb von Google Cloud), leitet der Load-Balancer den Traffic über Cloud VPN oder Cloud Interconnect an das vorgesehene externe Ziel weiter.

Interne Clients (in Google Cloud oder lokal)

Sie können auch eine hybride Bereitstellung für Clients innerhalb von Google Cloud einrichten. In diesem Fall stammt der Clienttraffic aus dem Google Cloud-VPC-Netzwerk, Ihrem lokalen Netzwerk oder aus einer anderen Cloud und wird an Endpunkte lokal oder in anderen Cloud-Netzwerken weitergeleitet.

Der regionale interne Application Load Balancer ist ein regionaler Load Balancer. Das bedeutet, dass er Traffic nur an Endpunkte innerhalb derselben Google Cloud-Region wie die Ressourcen des Load Balancers weiterleiten kann. Der regionenübergreifende interne Application Load Balancer ist ein multiregionaler Load Balancer, der Traffic auf Backend-Dienste verteilen kann, die global verteilt sind.

Das folgende Diagramm zeigt eine Hybridbereitstellung mit einem regionalen internen Application Load Balancer.

Hybridkonnektivität mit regionalen internen Application Load Balancern.
Hybridkonnektivität mit regionalen internen Application Load Balancern (zum Vergrößern klicken)

Anwendungsfall: Migration zu Cloud

Durch die Migration eines vorhandenen Dienstes in die Cloud können Sie lokale Kapazität freigeben und die Kosten und den Aufwand für die Wartung der lokalen Infrastruktur reduzieren. Sie können vorübergehend eine Hybridbereitstellung einrichten, die Ihnen die Weiterleitung von Traffic sowohl zu Ihrem derzeitigen lokalen Dienst als auch zu einem entsprechenden Endpunkt des Google Cloud-Dienstes ermöglicht.

Das folgende Diagramm veranschaulicht diese Einrichtung mit einem internen Application Load Balancer.

Zu Google Cloud migrieren
Zu Google Cloud migrieren (zum Vergrößern klicken)

Wenn Sie einen internen Aoolication Load Balancer zur Verarbeitung interner Clients verwenden, können Sie den Load Balancer für Google Cloud so konfigurieren, dass die gewichtete Trafficaufteilung zum Aufteilen von Traffic auf die beiden Dienste verwendet wird. Bei der Trafficaufteilung können Sie mit dem Senden von 0 % des Traffics an den Google Cloud-Dienst und von 100 % an den lokalen Dienst beginnen. Anschließend können Sie den Anteil des an den Google Cloud-Dienst gesendeten Traffics schrittweise erhöhen. Schließlich senden Sie 100 % des Traffics an den Google Cloud-Dienst und deaktivieren den lokalen Dienst.

Hybridarchitektur

In diesem Abschnitt werden die Load-Balancing-Architektur und die Ressourcen beschrieben, die zum Konfigurieren einer hybriden Load-Balancing-Bereitstellung erforderlich sind.

Die Konfiguration von lokalen und anderen Cloud-Diensten entspricht grundsätzlich dem anderer Cloud Load Balancing-Back-Ends. Der Hauptunterschied besteht darin, dass Sie für die Konfiguration der Endpunkte dieser Back-Ends eine Hybridkonnektivitäts-NEG verwenden. Die Endpunkte müssen gültige IP:port-Kombinationen sein, die Ihre Clients über Hybridkonnektivität erreichen können, z. B. Cloud VPN oder Cloud Interconnect.

Die folgenden Diagramme zeigen die Google Cloud-Ressourcen, die zum Aktivieren des Hybrid-Load Balancings für externe Application Load Balancer und interne regionale Application Load Balancer erforderlich sind.

Globales externes HTTP(S)

Ressourcen des globalen externen Application Load Balancers für Hybridkonnektivität.
Ressourcen des globalen externen Application Load Balancers für Hybridkonnektivität (zum Vergrößern anklicken)

Regionales externes HTTP(S)

Ressourcen des regionalen externen Application Load Balancers für Hybridkonnektivität.
Ressourcen des regionalen externen Application Load Balancers für Hybridkonnektivität (zum Vergrößern anklicken)

Regionales internes HTTP(S)

Ressourcen des regionalen internen Application Load Balancers für Hybridkonnektivität.
Ressourcen des internen regionalen Application Load Balancers für Hybridkonnektivität (zum Vergrößern anklicken)

Regionaler interner Proxy

Regionale interne Proxy-Network Load Balancer-Ressourcen für Hybridkonnektivität.
Ressourcen des regionalen internen Proxy-Network Load Balancers für Hybridkonnektivität (zum Vergrößern anklicken)

Regional oder global

Das Routing von Cloud Load Balancing hängt vom Bereich des konfigurierten Load-Balancers ab:

Externer Application Load Balancer und externer Proxy-Network Load Balancer. Diese Load Balancer können je nach verwendeter Netzwerkstufe entweder für globales oder regionales Routing konfiguriert werden. Sie erstellen das Hybrid-NEG-Backend des Load Balancers in derselben Region, in der die Hybridkonnektivität konfiguriert wurde. Endpunkte, die nicht aus Google Cloud stammen, müssen ebenfalls entsprechend konfiguriert werden, um das umgebungsbasierte Load Balancing zu nutzen.

Regionenübergreifender interner Application Load Balancer und regionenübergreifender interner Proxy-Network Load Balancer. Dies ist ein multiregionaler Load Balancer, der Traffic auf Backend-Dienste verteilen kann, die global verteilt sind. Sie erstellen das Hybrid-NEG-Backend des Load Balancers in derselben Region, in der die Hybridkonnektivität konfiguriert wurde. Endpunkte, die nicht aus Google Cloud stammen, müssen ebenfalls entsprechend konfiguriert werden, um das umgebungsbasierte Load Balancing zu nutzen.

Interner Application Load Balancer und regionaler interner Proxy-Network Load Balancer. Dies sind regionale Load Balancer. Das heißt, sie können Traffic nur an Endpunkte innerhalb derselben Region wie der Load-Balancer weiterleiten. Die Load Balancer-Komponenten müssen in der Region konfiguriert werden, in der die Hybridkonnektivität konfiguriert wurde. Standardmäßig müssen sich Clients, die auf den Load Balancer zugreifen, ebenfalls in derselben Region befinden. Wenn Sie jedoch den globalen Zugriff aktivieren, können Clients aus jeder Region auf den Load Balancer zugreifen.

Wenn beispielsweise das Cloud VPN-Gateway oder der Cloud Interconnect-VLAN-Anhang in REGION_A konfiguriert ist, müssen die vom Load-Balancer erforderlichen Ressourcen (z. B. Backend-Dienst, Hybrid-NEG oder Weiterleitungsregel) in der REGION_A-Region erstellt werden. Standardmäßig müssen sich Clients, die auf den Load Balancer zugreifen, ebenfalls in der Region REGION_A befinden. Wenn Sie jedoch den globalen Zugriff aktivieren, können Clients aus jeder Region auf den Load Balancer zugreifen.

Anforderungen an die Netzwerkverbindung

Bevor Sie eine Bereitstellung mit Hybrid-Load-Balancing konfigurieren, müssen Sie die folgenden Ressourcen eingerichtet haben:

  • Google Cloud-VPC-Netzwerk: Ein in Google Cloud konfiguriertes VPC-Netzwerk. Dies ist das VPC-Netzwerk, das zum Konfigurieren von Cloud Interconnect / Cloud VPN und Cloud Router verwendet wird. Dies ist auch das gleiche Netzwerk, in dem Sie die Load Balancing-Ressourcen erstellen (Weiterleitungsregel, Ziel-Proxy, Backend-Dienst usw.). Die IP-Adressen und IP-Adressbereiche für lokale, andere Cloud- und Google Cloud-Subnetze dürfen sich nicht überschneiden. Bei Überschneidung von IP-Adressen haben Subnetzrouten Vorrang vor Remote-Verbindungen.

  • Hybridkonnektivität. Ihre Google Cloud-Umgebung, lokale Umgebung oder sonstige Cloud-Umgebung muss über Hybridkonnektivität verbunden sein. Dafür werden entweder Cloud Interconnect-VLAN-Anhänge oder Cloud VPN-Tunnel mit Cloud Router verwendet. Wir empfehlen die Verwendung einer Verbindung mit Hochverfügbarkeit. Ein Cloud Router, der für das globale dynamische Routing aktiviert ist, erkennt den spezifischen Endpunkt über BGP und programmiert ihn in Ihrem Google Cloud-VPC-Netzwerk. Regionales dynamisches Routing wird nicht unterstützt. Statische Routen werden ebenfalls nicht unterstützt.

    Cloud Interconnect/Cloud VPN und Cloud Router müssen im selben VPC-Netzwerk konfiguriert werden, das Sie für die hybride Load-Balancing-Bereitstellung verwenden möchten. Der Cloud Router muss außerdem die folgenden Routen zu Ihrer lokalen Umgebung bewerben:

    • Von den Systemdiagnosen von Google verwendete Bereiche: 35.191.0.0/16 und 130.211.0.0/22. Dies ist für globale externe Application Load Balancer, klassische Application Load Balancer, globale externe Proxy-Network Load Balancer und klassische Proxy-Network Load Balancer erforderlich.

    • Der Bereich des Nur-Proxy-Subnetzes der Region: für Envoy-basierte Load Balancer – regionale externe Application Load Balancer, regionale interne Application Load Balancer, regionenübergreifende interne Application Load Balancer,regionale externe Proxy-Network Load Balancer, regionenübergreifende interne Proxy-Network Load Balancer und regionale interne Proxy-Network Load Balancer.

      Außerdem ist das Nur-Proxy-Subnetz der Werberegion erforderlich, damit verteilte Envoy-Systemdiagnosen funktionieren. Die verteilte Envoy-Systemdiagnose ist der Standard-Systemdiagnosemechanismus für zonale Hybridkonnektivitäts-NEGS (d. h. NON_GCP_PRIVATE_IP_PORT-Endpunkte) hinter Envoy-basierten Load Balancern.

  • Netzwerkendpunkte (IP:Port) in Ihrer lokalen Umgebung oder in anderen Clouds. Einen oder mehrere IP:Port-Netzwerkendpunkte, die in Ihrer lokalen Umgebung oder in einer anderen Cloud-Umgebung konfiguriert sind und mithilfe von Cloud Interconnect oder Cloud VPN weitergeleitet werden können. Wenn mehrere Pfade zum IP-Endpunkt vorhanden sind, folgt das Routing dem in der Übersicht über VPC-Routen und der Übersicht über Cloud Router beschriebenen Verhalten.

  • Firewallregeln in Ihrer lokalen Umgebung oder in einer anderen Cloud. Die folgenden Firewallregeln müssen in Ihrer lokalen oder sonstigen Cloud-Umgebung erstellt werden:

    • Firewallregeln für eingehenden Traffic erlauben Traffic von der Systemdiagnose von Google an Ihre Endpunkte. Die Bereiche für die Zulassungsliste sind 35.191.0.0/16 und 130.211.0.0/22. Beachten Sie, dass diese Bereiche auch von Cloud Router Ihrem lokalen Netzwerk angeboten werden müssen. Weitere Informationen finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.
    • Firewallregeln zum Zulassen von eingehendem Traffic, damit Traffic mit Load-Balancing die Endpunkte erreichen kann.
    • Für Envoy-basierte Load Balancer – regionale externe Application Load Balancer, regionale interne Application Load Balancer, regionenübergreifende interne Application Load Balancer,regionale externe Proxy-Network Load Balancer, regionenübergreifende interne Proxy-Network Load Balancer und regionale interne Proxy-Network Load Balancer – müssen Sie außerdem eine Firewall-Regel erstellen, um den Traffic aus dem Nur-Proxy-Subnetz der Region zu den Endpunkten zuzulassen, die sich lokal oder in anderen Cloud-Umgebungen befinden.

Komponenten des Lastenausgleichsmoduls

Je nach Typ des Load-Balancers können Sie auf der Standard- oder Premium-Netzwerkstufe eine Bereitstellung mit Hybrid-Load-Balancing einrichten.

Ein Hybrid-Load-Balancer erfordert spezifische Konfiguration nur für den Backend-Dienst. Die Frontend-Konfiguration ist die gleiche wie für jeden anderen Load-Balancer. Die Envoy-basierten Load Balancer – regionale externe Application Load Balancer, regionale interne Application Load Balancer, regionenübergreifende interne Application Load Balancer,regionale externe Proxy-Network Load Balancer, regionenübergreifende interne Proxy-Network Load Balancer und regionale interne Proxy-Network Load Balancer – erfordern ein zusätzliches Nur-Proxy-Subnetz, um Envoy-Proxys in Ihrem Namen auszuführen.

Frontend-Konfiguration

Für das Hybrid-Load-Balancing ist keine spezielle Frontend-Konfiguration erforderlich. Weiterleitungsregeln werden verwendet, um Traffic nach IP-Adresse, Port und Protokoll an einen Zielproxy weiterzuleiten. Der Zielproxy beendet dann Verbindungen von Clients.

URL-Zuordnungen werden von HTTP(S)-Load-Balancern verwendet, um URL-basiertes Routing von Anfragen an die entsprechenden Backend-Dienste einzurichten.

Weitere Informationen zu den einzelnen Komponenten finden Sie in den Architekturabschnitten der jeweiligen Load-Balancer-Übersicht:

Backend-Dienst

Backend-Dienste stellen Konfigurationsinformationen für den Load-Balancer bereit. Load-Balancer leiten den eingehenden Traffic anhand der Informationen in einem Backend-Dienst an einen oder mehrere verknüpfte Backends weiter.

Zum Einrichten einer hybriden Load-Balancing-Bereitstellung konfigurieren Sie den Load-Balancer mit Back-Ends sowohl innerhalb als auch außerhalb von Google Cloud.

  • Back-Ends außerhalb von Google Cloud (lokal oder andere Cloud)

    Jedes Ziel, das Sie mit den Google-Produkten für Hybridkonnektivität (entweder Cloud VPN oder Cloud Interconnect) und mit einer gültigen IP:Port-Kombination erreichen können, kann als Endpunkt für den Load-Balancer konfiguriert werden.

    Konfigurieren Sie Ihre Cloud-Back-Ends außerhalb von Google Cloud so:

    1. Fügen Sie jede IP:Port-Kombination aus Endpunkten außerhalb des Google Cloud-Netzwerks zu einer Netzwerk-Endpunktgruppe mit Hybridkonnektivität hinzu. Achten Sie darauf, dass diese IP-Adresse und dieser Port über Hybridkonnektivität von Google Cloud aus erreichbar sind (entweder über Cloud VPN oder Cloud Interconnect). Für NEGs mit Hybridkonnektivität legen Sie den Netzwerkendpunkttyp auf NON_GCP_PRIVATE_IP_PORT fest.
    2. Geben Sie beim Erstellen der NEG eine Google Cloud-Zone an, mit der die geografische Entfernung zwischen Google Cloud und Ihrer lokalen oder sonstigen Cloud-Umgebung minimiert wird. Wenn Sie beispielsweise einen Dienst in einer lokalen Umgebung in Frankfurt hosten, können Sie beim Erstellen der NEG die Google Cloud-Zone europe-west3-a angeben.

    3. Fügen Sie diese Hybridkonnektivitäts-NEG als Backend für den Backend-Dienst hinzu.

      Eine Hybridkonnektivitäts-NEG darf nur Nicht-Google Cloud-Endpunkte enthalten. Traffic kann verworfen werden, wenn ein Hybrid-NEG Endpunkte für Ressourcen in einem Google Cloud-VPC-Netzwerk enthält, z. B. IP-Adressen für Weiterleitungsregeln für interne Passthrough-Network Load Balancer. Konfigurieren Sie Google Cloud-Endpunkte wie im nächsten Abschnitt beschrieben.

  • Google Cloud-Back-Ends

    Konfigurieren Sie Ihre Google Cloud-Endpunkte so:

    1. Erstellen Sie einen separaten Backend-Dienst für die Google Cloud-Backends.
    2. Konfigurieren Sie mehrere Back-Ends (GCE_VM_IP_PORT zonale NEGs oder Instanzgruppen) in derselben Region, in der Sie die Hybridkonnektivität eingerichtet haben.

Weitere Aspekte:

  • Jede Hybridkonnektivitäts-NEG kann nur Netzwerkendpunkte desselben Typs (NON_GCP_PRIVATE_IP_PORT) enthalten.

  • Sie können einen einzelnen Backend-Dienst verwenden, um sowohl auf Google Cloud-basierte Backends (mithilfe von zonalen NEGs mit GCE_VM_IP_PORT-Endpunkten) als auch lokal oder andere Cloud-Backends zu verweisen (mit Hybridkonnektivitäts-NEGs mit NON_GCP_PRIVATE_IP_PORT Endpunkten). Andere Kombinationen von gemischten Backend-Typen sind nicht zulässig. Cloud Service Mesh unterstützt keine gemischten Backend-Typen in einem einzelnen Backend-Dienst.

  • Das Load-Balancing-Schema des Backend-Dienstes muss eines der Folgenden sein:

    • EXTERNAL_MANAGED für globale externe Application Load Balancer, regionale externe Application Load Balancer, globale externe Proxy-Network Load Balancer und regionale externe Proxy-Network Load Balancer

    • EXTERNAL für klassische Application Load Balancer und klassische Proxy-Network Load Balancer

    • INTERNAL_MANAGED für interne Application Load Balancer und regionale interne Proxy-Network Load Balancer

    INTERNAL_SELF_MANAGED wird für Cloud Service Mesh-Bereitstellungen in mehreren Umgebungen und Hybridkonnektivitäts-NEGs unterstützt.

  • Das Protokoll des Backend-Dienstes muss entweder HTTP, HTTPS oder HTTP2 für die Application Load Balancer und entweder TCP oder SSL für die Proxy-Network Load Balancer sein. Eine Liste der Backend-Dienstprotokolle, die von den einzelnen Load-Balancern unterstützt werden, finden Sie unter Protokolle vom Load-Balancer zum Backend.

  • Der Balancing-Modus für das Hybrid-NEG-Backend muss RATE für Application Load Balancer und CONNECTION für Proxy-Network Load Balancer sein. Weitere Informationen zu Balancing-Modi finden Sie unter Übersicht über Backend-Dienste.

  • Aktualisieren Sie die Backends, die mit Ihrem Backend-Dienst verknüpft sind, um weitere Netzwerkendpunkte hinzuzufügen.

  • Wenn Sie verteilte Envoy-Systemdiagnosen mit zonalen Hybridkonnektivitäts-NEGS (d. h. NON_GCP_PRIVATE_IP_PORT) hinter Envoy-basierten Load-Balancern verwenden, konfigurieren Sie nicht denselben Netzwerk-Endpunkt in mehreren NEGs, die an einen Backend-Dienst angehängt sind. Dies führt zu unerwartetem Verhalten.

Zentrale Systemdiagnosen

Bei der Verwendung von Hybrid-NEGs sind zentralisierte Systemdiagnosen für globale externe Application Load Balancer, klassische Application Load Balancer, globale externe Proxy-Network Load Balancer und klassische Proxy-Network Load Balancer erforderlich. Andere Envoy-basierte Load Balancer verwenden verteilte Envoy-Systemdiagnosen, wie im folgenden Abschnitt beschrieben.

Erstellen Sie für NON_GCP_PRIVATE_IP_PORT-Endpunkte außerhalb von Google Cloud Firewallregeln in Ihren lokalen und anderen Cloud-Netzwerken. Wenden Sie sich dazu an Ihren Netzwerkadministrator. Der für die Hybridkonnektivität verwendete Cloud Router muss auch die Bereiche anbieten, die von den Systemdiagnoseprüfungen von Google verwendet werden. Die anzubietenden Bereiche sind 35.191.0.0/16 und 130.211.0.0/22.

Erstellen Sie für andere Arten von Backends in Google Cloud Firewallregeln in Google Cloud, wie in diesem Beispiel gezeigt.

Weitere Dokumentation:

Verteilte Envoy-Systemdiagnosen

Die Konfiguration der Systemdiagnose variiert je nach Art des Load Balancers:

  • Globaler externer Application Load Balancer, klassischer Application Load Balancer, globaler externer Proxy-Network Load Balancer und klassischer Proxy-Network Application Load Balancer. Diese Load Balancer unterstützen keine verteilten Envoy-Systemdiagnosen. Sie verwenden den zentralen Systemdiagnosemechanismus von Google, wie im Abschnitt Zentrale Systemdiagnosen beschrieben.

  • Regionaler externer Application Load Balancer, regionaler interner Application Load Balancer, regionaler externer Proxy-Network Load Balancer, regionaler interner Proxy-Network Load Balancer, regionenübergreifender interner Proxy-Network Load Balancer und regionenübergreifender interner Application Load Balancer. Diese Load Balancer verwenden verteilte Envoy-Systemdiagnosen, um den Status von Hybrid-NEGs zu prüfen. Die Systemdiagnoseprüfungen stammen von der Envoy-Proxy-Software selbst. Jeder Backend-Dienst muss mit einer Systemdiagnose verknüpft sein, die den Status der Backends prüft. Systemdiagnoseprüfungen stammen von den Envoy-Proxys im Nur-Proxy-Subnetz in der Region. Damit die Systemdiagnosetests korrekt ausgeführt werden können, müssen Sie in der externen Umgebung Firewallregeln erstellen, die Traffic vom Nur-Proxy-Subnetz zu Ihren externen Backends zulassen.

    Für NON_GCP_PRIVATE_IP_PORT-Endpunkte außerhalb von Google Cloud müssen Sie diese Firewallregeln in Ihren lokalen und anderen Cloud-Netzwerken erstellen. Wenden Sie sich dazu an Ihren Netzwerkadministrator. Der Cloud Router, den Sie für die Hybridkonnektivität verwenden, muss auch den Nur-Proxy-Subnetzbereich der Region anbieten.

Verteilte Envoy-Systemdiagnosen werden mit der gleichen Google Cloud Console, gcloud CLI und API-Prozessen erstellt wie zentralisierte Systemdiagnosen. Es ist keine weitere Konfiguration erforderlich.

Wichtige Hinweise:

  • gRPC-Systemdiagnosen werden nicht unterstützt.
  • Systemdiagnosen mit aktiviertem PROXY Protocol v1 werden nicht unterstützt.
  • Wenn Sie gemischte NEGs verwenden, bei denen ein einzelner Backend-Dienst eine Kombination aus zonalen NEGs (GCE_VM_IP_PORT-Endpunkte in Google Cloud) und Hybrid-NEGs (NON_GCP_PRIVATE_IP_PORT-Endpunkte außerhalb von Google Cloud) ist, müssen Sie Firewallregeln einrichten, um Traffic von den IP-Bereichen der Google-Systemdiagnoseprüfung (130.211.0.0/22 und35.191.0.0/16) an die zonalen NEG-Endpunkte in Google Cloud zuzulassen. Das liegt daran, dass die zonalen NEGs das zentralisierte Systemdiagnosesystem von Google verwenden.

  • Da die Envoy-Datenebene Systemdiagnosen verarbeitet, können Sie den Systemstatus der externen Endpunkte nicht mit der Google Cloud Console, der API oder der gcloud CLI prüfen. Bei Hybrid-NEGs mit Envoy-basierten Load Balancern zeigt die Google Cloud Console den Status der Systemdiagnose als N/A an. Dies ist zu erwarten.

  • Jeder Envoy-Proxy, der dem Nur-Proxy-Subnetz in der Region im VPC-Netzwerk zugewiesen ist, initiiert unabhängig Systemdiagnosen. Daher kann es aufgrund von Systemdiagnosen zu einem Anstieg des Netzwerktraffics kommen. Die Zunahme hängt von der Anzahl der Envoy-Proxys, die Ihrem VPC-Netzwerk in einer Region zugewiesen sind, der Menge des von diesen Proxys empfangenen Traffics und der Anzahl der Endpunkte ab, die jeder Envoy-Proxy für die Systemdiagnose benötigt. Im schlimmsten Fall steigt der Netzwerktraffic aufgrund von Systemdiagnosen quadratisch ((O(n^2))) an.

  • Systemdiagnose-Logs für verteilte Envoy-Systemdiagnosen enthalten keine detaillierten Systemzustände. Informationen dazu, was in Logs erfasst wird, finden Sie unter Systemdiagnose-Logging. Weitere Informationen zur Fehlerbehebung bei der Konnektivität von Envoy-Proxys zu Ihren NEG-Endpunkten finden Sie in den entsprechenden Load Balancer-Logs.

Weitere Dokumentation:

Beschränkungen

  • Der für die Hybridkonnektivität verwendete Cloud Router muss mit globalem dynamischem Routing aktiviert werden. Regionales dynamisches Routing und statische Routen werden nicht unterstützt.
  • Für die Envoy-basierten regionalen Load Balancer – regionale externe Application Load Balancer, regionale externe Proxy-Network Load Balancer, regionale interne Proxy-Network Load Balancer und interne Application Load Balancer – muss die Hybridkonnektivität in derselben Region wie der Load Balancer konfiguriert werden. Wenn sie in verschiedenen Regionen konfiguriert sind, werden Back-Ends möglicherweise als fehlerfrei angezeigt, aber Clientanfragen werden nicht an die Back-Ends weitergeleitet.

  • Die hier dokumentierten Überlegungen zu verschlüsselten Verbindungen vom Load-Balancer zu den Backends gelten auch für Backend-Endpunkte außerhalb von Google Cloud, die in der Hybridkonnektivitäts-NEG konfiguriert sind.

    Überprüfen Sie auch die Sicherheitseinstellungen in der Hybridkonnektivitäts-Konfiguration. Derzeit werden HA-VPN-Verbindungen standardmäßig verschlüsselt (IPSec). Cloud Interconnect-Verbindungen werden nicht standardmäßig verschlüsselt. Weitere Informationen finden Sie im Whitepaper Verschlüsselung während der Übertragung.

Logging

An einen Endpunkt in einer Hybrid-NEG weitergeleitete Anfragen werden in Cloud Logging auf dieselbe Weise protokolliert wie Anfragen an andere Back-Ends. Wenn Sie Cloud CDN für Ihren globalen externen Application Load Balancer aktivieren, werden Cache-Treffer ebenfalls protokolliert.

Weitere Informationen finden Sie unter:

Kontingent

Sie können so viele Hybrid-NEGs mit Netzwerkendpunkten konfigurieren, wie es Ihr Kontingent für Netzwerk-Endpunktgruppen zulässt. Weitere Informationen finden Sie unter NEG-Back-Ends und Endpunkte pro NEG.

Nächste Schritte