Systemdiagnosen und automatische Reparatur einrichten

Mithilfe von verwalteten Instanzgruppen (Managed instance groups, MIGs) können Sie für Ihre Anwendungen Hochverfügbarkeit gewährleisten. Die Instanzgruppen sorgen proaktiv dafür, dass die VM-Instanzen verfügbar bleiben, also den Status RUNNING behalten. Wenn eine verwaltete Instanz nicht mehr ausgeführt wird, die Statusänderung aber nicht von der MIG initiiert wurde, werden die Instanzen von der MIG automatisch neu erstellt. Wenn dagegen der Status RUNNING der Instanz explizit durch die MIG aufgehoben wurde, z. B. wenn durch ein Autoscaling eine Instanz gelöscht wurde, wird die Instanz nicht neu erstellt.

Zu den Änderungen des Instanzstatus, die nicht von der MIG initiiert werden, gehören:

Nicht immer reicht es jedoch aus, die Integrität von Anwendungen am Status der Instanzen festzumachen. Beispielsweise werden bei der Prüfung auf den Instanzstatus RUNNING keine Anwendungsfehler wie "Einfrieren", "Überlastung" oder "Absturz" ermittelt.

Sie können für Ihre MIG eine Richtlinie zur automatischen Reparatur konfigurieren, um die Verfügbarkeit Ihrer Anwendung zu verbessern und um zu prüfen, ob die Anwendung wie erwartet antwortet.

Im Rahmen dieser Richtlinie wird eine anwendungsbasierte Systemdiagnose ausgeführt. Die Prüfung, ob eine Anwendung antwortet, liefert genauere Ergebnisse als die einfache Prüfung, ob eine VM den Status RUNNING hat.

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

Verhalten bei der automatischen Reparatur

Bei der automatischen Reparatur werden fehlerhafte VMs mithilfe der Instanzvorlage neu erstellt, die ursprünglich zum Erstellen der VM verwendet wurde. Das muss nicht zwingend die aktuelle Instanzvorlage in der MIG sein. Wenn beispielsweise eine VM mit instance-template-a erstellt wurde und Sie die MIG so aktualisieren, dass instance-template-b im OPPORTUNISTIC-Modus verwendet wird, nutzt die automatische Reparatur weiterhin instance-template-a, um die VM neu zu erstellen. Dies liegt daran, dass die Neuerstellung durch eine automatische Reparatur nicht vom Nutzer eingeleitet wird. Daher geht Compute Engine nicht davon aus, dass für die VM die neue Vorlage verwendet werden soll. Informationen zum Anwenden einer neuen Vorlage finden Sie unter Instanzvorlage für eine verwaltete Instanzgruppe ändern.

Die Anzahl der gleichzeitig automatisch reparierten VMs ist immer kleiner als die Größe der MIG. Damit ist gewährleistet, dass die Gruppe auch dann eine Teilmenge von VMs ausführt, wenn beispielsweise die Richtlinie für die automatische Reparatur nicht der Arbeitslast entspricht, die Firewallregeln falsch konfiguriert wurden oder Probleme mit der Netzwerkverbindung bzw. -infrastruktur vorliegen und so fehlerfreie VM als fehlerhaft eingestuft werden. Wenn eine zonale MIG aber nur eine VM oder eine regionale MIG nur eine VM pro Zone hat, erstellt die automatische Reparatur diese VMs neu, sobald sie fehlerhaft werden.

Während der Initialisierungsphase wird eine VM von der automatischen Reparatur nicht neu erstellt. Weitere Informationen finden Sie auf der Seite zum Attribut autoHealingPolicies[].initialDelaySec. Diese Einstellung verzögert die Prüfung durch die automatische Reparatur, sodass die VM nicht vorzeitig neu erstellt wird, wenn sie gerade gestartet wird. Der Timer für die anfängliche Verzögerung startet, wenn sich currentAction im Status VERIFYING befindet.

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

Automatische Reparatur und Laufwerke

