Interner Application Load Balancer – Übersicht

In diesem Dokument werden die Konzepte vorgestellt, die Sie verstehen sollten, wenn Sie interne Application Load Balancer konfigurieren möchten.

Ein interner Google Cloud Application Load Balancer ist ein proxy-basierter, Layer-7-Load Balancer, mit dem Sie Ihre Dienste hinter einer einzigen IP-Adresse ausführen und skalieren können. Der interne Application Load Balancer verteilt HTTP- und HTTPS-Traffic an Back-Ends, die auf einer Vielzahl von Google Cloud-Plattformen wie Compute Engine, Google Kubernetes Engine (GKE) und Cloud Run gehostet werden. Weitere Informationen finden Sie unter Anwendungsfälle.

Betriebsarten

Sie können einen externen Application Load Balancer in den folgenden Modi konfigurieren:

  • Regionenübergreifender interner Application Load Balancer. Dies ist ein multiregionaler Load Balancer, der als verwalteter Dienst auf Grundlage des Open-Source-Envoy-Proxys implementiert ist. Mit dem regionenübergreifenden Modus können Sie Traffic auf global verteilte Backend-Dienste verteilen, einschließlich der Trafficverwaltung, die dafür sorgt, dass der Traffic an das nächstgelegene Backend weitergeleitet wird. Dieser Load Balancer ermöglicht auch Hochverfügbarkeit. Durch die Platzierung von Backends in mehreren Regionen lassen sich Fehler in einer einzelnen Region vermeiden. Wenn die Back-Ends einer Region ausfallen, kann der Traffic auf eine andere Region umgeleitet werden.

  • Regionaler interner Application Load Balancer. Dies ist ein regionaler Load Balancer, der als verwalteter Dienst im Open-Source-Envoy-Proxy implementiert ist. Der regionale Modus stellt sicher, dass alle Clients und Back-Ends aus einer bestimmten Region stammen, was hilfreich ist, wenn Sie regionale Compliance benötigen. Dieser Load Balancer wird mit umfangreichen Trafficsteuerungsfunktionen aktiviert, die auf HTTP(S)-Parametern basieren. Nachdem der Load Balancer konfiguriert wurde, werden automatisch Envoy-Proxys zugewiesen, um Ihre Trafficanforderungen zu erfüllen.

    In der folgenden Tabelle werden die wichtigen Unterschiede zwischen regionalen und regionenübergreifenden Modi beschrieben:

    Funktion Regionsübergreifender interner Application Load Balancer Regionaler interner Application Load Balancer
    Virtuelle IP-Adresse (VIP) des Load Balancers. Wird aus einem Subnetz in einer bestimmten Google Cloud-Region zugewiesen.

    VIP-Adressen aus mehreren Regionen können denselben globalen Backend-Dienst verwenden. Sie können das DNS-basierte globale Load Balancing mithilfe von DNS-Routingrichtlinien konfigurieren, um Clientanfragen an die nächstgelegene VIP-Adresse weiterzuleiten.

    		 Wird aus einem Subnetz in einer bestimmten Google Cloud-Region zugewiesen.
    Clientzugriff Zugriff immer global. Clients aus jeder Google Cloud-Region in einer VPC können Traffic an den Load Balancer senden. Zugriff ist standardmäßig nicht global möglich.
    (Optional) Sie können den globalen Zugriff aktivieren.
    Back-Ends mit Load Balancing Globale Back-Ends.
    Der Load Balancer kann Traffic an Back-Ends in jeder Region senden.    		 Regionale Back-Ends.
    Der Load Balancer kann Traffic nur an Back-Ends senden, die sich in derselben Region wie der Proxy des Load Balancers befinden.
    Hochverfügbarkeit und Failover Automatisches Failover auf fehlerfreie Backends in derselben oder in unterschiedlichen Regionen. Automatisches Failover auf fehlerfreie Back-Ends in derselben Region.

Modus bestimmen

Cloud Console

  1. Rufen Sie in der Google Cloud Console die Seite Load-Balancing auf.

    Load-Balancing aufrufen

  2. Auf dem Tab Load Balancer werden der Typ, das Protokoll und die Region des Load Balancers angezeigt. Wenn die Region leer ist, befindet sich der Load Balancer im regionenübergreifenden Modus. In der folgenden Tabelle wird zusammengefasst, wie Sie den Modus des Load-Balancers bestimmen.

    Load-Balancer-Modus Load Balancer-Typ Zugriffstyp Region
    Regionaler interner Application Load Balancer Anwendung Intern Gibt eine Region an
    Regionsübergreifender interner Application Load Balancer Anwendung Intern

gcloud

  1. Führen Sie den folgenden Befehl aus, um den Modus eines Load-Balancers zu bestimmen:

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

    Prüfen Sie in der Befehlsausgabe das Load-Balancing-Schema, die Region und die Netzwerkstufe. In der folgenden Tabelle wird zusammengefasst, wie Sie den Modus des Load-Balancers bestimmen.

    Load-Balancer-Modus Load-Balancing-Schema Weiterleitungsregel
    Regionsübergreifender interner Application Load Balancer INTERNAL_MANAGED Global
    Regionaler interner Application Load Balancer INTERNAL_MANAGED Regional

Architektur und Ressourcen

Das folgende Diagramm zeigt die Google Cloud-Ressourcen, die für interne Application Load Balancer erforderlich sind:

Regionsübergreifend

Dieses Diagramm zeigt die Komponenten der regionsübergreifenden internen Bereitstellung des Application Load Balancers in der Premium-Stufe innerhalb desselben VPC-Netzwerks. Jede globale Weiterleitungsregel verwendet eine regionale IP-Adresse, mit der die Clients eine Verbindung herstellen.

Komponenten eines regionenübergreifenden internen Application Load Balancers.
Komponenten des regionsübergreifenden internen Application Load Balancers (zum Vergrößern klicken)

Regional

Dieses Diagramm zeigt die Komponenten der Bereitstellung eines regionalen internen Application Load Balancers in der Premium-Stufe.

Komponenten eines regionalen internen Application Load Balancers.
Nummerierte Komponenten des regionalen internen Application Load Balancers (zum Vergrößern klicken).

Die folgenden Ressourcen sind für die Bereitstellung eines internen Application Load Balancers erforderlich:

Nur-Proxy-Subnetz

Im obigen Diagramm stellt das Nur-Proxy-Subnetz eine Reihe von IP-Adressen bereit, die Google zum Ausführen von Envoy-Proxys in Ihrem Namen verwendet. Sie müssen in jeder Region eines VPC-Netzwerks, in dem Sie interne Application Load Balancer verwenden, ein Nur-Proxy-Subnetz erstellen.

In der folgenden Tabelle werden die Unterschiede zwischen Subnetzen mit nur Proxys im regionalen und regionenübergreifenden Modus beschrieben:

Load-Balancer-Modus Wert des Flags --purpose des Nur-Proxy-Subnetzes
Regionsübergreifender interner Application Load Balancer

GLOBAL_MANAGED_PROXY

Regionale und regionenübergreifende Load Balancer können nicht dieselben Subnetze verwenden

Der regionenübergreifende Envoy-basierte Load Balancer muss in jeder Region, in der der Load Balancer konfiguriert ist, ein Nur-Proxy-Subnetz haben. Regionenübergreifende Load Balancer-Proxys in derselben Region und demselben Netzwerk verwenden dasselbe Nur-Proxy-Subnetz.
Regionaler interner Application Load Balancer

REGIONAL_MANAGED_PROXY

Regionale und regionenübergreifende Load Balancer können nicht dieselben Subnetze verwenden

