Konzepte der Systemdiagnose

Die Google Cloud Platform (GCP) bietet Mechanismen zur Systemdiagnose, die feststellen, ob Back-Ends wie Instanzgruppen und Netzwerk-Endpunktgruppen (NEGs) ordnungsgemäß auf Traffic reagieren. In diesem Dokument werden Konzepte der Systemdiagnose für die GCP und ihre Load-Balancer behandelt.

Übersicht

Die GCP stellt globale und regionale Systemdiagnosen zur Verfügung, die konfigurierbar und regelmäßig eine Verbindung zu Back-Ends herstellen. Jeder Verbindungsversuch wird als Prüfung bezeichnet. Die GCP zeichnet den Erfolg oder Misserfolg jeder Prüfung auf.

Systemdiagnosen und Load-Balancer arbeiten zusammen. Anhand einer konfigurierbaren Anzahl von sequenziellen erfolgreichen oder fehlgeschlagenen Prüfungen berechnet die GCP einen Gesamtsystemzustand für jedes Back-End im Load-Balancer. Back-Ends, die bei der konfigurierten Anzahl von Durchläufen erfolgreich reagieren, werden als fehlerfrei betrachtet. Back-Ends, die bei der konfigurierten Anzahl von Durchläufen nicht erfolgreich reagieren, sind fehlerhaft.

Die GCP verwendet den Gesamtsystemzustand jedes Back-Ends, um zu bestimmen, ob es berechtigt ist, neue Anfragen zu erhalten. Zusätzlich zur Konfiguration von Schwellenwerten für die Prüfungshäufigkeit und den Systemzustand können Sie die Kriterien für eine erfolgreiche Prüfung konfigurieren. In diesem Dokument wird die Funktionsweise von Systemdiagnosen im Detail beschrieben.

Die GCP verwendet spezielle Routen, die in Ihrem VPC-Netzwerk für Systemdiagnosen nicht definiert sind. Umfassende Informationen hierzu finden Sie unter Load-Balancer-Rückgabepfade.

Kategorien, Protokolle und Ports der Systemdiagnose

Die GCP organisiert Systemdiagnosen nach Kategorie und Protokoll.

Es gibt zwei Systemdiagnose-Kategorien: Systemdiagnosen und Legacy-Systemdiagnosen. Jede Kategorie unterstützt einen anderen Satz von Protokollen und eine Methode zum Angeben des Ports, der für die Systemdiagnose verwendet wird. Das Protokoll und der Port legen fest, wie GCP-Systemdiagnosen Ihre Back-Ends kontaktieren. Sie können beispielsweise eine Systemdiagnose erstellen, die das HTTP-Protokoll an TCP-Port 80 verwendet, oder eine, die das TCP-Protokoll für einen benannten Port verwendet, der für eine Instanzgruppe konfiguriert ist.

Für die meisten GCP-Load-Balancer sind Systemdiagnosen (im Gegensatz zu Legacy-Systemdiagnosen) erforderlich. Für das Netzwerk-Load-Balancing sind jedoch Legacy-Systemdiagnosen erforderlich, bei denen das HTTP-Protokoll verwendet wird. Weitere Informationen zur Auswahl der Kategorie und des Protokolls sowie zur Angabe der Ports finden Sie unter Systemdiagnose auswählen.

Sie können eine Legacy-Systemdiagnose nicht in eine Systemdiagnose konvertieren oder umgekehrt.

Der Begriff Systemdiagnose bezieht sich nicht auf Legacy-Systemdiagnosen. Legacy-Systemdiagnosen werden in diesem Dokument explizit als Legacy-Systemdiagnosen bezeichnet.

Systemdiagnose auswählen

Systemdiagnosen müssen mit dem Typ des Load-Balancers und den verwendeten Back-End-Typen (Instanzgruppen oder Netzwerk-Endpunktgruppen) kompatibel sein. Dies sind die drei Faktoren, die Sie beim Erstellen einer Systemdiagnose angeben müssen:

  • Kategorie: Systemdiagnose oder Legacy-Systemdiagnose, die mit dem Load-Balancer kompatibel sein muss
  • Protokoll: bestimmt, welches Protokoll die GCP-Systeme verwenden, um Ihre Back-Ends regelmäßig zu prüfen
  • Portspezifikation: bestimmt, welche Ports für das Protokoll der Systemdiagnose verwendet werden

In der Anleitung am Ende dieses Abschnitts werden gültige Kombinationen aus Systemdiagnose-Kategorie, -Protokoll und -Portspezifikation für bestimmte Load-Balancer- und Back-End-Typen zusammengefasst.

