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 auf Compute Engine und Google Kubernetes Engine (GKE) 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) 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 basierendem Load-Balancing (zum Vergrößern klicken)
Interne Dienste mit auf Layer 7 basierendem Load-Balancing (zum Vergrößern klicken)

Für die Bereitstellung des Load-Balancing-Dienstes werden zwei zusätzliche Komponenten verwendet:

  • Eine URL-Zuordnung, mit der die Trafficsteuerungsregeln definiert werden, die auf Layer-7-Parametern wie HTTP-Headern basieren und bestimmten Back-End-Diensten zugeordnet sind. Der Load-Balancer wertet eingehende Anfragen anhand der URL-Zuordnung aus, um Traffic an Back-End-Dienste weiterzuleiten oder zusätzliche Aktionen auszuführen (z. B. Weiterleitungen).
  • Systemdiagnosen, die regelmäßig den Status der Back-Ends prüfen und durch die sich das Risiko verringert, dass Clienttraffic an ein nicht antwortendes Back-End gesendet wird.

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.

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 basierendem 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.

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 basierendes Routing für interne Ebenen in einer mehrstufigen Anwendung (zum Vergrößern klicken)
Auf Layer 7 basierendes Routing für interne Ebenen in einer mehrstufigen Anwendung

Zugriffsbeispiele

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.

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

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.

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

  • 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).

    Die mit der Weiterleitungsregel verknüpfte interne IP-Adresse 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 INTERNAL_HTTPS_LOAD_BALANCER gesetzt ist.
  • 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 prüft keine IP-Adressen, die sich vor den letzten beiden IP-Adressen in diesem Header befinden.

    Wenn Sie als Back-End-Server einen Proxy ausführen, hängt dieser Proxy in der Regel weitere Informationen an den X-Forwarded-For-Header an. Ihre Software muss dies möglicherweise berücksichtigen. 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.

  • Der HTTP(S)-Proxy verwendet eine regionale URL-Zuordnung, um anhand von HTTP-Attributen (z. B. Anfragepfad, Cookies oder Header) eine Routingentscheidung zu treffen. Auf Grundlage 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.

  • Ein regionaler Back-End-Dienst verteilt Anfragen an fehlerfreie Back-Ends (entweder Instanzgruppen mit Compute Engine-VMs oder NEGs mit GKE-Containern).

  • Mindestens ein Back-End muss mit dem Back-End-Dienst verbunden sein. 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 (zonal)

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

  • 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.

SSL-Zertifikate

Wenn Sie das HTTPS-basierte Load-Balancing verwenden, müssen Sie ein oder mehrere SSL-Zertifikate auf dem HTTPS-Ziel-Proxy installieren.

Diese Zertifikate werden von HTTPS-Ziel-Proxys verwendet, um die Kommunikation zwischen dem Load-Balancer und dem Client zu sichern.

Informationen zur Anzahl und zu den Kontingenten von SSL-Zertifikaten finden Sie auf der Seite mit den Load-Balancing-Kontingenten unter SSL-Zertifikate.

Um optimale Sicherheit zu erhalten, verwenden Sie bei der Bereitstellung des HTTPS-Load-Balancers eine Ende-zu-Ende-Verschlüsselung. Weitere Informationen finden Sie unter Verschlüsselung vom Load-Balancer zu Back-Ends.

Allgemeine Informationen darüber, wie Google Nutzertraffic verschlüsselt, finden Sie im Whitepaper Verschlüsselung bei der Übertragung in Google Cloud.

Firewallregeln

Der interne HTTP(S)-Load-Balancer erfordert die folgenden Firewallregeln:

Zeitlimits und Wiederholungsversuche

Das Zeitlimit für den Back-End-Dienst ist ein Anfrage/Antwort-Zeitlimit für HTTP(S)-Traffic. Das Zeitlimit definiert, wie lange der Load-Balancer wartet, bis ein Back-End eine vollständige Antwort auf eine Anfrage zurückgibt.

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.

