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:
- Hardwarefehler.
- Beenden einer Instanz auf Abruf.
- Löschen einer MIG-Instanz mithilfe der Methode
instances.delete
anstelle der MethodeinstanceGroupManagers.deleteInstances
in der Compute Engine API oder imgcloud
-Befehlszeilentool. - Infrastrukturwartungsereignisse, wenn die VM-Instanz nicht auf Live-Migration eingestellt ist.
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:
- Erstellen Sie regelmäßig Snapshots des nichtflüchtigen Speichers.
- Exportieren Sie Daten in eine andere Quelle, zum Beispiel Cloud Storage.
- Zustandsorientierte nichtflüchtige Speicher konfigurieren
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
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 Systemdiagnose3
-mal hintereinander erfolglos war.- Rufen Sie in der Google Cloud Console die Seite Systemdiagnose erstellen auf.
- Geben Sie einen Namen für die Systemdiagnose ein, z. B.
example-check
. - Prüfen Sie, ob unter Protokoll die Option HTTP ausgewählt ist.
- Geben Sie für Port den Wert
80
ein. - Geben Sie für Überprüfungsintervall den Wert
5
ein. - Geben Sie für Zeitlimit den Wert
5
ein. - 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. - 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. - Klicken Sie auf Erstellen, um die Systemdiagnose zu erstellen.
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
und35.191.0.0/16
. Stellen Sie deshalb sicher, dass Ihre Netzwerk-Firewallregeln die Verbindung zulassen. In diesem Beispiel nutzt die MIG das Netzwerkdefault
. Deren VMs überwachen Port80
. Wenn Port80
im Netzwerk "default" noch nicht offen ist, erstellen Sie eine entsprechende Firewallregel.- Rufen Sie in der Google Cloud Console die Seite Firewallregel erstellen auf.
- Geben Sie für Name einen Namen für die Firewallregel ein. Beispiel:
allow-health-check
- Wählen Sie unter Netzwerk das Netzwerk
default
aus. - Wählen Sie für Quellfilter die Option
IP ranges
aus. - Geben Sie für Quell-IP-Bereiche
130.211.0.0/22
und35.191.0.0/16
ein. - Wählen Sie unter Protokolle und Ports die Option Angegebene Protokolle und Ports aus und geben Sie
tcp:80
ein. - Klicken Sie auf Erstellen.
Wenden Sie die Systemdiagnose auf die regionale oder zonale MIG an. Konfigurieren Sie dazu eine Richtlinie zur automatischen Reparatur.
- Rufen Sie in der Google Cloud Console die Seite Instanzgruppen auf.
- Klicken Sie in der Spalte Name der Liste auf den Namen der MIG, auf die Sie die Systemdiagnose anwenden möchten.
- Klicken Sie auf Gruppe bearbeiten, um diese MIG zu ändern.
- Wählen Sie unter Automatische Reparatur die Systemdiagnose aus, die Sie zuvor erstellt haben.
- Ä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 StatusVERIFYING
gilt. - 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.
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 Systemdiagnose3
-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
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
und35.191.0.0/16
. Sorgen Sie dafür, dass Ihre Firewallregeln die Verbindung zulassen. In diesem Beispiel verwendet die MIG das Netzwerkdefault
. Deren VMs überwachen Port80
. Wenn Port80
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
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ürcurrentAction
der VM der StatusVERIFYING
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.
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 Systemdiagnose3
-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 }
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
und35.191.0.0/16
. Sorgen Sie dafür, dass Ihre Firewallregeln die Verbindung zulassen. In diesem Beispiel nutzt die MIG das Netzwerkdefault
. Deren VMs überwachen Port80
. Falls Port80
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" } ] }
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
oderregionInstanceGroupManager
.Sie können mit den Methoden
insert
oderpatch
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ürcurrentAction
der VM der StatusVERIFYING
gilt.Wenn Sie die anwendungsbasierte automatische Reparatur deaktivieren möchten, geben Sie für die Richtlinie zur automatischen Reparatur einen leeren Wert an:
autoHealingPolicies[]
. MitautoHealingPolicies[]
erstellt die MIG nur VMs neu, die nicht den StatusRUNNING
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:instanceGroupManagers.get
gibt die angegebene verwaltete zonale Instanzgruppenressource zurückinstanceGroupManagers.list
gibt alle zonalen MIGs im angegebenen Projekt und in der angegebenen Zone zurückregionInstanceGroupManagers.get
gibt die angegebene regionale MIG-Ressource zurück.regionInstanceGroupManagers.list
gibt alle regional verwalteten MIGs in einem angegebenen Projekt und einer angegebenen Region zurück.
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ätszustandHEALTHY
benötigt. Sie können diese Zeit messen, indem Sie die Methodelist-instances
abfragen.
Sie können den Integritätszustand in der Console, dem gcloud
-Befehlszeilentool oder der API ansehen.
Console
Rufen Sie in der Google Cloud Console die Seite Instanzgruppen auf.
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.
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
oderTIMEOUT
, 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 Methodenstop
undstart
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 istNONE
. - 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 als1
sein. Setzen Sie diesen Wert idealerweise auf3
oder höher. Dies schützt vor seltenen Fehlern wie einem Netzwerkpaketverlust.healthy-threshold
: Ein Wert von2
ist für die meisten Anwendungen ausreichend.timeout
: Legen Sie hierfür einen großzügigen Wert fest. Der Zeitwert sollte fünfmal so hoch sein wie die erwartete Antwortzeit oder noch höher. Das sorgt für Schutz bei unerwarteten Verzögerungen wie ausgelasteten Instanzen oder langsamen Netzwerkverbindungen.check-interval
: Dieser Wert sollte zwischen 1 Sekunde und dem Zweifachen des Zeitlimits liegen (nicht zu lang oder zu kurz). Bei einem zu langen Intervall wird eine Instanz mit Fehlern nicht rechtzeitig erkannt. Ein zu kurzes Intervall kann zu einer merklichen Auslastung der Instanzen und des Netzwerks führen, da jede Sekunde eine hohe Anzahl von Systemdiagnoseprüfungen gesendet wird.
Weitere Informationen
- Die Anleitung Automatische Reparatur für hochverfügbare Anwendungen verwenden durcharbeiten
- Mehr über Instanzgruppen erfahren
- Autoscaling für die MIG aktivieren
- Load-Balancing für die MIG aktivieren