Google Cloud bietet konfigurierbare Systemdiagnosen für Google Cloud-Load-Balancer-Back-Ends, Traffic Director-Back-Ends und anwendungsbasierte automatische Reparatur für verwaltete Instanzgruppen. In diesem Dokument werden wichtige Konzepte der Systemdiagnose behandelt.
Sofern nicht anders angegeben, werden Google Cloud-Systemdiagnosen durch dedizierte Softwareaufgaben implementiert, die gemäß den in einer Systemdiagnoseressource angegebenen Parametern eine Verbindung zu Back-Ends herstellen. Jeder Verbindungsversuch wird als Prüfung bezeichnet. Google Cloud zeichnet den Erfolg oder Misserfolg jeder Prüfung auf.
Anhand einer konfigurierbaren Anzahl von sequenziellen erfolgreichen oder fehlgeschlagenen Prüfungen wird für jedes Back-End ein Gesamtsystemzustand berechnet. 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.
Der Gesamtsystemzustand jedes Back-Ends bestimmt, ob es berechtigt ist, neue Anfragen zu erhalten. Sie können die Kriterien konfigurieren, die eine erfolgreiche Prüfung definieren. Dies wird unter Funktionsweise von Systemdiagnosen ausführlich erläutert.
Systemdiagnosen, die durch dedizierte Softwareaufgaben implementiert werden, verwenden spezielle Routen, die nicht in Ihrem Virtual Private Cloud-Netzwerk (VPC) definiert sind. Weitere Informationen finden Sie unter Load-Balancer-Rückgabepfade.
Kategorien, Protokolle und Ports der Systemdiagnose
Systemdiagnosen haben eine Kategorie und ein Protokoll. Die beiden Kategorien sind Systemdiagnosen und Legacy-Systemdiagnosen sowie die folgenden unterstützten Protokolle:
Systemdiagnosen
Legacy-Systemdiagnosen:
Das Protokoll und der Port legen fest, wie die Systemdiagnoseprüfungen durchgeführt werden. Eine Systemdiagnose kann beispielsweise das HTTP-Protokoll an TCP-Port 80 oder das TCP-Protokoll für einen benannten Port in einer Instanzgruppe verwenden.
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 dem Typ des Load-Balancers (oder Traffic Director) und den Back-End-Typen kompatibel sein. Bei der Auswahl einer Systemdiagnose müssen folgende Faktoren berücksichtigt werden:
- Kategorie: Systemdiagnose oder Legacy-Systemdiagnose
- Protokoll: Protokoll, mit dem Google Cloud die Back-Ends prüft
- Portspezifikation: Ports, die Google Cloud mit dem Protokoll verwendet
Im Load-Balancer-Leitfaden wird die gültige Auswahl der Systemdiagnose für jeden Load-Balancer- und Back-End-Typ beschrieben. Eine allgemeine Zusammenfassung finden Sie in der Tabelle der Systemdiagnose-Features.
Kategorie und Protokoll
Es empfiehlt sich, dasselbe Protokoll wie der Load-Balancer zu verwenden. Dies ist aber weder erforderlich noch ist es immer möglich.
Zielpoolbasierte externe Passthrough-Netzwerk-Load-Balancer erfordern beispielsweise Legacy-Systemdiagnosen. Sie erfordern auch, dass die Legacy-Systemdiagnosen das HTTP-Protokoll verwenden, obwohl zielpoolbasierte externe Passthrough-Netzwerk-Load-Balancer TCP oder UDP unterstützen. Für zielpoolbasierte externe Passthrough-Netzwerk-Load-Balancer müssen Sie einen HTTP-Server auf Ihren VM-Instanzen ausführen, damit sie auf Systemdiagnoseprüfungen reagieren können.
Darüber hinaus unterstützen bestimmte Envoy-basierte Load-Balancer, die Hybrid-NEG-Back-Ends verwenden, keine gRPC-Systemdiagnosen. Weitere Informationen finden Sie in der Übersicht zu Hybrid-NEGs.
Für fast alle anderen Load-Balancer-Typen müssen Sie reguläre Nicht-Legacy-Systemdiagnosen verwenden, bei denen das Protokoll mit dem Back-End-Dienst-Protokoll des Load-Balancers übereinstimmt.
Kategorie und Portspezifikation
Sie müssen einen Port für die Systemdiagnose angeben. Systemdiagnosen haben zwei Methoden zur Portspezifikation: --port und --use-serving-port. Für Legacy-Systemdiagnosen gibt es eine Methode: --port.
Load-Balancer-Anleitung
Diese Tabelle enthält die unterstützte Kategorie, den Bereich und die Portspezifikation für jeden Load-Balancer und Back-End-Typ.
| Load-Balancer | Back-End-Typ | Kategorie und Bereich der Systemdiagnose | Portspezifikation |
|---|---|---|---|
|
Globaler externer Application Load Balancer Klassischer Application Load Balancer 1 Globaler externer Proxy-Network-Load-Balancer Klassischer Proxy-Network-Load-Balancer |
Unterstützte NEGs | Systemdiagnose (global) |
|
| Instanzgruppen | Systemdiagnose (global) |
|
|
| Regionaler externer Application Load Balancer | Unterstützte NEGs | Systemdiagnose (regional) |
|
| Instanzgruppen | Systemdiagnose (regional) |
|
|
| Regionenübergreifender interner Application Load Balancer | Unterstützte NEGs | Systemdiagnose (global) |
|
| Instanzgruppen | Systemdiagnose (global) |
|
|
|
Regionaler interner Application Load Balancer Regionaler interner Proxy-Network Load Balancer Regionaler externer Proxy-Network Load Balancer |
Unterstützte NEGs | Systemdiagnose (regional) |
|
| Instanzgruppen | Systemdiagnose (regional) |
|
|
| Externer Passthrough-Netzwerk-Load-Balancer 2 | Instanzgruppen | Systemdiagnose (regional) |
|
| Instanzen in Zielpools |
Legacy-Systemdiagnose (global mit dem HTTP-Protokoll) |
Legacy-Systemdiagnosen unterstützen nur die Spezifikation für die Portnummer (--port). |
|
| Interner Passthrough-Netzwerk-Load-Balancer 2 | Unterstützte NEGs | Systemdiagnose (global oder regional) |
|
| Instanzgruppen | Systemdiagnose (global oder regional) |
|
| Load-Balancer-Modus | Unterstützte Legacy-Systemdiagnosen |
|---|---|
Globaler externer Application Load Balancer Klassischer Application Load Balancer |
Ja, wenn die beiden folgenden Bedingungen zutreffen:
|
| Regionaler externer Application Load Balancer | Nein |
--use-serving-port nicht verwenden, da Back-End-Dienste, die mit internen Passthrough-Netzwerk-Load-Balancern und externen Passthrough-Netzwerk-Load-Balancern verwendet werden, keinen benannten Port abonnieren. Darüber hinaus unterstützen interne Passthrough-Netzwerk-Load-Balancer nur zonale NEGs mit GCE_VM_IP-Endpunkten, für die keine Portinformationen vorhanden sind.
Systemdiagnose mit Traffic Director in Hybridumgebungen durchführen
Bei Traffic Director unterscheidet sich das Systemdiagnoseverhalten für Netzwerkendpunkte vom Typ INTERNET_FQDN_PORT und NON_GCP_PRIVATE_IP_PORT vom Systemdiagnoseverhalten für andere Arten von Netzwerkendpunkten.
Anstatt die dedizierten Softwareaufgaben zu verwenden, programmiert Traffic Director Envoy-Proxys für Systemdiagnosen für Internet-NEGs (INTERNET_FQDN_PORT-Endpunkte) und Hybrid-NEGs (NON_GCP_PRIVATE_IP_PORT-Endpunkte).
Envoy unterstützt die folgenden Protokolle für Systemdiagnosen:
- HTTP
- HTTPS
- HTTP/2
- TCP
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 Prüfung Instanzen in Instanzgruppen oder Endpunkte in zonalen NEGs auswertet.
Die Einstellungen einer Systemdiagnose können nicht pro Back-End konfiguriert werden. Systemdiagnosen sind mit einem gesamten Back-End-Dienst verknüpft. Bei einem zielpoolbasierten externen Passthrough-Netzwerk-Load-Balancer wird eine Legacy-HTTP-Systemdiagnose mit dem gesamten Zielpool verknüpft. 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üfintervallcheck-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. | 5s (5 Sekunden) |
Zeitlimittimeout |
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. | 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 |
|---|---|---|
|
|
Firewallregeln für alle Produkte außer externe Passthrough-Netzwerk-Load-Balancer |
| Externer Passthrough-Netzwerk-Load-Balancer |
Bei IPv4-Traffic zu den Back-Ends:
Bei IPv6-Traffic zu den Back-Ends:
Zielpoolbasierte externe Passthrough-Netzwerk-Load-Balancer unterstützen nur IPv4-Traffic und leiten Systemdiagnosen möglicherweise über den Metadatenserver weiter. In diesem Fall stimmen die Quellen des Systemdiagnosepakets mit der IP-Adresse des Metadatenservers überein: |
Firewallregeln für externe Passthrough-Netzwerk-Load-Balancer |
| Interner Passthrough-Netzwerk-Load-Balancer |
Bei IPv6-Traffic zu den Back-Ends:
|
Firewallregeln für interne Passthrough-Netzwerk-Load-Balancer |
| Traffic Director mit Internet-NEG-Back-Ends und Hybrid-NEG-Back-Ends | IP-Adressen der VMs, auf denen die Envoy-Software ausgeführt wird | Beispiel für Firewallregel |
1 Die Prüfbereiche der Systemdiagnose von Google müssen bei Hybrid-NEGs nicht auf die Zulassungsliste gesetzt werden. Wenn Sie jedoch eine Kombination aus hybriden und zonalen NEGs in einem einzelnen Back-End-Dienst verwenden, müssen Sie die Prüfbereiche der Systemdiagnose von Google für die zonalen NEGs auf die Zulassungsliste setzen.
2 Bei regionalen Internet-NEGs sind Systemdiagnosen optional. Der Traffic von Load-Balancern mit regionalen Internet-NEGs stammt aus dem Nur-Proxy-Subnetz und wird dann (mithilfe von Cloud NAT) in die manuelle oder automatisch zugewiesene NAT-IP-Adressen NAT-übersetzt. Dieser Traffic umfasst sowohl Systemdiagnoseprüfungen als auch Nutzeranfragen vom Load Balancer an die Back-Ends. Weitere Informationen finden Sie unter Regionale NEGs: Cloud NAT für ausgehenden Traffic verwenden.
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 die Systemdiagnose zulassen, blockiert die implizierte deny-Regel den eingehenden Traffic. Wenn Prober Ihre Back-Ends nicht kontaktieren können, betrachtet der Load-Balancer Ihre Back-Ends als fehlerhaft.
Das Verhalten, wenn alle Back-Ends fehlerhaft sind, hängt vom Typ des Load-Balancers ab:
Der klassische Application Load Balancer gibt HTTP 502-Antworten an Clients zurück, wenn alle Back-Ends fehlerhaft sind.
Globale externe Application Load Balancer, regionale externe Application Load Balancer und interne Application Load Balancer geben HTTP 503-Antworten an Clients zurück, wenn alle Back-Ends fehlerhaft sind.
Bei globalen Proxy-Network-Load-Balancern und klassischen Network-Load-Balancern tritt eine Zeitüberschreitung auf, wenn alle Back-Ends fehlerhaft sind.
Regionale externe Proxy-Network-Load-Balancer und regionale interne Proxy-Network-Load-Balancer beenden Clientverbindungen, indem sie ein TCP RST-Paket senden, wenn alle Back-Ends fehlerhaft sind.
Wenn alle Back-Ends fehlerhaft sind und kein Failover konfiguriert ist, verteilen interne Passthrough-Netzwerk-Load-Balancer und auf Back-End-Diensten basierende externe Passthrough-Netzwerk-Load-Balancer den Traffic als letzte Möglichkeit auf alle Back-End-VMs. Weitere Informationen zu diesem Verhalten finden Sie unter Trafficverteilung für interne Passthrough-Netzwerk-Load-Balancer und Trafficverteilung für auf Back-End-Diensten basierende externe Passthrough-Netzwerk-Load-Balancer.
Wenn alle Back-Ends fehlerhaft sind, verteilen zielpoolbasierte externe Passthrough-Netzwerk-Load-Balancer als letzte Möglichkeit den Traffic auf alle Back-End-VMs.
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, um Systemdiagnoseprüfungen für externe Application Load Balancer und externe Proxy-Netzwerk-Load-Balancer zu senden. Wenn ein Paket aus dem Internet empfangen wird und die Quell-IP-Adresse des Pakets innerhalb eines Prüfungs-IP-Bereichs liegt, löscht Google das Paket. Dazu gehört die externe IP-Adresse einer Compute Engine-Instanz oder eines Google Kubernetes Engine-Knotens (GKE).
Die Prüfungs-IP-Bereiche sind ein vollständiger Satz möglicher IP-Adressen, die von Google Cloud-Probern verwendet werden. Wenn Sie
tcpdumpoder ein ähnliches Tool verwenden, beobachten Sie möglicherweise nicht den Traffic von allen IP-Adressen in allen Prüfungs-IP-Bereichen. Erstellen Sie als Best Practice Firewallregeln für eingehenden Traffic, die alle Prüfungs-IP-Bereiche als Quellen zulassen. Google Cloud kann neue Prober automatisch ohne Benachrichtigung implementieren.
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 Passthrough-Netzwerk-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 externe Passthrough-Netzwerk-Load-Balancer. Wenn Sie mehrere Weiterleitungsregeln konfiguriert haben, die auf denselben Back-End-Dienst oder Zielpool verweisen, verwendet Google Cloud mehrere Prober, um jede IP-Adresse zu prüfen. Die Prüfungshäufigkeit pro Back-End-VM wird mit der Anzahl der konfigurierten Weiterleitungsregeln multipliziert.
Mehrere Zielproxys für externe Application Load Balancer. Wenn Sie mehrere Zielproxys haben, die Traffic an dieselbe URL-Zuordnung weiterleiten, 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.
Mehrere Zielproxys für externe Proxy-Netzwerk-Load-Balancer und regionale interne Proxy-Netzwerk-Load-Balancer. Wenn Sie mehrere Zielproxys konfiguriert haben, die Traffic an denselben Back-End-Dienst weiterleiten, 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 der Back-End-Dienste. Wenn ein Back-End 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. Diese zonalen NEGs haben nicht unbedingt denselben Satz von Endpunkten und unterschiedliche Endpunkte können auf dasselbe Back-End verweisen.
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.
Bei externen Passthrough-Netzwerk-Load-Balancern und internen Passthrough-Netzwerk-Load-Balancern muss die Anwendung an die IP-Adresse des Load-Balancers (oder eine beliebige IP-Adresse 0.0.0.0) gebunden werden.
| Load-Balancer | Zielnetzwerkschnittstelle | Ziel-IP-Adresse |
|---|---|---|
|
|
|
| Externer Passthrough-Netzwerk-Load-Balancer | Primäre Netzwerkschnittstelle (nic0) |
IP-Adresse der externen Weiterleitungsregel Wenn mehrere Weiterleitungsregeln auf denselben Back-End-Dienst verweisen (denselben Zielpool für zielpoolbasierte externe Passthrough-Netzwerk-Load-Balancer), sendet Google Cloud Prüfungen an jede IP-Adresse der Weiterleitungsregel. Dies kann zu einer höheren Anzahl von Prüfungen führen. |
| Interner Passthrough-Netzwerk-Load-Balancer | Sowohl für Instanzgruppen-Back-Ends als auch für zonale NEG-Back-Ends mit GCE_VM_IP-Endpunkten hängt die verwendete Netzwerkschnittstelle davon ab, wie der Back-End-Dienst konfiguriert ist. Weitere Informationen finden Sie unter Back-End-Dienste und Netzwerkschnittstellen.
|
Die IP-Adresse der internen 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. |
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 des HTTP-Antworttexts 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 |
|---|---|
Anfragepfadrequest-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, /.
|
Antwortresponse |
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 ordnungsgemäß beendet, entweder über:
- Das Back-End oder
- Der Google Cloud-Prober sendet ein TCP-RST-Paket (Reset), während die TCP-Sitzung für den Prober noch läuft.
Wenn das Back-End ein TCP-RST-Paket (zurücksetzen) sendet, um eine TCP-Sitzung für eine TCP-Systemdiagnose zu schließen, könnte die Prüfung als nicht erfolgreich eingestuft werden. Dies geschieht, wenn der Google Cloud-Prober bereits eine ordnungsgemäße TCP-Beendigung initiiert hat.
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.
Wichtige Hinweise:
- gRPC-Systemdiagnosen werden nur mit gRPC-Anwendungen und Traffic Director verwendet.
- gRPC-Systemdiagnosen unterstützen keine TLS.
Hier finden Sie weitere Informationen:
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 Intaktheithealthy-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. | Ein Grenzwert von 2 Prüfungen. |
Fehlerschwellenwertunhealthy-threshold |
Der Fehlerschwellenwert gibt die Anzahl der aufeinanderfolgenden fehlgeschlagenen Prüfergebnisse an, die nötig sind, damit ein Back-End als fehlerhaft eingestuft wird. | Ein Grenzwert 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 dassubjectAlternativeName-Attribut müssen mit einemHost-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:
- 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.
Jeder Systemdiagnose-Prober führt Folgendes aus:
- Initiiert alle 30 Sekunden eine HTTP-Verbindung von einer der Quell-IP-Adressen zur Back-End-Instanz.
- Wartet bis zu fünf Sekunden auf den Antwortcode
HTTP 200 (OK)(das Erfolgskriterium für HTTP-, HTTPS- und HTTP/2-Protokolle).
Ein Back-End gilt als fehlerhaft, wenn mindestens ein System für die Systemdiagnoseprüfung folgende Voraussetzungen erfüllt:
- 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. - Es erhält zwei aufeinanderfolgende Antworten, die nicht den protokollspezifischen Erfolgskriterien entsprechen.
- Es erhält keinen
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):
- t=0: Prüfung A starten
- t=5: Prüfung A stoppen
- t=30: Prüfung B starten
- t=35: Prüfung B stoppen
- t=60: Prüfung C starten
- t=65: Prüfung C stoppen
Nächste Schritte
- Informationen zum Erstellen, Ändern und Verwenden von Systemdiagnosen unter Systemdiagnosen erstellen
- Aktivieren Sie Systemdiagnose-Logging, um Fehler bei Systemdiagnosen zu beheben.