Systemdiagnosen – Übersicht

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

Google Cloud 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 und jedes System zur Systemdiagnose als Prober bezeichnet. Google Cloud zeichnet den Erfolg oder Misserfolg jeder Prüfung auf.

Systemdiagnosen funktionieren mit Load-Balancern und Traffic Director. Anhand einer konfigurierbaren Anzahl von sequenziellen erfolgreichen oder fehlgeschlagenen Prüfungen berechnet Google Cloud einen Gesamtsystemzustand für jedes Back-End im Load-Balancer oder Traffic Director. 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.

Google 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. Dies wird unter Funktionsweise von Systemdiagnosen ausführlich erläutert.

Google Cloud verwendet spezielle Routen, die nicht in Ihrem Virtual Private Cloud-Netzwerk (VPC) für Systemdiagnosen definiert sind. Ausführliche Informationen finden Sie unter Load-Balancer-Rückgabepfade.

Kategorien, Protokolle und Ports der Systemdiagnose

Google Cloud organisiert Systemdiagnosen nach Kategorie und Protokoll.

Die beiden Kategorien sind Systemdiagnosen und Legacy-Systemdiagnosen. Jede Kategorie unterstützt einen anderen Satz von Protokollen und eine Methode zur Angabe des Ports, der für die Systemdiagnose verwendet wird. Das Protokoll und der Port legen fest, wie Google Cloud-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 Traffic Director und die meisten Google Cloud-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. Im nächsten Abschnitt Systemdiagnose auswählen erhalten Sie eine spezifische Anleitung zur Auswahl der Kategorie, des Protokolls und der Ports.

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

Systemdiagnose auswählen

Systemdiagnosen müssen mit Traffic Director oder dem Typ des Load-Balancers und den vom Produkt verwendeten Back-End-Typen (Instanzgruppen oder zonale NEGs) kompatibel sein. Beim Erstellen einer Systemdiagnose müssen Sie die folgenden drei Faktoren angeben:

  • Kategorie: Systemdiagnose oder Legacy-Systemdiagnose, die mit dem Load-Balancer kompatibel sein muss
  • Protokoll: bestimmt, welches Protokoll die Google Cloud-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.

Weitere Informationen zu den Arten von Systemdiagnosen, die von den verschiedenen Load-Balancern unterstützt werden, finden Sie unter Systemdiagnosen.

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. Alle anderen Load-Balancer verwenden 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 einen HTTP-Server auf Ihren Instanzen der virtuellen Maschine (VM-Instanzen) ausführen, damit sie auf Systemdiagnoseprüfungen reagieren können.

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

Systemdiagnose-Kategorie Unterstützte Protokolle
Systemdiagnose • gRPC
• HTTP
• HTTPS
• HTTP/2 (mit TLS)
• 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 vom Load-Balancer 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.
--use-serving-port:
• Verwenden Sie für Instanzgruppen den benannten Port, der vom Back-End-Dienst genutzt wird.
• Verwenden Sie für zonale NEGs den an jedem Endpunkt definierten Port.
Legacy-Systemdiagnose --port: Geben Sie eine TCP-Portnummer an.

Load-Balancer-Anleitung

Diese Tabelle enthält die unterstützte Kategorie, den Bereich und die Portspezifikation für jeden Google Cloud-Load-Balancer und Back-End-Typ.

Load-Balancer Back-End-Typ Kategorie und Bereich der Systemdiagnose Portspezifikation
Internes TCP/UDP-Load-Balancing 1 Instanzgruppen Systemdiagnose (global oder regional)
  • Benutzerdefinierte Portnummer (--port)
Internes HTTP(S)-Load-Balancing Zonale NEGs Systemdiagnose (regional)
  • Benutzerdefinierte Portnummer (--port)
  • Portnummer des Endpunkts (--use-serving-port)
Instanzgruppen Systemdiagnose (regional)
  • Benutzerdefinierte Portnummer (--port)
  • Benannter Port des Back-End-Dienstes (--use-serving-port)
Netzwerk-Load-Balancing Instanzen
in Zielpools
Legacy-Systemdiagnose (global), die das HTTP-Protokoll verwendet Legacy-Systemdiagnosen unterstützen nur die Spezifikation für die Portnummer (--port).
Externes HTTP(S)-Load-Balancing 2

TCP-Proxy-Load-Balancing

SSL-Proxy-Load-Balancing
Zonale NEGs Systemdiagnose (global)
  • Benutzerdefinierte Portnummer (--port)
  • Portnummer des Endpunkts (--use-serving-port)