In diesem Abschnitt bezieht sich der Begriff Instanzgruppe auf nicht verwaltete Instanzgruppen, verwaltete zonale Instanzgruppen oder verwaltete regionale Instanzgruppen.

Kategorie und Protokoll

Der Typ des Load-Balancers und die Back-End-Typen, die vom Load-Balancer verwendet werden, bestimmen die Kategorie der Systemdiagnose. Für das Netzwerk-Load-Balancing sind Legacy-Systemdiagnosen erforderlich, die das HTTP-Protokoll verwenden. Verwenden Sie für alle anderen Load-Balancer-Typen reguläre Systemdiagnosen.

Sie müssen ein Protokoll aus der Liste der Protokolle auswählen, die von der Kategorie der Systemdiagnose unterstützt werden. Es empfiehlt sich, dasselbe Protokoll wie der Load-Balancer zu verwenden. Dies ist aber weder erforderlich noch immer möglich. Netzwerk-Load-Balancer erfordern beispielsweise, dass Legacy-Systemdiagnosen verwendet werden und dass diese das HTTP-Protokoll nutzen, obwohl das Netzwerk-Load-Balancing im Allgemeinen TCP und UDP unterstützt. Für Netzwerk-Load-Balancer müssen Sie auf Ihren VMs einen HTTP-Server ausführen, damit sie auf Systemdiagnose-Prüfungen reagieren können.

In der folgenden Tabelle sind die Systemdiagnose-Kategorien und die von jeder Kategorie unterstützten Protokolle aufgeführt.

Systemdiagnose-Kategorie Unterstützte Protokolle
Systemdiagnose • HTTP
• HTTPS
• HTTP/2
• SSL
• TCP
Legacy-Systemdiagnose • HTTP
• HTTPS (Legacy-HTTPS-Systemdiagnosen werden für Netzwerk-Load-Balancer nicht unterstützt und können nicht mit den meisten anderen Load-Balancer-Typen verwendet werden.)

Kategorie und Portspezifikation

Zusätzlich zu einem Protokoll müssen Sie für Ihre Systemdiagnose eine Portspezifikation auswählen. Systemdiagnosen stellen drei Portspezifikationsmethoden bereit, und Legacy-Systemdiagnosen stellen eine Methode bereit. Nicht alle Methoden der Portspezifikation sind auf jeden Typ von Load-Balancer anwendbar. Der Typ des Load-Balancers und die Typen der verwendeten Back-Ends bestimmen, welche Portspezifikationsmethode Sie nutzen können.

Systemdiagnose-Kategorie Methoden und Bedeutungen der Portspezifikation
Systemdiagnose --port: Geben Sie eine TCP-Portnummer an.
--port-name: Geben Sie einen benannten Port einer Instanzgruppe an.
--use-serving-port: Verwenden Sie für Instanzgruppen den benannten Port, der vom Back-End-Dienst genutzt wird. Verwenden Sie für Netzwerkendpunktgruppen den an jedem Endpunkt definierten Port.
Legacy-Systemdiagnose --port: Geben Sie eine TCP-Portnummer an.

Beachten Sie hier und unten: Das Flag --use-serving-port ist mit gcloud beta compute health-checks create implementiert, jedoch nicht mit gcloud beta compute health-checks update.

Load-Balancer-Anleitung

Verwenden Sie diese Tabelle, um die richtige Kategorie und das richtige Systemdiagnose-Protokoll für einen bestimmten Load-Balancer auszuwählen.

Load-Balancer Back-End-Typ Kategorie und Bereich der Systemdiagnose Portspezifikation
Internes TCP/UDP Instanzgruppen eines regionalen internen Back-End-Dienstes Systemdiagnose (global) Portnummer (--port) oder benannter Port (--port-name).
Sie können nicht das Flag --use-serving-port verwenden, da Back-End-Dienste mit Load-Balancing-Schemas INTERNAL keinen zugeordneten benannten Port haben.
Internes HTTP(S) Netzwerk-Endpunktgruppen
eines Back-End-Dienstes
Systemdiagnose (regional) Portnummer (--port) oder
--use-serving-port
Instanzgruppen eines Back-End-Dienstes Systemdiagnose (regional) Portnummer (--port), benannter Port (--port-name) oder
--use-serving-port
Netzwerk Instanzgruppen, die Zielpools verwenden Legacy-Systemdiagnose (global)
unter Verwendung des HTTP-Protokolls
Legacy-Systemdiagnosen unterstützen nur die Portspezifikation über die Portnummer (--port).
TCP-Proxy
SSL-Proxy
HTTP(S) 1
Netzwerk-Endpunktgruppen
eines Back-End-Dienstes
Systemdiagnose (global) Portnummer (--port) oder
--use-serving-port
Instanzgruppen eines Back-End-Dienstes Systemdiagnose (global) Portnummer (--port), benannter Port (--port-name) oder
--use-serving-port