Bei der Neuerstellung einer VW anhand ihrer Vorlage werden von der automatischen Reparatur unterschiedliche Arten von Laufwerken unterschiedlich behandelt. Einige Laufwerkkonfigurationen können dazu führen, dass die automatische Reparatur fehlschlägt, sobald Sie versuchen, eine VM 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 VM neu erstellt werden.
Neuer nichtflüchtiger Speicher false Laufwerk bleibt erhalten und wird wieder angefügt, wenn die automatische Reparatur die VM neu erstellt.
Vorhandener nichtflüchtiger Speicher true Altes Laufwerk wird gelöscht. Die Neuerstellung der VM schlägt fehl, da Compute Engine der VW kein gelöschtes Laufwerk neu 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 MIG jedoch maximal eine VM enthalten, da ein einzelner nichtflüchtiger Speicher im Schreib-/Lesemodus nicht mehreren VMs 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 VM neu erstellt oder gelöscht wird.

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

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

Wenn Ihre VMs wichtige Einstellungen enthalten, die Sie beibehalten möchten, empfiehlt Google außerdem, in Ihrer Instanzvorlage ein benutzerdefiniertes Image zu verwenden. Ein benutzerdefiniertes Image enthält alle benötigten benutzerdefinierten Einstellungen. Wenn Sie in Ihrer Instanzvorlage ein benutzerdefiniertes Image festlegen, verwendet die MIG zum Neuerstellen von VMs das benutzerdefinierte Image, das die erforderlichen benutzerdefinierten Einstellungen enthält.

Systemdiagnose und Richtlinie für die automatische Reparatur einrichten

Sie können pro MIG maximal eine Richtlinie für die automatische Reparatur einrichten.

Eine Systemdiagnose kann auf maximal 50 MIGs angewendet werden. Wenn 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 MIG angewendet wird. In diesem Beispiel erstellen Sie eine Systemdiagnose, die Port 80 auf eine Antwort des Webservers prüft. Damit die Systemdiagnoseprüfungen die einzelnen Webserver erreichen können, müssen Sie eine Firewallregel einrichten. Schließlich wenden Sie die Systemdiagnose auf die MIG an und erstellen dafür die Richtlinie für die automatische Reparatur der Gruppe.

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. Sie 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. Prüfen Sie, ob unter Protokoll die Option 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 anzugeben, wie viele aufeinanderfolgende Systemdiagnosen erfolgreich sein müssen, bevor eine fehlerhafte VM als fehlerfrei markiert wird. Geben Sie in diesem Beispiel 1 ein.
    8. 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.
    9. Klicken Sie auf Erstellen, um die Systemdiagnose zu erstellen.

  2. Richten Sie eine Firewallregel ein, damit die Systemdiagnoseprüfungen eine Verbindung zu Ihrer Anwendung herstellen können.

    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 Firewallregel erstellen auf.

      Zur Seite "Firewallregel erstellen"

    2. Geben Sie für Name einen Namen für die Firewallregel ein. Beispiel: allow-health-check
    3. Wählen Sie unter Netzwerk das Netzwerk 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 regionale oder zonale MIG an. Konfigurieren Sie dazu eine Richtlinie zur automatischen Reparatur.

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

      Zur Seite Instanzgruppen

    2. Klicken Sie in der Spalte Name der Liste auf den Namen der MIG, auf die Sie die Systemdiagnose anwenden möchten.
    3. Klicken Sie auf Gruppe bearbeiten, um diese MIG zu ändern.
    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 übernehme Sie sie. Mit dieser Einstellung wird die potenzielle vorzeitige Neuerstellung der VM durch die automatische Reparatur verzögert, wenn die VM gerade gestartet wird. Der Timer für die anfängliche Verzögerung startet, wenn für currentAction der VM der Status VERIFYING gilt.
    6. Klicken Sie auf Speichern, um die Änderungen zu übernehmen.

gcloud

Wenn Sie die Befehlszeilenbeispiele in dieser Anleitung verwenden möchten, installieren Sie das gcloud-Befehlszeilentool oder verwenden Sie eine Cloud Shell.

  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. 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. Richten Sie die Firewallregel so ein, dass die Systemdiagnosetests eine Verbindung zu Ihrer Anwendung herstellen können.

    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

  3. Wenden Sie die Systemdiagnose auf die regionale oder zonale MIG an. Konfigurieren Sie dazu eine Richtlinie zur automatischen Reparatur.

    Zum Anwenden der Systemdiagnose auf die MIG verwenden Sie den Befehl update.

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

    Beispiel:

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