Instanzgruppen Systemdiagnose (global)
  • Benutzerdefinierte Portnummer (--port)
  • Benannter Port des Back-End-Dienstes (--use-serving-port)

1 Sie können nicht das Flag --use-serving-port verwenden, da interne Back-End-Dienste keinen zugeordneten benannten Port haben.
2 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 Back-Ends sind Instanzgruppen, keine zonalen NEGs.
  • Die Back-End-VMs liefern Traffic, der entweder HTTP- oder HTTPS-Protokolle verwendet.

Funktionsweise von Systemdiagnosen

In den folgenden Abschnitten wird beschrieben, wie Systemdiagnosen funktionieren.

Prüfungen

Wenn Sie eine Systemdiagnose oder Legacy-Systemdiagnose erstellen, legen Sie die folgenden Flags fest oder akzeptieren deren Standardwerte. Jede von Ihnen erstellte Systemdiagnose oder Legacy-Systemdiagnose wird von mehreren Prüfungen implementiert. Diese Flags steuern, wie häufig jede Google Cloud-Systemdiagnoseprüfung Instanzgruppen-Back-Ends oder Endpunkte in zonalen NEG-Back-Ends prüft.

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 entweder einem vollständigen Zielpool (für Netzwerk-Load-Balancing) oder einem Back-End-Dienst (für bestimmte externe HTTP(S)-Load-Balancing-Konfigurationen) 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, die von einem Prober aus erfolgt ist, bis zum Start der nächsten Prüfung, die vom selben Prober aus erfolgt ist. Die Einheit sind Sekunden. Wenn keine Angabe gemacht wird, verwendet Google Cloud 5s (5 Sekunden).
Zeitlimit
timeout
Das Zeitlimit ist die Zeit, die Google Cloud auf eine Antwort von einer Prüfung wartet. Der Wert muss kleiner oder gleich dem Prüfintervall sein. Die Einheit sind Sekunden. Wenn keine Angabe gemacht wird, verwendet Google Cloud 5s (5 Sekunden).

Prüfungs-IP-Bereiche und Firewallregeln

Damit Systemdiagnosen funktionieren, müssen Sie allow-Firewallregeln für eingehenden Traffic erstellen, damit Traffic aus Google Cloud-Probern eine Verbindung zu Ihren Back-Ends herstellen kann.

Die folgende Tabelle zeigt die zulässigen Quell-IP-Bereiche:

Produkt Quell-IP-Bereiche der Prüfung Beispiel für Firewallregel
Internes TCP/UDP-Load-Balancing
Internes HTTP(S)-Load-Balancing
Externes HTTP(S)-Load-Balancing
SSL-Proxy-Load-Balancing
TCP-Proxy-Load-Balancing
Traffic Director
35.191.0.0/16
130.211.0.0/22
Firewallregeln für alle Produkte außer Netzwerk-Load-Balancer
Netzwerk-Load-Balancing 35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
Firewallregeln für Netzwerk-Load-Balancer

Bedeutung von Firewallregeln

Google Cloud erfordert, dass Sie die erforderlichen allow-Firewallregeln für eingehenden Traffic erstellen, um Traffic von Probern zu Ihren Back-Ends zuzulassen. Sie sollten diese Regeln nur auf Protokolle und Ports beschränken, die mit denjenigen übereinstimmen, die von Ihren Systemdiagnosen verwendet werden. Verwenden Sie bei den Quell-IP-Bereichen die im vorherigen Abschnitt aufgeführten dokumentierten Prüfungs-IP-Bereiche.

