Systemdiagnosen erstellen

Die Google Cloud Platform (GCP) bietet Mechanismen zur Systemdiagnose, die bestimmen, ob VM-Instanzen ordnungsgemäß auf Traffic antworten. In diesem Dokument wird beschrieben, wie Systemdiagnosen für Load-Balancer erstellt und verwendet werden.

Auf dieser Seite wird davon ausgegangen, dass Sie mit Konzepten der Systemdiagnose vertraut sind und über Kenntnisse der GCP-Firewallregeln verfügen.

Kategorien, Protokolle und Ports der Systemdiagnose

Die GCP organisiert Systemdiagnosen nach Kategorie und Protokoll.

Es gibt zwei Systemdiagnose-Kategorien: Systemdiagnosen und Legacy-Systemdiagnosen. Jede Kategorie unterstützt einen anderen Satz von Protokollen und eine Methode zur Angabe des Ports, der für die Systemdiagnose verwendet wird.

Die meisten Load-Balancer verwenden Nicht-Legacy-Systemdiagnosen, für das Netzwerk-Load-Balancing ist jedoch die Verwendung von Legacy-Systemdiagnosen erforderlich. Weitere Informationen zur Bestimmung der entsprechenden Kategorie, des Protokolls und der Portspezifikationsmethode finden Sie unter Auswählen einer Systemdiagnose auf der Seite Systemdiagnosekonzepte.

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 erstellen

Mit der GCP können Sie eine Systemdiagnose erstellen oder auswählen, wenn Sie die Back-End-Konfiguration des Load-Balancers in der GCP Console vornehmen.

Sie können eine Systemdiagnose auch unabhängig von der Konfiguration des Load-Balancers in der GCP Console 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 GCP Console, dem gcloud-Befehlszeilentool oder den REST APIs erstellen. Nachdem Sie die Hintergrundinformationen in diesem Abschnitt gelesen haben, können Sie eine weiterführende Anleitung unter Systemdiagnosen erstellen und ändern abrufen.

Netzwerk-Load Balancer müssen Legacy-Systemdiagnosen verwenden, die Sie erstellen oder auswählen können, wenn Sie die Back-End-Konfiguration des Netzwerk-Load-Balancers in der GCP Console vornehmen. Um unabhängig davon eine Legacy-Systemdiagnose zu erstellen, müssen Sie entweder das gcloud-Befehlszeilentool oder die REST APIs verwenden. Weitere Informationen dazu erhalten Sie unter Legacy-Systemdiagnosen.

Flags, die von allen Systemdiagnosen verwendet werden

Die folgenden Flags gelten unabhängig vom Protokoll für alle Systemdiagnosen:

gcloud compute health-checks create PROTOCOL HEALTH_CHECK_NAME \
    --description=DESCRIPTION \
    --check-interval=CHECK_INTERVAL \
    --timeout=TIMEOUT \
    --healthy-threshold=HEALTHY_THRESHOLD \
    --unhealthy-threshold=UNHEALTHY_THRESHOLD \
    ...additional flags

Dabei gilt:

• PROTOCOL definiert das für die Systemdiagnose verwendete Protokoll. Gültige Optionen sind http, https, http2, ssl und tcp.
• HEALTH_CHECK_NAME ist der Name der Systemdiagnose. Innerhalb eines bestimmten Projekts muss jede Systemdiagnose einen eindeutigen Namen haben.
• 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 nicht angegeben, verwendet die GCP einen Wert von 5s (5 Sekunden).
• TIMEOUT ist die Zeitspanne, die die GCP auf eine Antwort für einen Testdurchlauf wartet. Der Wert von TIMEOUT muss kleiner oder gleich dem von CHECK_INTERVAL sein. Die Einheiten sind Sekunden. Wenn nicht angegeben, verwendet die GCP einen Wert von 5s (5 Sekunden).
• HEALTHY_THRESHOLD und UNHEALTHY_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 die GCP einen Standardschwellenwert von 2.
• ...additional flags sind weitere Flags zur Festlegung von Ports und Optionen speziell für das PROTOCOL. Diese Flags werden in den folgenden Abschnitten erläutert.

Flags zur Portspezifikation

