Anwendungsbasierte Systemdiagnose und automatische Reparatur einrichten

---

In diesem Dokument wird gezeigt, wie Sie eine anwendungsbasierte Systemdiagnose für die automatische Reparatur von VMs in einer verwalteten Instanzgruppe (MIG) einrichten. Außerdem wird erläutert, wie eine Systemdiagnose ohne automatische Reparatur verwendet, eine Systemdiagnose entfernt, die Richtlinie für die automatische Reparatur aufgerufen und der Systemstatus jeder VM geprüft werden kann.

Sie können eine anwendungsbasierte Systemdiagnose konfigurieren, um zu prüfen, ob Ihre Anwendung auf einer VM wie erwartet reagiert. Wenn mit der von Ihnen konfigurierten Systemdiagnose festgestellt wird, dass Ihre Anwendung auf einer VM nicht reagiert, markiert die MIG diese VM als fehlerhaft und repariert sie. Die Reparatur einer VM, die auf einer anwendungsbasierten Systemdiagnose beruht, wird als automatische Reparatur bezeichnet.

Sie können Reparaturen in einer MIG auch deaktivieren und dann eine Systemdiagnose verwenden, ohne die automatische Reparatur auszulösen.

Weitere Informationen zu Reparaturen in einer MIG finden Sie unter VMs für Hochverfügbarkeit reparieren.

Hinweise

• Richten Sie die Authentifizierung ein, falls Sie dies noch nicht getan haben. Bei der Authentifizierung wird Ihre Identität für den Zugriff auf Google Cloud-Dienste und APIs überprüft. Zur Ausführung von Code oder Beispielen aus einer lokalen Entwicklungsumgebung können Sie sich so bei Compute Engine authentifizieren.
  

  Select the tab for how you plan to use the samples on this page:

  Console

  When you use the Google Cloud console to access Google Cloud services and APIs, you don't need to set up authentication.

  gcloud

  1. Install the Google Cloud CLI, then initialize it by running the following command:

     gcloud init

     Note: If you installed the gcloud CLI previously, make sure you have the latest version by running gcloud components update.
  2. Set a default region and zone.

  Terraform

  Wenn Sie die Terraform-Beispiele auf dieser Seite in einer lokalen Entwicklungsumgebung verwenden möchten, installieren und initialisieren Sie die gcloud CLI und richten dann die Standardanmeldedaten für Anwendungen mit Ihren Nutzeranmeldedaten ein.

  1. Install the Google Cloud CLI.

  2. To initialize the gcloud CLI, run the following command:

     gcloud init

  3. If you're using a local shell, then create local authentication credentials for your user account:

     gcloud auth application-default login

     You don't need to do this if you're using Cloud Shell.

  Weitere Informationen unter Set up authentication for a local development environment.

  REST

  Verwenden Sie die von der gcloud CLI bereitgestellten Anmeldedaten, um die REST API-Beispiele auf dieser Seite in einer lokalen Entwicklungsumgebung zu verwenden.

  Install the Google Cloud CLI, then initialize it by running the following command:

  gcloud init

  Weitere Informationen finden Sie unter Für die Verwendung von REST authentifizieren in der Dokumentation zur Google Cloud-Authentifizierung.

Preise

Wenn Sie eine anwendungsbasierte Systemdiagnose einrichten, schreibt Compute Engine standardmäßig immer dann einen Logeintrag in Cloud Logging, wenn sich der Systemzustand einer VM ändert. In Cloud Logging steht ein kostenloses Kontingent pro Monat zur Verfügung. Ist es aufgebraucht, wird das Logging nach Datenvolumen abgerechnet. Sie können Kosten vermeiden, indem Sie die Änderungslogs des Systemzustands deaktivieren.

Anwendungsbasierte Systemdiagnose und automatische Reparatur einrichten

So richten Sie eine anwendungsbasierte Systemdiagnose und die automatische Reparatur in einer MIG ein:

1. Erstellen Sie eine Systemdiagnose, falls noch nicht geschehen.
2. Konfigurieren Sie eine Richtlinie für die automatische Reparatur in der MIG, um die Systemdiagnose anzuwenden.

Tipp: Verwenden Sie für das Load-Balancing und die automatische Reparatur getrennte Systemdiagnosen. Bei Systemdiagnosen für Load-Balancing werden nicht mehr reagierende Instanzen erkannt und Traffic von diesen umgeleitet. Bei Systemdiagnosen für die automatische Reparatur werden fehlerhafte VMs erkannt und diese VMs proaktiv neu erstellt. Daher sollte diese Systemdiagnose konservativer vorgehen als eine Load-Balancing-Systemdiagnose. Weitere Informationen finden Sie unter Grundlagen einer guten Systemdiagnose für die automatische Reparatur.

Systemdiagnose erstellen

Eine Systemdiagnose kann auf maximal 50 MIGs angewendet werden. Wenn Sie mehr als 50 Gruppen haben, erstellen Sie mehrere Systemdiagnosen.

Das folgende Beispiel zeigt, wie eine Systemdiagnose für die automatische Reparatur erstellt wird. Sie können entweder eine regionale oder eine globale Systemdiagnose für die automatische Reparatur in MIGs erstellen. In diesem Beispiel erstellen Sie eine globale Systemdiagnose, die nach einer Antwort des Webservers auf Port 80 sucht. Damit die Systemdiagnoseprüfungen den Webserver erreichen können, müssen Sie eine Firewallregel einrichten.

Erforderliche Berechtigungen für diese Aufgabe

Zum Ausführen dieser Aufgabe benötigen Sie die folgenden Berechtigungen:

• compute.healthChecks.create für das Projekt, wenn Sie eine Systemdiagnose erstellen.
• compute.healthChecks.use für die zu verwendende Systemdiagnose
• compute.firewalls.create für das Projekt, wenn Sie eine Firewall erstellen
• compute.networks.updatePolicy für das Netzwerk, wenn Sie eine Firewall erstellen

