SSL-Proxy-Load-Balancing – Übersicht

SSL-Proxy-Load-Balancing ist ein Reverse-Proxy-Load-Balancer, der SSL-Traffic aus dem Internet auf VM-Instanzen in Ihrem Google Cloud VPC-Netzwerk verteilt.

Wenn Sie das SSL-Proxy-Load-Balancing für Ihren SSL-Traffic verwenden, werden SSL-(TLS-)Verbindungen von Nutzern auf der Load-Balancing-Ebene terminiert und dann über SSL (empfohlen) oder TCP zu den nächstgelegenen verfügbaren Back-End-Instanzen weitergeleitet. Informationen zu den unterstützten Back-Ends finden Sie unter Back-Ends.

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

In diesem Beispiel wird der Traffic von Nutzern aus Iowa und Boston auf der Load-Balancing-Ebene beendet und es wird eine separate Verbindung zum ausgewählten Back-End aufgebaut.

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

SSL-Proxy-Load-Balancing ist für Nicht-HTTP(S)-Traffic konzipiert. Für HTTP(S)-Traffic wird die Verwendung von HTTP(S)-Load-Balancing empfohlen.

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

Vorteile

Bei Verwendung des SSL-Proxy-Load-Balancings bieten sich unter anderem folgende Vorteile:

  • IPv6-Beendigung SSL-Proxy-Load-Balancing wird für Clienttraffic von IPv4- und IPv6-Adressen unterstützt. IPv6-Anfragen von Clients werden auf der Load-Balancing-Ebene beendet und dann über IPv4 an Ihre VMs 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.

  • Bessere Auslastung von Back-Ends Die SSL-Verarbeitung kann sehr CPU-intensiv sein, wenn die verwendeten Chiffren nicht CPU-effizient sind. Sie können die CPU-Leistung maximieren, indem Sie ECDSA-SSL-Zertifikate sowie TLS 1.2 verwenden und bevorzugt die Cipher Suite ECDHE-ECDSA-AES128-GCM-SHA256 für SSL zwischen dem Load-Balancer und Ihren Back-End-Instanzen einsetzen.

  • Zertifikatsverwaltung Kundenseitige SSL-Zertifikate können entweder Zertifikate sein, die Sie selbst abrufen und verwalten (selbstverwaltete Zertifikate), oder Zertifikate, die von Google abgerufen und verwaltet werden (von Google verwaltete Zertifikate). Von Google verwaltete SSL-Zertifikate unterstützen jeweils bis zu 100 Domains. Für von Google verwaltete Zertifikate werden mehrere Domains unterstützt. Sie müssen nur auf dem Load-Balancer Zertifikate bereitstellen. Auf VMs können Sie die Verwaltung mithilfe selbst signierter Zertifikate vereinfachen.

  • Sicherheitspatches Wenn im SSL- oder TCP-Paket Sicherheitslücken auftreten, werden für den Load-Balancer automatisch Patches bereitgestellt, um die Sicherheit Ihrer VMs zu gewährleisten.

  • Unterstützung für folgende bekannten 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 und 9300. Wenn Sie von Google verwaltete SSL-Zertifikate mit SSL-Proxy-Load-Balancing verwenden, muss der Front-End-Port für Traffic 443 sein, damit die von Google verwalteten SSL-Zertifikate bereitgestellt und erneuert werden können.

  • SSL-Richtlinien Mit SSL-Richtlinien können Sie die Features von SSL steuern, die Ihr SSL-Proxy-Load-Balancer mit Clients aushandelt.

  • Beendigung von TLS geografisch steuern Der SSL-Proxy-Load-Balancer beendet TLS an global verteilten Orten, um die Latenz zwischen den Clients und dem Load-Balancer zu minimieren. Wenn Sie steuern müssen, wo TLS geografisch beendet wird, sollten Sie stattdessen den Load-Balancer des Netzwerks verwenden und TLS auf Back-Ends in solchen Regionen beenden, die für Ihren Bedarf geeignet sind.

Verhalten des Load-Balancers in Netzwerkdienststufen

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.