API

Wenn Sie die API-Beispiele dieser Anleitung verwenden möchten, richten Sie den API-Zugang ein.

  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. Sie wird als fehlerhaft markiert, wenn die Systemdiagnose 3-mal hintereinander erfolglos war.

    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
}

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

    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. Falls 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"
  }
 ]
}

  3. Wenden Sie die Systemdiagnose auf die regionale oder zonale MIG an. Konfigurieren Sie dazu eine Richtlinie zur automatischen Reparatur.

    Richtlinien zur automatischen Reparatur sind Teil der Ressource instanceGroupManager oder regionInstanceGroupManager.

    Sie können mit den Methoden insert oder patch festgelegt werden.

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

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

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

    Wenn Sie die anwendungsbasierte automatische Reparatur deaktivieren möchten, geben Sie für die Richtlinie zur automatischen Reparatur einen leeren Wert an: autoHealingPolicies[]. Mit autoHealingPolicies[] erstellt die MIG nur VMs neu, die nicht den Status RUNNING haben.

    Sie können die Richtlinie zur automatischen Reparatur einer MIG im Feld instanceGroupManagers.autoHealingPolicies abrufen. Eine MIG-Ressource lässt sich mit einer der folgenden Methoden abrufen:

Nach der Erstellung der Gruppe oder der Aktualisierung der Systemdiagnosekonfiguration kann es bis zu 30 Minuten dauern, bis die automatische Reparatur mit dem Monitoring der Instanzen in der Gruppe beginnt. Sobald das Monitoring gestartet wurde, beginnt Compute Engine, Instanzen basierend auf Ihrer Konfiguration für die automatische 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:

  • 30 Minuten Verzögerung, bevor die automatische Reparatur mit dem Monitoring der Instanzen 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)
  • = 36 Minuten, bevor die Instanz als fehlerfrei markiert oder neu erstellt wird

Status prüfen

Es gibt verschiedene Möglichkeiten zu prüfen, ob eine VM erstellt wurde und ihre Anwendung reagiert. Sie können dazu den aktuellen Systemstatus und die aktuelle Aktion der einzelnen VMs sowie den Status der Gruppe prüfen.

VMs auf fehlerfreien Status prüfen

Wenn Sie die automatische Reparatur für Ihre MIG konfiguriert haben, können Sie den Systemstatus jeder einzelnen verwalteten Instanz prüfen.

Bei dieser Prüfung werden die folgenden Fehler erkannt:

  • Fehlerhafte VMs, die nicht automatisch 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 gerade automatisch repariert. Die automatische 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. Sie können diese Zeit messen, indem Sie die Methode list-instances abfragen.

Sie können den Integritätszustand in der Console, dem gcloud-Befehlszeilentool oder der API ansehen.

Console

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

    Zur Seite "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.

API

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 30 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 automatischen Reparatur, wenn möglich, sofort repariert.
  • VMs im Status UNKNOWN werden 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 unter mig-discuss@google.com an unser Team.

Aktuelle Aktionen für VMs ansehen

Wenn eine VM gerade erstellt wird, lautet der Wert für currentAction dieser Instanz CREATING. Wenn die Gruppe mit einer automatischen Reparatur verknüpft ist, ändert sich der Status von currentAction in VERIFYING, wenn die VM erstellt ist und ausgeführt wird. Die Systemdiagnose beginnt dann mit der Prüfung der VM-Anwendung. Durchläuft die Anwendung diese erste Systemdiagnose innerhalb ihrer Startphase erfolgreich, wird die VM bestätigt und currentAction erhält den Status NONE.

Mit dem gcloud-Befehlszeilentool können Sie sich die ausgeführten currentAction und die status jeder Instanz in einer verwalteten Instanzgruppe oder die Compute Engine API anzeigen lassen.

gcloud 

gcloud compute instance-groups managed list-instances INSTANCE_GROUP_NAME \
    [--zone=ZONE | --region=REGION]

Der Befehl gibt eine Liste der Instanzen in der MIG sowie deren Status und aktuelle Aktionen zurück. Beispiel:

NAME               ZONE           STATUS   HEALTH_STATE  ACTION  INSTANCE_TEMPLATE  VERSION_NAME  LAST_ERROR
vm-instances-9pk4  us-central1-f                          CREATING  my-new-template
vm-instances-h2r1  us-central1-f  STOPPING                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

