Hybrid-Load-Balancing – Übersicht

Cloud Load Balancing unterstützt Load-Balancing-Traffic zu Endpunkten, die über Google Cloud hinausgehen, z. B. lokale Rechenzentren und andere öffentliche Clouds, die Sie über Hybridkonnektivität erreichen können.

Eine Hybridstrategie ist eine pragmatische Lösung, mit der Sie Ihr Unternehmen an wechselnde Marktbedürfnisse anpassen und Ihre Anwendungen schrittweise modernisieren können. Dies kann eine temporäre Hybridbereitstellung sein, um die Migration zu einer modernen cloudbasierten Lösung zu ermöglichen, oder eine dauerhafte Bereitstellung der IT-Infrastruktur Ihres Unternehmens.

Mit der Einrichtung des Hybrid-Load-Balancings können Sie außerdem die Vorteile der Netzwerkfunktionen von Cloud Load Balancing für Dienste nutzen, die in Ihrer vorhandenen Infrastruktur außerhalb von Google Cloud ausgeführt werden.

Hybrid-Load-Balancing wird auf den folgenden Google Cloud-Load-Balancern unterstützt:

Anwendungsfall: Traffic an einen lokalen Standort oder eine andere Cloud weiterleiten

Der einfachste Anwendungsfall für dieses Feature ist das Routing von Traffic von einem Google Cloud-Load-Balancer zu Google Cloud, einem lokalen Standort oder einer anderen Cloud. Clients können Traffic entweder aus dem öffentlichen Internet, von Google Cloud oder von einem lokalen Client aus generieren.

Öffentliche Clients

Mithilfe des HTTP(S)-Load-Balancings können Sie Traffic von externen Clients an ein Back-End in Google Cloud, lokal oder in einer anderen Cloud weiterleiten. Mit HTTP(S)-Load-Balancing können Sie auch Mehrwert-Netzwerkfunktionen für Ihre lokalen Dienste aktivieren. Sie können:

  • Verwenden Sie die globale Edge-Infrastruktur von Google, um Nutzerverbindungen näher am Nutzer zu beenden und somit die Latenz zu verringern.
  • Schützen Sie Ihren Dienst mit Google Cloud Armor, einem Edge-DDoS-Sicherheitsprodukt für alle Dienste, auf die über einen externen HTTP(S)-Load-Balancer zugegriffen wird.
  • Aktivieren Sie Ihren Dienst, um die Zustellung mithilfe von Cloud CDN zu optimieren. Mit Cloud CDN können Sie Inhalte in der Nähe Ihrer Nutzer im Cache speichern. Cloud CDN bietet Funktionen wie Cache-Entwertung und Cloud CDN-signierte URLs.
  • Verwenden Sie von Google verwaltete SSL-Zertifikate. Sie können Zertifikate und private Schlüssel wiederverwenden, die Sie bereits für andere Google Cloud-Produkte verwenden. Sie müssen somit keine separaten Zertifikate verwalten.

Das folgende Diagramm zeigt eine Hybridbereitstellung mit einem externen HTTP(S)-Load-Balancer.

Hybridkonnektivität mit HTTP(S)-Load-Balancing (zum Vergrößern klicken)
Hybridkonnektivität mit externem HTTP(S)-Load-Balancing (zum Vergrößern klicken)

In diesem Diagramm gelangt Traffic von Clients im öffentlichen Internet über einen Load-Balancer von Google Cloud wie den externen HTTP(S)-Load-Balancer in Ihr privates lokales Netzwerk oder in ein Cloud-Netzwerk. Sobald der Traffic den Load-Balancer erreicht, können Sie Edge-Netzwerkdienste wie den DDoS-Schutz von Google Cloud Armor oder die IAP-Nutzerauthentifizierung (Identity-Aware Proxy) anwenden.

