Google Distributed Cloud è progettato per limitare l'ambito degli errori e dare la priorità alle funzionalità fondamentali per la continuità aziendale. Questo documento spiega in che modo la funzionalità dei tuoi cluster è interessata in caso di errore. Queste informazioni possono aiutarti a stabilire le priorità delle aree da risolvere in caso di problemi.
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.Le funzionalità di base di Google Distributed Cloud includono le seguenti categorie:
- Esegui carichi di lavoro: i carichi di lavoro esistenti possono continuare a essere eseguiti. Questo è il considerazione più importante per mantenere la continuità aziendale. Anche se il cluster ha un problema, i carichi di lavoro esistenti potrebbero continuare a funzionare senza interruzione.
- Gestisci i carichi di lavoro: puoi creare, aggiornare ed eliminare i carichi di lavoro. Questo è il secondo aspetto più importante da considerare per scalare i carichi di lavoro quando il traffico aumenta, anche se il cluster ha un problema.
- Gestire i cluster utente: puoi gestire i nodi, aggiornare, eseguire l'upgrade ed eliminare i cluster utente. Questo aspetto è meno importante rispetto alle considerazioni sul ciclo di vita dell'applicazione. Se la capacità è disponibile sui nodi esistenti, l'impossibilità di modificare i cluster di utenti non influisce sui carichi di lavoro degli utenti.
- Gestisci i cluster di amministrazione: puoi aggiornare ed eseguire l'upgrade del cluster di amministrazione. Questa è la considerazione meno importante perché il cluster di amministrazione non ospita carichi di lavoro degli utenti. Se si verifica un problema con il cluster di amministrazione, i carichi di lavoro delle applicazioni continuano a essere eseguiti senza interruzioni.
Le sezioni seguenti utilizzano queste categorie di funzionalità di base per descrivere l'impatto di tipi specifici di scenari di errore.
Modalità di errore
I seguenti tipi di errori possono influire sul rendimento dei cluster Google Distributed Cloud.
Errore dell'host ESXi
In questo scenario di errore, un host ESXi che esegue istanze di macchine virtuali (VM) che ospitano i nodi Kubernetes potrebbe smettere di funzionare o diventare partizionato in rete.
| Esegui carichi di lavoro | Gestire i carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione | Possibile interruzione e recupero automatico | Possibile interruzione e recupero automatico | Interruzioni e ripristino automatico | Interruzioni e ripristino automatico |
| Spiegazione | I pod in esecuzione sulle VM ospitate dall'host non funzionante vengonointerrotti e riprogrammati automaticamente su altre VM in stato integro. Se le applicazioni utente dispongono di capacità di carico di lavoro di riserva e sono distribuite su più nodi, l'interruzione non è osservabile dai client che implementano i tentativi di nuovo invio. |
Se l'errore dell'host interessa la VM del control plane in un cluster utente non ad alta disponibilità o più di una VM del control plane in un cluster utente ad alta disponibilità, si verifica un'interruzione. | Se l'errore dell'host interessa la VM del piano di controllo o le VM worker nel cluster di amministrazione, si verifica un'interruzione. | Se l'errore dell'host interessa la VM del piano di controllo nel cluster di amministrazione, si verifica un'interruzione. |
| Recupero | vSphere HA riavvia automaticamente le VM sugli host integri. | vSphere HA riavvia automaticamente le VM sugli host integri. | vSphere HA riavvia automaticamente le VM sugli host integri. | vSphere HA riavvia automaticamente le VM sugli host integri. |
| Prevenzione | Esegui il deployment dei carichi di lavoro in modo ad alta disponibilità per ridurre al minimo la possibilità di interruzioni. | Utilizza cluster di utenti ad alta disponibilità per ridurre al minimo la possibilità di interruzioni. | — | — |
Errore della VM
In questo scenario di errore, una VM potrebbe essere eliminata inaspettatamente, un disco di avvio potrebbe essere danneggiato o una VM potrebbe essere compromessa a causa di problemi del sistema operativo.
| Esegui i carichi di lavoro | Gestire i carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione | Possibile interruzione e recupero automatico | Possibile interruzione e recupero automatico | Interruzioni e ripristino automatico/manuale | Interruzioni e recupero manuale |
| Spiegazione | I pod in esecuzione sulle VM worker non funzionanti vengono interrotti e Kubernetes li riprogramma automaticamente su altre VM funzionanti. Se le applicazioni utente dispongono di capacità di carico di lavoro di riserva e sono distribuite su più nodi, l'interruzione non è osservabile dai client che implementano i tentativi di nuovo invio. |
Se la VM del piano di controllo in un cluster utente non ad alta disponibilità o più di una VM del piano di controllo in un cluster utente ad alta disponibilità non funziona, si verifica un'interruzione. | Se la VM del piano di controllo o le VM worker nel cluster di amministrazione non funzionano, si verifica un'interruzione. | Se la VM del piano di controllo nel cluster di amministrazione non funziona, si verifica un'interruzione. |
| Recupero | La VM con errore viene recuperata automaticamente se la riparazione automatica dei nodi è abilitata nel cluster utente. | La VM con errore viene recuperata automaticamente se la riparazione automatica dei nodi è attivata nel cluster di amministrazione. | La VM worker non funzionante nel cluster di amministrazione viene recuperata automaticamente se la riparazione automatica dei nodi è abilitata nel cluster di amministrazione. Per recuperare la VM del piano di controllo del cluster di amministrazione, consulta Riparazione della VM del piano di controllo del cluster di amministrazione. |
Per recuperare la VM del piano di controllo del cluster di amministrazione, consulta Riparazione della VM del piano di controllo del cluster di amministrazione. |
| Prevenzione | Esegui il deployment dei carichi di lavoro in modo ad alta disponibilità per ridurre al minimo la possibilità di interruzioni. | Utilizza cluster di utenti ad alta disponibilità per ridurre al minimo la possibilità di interruzioni. | — | — |
Errore di archiviazione
In questo scenario di errore, i contenuti di un file VMDK potrebbero essere danneggiati a causa di un disinserimento non corretto di una VM oppure un errore del datastore potrebbe causare la perdita dei dati di etcd e dei PersistentVolume (PV).
Errore etcd
| Esegui carichi di lavoro | Gestire i carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione | Nessuna interruzione | Possibile interruzione e ripristino manuale | Interruzioni e recupero manuale | Interruzioni e recupero manuale |
| Spiegazione | — | Se lo spazio dati etcd in un cluster utente non ad alta disponibilità o più di una replica etcd in un cluster utente ad alta disponibilità non va a buon fine, si verifica un'interruzione. | Se lo spazio dati etcd in un cluster utente non ad alta disponibilità o più di una replica etcd in un cluster utente ad alta disponibilità non va a buon fine, si verifica un'interruzione. Se la replica etcd in un cluster di amministrazione non riesce, si verifica un'interruzione. |
Se la replica etcd in un cluster di amministrazione non riesce, si verifica un'interruzione. |
| Prevenzione | — | Google Distributed Cloud fornisce una procedura manuale per recuperare dall'errore. | Google Distributed Cloud fornisce una procedura manuale per recuperare dal fallimento. | Google Distributed Cloud fornisce una procedura manuale per recuperare dal fallimento. |
Errore PV dell'applicazione utente
| Esegui i carichi di lavoro | Gestire i carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione | Possibile interruzione | Nessuna interruzione | Nessuna interruzione | Nessuna interruzione |
| Spiegazione | I carichi di lavoro che utilizzano la PV non riuscita sono interessati. Esegui il deployment dei carichi di lavoro in modalità HA per ridurre al minimo la possibilità di interruzione. |
— | — | — |
Errore del bilanciatore del carico
In questo scenario di errore, un errore del bilanciatore del carico potrebbe influire sui carichi di lavoro degli utenti
che espongono servizi di tipo LoadBalancer.
| Esegui i carichi di lavoro | Gestire i carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzioni e recupero manuale | ||||
| Spiegazione |
Si verificano alcuni secondi di interruzione finché il bilanciatore del carico di riserva non recupera la connessione VIP del piano di controllo amministrativo. L'interruzione del servizio potrebbe durare fino a 2 secondi quando utilizzi Seesaw e fino a 300 secondi quando utilizzi F5. La durata dell'interruzione del failover di MetalLB aumenta con l'aumento del numero di nodi di bilanciamento del carico. Con meno di 5 nodi, l'interruzione avviene entro 10 secondi. |
|||
| Recupero | Seesaw HA rileva automaticamente l'errore e esegue il failover all'utilizzo dell'istanza di backup. Google Distributed Cloud fornisce una procedura manuale per recuperare da un errore di Seesaw. |
|||
Ripristino di un cluster danneggiato
Le sezioni seguenti descrivono come recuperare un cluster danneggiato.
Ripristino da guasti dell'host ESXi
Google Distributed Cloud si basa su vSphere HA per fornire il recupero da un errore dell'host ESXi. vSphere HA può monitorare continuamente gli host ESXi e riavviare automaticamente le VM su altri host, se necessario. Questo è trasparente per gli utenti di Google Distributed Cloud.
Ripristino da guasti delle VM
Gli errori delle VM possono includere:
Eliminazione imprevista di una VM.
Corruzione del disco di avvio della VM, ad esempio un disco di avvio che diventa di sola lettura a causa di log del journal dello spam.
Mancata attivazione della VM a causa di problemi di configurazione di rete o del disco a basso rendimento, ad esempio una VM che non può essere avviata perché non è possibile allocare un indirizzo IP.
Danneggiamento del file system overlay di Docker.
Perdita della VM del piano di controllo dell'amministratore a causa di un errore di upgrade.
Problemi relativi al sistema operativo.
Google Distributed Cloud fornisce un meccanismo di recupero automatico per i nodi aggiuntivi di amministrazione, i piani di controllo utente e i nodi utente. Questa funzionalità di riparazione automatica dei nodi può essere abilitata per i cluster di amministrazione e utente.
La VM del piano di controllo amministrativo è speciale nel senso che non è gestita da un cluster Kubernetes e la sua disponibilità non influisce sulla continuità aziendale. Per il recupero dei guasti delle VM del piano di controllo dell'amministratore, contatta l'assistenza clienti Google Cloud.
Ripristino da errori di archiviazione
Alcuni errori di archiviazione possono essere mitigati da vSphere HA e vSAN senza influire su Google Distributed Cloud. Tuttavia, alcuni errori di archiviazione potrebbero verificarsi a livello di vSphere causando la corruzione o la perdita di dati su vari componenti di Google Distributed Cloud.
Le informazioni con stato di un cluster e dei workload utente vengono archiviate nei seguenti punti:
- etcd: ogni cluster (cluster di amministrazione e cluster utente) ha un database etcd che memorizza lo stato (oggetti Kubernetes) del cluster.
- PersistentVolumes: utilizzati sia dai componenti di sistema sia dai carichi di lavoro degli utenti.
Ripristino da danneggiamento o perdita di dati etcd
etcd è il database utilizzato da Kubernetes per archiviare tutto lo stato del cluster, inclusi i manifest delle applicazioni utente. Le operazioni del ciclo di vita dell'applicazione smetterebbero di funzionare se il database etcd del cluster utente viene danneggiato o perso. Le operazioni del ciclo di vita del cluster utente smetterebbero di funzionare se il database etcd del cluster di amministrazione viene danneggiato o perso.
etcd non fornisce un meccanismo integrato affidabile per rilevare la corruzione dei dati. Devi esaminare i log dei pod etcd se sospetti che i dati di etcd siano stati danneggiati o persi.
Un pod etcd in attesa/con errori/in loop di arresto anomalo non indica sempre che i dati di etcd sono danneggiati o persi. Potrebbe essere dovuto a errori sulle VM che ospitano i pod etcd. Devi eseguire il seguente recupero di etcd solo in caso di danneggiamento o perdita di dati.
Per poter recuperare (in uno stato recente del cluster) i dati di etcd in caso di danneggiamento o perdita, è necessario eseguire il backup dei dati di etcd dopo qualsiasi operazione del ciclo di vita nel cluster (ad esempio creazione, aggiornamento o upgrade). Per eseguire il backup dei dati etcd, consulta Eseguire il backup di un cluster di amministrazione e Eseguire il backup di un cluster utente.
Il ripristino dei dati etcd riporta il cluster a uno stato precedente. Se viene eseguito un backup prima del deployment di un'applicazione e questo backup viene utilizzato per ripristinare il cluster, l'applicazione di recente implementata non verrà eseguita nel cluster ripristinato. Ad esempio, se utilizzi lo snapshot etcd di un cluster di amministrazione di cui è stato eseguito lo snapshot prima di creare un cluster utente, il control plane del cluster utente viene rimosso dal cluster di amministrazione ripristinato. Pertanto, consigliamo di eseguire il backup del cluster dopo ogni operazione critica del cluster.
L'errore di danneggiamento o perdita dei dati etcd può verificarsi nei seguenti scenari:
Un singolo nodo di un cluster etcd a tre nodi (cluster utente HA) è permanentemente guasto a causa di danneggiamento o perdita dei dati. In questo caso, è guasto un solo nodo e il quorum di etcd esiste ancora. Questo scenario potrebbe verificarsi in un cluster HA, in cui i dati di una delle repliche etcd sono danneggiati o persi. Il problema può essere risolto senza perdita di dati sostituendo la replica etcd non riuscita con una nuova in stato pulito. Per ulteriori informazioni, consulta Sostituzione di una replica etcd non riuscita.
Due nodi di un cluster etcd a tre nodi (cluster utente HA) sono permanentemente danneggiati a causa di una perdita o di un danneggiamento dei dati. Il quorum è andato perso, quindi la sostituzione delle repliche etcd non funzionanti con altre nuove non risolve il problema. Lo stato del cluster deve essere ripristinato dai dati di backup. Per ulteriori informazioni, consulta Ripristinare un cluster di utenti da un backup (HA).
Un cluster etcd a un nodo (cluster di amministrazione o cluster utente non HA) è stato danneggiato in modo permanente a causa di una perdita o di un danneggiamento dei dati. Il quorum è andato perso, quindi devi creare un nuovo cluster dal backup. Per ulteriori informazioni, consulta Ripristinare un cluster di utenti da un backup (non HA).
Recupero da danneggiamento o perdita di PV dell'applicazione utente
Puoi utilizzare determinate soluzioni di archiviazione dei partner per eseguire il backup e il ripristino dei volumi permanenti delle applicazioni degli utenti. Per l'elenco dei partner di archiviazione che sono stati idonei per Google Distributed Cloud, consulta Partner di archiviazione GDC Ready.
Ripristino da errori del bilanciatore del carico
Per il bilanciatore del carico Seesaw in bundle, puoi recuperare dagli errori ricreando il bilanciatore del carico. Per ricreare il bilanciatore del carico, esegui l'upgrade di Seesaw alla stessa versione indicata nella documentazione della versione 1.16 Eseguire l'upgrade del bilanciatore del carico per il cluster di amministrazione.
In caso di errori del bilanciatore del carico del cluster di amministrazione, il piano di controllo potrebbe essere irraggiungibile. Esegui l'upgrade sulla VM del piano di controllo amministrativo in cui è presente l'accesso al control plane.
Per i bilanciatori del carico integrati (F5), contatta l'assistenza F5.
Per il bilanciatore del carico MetalLB in bundle, vengono utilizzati i nodi del cluster come bilanciatori del carico. La riparazione automatica dei nodi non viene attivata in caso di problemi del bilanciatore del carico. Puoi seguire la procedura manuale per riparare il nodo.