Informazioni sugli eventi host

Durante il ciclo di vita di un'istanza di macchina virtuale (VM) o bare metal, la macchina host su cui viene eseguita l'istanza può registrare più eventi host. Un evento host può includere la manutenzione regolare di Compute Engine dell'infrastruttura o, in rari casi, si tratta di un errore dell'host. Puoi scegliere come reagiscono le tue VM e le tue istanze bare metal durante o dopo un evento dell'host configurando il criterio di manutenzione dell'host.

Per impostazione predefinita, la maggior parte delle istanze è impostata sulla migrazione live durante organizzare eventi. Puoi ignorare questo comportamento e impostare esplicitamente le istanze in modo che si interrompano e, facoltativamente, si riavviino. Alcuni tipi di macchine non supportano la migrazione in tempo reale, ad esempio le istanze bare metal o le VM con GPU collegate. Questi le istanze si terminano durante gli eventi dell'host. Per ulteriori informazioni, consulta Comportamenti di manutenzione e riavvio.

Tipi di eventi host

Esistono due tipi di eventi host, descritti più dettagliatamente nella sezioni seguenti:

Se l'istanza non risponde, è possibile che venga attivato anche un riavvio o l'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 il trasferimento delle VM dal server host. Se attivi la migrazione live criterio di manutenzione dell'host per un tipo di istanza supportato, Compute Engine sposta l'istanza e l'interruzione dell'applicazione è minima.

Il comportamento dell'istanza durante un evento di manutenzione può variare a seconda del tenancy dell'istanza, nonché il tipo di macchina. La tabella seguente riassume il comportamento previsto per di manutenzione.

Tenancy dell'host Frequenza approssimativa degli eventi
di manutenzione		 Migrazione live supportata Selezione dell'organizzatore
Multi-tenant (condiviso) Ogni 2 settimane Sì Compute Engine
Single-tenant Ogni 4-6 settimane Dipende dal criterio di manutenzione dell'host Dipende dal criterio di manutenzione dell'host
X4 Minimo 90 giorni No Compute Engine
C3 Minimo 30 giorni No Compute Engine

Compute Engine applica inoltre alcuni upgrade di rete e hypervisor leggeri in background senza interruzioni mantenendo l'istanza sullo stesso host.

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 calcolo e che ne ha causato l'arresto anomalo. Un errore dell'host che coinvolge un guasto hardware totale o altri problemi hardware potrebbe impedire la migrazione live dell'istanza. Se l'istanza è impostata per il riavvio automatico, ovvero predefinita, Compute Engine riavvia l'istanza, in genere entro tre minuti dall'errore è stato rilevato. A seconda del problema, il riavvio potrebbe richiedere fino a 5,5 minuti.

A volte, un'istanza Compute 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 il recupero degli errori dell'host (anteprima). Per ulteriori informazioni, consulta Impostare i criteri di disponibilità.

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 potenzialmente disgregatori, consulta le seguenti risorse:

Google offre inoltre servizi gestiti come App Engine e Ambiente flessibile di App Engine.

Panoramica dei criteri di manutenzione dell'host

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

  • Evento di manutenzione
  • 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 su un altro host, scegli di arrestare l'istanza.

Puoi modificare lo stato di un'istanza criterio di manutenzione dell'host configurando le seguenti impostazioni:

  • Comportamento di manutenzione: indica se l'istanza è in fase di migrazione in tempo reale o è stata arrestata in caso di evento di manutenzione.
  • Comportamento al riavvio:indica se Compute Engine si riavvia o termina l'istanza se si arresta in modo anomalo, si verifica un errore dell'host o non risponde.
  • Tempo di rilevamento dell'errore dell'host: il tempo massimo che Compute Engine attende per riavviare o terminare un'istanza dopo aver rilevato che non risponde.
  • Tempo di recupero degli SSD locali:il tempo massimo in cui Compute Engine dedica il recupero dei dati sui dischi SSD locali ha rilevato un errore dell'host. I dati dell'unità SSD locale andranno persi se il tempo specificato scade senza che il recupero sia andato a buon fine.

Puoi aggiornare il criterio di manutenzione dell'host di un'istanza in qualsiasi momento per controllare come vuoi che si comportino le tue istanze.

Comportamenti di manutenzione e riavvio

Quando si verifica un evento host, l'istanza Compute può utilizzare la migrazione live, o la terminazione dell'istanza. Se un'istanza viene terminata, puoi scegliere di riavviarla autonomamente o di chiedere a Compute Engine di farlo automaticamente.

Le seguenti serie di macchine non supportano la migrazione live e vengono invece terminate durante gli eventi dell'host:

Migrazione live

Per impostazione predefinita, la maggior parte dei tipi di istanze è impostata su migrazione live, ad eccezione di:

  • Istanze con GPU e TPU collegate
  • Istanze bare metal C3 o X4
  • Istanze Z3

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

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

compute.instances.migrateOnHostMaintenance

Termina e riavvia

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 a Google Cloud di arrestare l'istanza quando si verifica un evento host. Con questa configurazione, se si verifica un evento host, Compute Engine invia un segnale di spegnimento graduale per arrestare l'istanza. Attende quindi 60 secondi affinché l'istanza si arresti correttamente e imposta lo stato dell'istanza su TERMINATED. Se l'istanza non si arresta correttamente in 60 secondi, viene terminata forzatamente.

