Internes HTTP(S)-Load-Balancing

Das interne HTTP(S)-Load-Balancing von Google Cloud ist ein proxy-basierter, regionaler Layer-7-Load-Balancer, mit dem Sie Ihre Dienste hinter einer internen IP-Adresse ausführen und skalieren können.

Das interne HTTP(S)-Load-Balancing verteilt HTTP- und HTTPS-Traffic auf Back-Ends, die in Compute Engine, Google Kubernetes Engine (GKE) und Cloud Run gehostet werden. Auf den Load-Balancer kann nur in der ausgewählten Region Ihres VPC-Netzwerks (Virtual Private Cloud) mit einer internen IP-Adresse zugegriffen werden.

Das interne HTTP(S)-Load-Balancing ist ein verwalteter Dienst, der auf dem Open-Source-Proxy von Envoy basiert. Dadurch werden zahlreiche Funktionen zur Trafficsteuerung anhand von HTTP(S)-Parametern ermöglicht. Nachdem der Load-Balancer konfiguriert wurde, werden automatisch Envoy-Proxys zugewiesen, um Ihre Trafficanforderungen zu erfüllen.

Auf übergeordneter Ebene besteht ein interner HTTP(S)-Load-Balancer aus Folgendem:

  • Einer internen IP-Adresse, an die Clients Traffic senden. Nur Clients, die sich in derselben Region befinden wie der Load-Balancer, können auf diese IP-Adresse zugreifen. Interne Clientanfragen bleiben in Ihrem Netzwerk und in Ihrer Region.
  • Einem oder mehreren Back-End-Diensten, an die der Load-Balancer Traffic weiterleitet. Back-Ends können Compute Engine-VMs, Gruppen von Compute Engine-VMs (über Instanzgruppen), Cloud Run-Anwendungen oder GKE-Knoten (über Netzwerk-Endpunktgruppen [NEGs]) sein. Diese Back-Ends müssen sich in derselben Region wie der Load-Balancer befinden.
Interne Dienste mit auf Layer 7 beruhendem Load-Balancing (zum Vergrößern klicken)
Interne Dienste mit auf Layer 7 basierendem Load-Balancing (zum Vergrößern klicken)

Informationen zu Einschränkungen, die für das interne HTTP(S)-Load-Balancing gelten, finden Sie im Abschnitt Einschränkungen.

Informationen über die unterschiedlichen Google Cloud-Load-Balancer finden Sie in den folgenden Dokumenten:

Anwendungsfälle

Das interne HTTP(S)-Load-Balancing ist für viele Anwendungsfälle geeignet. Dieser Abschnitt enthält einige allgemeine Beispiele. Weitere Beispiele finden Sie unter Anwendungsfälle für die Trafficverwaltung.

Dreistufige Webdienste

Sie können das interne HTTP(S)-Load-Balancing verwenden, um herkömmliche dreistufige Webdienste zu unterstützen. Das folgende Beispiel zeigt, wie Sie mit drei Arten von Google Cloud-Load-Balancern drei Stufen skalieren können. Auf jeder Stufe hängt die Art des Load-Balancers von Ihrem Traffictyp ab:

  • Webstufe: Der Traffic geht über das Internet ein und wird mithilfe eines externen HTTP(S)-Load-Balancers entsprechend verteilt.

  • Anwendungsstufe: Die Anwendungsstufe wird mithilfe eines regionalen internen HTTP(S)-Load-Balancers skaliert.

  • Datenbankstufe: Die Datenbankstufe wird mithilfe eines internen TCP/UDP-Load-Balancers skaliert.

Das Diagramm zeigt, wie sich der Traffic durch die Ebenen bewegt:

  1. Ein externer HTTP(S)-Load-Balancer verteilt den Traffic aus dem Internet an eine Reihe von Web-Front-End-Instanzgruppen in verschiedenen Regionen.
  2. Diese Front-Ends senden den HTTP(S)-Traffic an eine Reihe von regionalen, internen HTTP(S)-Load-Balancern (Gegenstand dieser Übersicht).
  3. Die internen HTTP(S)-Load-Balancer verteilen den Traffic auf Middleware-Instanzgruppen.
  4. Diese Middleware-Instanzgruppen senden den Traffic an interne TCP/UDP-Load-Balancer, die den Traffic auf Datenspeichercluster verteilen.
