Systemdiagnosen und automatische Reparatur für Instanzen in verwalteten Instanzgruppen einrichten

Sie können für verwaltete Instanzgruppen eine Richtlinie für die automatische Reparatur konfigurieren, um die Verfügbarkeit Ihrer Anwendung zu verbessern. Außerdem können Sie so überprüfen, ob die Anwendung wie erwartet antwortet.

Dazu baut die Richtlinie für die automatische Reparatur auf eine anwendungsbasierte Systemdiagnose. Die Überprüfung, ob eine Anwendung antwortet, ist genauer als jene, ob eine Instanz den Status RUNNING hat.

Wenn bei der automatischen Reparatur festgestellt wird, dass eine Anwendung nicht antwortet, wird diese Instanz von der verwalteten Instanzgruppe automatisch neu erstellt. Bei einer Instanz auf Abruf erstellt die Gruppe die Instanz neu, wenn die erforderlichen Ressourcen wieder verfügbar werden.

Verhalten bei der automatischen Reparatur

Bei der automatischen Reparatur werden fehlerhafte Instanzen mithilfe der Instanzvorlage wiederhergestellt, die ursprünglich zum Erstellen der VM-Instanz verwendet wurde. Hierbei handelt es sich nicht zwingend um die aktuelle Instanzvorlage, die der verwalteten Instanzgruppe zugeordnet ist. Wenn beispielsweise eine VM-Instanz mithilfe von instance-template-a erstellt wurde und Sie dann die verwaltete Instanzgruppe für die Verwendung von instance-template-b im Modus OPPORTUNISTIC aktualisieren, verwendet die automatische Reparatur weiterhin instance-template-a, um die Instanz neu zu erstellen. Dies liegt daran, dass Neuerstellungen durch eine automatische Reparatur nicht vom Nutzer eingeleitet werden. Daher kann Compute Engine nicht einfach davon ausgehen, dass für die VM-Instanz die neue Vorlage verwendet werden soll. Wenn Sie eine neue Vorlage anwenden möchten, finden Sie weitere Informationen unter Instanzvorlage für eine verwaltete Instanzgruppe ändern.

Die Anzahl der gleichzeitig automatisch reparierten Instanzen ist jederzeit kleiner als die Größe der verwalteten Instanzgruppe. So wird sichergestellt, dass die Gruppe auch dann einige Instanzen ausführt, wenn beispielsweise die Richtlinie für die automatische Reparatur nicht zur Arbeitslast passt, die Firewallregeln falsch konfiguriert wurden oder Probleme mit der Netzwerkverbindung oder -infrastruktur vorliegen, was dazu führt, dass fehlerfreie Instanzen als fehlerhaft identifiziert werden. Wenn jedoch eine zonal verwaltete Instanzgruppe nur eine Instanz oder eine regional verwaltete Instanzgruppe nur eine Instanz pro Zone hat, erstellt die automatische Reparatur diese Instanzen neu, sobald sie fehlerhaft werden.

Während der Initialisierungsphase wird eine Instanz von der automatischen Reparatur nicht neu erstellt. Weitere Informationen finden Sie unter dem Attribut autoHealingPolicies[].initialDelaySec. Diese Einstellung verzögert die Prüfung durch die automatische Reparatur, sodass die Instanz nicht vorzeitig neu erstellt wird, falls sie gerade gestartet wird. Der Timer für die anfängliche Verzögerung startet, wenn die Instanz als currentAction den Wert VERIFYING hat.

Automatische Reparatur und Laufwerke

Beim Wiederherstellen einer Instanz basierend auf ihrer Vorlage behandelt die automatische Reparatur verschiedene Arten von Datenträgern unterschiedlich. Einige Laufwerkkonfigurationen können dazu führen, dass die automatische Reparatur fehlschlägt, sobald Sie versuchen, eine verwaltete Instanz neu zu erstellen.

