Internes regionales TCP-Proxy-Load-Balancing – Übersicht

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Der interne TCP-Proxy-Load-Balancer von Google Cloud ist ein Proxy-basierter regionaler Load-Balancer, der von Open-Source-Envoy-Proxy-Software und dem Netzwerkvirtualisierungs-Stack von Andromeda bereitgestellt wird.

Dieser Load-Balancer stellt eine einzelne regionale interne IPv4-Adresse zum Hosten Ihrer TCP-Dienste bereit. Ein interner regionaler TCP-Proxy-Load-Balancer beendet zuerst die TCP-Verbindung zwischen dem Client und dem Load-Balancer in einem Envoy-Proxy. Der Proxy öffnet eine zweite TCP-Verbindung zu Back-Ends, die in Google Cloud, lokal oder in anderen Cloud-Umgebungen gehostet werden.

Der interne regionale TCP-Proxy-Load-Balancer verwendet die Netzwerkdienststufe "Premium".

Vorteile

Der interne regionale TCP-Proxy-Load-Balancer unterstützt Folgendes:

  • Load-Balancing für Back-Ends in Google Cloud, lokal oder in anderen Cloud-Umgebungen. Dies ist besonders nützlich, wenn es mit Private Service Connect verwendet wird, um Erstellerdienste aus lokalen Arbeitslasten für Nutzer in Google Cloud verfügbar zu machen.
  • Intelligentes Routing Der Load-Balancer leitet Anfragen basierend auf konfigurierbaren Zielkapazitäten an Back-Ends innerhalb einer Region weiter.
  • Neuzuordnung des Ports. Der von der Weiterleitungsregel des Load-Balancers verwendete Port muss nicht mit dem Port übereinstimmen, der beim Herstellen von Verbindungen zu seinen Back-Ends verwendet wird. Beispielsweise kann die Weiterleitungsregel den TCP-Port 80 verwenden, während die Verbindung zu den Back-Ends den TCP-Port 8080 verwendet.
  • Überwachung aller Ports Sie können die Weiterleitungsregel des Load-Balancers so konfigurieren, dass er einen beliebigen Port überwacht.
  • Lokalitätsrichtlinien. Innerhalb einer Back-End-Instanzgruppe oder Netzwerk-Endpunktgruppe können Sie konfigurieren, wie Anfragen an Mitgliedsinstanzen oder -Endpunkte verteilt werden.
  • Globaler Zugriff. Wenn der globale Zugriff aktiviert ist, können Clients aus beliebigen Regionen auf den Load-Balancer und seine Back-Ends zugreifen.

Architektur

Das folgende Diagramm zeigt die Google Cloud-Ressourcen, die für einen internen regionalen TCP-Proxy-Load-Balancer erforderlich sind.

Komponenten des internen regionalen TCP-Proxys (zum Vergrößern klicken)
Komponenten des internen regionalen TCP-Proxys (zum Vergrößern klicken)

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 ein Nur-Proxy-Subnetz in jeder Region eines VPC-Netzwerks erstellen, in der Sie einen Envoy-basierten Load-Balancer verwenden (z. B. der interne regionale TCP-Proxy-Load-Balancer, der interne HTTP(S)-Load-Balancer usw.). Alle Envoy-basierten Load-Balancer in einer Region und einem VPC-Netzwerk verwenden dasselbe Nur-Proxy-Subnetz. Der Zweck des Nur-Proxy-Subnetzes muss auf REGIONAL_MANAGED_PROXY festgelegt sein. Weiter:

  • Nur-Proxy-Subnetze werden nur für Envoy-Proxys und nicht für Ihre Back-Ends verwendet.
  • Back-End-VMs oder Endpunkte aller Envoy-basierten Load-Balancer in einer Region und einem VPC-Netzwerk empfangen Verbindungen von demselben Nur-Proxy-Subnetz.
  • Die IP-Adresse des 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.

Weiterleitungsregeln und IP-Adressen

Regionale 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 Back-End-Dienst besteht.

