Übersicht über Back-End-Dienste

Ein Back-End-Dienst definiert, wie Cloud Load Balancing 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. Für einen schnellen Einstieg haben die meisten Einstellungen Standardwerte, die eine einfache Konfiguration ermöglichen. Ein Backend-Dienst ist regional.

Load-Balancer, Envoy-Proxys und proxylose gRPC-Clients verwenden die Konfigurationsinformationen in der Back-End-Dienstressource, um die folgenden Aufgaben auszuführen:

• Weiterleiten von Traffic an die richtigen Back-Ends, die Instanzgruppen oder Netzwerk-Endpunktgruppen (NEGs) sind.
• Verteilen von Traffic gemäß einem Load-Balancing-Modus. Dies ist eine Einstellung für jedes Back-End.
• Bestimmen, welche Systemdiagnose den Zustand der Back-Ends überwacht.
• Angeben der Sitzungsaffinität.

Sie legen diese Werte fest, wenn Sie einen Backend-Dienst erstellen oder dem Backend-Dienst ein Backend hinzufügen.

In der folgenden Tabelle wird zusammengefasst, welche Load-Balancer Backend-Dienste verwenden. Das verwendete Produkt bestimmt auch die maximale Anzahl von Backend-Diensten, den Umfang eines Backend-Dienstes, den unterstützten Backend-Typ und das Load-Balancing-Schema des Backend-Dienstes. Das Load Balancing-Schema ist eine Kennzeichnung, die Google zum Klassifizieren von Weiterleitungsregeln und Backend-Diensten verwendet. Jedes Load Balancing-Produkt verwendet ein Load Balancing-Schema für seine Weiterleitungsregeln und Backend-Dienste. Einige Schemas werden von mehreren Produkten gemeinsam genutzt.

Load-Balancer benennen

Bei Proxy-Network Load Balancern und Passthrough-Network Load Balancern ist der Name des Load Balancers immer derselbe wie der Name des Backend-Dienstes. Das Verhalten für die einzelnen Trusted Cloud Schnittstellen ist wie folgt:

• Trusted Cloud console. Wenn Sie einen Proxy-Network Load Balancer oder einen Passthrough-Network Load Balancer über die Trusted Cloud -Konsole erstellen, wird dem Backend-Dienst automatisch derselbe Name zugewiesen, den Sie für den Load Balancer-Namen eingegeben haben.
• Google Cloud CLI oder API Wenn Sie einen Proxy Network Load Balancer oder einen Passthrough Network Load Balancer mit der gcloud CLI oder der API erstellen, geben Sie beim Erstellen des Backend-Dienstes einen Namen Ihrer Wahl ein. Dieser Name des Backend-Dienstes wird dann in der Trusted Cloud Console als Name des Load-Balancers angezeigt.

Informationen zur Namensgebung für Application Load Balancer finden Sie unter URL-Zuordnungen: Namensgebung für Load Balancer.

Back-Ends

Ein Backend besteht aus einem oder mehreren Endpunkten, die Traffic von einem Trusted Cloud by S3NSLoad-Balancer oder einem proxylosen gRPC-Client empfangen. Es gibt mehrere Arten von Back-Ends:

• Eine Instanzgruppe mit VM-Instanzen. Eine Instanzgruppe kann eine verwaltete Instanzgruppe mit oder ohne Autoscaling oder eine nicht verwaltete Instanzgruppe sein. Mehrere Back-End-Dienste können auf eine Instanzgruppe verweisen, aber alle Back-End-Dienste, die auf die Instanzgruppe verweisen, müssen denselben Balancing-Modus verwenden.
• Zonale NEG
• Internet-NEG
• Hybrid-Konnektivitäts-NEG
• NEG für Portzuordnung
• Service Directory-Dienstbindungen

Sie können keine Backend-Instanzgruppe oder NEG löschen, die mit einem Backend-Dienst verknüpft ist. Bevor Sie eine Instanzgruppe oder NEG löschen, müssen Sie sie als Backend aus allen Backend-Diensten entfernen, die darauf verweisen.

Instanzgruppen

In diesem Abschnitt wird erläutert, wie Instanzgruppen mit dem Back-End-Dienst funktionieren.

Backend-VMs und externe IP-Adressen

Backend-VMs in Backend-Diensten benötigen keine externen IP-Adressen:

• Für regionale externe Application Load Balancer: Clients kommunizieren mit einem Envoy-Proxy, der die externe IP-Adresse Ihres Load-Balancers hostet. Envoy-Proxys kommunizieren mit Backend-VMs oder -Endpunkten, indem Pakete an eine interne Adresse gesendet werden. Diese wird durch Zusammenführen einer Kennung für das VPC-Netzwerk des Backends mit der internen IPv4-Adresse des Backends erstellt.

  • Bei Instanzgruppen-Back-Ends ist die interne IPv4-Adresse immer die primäre interne IPv4-Adresse, die der nic0-Schnittstelle der VM entspricht, und nic0 muss sich im selben Netzwerk wie der Load-Balancer befinden.
  • FürGCE_VM_IP_PORT Endpunkte in einer zonalen NEG können Sie die IP-Adresse des Endpunkts entweder als primäre IPv4-Adresse angeben, die einer beliebigen Netzwerkschnittstelle einer VM zugeordnet ist, oder als beliebige IPv4-Adresse aus einem Alias-IP-Adressbereich, der mit einer beliebigen Netzwerkschnittstelle einer VM verknüpft ist, solange sich die Netzwerkschnittstelle im selben Netzwerk wie der Load-Balancer befindet.

• Für externe Passthrough-Network-Load-Balancer: Clients kommunizieren direkt über die Maglev-Passthrough-Load-Balancing-Infrastruktur von Google mit Back-Ends. Die Pakete werden weitergeleitet und an Back-Ends gesendet, wobei die ursprünglichen Quell- und Ziel-IP-Adressen beibehalten werden. Back-Ends antworten auf Clients mit Direct Server Return.. Die zum Auswählen eines Back-Ends und zum Verfolgen von Verbindungen verwendeten Methoden sind konfigurierbar.

  • Bei Back-Ends von Instanzgruppen werden Pakete immer an die nic0-Schnittstelle der VM gesendet.
  • Bei GCE_VM_IP-Endpunkten in einer zonalen NEG werden Pakete an die Netzwerkschnittstelle der VM im Subnetzwerk zugestellt, das der NEG zugeordnet ist.

Benannte Ports

Das Attribut Benannter Port des Backend-Dienstes gilt nur für Proxy-basierte Load-Balancer (Application Load Balancer und Proxy-Netzwerk-Load-Balancer), die Instanzgruppen-Backends verwenden. Der benannte Port definiert den Zielport, der für die TCP-Verbindung zwischen dem Proxy (GFE oder Envoy) und der Backend-Instanz verwendet wird.

