Übersicht über Cloud Load Balancing

Ein Load-Balancer verteilt den Nutzertraffic auf mehrere Instanzen Ihrer Anwendungen. Durch die Verteilung der Last lässt sich mit Load-Balancing das Risiko verringern, dass Ihre Anwendungen Leistungsprobleme verursachen.

Einfache Übersicht über das Load-Balancing (zum Vergrößern klicken)
Einfache Übersicht über das Load-Balancing (zum Vergrößern klicken)

Informationen zum Cloud Load Balancing

Mit Cloud Load Balancing können Sie Inhalte auf einem System bereitstellen, das sich so nah wie möglich bei Ihren Nutzern befindet und auf über eine Million Abfragen pro Sekunde antworten kann.

Cloud Load Balancing ist ein vollständig verteilter, softwarebasierter verwalteter Dienst. Da er nicht hardwarebasiert ist, benötigen Sie keine Infrastruktur für physisches Load-Balancing.

Google Cloud bietet die folgenden Load-Balancing-Features:

  • Einzelne IP-Adresse, die als Front-End dient
  • Automatisches intelligentes Autoscaling Ihrer Back-Ends
  • Externes Load-Balancing, wenn Nutzer über das Internet auf Ihre Anwendungen zugreifen
  • Internes Load-Balancing, wenn sich Ihre Clients in Google Cloud befinden
  • Regionales Load-Balancing, wenn Ihre Anwendungen in einer einzelnen Region verfügbar sind
  • Globales Load-Balancing, wenn Ihre Anwendungen weltweit verfügbar sind
  • Pass-Through-Load-Balancing (siehe auch Direct Server Return (DSR) oder direktes Routing)
  • Proxy-basiertes Load-Balancing (als Alternative zu Pass-Through)
  • Layer-4-basiertes Load-Balancing zum Weiterleiten von Traffic basierend auf Daten aus Netzwerk- und Transportschichtprotokollen wie TCP, UDP, ESP oder ICMP
  • Layer-7-basiertes Load-Balancing zum Hinzufügen von Entscheidungen über das Anfragerouting basierend auf Attributen wie HTTP-Header und Uniform Resource Identifier
  • Integration mit Cloud CDN für die Inhaltsübermittlung aus dem Cache

Eine ausführlichere Liste der Features finden Sie unter Load-Balancer-Features.

Cloud Load Balancing-Typen

In der folgenden Tabelle sind die Merkmale der einzelnen Google Cloud Load-Balancer zusammengefasst. Dazu gehören unter anderem die Angaben, ob ein Load-Balancer eine interne oder externe IP-Adresse verwendet, ob der Load-Balancer regional oder global ist, sowie Informationen zu den unterstützten Netzwerkdienststufen und Traffictypen.

Intern oder extern Regional oder global Unterstützte Netzwerkstufen Proxy oder Pass-Through Traffictyp Load-Balancer-Typ
Intern Regional Nur Premium Pass-Through TCP oder UDP Internes TCP/UDP
Regional Nur Premium Proxy HTTP oder HTTPS Internes HTTP(S)
Extern Regional Premium oder Standard Passthrough TCP, UDP, ESP oder ICMP (Vorschau) Externes TCP/UDP-Netzwerk
Global in der Premium-Stufe

Praktisch regional1 in der Standard-Stufe
Premium oder Standard Proxy TCP TCP-Proxy
Premium oder Standard Proxy SSL SSL-Proxy
Premium oder Standard Proxy HTTP oder HTTPS Externes HTTP(S)
1Praktisch regional bedeutet, dass bei Auswahl der Standardstufe der Back-End-Dienst zwar global ist, die externe Weiterleitungsregel und die externe IP-Adresse jedoch regional sein müssen. Außerdem müssen sich die an den globalen Back-End-Dienst angehängten Back-End-Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs) in derselben Region wie die Weiterleitungsregel und die IP-Adresse befinden. Weitere Informationen finden Sie unter Standardstufe für HTTP(S)-Load-Balancing, TCP-Proxy-Load-Balancing und SSL-Proxy-Load-Balancing konfigurieren.

