Informazioni sugli eventi dell'host

Nel corso del ciclo di vita di un'istanza di macchina virtuale (VM) o di un'istanza bare metal, la macchina host su cui viene eseguita l'istanza può essere soggetta a numerosi eventi host. Un evento host può includere la normale manutenzione dell'infrastruttura Compute Engine o, in rari casi, un errore dell'host. Puoi scegliere in che modo le tue istanze di computing rispondono durante o dopo un evento host configurando la policy di manutenzione dell'host.

Per impostazione predefinita, la maggior parte delle istanze è impostata per la migrazione live durante gli eventi host. Per tutte le serie di macchine, ad eccezione di Z3, puoi sostituire questo comportamento e impostare esplicitamente le istanze in modo che vengano terminate e, facoltativamente, riavviate. Le istanze create utilizzando determinati tipi di macchine o configurazioni non supportano la migrazione live, ad esempio:

  • Istanze H4D
  • Istanze Z3 con più di 18.000 GiB di Titanium SSD collegato
  • Istanze Z4D e Z4M con più di 42.000 GiB di Titanium SSD collegato
  • Istanze con un'interfaccia di rete Cloud RDMA
  • Istanze bare metal
  • Istanze con GPU collegate

Queste istanze vengono terminate durante gli eventi host. Per saperne di più, consulta Comportamenti di manutenzione e riavvio.

Tipi di eventi host

Esistono tre tipi di eventi host, descritti in dettaglio nelle sezioni seguenti:

Se l'istanza non risponde, può anche attivare un riavvio o un arresto dell'istanza.

Eventi di manutenzione

Un evento di manutenzione si verifica quando Compute Engine deve eseguire un'attività di manutenzione o riparazione che richiede lo spostamento delle VM dal server host. Se abiliti la policy di manutenzione dell'host migrazione live per un tipo di istanza supportato, Compute Engine sposta l'istanza in un nuovo host e l'interruzione dell'applicazione è minima.

Compute Engine applica anche alcuni upgrade leggeri dell'hypervisor e della rete in background in modo non invasivo, mantenendo l'istanza sullo stesso host.

Il comportamento dell'istanza durante un evento di manutenzione può variare a seconda della tenancy dell'istanza e del tipo di macchina.

Per le VM single-tenant, la frequenza approssimativa degli eventi di manutenzione dell'host pianificati è ogni 4-6 settimane. La migrazione live è supportata o meno a seconda della policy di manutenzione dell'host per la VM single-tenant.

Puoi trovare informazioni sul comportamento di manutenzione per ogni tipo di macchina nella pagina della famiglia di macchine corrispondente, come segue:

Per le famiglie di macchine ottimizzate per l'acceleratore, consulta le pagine seguenti:

Manutenzione di emergenza

Un evento di manutenzione di emergenza si verifica quando Compute Engine rileva un guasto imminente dell'host o un altro problema hardware che richiede una manutenzione urgente. Per questi eventi, Compute Engine pianifica l'evento di manutenzione e crea una notifica. Le finestre di notifica degli eventi di manutenzione di emergenza sono in genere più brevi rispetto a quelle degli eventi di manutenzione standard.

Un evento di manutenzione di emergenza in genere fornisce un preavviso di 7-14 giorni. A seconda della gravità del problema, la finestra di notifica può essere più breve. Esamina la notifica di manutenzione per le funzionalità supportate, ad esempio l'avvio della manutenzione in un momento a tua scelta. Se non viene intrapresa alcuna azione o se non è possibile avviare manualmente la manutenzione, Compute Engine la avvia automaticamente al termine della finestra di notifica.

Se è in attesa un evento di manutenzione pianificato quando Compute Engine invia una notifica di manutenzione di emergenza, l'evento di manutenzione di emergenza sostituisce l'evento di manutenzione pianificato.

Puoi controllare il motivo della manutenzione di emergenza nel campo maintenanceReasons dei metadati dell'istanza. Questo campo contiene un valore che rappresenta la categoria di errore.

Errori dell'host

Un errore dell'host (compute.instances.hostError) indica che si è verificato un problema hardware o software sulla macchina fisica o sull'infrastruttura del data center che ospita l'istanza di computing e ne ha causato l'arresto anomalo. Un errore dell'host che coinvolge un guasto hardware totale o altri problemi relativi all'hardware potrebbe impedire la migrazione live dell'istanza. Se l'istanza è impostata per il riavvio automatico, che è l' impostazione predefinita, Compute Engine la riavvia, in genere entro tre minuti dal rilevamento dell'errore. A seconda del problema, il riavvio potrebbe richiedere fino a 5,5 minuti.

Dopo che un'istanza di computing rileva un errore dell'host o se segnali l'host come difettoso, l' host dell'istanza richiede una manutenzione di emergenza non pianificata. Per impostazione predefinita, Compute Engine fornisce un preavviso di alcune ore quando pianifica questo tipo di manutenzione.

