TCP-Proxy-Load-Balancing – Überblick

TCP-Proxy-Load-Balancing ist ein Reverse-Proxy-Load-Balancer, der TCP-Traffic aus dem Internet auf VM-Instanzen in Ihrem Google Cloud VPC-Netzwerk verteilt. Bei Verwendung des TCP-Proxy-Load-Balancings wird Traffic über eine TCP-Verbindung auf der Load-Balancing-Ebene beendet und dann über TCP oder SSL zum nächstgelegenen verfügbaren Back-End weitergeleitet.

Mit TCP-Proxy-Load-Balancing können Sie eine einzelne IP-Adresse für alle Nutzer auf der ganzen Welt verwenden. Der TCP-Proxy-Load-Balancer leitet den Traffic automatisch an die Back-Ends weiter, die dem Nutzer am nächsten sind.

Auf der Premium-Stufe kann das TCP-Proxy-Load-Balancing als globaler Load-Balancing-Dienst konfiguriert werden. Bei der Standardstufe führt der TCP-Proxy-Load-Balancer das Load-Balancing regional aus. Weitere Informationen finden Sie unter TCP-Proxy-Load-Balancing.

In diesem Beispiel werden die Verbindungen für den Traffic von Nutzern in Seoul und Boston auf der Load-Balancing-Ebene beendet. Diese Verbindungen sind mit 1a und 2a gekennzeichnet. Vom Load-Balancer werden separate Verbindungen zu den ausgewählten Back-End-Instanzen aufgebaut. Diese Verbindungen sind mit 1b und 2b gekennzeichnet.

Cloud Load Balancing mit TCP-Beendigung (zum Vergrößern klicken)

TCP-Proxy-Load-Balancing ist für TCP-Traffic an bestimmten gängigen Ports vorgesehen, z. B. Port 25 für Simple Mail Transfer Protocol (SMTP). Weitere Informationen finden Sie unter Angabe von Ports. Verwenden Sie für Client-Traffic, der an diesen Ports verschlüsselt wird, SSL-Proxy-Load-Balancing.

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

• Load-Balancing
• Load-Balancer auswählen
• Load-Balancer-Features

Vorteile

Zu den Vorteilen des TCP-Proxy-Load-Balancers gehören:

• IPv6-Beendigung. TCP-Proxy-Load-Balancing unterstützt Client-Traffic sowohl von IPv4- als auch von IPv6-Adressen. IPv6-Anfragen von Clients werden auf der Ebene des Load-Balancings beendet und dann über IPv4 an die Back-Ends weitergeleitet.
• Intelligentes Routing Der Load-Balancer kann Anfragen an Back-End-Speicherorte mit freien Kapazitäten weiterleiten. Im Gegensatz dazu muss ein L3/L4-Load-Balancer ohne Berücksichtigung der Kapazitäten eine Weiterleitung zu regionalen Back-Ends vornehmen. Intelligentes Routing ermöglicht die Bereitstellung mit N+1 oder N+2 anstelle von x*N.
• Sicherheitspatches: Wenn im TCP-Paket Sicherheitslücken auftreten, stellt Cloud Load Balancing für den Load-Balancer automatisch Patches bereit, um für die Sicherheit Ihrer Back-Ends zu sorgen.
• Unterstützung für folgende bekannten TCP-Ports. 5, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671, 5672, 5900, 5901, 6379, 8085, 8099, 9092, 9200 und 9300.

Hinweis: Das TCP-Proxy-Load-Balancing unterstützt nicht die TCP-Ports 80 und 8080. Verwenden Sie für HTTP-Traffic externes HTTP(S)-Load-Balancing.

Architektur

Die folgenden Komponenten gehören zu TCP-Proxy-Load-Balancern.

Weiterleitungsregeln und IP-Adressen

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.

Jede Weiterleitungsregel stellt eine einzelne IP-Adresse bereit, die Sie in DNS-Einträgen für Ihre Anwendung verwenden können. Ein Load-Balancing für DNS ist nicht erforderlich. 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.

Externe Weiterleitungsregeln, die in der Definition eines TCP-Proxy-Load-Balancers verwendet werden, können auf genau einen der aufgeführten Ports verweisen, die unter Portspezifikationen für Weiterleitungsregeln aufgeführt sind.

Zielproxys