Globales oder regionales Load-Balancing

Verwenden Sie globales Load-Balancing, wenn Ihre Back-Ends über mehrere Regionen verteilt sind, Ihre Nutzer Zugriff auf dieselben Anwendungen und Inhalte benötigen und wenn Sie Zugriff über eine einzige Anycast-IP-Adresse gewähren möchten. Globales Load-Balancing kann auch eine IPv6-Beendigung bieten.

Verwenden Sie regionales Load-Balancing, wenn sich Ihre Back-Ends in einer einzigen Region befinden und lediglich eine IPv4-Beendigung benötigt wird.

Ausfallsicherheit des Load-Balancers

Load-Balancer sind ein sehr wichtiger Bestandteil der meisten hochverfügbaren Anwendungen. Google Cloud bietet sowohl regionale als auch globale Load-Balancer. In beiden Fällen ist es wichtig zu verstehen, dass die Ausfallsicherheit der gesamten Anwendung nicht nur vom gewählten Load-Balancer, sondern auch von der Redundanz Ihrer Back-End-Dienste abhängt.

In der folgenden Tabelle wird die Ausfallsicherheit des Load-Balancers basierend auf der Verteilung oder dem Bereich des Load-Balancers zusammengefasst.

Load-Balancer-Bereich Architektur Stabil bei zonalem Ausfall Stabil bei regionalem Ausfall
Global Jeder Load-Balancer ist auf alle Regionen verteilt.
Regional Jeder Load-Balancer ist auf mehrere Zonen in der Region verteilt. Ein Ausfall in einer bestimmten Region wirkt sich auf die regionalen Load-Balancer in dieser Region aus.

Externes oder internes Load-Balancing

Die Load-Balancer von Google Cloud lassen sich in externe und interne Load-Balancer unterteilen:

  • Externe Load-Balancer verteilen den aus dem Internet kommenden Traffic auf Ihr Google Cloud-VPC-Netzwerk (Virtual Private Cloud). Für globales Load-Balancing ist die Premium-Stufe der Netzwerkdienststufen erforderlich. Für regionales Load-Balancing können Sie die Standardstufe verwenden.

  • Interne Load-Balancer verteilen den Traffic auf Instanzen innerhalb von Google Cloud.

Externe und interne Load-Balancing-Typen (zum Vergrößern klicken)
Externe und interne Load-Balancing-Typen (zum Vergrößern klicken)

Das folgende Diagramm veranschaulicht anhand eines gängigen Anwendungsfalls, wie das externe und interne Load-Balancing zusammen verwendet werden. In der Abbildung ist der Traffic so verteilt:

  1. Traffic von Nutzern in San Francisco, Iowa und Singapur wird an einen externen Load-Balancer (1.1.1.1) weitergeleitet.
  2. Der externe Load-Balancer verteilt diesen Traffic auf verschiedene Regionen in einem Google Cloud-Netzwerk.
  3. Nachdem sich der Traffic innerhalb von Google Cloud befindet, verteilen zwei interne Load-Balancer (10.10.10.10) und (10.20.1.1) den Traffic innerhalb ihrer jeweiligen Regionen: us-central1 und asia-east1.
  4. Innerhalb von us-central1 verteilt der interne Load-Balancer 10.10.10.10 den Traffic auf zwei Zonen: us-central1-a und us-central1-b.
  5. Innerhalb von asia-east1 verteilt der interne Load-Balancer 10.20.1.1 den Traffic innerhalb einer Zone: asia-east1-a.
Zusammenarbeit von externem und internem Load-Balancing (zum Vergrößern klicken)
Zusammenarbeit von externem und internem Load-Balancing (zum Vergrößern klicken)

Traffictyp