Wie die Anfrage weitergeleitet wird (ob an ein Google Cloud-Back-End oder an einen lokalen/Cloud-Endpunkt) hängt davon ab, wie Ihre URL-Zuordnung konfiguriert ist. Abhängig von Ihrer URL-Zuordnung wählt der Load-Balancer einen Back-End-Dienst für die Anfrage aus. Wenn der ausgewählte Back-End-Dienst mit einer Hybridkonnektivitäts-NEG konfiguriert wurde (nur für Endpunkte außerhalb von Google Cloud), leitet der Load-Balancer den Traffic über Cloud VPN oder Cloud Interconnect an das vorgesehene Ziel weiter.

Interne Clients (in Google Cloud oder lokal)

Sie können auch eine hybride Bereitstellung für Clients innerhalb von Google Cloud einrichten. In diesem Fall stammt der Clienttraffic aus dem Google Cloud-VPC-Netzwerk, Ihrem lokalen Netzwerk oder aus einer anderen Cloud und wird an Endpunkte weitergeleitet, die sich in Google Cloud, in Ihrer lokalen Umgebung oder in einer anderen Cloud befinden können. Beachten Sie, dass das interne HTTP(S)-Load-Balancing ein regionaler Load-Balancer ist. Das bedeutet, dass Traffic nur an Endpunkte in derselben GCP-Zone oder -Region wie die Ressourcen des Load-Balancers weitergeleitet werden kann.

Das folgende Diagramm zeigt eine Hybridbereitstellung mit einem internen HTTP(S)-Load-Balancer.

Hybridkonnektivität mit internem HTTP(S)-Load-Balancing (zum Vergrößern klicken)
Hybridkonnektivität mit internem HTTP(S)-Load-Balancing (zum Vergrößern klicken)

Anwendungsfall: Migration zu Cloud

Durch die Migration eines vorhandenen Dienstes in die Cloud können Sie lokale Kapazität freigeben und die Kosten und den Aufwand für die Wartung der lokalen Infrastruktur reduzieren. Sie können vorübergehend eine Hybridbereitstellung einrichten, die Ihnen die Weiterleitung von Traffic sowohl zu Ihrem derzeitigen lokalen Dienst als auch zu einem entsprechenden Endpunkt des Google Cloud-Dienstes ermöglicht.

Das folgende Diagramm veranschaulicht diese Einrichtung mit internem HTTP(S)-Load-Balancing.

Zu Google Cloud migrieren (zum Vergrößern klicken)
Zu Google Cloud migrieren (zum Vergrößern klicken)

Wenn Sie das interne HTTP(S)-Load-Balancing zur Verarbeitung interner Clients verwenden, können Sie den Load-Balancer für Google Cloud so konfigurieren, dass die gewichtete Trafficaufteilung zum Aufteilen von Traffic auf die beiden Dienste verwendet wird. Bei der Trafficaufteilung können Sie mit dem Senden von 0 % des Traffics an den Google Cloud-Dienst und von 100 % an den lokalen Dienst beginnen. Anschließend können Sie den Anteil des an den Google Cloud-Dienst gesendeten Traffics schrittweise erhöhen. Schließlich senden Sie 100 % des Traffics an den Google Cloud-Dienst und deaktivieren den lokalen Dienst.

Hybridarchitektur

In diesem Abschnitt werden die Load-Balancing-Architektur und die Ressourcen beschrieben, die zum Konfigurieren einer hybriden Load-Balancing-Bereitstellung erforderlich sind.

Die Konfiguration von lokalen und anderen Cloud-Diensten entspricht grundsätzlich dem anderer Cloud Load Balancing-Back-Ends. Der Hauptunterschied besteht darin, dass Sie für die Konfiguration der Endpunkte dieser Back-Ends eine Hybridkonnektivitäts-NEG verwenden. Die Endpunkte müssen gültige IP:port-Kombinationen sein, die Ihre Clients über Hybridkonnektivität erreichen können, z. B. Cloud VPN oder Cloud Interconnect.

Das folgende Diagramm zeigt die Google Cloud-Ressourcen, die zum Aktivieren des Hybrid-Load-Balancings für das externe HTTP(S)-Load-Balancing erforderlich sind.

