Systemdiagnosen und automatische Reparatur einrichten

Mithilfe von verwalteten Instanzgruppen (Managed instance groups, MIGs) können Sie die Hochverfügbarkeit Ihrer Anwendungen aufrechterhalten. Die Instanzgruppen sorgen proaktiv dafür, dass die VM-Instanzen verfügbar bleiben, das heißt, den Status RUNNING behalten. Verlieren Instanzen den Status RUNNING aus Gründen, die nichts mit der verwalteten Instanzgruppe (MIG) zu tun haben, z. B. aufgrund eines Hardwarefehlers und nicht aufgrund einer Autoscaling-Entscheidung, werden die Instanzen von der MIG automatisch neu erstellt. 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" erkannt.

Um die Verfügbarkeit Ihrer Anwendungen zu verbessern und zu prüfen, ob die Anwendung wie erwartet antwortet, können Sie für Ihre verwalteten Instanzgruppen eine Richtlinie für die automatische Reparatur konfigurieren.

Im Rahmen der Richtlinie wird eine anwendungsbasierte Systemdiagnose durchgeführt. Die Prüfung, ob eine Anwendung antwortet, liefert genauere Ergebnisse als die Überprüfung des Status RUNNING von Instanzen.

Wird bei der automatischen Reparatur festgestellt, dass eine Anwendung nicht antwortet, wird die entsprechende Instanz von der verwalteten Instanzgruppe automatisch neu erstellt. Instanzen auf Abruf werden von der Gruppe neu erstellt, sobald 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. Das muss nicht zwingend die aktuelle Instanzvorlage in der verwalteten Instanzgruppe sein. Beispiel: Eine VM-Instanz wurde mit der Vorlage instance-template-a erstellt. Anschließend wurde die verwaltete Instanzgruppe aktualisiert und verwendet nun instance-template-b im Modus OPPORTUNISTIC. Bei der automatischen Reparatur wird in diesem Fall zur Wiederherstellung der Instanz weiterhin die Vorlage instance-template-a verwendet. Dies liegt daran, dass die von der automatischen Reparatur herbeigeführten Wiederherstellungen nicht vom Nutzer eingeleitet werden. Compute Engine geht daher nicht davon aus, dass die neue Vorlage für die VM-Instanz verwendet werden soll. Informationen dazu, wie Sie eine neue Vorlage anwenden können, finden Sie 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 auf der Seite zum 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 sich currentAction im Statuts VERIFYING befindet.

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 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 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. 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. Stellen Sie deshalb sicher, dass Ihre Netzwerk-Firewallregeln die Verbindung zulassen. In diesem Beispiel nutzt die verwaltete Instanzgruppe das Netzwerk default und ihre Instanzen behalten Port 80 im Blick. Falls 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 regional oder zonal verwaltete Instanzgruppe 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 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 startet, wenn sich currentAction der Instanz im Status VERIFYING befindet.
    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

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.

    Sie könnten beispielsweise eine Systemdiagnose erstellen, 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. 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 verwaltete Instanzgruppe das Netzwerk default und ihre Instanzen behalten Port 80 im Blick. 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 eine 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 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 der Instanzen in der Gruppe durch die automatische Reparatur beginnt.

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.

    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://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 verwaltete Instanzgruppe das Netzwerk default und ihre Instanzen behalten Port 80 im Blick. 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://compute.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.

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

    Die Richtlinie für die automatische Reparatur einer verwalteten Instanzgruppe kann im Feld instanceGroupManagers.autoHealingPolicies angesehen werden. Die Ressource einer verwalteten Instanzgruppe kann mit einer der folgenden Methoden ausgegeben werden:

Status prüfen

Es gibt verschiedene Möglichkeiten zu prüfen, ob eine Instanz erstellt wurde und ihre Anwendung reagiert. Sie können den aktuellen Integritätszustand der einzelnen Instanzen prüfen, indem Sie die aktuelle Aktion prüfen oder den Status der Gruppe prüfen.

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

Intakten Zustand von Instanzen prüfen

Wenn Sie die automatische Reparatur für die verwaltete Instanzgruppe konfiguriert haben, können Sie jede einzelne Instanz auf ihre Intaktheit prüfen.

Bei dieser Prüfung werden die folgenden Fehler erkannt:

  • Fehlerhafte VMs, die nicht automatisch repariert werden. In den folgenden Situationen kann es vorkommen, dass als fehlerhaft erkannte VM-Instanzen nicht sofort repariert werden:
    • Die VM befindet sich noch im Startvorgang und die Zeit der anfängliche 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 Instanzgruppe, die Sie sich genauer ansehen möchten. Ihnen wird eine Seite mit den Attributen der Instanzgruppe und einer Liste der zur Gruppe gehörenden Instanzen angezeigt.

  3. Wenn eine Instanz fehlerhaft ist, können Sie den Integritätszustand in der Spalte Probleme ansehen.

