Questa pagina descrive le opzioni a tua alta disponibilità (HA) in Cluster Anthos su VMware (GKE On-Prem), come configurare alcuni componenti Cluster Anthos su VMware per l'alta disponibilità e come eseguire il ripristino in caso di emergenza.
Funzionalità di base
Cluster Anthos su VMware include un cluster di amministrazione e uno o più cluster utente.
Il cluster di amministrazione gestisce il ciclo di vita dei cluster utente, inclusi creazione, aggiornamenti, upgrade ed eliminazione dei cluster utente. Nel cluster di amministrazione, il master di amministrazione gestisce i nodi worker amministrativi, che includono i master degli utenti (nodi che eseguono il piano di controllo dei cluster utente gestiti) e i nodi dei componenti aggiuntivi (nodi che eseguono i componenti aggiuntivi che supportano la funzionalità del cluster di amministrazione).
Per ogni cluster utente, il cluster di amministrazione ha un nodo non ad alta disponibilità o tre nodi ad alta disponibilità che eseguono il piano di controllo. Il piano di controllo include il server API Kubernetes, lo scheduler Kubernetes, il controller Controller Kubernetes e diversi controller critici per il cluster utente.
La disponibilità del piano di controllo del cluster utente è fondamentale per le operazioni del carico di lavoro, ad esempio la creazione, il scale up e lo scale down del carico di lavoro e la terminazione. In altre parole, un'interruzione del piano di controllo non interferisce con i carichi di lavoro in esecuzione, ma i carichi di lavoro esistenti perdono le funzionalità di gestione dal server API di Kubernetes se il relativo piano di controllo è assente.
Il deployment dei carichi di lavoro e dei servizi containerizzati viene eseguito nei nodi worker del cluster utente. Qualsiasi nodo worker non deve essere critico per la disponibilità dell'applicazione, a condizione che venga eseguito il deployment dell'applicazione con pod ridondanti pianificati su più nodi worker.
I cluster Anthos su VMware sono progettati per garantire che gli errori vengano isolati il più possibile in un'area funzionale e che diano la priorità alle funzionalità critiche per la continuità aziendale.
La funzionalità di base di Cluster Anthos su VMware include le seguenti categorie:
Ciclo di vita delle applicazioni
I carichi di lavoro esistenti possono essere eseguiti di continuo. Questa è la funzionalità più importante per garantire la continuità aziendale.
Puoi creare, aggiornare ed eliminare i carichi di lavoro. Questa è la seconda funzionalità più importante perché Cluster Anthos su VMware deve scalare i carichi di lavoro quando il traffico aumenta.
Ciclo di vita del cluster utente
Puoi aggiungere, aggiornare, eseguire l'upgrade ed eliminare i cluster utente. Questo aspetto è meno importante perché l'impossibilità di modificare i cluster utente non influisce sui carichi di lavoro degli utenti.
Ciclo di vita del cluster di amministrazione
Puoi aggiornare ed eseguire l'upgrade del cluster di amministrazione. Questo è il meno importante perché il cluster di amministrazione non ospita carichi di lavoro degli utenti.
Modalità di errore
I seguenti tipi di errore possono influire sulle prestazioni dei cluster Anthos sui cluster VMware.
Errore host ESXi
Un host ESXi che esegue istanze di macchine virtuali (VM) che ospitano nodi Kubernetes potrebbe non funzionare più o diventare partizionato della rete.
| Carichi di lavoro esistenti | Creazione, aggiornamento ed eliminazione dei carichi di lavoro | Ciclo di vita del cluster utente | Ciclo di vita del cluster di amministrazione |
|---|---|---|---|
| Possibile interruzione + ripristino automatico |
Possibile interruzione + ripristino automatico |
Interruzione + ripristino automatico |
Interruzione + ripristino automatico |
I pod in esecuzione sulle VM ospitate dall'host non riuscito vengono interrotti e ripianificati automaticamente su altre VM integre. Se le applicazioni degli utenti 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 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 piano di controllo nel cluster di amministrazione, si verifica un'interruzione. |
| 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. |
| Esegui il deployment dei carichi di lavoro in modo da ridurre al minimo la possibilità di interruzioni. | Utilizza i cluster utente ad alta disponibilità per ridurre al minimo la possibilità di interruzioni. |
Errore della VM
Una VM potrebbe essere eliminata in modo imprevisto o un disco di avvio potrebbe danneggiarsi. Inoltre, una VM potrebbe essere compromessa a causa di problemi del sistema operativo.
| Carichi di lavoro esistenti | Creazione, aggiornamento ed eliminazione dei carichi di lavoro | Ciclo di vita del cluster utente | Ciclo di vita del cluster di amministrazione |
|---|---|---|---|
| Possibile interruzione + ripristino automatico |
Possibile interruzione + ripristino automatico |
Interruzione + ripristino automatico/manuale |
Interruzione + ripristino manuale |
I pod in esecuzione sulle VM worker non riuscite vengono interrotti e ripianificati automaticamente su altre VM integre da Kubernetes. Se le applicazioni degli utenti hanno 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 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 riesce, 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. | Se la VM del piano di controllo nel cluster di amministrazione ha esito negativo, si verifica un'interruzione. |
| La VM non riuscita viene recuperata automaticamente se nel cluster utente è abilitata la riparazione automatica dei nodi. | La VM non riuscita 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 Riparazione delle VM del piano di controllo del cluster di amministrazione. |
Per recuperare la VM del piano di controllo del cluster di amministrazione, vedi Riparazione delle VM del piano di controllo del cluster di amministrazione. |
| Esegui il deployment dei carichi di lavoro in modo da ridurre al minimo la possibilità di interruzioni. | Utilizza i cluster utente ad alta disponibilità per ridurre al minimo la possibilità di interruzioni. |
Errore di archiviazione
Il contenuto di un file VMDK potrebbe essere danneggiato a causa di un arresto anomalo della VM, oppure un errore del datastore potrebbe causare la perdita dei dati etcd e dei PersistentVolume (PV).
errore etcd
| Carichi di lavoro esistenti | Creazione, aggiornamento ed eliminazione dei carichi di lavoro | Ciclo di vita del cluster utente | Ciclo di vita del cluster di amministrazione |
|---|---|---|---|
| Nessuna interruzione | Possibile interruzione + Ripristino manuale |
Interruzione + Ripristino manuale |
Interruzione + Ripristino manuale |
| 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à non riesce, 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à non riesce, si verifica un'interruzione. Se la replica etcd in un cluster di amministrazione ha esito negativo, si verifica un'interruzione. |
Se la replica etcd in un cluster di amministrazione ha esito negativo, si verifica un'interruzione. | |
| I cluster Anthos su VMware forniscono un processo manuale per il ripristino dall'errore. | Cluster Anthos su VMware fornisce un processo manuale per il ripristino dall'errore. | Cluster Anthos su VMware fornisce un processo manuale per il ripristino dall'errore. |
Errore PV dell'applicazione utente
| Carichi di lavoro esistenti | Creazione, aggiornamento ed eliminazione dei carichi di lavoro | Ciclo di vita del cluster utente | Ciclo di vita del cluster di amministrazione |
|---|---|---|---|
| Possibile interruzione | Nessuna interruzione | Nessuna interruzione | Nessuna interruzione |
Sono interessati i carichi di lavoro che utilizzano il volume permanente non riuscito. Esegui il deployment dei carichi di lavoro nell'alta disponibilità per ridurre al minimo la possibilità di interruzioni. |
Errore del bilanciatore del carico
Un errore del bilanciatore del carico potrebbe interessare i carichi di lavoro degli utenti che espongono servizi di tipo LoadBalancer.
| Carichi di lavoro esistenti | Creazione, aggiornamento ed eliminazione dei carichi di lavoro | Ciclo di vita del cluster utente | Ciclo di vita del cluster di amministrazione |
|---|---|---|---|
| Interruzione + Ripristino manuale |
|||
|
Prima che il bilanciatore del carico in standby recuperi la connessione VIP del piano di controllo amministratore, mancano alcuni secondi. 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 di pari passo con l'aumento del numero di nodi del bilanciatore del carico. Con meno di 5 nodi, l'interruzione avviene entro 10 secondi. Seesaw HA rileva automaticamente l'errore e esegue il failover utilizzando l'istanza di backup. I cluster Anthos su VMware forniscono un processo manuale per il ripristino da un errore di Seesaw. |
|||
Abilitazione dell'alta disponibilità in corso...
I cluster vSphere e Anthos su VMware forniscono una serie di funzionalità che contribuiscono all'alta disponibilità (HA).
vSphere HA e vMotion
Ti consigliamo di abilitare le due funzionalità seguenti nel cluster vCenter, che ospitano i tuoi cluster Anthos su cluster VMware:
Queste funzionalità migliorano la disponibilità e il recupero in caso di errore di un host ESXi.
vCenter HA utilizza più host ESXi configurati come cluster per fornire
il ripristino rapido dalle interruzioni e un'alta disponibilità economica per le applicazioni
in esecuzione nelle macchine virtuali. Ti consigliamo di eseguire il provisioning del cluster vCenter con host aggiuntivi e di abilitare il monitoraggio dell'host vSphere HA con Host Failure Response impostato su Restart VMs. Le VM possono quindi essere riavviate automaticamente su altri host disponibili in caso di errore host ESXi.
vMotion consente la migrazione live delle applicazioni da un host ESXi a un altro tempo di inattività. Per la manutenzione pianificata dell'host, puoi utilizzare la migrazione live di vMotion per evitare del tutto i tempi di inattività delle applicazioni e garantire la continuità aziendale.
Cluster di amministrazione
Cluster Anthos su VMware non supporta l'esecuzione di più piani di controllo per il cluster di amministrazione. Tuttavia, la mancata disponibilità del piano di controllo dell'amministratore non influisce sulla funzionalità dei cluster utente esistenti o sui carichi di lavoro in esecuzione nei cluster utente.
In un cluster di amministrazione esistono due nodi aggiuntivi. Se uno non è attivo, l'altro può comunque gestire le operazioni del cluster di amministrazione. Per la ridondanza, Cluster Anthos su VMware diffonde i servizi aggiuntivi dei componenti aggiuntivi, come kube-dns, in entrambi i nodi dei componenti aggiuntivi.
Se imposti antiAffinityGroups.enabled su true nel file di configurazione del cluster di amministrazione, Cluster Anthos su VMware crea automaticamente le regole di anti-affinità vSphere DRS per i nodi dei componenti aggiuntivi, in modo da distribuirli su due host fisici per l'alta disponibilità.
Cluster utente
Puoi abilitare l'alta disponibilità per un cluster utente impostando masterNode.replicas su 3 nel file di configurazione del cluster utente. Questo comporta tre nodi nel cluster di amministrazione, ognuno dei quali esegue un piano di controllo per il cluster utente. Ciascuno di questi nodi esegue anche una replica etcd. Il cluster utente continua a funzionare finché esiste un piano di controllo in esecuzione e un quorum etcd. Un quorum etcd
richiede che due delle tre repliche etcd funzionino.
Se imposti antiAffinityGroups.enabled su true nel file di configurazione del cluster di amministrazione, Cluster Anthos su VMware crea automaticamente regole di anti-affinità vSphere DRS per i tre nodi che eseguono il piano di controllo del cluster utente.
Di conseguenza, queste VM sono distribuite tra tre host fisici.
I cluster Anthos su VMware creano anche regole anti-affinità DRS per i nodi worker nel cluster utente, in modo che i nodi vengano distribuiti su almeno tre host fisici. Vengono utilizzate più regole anti-affinità DRS per pool di nodi del cluster utente, in base al numero di nodi. Questo garantisce che i nodi worker possano trovare host su cui eseguire gli elementi, anche quando il numero di host è inferiore al numero di VM nel pool di nodi del cluster utente. Ti consigliamo di includere host fisici aggiuntivi nel cluster vCenter. Configura inoltre i DRS in modo che siano completamente automatizzati, in modo che un host non sia più disponibile, in modo che possa riavviarlo automaticamente su altri host disponibili senza violare le regole di anti-affinità delle VM.
I cluster Anthos su VMware mantengono un'etichetta speciale del nodo, onprem.gke.io/failure-domain-name, il cui valore è impostato sul nome host ESXi sottostante. Le applicazioni utente che vogliono un'alta disponibilità possono configurare podAntiAffinity regole con questa etichetta come topologyKey per assicurarsi che i relativi pod dell'applicazione siano distribuiti su VM diverse e host fisici.
Puoi anche configurare più pool di nodi per un cluster utente con datastore diversi ed etichette speciali dei nodi. Analogamente, puoi configurare podAntiAffinity regole con l'etichetta speciale del nodo topologyKey per ottenere una maggiore disponibilità in caso di errori del datastore.
Per avere alta disponibilità per i carichi di lavoro degli utenti, assicurati che il cluster utente abbia un numero sufficiente di repliche in nodePools.replicas, che garantisce il numero desiderato di nodi worker del cluster utente in esecuzione.
Puoi utilizzare datastore separati per i cluster di amministrazione e i cluster utente per isolare i propri errori.
Bilanciatore del carico
Esistono due tipi di bilanciatori del carico che puoi utilizzare per l'alta disponibilità.
Bilanciatore del carico MetalLB in bundle
Per il
bilanciatore del carico MetalLB in bundle,
puoi ottenere alta disponibilità grazie alla presenza di più nodi con enableLoadBalancer: true.
MetalLB distribuisce i servizi sui nodi del bilanciatore del carico, ma per un singolo servizio è presente un solo nodo leader che gestisce tutto il traffico per quel servizio.
Durante l'upgrade del cluster, si verifica un tempo di inattività durante l'upgrade dei nodi del bilanciatore del carico. La durata dell'interruzione del failover di MetalLB aumenta di pari passo con l'aumento del numero di nodi del bilanciatore del carico. Con meno di 5 nodi, l'interruzione avviene entro 10 secondi.
Bilanciatore del carico di Seesaw in bundle
Per il bilanciatore del carico di Seesaw in bundle, puoi abilitare l'alta disponibilità impostando loadBalancer.seesaw.enableHA su true nel file di configurazione del cluster.
Devi anche abilitare una combinazione di apprendimento MAC, trasmissioni falsificate e modalità promiscua sul gruppo di porte del bilanciatore del carico.
Con l'alta disponibilità, due bilanciatori del carico sono configurati in modalità passiva attiva. Se il bilanciatore del carico attivo presenta un problema, il traffico non riesce a raggiungere il bilanciatore del carico passivo.
Durante l'upgrade di un bilanciatore del carico si verifica un tempo di inattività. Se l'alta disponibilità è abilitata per il bilanciatore del carico, il tempo di inattività massimo è di due secondi.
Bilanciatore del carico BIG-IP integrato F5
La piattaforma F5 BIG-IP fornisce vari servizi per aiutarti a migliorare la sicurezza, la disponibilità e le prestazioni delle tue applicazioni. Per Cluster Anthos su VMware, BIG-IP fornisce servizi di bilanciamento del carico con accesso esterno e L3/4.
Per ulteriori informazioni, consulta la pagina sulla alta disponibilità di BIG-IP.
Recupero di un cluster non funzionante
Le sezioni seguenti descrivono come recuperare un cluster non funzionante.
Ripristino da errori dell'host ESXi
Cluster Anthos su VMware si basa su vSphere HA per fornire il ripristino da un errore dell'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 Cluster Anthos su VMware.
Ripristino dagli errori delle VM
Gli errori relativi alla VM possono includere quanto segue:
Eliminazione imprevista di una VM.
danneggiamento del disco di avvio della VM; ad esempio, un disco di avvio è diventato di sola lettura a causa dei log del journal dello spam.
Errore di avvio della VM a causa di problemi di configurazione della rete o del disco a prestazioni basse. Ad esempio, una VM non può essere avviata perché non può essere allocato un indirizzo IP per qualche motivo.
i file system in overlay Docker.
Perdita della VM del piano di controllo dell'amministratore a causa di un errore di upgrade.
Problemi relativi al sistema operativo.
Gli errori della VM illustrati in questa sezione non includono il danneggiamento o la perdita di dati sui dischi dati PV o etcd collegati alla VM. Per ulteriori informazioni, consulta la pagina Ripristino dagli errori di archiviazione.
Cluster Anthos su VMware fornisce un meccanismo di recupero automatico per i nodi di componenti aggiuntivi amministrativi, i piani di controllo degli utenti e i 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 amministrativo è speciale, in quanto non è gestita da un cluster Kubernetes e la sua disponibilità non influisce sulla continuità aziendale. Per il recupero degli errori VM del piano di controllo amministrativo, contatta l'Assistenza Google.
Ripristino da errori di archiviazione
Alcuni degli errori di archiviazione possono essere mitigati da vSphere HA e vSAN senza influire sui cluster Anthos su VMware. Tuttavia, alcuni errori di archiviazione potrebbero essere visualizzati dal livello vSphere a causa del danneggiamento o della perdita di dati sui vari componenti Cluster Anthos su VMware.
Le informazioni stateful di un cluster e dei carichi di lavoro degli utenti sono archiviate nelle seguenti posizioni:
etcd
Ogni cluster (cluster di amministrazione e cluster utente) dispone di un database etcd che archivia lo stato (oggetti Kubernetes) del cluster.
I PersistentVolume forniscono
Utilizzato sia dai componenti di sistema sia dai carichi di lavoro degli utenti.
Recupero da danni o perdita di dati etcd
etcd è il database utilizzato da Kubernetes per archiviare tutti gli stati del cluster, inclusi i manifest dell'applicazione utente. Le operazioni del ciclo di vita dell'applicazione smetterebbero di funzionare se il database etcd del cluster utente è danneggiato o smarrito. Le operazioni del ciclo di vita dei cluster utente smetteranno di funzionare se il database etcd del cluster di amministrazione è danneggiato o smarrito.
etcd non fornisce un meccanismo affidabile integrato per rilevare il danneggiamento dei dati. Devi guardare i log dei pod etcd se sospetti che i dati etcd siano danneggiati o persi.
Un pod etcd/losh-looping etcd non sempre indica che i dati etcd siano corrotti o persi. Il problema potrebbe essere dovuto agli errori nelle VM che ospitano i pod etcd. Esegui il seguente ripristino etcd solo per il danneggiamento o la perdita di dati.
Per poter ripristinare (in uno stato recente del cluster) la corruzione o la perdita di dati etcd, è necessario eseguire il backup dei dati etcd dopo ogni operazione del ciclo di vita nel cluster (ad esempio, creazione, aggiornamento o upgrade). Per effettuare il backup dei dati etcd, consulta Backup di un cluster di amministrazione e Backup di un cluster utente.
Il ripristino dei dati etcd ripristina lo stato precedente del cluster. In altre parole, se viene eseguito un backup prima che venga eseguito il deployment di un'applicazione e questo viene utilizzato per ripristinare il cluster, l'applicazione non sarà in esecuzione nel cluster ripristinato. Ad esempio, se utilizzi lo snapshot etcd di un cluster di amministrazione con snapshot prima della creazione di un cluster utente, il cluster di controllo del cluster utente viene rimosso dal piano di controllo del cluster utente. Pertanto, ti consigliamo di eseguire il backup del cluster dopo ogni operazione critica del cluster.
Il danneggiamento o la perdita di dati etcd può verificarsi nei seguenti casi:
Un singolo nodo di un cluster etcd a tre nodi (cluster di utenti HA) non funziona correttamente a causa di danneggiamento o perdita di dati. In questo caso, un solo nodo è inaccessibile e esiste ancora il quorum etcd. Questo 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 ulteriori informazioni, consulta la sezione Sostituzione di una replica etcd non riuscita.
Due nodi di un cluster etcd a tre nodi (cluster di utenti ad alta disponibilità) si rompono definitivamente a causa di danneggiamento o perdita di dati. Il quorum viene perso, quindi la sostituzione delle repliche etcd non riuscite con nuove repliche non è utile. Lo stato del cluster deve essere ripristinato dai dati di backup. Per ulteriori informazioni, consulta la sezione Ripristinare un cluster utente da un backup (HA).
Un cluster etcd a nodo singolo (cluster di amministrazione o cluster utente non HA) è danneggiato in modo permanente a causa di danneggiamento o perdita di dati. Il quorum viene perso, quindi devi creare un nuovo cluster dal backup. Per ulteriori informazioni, consulta la sezione Ripristinare un cluster utente da un backup (non ad alta disponibilità).
Ripristino da danneggiamento o perdita di dati PV delle applicazioni utente
I clienti di Cluster Anthos su VMware possono utilizzare determinate soluzioni di archiviazione dei partner per eseguire il backup e ripristinare gli oggetti PersistentVolume dell'applicazione utente.
Per l'elenco dei partner di archiviazione idonei per Cluster Anthos su VMware, consulta Anthos Ready Storage Partners.
Ripristino dagli errori del bilanciatore del carico
Per il bilanciatore del carico di 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 in Eseguire l'upgrade del bilanciatore del carico per il cluster di amministrazione.
Nel caso di errori del bilanciatore del carico del cluster di amministrazione, il piano di controllo potrebbe non essere raggiungibile. Di conseguenza, devi eseguire l'upgrade sulla VM del piano di controllo amministratore, in cui è presente l'accesso al piano di controllo.
Per i bilanciatori del carico integrati (F5), consulta l'assistenza F5.
Per il bilanciatore del carico MetalLB in bundle, utilizza nodi cluster come bilanciatori del carico. La riparazione automatica dei nodi non viene attivata per problemi del bilanciatore del carico. Puoi seguire la procedura manuale per riparare il nodo.
Utilizzo di più cluster per il ripristino di emergenza
Il deployment di applicazioni in più cluster su più vCenter o piattaforme Anthos può fornire una disponibilità globale più elevata e limitare il raggio di esplosione durante le interruzioni.
Questa configurazione utilizza il cluster Anthos esistente nel data center secondario per il ripristino di emergenza anziché la configurazione di un nuovo cluster. Di seguito è riportato un riepilogo di alto livello per ottenere questo risultato:
Creare un altro cluster di amministrazione e un cluster utente nel data center secondario. In questa architettura multi-cluster, richiediamo agli utenti di avere due cluster di amministrazione in ogni data center e ogni cluster di amministrazione esegue un cluster utente.
Il cluster utente secondario ha un numero minimo di nodi worker (tre) ed è un hot standby (sempre in esecuzione).
I deployment delle applicazioni possono essere replicati tra i due vCenter utilizzando Anthos Config Management, oppure l'approccio preferito è l'uso di una toolchain di applicazioni DevOps (CI/CD, Spinnaker) esistente.
In caso di disastro, il cluster utente può essere ridimensionato in base al numero di nodi.
Inoltre, è necessario uno scambio di DNS per instradare il traffico tra i cluster al data center secondario.