Laufwerkstyp autodelete Verhalten während der automatischen Reparatur
Neuer nichtflüchtiger Speicher true Das Laufwerk wird gemäß der Vorlage der Instanz neu erstellt. Alle Daten, die auf dieses Laufwerk geschrieben wurden, gehen verloren, wenn das Laufwerk und seine Instanz neu erstellt werden.
Neuer nichtflüchtiger Speicher false Laufwerk bleibt erhalten und wird wieder angefügt, sobald die automatische Reparatur die Instanz neu erstellt.
Vorhandener nichtflüchtiger Speicher true Altes Laufwerk wird gelöscht. Die VM-Instanzwiederherstellung schlägt fehl, da Compute Engine ein gelöschtes Laufwerk der Instanz nicht erneut hinzufügen kann.
Vorhandener nichtflüchtiger Speicher false Das alte Laufwerk wird gemäß der Vorlage der Instanz erneut hinzugefügt. Die Daten auf dem Laufwerk bleiben erhalten. Bei vorhandenen Laufwerken mit Lese- und Schreibberechtigung kann eine verwaltete Instanzgruppe jedoch maximal eine VM enthalten, da ein einzelner nichtflüchtiger Speicher im Schreib-/Lesemodus nicht mehreren Instanzen zugeordnet werden kann.
Neue lokale SSD – Das Laufwerk wird gemäß der Vorlage der Instanz neu erstellt. Die auf einer lokalen SSD abgelegten Daten gehen verloren, wenn eine Instanz neu erstellt oder gelöscht wird.

Die automatische Reparatur ordnet Laufwerke, die nicht in der Instanzvorlage angegeben sind, z. B. Laufwerke, die Sie nach dem Erstellen der VM manuell einer VM zugeordnet haben, nicht neu zu.

Treffen Sie folgende Vorkehrungen, um wichtige Daten, die auf das Laufwerk geschrieben wurden, zu erhalten:

  • Erstellen Sie regelmäßig Snapshots des nichtflüchtigen Speichers.

  • Exportieren Sie Daten in eine andere Quelle, zum Beispiel Cloud Storage.

Wenn Ihre Instanzen wichtige Einstellungen enthalten, die Sie beibehalten möchten, empfiehlt Google außerdem, dass Sie in Ihrer Instanzvorlage ein benutzerdefiniertes Image verwenden. Ein benutzerdefiniertes Image enthält alle benutzerdefinierten Einstellungen, die Sie benötigen. Wenn Sie ein benutzerdefiniertes Image in Ihrer Instanzvorlage festlegen, erstellt die verwaltete Instanzgruppe mithilfe des benutzerdefinierten Images, das die erforderlichen benutzerdefinierten Einstellungen enthält, Instanzen neu.

Eine Systemdiagnose und eine Richtlinie für die automatische Reparatur einrichten

Sie können je verwalteter Instanzgruppe maximal eine Richtlinie für die automatische Reparatur einrichten.

Eine Systemdiagnose kann auf maximal 50 verwaltete Instanzgruppe angewendet werden. Falls Sie mehr als 50 Gruppen haben, erstellen Sie mehrere Systemdiagnosen.

Beispiel zum Einrichten einer Systemdiagnose

Das folgende Beispiel zeigt, wie eine Systemdiagnose für eine verwaltete Instanzgruppe verwendet wird. In diesem Beispiel erstellen Sie eine Systemdiagnose, die nach einer Antwort des Webservers auf Port 80 sucht. Damit die Systemdiagnoseprüfungen die einzelnen Webserver erreichen, müssen Sie eine Firewallregel einrichten. Schließlich wenden Sie die Systemdiagnose auf die verwaltete Instanzgruppe an, indem Sie die Richtlinie für die automatische Reparatur erstellen.