Auf Layer 7 basiertes Routing für interne Ebenen in einer mehrstufigen Anwendung (zum Vergrößern klicken)
Auf Layer 7 basiertes Routing für interne Ebenen in einer mehrstufigen Anwendung

Load-Balancing mit pfadbasiertem Routing

Ein häufiger Anwendungsfall ist das Load-Balancing zwischen verschiedenen Diensten. In diesem Beispiel fordert ein interner Client mithilfe derselben Basis-URL mygcpservice.internal und den Pfaden /video und /images Video- und Bildinhalte an.

Die URL-Zuordnung des internen HTTP(S)-Load-Balancers gibt an, dass Anfragen an den Pfad /video an den Back-End-Dienst für Videos und Anfragen an den Pfad /images an den Back-End-Dienst für Bilder gesendet werden. Im folgenden Beispiel werden die Back-End-Dienste für Videos und Bilder mithilfe von Compute Engine-VMs bereitgestellt. Sie können jedoch auch mithilfe von GKE-Pods bereitgestellt werden.

Wenn ein interner Client eine Anfrage an die interne IP-Adresse des Load-Balancers sendet, wertet der Load-Balancer die Anfrage gemäß dieser Logik aus und sendet sie an den richtigen Back-End-Dienst.

Das folgende Diagramm veranschaulicht diesen Anwendungsfall.

Interne (Mikro-)Dienste mit auf Layer 7 beruhendem Load-Balancing (zum Vergrößern klicken)
Interne (Mikro-)Dienste mit auf Layer 7 basierendem Load-Balancing

Legacy-Dienste modernisieren

Das interne HTTP(S)-Load-Balancing kann ein wirksames Tool zur Modernisierung von Legacy-Anwendungen sein.

Ein Beispiel für eine Legacy-Anwendung ist eine umfangreiche monolithische Anwendung, die sich nicht einfach aktualisieren lässt. In diesem Fall können Sie vor der Legacy-Anwendung einen internen HTTP(S)-Load-Balancer bereitstellen. Anschließend können Sie die Trafficsteuerungsfunktionen des Load-Balancers verwenden, um einen Teil des Traffics an neue Mikrodienste weiterzuleiten, die die von Ihrer Legacy-Anwendung bereitgestellten Funktionen ersetzen.

Zuerst würden Sie die URL-Zuordnung des Load-Balancers so konfigurieren, dass standardmäßig der gesamte Traffic zur Legacy-Anwendung weitergeleitet wird. Somit wird das bereits gegebene Verhalten beibehalten. Wenn Ersatzdienste entwickelt werden, würden Sie die URL-Zuordnung aktualisieren, um Teile des Traffics an diese Ersatzdienste weiterzuleiten.

Angenommen, Ihre Legacy-Anwendung umfasst eine Funktion zur Verarbeitung von Videos, die bereitgestellt wird, wenn interne Clients Anfragen an /video senden. So könnten Sie diesen Videodienst herauslösen und in einen separaten Mikrodienst aufnehmen:

  1. Fügen Sie vor Ihrer Legacy-Anwendung ein internes HTTP(S)-Load-Balancing hinzu.
  2. Erstellen Sie einen Ersatzmikrodienst zur Verarbeitung von Videos.
  3. Aktualisieren Sie die URL-Zuordnung des Load-Balancers, sodass alle Anfragen an den Pfad /video an den neuen Mikrodienst und nicht an die Legacy-Anwendung weitergeleitet werden.

Im Zuge der Entwicklung zusätzlicher Ersatzdienste würden Sie die URL-Zuordnung fortlaufend aktualisieren. Im Laufe der Zeit würden weniger Anfragen an die Legacy-Anwendung weitergeleitet. Schließlich würden Ersatzdienste für alle Funktionen der Legacy-Anwendung zur Verfügung stehen. An diesem Punkt können Sie Ihre Legacy-Anwendung entfernen.

Load-Balancing 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.

Das folgende Diagramm zeigt eine Hybridbereitstellung mit einem internen HTTP(S)-Load-Balancer.

Hybridkonnektivität mit internem HTTP(S)-Load-Balancing (zum Vergrößern klicken)
Hybridkonnektivität mit internem HTTP(S)-Load-Balancing (zum Vergrößern klicken)

Private Service Connect

Sie können ein internes HTTP(S)-Load-Balancing verwenden, um Anfragen an unterstützte regionale Google APIs und -Dienste zu senden. Weitere Informationen finden Sie unter Private Service Connect verwenden, um mit HTTP(S)-Nutzerdienstkontrollen auf Google APIs zuzugreifen.