Dieses Produkt oder Feature ist eine Vorabveröffentlichung, für die möglicherweise nur eingeschränkter Support verfügbar ist. Änderungen sind jederzeit möglich. Weitere Informationen finden Sie unter Produkte und Dienste.

Zusätzlich zu einem Protokoll müssen Sie einen Port für eine Systemdiagnose angeben. Die Art und Weise, wie Sie den Port angeben, hängt vom Typ des Load-Balancers und vom Typ des Back-Ends ab, das von seinem Back-End-Dienst verwendet wird. Die folgende Tabelle enthält Optionen der Portspezifikation für gültige Kombinationen von Load-Balancern und Back-Ends. Wie in der Tabelle verwendet, bezieht sich der Begriff Instanzgruppe auf nicht verwaltete Instanzgruppen, verwaltete zonale Instanzgruppen oder verwaltete regionale Instanzgruppen.

Systemdiagnosen können nur einen Typ von Portspezifikation verwenden.

Load-Balancer	Back-End-Typ	Portspezifikation
Internes TCP/UDP-Load-Balancing	Instanzgruppen	Verwenden Sie eine dieser Optionen^1: • --port: Geben Sie einen Port als Zahl von 1 bis 65535 an • --port-name: Geben Sie einen beliebigen benannten Port an, der von einer Instanzgruppe exportiert wurde Sie können das Flag --use-serving-port nicht für eine Systemdiagnose verwenden, die mit einem internen Load-Balancer verknüpft ist, da bei Back-End-Diensten für interne Load-Balancer keine Portspezifikation vorhanden ist.
Internes HTTP(S)-Load-Balancing TCP-Proxy-Load-Balancing SSL-Proxy-Load-Balancing HTTP(S)-Load-Balancing	Netzwerkendpunktgruppen	Verwenden Sie eine dieser Optionen^1: • --port: Geben Sie einen Port als Zahl von 1 bis 65535 an • --use-serving-port^2: Verwenden Sie den von jedem Endpunkt in der Netzwerkendpunktgruppe angegebenen Port.
	Instanzgruppen	Verwenden Sie eine dieser Optionen^1: • --port: Geben Sie einen Port als Zahl von 1 bis 65535 an • --port-name: Geben Sie einen beliebigen benannten Port an, der von einer Instanzgruppe exportiert wurde • --use-serving-port ^2: Verwenden Sie denselben nach der Instanzgruppe benannten Port, den der Back-End-Dienst gemäß seiner Konfiguration nutzt.

¹Kombinationen von Portspezifikationen werden folgendermaßen aufgelöst:

• Wenn --use-serving-port angegeben ist, können weder --port noch --port-name angegeben werden.
• Wenn sowohl --port als auch --port-name angegeben sind, hat --port Vorrang.
• Wenn keine der drei Optionen angegeben ist, lautet der Standardwert: --port=80

²Beta: Sie müssen die folgenden gcloud-Betabefehle verwenden, wenn Sie --use-serving-port benötigen:

• gcloud beta compute health-checks create
• gcloud beta compute health-checks update

Optionale 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 Intervalle, Zeitüberschreitungen und Fehlerschwellenwerte erstellt.

gcloud compute health-checks create http hc-http-port-80 \
    --description="Simple HTTP port 80 health check" \
    --check-interval=5s \
    --timeout=5s \
    --healthy-threshold=2 \
    --unhealthy-threshold=2 \
    --port=80 \
    --host=HOST \
    --proxy-header=PROXY_HEADER \
    --request-path=REQUEST_PATH \
    --response=RESPONSE

• Das Protokoll kann http (wie in diesem Beispiel), https oder http2 sein.
• Unter HOST können Sie einen Host-HTTP-Header anzugeben. Wenn nicht angegeben, wird die IP-Adresse der Weiterleitungsregel des Load-Balancers verwendet.
• PROXY_HEADER muss entweder NONE oder PROXY_V1 sein. Wenn nicht angegeben, verwendet die GCP NONE. Der Wert von PROXY_V1 fügt den Header PROXY UNKNOWN\r\n hinzu.
• REQUEST_PATH gibt den URL-Pfad an, den die GCP zum 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, z. B. werden Operatoren wie ! in HAProxy nicht unterstützt.