So wird der Traffic den Back-Ends zugewiesen:

  1. Wenn ein Client eine Anfrage sendet, ermittelt der Load-Balancing-Dienst anhand der Quell-IP-Adresse den ungefähren Ursprung der Anfrage.
  2. Der Load-Balancing-Dienst bestimmt die Standorte der Back-Ends, die dem Back-End-Dienst gehören, deren Gesamtkapazität und deren aktuelle Auslastung.
  3. Wenn die Back-End-Instanzen, die dem Nutzer am nächsten sind, freie Kapazitäten haben, wird die Anfrage an die nächstgelegene Gruppe von Back-Ends weitergeleitet.
  4. Eingehende Anfragen an die angegebene Region werden gleichmäßig auf alle verfügbaren Back-End-Instanzen in dieser Region verteilt. Bei sehr kleinen Arbeitslasten kann sich die Verteilung als ungleichmäßig darstellen.
  5. Wenn es in einer bestimmten Region keine fehlerfreien Back-End-Instanzen mit verfügbarer Kapazität gibt, sendet der Load-Balancer die Anfrage stattdessen an die nächstgelegene Region mit verfügbarer Kapazität.

Standardstufe

Bei der Standardstufe ist das TCP-Proxy-Load-Balancing ein regionaler Dienst. Die Back-Ends müssen sich alle in der Region befinden, die von der externen IP-Adresse und Weiterleitungsregel des Load-Balancers verwendet wird.

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.

Jede externe Weiterleitungsregel, die in einem SSL-Proxy-Load-Balancer verwendet wird, kann auf genau einen der Ports verweisen, die unter Portspezifikationen für Weiterleitungsregeln aufgeführt sind.

Zielproxys

SSL-Proxy-Load-Balancing beendet SSL-Verbindungen des Clients und erstellt neue Verbindungen zu den Back-Ends. Der Zielproxy leitet eingehende Anfragen direkt 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.

SSL-Zertifikate

Auf dem Ziel-SSL-Proxy müssen Sie mindestens ein SSL-Zertifikat installieren.

Mit den Zertifikaten sichert der SSL-Ziel-Proxy die Kommunikation zwischen einem Google Front End (GFE) und dem Client. Diese können selbstverwaltete oder von Google verwaltete SSL-Zertifikate sein.

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

Zur Gewährleistung einer optimalen Sicherheit verwenden Sie bei der Bereitstellung des SSL-Proxy-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.

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

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.

Firewallregeln

Die Back-End-Instanzen müssen Verbindungen von den GFE- / Systemdiagnosebereichen des Load-Balancers zulassen. Dies bedeutet, dass Sie eine Firewallregel erstellen müssen, die Traffic von 130.211.0.0/22 und 35.191.0.0/16 zulässt, um Ihre Back-End-Instanzen oder Endpunkte zu erreichen. Diese IP-Adressbereiche werden als Quellen für Systemdiagnose-Pakete und für alle Pakete mit Load-Balancing verwendet, die an Ihre Back-Ends gesendet werden.

Die Ports, die Sie für diese Firewallregel konfigurieren, müssen Traffic zu Back-End-Instanzen oder -Endpunkten zulassen:

  • Sie müssen die von jeder Weiterleitungsregel verwendeten Ports zulassen.
  • Sie müssen die von jeder Systemdiagnose verwendeten Ports zulassen, die für jeden Back-End-Dienst konfiguriert sind.

Firewallregeln werden auf VM-Instanzebene und nicht auf GFE-Proxys (Google Front End) implementiert. Sie können Google Cloud-Firewallregeln nicht verwenden, um zu verhindern, dass Traffic den Load-Balancer erreicht.

Weitere Informationen zu Systemdiagnosetests und dazu, warum Traffic von 130.211.0.0/22 und 35.191.0.0/16 zugelassen werden muss, finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.

Quell-IP-Adressen

Die Quell-IP-Adressen für Pakete, die von jeder Instanz oder jedem Container des Back-Ends der virtuellen Maschine erkannt werden, sind Adressen aus folgenden Bereichen:

  • 35.191.0.0/16
  • 130.211.0.0/22

Die Quell-IP-Adresse für tatsächlichen Traffic mit Load-Balancing liegt innerhalb der Systemdiagnose-IP-Bereiche.