Console

  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 Instanzen als fehlerhaft (UNHEALTHY) markiert und dafür sorgt, dass sie neu erstellt werden. In diesem Beispiel wird eine Instanz als intakt markiert, wenn die Systemdiagnose einmal erfolgreich für sie ausgeführt wird. Sie wird als fehlerhaft markiert, wenn die Systemdiagnose 3-mal hintereinander erfolglos war.

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

      Zur Seite "Systemdiagnosen erstellen"

    2. Geben Sie einen Namen für die Systemdiagnose ein, z. B. example-check.
    3. Stellen Sie unter Protokoll sicher, dass HTTP ausgewählt ist.
    4. Geben Sie für Port den Wert 80 ein.
    5. Geben Sie für Überprüfungsintervall den Wert 5 ein.
    6. Geben Sie für Zeitlimit den Wert 5 ein.
    7. Legen Sie einen Schwellenwert für Intaktheit fest, um zu bestimmen, wie viele aufeinanderfolgende Systemdiagnosen erfolgreich sein müssen, bevor eine fehlerhafte Instanz als intakt markiert wird. Geben Sie in diesem Beispiel 1 ein.
    8. Legen Sie einen Fehlerschwellenwert fest, um zu bestimmen, wie viele aufeinanderfolgende Systemdiagnosen fehlschlagen müssen, bevor eine intakte Instanz als fehlerhaft markiert wird. Geben Sie in diesem Beispiel 3 ein.
    9. Klicken Sie auf Erstellen, um die Systemdiagnose zu erstellen.

  2. Erstellen Sie eine Firewallregel, damit für die Systemdiagnoseprüfungen eine Verbindung zu Ihrer Anwendung hergestellt werden kann.

    Die Systemdiagnoseprüfungen 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 verwaltete Instanzgruppe das Netzwerk default und ihre Instanzen überwachen Port 80. Falls Port 80 im Netzwerk "default" noch nicht offen ist, erstellen Sie eine entsprechende Firewallregel.

    1. Gehen Sie in der GCP Console zur Seite Firewallregel erstellen.

      Zur Seite "Firewallregel erstellen"

    2. Geben Sie unter Name einen Namen für die Firewallregel ein, z. B. allow-health-check.
    3. Wählen Sie für Netzwerk die Option default aus.
    4. Wählen Sie für Quellfilter die Option IP ranges aus.
    5. Geben Sie für Quell-IP-Bereiche 130.211.0.0/22 und 35.191.0.0/16 ein.
    6. Wählen Sie unter Protokolle und Ports die Option Angegebene Protokolle und Ports aus und geben Sie tcp:80 ein.
    7. Klicken Sie auf Erstellen.

  3. Wenden Sie die Systemdiagnose auf die regional oder zonal verwaltete Instanzgruppe an. Konfigurieren Sie dazu eine Richtlinie zur automatischen Reparatur.

    1. Öffnen Sie in der GPC Console die Seite Instanzgruppen.

      Zur Seite "Instanzgruppen"

    2. Klicken Sie in der Spalte Name der Liste auf den Namen der Instanzgruppe, auf die Sie die Systemdiagnose anwenden möchten.
    3. Klicken Sie auf Gruppe bearbeiten, um die verwaltete Instanzgruppe zu bearbeiten.
    4. Wählen Sie unter Automatische Reparatur die Systemdiagnose aus, die Sie zuvor erstellt haben.
    5. Ändern Sie die Einstellung für die Anfängliche Verzögerung oder behalten Sie sie bei. Mit dieser Einstellung wird die potenzielle vorzeitige Neuerstellung der Instanz durch die automatische Reparatur verzögert, wenn die Instanz gerade gestartet wird. Der Timer für die anfängliche Verzögerung wird gestartet, wenn die currentAction der Instanz den Status VERIFYING hat.
    6. Klicken Sie auf Speichern, um die Änderungen zu übernehmen.

    Es kann 15 Minuten dauern, bis das Monitoring von Instanzen in der Gruppe durch die automatische Reparatur beginnt.

gcloud

Installieren Sie das gcloud-Befehlszeilentool oder verwenden Sie Cloud Shell, um die Befehlszeilenbeispiele aus dieser Anleitung nachzustellen.

  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 Instanzen als fehlerhaft (UNHEALTHY) markiert und dafür sorgt, dass sie neu erstellt werden. In diesem Beispiel wird eine Instanz als intakt markiert, wenn die Systemdiagnose einmal erfolgreich für sie ausgeführt wird. Sie wird als fehlerhaft markiert, wenn die Systemdiagnose 3-mal hintereinander erfolglos war.

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

  2. Erstellen Sie eine Firewallregel, damit für die Systemdiagnoseprüfungen eine Verbindung zu Ihrer Anwendung hergestellt werden kann.

    Die Systemdiagnoseprüfungen stammen von Adressen in den Bereichen 130.211.0.0/22 und 35.191.0.0/16. Sorgen Sie deshalb dafür, dass Ihre Firewallregeln die Verbindung zulassen. In diesem Beispiel nutzt die verwaltete Instanzgruppe das Netzwerk default und ihre Instanzen überwachen Port 80. Falls 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

  3. Wenden Sie die Systemdiagnose auf die regional oder zonal verwaltete Instanzgruppe an. Konfigurieren Sie dazu eine Richtlinie zur automatischen Reparatur.

    Verwenden Sie den Befehl update, um die Systemdiagnose auf die verwaltete Instanzgruppe anzuwenden.

    Mit der Einstellung initial-delay wird die potenzielle vorzeitige Neuerstellung der Instanz durch die automatische Reparatur verzögert, wenn die Instanz gerade gestartet wird. Der Timer für die anfängliche Verzögerung startet, wenn sich die currentAction der Instanz im Status VERIFYING befindet.

    Beispiel:

    gcloud compute instance-groups managed update my-mig \
    --health-check example-check \
    --initial-delay 300 \
    --zone us-east1-b

    Es kann 15 Minuten dauern, bis das Monitoring von Instanzen in der Gruppe durch die automatische Reparatur beginnt.