Alle regionalen Envoy-basierten Load Balancer in einer Region und einem VPC-Netzwerk verwenden dasselbe Nur-Proxy-Subnetz

Weiter:

  • Nur-Proxy-Subnetze werden nur für Envoy-Proxys und nicht für Ihre Back-Ends verwendet.
  • Backend-VMs bzw. Endpunkte aller internen Application Load Balancer in einer Region und einem VPC-Netzwerk empfangen Verbindungen vom Nur-Proxy-Subnetz.
  • Die IP-Adresse eines internen Application Load Balancers befindet sich nicht im Nur-Proxy-Subnetz. Die IP-Adresse des Load-Balancers wird durch seine intern verwaltete Weiterleitungsregel definiert, die unten beschrieben ist.

Weiterleitungsregel und IP-Adresse

Weiterleitungsregeln leiten Traffic abhängig von der IP-Adresse, dem Port und dem Protokoll an eine Load-Balancing-Konfiguration weiter, die aus einem Zielproxy und einem Backend-Dienst besteht.

IP-Adressspezifikation Jede Weiterleitungsregel verweist auf eine einzelne regionale IP-Adresse, die Sie in DNS-Einträgen für Ihre Anwendung verwenden können. Sie können entweder eine statische IP-Adresse reservieren, die Sie verwenden können, oder Cloud Load Balancing eine Adresse für Sie zuweisen lassen. Wir empfehlen, eine statische IP-Adresse zu reservieren. Andernfalls müssen Sie den DNS-Eintrag jedes Mal, wenn Sie eine Weiterleitungsregel löschen und eine neue erstellen, mit der neu zugewiesenen sitzungsspezifischen IP-Adresse aktualisieren.

Clients verwenden die IP-Adresse und den Port, um eine Verbindung zu den Envoy-Proxys des Load Balancers herzustellen. Die IP-Adresse der Weiterleitungsregel ist die IP-Adresse des Load Balancers (manchmal auch virtuelle IP-Adresse oder VIP genannt). Clients, die eine Verbindung zu einem Load Balancer herstellen, müssen HTTP-Version 1.1 oder höher verwenden. Eine vollständige Liste der unterstützten Protokolle finden Sie unter Load Balancer-Features.

Die mit der Weiterleitungsregel verknüpfte interne IP-Adresse kann aus einem Subnetz im selben Netzwerk und in derselben Region wie die Back-Ends stammen.

Portspezifikation Jede Weiterleitungsregel für einen Application Load Balancer kann auf einen einzelnen Port von 1–65535 verweisen. Wenn Sie mehrere Ports unterstützen möchten, müssen Sie mehrere Weiterleitungsregeln konfigurieren. Sie können mehrere Weiterleitungsregeln so konfigurieren, dass sie dieselbe interne IP-Adresse (VIP) verwenden und auf denselben Ziel-HTTP(S)-Proxy verweisen, solange die gesamte Kombination von IP-Adresse, Port und Protokoll für jede Weiterleitungsregel eindeutig ist. Auf diese Weise können Sie einen einzelnen Load Balancer mit einer freigegebenen URL-Zuordnung als Proxy für mehrere Anwendungen verwenden.

Die Art der Weiterleitungsregel, die IP-Adresse und das Load-Balancing-Schema, die von internen Application Load Balancern verwendet werden, hängen vom Modus des Load Balancers ab.

Load-Balancer-Modus Weiterleitungsregel, IP-Adresse und Nur-Proxy-Subnetz --purpose Routing vom Client zum Frontend des Load Balancers
Regionsübergreifender interner Application Load Balancer

Globale Weiterleitungsregel

Regionale IP-Adressen

Load Balancing-Schema:

INTERNAL_MANAGED

Nur-Proxy-Subnetz: --purpose

GLOBAL_MANAGED_PROXY

IP-Adresse --purpose:

SHARED_LOADBALANCER_VIP

Der globale Zugriff ist standardmäßig aktiviert, damit Clients aus jeder Region in einer VPC auf den Load Balancer zugreifen können. Back-Ends können sich in mehreren Regionen befinden.
Regionaler interner Application Load Balancer

Regionale Weiterleitungsregel

Regionale IP-Adresse

Load Balancing-Schema:

INTERNAL_MANAGED

Nur-Proxy-Subnetz: --purpose

REGIONAL_MANAGED_PROXY

IP-Adresse --purpose:

SHARED_LOADBALANCER_VIP

Sie können den globalen Zugriff aktivieren, damit Clients aus jeder Region in einer VPC auf Ihren Load Balancer zugreifen können. Backends müssen sich auch in derselben Region wie der Load Balancer befinden.

Weiterleitungsregeln und VPC-Netzwerke

In diesem Abschnitt wird beschrieben, wie Weiterleitungsregeln, die von externen Application Load Balancern verwendet werden, mit VPC-Netzwerken verknüpft werden.

Load-Balancer-Modus VPC-Netzwerkverknüpfung
Regionsübergreifender interner Application Load Balancer

Regionaler interner Application Load Balancer

Regionale interne IPv4-Adressen befinden sich immer in VPC-Netzwerken. Wenn Sie die Weiterleitungsregel erstellen, müssen Sie das Subnetz angeben, aus dem die interne IP-Adresse übernommen wird. Dieses Subnetz muss sich in derselben Region und im selben VPC-Netzwerk befinden, in der bzw. in dem ein Nur-Proxy-Subnetz erstellt wurde. Es gibt also eine implizite Netzwerkverknüpfung.

Zielproxy

Ein HTTP(S)-Zielproxy beendet HTTP(S)-Verbindungen von Clients. Der HTTP(S)-Proxy prüft die URL-Zuordnung, um zu ermitteln, wie Traffic an Back-Ends weitergeleitet wird. Ein Ziel-HTTPS-Proxy verwendet ein SSL-Zertifikat, um sich bei Clients zu authentifizieren.

Der Load-Balancer behält den Host-Header der ursprünglichen Clientanfrage bei. Der Load-Balancer hängt außerdem zwei IP-Adressen an den Header X-Forwarded-For an:

  • Die IP-Adresse des Clients, der eine Verbindung zum Load-Balancer herstellt
  • Die IP-Adresse der Weiterleitungsregel des Load-Balancers

Wenn in der eingehenden Anfrage kein X-Forwarded-For-Header vorhanden ist, stellen diese beiden IP-Adressen den gesamten Header-Wert dar. Wenn die Anfrage einen X-Forwarded-For-Header hat, werden andere Informationen wie die von Proxys auf dem Weg zum Load-Balancer erfassten IP-Adressen vor den beiden IP-Adressen gespeichert. Der Load-Balancer überprüft keine IP-Adressen, die vor den letzten beiden IP-Adressen in diesem Header liegen.

Wenn Sie einen Proxy als Back-End-Server ausführen, fügt dieser Proxy in der Regel weitere Informationen an den Header X-Forwarded-For an. Dies kann in Ihrer Software erforderlich sein. Die weitergeleiteten Anfragen vom Load-Balancer stammen von einer IP-Adresse im Nur-Proxy-Subnetz. Ihr Proxy auf der Backend-Instanz erfasst möglicherweise diese Adresse sowie die eigene IP-Adresse der Backend-Instanz.

Je nach der Art des Traffics, den Ihre Anwendung verarbeiten muss, können Sie einen Load Balancer mit einem Ziel-HTTP-Proxy oder einem Ziel-HTTPS-Proxy konfigurieren.

In der folgenden Tabelle sind die Zielproxy APIs aufgeführt, die für interne Application Load Balancer erforderlich sind:

Load-Balancer-Modus Zielproxy
Regionsübergreifender interner Application Load Balancer
Regionaler interner Application Load Balancer

SSL-Zertifikate

Interne Application Load Balancer, die HTTPS-Zielproxys verwenden, benötigen als Teil der Load-Balancer-Konfiguration private Schlüssel und SSL-Zertifikate.

In der folgenden Tabelle ist der Typ der SSL-Zertifikate angegeben, die von internen Application Load Balancern in den einzelnen Modi benötigt werden:

Load-Balancer-Modus SSL-Zertifikattyp
Regionaler interner Application Load Balancer

Regionale SSL-Zertifikate für die Compute Engine

Von Zertifikatmanager selbst verwaltete regionale Zertifikate und von Google verwaltete Zertifikate.

Die folgenden Typen der von Google verwalteten Zertifikate werden von Zertifikatmanager unterstützt:

Von Google verwaltete Zertifikate mit Load Balancer-Autorisierung werden nicht unterstützt.
Regionsübergreifender interner Application Load Balancer

Von Certificate Manager selbst verwaltete Zertifikate und von Google verwaltete Zertifikate.

Die folgenden Typen der von Google verwalteten Zertifikate werden von Certificate Manager unterstützt:

Von Google verwaltete Zertifikate mit Load Balancer-Autorisierung werden nicht unterstützt.

Compute Engine-SSL-Zertifikate werden nicht unterstützt.

URL-Zuordnungen

Der HTTP(S)-Zielproxy verwendet URL-Zuordnungen, um anhand von HTTP-Attributen (z. B. Anfragepfad, Cookies oder Header) eine Routingentscheidung zu treffen. Anhand dieser Entscheidung leitet der Proxy Clientanfragen an bestimmte Backend-Dienste weiter. In der URL-Zuordnung können zusätzliche Aktionen angegeben werden, unter anderem das Überschreiben von Headern, das Senden von Weiterleitungen an Clients und das Konfigurieren von Zeitlimitrichtlinien.

In der folgenden Tabelle ist der Typ der URL-Zuordnung angegeben, der von internen Application Load Balancern in den einzelnen Modi benötigt wird:

Load-Balancer-Modus Typ der URL-Zuordnung
Regionsübergreifender interner Application Load Balancer Globale URL-Zuordnungen
Regionaler interner Application Load Balancer Regions-URL-Zuordnungen

Backend-Dienst

Ein Back-End-Dienst stellt dem Load Balancer Konfigurationsinformationen zur Verfügung, damit er Anfragen an seine Back-Ends weiterleiten kann, z. B. an Compute Engine-Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs). Weitere Informationen zu Back-End-Diensten finden Sie unter Übersicht über Back-End-Dienste.

Umfang des Back-End-Dienstes

In der folgenden Tabelle sehen Sie, welche Backend-Dienstressource und welcher Umfang von internen Application Load Balancern verwendet werden:

Load-Balancer-Modus Ressource für Back-End-Dienst
Regionsübergreifender interner Application Load Balancer backendServices (global)
Regionaler interner Application Load Balancer regionBackendServices (regional)

Protokoll für Back-Ends

Backend-Dienste für Application Load Balancer müssen eines der folgenden Protokolle verwenden, um Anfragen an Backends zu senden:

  • HTTP, bei dem HTTP/1.1 und kein TLS verwendet wird
  • HTTPS, bei dem HTTP/1.1 und TLS verwendet werden
  • HTTP/2, das HTTP/2 und TLS verwendet (HTTP/2 ohne Verschlüsselung wird nicht unterstützt).

Der Load Balancer verwendet nur das von Ihnen angegebene Protokoll für die Kommunikation mit den Backends. Der Load Balancer greift nicht auf ein anderes Protokoll zurück, wenn er mit dem angegebenen Protokoll für den Backend-Dienst nicht mit den Backends kommunizieren kann.

Das Protokoll des Back-End-Dienstes muss nicht mit dem Protokoll übereinstimmen, das von den Clients für die Kommunikation mit dem Load Balancer verwendet wird. Clients können beispielsweise Anfragen mit HTTP/2 an den Load Balancer senden, der Load Balancer kann aber mit Back-Ends über HTTP/1.1 (HTTP oder HTTPS) kommunizieren.

Back-Ends

In der folgenden Tabelle sind die Backend-Features aufgeführt, die von internen Application Load Balancern in den einzelnen Modi unterstützt werden.


Load-Balancer-Modus		 Unterstützte Back-Ends in einem Back-End-Dienst* Unterstützt Back-End-Buckets Unterstützt Google Cloud Armor Unterstützt Cloud CDN. Unterstützt IAP Unterstützt Diensterweiterungen
Instanzgruppen† Zonale NEGs‡ Internet-NEGs Serverlose NEGs Hybrid-NEGs Private Service Connect-NEGs
Regionsübergreifender interner Application Load Balancer
Cloud Run
Regionaler interner Application Load Balancer
Cloud Run

* Die Back-Ends eines Back-End-Dienstes müssen vom selben Typ sein: alle Instanzgruppen oder alle NEGs desselben Typs. Eine Ausnahme von dieser Regel ist, dass sowohl zonale GCE_VM_IP_PORT-NEGs als auch hybride NEGs für denselben Backend-Dienst verwendet werden können, um eine Hybridarchitektur zu unterstützen.

† Kombinationen aus zonal nicht verwalteten, zonal verwalteten und regional verwalteten Instanzgruppen werden für denselben Back-End-Dienst unterstützt. Wenn Sie das Autoscaling für eine verwaltete Instanzgruppe verwenden, die ein Back-End für zwei oder mehr Back-End-Dienste ist, konfigurieren Sie die Autoscaling-Richtlinie der Instanzgruppe für die Verwendung mehrerer Signale.

‡ Zonale NEGs müssen GCE_VM_IP_PORT-Endpunkte verwenden.

Back-Ends und VPC-Netzwerke

Die Einschränkungen, wo sich Back-Ends befinden können, hängen vom Typ des Back-Ends ab.

  • Bei Instanzgruppen, zonalen NEGs und NEGs mit Hybrid-Konnektivität müssen sich alle Backends im selben Projekt und in derselben Region wie der Backend-Dienst befinden. Ein Load Balancer kann jedoch auf ein Backend verweisen, das ein anderes VPC-Netzwerk im selben Projekt wie der Backend-Dienst verwendet. Diese Funktion befindet sich in der Vorabversion. Die Verbindung zwischen dem VPC-Netzwerk des Load Balancers und dem Backend-VPC-Netzwerk kann entweder über VPC-Netzwerk-Peering, Cloud VPN-Tunnel, Cloud Interconnect-VLAN-Anhänge oder ein Network Connectivity Center-Framework konfiguriert werden.

    Definition des Backend-Netzwerks

    • Bei zonalen und hybriden NEGs geben Sie das VPC-Netzwerk beim Erstellen der NEG explizit an.
    • Bei verwalteten Instanzgruppen wird das VPC-Netzwerk in der Instanzvorlage definiert.
    • Bei nicht verwalteten Instanzgruppen wird das VPC-Netzwerk der Instanzgruppe so festgelegt, dass es mit dem VPC-Netzwerk der nic0-Schnittstelle der ersten VM übereinstimmt, die der Instanzgruppe hinzugefügt wird.

    Anforderungen an das Backend-Netzwerk

    Das Netzwerk deines Backends muss eine der folgenden Netzwerkanforderungen erfüllen:

    • Das VPC-Netzwerk des Backends muss genau mit dem VPC-Netzwerk der Weiterleitungsregel übereinstimmen.

    • Das VPC-Netzwerk des Backends muss über VPC-Netzwerk-Peering mit dem VPC-Netzwerk der Weiterleitungsregel verbunden sein. Sie müssen den Austausch von Subnetzrouten konfigurieren, um die Kommunikation zwischen dem Nur-Proxy-Subnetz im VPC-Netzwerk der Weiterleitungsregel und den Subnetzen zu ermöglichen, die von den Backend-Instanzen oder Endpunkten verwendet werden.

  • Sowohl das VPC-Netzwerk des Backends als auch das VPC-Netzwerk der Weiterleitungsregel müssen VPC-Spokes auf demselben Network Connectivity Center-Hub sein. Import- und Exportfilter müssen die Kommunikation zwischen dem Nur-Proxy-Subnetz im VPC-Netzwerk der Weiterleitungsregel und den Subnetzen zulassen, die von Backend-Instanzen oder Endpunkten verwendet werden.

  • Bei allen anderen Backend-Typen müssen sich alle Backends im selben VPC-Netzwerk und in derselben Region befinden.