Load-Balancing für GKE-Anwendungen

Wenn Sie Anwendungen in GKE erstellen, empfehlen wir die Verwendung des integrierten GKE-Ingress-Controller, der Google Cloud-Load-Balancer im Namen von GKE-Nutzern bereitstellt. Dies ist mit der auf dieser Seite beschriebenen eigenständigen Load-Balancing-Architektur identisch, mit dem Unterschied, dass der Lebenszyklus vollständig automatisiert ist und von GKE gesteuert wird.

Zugehörige GKE-Dokumentation:

Architektur und Ressourcen

Das folgende Diagramm zeigt die Google Cloud-Ressourcen, die für einen internen HTTP(S)-Load-Balancer erforderlich sind.

Komponenten des internen HTTP(S)-Load-Balancings (zum Vergrößern klicken)
Komponenten des internen HTTP(S)-Load-Balancings

Jeder interne HTTP(S)-Load-Balancer verwendet die folgenden Google Cloud-Konfigurationsressourcen:

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 HTTP(S)-Load-Balancer verwenden, ein Nur-Proxy-Subnetz erstellen. Alle internen HTTP(S)-Load-Balancer in einer Region und einem VPC-Netzwerk haben dasselbe Nur-Proxy-Subnetz, da alle internen HTTP(S)-Load-Balancer in der Region und dem VPC-Netzwerk einen Pool von Envoy-Proxys teilen. Weiter:

  • Nur-Proxy-Subnetze werden nur für Envoy-Proxys und nicht für Ihre Back-Ends verwendet.
  • Back-End-VMs bzw. Endpunkte aller internen HTTP(S)-Load-Balancer in einer Region und einem VPC-Netzwerk empfangen Verbindungen vom Nur-Proxy-Subnetz.
  • Die IP-Adresse eines internen HTTP(S)-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

Eine intern verwaltete Weiterleitungsregel gibt eine interne IP-Adresse, einen Port und einen regionalen HTTP(S)-Ziel-Proxy an. 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 internen HTTP(S)-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 interne IP-Adresse der Weiterleitungsregel kann aus jedem Subnetz (im selben Netzwerk und in derselben Region) stammen, wobei das Flag --purpose auf PRIVATE gesetzt ist. Hinweis:

  • Die IP-Adresse kann (muss aber nicht) aus demselben Subnetz wie die Back-End-Instanzgruppen stammen.
  • Die IP-Adresse darf nicht aus dem reservierten Nur-Proxy-Subnetz stammen, dessen Flag --purpose auf REGIONAL_MANAGED_PROXY gesetzt ist.

Jede externe Weiterleitungsregel, die Sie in einem internen HTTP(S)-Load-Balancer verwenden, kann auf genau einen TCP-Port verweisen. Verwenden Sie für HTTP-Load-Balancer entweder Port 80 oder 8080 und für HTTPS-Load-Balancer Port 443.

Zielproxy

Ein regionaler 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 Back-End-Instanz erfasst möglicherweise diese Adresse sowie die eigene IP-Adresse der Back-End-Instanz.

SSL-Zertifikate

Transport Layer Security (TLS) ist ein Verschlüsselungsprotokoll, das in SSL-Zertifikaten zum Schutz der Netzwerkkommunikation verwendet wird.

Google Cloud verwendet SSL-Zertifikate, um für einen Load-Balancer Datenschutz und Sicherheit von einem Client bereitzustellen. Wenn Sie das HTTPS-basierte Load-Balancing verwenden, müssen Sie ein oder mehrere SSL-Zertifikate auf dem HTTPS-Ziel-Proxy installieren.

Weitere Informationen zu SSL-Zertifikaten finden Sie hier:

URL-Zuordnung

Der HTTP(S)-Proxy verwendet eine regionale URL-Zuordnung, um anhand von HTTP-Attributen (z. B. Anfragepfad, Cookies oder Header) eine Routingentscheidung zu treffen. Anhand dieser Entscheidung leitet der Proxy Clientanfragen an bestimmte regionale Back-End-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.

Back-End-Dienst

Ein regionaler Back-End-Dienst verteilt Anfragen an fehlerfreie Back-Ends: Instanzgruppen mit Compute Engine-VMs, NEGs mit GKE-Containern oder Private Service Connect-NEGs, die auf unterstützte Google APIs und Google-Dienste verweisen.