Wenn Sie keine allow-Firewallregeln für eingehenden Traffic haben, die das Protokoll, den Port und den Quell-IP-Bereich zulassen, die von Ihrer Systemdiagnose verwendet werden, wird der eingehende Traffic aus allen Quellen von der implizierten deny-Firewallregel für eingehenden Traffic blockiert. Wenn Prober Ihre Back-Ends nicht kontaktieren können, kategorisiert der Google Cloud-Load-Balancer alle Back-Ends als fehlerhaft. Das Verhalten, wenn alle Back-Ends fehlerhaft sind, hängt vom Typ des Load-Balancers ab:

  • Ein externer HTTP(S)-Load-Balancer gibt HTTP 502-Antworten an Clients zurück, wenn alle Back-Ends fehlerhaft sind.

  • Ein interner HTTP(S)-Load-Balancer gibt HTTP 503-Antworten an Clients zurück, wenn alle Back-Ends fehlerhaft sind.

  • Bei SSL-Proxy-Load-Balancern und TCP-Proxy-Load-Balancern tritt eine Zeitüberschreitung auf, wenn alle Back-Ends fehlerhaft sind.

  • Ein Netzwerk-Load-Balancer versucht als letztes Mittel, den Traffic auf alle Back-End-VMs zu verteilen, wenn sie alle fehlerhaft sind.

  • Ein interner TCP/UDP-Load-Balancer ohne konfiguriertes Failover verteilt den Traffic als letzte Option auf alle Back-End-VMs, wenn sie alle fehlerhaft sind. Sie können dieses Verhalten deaktivieren, wenn Sie das Failover aktivieren.

Sicherheitsaspekte für Prüfungs-IP-Bereiche

Beachten Sie bei der Planung von Systemdiagnosen und den erforderlichen Firewallregeln die folgenden Informationen:

  • Die Prüfungs-IP-Bereiche gehören Google. Google Cloud verwendet spezielle Routen außerhalb Ihres VPC-Netzwerks, jedoch innerhalb des Produktionsnetzwerks von Google, um die Kommunikation mit Probern zu vereinfachen.

  • Google verwendet die Prüfungs-IP-Bereiche ausschließlich zum Durchführen von Systemdiagnoseprüfungen und zum Senden von Traffic aus Google Front-Ends (GFEs) für externe HTTP(S)-Load-Balancer, SSL-Proxy-Load-Balancer und TCP-Proxy-Load-Balancer. Wenn ein Paket aus dem Internet empfangen wird, einschließlich der externen IP-Adresse einer Compute Engine-Instanz oder eines Google Kubernetes Engine-Knotens (GKE), und die Quell-IP-Adresse des Pakets innerhalb eines Prüfungs-IP-Bereichs liegt, löscht Google das Paket.

  • Die Prüfungs-IP-Bereiche sind ein vollständiger Satz möglicher IP-Adressen, die von Google Cloud-Probern verwendet werden. Wenn Sie tcpdump oder ein ähnliches Tool verwenden, beobachten Sie möglicherweise nicht den Traffic aus allen IP-Adressen in allen Prüfungs-IP-Bereichen. Sie sollten allow-Firewallregeln für eingehenden Traffic für den ausgewählten Load-Balancer erstellen. Dazu verwenden Sie alle Prüfungs-IP-Bereiche als Quellen, da Google Cloud neue Prober automatisch ohne Benachrichtigung implementieren kann.

Mehrere Prüfungen und Häufigkeit

Google Cloud sendet Systemdiagnoseprüfungen von mehreren redundanten Systemen, den sogenannten Probern. Prober verwenden bestimmte Quell-IP-Bereiche. Google Cloud verlässt sich bei der Implementierung einer Systemdiagnose nicht nur auf einen einzelnen Prober. Stattdessen bewerten mehrere Prober die Instanzen in Instanzgruppen-Back-Ends oder die Endpunkte in zonalen NEG-Back-Ends gleichzeitig. Wenn ein Prober fehlschlägt, erfasst Google Cloud die Systemzustände des Back-Ends weiterhin.

Die Intervall- und Zeitlimiteinstellungen, die Sie für eine Systemdiagnose konfigurieren, werden auf alle Prober angewendet. Für ein bestimmtes Back-End zeigen Software-Zugriffslogs und tcpdump häufigere Prüfungen als die von Ihnen konfigurierten Einstellungen an.

Dieses Verhalten ist normal und Sie können die Anzahl der Prober, die Google Cloud 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 Prober 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 Google Cloud gleichzeitig verwendeten Prober 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 Google Cloud mehrere Prober, 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 Google Cloud mehrere Prober, um jede IP-Adresse zu prüfen. Die Prüfungshäufigkeit, die von jeder Instanz im Zielpool angezeigt wird, wird mit der Anzahl der konfigurierten Weiterleitungsregeln multipliziert.

  • Mehrere Zielproxys für externe HTTP(S)-Load-Balancer: Wenn Sie mehrere Zielproxys konfiguriert haben, die Traffic an dieselbe URL-Zuordnung für externes HTTP(S)-Load-Balancing leiten, verwendet Google Cloud mehrere Prober, 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-Load-Balancer und TCP-Proxy-Load-Balancer: Wenn Sie mehrere Zielproxys konfiguriert haben, die Traffic an denselben Back-End-Dienst für SSL-Proxy-Load-Balancing oder TCP-Proxy-Load-Balancing leiten, verwendet Google Cloud mehrere Prober, um die jedem Zielproxy zugeordnete IP-Adresse 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 ist es schwieriger, die genaue Anzahl der Systemdiagnoseprüfungen zu ermitteln. Beispielsweise kann derselbe Endpunkt in mehreren zonalen NEGs vorliegen, wobei diese zonalen NEGs nicht unbedingt denselben Satz von Endpunkten haben und unterschiedliche Endpunkte auf dasselbe Back-End verweisen können.

