Google Distributed Cloud è progettato per limitare l'ambito degli errori e per dare priorità alla funzionalità fondamentale per la continuità aziendale. Questo documento spiega l'impatto in caso di errore sulla funzionalità dei cluster. Queste informazioni possono aiutarti a dare la priorità alle aree da risolvere in caso di problemi.
Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.La funzionalità di base di Google Distributed Cloud include le seguenti categorie:
- Esegui carichi di lavoro: i carichi di lavoro esistenti possono continuare a essere eseguiti. Questo è il fattore più importante per mantenere la continuità aziendale. Anche se il cluster presenta un problema, i carichi di lavoro esistenti potrebbero continuare a essere eseguiti senza interruzioni.
- Gestione dei carichi di lavoro: puoi creare, aggiornare ed eliminare i carichi di lavoro. Questa è la seconda considerazione più importante per scalare i carichi di lavoro quando il traffico aumenta, anche se il cluster ha un problema.
- Gestisci i cluster utente: puoi gestire i nodi, aggiornare, eseguire l'upgrade e l'eliminazione dei cluster utente. Questo aspetto è meno importante delle considerazioni sul ciclo di vita dell'applicazione. Se è disponibile capacità nei nodi esistenti, l'impossibilità di modificare i cluster utente non influisce sui carichi di lavoro degli utenti.
- Gestisci i cluster di amministrazione: puoi aggiornare il cluster di amministrazione ed eseguirne l'upgrade. Questa è la considerazione meno importante perché il cluster di amministrazione non ospita alcun carico di lavoro utente. Se si verifica un problema nel cluster di amministrazione, i carichi di lavoro dell'applicazione 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 sulle prestazioni dei cluster Google Distributed Cloud.
Errore host ESXi
In questo scenario di errore, un host ESXi che esegue istanze di macchine virtuali (VM) che ospitano nodi Kubernetes potrebbe smettere di funzionare o diventare partizionate nella rete.
| Esegui carichi di lavoro | Gestisci carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione | Possibile interruzione e ripristino automatico | Possibile interruzione e ripristino automatico | Interruzione e ripristino automatico | Interruzione e ripristino automatico |
| Spiegazione | I pod in esecuzione sulle VM ospitate dall'host in errore vengono interrotti e vengono ripianificati automaticamente su altre VM integre. Se le applicazioni utente hanno una capacità di carico di lavoro di riserva e sono distribuite su più nodi, l'interruzione non è osservabile dai client che implementano i nuovi tentativi. |
Se l'errore dell'host influisce sulla VM del piano di controllo in un cluster utente non ad alta disponibilità o su più di una VM del piano di controllo 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 su host integri. | vSphere HA riavvia automaticamente le VM su host integri. | vSphere HA riavvia automaticamente le VM su host integri. | vSphere HA riavvia automaticamente le VM su host integri. |
| Prevenzione | Esegui il deployment dei carichi di lavoro in modo ad alta disponibilità per ridurre al minimo le possibilità di interruzioni. | Utilizza i cluster utente ad alta disponibilità per ridurre al minimo le possibilità di interruzioni. | — | — |
Errore VM
In questo scenario di errore, una VM potrebbe essere eliminata in modo imprevisto, un disco di avvio potrebbe essere danneggiato o una VM potrebbe essere compromessa a causa di problemi del sistema operativo.
| Esegui carichi di lavoro | Gestisci carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione | Possibile interruzione e ripristino automatico | Possibile interruzione e ripristino automatico | Interruzione e ripristino automatico/manuale | Interruzione e ripristino manuale |
| Spiegazione | I pod in esecuzione sulle VM worker in stato di errore vengono interrotti e vengono ripianificati automaticamente su altre VM integre da Kubernetes. Se le applicazioni utente hanno una capacità di carico di lavoro di riserva e sono distribuite su più nodi, l'interruzione non è osservabile dai client che implementano i nuovi tentativi. |
In caso di errore della VM del piano di controllo in un cluster utente non ad alta disponibilità o di più di una VM del piano di controllo in un cluster utente ad alta disponibilità, si verifica un'interruzione. | In caso di errore della VM del piano di controllo o delle VM worker nel cluster di amministrazione, si verifica un'interruzione. | In caso di errore della VM del piano di controllo nel cluster di amministrazione, si verifica un'interruzione. |
| Recupero | La VM in errore viene recuperata automaticamente se la riparazione automatica dei nodi è abilitata nel cluster utente. | La VM in errore viene recuperata automaticamente se la riparazione automatica dei nodi è abilitata nel cluster di amministrazione. | La VM worker non riuscita 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, vedi Riparare la VM del piano di controllo del cluster di amministrazione. |
Per recuperare la VM del piano di controllo del cluster di amministrazione, vedi Riparare la 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 le possibilità di interruzioni. | Utilizza i cluster utente ad alta disponibilità per ridurre al minimo le possibilità di interruzioni. | — | — |
Errore di archiviazione
In questo scenario di errore, i contenuti di un file VMDK potrebbero essere danneggiati a causa dello spegnimento di una VM oppure un errore del datastore potrebbe causare la perdita di dati etcd e di PersistentVolume (PV).
errore etcd
| Esegui carichi di lavoro | Gestisci carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione | Nessuna interruzione | Possibile interruzione e recupero manuale | Interruzione e ripristino manuale | Interruzione e ripristino manuale |
| Spiegazione | — | Se l'archivio etcd in un cluster utente non ad alta disponibilità o più di una replica etcd in un cluster utente ad alta disponibilità ha esito negativo, si verifica un'interruzione. | Se l'archivio etcd in un cluster utente non ad alta disponibilità o più di una replica etcd in un cluster utente ad alta disponibilità ha esito negativo, si verifica un'interruzione. In caso di errore della replica etcd in un cluster di amministrazione, si verifica un'interruzione. |
In caso di errore della replica etcd in un cluster di amministrazione, si verifica un'interruzione. |
| Prevenzione | — | Google Distributed Cloud fornisce un processo manuale per ripristinare l'errore. | Google Distributed Cloud fornisce un processo manuale per il ripristino dall'errore. | Google Distributed Cloud fornisce un processo manuale per il ripristino dall'errore. |
Errore PV dell'applicazione utente
| Esegui carichi di lavoro | Gestisci carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione | Possibile interruzione | Nessuna interruzione | Nessuna interruzione | Nessuna interruzione |
| Spiegazione | Sono interessati i carichi di lavoro che utilizzano il volume permanente in errore. Esegui il deployment dei carichi di lavoro ad alta disponibilità per ridurre al minimo le possibilità di interruzioni. |
— | — | — |
Errore del bilanciatore del carico
In questo scenario di errore, un errore del bilanciatore del carico potrebbe interessare i carichi di lavoro degli utenti che espongono servizi di tipo LoadBalancer.
| Esegui carichi di lavoro | Gestisci carichi di lavoro | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione e ripristino manuale | ||||
| Spiegazione |
Si verificano alcuni secondi di interruzione prima che il bilanciatore del carico in standby recuperi la connessione VIP del piano di controllo dell'amministratore. 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 all'aumentare del numero di nodi del bilanciatore del carico. Con meno di 5 nodi, l'interruzione avviene entro 10 secondi. |
|||
| Recupero | L'alta disponibilità di Seesaw rileva automaticamente l'errore e non riesce a utilizzare l'istanza di backup. Google Distributed Cloud fornisce un processo manuale per il ripristino da un errore di Seesaw. |
|||
Recupero di un cluster danneggiato
Le sezioni seguenti descrivono come ripristinare un cluster danneggiato.
Ripristino da errori dell'host ESXi
Google Distributed Cloud si basa su vSphere HA per il ripristino da un guasto dell'host ESXi. vSphere HA può monitorare continuamente gli host ESXi e riavviare automaticamente le VM su altri host quando necessario. Ciò è trasparente per gli utenti di Google Distributed Cloud.
Ripristino da errori della VM
Gli errori della VM possono includere:
Eliminazione imprevista di una VM.
Danneggiamento del disco di avvio delle VM, ad esempio un disco di avvio che diventa di sola lettura a causa dei log del journal dello spam.
Errore di avvio della VM dovuto a problemi di configurazione della rete o del disco con prestazioni ridotte, ad esempio una VM che non può essere avviata perché non può essere allocata un indirizzo IP.
Danneggiamento del file system overlay Docker.
Perdita della VM del piano di controllo di amministrazione a causa di un errore di upgrade.
Problemi del sistema operativo.
Google Distributed Cloud fornisce un meccanismo di recupero automatico per i nodi dei componenti aggiuntivi di amministrazione, dei piani di controllo degli utenti e dei nodi utente. Questa funzionalità di riparazione automatica dei nodi può essere abilitata per cluster di amministrazione e cluster utente.
La VM del piano di controllo amministratore è speciale, nel senso che non è gestita da un cluster Kubernetes e la sua disponibilità non influisce sulla continuità aziendale. Per il ripristino degli errori delle VM del piano di controllo amministratore, contatta l'assistenza clienti Google Cloud.
Ripristino da errori di archiviazione
Alcuni degli errori di archiviazione possono essere limitati da vSphere HA e vSAN senza influire su Google Distributed Cloud. Tuttavia, alcuni errori di archiviazione potrebbero verificarsi a livello di vSphere, causando il danneggiamento o la perdita dei dati su vari componenti di Google Distributed Cloud.
Le informazioni stateful di un cluster e dei carichi di lavoro utente sono archiviate nei seguenti posti:
- etcd: ogni cluster (cluster di amministrazione e cluster utente) ha un database etcd in cui è archiviato lo stato (oggetti Kubernetes) del cluster.
- PersistentVolumes: utilizzati sia da componenti di sistema sia dai carichi di lavoro degli utenti.
Ripristino da danneggiamento o perdita dei dati etcd
etcd è il database utilizzato da Kubernetes per archiviare tutti gli stati del cluster, inclusi i manifest delle applicazioni utente. Le operazioni del ciclo di vita dell'applicazione smetteranno di funzionare se il database etcd del cluster utente viene danneggiato o smarrito. Le operazioni del ciclo di vita del cluster utente smetteranno di funzionare se il database etcd del cluster di amministrazione risulta danneggiato o smarrito.
etcd non fornisce un meccanismo integrato affidabile per il rilevamento del danneggiamento dei dati. Devi esaminare i log dei pod etcd se sospetti che i dati etcd siano danneggiati o persi.
Un pod etcd in attesa/errore/con arresto anomalo in loop non sempre indica che i dati etcd sono danneggiati o persi. Potrebbe essere dovuto agli errori sulle VM che ospitano i pod etcd. Devi eseguire il seguente ripristino etcd solo in caso di danneggiamento o perdita dei dati.
Per poter recuperare (in uno stato recente del cluster) da danneggiamento o perdita dei dati etcd, è necessario eseguire il backup dei dati etcd dopo qualsiasi operazione relativa al ciclo di vita nel cluster (ad esempio creazione, aggiornamento o upgrade). Per eseguire il backup dei dati etcd, vedi Backup di un cluster di amministrazione e Backup di un cluster utente.
Il ripristino dei dati etcd porta il cluster a uno stato precedente. Se viene eseguito un backup prima del deployment di un'applicazione e poi viene utilizzato per ripristinare il cluster, l'applicazione di cui è stato eseguito il deployment di recente non verrà eseguita nel cluster ripristinato. Ad esempio, se utilizzi lo snapshot etcd di un cluster di amministrazione di cui viene creato uno snapshot prima di creare un cluster utente, nel cluster di amministrazione ripristinato verrà rimosso il piano di controllo del cluster utente. Ti consigliamo quindi di eseguire il backup del cluster dopo ogni operazione critica.
L'errore di perdita o danneggiamento dei dati etcd può verificarsi nei seguenti scenari:
Un singolo nodo di un cluster a tre nodi etcd (cluster utente ad alta disponibilità) viene interrotto definitivamente a causa del danneggiamento o della perdita dei dati. In questo caso, un solo nodo non è funzionante ed esiste ancora il quorum etcd. Questo scenario potrebbe verificarsi in un cluster ad alta disponibilità, in cui i dati di una delle repliche etcd sono danneggiati o persi. Il problema può essere risolto senza alcuna perdita di dati sostituendo la replica etcd non riuscita con una nuova in stato pulito. Per maggiori informazioni, consulta Sostituzione di una replica etcd non riuscita.
Due nodi di un cluster a tre nodi etcd (cluster utente ad alta disponibilità) vengono interrotti definitivamente a causa di danneggiamento o perdita dei dati. Il quorum è perso, quindi sostituire le repliche etcd non riuscite con quelle nuove non aiuta. Lo stato del cluster deve essere ripristinato dai dati di backup. Per maggiori informazioni, consulta Ripristinare un cluster utente da un backup (HA).
Un cluster etcd a nodo singolo (cluster di amministrazione o cluster utente non ad alta disponibilità) viene interrotto definitivamente a causa di danneggiamento o perdita dei dati. Il quorum è stato perso, quindi devi creare un nuovo cluster dal backup. Per maggiori informazioni, consulta Ripristinare un cluster utente da un backup (non ad alta disponibilità).
Recupero da danneggiamento o perdita del PV dell'applicazione utente
Puoi utilizzare determinate soluzioni di archiviazione dei partner per eseguire il backup e il ripristino degli oggetti PersistentVolume dell'applicazione utente. Per l'elenco dei partner di archiviazione che sono stati qualificati per Google Distributed Cloud, consulta Partner di archiviazione Anthos Ready.
Ripristino da errori del bilanciatore del carico
Per il bilanciatore del carico di Seesaw in bundle, puoi ripristinare gli errori ricreando il bilanciatore del carico. Per ricreare il bilanciatore del carico, esegui l'upgrade di Seesaw alla stessa versione, come mostrato in 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 fuori portata. Esegui l'upgrade sulla VM del piano di controllo di amministrazione in cui si trova l'accesso al piano di controllo.
Per i bilanciatori del carico integrati (F5), contatta l'assistenza F5.
Per il bilanciatore del carico MetalLB in bundle, utilizza i nodi 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.