Backends und Netzwerkschnittstellen

Wenn Sie Instanzgruppen-Backends verwenden, werden Pakete immer an nic0 gesendet. Wenn Sie Pakete an verschiedene NICs senden möchten, verwenden Sie stattdessen NEG-Backends.

Wenn Sie zonale NEG-Backends verwenden, werden Pakete an die Netzwerkschnittstelle gesendet, die durch den Endpunkt in der NEG dargestellt wird. Die NEG-Endpunkte müssen sich im selben VPC-Netzwerk wie das explizit definierte VPC-Netzwerk der NEG befinden.

Backend-Teilmengeneinstellung

Die Backend-Teilmengeneinstellung ist eine optionale Funktion, die vom regionalen internen Application Load Balancer unterstützt wird und die Leistung und Skalierbarkeit verbessert, indem jeder Proxy-Instanz eine Teilmenge von Backends zugewiesen wird.

Standardmäßig ist die Backend-Teileinstellung deaktiviert. Informationen zum Aktivieren dieser Funktion finden Sie unter Backend-Teilmengeneinstellung für internen Application Load Balancer.

Systemdiagnosen

Jeder Backend-Dienst gibt eine Systemdiagnose an, die regelmäßig die Bereitschaft der Backends überwacht, eine Verbindung vom Load-Balancer zu erhalten. Dadurch besteht ein geringeres Risiko, dass Anfragen an Back-Ends gesendet werden, die die Anfrage nicht verarbeiten können. Systemdiagnosen prüfen nicht, ob die Anwendung selbst funktioniert.

Für die Systemdiagnoseprüfungen müssen Sie eine Firewallregel zum Zulassen von eingehendem Traffic erstellen, damit Systemdiagnoseprüfungen Ihre Backend-Instanzen erreichen können. In der Regel gehen Systemdiagnoseprüfungen vom zentralen Systemdiagnosemechanismus von Google aus. Bei Hybrid-NEGs stammen die Systemdiagnosen jedoch stattdessen aus dem Nur-Proxy-Subnetz. Weitere Informationen finden Sie unter Verteilte Systemdiagnosen für Envoy in der Übersicht der Hybrid-NEGs.

Systemdiagnoseprotokoll

Obwohl es nicht erforderlich und nicht immer möglich ist, empfiehlt es sich, eine Systemdiagnose zu verwenden, deren Protokoll dem Protokoll des Backend-Dienstes entspricht. So lässt sich beispielsweise mit einer HTTP/2-Systemdiagnose die HTTP/2-Konnektivität zu Back-Ends am genauesten testen. Im Gegensatz dazu unterstützen interne Application Load Balancer, die Hybrid-NEG-Back-Ends verwenden, keine gRPC-Systemdiagnosen. Eine Liste der unterstützten Systemdiagnoseprotokolle finden Sie unter Load-Balancing-Features.

In der folgenden Tabelle wird der Bereich der Systemdiagnosen angegeben, die von internen Application Load Balancern unterstützt werden:

Load-Balancer-Modus Systemdiagnosetyp
Regionsübergreifender interner Application Load Balancer Global
Regionaler interner Application Load Balancer Regional

Weitere Informationen zu Systemdiagnosen finden Sie hier:

Firewallregeln

Für einen internen Application Load Balancer sind die folgenden Firewallregeln erforderlich:

  • Eine Regel zum Zulassen von eingehendem Traffic, um Traffic von den zentralen Systemdiagnosebereichen von Google zuzulassen.
    • 35.191.0.0/16
    • 130.211.0.0/22

    Bei IPv6-Traffic zu den Back-Ends:

    • 2600:2d00:1:b029::/64
  • Eine Regel zum Zulassen von eingehendem Traffic, um Traffic vom Nur-Proxy-Subnetz zuzulassen.

Für die folgenden Bereiche gelten bestimmte Ausnahmen von den Firewallregeln:

  • Die Prüfbereiche der Systemdiagnose von Google müssen bei Hybrid-NEGs nicht auf die Zulassungsliste gesetzt werden. Wenn Sie jedoch eine Kombination aus hybriden und zonalen NEGs in einem einzelnen Backend-Dienst verwenden, müssen Sie die Prüfbereiche der Systemdiagnose von Google für die zonalen NEGs auf die Zulassungsliste setzen.
  • Bei regionalen Internet-NEGs sind Systemdiagnosen optional. Der Traffic von Load-Balancern mit regionalen Internet-NEGs stammt aus dem Nur-Proxy-Subnetz und wird dann (mithilfe von Cloud NAT) in die manuelle oder automatisch zugewiesene NAT-IP-Adressen NAT-übersetzt. Dieser Traffic umfasst sowohl Systemdiagnoseprüfungen als auch Nutzeranfragen vom Load Balancer an die Back-Ends. Weitere Informationen finden Sie unter Regionale NEGs: Cloud NAT für ausgehenden Traffic verwenden.

Clientzugriff

Clients können sich im selben Netzwerk oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering verbunden ist.

Für regionenübergreifende interne Application Load Balancer ist der globale Zugriff standardmäßig aktiviert. Clients aus jeder Region in einer VPC können auf Ihren Load Balancer zugreifen.

Bei regionalen internen Application Load Balancern müssen sich Clients standardmäßig in derselben Region wie der Load Balancer befinden. Sie können den globalen Zugriff aktivieren, damit Clients aus jeder Region in einer VPC auf Ihren Load Balancer zugreifen können.

In der folgenden Tabelle wird der Clientzugriff für regionale interne Application Load Balancer zusammengefasst:

Globaler Zugriff deaktiviert Globaler Zugriff aktiviert
Clients müssen sich in derselben Region wie der Load-Balancer befinden. Sie müssen sich außerdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist. Clients können sich in jeder beliebigen Region befinden. Sie müssen sich aber trotzdem im selben VPC-Netzwerk wie der Load-Balancer oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering mit dem VPC-Netzwerk des Load-Balancers verbunden ist.
Lokale Clients können über Cloud VPN-Tunnel oder VLAN-Anhänge auf den Load Balancer zugreifen. Diese Tunnel oder Anhänge müssen sich in derselben Region wie der Load-Balancer befinden. Lokale Clients können über Cloud VPN-Tunnel oder VLAN-Anhänge auf den Load Balancer zugreifen. Diese Tunnel oder Anhänge können sich in einer beliebigen Region befinden.

GKE-Support