Die Berechtigungen sind in folgenden vorkonfigurierten Rollen verfügbar.

• compute.networkAdmin zum Erstellen von Systemdiagnosen
• compute.securityAdmin zum Konfigurieren von Firewallregeln, damit die Systemdiagnose eine Verbindung herstellen kann

Console

1. Erstellen Sie eine Systemdiagnose für die automatische Reparatur, die konservativer ist als eine Load-Balancing-Systemdiagnose.

   Beispielsweise können Sie eine Systemdiagnose erstellen, die Port 80 auf eine Antwort prüft und VMs erst mit einer gewissen Fehlertoleranz als fehlerhaft (UNHEALTHY) markiert und deren Neuerstellung auslöst. In diesem Beispiel wird eine VM als fehlerfrei markiert, wenn die Systemdiagnose einmal erfolgreich für sie ausgeführt wird. Die VM wird als fehlerhaft markiert, wenn die Systemdiagnose 3-mal hintereinander erfolglos war.

   1. Rufen Sie in der Google Cloud Console die Seite Systemdiagnose erstellen auf.

      Zur Seite "Systemdiagnose erstellen"

   2. Geben Sie einen Namen für die Systemdiagnose ein, z. B. example-check.

   3. Wählen Sie einen Bereich aus. Sie können entweder Regional oder Global auswählen. Wählen Sie für dieses Beispiel Global aus.

   4. Prüfen Sie, ob unter Protokoll die Option HTTP ausgewählt ist.

   5. Geben Sie für Port den Wert 80 ein.

   6. Geben Sie im Abschnitt Diagnosekriterien die folgenden Werte an:

      1. Geben Sie für Überprüfungsintervall den Wert 5 ein.
      2. Geben Sie für Zeitlimit den Wert 5 ein.
      3. Legen Sie einen Schwellenwert für Intaktheit fest, um anzugeben, wie viele aufeinanderfolgende Systemdiagnosen erfolgreich sein müssen, bevor eine fehlerhafte VM als fehlerfrei markiert wird. Geben Sie in diesem Beispiel 1 ein.
      4. Legen Sie einen Fehlerschwellenwert fest, um anzugeben, wie viele aufeinanderfolgende Systemdiagnosen fehlschlagen müssen, bevor eine fehlerfreie VM als fehlerhaft markiert wird. Geben Sie in diesem Beispiel 3 ein.

   7. Klicken Sie auf Erstellen, um die Systemdiagnose zu erstellen.

2. Richten Sie die Firewallregel so ein, dass die Systemdiagnosetests eine Verbindung zu Ihrer Anwendung herstellen können.

   Achtung: Wenn die Systemdiagnoseprüfungen durch Firewallregeln blockiert sind, werden Ihre VMs als UNHEALTHY markiert, weil sie keine Verbindung zur Anwendung herstellen können. Das kann dazu führen, dass VMs neu erstellt werden, die eigentlich intakt sind.

   Die Systemdiagnosetests stammen von Adressen in den Bereichen 130.211.0.0/22 und 35.191.0.0/16. Stellen Sie deshalb sicher, dass Ihre Netzwerk-Firewallregeln die Verbindung zulassen. In diesem Beispiel nutzt die MIG das Netzwerk default. Deren VMs überwachen Port 80. Wenn Port 80 im Netzwerk "default" noch nicht offen ist, erstellen Sie eine entsprechende Firewallregel.

   1. Rufen Sie in der Google Cloud Console die Seite der Firewall-Richtlinien auf.

      Zu den Firewall-Richtlinien

   2. Klicken Sie auf Firewallregel erstellen.

   3. Geben Sie einen Namen für die Firewallregel ein. Beispiel: allow-health-check

   4. Wählen Sie unter Netzwerk das Netzwerk default aus.

   5. Wählen Sie für Ziele die Option All instances in the network aus.

   6. Wählen Sie für Quellfilter die Option IPv4 ranges aus.

   7. Geben Sie unter Quell-IPv4-Bereiche die Werte 130.211.0.0/22 und 35.191.0.0/16 ein.

   8. Wählen Sie unter Protokolle und Ports die Option Angegebene Protokolle und Ports aus und gehen Sie so vor:

      1. Wählen Sie TCP aus.
      2. Geben Sie in das Feld Ports den Wert 80 ein.

   9. Klicken Sie auf Erstellen.

gcloud

1. Erstellen Sie eine Systemdiagnose für die automatische Reparatur, die konservativer ist als eine Load-Balancing-Systemdiagnose.

   Erstellen Sie beispielsweise eine Systemdiagnose, die eine Antwort von Port 80 erwartet und eine gewisse Fehlertoleranz hat, bevor sie VMs als fehlerhaft (UNHEALTHY) markiert und dafür sorgt, dass sie neu erstellt werden. In diesem Beispiel wird eine VM als fehlerfrei markiert, wenn die Systemdiagnose einmal erfolgreich für sie ausgeführt wird. Die VM wird als fehlerhaft markiert, wenn die Systemdiagnose 3-mal hintereinander erfolglos war. Mit dem folgenden Befehl wird eine globale Systemdiagnose erstellt.

   gcloud compute health-checks create http example-check --port 80 \
      --check-interval 30s \
      --healthy-threshold 1 \
      --timeout 10s \
      --unhealthy-threshold 3 \
      --global
   

   Hinweis: Verwenden Sie neuere Systemdiagnosen, die die HTTP, HTTPS, TCP, and SSL (TLS) Protokolle unterstützen. Legacy-Systemdiagnosen von Compute Engine für HTTP/HTTPS funktionieren weiterhin.