Benannte Ports werden so konfiguriert:

• An jedem Backend einer Instanzgruppe müssen Sie einen oder mehrere benannte Ports mit Schlüssel/Wert-Paaren konfigurieren. Der Schlüssel steht für einen aussagekräftigen Portnamen, den Sie auswählen, und der Wert steht für die Portnummer, die Sie dem Namen zuweisen. Die Zuordnung von Namen zu Zahlen erfolgt einzeln für jedes Backend der Instanzgruppe.

• Im Backend-Dienst geben Sie einen einzelnen benannten Port nur mit dem Portnamen (--port-name) an.

Auf Backend-Basis pro Instanz übersetzt der Backend-Dienst den Portnamen in eine Portnummer. Wenn der benannte Port einer Instanzgruppe mit dem --port-name des Backend-Dienstes übereinstimmt, verwendet der Backend-Dienst diese Portnummer für die Kommunikation mit den VMs der Instanzgruppe.

Sie können den benannten Port beispielsweise für eine Instanzgruppe mit dem Namen my-service-name und dem Port 8888 festlegen:

gcloud compute instance-groups unmanaged set-named-ports my-unmanaged-ig \
    --named-ports=my-service-name:8888

Dann müssen Sie in der Konfiguration des Backend-Dienstes auf den benannten Port verweisen, wobei --port-name im Backend-Dienst auf my-service-name gesetzt ist:

gcloud compute backend-services update my-backend-service \
    --port-name=my-service-name

Ein Backend-Dienst kann bei der Kommunikation mit VMs in verschiedenen Instanzgruppen eine andere Portnummer verwenden, wenn jede Instanzgruppe eine andere Portnummer für denselben Portnamen angibt.

Die aufgelöste Portnummer, die vom Backend-Dienst des Proxy-Load-Balancers verwendet wird, muss nicht mit der von den Weiterleitungsregeln des Load-Balancers verwendeten Portnummer übereinstimmen. Ein Proxy-Load-Balancer überwacht TCP-Verbindungen, die an die IP-Adresse und den Zielport seiner Weiterleitungsregeln gesendet werden. Da der Proxy eine zweite TCP-Verbindung zu seinen Back-Ends öffnet, kann der Zielport der zweiten TCP-Verbindung variieren.

Benannte Ports gelten nur für Instanzgruppen-Back-Ends. Zonale NEGs mit GCE_VM_IP_PORT-Endpunkten, Hybrid-NEGs mit NON_GCP_PRIVATE_IP_PORT-Endpunkten und Internet-NEGs definieren Ports mit einem anderen Mechanismus, nämlich auf den Endpunkten selbst.

Interne Passthrough-Network-Load-Balancer und externe Passthrough-Network-Load-Balancer verwenden keine benannten Ports. Dies liegt daran, dass es sich um Pass-Through-Load-Balancer handelt, die Verbindungen direkt an Back-Ends weiterleiten, anstatt neue Verbindungen zu erstellen. An den Back-Ends zugestellte Pakete behalten die Ziel-IP-Adresse und den Port der Weiterleitungsregel des Load-Balancers bei.

Weitere Informationen zum Erstellen benannter Ports finden Sie in den folgenden Anleitungen:

• Nicht verwaltete Instanzgruppen: Mit benannten Ports arbeiten
• Verwaltete Instanzgruppen: Benannte Ports verwalteten Instanzgruppen zuweisen

Einschränkungen und Richtlinien für Instanzgruppen

Beachten Sie beim Erstellen von Instanzgruppen für Ihre Load-Balancer die folgenden Einschränkungen und Hinweise:

• Platzieren Sie eine VM nicht in mehr als einer Instanzgruppe mit Load-Balancing. Wenn eine VM Mitglied von zwei oder mehr nicht verwalteten Instanzgruppen oder Mitglied einer verwalteten Instanzgruppe und einer oder mehreren nicht verwalteten Instanzgruppen ist, Trusted Cloudkönnen Sie jeweils nur eine dieser Instanzgruppen gleichzeitig als Back-End für einen bestimmten Back-End-Dienst verwenden.

  Wenn eine VM an mehreren Load-Balancern beteiligt sein soll, müssen Sie dieselbe Instanzgruppe als Back-End für jeden der Back-End-Dienste verwenden.

• Wenn Sie bei Proxy-Load-Balancern den Traffic auf verschiedene Ports verteilen möchten, geben Sie die erforderlichen benannten Ports in einer Instanzgruppe an und lassen Sie jeden Back-End-Dienst einen eindeutigen benannten Port abonnieren.

• Sie können dieselbe Instanzgruppe als Back-End für mehrere Back-End-Dienste verwenden. In diesem Fall müssen die Back-Ends kompatible Balancing-Modi verwenden. Kompatibel bedeutet, dass die Balancing-Modi identisch oder eine Kombination aus kompatiblen Balancing-Modi sein müssen, z. B. CONNECTION und RATE.

  Folgende Balancing-Modus-Kombinationen sind inkompatibel:

  • CONNECTION mit UTILIZATION
  • RATE mit UTILIZATION
  • CUSTOM_METRICS mit UTILIZATION
  • CUSTOM_METRICS mit RATE
  • CUSTOM_METRICS mit CONNECTION

  Dazu ein Beispiel:

  • Sie haben zwei Backend-Dienste: external-https-backend-service für einen externen Application Load Balancer und internal-tcp-backend-service für einen internen Passthrough-Network-Load-Balancer.
  • Sie verwenden eine Instanzgruppe namens instance-group-a in internal-tcp-backend-service.
  • In internal-tcp-backend-service müssen Sie den Balancing-Modus CONNECTION anwenden, da interne Passthrough-Network-Load-Balancer nur den Balancing-Modus CONNECTION unterstützen.
  • Sie können instance-group-a auch in external-https-backend-service verwenden, wenn Sie den Balancing-Modus RATE in external-https-backend-service anwenden.
  • instance-group-a kann nicht in external-https-backend-service mit dem Balancing-Modus UTILIZATION verwendet werden.

• So ändern Sie den Balancing-Modus für eine Instanzgruppe, die als Back-End für mehrere Back-End-Dienste dient:

  • Entfernen Sie die Instanzgruppe aus allen Back-End-Diensten bis auf einem.
  • Ändern Sie den Balancing-Modus für das Back-End auf dem einen verbleibenden Back-End-Dienst.
  • Fügen Sie den anderen Back-End-Diensten die Instanzgruppe wieder als Back-End hinzu, wenn sie den neuen Balancing-Modus unterstützen.