Questa opzione è ideale se le tue istanze richiedono prestazioni sempre massime, e se l'applicazione nel suo complesso è progettata per gestire gli errori o i riavvii delle istanze.

Quando Compute Engine arresta un'istanza a causa di un evento dell'host, registra un evento di sistema che viene pubblicato nell'elenco delle operazioni di zona e nei log degli eventi di sistema. Puoi rivedere questo evento la visualizzazione delle operazioni di Compute Engine per una zona specifica. Gli eventi di terminazione dell'istanza hanno il seguente tipo di operazione:

compute.instances.terminateOnHostMaintenance

Riavvio automatico

Se l'istanza è configurata per arrestarsi in caso di evento di manutenzione o se si arresta in modo 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 riavvia l'istanza su un server host diverso nella stessa zona. Le istanze Z3 e X4 hanno tempi di attesa predefiniti diversi. Questi tipi di istanze vengono riavviati sullo stesso server host dopo l'interruzione dell'istanza.

Per configurare il riavvio automatico, imposta il campo del criterio di manutenzione dell'host Da automaticRestart a true. Questa impostazione non si applica se l'istanza è offline a causa di un'interruzione del servizio a livello di zona o per un'azione dell'utente, come chiamata sudo shutdown all'interno del sistema operativo guest.

Quando Compute Engine riavvia automaticamente l'istanza, segnala un evento di sistema pubblicato nell'elenco delle operazioni per 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 la terminazione dell'istanza

Poiché Persistent Disk e Hyperdisk sono archiviazione di rete, al riavvio dell'istanza, Compute Engine ricollega il disco di avvio e eventuali dischi secondari all'istanza. I dati su questi dischi vengono mantenuti la migrazione live e i riavvii delle istanze.

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

  • I dischi SSD locali vengono conservati se:

    • Configuri l'istanza per la migrazione live e l'istanza passa tramite 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 tempo.
    • Un'istanza di computing con dischi SSD locali collegati che supporta solo la terminazione e il riavvio automatico subisce un evento di manutenzione. L'istanza viene riavviata in situ, preservando i dati dell'unità SSD locale, anziché eseguire la migrazione a un nuovo host.

  • I dischi SSD locali non vengono conservati se:

    • Arresti il sistema operativo guest e forzi l'interruzione dell'istanza.
    • Configuri l'istanza in modo che venga arrestata in caso di eventi di manutenzione dell'host passa attraverso un evento di manutenzione dell'host.
    • 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. Al riavvio dell'istanza, Compute Engine collega dischi SSD locali vuoti all'istanza riavviata. Devi formattare e montare. prima che l'istanza possa utilizzarli. I dati sui dischi SSD locali originali non sono recuperabili.

Google Cloud si impegna a garantire che i dati dell'SSD locale rimangano invariati. Tuttavia, in alcuni casi i dati non possono essere recuperati, ad esempio in caso di timeout. Per ulteriori informazioni su quando i dischi SSD locali vengono conservata, consulta Persistenza dei dati degli SSD locali.

Timeout del ripristino degli SSD locali

Quando si verifica un errore dell'host, Compute Engine tenta di recuperare eventuali i dischi SSD collegati all'istanza. Puoi controllare il tempo impiegato da Compute Engine per tentare di recuperare i dati con l'impostazione localSsdRecoveryTimeout delle norme dell'host.

Per impostazione predefinita, Compute Engine impiega un'ora per recuperare i dati, ma i valori validi per questa impostazione sono compresi tra 0 e 168, con incrementi di 1 ora. Per le istanze Z3, il valore predefinito è 6, il che significa che le istanze Z3 tenteranno di recuperare i dati dell'SSD locale per 6 ore prima di raggiungere il limite di timeout.

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

Se il timeout del recupero non è impostato su 0, ma il limite di tempo viene raggiunto prima vengono recuperati i dati degli SSD locali, Compute Engine riavvia l'istanza senza il disco SSD locale. Collegamenti a Compute Engine nuovi dischi SSD locali vuoti sull'istanza riavviata. Devi formattare e montare questi prima che l'istanza possa utilizzarli.

L'istanza si trova in una classe REPAIRING mentre Compute Engine tenta di recuperare i dischi SSD locali. L'istanza e i dischi SSD locali non sono disponibili durante questo periodo.

Se imposti il timeout del 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.

Interrompi il ripristino del disco SSD locale

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

Questo comando arresta il processo di recupero, arresta l'istanza Compute e elimina i dati degli SSD locali. Puoi quindi riavviare l'istanza. Vedi Arrestare un'istanza con SSD locale per ulteriori informazioni.

Per impostare il timeout del recupero degli SSD locali, consulta Impostare il criterio di manutenzione dell'host dell'istanza.

Pianificazione della manutenzione

Google Cloud offre funzionalità che consentono un controllo più rigido sulla manutenzione. Utilizzando alcune famiglie di macchine, puoi specificare le preferenze di manutenzione e ricevere notifiche di manutenzione tramite Cloud Logging, il server di metadati dell'istanza, il comando compute instances describe dell'interfaccia a riga di comando gcloud CLI Metodo REST instances.describe. Al ricevimento di un notifica, hai un periodo di tempo in cui puoi avviare la manutenzione pianificata dell'oggetto in questione. Se non attivi la manutenzione pianificata, di manutenzione si verifica alla fine del periodo di tempo di notifica, ovvero all'orario programmato indicato nella notifica.

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

Passaggi successivi