A volte, un'istanza di computing potrebbe non rispondere prima che venga segnalato un errore dell'host. Puoi ridurre il tempo di attesa di Compute Engine per riavviare o terminare l'istanza impostando il timeout per la correzione degli errori dell'host. Per saperne di più, consulta Imposta la policy per un'istanza esistente.

A volte possono verificarsi guasti hardware e software fisici, ma si tratta di casi rari. Per proteggere le tue applicazioni e i tuoi servizi da questi eventi di sistema che potrebbero causare interruzioni, consulta le seguenti risorse:

Google offre anche servizi gestiti come App Engine e l' ambiente flessibile App Engine.

Panoramica della policy di manutenzione dell'host

La policy di manutenzione dell'host di un'istanza determina il suo comportamento durante i seguenti eventi host:

  • Evento di manutenzione
  • Evento di manutenzione di emergenza
  • Evento di errore dell'host o istanza che non risponde

Puoi configurare le istanze in modo che continuino a essere eseguite durante la manutenzione dell'host, mentre Compute Engine esegue la migrazione live a un altro host, oppure puoi scegliere di arrestare l'istanza.

Puoi modificare la policy di manutenzione dell'host di un'istanza configurando le seguenti impostazioni:

  • Comportamento di manutenzione: indica se viene eseguita la migrazione live o l'arresto dell'istanza quando si verifica un evento di manutenzione.
  • Comportamento di riavvio: indica se Compute Engine riavvia o termina l'istanza se si verifica un arresto anomalo, un errore dell'host o se l'istanza non risponde.
  • Tempo di rilevamento degli errori dell'host: il periodo di tempo massimo che Compute Engine attende per riavviare o terminare un'istanza dopo aver rilevato che non risponde.
  • Tempo di recupero dell'SSD locale: il periodo di tempo massimo che Compute Engine trascorre nello stato REPAIRING per recuperare i dati sui dischi SSD locali dopo aver rilevato un errore dell'host o durante un evento di manutenzione che richiede l'arresto dell'istanza. Se il tempo specificato trascorre senza un recupero riuscito, i dati dell'SSD locale vengono persi.

Puoi aggiornare la policy di manutenzione dell'host di un'istanza in qualsiasi momento per controllare il comportamento delle istanze.

Comportamenti di manutenzione e riavvio

Quando si verifica un evento host, l'istanza di computing può utilizzare la migrazione live oppure può essere terminata. Se un'istanza viene terminata, puoi scegliere di riavviarla autonomamente o di farla riavviare automaticamente da Compute Engine.

Le seguenti serie di macchine potrebbero non supportare la migrazione live e richiedere invece l'arresto durante gli eventi host:

  • Le istanze basate sui seguenti tipi di macchine vengono arrestate e riavviate in loco:
    • Z3 con più di 18.000 GiB di Titanium SSD
    • Z4D o Z4M con più di 42.000 GiB di Titanium SSD
    • Z4M con un' interfaccia di rete Cloud RDMA
    • X5,
    • X4
    • H4D
  • Le istanze bare metal vengono arrestate e riavviate, il che significa che potrebbero essere riavviate su un host diverso. Per ulteriori dettagli, consulta la documentazione "Esperienza di manutenzione" per la serie di macchine. Ad esempio, per i tipi di macchine bare metal C3, consulta Esperienza di manutenzione per le istanze C3.
  • Istanze Confidential VM ad eccezione dei tipi di macchine N2D con piattaforme CPU AMD EPYC Milan che eseguono AMD SEV.
  • Istanze con GPU
  • Istanze con TPU

Migrazione live

Per impostazione predefinita, la maggior parte dei tipi di istanze è impostata per la migrazione live, ad eccezione dei tipi di istanze menzionati nella sezione precedente.

Durante la migrazione live, Compute Engine esegue automaticamente la migrazione dell'istanza da un evento di manutenzione dell'infrastruttura e l'istanza rimane in esecuzione durante la migrazione. L'istanza potrebbe registrare un breve periodo di prestazioni ridotte, ma in generale la maggior parte delle istanze non dovrebbe avere prestazioni notevolmente diverse. Questa opzione è ideale per le istanze che richiedono un uptime costante e possono tollerare un breve periodo di prestazioni ridotte.

Quando Compute Engine esegue la migrazione dell'istanza, segnala un evento di sistema pubblicato nell'elenco delle operazioni di zona e nei log degli eventi di sistema. Puoi esaminare questo evento visualizzando le operazioni di Compute Engine per una zona specifica. Gli eventi di migrazione live hanno il seguente tipo di operazione:

compute.instances.migrateOnHostMaintenance

Terminazione e riavvio