• Wenn Ihre Instanzgruppe mit mehreren Back-End-Diensten verknüpft ist, kann jeder Back-End-Dienst auf denselben benannten Port oder einen anderen benannten Port in der Instanzgruppe verweisen.

• Wir empfehlen, eine automatisch skalierte verwaltete Instanzgruppe nicht mehr als einem Back-End-Dienst hinzuzufügen. Dies kann zu einer unvorhersehbaren und unnötigen Skalierung der Instanzen in der Gruppe führen, insbesondere wenn Sie den Autoscaling-Messwert HTTP-Load-Balancing-Auslastung verwenden.

  • Dieses Szenario wird zwar nicht empfohlen, kann aber funktionieren, wenn der Autoscaling-Messwert entweder ein Messwert für die CPU-Auslastung oder für Cloud Monitoring ist, und nicht mit der Bereitstellungskapazität des Load-Balancers zusammenhängt. Die Verwendung eines dieser Autoscaling-Messwerte verhindert möglicherweise eine fehlerhafte Skalierung.

Zonale Netzwerk-Endpunktgruppen

Netzwerkendpunkte stellen Dienste gemäß ihrer IP-Adresse oder einer Kombination aus IP-Adresse und Port dar und verweisen nicht auf eine VM in einer Instanzgruppe. Eine Netzwerk-Endpunktgruppe (NEG) ist eine logische Gruppierung von Netzwerkendpunkten.

Zonale Netzwerk-Endpunktgruppen (NEGs) sind zonale Ressourcen, die Sammlungen von IP-Adressen oder IP-Adressen und Port-Kombinationen für Trusted Cloud Ressourcen in einem einzelnen Subnetz darstellen.

Ein Back-End-Dienst, der zonale NEGs als Back-Ends verwendet, verteilt den Traffic auf Anwendungen oder Container, die innerhalb von VMs ausgeführt werden.

Für zonale NEGs sind zwei Arten von Netzwerkendpunkten verfügbar:

• GCE_VM_IP-Endpunkte (werden nur bei internen Passthrough-Network-Load-Balancern und Backend-Dienst-basierten externen Passthrough-Network-Load-Balancern unterstützt).
• GCE_VM_IP_PORT-Endpunkte

Informationen zu den Produkten, die zonale NEG-Backends unterstützen, finden Sie unter Tabelle: Backend-Dienste und unterstützte Backend-Typen.

Weitere Informationen finden Sie unter Übersicht über zonale NEGs.

Internetnetzwerk-Endpunktgruppen

Internet-NEGs sind Ressourcen, die externe Back-Ends definieren. Ein externes Backend ist ein Backend, das in der lokalen Infrastruktur oder in der Infrastruktur von Drittanbietern gehostet wird.

Eine Internet-NEG ist eine Kombination aus einem Hostnamen oder einer IP-Adresse und einem optionalen Port. Für Internet-NEGs sind zwei Arten von Netzwerkendpunkten verfügbar: INTERNET_FQDN_PORT und INTERNET_IP_PORT.

Weitere Informationen finden Sie unter Übersicht über Internetnetzwerk-Endpunktgruppen.

Gemischte Back-Ends

Die folgenden Überlegungen zur Nutzung gelten, wenn Sie einem einzelnen Backend-Dienst verschiedene Arten von Backends hinzufügen:

• Ein einzelner Backend-Dienst kann nicht gleichzeitig Instanzgruppen und zonale NEGs verwenden.
• Sie können jedoch eine Kombination verschiedener Arten von Instanzgruppen für denselben Backend-Dienst verwenden. Beispielsweise kann ein einzelner Backend-Dienst auf eine Kombination aus verwalteten und nicht verwalteten Instanzgruppen verweisen. Ausführliche Informationen dazu, welche Backends mit welchen Backend-Diensten kompatibel sind, finden Sie in der Tabelle im vorherigen Abschnitt.
• Mit bestimmten Proxy-Load-Balancern können Sie eine Kombination aus zonalen NEGs (mit GCE_VM_IP_PORT-Endpunkten) und Hybridkonnektivitäts-NEGs (mit NON_GCP_PRIVATE_IP_PORT-Endpunkten) verwenden, um Hybrid-Load-Balancing zu konfigurieren. Informationen dazu, welche Load-Balancer diese Funktion haben, finden Sie unter Tabelle: Backend-Dienste und unterstützte Backend-Typen.

Protokoll für Back-Ends

Beim Erstellen eines Back-End-Diensts müssen Sie das Protokoll angeben, das für die Kommunikation mit den Back-Ends verwendet werden soll. Sie können nur ein Protokoll pro Back-End-Dienst angeben. Sie können kein sekundäres Protokoll angeben, das als Fallback verwendet werden soll.

Welche Protokolle gültig sind, hängt vom Typ des Load-Balancers.

Durch das Ändern des Protokolls eines Back-End-Dienstes werden die Back-Ends für einige Minuten über Load-Balancer unerreichbar.

Verschlüsselung zwischen dem Load-Balancer und Back-Ends

Informationen zur Verschlüsselung zwischen dem Load-Balancer und den Back-Ends finden Sie unter Verschlüsselung der Back-Ends.

Traffic-Verteilung

Die Werte der folgenden Felder in der Ressource für Back-End-Dienste beeinflussen verschiedene Aspekte des Back-End-Verhaltens:

• Ein Balancing-Modus definiert, wie der Load-Balancer die Bereitschaft von Back-Ends für neue Anfragen oder Verbindungen misst.
• Eine Zielkapazität, die eine maximale Zielanzahl von Verbindungen, eine maximale Zielrate oder die maximale CPU-Zielauslastung definiert.
• Mit einem Kapazitätsskalierer wird die verfügbare Gesamtkapazität angepasst, ohne die Zielkapazität zu ändern.

Balancing-Modus

Der Balancing-Modus bestimmt, ob die Back-Ends eines Load-Balancers zusätzlichen Traffic verarbeiten können oder vollständig geladen werden.

Trusted Cloud bietet vier Balancing-Modi:

• CONNECTION: Bestimmt, wie die Last anhand der Gesamtzahl der Verbindungen verteilt wird, die das Backend verarbeiten kann.
• RATE: Die maximale Anzahl von Anfragen (Abfragen) pro Sekunde (RPS, QPS). Der maximale RPS/QPS-Wert kann überschritten werden, wenn alle Back-Ends die Kapazität erreichen oder überschreiten.
• UTILIZATION: Bestimmt, wie die Last anhand der Auslastung der Instanzen in einer Instanzgruppe verteilt wird.
• CUSTOM_METRICS: Bestimmt, wie die Last auf Grundlage von benutzerdefinierten Messwerten verteilt wird.

