Ein Load-Balancer ist ein System, das aus mehreren interagierenden Komponenten besteht. Es gibt keine einzelne API-Ressource, die einen Load-Balancer darstellt. Stattdessen arbeiten mehrere Komponenten zusammen, um eingehenden Traffic auf mehrere Back-Ends zu verteilen.
Das folgende Diagramm zeigt die Kernkomponenten 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
In diesem Abschnitt finden Sie einen allgemeinen Überblick über die wichtigsten Komponenten eines Load-Balancers, von dem Punkt an, an dem Traffic den Load-Balancer erreicht, bis zu dem Punkt, an dem er an die Backend-Ressource weitergeleitet wird. Weitere Informationen zu den einzelnen Load-Balancer-Komponenten finden Sie auf der Seite, die in jedem Abschnitt verlinkt ist.
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 Übersicht über Weiterleitungsregeln.
Ziel-Proxy
Ziel-Proxys beenden eingehende Verbindungen von Clients und erstellen neue Verbindungen vom Load Balancer zu den Backends.
Die erste Verbindung stammt vom Client und wird am Ziel-Proxy des Load-Balancers beendet.
Die zweite Verbindung beginnt am Ziel-Proxy 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, dem sogenannten Nur-Proxy-Subnetz, das ausschließlich für Envoy-Proxys reserviert ist. Informationen dazu, ob ein Load-Balancer auf GFE oder Envoy basiert, finden Sie unter Zugrunde liegende Technologien von Google Cloud Load Balancern.
Ziel-Proxys 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 Backend-Instanzen an den Zielproxy und nicht direkt an den Client zurückgesendet.
Für Routingentscheidungen verwendet ein HTTP(S)-Zielproxy eine URL-Zuordnung. Ein TCP-Zielproxy kann optional eine oder mehrere TLS-Routen verwenden, um SNI-basiertes Routing auszuführen.
Weitere Informationen finden Sie unter Ziel-Proxys.
Nur-Proxy-Subnetz
Ein Nur-Proxy-Subnetz bietet einen Pool von IP-Adressen, die ausschließlich für Envoy-Proxys reserviert sind, die von Google Cloud Load-Balancern 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
Nachdem die Verbindung beendet wurde, entscheidet der HTTP(S)-Ziel-Proxy anhand der URL-Zuordnung, wohin die neue Anfrage weitergeleitet werden soll (die zweite Verbindung, wie im Abschnitt Zielproxy angegeben). Die URL-Zuordnung leitet die Anfrage entweder an den Backend-Dienst oder den Backend-Bucket weiter. 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 Domainname, Anfragepfad und Abfrageparametern treffen.
Weitere Informationen finden Sie unter URL-Zuordnungen.
TLS-Route
Mit einer TLS-Route (dargestellt durch die TLSRoute-API-Ressource) können Sie TCP-Traffic anhand der SNI-Hostnamen (Server Name Indication) weiterleiten, die im TLS-Handshake des Clients angegeben sind.
TLS-Routen werden optional an den TCP-Zielproxy eines Load-Balancers angehängt.
Anstatt den gesamten eingehenden Traffic an einen einzelnen Standard-Backend-Dienst weiterzuleiten, verwendet der TCP-Zielproxy die TLS-Routenkonfiguration, um die ClientHello-Nachricht des TLS-Handshakes dynamisch zu prüfen und den Traffic anhand des übereinstimmenden SNI-Hostnamens an den entsprechenden Backend-Dienst weiterzuleiten.
TLS-Routen werden nur von Proxy-Network Load Balancern verwendet, insbesondere von regionalen externen Proxy-Network Load Balancern, regionalen internen Proxy-Network Load Balancern und regionenübergreifenden internen Proxy-Network Load Balancern. Da sie auf der TLS-Ebene ausgeführt werden, ermöglichen sie TLS-Passthrough, bei dem der verschlüsselte Traffic direkt an das Backend weitergeleitet wird, ohne vom Load Balancer entschlüsselt zu werden.
Weitere Informationen finden Sie unter SNI-basiertes Routing mit TLS Routen.
Backend-Dienst
Ein Backend-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 des Load-Balancers genau steuern und Traffic an die richtigen Back-Ends weiterleiten, die entweder VM-Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs) sein können.
Weitere Informationen finden Sie unter Übersicht über Backend-Dienste.
Backend-Bucket
Wenn Ihre Arbeitslast statische Inhalte mit dem HTTP(S)-Protokoll bereitstellt, können Sie einen Cloud Storage-Bucket verwenden, um statische Inhalte zu speichern, und dann einen Backend Bucket verwenden, um Anfragen dorthin weiterzuleiten.
Systemdiagnosen
Wenn Sie den Backend-Dienst eines Load-Balancers konfigurieren, müssen Sie eine oder mehrere Systemdiagnosen für die Back-Ends angeben. Eine Systemdiagnose ermittelt, wie der Name schon sagt, ob die Backend-Instanzen des Load-Balancers fehlerfrei sind. Diese Entscheidung basiert darauf, ob das Backend auf eingehenden Traffic reagieren kann. Der Traffic, auf den ein Backend reagieren muss, hängt vom Typ des Load-Balancers ab. Sie können Systemdiagnosen mit Protokollen der Ebene 7 und der Ebene 4 erstellen , um Instanzen mit Load Balancing zu überwachen.
Firewallregeln
Damit Systemdiagnosen funktionieren, müssen Sie Firewallregeln zum Zulassen von eingehendem Traffic (allow) 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 von Google Front End zulässt, um eine Verbindung zu Ihren
Back-Ends herzustellen. Load-Balancer, die auf dem Open-Source-Envoy-Proxy basieren, erfordern eine Firewallregel zum Zulassen von eingehendem Traffic (allow), die Traffic vom Nur-Proxy-Subnetz zu den Backend-Instanzen zulässt.
Weitere Informationen finden Sie unter Firewallregeln.
Back-Ends
Back-Ends sind das endgültige Ziel von Traffic mit Load Balancing.
Verschiedene Load-Balancer unterstützen unterschiedliche Arten von Back-Ends. Wenn Sie dem Backend-Dienst ein Backend hinzufügen, geben Sie einen Balancing-Modus an. In diesem Modus wird die Kapazität des Backends zur Verarbeitung neuer Anfragen bewertet und festgelegt, wie Traffic auf die Back-Ends verteilt wird.
Weitere Informationen finden Sie unter Back-Ends.
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.