Alta affidabilità per le tue app

Questo documento fornisce indicazioni tecniche e best practice per la progettazione e il deployment di carichi di lavoro a disponibilità elevata (HA) in più zone in un universo air-gapped di Google Distributed Cloud (GDC). La guida illustra i principali pattern architetturali, le configurazioni dei servizi e le considerazioni operative per ridurre al minimo i tempi di inattività e garantire la continuità operativa.

Le strategie descritte in questo documento sono destinate ai seguenti professionisti tecnici:

  • Architetti cloud che progettano architetture di infrastrutture e applicazioni resilienti.

  • Ingegneri DevOps e Site Reliability Engineer che implementano strategie di deployment, automazione, monitoraggio e risposta agli incidenti per i carichi di lavoro HA.

  • Sviluppatori di applicazioni che creano applicazioni a tolleranza di errore che si integrano con i pattern HA.

Per saperne di più, consulta Pubblico della documentazione GDC con air gap.

Importanza dell'alta affidabilità

Nei moderni sistemi distribuiti, la pianificazione dell'alta affidabilità è fondamentale. I tempi di inattività possono causare interruzioni significative dell'attività, perdite di entrate e una scarsa esperienza utente.

Per i carichi di lavoro eseguiti nei data center privati che utilizzano GDC, la disponibilità spesso è direttamente correlata al successo operativo principale, in particolare per le applicazioni sensibili alla latenza o mission critical. La progettazione per la disponibilità elevata fin dall'inizio è essenziale per creare servizi resilienti e affidabili.

GDC fornisce funzionalità di iperscalabilità all'interno del tuo ambiente air-gapped con più data center disconnessi o zone. La disponibilità elevata per le app multi-zona dipende dai servizi multi-zona, come il bilanciamento del carico e l'archiviazione asincrona. Per saperne di più sui servizi importanti da utilizzare per la disponibilità elevata, consulta le sezioni Scalabilità e bilanciamento del carico e Deployment di app HA tra le zone con archiviazione asincrona di questo documento.

Funzionalità di iperscalabilità, fornite localmente

GDC estende Google Cloud l'infrastruttura e i servizi a livello perimetrale e ai tuoi data center. GDC fornisce una soluzione hardware e software completamente gestita che ti consente di eseguire Google Kubernetes Engine (GKE) sui cluster GDC e altri Google Cloud servizi più vicini a dove vengono generati e utilizzati i dati.

Questo documento si concentra sugli universi GDC configurati in una topologia multi-zona. In questa configurazione, un singolo universo comprende più zone fisicamente isolate all'interno della stessa località.

Queste zone hanno alimentazione, raffreddamento e rete indipendenti, che forniscono protezione da guasti dell'infrastruttura fisica localizzata. La connettività di rete a bassa latenza e banda larga tra le zone consente la replica dei dati e il failover rapido, costituendo la base per la creazione di applicazioni a disponibilità elevata.

Scalabilità e bilanciamento del carico

Oltre alla ridondanza dei componenti di base, la gestione efficace del traffico e l'abilitazione della scalabilità senza interruzioni sono fondamentali per mantenere l'alta affidabilità, soprattutto in condizioni di carico variabili. GDC fornisce diversi meccanismi per il bilanciamento del carico e la gestione sofisticata del traffico.

Bilanciatore del carico esterno per il traffico nord-sud

Per esporre le applicazioni agli utenti o ai sistemi esterni a un cluster GKE su GDC (traffico nord-sud), utilizza le funzionalità di bilanciamento del carico esterno gestito di GDC. Il servizio del bilanciatore del carico esterno (ELB) fornisce queste funzionalità e si integra perfettamente con Kubernetes.