In GKE werden interne Application Load Balancer auf folgende Weise verwendet:

  • Für interne Gateways, die mit dem GKE-Gateway-Controller erstellt wurden, kann jeder Modus eines internen Application Load Balancers verwendet werden. Sie steuern den Modus des Load Balancers, indem Sie eine GatewayClass auswählen. Der GKE-Gateway-Controller verwendet immer GCE_VM_IP_PORT zonale NEG-Backends.

  • Interne Ingresse, die mit dem GKE-Ingress-Controller erstellt wurden, sind immer regionale interne Application Load Balancer. Der GKE Ingress-Controller verwendet immer zonale NEG-Back-Ends vom Typ GCE_VM_IP_PORT.

Architekturen freigegebener VPCs

Interne Application Load Balancer unterstützen Netzwerke, die eine freigegebene VPC verwenden. Eine freigegebene VPC ermöglicht Organisationen, Ressourcen aus mehreren Projekten mit einem gemeinsamen VPC-Netzwerk zu verbinden, sodass sie sicher und effizient über interne IP-Adressen dieses Netzwerks miteinander kommunizieren können. Wenn Sie noch nicht mit freigegebenen VPCs vertraut sind, lesen Sie die Dokumentation Freigegebene VPC – Übersicht.

Es gibt viele Möglichkeiten, einen internen Application Load Balancer in einem freigegebenen VPC-Netzwerk zu konfigurieren. Unabhängig vom Bereitstellungstyp müssen sich alle Komponenten des Load-Balancers in derselben Organisation befinden.

Subnetze und IP-Adresse Frontend-Komponenten Backend-Komponenten

Erstellen Sie das erforderliche Netzwerk und die Subnetze (einschließlich des Nur-Proxy-Subnetzes) im freigegebenen VPC-Hostprojekt.

Die interne IP-Adresse des Load-Balancers kann entweder im Hostprojekt oder in einem Dienstprojekt definiert werden. Sie muss jedoch ein Subnetz im gewünschten freigegebenen VPC-Netzwerk im Hostprojekt verwenden. Die Adresse selbst stammt aus dem primären IP-Bereich des Subnetzes, auf das verwiesen wurde.

 Die regionale interne IP-Adresse, die Weiterleitungsregel, der Ziel-HTTP(S)-Proxy und die zugehörige URL-Zuordnung müssen im selben Projekt definiert sein. Dieses Projekt kann das Hostprojekt oder ein Dienstprojekt sein. Sie haben folgende Möglichkeiten:
  • Erstellen Sie Backend-Dienste und Backends (Instanzgruppen, serverlose NEGs oder andere unterstützte Backend-Typen) im selben Dienstprojekt wie die Frontend-Komponenten.
  • Erstellen Sie Backend-Dienste und Backends (Instanzgruppen, serverlose NEGs oder andere unterstützte Backend-Typen) in so vielen Dienstprojekten wie nötig. Eine einzelne URL-Zuordnung kann auf Backend-Dienste in verschiedenen Projekten verweisen. Diese Art der Bereitstellung wird als projektübergreifende Dienstreferenz bezeichnet.

Jeder Backend-Dienst muss im selben Projekt wie die Backends definiert werden, auf die er verweist. Mit den Backend-Diensten verknüpfte Systemdiagnosen müssen auch im selben Projekt wie der Backend-Dienst definiert werden.

Sie können alle Load-Balancing-Komponenten und Backends im freigegebenen VPC-Hostprojekt erstellen, aber die Zuständigkeiten für Netzwerkverwaltung und Dienstentwicklung werden bei diesem Modell nicht getrennt.

Alle Load-Balancer-Komponenten und Back-Ends in einem Dienstprojekt

Das folgende Architekturdiagramm zeigt eine standardmäßige Bereitstellung einer freigegebenen VPC, bei der sich alle Load-Balancer-Komponenten und Backends in einem Dienstprojekt befinden. Dieser Bereitstellungstyp wird von allen Application Load Balancern unterstützt.

Der Load-Balancer verwendet IP-Adressen und Subnetze aus dem Hostprojekt. Clients können auf einen internen Application Load Balancer zugreifen, wenn sie sich im selben freigegebenen VPC-Netzwerk und in derselben Region wie der Load Balancer befinden. Clients können sich im Hostprojekt, in einem angehängten Dienstprojekt oder in verbundenen Netzwerken befinden.

Interner Application Load Balancer in einem freigegebenen VPC-Netzwerk
Interner Application Load Balancer in freigegebenem VPC-Netzwerk

Serverlose Back-Ends in einer freigegebenen VPC-Umgebung

Bei einem internen Application Load Balancer, der ein serverloses NEG-Backend verwendet, muss sich der Cloud Run-Sicherungsdienst im selben Dienstprojekt wie der Backend-Dienst und die serverlose NEG befinden. Die Frontend-Komponenten (Weiterleitungsregel, Zielproxy, URL-Zuordnung) des Load-Balancers können entweder im Hostprojekt, im selben Dienstprojekt wie die Backend-Komponenten oder in einem anderen Dienstprojekt in derselben Umgebung mit freigegebener VPC erstellt werden.

Projektübergreifender Dienstverweis

Der projektübergreifende Dienstverweis ist ein Bereitstellungsmodell, bei dem sich das Frontend und die URL-Zuordnung des Load Balancers in einem Projekt und der Backend-Dienst und die Backends des Load Balancers in einem anderen Projekt befinden.

Mit projektübergreifenden Dienstreferenzen können Organisationen einen zentralen Load-Balancer konfigurieren und Traffic an Hunderte von Diensten weiterleiten, die über mehrere verschiedene Projekte verteilt sind. Sie können alle Regeln und Richtlinien für das Traffic-Routing zentral in einer URL-Zuordnung verwalten. Sie können den Load-Balancer auch mit einem einzelnen Satz von Hostnamen und SSL-Zertifikaten verknüpfen. Sie können daher die Anzahl der für die Bereitstellung Ihrer Anwendung erforderlichen Load-Balancer optimieren und die Verwaltungs-, Betriebskosten- und Kontingentanforderungen reduzieren.

Wenn Sie für jedes Ihrer funktionalen Teams unterschiedliche Projekte verwenden, können Sie auch eine Trennung der Rollen innerhalb Ihrer Organisation erreichen. Dienstinhaber können sich auf das Erstellen von Diensten in Dienstprojekten konzentrieren, während Netzwerkteams Load-Balancer in einem anderen Projekt bereitstellen und verwalten können. Beide Dienste können über projektübergreifende Dienstreferenzen verbunden werden.

Dienstinhaber können die Autonomie der Freigabe ihrer Dienste aufrechterhalten und steuern, welche Nutzer über den Load-Balancer auf ihre Dienste zugreifen können. Dies wird durch eine spezielle IAM-Rolle mit der Bezeichnung Nutzer von Compute-Load-Balancer-Diensten (roles/compute.loadBalancerServiceUser) erreicht.

Bei internen Application Load Balancern wird der projektübergreifende Dienstverweis nur in Umgebungen mit freigegebene VPC unterstützt.

Informationen zum Konfigurieren der freigegebenen VPC für einen internen Application Load Balancer mit und ohne projektübergreifenden Dienstverweis finden Sie unter Internen Application Load Balancer mit freigegebener VPC einrichten.

Bekannte Einschränkungen beim projektübergreifenden Dienstverweis

  • Sie können nicht auf einen projektübergreifenden Backend-Dienst verweisen, wenn der Backend-Dienst regionale Internet-NEG-Backends hat. Alle anderen Backend-Typen werden unterstützt.
  • Google Cloud unterscheidet nicht zwischen Ressourcen (z. B. Backend-Diensten), die in mehreren Projekten denselben Namen verwenden. Wenn Sie projektübergreifende Dienstverweise verwenden, empfehlen wir daher, eindeutige Backend-Dienstnamen für alle Projekte in Ihrer Organisation zu verwenden.