Auch die Art von Traffic, die der Load-Balancer verarbeiten muss, spielt bei der Auswahl des zu verwendenden Load-Balancers eine Rolle.

  • Für HTTP- und HTTPS-Traffic können Sie Folgendes verwenden:
    • Externes HTTP(S)-Load-Balancing
    • Internes HTTP(S)-Load-Balancing
  • Für TCP-Traffic können Sie Folgendes verwenden:
    • TCP-Proxy-Load-Balancing
    • Netzwerk-Load-Balancing
    • Internes TCP/UDP-Load-Balancing
  • Für UDP-Traffic können Sie Folgendes verwenden:
    • Netzwerk-Load-Balancing
    • Internes TCP/UDP-Load-Balancing
  • Für ESP- oder ICMP-Traffic können Sie Folgendes verwenden:

Back-End-Region und Netzwerk

In der folgenden Tabelle ist die Unterstützung für Back-Ends in verschiedenen VPC-Netzwerken zusammengefasst. Die Tabelle enthält auch Informationen zur Unterstützung von Multi-NIC-Load-Balancing.

Load-Balancer-Typ Back-End-Region und Netzwerk Hinweise zu Multi-NIC
Internes TCP/UDP-Load-Balancing Alle Back-Ends müssen sich in demselben VPC-Netzwerk und derselben Region wie der Back-End-Dienst befinden. Der Back-End-Dienst muss sich außerdem in derselben Region und demselben VPC-Netzwerk befinden wie die Weiterleitungsregel. Wenn Sie mehrere Load-Balancer verwenden, können die Lasten gleichmäßig auf mehrere NICs im selben Back-End verteilt werden.
Internes HTTP(S)-Load-Balancing Alle Back-Ends müssen sich in demselben VPC-Netzwerk und derselben Region wie der Back-End-Dienst befinden. Der Back-End-Dienst muss sich außerdem in derselben Region und demselben VPC-Netzwerk befinden wie die Weiterleitungsregel. Die Back-End-VM nic0 muss sich im selben Netzwerk und in derselben Region befinden wie die Weiterleitungsregel.
HTTP(S)-Load-Balancing, SSL-Proxy-Load-Balancing, TCP-Proxy-Load-Balancing Bei der Premium-Stufe: Back-Ends können sich in jeder Region und in jedem VPC-Netzwerk befinden.

In der Standard-Stufe: Back-Ends müssen sich in derselben Region wie die Weiterleitungsregel befinden, können sich aber in einem beliebigen VPC-Netzwerk befinden.
Der Load-Balancer sendet Traffic nur an die erste Netzwerkschnittstelle (nic0), je nachdem, in welchem VPC-Netzwerk sich nic0 befindet.

Firewallregeln

In der folgenden Tabelle sind die mindestens erforderlichen Firewallregeln für den Zugriff auf den Load-Balancer zusammengefasst.

Load-Balancer-Typ Mindestens erforderliche Firewallregeln zum Zulassen von eingehendem Traffic Übersicht Beispiel
Externes HTTP(S)-Load-Balancing
  • Bereiche der Systemdiagnose
Übersicht Beispiel
Internes HTTP(S)-Load-Balancing
  • Bereiche der Systemdiagnose
  • Nur-Proxy-Subnetz
Übersicht Beispiel
Internes TCP/UDP-Load-Balancing
  • Bereiche der Systemdiagnose
  • Interne Quell-IP-Adressen von Clients
Übersicht Beispiel
SSL-Proxy-Load-Balancing
  • Bereiche der Systemdiagnose
Übersicht Beispiel
TCP-Proxy-Load-Balancing
  • Bereiche der Systemdiagnose
Übersicht Beispiel
Netzwerk-Load-Balancing
  • Bereiche der Systemdiagnose
  • Externe Quell-IP-Adressen von Clients im Internet
    (z. B. 0.0.0.0/0 oder eine bestimmte Gruppe von Bereichen)
Übersicht Beispiel

