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. Cloud Load Balancing von Google basiert auf zuverlässigen, leistungsstarken Technologien wie Maglev, Andromeda, Google Front Ends und Envoy – denselben Technologien, die auch für die eigenen Produkte von Google verwendet werden.
Cloud Load Balancing bietet ein umfassendes Portfolio an Anwendungs- und Netzwerk-Load-Balancern. Mit unseren globalen Proxy-Load-Balancern können Sie Millionen von Anfragen pro Sekunde zwischen Back-Ends in mehreren Regionen mit unserer Google Front End-Flotte an über 80 verschiedenen Standorten weltweit verteilen – alles mit einer einzigen Anycast-IP-Adresse. Mit unseren regionalen Proxy-Load-Balancern können Sie strenge rechtliche Kontrollen implementieren und Ihre Back-Ends und Proxys in einer Region Ihrer Wahl im Blick behalten, ohne sich um TLS/SSL-Auslagerungen kümmern zu müssen. Verwenden Sie unsere Passthrough-Load-Balancer, um mehrere Protokolle schnell an Back-Ends mit der hohen Leistung von Direct Server Return weiterzuleiten.
Wichtige Funktionen von Cloud Load Balancing
Cloud Load Balancing bietet die folgenden Load Balancing-Features:
Einzelne Anycast-IP-Adresse. Mit Cloud Load Balancing ist eine einzige Anycast-IP-Adresse das Frontend für alle Ihre Backend-Instanzen in verschiedenen Regionen der Welt. Sie profitieren von einem regionenübergreifenden Load-Balancing, einschließlich automatischen Failovers auf mehrere Regionen. Dabei wird der Traffic zu Failover-Back-Ends verschoben, wenn Ihre primären Back-Ends fehlerhaft werden. Cloud Load Balancing reagiert sofort auf Änderungen hinsichtlich Nutzern, Traffic, Netzwerk, Backend-Zustand und anderen damit verbundenen Bedingungen.
Nahtloses Autoscaling. Mit Cloud Load Balancing wird einfach dem Nutzer- und Trafficaufkommen entsprechend skaliert. Dies gilt auch für die Verarbeitung unerwarteter und plötzlich auftretender starker Spitzen. Der Traffic wird dabei weltweit auf andere Regionen mit verfügbaren Kapazitäten umgeleitet. Autoscaling erfordert keine Vorbereitung. Sie können innerhalb von Sekunden von null auf vollen Traffic skalieren.
Softwarebasiertes Load-Balancing. Cloud Load Balancing ist ein vollständig verteilter, softwarebasierter verwalteter Dienst für Ihren gesamten Traffic. Da Cloud Load Balancing nicht auf Instanzen oder Geräten beruht, sind Sie an keine physische Load-Balancing-Infrastruktur gebunden. Auch die Herausforderungen hinsichtlich Hochverfügbarkeit, Skalierung und Verwaltung, wie sie bei instanzbasierten Load-Balancern auftreten, entfallen.
Layer-4- und Layer-7-Load-Balancing. Verwenden Sie das Layer-4-basierte Load-Balancing, um Traffic anhand von Daten aus Netzwerk- und Transportschichtprotokollen wie TCP, UDP, ESP, GRE, ICMP und ICMPv6 weiterzuleiten. Verwenden Sie Layer-7-basiertes Load-Balancing zum Hinzufügen von Entscheidungen über das Anfragerouting basierend auf Attributen wie HTTP-Header und Uniform Resource Identifier.
Externes und internes Load-Balancing Definiert, ob der Load Balancer für externen oder internen Zugriff verwendet werden kann. Ein externer Load Balancer akzeptiert Traffic aus dem Internet, während ein interner Load Balancer nur RFC 1918-Traffic akzeptiert. Sie können externes Load Balancing verwenden, wenn Ihre Nutzer über das Internet auf Ihre Anwendungen zugreifen. Sie können internes Load Balancing verwenden, wenn sich Ihre Clients in Google Cloud befinden. Weitere Informationen finden Sie unter Externes und internes Load Balancing im Vergleich.
Globales und regionales Load-Balancing Definiert den Geltungsbereich des Load Balancers. Ein globaler Load Balancer unterstützt Back-Ends in mehreren Regionen, während ein regionaler Load Balancer Back-Ends in einer einzelnen Region unterstützt. Auch wenn sich die IP-Adresse eines regionalen Load Balancers in einer Region befindet, ist er weltweit zugänglich. Sie können Ihre Backends auf eine oder mehrere Regionen verteilen, um Verbindungen in der Nähe Ihrer Nutzer zu beenden und Ihre Anforderungen an die Hochverfügbarkeit zu erfüllen. Weitere Informationen finden Sie unter Globales oder regionales Load Balancing.
Routing von Traffic in der Premium-Stufe- und der Standardstufe Die Load Balancing-Dienste in Google Cloud sind je nach ausgewählter Netzwerkebene (Premium-Stufe- oder Standardebene) unterschiedlich. Erstere sind teurer als letztere. Bei der Premium-Stufe wird das hochwertige globale Backbone von Google genutzt, während bei der Standardstufe das öffentliche Internet verwendet wird, um Traffic über das Netzwerk zu leiten. Die von Ihnen gewählte Netzwerkebene hängt davon ab, ob Sie bei Ihrer Unternehmensarbeitslast Kosten oder Leistung priorisieren. Einige Load Balancing-Dienste sind nur in der Premium-Stufe und nicht in der Standardstufe verfügbar. Weitere Informationen finden Sie unter Premium- oder Standard-Netzwerkdienststufe.
Unterstützung erweiterter Features. Cloud Load Balancing unterstützt Features wie das IPv6-Load-Balancing, Quell-IP-basierte Traffic-Steuerung, gewichtetes Load-Balancing, WebSockets, benutzerdefinierte Anfrage-Header und Protokollweiterleitung für private virtuelle IP-Adressen (VIPs).
Es enthält auch die folgenden Integrationen:
- Integration in Cloud CDN für die Inhaltsübermittlung aus dem Cache. Cloud CDN wird mit dem globalen externen Application Load Balancer und dem klassischen Application Load Balancer unterstützt.
- Integration in Google Cloud Armor zum Schutz Ihrer Infrastruktur vor DDoS-Angriffen (Distributed Denial of Service) und anderen gezielten Anwendungsangriffen. Immer aktiver On-DDoS-Schutz ist für den globalen externen Application Load Balancer, den klassischen Application Load Balancer, den externen Proxy-Network-Load-Balancer und den externen Passthrough-Network-Load-Balancer verfügbar. Darüber hinaus unterstützt Google Cloud Armor den erweiterten DDoS-Netzwerkschutz nur für externe Passthrough-Network-Load-Balancer. Weitere Informationen finden Sie unter Erweiterten DDoS-Netzwerkschutz konfigurieren.
Arten von Google Cloud-Load Balancern
Cloud Load Balancing bietet zwei Arten von Load-Balancern: Application Load Balancer und Network Load Balancer. Wählen Sie einen Application Load Balancer aus, wenn Sie einen Layer-7-Load-Balancer für Ihre Anwendungen mit HTTP(S)-Traffic benötigen. Wählen Sie einen Network Load Balancer aus, wenn Sie einen Layer-4-Load-Balancer benötigen, der TLS-Auslagerung (mit einem Proxy-Load-Balancer) unterstützt, oder wenn Sie Unterstützung für IP-Protokolle wie UDP, ESP und ICMP (mit einem Passthrough-Load-Balancer) benötigen.
Die folgende Tabelle bietet einen allgemeinen Überblick über die verschiedenen Arten von Google Cloud Load Balancern, kategorisiert nach der OSI-Schicht, in der sie ausgeführt werden, und danach, ob sie für externen oder internen Zugriff verwendet werden.
| lan Cloud Load Balancing | Extern (Internet-Traffic wird akzeptiert) |
Intern (nur RFC 1918-Traffic akzeptiert) |
|---|---|---|
|
Application Load Balancer HTTPS Layer-7-Load Balancing |
|
|
|
Network Load Balancer TCP/SSL/Sonstiges Layer-4-Load Balancing |
||
| Proxy-Network-Load-Balancer | ||
|
|
|
| Passthrough-Network-Load-Balancer | ||
|
|
|
Application Load Balancer
Application Load Balancer sind proxybasierte Layer-7-Load-Balancer, mit denen Sie Ihre Services hinter einer Anycast-IP-Adresse ausführen und skalieren können. Der Application Load Balancer verteilt HTTP- und HTTPS-Traffic auf Back-Ends, die auf einer Vielzahl von Google Cloud-Plattformen wie Compute Engine und Google Kubernetes Engine (GKE) gehostet werden, sowie auf externe Back-Ends außerhalb von Google Cloud.
Das folgende Diagramm bietet eine allgemeine Übersicht über die verschiedenen Arten von Application Load Balancern, die extern oder intern bereitgestellt werden können, je nachdem, ob Ihre Anwendung mit dem Internet oder intern verbunden ist.
Externe Application Load Balancer sind als verwaltete Dienste implementiert, entweder auf Google Front Ends (GFEs) oder auf Envoy-Proxys. Clients können von überall im Internet aus eine Verbindung zu diesen Load Balancern herstellen. Bitte beachten Sie dabei Folgendes:
- Diese Load Balancer können in den folgenden Modi bereitgestellt werden: global, regional oder klassisch.
- Globale externe Application Load Balancer unterstützen Backends in mehreren Regionen.
- Regionale externe Application Load Balancer unterstützen nur Backends in einer einzelnen Region.
- Klassische Application Load Balancer sind in der Premium-Stufe global. In der Standardstufe können sie Traffic nur an Back-Ends in einer einzelnen Region verteilen.
- Application Load Balancer verwenden den Open-Source-Envoy-Proxy, um erweiterte Funktionen zur Trafficverwaltung zu aktivieren.
Interne Application Load Balancer basieren auf dem Andromeda-Stack zur Netzwerkvirtualisierung und dem Open-Source-Envoy-Proxy. Dieser Load-Balancer bietet internes Proxy-basiertes Load-Balancing für Layer-7-Anwendungsdaten. Der Load Balancer verwendet eine interne IP-Adresse, auf die nur Clients im selben VPC-Netzwerk oder Clients, die mit Ihrem VPC-Netzwerk verbunden sind, zugreifen können. Wichtige Hinweise:
- Diese Load Balancer können in den folgenden Modi bereitgestellt werden: regional oder regionenübergreifend.
- Regionale interne Application Load Balancer unterstützen nur Back-Ends in einer einzelnen Region.
- Regionenübergreifende interne Application Load Balancer (Vorschau) unterstützen Backends in mehreren Regionen und sind immer global zugänglich. Clients aus jeder Google Cloud-Region können Traffic an den Load Balancer senden.
Weitere Informationen zu Application Load Balancern finden Sie unter Application Load Balancer.
Network Load Balancer
Network Load Balancer sind Layer-4-Load-Balancer, die TCP-, UDP- oder anderen IP-Protokoll-Traffic verarbeiten können. Diese Load-Balancer sind entweder als Proxy-Load-Balancer oder als Passthrough-Load-Balancer verfügbar. Sie können einen Load-Balancer abhängig von den Anforderungen Ihrer Anwendung und der Art des zu verarbeitenden Traffics auswählen. Wählen Sie einen Proxy-Network-Load-Balancer aus, wenn Sie einen Reverse-Proxy-Load-Balancer mit Unterstützung für erweiterte Trafficsteuerungen und Back-Ends lokal und in anderen Cloud-Umgebungen konfigurieren möchten. Wählen Sie einen Passthrough-Network Load Balancer aus, wenn Sie die Quell-IP-Adresse der Clientpakete beibehalten möchten, die direkte Serverrückgabe für Antworten bevorzugen oder eine Vielzahl von IP-Protokollen wie TCP, UDP, ESP, GRE, ICMP und ICMPv6 verarbeiten möchten.
Proxy-Network-Load-Balancer
Proxy-Network-Load-Balancer sind Layer-4-Reverse-Proxy-Load-Balancer, die TCP-Traffic auf VM-Instanzen (virtuelle Maschine) in Ihrem Google Cloud-VPC-Netzwerk verteilen. Der Traffic wird auf der Load Balancing-Ebene beendet und dann über TCP an das nächstgelegene verfügbare Backend weitergeleitet.
Das folgende Diagramm bietet eine allgemeine Übersicht über die verschiedenen Arten von Proxy-Netzwerk-Load Balancern, die extern oder intern bereitgestellt werden können, je nachdem, ob Ihre Anwendung mit dem Internet oder intern verbunden ist.
Externe Proxy-Network-Load-Balancer sind Layer-4-Load-Balancer, die Traffic aus dem Internet auf Back-Ends in Ihrem Google Cloud-VPC-Netzwerk, lokal oder in anderen Cloud-Umgebungen verteilen. Diese Load Balancer basieren entweder auf Google Front Ends (GFEs) oder auf Envoy-Proxys.
Diese Load Balancer können in den folgenden Modi bereitgestellt werden: global, regional oder klassisch.
- Globale externe Proxy-Network-Load-Balancer unterstützen Back-Ends in mehreren Regionen.
- Regionale externe Proxy-Network-Load-Balancer unterstützen Back-Ends in einer einzelnen Region.
- Klassische Proxy-Network Load Balancer sind in der Premium-Stufe global. In der Standardstufe können sie Traffic nur an Back-Ends in einer einzelnen Region verteilen.
Interne Proxy-Network-Load-Balancer sind Envoy-Proxy-basierte regionale Layer-4-Load-Balancer, mit denen Sie Ihren TCP-Diensttraffic hinter einer internen IP-Adresse, auf die nur Clients im selben VPC-Netzwerk oder Clients, die mit Ihrem VPC-Netzwerk verbunden sind, Zugriff haben, ausführen und skalieren können.
Diese Load Balancer können in einem der folgenden Modi bereitgestellt werden: regional oder regionenübergreifend.
- Regionale interne Proxy-Network-Load-Balancer unterstützen nur Back-Ends in einer einzelnen Region.
- Regionenübergreifende interne Proxy-Network Load Balancer (Vorschau) unterstützen Back-Ends in mehreren Regionen und sind immer global zugänglich. Clients aus jeder Google Cloud-Region können Traffic an den Load Balancer senden.
Weitere Informationen zu Proxy-Network Load Balancern finden Sie unter Proxy-Network Load Balancer.
Passthrough-Network-Load-Balancer
Passthrough-Network-Load-Balancer sind regionale Layer-4-Passthrough-Load-Balancer. Diese Load-Balancer verteilen den Traffic zwischen Back-Ends in derselben Region wie der Load-Balancer. Sie werden mithilfe von Andromeda Virtual Networking und Google Maglev implementiert.
Wie der Name verrät, sind diese Load Balancer keine Proxys. Pakete mit Load-Balancing werden von Backend-VMs mit den Quell- und Ziel-IP-Adressen des Pakets, dem Protokoll und den unveränderten Quell- und Zielports angezeigt, wenn das Protokoll portbasiert ist. Verbindungen mit Load Balancing werden bei den Backends beendet. Antworten von den Backend-VMs werden direkt an die Clients gesendet, nicht über den Load-Balancer. Der Branchenbegriff hierfür ist direkte Serverrückgabe (DSR).
Diese Load Balancer werden, wie in der folgenden Abbildung dargestellt, in zwei Modi bereitgestellt, je nachdem, ob der Load Balancer mit dem Internet oder intern verbunden ist.
Externe Passthrough-Network-Load-Balancer basieren auf Maglev. Clients können unabhängig von ihren Netzwerkdienststufen von überall im Internet aus eine Verbindung zu diesen Load Balancern herstellen. Der Load-Balancer kann auch Traffic von Google Cloud-VMs mit externen IP-Adressen oder von Google Cloud-VMs empfangen, die über Cloud NAT oder instanzbasiertes NAT Internetzugriff haben.
Backends für externe Passthrough-Network Load Balancer können entweder mit einem Backend-Dienst oder mit einem Zielpool bereitgestellt werden. Für neue Bereitstellungen empfehlen wir die Verwendung von Backend-Diensten.
Interne Passthrough-Network-Load-Balancer basieren auf dem Andromeda-Stack zur Netzwerkvirtualisierung. Mit einem internen Passthrough-Network-Load-Balancer können Sie TCP/UDP-Traffic hinter einer internen Load-Balancing-IP-Adresse, die nur für Systeme im selben VPC-Netzwerk oder für Systeme, die mit Ihrem VPC-Netzwerk verbunden sind, gleichmäßig verteilen. Außerdem kann dieser Load-Balancer nur in der Premiumstufe konfiguriert werden.
Weitere Informationen zu Passthrough-Network Load Balancern finden Sie unter Passthrough-Network Load Balancer.
Komponenten des Lastenausgleichsmoduls
Ein Load Balancer ist ein System aus mehreren interagierenden Komponenten. Es gibt keine einzelne API-Ressource, die einen Load Balancer darstellt. Stattdessen arbeiten mehrere Komponenten zusammen, um den eingehenden Traffic auf mehrere Backends zu verteilen.
Das folgende Diagramm zeigt die Hauptkomponenten eines Application Load Balancers, eines Proxy-Network Load Balancers und eines Passthrough-Network Load Balancers.
Application Load Balancer
Proxy-Network Load Balancer
Passthrough-Network Load Balancer
Die folgenden Informationen bieten einen allgemeinen Überblick über die wichtigsten Komponenten eines Load Balancers, beginnend mit dem Punkt, an dem der Traffic den Load Balancer erreicht, bis hin zur Phase, in der er an die Backend-Ressource weitergeleitet wird. Weitere Informationen zu den einzelnen Load Balancer-Komponenten finden Sie auf den verlinkten Seiten.
Weiterleitungsregel
Eine Weiterleitungsregel gibt eine IP-Adresse, ein IP-Protokoll und einen oder mehrere Ports an, an denen der Load Balancer Traffic annimmt. Die Weiterleitungsregel und die zugehörige IP-Adresse stellen das Frontend eines Google Cloud-Load Balancers dar.
Weitere Informationen finden Sie unter Weiterleitungsregeln.
Zielproxy
Zielproxys beenden eingehende Verbindungen von Clients und erstellen neue Verbindungen vom Load Balancer zu den Back-Ends.
Die erste Verbindung stammt vom Client und wird am Zielproxy des Load Balancers beendet.
Die zweite Verbindung beginnt beim Zielproxy und endet an der Backend-Instanz, die die Clientanfrage verarbeitet.
Die erste Verbindung wird entweder in einem Google Front End (GFE) oder in einem speziell dafür vorgesehenen Subnetz beendet, das als Nur-Proxy-Subnetz bezeichnet wird und ausschließlich für Envoy-Proxys reserviert ist. Ob ein Load Balancer auf der GFE oder auf Envoy basiert, sehen Sie in der Tabelle im Abschnitt Die zugrunde liegenden Technologien von Google Cloud Load Balancern dieses Dokuments.
Zielproxies werden nur von proxybasierten Load Balancern wie Application Load Balancern und Proxy-Network Load Balancern verwendet. Bei diesen Arten von Load Balancern werden Antworten von den Back-End-Instanzen an den Zielproxy zurückgesendet, nicht direkt an den Client.
Weitere Informationen finden Sie unter Zielproxys.
Nur-Proxy-Subnetz
Ein Nur-Proxy-Subnetz bietet einen Pool von IP-Adressen, die ausschließlich für Envoy-Proxys reserviert sind, die von Load-Balancern von Google Cloud verwendet werden. Die Proxys beenden eingehende Verbindungen und erstellen dann neue Verbindungen zum Backend.
Weitere Informationen finden Sie unter Nur-Proxy-Subnetze für Envoy-basierte Load Balancer.
SSL-Zertifikate
SSL-Zertifikate, auch als TLS-Zertifikate (Transport Layer Security) bezeichnet, ermöglichen eine sichere Kommunikation zwischen Clients und Load Balancern. Proxybasierte Load Balancer, deren Weiterleitungsregeln auf einen Ziel-HTTPS-Proxy oder Ziel-SSL-Proxy verweisen, benötigen einen privaten Schlüssel und ein SSL-Zertifikat als Teil der Zielproxy-Konfiguration des Load Balancers.
Weitere Informationen finden Sie unter SSL-Zertifikate.
URL-Zuordnung
Nach dem Beenden der Verbindung entscheidet der Ziel-HTTP(S)-Proxy anhand der URL-Zuordnung, wohin die neue Anfrage weitergeleitet werden soll (die zweite Verbindung, wie im Abschnitt Zielproxy angegeben). Die Anfrage wird entweder an den Back-End-Dienst oder an den Back-End-Bucket weitergeleitet. URL-Zuordnungen werden nur von Application Load Balancern verwendet. Da Application Load Balancer auf Ebene 7 des OSI-Modells ausgeführt werden, können sie Routingentscheidungen anhand von HTTP-Attributen wie Domainnamen, Anfragepfad und Abfrageparametern treffen.
Weitere Informationen finden Sie unter URL-Zuordnungen.
Backend-Dienst
Ein Back-End-Dienst definiert, wie der Load Balancer Traffic verteilt. Die Back-End-Dienstkonfiguration enthält eine Reihe von Werten, z. B. das Protokoll für die Verbindung mit Back-Ends, verschiedene Verteilungs- und Sitzungseinstellungen, Systemdiagnosen und Zeitüberschreitungen.
Mit diesen Einstellungen können Sie das Verhalten Ihres Load Balancers genau steuern und Traffic an die richtigen Back-Ends weiterleiten. Dies können entweder VM-Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs) sein.
Weitere Informationen finden Sie unter Übersicht über Back-End-Dienste.
Backend-Bucket
Wenn Ihre Arbeitslast statische Inhalte über das HTTP(S)-Protokoll bereitstellt, können Sie statische Inhalte in einem Cloud Storage-Bucket speichern und Anfragen dann über einen Back-End-Bucket an ihn weiterleiten.
Systemdiagnosen
Wenn Sie den Back-End-Dienst eines Load Balancers konfigurieren, müssen Sie eine oder mehrere Systemdiagnosen für die Back-Ends angeben. Mit einer Systemdiagnose wird, wie der Name schon sagt, festgestellt, ob die Back-End-Instanzen des Load Balancers fehlerfrei arbeiten. Diese Entscheidung basiert auf der Fähigkeit des Backends, auf eingehenden Traffic zu reagieren. Auf welchen Traffic ein Back-End reagieren muss, hängt vom Typ des Load Balancers ab. Sie können Systemdiagnosen mit Layer 7- und Layer 4-Protokollen erstellen, um Instanzen mit Load Balancing zu überwachen.
Firewallregeln
Damit Systemdiagnosen funktionieren, müssen Sie allow-Firewallregeln für eingehenden Traffic erstellen, damit Systemdiagnoseprüfungen Ihre Back-Ends erreichen können.
Load Balancer, die auf Google Front Ends basieren, erfordern eine Firewallregel zum Zulassen von eingehendem Traffic, die Traffic von den CIDRs des Google Front Ends zu Ihren Back-Ends zulässt. Load Balancer, die auf dem Open-Source-Envoy-Proxy basieren, erfordern eine Firewallregel zum Zulassen von eingehendem Traffic, die Traffic vom Nur-Proxy-Subnetz zu den Backend-Instanzen zulässt.allow
Weitere Informationen finden Sie unter Firewallregeln.
Back-Ends
Back-Ends sind das Endziel von Traffic, für den ein Load Balancing vorgenommen wird.
Verschiedene Load Balancer unterstützen unterschiedliche Arten von Back-Ends. Wenn Sie dem Back-End-Dienst ein Back-End hinzufügen, geben Sie einen Balancing-Modus an, der die Kapazität des Back-Ends zum Abwickeln neuer Anfragen bewertet und bestimmt, wie der Traffic auf die Back-Ends verteilt wird.
Weitere Informationen finden Sie unter Back-Ends.
Die zugrunde liegenden Technologien von Google Cloud-Load Balancern
In der folgenden Tabelle sind die zugrunde liegenden Technologien aufgeführt, auf denen die einzelnen Google Cloud-Load Balancer basieren.
- Google Front Ends (GFEs) sind softwarebasierte, verteilte Systeme, die sich in 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 ist ein Open-Source-Edge- und -Dienstproxy, der für cloudnative Anwendungen entwickelt wurde.
| Load-Balancer | Technologie |
|---|---|
| Globaler externer Application Load Balancer | Envoy-basiertes Google Front End (GFE) |
| Klassischer Application Load Balancer | GFE |
| Regionaler externer Application Load Balancer | Envoy |
| Regionsübergreifender interner Application Load Balancer | Envoy |
| Regionaler interner Application Load Balancer | Envoy |
| Globaler externer Proxy-Network Load Balancer | Envoy-basierte GFE |
| Klassischer Proxy-Network Load Balancer | GFE |
| Regionaler externer Proxy-Network Load Balancer | Envoy |
| Regionaler interner Proxy-Network Load Balancer | Envoy |
| Regionsübergreifender interner Proxy-Network Load Balancer | Envoy |
| Externer Passthrough-Network Load Balancer | Maglev |
| Interner Passthrough-Network-Load-Balancer | Andromeda |
Load-Balancer auswählen
Um zu bestimmen, welches Cloud Load Balancing-Produkt verwendet werden soll, müssen Sie erst einmal festlegen, welche Art von Traffic Ihre Load-Balancer verarbeiten müssen. In der Regel wählen Sie einen Application Load Balancer aus, wenn Sie ein flexibles Feature-Set für Ihre Anwendungen mit HTTP(S)-Traffic benötigen. Außerdem verwenden Sie einen Network Load Balancer, wenn Sie eine umfangreiche TLS-Auslagerung oder Unterstützung für UDP benötigen oder Client-IP-Adressen für Ihre Anwendungen freigeben müssen.
Sie können Ihre Auswahl weiter eingrenzen, abhängig von den Anforderungen Ihrer Anwendung: Ob Ihre Anwendung extern (mit dem Internet) oder intern verbunden ist, ob Sie global oder regional bereitgestellte Back-Ends benötigen und ob Sie Premium oder Standard-Netzwerkdienststufe benötigen.
Das folgende Diagramm zeigt alle verfügbaren Bereitstellungsmodi für Cloud Load Balancing. Weitere Informationen finden Sie im Leitfaden Load Balancer auswählen.
1. Globale externe Application Load Balancer unterstützen zwei Betriebsmodi: global und klassisch.
2. Globale externe Proxy-Network Load Balancer unterstützen zwei Betriebsmodi: global und klassisch.
3. Passthrough-Network Load Balancer behalten die Quell-IP-Adressen des Clients bei. Passthrough-Network-Load-Balancer unterstützen auch zusätzliche Protokolle wie UDP, ESP und ICMP.
Zusammenfassung der Typen von Google Cloud-Load-Balancern
Die folgende Tabelle enthält Details wie die Netzwerkdienstebene, auf der die einzelnen Load Balancer ausgeführt werden, sowie das Load Balancing-Schema.
| Load-Balancer | Bereitstellungsmodus | Traffictyp | Netzwerkdienststufe | Load-Balancing-Schema * |
|---|---|---|---|---|
| Application Load Balancer | Global, extern | HTTP oder HTTPS | Premium-Stufe | EXTERNAL_MANAGED |
| Regional, extern | HTTP oder HTTPS | Premium- oder Standardstufe | EXTERNAL_MANAGED | |
| Klassisch | HTTP oder HTTPS | Global in der Premium-Stufe Regional in der Standardstufe. |
EXTERN† | |
| Regional intern | HTTP oder HTTPS | Premium-Stufe | INTERNAL_MANAGED | |
| Regionenübergreifend, intern | HTTP oder HTTPS | Premium-Stufe | INTERNAL_MANAGED | |
| Proxy-Network-Load-Balancer | Global, extern | TCP mit optionaler SSL-Auslagerung | Premium-Stufe | EXTERNAL_MANAGED |
| Regional, extern | TCP | Premium- oder Standardstufe | EXTERNAL_MANAGED | |
| Klassisch | TCP mit optionaler SSL-Auslagerung | Global in der Premium-Stufe Regional in der Standardstufe. |
EXTERN | |
| Regional intern | TCP ohne SSL-Übertragung | Premium-Stufe | INTERNAL_MANAGED | |
| Regionenübergreifend, intern | TCP ohne SSL-Übertragung | Premium-Stufe | INTERNAL_MANAGED | |
| Passthrough-Network-Load-Balancer | Extern Immer regional |
TCP, UDP, ESP, GRE, ICMP und ICMPv6 | Premium- oder Standardstufe | EXTERN |
Intern Immer regional |
TCP, UDP, ICMP, ICMPv6, SCTP, ESP, AH und GRE | Premium-Stufe | INTERN |
* Das Load-Balancing-Schema ist ein Attribut für die Weiterleitungsregel und den Backend-Dienst eines Load Balancers und gibt an, ob der Load Balancer für internen oder externen Traffic verwendet werden kann.
Der Begriff managed in EXTERNAL_MANAGED oder INTERNAL_MANAGED gibt an, dass der Load Balancer als verwalteter Dienst entweder auf einem Google Front End (GFE) oder auf dem Open-Source-Envoy-Proxy implementiert wird. In einem verwalteten Load Balancing-Schema werden Anfragen entweder an das GFE oder an den Envoy-Proxy weitergeleitet.
EXTERNAL_MANAGED-Back-End-Dienste können an EXTERNAL-Weiterleitungsregeln angehängt werden. EXTERNAL-Back-End-Dienste können jedoch nicht an EXTERNAL_MANAGED-Weiterleitungsregeln angehängt werden.
Wenn Sie die neuen Funktionen nutzen möchten, die nur mit dem globalen externen Application Load Balancer verfügbar sind, empfehlen wir Ihnen, Ihre vorhandenen EXTERNAL-Ressourcen mithilfe des Migrationsvorgangs unter Ressourcen vom klassischen zum globalen externen Application Load Balancer migrieren zu EXTERNAL_MANAGED zu migrieren.
Interfaces
Sie können Ihre Load-Balancer über folgende Oberflächen konfigurieren und aktualisieren:
Die Google Cloud-CLI: Ein Befehlszeilentool, das in der Google Cloud-CLI enthalten ist. In der Dokumentation wird dieses Tool häufig zum Ausführen von Aufgaben erwähnt. Eine vollständige Übersicht über das Tool finden Sie im Leitfaden zur gcloud CLI. Befehle im Zusammenhang mit dem 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 --helpDie Google Cloud Console: Load-Balancing-Aufgaben können über die Google 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.
Terraform: Sie können ein Open-Source-Infrastruktur-als-Code-Tool wie Terraform verwenden, um die Google Cloud-Load-Balancing-Infrastruktur bereitzustellen, zu aktualisieren und zu löschen.
Nächste Schritte
- Informationen darüber, welcher Google Cloud-Load-Balancer Ihren Anforderungen am besten entspricht, finden Sie unter Load-Balancer auswählen.
- Eine vergleichende Übersicht über die von Cloud Load Balancing angebotenen Load-Balancing-Features finden Sie unter Load-Balancer-Features im Vergleich.