Beispiel 1: Load-Balancer-Frontend und -Backend in verschiedenen Dienstprojekten

Im Folgenden finden Sie ein Beispiel für eine Bereitstellung in einer freigegebene VPC, bei der das Frontend und die URL-Zuordnung des Load Balancers in Dienstprojekt A erstellt werden. Die URL-Zuordnung verweist auf einen Backend-Dienst in Dienstprojekt B.

In diesem Fall benötigen Netzwerkadministratoren oder Load-Balancer-Administratoren im Dienstprojekt A Zugriff auf Backend-Dienste im Dienstprojekt B. Administratoren des Dienstprojekts B gewähren Load-Balancer-Administratoren im Dienstprojekt A, die auf den Backend-Dienst im Dienstprojekt B verweisen möchten, die IAM-Rolle compute.loadBalancerServiceUser.

Frontend und URL-Zuordnung des Load-Balancers im Dienstprojekt
Frontend und Backend des Load-Balancers in verschiedenen Dienstprojekten

Beispiel 2: Load-Balancer-Frontend im Hostprojekt und Back-Ends in Dienstprojekten

Im Folgenden finden Sie ein Beispiel für eine Bereitstellung mit freigegebene VPC, bei der das Frontend und die URL-Zuordnung des Load Balancers im Hostprojekt und die Backend-Dienste (und Backends) in Dienstprojekten erstellt werden.

In diesem Fall benötigen Netzwerkadministratoren oder Load-Balancer-Administratoren im Hostprojekt Zugriff auf Backend-Dienste im Dienstprojekt. Dienstprojektadministratoren erteilen Load-Balancer-Administratoren im Hostprojekt A, die auf den Backend-Dienst im Dienstprojekt verweisen möchten, die IAM-Rolle compute.loadBalancerServiceUser.

Frontend und URL-Zuordnung des Load Balancers im Hostprojekt
Frontend und URL-Zuordnung des Load Balancers im Hostprojekt (zum Vergrößern anklicken)

Zeitüberschreitungen und Wiederholungsversuche

Interne Application Load Balancer unterstützen die folgenden Zeitüberschreitungstypen:

Zeitlimittyp und Beschreibung Standardwerte Unterstützt benutzerdefinierte Werte
Regionsübergreifend Regional
Zeitlimit für Backend-Dienst

Eine Zeitüberschreitung bei Anfrage und Antwort. Stellt die maximale Zeitspanne dar, die ablaufen kann, wenn der Load Balancer das erste Byte einer Anfrage an das Backend sendet, bis das Backend das letzte Byte der HTTP-Antwort an den Load Balancer zurückgibt. Wenn das Backend die vollständige HTTP-Antwort nicht innerhalb dieses Zeitlimits an den Load Balancer zurückgegeben hat, werden die verbleibenden Antwortdaten gelöscht.
  • Für serverlose NEGs in einem Backend-Dienst: 60 Minuten
  • Für alle anderen Backend-Typen in einem Backend-Dienst: 30 Sekunden
Client-HTTP-Keepalive-Zeitlimit

Die maximale Zeitspanne, in der die TCP-Verbindung zwischen einem Client und dem verwalteten Envoy-Proxy des Load Balancers inaktiv sein kann. (Die gleiche TCP-Verbindung kann für mehrere HTTP-Anfragen verwendet werden.)

 10 Minuten und 600 Sekunden
HTTP-Keepalive-Zeitlimit des Back-Ends

Die maximale Zeitspanne, in der die TCP-Verbindung zwischen dem verwalteten Envoy-Proxy des Load Balancers und einem Backend inaktiv sein kann. (Die gleiche TCP-Verbindung kann für mehrere HTTP-Anfragen verwendet werden.)

 10 Minuten und 600 Sekunden

Zeitlimit für Backend-Dienst

Das konfigurierbare Zeitlimit des Backend-Diensts stellt die maximale Zeitspanne dar, die der Load Balancer auf die Verarbeitung einer HTTP-Anfrage durch das Backend wartet und die entsprechende HTTP-Antwort zurückgibt. Mit Ausnahme von serverlosen NEGs beträgt der Standardwert für das Zeitlimit des Backend-Diensts 30 Sekunden.

Wenn Sie beispielsweise eine Datei mit 500 MB herunterladen möchten und der Wert des Zeitlimits für den Backend-Dienst 90 Sekunden beträgt, erwartet der Load Balancer, dass das Backend die gesamte Datei mit 500 MB innerhalb von 90 Sekunden bereitstellt. Das Zeitlimit für den Backend-Dienst kann auch so konfiguriert werden, dass das Backend seine vollständige HTTP-Antwort sendet. Wenn der Load Balancer in dieser Situation zumindest HTTP-Antwortheader erhalten hat, sendet er die vollständigen Antwortheader und so viel vom Antwort-Body zurück, wie er innerhalb des Zeitlimits für den Backend-Dienst erhalten konnte.

Sie sollten das Zeitlimit für den Backend-Dienst auf die längste Zeitspanne festlegen, von der Sie erwarten, dass Ihr Backend sie zur Verarbeitung einer HTTP-Antwort benötigt. Sie sollten das Zeitlimit für den Backend-Dienst erhöhen, wenn die auf Ihrem Backend ausgeführte Software mehr Zeit benötigt, um eine HTTP-Anfrage zu verarbeiten und die gesamte Antwort zurückzugeben.

Das Zeitlimit für den Backend-Dienst akzeptiert Werte zwischen 1 und 2,147,483,647 Sekunden. Größere Werte sind jedoch keine praktischen Konfigurationsoptionen. Google Cloud garantiert auch nicht, dass eine zugrunde liegende TCP-Verbindung für den gesamten Wert des Zeitlimits des Backend-Diensts geöffnet bleibt. Clientsysteme müssen eine Wiederholungslogik implementieren, anstatt sich auf eine TCP-Verbindung zu verlassen, die über einen längeren Zeitraum offen ist.

Bei WebSocket-Verbindungen, die mit internen Application Load Balancern verwendet werden, folgen aktive WebSocket-Verbindungen nicht der Zeitüberschreitung des Backend-Dienstes. Inaktive WebSocket-Verbindungen werden nach der Zeitüberschreitung des Backend-Dienstes geschlossen.

Google Cloud startet die Anzahl der Envoy-Softwareaufgaben regelmäßig neu oder ändert sie. Je länger der Zeitlimitwert des Backend-Diensts ist, desto wahrscheinlicher ist es, dass TCP-Verbindungen durch Envoy-Aufgabenneustarts oder -ersetzungen beendet werden.

Verwenden Sie eine der folgenden Methoden, um das Zeitlimit des Backend-Dienstes zu konfigurieren:

Console

Ändern Sie das Feld Zeitlimit des Backend-Diensts des Load Balancers.

gcloud

Verwenden Sie den Befehl gcloud compute backend-services update, um den Parameter --timeout der Backend-Dienstressource zu ändern.

API

Ändern Sie den Parameter timeoutSec für die Ressource regionBackendServices.

Client-HTTP-Keepalive-Zeitlimit

Das Client-HTTP-Keepalive-Zeitlimit stellt die maximale Zeitspanne dar, die eine TCP-Verbindung zwischen dem (nachgelagerten) Client und einem Envoy-Proxy inaktiv sein kann. Der Standardwert für das Client-HTTP-Keepalive-Zeitlimit beträgt 600 Sekunden. Sie können das Zeitlimit mit einem Wert zwischen 5 und 600 Sekunden konfigurieren.