Die Spalte HEALTH_STATE ist leer, sofern Sie keine Systemdiagnose eingerichtet haben.

API

Rufen Sie die Methode listManagedInstances für eine regionale oder zonale MIG-Ressource auf. Beispiel:

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

Der Aufruf gibt eine Liste der Instanzen für die MIG zurück, einschließlich instanceStatus und currentAction jeder Instanz.

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

Eine Liste der gültigen Werte für das Feld instanceStatus finden Sie unter Status einer Instanz prüfen.

Wenn an einer 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 hat das Feld currentAction den Wert NONE.

Folgende currentAction-Werte sind möglich:

  • ABANDONING. Die Instanz wird gerade aus der MIG 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 MIG nicht, die Instanz noch einmal zu ersetzen.
  • DELETING: Die Instanz wird gerade gelöscht.
  • RECREATING. Die Instanz wird gerade ersetzt.
  • REFRESHING: Die Instanz wird 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.

Stabilität der MIG prüfen

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

Wenn alle VMs der Gruppe ausgeführt werden und fehlerfrei sind, d. h. wenn für currentAction der einzelnen verwalteten Instanzen der Wert NONE lautet, gilt status.isStable==true. Die Stabilität einer MIG hängt von Gruppenkonfigurationen ab, die über die Richtlinie zur automatischen Reparatur hinausgehen. Wenn beispielsweise für Ihre Gruppe das Autoscaling aktiviert ist und wenn sie derzeit skaliert wird, dann gilt isStable==false aufgrund des Autoscaling-Vorgangs.

Prüfen Sie, ob alle Instanzen in einer verwalteten Instanzgruppe ausgeführt werden und fehlerfrei sind, indem Sie den Wert des Feldes status.isStable der Gruppe prüfen.

gcloud

Führen Sie den Befehl describe aus:

gcloud compute instance-groups managed describe instance-group-name \
    [--zone zone | --region region]

Das gcloud-Tool gibt detaillierte Informationen zur MIG zurück, einschließlich des Felds status.isStable.

Wenn ein Skript pausiert werden soll, bis die MIG stabil ist, verwenden Sie den Befehl wait-until mit dem Flag --stable. Beispiel:

gcloud compute instance-groups managed wait-until instance-group-name \
    --stable \
    [--zone zone | --region region]
Waiting for group to become stable, current operations: deleting: 4
Waiting for group to become stable, current operations: deleting: 4
...
Group is stable

Der Befehl gibt das Ergebnis zurück, nachdem status.isStable für die MIG auf true gesetzt wurde.

API

Stellen Sie für eine zonale MIG eine GET-Anfrage an die Methode instanceGroupManagers.get:

GET https://compute.googleapis.com/compute/v1/projects/project-id/zones/zone/instanceGroupManagers/instance-group-name/get

Ersetzen Sie für regional verwaltete Instanzgruppen zones/zone durch regions/region:

GET https://compute.googleapis.com/compute/v1/projects/project-id/regions/region/instanceGroupManagers/instance-group-name/get

Die Compute Engine API gibt detaillierte Informationen zur MIG zurück, einschließlich des Felds status.isStable.

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

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

  • Die Instanzen in der MIG werden nicht geändert und die currentAction für alle Instanzen ist NONE.
  • Es gibt keine Änderungen bei Instanzen in der MIG.
  • Die MIG selbst wird nicht geändert.

Beachten Sie, dass die Stabilität einer MIG von zahlreichen Faktoren abhängt, da eine MIG auf verschiedene Arten geändert werden kann. 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 MIG zu ändern.
  • Eine Ressource für die automatische Reparatur ersetzt in der MIG eine oder mehrere fehlerhafte Instanzen.
  • In einer regionalen MIG werden einige der Instanzen neu verteilt.

Sobald alle Aktionen abgeschlossen sind, wird status.isStable für diese MIG wieder auf true gesetzt.

Frühere automatische Reparaturvorgänge ansehen

Sie können das gcloud-Tool oder die API verwenden, um vergangene automatische Reparaturereignisse anzusehen.

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

API

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 zoneOoperations.

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