Questo documento descrive in che modo un gruppo di istanze gestite (MIG) garantisce l'alta disponibilità dell'applicazione riparando le VM non funzionanti e non attive nel gruppo.
Un gruppo di istanze gestite mantiene la tua applicazione operativa e disponibile mantenendo in modo proattivo di VM in esecuzione nel gruppo. Se una VM del gruppo si arresta in modo anomalo, il gruppo di istanze gestite la ripara ricreandola nei seguenti modi per ripristinarla:
- Riparazione automatica di una VM non riuscita: se una VM non funziona o viene eliminata da un'azione non avviata dal gruppo di istanze gestite, il gruppo di istanze gestite ripara automaticamente la VM non riuscita. In questo documento, consulta Riparazione automatica di una VM non riuscita.
- Riparazione di una VM in base a un controllo di integrità dell'applicazione: un modo facoltativo per migliorare ulteriormente l'alta disponibilità riparando le VM non integre. Se configurerai un controllo di integrità basato sull'applicazione e la tua applicazione non supera il controllo di integrità, il gruppo di istanze gestite contrassegna la VM come non integra e la ripara. La riparazione di una VM in base a un controllo di integrità dell'applicazione è chiamata anche riparazione automatica. In questo documento, consulta Riparazione di una VM in base a un controllo di integrità dell'applicazione.
Ripara automaticamente una VM non riuscita
Se una VM in un gruppo di istanze gestite non funziona, il gruppo di istanze gestite la ripara automaticamente ricreandola. Una VM può generare un errore per i seguenti motivi:
- Motivi imprevisti, ad esempio un guasto hardware.
- Azioni non avviate dal gruppo di istanze gestite, ad esempio:
- Prenotazione di una VM spot.
- Eventi di manutenzione dell'infrastruttura se l'istanza VM non è impostata per la migrazione live.
- Azioni eseguite direttamente su una VM utilizzando la
pagina della console delle istanze VM,
instances
i comandi gcloud CLI o lainstances
risorsa API. Ad esempio, l'arresto di una VM nel gruppo utilizzando il metodoinstances.stop
o il comandogcloud compute instances stop
attiva la riparazione.
Se il gruppo di istanze gestite arresta intenzionalmente una VM, ad esempio quando un autoscaler ed elimina una VM, il gruppo di istanze gestite non la ripara.
Ripara una VM in base a un controllo di integrità dell'applicazione
Oltre alla riparazione automatica delle VM non riuscite, potresti voler riparare una VM se l'applicazione in esecuzione sulla VM si blocca, si arresta in modo anomalo o esaurisce la memoria. Per assicurarti che l'applicazione risponda come previsto, puoi: e configurare un controllo di integrità basato sull'applicazione.
Un controllo di integrità basato sull'applicazione verifica periodicamente che l'applicazione su ogni VM di un gruppo di istanze gestite risponda come previsto. Se l'applicazione su una VM non risponde, il gruppo di istanze gestite contrassegna la VM come non integra. Il gruppo di istanze gestite ripara quindi la VM non integra. La riparazione di una VM in base a un controllo di integrità dell'applicazione è chiamata riparazione automatica.
Per garantire che il gruppo di istanze gestite continui a eseguire un sottoinsieme delle sue VM, il gruppo non esegue mai contemporaneamente l'autocorrezione di tutte le sue VM. Questa opzione è utile se, ad esempio, un controllo di integrità non corretto attiva riparazioni non necessarie, un firewall configurato in modo errato impedisce che un controllo di integrità esegua il probe della VM, o se è presente una connettività di rete a problemi dell'infrastruttura che identificano erroneamente una VM in stato non integro. Tuttavia, se un gruppo di istanze gestite a livello di zona ha una sola VM oppure un gruppo di istanze gestite a livello di regione ha una sola VM per zona. corregge automaticamente queste VM quando non sono integri.
Norme sulla riparazione automatica
Ogni gruppo di istanze gestite ha un criterio di riparazione automatica in cui puoi configurare un controllo di integrità e
imposta anche un ritardo iniziale. Il ritardo iniziale è il tempo impiegato da una nuova VM
inizializzare ed eseguire lo script di avvio. Il timer del ritardo iniziale si avvia quando
Il gruppo di istanze gestite modifica il campo currentAction
della VM
su VERIFYING
. Durante il periodo di ritardo iniziale di una VM,
Il gruppo di istanze gestite ignora i controlli di integrità non riusciti perché la VM potrebbe essere in fase di avvio
e il processo di sviluppo. Questo impedisce al gruppo di istanze gestite di ricreare prematuramente una VM. Se il controllo di integrità riceve una risposta positiva durante il ritardo iniziale, indica che la procedura di avvio è completata e la VM è pronta.
Per ulteriori informazioni sulla configurazione di un criterio di riparazione automatica, consulta Configurare un controllo di integrità e la riparazione automatica dell'applicazione.
Monitora le modifiche dello stato di integrità dell'applicazione
Se hai configurato un controllo di integrità basato su applicazione nel tuo gruppo di istanze gestite, puoi controllare lo stato di integrità di ogni VM nel gruppo di istanze gestite. Per ulteriori informazioni, vedi Controlla se le VM sono integre.
Puoi anche monitorare i cambiamenti nello stato di integrità di una VM. Per ulteriori informazioni, vedi Monitorare le modifiche dello stato di integrità.
Prezzi
Quando configuri un controllo di integrità basato sull'applicazione, per impostazione predefinita Compute Engine scrive una voce di log ogni volta che lo stato di integrità di un'istanza gestita cambia. Cloud Logging fornisce una allocazione gratuita al mese, dopodiché e il prezzo del logging dipende dal volume di dati. Per evitare costi, puoi disattivare i log delle modifiche dello stato di integrità.
Comportamento durante una riparazione
Le seguenti sezioni spiegano il comportamento durante le riparazioni automatiche e di riparazioni basate sul controllo di integrità dell'applicazione.
Aggiornamento sulla riparazione
Per impostazione predefinita, durante una riparazione un gruppo di istanze gestite ricrea una VM utilizzando il modello di istanza originale utilizzato per crearla. Ad esempio, se una VM è stata creata utilizzando instance-template-a
e poi aggiorni il gruppo di istanze gestite in modo che utilizzi instance-template-b
in modalità OPPORTUNISTIC
, il gruppo di istanze gestite continuerà a utilizzare instance-template-a
per ricreare la VM.
Se vuoi che il gruppo di istanze gestite utilizzi il modello di istanza e le configurazioni per istanza più recenti durante la riparazione delle VM, puoi configurare il gruppo in modo da applicare gli aggiornamenti di configurazione durante le riparazioni.
Gestione dei dischi
Durante una riparazione, quando viene ricreata una VM in base al relativo modello, il gruppo di istanze gestite gestisce in modo diverso i diversi tipi di dischi. Alcune configurazioni dei dischi possono causare un fallimento della riparazione durante il tentativo di ricreare una VM.
Tipo di disco | autodelete |
Comportamento durante una riparazione |
---|---|---|
Nuovo disco permanente | true |
Il disco viene ricreato come specificato nel modello di istanza. Tutti i dati scritti su quel disco andranno persi quando il disco e la relativa VM vengono ricreati. |
Nuovo disco permanente | false |
Il disco viene conservato e ricollegato quando il gruppo di istanze gestite ricrea la VM. |
Disco permanente esistente | true |
Il disco precedente è stato eliminato. L'operazione di ricreazione della VM non riesce perché Compute Engine non può ricollegare un disco eliminato alla VM. Tuttavia, per i dischi di lettura/scrittura esistenti, un gruppo di istanze gestite può avere al massimo una VM perché un singolo disco permanente non può essere collegato a più VM in modalità di lettura/scrittura. |
Disco permanente esistente | false |
Il vecchio disco viene ricollegato come specificato nel modello dell'istanza. I dati sul disco vengono conservati. Tuttavia, per i dischi di lettura/scrittura esistenti, un gruppo di istanze gestite può avere al massimo una VM perché un singolo disco permanente non può essere collegato a più VM in modalità di lettura/scrittura. |
Nuova SSD locale | N/D | Il disco viene ricreato come specificato nel modello dell'istanza. I dati su un SSD locale vengono persi quando una VM viene ricreata o eliminata. |
Il gruppo MIG non ricollega i dischi non specificati nel modello di istanza o nelle configurazioni per istanza, ad esempio i dischi collegati manualmente a una VM dopo la sua creazione.
Per preservare i dati importanti scritti sul disco, prendi precauzioni, ad esempio:
- Esegui regolarmente snapshot dei dischi permanenti.
- Esportare i dati in un'altra origine, ad esempio Cloud Storage.
- Configura i dischi permanenti stateful.
Se le tue VM hanno impostazioni importanti che vuoi conservare, Google ti consiglia di utilizzare una immagine personalizzata nel modello di istanza. Un'immagine personalizzata contiene tutte le impostazioni personalizzate di cui hai bisogno. Quando specifichi un'immagine personalizzata nel tuo modello di istanza, il gruppo di istanze gestite ricrea le VM utilizzando l'immagine personalizzata che contiene le impostazioni personalizzate necessarie.
Disattivare le riparazioni
Puoi disattivare le riparazioni eseguite automaticamente da un gruppo di istanze gestite. Quando disattivi le riparazioni, vengono disattivate anche le riparazioni delle VM non riuscite e quelle basate su un controllo di integrità dell'applicazione.
Ti consigliamo di disattivare le riparazioni in un MIG in scenari come i seguenti:
- Per esaminare o eseguire il debug di una VM non riuscita senza interruzione della riparazione automatica.
- Per riparare manualmente le VM o implementare la tua logica di riparazione.
- Per impedire la registrazione di nuove VM mentre è in corso un job batch.
- Osservare gli stati di integrità delle applicazioni senza riparare una VM in stato non integro.
- Per perfezionare la configurazione del controllo di integrità senza attivare i falsi trigger. riparazioni.
Quando disattivi le riparazioni, il gruppo di istanze gestite non esegue alcuna azione se una VM nel gruppo
o non riesce
diventa insalubre. Le VM non riuscite e non integre continuano a far parte del gruppo e il numero target di VM in esecuzione nel gruppo di istanze gestite (targetSize
) rimane invariato.
Se il gruppo di istanze gestite
tipo di aggiornamento
è impostato su proactive
ed è disponibile un nuovo modello di istanza, il gruppo di istanze gestite
prova ad aggiornare le VM non riuscite e quelle in stato non integro.
Se hai configurato un controllo di integrità basato sull'applicazione, la disattivazione delle riparazioni non influisce sul funzionamento del controllo di integrità. La il controllo di integrità continua a testare l'applicazione e a fornire l'integrità della VM stati. In questo modo puoi monitorare gli stati di integrità dell'applicazione impedendo al gruppo di istanze gestite di riparare le VM non integre.
Se il gruppo di istanze gestite fa parte di un servizio di backend di un bilanciatore del carico e disattivi le riparazioni nel gruppo di istanze gestite, tutte le VM non riparate non riuscite o in stato non integro non rispondono al controllo di integrità del bilanciatore del carico. Se il numero di questi elementi non è andato a buon fine o in stato non integro nel gruppo di istanze gestite, il bilanciatore del carico potrebbe ridurre il traffico tramite il gruppo di istanze gestite o passare a un altro backend, se configurato. Quando le VM non riuscite diventano nuovamente disponibili, il bilanciatore del carico riprende il traffico verso il gruppo di istanze gestite.
Per maggiori informazioni, consulta Disattivare le riparazioni in un gruppo di istanze gestite.
Passaggi successivi
- Configura un controllo di integrità e la riparazione automatica basati sull'applicazione.
- Controlla se le riparazioni sono disattivate in un MIG.
- Applica gli aggiornamenti di configurazione durante le riparazioni.