DDoS-Schutzmaßnahmen für externe Load-Balancer

Google Cloud bietet je nach Load-Balancer-Typ verschiedene DDoS-Schutzmaßnahmen.

Proxy-basierte externe Load-Balancer

Alle Proxy-basierten externen Load-Balancer von Google Cloud übernehmen automatisch den DDoS-Schutz der Google Front Ends (GFEs), die Teil der Produktionsinfrastruktur von Google sind.

Zusätzlich zum automatischen DDoS-Schutz der GFEs können Sie für externe HTTP(S)-Load-Balancer Google Cloud Armor konfigurieren.

Externe Passthrough-Load-Balancer

Der einzige externe Passthrough-Load-Balancer ist der Netzwerk-Load-Balancer. Dieser wird mithilfe derselben Routinginfrastruktur von Google eingebunden, die zum Einbinden externer IP-Adressen für Compute Engine-VMs verwendet wird. Bei Traffic zu einem Netzwerk-Load-Balancer begrenzt Google Cloud die eingehenden Pakete pro VM.

Weitere Informationen finden Sie unter Eingehender Traffic zu externen IP-Adresszielen.

Die zugrunde liegende Technologie von Google Cloud Load Balancing

In diesem Abschnitt finden Sie weitere Informationen zu den einzelnen Typen der Google Cloud-Load-Balancer, einschließlich Links zur Übersichtsdokumentation für ein tieferes Verständnis.

Externe und interne Load-Balancing-Typen und die zugrunde liegende Technologie (zum Vergrößern klicken)
Externe und interne Load-Balancing-Typen und die zugrunde liegende Technologie (zum Vergrößern klicken)
  • Google Front Ends (GFEs) sind softwarebasierte, verteilte Systeme, die sich an Google-PoPs (Points of Presence) befinden und globales Load-Balancing in Verbindung mit anderen Systemen und Steuerungsebenen ausführen.
  • Andromeda ist der softwarebasierte Netzwerkvirtualisierungs-Stack von Google Cloud.
  • Maglev ist ein verteiltes System für das Netzwerk-Load-Balancing.
  • Envoy Proxy ist ein Open-Source-Edge- und -Dienstproxy, der für cloudnative Anwendungen entwickelt wurde.

Internes HTTP(S)-Load-Balancing

Das interne HTTP(S)-Load-Balancing baut auf dem Andromeda-Netzwerkvirtualisierungs-Stack auf und ist ein verwalteter Dienst, der auf dem Open Source-Envoy-Proxy basiert. Dieser Load-Balancer bietet Proxy-basiertes Load-Balancing für Layer-7-Anwendungsdaten. Mit URL-Maps legen Sie fest, wie der Traffic weitergeleitet wird. Der Load-Balancer verwendet eine interne IP-Adresse, die als Front-End für Ihre Back-Ends fungiert.

Externes HTTP(S)-Load-Balancing

HTTP(S)-Load-Balancing ist in GFEs implementiert. GFEs sind global verteilt und arbeiten über das globale Netzwerk und die Steuerungsebene von Google zusammen. Auf der Premium-Stufe bieten GFEs multiregionales Load-Balancing, bei dem Traffic an das nächstgelegene fehlerfreie Back-End mit Kapazität weitergeleitet und HTTP(S)-Traffic so nahe wie möglich bei den Nutzern beendet wird.

Internes TCP/UDP-Load-Balancing

Das interne TCP/UDP-Load-Balancing basiert auf dem Andromeda-Netzwerkvirtualisierungs-Stack. Mit internem TCP/UDP-Load-Balancing können Sie TCP/UDP-Traffic hinter einer internen Load-Balancing-IP-Adresse, die nur für Ihre internen VM-Instanzen zugänglich ist, gleichmäßig verteilen. Beim internen TCP/UDP-Load-Balancing wird eine interne IP-Adresse für das Load-Balancing konfiguriert, die als Front-End für Ihre internen Back-End-Instanzen fungiert. Für Ihren Dienst mit Load-Balancing verwenden Sie nur interne IP-Adressen. So wird Ihre Konfiguration einfacher.