Durch das TCP-Proxy-Load-Balancing werden TCP-Verbindungen des Clients beendet und neue Verbindungen zu den Back-Ends aufgebaut. 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. Die Zielproxys leiten eingehende Anfragen direkt an Back-End-Dienste weiter.

Back-End-Dienste

Back-End-Dienste leiten eingehenden Traffic an mindestens ein verknüpftes Back-End weiter. Jedes Back-End besteht aus einer Instanzgruppe oder einer Netzwerk-Endpunktgruppe und Informationen zur Bereitstellungskapazität des Back-Ends. Die Bereitstellungskapazität für das Back-End basiert auf der CPU oder auf Anfragen pro Sekunde (Requests Per Second, RPS).

TCP-Proxy-Load-Balancer haben jeweils eine einzelne Back-End-Dienstressource. Änderungen am Back-End-Dienst erfolgen nicht sofort. Es kann einige Minuten dauern, bis Änderungen an Google Front Ends (GFEs) wirksam werden.

Der Back-End-Dienst legt die Systemdiagnosen fest, die für die verfügbaren Back-Ends auszuführen sind.

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.

Back-Ends und VPC-Netzwerke

Alle Back-Ends müssen sich in demselben Projekt befinden, können jedoch in verschiedenen VPC-Netzwerken sein. Die verschiedenen VPC-Netzwerke müssen nicht über VPC-Netzwerk-Peering verbunden sein, da GFE-Proxysysteme direkt mit Back-Ends in ihren jeweiligen VPC-Netzwerken kommunizieren.

Protokoll für die Kommunikation mit den Back-Ends

Wenn Sie einen Back-End-Dienst für den TCP-Proxy-Load-Balancer konfigurieren, legen Sie das Protokoll fest, über das der Back-End-Dienst mit den Back-Ends kommuniziert. Zur Auswahl stehen die Protokolle SSL oder TCP. Der Load-Balancer verwendet nur das angegebene Protokoll und versucht nicht, eine Verbindung mit dem anderen Protokoll auszuhandeln.

Firewallregeln

Für HTTP(S)-Load-Balancing sind die folgenden Firewallregeln erforderlich:

• Für die globalen externen HTTP(S)-Load-Balancer ist eine Regel zum Zulassen von eingehendem Traffic erforderlich, um Traffic von Google Front Ends (GFEs) zu Ihren Back-Ends zuzulassen.
  Regionaler externer HTTP(S)-Load-Balancer: eine Regel zum Zulassen von eingehendem Traffic, um Traffic vom Nur-Proxy-Subnetz zuzulassen.
• Eine Regel zum Zulassen von eingehendem Traffic, um Traffic von den Bereichen der Systemdiagnoseprüfungen zuzulassen. Weitere Informationen zu Systemdiagnoseprüfungen und dazu, warum Traffic von ihnen zugelassen werden muss, finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.

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.

Firewallregeln werden auf VM-Instanzebene und nicht auf GFE-Proxys implementiert. Sie können Google Cloud-Firewallregeln nicht verwenden, um zu verhindern, dass Traffic den Load-Balancer erreicht. Für globale externe HTTP(S)-Load-Balancer können Sie dies mit Google Cloud Armor erreichen.

Für SSL-Proxy-Load-Balancer und TCP-Proxy-Load-Balancer sind folgende Quellbereiche erforderlich:

• 130.211.0.0/22
• 35.191.0.0/16

Diese Bereiche gelten für Systemdiagnosen und Anfragen vom GFE.

Wichtig: Achten Sie darauf, dass Pakete aus den vollständigen Systemdiagnosebereichen zulässig sind. Wenn Ihre Firewallregel nur Pakete aus einem Teil der Bereiche zulässt, können Systemdiagnosen fehlschlagen, weil der Load-Balancer nicht mit Ihren Back-Ends kommunizieren kann. Dies führt zu Zeitüberschreitungen bei der Verbindung.

Quell-IP-Adressen

Die Quell-IP-Adresse für Pakete, die von den Back-Ends erkannt wird, ist nicht die externe Google Cloud-IP-Adresse des Load-Balancers. Mit anderen Worten: Es gibt zwei TCP-Verbindungen.

• Verbindung 1 vom ursprünglichen Client zum Load-Balancer (GFE):

  • Quell-IP-Adresse: Der ursprüngliche Client (oder die externe IP-Adresse, wenn sich der Client hinter NAT oder einem Weiterleitungsproxy befindet)
  • Ziel-IP-Adresse: IP-Adresse Ihres Load-Balancers