Back-End-Dienste unterstützen die HTTP-, HTTPS- oder HTTP/2-Protokolle. HTTP/2 wird nur über TLS unterstützt. Clients und Back-Ends müssen nicht dasselbe Anfrageprotokoll verwenden. Clients können beispielsweise Anfragen mit HTTP/2 an den Load-Balancer senden und der Load-Balancer kann diese Anfragen mit HTTP/1.1 an Back-Ends weiterleiten.

Mindestens ein Back-End muss mit dem Back-End-Dienst verbunden sein. Da der Bereich eines internen HTTP(S)-Load-Balancers regional und nicht global ist, müssen sich Clients und Back-End-VMs oder Endpunkte alle in derselben Region befinden. Back-Ends können Instanzgruppen oder NEGs in einer beliebigen der folgenden Konfigurationen sein:

  • Verwaltete Instanzgruppen (zonal oder regional)
  • Nicht verwaltete Instanzgruppen (zonal)
  • Netzwerk-Endpunktgruppen

Sie können nicht sowohl Instanzgruppen als auch NEGs für denselben Back-End-Dienst verwenden.

Back-Ends und VPC-Netzwerke

Alle Back-Ends müssen sich in demselben VPC-Netzwerk und derselben Region befinden. Das Platzieren von Back-Ends in verschiedenen VPC-Netzwerken, auch wenn diese über VPC-Netzwerk-Peering verbunden sind, wird nicht unterstützt. Weitere Informationen dazu, wie Clientsysteme in Peering-VPC-Netzwerken auf Load-Balancer zugreifen können, finden Sie unter Internes HTTP(S)-Load-Balancing und verbundene Netzwerke.

Back-End-Teilmengeneinstellung

Die Back-End-Teileinstellung ist eine optionale Funktion, die die Leistung und Skalierbarkeit verbessert, indem jeder der Proxyinstanzen eine Teilmenge der Back-Ends zugewiesen wird.

Standardmäßig ist die Back-End-Teileinstellung deaktiviert. Informationen zum Aktivieren dieser Funktion finden Sie unter Back-End-Teileinstellung für internen HTTP(S)-Load-Balancer.

Systemdiagnose

Eine regionale Systemdiagnose überwacht regelmäßig die Bereitschaft Ihrer Back-Ends. Dadurch besteht ein geringeres Risiko, dass Anfragen an Back-Ends gesendet werden, die die Anfrage nicht verarbeiten können.

Firewallregeln

Für einen internen HTTP(S)-Load-Balancer sind die folgenden Firewallregeln erforderlich:

Architekturen freigegebener VPCs

Das interne HTTP(S)-Load-Balancing unterstützt Netzwerke, die eine freigegebene VPC verwenden. Mit einer freigegebenen VPC können Sie die Zuständigkeiten zwischen Netzwerkadministratoren und Dienstentwicklern klar trennen. Ihre Entwicklungsteams können sich auf das Erstellen von Diensten in Dienstprojekten konzentrieren, während die Netzwerkinfrastrukturteams das Load-Balancing bereitstellen und verwalten können. Darüber hinaus können Ihre Netzwerkadministratoren interne IP-Adressen sicher und effizient verwalten. Wenn Sie noch nicht mit freigegebenen VPCs vertraut sind, lesen Sie die Dokumentation Freigegebene VPC – Übersicht.

Es gibt viele Möglichkeiten, das interne HTTP(S)-Load-Balancing 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 Weiterleitungsregel Zielproxy und URL-Zuordnung Back-End-Komponenten
Erstellen Sie das erforderliche Netzwerk, Subnetze (einschließlich des Nur-Proxy-Subnetzes) und interne IP-Adressen im freigegebenen VPC-Hostprojekt. Die Weiterleitungsregel kann entweder im Hostprojekt oder in einem Dienstprojekt definiert werden. Der Zielproxy und die URL-Zuordnung müssen im selben Projekt wie die Weiterleitungsregel definiert werden.

Back-End-Dienste und Back-Ends können in beliebig vielen Dienstprojekten erstellt werden. Eine einzelne URL-Zuordnung kann auf Back-End-Dienste in verschiedenen Projekten verweisen. Diese Art der Bereitstellung wird als projektübergreifende Dienstreferenz bezeichnet. Dieser Anwendungsfall befindet sich in der Vorschauphase.