Externe HTTP(S)-Load-Balancer-Ressourcen für Hybridkonnektivität (zum Vergrößern klicken)
Externe HTTP(S)-Load-Balancer-Ressourcen für Hybridkonnektivität (zum Vergrößern klicken)

Das folgende Diagramm zeigt die Google Cloud-Ressourcen, die zum Aktivieren des Hybrid-Load-Balancings für das interne HTTP(S)-Load-Balancing erforderlich sind.

Interne HTTP(S)-Load-Balancer-Ressourcen für Hybridkonnektivität (zum Vergrößern klicken)
Interne HTTP(S)-Load-Balancer-Ressourcen für Hybridkonnektivität (zum Vergrößern klicken)

Regional oder global

Das Routing von Cloud Load Balancing hängt vom Bereich des konfigurierten Load-Balancers ab:

Externes HTTP(S)-Load-Balancing. Bei Traffic aus dem Internet kann der externe HTTP(S)-Load-Balancer je nach verwendeter Netzwerkstufe entweder für globales oder für regionales Routing konfiguriert werden. Sie sollten das Hybrid-NEG-Back-End des Load-Balancers in derselben Region erstellen, in der die Hybridkonnektivität konfiguriert wurde. Endpunkte, die nicht aus Google Cloud stammen, müssen ebenfalls entsprechend konfiguriert werden, um das umgebungsbasierte Load-Balancing zu nutzen.

Internes HTTP(S)-Load-Balancing. Für Traffic von internen Clients ist der interne HTTP(S)-Load-Balancer ein regionaler Load-Balancer. Das heißt, er kann Traffic nur an Endpunkte innerhalb derselben Region wie der Load-Balancer weiterleiten. Die Komponenten des internen HTTP(S)-Load-Balancers müssen in derselben Region konfiguriert sein, in der Hybridkonnektivität konfiguriert wurde. Da das interne HTTP(S)-Load-Balancing keinen globalen Zugriff unterstützt, müssen sich Clients, die auf den Load-Balancer zugreifen, ebenfalls in derselben Region befinden.

Wenn beispielsweise das Cloud VPN-Gateway oder der Cloud Interconnect-VLAN-Anhang in us-central1 konfiguriert wurde, müssen die vom internen HTTP(S)-Load-Balancer erforderlichen Ressourcen (Back-End-Dienst, Hybrid-NEG, Weiterleitungsregel, usw.) in der Region us-central1 erstellt werden. Clients, die auf den Load-Balancer zugreifen, müssen sich auch in der Region us-central1 befinden.

Anforderungen an die Netzwerkverbindung