2. Richten Sie die Firewallregel so ein, dass die Systemdiagnosetests eine Verbindung zu Ihrer Anwendung herstellen können.

   Achtung: Wenn die Systemdiagnoseprüfungen durch Firewallregeln blockiert sind, werden Ihre VMs als UNHEALTHY markiert, weil sie keine Verbindung zur Anwendung herstellen können. Das kann dazu führen, dass VMs neu erstellt werden, die eigentlich intakt sind.

   Die Systemdiagnosetests stammen von Adressen in den Bereichen 130.211.0.0/22 und 35.191.0.0/16. Sorgen Sie dafür, dass Ihre Firewallregeln die Verbindung zulassen. In diesem Beispiel verwendet die MIG das Netzwerk default. Deren VMs überwachen Port 80. Wenn Port 80 im Netzwerk "default" noch nicht offen ist, erstellen Sie eine entsprechende Firewallregel.

   gcloud compute firewall-rules create allow-health-check \
       --allow tcp:80 \
       --source-ranges 130.211.0.0/22,35.191.0.0/16 \
       --network default
   

Terraform

1. Erstellen Sie mit der Ressource google_compute_http_health_check eine Systemdiagnose.

   Beispielsweise können Sie eine Systemdiagnose erstellen, die Port 80 auf eine Antwort prüft und VMs erst mit einer gewissen Fehlertoleranz als fehlerhaft (UNHEALTHY) markiert und deren Neuerstellung auslöst. In diesem Beispiel wird eine VM als fehlerfrei markiert, wenn die Systemdiagnose einmal erfolgreich für sie ausgeführt wird. Die VM wird als fehlerhaft markiert, wenn die Systemdiagnose 3-mal hintereinander erfolglos war. Die folgende Anfrage erstellt eine globale Systemdiagnose.

   resource "google_compute_http_health_check" "default" {
     name                = "example-check"
     timeout_sec         = 10
     check_interval_sec  = 30
     healthy_threshold   = 1
     unhealthy_threshold = 3
     port                = 80
   }

2. Erstellen Sie eine Firewall mit der google_compute_firewall-Ressource.

   Achtung: Wenn die Systemdiagnoseprüfungen durch Firewallregeln blockiert sind, werden Ihre VMs als UNHEALTHY markiert, weil sie keine Verbindung zur Anwendung herstellen können. Das kann dazu führen, dass VMs neu erstellt werden, die eigentlich intakt sind.

   Die Systemdiagnosetests stammen von Adressen in den Bereichen 130.211.0.0/22 und 35.191.0.0/16. Sorgen Sie dafür, dass Ihre Firewallregeln die Verbindung zulassen. In diesem Beispiel nutzt die MIG das Netzwerk default. Deren VMs überwachen Port 80. Wenn Port 80 im Netzwerk "default" noch nicht offen ist, erstellen Sie eine entsprechende Firewallregel.

   resource "google_compute_firewall" "default" {
     name          = "allow-health-check"
     network       = "default"
     source_ranges = ["130.211.0.0/22", "35.191.0.0/16"]
     allow {
       protocol = "tcp"
       ports    = [80]
     }
   }

Informationen zum Anwenden oder Entfernen einer Terraform-Konfiguration finden Sie unter Grundlegende Terraform-Befehle.

REST

1. Erstellen Sie eine Systemdiagnose für die automatische Reparatur, die konservativer ist als eine Load-Balancing-Systemdiagnose.

   Beispielsweise können Sie eine Systemdiagnose erstellen, die Port 80 auf eine Antwort prüft und VMs erst mit einer gewissen Fehlertoleranz als fehlerhaft (UNHEALTHY) markiert und deren Neuerstellung auslöst. In diesem Beispiel wird eine VM als fehlerfrei markiert, wenn die Systemdiagnose einmal erfolgreich für sie ausgeführt wird. Die VM wird als fehlerhaft markiert, wenn die Systemdiagnose 3-mal hintereinander erfolglos war. Die folgende Anfrage erstellt eine globale Systemdiagnose.

   POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks
   
   {
    "name": "example-check",
    "type": "http",
    "port": 80,
    "checkIntervalSec": 30,
    "healthyThreshold": 1,
    "timeoutSec": 10,
    "unhealthyThreshold": 3
   }
   

   Hinweis: Verwenden Sie neuere Systemdiagnosen, die die HTTP, HTTPS, TCP, and SSL (TLS) Protokolle unterstützen. Legacy-Systemdiagnosen von Compute Engine für HTTP/HTTPS funktionieren weiterhin.

2. Richten Sie die Firewallregel so ein, dass die Systemdiagnosetests eine Verbindung zu Ihrer Anwendung herstellen können.

   Achtung: Wenn die Systemdiagnoseprüfungen durch Firewallregeln blockiert sind, werden Ihre VMs als UNHEALTHY markiert, weil sie keine Verbindung zur Anwendung herstellen können. Das kann dazu führen, dass VMs neu erstellt werden, die eigentlich intakt sind.

   Die Systemdiagnosetests stammen von Adressen in den Bereichen 130.211.0.0/22 und 35.191.0.0/16. Sorgen Sie dafür, dass Ihre Firewallregeln die Verbindung zulassen. In diesem Beispiel nutzt die MIG das Netzwerk default. Deren VMs überwachen Port 80. Wenn Port 80 im Netzwerk "default" noch nicht offen ist, erstellen Sie eine entsprechende Firewallregel.

   POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls
   
   {
    "name": "allow-health-check",
    "network": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/default",
    "sourceRanges": [
     "130.211.0.0/22",
     "35.191.0.0/16"
    ],
    "allowed": [
     {
      "ports": [
       "80"
      ],
      "IPProtocol": "tcp"
     }
    ]
   }
   

   Ersetzen Sie dabei PROJECT_ID durch Ihre Projekt-ID.

Richtlinie für die automatische Reparatur in einer MIG konfigurieren

In einer MIG können Sie nur eine Richtlinie für die automatische Reparatur einrichten, um eine Systemdiagnose anzuwenden.

