Mithilfe dieses Dokuments können Sie feststellen, welcher Load-Balancer von Google Cloud Ihre Anforderungen am besten erfüllt. Eine Übersicht aller verfügbaren Cloud Load Balancing-Produkte finden Sie unter Übersicht über Cloud Load Balancing.
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. Wählen Sie einen Proxy-Network Load Balancer aus, um TCP-Proxy-Load-Balancing für Backends in einer oder mehreren Regionen zu implementieren. Und Sie wählen einen Passthrough-Network-Load-Balancer aus, um die Quell-IP-Adressen von Clients beizubehalten, den Overhead von Proxys zu vermeiden sowie zusätzliche Protokolle wie UDP, ESP und ICMP zu unterstützen.
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 und ob Sie global oder regional bereitgestellte Back-Ends benötigen.
Im folgenden Diagramm werden alle verfügbaren Bereitstellungsmodi für Cloud Load Balancing zusammengefasst.
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 Quell-IP-Adressen von Clients bei. Passthrough-Network-Load-Balancer unterstützen auch zusätzliche Protokolle wie UDP, ESP und ICMP.
Load-Balancing-Aspekte
Berücksichtigen Sie bei der Entscheidung, welcher Load-Balancer am besten für Ihre Implementierung von Google Cloud geeignet ist, die folgenden Aspekte von Cloud Load Balancing:
- Traffic-Typ
- Externes oder internes Load-Balancing
- Globales oder regionales Load-Balancing
- Premium- oder Standard-Netzwerkdienststufe
- Proxy- oder Passthrough-Load-Balancing
Traffic-Typ
Auch die Art von Traffic, die der Load-Balancer verarbeiten muss, spielt bei der Auswahl des zu verwendenden Load-Balancers eine Rolle.
| Load Balancer-Typ | Traffic-Typ |
|---|---|
| Application Load Balancer | HTTP oder HTTPS |
| Passthrough-Network-Load-Balancer | TCP oder UDP Diese Load-Balancer unterstützen auch anderen IP-Protokoll-Traffic wie ESP, GRE, ICMP und ICMPv6. |
| Proxy-Network-Load-Balancer | TCP mit optionaler SSL-Auslagerung |
Externes oder internes Load-Balancing
Google Cloud-Load-Balancer können als externe oder interne Load-Balancer bereitgestellt werden:
Externe Load-Balancer verteilen den aus dem Internet kommenden Traffic auf Ihr Google Cloud-VPC-Netzwerk (Virtual Private Cloud).
Interne Load-Balancer verteilen den Traffic von Clients im selben VPC-Netzwerk wie der Load-Balancer oder Clients, die über VPC-Netzwerk-Peering, Cloud VPN oder Cloud Interconnect mit Ihrem VPC-Netzwerk verbunden sind.
Anhand der Zusammenfassungstabelle können Sie bestimmen, welcher Load-Balancer den Anforderungen Ihrer Anwendung entspricht.
Globales oder regionales Load-Balancing
Abhängig von der Art des Traffics, den der Load-Balancer verarbeiten muss, und ob Ihre Clients intern oder extern sind, können Sie möglicherweise zwischen einem globalen oder einem regionalen Load-Balancer wählen.
Wählen Sie einen globalen Load Balancer oder einen regionenübergreifenden Load Balancer aus, wenn der Load Balancer global verteilt werden oder sich über mehrere Regionen erstrecken soll. Solche Load Balancer können den Traffic auch auf Back-Ends in mehreren Regionen verteilen. Sie eignen sich daher, wenn Ihre Anwendung oder Ihre Inhalte über mehrere Regionen verteilt sind oder wenn Sie die Flexibilität haben möchten, Back-Ends mit mehreren Regionen in dem Moment hinzuzufügen, in dem sich Ihre Anwendung auf neue geografische Gebiete ausweitet.
Nur externe Load Balancer sind als globale Load Balancer verfügbar. Wählen Sie für interne Load Balancer mit Back-Ends in mehreren Regionen den regionenübergreifenden Load Balancer aus. Regionenübergreifende Load Balancer bieten Zugriff mithilfe einer regionalen internen IP-Adresse, die aus dem regionalen Subnetz im VPC-Netzwerk stammt. Dies unterscheidet sich von globalen Load Balancern, die Zugriff über eine einzelne Anycast-IP-Adresse und durch IPv6-Beendigung am Load Balancer bieten. Weitere Informationen finden Sie in der folgenden Tabelle.
Wählen Sie einen regionalen Load-Balancer aus, wenn Sie nur Back-Ends in einer einzelnen Region benötigen, lediglich eine IPv4-Beendigung (nicht IPv6) erforderlich ist oder wenn der Traffic aufgrund rechtlicher Compliance-Anforderungen in einer bestimmten Region bleiben muss.
Arbeitslasten, die aus Compliance-Gründen regionalisierte Ressourcen benötigen, erfordern, dass bestimmte Ressourcen in einer bestimmten Region verwaltet werden müssen oder dass Traffic in einer bestimmten Region beendet werden muss. Wenn Sie steuern müssen, wo TLS geografisch beendet wird, sollten Sie einen regionalen Load Balancer verwenden. Ein regionaler Load Balancer wird in einer spezifischen, von Ihnen ausgewählten Region bereitgestellt und kann nur eine Verbindung zu Backends in derselben Region herstellen. Bei regionalen Load-Balancern wird TLS also nur in der Region beendet, in der Sie den Load-Balancer und seine Back-Ends bereitgestellt haben. Globale Load-Balancer beenden Transport Layer Security (TLS) an global verteilten Orten, um die Latenz zwischen Clients und dem Load-Balancer zu minimieren.
Load-Balancer sind ein sehr wichtiger Bestandteil der meisten hochverfügbaren Anwendungen. Beachten Sie, dass die Ausfallsicherheit der gesamten Anwendung nicht nur vom Bereich des ausgewählten Load-Balancers (global oder regional), sondern auch von der Redundanz Ihrer Backend-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. | ||
| Regionenübergreifend | 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. |
Anhand der Zusammenfassungstabelle können Sie bestimmen, welcher Load-Balancer den Anforderungen Ihrer Anwendung entspricht.
Proxy- oder Passthrough-Load-Balancing
Abhängig von der Art des Traffics, den der Load-Balancer verarbeiten muss, und davon, ob Ihre Clients intern oder extern sind, können Sie möglicherweise zwischen einem Proxy-Load-Balancer oder einem Passthrough-Load-Balancer wählen.
Proxy-Load-Balancer beenden eingehende Clientverbindungen am Load Balancer und öffnen dann neue Verbindungen vom Load Balancer zu den Backends. Auf diese Weise funktionieren alle Application Load Balancer und Proxy-Network-Load-Balancer. Sie beenden Clientverbindungen entweder mithilfe von Google Front Ends (GFEs) oder Envoy-Proxys.
Passthrough-Load-Balancer beenden Clientverbindungen nicht. Stattdessen werden Pakete mit Load-Balancing von Backend-VMs mit der Quelle, dem Ziel und, falls zutreffend, den Portinformationen des Pakets empfangen. Verbindungen werden dann von den Backend-VMs beendet. Antworten von den Backend-VMs werden direkt an die Clients gesendet, nicht über den Load-Balancer. Der Begriff hierfür ist direkte Serverrückgabe. Verwenden Sie einen Passthrough-Load-Balancer, wenn Sie die Informationen des Clientpakets beibehalten müssen. Wie der Name verrät, fallen die Passthrough-Network-Load-Balancer unter diese Kategorie.
Anhand der Zusammenfassungstabelle können Sie bestimmen, welcher Load-Balancer den Anforderungen Ihrer Anwendung entspricht.
Premium- oder Standard-Netzwerkdienststufe
In Netzwerkdienststufen können Sie Verbindungen zwischen Systemen im Internet und Ihren Google Cloud-Instanzen optimieren. In der Premium-Stufe wird der Traffic über das Premium-Backbone von Google geleitet, während die Standardstufe reguläre Netzwerke von Internetanbietern verwendet. In der Regel wählen Sie die Premium-Stufe aus, um eine hohe Leistung bei niedriger Latenz zu erzielen. Sie können die Standardstufe als kostengünstige Alternative für Anwendungen auswählen, die keine hohen Anforderungen an Latenz oder Leistung haben.
Premium-Stufe. Wenn sich die IP-Adresse des Load-Balancers in der Premium-Stufe befindet, durchquert der Traffic den hochwertigen globalen Backbone von Google mit der Absicht, dass die Pakete den Edge-Peering-Punkt von Google möglichst nah am Client betreten bzw. verlassen. Wenn Sie keine Netzwerkstufe angeben, verwendet Ihr Lastenausgleichsmodul standardmäßig die Premiumstufe. Beachten Sie, dass alle internen Load-Balancer immer Premium-Stufe sind. Darüber hinaus kann der globale externe Application Load Balancer nur in der Premium-Stufe konfiguriert werden.
Standardstufe. Wenn sich die IP-Adresse des Load-Balancers in der Standardstufe befindet, betritt und verlässt der Traffic das Google-Netzwerk an einem Peering-Punkt, der derjenigen Google Cloud-Region am nächsten ist, in der der Load-Balancer konfiguriert ist. Wie in der Zusammenfassungstabelle erwähnt, können nicht alle Load-Balancer in der Standardstufe bereitgestellt werden. Planen Sie daher Ihr Budget entsprechend.
Da Sie eine Stufe auf Ressourcenebene auswählen, z. B. die externe IP-Adresse für einen Load-Balancer oder eine VM, können Sie für einige Ressourcen die Standardstufe und für andere die Premium-Stufe verwenden. Sie können den Entscheidungsbaum in der Dokumentation zu Netzwerkdienststufen verwenden, um eine Entscheidung zu treffen.
DDoS-Schutzmaßnahmen für externe Load-Balancer
Google Cloud Armor bietet abhängig vom Typ des Load-Balancers sowohl immer aktive als auch vom Nutzer konfigurierbare DDoS-Schutzmaßnahmen.
| Load-Balancer-Typ oder -Modus | Permanenten DDoS-Schutz | Google Cloud Armor-Sicherheitsrichtlinien |
|---|---|---|
| Globaler externer Application Load Balancer | ||
| Klassischer Application Load Balancer | ||
| Regionaler externer Application Load Balancer | ||
| Globaler externer Proxy-Network Load Balancer | ||
| Klassischer Proxy-Network Load Balancer | ||
| Externer Passthrough-Network Load Balancer |
Sie können auch einen erweiterten DDoS-Netzwerkschutz für externe Passthrough-Network-Load-Balancer, Protokollweiterleitung oder VMs mit öffentlichen IP-Adressen konfigurieren. Weitere Informationen zum erweiterten Netzwerk-DDoS-Schutz finden Sie unter Erweiterten DDoS-Netzwerkschutz konfigurieren.
Zusammenfassung der Load-Balancer von Google Cloud
Die folgende Tabelle enthält detaillierte Informationen zu den einzelnen Load-Balancern.
| Load-Balancer | Bereitstellungsmodus | Traffic-Typ | 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 im Load-Balancing-Schema gibt an, dass der Load-Balancer als verwalteter Dienst auf Google Front Ends (GFEs) oder dem Open-Source-Envoy-Proxy implementiert wird. In einem Load-Balancing-Schema, das *_MANAGED ist, werden Anfragen entweder an das GFE oder an den Envoy-Proxy weitergeleitet.
Nächste Schritte
- Eine vergleichende Übersicht über die von Cloud Load Balancing angebotenen Load-Balancing-Funktionen finden Sie unter Load-Balancing-Funktionsvergleich.