Für jeden Load-Balancer verfügbare Balancing-Modi

Sie legen den Balancing-Modus fest, wenn Sie dem Backend-Dienst ein Backend hinzufügen. Die für einen Load Balancer verfügbaren Balancing-Modi hängen vom Typ des Load Balancers und vom Typ der Backends ab.

Passthrough-Network Load Balancer erfordern den Balancing-Modus CONNECTION, unterstützen jedoch keine Festlegung einer Zielkapazität.

Application Load Balancer unterstützen die Balancing-Modi RATE, UTILIZATION oder CUSTOM_METRICS für Instanzgruppen-Back-Ends und die Balancing-Modi RATE oder CUSTOM_METRICS für zonale NEGs (GCE_VM_IP_PORT-Endpunkte) und Hybrid-NEGs (NON_GCP_PRIVATE_IP_PORT-Endpunkte). Bei allen anderen unterstützten Back-Ends muss der Balancing-Modus ausgelassen werden.

• Bei regionalen externen Application Load Balancern und regionalen internen Application Load Balancern wird die Zielkapazität des Balancing-Modus verwendet, um die Anteile der Anfragen zu berechnen, die an jedes Backend (Instanzgruppe oder NEG) in der Region gesendet werden sollen. Innerhalb jeder Instanzgruppe oder NEG bestimmt die Load-Balancing-Richtlinie (LocalityLbPolicy), wie der Traffic auf Instanzen oder Endpunkte innerhalb der Gruppe verteilt wird.

Die Proxy-Network Load Balancer unterstützen die Balancing-Modi CONNECTION und UTILIZATION für VM-Instanzgruppen-Back-Ends, den Balancing-Modus CONNECTION für zonale NEGs mit GCE_VM_IP_PORT-Endpunkten und CONNECTION-Balancing-Modus für Hybrid-NEGs (NON_GCP_PRIVATE_IP_PORT-Endpunkte). Bei allen anderen unterstützten Back-Ends muss der Balancing-Modus ausgelassen werden.

• Bei regionalen externen Proxy-Netzwerk-Load-Balancern und regionalen internen Proxy-Network-Load-Balancern wird anhand der Zielkapazität des Load-Balancing-Modus berechnet, wie viele Anfragen anteilig an die einzelnen Back-Ends (Instanzgruppe oder NEG) gesendet werden. Innerhalb jeder Instanzgruppe oder NEG bestimmt die Load-Balancing-Richtlinie (localityLbPolicy), wie der Traffic auf Instanzen oder Endpunkte innerhalb der Gruppe verteilt wird.

In der folgenden Tabelle sind die für jede Kombination aus Load-Balancer und Backend verfügbaren Load-Balancing-Modi zusammengefasst.

Wenn die durchschnittliche Auslastung aller VMs, die mit einem Back-End-Dienst verknüpft sind, unter 10 % liegt, bevorzugt Trusted Cloud möglicherweise bestimmte Zonen. Dies kann passieren, wenn Sie regionale verwaltete Instanzgruppen, zonal verwaltete Instanzgruppen in verschiedenen Zonen und zonale nicht verwaltete Instanzgruppen verwenden. Dieses zonale Ungleichgewicht wird automatisch aufgelöst, wenn mehr Traffic an den Load-Balancer gesendet wird.

Weitere Informationen finden Sie unter gcloud compute backend-services add-backend.

Zielkapazität

Jeder Load-Balancing-Modus verfügt über eine entsprechende Zielkapazität, die einen der folgenden Zielwerte definiert:

• Anzahl Verbindungen
• Rate
• CPU-Auslastung

Für jeden Balancing-Modus ist die Zielkapazität kein Schutzschalter. Ein Load-Balancer kann das Maximum unter bestimmten Bedingungen überschreiten, z. B. wenn alle Back-End-VMs oder Endpunkte das Maximum erreicht haben.

Verbindungsmodus für Verbindungen

Im CONNECTION-Balancing-Modus definiert die Zielkapazität eine maximale Zielanzahl offener Verbindungen. Mit Ausnahme der internen Passthrough-Network-Load-Balancer und externen Passthrough-Network-Load-Balancer müssen Sie eine der folgenden Einstellungen verwenden, um eine maximale Anzahl von Verbindungen festzulegen:

• max-connections-per-instance (pro VM): Durchschnittliche Anzahl von Verbindungen für eine einzelne VM.
• max-connections-per-endpoint (pro Endpunkt in einer zonalen NEG): Die durchschnittliche Anzahl der Verbindungen für einen einzelnen Endpunkt.
• max-connections (pro zonale NEGs und für zonale Instanzgruppen): Ziel der durchschnittlichen Anzahl von Verbindungen für die gesamte NEG oder Instanzgruppe. Verwenden Sie für regional verwaltete Instanzgruppen stattdessen max-connections-per-instance.

In der folgenden Tabelle wird gezeigt, wie mit dem Parameter für die Zielkapazität Folgendes definiert wird:

• Die Zielkapazität für das gesamte Back-End
• Die erwartete Zielkapazität für jede Instanz oder jeden Endpunkt

Wie dargestellt, sind die Einstellungen max-connections-per-instance und max-connections-per-endpoint Proxys für die Berechnung einer angestrebten maximalen Anzahl von Verbindungen für die gesamte VM-Instanzgruppe oder das gesamte zonale NEG:

• In einer VM-Instanzgruppe mit N-Instanzen hat die Einstellung von max-connections-per-instance=X dieselbe Bedeutung wie die Einstellung von max-connections=X × N.
• In einer zonalen NEG mit N-Endpunkten hat die Einstellung von max-connections-per-endpoint=X dieselbe Bedeutung wie die Einstellung von max-connections=X × N.

Load-Balancing-Modus

Für den Balancing-Modus RATE müssen Sie die Zielkapazität mit einem der folgenden Parameter definieren:

• max-rate-per-instance (pro VM): Geben Sie eine durchschnittliche Ziel-HTTP-Anfragerate für eine einzelne VM an.
• max-rate-per-endpoint (pro Endpunkt in einer zonalen NEG): Geben Sie eine durchschnittliche Ziel-HTTP-Anfragerate für einen einzelnen Endpunkt an.
• max-rate (pro zonale NEGs und für zonale Instanzgruppen): Geben Sie eine durchschnittliche Ziel-HTTP-Anfragerate für die gesamte NEG oder Instanzgruppe an. Verwenden Sie für regional verwaltete Instanzgruppen stattdessen max-rate-per-instance.

In der folgenden Tabelle wird gezeigt, wie mit dem Parameter für die Zielkapazität Folgendes definiert wird:

• Die Zielkapazität für das gesamte Back-End
• Die erwartete Zielkapazität für jede Instanz oder jeden Endpunkt

Wie dargestellt, sind die Einstellungen max-rate-per-instance und max-rate-per-endpoint Proxys für die Berechnung einer maximalen Zielrate von HTTP-Anfragen für die gesamte Instanzgruppe oder die gesamte zonale NEG:

• In einer Instanzgruppe mit N-Instanzen hat die Einstellung von max-rate-per-instance=X dieselbe Bedeutung wie die Einstellung von max-rate=X × N.
• In einer zonalen NEG mit N-Endpunkten hat die Einstellung von max-rate-per-endpoint=X dieselbe Bedeutung wie die Einstellung von max-rate=X × N.

Balancing-Modus „Auslastung”

Der Balancing-Modus UTILIZATION hat keine erforderliche Zielkapazität. Sie haben eine Reihe von Optionen, die vom Backend-Typ abhängig sind, wie in der Tabelle im folgenden Abschnitt zusammengefasst.

Die Zielkapazität max-utilization kann nur pro Instanzgruppe angegeben und nicht auf eine bestimmte VM in der Gruppe angewendet werden.

Der Balancing-Modus UTILIZATION hat keine erforderliche Zielkapazität. Wenn Sie die Trusted Cloud Console verwenden, um einem Backend-Dienst eine Backend-Instanzgruppe hinzuzufügen, legt dieTrusted Cloud Console den Wert von max-utilization auf 0,8 (80%) fest, wenn der UTILIZATION-Balancing-Modus ausgewählt ist. Zusätzlich zu max-utilization unterstützt der UTILIZATION-Balancing-Modus komplexere Zielkapazitäten, wie in der Tabelle im folgenden Abschnitt zusammengefasst.

Balancing-Modus für benutzerdefinierte Messwerte

Mit dem CUSTOM_METRICS-Balancing-Modus können Sie eigene benutzerdefinierte Messwerte definieren, mit denen bestimmt wird, wie die Last verteilt wird. Mit benutzerdefinierten Messwerten können Sie das Verhalten der Traffic-Verteilung Ihres Load-Balancers so konfigurieren, dass es auf Messwerten basiert, die für Ihre Anwendungs- oder Infrastrukturanforderungen spezifisch sind, anstatt auf den standardmäßigen Auslastungs- oder ratenbasierten Messwerten vonTrusted Cloud.

Weitere Informationen finden Sie unter Benutzerdefinierte Messwerte für Application Load Balancer.

Balancing-Modus eines Load-Balancers ändern

Bei einigen Load-Balancern oder Load-Balancer-Konfigurationen können Sie den Balancing-Modus nicht ändern, da der Backend-Dienst nur einen möglichen Balancing-Modus hat. Bei anderen ist es jedoch möglich, den Balancing-Modus zu ändern, da diesen Backend-Diensten je nach verwendetem Backend mehrere Modi zur Verfügung stehen.

Informationen dazu, welche Balancing-Modi für jeden Load-Balancer unterstützt werden, finden Sie in der Tabelle: Für jeden Load-Balancer verfügbare Balancing-Modi.

Balancing-Modi und Einstellungen für die Zielkapazität

Bei Produkten, die eine Angabe der Zielkapazität unterstützen, ist die Zielkapazität kein Schutzschalter. Wenn das konfigurierte maximale Zielkapazitätslimit in einer bestimmten Zone erreicht ist, werden neue Anfragen oder Verbindungen auf andere Zonen verteilt, in denen Anfragen oder Verbindungen nicht mit der Zielkapazität verarbeitet werden. Wenn alle Zonen die Zielkapazität erreicht haben, werden neue Anfragen oder Verbindungen durch Überfüllung verteilt.

Application Load Balancer und Cloud Service Mesh

In dieser Tabelle sind die verfügbaren Kombinationen aus Balancing-Modus und Zielkapazität für Application Load Balancer und Cloud Service Mesh aufgeführt.

Proxy-Network-Load-Balancer

In dieser Tabelle sind die verfügbaren Kombinationen aus Balancing-Modus und Zielkapazität für Proxy-Network Load Balancer aufgeführt.

Passthrough-Network-Load-Balancer

In dieser Tabelle sind die verfügbaren Kombinationen aus Balancing-Modus und Zielkapazität für Passthrough-Network Load Balancer aufgeführt.

Kapazitätsskalierer

Verwenden Sie den Kapazitätsskalierer, um die Zielkapazität (maximale Auslastung, maximale Rate oder maximale Verbindungen) zu skalieren, ohne dabei die Zielkapazität zu ändern.

Die Referenzdokumentation zu Trusted Cloud finden Sie hier:

• Google Cloud CLI: Kapazitätsskalierer
• API:
  • Regional

Sie können den Kapazitätsskalierer anpassen, um die effektive Zielkapazität zu skalieren, ohne einen der --max-*-Parameter explizit zu ändern.

Sie können den Kapazitätsskalierer auf einen dieser Werte setzen:

• Der Standardwert ist 1. Das bedeutet, dass die Gruppe bis zu 100 % der konfigurierten Kapazität bereitstellt (je nach balancingMode).
• Der Wert 0 bedeutet, dass die Gruppe vollständig per Drain beendet wurde. Sie bietet 0 % der verfügbaren Kapazität. Sie können die Einstellung 0 nicht konfigurieren, wenn nur ein Backend mit dem Backend-Dienst verbunden ist.
• Ein Wert zwischen 0.1 (10 %) to 1.0 (100 %).

Die folgenden Beispiele veranschaulichen, wie der Kapazitätsskalierer in Verbindung mit der Einstellung der Zielkapazität funktioniert.

• Wenn der Balancing-Modus RATE lautet, die max-rate auf 80 RPS festgelegt und der Kapazitätsskalierer 1.0 ist, dann ist die verfügbare Kapazität auch 80 RPS.

• Wenn der Balancing-Modus RATE lautet, ist max-rate auf 80 RPS festgelegt und der Kapazitätsskalierer ist 0.5, die verfügbare Kapazität ist 40 RPS (0.5 times 80).

• Wenn der Balancing-Modus RATE ist, diemax-rate auf 80 RPS festgelegt ist und der Kapazitätsskalierer 0.0 ist, dann ist die verfügbare Kapazität null (0).

Load-Balancing-Richtlinie für Dienste

Eine Load-Balancing-Richtlinie für Dienste (serviceLbPolicy) ist eine Ressource, die dem Backend-Dienst des Load Balancers zugeordnet ist. Damit können Sie die Parameter anpassen, die beeinflussen, wie der Traffic innerhalb der Backends verteilt wird, die einem Backend-Dienst zugeordnet sind:

• Passen Sie den Load-Balancing-Algorithmus an, der verwendet wird, um zu bestimmen, wie Traffic auf Regionen oder Zonen verteilt wird.
• Aktivieren Sie den automatischen Kapazitätsausgleich, damit der Load Balancer Traffic von fehlerhaften Back-Ends schnell leeren kann.

Außerdem können Sie bestimmte Back-Ends als bevorzugte Back-Ends festlegen. Diese Back-Ends müssen für die Kapazität verwendet werden (d. h. die Zielkapazität, die vom Balancing-Modus des Back-Ends angegeben wird), bevor Anfragen an die verbleibenden Back-Ends gesendet werden.

Weitere Informationen finden Sie unter Erweiterte Load-Balancing-Optimierungen mit einer Dienst-Load-Balancing-Richtlinie.

Load-Balancing-Richtlinie für den Ort

Bei einem Backend-Dienst beruht die Trafficverteilung auf dem Balancing-Modus und einer Load-Balancing-Richtlinie für den Ort. Der Balancing-Modus bestimmt den Anteil des Traffics, der an jedes Backend (Instanzgruppe oder -NEG) gesendet werden soll. Die Richtlinie für den Ort des Load-Balancing (LocalityLbPolicy) bestimmt dann, wie der Traffic auf Instanzen oder Endpunkte innerhalb jeder Zone verteilt wird. Bei regional verwalteten Instanzgruppen gilt die Richtlinie für den Ort für jede einzelne Zone.

Die Load-Balancing-Richtlinie für den Ort wird pro Backend-Dienst konfiguriert. Diese Einstellungen sind verfügbar:

• ROUND_ROBIN (Standard): Dies ist die Standardeinstellung für die Load-Balancing-Richtlinie für den Ort, bei der der Load-Balancer ein fehlerfreies Back-End im Round-Robin-Verfahren auswählt.

• WEIGHTED_ROUND_ROBIN: Der Load-Balancer verwendet nutzerdefinierte benutzerdefinierte Messwerte, um die optimale Instanz oder den optimalen Endpunkt im Backend für die Anfrageabwicklung auszuwählen.

• LEAST_REQUEST: Ein O(1)-Algorithmus, bei dem der Load Balancer zwei zufällige intakte Hosts und den Host mit weniger aktiven Anfragen auswählt.

• RING_HASH: Dieser Algorithmus implementiert konsistente Hashfunktion für Backends. Der Algorithmus hat die Eigenschaft, dass das Hinzufügen oder Entfernen eines Hosts aus einem Set von N Hosts sich nur auf 1/N der Anfragen auswirkt.

• RANDOM: Der Load-Balancer wählt einen zufälligen intakten Host aus.

• ORIGINAL_DESTINATION: Der Load-Balancer wählt ein Backend basierend auf den Client-Verbindungs-Metadaten aus. Verbindungen werden zur ursprünglichen Ziel-IP-Adresse geöffnet, die in der eingehenden Clientanfrage angegeben ist, bevor die Anfrage an den Load Balancer weitergeleitet wurde.

  ORIGINAL_DESTINATION wird für globale und regionale externe Application Load Balancer nicht unterstützt.

• MAGLEV: Implementiert konsistente Hashfunktion für Backends und kann als Ersatz für die RING_HASH-Richtlinie verwendet werden. Maglev ist nicht so stabil wie RING_HASH, bietet aber schnellere Build-Zeiten von Nachschlagetabellen und Host-Auswahlzeiten. Weitere Informationen zu Maglev finden Sie im Maglev-Whitepaper.

• WEIGHTED_MAGLEV: Implementiert das gewichtete Load-Balancing pro Instanz mithilfe von Gewichtungen, die von Systemdiagnosen gemeldet werden. Wenn diese Richtlinie verwendet wird, muss der Backend-Dienst eine Nicht-Legacy-HTTP-basierte Systemdiagnose konfigurieren. Die Systemdiagnoseantworten müssen das nicht standardmäßige HTTP-Antwortheader-Feld X-Load-Balancing-Endpoint-Weight enthalten, um die Gewichtungen pro Instanz anzugeben. Load-Balancing-Entscheidungen werden auf Grundlage der gewichteten Werte pro Instanz getroffen, die in den zuletzt verarbeiteten Antworten auf die Systemdiagnose gemeldet werden, sofern jede Instanz einen gültigen gewichteten Wert oder UNAVAILABLE_WEIGHT meldet. Andernfalls bleibt das Load Balancing gleich gewichtet.

  WEIGHTED_MAGLEV wird nur für externe Passthrough-Network-Load-Balancer unterstützt. Ein Beispiel finden Sie unter Gewichtetes Load Balancing für externe Passthrough-Network Load Balancer einrichten.

Das Konfigurieren einer Load Balancing-Richtlinie für den Ort wird nur für Backend-Dienste unterstützt, die mit den folgenden Load Balancern verwendet werden:

• Globaler externer Application Load Balancer
• Regionaler externer Application Load Balancer
• Regionsübergreifender interner Application Load Balancer
• Regionaler interner Application Load Balancer
• Externer Passthrough-Network Load Balancer

Der effektive Standardwert der Load Balancing-Richtlinie für den Ort (localityLbPolicy) ändert sich entsprechend den Einstellungen für die Sitzungsaffinität. Wenn die Sitzungsaffinität nicht konfiguriert ist, d. h., wenn sie den Standardwert NONE beibehält, ist der Standardwert für localityLbPolicy ROUND_ROBIN. Wenn die Sitzungsaffinität auf einen anderen Wert als NONE festgelegt ist, ist der Standardwert für localityLbPolicy MAGLEV.

Sie können eine Load Balancing-Richtlinie für den Ort mit derTrusted Cloud Console, gcloud (--locality-lb-policy) oder der API (localityLbPolicy) konfigurieren.

Backend-Teilmengeneinstellung

Die Backend-Teileinstellung ist eine optionale Funktion, die die Leistung und Skalierbarkeit verbessert, indem jeder der Proxyinstanzen eine Teilmenge der Backends zugewiesen wird.

Die Backend-Teileinstellung wird für Folgendes unterstützt:

• Regionaler interner Application Load Balancer
• Interner Passthrough-Network Load Balancer

Backend-Teileinstellung für regionale interne Application Load Balancer