Sie können entweder eine regionale oder eine globale Systemdiagnose für die automatische Reparatur in MIGs verwenden. Regionale Systemdiagnosen reduzieren regionenübergreifende Abhängigkeiten und helfen dabei, den Datenstandort zu erreichen. Globale Systemdiagnosen sind praktisch, wenn Sie dieselbe Systemdiagnose für MIGs in mehreren Regionen verwenden möchten.

Bevor Sie eine Richtlinie für die automatische Reparatur konfigurieren, führen Sie folgende Schritte aus:

• Wenn Sie noch keine Systemdiagnose haben, erstellen Sie eine Systemdiagnose.
• Wenn Sie verhindern möchten, dass die automatische Reparatur fälschlicherweise ausgelöst wird, während Sie eine neue Systemdiagnose einrichten, müssen Sie zuerst die Reparaturen in der MIG deaktivieren und dann die Richtlinie für die automatische Reparatur konfigurieren.

Erforderliche Berechtigungen für diese Aufgabe

Zum Ausführen dieser Aufgabe benötigen Sie die folgenden Berechtigungen:

• compute.instanceGroupManagers.update in der MIG

Die Berechtigungen sind in folgenden vorkonfigurierten Rollen verfügbar.

• compute.instanceAdmin.v1 zum Erstellen und Aktualisieren von Richtlinien zur automatischen Reparatur in MIGs

Console

1. Rufen Sie in der Google Cloud Console die Seite Instanzgruppen auf.

   Zu den Instanzgruppen

2. Klicken Sie in der Spalte Name der Liste auf den Namen der MIG, für die Sie die Systemdiagnose anwenden möchten.

3. Klicken Sie auf Bearbeiten, um diese MIG zu ändern.

4. Wählen Sie im Abschnitt Lebenszyklus von VM-Instanzen unter Automatische Reparatur eine globale oder regionale Systemdiagnose aus.

5. Ändern Sie die Einstellung für die Anfängliche Verzögerung oder behalten Sie sie bei.

   Die anfängliche Verzögerung ist die Anzahl von Sekunden, die eine neue VM zum Initialisieren und Ausführen des Startskripts benötigt. Während des anfänglichen Verzögerungszeitraums einer VM ignoriert die MIG fehlgeschlagene Systemdiagnosen, da sich die VM möglicherweise im Startvorgang befindet. Dadurch wird verhindert, dass die MIG eine VM vorzeitig neu erstellt. Wenn die Systemdiagnose während der anfänglichen Verzögerung eine fehlerfreie Antwort empfängt, gibt dies an, dass der Startvorgang abgeschlossen ist und die VM bereit ist. Der Timer für die anfängliche Verzögerung startet, wenn sich das Feld currentAction der VM in VERIFYING ändert. Der Wert der anfänglichen Verzögerung muss zwischen 0 und 3.600 Sekunden liegen. In der Console beträgt der Standardwert 300 Sekunden.

6. Klicken Sie auf Speichern, um die Änderungen zu übernehmen.

gcloud

Hinweis: Der Befehl set-autohealing wurde verworfen und wird demnächst entfernt. Verwenden Sie stattdessen den Befehl update für eine vorhandene MIG und den Befehl create für eine neue MIG.

Verwenden Sie zum Konfigurieren der Richtlinie für die automatische Reparatur in einer vorhandenen MIG den Befehl update.

Verwenden Sie beispielsweise den folgenden Befehl, um die Richtlinie für die automatische Reparatur in einer vorhandenen zonalen MIG zu konfigurieren:

gcloud compute instance-groups managed update MIG_NAME \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

Zum Konfigurieren der automatischen Reparaturrichtlinie beim Erstellen einer MIG verwenden Sie den Befehl create.

Verwenden Sie beispielsweise den folgenden Befehl, um beim Erstellen einer zonalen MIG die Richtlinie für die automatische Reparatur zu konfigurieren:

gcloud compute instance-groups managed create MIG_NAME \
    --size SIZE \
    --template INSTANCE_TEMPLATE_URL \
    --health-check HEALTH_CHECK_URL \
    --initial-delay INITIAL_DELAY \
    --zone ZONE

Ersetzen Sie Folgendes:

• MIG_NAME: Name der MIG, in der Sie die automatische Reparatur einrichten möchten.
• SIZE: Anzahl der VMs in der Gruppe.
• INSTANCE_TEMPLATE_URL: Die teilweise URL der Instanzvorlage, die Sie zum Erstellen der VMs in der Gruppe verwenden möchten. Beispiel:
  • Regionale Instanzvorlage: projects/example-project/regions/us-central1/instanceTemplates/example-template.
  • Globale Instanzvorlage: projects/example-project/global/instanceTemplates/example-template.
• HEALTH_CHECK_URL: Die teilweise URL der Systemdiagnose, die Sie für die automatische Reparatur einrichten möchten. Wenn Sie eine regionale Systemdiagnose verwenden möchten, müssen Sie die teilweise URL der regionalen Systemdiagnose angeben. Beispiel:
  • Regionale Systemdiagnose: projects/example-project/regions/us-central1/healthChecks/example-health-check.
  • Globale Systemdiagnose: projects/example-project/global/healthChecks/example-health-check.
• INITIAL_DELAY: Die Anzahl der Sekunden, die eine neue VM zum Initialisieren und Ausführen des Startskripts benötigt. Während des anfänglichen Verzögerungszeitraums einer VM ignoriert die MIG fehlgeschlagene Systemdiagnosen, da sich die VM möglicherweise im Startvorgang befindet. Dadurch wird verhindert, dass die MIG eine VM vorzeitig neu erstellt. Wenn die Systemdiagnose während der anfänglichen Verzögerung eine fehlerfreie Antwort empfängt, gibt dies an, dass der Startvorgang abgeschlossen ist und die VM bereit ist. Der Timer für die anfängliche Verzögerung startet, wenn sich das Feld currentAction der VM in VERIFYING ändert. Der Wert der anfänglichen Verzögerung muss zwischen 0 und 3600 Sekunden liegen. Der Standardwert ist 0.
• ZONE: Die Zone, in der sich die MIG befindet. Verwenden Sie bei einer regionalen MIG das Flag --region.