API

Richten Sie einen API-Zugang ein, um die API-Beispiele aus dieser Anleitung zu nutzen.

  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 Instanzen als fehlerhaft (UNHEALTHY) markiert und dafür sorgt, dass sie neu erstellt werden. In diesem Beispiel wird eine Instanz als intakt markiert, wenn die Systemdiagnose einmal erfolgreich für sie ausgeführt wird. Sie wird als fehlerhaft markiert, wenn die Systemdiagnose 3-mal hintereinander erfolglos war.

    POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/healthChecks

{
 "name": "example-check",
 "type": "http",
 "port": 80,
 "checkIntervalSec": 30,
 "healthyThreshold": 1,
 "timeoutSec": 10,
 "unhealthyThreshold": 3
}

  2. Erstellen Sie eine Firewallregel, damit für die Systemdiagnoseprüfungen eine Verbindung zu Ihrer Anwendung hergestellt werden kann.

    Die Systemdiagnoseprüfungen stammen von Adressen in den Bereichen 130.211.0.0/22 und 35.191.0.0/16. Sorgen Sie deshalb dafür, dass Ihre Firewallregeln die Verbindung zulassen. In diesem Beispiel nutzt die verwaltete Instanzgruppe das Netzwerk default und ihre Instanzen überwachen Port 80. Falls Port 80 im Netzwerk "default" noch nicht offen ist, erstellen Sie eine entsprechende Firewallregel.

    POST https://www.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"
  }
 ]
}

  3. Wenden Sie die Systemdiagnose auf die regional oder zonal verwaltete Instanzgruppe an. Konfigurieren Sie dazu eine Richtlinie zur automatischen Reparatur.

    Eine Richtlinie zur automatischen Reparatur ist Teil der Ressource instanceGroupManager oder regionInstanceGroupManager.

    Mit den Methoden insert oder patch können Sie die Richtlinie zur automatischen Reparatur festlegen.

    Im folgenden Beispiel wird eine Richtlinie zur automatischen Reparatur mit der Methode instanceGroupManagers.patch eingerichtet.

    PATCH https://www.googleapis.com/compute/projects/[PROJECT_ID]/zones/[ZONE]/instanceGroupManagers/[INSTANCE_GROUP]
{
  "autoHealingPolicies": [
    {
      "healthCheck": "global/healthChecks/example-check",
      "initialDelaySec": 300
    }
  ],
}

    Mit der Einstellung initialDelaySec wird die potenzielle vorzeitige Neuerstellung der Instanz durch die automatische Reparatur verzögert, wenn die Instanz gerade gestartet wird. Der Timer für die anfängliche Verzögerung startet, wenn sich die currentAction der Instanz im Status VERIFYING befindet.

    Es kann 15 Minuten dauern, bis das Monitoring von Instanzen in der Gruppe durch die automatische Reparatur beginnt.

    Wenn Sie die anwendungsbasierte automatische Reparatur deaktivieren möchten, geben Sie als Richtlinie zur automatischen Reparatur einen leeren Wert an: autoHealingPolicies[]. Mit autoHealingPolicies[] erstellt die verwaltete Instanzgruppe nur die Instanzen neu, die nicht den Status RUNNING haben.

    Sie können die Richtlinie zur automatischen Reparatur einer verwalteten Instanzgruppe aus dem Feld instanceGroupManagers.autoHealingPolicies ablesen. Zum Abrufen der Ressource einer verwalteten Instanzgruppe verwenden Sie eine der folgenden Methoden:

Status überprüfen

Sie können überprüfen, ob eine Instanz erstellt wurde und ihre Anwendung reagiert, indem Sie die aktuelle Aktion für jede Instanz oder den Gruppenstatus überprüfen.