Die Quell-IP-Adressen für den Traffic, die von den Back-Ends erkannt werden, entsprechen nicht der externen Google Cloud-IP-Adresse des Load-Balancers. Mit anderen Worten: Es gibt zwei HTTP-, SSL- oder TCP-Sitzungen:

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

    • Quell-IP-Adresse: Der ursprüngliche Client (oder die externe IP-Adresse, wenn der Client hinter NAT liegt)
    • Ziel-IP-Adresse: IP-Adresse Ihres Load-Balancers
  • Sitzung 2 vom Load-Balancer (GFE) zur Back-End-VM oder zum Back-End-Container:

    • Quell-IP-Adresse: IP-Adresse aus einem der folgenden Bereiche: 35.191.0.0/16 oder 130.211.0.0/22

      Eine Vorhersage der tatsächlichen Quelladresse ist nicht möglich.

    • Ziel-IP-Adresse: Interne IP-Adresse der Back-End-VM oder des Containers im VPC-Netzwerk (Virtual Private Cloud)

Quell-IP-Adressen von Clients beibehalten

Um die ursprünglichen Quell-IP-Adressen eingehender Verbindungen zum Load Balancer beizubehalten, können Sie den Load Balancer so konfigurieren, dass ein Header des PROXY-Protokolls Version 1 vorangestellt wird. Auf diese Weise werden die ursprünglichen Verbindungsinformationen beibehalten. Weitere Informationen finden Sie unter PROXY-Protokollheader für den Proxy aktualisieren.

Offene Ports

SSL-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. Die Reverse-Proxy-Funktionalität wird von den Google-Front-Ends (GFEs) bereitgestellt.

Die festgelegten Firewallregeln blockieren den Traffic von den GFEs zu den Back-End-Instanzen, aber nicht den eingehenden Traffic zu den GFEs.

Die SSL-Proxy-Load-Balancer haben eine Reihe von offenen Ports, um andere Google-Dienste, die in derselben Architektur ausgeführt werden, zu unterstützen. Wenn Sie einen Sicherheits- oder Portscan für die externe IP-Adresse Ihres Load-Balancers ausführen, wirkt es so, als ob weitere Ports offen wären.

Dies hat keine Auswirkungen auf SSL-Proxy-Load-Balancer. Externe Weiterleitungsregeln, die in der Definition eines SSL-Proxy-Load-Balancers verwendet werden, können auf genau einen der aufgeführten Ports verweisen, die unter Portspezifikationen für Weiterleitungsregeln aufgeführt sind. Traffic mit einem anderen TCP-Zielport wird nicht an das Back-End des Load-Balancers weitergeleitet.

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

Balancing-Modus

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

Beim SSL-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.

Nutzungshinweise und Einschränkungen

  • Wenn Sie den Traffic zwischen der Load-Balancing-Ebene und den Back-End-Instanzen über unverschlüsselte TCP-Verbindungen senden, können Sie die SSL-Verarbeitung von Ihren Back-Ends auslagern. Dies beeinträchtigt jedoch die Sicherheit. Daher wird dies nicht empfohlen.

  • Sie können SSL-Richtlinien mit dem gcloud-Befehlszeilentool erstellen.

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

  • Die auf einem Clientzertifikat basierte Authentifizierung, die auch als gegenseitige TLS-Authentifizierung bezeichnet wird, wird von SSL-Proxy-Load-Balancern nicht unterstützt.

  • Obwohl das SSL-Proxy-Load-Balancing HTTPS-Traffic verarbeiten kann, wird dies nicht empfohlen. Für HTTPS-Traffic sollten Sie stattdessen HTTP(S)-Load-Balancing verwenden. HTTP(S) Load Balancing führt auch Folgendes aus, was es in den meisten Fällen zu einer besseren Wahl macht:

    • Unterstützt Negotiation mit HTTP/2 und SPDY/3.1.
    • Weist ungültige HTTP-Anfragen oder -Antworten zurück.
    • Leitet Anfragen je nach URL-Host und -Pfad an verschiedene VMs weiter
    • Integriert sich in Cloud CDN.
    • Verteilt die Anfragelast gleichmäßiger zwischen den Back-End-Instanzen, wodurch die Back-End-Auslastung optimiert wird. Beim HTTPS-Load-Balancing wird jede Anfrage separat verarbeitet, während beim SSL-Proxy-Load-Balancing alle Byte einer SSL- oder TCP-Verbindung an dieselbe Back-End-Instanz gesendet werden.
  • Für SSL-Proxy-Load-Balancer mit von Google verwalteten SSL-Zertifikaten müssen die Front-End-Ports 443 enthalten, damit die Zertifikate bereitgestellt und verlängert werden.

    SSL-Proxy-Load-Balancing kann für andere Protokolle verwendet werden, die SSL verwenden, z. B. WebSockets und IMAP über SSL.

Weitere Informationen