Se non vuoi che venga eseguita la migrazione live dell'istanza o se il tipo di istanza non supporta la migrazione live, puoi scegliere di consentire Google Cloud l'arresto dell'istanza quando si verifica un evento host. Con questa configurazione, se si verifica un evento host, Compute Engine invia un segnale di spegnimento software per arrestare l'istanza. Attende quindi 60 secondi che l'istanza si arresti correttamente e imposta lo stato dell'istanza su TERMINATED. Se l'istanza non si arresta correttamente entro 60 secondi, viene terminata forzatamente.

Questa opzione è ideale se le istanze richiedono prestazioni costanti e massime e se l'applicazione complessiva è progettata per gestire gli errori o i riavvii delle istanze.

Quando Compute Engine arresta un'istanza a causa di un evento host, segnala un evento di sistema pubblicato nell'elenco delle operazioni di zona e nei log degli eventi di sistema. Puoi esaminare questo evento visualizzando le operazioni di Compute Engine per una zona specifica. Gli eventi di arresto dell'istanza hanno il seguente tipo di operazione:

compute.instances.terminateOnHostMaintenance

Riavvio automatico

Se l'istanza è configurata per l'arresto quando si verifica un evento di manutenzione o se si verifica un arresto anomalo a causa di un problema hardware sottostante, Compute Engine può riavviare automaticamente l'istanza. L'istanza viene riavviata sullo stesso server host o spostata su un altro server nella stessa zona che non partecipa all'evento di manutenzione.

Per impostazione predefinita, Compute Engine tenta di recuperare le istanze con dischi SSD locali collegati per un'ora. Se viene raggiunto il limite di tempo, Compute Engine tenta di riavviare l'istanza su un server host diverso nella stessa zona. Le istanze Z4D, Z4M, Z3, X4 e H4D hanno tempi di attesa predefiniti diversi. Questi tipi di istanze vengono riavviati sullo stesso server host dopo l'arresto dell'istanza.

Per configurare il riavvio automatico, imposta il campo automaticRestart della policy di manutenzione dell'host su true. Questa impostazione non si applica se l'istanza viene messa offline a causa di un'interruzione a livello di zona o tramite un'operazione manuale, ad esempio chiamando sudo shutdown nel sistema operativo guest.

Quando Compute Engine riavvia automaticamente l'istanza, segnala un evento di sistema pubblicato nell'elenco delle operazioni di zona. Puoi esaminare questo evento visualizzando le operazioni di Compute Engine per una zona specifica. Gli eventi di riavvio automatico hanno il seguente tipo di operazione:

compute.instances.automaticRestart

Persistenza del disco dopo l'arresto dell'istanza

Poiché Persistent Disk e Hyperdisk sono Network Attached Storage, quando l'istanza viene riavviata, Compute Engine ricollega il disco di avvio e tutti i dischi secondari all'istanza. I dati su questi dischi persistono durante la migrazione live e i riavvii dell'istanza.

Quando possibile, Compute Engine conserva i dati sui dischi SSD locali dopo un evento host. Tuttavia, Compute Engine non garantisce la persistenza dei dati dell'SSD locale.

  • I dischi SSD locali vengono conservati nei seguenti scenari:

    • Riavvii il sistema operativo guest.
    • Configuri l'istanza per la migrazione live e l'istanza viene sottoposta a un evento di manutenzione dell'host.
    • Si verifica un errore dell'host e Compute Engine ricollega l'istanza ai dischi SSD locali entro il limite di timeout.
    • Scegli di conservare i dati dell'SSD locale quando arresti o sospendi l'istanza (anteprima).
    • Un'istanza di computing con dischi SSD locali collegati che supporta solo l'arresto e il riavvio automatico viene sottoposta a un evento di manutenzione. L'istanza viene riavviata in loco, conservando i dati dell'SSD locale, anziché eseguire la migrazione a un nuovo host.

  • I dischi SSD locali non vengono conservati nei seguenti scenari:

    • Arresti il sistema operativo guest e forzi l'arresto dell'istanza.
    • Crei una VM spot o VM preemptible e la VM viene sottoposta alla procedura di prerilascio.
    • Configuri l'istanza in modo che si arresti in caso di eventi di manutenzione dell'host anziché utilizzare la migrazione live e questi si verificano.
    • Configuri erroneamente un disco SSD locale e non è raggiungibile.
    • Disattivi la fatturazione del progetto, l'istanza viene arrestata.
    • Se automaticRestart non è configurato sull'istanza.
    • Si verifica un errore dell'host e Compute Engine non riesce a ricollegare i dischi all'istanza prima della scadenza del timeout. In questo caso, l'istanza viene riavviata senza recuperare i dischi SSD locali. Quando l'istanza viene riavviata, Compute Engine collega dischi SSD locali vuoti all'istanza riavviata. Devi formattare e montare questi dischi prima che l'istanza possa utilizzarli. I dati sui dischi SSD locali originali non sono recuperabili.