Ziel für Prüfungspakete

In der folgenden Tabelle sind die Netzwerkschnittstelle und Ziel-IP-Adressen aufgeführt, an die Systemdiagnose-Prober Pakete abhängig vom Typ des Load-Balancers senden.

Für Netzwerk-Load-Balancer und interne TCP/UDP-Load-Balancer muss die Anwendung an die IP-Adresse des Load-Balancers (oder eine beliebige IP-Adresse 0.0.0.0) gebunden werden.

Load-Balancer Zielnetzwerkschnittstelle IP-Adresse des Ziels
Internes TCP/UDP-Load-Balancing Die Netzwerkschnittstelle der Instanz, die sich im Netzwerk befindet, das für den internen Back-End-Dienst angegeben wurde. Falls nicht angegeben, wird die primäre Netzwerkschnittstelle (nic0) verwendet.

Weitere Informationen finden Sie unter Back-End-Dienste und Netzwerkschnittstellen.
Die IP-Adresse der internen Weiterleitungsregel.

Wenn mehrere Weiterleitungsregeln auf denselben Back-End-Dienst verweisen, sendet Google Cloud Prüfungen an die IP-Adresse jeder Weiterleitungsregel. Dies kann zu einer höheren Anzahl von Prüfungen führen.
Netzwerk-Load-Balancing Primäre Netzwerkschnittstelle (nic0) IP-Adresse der externen Weiterleitungsregel

Wenn mehrere Weiterleitungsregeln auf denselben Zielpool verweisen, sendet Google Cloud Prüfungen an die IP-Adresse jeder Weiterleitungsregel. Dies kann zu einer höheren Anzahl von Prüfungen führen.
Externes HTTP(S)-Load-Balancing

Internes HTTP(S)-Load-Balancing

SSL-Proxy-Load-Balancing

TCP-Proxy-Load-Balancing

Primäre Netzwerkschnittstelle (nic0)
  • Für Instanzgruppen-Back-Ends die primäre interne IP-Adresse, die der primären Netzwerkschnittstelle (nic0) jeder Instanz zugeordnet ist.
  • Für zonale NEG-Back-Ends die IP-Adresse des Endpunkts, die entweder eine primäre interne IP-Adresse oder ein Alias-IP-Bereich (der primären Netzwerkschnittstelle nic0 auf der Instanz, auf der der Endpunkt gehostet wird) ist.

Erfolgskriterien für HTTP, HTTPS und HTTP/2

Wenn eine Systemdiagnose das HTTP-, HTTPS- oder HTTP/2-Protokoll verwendet, muss für jede Prüfung ein HTTP 200 (OK)-Antwortcode vor dem Ablauf des Zeitlimits der Prüfung gesendet werden. Außerdem haben Sie folgende Möglichkeiten:

  • Sie können Google Cloud-Prober so konfigurieren, dass HTTP-Anfragen an einen bestimmten Anfragepfad gesendet werden. Wenn Sie keinen Anfragepfad angeben, wird / verwendet.

  • Wenn Sie eine inhaltsbasierte Systemdiagnose konfigurieren, indem Sie einen erwarteten Antwortstring festlegen, muss Google Cloud den erwarteten String innerhalb der ersten 1.024 Byte der HTTP-Antwort finden.

  • Wenn Sie einen erwarteten Antwortstring konfigurieren, muss jede Google Cloud-Systemdiagnoseprüfung den erwarteten Antwortstring innerhalb der ersten 1.024 Byte der tatsächlichen Antwort aus Ihren Back-Ends finden.

Die folgenden Kombinationen von Anfragepfad- und Antwortstring-Flags sind für Systemdiagnosen verfügbar, die HTTP-, HTTPS- und HTTP/2-Protokolle verwenden.