1 Unter den folgenden Umständen ist es zwar möglich, aber nicht empfehlenswert, eine Legacy-Systemdiagnose für Back-End-Dienste zu verwenden, die mit HTTP(S)-Load-Balancern verknüpft sind:

  • Die vom Back-End-Dienst verwendeten Back-Ends sind Instanzgruppen, keine Netzwerk-Endpunktgruppen.
  • Die Back-End-VMs können entweder mit HTTP oder HTTPS geprüft werden.

Funktionsweise von Systemdiagnosen

Prüfungen

Wenn Sie eine Systemdiagnose oder Legacy-Systemdiagnose erstellen, legen Sie die folgenden Flags fest oder akzeptieren deren Standardwerte. Diese Flags steuern, wie häufig jedes GCP-System zur Systemdiagnose Ihre Instanzgruppe oder Ihre NEG-Back-Ends prüft. Die GCP implementiert Prüfungen mithilfe mehrerer Systeme.

Die Einstellungen einer Systemdiagnose können nicht pro Back-End konfiguriert werden. Systemdiagnosen sind mit einem gesamten Back-End-Dienst verknüpft und Legacy-Systemdiagnosen sind einem bestimmten Zielpool oder Back-End-Dienst für bestimmte HTTP(S)-Load-Balancer zugeordnet. Daher sind die Parameter für die Prüfung für alle Back-Ends, auf die von einem bestimmten Back-End-Dienst oder Zielpool verwiesen wird, gleich.

Konfigurations-Flag Zweck Standardwert
Prüfintervall
check-interval
Das Prüfintervall ist die Zeit vom Start einer Prüfung, der von einem Prüfsystem aus erfolgt ist, bis zum Start der nächsten Prüfung, der vom selben System aus erfolgt ist. Die Einheit sind Sekunden. Wenn nicht angegeben, verwendet die GCP 5s (5 Sekunden).
Zeitlimit
timeout
Das Zeitlimit ist die Zeit, die die GCP auf eine Antwort für eine Prüfung wartet. Der Wert muss kleiner oder gleich dem Prüfintervall sein. Die Einheit sind Sekunden. Wenn nicht angegeben, verwendet die GCP 5s (5 Sekunden).

Prüfungs-IP-Bereiche

Die Quell-IP-Adressen für GCP-Prüfsysteme hängen vom Typ des Load-Balancers ab. Verwenden Sie die folgende Tabelle, um Firewall-Zulassungsregeln für eingehenden Traffic zu erstellen, die Traffic von GCP-Prüfsystemen zu Ihren Back-Ends zulassen.

Load-Balancer Prüfungs-IP-Bereiche Beispiel für Firewallregel
Intern
TCP-Proxy
SSL-Proxy
HTTP(S)
Internes HTTP(S)
35.191.0.0/16
130.211.0.0/22
Firewallregeln für alle Load-Balancer mit Ausnahme von Netzwerk-Load-Balancern
Netzwerk 35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
Firewallregeln für Netzwerk-Load-Balancer

Mehrere Prüfungen und Häufigkeit

Die GCP sendet Systemdiagnose-Prüfungen von mehreren redundanten Systemen aus den entsprechenden Quell-IP-Bereichen. Kein einzelnes Prüfsystem ist für alle Prüfungen verantwortlich. Da mehrere Systeme gleichzeitig Prüfungen ausgeben, führt der Ausfall eines Systems nicht dazu, dass die GCP den Überblick über den Back-End-Systemzustand verliert.

Die Intervall- und Zeitlimiteinstellungen, die Sie für eine Systemdiagnose konfigurieren, werden auf alle Prüfsysteme angewendet. Für ein bestimmtes Back-End zeigen Software-Zugriffslogs und tcpdump häufigere Systemdiagnose-Prüfungen als die von Ihnen konfigurierten Einstellungen an. Da mehrere Prüfsysteme Ihre Back-Ends gleichzeitig kontaktieren, führt dies zu mehr Systemdiagnose-Prüfungen, als dies mit einer Konfiguration für ein einzelnes Prüfsystem der Fall wäre.