Le caratteristiche principali del servizio ELB che forniscono disponibilità elevata e scalabilità sono le seguenti:

  • Servizio gestito: viene eseguito come servizio specifico di GDC, ed è progettato per l'alta affidabilità e la resilienza in un ambiente air-gapped.

  • Accesso esterno: esegue il provisioning di indirizzi IP esterni stabili da pool gestiti da GDC, fornendo un punto di ingresso coerente per i client esterni.

  • Integrazione del bilanciatore del carico con Kubernetes: esegue automaticamente il provisioning e la configurazione del bilanciatore del carico quando crei un Kubernetes Service di type: LoadBalancer senza annotazioni interne specifiche.

  • Rilevamento della zona: distribuisce il traffico in entrata tra i pod dell'applicazione integri in esecuzione in tutte le zone disponibili all'interno dell'universo GDC. L'ELB si basa sui probe di idoneità dei pod per determinare l'integrità del backend.

  • Scalabilità: gestisce la distribuzione del traffico esterno man mano che l'applicazione esegue lo scale out orizzontale tra nodi e zone.

Per ottenere la disponibilità elevata per l'ingresso del traffico esterno in modo che le richieste dei client vengano automaticamente instradate dalle zone o dalle istanze in errore, ti consigliamo di utilizzare un bilanciatore del carico esterno.

Per saperne di più, consulta Configurare i bilanciatori del carico esterni.

Bilanciatore del carico interno per il traffico est-ovest

Per la comunicazione tra i servizi in esecuzione all'interno dello stesso cluster GKE su GDC (traffico est-ovest), GDC fornisce un bilanciatore del carico interno (ILB). Un ILB è fondamentale per disaccoppiare i servizi interni e fornire percorsi di comunicazione interni che siano anche a disponibilità elevata e scalabili.

Le caratteristiche principali del servizio ILB che forniscono disponibilità elevata e scalabilità sono le seguenti:

  • Accesso interno: esegue il provisioning di un indirizzo IP interno stabile accessibile solo dall'interno della rete GDC, ad esempio nodi del cluster o altri servizi interni.

  • Integrazione del bilanciatore del carico con Kubernetes: esegue il provisioning del bilanciamento del carico creando un Kubernetes Service di type: LoadBalancer con un' annotazione specifica per indicare che deve essere interno. Ad esempio, networking.gke.io/load-balancer-type: "Internal".

  • Rilevamento della zona: distribuisce il traffico tra i pod di backend integri, che sono identificati con i probe di idoneità, che si trovano in tutte le zone disponibili. Questa distribuzione impedisce errori di comunicazione interna se una zona riscontra problemi.

  • Service Discovery e disaccoppiamento: fornisce un indirizzo IP interno stabile e un nome DNS con l'integrazione di kube-dns e CoreDNS. I servizi possono rilevarsi e comunicare tra loro, eliminando la necessità per i client di conoscere gli indirizzi IP dei singoli pod.

  • Scalabilità: facilita la scalabilità dei servizi di backend interni distribuendo il traffico tra tutte le repliche integre disponibili.

L'utilizzo di un ILB per la comunicazione interna da servizio a servizio rende il flusso di traffico interno resiliente agli errori di zona e fornisce una scalabilità efficace, integrando la disponibilità elevata fornita dall'ELB esterno e dalla distribuzione di Compute sottostante. Questa strategia viene spesso utilizzata per le applicazioni a più livelli in cui le API frontend devono comunicare con le API o i database di backend all'interno del cluster Kubernetes.

Per saperne di più, consulta Configurare i bilanciatori del carico interni.

Deployment di app HA tra le zone con archiviazione asincrona

GDC ti consente di eseguire l'infrastruttura e le applicazioni più vicino alle tue origini dati. Per eseguire il deployment di applicazioni HA con un'origine dati resiliente, implementa la replica dell'archiviazione asincrona per la persistenza dei dati e il ripristino di emergenza.

Le zone rappresentano domini di errore distinti all'interno di un singolo universo. Distribuendo i componenti dell'applicazione e replicando i dati tra le zone, puoi migliorare significativamente la resilienza ai guasti hardware localizzati o agli eventi di manutenzione.

Per saperne di più, consulta Protezione dei dati con l'archiviazione multi-zona.

Passaggi successivi