Bevor Sie eine Bereitstellung mit Hybrid-Load-Balancing konfigurieren, müssen Sie die folgenden Ressourcen eingerichtet haben:

  • Google Cloud-VPC-Netzwerk: Ein in Google Cloud konfiguriertes VPC-Netzwerk. Dies ist das Netzwerk, in dem die Hybrid-Load-Balancing-Ressourcen (Weiterleitungsregel, Zielproxy, Back-End-Dienst usw.) erstellt werden. Die IP-Adressen und IP-Adressbereiche für lokale, andere Cloud- und Google Cloud-Subnetze dürfen sich nicht überschneiden. Bei Überschneidung von IP-Adressen haben Subnetzrouten Vorrang vor Remote-Verbindungen.
  • Hybridkonnektivität. Ihre Google Cloud-Umgebung, lokale Umgebung oder sonstige Cloud-Umgebung muss über Hybridkonnektivität verbunden sein. Dafür werden entweder Cloud Interconnect-VLAN-Anhänge oder Cloud VPN-Tunnel mit Cloud Router verwendet. Wir empfehlen die Verwendung einer Verbindung mit Hochverfügbarkeit. Ein Cloud Router, der für das globale dynamische Routing aktiviert ist, erkennt den spezifischen Endpunkt über BGP und programmiert ihn in Ihrem Google Cloud-VPC-Netzwerk. Regionales dynamisches Routing wird nicht unterstützt. Statische Routen werden ebenfalls nicht unterstützt.

    Cloud Interconnect/Cloud VPN und Cloud Router müssen im selben VPC-Netzwerk konfiguriert werden, das Sie für die hybride Load-Balancing-Bereitstellung verwenden möchten. Der Cloud Router muss außerdem die folgenden Routen zu Ihrer lokalen Umgebung bewerben:
    • Die von den Systemdiagnoseprüfungen von Google verwendeten Bereiche: 35.191.0.0/16 und 130.211.0.0/22.
    • Nur beim internen HTTP(S)-Load-Balancing: der Bereich des Nur-Proxy-Subnetzes der Region.
  • Netzwerkendpunkte (IP:Port) in Ihrer lokalen Umgebung oder in einer anderen Cloud. Einen oder mehrere IP:Port-Netzwerkendpunkte, die in Ihrer lokalen Umgebung oder in einer anderen Cloud-Umgebung konfiguriert sind und über Cloud Interconnect oder Cloud VPN weitergeleitet werden können. Wenn mehrere Pfade zum IP-Endpunkt vorhanden sind, folgt das Routing dem in der Übersicht über VPC-Routen und der Übersicht über Cloud Router beschriebenen Verhalten.
  • Firewallregeln in Ihrer lokalen oder sonstigen Cloud-Umgebung. Die folgenden Firewallregeln müssen in Ihrer lokalen oder sonstigen Cloud-Umgebung erstellt werden:
    • Firewallregeln für eingehenden Traffic erlauben Traffic von der Systemdiagnose von Google an Ihre Endpunkte. Für den externen HTTP(S)-Load-Balancer, den internen HTTP(S)-Load-Balancer, den TCP-Proxy-Load-Balancer und den SSL-Proxy-Load-Balancer sind die zulässigen Bereiche 35.191.0.0/16 und 130.211.0.0/22. Beachten Sie, dass diese Bereiche auch von Cloud Router Ihrem lokalen Netzwerk angeboten werden müssen. Weitere Informationen finden Sie unter Prüfungs-IP-Bereiche und Firewallregeln.
    • Firewallregeln zum Zulassen von eingehendem Traffic, damit Traffic mit Load-Balancing die Endpunkte erreichen kann.
    • Beim internen HTTP(S)-Load-Balancing müssen Sie außerdem eine Firewallregel erstellen, damit Traffic aus dem Proxy-Only-Subnetz der Region die Endpunkte erreichen kann.

Komponenten des Lastenausgleichsmoduls

Je nach Typ des Load-Balancers können Sie auf der Standard- oder Premium-Netzwerkstufe eine Bereitstellung mit Hybrid-Load-Balancing einrichten.

Ein Hybrid-Load-Balancer erfordert spezifische Konfiguration nur für den Back-End-Dienst. Die Front-End-Konfiguration ist die gleiche wie für jeden anderen Load-Balancer. Darüber hinaus benötigen interne HTTP(S)-Load-Balancer ein Nur-Proxy-Subnetz, um Envoy-Proxys in Ihrem Namen auszuführen.

Front-End-Konfiguration

Für das Hybrid-Load-Balancing ist keine spezielle Front-End-Konfiguration erforderlich. Weiterleitungsregeln werden verwendet, um Traffic nach IP-Adresse, Port und Protokoll an einen Zielproxy weiterzuleiten. Der Zielproxy beendet dann Verbindungen von Clients.

URL-Zuordnungen werden von HTTP(S)-Load-Balancern verwendet, um URL-basiertes Routing von Anfragen an die entsprechenden Back-End-Dienste einzurichten.

Weitere Informationen zu den einzelnen Komponenten finden Sie in den Architekturabschnitten der jeweiligen Load-Balancer-Übersicht:

Back-End-Dienst

Back-End-Dienste stellen Konfigurationsinformationen für den Load-Balancer bereit. Load-Balancer leiten den eingehenden Traffic anhand der Informationen in einem Back-End-Dienst an einen oder mehrere verknüpfte Back-Ends weiter.