Sie können auch alle Load-Balancer-Komponenten und deren Back-Ends in einem einzelnen Dienstprojekt erstellen.

Jeder Back-End-Dienst muss im selben Projekt wie die Back-End-Instanzen definiert werden, auf die er verweist. Diese Instanzen müssen sich in Instanzgruppen befinden, die als Back-Ends an den Back-End-Dienst angehängt wurden. Mit den Back-End-Diensten verknüpfte Systemdiagnosen müssen auch im selben Projekt wie der Back-End-Dienst definiert werden.

Sie erstellen das erforderliche Netzwerk, die Subnetze und IP-Adressen im Hostprojekt. Für die Load-Balancer-Komponenten können Sie dann einen der folgenden Schritte ausführen:

In allen diesen Bereitstellungsmodellen können Clients auf den 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.

Projektübergreifender Dienstverweis

In diesem Modell befinden sich das Front-End und die URL-Zuordnung des Load-Balancers in einem Host- oder Dienstprojekt. Die Back-End-Dienste und Back-Ends des Load-Balancers können auf Projekte in der freigegebenen VPC-Umgebung verteilt werden. Auf projektübergreifende Back-End-Dienste kann in einer einzelnen URL-Zuordnung verwiesen werden. Dies wird als projektübergreifender Dienstverweis bezeichnet.

Der projektübergreifende Dienstverweis bietet Dienstentwicklern und Administratoren Autonomie über die Bereitstellung ihrer Dienste über den zentral verwalteten Load-Balancer. Dienstprojektadministratoren verwenden die IAM-Rolle compute.loadBalancerServiceUser, um Zugriff auf Back-End-Dienste in ihren Projekten zu gewähren.

Informationen zum Konfigurieren der freigegebenen VPC für einen internen HTTP(S)-Load-Balancer (mit und ohne projektübergreifendem Dienstverweis) finden Sie unter Internen HTTP(S)-Load-Balancer mit freigegebener VPC einrichten.

Projektübergreifender Dienst, der auf Beispiel 1 verweist: Front-End und Back-End des Load-Balancers in verschiedenen Dienstprojekten

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

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

Front-End und URL-Zuordnung des Load-Balancers im Dienstprojekt
Front-End und Back-End des Load-Balancers in verschiedenen Dienstprojekten

Projektübergreifender Dienst, der auf Beispiel 2 verweist: Front-End des Load-Balancers im Hostprojekt; Back-Ends in Dienstprojekten

Bei dieser Art der Bereitstellung werden das Front-End und die URL-Zuordnung des Load-Balancers im Hostprojekt und die Back-End-Dienste (und Back-Ends) in Dienstprojekten erstellt.

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

Front-End und URL-Zuordnung des Load-Balancers im Hostprojekt
Front-End und URL-Zuordnung des Load-Balancers im Hostprojekt

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

In diesem Modell befinden sich alle Load-Balancer-Komponenten und Back-Ends in einem Dienstprojekt. Dieses Bereitstellungsmodell wird von allen HTTP(S)-Load-Balancern unterstützt.

Der Load-Balancer verwendet IP-Adressen und Subnetze aus dem Hostprojekt.

Interner HTTP(S)-Load-Balancer in einem freigegebenen VPC-Netzwerk
Interner HTTP(S)-Load-Balancer in einem freigegebenen VPC-Netzwerk

Load-Balancer und Back-Ends in einem Hostprojekt

In diesem Modell befinden sich das freigegebene VPC-Netzwerk, die Load-Balancer-Komponenten und die Back-Ends im Hostprojekt. Dieses Modell trennt nicht die Zuständigkeiten für Netzwerkverwaltung und Dienstentwicklung.

Die Konfiguration für dieses Modell entspricht der Konfiguration des Load-Balancers in einem eigenständigen VPC-Netzwerk.

Zeitüberschreitungen und Wiederholungsversuche