Wenn die GCP den erwarteten Antwortstring an einer beliebigen Stelle in den ersten 1.024 Byte des empfangenen Antworttexts findet und der HTTP-Status 200 (OK) lautet, gilt der Testdurchlauf als erfolgreich.

Die Flags --request-path und --response ändern die Erfolgskriterien für den Systemdiagnosetest.

Optionale 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 Intervalle, Zeitüberschreitungen und Fehlerschwellenwerte erstellt.

gcloud compute health-checks create tcp hc-tcp-3268 \
    --description="Health check: TCP 3268" \
    --check-interval=5s \
    --timeout=5s \
    --healthy-threshold=2 \
    --unhealthy-threshold=2 \
    --port=3268 \
    --proxy-header=PROXY_HEADER \
    --request=REQUEST_STRING \
    --response=RESPONSE_STRING

• Das Protokoll kann tcp (wie in diesem Beispiel) oder ssl sein.
• PROXY_HEADER muss entweder NONE oder PROXY_V1 sein. Wenn nicht angegeben, verwendet die GCP NONE. Der Wert von PROXY_V1 fügt den Header PROXY UNKNOWN\r\n hinzu.
• 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 den Systemdiagnosetest. Wenn Sie das Flag --response verwenden, entweder allein oder in Verbindung mit dem Flag --request, muss die zurückgegebene Antwort genau mit dem erwarteten Antwortstring übereinstimmen.

Systemdiagnosen erstellen und ändern

Sie können eine Systemdiagnose nicht in eine Legacy-Systemdiagnose konvertieren oder umgekehrt, indem Sie sie ändern.

Console

In der GCP Console werden sowohl Systemdiagnosen als auch Legacy-Systemdiagnosen aufgelistet. Sie können vorhandene Systemdiagnosen und Legacy-Systemdiagnosen bearbeiten. Sie können jedoch keine Legacy-Systemdiagnose auf der Seite "Systemdiagnosen" in der GCP Console erstellen.

So erstellen Sie eine Systemdiagnose:

1. Gehen Sie in der Google Cloud Platform Console auf die Seite "Systemdiagnosen".
   Weiter zur Seite der Systemdiagnosen
2. Klicken Sie auf Systemdiagnose erstellen.
3. 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.
   • Protokoll: Wählen Sie ein Protokoll für die Systemdiagnose aus.
   • Port: Geben Sie eine Portnummer an.
   • 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 Optionale 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 Optionale Flags für SSL- und TCP-Systemdiagnosen.
   • Check interval: Definiert die Zeitspanne vom Start einer Prüfung bis zum Start der nächsten.
   • Timeout: Definiert, wie lange die GCP bei einer Prüfung auf eine Antwort wartet. Der Wert muss kleiner oder gleich dem Überprüfungsintervall sein.
   • Healthy threshold: Definiert die Anzahl der sequenziellen Prüfungen, die bestanden werden müssen, damit eine Instanz als fehlerfrei erachtet wird.
   • Unhealthy threshold: Definiert die Anzahl der sequenziellen Prüfungen, die nicht bestanden werden müssen, damit eine Instanz als fehlerhaft erachtet wird.
4. Klicken Sie auf Erstellen.

So bearbeiten Sie eine Systemdiagnose:

1. Gehen Sie in der Google Cloud Platform Console auf die Seite "Systemdiagnosen".
   Weiter zur Seite der Systemdiagnosen
2. Klicken Sie auf eine Systemdiagnose, um die zugehörigen Details anzusehen.
3. Wenn Sie die Systemdiagnose ändern müssen, klicken Sie auf Bearbeiten und danach:
   • Nehmen Sie nach Bedarf Änderungen an den Parametern vor.
   • Klicken Sie auf Speichern.

gcloud

1. Mit den folgenden gcloud-Befehlen listen Sie Systemdiagnosen auf:

   gcloud compute health-checks list
   

2. Ermitteln Sie eine Systemdiagnose, beschreiben Sie sie mit dem entsprechenden gcloud-Befehl und ersetzen Sie HEALTH_CHECK_NAME durch den Namen der Systemdiagnose.

   gcloud compute health-checks describe HEALTH_CHECK_NAME
   