Eine regionale, intern verwaltete Weiterleitungsregel gibt eine interne IP-Adresse, einen Port und einen regionalen TCP-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. 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.
  • Wenn Sie eine interne IP-Adresse für mehrere Weiterleitungsregeln freigeben möchten, setzen Sie das Flag --purpose auf SHARED_LOADBALANCER_VIP.

Intern verwaltete Weiterleitungsregeln unterstützen alle möglichen Ports, aber jede Weiterleitungsregel kann auf genau einen Port verweisen.

Weiterleitungsregeln und globaler Zugriff

Die Weiterleitungsregeln eines internen regionalen TCP-Proxy-Load-Balancers sind regional, auch wenn der globale Zugriff aktiviert ist. Nachdem Sie den globalen Zugriff aktiviert haben, wird das Flag allowGlobalAccess der regionalen internen Weiterleitungsregel auf true gesetzt.

Zielproxys

Der interne regionale TCP-Proxy-Load-Balancer beendet TCP-Verbindungen vom Client und erstellt neue Verbindungen zu den Back-Ends. Standardmäßig bleiben die ursprüngliche IP-Adresse des Clients und die Portinformationen nicht erhalten. Sie können diese Informationen jedoch mithilfe des Proxy-Protokolls aufbewahren. Der Zielproxy leitet eingehende Anfragen direkt an den Back-End-Dienst des Load-Balancers weiter.

Back-End-Dienst

Ein Back-End-Dienst leitet eingehenden Traffic an ein oder mehrere verknüpfte Back-Ends weiter. Ein Back-End ist entweder eine Instanzgruppe oder eine Netzwerk-Endpunktgruppe. Das Back-End enthält Informationen zum Balancing-Modus, um die Vollständigkeit basierend auf Verbindungen zu definieren (oder, nur bei Instanzgruppen-Back-Ends, basierend auf der Auslastung).

Jeder interne regionale TCP-Proxy-Load-Balancer hat eine einzelne Back-End-Dienstressource.

Unterstützte Back-Ends

Der Back-End-Dienst unterstützt die folgenden Arten von Back-Ends:

  • Alle Instanzgruppen-Back-Ends: Instanzgruppen können zonal nicht verwaltet, zonal verwaltet oder regional verwaltet sein.
  • Alle Back-Ends der Netzwerk-Endpunktgruppe: zonale NEGs mit GCE_VM_IP_PORT-Endpunkten und Hybridkonnektivitäts-NEGs mit NON_GCP_PRIVATE_IP_PORT-Endpunkten werden unterstützt.

Alle Back-Ends müssen vom selben Typ sein (Instanzgruppen oder NEGs). Sie können verschiedene Typen von Instanzgruppen-Back-Ends gleichzeitig verwenden. Sie können auch verschiedene Arten von NEG-Back-Ends gleichzeitig verwenden. Sie können jedoch Instanzgruppen- und NEG-Back-Ends nicht zusammen auf demselben Back-End-Dienst verwenden.

Sie können zonale und hybride NEGs innerhalb desselben Back-End-Dienstes kombinieren.

Sie vermeiden Unterbrechungen für Ihre Nutzer weitgehend, wenn Sie den Verbindungsausgleich bei Back-End-Diensten aktivieren. Unterbrechungen dieser Art können auftreten, wenn ein Back-End beendet, manuell entfernt oder durch Autoscaling entfernt wird. Weitere Informationen zum Vermeiden von Dienstunterbrechungen mithilfe des Verbindungsausgleichs finden Sie unter Verbindungsausgleich aktivieren.

Protokoll für die Kommunikation mit den Back-Ends

Wenn Sie einen Back-End-Dienst für einen internen TCP-Proxy-Load-Balancer konfigurieren, legen Sie das Protokoll fest, über das der Back-End-Dienst mit den Back-Ends kommuniziert. Der Load-Balancer verwendet nur das angegebene Protokoll und versucht nicht, eine Verbindung mit dem anderen Protokoll auszuhandeln. Der interne regionale TCP-Proxy-Load-Balancer unterstützt nur TCP für die Kommunikation mit den Back-Ends.

Systemdiagnose