Internes HTTP(S)-Load-Balancing hat zwei verschiedene Zeitlimittypen:
  • Eine konfigurierbares HTTP-Zeitlimit des Back-End-Dienstes, 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. Unter diesen Umständen sollten Sie dieses Zeitlimit eventuell erhöhen:

    • Sie erwarten, dass HTTP-Antworten von einem Back-End länger dauern.
    • Sie sehen eine HTTP-408-Antwort mit jsonPayload.statusDetail client_timed_out.
    • Die Verbindung wurde zu einem WebSocket hochgestuft

    Beim Senden von WebSocket-Traffic über den Load-Balancer wird das Zeitlimit für den Back-End-Dienst als die maximale Zeit verstanden, die eine WebSocket-Verbindung geöffnet sein kann – im Leerlauf oder aktiv. Weitere Informationen finden Sie unter Einstellungen für Back-End-Dienste.

  • Eine TCP-Sitzungszeitüberschreitung, deren Wert unveränderlich bei 10 Minuten (600 Sekunden) liegt. Diese Sitzungszeitüberschreitung wird manchmal als Keepalive- oder Leerlaufzeitüberschreitung bezeichnet. Ihr Wert kann nicht über eine Änderung im Back-End-Dienst konfiguriert werden. 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 dargestellt, die erforderlich sind, um Keepalive-Zeitlimits bei häufig verwendeter Webserversoftware zu ändern:

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

Der Load-Balancer wiederholt fehlerhafte GET-Anfragen unter bestimmten Umständen, etwa wenn das Zeitlimit des Back-End-Diensts abgelaufen ist. Fehlerhafte POST-Anfragen werden nicht wiederholt. Es gibt maximal zwei Wiederholungsversuche. Bei wiederholten Anfragen wird nur ein Logeintrag für die endgültige Antwort generiert.

Weitere Informationen finden Sie unter Logging und Monitoring für HTTP(S)-Load-Balancing.

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. Weitere Informationen zum Zeitlimit des Back-End-Diensts und zu dessen Konfiguration finden Sie unter Zeitüberschreitungen und Wiederholungsversuche.

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

Traffictypen, -schema und -bereich

Back-End-Dienste unterstützen die HTTP-, HTTPS- oder HTTP/2-Protokolle. 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.

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.

Architekturen freigegebener VPCs

Das interne HTTP(S)-Load-Balancing unterstützt Netzwerke, die eine freigegebene VPC verwenden. Wenn Sie noch nicht mit freigegebenen VPCs vertraut sind, lesen Sie die Dokumentation Freigegebene VPC – Übersicht. Auf oberster Ebene:

  • Sie legen ein Hostprojekt fest und hängen ein oder mehrere Dienstprojekte an.
  • Der Hostprojektadministrator erstellt ein oder mehrere freigegebene VPC-Netzwerke und Subnetze und gibt diese für Dienstprojekte frei.
  • Zulässige Ressourcen aus Dienstprojekten können Subnetze im freigegebenen VPC-Netzwerk verwenden.

Im Kontext des internen HTTP(S)-Load-Balancings gibt es zwei Möglichkeiten, das Load-Balancing in einem freigegebenen VPC-Netzwerk zu konfigurieren. Sie können den Load-Balancer und seine Back-End-Instanzen entweder im Dienstprojekt oder im Hostprojekt erstellen.

Load-Balancer und Back-Ends in einem Dienstprojekt

In diesem Modell stellen Sie den Load-Balancer und die Back-End-Instanzen in einem Dienstprojekt bereit. Anschließend konfigurieren Sie den Load-Balancer und die Back-End-Instanzen für die Verwendung des freigegebenen VPC-Netzwerks.

Dieses Bereitstellungsmodell entspricht dem typischen Anwendungsfall für das Bereitstellungsmodell des freigegebenen VPC-Netzwerks: Aufgabenteilung zwischen Netzwerkverwaltung und Dienstentwicklung. Es ermöglicht Netzwerkadministratoren eine sichere und effiziente Zuweisung interner IP-Bereiche und sorgt für eine klare Trennung der Zuständigkeiten zwischen Netzwerkadministratoren und Dienstentwicklern.

Internes HTTP(S)-Load-Balancing in einem freigegebenen VPC-Netzwerk
Internes HTTP(S)-Load-Balancing in einem freigegebenen VPC-Netzwerk

Hostprojekt

Der Administrator des Hostprojekts tut Folgendes:

  • Er richtet das freigegebene VPC-Netzwerk im Hostprojekt ein.
  • Er stellt Subnetze aus dem freigegebenen VPC-Netzwerk bereit.
  • Er konfiguriert Firewallregeln im freigegebenen VPC-Netzwerk.