3. Verwenden Sie zum Ändern der Systemdiagnose den entsprechenden gcloud-Befehl und ersetzen Sie dabei HEALTH_CHECK_NAME durch den Namen der Systemdiagnose. Mit Ausnahme des Namens und Protokolls der Systemdiagnose können Sie alle allgemeinen Flags, Portspezifikations-Flags und optionalen Flags ändern. Wenn Sie eine vorhandene Systemdiagnose mithilfe des Befehls gcloud compute health-checks update ändern, werden vorkonfigurierte Einstellungen für Flags beibehalten, die Sie weglassen. Mit dem folgenden Befehl wird eine Beispiel-Systemdiagnose geändert, indem das Überprüfungsintervall, die Zeitüberschreitung und der Anfragepfad angepasst werden:

   gcloud compute health-checks update http hc-http-port-80 \
       --check-interval=20s \
       --timeout=15s \
       --request-path="/health"
   

API

1. Sie können Systemdiagnosen mit dem API-Aufruf healthChecks.list auflisten.

2. Wenn Sie den Namen einer Systemdiagnose kennen, können Sie ihre Konfigurationsdetails mit dem API-Aufruf healthChecks.get abrufen.

3. Wenn Sie eine Systemdiagnose ändern müssen, verwenden Sie diese API-Aufrufe:

   • healthChecks.update
   • healthChecks.patch

Legacy-Systemdiagnosen

Legacy-Systemdiagnosen erstellen

In diesem Abschnitt wird beschrieben, wie Sie Legacy-Systemdiagnosen erstellen, die für Netzwerk-Load-Balancer erforderlich sind.

Hinweis: Obwohl Legacy-Systemdiagnosen sowohl mit dem HTTP- als auch mit dem HTTPS-Protokoll erstellt werden können, unterstützen Netzwerk-Load-Balancer nur Legacy-Systemdiagnosen, die das HTTP-Protokoll verwenden.

Console

Obwohl die Seite "Systemdiagnosen" der GCP Console sowohl Systemdiagnosen als auch Legacy-Systemdiagnosen auflistet, können Sie in der GCP Console keine Legacy-Systemdiagnose erstellen. Sie können eine Legacy-Systemdiagnose nur über die Seite "Netzwerk-Load-Balancer" der GCP Console erstellen.

gcloud

Verwenden Sie den folgenden gcloud-Befehl, um eine Legacy-Systemdiagnose für einen Netzwerk-Load-Balancer zu erstellen:

gcloud compute LEGACY_CHECK_TYPE create LEGACY_HEALTH_CHECK_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 ist http-health-checks bei einer Legacy-HTTP-Systemdiagnose oder https-health-checks für eine Legacy-HTTPS-Systemdiagnose. Wenn Sie die Legacy-Systemdiagnose für einen Netzwerk-Load-Balancer erstellen, müssen Sie http-health-checks verwenden.
• LEGACY_HEALTH_CHECK_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 definiert die Zeitspanne vom Start einer Prüfung bis zum Start der nächsten. Die Einheiten sind Sekunden. Wenn nicht angegeben, verwendet die GCP einen Wert von 5s (5 Sekunden).
• Timeout definiert, wie lange die GCP bei einer Prüfung auf eine Antwort wartet. Der Wert von TIMEOUT muss kleiner oder gleich dem von CHECK_INTERVAL sein. Die Einheiten sind Sekunden. Wenn nicht angegeben, verwendet die GCP einen Wert von 5s (5 Sekunden).
• HEALTHY_THRESHOLD und UNHEALTHY_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 die GCP einen Standardschwellenwert von 2.
• 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 nicht angegeben, verwendet die GCP 80.
• REQUEST_PATH gibt den URL-Pfad an, den die GCP zum Senden von Systemdiagnoseanfragen verwendet. Wenn nichts angegeben ist, werden Systemdiagnoseanfragen an / gesendet.

API

Mit folgendem API-Aufruf können Sie für einen Netzwerk-Load-Balancer eine Legacy-Systemdiagnose erstellen:

• httpHealthChecks.insert

Legacy-Systemdiagnosen aufrufen und ändern

Console

In der GCP Console werden sowohl Systemdiagnosen als auch Legacy-Systemdiagnosen auf der Seite "Systemdiagnosen" aufgelistet. So bearbeiten Sie eine vorhandene Legacy-Systemdiagnose:

1. Gehen Sie in der Google Cloud Platform Console auf die Seite "Systemdiagnosen".
   Weiter zur Seite der Systemdiagnosen
2. Klicken Sie auf eine Systemdiagnose, um die zugehörigen Details anzusehen.
3. Wenn Sie die Systemdiagnose ändern müssen, klicken Sie auf Bearbeiten und danach:
   • Nehmen Sie nach Bedarf Änderungen an den Parametern vor.
   • Klicken Sie auf Speichern.

gcloud

1. Verwenden Sie die folgenden gcloud-Befehle, um Legacy-Systemdiagnosen für Netzwerk-Load-Balancer aufzulisten.

   gcloud compute http-health-checks list
   

2. Ermitteln Sie eine Systemdiagnose, beschreiben Sie sie mit dem entsprechenden gcloud-Befehl und ersetzen Sie LEGACY_HEALTH_CHECK_NAME durch den Namen der Systemdiagnose.

   gcloud compute http-health-checks describe LEGACY_HEALTH_CHECK_NAME
   

3. Wenn Sie eine Systemdiagnose ändern müssen, verwenden Sie den entsprechenden gcloud-Befehl und ersetzen Sie LEGACY_HEALTH_CHECK_NAME durch den Namen der Systemdiagnose. Beim Ändern einer Systemdiagnose mit gcloud werden vorhandene Einstellungen für die Flags beibehalten, die Sie auslassen.

   gcloud compute http-health-checks update LEGACY_HEALTH_CHECK_NAME \
       ...other options
   

   Dabei sind ...other options die Optionen zum Erstellen einer Legacy-Systemdiagnose.

API

1. Verwenden Sie den folgenden API-Aufruf, um Legacy-Systemdiagnosen für Netzwerk-Load-Balancer aufzulisten.

   • httpHealthChecks.list

2. Wenn Sie den Namen einer Legacy-Systemdiagnose kennen, können Sie ihre Konfigurationsdetails mit diesem API-Aufruf abrufen:

   • httpHealthChecks.get

3. Wenn Sie eine Legacy-Systemdiagnose ändern müssen, verwenden Sie diese API-Aufrufe:

   • httpHealthChecks.update
   • httpHealthChecks.patch

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 Netzwerktags konfigurieren.

Jedes dieser Beispiele lässt den gesamten TCP-Traffic von GCP-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 die GCP Ihre VMs über HTTP an Port 80 kontaktieren könnte, aber nicht über HTTPS an Port 443.

Regeln für Systemdiagnosen

Das folgende Beispiel erstellt eine Firewallregel für eingehenden Traffic für nachstehende Load-Balancer:

• Internes TCP/UDP-Load-Balancing (Systemdiagnosen)
• Internes HTTP(S)-Load-Balancing (Systemdiagnosen)
• TCP-Proxy-Load-Balancing (Systemdiagnosen)
• SSL-Proxy-Load-Balancing (Systemdiagnosen)
• HTTP(S)-Load-Balancing (Systemdiagnosen und Legacy-Systemdiagnosen)

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

Nur beim internen HTTP(S)-Load-Balancing umfasst der Quell-IP-Bereich alle IP-Adressen im Nur-Proxysubnetz.

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

1. Rufen Sie in der Google Cloud Platform Console die Seite "Firewallregeln" auf.
   Zur Seite "Firewallregeln"
2. Klicken Sie auf Firewallregel erstellen.
3. 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 Zieltags aus und geben Sie dann Tags in das Textfeld Zieltags 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. TCP ist das zugrunde liegende Protokoll für alle Systemdiagnose-Protokolle.
   • Klicken Sie auf Erstellen.
4. 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 Netzwerktag verwendet.

gcloud