Jeder Back-End-Dienst gibt eine Systemdiagnose an, die regelmäßig die Bereitschaft der Back-Ends ü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.

Firewallregeln

Ein interner regionaler TCP-Proxy-Load-Balancer erfordert die folgenden Firewallregeln:

  • Eine Regel zum Zulassen von eingehendem Traffic, um Traffic von den Systemdiagnoseprüfungen von Google zuzulassen.
    • 35.191.0.0/16
    • 130.211.0.0/22
    Derzeit gehen Systemdiagnoseprüfungen für Hybrid-NEGs vom zentralisierten Mechanismus von Google für Systemdiagnosen aus. Wenn Sie Traffic aus den Google-Systemdiagnosebereichen nicht erlauben können, Ihre Hybridendpunkte zu erreichen, und wenn die Systemdiagnoseprüfungen stattdessen von privaten IP-Adressen ausgehen sollen, wenden Sie sich an Ihren Google-Kundenbetreuer, damit er das Projekt für verteilte Envoy-Systemdiagnosen auf die Zulassungsliste setzt.
  • Eine Regel zum Zulassen von eingehendem Traffic, um Traffic vom Nur-Proxy-Subnetz zuzulassen.

Die Ports für diese Firewallregeln müssen so konfiguriert werden:

  • Lassen Sie Traffic zum Zielport für die Systemdiagnose der einzelnen Back-End-Dienste zu.

  • Instanzgruppen-Back-Ends: Bestimmen Sie die Ports, die durch die Zuordnung zwischen dem benannten Port des Back-End-Dienstes und den mit diesem benannten Port verknüpften Portnummern in jeder Instanzgruppe konfiguriert werden sollen. Die Portnummern können je nach Instanzgruppe, die demselben Back-End-Dienst zugewiesen ist, variieren.

  • GCE_VM_IP_PORT-NEG-Back-Ends: Lassen Sie Traffic zu den Portnummern der Endpunkte zu.

Clientzugriff

Standardmäßig müssen sich Clients in derselben Region wie der Load-Balancer befinden. Clients können sich im selben Netzwerk oder in einem VPC-Netzwerk befinden, das über VPC-Netzwerk-Peering verbunden ist. Sie können den globalen Zugriff aktivieren, damit Clients aus beliebigen Regionen auf Ihren Load-Balancer zugreifen können.

Interner regionaler TCP-Proxy-Load-Balancer mit globalem Zugriff (zum Vergrößern klicken)
Interner regionaler TCP-Proxy-Load-Balancer mit globalem Zugriff (zum Vergrößern klicken)

In der folgenden Tabelle wird der Clientzugriff 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.

Architektur einer freigegebenen VPC

Der interne regionale TCP-Proxy-Load-Balancer 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 und die Netzwerkinfrastrukturteams das Load-Balancing bereitstellen und verwalten. Wenn Sie noch nicht mit freigegebenen VPCs vertraut sind, lesen Sie die Dokumentation Freigegebene VPC – Übersicht.

IP-Adresse Weiterleitungsregel Zielproxy Back-End-Komponenten

Eine interne IP-Adresse muss im selben Projekt wie die Back-Ends definiert werden.

Damit der Load-Balancer in einem freigegebenen VPC-Netzwerk verfügbar ist, muss die interne IP-Adresse von Google Cloud im selben Dienstprojekt definiert werden, in dem sich die Back-End-VMs befinden. Außerdem muss sie auf ein Subnetz im gewünschten freigegebenen VPC-Netzwerk im Hostprojekt verweisen. Die Adresse selbst stammt aus dem primären IP-Bereich des Subnetzes, auf das verwiesen wurde.

Eine interne Weiterleitungsregel muss im selben Projekt wie die Back-Ends definiert werden.

Damit der Load-Balancer in einem freigegebenen VPC-Netzwerk verfügbar ist, muss die interne Weiterleitungsregel im selben Dienstprojekt definiert werden, in dem sich die Back-End-VMs befinden. Außerdem muss sie auf dasselbe Subnetz (im freigegebenen VPC-Netzwerk) verweisen, auf das die verknüpfte interne IP-Adresse verweist.

