In questa pagina vengono descritte le opzioni per l'alta disponibilità in Google Distributed Cloud (software solo) per VMware.
Funzionalità di base
Un'installazione solo software di Google Distributed Cloud for VMware include un amministratore e uno o più cluster utente.
Il cluster di amministrazione gestisce il ciclo di vita dei cluster utente, tra cui creazione, aggiornamento, upgrade ed eliminazione di cluster. Nel cluster di amministrazione, l'amministratore Il master gestisce i nodi worker dell'amministratore, che includono i master degli utenti (nodi in esecuzione il piano di controllo dei cluster utente gestiti) e i nodi aggiuntivi (nodi in esecuzione 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 l'API Kubernetes server, lo scheduler Kubernetes, il gestore dei controller Kubernetes e diversi e i controller critici per il cluster utente.
La disponibilità del piano di controllo del cluster utente è fondamentale per le operazioni dei carichi di lavoro come la creazione, lo scale up e lo scale down e la terminazione dei carichi di lavoro. In altre parole, un l'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 dell'API Kubernetes se il piano di controllo corrispondente è assente.
Il deployment dei carichi di lavoro e dei servizi containerizzati viene eseguito nel worker del cluster utente nodi. Ogni singolo nodo worker non dovrebbe essere critico per la disponibilità dell'applicazione purché venga eseguito il deployment dell'applicazione con pod ridondanti pianificati con più nodi worker.
Attivazione dell'alta disponibilità
vSphere e Google Distributed Cloud forniscono una serie di funzionalità che contribuiscono all'alta disponibilità (HA).
HA e vMotion vSphere
Ti consigliamo di abilitare le due funzionalità seguenti nel cluster vCenter che ospita i tuoi cluster Google Distributed Cloud:
Queste funzioni 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
per il ripristino da interruzioni del servizio e ad alta disponibilità economica
in esecuzione su macchine virtuali. Ti consigliamo di eseguire il provisioning di vCenter
con altri host e
abilita il monitoraggio host ad alta disponibilità di vSphere
con Host Failure Response impostato su Restart VMs. Le VM possono quindi essere
verrà riavviato automaticamente su altri host disponibili in caso di errore dell'host ESXi.
vMotion consente la migrazione live delle VM da un host ESXi a un altro senza tempi di inattività. Per la manutenzione pianificata dell'host, puoi utilizzare la migrazione live di vMotion per evitare l'inattività delle applicazioni e garantire la continuità aziendale.
Cluster di amministrazione
Google Distributed Cloud supporta la creazione di amministratori ad alta disponibilità cluster. Un cluster di amministrazione ad alta disponibilità ha tre nodi che eseguono i componenti del piano di controllo. Per informazioni su requisiti e limitazioni, vedi Cluster di amministrazione ad alta disponibilità.
Tieni presente che la mancata disponibilità del piano di controllo del cluster di amministrazione influisce sulle funzionalità del cluster utente esistente o su qualsiasi carico di lavoro in esecuzione cluster.
Esistono due nodi dei componenti aggiuntivi in un cluster di amministrazione. Se una non è attiva, l'altra
possono comunque gestire le operazioni
del cluster di amministrazione. Per la ridondanza,
Google Distributed Cloud diffonde servizi aggiuntivi critici, come kube-dns,
in entrambi i nodi dei componenti aggiuntivi.
Se imposti antiAffinityGroups.enabled su true nel cluster di amministrazione
di configurazione del deployment, Google Distributed Cloud crea automaticamente
DRS vSphere
regole di anti-affinità per i nodi dei componenti aggiuntivi, che ne causano la diffusione
due host fisici per l'alta disponibilità.
Cluster utente
Puoi abilitare l'alta disponibilità per un cluster utente impostando masterNode.replicas su 3 in
il file di configurazione del cluster utente. Se il cluster utente ha
Piano di controllo V2
abilitato (consigliato), i tre nodi del piano di controllo vengono eseguiti nel cluster utente.
Cluster utente kubeception dell'alta disponibilità legacy
per eseguire i tre nodi del piano di controllo nel cluster di amministrazione. Ogni piano di controllo
esegue anche una replica etcd. Il cluster utente continua a funzionare
purché ci sia un piano di controllo in esecuzione e un quorum etcd. Un etcd
il quorum richiede che due delle tre repliche etcd funzionino.
Se imposti antiAffinityGroups.enabled su true nel cluster di amministrazione
di configurazione del deployment, Google Distributed Cloud crea automaticamente vSphere DRS
regole di anti-affinità per i tre nodi che eseguono il piano di controllo del cluster utente.
Questo fa sì che le VM vengano distribuite tra tre host fisici.
Google Distributed Cloud crea anche regole di anti-affinità vSphere DRS per nodi worker nel cluster utente, con la conseguente distribuzione dei nodi 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 possono trovare gli host su cui eseguire l'esecuzione, anche quando il numero di host è inferiore rispetto al numero di VM nel pool di nodi del cluster utente. Ti consigliamo di includere host fisici aggiuntivi nel cluster vCenter. Configura anche DRS in modo che in modo che nel caso in cui un host non sia più disponibile, DRS possa riavvia le VM su altri host disponibili senza violare le VM regole di anti-affinità.
Google Distributed Cloud gestisce un'etichetta speciale per i nodi,
onprem.gke.io/failure-domain-name, il cui valore è impostato sull'ESXi sottostante
nome host. È possibile configurare applicazioni utente che vogliono un'alta disponibilità
podAntiAffinity regole con questa etichetta topologyKey per garantire che
i pod delle applicazioni sono distribuiti su diverse VM e host fisici.
Puoi anche configurare più pool di nodi per un cluster utente con diverse
datastore ed etichette di nodi speciali. Allo stesso modo, puoi configurare podAntiAffinity
di regole con quell'etichetta nodo speciale come topologyKey per ottenere
la disponibilità in caso di errori del datastore.
Per avere l'alta disponibilità per i carichi di lavoro utente, assicurati che il cluster utente abbia un numero sufficiente
di repliche sotto nodePools.replicas, il che garantisce il numero desiderato di
di nodi worker del cluster in esecuzione.
Puoi utilizzare datastore separati per i cluster di amministrazione e i cluster utente per isolare i loro 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
bilanciatore del carico MetalLB in bundle,
si ottiene l'alta disponibilità perché ha più di un nodo con enableLoadBalancer: true.
MetalLB distribuisce i servizi sui nodi del bilanciatore del carico, ma per una singola esiste 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 con l'aumento del numero di nodi del bilanciatore del carico aumenta. Con meno di 5 nodi, l'interruzione avviene entro 10 secondi.
Bilanciatore del carico Seesaw in bundle
Per
bilanciatore del carico Seesaw in bundle,
puoi abilitare l'alta disponibilità impostando
Da loadBalancer.seesaw.enableHA a true nel file di configurazione del cluster.
Devi inoltre abilitare una combinazione di apprendimento MAC, trasmissioni contraffatte,
e promiscuo sul gruppo di porte del bilanciatore del carico.
Con l'alta disponibilità, vengono configurati due bilanciatori del carico in modalità attiva-passiva. Se lo stato attivo si è verificato un problema con il bilanciatore del carico passivo.
Durante l'upgrade di un bilanciatore del carico, si verifica un tempo di inattività. Se l'alta disponibilità è abilitato per il bilanciatore del carico, il tempo di inattività massimo è di due secondi.
Bilanciatore del carico F5 BIG-IP integrato
La piattaforma F5 BIG-IP offre vari Servizi per aiutarti a migliorare sicurezza, disponibilità e prestazioni delle tue applicazioni. Per Google Distributed Cloud, BIG-IP fornisce accesso esterno e servizi di bilanciamento del carico L3/4.
Utilizzo di più cluster per il ripristino di emergenza
Deployment di applicazioni in più cluster su più vCenter Le piattaforme GKE Enterprise possono fornire una maggiore disponibilità globale per limitare la portata dell'attacco durante le interruzioni.
Questa configurazione utilizza il cluster GKE Enterprise esistente di un data center secondario per il ripristino di emergenza anziché 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 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 è hot standby (sempre in esecuzione).
I deployment delle applicazioni possono essere replicati tra i due vCenter utilizzando Config Sync o l'approccio preferito è utilizzare una toolchain DevOps (CI/CD, Spinnaker) per applicazioni esistente.
In caso di emergenza, il cluster utente può essere ridimensionato al numero nodi.
Inoltre, è necessario un cambio DNS per instradare il traffico tra automaticamente al data center secondario.