Google Cloud utilizza un approccio di tipo "best effort" per mantenere intatti i dati dell'SSD locale. Tuttavia, in alcuni casi i dati non possono essere recuperati, ad esempio in caso di timeout. Per saperne di più su quando i dischi SSD locali vengono conservati, consulta Persistenza dei dati dell'SSD locale.

Timeout del recupero degli SSD locali

Quando un'istanza con dischi SSD locali collegati entra nello REPAIRING stato, Compute Engine tenta di recuperare o conservare i dati dell'SSD locale. Durante questo periodo, l'istanza e i dischi SSD locali non sono disponibili.

Un'istanza entra nello stato REPAIRING e avvia il conto alla rovescia del timeout di recupero dell'SSD locale nei seguenti scenari:

  • Si verifica un errore dell'host.
  • Si verifica una manutenzione pianificata su un'istanza che supporta la persistenza dei dati dell'SSD locale dopo l'arresto e l'istanza è configurata sia per l'arresto in caso di manutenzione dell'host (onHostMaintenance impostato su TERMINATE) sia per il riavvio automatico (automaticRestart impostato su true). Durante la manutenzione, Compute Engine conserva i dati riavviando l'istanza in loco sullo stesso host o eseguendo la migrazione dell'istanza e dei relativi dati dell'SSD locale a un altro host mentre è arrestata.

Puoi controllare il tempo che Compute Engine dedica al tentativo di recuperare o conservare i dati con l'impostazione localSsdRecoveryTimeout della policy dell'host. Per impostazione predefinita, Compute Engine dedica 1 ora al recupero dei dati, ma i valori validi per questa impostazione sono compresi tra 0 e 168, con incrementi di 1 ora. I seguenti tipi di macchine hanno valori predefiniti diversi:

  • Tipi di macchine VM Z4D, Z4M e Z3: il valore predefinito è 6, il che significa che queste istanze tentano di recuperare i dati dell'SSD locale per 6 ore nello stato REPAIRING prima di raggiungere il limite di timeout.
  • Bare metal Z4M e bare metal Z3: il valore predefinito è 168 ore (7 giorni).

Se imposti il timeout di recupero dell'SSD locale su 0, Compute Engine non tenta di recuperare i dischi SSD locali collegati. L'istanza viene riavviata il prima possibile e i dati dell'SSD locale non sono recuperabili. Utilizza questa configurazione se la ripresa del carico di lavoro è più importante del recupero dei dati dell'SSD locale.

Se il timeout di recupero non è impostato su 0, ma viene raggiunto il limite di tempo prima del recupero dei dati dell'SSD locale, Compute Engine riavvia l'istanza senza il disco SSD locale. Compute Engine collega nuovi dischi SSD locali vuoti all'istanza riavviata. Devi formattare e montare questi dischi prima che l'istanza possa utilizzarli.

Se imposti il timeout di recupero dell'SSD locale sul valore massimo di 168, l'istanza rimane nello stato REPAIRING per un massimo di 7 giorni mentre Compute Engine tenta di recuperare i dischi SSD locali.

Non ti vengono addebitati costi per l'istanza mentre è nello stato REPAIRING, come descritto in Ciclo di vita dell'istanza VM.

Interrompi il recupero del disco SSD locale

Puoi interrompere la procedura di recupero del disco SSD locale prima che Compute Engine raggiunga il limite di timeout di recupero. Per farlo, utilizza il comando gcloud compute instances stop con il flag --discard-local-ssd=True.

Questo comando interrompe la procedura di recupero, arresta l'istanza di computing e ignora i dati dell'SSD locale. Puoi quindi riavviare l'istanza. Per saperne di più, consulta Arresta un'istanza con SSD locale.

Per impostare il timeout di recupero dell'SSD locale, consulta Imposta la policy di manutenzione dell'host dell'istanza.

Pianificazione della manutenzione

Google Cloud fornisce funzionalità che consentono un controllo più rigoroso della manutenzione. Utilizzando determinate famiglie di macchine, puoi specificare le preferenze di manutenzione e ricevere notifiche degli eventi di manutenzione imminenti tramite Cloud Logging, il server di metadati dell'istanza, il comando gcloud CLI compute instances describe o il metodo REST instances.describe. Dopo aver ricevuto una notifica, hai un periodo di tempo in cui puoi avviare la manutenzione pianificata in un momento a tua scelta. Se non attivi la manutenzione pianificata, l'evento di manutenzione si verifica alla fine del periodo di tempo della notifica, ovvero l'ora pianificata indicata nella notifica.

Puoi utilizzare queste funzionalità in combinazione con la policy di manutenzione dell'host per personalizzare una pianificazione della manutenzione adatta al tuo carico di lavoro.

Passaggi successivi