Bei der erstmaligen Verknüpfung einer Systemdiagnose mit einer verwalteten Instanzgruppe kann es 15 Minuten dauern, bis das Monitoring beginnt.

Aktuelle Aktionen auf Instanzen

Während eine verwaltete Instanz erstellt wird, hat die currentAction den Status CREATING. Wenn die Gruppe mit einer automatischen Reparatur verknüpft ist, wechselt der Status der currentAction zu VERIFYING, sobald die verwaltete Instanz erstellt ist und ausgeführt wird. Die Systemdiagnose beginnt dann mit der Prüfung der Anwendung der Instanz. Besteht die Anwendung diese erste Systemdiagnose innerhalb ihrer Startdauer, wird die Instanz bestätigt und die currentAction wechselt in den Status NONE.

Wenn Sie die currentAction aufrufen möchten, die gerade ausgeführt wird, sowie den status jeder Instanz in einer verwalteten Instanzgruppe, können Sie dafür das gcloud-Befehlszeilentool oder die API verwenden.

gcloud 

gcloud compute instance-groups managed list-instances [INSTANCE_GROUP_NAME] [--filter="zone:([ZONE])" | --filter="region:([REGION])"]

gcloud gibt als Antwort eine Liste der Instanzen in der Instanzgruppe sowie ihren jeweiligen Status und ihre jeweilige aktuelle Aktion zurück. Beispiel:

NAME               ZONE           STATUS   ACTION    INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f           CREATING  my-new-template
vm-instances-h2r1  us-central1-f           DELETING  my-old-template
vm-instances-j1h8  us-central1-f  RUNNING  NONE      my-old-template
vm-instances-ngod  us-central1-f  RUNNING  NONE      my-old-template

API

Führen Sie in der API eine POST-Anfrage für die Methode regionInstanceGroupManagers.listManagedInstances aus. Verwenden Sie für eine zonal verwaltete Instanzgruppe die zonale Methode instanceGroupManagers.listManagedInstances.

POST https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/regions/[REGION]/instanceGroupManagers/[INSTANCE_GROUP_NAME]/listManagedInstances

Die API gibt eine Liste der Instanzen in der Gruppe zurück, einschließlich des instanceStatus und der currentAction jeder Instanz.

{
 "managedInstances": [
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-prvp",
   "id": "5317605642920955957",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-pz5j",
   "currentAction": "DELETING"
  },
  {
   "instance": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/instances/vm-instances-w2t5",
   "id": "2800161036826218547",
   "instanceStatus": "RUNNING",
   "instanceTemplate": "https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/global/instanceTemplates/[INSTANCE_TEMPLATE_NAME]",
   "currentAction": "REFRESHING"
  }
 ]
}

Der Status jeder Instanz in einer verwalteten Instanzgruppe wird durch das zugehörige instanceStatus-Feld beschrieben. Eine Liste der gültigen Werte für das Feld instanceStatus finden Sie unter Status einer Instanz prüfen.

Wenn an der Instanz eine Änderung vorgenommen wird, enthält das Feld currentAction eine der folgenden Aktionen als Wert, damit Sie den Fortschritt der Änderung verfolgen können. Andernfalls enthält das Feld currentAction den Wert NONE.

Mögliche Werte für currentAction sind:

  • ABANDONING: Die Instanz wird gerade aus der verwalteten Instanzgruppe entfernt.
  • CREATING: Die Instanz wird gerade erstellt.
  • CREATING_WITHOUT_RETRIES. Die Instanz wird ohne Neuversuche erstellt. Wenn die Instanz beim ersten Versuch nicht erstellt wird, versucht die verwaltete Instanzgruppe nicht noch einmal, die Instanz zu ersetzen.
  • DELETING: Die Instanz wird gerade gelöscht.
  • RECREATING: Die Instanz wurde gelöscht und wird gerade ersetzt.
  • REFRESHING: Die Instanz wird gerade aus den aktuellen Zielpools entfernt und anschließend zu den in der Liste enthaltenen Zielpools wieder hinzugefügt. Diese Liste kann mit den bestehenden Zielpools identisch sein oder davon abweichen.
  • RESTARTING: Die Instanz wird gerade mit den Methoden stop und start neu gestartet.
  • VERIFYING: Die Instanz wurde erstellt und wird gerade verifiziert.
  • NONE: Für die Instanz werden gerade keine Aktionen durchgeführt.

