Übersicht: Externes TCP-Proxy-Load-Balancing

Externes 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 externen 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 externem TCP-Proxy-Load-Balancing können Sie eine einzelne IP-Adresse für alle Nutzer auf der ganzen Welt verwenden. Der externe TCP-Proxy-Load-Balancer leitet den Traffic automatisch an die Back-Ends weiter, die dem Nutzer am nächsten sind.

Bei der Premium-Stufe kann das externe TCP-Proxy-Load-Balancing als globaler Load-Balancing-Dienst konfiguriert werden. Bei der Standardstufe führt der externe TCP-Proxy-Load-Balancer das Load-Balancing regional aus.

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)
Cloud Load Balancing mit TCP-Beendigung (zum Vergrößern klicken)

Das externe 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, das externe SSL-Proxy-Load-Balancing.

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

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

Vorteile

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

  • IPv6-Beendigung Das externe 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. 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671, 5672, 5900, 5901, 6379, 8085, 8099, 9092, 9200, and 9300.
  • Einbindung in Google Cloud Armor. Sie können die Sicherheitsrichtlinien von Google Cloud Armor verwenden, um Ihre Infrastruktur vor DDoS-Angriffen (Distributed Denial of Service) und anderen gezielten Angriffen zu schützen.

Architektur

Die folgenden Komponenten gehören zu externen 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 externen 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 externe TCP-Proxy-Load-Balancing werden TCP-Verbindungen des Clients beendet und neue Verbindungen zu den Back-Ends aufgebaut. Der Zielproxy leitet diese neuen Verbindungen an den Back-End-Dienst weiter.

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.

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

Jeder externe TCP-Proxy-Load-Balancer hat 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 einen externen 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 das externe TCP-Proxy-Load-Balancing und das externe SSL-Proxy-Load-Balancing gelten die folgenden Firewallregeln:

  • Eine Firewallregel zum Zulassen von eingehendem Traffic, die eingehenden Traffic von Google Front Ends (GFEs) zu Ihren Back-Ends zulässt.

  • Eine Firewallregel zum Zulassen von eingehendem Traffic, die Traffic von den Systemdiagnoseprüfungen zu Ihren Back-Ends zulässt. Weitere Informationen zu Systemdiagnoseprüfungen und dazu, warum Traffic von ihnen zugelassen werden muss, finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.

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.

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.

Folgende Quell-IP-Adressbereiche müssen zugelassen werden:

  • 130.211.0.0/22
  • 35.191.0.0/16

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

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.

Offene Ports

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

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

Architektur einer freigegebenen VPC

Das externe TCP-Proxy-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 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 und URL-Zuordnung Back-End-Komponenten
Eine externe IP-Adresse muss im selben Projekt wie der Load-Balancer definiert werden. Die externe Weiterleitungsregel muss im selben Projekt wie die Back-End-Instanzen (im Dienstprojekt) definiert werden. Der TCP-Zielproxy und die URL-Zuordnung müssen im selben Projekt wie die Back-End-Instanzen definiert werden. Ein globaler Back-End-Dienst muss im selben Projekt wie die Back-End-Instanzen definiert werden. 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 sein.

Traffic-Verteilung

Die Art und Weise, wie ein externer 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 externe 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:

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

  1. Die externe IP-Adresse der Weiterleitungsregel wird durch Edge-Router an den Rändern des Google-Netzwerks beworben. Jedes Advertising listet einen nächsten Hop zu einem Layer-3/4-Load-Balancing-System (Maglev) auf.
  2. 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.

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

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

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

Balancing-Modus

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

Beim externen 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 externe 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:

Nächste Schritte