• Verbindung 2 vom Load-Balancer (GFE) zur Back-End-VM oder zum Back-End-Endpunkt:

  • Quell-IP-Adresse: IP-Adresse aus einem der unter Firewallregeln angegebenen Bereiche

  • Ziel-IP-Adresse: die interne IP-Adresse der Back-End-VM oder des Containers im VPC-Netzwerk.

Hinweis: Bei Internet-NEGs stammen Anfragen vom Load-Balancer aus verschiedenen IP-Bereichen. Weitere Informationen finden Sie unter Anfragen authentifizieren.

Offene Ports

TCP-Proxy-Load-Balancer sind Reverse-Proxy-Load-Balancer. Der Load-Balancer beendet eingehende Verbindungen und öffnet dann neue Verbindungen vom Load-Balancer zu den Back-Ends. Diese Load-Balancer werden mit Google Front End-Proxys (GFE) weltweit implementiert.

GFEs haben mehrere offene Ports, um andere Google-Dienste, die in derselben Architektur ausgeführt werden, zu unterstützen. Eine Liste der Ports, die in GFEs wahrscheinlich geöffnet sind, finden Sie unter Weiterleitungsregel: Portspezifikationen. Möglicherweise gibt es andere offene Ports für andere Google-Dienste, die auf GFEs ausgeführt werden.

Aus folgenden Gründen ist die Ausführung eines Portscans für die IP-Adresse eines GFE-basierten Load-Balancers aus Sicht der Prüfung nicht hilfreich:

• Ein Portscan (z. B. mit nmap) erwartet beim Ausführen von TCP-SYN-Tests normalerweise kein Antwortpaket oder ein TCP-RST-Paket. GFEs senden SYN-ACK-Pakete als Antwort auf SYN-Prüfungen für eine Vielzahl von Ports, wenn Ihr Load-Balancer eine IP-Adresse der Premium-Stufe verwendet. GFEs senden jedoch nur Pakete an Ihre Back-Ends, wenn Pakete an die IP-Adresse und den Zielport Ihres Load-Balancers gesendet wurden, die in seiner Weiterleitungsregel konfiguriert sind. Pakete, die an verschiedene IP-Adressen des Load-Balancers oder an die IP-Adresse Ihres Load-Balancers an einem Port gesendet werden, der nicht in Ihrer Weiterleitungsregel konfiguriert ist, führen nicht dazu, dass Pakete an die Back-Ends Ihres Load-Balancers gesendet werden. Auch ohne eine spezielle Konfiguration bieten die Google-Infrastruktur und die GFEs gestaffelte Sicherheitsebenen für DDoS-Angriffe und SYN-Floods.

• Pakete, die an die IP-Adresse Ihres Load-Balancers gesendet werden, können von jedem GFE in der Google-Flotte beantwortet werden. Wird jedoch eine Kombination aus IP-Adresse und Zielport eines Load-Balancers gescannt, wird nur ein einziges GFE pro TCP-Verbindung abgefragt. Die IP-Adresse des Load-Balancers wird keinem einzelnen Gerät oder System zugewiesen. Wenn also die IP-Adresse eines GFE-basierten Load-Balancers gescannt wird, werden nicht alle GFEs in der Flotte von Google gescannt.

Daher können Sie die Sicherheit Ihrer Back-End-Instanzen am besten mit folgenden Methoden prüfen:

• Ein Sicherheitsprüfer sollte die Konfiguration der Weiterleitungsregeln für die Konfiguration des Load-Balancers prüfen. Die Weiterleitungsregeln definieren den Zielport, für den Ihr Load-Balancer Pakete akzeptiert und an die Back-Ends weiterleitet. Bei GFE-basierten Load-Balancern kann jede externe Weiterleitungsregel nur auf einen einzelnen TCP-Zielport verweisen.

• Ein Sicherheitsprüfer sollte die Konfiguration der Firewallregel für Back-End-VMs prüfen. Die festgelegten Firewallregeln blockieren den Traffic von den GFEs zu den Back-End-VMs, aber nicht den eingehenden Traffic zu den GFEs. Best Practices finden Sie im Abschnitt Firewallregeln.

Traffic-Verteilung

