Load-Balancer auswählen

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.

Load-Balancer auswählen.
Wählen Sie einen Load Balancer aus (zum Vergrößern klicken).

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

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