Dienstprojekt

  • Der Dienstprojektadministrator erstellt den Load-Balancer (Weiterleitungsregel, HTTP(S)-Ziel-Proxy, URL-Zuordnung, Back-End-Dienst(e)) und Back-End-Instanzen im Dienstprojekt.
  • Diese Load-Balancing-Ressourcen und Back-End-Instanzen verweisen auf das freigegebene Netzwerk und die Subnetze aus dem freigegebenen VPC-Hostprojekt.

Mit diesem Muster können Dienstentwickler Dienste mit Load-Balancing in ihren eigenen Dienstprojekten erstellen. Das Dienstentwicklungsteam kann auch die Konfiguration des Load-Balancers aktualisieren und Änderungen an Back-End-Instanzen vornehmen, ohne die Administratoren des Hostprojekts einzubeziehen.

Wenn sich Clients im selben freigegebenen VPC-Netzwerk wie der Load-Balancer befinden, können sie sich entweder im Hostprojekt oder in einem Dienstprojekt befinden. Solche Clients können über die private IP-Adresse des Load-Balancers auf Dienste mit Load-Balancing zugreifen.

Informationen zum Konfigurieren eines internen HTTP(S)-Load-Balancers für ein freigegebenes VPC-Netzwerk finden Sie unter Internes HTTP(S)-Load-Balancing mit freigegebener VPC einrichten.

Load-Balancer und Back-Ends in einem Hostprojekt

Bei diesem Netzwerkbereitstellungsmodell befinden sich das Netzwerk, der Load-Balancer und die Back-Ends im Hostprojekt. Diese Einrichtung funktioniert zwar, eignet sich jedoch nicht für typische freigegebene VPC-Bereitstellungen, da sie die Zuständigkeiten für Netzwerkverwaltung und Dienstentwicklung nicht trennt.

Wenn Sie trotzdem einen Load-Balancer und dessen Back-Ends im Hostprojekt ausführen müssen, führen Sie die Schritte unter Internes HTTP(S)-Load-Balancing einrichten aus.

Beschränkungen

  • Das interne HTTP(S)-Load-Balancing funktioniert auf regionaler Ebene.

  • 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:

  • Beim Erstellen eines internen HTTP(S)-Load-Balancers in einem Host- oder Dienstprojekt in einer freigegebenen VPC:

    • Alle Load-Balancing-Komponenten und Back-Ends müssen sich im selben Projekt befinden, entweder alle in einem Hostprojekt oder alle in einem Dienstprojekt. Sie können beispielsweise die Weiterleitungsregel des Load-Balancers nicht in einem Projekt bereitstellen und Back-End-Instanzen in einem anderen Projekt erstellen.

    • Clients können sich entweder im Hostprojekt, in angehängten Dienstprojekten oder in verbundenen Netzwerken befinden. Clients müssen dasselbe freigegebene VPC-Netzwerk verwenden und sich in derselben Region wie der Load-Balancer befinden.

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

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

  • In jedem VPC-Netzwerk muss jede intern verwaltete Weiterleitungsregel eine eigene IP-Adresse haben. Weitere Informationen finden Sie unter Mehrere Weiterleitungsregeln mit einer gemeinsamen IP-Adresse.

  • Die interne Weiterleitungsregel, die Ihr interner HTTP(S)-Load-Balancer verwendet, muss genau einen Port haben.

  • Wenn Sie Anfragen über einen intermediäre Router-VM(z. B. eine Routing-Appliance) an einen internen HTTP (S)-Load-Balancer senden, müssen Sie die Routing-Appliance so konfigurieren, dass sie Folgendes tut:

    1. Konfigurieren Sie die Router-VM (die Routing-Appliance), so, dass sie eine Source Network Address Translation, (SNAT) durchführt, bevor Anfragepakete an den internen HTTP(S)-Load-Balancer gesendet werden.
    2. Konfigurieren der Router-VM für die Durchführung der Zielnetzwerkadressübersetzung (Destination Network Address Translation, DNAT), wenn sie Antwortpakete ausliefert, die vom internen HTTP(S)-Load-Balancer gesendet werden.

Nächste Schritte