Bei regionalen internen Application Load Balancern weist die Backend-Teilmengeneinstellung jeder Proxy-Instanz automatisch nur eine Teilmenge der Backends im regionalen Backend-Dienst zu. Standardmäßig öffnet jede Proxy-Instanz Verbindungen zu allen Backends innerhalb eines Backend-Dienstes. Wenn die Anzahl der Proxy-Instanzen und der Back-Ends beide offene Verbindungen zu allen Back-Ends haben, kann dies zu Leistungsproblemen führen.

Durch Aktivieren der Teileinstellung öffnet jeder Proxy nur Verbindungen zu einer Teilmenge der Backends, wodurch die Anzahl der Verbindungen reduziert wird, die für jedes Backend offen sind. Wenn Sie die Anzahl der gleichzeitig offenen Verbindungen zu jedem Backend reduzieren, kann die Leistung sowohl für die Backends als auch für die Proxys verbessert werden.

Das folgende Diagramm zeigt einen Load-Balancer mit zwei Proxys. Ohne Backend-Teilmenge wird der Traffic von beiden Proxys auf alle Backends im Backend-Dienst 1 verteilt. Wenn die Backend-Teileinstellung aktiviert ist, wird der Traffic von jedem Proxy auf eine Teilmenge der Backends verteilt. Traffic von Proxy 1 wird an die Backends 1 und 2 verteilt und Traffic von Proxy 2 an Backend 3 und 4 verteilt.

Sie können den Load-Balancing-Traffic zu den Back-Ends zusätzlich optimieren, indem Sie die Richtlinie localityLbPolicy festlegen. Weitere Informationen finden Sie unter Trafficrichtlinien.

Informationen zum Einrichten der Backend-Teilmengeneinstellung für interne Application Load Balancer finden Sie unter Backend-Teilmengeneinstellung konfigurieren.

Einschränkungen im Zusammenhang mit der Backend-Teilmengeneinstellung für den internen Application Load Balancer

• Die Backend-Teilmengeneinstellung ist zwar so konzipiert, dass alle Backend-Instanzen weiterhin gut ausgelastet sind, sie kann aber zu einer gewissen Verzerrung des Trafficvolumens führen, das jedes Backend erhält. Das Festlegen von localityLbPolicy auf LEAST_REQUEST wird für Backend-Dienste empfohlen, die empfindlich auf die Balance der Backend-Last reagieren.
• Durch Aktivieren oder Deaktivieren der Teilmengeneinstellung werden bestehende Verbindungen unterbrochen.
• Die Backend-Teileinstellung erfordert, dass die Sitzungsaffinität NONE ist (ein 5-Tupel-Hash). Andere Optionen für die Sitzungsaffinität können nur verwendet werden, wenn die Backend-Teilmengeneinstellung deaktiviert ist. Die Standardwerte der Flags --subsetting-policy und --session-affinity sind beide NONE und können jeweils nur auf einen anderen Wert festgelegt werden.

Backend-Teilmengeneinstellung für internen Passthrough-Network-Load-Balancer

Die Backend-Teilmengeneinstellung für den internen Passthrough-Network-Load-Balancer ermöglicht es Ihnen, Ihren internen Passthrough-Network-Load-Balancer zu skalieren, um eine größere Anzahl von Backend-VM-Instanzen pro internem Backend-Dienst zu unterstützen.

Informationen dazu, wie sich diese Einstellung auf dieses Limit auswirkt, finden Sie im Abschnitt „Backend-Dienste“ unter Ressourcenquoten und Limits für Load-Balancing.

Die Teilmengeneinstellung ist standardmäßig deaktiviert, wodurch die Verteilung des Back-End-Dienstes auf maximal 250 Back-End-Instanzen oder Endpunkte begrenzt ist. Wenn der Back-End-Dienst mehr als 250 Back-Ends unterstützen soll, können Sie die Teilmengeneinstellung aktivieren. Wenn die Teilmengeneinstellung aktiviert ist, wird für jede Clientverbindung eine Teilmenge von Back-End-Instanzen ausgewählt.

Das folgende Diagramm zeigt ein skaliertes Modell des Unterschieds zwischen diesen beiden Betriebsmodi.

Ohne die Teilmengeneinstellung ist der gesamte Satz fehlerfreier Back-Ends besser genutzt und neue Clientverbindungen werden gemäß der Traffic-Verteilung auf alle fehlerfreien Back-Ends verteilt. Teilmengeneinstellung setzt Load-Balancing-Einschränkungen ein, ermöglicht dem Load-Balancer jedoch, mehr als 250 Back-Ends zu unterstützen.

Eine Konfigurationsanleitung finden Sie unter Teilmengeneinstellung.

Einschränkungen im Zusammenhang mit der Backend-Teilmengeneinstellung für den internen Passthrough-Network-Load-Balancer

• Wenn die Teilmengeneinstellung aktiviert ist, erhalten nicht alle Back-Ends Traffic von einem bestimmten Absender, auch wenn die Anzahl der Back-Ends gering ist.
• Die maximale Anzahl von Backend-Instanzen, wenn die Teilmengeneinstellung aktiviert ist, finden Sie auf der Seite "Kontingente".
• Für die Teilmengeneinstellung wird nur 5-Tupel-Sitzungsaffinität unterstützt.
• Die Paketspiegelung wird bei der Teilmengeneinstellung nicht unterstützt.
• Durch Aktivieren oder Deaktivieren der Teilmengeneinstellung werden bestehende Verbindungen unterbrochen.
• Wenn lokale Clients auf einen internen Passthrough-Network-Load-Balancer zugreifen müssen, kann die Teilmengeneinstellung die Anzahl der Back-Ends, die Verbindungen von Ihren lokalen Clients erhalten, erheblich reduzieren. Dies liegt daran, dass die Region des Cloud VPN-Tunnels oder des Cloud Interconnect-VLAN-Anhangs die Teilmenge der Back-Ends des Load-Balancers bestimmt. Alle Cloud VPN- und Cloud Interconnect-Endpunkte in einer bestimmten Region verwenden dieselbe Teilmenge. Unterschiedliche Teilmengen werden in unterschiedlichen Regionen verwendet.

Preise für Backend-Teilmengen

Für die Verwendung der Backend-Teileinstellung fallen keine Kosten an. Weitere Informationen finden Sie unter Alle Netzwerkpreise.

Sitzungsaffinität

Mit der Sitzungsaffinität können Sie steuern, wie der Load-Balancer Back-Ends für neue Verbindungen auf vorhersehbare Weise auswählt, solange die Anzahl der fehlerfreien Back-Ends konstant bleibt. Dies ist nützlich für Anwendungen, bei denen mehrere Anfragen eines bestimmten Nutzers an dasselbe Backend oder denselben Endpunkt weitergeleitet werden müssen. Zu diesen Anwendungen gehören in der Regel zustandsorientierte Server, die von der Anzeigenbereitstellung, Spielen oder Diensten mit hohem internen Caching verwendet werden.