1. Verwenden Sie den folgenden gcloud-Befehl, um eine Firewallregel namens fw-allow-health-checks zu erstellen, die eingehende Verbindungen zu Instanzen in Ihrem Netzwerk mit dem Tag allow-health-checks erlaubt. Ersetzen Sie NETWORK_NAME durch den Namen Ihres Netzwerks.

   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

2. 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 Netzwerktag verwendet.

Weitere Informationen finden Sie in der Dokumentation zu gcloud-Firewallregeln und in der API-Dokumentation.

Regeln für Netzwerk-Load-Balancing

Das folgende Beispiel erstellt eine Firewallregel für eingehenden Traffic für das Netzwerk-Load-Balancing, wofür eine Legacy-Systemdiagnose benötigt wird. Die Quell-IP-Bereiche der Legacy-Systemdiagnosen für das Netzwerk-Load-Balancing lauten:

• 35.191.0.0/16
• 209.85.152.0/22

• 209.85.204.0/22

Console

1. Rufen Sie in der Google Cloud Platform Console die Seite "Firewallregeln" auf.
   Zur Seite "Firewallregeln"
2. Klicken Sie auf Firewallregel erstellen.
3. 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 Zieltags aus und geben Sie dann Tags in das Textfeld Zieltags 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.
4. 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 Netzwerktag verwendet.

gcloud

1. Verwenden Sie den folgenden gcloud-Befehl, um eine Firewallregel namens fw-allow-network-lb-health-checks zu erstellen, die eingehende Verbindungen zu Instanzen in Ihrem Netzwerk mit dem Tag allow-network-lb-health-checks erlaubt. Ersetzen Sie NETWORK_NAME durch den Namen Ihres 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

2. 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 Netzwerktag verwendet.

Weitere Informationen finden Sie in der Dokumentation zu gcloud-Firewallregeln und in der API-Dokumentation.

Verknüpfung mit Load-Balancern

Protokolle und Load-Balancer

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 oder UDP verwenden. Wenn Sie HTTP-Traffic von VMs hinter einem internen Load-Balancer weiterleiten, ist es sinnvoll, eine Systemdiagnose mithilfe des HTTP-Protokolls durchzuführen.

• Eine Legacy-Systemdiagnose ist auf das HTTP-Protokoll beschränkt. Wenn Sie einen Netzwerk-Load-Balancer verwenden, um TCP-Traffic auszugleichen, müssen Sie einen HTTP-Dienst auf den VMs ausführen, für die das Load-Balancing gilt, damit diese auf Systemdiagnosetests reagieren können.

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

Folgende Voraussetzungen sollten für diesen Abschnitt erfüllt sein. Sie haben:

• Einen internen TCP-Proxy-, SSL-Proxy- oder HTTP(S)-Load-Balancer erstellt.
• Eine Systemdiagnose erstellt.
• Die Firewallregeln für Systemdiagnosen konfiguriert.

Informationen zur Verknüpfung einer Systemdiagnose mit einem neuen TCP-Proxy-, SSL-Proxy- oder HTTP(S)-Load-Balancer finden Sie in der Einrichtungsanleitung für den entsprechenden Load-Balancer.

Console

So verknüpfen Sie eine Systemdiagnose mit einem vorhandenen internen, TCP-Proxy-, SSL-Proxy- oder HTTP(S)-Load-Balancer:

1. Gehen Sie in der Google Cloud Platform Console zur Seite "Load-Balancing".
   Zur Seite "Load-Balancing"
2. Klicken Sie auf einen Load-Balancer, um dessen Details aufzurufen.
3. Klicken Sie auf Bearbeiten und anschließend auf Back-End-Konfiguration.
4. Wählen Sie aus dem Menü Systemdiagnose eine Systemdiagnose aus.
5. Klicken Sie auf Aktualisieren.

gcloud

So verknüpfen Sie eine Systemdiagnose mit einem vorhandenen internen, TCP-Proxy-, SSL-Proxy- oder HTTP(S)-Load-Balancer:

1. Identifizieren Sie den Back-End-Dienst oder die Back-End-Dienste, die vom Load-Balancer verwendet werden. Interne, TCP-Proxy- und SSL-Proxy-Load-Balancer haben nur einen Back-End-Dienst für den gesamten Load-Balancer. HTTP(S)-Load-Balancer haben einen oder mehrere Back-End-Dienste, die mit ihrer URL-Zuordnung verknüpft sind.

   • Führen Sie den folgenden Befehl aus, um Back-End-Dienste für interne TCP/UDP-Load-Balancer aufzulisten. Ermitteln Sie den Namen und die Region des Back-End-Dienstes.

     gcloud compute backend-services list \
         --filter="loadBalancingScheme=INTERNAL"
     

   • Führen Sie den folgenden Befehl aus, um Back-End-Dienste für interne HTTP(S) -Load-Balancer aufzulisten. Ermitteln Sie den Namen und die Region des Back-End-Dienstes.

     gcloud compute backend-services list \
         --filter="loadBalancingScheme=INTERNAL_MANAGED"
     

   • So listen Sie Back-End-Dienste für TCP-Proxy-Load-Balancer auf:

     gcloud compute backend-services list \
         --filter="loadBalancingScheme=EXTERNAL" \
         --filter="protocol=TCP"
     

   • So listen Sie Back-End-Dienste für SSL-Proxy-Load-Balancer auf:

     gcloud compute backend-services list \
         --filter="loadBalancingScheme=EXTERNAL" \
         --filter="protocol=SSL"
     

   • Wenn Sie Back-End-Dienste für HTTP(S)-Load-Balancing ermitteln möchten, identifizieren Sie die URL-Zuordnung, beschreiben Sie sie und ersetzen Sie URL_MAP_NAME durch den Namen der URL-Zuordnung. Die verwendeten Back-End-Dienste werden im Abschnitt pathMatchers der Antwort aufgelistet.

     gcloud compute url-maps list
     gcloud compute url-maps describe URL_MAP_NAME
     

2. Ermitteln Sie eine Systemdiagnose. Bei Bedarf rufen Sie die Systemdiagnosen auf.

3. Verknüpfen Sie die Systemdiagnose mit dem Back-End-Dienst. Ersetzen Sie in den folgenden Befehlen BACKEND_SERVICE_NAME durch den Namen des Back-End-Dienstes und HEALTH_CHECK_NAME durch den Namen der Systemdiagnose. Diese Befehle ersetzen alle Systemdiagnosen, die mit dem Back-End-Dienst verknüpft sind. In den meisten Fällen ist nur eine Systemdiagnose mit dem Back-End-Dienst verknüpft.

   • Verwenden Sie den folgenden Befehl, um die Systemdiagnose eines Back-End-Dienstes für einen internen Load-Balancer zu ändern. Da die Back-End-Dienste für interne Load-Balancer regional sind, müssen Sie neben dem Namen auch die REGION angeben.

     gcloud compute backend-services update BACKEND_SERVICE_NAME \
         --region REGION \
         --health-checks HEALTH_CHECK_NAME
     

   • So ändern Sie die Systemdiagnose eines Back-End-Dienstes für TCP-Proxy-, SSL-Proxy- und HTTP(S)-Load-Balancer:

     gcloud compute backend-services update BACKEND_SERVICE_NAME \
         --global \
         --health-checks HEALTH_CHECK_NAME
     

API

1. Sie können Back-End-Dienste mit dem API-Aufruf backendServices.list auflisten.

2. Systemdiagnosen aufrufen

3. Verwenden Sie einen der folgenden API-Aufrufe, um eine Systemdiagnose mit einem Back-End-Dienst zu verknüpfen:

   • backendServices.update
   • backendServices.patch

Legacy-Systemdiagnosen für 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 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 einrichten. Wenn Sie einen neuen Netzwerk-Load-Balancer erstellen, müssen Sie eine Legacy-Systemdiagnose mit seinem Zielpool verknüpfen.

Console

So verknüpfen Sie eine Systemdiagnose mit einem vorhandenen Netzwerk-Load-Balancer:

1. Gehen Sie in der Google Cloud Platform Console zur Seite "Load-Balancing".
   Zur Seite "Load-Balancing"