Dies ist das erwartete Verhalten und Sie können die Anzahl der Prüfsysteme, die die GCP für Systemdiagnosen verwendet, nicht konfigurieren. Sie können jedoch die Auswirkungen mehrerer simultaner Prüfungen kalkulieren, indem Sie die folgenden Faktoren berücksichtigen:

  • Berücksichtigen Sie Folgendes, um die Prüfungshäufigkeit pro Back-End-Dienst zu schätzen:

    • Basishäufigkeit pro Back-End-Dienst: Jeder Systemdiagnose ist eine Prüfungshäufigkeit zugeordnet, die umgekehrt proportional zum konfigurierten Prüfintervall ist:

      1(Prüfintervall)

      Wenn Sie eine Systemdiagnose mit einem Back-End-Dienst verknüpfen, legen Sie eine Basishäufigkeit fest, die von jedem Prüfsystem für Back-Ends in diesem Back-End-Dienst verwendet wird.

    • Prüfungsskalierungsfaktor: Die Basishäufigkeit des Back-End-Dienstes wird mit der Anzahl der von der GCP gleichzeitig verwendeten Prüfsysteme multipliziert. Diese Zahl kann variieren, liegt jedoch in der Regel zwischen 5 und 10.

  • Mehrere Weiterleitungsregeln für interne TCP/UDP-Load-Balancer: Wenn Sie mehrere interne Weiterleitungsregeln mit jeweils unterschiedlicher IP-Adresse konfiguriert haben, die auf denselben regionalen internen Back-End-Dienst verweisen, verwendet die GCP mehrere Prüfsysteme, um jede IP-Adresse zu prüfen. Die Prüfungshäufigkeit pro Back-End-Dienst wird mit der Anzahl der konfigurierten Weiterleitungsregeln multipliziert.

  • Mehrere Weiterleitungsregeln für Netzwerk-Load-Balancer: Wenn Sie mehrere Weiterleitungsregeln konfiguriert haben, die auf denselben Zielpool verweisen, verwendet die GCP mehrere Prüfsysteme, um jede IP-Adresse zu prüfen. Die Prüfungshäufigkeit, die von jedem Back-End im Zielpool gesehen wird, wird mit der Anzahl der konfigurierten Weiterleitungsregeln multipliziert.

  • Mehrere Zielproxys für HTTP(S)-Load-Balancer: Wenn Sie mehrere Zielproxys für dieselbe URL-Zuordnung für das HTTP(S)-Load-Balancing konfiguriert haben, verwendet die GCP mehrere Prüfsysteme, um die IP-Adresse jedes Zielproxys zu prüfen. Die Prüfungshäufigkeit pro Back-End-Dienst wird mit der Anzahl der konfigurierten Zielproxys multipliziert.

  • Mehrere Zielproxys für SSL-Proxy- und TCP-Proxy-Load-Balancer: Wenn Sie mehrere Zielproxys für denselben Back-End-Dienst für SSL-Proxy- oder TCP-Proxy-Load-Balancing konfiguriert haben, verwendet die GCP mehrere Prüfsysteme, um die IP-Adresse jedes Zielproxys zu prüfen. Die Prüfungshäufigkeit pro Back-End-Dienst wird mit der Anzahl der konfigurierten Zielproxys multipliziert.

  • Summe über Back-End-Dienste: Wenn ein Back-End (z. B. eine Instanzgruppe) von mehreren Back-End-Diensten verwendet wird, werden die Back-End-Instanzen so oft kontaktiert, wie es der Häufigkeitssumme der Systemdiagnose jedes Back-End-Dienstes entspricht.

    Mit NEG-Back-Ends (Netzwerk-Endpunktgruppen) ist es schwieriger, die genaue Anzahl der Systemdiagnose-Prüfungen zu ermitteln. Beispielsweise kann derselbe Endpunkt in mehreren NEGs vorliegen, wobei diese NEGs nicht unbedingt denselben Satz von Endpunkten haben und unterschiedliche Endpunkte auf dasselbe Back-End verweisen können.

Ziel für Systemdiagnose-Pakete