Terraform

Verwenden Sie den Block auto_healing_policies, um eine Richtlinie für die automatische Reparatur in einer MIG zu konfigurieren.

Im folgenden Beispiel wird die Richtlinie für die automatische Reparatur in einer zonalen MIG konfiguriert. Weitere Informationen zu der im Beispiel verwendeten Ressource finden Sie unter google_compute_instance_group_manager. Verwenden Sie für eine regionale MIG die google_compute_region_instance_group_manager-Ressource.

resource "google_compute_instance_group_manager" "default" {
  name               = "igm-with-hc"
  base_instance_name = "test"
  target_size        = 3
  zone               = "us-central1-f"
  version {
    instance_template = google_compute_instance_template.default.id
    name              = "primary"
  }
  auto_healing_policies {
    health_check      = google_compute_http_health_check.default.id
    initial_delay_sec = 30
  }
}

Informationen zum Anwenden oder Entfernen einer Terraform-Konfiguration finden Sie unter Grundlegende Terraform-Befehle.

REST

Hinweis: Die Methoden instanceGroupManagers.setAutohealingPolicies und regionInstanceGroupManager.setAutohealingPolicies sind nicht Teil der allgemein verfügbaren API und werden eingestellt. Verwenden Sie stattdessen die Methode patch oder insert.

So konfigurieren Sie die Richtlinie für die automatische Reparatur in einer vorhandenen MIG mit der Methode patch:

• Verwenden Sie für eine zonale MIG die Methode instanceGroupManager.patch.
• Verwenden Sie für eine regionale MIG die Methode regionInstanceGroupManager.patch.

Mit dem folgenden Aufruf können Sie beispielsweise die automatische Reparatur in einer vorhandenen zonalen MIG einrichten:

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

{
  "autoHealingPolicies": [
  {
    "healthCheck": "HEALTH_CHECK_URL",
    "initialDelaySec": INITIAL_DELAY
  }
  ]
}

So konfigurieren Sie die Richtlinie für die automatische Reparatur beim Erstellen einer MIG mit der Methode insert:

• Verwenden Sie für eine zonale MIG die Methode instanceGroupManager.insert.
• Verwenden Sie für eine regionale MIG die Methode regionInstanceGroupManager.insert.

Mit dem folgenden Aufruf können Sie beispielsweise beim Erstellen einer zonalen MIG die Richtlinie für die automatische Reparatur konfigurieren:

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers

{
  "name": "MIG_NAME",
  "targetSize": SIZE,
  "instanceTemplate": "INSTANCE_TEMPLATE_URL"
  "autoHealingPolicies": [
    {
      "healthCheck": "HEALTH_CHECK_URL",
      "initialDelaySec": INITIAL_DELAY
    }
  ],
}

Ersetzen Sie Folgendes:

• PROJECT_ID: Ihre Projekt-ID.
• MIG_NAME: Name der MIG, in der Sie die automatische Reparatur einrichten möchten.
• SIZE: Anzahl der VMs in der Gruppe.
• INSTANCE_TEMPLATE_URL: Die teilweise URL der Instanzvorlage, die Sie zum Erstellen der VMs in der Gruppe verwenden möchten. Beispiel:
  • Regionale Instanzvorlage: projects/example-project/regions/us-central1/instanceTemplates/example-template.
  • Globale Instanzvorlage: projects/example-project/global/instanceTemplates/example-template.
• HEALTH_CHECK_URL: Die teilweise URL der Systemdiagnose, die Sie für die automatische Reparatur einrichten möchten. Beispiel:
  • Regionale Systemdiagnose: projects/example-project/regions/us-central1/healthChecks/example-health-check.
  • Globale Systemdiagnose: projects/example-project/global/healthChecks/example-health-check.
• INITIAL_DELAY: Die Anzahl der Sekunden, die eine neue VM zum Initialisieren und Ausführen des Startskripts benötigt. Während des anfänglichen Verzögerungszeitraums einer VM ignoriert die MIG fehlgeschlagene Systemdiagnosen, da sich die VM möglicherweise im Startvorgang befindet. Dadurch wird verhindert, dass die MIG eine VM vorzeitig neu erstellt. Wenn die Systemdiagnose während der anfänglichen Verzögerung eine fehlerfreie Antwort empfängt, gibt dies an, dass der Startvorgang abgeschlossen ist und die VM bereit ist. Der Timer für die anfängliche Verzögerung startet, wenn sich das Feld currentAction der VM in VERIFYING ändert. Der Wert der anfänglichen Verzögerung muss zwischen 0 und 3600 Sekunden liegen. Der Standardwert ist 0.
• ZONE: Die Zone, in der sich die MIG befindet. Verwenden Sie bei einer regionalen MIG regions/REGION in der URL.

Nach Abschluss der Einrichtung der automatischen Reparatur kann es 10 Minuten dauern, bis die automatische Reparatur mit dem Monitoring der VMs in der Gruppe beginnt. Nach Beginn des Monitorings startet Compute Engine, VMs basierend auf Ihrer Konfiguration der automatischen Reparatur als fehlerfrei zu kennzeichnen oder neu zu erstellen. Wenn Sie beispielsweise eine anfängliche Verzögerung von 5 Minuten, ein Systemdiagnoseintervall von 1 Minute und einen intakten Schwellenwert von 1 Prüfung konfigurieren, sieht die Zeitachse so aus:

• 10 Minuten Verzögerung, bevor die automatische Reparatur mit dem Monitoring von VMs in der Gruppe beginnt
• +5 Minuten für die konfigurierte anfängliche Verzögerung
• + 1 Minute für das Überprüfungsintervall * Schwellenwert für Intaktheit (60 s * 1)
• = 16 Minuten, bevor die VM als fehlerfrei markiert oder neu erstellt wird