Trusted Cloud -Load-Balancer bieten Sitzungsaffinität auf Best-Effort-Basis. Faktoren wie das Ändern des Status der Backend-Systemdiagnose, das Hinzufügen oder Entfernen von Backends, Änderungen an den Backend-Gewichtungen (einschließlich des Aktivierens oder Deaktivierens des gewichteten Load-Balancings) oder Änderungen an der Backend-Auslastung, entsprechend der Messung durch den Balancing-Modus, können die Sitzungsaffinität beeinträchtigen.

Das Load-Balancing mit Sitzungsaffinität funktioniert gut, wenn die Verteilung einmaliger Verbindungen angemessen groß ist. Ein angemessen großer Wert bedeutet mindestens ein Vielfaches der Anzahl der Back-Ends. Das Testen eines Load-Balancers mit einer kleinen Anzahl von Verbindungen ermöglicht keine genaue Darstellung der Verteilung von Clientverbindungen zwischen Back-Ends.

Standardmäßig wählen alle Trusted Cloud Load-Balancer die Back-Ends mithilfe eines 5-Tupel-Hash-Werts (--session-affinity=NONE) aus:

• Quell-IP-Adresse des Pakets
• Quellport des Pakets (falls im Header des Pakets vorhanden)
• Ziel-IP-Adresse des Pakets
• Zielport des Pakets (falls im Header des Pakets vorhanden)
• Protokoll des Pakets

Weitere Informationen zur Sitzungsaffinität für Passthrough-Network Load Balancer finden Sie in den folgenden Dokumenten:

• Traffic-Verteilung für externe Passthrough-Network Load Balancer
• Traffic-Verteilung für interne Passthrough-Network Load Balancer

Weitere Informationen zur Sitzungsaffinität für Application Load Balancer finden Sie in den folgenden Dokumenten:

• Sitzungsaffinität für externe Application Load Balancer
• Sitzungsaffinität für interne Application Load Balancer

Weitere Informationen zur Sitzungsaffinität für Proxy-Network Load Balancer finden Sie in den folgenden Dokumenten:

• Sitzungsaffinität für externe Proxy-Network Load Balancer
• Sitzungsaffinität für interne Proxy-Network Load Balancer

Zeitlimit für Backend-Dienst

Die meisten Trusted Cloud Load-Balancer haben ein Zeitlimit für den Back-End-Dienst. Der Standardwert beträgt 30 Sekunden. Der maximal zulässige Bereich der Zeitüberschreitungswerte liegt zwischen 1 und 2.147.483.647 Sekunden.

• Bei externen Application Load Balancern und internen Application Load Balancern, die das HTTP-, HTTPS- oder HTTP/2-Protokoll verwenden, ist das Zeitlimit des Backend-Diensts ein Anfrage- und Antwort-Zeitlimit für HTTP(S)-Traffic.

  Weitere Informationen zum Zeitlimit des Backend-Dienstes für jeden Load-Balancer finden Sie hier:

  • Informationen zu regionalen externen Application Load Balancern finden Sie unter Zeitlimits und Wiederholungsversuche.
  • Informationen zu internen Application Load Balancern finden Sie unter Zeitlimits und Wiederholungsversuche.

• Bei externen Proxy-Network-Load-Balancern ist das Zeitlimit ein Zeitlimit bei Inaktivität. Wenn Sie mehr oder weniger Zeit vor dem Löschen der Verbindung zulassen möchten, ändern Sie den Zeitlimitwert. Dieses Zeitlimit bei Inaktivität wird auch für WebSocket-Verbindungen verwendet.

• Bei internen Passthrough-Network-Load-Balancern und externen Passthrough-Network-Load-Balancern können Sie den Wert des Zeitlimits des Backend-Dienstes mit gcloud oder der API festlegen, aber der Wert wird ignoriert. Das Zeitlimit für den Back-End-Dienst hat für diese Passthrough-Load-Balancer keine Bedeutung.

Systemdiagnosen

Jeder Backend-Dienst, dessen Backends Instanzgruppen oder zonale NEGs sind, muss eine zugehörige Systemdiagnose haben.

Wenn Sie einen Load-Balancer mit der Trusted Cloud Console erstellen, können Sie die Systemdiagnose bei Bedarf zusammen mit dem Load-Balancer erstellen oder auf eine vorhandene Systemdiagnose verweisen.

Wenn Sie einen Backend-Dienst mit den Backends einer Instanzgruppe oder einer zonalen NEG mit Google Cloud CLI oder der API erstellen, müssen Sie auf eine vorhandene Systemdiagnose verweisen. Weitere Informationen zu Art und Umfang der erforderlichen Systemdiagnose finden Sie in der Load-Balancer-Anleitung in der Übersicht über Systemdiagnosen.

Weitere Informationen finden Sie in den folgenden Dokumenten:

• Übersicht über Systemdiagnosen
• Systemdiagnosen erstellen
• gcloud-Systemdiagnose
• REST API-Systemdiagnose

IAP

Mit IAP können Sie eine zentrale Autorisierungsschicht für Anwendungen einrichten, auf die über HTTPS zugegriffen wird. Damit erhalten Sie ein Zugriffssteuerungsmodell auf Anwendungsebene und müssen keine Firewalls auf Netzwerkebene einsetzen. IAP wird von bestimmten Application Load Balancern unterstützt.

IAP ist nicht mit Cloud CDN kompatibel. Sie können nicht für denselben Backend-Dienst aktiviert werden.

Funktionen der erweiterten Trafficverwaltung

Informationen zu erweiterten Funktionen für die Trafficverwaltung, die für die mit Load-Balancern verknüpften Back-End-Dienste und URL-Zuordnungen konfiguriert werden, finden Sie unter:

• Trafficverwaltung für interne Application Load Balancer
• Trafficverwaltung für globale externe Application Load Balancer
• Übersicht über die Trafficverwaltung für regionale externe Application Load Balancer

API und gcloudReferenz

Weitere Informationen zu den Attributen der Backend-Dienstressource finden Sie in den folgenden Referenzen:

• API-Ressource für regionalen Back-End-Dienst

• gcloud compute backend-services-Seite für regionale Backend-Dienste

Nächste Schritte

Eine Dokumentation und Informationen zur Verwendung von Backend-Diensten beim Load-Balancing finden Sie in den folgenden Abschnitten:

• Benutzerdefinierte Header erstellen
• Externen Application Load Balancer erstellen
• Übersicht über externen Application Load Balancer
• Verbindungsausgleich aktivieren
• Verschlüsselung während der Übertragung in Trusted Cloud