Die Art und Weise, wie ein TCP-Proxy-Load-Balancer den Traffic an seine Back-Ends verteilt, hängt vom Load-Balancing-Modus und der ausgewählten Hash-Methode ab, um ein Back-End auszuwählen (Sitzungsaffinität).

Verteilung von Verbindungen

Das TCP-Proxy-Load-Balancing kann als globaler Load-Balancing-Dienst mit der Premium-Stufe und als regionaler Dienst in der Standardstufe konfiguriert werden.

Premium-Stufe:

• Sie können nur einen Back-End-Dienst haben und der Back-End-Dienst kann Back-Ends in mehreren Regionen haben. Für globales Load-Balancing stellen Sie Ihre Back-Ends in mehreren Regionen bereit. Der Load-Balancer leitet den Traffic automatisch an die Region weiter, die dem Nutzer am nächsten ist. Ist eine Region ausgelastet, leitet der Load-Balancer neue Verbindungen automatisch zu einer anderen Region mit freien Kapazitäten um. Bestehende Nutzerverbindungen bleiben aber in der aktuellen Region.
• Google bewirbt die IP-Adresse Ihres Load-Balancers von allen Points of Presence weltweit. Jede IP-Adresse des Load-Balancers ist eine globale Anycast-Adresse.
• Wenn Sie einen Back-End-Dienst mit Back-Ends in mehreren Regionen konfigurieren, versuchen Google Front Ends (GFEs) Anfragen an fehlerfreie Back-End-Instanzgruppen oder NEGs in der Region weiterzuleiten, die dem Nutzer am nächsten ist. Weitere Informationen zu diesem Vorgang finden Sie auf dieser Seite.

Standardstufe:

• Google bewirbt die IP-Adresse Ihres Load-Balancers von Points of Presence, die mit der Region der Weiterleitungsregel verknüpft sind. Der Load-Balancer verwendet eine regionale externe IP-Adresse.

• Sie können Back-Ends in derselben Region wie die Weiterleitungsregel konfigurieren. Der hier dokumentierte Prozess gilt weiterhin, aber der Load-Balancer leitet Anfragen nur an fehlerfreie Back-Ends in dieser einen Region weiter.

Ablauf der Anfrageverteilung:

Der Balancing-Modus und die Auswahl des Ziels definieren die Back-End-Vollständigkeit aus der Perspektive jeder zonalen GCE_VM_IP_PORT-NEG, zonalen Instanzgruppe oder Zone einer regionalen Instanzgruppe. Die Verteilung innerhalb einer Zone erfolgt anschließend mit konsistentem Hashing.

GFE-basierte globale externe HTTP(S)-Load-Balancer verwenden den folgenden Prozess, um eingehende Anfragen zu verteilen:

1. Die externe IP-Adresse der Weiterleitungsregel wird durch Edge-Router an den Rändern des Google-Netzwerks beworben. Jede Anzeige enthält einen nächsten Hop zu einem Layer-Load-Balancing-System mit 3/4-Ebene (Maglev) in größtmöglicher Nähe des Nutzers.
2. Maglev-Systeme prüfen die Quell-IP-Adresse des eingehenden Pakets. Sie leiten die eingehende Anfrage an die Maglev-Systeme weiter, die von den Geo-IP-Systemen von Google so nah wie möglich am Nutzer ermittelt werden.
3. Die Maglev-Systeme leiten Traffic an ein Google Front End (GFE) der ersten Ebene weiter. Das GFE auf der ersten Ebene beendet TLS gegebenenfalls und leitet dann den Traffic gemäß diesem Prozess an GFEs der zweiten Ebene weiter:
1. Wenn ein Back-End-Dienst eine Instanzgruppe oder GCE_VM_IP_PORT-NEG-Back-Ends verwendet, bevorzugen die GFEs der ersten Ebene GFEs der zweiten Ebene, die sich innerhalb oder in der Nähe der Region mit der Instanzgruppe oder NEG befinden.
2. Bei Back-End-Buckets und Back-End-Diensten mit Hybrid-NEGs, serverlosen NEGs und Internet-NEGs wählen die GFEs der ersten Ebene GFEs der zweiten Ebene in einer Teilmenge von Regionen aus, sodass die Umlaufzeit zwischen den beiden GFEs minimiert wird.

   Die GFE-Einstellung der zweiten Ebene ist keine Garantie und kann sich je nach den Netzwerkbedingungen und Wartungsaktivitäten von Google dynamisch ändern.

   GFEs der zweiten Ebene erkennen den Status der Systemdiagnose und die tatsächliche Nutzung der Back-End-Kapazität.