Konfigurations-Flag Erfolgskriterien
Anfragepfad
request-path
Geben Sie den URL-Pfad an, an den Google Cloud Prüfungsanfragen für die Systemdiagnose sendet.
Wenn keine Angabe gemacht wird, sendet Google Cloud Prüfungsanfragen 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 Google Cloud diesen String innerhalb der ersten 1.024 Byte der Antwort zusätzlich zum Status HTTP 200 (OK).

Erfolgskriterien für SSL und TCP

Sofern Sie keinen erwarteten Antwortstring angeben, sind die Prüfungen für Systemdiagnosen, die SSL- und TCP-Protokolle verwenden, erfolgreich, wenn die beiden folgenden Basisbedingungen zutreffen:

  • Jeder Google Cloud-Prober kann vor dem konfigurierten Ablauf des Zeitlimits der Prüfung einen SSL- oder TCP-Handshake erfolgreich durchführen.
  • Bei TCP-Systemdiagnosen wird die TCP-Sitzung entweder von Ihrem Back-End oder dem Google Cloud-Prober ordnungsgemäß beendet oder Ihr Back-End sendet ein TCP-RST-Paket (Reset), während die TCP-Sitzung für den Prober noch läuft.

Wenn Ihr Back-End ein TCP-RST-Paket sendet, um eine TCP-Sitzung für eine TCP-Systemdiagnose zu schließen, nachdem der Google Cloud-Prober eine ordnungsgemäße TCP-Beendigung eingeleitet hat, könnte die Prüfung als nicht erfolgreich eingestuft werden.

Sie können eine inhaltsbasierte Systemdiagnose erstellen, wenn Sie 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 Google Cloud eine Prüfung nur dann als erfolgreich, wenn die Basisbedingungen erfüllt sind 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 Erfolgskriterien
Weder Anfrage noch Antwort angegeben

Keines dieser Flags angegeben: --request, --response
Google Cloud betrachtet die Prüfung als erfolgreich, wenn die Basisbedingungen erfüllt sind.
Sowohl Anfrage als auch Antwort angegeben

Beide Flags angegeben: --request, --response
Google Cloud sendet Ihren konfigurierten Anfragestring und wartet auf den erwarteten Antwortstring. Google Cloud betrachtet die Prüfung als erfolgreich, wenn die Basisbedingungen erfüllt sind und der zurückgegebene Antwortstring mit dem erwarteten Antwortstring genau übereinstimmt.
Nur Antwort angegeben

Angegebene Flags: nur --response
Google Cloud wartet auf den erwarteten Antwortstring und betrachtet die Prüfung als erfolgreich, wenn die Basisbedingungen erfüllt sind und der zurückgegebene Antwortstring mit dem erwarteten Antwortstring genau übereinstimmt.

Sie sollten --response nur alleine verwenden, wenn Ihre Back-Ends automatisch einen Antwortstring als Teil des TCP- oder SSL-Handshakes senden.
Nur Anfrage angegeben

Angegebene Flags: nur --request
Google Cloud sendet Ihren konfigurierten Anfragestring und betrachtet die Prüfung als erfolgreich, wenn die Basisbedingungen erfüllt sind. Die Antwort, falls vorhanden, wird nicht geprüft.

Erfolgskriterien für gRPC

Wenn Sie gRPC-Systemdiagnosen verwenden, achten Sie darauf, dass der gRPC-Dienst die RPC-Antwort mit dem Status OK und dem Statusfeld auf SERVING bzw. NOT_SERVING gesetzt sendet. Weitere Informationen finden Sie in der gRPC-Dokumentation zu Systemdiagnosen.

Systemzustand

Google Cloud ermittelt mit den folgenden Konfigurations-Flags den Gesamtzustand aller Back-Ends, an die Traffic verteilt wird.

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 Google Cloud 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 Google Cloud einen Schwellenwert von 2 Prüfungen.

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

Google Cloud 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.

Zusätzliche Hinweise

Inhaltsbasierte Systemdiagnosen

Bei einer inhaltsbasierten Systemdiagnose hängt das Erfolgskriterium von der Auswertung eines erwarteten Antwortstrings ab. Verwenden Sie eine inhaltsbasierte Systemdiagnose, um Google Cloud-Systemdiagnoseprüfungen anzuweisen, die Back-End-Antwort vollständiger zu validieren.

  • Sie konfigurieren eine inhaltsbasierte HTTP-, HTTPS- oder HTTP/2-Systemdiagnose, indem Sie einen erwarteten Antwortstring angeben und optional einen Anfragepfad definieren. Weitere Informationen finden Sie unter Erfolgskriterien für HTTP, HTTPS und HTTP/2.

  • Sie konfigurieren eine inhaltsbasierte SSL- oder TCP-Systemdiagnose, indem Sie einen erwarteten Antwortstring angeben und optional einen Anfragepfad definieren. Weitere Informationen finden Sie unter Erfolgskriterien für SSL und TCP.