Internes HTTP(S)-Load-Balancing hat drei verschiedene Zeitlimittypen:
  • Ein konfigurierbares HTTP-Zeitlimit des Back-End-Diensts, das sich danach richtet, wie lange der Load-Balancer auf eine vollständige HTTP-Antwort vom Back-End wartet. Der Standardwert für das Zeitlimit des Back-End-Diensts beträgt 30 Sekunden. Zulässig sind Zeitlimitwerte im Bereich von 1 bis 2.147.483.647 Sekunden.

    Wenn das Zeitlimit für den Back-End-Dienst beispielsweise auf den Standardwert von 30 Sekunden festgelegt ist, haben die Back-Ends 30 Sekunden Zeit, um auf Anfragen zu antworten. Der Load-Balancer wiederholt die HTTP-GET-Anfrage einmal, wenn das Back-End die Verbindung trennt oder das Zeitlimit überschritten wird, bevor Antwortheader an den Load-Balancer gesendet werden. Wenn das Back-End Antwortheader sendet oder die an das Back-End gesendete Anfrage keine HTTP-GET-Anfrage ist, wiederholt der Load-Balancer die Anfrage nicht. Wenn das Back-End überhaupt nicht antwortet, gibt der Load-Balancer eine HTTP 5xx-Antwort an den Client zurück. Ändern Sie für diese Load-Balancer den Zeitlimitwert, wenn Sie mehr oder weniger Zeit für die Beantwortung der Anfragen durch die Back-Ends einplanen möchten.

    Das Zeitlimit für den Back-End-Dienst sollte auf die maximal mögliche Zeit vom ersten Byte der Anfrage bis zum letzten Byte der Antwort für die Interaktion zwischen Envoy und Ihrem Back-End festgelegt werden. Wenn Sie WebSockets verwenden, sollte das Zeitlimit des Back-End-Dienstes auf die maximale Dauer eines WebSockets, inaktiv oder aktiv, festgelegt werden.

    Unter diesen Umständen sollten Sie dieses Zeitlimit eventuell erhöhen:

    • Sie erwarten, dass HTTP-Antworten von einem Back-End länger dauern.
    • Die Verbindung wurde zu einem WebSocket hochgestuft.

    Das von Ihnen festgelegte Zeitlimit für den Back-End-Dienst ist ein Best-Effort-Ziel. Dabei ist nicht garantiert, dass die zugrunde liegenden TCP-Verbindungen für die Dauer dieses Zeitlimits geöffnet bleiben.

    Sie können das Zeitlimit für den Back-End-Dienst auf einen beliebigen Wert festlegen. Wenn Sie ihn jedoch auf einen Wert über einen Tag hinaus (86.400 Sekunden) festlegen, bedeutet dies nicht, dass der Load-Balancer so lange eine TCP-Verbindung beibehält. Es kann sein, muss aber nicht. Google startet Envoy-Proxys regelmäßig für Softwareupdates und routinemäßige Wartungen neu. Dies wird durch das Zeitlimit des Back-End-Dienstes nicht überschrieben. Je länger Sie das Zeitlimit des Back-End-Diensts festlegen, desto wahrscheinlicher ist es, dass Google eine TCP-Verbindung für die Envoy-Wartung beendet. Wir empfehlen Ihnen, eine Wiederholungslogik zu implementieren, um die Auswirkungen solcher Ereignisse zu reduzieren.

    Weitere Informationen finden Sie unter Einstellungen für Back-End-Dienste.

    Das Zeitlimit des Back-End-Diensts ist keine HTTP-Leerlaufzeitüberschreitung (Keepalive-Zeitüberschreitung). Es kann vorkommen, dass die Ein- und Ausgabe (IO) des Back-Ends aufgrund eines langsamen Clients, z. B. ein Browser mit langsamer Verbindung, blockiert wird. Diese Wartezeit wird nicht auf das Zeitlimit des Back-End-Diensts angerechnet.

  • Ein HTTP-Keepalive-Zeitlimit, dessen Wert unveränderlich bei 10 Minuten (600 Sekunden) liegt. Dieser Wert kann nicht konfiguriert werden, indem Ihr Back-End-Dienst geändert wird. Sie müssen die von den Back-Ends verwendete Webserversoftware so konfigurieren, dass die darin angegebene Keepalive-Zeitüberschreitung länger als 600 Sekunden ist, damit Verbindungen nicht vorzeitig vom Back-End geschlossen werden. Dieses Zeitlimit gilt nicht für WebSockets. In dieser Tabelle werden die Änderungen veranschaulicht, die erforderlich sind, um Keepalive-Zeitüberschreitungen für häufig verwendete Webserversoftware zu ändern:
    Webserversoftware Parameter Standardeinstellung Empfohlene Einstellung
    Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
    nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;
  • Eine Zeitüberschreitung bei inaktivem Stream, deren Wert unveränderlich bei 5 Minuten (300 Sekunden) liegt. Dieser Wert ist nicht konfigurierbar. HTTP-Streams werden nach 5 Minuten ohne Aktivität inaktiv.