Wenn Sie die Reparaturen in der MIG deaktiviert haben, bevor Sie die Richtlinie für die automatische Reparatur konfigurieren, können Sie den VM-Systemstatus überwachen, um zu prüfen, ob die Systemdiagnose wie erwartet funktioniert, und dann die MIG auf die Reparatur von VMs zurücksetzen.

Systemdiagnose ohne automatische Reparatur verwenden

Sie können die in einer MIG konfigurierte Systemdiagnose ohne automatische Reparatur verwenden, indem Sie Reparaturen in der MIG deaktivieren. Dies ist in Szenarien hilfreich, in denen Sie die Systemdiagnose nur zur Überwachung des Anwendungsstatus verwenden oder eine eigene Reparaturlogik auf Basis der Systemdiagnose implementieren möchten.

Achtung: Seien Sie vorsichtig, wenn Sie die Reparaturen in einer MIG deaktivieren, da sie damit auch die automatische Reparatur fehlgeschlagener VMs in der MIG ausschalten.

Informationen zum Festlegen der MIG auf die Reparatur fehlerhafter VMs finden Sie unter MIG zum Reparieren ausgefallener und fehlerhafter VMs einrichtenn.

Systemdiagnose entfernen

So entfernen Sie eine in einer Richtlinie für die automatische Reparatur konfigurierte Systemdiagnose:

Console

1. Rufen Sie in der Google Cloud Console die Seite Instanzgruppen auf.

   Zu den Instanzgruppen

   1. Klicken Sie auf den Namen der MIG, aus der Sie die Systemdiagnose entfernen möchten.
   2. Klicken Sie auf Bearbeiten, um diese MIG zu ändern.
   3. Wählen Sie im Abschnitt Lebenszyklus von VM-Instanzen unter Automatische Reparatur die Option Keine Systemdiagnose aus.
   4. Klicken Sie auf Speichern, um die Änderungen zu übernehmen.

gcloud

Wenn Sie die Konfiguration der Systemdiagnose in einer Richtlinie für die automatische Reparatur entfernen möchten, verwenden Sie mit dem Befehl update das Flag --clear-autohealing:

gcloud compute instance-groups managed update MIG_NAME \
    --clear-autohealing

Ersetzen Sie dabei MIG_NAME durch den Namen einer MIG.

REST

Wenn Sie die Konfiguration der Systemdiagnose in einer Richtlinie für die automatische Reparatur entfernen möchten, geben Sie für die Richtlinie zur automatischen Reparatur einen leeren Wert an.

• Verwenden Sie für eine zonale MIG die Methode instanceGroupManagers.patch.
• Verwenden Sie für eine eine regionale MIG die Methode regionInstanceGroupManagers.patch.

Wenn Sie beispielsweise die Systemdiagnose in einer zonalen MIG entfernen möchten, stellen Sie folgende Anfrage:

PATCH https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

{
  "autoHealingPolicies": [
    {}
  ]
}

Ersetzen Sie Folgendes:

• PROJECT_ID: Ihre Projekt-ID.
• MIG_NAME: Name der MIG, in der Sie die automatische Reparatur einrichten möchten.
• ZONE: Die Zone, in der sich die MIG befindet. Verwenden Sie für eine regionale MIG regions/REGION.

Richtlinie für die automatische Reparatur in einer MIG aufrufen

So können Sie die Richtlinie für die automatische Reparatur einer MIG aufrufen:

Console

1. Rufen Sie in der Google Cloud Console die Seite Instanzgruppen auf.

   Zu den Instanzgruppen

2. Klicken Sie auf den Namen der MIG, für die Sie die Richtlinie zur automatischen Reparatur aufrufen möchten.

3. Wechseln Sie zum Tab Details.

4. Im Abschnitt Lebenszyklus von VM-Instanzen werden im Feld Automatische Reparatur die Systemdiagnose und die anfängliche Verzögerung angezeigt, die in der Richtlinie für die automatische Reparatur konfiguriert sind.

gcloud

Verwenden Sie den folgenden Befehl, um die Richtlinie für die automatische Reparatur in einer MIG aufzurufen:

gcloud compute instance-groups managed describe MIG_NAME \
    --format="(autoHealingPolicies)"

Ersetzen Sie dabei MIG_NAME durch den Namen einer MIG.

Hier ein Beispiel für eine Ausgabe:

autoHealingPolicies:
  healthCheck: https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check
  initialDelaySec: 300

REST

Verwenden Sie die REST-Methoden wie im Folgenden dargestellt, um die Richtlinie für die automatische Reparatur in einer MIG aufzurufen:

• Verwenden Sie für eine zonale MIG die Methode instanceGroupManagers.get.
• Verwenden Sie für eine regionale MIG die Methode regionInstanceGroupManagers.get.

Mit der folgenden Anfrage können Sie beispielsweise die Richtlinie zur automatischen Reparatur in einer zonalen MIG aufrufen:

GET https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroupManagers/MIG_NAME

Suchen Sie im Antworttext nach dem Objekt autoHealingPolicies[].

Hier ist eine Beispielantwort:

{
  ...
  "autoHealingPolicies": [
    {
      "healthCheck": "https://www.googleapis.com/compute/v1/projects/example-project/global/healthChecks/example-health-check",
      "initialDelaySec": 300
    }
  ],
  ...
}

Ersetzen Sie Folgendes:

• PROJECT_ID: Ihre Projekt-ID.
• MIG_NAME: Name der MIG, in der Sie die automatische Reparatur einrichten möchten.
• ZONE: Die Zone, in der sich die MIG befindet. Verwenden Sie für eine regionale MIG regions/REGION.

Prüfen Sie den Status

Nachdem Sie eine anwendungsbasierte Systemdiagnose in einer MIG eingerichtet haben, können Sie mit den folgenden Aktionen prüfen, ob eine VM ausgeführt wird und ihre Anwendung reagiert:

• VMs auf fehlerfreien Status prüfen
• Aktuelle Aktionen für VMs prüfen
• MIG auf Stabilität prüfen

VMs auf fehlerfreien Status prüfen

Wenn Sie eine anwendungsbasierte Systemdiagnose für Ihre MIG konfiguriert haben, können Sie den Systemzustand jeder einzelnen verwalteten Instanz prüfen.

Bei dieser Prüfung werden die folgenden Fehler erkannt:

• Fehlerhafte VMs, die nicht repariert wurden. In den folgenden Situationen kann es vorkommen, dass als fehlerhaft erkannte VMs nicht sofort repariert werden:
  • Die VM befindet sich noch im Boot-Vorgang und der Zeitraum der anfänglichen Verzögerung ist noch nicht verstrichen.
  • Ein großer Anteil an fehlerhaften Instanzen wird repariert. Die MIG Reparatur verzögert weitere automatische Reparaturen, um sicherzustellen, dass eine Teilmenge der Instanzen weiterhin in der Gruppe ausgeführt wird.
• Konfigurationsfehler der Systemdiagnose. Wenn die Instanz den Integritätszustand TIMEOUT meldet, ist dies beispielsweise ein Hinweis auf falsch konfigurierte Firewallregeln oder ungültige Endpunkte für die Systemdiagnose von Anwendungen.
• Der zu konfigurierende anfängliche Verzögerungswert. Dafür wird die Zeit gemessen, die die VM für den Übergang zum Status RUNNING und für den Übergang zum Integritätszustand HEALTHY benötigt. Zum Messen dieser Lücke können Sie die Methode list-instances abfragen oder die Zeit zwischen dem instances.insert-Vorgang und dem ersten empfangenen fehlerfreies Signal überwachen.

Verwenden Sie die Console, das gcloud-Befehlszeilentool oder REST, um den Systemzustand aufzurufen.

Erforderliche Berechtigungen für diese Aufgabe

Zum Ausführen dieser Aufgabe benötigen Sie die folgenden Berechtigungen:

• compute.instanceGroupManagers.get in der MIG

Console

1. Rufen Sie in der Google Cloud Console die Seite Instanzgruppen auf.

   Zu den Instanzgruppen.

2. Klicken Sie in der Spalte Name der Liste auf den Namen der MIG, die Sie prüfen möchten. Es wird eine Seite mit den Attributen der Instanzgruppe und einer Liste der in der Gruppe enthaltenen VMs geöffnet.

3. Wenn eine VM fehlerhaft ist, können Sie den Systemstatus in der Spalte Systemdiagnosestatus feststellen.

gcloud

Verwenden Sie den Unterbefehl list-instances.

gcloud compute instance-groups managed list-instances instance-group
NAME              ZONE                  STATUS   HEALTH_STATE  ACTION  INSTANCE_TEMPLATE                            VERSION_NAME  LAST_ERROR
igm-with-hc-fvz6  europe-west1          RUNNING  HEALTHY       NONE    my-template
igm-with-hc-gtz3  europe-west1          RUNNING  HEALTHY       NONE    my-template

In der Spalte HEALTH_STATE wird der Status der einzelnen VMs angezeigt.

REST

Erstellen Sie für eine regionale MIG eine POST-Anfrage an die Methode listManagedInstances:

POST https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group/listManagedInstances

Verwenden Sie für eine zonale MIG die zonale MIG-Methode listManagedInstances:

POST https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group/listManagedInstances

Die Anfrage gibt eine Antwort ähnlich der folgenden zurück. Sie enthält ein instanceHealth-Feld für die einzelnen verwalteten Instanzen.

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/example-group-5485",
   "instanceStatus": "RUNNING",
   "currentAction": "NONE",
   "lastAttempt": {
   },
   "id": "6159431761228150698",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/example-template",
   "version": {
    "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/project-id/global/instanceTemplates/example-template"
   },
   "instanceHealth": [
    {
     "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/http-basic-check",
     "detailedHealthState": "HEALTHY"
    }
   ]
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/project-id/zones/zone/instances/example-group-sfdp",
   "instanceStatus": "STOPPING",
   "currentAction": "DELETING",
   "lastAttempt": {
   },
   "id": "6622324799312181783",
   "instanceHealth": [
    {
     "healthCheck": "https://www.googleapis.com/compute/v1/projects/project-id/global/healthChecks/http-basic-check",
     "detailedHealthState": "TIMEOUT"
    }
   ]
  }
 ]
}

Systemstatus

Für VMs sind die folgenden Systemstatus möglich:

• HEALTHY: Die VM ist erreichbar, zum Endpunkt der Systemdiagnose der Anwendung kann eine Verbindung hergestellt werden und die Antwort entspricht den in der Systemdiagnose definierten Anforderungen.
• DRAINING: Die VM wird per Drain beendet. Vorhandene Verbindungen zur VM können noch beendet werden, neue Verbindungen werden aber abgelehnt.
• UNHEALTHY: Die VM ist erreichbar, entspricht aber nicht den in der Systemdiagnose definierten Anforderungen.
• TIMEOUT: Die VW ist nicht erreichbar, zum Endpunkt der Systemdiagnose der Anwendung kann keine Verbindung hergestellt werden oder der Server einer VM antwortet nicht innerhalb des angegebenen Zeitlimits. Das kann beispielsweise auf eine falsche Konfiguration von Firewallregeln oder eine überlastete Serveranwendung einer VM zurückzuführen sein.
• UNKNOWN: Die VM wird von der Systemdiagnose nicht erkannt oder ihr Status ist im Moment nicht bekannt. Es kann 10 Minuten dauern, bis das Monitoring von neuen VMs in einer MIG beginnt.

Neue VMs geben UNHEALTHY zurück, bis sie von der Systemdiagnose geprüft wurden.

