Questa pagina descrive le opzioni per l'alta disponibilità (HA) in GKE su VMware, come configurare determinati componenti GKE on VMware per l'alta disponibilità e come eseguire il ripristino in caso di emergenza.
Funzionalità di base
GKE on 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 di amministrazione, che includono i master utente (nodi che eseguono il piano di controllo dei cluster utente gestiti) e i nodi 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 gestore del controller Kubernetes e diversi controller critici per il cluster utente.
La disponibilità del piano di controllo del cluster utente è fondamentale per operazioni dei carichi di lavoro come creazione, scale up e scale down e 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 funzionalità di gestione del server API 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 singolo non deve essere fondamentale per la disponibilità dell'applicazione purché venga eseguito il deployment dell'applicazione con pod ridondanti pianificati su più nodi worker.
GKE su VMware è progettato per garantire che gli errori siano isolati il più possibile in un'area funzionale e per dare la priorità alle funzionalità fondamentali per la continuità aziendale.
La funzionalità di base di GKE su VMware include le seguenti categorie:
Ciclo di vita delle applicazioni
I carichi di lavoro esistenti possono essere eseguiti continuamente. 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é GKE 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 è 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 utente.
Modalità di errore
I seguenti tipi di errori possono influire sulle prestazioni dei cluster GKE su VMware.
Errore host ESXi
Un host ESXi che esegue istanze di macchine virtuali (VM) che ospitano nodi Kubernetes potrebbero smettere di funzionare o diventare partizionate di 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 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 interessa 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à, 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. |
| L'alta disponibilità di vSphere riavvia automaticamente le VM su host integri. | L'alta disponibilità di vSphere riavvia automaticamente le VM su host integri. | L'alta disponibilità di vSphere riavvia automaticamente le VM su host integri. | L'alta disponibilità di vSphere riavvia automaticamente le VM su host integri. |
| Esegui il deployment dei carichi di lavoro in modalità ad alta disponibilità per ridurre al minimo la possibilità di interruzioni. | Utilizza i cluster utente ad alta disponibilità per ridurre al minimo la possibilità di interruzioni. |
Errore 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 riusciti 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 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à ha esito negativo, 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. |
| La VM non riuscita viene recuperata automaticamente se la riparazione automatica dei nodi è abilitata nel cluster utente. | 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 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. |
| Esegui il deployment dei carichi di lavoro in modalità ad alta disponibilità per 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
I contenuti di un file VMDK potrebbero essere danneggiati a causa dell'arresto non corretto di una VM oppure un errore del datastore potrebbe causare la perdita di dati etcd e di 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à 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. Se la replica etcd in un cluster di amministrazione non va a buon fine, si verifica un'interruzione. |
Se la replica etcd in un cluster di amministrazione non va a buon fine, si verifica un'interruzione. | |
| GKE on VMware fornisce un processo manuale per il ripristino dall'errore. | GKE on VMware fornisce un processo manuale per il ripristino dall'errore. | GKE on VMware fornisce un processo manuale per il ripristino dall'errore. |
Errore volume permanente 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 con alta disponibilità per ridurre al minimo la possibilità di interruzioni. |
Errore del bilanciatore del carico
Un errore del bilanciatore del carico potrebbe influire sui 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 |
|||
|
L'interruzione può richiedere alcuni secondi prima che il bilanciatore del carico in standby recuperi la connessione VIP del piano di controllo di amministrazione. L'interruzione del servizio potrebbe durare fino a 2 secondi quando utilizzi Seesaw e fino a 300 secondi con F5. La durata dell'interruzione del failover di MetalLB cresce con l'aumentare del numero di nodi del bilanciatore del carico. Con meno di cinque nodi, l'interruzione avviene entro 10 secondi. L'alta disponibilità di Seesaw rileva automaticamente l'errore ed esegue il failover sull'istanza di backup. GKE on VMware fornisce un processo manuale per il ripristino da un errore di Seesaw. |
|||
Attivazione dell'alta disponibilità
vSphere e GKE on 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 ospita i tuoi cluster GKE su VMware:
Queste funzionalità migliorano la disponibilità e il ripristino in caso di errore di un host ESXi.
vCenter HA utilizza più host ESXi configurati come cluster per fornire un ripristino rapido da 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 host di vSphere ad alta disponibilità con Host Failure Response impostato su Restart VMs. Le VM possono quindi essere riavviate automaticamente su altri host disponibili in caso di errore di un host ESXi.
vMotion consente la migrazione live delle VM da un host ESXi a un altro senza tempo di inattività. Per la manutenzione pianificata dell'host, puoi utilizzare la migrazione live di vMotion per evitare completamente il tempo di inattività delle applicazioni e garantire la continuità aziendale.
Cluster di amministrazione
GKE on VMware non supporta l'esecuzione di più piani di controllo per il cluster di amministrazione. Tuttavia, l'indisponibilità 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 sono presenti due nodi aggiuntivi. Se una non è attiva, l'altra può comunque gestire le operazioni del cluster di amministrazione. Per garantire la ridondanza, GKE su VMware distribuisce i servizi aggiuntivi critici, come kube-dns, su entrambi i nodi dei componenti aggiuntivi.
Se imposti antiAffinityGroups.enabled su true nel file di configurazione del cluster di amministrazione, GKE su VMware crea automaticamente regole anti-affinità vSphere DRS per i nodi dei componenti aggiuntivi, che ne determinano la distribuzione tra 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. Ne consegue che nel cluster di amministrazione sono presenti tre nodi, ognuno dei quali esegue un piano di controllo per il cluster utente. Ognuno di questi nodi esegue anche una replica etcd. Il cluster utente continua a funzionare finché è in esecuzione un piano di controllo e un quorum etcd. Un quorum etcd
richiede che due delle tre repliche etcd siano funzionanti.
Se imposti antiAffinityGroups.enabled su true nel file di configurazione del cluster di amministrazione, GKE su VMware crea automaticamente regole anti-affinità vSphere DRS per i tre nodi che eseguono il piano di controllo del cluster utente.
Questo fa sì che le VM siano distribuite su tre host fisici.
GKE su VMware crea anche regole di anti-affinità vSphere DRS per i nodi worker nel cluster utente, in modo che i nodi vengano distribuiti su almeno tre host fisici. Vengono utilizzate più regole di anti-affinità DRS per pool di nodi del cluster utente in base al numero di nodi. Ciò garantisce che i nodi worker possano trovare gli host su cui eseguire l'esecuzione, 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. Inoltre, configura il DRS in modo che sia completamente automatizzato in modo che, nel caso in cui un host non sia disponibile, può riavviare automaticamente le VM su altri host disponibili senza violare le regole di anti-affinità delle VM.
GKE su VMware mantiene un'etichetta di nodo speciale, onprem.gke.io/failure-domain-name, il cui valore è impostato sul nome host ESXi sottostante. Le applicazioni utente che vogliono una disponibilità elevata possono configurare regole podAntiAffinity con questa etichetta come topologyKey per garantire che i loro pod dell'applicazione siano distribuiti tra VM e host fisici diversi.
Puoi anche configurare più pool di nodi per un cluster utente con datastore diversi ed etichette speciali dei nodi. Allo stesso modo, puoi configurare le regole podAntiAffinity con questa etichetta nodo speciale come topologyKey per ottenere una maggiore disponibilità in caso di errori del datastore.
Per disporre dell'alta disponibilità per i carichi di lavoro degli utenti, assicurati che il cluster utente abbia un numero sufficiente di repliche in nodePools.replicas, in modo da garantire 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 relativi 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 l'alta disponibilità avendo più di un nodo con enableLoadBalancer: true.
MetalLB distribuisce i servizi sui nodi del bilanciatore del carico, ma per un singolo servizio esiste un solo nodo leader che gestisce tutto il traffico per quel servizio.
Durante l'upgrade del cluster, si verificano tempi di inattività quando viene eseguito l'upgrade dei nodi del bilanciatore del carico. La durata dell'interruzione del failover di MetalLB cresce con l'aumentare del numero di nodi del bilanciatore del carico. Con meno di cinque nodi, l'interruzione avviene entro 10 secondi.
Bilanciatore del carico 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 inoltre abilitare una combinazione di apprendimento MAC, trasmissioni falsificate e modalità promiscua sul gruppo di porte del bilanciatore del carico.
Con l'alta disponibilità, vengono configurati due bilanciatori del carico in modalità attivo-passivo. Se si verifica un problema con il bilanciatore del carico attivo, il traffico esegue il failover del bilanciatore del carico passivo.
Durante l'upgrade di un bilanciatore del carico si verificano tempi 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 F5 integrato
La piattaforma F5 BIG-IP offre diversi servizi per aiutarti a migliorare sicurezza, disponibilità e prestazioni delle tue applicazioni. Per GKE on VMware, BIG-IP fornisce accesso esterno e servizi di bilanciamento del carico L3/4.
Per ulteriori informazioni, consulta la pagina relativa all'alta disponibilità di BIG-IP.
Ripristino di un cluster danneggiato
Le seguenti sezioni descrivono come ripristinare un cluster danneggiato.
Ripristino da errori dell'host ESXi
GKE su VMware si basa su vSphere HA per fornire 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. Questo è trasparente per gli utenti di GKE su VMware.
Ripristino da errori della VM
Gli errori delle VM possono includere:
Eliminazione imprevista di una VM.
Corruzione del disco di avvio delle 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 con prestazioni ridotte. Ad esempio, una VM non può essere avviata perché per qualche motivo non può essere allocato un indirizzo IP.
Corruzione del file system dell'overlay Docker.
Perdita della VM del piano di controllo dell'amministratore a causa di un errore di upgrade.
Problemi con il sistema operativo.
Gli errori della VM discussi in questa sezione non includono il danneggiamento o la perdita dei dati dei dischi dati PV o etcd collegati alla VM. Per questa richiesta, consulta la sezione Ripristino da errori di archiviazione.
GKE su VMware fornisce un meccanismo di recupero automatico per i nodi dei componenti aggiuntivi 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 piano di controllo dell'amministratore è speciale, nel senso che non è gestita da un cluster Kubernetes e la sua disponibilità non influisce sulla continuità aziendale. Per il recupero degli errori delle VM del piano di controllo amministratore, contatta l'Assistenza Google.
Ripristino da errori di archiviazione
Alcuni degli errori di archiviazione possono essere mitigati da vSphere ad alta disponibilità e vSAN senza influire su GKE su VMware. Tuttavia, alcuni errori di archiviazione potrebbero verificarsi a livello di vSphere, causando il danneggiamento o la perdita dei dati su vari componenti GKE su VMware.
Le informazioni stateful di un cluster e dei carichi di lavoro utente vengono archiviate nelle posizioni seguenti:
etcd
Ogni cluster (cluster di amministrazione e cluster utente) ha un database etcd che memorizza lo stato (oggetti Kubernetes) del cluster.
PersistentVolumes
Utilizzato sia dai componenti di sistema che dai carichi di lavoro degli utenti.
Ripristino in seguito a perdita o danneggiamento dei 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 smetteranno di funzionare se il database etcd del cluster utente è danneggiato o viene perso. Le operazioni del ciclo di vita del cluster utente smetteranno di funzionare se il database etcd del cluster di amministrazione risulta danneggiato o viene 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 attesa/errore/arresti anomali in loop non sempre indica che i dati etcd sono danneggiati o persi. Il problema potrebbe essere dovuto agli errori nelle VM che ospitano i pod etcd. Devi eseguire il seguente ripristino etcd solo in caso di danneggiamento o perdita dei dati.
Per poter ripristinare i dati (a uno stato recente del cluster) da danni o perdite 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, consulta Backup di un cluster di amministrazione e Backup di un cluster utente.
Il ripristino dei dati etcd riporta il cluster a uno stato precedente. In altre parole, se viene eseguito un backup prima del deployment di un'applicazione e poi 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 di cui viene eseguita lo snapshot prima di creare un cluster utente, il piano di controllo del cluster utente viene rimosso nel cluster di amministrazione ripristinato. Ti consigliamo quindi di eseguire il backup del cluster dopo ogni operazione critica sul cluster.
L'errore di danneggiamento/perdita dei dati eccd può verificarsi nei seguenti scenari:
Un singolo nodo di un cluster a tre nodi (cluster utente ad alta disponibilità) non funziona in modo permanente a causa di danneggiamento o perdita dei dati. In questo caso, solo un singolo nodo è inaccessibile e il quorum etcd esiste ancora. Questo può accadere 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 Sostituzione di una replica del file etcd non riuscita.
Due nodi di un cluster a tre nodi ecc. (cluster utente ad alta disponibilità) vengono danneggiati definitivamente a causa di un danneggiamento o una perdita dei dati. Il quorum è perso, quindi sostituire le repliche etcd non riuscite con nuove repliche non aiuta. Lo stato del cluster deve essere ripristinato dai dati di backup. Per ulteriori informazioni, consulta Ripristinare un cluster utente da un backup (HA).
Un cluster a nodo singolo (cluster di amministrazione o cluster utente non ad alta disponibilità) viene danneggiato definitivamente a causa di danni o perdite dei dati. Il quorum è perso, quindi devi creare un nuovo cluster dal backup. Per ulteriori informazioni, consulta Ripristinare un cluster utente da un backup (non ad alta disponibilità).
Ripristino in seguito a danneggiamento o perdita del volume permanente dell'applicazione utente
I clienti di GKE su VMware possono utilizzare determinate soluzioni di archiviazione dei partner per eseguire il backup e il ripristino degli oggetti PersistentVolume per le applicazioni utente.
Per l'elenco dei partner di archiviazione idonei per GKE su VMware, consulta Partner di archiviazione Anthos Ready.
Ripristino dagli errori del bilanciatore del carico
Per il bilanciatore del carico di Seesaw in bundle, puoi recuperare gli errori ricreando il bilanciatore del carico. Per ricreare il bilanciatore del carico, esegui l'upgrade di Seesaw alla stessa versione mostrata 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. Di conseguenza, devi eseguire l'upgrade sulla VM del piano di controllo di amministrazione in cui è presente l'accesso al piano di controllo.
Per i bilanciatori del carico integrati (F5), consulta l'assistenza di F5.
Per il bilanciatore del carico MetalLB in bundle, utilizza nodi cluster come bilanciatori del carico. La riparazione automatica del nodo non viene attivata in caso di 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ù piattaforme vCenter o GKE Enterprise può fornire una maggiore disponibilità globale e limitare la portata dell'attacco durante le interruzioni.
Questa configurazione utilizza il cluster GKE Enterprise esistente nel data center secondario per il ripristino di emergenza, anziché configurare un nuovo cluster. Di seguito è riportato un riepilogo generale per raggiungere questo obiettivo:
Crea un altro cluster di amministrazione e un altro cluster utente nel data center secondario. In questa architettura multi-cluster, gli utenti devono 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 è in modalità hot standby (sempre in esecuzione).
I deployment delle applicazioni possono essere replicati tra i due vCenter utilizzando Config Management oppure l'approccio preferito consiste nell'utilizzare una toolchain DevOps (CI/CD, Spinnaker) esistente per le applicazioni.
In caso di emergenza, il cluster utente può essere ridimensionato al numero di nodi.
Inoltre, è necessaria una commutazione DNS per instradare il traffico tra i cluster al data center secondario.