Zum Einrichten einer hybriden Load-Balancing-Bereitstellung konfigurieren Sie den Load-Balancer mit Back-Ends sowohl innerhalb als auch außerhalb von Google Cloud.

  • Back-Ends außerhalb von Google Cloud (lokal oder andere Cloud)

    Jedes Ziel, das Sie mit den Google-Produkten für Hybridkonnektivität (entweder Cloud VPN oder Cloud Interconnect) und mit einer gültigen IP:Port-Kombination erreichen können, kann als Endpunkt für den Load-Balancer konfiguriert werden.

    Konfigurieren Sie Ihre Cloud-Back-Ends außerhalb von Google Cloud so:

    1. Fügen Sie jede IP:Port-Kombination aus Endpunkten außerhalb des Google Cloud-Netzwerks zu einer Netzwerk-Endpunktgruppe mit Hybridkonnektivität hinzu. Achten Sie darauf, dass diese IP-Adresse und dieser Port über Hybridkonnektivität von Google Cloud aus erreichbar sind (entweder über Cloud VPN oder Cloud Interconnect). Für NEGs mit Hybridkonnektivität legen Sie den Netzwerkendpunkttyp auf NON_GCP_PRIVATE_IP_PORT fest.
    2. Geben Sie beim Erstellen der NEG eine Google Cloud-Zone an, mit der die geografische Entfernung zwischen Google Cloud und Ihrer lokalen oder sonstigen Cloud-Umgebung minimiert wird. Wenn Sie beispielsweise einen Dienst in einer lokalen Umgebung in Frankfurt hosten, können Sie beim Erstellen der NEG die Google Cloud-Zone europe-west3-a angeben.
    3. Fügen Sie diese Hybridkonnektivitäts-NEG als Back-End für den Back-End-Dienst hinzu.

  • Google Cloud-Back-Ends

    Konfigurieren Sie Ihre Google Cloud-Endpunkte so:

    1. Erstellen Sie einen separaten Back-End-Dienst für die Google Cloud-Back-Ends.
    2. Konfigurieren Sie mehrere Back-Ends (zonale NEGs oder Instanzgruppen) in derselben Region, in der Sie die Hybridkonnektivität eingerichtet haben.

Weitere Aspekte:

  • Jede Hybridkonnektivitäts-NEG kann nur Netzwerkendpunkte desselben Typs (NON_GCP_PRIVATE_IP_PORT) enthalten.

  • Der Back-End-Dienst kann nicht gleichzeitig andere NEG-Typen oder Instanzgruppen als Back-Ends verwenden. Alle Back-Ends eines Back-End-Dienstes müssen vom gleichen Typ sein. Wenn Sie Back-Ends in Google Cloud haben, müssen Sie dafür einen separaten Back-End-Dienst erstellen. Das liegt daran, dass Google Cloud-basierte Back-Ends einen anderen Back-End-Typ (Instanzgruppe oder zonale NEG) verwenden und Back-End-Dienste mit gemischten Back-End-Typen nicht unterstützt werden.

  • Das Load-Balancing-Schema des Back-End-Dienstes muss entweder EXTERNAL_MANAGED für den globalen externen HTTP(S)-Load-Balancer, EXTERNAL für den globalen externen HTTP(S)-Load-Balancer (klassisch), für den TCP-Proxy-Load-Balancer und SSL-Proxy-Load-Balancer oder INTERNAL_MANAGED für interne HTTP(S)-Load-Balancer sein. INTERNAL_SELF_MANAGED wird für Traffic Director-Bereitstellungen in mehreren Umgebungen und Hybridkonnektivitäts-NEGs unterstützt.

  • Das Back-End-Dienstprotokoll muss einer von HTTP, HTTPS oder HTTP2 für die HTTP(S)-Load-Balancer und entweder TCP oder SSL für den TCP-Proxy und den SSL-Proxy-Load-Balancer sein. Eine Liste der Back-End-Dienstprotokolle, die von den einzelnen Load-Balancern unterstützt werden, finden Sie unter Protokolle vom Load-Balancer zum Back-End.

  • Der Balancing-Modus für das Back-End muss RATE für externes und internes HTTP(S)-Load-Balancing und CONNECTION für TCP/SSL-Proxy-Load-Balancing sein. Weitere Informationen zu Balancing-Modi finden Sie unter Übersicht über Back-End-Dienste.

  • Aktualisieren Sie die Back-Ends, die mit Ihrem Back-End-Dienst verknüpft sind, um weitere Netzwerkendpunkte hinzuzufügen.