Sobald eine Instanz erfolgreich aktualisiert wurde, wird im Feld instanceStatus der aktuelle Status der Instanz angezeigt.

Gruppenstatus

Auf Gruppenebene fügt Compute Engine Werte in das Feld status ein, das das Flag isStable enthält. Sie können mit dem gcloud-Tool oder der API auf dieses Flag zugreifen.

Wenn alle Instanzen in der Gruppe ausgeführt werden und fehlerfrei sind, d. h. die currentAction jeder verwalteten Instanz ist NONE, dann gilt status.isStable==true. Beachten Sie, dass die Stabilität einer verwalteten Instanzgruppe von Gruppenkonfigurationen abhängt, die nicht mit der Richtlinie für die automatische Reparatur zusammenhängen. Wenn Ihre Gruppe beispielsweise generell automatisch skaliert und gerade hochskaliert wird, dann gilt aufgrund des Autoscaling-Vorgangs isStable==false.

Sie können überprüfen, ob eine verwaltete Instanzgruppe ausgeführt wird und fehlerfrei ist. Dazu prüfen Sie den Wert des Feldes status.isStable der zugeordneten Ressource instanceGroupManagers oder regionInstanceGroupManagers.

Wenn status.isStable auf false gesetzt ist, bedeutet das, dass Änderungen aktiv sind, ausstehen oder dass die verwaltete Instanzgruppe gerade geändert wird.

Wenn status.isStable auf true gesetzt ist, bedeutet das Folgendes:

  • Gerade wird keine der Instanzen in der verwalteten Instanzgruppe geändert und die currentAction hat für alle Instanzen den Wert NONE.
  • Für die Instanzen in der verwalteten Instanzgruppe stehen keine Änderungen aus.
  • Die verwaltete Instanzgruppe selbst wird gerade nicht geändert.

Verwaltete Instanzgruppen können auf verschiedene Arten geändert werden. Beispiel:

  • Sie stellen eine Anfrage, um eine neue Instanzvorlage bereitzustellen.
  • Sie stellen eine Anfrage, um in der Gruppe Instanzen zu erstellen, zu löschen, deren Größe anzupassen oder sie zu aktualisieren.
  • Durch das Autoscaling wird eine Anfrage gestellt, um die Größe der Gruppe zu ändern.
  • Eine Ressource für die automatische Reparatur ersetzt in der verwalteten Instanzgruppe eine oder mehrere fehlerhafte Instanzen.
  • In einer regional verwalteten Instanzgruppe werden einige der Instanzen neu verteilt.

Sobald alle Aktionen abgeschlossen wurden, wird für die verwaltete Instanzgruppe status.isStable wieder auf true gesetzt.

Sie können auch den Befehl gcloud beta compute instance-groups managed wait-until mit dem Flag --stable verwenden, damit gewartet wird, bis status.isStable für die Gruppe auf true gesetzt ist:

gcloud beta compute instance-groups managed wait-until INSTANCE_GROUP_NAME \
    --stable \
    [--zone [ZONE] | --region [REGION]]

Frühere automatische Reparaturvorgänge ansehen

Mit dem gcloud-Tool oder der API können Sie frühere automatische Reparaturereignisse aufrufen.

gcloud

Mit dem Befehl gcloud compute operations list und einem Filter können Sie eine Liste der automatischen Reparaturereignisse in Ihrem Projekt aufrufen.

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

Verwenden Sie den Befehl describe, um weitere Informationen zu einem bestimmten Reparaturvorgang zu erhalten. Beispiel:

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

API

Richten Sie für regional verwaltete Instanzgruppe die Anfrage GET an regionOperations und verwenden Sie einen Filter, um die Ergebnisliste auf Ereignisse des Typs compute.instances.repair.* zu begrenzen.

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/region/[REGION]/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

Verwenden Sie für zonal verwaltete Instanzgruppen die Ressource zoneOoperations.

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/[ZONE]/operations?filter=operationType+%3D+%22compute.instances.repair.*%22

Senden Sie für weitere Informationen zu einem bestimmten Reparaturvorgang eine GET-Anfrage für den jeweiligen Vorgang. Beispiel:

GET https://www.googleapis.com/compute/v1/projects/[PROJECT_ID]/zones/us-east1-b/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 mehr. 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 größer. 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 der Zeitüberschreitung 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

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...

dieser Seite
Feedback zur Dokumentation
Compute Engine-Dokumentation
Feedback zum Produkt