Google Cloud bietet Mechanismen zur Systemdiagnose, die bestimmen, ob Back-End-Instanzen ordnungsgemäß auf den Traffic reagieren. In diesem Dokument wird beschrieben, wie Systemdiagnosen für Load-Balancer und Traffic Director erstellt und verwendet werden.
Auf dieser Seite wird davon ausgegangen, dass Sie mit den folgenden Konzepten vertraut sind:
Kategorien, Protokolle und Ports der Systemdiagnose
Google Cloud 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 zur Angabe des Ports, der für die Systemdiagnose verwendet wird.
Traffic Director und die meisten Load-Balancer verwenden Nicht-Legacy-Systemdiagnosen. Für das zielpoolbasierte Netzwerk-Load-Balancing müssen jedoch Legacy-Systemdiagnosen verwendet werden. Informationen zur Bestimmung der entsprechenden Kategorie, des Protokolls und der Portspezifikationsmethode finden Sie auf der Seite Übersicht über Systemdiagnosen unter Systemdiagnose auswählen.
Das Protokoll, das Sie für eine Systemdiagnose auswählen, muss nicht mit dem Protokoll übereinstimmen, das vom Load-Balancer verwendet wird, in einigen Fällen ist dies sogar nicht möglich. Weitere Informationen finden Sie unter Protokolle und Load-Balancer.
Der Begriff "Systemdiagnose" bezieht sich nicht auf Legacy-Systemdiagnosen, die in diesem Dokument explizit als "Legacy-Systemdiagnosen" bezeichnet werden.
Systemdiagnosen auflisten
Console
- Rufen Sie in der Google Cloud Console die Seite "Systemdiagnosen" auf.
Zur Seite "Systemdiagnosen" - Klicken Sie auf eine Systemdiagnose, um die zugehörigen Details anzusehen.
gcloud
Verwenden Sie den Befehl compute health-checks
list
, um Systemdiagnosen aufzulisten:
So listen Sie globale Systemdiagnosen auf:
gcloud compute health-checks list \ --global
So listen Sie regionale Systemdiagnosen auf: Ersetzen Sie
REGION_LIST
durch eine durch Kommas getrennte Liste der abzufragenden Google Cloud-Regionen.gcloud compute health-checks list \ --regions=REGION_LIST
Nachdem Sie den Namen und den Bereich einer Systemdiagnose kennen, können Sie mit dem Befehl compute
health-checks
describe
die aktuelle Konfiguration ansehen.
Um eine globale Systemdiagnose zu beschreiben, ersetzen Sie
NAME
durch deren Namen.gcloud compute health-checks describe NAME \ --global
Um eine regionale Systemdiagnose zu beschreiben, ersetzen Sie
NAME
durch deren Namen undREGION
durch deren Region.gcloud compute health-checks describe NAME \ --region=REGION
API
Verwenden Sie diese API-Aufrufe, um Systemdiagnosen aufzulisten:
So listen Sie globale Systemdiagnosen auf: healthChecks.list
So listen Sie regionale Systemdiagnosen auf: regionHealthChecks.list
Verwenden Sie diese API-Aufrufe, um die aktuelle Konfiguration einer Systemdiagnose zu beschreiben:
So beschreiben Sie eine globale Systemdiagnose: healthChecks.get
So beschreiben Sie eine regionale Systemdiagnose: regionHealthChecks.get
Systemdiagnosen erstellen
Mit Google Cloud können Sie eine Systemdiagnose erstellen oder auswählen, wenn Sie die Back-End-Konfiguration des Load-Balancers in der Cloud Console abschließen.
Sie können auch unabhängig von der Load-Balancer-Konfiguration eine Systemdiagnose erstellen. Dies ist nützlich, wenn Sie zuerst Ihre Systemdiagnose erstellen müssen oder wenn Sie eine Systemdiagnose für mehrere Load-Balancer verwenden möchten. Sie können eine Systemdiagnose mit der Cloud Console, mit der Google Cloud-Befehlszeile oder den REST APIs erstellen.
Console
- Rufen Sie in der Google Cloud Console die Seite "Systemdiagnosen" auf.
Zur Seite "Systemdiagnosen" - Klicken Sie auf Systemdiagnose erstellen.
- Geben Sie auf der Seite Systemdiagnose erstellen die folgenden Informationen an:
- Name: Geben Sie einen Namen für die Systemdiagnose ein.
- Beschreibung: Geben Sie optional eine Beschreibung ein.
- Bereich: Wählen Sie einen Bereich aus, entweder Global oder Regional, je nach Art des Load-Balancers.
- Wenn Sie Regional ausgewählt haben, wählen Sie eine Region aus dem Drop-down-Menü aus.
- Protokoll: Wählen Sie ein Protokoll für die Systemdiagnose aus.
- Port: Geben Sie eine Portnummer an. Wenn Sie eine Systemdiagnose in der Cloud Console erstellen, müssen Sie den Port mit einer Portnummer angeben.
- Proxy-Protokoll: Optional können Sie einen Proxy-Header an die Anfragen anfügen, die von den Prüfsystemen der Systemdiagnose gestellt werden.
- Anfragepfad und Antwort: Bei HTTP-, HTTPS- und HTTP2-Protokollen können Sie optional einen URL-Pfad angeben, den die Prüfsysteme der Systemdiagnose kontaktieren. Weitere Informationen finden Sie unter Zusätzliche Flags für HTTP-, HTTPS- und HTTP/2-Systemdiagnosen.
- Anfrage und Antwort: Bei TCP- und SSL-Protokollen können Sie einen zu sendenden ASCII-Textstring und einen erwarteten Textantwortstring angeben. Weitere Informationen finden Sie unter Zusätzliche Flags für SSL- und TCP-Systemdiagnosen.
- Überprüfungsintervall: Definieren Sie die Zeitspanne vom Start einer Prüfung bis zum Start der nächsten.
- Zeitlimit: Definieren Sie die Zeitspanne, die Google Cloud auf eine Antwort auf eine Prüfung wartet. Der Wert muss kleiner oder gleich dem Überprüfungsintervall sein.
- Schwellenwert für Intaktheit: Definieren Sie die Anzahl der sequenziellen Prüfungen, die erfolgreich sein müssen, damit die VM-Instanz als fehlerfrei gilt.
- Fehlerschwellenwert: Definieren Sie die Anzahl der sequenziellen Prüfungen, die fehlschlagen müssen, damit die VM-Instanz als fehlerhaft gilt.
- Klicken Sie auf Erstellen.
gcloud
Verwenden Sie zum Erstellen einer globalen Systemdiagnose den geeigneten Befehl
compute health-checks create
:gcloud compute health-checks create PROTOCOL NAME \ --global \ --description=DESCRIPTION \ --check-interval=CHECK_INTERVAL \ --timeout=TIMEOUT \ --healthy-threshold=HEALTHY_THRESHOLD \ --unhealthy-threshold=UNHEALTHY_THRESHOLD \ PORT_SPECIFICATION \ ADDITIONAL_FLAGS
Verwenden Sie zum Erstellen einer regionalen Systemdiagnose den geeigneten Befehl
compute health-checks create
:gcloud compute health-checks create PROTOCOL NAME \ --region=REGION \ --description=DESCRIPTION \ --check-interval=CHECK_INTERVAL \ --timeout=TIMEOUT \ --healthy-threshold=HEALTHY_THRESHOLD \ --unhealthy-threshold=UNHEALTHY_THRESHOLD \ PORT_SPECIFICATION \ ADDITIONAL_FLAGS
Dabei gilt:
PROTOCOL
definiert das für die Systemdiagnose verwendete Protokoll. Gültige Optionen sindgrpc
,http
,https
,http2
,ssl
undtcp
.NAME
ist der Name der Systemdiagnose. Innerhalb eines bestimmten Projekts: Jede globale Systemdiagnose muss einen eindeutigen Namen haben und regionale Systemdiagnosen müssen innerhalb einer bestimmten Region eindeutige Namen haben.REGION
: Alle Load-Balancer mit Ausnahme von regionalen externen HTTP(S)-Load-Balancern und internen HTTP(S)-Load-Balancern verwenden globale Systemdiagnosen (--global
). Interne HTTP(S)-Load-Balancer verwenden regionale Systemdiagnosen, deren Region mit der Region des Back-End-Dienstes übereinstimmen muss.DESCRIPTION
ist eine optionale Beschreibung.CHECK_INTERVAL
ist die Zeitspanne vom Start der Verbindung eines Prüfsystems zur Systemdiagnose bis zum Start der nächsten. Die Einheiten sind Sekunden. Wenn keine Angabe gemacht wird, verwendet Google Cloud den Wert5s
(5 Sekunden).TIMEOUT
ist die Zeitspanne, die Google Cloud bei einer Prüfung auf eine Antwort wartet. Der Wert vonTIMEOUT
muss kleiner oder gleichCHECK_INTERVAL
sein. Die Einheit sind Sekunden. Wenn keine Angabe gemacht wird, verwendet Google Cloud den Wert5s
(5 Sekunden).HEALTHY_THRESHOLD
undUNHEALTHY_THRESHOLD
geben die Anzahl der sequenziellen Testdurchläufe an, die bestanden werden oder fehlschlagen müssen, damit die VM-Instanz als fehlerfrei oder fehlerhaft eingestuft wird. Wenn einer der Parameter nicht angegeben ist, verwendet Google Cloud den Standardschwellenwert2
.PORT_SPECIFICATION
: Definiert die Portspezifikation mit einem der Flags zur Portspezifikation.ADDITIONAL_FLAGS
sind weitere Flags zur Festlegung von Ports und Optionen speziell für dasPROTOCOL
. Weitere Informationen finden Sie unter Zusätzliche Flags für HTTP-, HTTPS- und HTTP/2-Systemdiagnosen, Zusätzliche Flags für SSL- und TCP-Systemdiagnosen oder Zusätzliches Flag für gRPC-Systemdiagnosen.
API
Verwenden Sie zum Erstellen einer globalen Systemdiagnose healthChecks.insert.
Verwenden Sie zum Erstellen einer regionalen Systemdiagnose regionHealthChecks.insert.
Systemdiagnosen ändern
Sie können eine Systemdiagnose nicht in eine Legacy-Systemdiagnose (oder umgekehrt) umwandeln, indem Sie die Systemdiagnose ändern. Sie können auch den Namen oder Bereich einer Systemdiagnose nicht ändern (z. B. global in regional).
Console
- Rufen Sie in der Google Cloud Console die Seite "Systemdiagnosen" auf.
Zur Seite "Systemdiagnosen" - Klicken Sie auf eine Systemdiagnose, um die zugehörigen Details anzusehen.
- Wenn Sie die Systemdiagnose ändern müssen, klicken Sie auf Bearbeiten und gehen Sie dann so vor:
- Nehmen Sie nach Bedarf Änderungen an den Parametern vor.
- Klicken Sie auf Speichern.
gcloud
Geben Sie den Namen und den Bereich der Systemdiagnose an. Eine Anleitung finden Sie unter Systemdiagnosen auflisten.
Mit Ausnahme des Namens, Protokolls und des Bereichs einer Systemdiagnose können Sie alle allgemeinen Flags, Flags zur Portspezifikation und optionalen Flags ändern. Verwenden Sie zum Ändern einer vorhandenen Systemdiagnose den geeigneten
compute health-checks update
-Befehl. Bei Flags, die Sie weglassen, bleiben die vorkonfigurierten Einstellungen erhalten.Beispiel für die Änderung einer globalen Systemdiagnose: Der folgende Befehl ändert eine globale HTTP-Systemdiagnose mit dem Namen
hc-http-port-80
, indem ihr Prüfintervall, Zeitlimit und Anfragepfad geändert werden:gcloud compute health-checks update http hc-http-port-80 \ --global \ --check-interval=20s \ --timeout=15s \ --request-path="/health"
Beispiel für die Änderung einer regionalen Systemdiagnose: Der folgende Befehl ändert eine regionale TCP-Systemdiagnose in
us-west1
mit dem Namenhc-west1-tcp-ldap
, indem die Portspezifikation geändert wird:gcloud compute health-checks update tcp hc-west1-tcp-ldap \ --region=us-west1 \ --port=631
API
Geben Sie den Namen und den Bereich der Systemdiagnose an. Eine Anleitung finden Sie unter Systemdiagnosen auflisten.
Mit Ausnahme des Namens, Protokolls und des Bereichs einer Systemdiagnose können Sie mit diesen API-Aufrufen alle allgemeinen Flags, Flags zur Portspezifikation und optionalen Flags ändern. Verwenden Sie
patch
-API-Aufrufe, um alle vorkonfigurierten Einstellungen beizubehalten, die nicht explizit in der Anfrage festgelegt wurden.Verwenden Sie zum Ändern einer globalen Systemdiagnose entweder healthChecks.update oder healthChecks.patch.
Verwenden Sie zum Ändern einer regionalen Systemdiagnose entweder regionHealthChecks.update oder regionHealthChecks.patch.
Zusätzliche Flags
In diesem Abschnitt werden zusätzliche Flags beschrieben, die Sie beim Erstellen oder Ändern einer Systemdiagnose verwenden können. Einige Flags, wie die Portspezifikation, müssen mithilfe von gcloud
oder der API festgelegt werden.
Flags zur Portspezifikation
Wenn Sie eine Systemdiagnose mit der Google Cloud-Befehlszeile oder der API erstellen, haben Sie zwei Möglichkeiten, den Port der Systemdiagnose anzugeben. Die folgende Tabelle enthält Optionen der Portspezifikation für gültige Kombinationen von Load-Balancern und Back-Ends. Der Begriff Instanzgruppe bezieht sich auf nicht verwaltete Instanzgruppen, verwaltete zonale Instanzgruppen oder verwaltete regionale Instanzgruppen.
Jede Systemdiagnose kann nur einen Typ von Portspezifikation verwenden.
Produkt | Back-End-Typ | Optionen für die Portspezifikation |
---|---|---|
Netzwerk-Load-Balancing | Instanzgruppen | • --port : Geben Sie einen TCP-Port nach Nummer an, von 1 bis 65535 Das Flag --use-serving-port wird für eine mit einem Netzwerk-Load-Balancer verknüpfte Systemdiagnose ignoriert, da Back-End-Dienste für Netzwerk-Load-Balancer keine Portspezifikation haben.
|
Internes TCP/UDP-Load-Balancing | Instanzgruppen | • --port : Geben Sie einen TCP-Port nach Nummer an, von 1 bis 65535 Das Flag --use-serving-port wird für eine mit einem internen TCP/UDP-Load-Balancer verknüpfte Systemdiagnose ignoriert, da Back-End-Dienste für interne TCP/UDP-Load-Balancer keine Portspezifikation haben.
|
Internes HTTP(S)-Load-Balancing TCP-Proxy-Load-Balancing SSL-Proxy-Load-Balancing Externes HTTP(S)-Load-Balancing (global und regional) Traffic Director |
Zonale NEGs | • --port : Geben Sie einen TCP-Port als Zahl an, von 1 bis 65535 .• --use-serving-port : Verwenden Sie den Port jedes Endpunkts in der Netzwerk-Endpunktgruppe. |
Instanzgruppen | • --port : Geben Sie einen TCP-Port als Zahl an, von 1 bis 65535 .• --use-serving-port : Verwenden Sie denselben benannten Port der Instanzgruppe, den der Back-End-Dienst verwendet. |
Wenn Sie die Portspezifikation weglassen, verwendet Google Cloud die folgenden Standardeinstellungen:
- Wenn das Protokoll der Systemdiagnose
TCP
oderHTTP
ist, wird--port=80
verwendet. - Wenn das Protokoll der Systemdiagnose
SSL
,HTTPS
oderHTTP2
ist, wird--port=443
verwendet. - Wenn das Protokoll der Systemdiagnose
GRPC
lautet, gibt es keinen implizierten Standardwert und Sie müssen die Portspezifikation angeben.
Zusätzliche Flags für HTTP-, HTTPS- und HTTP/2-Systemdiagnosen
Zusätzlich zu den allgemeinen Flags und Portspezifikationen können Sie die folgenden optionalen Flags für HTTP-, HTTPS- und HTTP/2-Systemdiagnosen verwenden. In diesem Beispiel wird eine HTTP-Systemdiagnose namens hc-http-port-80
unter Verwendung von Port 80 mit Standardkriterien für Intervall, Zeitlimit und Fehlerschwellenwert erstellt.
gcloud compute health-checks create HTTP_PROTOCOL hc-http-port-80 \ COMMON_FLAGS \ PORT_SPECIFICATION \ --host=HOST \ --proxy-header=PROXY_HEADER \ --request-path=REQUEST_PATH \ --response=RESPONSE
HTTP_PROTOCOL
: Kannhttp
(HTTP/1.1 ohne TLS),https
(HTTP/1.1 mit TLS) oderhttp2
(HTTP/2 mit TLS) sein.COMMON_FLAGS
: Definiert die allgemeinen Flags. Siehe Erstellungsverfahren.PORT_SPECIFICATION
: Definiert die Portspezifikation mit einem der Flags zur Portspezifikation.- Mit
HOST
können Sie einenHost
-HTTP-Header angeben. Wenn nicht angegeben, wird die IP-Adresse der Weiterleitungsregel des Load-Balancers verwendet. PROXY_HEADER
muss entwederNONE
oderPROXY_V1
sein. Wenn nichts angegeben ist, verwendet Google CloudNONE
. Beim WertPROXY_V1
wird dem HeaderPROXY UNKNOWN\r\n
hinzugefügt.REQUEST_PATH
gibt den URL-Pfad an, den Google Cloud beim Senden von Systemdiagnoseanfragen verwendet. Wenn nichts angegeben ist, werden Systemdiagnoseanfragen an/
gesendet.RESPONSE
definiert eine optionale erwartete Antwort. Antwortstrings müssen die folgenden Regeln erfüllen:- Der Antwortstring muss aus ASCII-Zeichen, Ziffern und Leerzeichen bestehen.
- Der Antwortstring kann bis zu 1.024 Zeichen lang sein.
- Der Abgleich von Platzhaltern wird nicht unterstützt.
- Die inhaltsbasierte Überprüfung unterstützt keine Inversion. Operatoren wie
!
in HAProxy werden beispielsweise nicht unterstützt.
Wenn Google Cloud den erwarteten Antwortstring an einer beliebigen Stelle in den ersten 1.024 Byte des empfangenen Antworttexts findet und der HTTP-Status 200 (OK) ist, gilt die Prüfung als erfolgreich.
Die Flags --request-path
und --response
ändern die Erfolgskriterien für die Prüfung der Systemdiagnose.
Zusätzliche Flags für SSL- und TCP-Systemdiagnosen
Zusätzlich zu den allgemeinen Flags und Portspezifikationen können Sie die folgenden optionalen Flags für SSL- und TCP-Systemdiagnosen verwenden. In diesem Beispiel wird eine TCP-Systemdiagnose namens hc-tcp-3268
unter Verwendung von Port 3268 mit Standardkriterien für Intervall, Zeitlimit und Fehlerschwellenwert erstellt.
gcloud compute health-checks create tcp hc-tcp-3268 \ COMMON_FLAGS \ PORT_SPECIFICATION \ --proxy-header=PROXY_HEADER \ --request=REQUEST_STRING \ --response=RESPONSE_STRING
- Das Protokoll kann
tcp
(wie in diesem Beispiel) oderssl
sein. COMMON_FLAGS
: Definiert die allgemeinen Flags. Siehe Erstellungsverfahren.PORT_SPECIFICATION
: Definiert die Portspezifikation mit einem der Flags zur Portspezifikation.PROXY_HEADER
muss entwederNONE
oderPROXY_V1
sein. Wenn nichts angegeben ist, verwendet Google CloudNONE
. Beim WertPROXY_V1
wird dem HeaderPROXY UNKNOWN\r\n
hinzugefügt.REQUEST_STRING
: Sie können einen bis zu 1.024 ASCII-Zeichen langen String angeben, der gesendet wird, nachdem die TCP- oder SSL-Sitzung erstellt wurde.RESPONSE_STRING
: Sie können einen String für die erwartete Antwort von bis zu 1.024 ASCII-Zeichen Länge angeben.
Die Flags --request
und --response
ändern die Erfolgskriterien für die Prüfung der Systemdiagnose. Wenn Sie das Flag --response
entweder allein oder in Verbindung mit dem Flag --request
verwenden, muss die zurückgegebene Antwort genau mit dem erwarteten Antwortstring übereinstimmen.
Zusätzliches Flag für gRPC-Systemdiagnosen
Der Back-End-gRPC-Server muss den gRPC-Systemdiagnosedienst implementieren, wie im gRPC-Systemdiagnoseprotokoll beschrieben.
Google Cloud sendet durch Aufrufen der Methode Check
des Systemdiagnosedienstes in Ihrem Back-End eine HealthCheckRequest
-Nachricht an Ihre Back-Ends. Für den Dienstparameter in der Anfrage wird ein leerer String festgelegt, sofern kein gRPC-Dienstname angegeben ist.
Eine gRPC-Systemdiagnose kann den Status eines gRPC-Dienstes prüfen. Sie können einen String mit bis zu 1.024 ASCII-Zeichen verwenden. Das ist der Name eines bestimmten gRPC-Dienstes, der auf einer Back-End-VM oder NEG ausgeführt wird. Verwenden Sie dazu das folgende optionale Flag für gRPC-Systemdiagnosen:
--grpc-service-name=GRPC_SERVICE_NAME
Es können zum Beispiel folgende Dienste und der Status vorliegen, die der Back-End-Server beim gRPC-Systemdiagnosedienstes des Back-Ends registriert.
MyPackage.ServiceA
mit dem AuslieferungsstatusSERVING
MyPackage.ServiceB
mit dem AuslieferungsstatusNOT_SERVING
- Leerer Dienstname mit Auslieferungsstatus
NOT_SERVING
Wenn Sie eine Systemdiagnose für MyPackage.ServiceA
erstellen, gibt diese Prüfung HEALTHY
zurück, da der Status des Dienstes SERVING
lautet.
gcloud beta compute health-checks create grpc MyGrpcHealthCheckServiceA \ --grpc-service-name=MyPackage.ServiceA
Wenn Sie eine Systemdiagnose für MyPackage.ServiceB
erstellen, gibt diese Prüfung UNHEALTHY
zurück, da der Dienststatus NOT_SERVING
lautet.
Wenn Sie eine Systemdiagnose für MyPackage.ServiceC
erstellen, die nicht beim gRPC-Systemdiagnosedienst registriert ist, gibt die Systemdiagnose den gRPC-Status NOT_FOUND
zurück. Dieser entspricht UNHEALTHY
.
Wenn Sie eine Systemdiagnose für den leeren Dienstnamen erstellen, gibt diese Prüfung den Status UNHEALTHY
zurück, da der leere Dienstname mit dem Status NOT_SERVING
registriert ist.
Alte Systemdiagnosen
In diesem Abschnitt wird beschrieben, wie Sie Legacy-HTTP-Systemdiagnosen und Legacy-HTTPS-Systemdiagnosen auflisten, erstellen und ändern.
Wenn die Antwort der Legacy-Systemdiagnose-Prüfung HTTP 200 OK
lautet, gilt die Prüfung als erfolgreich. Alle anderen HTTP-Antwortcodes, einschließlich der Weiterleitung (301
, 302
), gelten als fehlerhaft.
Legacy-Systemdiagnosen auflisten
Console
- Rufen Sie in der Google Cloud Console die Seite "Systemdiagnosen" auf.
Zur Seite "Systemdiagnosen" - Klicken Sie auf eine Legacy-Systemdiagnose, um die zugehörigen Details anzusehen.
gcloud
Verwenden Sie den Befehl
compute http-health-checks list
, um Legacy-HTTP-Systemdiagnosen aufzulisten:gcloud compute http-health-checks list
Verwenden Sie den Befehl
compute https-health-checks list
, um Legacy-HTTPS-Systemdiagnosen aufzulisten:gcloud compute https-health-checks list
Verwenden Sie zum Beschreiben einer Legacy-HTTP-Systemdiagnose den Befehl
compute http-health-checks describe
und ersetzen Sie dabeiNAME
durch deren Namen.gcloud compute http-health-checks describe NAME
Verwenden Sie zum Beschreiben einer Legacy-HTTPS-Systemdiagnose den Befehl
compute https-health-checks describe
und ersetzen SieNAME
durch deren Namen.gcloud compute https-health-checks describe NAME
API
So listen Sie Legacy-Systemdiagnosen auf:
Verwenden Sie httpHealthChecks.list, um Legacy-HTTP-Systemdiagnosen aufzulisten.
Verwenden Sie httpsHealthChecks.list, um Legacy-HTTPS-Systemdiagnosen aufzulisten.
So beschreiben Sie eine Legacy-Systemdiagnose:
Verwenden Sie httpHealthChecks.get, um die Legacy-HTTP-Systemdiagnose zu beschreiben.
Verwenden Sie httpsHealthChecks.get, um die Legacy-HTTPS-Systemdiagnose zu beschreiben.
Legacy-Systemdiagnosen erstellen
Console
Obwohl auf der Seite der Systemdiagnosen der Cloud Console sowohl Systemdiagnosen als auch Legacy-Systemdiagnosen aufgeführt sind und sie diese bearbeiten können, können Sie auf der Seite der Systemdiagnosen der Cloud Console keine neue Legacy-Systemdiagnose erstellen.
Eine Legacy-Systemdiagnose kann in der Cloud Console nur beim Erstellen eines zielpoolbasierten Netzwerk-Load-Balancers erstellt werden.
Wenn Sie die Legacy-Systemdiagnose allein erstellen möchten, verwenden Sie die gcloud
- oder API-Anweisungen in diesem Abschnitt.
gcloud
Verwenden Sie zum Erstellen einer Legacy-Systemdiagnose den Befehl compute http-health-checks
create
:
gcloud compute LEGACY_CHECK_TYPE create NAME \ --description=DESCRIPTION \ --check-interval=CHECK_INTERVAL \ --timeout=TIMEOUT \ --healthy-threshold=HEALTHY_THRESHOLD \ --unhealthy-threshold=UNHEALTHY_THRESHOLD \ --host=HOST \ --port=PORT \ --request-path=REQUEST_PATH
Dabei gilt:
LEGACY_CHECK_TYPE
isthttp-health-checks
für eine Legacy-HTTP-Systemdiagnose oderhttps-health-checks
für eine Legacy-HTTPS-Systemdiagnose. Wenn Sie die Legacy-Systemdiagnose für einen zielpoolbasierten Netzwerk-Load-Balancer erstellen, müssen Siehttp-health-checks
verwenden.NAME
ist der Name der Legacy-Systemdiagnose. Innerhalb eines bestimmten Projekts muss jede Legacy-Systemdiagnose einen eindeutigen Namen haben.DESCRIPTION
ist eine optionale Beschreibung.CHECK_INTERVAL
ist die Zeitspanne vom Start einer Prüfung bis zum Start der nächsten. Die Einheit sind Sekunden. Wenn keine Angabe gemacht wird, verwendet Google Cloud den Wert5s
(5 Sekunden).TIMEOUT
ist die Zeitspanne, die Google Cloud auf eine Antwort auf eine Prüfung wartet. Der Wert vonTIMEOUT
muss kleiner oder gleichCHECK_INTERVAL
sein. Die Einheit sind Sekunden. Wenn keine Angabe gemacht wird, verwendet Google Cloud den Wert5s
(5 Sekunden).HEALTHY_THRESHOLD
undUNHEALTHY_THRESHOLD
geben die Anzahl der sequenziellen Testdurchläufe an, die bestanden werden oder fehlschlagen müssen, damit die VM-Instanz als fehlerfrei oder fehlerhaft eingestuft wird. Wenn einer der Parameter nicht angegeben ist, verwendet Google Cloud den Standardschwellenwert2
.- Unter
HOST
können Sie einen Host-HTTP-Header anzugeben. Wenn nicht angegeben, wird die IP-Adresse der Weiterleitungsregel des Load-Balancers verwendet. - Unter
PORT
können Sie eine Portnummer angeben. Wenn nichts angegeben ist, verwendet Google Cloud80
. REQUEST_PATH
gibt den URL-Pfad an, den Google Cloud beim Senden von Systemdiagnoseanfragen verwendet. Wenn nichts angegeben ist, werden Systemdiagnoseanfragen an/
gesendet.
API
Verwenden Sie zum Erstellen einer Legacy-HTTP-Systemdiagnose den API-Aufruf httpHealthChecks.insert.
Verwenden Sie zum Erstellen einer Legacy-HTTPS-Systemdiagnose httpsHealthChecks.insert.
Legacy-Systemdiagnosen ändern
Console
- Rufen Sie in der Google Cloud Console die Seite "Systemdiagnosen" auf.
Zur Seite "Systemdiagnosen" - Klicken Sie auf eine Systemdiagnose, um die zugehörigen Details anzusehen.
- Klicken Sie auf Bearbeiten , nehmen Sie die gewünschten Änderungen vor und klicken Sie dann auf Speichern.
gcloud
Verwenden Sie zum Ändern einer Legacy-HTTP-Systemdiagnose den Befehl
compute http-health-checks update
und ersetzen Sie dabeiNAME
durch deren Namen. Beim Ändern einer Systemdiagnose mitgcloud
werden vorkonfigurierte Einstellungen für die Flags beibehalten, die Sie auslassen.OTHER_OPTIONS
sind die Optionen, die unter Legacy-Systemdiagnose erstellen beschrieben werden.gcloud compute http-health-checks update NAME \ OTHER_OPTIONS
Verwenden Sie zum Ändern einer Legacy-HTTPS-Systemdiagnose den Befehl
compute https-health-checks update
und ersetzen Sie dabeiNAME
durch deren Namen. Beim Ändern einer Systemdiagnose mitgcloud
werden vorkonfigurierte Einstellungen für die Flags beibehalten, die Sie auslassen.OTHER_OPTIONS
sind die Optionen, die unter Legacy-Systemdiagnose erstellen beschrieben werden.gcloud compute https-health-checks update NAME \ OTHER_OPTIONS
API
Mit Ausnahme des Namens und Typs einer Legacy-Systemdiagnose können Sie alle für die Erstellung verwendeten Flags ändern. Die patch
-API-Aufrufe behalten alle vorkonfigurierten Einstellungen bei, die nicht explizit in der Patch-Anfrage festgelegt wurden.
Verwenden Sie zum Ändern einer Legacy-HTTP-Systemdiagnose entweder httpHealthChecks.update oder httpHealthChecks.patch.
Verwenden Sie zum Ändern einer Legacy-HTTPS-Systemdiagnose entweder httpsHealthChecks.update oder httpsHealthChecks.patch.
Erforderliche Firewallregeln
Sie müssen Firewallregeln für eingehenden Traffic erstellen, die auf alle VMs mit Load-Balancing angewendet werden können und Traffic von IP-Bereichen des Systemdiagnose-Probers zulassen. In den folgenden Beispielen werden Firewallregeln erstellt, die auf VM-Instanzen nach Zieltag anwendbar sind. Weitere Informationen zur Angabe von Zielen für Firewallregeln finden Sie in der Erläuterung der Ziele in der Übersicht über Firewallregeln und unter Netzwerk-Tags konfigurieren.
Jedes dieser Beispiele lässt den gesamten TCP-Traffic von Google Cloud-Systemdiagnosen zu Ihren VM-Instanzen zu. (TCP-Traffic umfasst SSL-, HTTP-, HTTPS- und HTTP/2-Traffic.) Wenn Sie möchten, können Sie Ports zusammen mit dem TCP-Protokoll angeben; wenn Sie jedoch Ports angeben, werden Ihre Firewallregeln möglicherweise für eine bestimmte Systemdiagnose spezifisch. Durch die Verwendung von tcp:80
für das Protokoll und den Port wird TCP-Traffic auf Port 80 zugelassen, sodass Google Cloud Ihre VMs über HTTP an Port 80 kontaktieren könnte, aber nicht über HTTPS an Port 443.
Firewallregeln für Systemdiagnosen
Das folgende Beispiel erstellt eine Firewallregel für eingehenden Traffic für nachstehende Load-Balancer:
- Internes TCP/UDP-Load-Balancing
- Internes HTTP(S)-Load-Balancing
- TCP-Proxy-Load-Balancing
- SSL-Proxy-Load-Balancing
- HTTP(S)-Load-Balancing (global und regional)
Für diese Load-Balancer lauten die Quell-IP-Bereiche der Systemdiagnosen (einschließlich der Legacy-Systemdiagnosen, falls beim HTTP(S)-Load-Balancing verwendet):
35.191.0.0/16
130.211.0.0/22
Sollten Sie Regeln für Netzwerk-Load-Balancing erstellen müssen, finden Sie weitere Informationen dazu im nächsten Abschnitt Regeln für Netzwerk-Load-Balancing.
Console
- Rufen Sie in der Google Cloud Console die Seite „Firewallregeln“ auf.
Zur Seite "Firewall" - Klicken Sie auf Firewallregel erstellen.
- Geben Sie auf der Seite Firewallregel erstellen die folgenden Informationen an:
- Name: Geben Sie einen Namen für die Regel an. Verwenden Sie für dieses Beispiel
fw-allow-health-checks
. - Netzwerk: Wählen Sie ein VPC-Netzwerk aus.
- Priorität: Geben Sie eine Zahl für die Priorität ein. Niedrigere Zahlen haben höhere Prioritäten. Achten Sie darauf, dass die Firewallregel eine höhere Priorität hat als andere Regeln, die möglicherweise eingehenden Traffic ablehnen.
- Traffic-Richtung: Wählen Sie eingehend aus.
- Aktion bei Übereinstimmung: Wählen Sie Zulassen aus.
- Ziele: Wählen Sie Angegebene Ziel-Tags aus und geben Sie dann Tags in das Textfeld Ziel-Tags ein. Verwenden Sie für dieses Beispiel
allow-health-checks
. - Quellfilter: Wählen Sie IP-Bereiche aus.
- Quell-IP-Bereiche:
35.191.0.0/16,130.211.0.0/22
- Zulässige Protokolle und Ports: Verwenden Sie
tcp
und den in Ihrer Systemdiagnose konfigurierten Port. TCP ist das zugrunde liegende Protokoll für alle Systemdiagnose-Protokolle. - Klicken Sie auf Erstellen.
- Name: Geben Sie einen Namen für die Regel an. Verwenden Sie für dieses Beispiel
- Fügen Sie das Netzwerktag auf jeder Ihrer Instanzen mit Load-Balancing hinzu, sodass diese neue Firewallregel für eingehenden Traffic auf sie angewendet wird. In diesem Beispiel wird
allow-health-checks
für das Netzwerk-Tag verwendet.
gcloud
Erstellen Sie mit dem folgenden
gcloud
-Befehl eine Firewallregel namensfw-allow-health-checks
, die eingehende TCP-Verbindungen von Google Cloud-Systemdiagnosen zu Instanzen in Ihrem VPC-Netzwerk mit dem Tagallow-health-checks
zulässt. Ersetzen SieNETWORK_NAME
durch den Namen Ihres VPC-Netzwerks undPORT
durch die von Ihrem Load-Balancer verwendeten Ports.gcloud compute firewall-rules create fw-allow-health-checks \ --network=NETWORK_NAME \ --action=ALLOW \ --direction=INGRESS \ --source-ranges=35.191.0.0/16,130.211.0.0/22 \ --target-tags=allow-health-checks \ --rules=tcp:PORT
Fügen Sie das Netzwerktag auf jeder Ihrer Instanzen mit Load-Balancing hinzu, sodass diese neue Firewallregel für eingehenden Traffic auf sie angewendet wird. In diesem Beispiel wird
allow-health-checks
für das Netzwerk-Tag verwendet.
Weitere Informationen finden Sie in der Dokumentation zu gcloud
-Firewallregeln und in der API-Dokumentation.
Regeln für Netzwerk-Load-Balancing
Im folgenden Beispiel wird eine Firewallregel für eingehenden Traffic für das Netzwerk-Load-Balancing erstellt. Die Quell-IP-Bereiche für das Netzwerk-Load-Balancing lauten:
35.191.0.0/16
209.85.152.0/22
209.85.204.0/22
Diese Bereiche gelten für beide Arten von Netzwerk-Load-Balancern: zielpoolbasierte Netzwerk-Load-Balancer die Legacy-Systemdiagnosen verwenden und Back-End-Dienst- und Netzwerk-Load-Balancer die Nicht-Legacy-Systemdiagnosen verwenden.
Console
- Rufen Sie in der Google Cloud Console die Seite „Firewallregeln“ auf.
Zur Seite "Firewall" - Klicken Sie auf Firewallregel erstellen.
- Geben Sie auf der Seite Firewallregel erstellen die folgenden Informationen an:
- Name: Geben Sie einen Namen für die Regel an. Verwenden Sie für dieses Beispiel
fw-allow-network-lb-health-checks
. - Netzwerk: Wählen Sie ein VPC-Netzwerk aus.
- Priorität: Geben Sie eine Zahl für die Priorität ein. Niedrigere Zahlen haben höhere Prioritäten. Achten Sie darauf, dass die Firewallregel eine höhere Priorität hat als andere Regeln, die möglicherweise eingehenden Traffic ablehnen.
- Traffic-Richtung: Wählen Sie eingehend aus.
- Aktion bei Übereinstimmung: Wählen Sie Zulassen aus.
- Ziele: Wählen Sie Angegebene Ziel-Tags aus und geben Sie dann Tags in das Textfeld Ziel-Tags ein. Verwenden Sie für dieses Beispiel
allow-network-lb-health-checks
. - Quellfilter: Wählen Sie IP-Bereiche aus.
- Quell-IP-Bereiche:
35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22
. - Zulässige Protokolle und Ports: Verwenden Sie
tcp
. TCP ist das zugrunde liegende Protokoll für HTTP und HTTPS. - Klicken Sie auf Erstellen.
- Name: Geben Sie einen Namen für die Regel an. Verwenden Sie für dieses Beispiel
- Fügen Sie das Netzwerktag auf jeder Ihrer Instanzen mit Load-Balancing hinzu, sodass diese neue Firewallregel für eingehenden Traffic auf sie angewendet wird. In diesem Beispiel wird
allow-network-lb-health-checks
für das Netzwerk-Tag verwendet.
gcloud
Erstellen Sie mit dem folgenden
gcloud
-Befehl eine Firewallregel namensfw-allow-network-lb-health-checks
, die eingehende TCP-Verbindungen von Google Cloud-Systemdiagnosen zu Instanzen in Ihrem VPC-Netzwerk mit dem Tagallow-network-lb-health-checks
zulässt. Ersetzen SieNETWORK_NAME
durch den Namen Ihres VPC-Netzwerks.gcloud compute firewall-rules create fw-allow-network-lb-health-checks \ --network=NETWORK_NAME \ --action=ALLOW \ --direction=INGRESS \ --source-ranges=35.191.0.0/16,209.85.152.0/22,209.85.204.0/22 \ --target-tags=allow-network-lb-health-checks \ --rules=tcp
Fügen Sie das Netzwerktag auf jeder Ihrer Instanzen mit Load-Balancing hinzu, sodass diese neue Firewallregel für eingehenden Traffic auf sie angewendet wird. In diesem Beispiel wird
allow-network-lb-health-checks
für das Netzwerk-Tag verwendet.
Weitere Informationen finden Sie in der Dokumentation zu gcloud
-Firewallregeln und in der API-Dokumentation.
Systemdiagnosen mit Load-Balancern und Traffic Director verknüpfen
In diesem Abschnitt werden bestimmte Empfehlungen für Systemdiagnosen und die Anforderungen beschrieben, die erfüllt sein müssen, bevor Sie eine Systemdiagnose mit einem Load-Balancer oder Traffic Director verknüpfen.
Übereinstimmung mit dem Protokoll
Es empfiehlt sich, eine Systemdiagnose (oder Legacy-Systemdiagnose) zu verwenden, deren Protokoll dem Protokoll entspricht, das vom Back-End-Dienst oder Zielpool des Load-Balancers verwendet wird. Die Protokolle der Systemdiagnose und des Load-Balancers müssen jedoch nicht identisch sein. Beispiele:
Beim internen TCP/UDP-Load-Balancing können Sie für das Protokoll des Back-End-Dienstes nur
TCP
oderUDP
verwenden. Wenn Sie HTTP-Traffic von VMs hinter einem internen TCP/UDP-Load-Balancer weiterleiten, ist es sinnvoll, eine Systemdiagnose mithilfe des HTTP-Protokolls durchzuführen.Für einen pool-basierten Netzwerk-Load-Balancer muss eine Legacy-HTTP-Systemdiagnose verwendet werden. Es kann keine Legacy-HTTPS-Systemdiagnose oder irgendeine Nicht-Legacy-Systemdiagnosen verwendet werden. Wenn Sie einen Zielpool-basierten Netzwerk-Load-Balancer zum Ausgleich von TCP-Traffic verwenden, müssen Sie einen HTTP-Dienst auf den VMs ausführen, für die das Load-Balancing erfolgt, damit diese auf Systemdiagnosetests reagieren können.
Ein auf dem Back-End-Dienst basierender Netzwerk-Load-Balancer kann Nicht-Legacy-Systemdiagnosen verwenden. Sie können also eine Systemdiagnose verwenden, deren Protokoll dem Protokoll entspricht, das vom Back-End-Dienst des Netzwerk-Load-Balancers verwendet wird.Verwenden Sie für Back-End-Dienste, die das gRPC-Protokoll verwenden, nur gRPC- oder TCP-Systemdiagnosen. Verwenden Sie keine HTTP(S)- oder HTTP/2-Systemdiagnosen.
Systemdiagnosen für Back-End-Dienste
In diesem Abschnitt wird die Verknüpfung einer Systemdiagnose mit einem Back-End-Dienst folgender Typen von Load-Balancern beschrieben:
- Internes TCP/UDP-Load-Balancing
- Internes HTTP(S)-Load-Balancing
- TCP-Proxy-Load-Balancing
- SSL-Proxy-Load-Balancing
- HTTP(S)-Load-Balancing
- Back-End-Dienst-basiertes Netzwerk-Load-Balancing
Folgende Voraussetzungen sollten für diesen Abschnitt erfüllt sein. Sie haben:
- Einen internen TCP/UDP-Load-Balancer, Back-End-Dienst-basierten Netzwerk-Load-Balancer, TCP-Proxy-Load-Balancer, SSL-Proxy-Load-Balancer oder externen HTTP(S)-Load-Balancer erstellt (global oder regional).
- Eine Systemdiagnose erstellt
- Die Firewallregeln für Systemdiagnosen konfiguriert Informationen zu einem auf einem Back-End-Dienst basierenden Netzwerk-Load-Balancer finden Sie unter Firewallregeln für das Netzwerk-Load-Balancing.
Informationen zum Verknüpfen einer Systemdiagnose mit einem neuen internen TCP/UDP-Load-Balancer, einem TCP-Proxy-Load-Balancer, einem SSL-Proxy-Load-Balancer, einem externen HTTP(S)-Load-Balancer oder einem Back-End-basierten Netzwerk-Load-Balancer finden Sie im Einrichtungsleitfaden für den entsprechenden Load-Balancer.
Console
So verknüpfen Sie eine Systemdiagnose mit einem vorhandenen internen TCP/UDP-Load-Balancer, TCP-Proxy-Load-Balancer, SSL-Proxy-Load-Balancer, externen HTTP(S)-Load-Balancer oder einem Back-End-basierten Netzwerk-Load-Balancer:
- Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
Zur Seite „Load-Balancing“ - Klicken Sie auf einen Load-Balancer, um dessen Details aufzurufen.
- Klicken Sie auf Bearbeiten und anschließend auf Back-End-Konfiguration.
- Wählen Sie aus dem Menü Systemdiagnose eine Systemdiagnose aus.
- Klicken Sie auf Aktualisieren.
gcloud
So verknüpfen Sie eine Systemdiagnose mit einem vorhandenen Back-End-Dienst:
Ermitteln Sie den Namen und den Bereich des Back-End-Dienstes. Netzwerk-Load-Balancer, interner TCP/UDP-Load-Balancer, TCP-Proxy-Load-Balancer und SSL-Proxy-Load-Balancer haben nur einen Back-End-Dienst pro Load-Balancer. Externe HTTP(S)-Load-Balancer und interne HTTP(S)-Load-Balancer haben einen oder mehrere Back-End-Dienste, die mit einer einzelnen URL-Zuordnung verknüpft sind.
Führen Sie den folgenden Befehl aus, um Back-End-Dienste für interne TCP/UDP-Load-Balancer aufzulisten. Ersetzen Sie dabei
REGION_LIST
durch eine durch Kommas getrennte Liste der abzufragenden Google Cloud-Regionen.gcloud compute backend-services list \ --filter="region:( REGION1 REGION2 ... ) AND loadBalancingScheme=INTERNAL"
Führen Sie den folgenden Befehl aus, um Back-End-Dienste für Netzwerk-Load-Balancer aufzulisten. Ersetzen Sie dabei jede REGION durch die Google Cloud-Region, die abgefragt werden soll.
gcloud compute backend-services list \ --filter="region:( REGION1 REGION2 ... ) AND loadBalancingScheme=EXTERNAL"
Führen Sie den folgenden Befehl aus, um Back-End-Dienste für TCP-Proxy-Load-Balancer aufzulisten. Back-End-Dienste für TCP-Proxy-Load-Balancer sind immer global, unabhängig von der Netzwerkdienststufe.
gcloud compute backend-services list \ --global \ --filter="loadBalancingScheme=EXTERNAL" \ --filter="protocol=TCP"
Führen Sie den folgenden Befehl aus, um Back-End-Dienste für SSL-Proxy-Load-Balancer aufzulisten. Back-End-Dienste für SSL-Proxy-Load-Balancer sind immer global, unabhängig von der Netzwerkdienststufe.
gcloud compute backend-services list \ --global \ --filter="loadBalancingScheme=EXTERNAL" \ --filter="protocol=SSL"
Zum Identifizieren von Back-End-Diensten für einen externen HTTP(S)-Load-Balancer ermitteln Sie zuerst eine URL-Zuordnung und beschreiben diese anschließend. URL-Zuordnungen und Back-End-Dienste für externe HTTP(S)-Load-Balancer sind immer global, unabhängig von der Netzwerkdienststufe. Ersetzen Sie
URL_MAP_NAME
durch den Namen der URL-Zuordnung. Die vom Load-Balancer verwendeten Back-End-Dienste sind in der Antwort aufgeführt.gcloud compute url-maps list \ --global
gcloud compute url-maps describe URL_MAP_NAME \ --global
Zum Identifizieren von Back-End-Diensten für einen regionalen externen HTTP(S)-Load-Balancer oder einen internen HTTP(S)-Load-Balancer ermitteln Sie zuerst eine URL-Zuordnung und beschreiben diese anschließend. URL-Zuordnungen und Back-End-Dienste für interne HTTP(S)-Load-Balancer sind regional. Ersetzen Sie
REGION_LIST
durch eine durch Kommas getrennte Liste der abzufragenden Google Cloud-Regionen. Ersetzen SieURL_MAP_NAME
durch den Namen der URL-Zuordnung undREGION
durch die Region. Die vom Load-Balancer verwendeten Back-End-Dienste sind in der Antwort aufgeführt.gcloud compute url-maps list \ --regions=REGION_LIST
gcloud compute url-maps describe URL_MAP_NAME \ --region=REGION
Ermitteln Sie eine Systemdiagnose. Siehe Systemdiagnosen auflisten.
Verknüpfen Sie mit dem Befehl
compute backend-services update
eine Systemdiagnose mit dem Back-End-Dienst. Jeder Back-End-Dienst muss auf eine einzelne Systemdiagnose verweisen. Ersetzen Sie in den folgenden BefehlenBACKEND_SERVICE_NAME
durch den Namen des Back-End-Dienstes,HEALTH_CHECK_NAME
durch den Namen der Systemdiagnose und gegebenenfallsREGION
durch die Google Cloud-Region des Back-End-Dienstes, den Status oder beide.So ändern Sie die Systemdiagnose eines internen TCP/UDP-Load-Balancers: Der Back-End-Dienst eines internen TCP/UDP-Load-Balancers ist regional. Er kann auf eine globale oder regionale Systemdiagnose verweisen. Das folgende Beispiel zeigt eine regionale Systemdiagnose. Wenn Sie eine globale Systemdiagnose mit Ihrem internen TCP/UDP-Load-Balancer verwenden, verwenden Sie
--global-health-checks
anstelle von--health-checks-region
.gcloud compute backend-services update BACKEND_SERVICE_NAME \ --region=REGION \ --health-checks=HEALTH_CHECK_NAME \ --health-checks-region=REGION
So ändern Sie die Systemdiagnose eines Back-End-Dienst-basierten Netzwerk-Load-Balancers: Der Back-End-Dienst eines Netzwerk-Load-Balancers ist regional. Er kann auf eine regionale Systemdiagnose verweisen.
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --region=REGION \ --health-checks=HEALTH_CHECK_NAME \ --health-checks-region=REGION
So ändern Sie die Systemdiagnose für einen TCP-Proxy-Load-Balancer, einen SSL-Proxy-Load-Balancer oder einen externen HTTP(S)-Load-Balancer: Sowohl der Back-End-Dienst als auch die Systemdiagnose sind für diese Load-Balancer global. Ein externer HTTP(S)-Load-Balancer kann auf mehrere Systemdiagnosen verweisen, wenn er auf mehr als einen Back-End-Dienst verweist.
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --global \ --health-checks HEALTH_CHECK_NAME \ --global-health-checks
So ändern Sie die Systemdiagnose für einen regionalen externen HTTP(S)-Load-Balancer oder einen internen HTTP(S)-Load-Balancer: Sowohl der Back-End-Dienst als auch die Systemdiagnose sind regional. Ein interner HTTP(S)-Load-Balancer kann auf mehrere Systemdiagnosen verweisen, wenn er auf mehr als einen Back-End-Dienst verweist.
gcloud compute backend-services update BACKEND_SERVICE_NAME \ --region=REGION \ --health-checks=HEALTH_CHECK_NAME \ --health-checks-region=REGION
API
Sie können Back-End-Dienste mit dem API-Aufruf backendServices.list auflisten.
Verwenden Sie einen der folgenden API-Aufrufe, um eine Systemdiagnose mit einem Back-End-Dienst zu verknüpfen:
Legacy-Systemdiagnosen für zielpoolbasiertes Netzwerk-Load-Balancing
In diesem Abschnitt wird beschrieben, wie Sie für das Netzwerk-Load-Balancing eine Legacy-Systemdiagnose mit einem Zielpool verknüpfen. Folgende Voraussetzungen sollten für diesen Abschnitt erfüllt sein. Sie haben:
- Einen zielpoolbasierten Netzwerk-Load-Balancer erstellt.
- Eine Legacy-Systemdiagnose erstellt
- Die Firewallregeln für das Netzwerk-Load-Balancing konfiguriert
Informationen zum Verknüpfen einer Legacy-Systemdiagnose mit einem neuen Netzwerk-Load-Balancer finden Sie unter Netzwerk-Load-Balancing mit einem Zielpool einrichten. Sie müssen beim Erstellen eines Netzwerk-Load-Balancers eine Legacy-Systemdiagnose mit seinem Zielpool verknüpfen.
Console
So verknüpfen Sie eine Systemdiagnose mit einem vorhandenen zielpoolbasierten Netzwerk-Load-Balancer:
- Öffnen Sie in der Google Cloud Console die Seite "Load-Balancing".
Zur Seite „Load-Balancing“ - Klicken Sie auf einen Netzwerk-Load-Balancer, um dessen Details aufzurufen.
- Klicken Sie auf Bearbeiten und anschließend auf Back-End-Konfiguration.
- Wählen Sie aus dem Menü Systemdiagnose eine Legacy-Systemdiagnose aus. (Es werden nur zulässige Systemdiagnosen angezeigt.)
- Klicken Sie auf Aktualisieren.
gcloud
So verknüpfen Sie eine Systemdiagnose mit einem vorhandenen zielpoolbasierten Netzwerk-Load-Balancer:
Ermitteln Sie den Zielpool bzw. die Zielpools. Ein Netzwerk-Load-Balancer hat mindestens einen Zielpool und möglicherweise einen sekundären Sicherungspool.
gcloud compute target-pools list
Ermitteln Sie eine Legacy-Systemdiagnose mithilfe des
HTTP
-Protokolls. Rufen Sie bei Bedarf die Legacy-Systemdiagnosen auf.Verknüpfen Sie die Legacy-Systemdiagnose mit dem Zielpool bzw. den Zielpools. Ersetzen Sie in den folgenden Befehlen
TARGET_POOL_NAME
durch den Namen des Zielpools,REGION
durch seine Region undLEGACY_CHECK_NAME
durch den Namen der Legacy-Systemdiagnose. Die Legacy-Systemdiagnose muss das HTTP-Protokoll verwenden.So entfernen Sie eine Legacy-HTTP-Systemdiagnose aus einem Zielpool:
gcloud compute target-pools remove-health-checks TARGET_POOL_NAME \ --region=REGION \ --http-health-check LEGACY_CHECK_NAME
So fügen Sie einem Zielpool eine Legacy-HTTP-Systemdiagnose hinzu:
gcloud compute target-pools add-health-checks TARGET_POOL_NAME \ --region=REGION \ --http-health-check LEGACY_CHECK_NAME
API
Sie können Zielpools mit dem API-Aufruf targetPools.list auflisten.
Rufen Sie die Legacy-Systemdiagnosen auf und ermitteln Sie eine Legacy-HTTP-Systemdiagnose.
Wenn Sie eine Legacy-HTTP-Systemdiagnose mit einem Zielpool verknüpfen möchten, verwenden Sie den API-Aufruf targetPools.addHealthCheck.
Status der Systemdiagnose prüfen
Nachdem Sie eine Systemdiagnose mit einem Back-End-Dienst oder einem Zielpool verknüpft haben, können Sie den sofortigen Status der Systemdiagnose für die Back-Ends des Load-Balancers abrufen.
Console
- Wechseln Sie zur Seite der Load-Balancing-Zusammenfassung.
Zur Seite "Load-Balancing" - Klicken Sie auf den Namen eines Load-Balancers.
- Prüfen Sie unter Back-End die Spalte Fehlerfrei. Der Systemstatus wird für jede Back-End-Instanzgruppe oder Netzwerk-Endpunktgruppe gemeldet.
gcloud
Bestimmen Sie für alle Load-Balancer mit Ausnahme von poolbasierten Netzwerk-Load-Balancern den Namen und den Umfang des Back-End-Dienstes. Back-End-Dienst-basierte Netzwerk-Load-Balancer, interne TCP/UDP-Load-Balancer, regionale externe HTTP(S)-Load-Balancer und interne HTTP(S)-Load-Balancer verwenden regionale Back-End-Dienste. Der TCP-Proxy-Load-Balancer, der SSL-Proxy-Load-Balancer und der externe HTTP(S)-Load-Balancer verwenden globale Back-End-Dienste.
Verwenden Sie den Befehl
compute backend-services get-health
. Ersetzen Sie dabeiNAME
durch den Namen des Back-End-Dienstes und bei BedarfREGION
durch die Region.So rufen Sie den sofortigen Systemzustand eines globalen Back-End-Dienstes ab:
gcloud compute backend-services get-health NAME \ --global
So rufen Sie den sofortigen Systemzustand eines regionalen Back-End-Dienstes ab:
gcloud compute backend-services get-health NAME \ --region=REGION
Identifizieren Sie für zielpoolbasierte Netzwerk-Load-Balancer den Namen und die Region des Zielpools des Load-Balancers und verwenden Sie dann den Befehl
compute target-pools get-health
. Ersetzen Sie dabeiNAME
durch den Namen des Zielpools undREGION
durch seine Region.gcloud compute target-pools get-health NAME \ --region=REGION
API
Bestimmen Sie für alle Load-Balancer mit Ausnahme von poolbasierten Netzwerk-Load-Balancern den Namen und den Umfang des Back-End-Dienstes. Back-End-Dienst-basierte Netzwerk-Load-Balancer, interne TCP/UDP-Load-Balancer, regionale externe HTTP(S)-Load-Balancer und interne HTTP(S)-Load-Balancer verwenden regionale Back-End-Dienste. Der TCP-Proxy-Load-Balancer, der SSL-Proxy-Load-Balancer und der externe HTTP(S)-Load-Balancer verwenden globale Back-End-Dienste.
Mit backendServices.getHealth können Sie den sofortigen Systemzustand eines globalen Back-End-Dienstes ermitteln.
Mit regionBackendServices.getHealth können Sie den sofortigen Systemzustand eines regionalen Back-End-Dienstes ermitteln.
Verwenden Sie für zielpoolbasierte Netzwerk-Load-Balancer targetPools.getHealth.