Zertifikate und Systemdiagnosen

Google Cloud-Systemdiagnose-Prober führen keine Zertifikatsprüfung durch, auch nicht bei Protokollen, die erfordern, dass Ihre Back-Ends Zertifikate verwenden (SSL, HTTPS und HTTP/2). Beispiel:

  • Sie können selbst signierte oder von einer Zertifizierungsstelle signierte Zertifikate verwenden.
  • Abgelaufene oder noch nicht gültige Zertifikate sind möglich.
  • Weder das CN- noch das subjectAlternativeName-Attribut müssen mit einem Host-Header oder DNS-PTR-Eintrag übereinstimmen.

Header

Bei Systemdiagnosen, die ein beliebiges Protokoll verwenden, jedoch nicht bei Legacy-Systemdiagnosen können Sie mithilfe des Flags --proxy-header einen Proxy-Header festlegen.

Bei Systemdiagnosen, die HTTP-, HTTPS- oder HTTP/2-Protokolle verwenden, und bei Legacy-Systemdiagnosen können Sie mithilfe des Flags --host einen HTTP-Host-Header festlegen.

Beispiel für eine Systemdiagnose

Das Beispiel für die Systemdiagnose verwendet die folgenden Einstellungen:

  • Intervall: 30 Sekunden
  • Zeitlimit: 5 Sekunden
  • Protokoll: HTTP
  • Fehlerschwellenwert: 2 (Standard)
  • Schwellenwert für Intaktheit: 2 (Standard)

Mit diesen Einstellungen verhält sich die Systemdiagnose folgendermaßen:

  1. Mehrere redundante Systeme werden gleichzeitig mit den Parametern der Systemdiagnose konfiguriert. Die Intervall- und Zeitlimiteinstellungen werden auf jedes System angewendet. Weitere Informationen finden Sie unter Mehrere Prüfungen und Häufigkeit.
  2. Jeder Systemdiagnose-Prober führt Folgendes aus:

    1. Initiiert alle 30 Sekunden eine HTTP-Verbindung von einer der Quell-IP-Adressen zur Back-End-Instanz.
    2. Wartet bis zu fünf Sekunden auf den Antwortcode HTTP 200 (OK) (das Erfolgskriterium für HTTP-, HTTPS- und HTTP/2-Protokolle).
  3. Ein Back-End gilt als fehlerhaft, wenn mindestens ein System für die Systemdiagnoseprüfung folgende Voraussetzungen erfüllt:

    1. Es erhält keinen HTTP 200 (OK)-Antwortcode für zwei aufeinanderfolgende Prüfungen. Beispielsweise wird die Verbindung möglicherweise abgelehnt oder es kommt zu einer Verbindungs- oder Socket-Zeitüberschreitung.
    2. Es erhält zwei aufeinanderfolgende Antworten, die nicht den protokollspezifischen Erfolgskriterien entsprechen.
  4. Ein Back-End gilt als fehlerfrei, wenn mindestens ein System für die Systemdiagnoseprüfung zwei aufeinanderfolgende Antworten empfängt, die den protokollspezifischen Erfolgskriterien entsprechen.

In diesem Beispiel initiiert jeder Prober alle 30 Sekunden eine Verbindung. Zwischen den Verbindungsversuchen eines Probers liegen 30 Sekunden, unabhängig von der Dauer des Zeitlimits (ganz gleich, ob es eine Zeitüberschreitung der Verbindung gab oder nicht). Mit anderen Worten: Das Zeitlimit muss immer kleiner oder gleich dem Intervall sein und das Zeitlimit verlängert das Intervall nicht.

In diesem Beispiel hat jeder Prober folgende Zeitintervalle (in Sekunden):

  1. t=0: Prüfung A starten
  2. t=5: Prüfung A stoppen
  3. t=30: Prüfung B starten
  4. t=35: Prüfung B stoppen
  5. t=60: Prüfung C starten
  6. t=65: Prüfung C stoppen

Weitere Informationen