Ein HTTP-Keepalive-Zeitlimit wird auch als TCP-Leerlaufzeitlimit bezeichnet.

Das Client-HTTP-Zeitlimit des Load Balancers sollte größer sein als das HTTP Keepalive-Zeitlimit (TCP inaktiv), das von nachgelagerten Clients oder Proxys verwendet wird. Wenn ein nachgelagerter Client ein größeres HTTP Keepalive-Zeitlimit (TCP inaktiv) hat als das HTTP Keepalive-Zeitlimit des Clients des Load Balancers, kann eine Race-Bedingung auftreten. Aus Sicht eines nachgelagerten Clients kann eine bestehende TCP-Verbindung länger als der Load Balancer inaktiv sein. Das bedeutet, dass der nachgelagerte Client Pakete senden kann, nachdem der Load Balancer die TCP-Verbindung als geschlossen betrachtet. In diesem Fall antwortet der Load Balancer mit einem TCP-Rücksetzpaket (RST).

HTTP-Keepalive-Zeitlimit des Back-Ends

Interne Application Load Balancer sind Proxys, die eine erste TCP-Verbindung zwischen dem (nachgelagerten) Client und einem Envoy-Proxy und eine zweite TCP-Verbindung zwischen dem Envoy-Proxy und Ihren Back-Ends verwenden.

Die sekundären TCP-Verbindungen des Load Balancers werden möglicherweise nicht nach jeder Anfrage geschlossen. Sie können offen bleiben, um mehrere HTTP-Anfragen und -Antworten zu verarbeiten. Das Backend-HTTP-Keepalive-Zeitlimit definiert das TCP-Leerlaufzeitlimit zwischen dem Load Balancer und Ihren Backends. Das Backend-HTTP-Keepalive-Zeitlimit gilt nicht für WebSockets.

Das Backend für das Keepalive-Zeitlimit ist auf 10 Minuten (600 Sekunden) beschränkt und kann nicht geändert werden. Das Backend-Keepalive-Zeitlimit des Load Balancers sollte unter dem Keepalive-Zeitlimit liegen, das von Software verwendet wird, die auf Ihren Backends ausgeführt wird. Dadurch wird eine Race-Bedingung vermieden, bei der das Betriebssystem Ihrer Back-Ends TCP-Verbindungen mit einem TCP-Zurücksetzen (RST) schließen kann. Da das Backend-Keepalive-Zeitlimit für den Load-Balancer nicht konfigurierbar ist, müssen Sie Ihre Backend-Software so konfigurieren, dass der HTTP-Keepalive-Zeitlimit (TCP inaktiv) größer als 600 Sekunden ist.

In der folgenden Tabelle sind die Änderungen aufgeführt, die zum Ändern der Keepalive-Zeitüberschreitungswerte für häufig verwendete Webserversoftware erforderlich sind.

Webserversoftware Parameter Standardeinstellung Empfohlene Einstellung
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

Wiederholungsversuche

Zum Konfigurieren von Wiederholungsversuchen können Sie in der URL-Zuordnung eine Wiederholungsrichtlinie verwenden. Die Standardanzahl an Wiederholungen (numRetries) ist 1. Der maximal konfigurierbare Wert für perTryTimeout ist 24 Stunden.

Ohne eine Wiederholungsrichtlinie werden fehlgeschlagene Anfragen ohne HTTP-Text (z. B. GET-Anfragen), die zu HTTP-Antworten 502, 503 oder 504 führen, einmal wiederholt.

HTTP-POST-Anfragen werden nicht wiederholt.

Bei wiederholten Requests wird nur ein Log-Eintrag für die endgültige Antwort generiert.

Weitere Informationen finden Sie unter Logging und Monitoring für Application Load Balancer.

Auf verbundene Netzwerke zugreifen

Ihre Clients kann auf einen internen Application Load Balancer in Ihrem VPC-Netzwerk über ein verbundenes Netzwerk zugreifen und zwar mithilfe von:

  • VPC-Netzwerk-Peering
  • Cloud VPN und Cloud Interconnect

Ausführliche Beispiele finden Sie unter Interne Application Load Balancer und verbundene Netzwerke.

Failover

Wenn ein Backend fehlerhaft wird, wird der Traffic automatisch zu fehlerfreien Backends weitergeleitet.

In der folgenden Tabelle wird das Failover-Verhalten in den einzelnen Modi beschrieben:

Load-Balancer-Modus Failover-Verhalten Verhalten, wenn alle Back-Ends fehlerhaft sind
Regionsübergreifender interner Application Load Balancer

Automatisches Failover auf fehlerfreie Backends in derselben Region oder in anderen Regionen.

Der Traffic wird anhand der konfigurierten Trafficverteilung auf fehlerfreie Backends verteilt, die sich über mehrere Regionen erstrecken.

 Gibt HTTP 503 zurück
Regionaler interner Application Load Balancer

Automatisches Failover auf fehlerfreie Back-Ends in derselben Region.

Der Envoy-Proxy sendet Traffic an fehlerfreie Backends in einer Region anhand der konfigurierten Trafficverteilung.

 Gibt HTTP 503 zurück

Hochverfügbarkeit und regionsübergreifender Failover

Für regionale interne Application Load Balancer

Um eine hohe Verfügbarkeit zu erreichen, sollten Sie mehrere regionale interne Application Load Balancer in Regionen bereitstellen, die den Traffic Ihrer Anwendung am besten unterstützen. Anschließend verwenden Sie eine Cloud DNS-Routingrichtlinie für die Standortbestimmung, um zu erkennen, ob ein Load Balancer bei einem regionalen Ausfall antwortet. Mit einer Standortbestimmungsrichtlinie wird Traffic basierend auf dem Ursprung der Clientanfrage an die nächstgelegene verfügbare Region weitergeleitet. Die Systemdiagnose ist standardmäßig für interne Application Load Balancer verfügbar.

Für regionenübergreifende interne Application Load Balancer

Sie können einen regionenübergreifenden internen Application Load Balancer in mehreren Regionen einrichten, um folgende Vorteile zu erhalten:

  1. Wenn der regionenübergreifende interne Application Load Balancer in einer Region ausfällt, leiten die DNS-Routingrichtlinien den Traffic an einen regionenübergreifenden internen Application Load Balancer in einer anderen Region weiter.

    Das Bereitstellungsbeispiel für Hochverfügbarkeit zeigt Folgendes:

    • Ein regionenübergreifender interner Application Load Balancer mit virtueller Frontend-IP-Adresse (VIP) in den Regionen RegionA und RegionB in Ihrem VPC-Netzwerk. Die Clients befinden sich in der Region RegionA.
    • Sie können den Load Balancer über Frontend-VIPs aus zwei Regionen zugänglich machen und mit DNS-Routingrichtlinien die optimale VIP an Ihre Clients zurückgeben. Verwenden Sie Standortbestimmung-Routingrichtlinien, wenn Ihre Clients die VIP verwenden sollen, die ihnen geografisch am nächsten ist.
    • DNS-Routingrichtlinien können erkennen, ob eine VIP während eines regionalen Ausfalls nicht antwortet, und die nächste optimale VIP an Ihre Clients zurückgeben, damit Ihre Anwendung auch bei regionalen Ausfällen verfügbar bleibt.
    Bereitstellung mit Hochverfügbarkeit für regionsübergreifenden internen Application Load Balancer.
    Regionenübergreifender interner Application Load Balancer mit Hochverfügbarkeitsbereitstellung (zum Vergrößern klicken) Vergrößern).

  2. Wenn Backends in einer bestimmten Region ausfallen, wird der regionenübergreifende interne Traffic des Application Load Balancers ordnungsgemäß auf die Backends in einer anderen Region übertragen.

    Das Beispiel für die regionenübergreifende Failover-Bereitstellung zeigt Folgendes:

    • Ein regionenübergreifender interner Application Load Balancer mit einer Frontend-VIP-Adresse in der Region RegionA Ihres VPC-Netzwerks. Ihre Kunden befinden sich ebenfalls in der Region RegionA.
    • Einen globalen Backend-Dienst, der auf die Backends in den Google Cloud-Regionen RegionA und RegionB verweist.
    • Wenn die Backends in der Region RegionA ausfallen, wird der Traffic auf die Region RegionB umgeleitet.
    Regionenübergreifender interner Application Load Balancer mit einer regionenübergreifenden Failover-Bereitstellung.
    Regionenübergreifender interner Application Load Balancer mit regionsübergreifender Failover-Bereitstellung (zum Vergrößern klicken)