4. Das GFE der zweiten Ebene leitet Anfragen an Back-Ends in Zonen innerhalb seiner Region weiter.
5. Bei der Premium-Stufe senden GFEs der zweiten Ebene manchmal Anfragen an Back-Ends in Zonen unterschiedlicher Regionen. Dieses Verhalten wird als Spillover bezeichnet.

Das Spillover unterliegt zwei Prinzipien:

• Ein Spillover ist möglich, wenn alle Back-Ends, die einem GFE einer zweiten Ebene bekannt sind, ausgelastet oder fehlerhaft sind.
• Das GFE der zweiten Ebene enthält Informationen für fehlerfreie, verfügbare Back-Ends in Zonen einer anderen Region.

Die GFEs der zweiten Ebene sind in der Regel so konfiguriert, dass sie eine Teilmenge der Back-End-Standorte bereitstellen.

Das Spillover-Verhalten schöpft nicht alle möglichen Google Cloud-Zonen aus. Wenn Sie Traffic von Back-Ends in einer bestimmten Zone oder einer gesamten Region weiterleiten müssen, legen Sie den Kapazitätsskalierer auf null fest. Wenn Sie Back-Ends für Systemdiagnosen konfigurieren, ist nicht garantiert, dass das GFE der zweiten Ebene Anfragen an Back-Ends in Zonen einer anderen Region weiterleitet.

6. Beim Verteilen von Anfragen an Back-Ends arbeiten GFEs auf einer zonalen Ebene.

   Bei einer geringen Anzahl von Verbindungen bevorzugen GFEs der zweiten Ebene manchmal eine bestimmte Zone innerhalb einer Region. Dieses Verhalten ist normal und wird erwartet. Die Verteilung zwischen Zonen in der Region ist erst dann gleichmäßig, wenn der Load-Balancer mehr Verbindungen erhält.

Balancing-Modus

Wenn Sie dem Back-End-Dienst ein Back-End hinzufügen, legen Sie einen Load-Balancing-Modus fest.

Beim TCP-Proxy-Load-Balancing sind die Balancing-Modi CONNECTION oder UTILIZATION möglich.

Wenn der Load-Balancing-Modus CONNECTION ist, basiert die Verteilung der Last darauf, wie viele gleichzeitige Verbindungen das Back-End verarbeiten kann. Außerdem müssen Sie einen der folgenden Parameter genau angeben: maxConnections (außer für regionale verwaltete Instanzgruppen), maxConnectionsPerInstance oder maxConnectionsPerEndpoint.

Wenn der Load-Balancing-Modus UTILIZATION ist, wird die Last anhand der Auslastung der Instanzen in einer Instanzgruppe verteilt.

Informationen zum Vergleichen der Load-Balancer-Typen und der unterstützten Balancing-Modi finden Sie unter Load-Balancing-Methoden.

Sitzungsaffinität

Mit Sitzungsaffinität werden alle Anfragen vom selben Client an dasselbe Back-End gesendet, wenn das Back-End fehlerfrei ist und Kapazität hat.

Das TCP-Proxy-Load-Balancing bietet Client-IP-Affinität, mit der alle Anfragen von derselben Client-IP-Adresse an dasselbe Back-End weitergeleitet werden.

Failover

Wenn ein Back-End fehlerhaft wird, wird der Traffic automatisch zu fehlerfreien Back-Ends in derselben Region weitergeleitet. Wenn alle Back-Ends innerhalb einer Region fehlerhaft sind, wird der Traffic an fehlerfreie Back-Ends in anderen Regionen verteilt (nur Premium-Stufe). Wenn alle Back-Ends fehlerhaft sind, löscht der Load-Balancer den Traffic.

Load-Balancing für GKE-Anwendungen

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

Zugehörige GKE-Dokumentation:

• Containernatives Load-Balancing über eigenständige NEGs

Nächste Schritte

• Informationen zum Konfigurieren eines TCP-Proxy-Load-Balancers finden Sie unter TCP-Proxy-Load-Balancing einrichten.
• Wie Sie ein Monitoring für Ihren TCP-Proxy-Load-Balancer einrichten, erfahren Sie unter Monitoring verwenden.
• Eine Liste der Points of Presence (PoPs) von Google finden Sie unter GFE-Standorte.