gcloud

Verwenden Sie den Unterbefehl list-instances.

gcloud beta 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 Zustand der einzelnen Instanzen angezeigt.

API

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

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

Verwenden Sie für eine verwaltete zonale Instanzgruppe die entsprechende Methode listManagedInstances:

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

Integritätszustände

Für Instanzen sind die folgenden Integritätszustände möglich:

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

Neue Instanzen geben UNHEALTHY zurück, bis sie von der Systemdiagnose überprüft wurden.

Ob eine Instanz repariert wird, hängt von ihrem Integritätszustand ab:

  • Instanzen im Zustand UNHEALTHY oder TIMEOUT, deren Initialisierungsphase abgelaufen ist, werden von der automatischen Reparatur, wenn möglich, sofort repariert.
  • Instanzen im Zustand UNKNOWN werden nicht sofort repariert. Damit soll eine unnötige Reparatur von Instanzen verhindert werden, für die vorübergehend kein Systemdiagnosesignal verfügbar ist.

Die automatische Reparatur kann in folgenden Fällen verzögert werden:

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

Wir möchten mehr über Ihre Anwendungsfälle und Herausforderungen erfahren. Wir freuen uns auch über Feedback zu den verschiedenen Integritätszuständen von VM-Instanzen. Senden Sie Ihr Feedback an unser Team unter mig-discuss@google.com.

Aktuelle Aktionen für Instanzen ansehen

Die currentAction für verwaltete Instanzen, die gerade erstellt werden, ist CREATING. Wenn die Gruppe mit einer automatischen Reparatur verknüpft ist, ändert sich der Status von 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. Durchläuft die Anwendung diese erste Systemdiagnose erfolgreich innerhalb ihrer Startdauer, wird die Instanz bestätigt und currentAction erhält den Status NONE.

Mit dem gcloud-Befehlszeilentool oder der API können Sie prüfen, ob currentAction ausgeführt wird und welchen status die einzelnen Instanzen in einer verwalteten Instanzgruppe haben.

gcloud

gcloud compute instance-groups managed list-instances instance-group-name \
[--filter="zone:(zone)" | --filter="region:(region)"]

gcloud gibt eine Liste der Instanzen in der Instanzgruppe sowie ihre jeweiligen Zustände und aktuellen Aktionen 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  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

API

Senden Sie in der API eine GET-Anfrage an die Methode regionInstanceGroupManagers.listManagedInstances. Verwenden Sie für eine verwaltete zonale Instanzgruppe die Methode instanceGroupManagers.listManagedInstances.

GET https://compute.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. Dabei wird jeweils auch instanceStatus und currentAction ausgegeben.

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

Der Status der einzelnen Instanzen in einer verwalteten Instanzgruppe wird durch das zugehörige Feld instanceStatus-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 hat das Feld currentAction den Wert NONE.

Folgende currentAction-Werte sind möglich:

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

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 Instanzen in der Gruppe ausgeführt werden und fehlerfrei sind, d. h. currentAction der einzelnen verwalteten Instanzen NONE ist, gilt status.isStable==true. Beachten Sie, dass die Stabilität einer verwalteten Instanzgruppe von Gruppenkonfigurationen abhängt, die über die Richtlinie für die automatische Reparatur hinausgehen. Wenn Ihre Gruppe beispielsweise generell automatisch skaliert und gerade hochskaliert wird, dann gilt aufgrund des Autoscaling-Vorgangs isStable==false.

Sie können prüfen, ob eine verwaltete Instanzgruppe ausgeführt wird und fehlerfrei ist, indem Sie den Wert des Felds status.isStable prüfen.

gcloud

Verwenden Sie den Instanzgruppenbefehl describe:

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

Das gcloud-Tool liefert detaillierte Informationen zur Instanzgruppe und gibt auch das Feld status.isStable zurück.

Um ein Skript anzuhalten, bis die Gruppe stabil ist, verwenden Sie den Befehl wait-until mit dem Flag --stable. Beispiel:

gcloud beta 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 Gruppe auf true gesetzt wurde.

API

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

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

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

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

Die API liefert detaillierte Informationen zur Instanzgruppe, einschließlich des Felds status.isStable.

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.

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 verwaltete regionale Instanzgruppen 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 verwaltete zonale Instanzgruppen die Ressource zoneOoperations.

GET https://compute.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://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: Muss 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 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