Google Distributed Cloud è progettato per limitare l'ambito degli errori e per dare la priorità alle funzionalità essenziali per la continuità operativa. Questo documento spiega in che modo la funzionalità dei cluster viene interessata in caso di errore. Queste informazioni possono aiutarti a dare la priorità alle aree da risolvere in caso di problemi.
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 è l'aspetto più importante da considerare per mantenere la continuità aziendale. Anche se il cluster ha un problema, i carichi di lavoro esistenti potrebbero continuare a essere eseguiti senza interruzioni.
- Gestisci carichi di lavoro: puoi creare, aggiornare ed eliminare i carichi di lavoro. Questo è il secondo aspetto più importante da considerare per scalare i workload 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 è disponibile capacità sui nodi esistenti, l'impossibilità di modificare i cluster utente non influisce sui carichi di lavoro degli utenti.
- Gestisci cluster di amministrazione: puoi aggiornare ed eseguire l'upgrade del cluster di amministrazione. Questo è l'aspetto meno importante perché il cluster di amministrazione non ospita alcun carico di lavoro utente. Se il cluster di amministrazione presenta un problema, 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 sul rendimento 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 partizionato in rete.
| Esegui carichi di lavoro | Gestire i workload | 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 non funzionante vengono interrotti e vengono automaticamente riprogrammati su altre VM integre. Se le applicazioni utente hanno capacità di workload 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 control plane in un cluster utente non HA o su più di una VM del control plane in un cluster utente HA, si verifica un'interruzione. | Se l'errore dell'host influisce sulla VM del piano di controllo o sulle VM worker nel cluster di amministrazione, si verifica un'interruzione. | Se l'errore dell'host influisce sulla VM del control plane 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 HA per ridurre al minimo la possibilità di interruzioni. | Utilizza i cluster utente HA per ridurre al minimo la possibilità di interruzioni. | — | — |
Errore della VM
In questo scenario di errore, una VM potrebbe essere eliminata in modo imprevisto, un disco di avvio potrebbe danneggiarsi o una VM potrebbe essere compromessa a causa di problemi del sistema operativo.
| Esegui carichi di lavoro | Gestire i workload | 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 recupero manuale |
| Spiegazione | I pod in esecuzione sulle VM worker non riuscite vengono interrotti e vengono automaticamente riprogrammati su altre VM integre da Kubernetes. Se le applicazioni utente hanno capacità di workload di riserva e sono distribuite su più nodi, l'interruzione non è osservabile dai client che implementano i nuovi tentativi. |
Se la VM del control plane in un cluster utente non HA o più di una VM del control plane in un cluster utente HA 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 control plane nel cluster di amministrazione non funziona, si verifica un'interruzione. |
| Recupero | La VM con errori viene recuperata automaticamente se la riparazione automatica dei nodi è abilitata nel cluster utente. | La VM con errori 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 control plane del cluster di amministrazione, vedi Riparazione della VM del control plane del cluster di amministrazione. |
Per recuperare la VM del control plane del cluster di amministrazione, vedi Riparazione della VM del control plane del cluster di amministrazione. |
| Prevenzione | Esegui il deployment dei carichi di lavoro in modo HA per ridurre al minimo la possibilità di interruzioni. | Utilizza i cluster utente HA 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 dello spegnimento anomalo di una VM o un errore del datastore potrebbe causare la perdita dei dati etcd e dei PersistentVolumes (PV).
Errore etcd
| Esegui carichi di lavoro | Gestire i workload | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione | Nessuna interruzione | Possibile interruzione e ripristino manuale | Interruzione e recupero manuale | Interruzione e recupero manuale |
| Spiegazione | — | Se l'archivio etcd in un cluster utente non HA o più di una replica etcd in un cluster utente HA non va a buon fine, si verifica un'interruzione. | Se l'archivio etcd in un cluster utente non HA o più di una replica etcd in un cluster utente HA 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 il ripristino dall'errore. | Google Distributed Cloud fornisce una procedura manuale per il ripristino in seguito all'errore. | Google Distributed Cloud fornisce una procedura manuale per il ripristino in seguito all'errore. |
Errore PV dell'applicazione utente
| Esegui carichi di lavoro | Gestire i workload | 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 il PV non riuscito sono interessati. Esegui il deployment dei carichi di lavoro in modalità HA per ridurre al minimo la possibilità di interruzioni. |
— | — | — |
Errore del bilanciatore del carico
In questo scenario di errore, un errore del bilanciamento del carico potrebbe influire sui carichi di lavoro degli utenti
che espongono servizi di tipo LoadBalancer.
| Esegui carichi di lavoro | Gestire i workload | Gestione dei cluster utente | Gestione dei cluster di amministrazione | |
|---|---|---|---|---|
| Interruzione e recupero manuale | ||||
| Spiegazione |
Si verifica un'interruzione di alcuni secondi finché il bilanciatore del carico di standby non recupera la connessione VIP del control plane di amministrazione. 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'aumentare del numero di nodi del bilanciatore del carico. Con meno di 5 nodi, l'interruzione dura 10 secondi. |
|||
| Recupero | Seesaw HA rileva automaticamente l'errore e esegue il failover per utilizzare l'istanza di backup. Google Distributed Cloud fornisce una procedura manuale per il ripristino da un errore di Seesaw. |
|||
Recupero di un cluster danneggiato
Le sezioni seguenti descrivono come recuperare un cluster danneggiato.
Recupero da errori dell'host ESXi
Google Distributed Cloud si basa su vSphere HA per fornire il ripristino in caso di errore di un host ESXi. vSphere HA può monitorare continuamente gli host ESXi e riavviare automaticamente le VM su altri host quando necessario. Questo è trasparente per gli utenti di Google Distributed Cloud.
Recupero da errori della VM
Gli errori della 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 di spam.
Errore di avvio della VM dovuto a problemi di configurazione del disco o della rete a basse prestazioni, ad esempio la VM non può essere avviata perché non è possibile allocare un indirizzo IP.
Corruzione del file system di overlay Docker.
Perdita della VM del piano di controllo amministrativo a causa di un errore di upgrade.
Problemi del sistema operativo.
Google Distributed Cloud fornisce un meccanismo di recupero automatico per i nodi del componente aggiuntivo di amministrazione, i piani di controllo utente e i nodi utente. Questa funzionalità di riparazione automatica dei nodi può essere abilitata per cluster di amministrazione e cluster utente.
La VM del control plane amministrativo è speciale in quanto non è gestita da un cluster Kubernetes e la sua disponibilità non influisce sulla continuità operativa. Per il recupero degli errori della VM del control plane di amministrazione, contatta l'assistenza clienti Google Cloud.
Recupero 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 emergere dal livello vSphere causando il danneggiamento o la perdita di dati su vari componenti di Google Distributed Cloud.
Le informazioni stateful di un cluster e dei workload utente vengono archiviate nei seguenti luoghi:
- etcd: ogni cluster (cluster di amministrazione e cluster utente) ha un database etcd che archivia lo stato (oggetti Kubernetes) del cluster.
- PersistentVolumes: utilizzati sia dai componenti di sistema che dai carichi di lavoro degli utenti.
Recupero da danneggiamento o perdita dei dati etcd
etcd è il database utilizzato da Kubernetes per archiviare lo stato di tutti i 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 è danneggiato o perso. Le operazioni del ciclo di vita del cluster utente smetterebbero di funzionare se il database etcd del cluster di amministrazione è danneggiato o perso.
etcd non fornisce un meccanismo integrato affidabile per rilevare il danneggiamento dei dati. Devi esaminare i log dei pod etcd se sospetti che i dati etcd siano danneggiati o persi.
Un pod etcd in stato di attesa/errore/loop di arresto anomalo non sempre significa che i dati etcd sono danneggiati o persi. Potrebbe essere dovuto agli errori sulle VM che ospitano i pod etcd. Devi eseguire il seguente recupero di etcd solo in caso di danneggiamento o perdita dei dati.
Per poter eseguire il recupero (a uno stato recente del cluster) in caso di danneggiamento o perdita dei dati etcd, è necessario eseguire il backup dei dati etcd dopo qualsiasi operazione del 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 riporta il cluster a uno stato precedente. Se viene eseguito un backup prima del deployment di un'applicazione e poi questo backup 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 creato prima della creazione di un cluster utente, il control plane del cluster utente viene rimosso dal cluster di amministrazione ripristinato. Pertanto, ti consigliamo di eseguire il backup del cluster dopo ogni operazione critica.
Il danneggiamento o la perdita dei dati etcd può verificarsi nei seguenti scenari:
Un singolo nodo di un cluster etcd a tre nodi (cluster utente HA) è danneggiato in modo permanente a causa di danneggiamento o perdita di dati. In questo caso, è danneggiato un solo nodo e il quorum 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 alcuna perdita di dati sostituendo la replica etcd non riuscita con una nuova nello stato pulito. Per ulteriori informazioni, vedi Sostituzione di una replica etcd non riuscita.
Due nodi di un cluster etcd a tre nodi (cluster utente HA) sono danneggiati in modo permanente a causa di corruzione o perdita di dati. Il quorum è perso, quindi la sostituzione delle repliche etcd non riuscite con nuove non è utile. Lo stato del cluster deve essere ripristinato dai dati di backup. Per saperne di più, vedi Ripristinare un cluster utente da un backup (HA).
Un cluster etcd a un solo nodo (cluster di amministrazione o cluster utente non HA) è danneggiato in modo permanente a causa di danneggiamento o perdita di dati. Il quorum è perso, quindi devi creare un nuovo cluster dal backup. Per maggiori informazioni, vedi Ripristinare un cluster utente da un backup (non HA).
Recupero da danneggiamento o perdita di PV dell'applicazione utente
Puoi utilizzare determinate soluzioni di archiviazione partner per eseguire il backup e il ripristino dei PersistentVolume delle applicazioni utente. Per l'elenco dei partner di archiviazione qualificati per Google Distributed Cloud, consulta la pagina Partner di archiviazione GDC Ready.
Recupero dagli errori del bilanciatore del carico
Per il bilanciatore del carico di Seesaw in bundle, puoi eseguire il ripristino in caso di errori ricreando il bilanciatore del carico. Per ricreare il bilanciatore del carico, esegui l'upgrade di Seesaw alla stessa versione mostrata nella documentazione della versione 1.16 Upgrade del bilanciatore del carico per il cluster di amministrazione.
In caso di errori del bilanciatore del carico del cluster di amministrazione, il control plane potrebbe essere irraggiungibile. Esegui l'upgrade sulla VM del control plane di amministrazione 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, utilizza 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.
Passaggi successivi
Se hai bisogno di ulteriore assistenza, contatta l'assistenza clienti Google Cloud.
Puoi anche consultare la sezione Richiedere assistenza per ulteriori informazioni sulle risorse di assistenza, tra cui:
- Requisiti per l'apertura di una richiesta di assistenza.
- Strumenti per aiutarti a risolvere i problemi, come log e metriche.
- Componenti supportati, versioni e funzionalità di Google Distributed Cloud per VMware (solo software).