WebSocket-Unterstützung

HTTP(S)-basierte Load Balancer von Google Cloud unterstützen das WebSocket-Protokoll, wenn Sie HTTP oder HTTPS als Protokoll für das Backend verwenden. Der Load-Balancer benötigt zum Weiterleiten von WebSocket-Verbindungen über einen Proxy keine Konfiguration.

Das WebSocket-Protokoll bietet einen Vollduplex-Kommunikationskanal zwischen Clients und dem Load Balancer. Weitere Informationen finden Sie unter RFC 6455.

Das WebSocket-Protokoll funktioniert so:

  1. Der Load Balancer erkennt eine WebSocket-Upgrade-Anfrage von einem HTTP(S)-Client. Die Anfrage enthält die Header Connection: Upgrade und Upgrade: websocket, gefolgt von anderen relevanten WebSocket-bezogenen Anfrageheadern.
  2. Das Backend sendet eine WebSocket-Upgrade-Antwort. Die Backend-Instanz sendet eine 101 switching protocol-Antwort mit Connection: Upgrade, Upgrade: websocket-Headern und anderen WebSocket-bezogenen Antwortheadern.
  3. Der Load Balancer leitet für die Dauer der aktuellen Verbindung bidirektionalen Traffic über einen Proxy weiter.

Wenn die Back-End-Instanz eine Fehlerantwort mit dem Antwortcode 426 oder 502 zurückgibt, schließt der Load Balancer die Verbindung.

Die Sitzungsaffinität für WebSockets funktioniert wie für jede andere Anfrage. Weitere Informationen finden Sie unter Sitzungsaffinität.

gRPC-Unterstützung

gRPC ist ein Open Source-Framework für Remoteprozeduraufrufe. Es basiert auf dem HTTP/2-Standard. Anwendungsfälle für gRPC sind:

  • Hoch skalierbare, verteilte Systeme mit geringer Latenz
  • Entwicklung mobiler Clients, die mit einem Cloud-Server kommunizieren
  • Entwurf neuer Protokolle, die genau, effizient und sprachunabhängig sein müssen
  • Layerdesign, um Erweiterung, Authentifizierung und Protokollierung zu ermöglichen

Um gRPC mit Ihren Google Cloud-Anwendungen zu verwenden, müssen Sie Anfragen durchgehend über HTTP/2 weiterleiten. So gehen Sie dazu vor:

  1. Konfigurieren Sie einen HTTPS-Load-Balancer.
  2. Wählen Sie HTTP/2 als Protokoll vom Load-Balancer zu den Back-Ends aus.

Der Load-Balancer verhandelt HTTP/2 mit Clients als Teil des SSL-Handshakes und verwendet dazu die ALPN TLS-Erweiterung.

Der Load-Balancer kann mit einigen Clients weiter HTTPS aushandeln oder unsichere HTTP-Anfragen auf einem Load-Balancer akzeptieren, der für die Verwendung von HTTP/2 zwischen dem Load-Balancer und den Backend-Instanzen konfiguriert ist. Diese HTTP- oder HTTPS-Anfragen werden vom Lastenausgleichsmodul transformiert, um die Anfragen über HTTP/2 an die Backend-Instanzen weiterzuleiten.

Sie müssen TLS auf Ihren Back-Ends aktivieren. Weitere Informationen finden Sie unter Verschlüsselung vom Load-Balancer zu Back-Ends.

TLS-Support

Standardmäßig akzeptiert ein HTTPS-Zielproxy nur TLS 1.0, 1.1, 1.2 und 1.3, wenn SSL-Requests von Clients beendet werden.

Wenn der Load Balancer HTTPS als Back-End-Dienstprotokoll verwendet, kann er TLS 1.0, 1.1, 1.2 oder 1.3 mit dem Back-End aushandeln.

Unterstützung für gegenseitiges TLS

Mutual TLS (mTLS) ist ein Industriestandardprotokoll für die gegenseitige Authentifizierung zwischen einem Client und einem Server. Sie sorgt dafür, dass sich sowohl Client als auch Server gegenseitig authentifizieren, indem sie überprüft, ob beide ein gültiges Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle (Certificate Authority, CA) haben. Im Gegensatz zu Standard-TLS, bei dem nur der Server authentifiziert wird, müssen bei mTLS sowohl der Client als auch der Server Zertifikate vorlegen, um die Identitäten beider Seiten zu bestätigen, bevor eine Kommunikation hergestellt wird.

Alle Application Load Balancer unterstützen mTLS. Bei mTLS fordert der Load Balancer an, dass der Client während des TLS-Handshakes mit dem Load Balancer ein Zertifikat sendet, um sich zu authentifizieren. Sie können einen Zertifikatmanager-Trust Store konfigurieren, mit dem der Load Balancer dann die Vertrauenskette des Clientzertifikats validiert.

Weitere Informationen zu mTLS finden Sie unter Gegenseitige TLS-Authentifizierung.

Beschränkungen

  • Es kann nicht garantiert werden, dass eine Anfrage von einem Client in einer Zone der Region an ein Backend gesendet wird, das sich in derselben Zone wie der Client befindet. Die Sitzungsaffinität reduziert nicht die Kommunikation zwischen Zonen.

  • Interne Application Load Balancer sind nicht mit den folgenden Features kompatibel:

  • Ein interner Application Load Balancer unterstützt HTTP/2 nur über TLS.

  • Clients, die eine Verbindung zu einem internen Application Load Balancer herstellen, müssen HTTP-Version 1.1 oder höher verwenden. HTTP 1.0 wird nicht unterstützt.

  • Von Google Cloud wird keine Warnung ausgegeben, wenn das Nur-Proxy-Subnetz keine IP-Adressen mehr hat.

  • Die interne Weiterleitungsregel, die Ihr interner Application Load Balancer verwendet, muss genau einen Port haben.

  • Interne Application Load Balancer unterstützen Cloud Trace nicht.

  • Wenn Sie einen internen Application Load Balancer mit Cloud Run in einer freigegebenen VPC-Umgebung verwenden, können eigenständige VPC-Netzwerke in Dienstprojekten Traffic an alle anderen Cloud Run-Dienste senden, die in einem anderen Dienstprojekte in derselben freigegebenen VPC-Umgebung bereitgestellt werden. Dies ist ein bekanntes Problem. Diese Form des Zugriffs wird in Zukunft blockiert.

  • Google Cloud kann nicht garantieren, dass eine zugrunde liegende TCP-Verbindung während des gesamten festgelegten Zeitlimits für den Backend-Dienst geöffnet bleibt. Clientsysteme müssen eine Wiederholungslogik implementieren, anstatt sich auf eine TCP-Verbindung zu verlassen, die über einen längeren Zeitraum offen ist.

Nächste Schritte