Systemdiagnosen

Jeder Back-End-Dienst muss mit einer Systemdiagnose verknüpft sein, die den Status der Back-Ends prüft. Damit die Systemdiagnosetests korrekt ausgeführt werden können, müssen Sie Firewallregeln erstellen, die Traffic aus den Prüfungs-IP-Bereichen von Google (130.211.0.0/22 und 35.191.0.0/16) zu Ihren Endpunkten zulassen.

Erstellen Sie für Back-Ends außerhalb von Google Cloud Firewallregeln in Ihren lokalen und anderen Cloud-Netzwerken. Wenden Sie sich dazu an Ihren Netzwerkadministrator. Der für die Hybridkonnektivität verwendete Cloud Router muss auch die Bereiche anbieten, die von den Systemdiagnoseprüfungen von Google verwendet werden. Die anzubietenden Bereiche sind 35.191.0.0/16 und 130.211.0.0/22.

Erstellen Sie für Back-Ends in Google Cloud Firewallregeln in Google Cloud, wie in diesem Beispiel gezeigt.

Beschränkungen

  • Hybridkonnektivitäts-NEGs werden in der Google Cloud Console nicht unterstützt. Zum Erstellen, Löschen oder Verwalten von NEGs mit Hybridkonnektivität müssen Sie die Google Cloud-Befehlszeile oder die REST API verwenden.
  • Der für die Hybridkonnektivität verwendete Cloud Router muss mit globalem dynamischem Routing aktiviert werden. Regionales dynamisches Routing und statische Routen werden nicht unterstützt.
  • Das interne HTTP(S)-Load-Balancing und Hybridkonnektivität müssen in derselben Region konfiguriert werden. Wenn sie in verschiedenen Regionen konfiguriert sind, werden Back-Ends möglicherweise als fehlerfrei angezeigt, aber Anfragen von Clients werden nicht an das Back-End weitergeleitet.

  • Die hier dokumentierten Überlegungen zu verschlüsselten Verbindungen vom Load-Balancer zu den Back-Ends gelten auch für Back-End-Endpunkte außerhalb von Google Cloud, die in der Hybridkonnektivitäts-NEG konfiguriert sind.

    Überprüfen Sie auch die Sicherheitseinstellungen in der Hybrid-Konnektivitätskonfiguration. Derzeit werden HA Cloud VPN-Verbindungen standardmäßig verschlüsselt (IPSec). Cloud Interconnect-Verbindungen werden nicht standardmäßig verschlüsselt. Weitere Informationen finden Sie im Whitepaper Verschlüsselung bei der Übertragung in Google Cloud.

Logging

An einen Endpunkt in einer Hybrid-NEG weitergeleitete Anfragen werden in Cloud Logging auf dieselbe Weise protokolliert wie Anfragen an andere HTTP(S)-Load-Balancing-Back-Ends. Weitere Informationen finden Sie unter Logging und Monitoring für das HTTP(S)-Load-Balancing.

Wenn Sie Cloud CDN für Ihren Load-Balancer aktivieren, werden Cache-Treffer ebenfalls protokolliert.

Kontingent

Sie können so viele Hybrid-NEGs mit Netzwerkendpunkten konfigurieren, wie es Ihr Kontingent für Netzwerk-Endpunktgruppen zulässt. Weitere Informationen finden Sie unter NEG-Back-Ends und Endpunkte pro NEG.

Nächste Schritte