Ob eine VM repariert wird, hängt von ihrem Systemstatus ab:

• VMs im Status UNHEALTHY oder TIMEOUT, deren Initialisierungsphase abgelaufen ist, werden von der MIG, wenn möglich, sofort repariert.
• Wenn eine VM den Systemstatus UNKNOWN hat, wird sie von der MIG nicht sofort repariert. Damit soll eine unnötige Reparatur von VMs vermieden werden, für die vorübergehend kein Systemdiagnosesignal verfügbar ist.

Die automatische Reparatur kann sich in folgenden Fällen verzögern:

• Eine VM bleibt nach mehreren aufeinanderfolgenden Reparaturen fehlerhaft.
• In der Gruppe ist ein großer Anteil der VMs fehlerhaft.

Wir möchten mehr über Ihre Anwendungsfälle und Probleme erfahren. Wir freuen uns auch über Feedback zu den verschiedenen Systemstatus von VMs. Senden Sie Ihr Feedback an unser Team unter [e-mail].

Aktuelle Aktionen für VMs prüfen

Wenn eine MIG eine VM-Instanz erstellt, setzt die MIG das schreibgeschützte Feld currentAction dieser Instanz auf CREATING. Wenn die Gruppe mit einer Richtlinie zur automatischen Reparatur verknüpft ist, setzt die MIG die aktuelle Aktion der Instanz auf VERIFYING, nachdem die VM erstellt wurde und ausgeführt wird. Die Systemdiagnose beginnt dann mit der Prüfung der Anwendung der VM. Besteht die Anwendung diese erste Systemdiagnose innerhalb ihrer Startdauer, wird die VM bestätigt und die MIG ändert das Feld currentAction der VM in NONE.

Informationen zum Prüfen der aktuellen Aktionen auf VMs finden Sie unter Aktuelle Aktionen für VMs aufrufen.

MIG auf Stabilität prüfen

Compute Engine füllt auf Gruppenebene das schreibgeschütztes Feld status aus, das ein isStable-Flag enthält.

Wenn alle VMs in der Gruppe ausgeführt werden und fehlerfrei sind, d. h. im Feld currentAction für jede verwaltete Instanz auf NONE gesetzt ist, dann setzt die MIG das Feld status.isStable auf true fest. Beachten Sie, dass die Stabilität einer MIG von Gruppenkonfigurationen abhängt, die nicht mit der Richtlinie für die automatische Reparatur zusammenhängen. Wenn Ihre Gruppe beispielsweise automatisch skaliert und herunter- oder hochskaliert wird, wird das Feld status.isStable aufgrund des Autoscaling-Vorgangs auf false gesetzt.

Informationen zum Prüfen der Werte des Felds status.isStable Ihrer MIG finden Sie unter MIG auf Stabilität prüfen.

Frühere automatische Reparaturvorgänge ansehen

Mit der gcloud CLI oder REST können Sie frühere automatische Reparaturereignisse aufrufen.

gcloud

Verwenden Sie den Befehl gcloud compute operations list mit einem Filter, um nur die automatischen Reparaturereignisse in Ihrem Projekt aufzurufen.

gcloud compute operations list --filter='operationType~compute.instances.repair.*'

Weitere Informationen zu einem bestimmten Reparaturvorgang erhalten Sie mit dem Befehl describe. Beispiel:

gcloud compute operations describe repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5 --zone us-east1-b

REST

Senden Sie für regionale MIGs eine GET-Anfrage an die Ressource regionOperations und geben Sie dabei einen Filter an, durch den die Ausgabeliste auf Ereignisse des Vorgangstyps compute.instances.repair.* beschränkt wird.

GET https://compute.googleapis.com/compute/v1/projects/project-id/region/region/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

Verwenden Sie für zonale MIGs die Ressource zoneOperations.

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

Für weitere Informationen zu einem bestimmten Reparaturvorgang senden Sie eine GET-Anfrage für diesen Vorgang. Beispiel:

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/operations/repair-1539070348818-577c6bd6cf650-9752b3f3-1d6945e5

Grundlagen einer guten Systemdiagnose für die automatische Reparatur

Die für die automatische Reparatur verwendeten Systemdiagnosen sollten konservativ sein, damit Instanzen nicht vorzeitig gelöscht und neu erstellt werden. Wenn eine Systemdiagnose für die automatische Reparatur zu aggressiv ist, kann die automatische Reparatur ausgelastete Instanzen fälschlicherweise als fehlerhaft interpretieren und unnötigerweise neu starten, wodurch die Verfügbarkeit reduziert wird.

• unhealthy-threshold: Sollte größer als 1 sein. Setzen Sie diesen Wert idealerweise auf 3 oder höher. Dies schützt vor seltenen Fehlern wie einem Netzwerkpaketverlust.
• healthy-threshold: Ein Wert von 2 ist für die meisten Anwendungen ausreichend.
• timeout: Legen Sie hierfür einen großzügigen Wert fest. Der Zeitwert sollte fünfmal so hoch sein wie die erwartete Antwortzeit oder noch höher. Das sorgt für Schutz bei unerwarteten Verzögerungen wie ausgelasteten Instanzen oder langsamen Netzwerkverbindungen.
• check-interval: Dieser Wert sollte zwischen 1 Sekunde und dem Zweifachen des Zeitlimits liegen (nicht zu lang oder zu kurz). Bei einem zu langen Intervall wird eine Instanz mit Fehlern nicht rechtzeitig erkannt. Ein zu kurzes Intervall kann zu einer merklichen Auslastung der Instanzen und des Netzwerks führen, da jede Sekunde eine hohe Anzahl von Systemdiagnoseprüfungen gesendet wird.

Weitere Informationen

• Die Anleitung Automatische Reparatur für hochverfügbare Anwendungen verwenden durcharbeiten
• Änderungen des VM-Systemzustands beobachten.
• Konfigurationsupdates während der Reparatur anwenden.