GCP-Systemdiagnose-Prüfungen senden Pakete nur an die primäre Netzwerkschnittstelle jeder Back-End-Instanz. Die Ziel-IP-Adresse dieser Pakete hängt vom Typ des Load-Balancers ab:

  • Bei internen TCP/UDP-Load-Balancern und Netzwerk-Load-Balancern ist das Ziel von Systemdiagnose-Paketen die IP-Adresse der Weiterleitungsregel des Load-Balancers. Wenn mehrere Weiterleitungsregeln auf denselben Back-End-Dienst oder Zielpool verweisen, sendet die GCP Prüfungen an die IP-Adresse jeder Weiterleitungsregel. Dies kann zu einer Erhöhung der Anzahl der Prüfungen führen, wie im vorherigen Abschnitt beschrieben.
  • Bei HTTP(S)-, TCP-Proxy-, SSL-Proxy- und internen HTTP(S)-Load-Balancern, die Instanzgruppen als Back-Ends verwenden, ist das Ziel von Systemdiagnose-Paketen die primäre interne IP-Adresse, die der primären Netzwerkschnittstelle jeder Back-End-Instanz zugeordnet ist.
  • Bei HTTP(S)-, TCP-Proxy-, SSL-Proxy- und internen HTTP(S)-Load-Balancern, die Netzwerk-Endpunktgruppen als Back-Ends verwenden, ist das Ziel von Systemdiagnose-Paketen die IP-Adresse des Endpunkts, die entweder eine primäre oder sekundäre Alias-IP-Adresse sein kann.

Inhaltsbasierte Systemdiagnosen

HTTP(S)-, HTTP/2-, TCP- und SSL-Systemdiagnosen können optional inhaltsbasiert (Anfrage/Antwort) sein. Bei einer inhaltsbasierten Systemdiagnose sendet der Systemdiagnose-Prober einen Anfragestring an das Back-End. Die Systemdiagnose ist so konfiguriert, dass eine bestimmte Antwort auf die Prüfung erwartet wird.

Erfolgskriterien für HTTP, HTTPS und HTTP/2

Antworten von Prüfungen für Systemdiagnosen mit HTTP-, HTTPS- oder HTTP/2-Protokollen sind nur erfolgreich, wenn die GCP auf die gesendete Anfrage eine Antwort HTTP 200 (OK) empfängt und diese vor Ablauf des Zeitlimits der Prüfung zugestellt wird.

Die Anfragen werden an einen konfigurierbaren Anfragepfad gesendet oder an /, falls nicht angegeben. Jede Antwort wird akzeptiert, es sei denn, Sie verwenden die inhaltsbasierte Prüfung, um einen erwarteten Antwortstring bereitzustellen. Folgende Flags stehen zur Steuerung der Erfolgskriterien für HTTP-, HTTPS- und HTTP/2-Systemdiagnosen zur Verfügung:

Konfigurations-Flag Zweck
Anfragepfad
request-path
Geben Sie den URL-Pfad an, an den die GCP Prüfanfragen für die Systemdiagnose sendet.
Wenn keine Angabe gemacht wird, sendet die GCP Prüfanfragen an den Stammpfad /. Die Option request-path unterstützt keine Abfrageparameter.
Antwort
response
Mit dem optionalen Antwort-Flag können Sie eine inhaltsbasierte Systemdiagnose konfigurieren. Der erwartete Antwortstring darf höchstens 1.024 ASCII-Zeichen (Einzel-Byte-Zeichen) lang sein. Nach der Konfiguration erwartet die GCP diesen String innerhalb der ersten 1.024 Byte der Antwort zusätzlich zum Status HTTP 200 (OK).

Die Verwendung einer inhaltsbasierten Systemdiagnose ist optional. Unabhängig davon, ob Sie einen erwarteten Antwortstring angeben oder nicht, erwartet die GCP, dass das zu prüfende Back-End mit HTTP 200 (OK) antwortet. Wenn Sie eine erwartete Antwort angeben, durchsucht jeder GCP-Systemdiagnose-Prober die von Ihren Back-Ends bereitgestellte Antwort und sucht innerhalb der ersten 1.024 Byte nach dem erwarteten Antwortstring. Eine inhaltsbasierte HTTP-Systemdiagnose wird als erfolgreich betrachtet, wenn sowohl HTTP 200 (OK) empfangen wird als auch die erwartete Antwort in den ersten 1.024 Byte der zurückgegebenen Antwort gefunden wird.

Erfolgskriterien für SSL und TCP

Standardmäßig sind Antworten bei Prüfungen für Systemdiagnosen mit SSL- und TCP-Protokollen nur erfolgreich, wenn die GCP erfolgreich einen SSL- oder TCP-Handshake ausführen kann, um eine Sitzung vor dem Ablauf des Zeitlimits der Prüfung zu erstellen.