2. Klicken Sie auf einen Netzwerk-Load-Balancer, um dessen Details aufzurufen.
3. Klicken Sie auf Bearbeiten und anschließend auf Back-End-Konfiguration.
4. Wählen Sie aus dem Menü Systemdiagnose eine Legacy-Systemdiagnose aus. (Es werden nur zulässige Systemdiagnosen angezeigt.)
5. Klicken Sie auf Aktualisieren.

gcloud

So verknüpfen Sie eine Systemdiagnose mit einem vorhandenen Netzwerk-Load-Balancer:

1. Ermitteln Sie den Zielpool bzw. die Zielpools. Netzwerk-Load-Balancer verfügen über mindestens einen Zielpool und möglicherweise über einen sekundären Sicherungspool.

   gcloud compute target-pools list
   

2. Ermitteln Sie eine Legacy-Systemdiagnose mithilfe des HTTP-Protokolls. Bei Bedarf rufen Sie die Legacy-Systemdiagnosen auf.

3. 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 und LEGACY_HEALTH_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_HEALTH_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_HEALTH_CHECK_NAME
     

API

1. Sie können Zielpools mit dem API-Aufruf targetPools.list auflisten.

2. Rufen Sie die Legacy-Systemdiagnosen auf und ermitteln Sie eine Legacy-HTTP-Systemdiagnose.

3. Wenn Sie eine Legacy-HTTP-Systemdiagnose mit einem Zielpool verknüpfen möchten, verwenden Sie den API-Aufruf targetPools.addHealthCheck.

Gezieltes Fehlschlagen der Systemdiagnose durch Blockieren von IP-Adressbereichen

Unter bestimmten Umständen ist es sinnvoll, Systemdiagnosen gezielt fehlschlagen zu lassen. So kann es z. B. sein, dass Sie für eine bestimmte VM das Fehlschlagen der Systemdiagnose als Teil einer Fehlerbehebungsaktivität herbeiführen möchten. Eine andere Möglichkeit ist das Fehlschlagen der Systemdiagnose für eine VM beim Herunterfahren.

Sie können für diese Fälle das Fehlschlagen einer Systemdiagnose bzw. Legacy-Systemdiagnose erzwingen. Dazu blockieren Sie vorübergehend den Zugriff auf die Systemdiagnose-IP-Bereiche. In diesem Beispiel wird gezeigt, wie man Systemdiagnosen mithilfe der iptables-Firewallsoftware, die auf einer Linux-VM ausgeführt wird, fehlschlagen lässt.

Wichtig: Das Blockieren von Prüfungen neuer und Legacy-Systemdiagnosen blockiert möglicherweise auch andere neu eingehende Verbindungen. Dies ist der Fall, wenn Ihre Systemdiagnose denselben Port wie Ihr Dienst verwendet und die Verbindungen aus denselben Systemdiagnose-IP-Bereichen stammen.

Damit die Prüfungen neuer und Legacy-Systemdiagnosen einer VM fehlschlagen, stellen Sie eine Verbindung zu ihr her und führen einen iptables-Befehl wie im folgenden Beispiel aus. Dabei ersetzen Sie HEALTH_CHECK_PORT durch die entsprechende TCP-Portnummer. Wenn die Prüfung einer VM gezielt beim Herunterfahren fehlschlagen soll, können Sie iptables-Befehle wie die folgenden einem Shutdown-Skript hinzufügen, gefolgt von einer geeigneten Verzögerung, die auf dem Überprüfungsintervall und dem Fehlerschwellenwert der Systemdiagnose basiert.

$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 35.191.0.0/16 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 130.211.0.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 209.85.152.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -I INPUT 1 -m state --state NEW \
-s 209.85.204.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset

Mit den folgenden Befehlen können Sie die iptables-Regeln wieder entfernen. Ersetzen Sie dabei HEALTH_CHECK_PORT durch den TCP-Port der Systemdiagnose.

$ sudo iptables -D INPUT -m state --state NEW \
-s 35.191.0.0/16 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -D INPUT -m state --state NEW \
-s 130.211.0.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -D INPUT -m state --state NEW \
-s 209.85.152.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset
$ sudo iptables -D INPUT -m state --state NEW \
-s 209.85.204.0/22 -p tcp --destination-port HEALTH_CHECK_PORT \
-j REJECT --reject-with tcp-reset