Das interne TCP/UDP-Load-Balancing unterstützt regionale verwaltete Instanzgruppen, sodass Sie Ihren Dienst durch Autoscaling für eine ganze Region vor zonalen Ausfällen schützen können.

Externes TCP/UDP-Netzwerk-Load-Balancing

Netzwerk-Load-Balancing basiert auf MagleV. Mit diesem Load-Balancer können Sie Traffic auf Ihren Systemen anhand von eingehenden IP-Protokolldaten wie Adresse, Protokoll und Port ausgleichen (optional). Dieses regionale Load-Balancing-System kommt ohne Proxy aus. Das bedeutet, dass ein Netzwerk-Load-Balancer ein Pass-Through-Load-Balancer ist, der keine Proxy-Verbindungen von Clients herstellt.

Back-End-Dienst-basierte Netzwerk-Load-Balancer unterstützen TCP-, UDP-, ESP- und ICMP-Traffic.

Zielpoolbasierte Netzwerk-Load-Balancer unterstützen nur TCP- oder UDP-Traffic.

SSL-Proxy-Load-Balancing

Das SSL-Proxy-Load-Balancing ist auf global verteilten GFEs implementiert. Wenn Sie sich für die Premium-Stufe der Netzwerkdienststufen entscheiden, ist ein SSL-Proxy-Load-Balancer global. Mit der Premium-Stufe können Back-Ends in mehreren Regionen bereitgestellt werden. Der Load-Balancer leitet dann Nutzertraffic automatisch an die nächstgelegene Region mit Kapazität weiter. Wenn Sie sich für die Standard-Stufe entscheiden, kann ein SSL-Proxy-Load-Balancer Traffic nur zwischen Back-Ends in einer einzelnen Region weiterleiten.

TCP-Proxy-Load-Balancing

Das TCP-Proxy-Load-Balancing ist auf global verteilten GFEs implementiert. Wenn Sie sich für die Premium-Stufe der Netzwerkdienststufen entscheiden, ist ein TCP-Proxy-Load-Balancer global. Mit der Premium-Stufe können Back-Ends in mehreren Regionen bereitgestellt werden. Der Load-Balancer leitet dann Nutzertraffic automatisch an die nächstgelegene Region mit Kapazität weiter. Wenn Sie sich für die Standard-Stufe entscheiden, kann ein TCP-Proxy-Load-Balancer Traffic nur zwischen Back-Ends in einer einzelnen Region weiterleiten.

Interfaces

Sie können Ihre Load-Balancer über die folgenden Oberflächen konfigurieren und aktualisieren:

  • Das gcloud-Befehlszeilentool: Ein Befehlszeilentool, das im Cloud SDK enthalten ist. Im Rahmen der Dokumentation zum HTTP(S)-Load-Balancing wird dieses Tool häufig zum Ausführen von Aufgaben benötigt. Eine vollständige Übersicht über das Tool finden Sie im Leitfaden zum gcloud-Tool. Befehle für das Load-Balancing finden Sie in der Befehlsgruppe gcloud compute.

    Ausführliche Hilfe zu jedem gcloud-Befehl erhalten Sie auch mit dem Flag --help:

    gcloud compute http-health-checks create --help
    
  • Die Google Cloud Console: Load-Balancing-Aufgaben können über die Cloud Console ausgeführt werden.

  • Die REST API: Alle Load-Balancing-Aufgaben können mit der Cloud Load Balancing API ausgeführt werden. In der API-Referenzdokumentation werden die verfügbaren Ressourcen und Methoden beschrieben.

Nächste Schritte

  • Informationen darüber, welcher Google Cloud-Load-Balancer Ihren Anforderungen am besten entspricht, finden Sie unter Load-Balancer auswählen.