Der Zielproxy muss im selben Projekt wie die Back-Ends definiert werden. Im Szenario eines freigegebenen VPC-Netzwerks befinden sich die Back-End-VMs normalerweise in einem Dienstprojekt. Dort müssen auch der regionale interne Back-End-Dienst und die Systemdiagnose definiert werden.

Traffic-Verteilung

Interne regionale TCP-Proxy-Load-Balancer verteilen den Traffic so an ihre Back-Ends:

  1. Verbindungen, die von einem einzelnen Client stammen, werden an dieselbe Zone gesendet, sofern fehlerfreie Back-Ends (Instanzgruppen oder NEGs) innerhalb dieser Zone verfügbar sind und Kapazität haben, wie durch den Balancing-Modus bestimmt. Bei internen regionalen TCP-Proxy-Load-Balancern kann der Balancing-Modus CONNECTION (Instanz- oder NEG-Back-Ends) oder UTILIZATION (nur Instanzgruppen-Back-Ends) sein.
  2. Verbindungen von einem Client werden an dasselbe Back-End gesendet, wenn Sie die Sitzungsaffinität konfiguriert haben.
  3. Nach der Auswahl eines Back-Ends wird der Traffic dann gemäß einer Load-Balancing-Richtlinie auf Instanzen (in einer Instanzgruppe) oder Endpunkte (in einer NEG) verteilt. Informationen zu den unterstützten Load-Balancing-Richtlinienalgorithmen finden Sie in der Einstellung localityLbPolicy in der API-Dokumentation für regionale Back-End-Dienste.

Sitzungsaffinität

Mit der Sitzungsaffinität können Sie den Back-End-Dienst des Load-Balancers so konfigurieren, dass alle Anfragen vom selben Client an dasselbe Back-End gesendet werden, sofern das Back-End fehlerfrei ist und Kapazität hat.

Der interne regionale TCP-Proxy-Load-Balancer bietet die Client-IP-Affinität, mit der alle Anfragen von derselben Client-IP-Adresse an dasselbe Back-End weitergeleitet werden, sofern dieses Back-End Kapazität hat und fehlerfrei ist.

Failover

Wenn ein Back-End fehlerhaft wird, wird der Traffic automatisch zu fehlerfreien Back-Ends in derselben Region weitergeleitet. Der Load-Balancer implementiert einen reibungslosen Failover-Algorithmus pro Zone. Anstatt zu warten, bis alle Back-Ends in einer Zone fehlerhaft werden, leitet der Load-Balancer den Traffic an eine andere Zone weiter, wenn das Verhältnis von fehlerfreien zu fehlerhaften Back-Ends in einer Zone unter einen bestimmten Prozentsatz fällt (70%, dieser Schwellenwert ist nicht konfigurierbar). Wenn alle Back-Ends in allen Zonen fehlerhaft sind, beendet der Load-Balancer die Clientverbindung sofort.

Load-Balancing für GKE-Anwendungen

Wenn Sie Anwendungen in Google Kubernetes Engine erstellen, können Sie eigenständige zonale NEGs verwenden, um den Traffic direkt auf Container zu verteilen. Bei eigenständigen NEGs müssen Sie das Service-Objekt erstellen, das die zonale NEG erstellt, und dann die NEG mit dem Back-End-Dienst verknüpfen, damit der Load-Balancer eine Verbindung zu den Pods herstellen kann.

Zugehörige GKE-Dokumentation:

Kontingente und Limits

Informationen zu Kontingenten und Limits finden Sie unter Kontingente für Load-Balancing-Ressourcen.

Beschränkungen

  • Der interne regionale TCP-Proxy-Load-Balancer unterstützt keinen IPv6-Traffic.
  • Der interne regionale TCP-Proxy-Load-Balancer unterstützt keine freigegebenen VPC-Bereitstellungen, bei denen sich das Front-End des Load-Balancers in einem Host- oder Dienstprojekt befindet und der Back-End-Dienst und die Back-Ends in einem anderen Dienstprojekt sind (auch als projektübergreifende Dienstverweise bezeichnet).

Nächste Schritte