Neuversuche

Wiederholungsversuche können mithilfe einer Wiederholungsrichtlinie in der URL-Zuordnung konfiguriert werden. Die Standardanzahl an Wiederholungen (numRetries) ist 1. Das Standardzeitlimit für jeden Versuch (perTryTimeout) beträgt 30 Sekunden mit einem maximal konfigurierbaren perTryTimeout von 24 Stunden.

Ohne eine Wiederholungsrichtlinie werden fehlgeschlagene Anfragen ohne HTTP-Text (z. B. GET-Anfragen), die zu HTTP-502-, 503- oder 504-Antworten führen, einmal wiederholt. HTTP-POST-Anfragen werden nicht wiederholt. Dieses Standardverhalten entspricht dem Zeitpunkt retryConditions=["gateway-error"].

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 HTTP(S)-Load-Balancing.

Auf verbundene Netzwerke zugreifen

Zugriff auf einen internen HTTP(S)-Load-Balancer in Ihrem VPC-Netzwerk erhalten Sie über ein verbundenes Netzwerk mithilfe von:

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

Ausführliche Beispiele finden Sie unter Internes HTTP(S)-Load-Balancing und verbundene Netzwerke.

Failover

Wenn ein Back-End fehlerhaft wird, wird der Traffic automatisch zu fehlerfreien Back-Ends in derselben Region weitergeleitet. Wenn alle Back-Ends fehlerhaft sind, gibt der Load-Balancer die Antwort HTTP 503 Service Unavailable zurück.

WebSocket-Unterstützung

HTTP(S)-basierte Load-Balancer von Google Cloud bieten native Unterstützung für das WebSocket-Protokoll, wenn Sie HTTP oder HTTPS als Protokoll für das Back-End 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 Servern. Durch eine HTTP(S)-Anfrage wird der Kanal initiiert. Ausführliche Informationen zum Protokoll finden Sie unter RFC 6455.

Wenn der Load-Balancer eine WebSocket-Upgrade-Anfrage von einem HTTP(S)-Client gefolgt von einer erfolgreichen Upgrade-Antwort der Back-End-Instanz erkennt, leitet er bidirektionalen Traffic für die Dauer der aktuellen Verbindung über einen Proxy weiter. Wenn die Back-End-Instanz keine erfolgreiche Upgrade-Antwort zurückgibt, schließt der Load-Balancer die Verbindung.

Die Zeitüberschreitung für eine WebSocket-Verbindung hängt vom konfigurierbaren Back-End-Dienst-Zeitlimit des Load-Balancers ab, das standardmäßig 30 Sekunden beträgt. Diese Zeitüberschreitung wird auf WebSocket-Verbindungen unabhängig davon angewendet, ob sie gerade verwendet werden.

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 Back-End-Instanzen konfiguriert ist. Diese HTTP- oder HTTPS-Anfragen werden vom Lastenausgleichsmodul transformiert, um die Anfragen über HTTP/2 an die Back-End-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 interne HTTP(S)-Load-Balancer HTTPS als Back-End-Dienstprotokoll verwendet, kann er TLS 1.0, 1.1, 1.2 oder 1.3 an das Back-End aushandeln.

Beschränkungen

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

  • Das interne HTTP(S)-Load-Balancing ist nicht mit den folgenden Features kompatibel:

  • Ein interner HTTP(S)-Load-Balancer unterstützt HTTP/2 nur über TLS.

  • Clients, die eine Verbindung zu einem internen HTTP(S)-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 HTTP(S)-Load-Balancer verwendet, muss genau einen Port haben.

  • Das interne HTTP(S)-Load-Balancing unterstützt Cloud Trace nicht.

  • Wenn Sie das interne HTTP(S)-Load-Balancing mit Cloud Run in einer freigegebenen VPC-Umgebung verwenden, können eigenständige VPC-Netzwerke in Dienstprojekten Traffic an andere Cloud Run-Dienste senden, die in anderen Dienstprojekten in derselben freigegebenen VPC-Umgebung bereitgestellt werden. Dies ist ein bekanntes Problem. Diese Form des Zugriffs wird in Zukunft blockiert.

Nächste Schritte