Optional können Sie nicht nur einen Handshake durchführen, sondern auch einen Anfragestring und einen erwarteten Antwortstring mit jeweils bis zu 1.024 ASCII-Zeichen (Einzel-Byte-Zeichen) angeben. Wenn ein erwarteter Antwortstring konfiguriert ist, betrachtet die GCP eine Prüfung nur dann als erfolgreich, wenn der SSL- oder TCP-Handshake abgeschlossen ist und der zurückgegebene Antwortstring mit dem erwarteten Antwortstring genau übereinstimmt. Für Systemdiagnosen mit den Protokollen SSL und TCP stehen die folgenden Kombinationen von Anfrage- und Antwort-Flags zur Verfügung:

Konfigurations-Flags Verhalten
Weder Anfrage noch Antwort angegeben
Keines dieser Flags angegeben: --request, --response
Die GCP betrachtet die Prüfung als erfolgreich, wenn die TCP- oder SSL-Sitzung vor dem Ablauf des Zeitlimits der Prüfung erstellt wird.
Sowohl Anfrage als auch Antwort angegeben
Beide Flags angegeben: --request, --response
Die GCP sendet Ihren konfigurierten Anfragestring und wartet auf den erwarteten Antwortstring. Die Prüfung ist erfolgreich, wenn vor Ablauf des Zeitlimits die TCP- oder SSL-Sitzung erstellt wird und der zurückgegebene Antwortstring mit dem erwarteten Antwortstring genau übereinstimmt.
Nur Antwort angegeben
Angegebene Flags: nur --response
Die GCP wartet auf den erwarteten Antwortstring. Die Prüfung ist erfolgreich, wenn vor Ablauf des Zeitlimits die TCP- oder SSL-Sitzung erstellt wird und der zurückgegebene Antwortstring mit dem erwarteten Antwortstring genau übereinstimmt.
Sie sollten --response nur dann allein verwenden, wenn Ihre Back-Ends mit Load-Balancing automatisch einen Antwortstring als Teil des Handshakes senden würden.
Nur Anfrage angegeben
Angegebene Flags: nur --request
Die GCP sendet Ihren konfigurierten Anfragestring. Die Prüfung ist erfolgreich, wenn vor Ablauf des Zeitlimits eine TCP- oder SSL-Sitzung erstellt wird. Die Antwort, falls vorhanden, wird nicht geprüft.

Systemzustand

Die GCP ermittelt den Gesamtsystemzustand jedes Back-Ends, das Teil des Load-Balancings ist, anhand der folgenden Konfigurations-Flags und je nachdem, ob die Prüfungen erfolgreich waren.

Konfigurations-Flag Zweck Standardwert
Schwellenwert für Intaktheit
healthy-threshold
Der Schwellenwert für Intaktheit gibt die Anzahl der aufeinanderfolgenden erfolgreichen Prüfergebnisse an, die nötig sind, damit ein Back-End als fehlerfrei gilt. Wenn keine Angabe gemacht wird, verwendet die GCP einen Schwellenwert von 2 Prüfungen.
Fehlerschwellenwert
unhealthy-threshold
Der Fehlerschwellenwert gibt die Anzahl der aufeinanderfolgenden fehlgeschlagenen Prüfergebnisse an, die nötig sind, damit ein Back-End als fehlerhaft eingestuft wird. Wenn keine Angabe gemacht wird, verwendet die GCP einen Schwellenwert von 2 Prüfungen.

Die GCP stuft Back-Ends als fehlerfrei ein, wenn der Schwellenwert für Intaktheit erreicht wurde. Fehlerfreie Back-Ends können neue Verbindungen erhalten.

Die GCP stuft Back-Ends als fehlerhaft ein, wenn der Fehlerschwellenwert erreicht wurde. Fehlerhafte Back-Ends können keine neuen Verbindungen erhalten. Vorhandene Verbindungen werden jedoch nicht sofort beendet. Stattdessen bleibt die Verbindung so lange bestehen, bis eine Zeitüberschreitung auftritt oder der Traffic unterbrochen wird. Das jeweilige Verhalten hängt vom Typ des verwendeten Load-Balancers ab.

Bestehende Verbindungen geben möglicherweise keine Antworten zurück, je nachdem, warum die Prüfung fehlgeschlagen ist. Ein fehlerhaftes Back-End kann fehlerfrei werden, wenn es den Schwellenwert für Intaktheit wieder erreicht.

Weitere Informationen

Mehr zum Konfigurieren von Systemdiagnosen erfahren Sie unter Systemdiagnosen erstellen.