Alta disponibilità per le tue app

Questa guida strategica fornisce indicazioni tecniche e best practice per la progettazione e l'implementazione di workload a disponibilità elevata (HA) in un universo con air gap Google Distributed Cloud (GDC) configurato con più zone o multizona. La guida descrive i principali pattern architetturali, le configurazioni dei servizi e le considerazioni operative necessarie per ridurre al minimo i tempi di inattività e garantire la continuità operativa per le applicazioni in esecuzione su GDC.

Le strategie di alta disponibilità sono destinate ai professionisti tecnici coinvolti nella progettazione, nel deployment e nella gestione delle applicazioni su GDC, che includono:

  • Architetti cloud all'interno del gruppo di amministratori della piattaforma: progettazione di architetture di infrastrutture e applicazioni resilienti su GDC.

  • Ingegneri DevOps e Site Reliability Engineer (SRE) all'interno del gruppo di operatori di applicazioni: Implementazione di strategie di deployment, automazione, monitoraggio e risposta agli incidenti per i carichi di lavoro HA.

  • Sviluppatori di applicazioni all'interno del gruppo di operatori di applicazioni: creazione di applicazioni a tolleranza di errore che si integrano perfettamente con i pattern dell'infrastruttura HA.

Per saperne di più, consulta la documentazione relativa ai segmenti di pubblico per GDC air-gapped.

Importanza dell'alta disponibilità

Nei moderni sistemi distribuiti, la pianificazione dell'alta disponibilità è fondamentale. Il tempo di inattività, pianificato o non pianificato, può causare interruzioni significative dell'attività, perdite di entrate, danni alla reputazione e un'esperienza utente scadente. Per i carichi di lavoro eseguiti all'edge o in data center privati utilizzando GDC, la disponibilità è spesso direttamente correlata al successo operativo principale, soprattutto per le applicazioni sensibili alla latenza o mission-critical. Progettare per l'alta disponibilità fin dall'inizio è essenziale per creare servizi resilienti e affidabili.

Funzionalità di iperscalabilità, fornite localmente

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

Questa guida si concentra in modo specifico sugli universi GDC configurati in una topologia multizona. Con più zone, un singolo universo GDC comprende più zone fisicamente isolate all'interno della stessa località, ad esempio un campus di data center o un'area metropolitana. Queste zone dispongono di alimentazione, raffreddamento e networking indipendenti, fornendo protezione da guasti localizzati dell'infrastruttura fisica. La connettività di rete a bassa latenza e larghezza di banda elevata tra le zone all'interno di un universo GDC consente la replica sincrona e il failover rapido, costituendo la base per la creazione di applicazioni a disponibilità elevata.

Scalabilità e bilanciamento del carico

Oltre alla ridondanza di base dei componenti, la gestione efficace del traffico e l'attivazione dello scaling continuo sono fondamentali per mantenere un'elevata disponibilità, soprattutto in presenza di 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 tue applicazioni a utenti o sistemi esterni a un cluster GKE su GDC (traffico nord-sud), utilizzi le funzionalità di bilanciamento del carico esterno gestito di GDC. Il servizio di bilanciamento del carico esterno (ELB) fornisce queste funzionalità e si integra perfettamente con Kubernetes.

Le caratteristiche principali del servizio ELB che fornisce HA e scalabilità sono le seguenti:

  • Servizio gestito: ELB è gestito da GDC, progettato per l'alta disponibilità e la resilienza.

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

  • Integrazione del bilanciatore del carico con Kubernetes: esegue automaticamente il provisioning e configura il bilanciatore del carico quando crei un Service di type: LoadBalancer Kubernetes 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. 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 la tua applicazione viene scalata orizzontalmente tra nodi e zone.

L'utilizzo di un bilanciatore del carico esterno è il modo standard e consigliato per ottenere l'alta disponibilità per l'ingresso del traffico esterno, in modo che le richieste dei client vengano instradate automaticamente lontano dalle zone o dalle istanze non funzionanti.

Per ulteriori informazioni, consulta la sezione Configurare i bilanciatori del carico esterni.

Bilanciatore del carico interno per il traffico est-ovest

Per la comunicazione tra i servizi in esecuzione nello stesso cluster GKE su GDC (traffico est-ovest), GDC fornisce un bilanciatore del carico interno (ILB). Ciò è 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 fornisce HA 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: in genere viene eseguito il provisioning creando un Service Kubernetes 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, identificati con i probe di disponibilità, che si trovano in tutte le zone disponibili. Questa distribuzione impedisce errori di comunicazione interni se una zona presenta 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 rilevare e comunicare tra loro, eliminando la necessità per i client di conoscere i singoli indirizzi IP dei pod.

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

L'utilizzo di un bilanciatore del carico interno per la comunicazione interna tra servizi rende il flusso di traffico interno resiliente agli errori di zona e fornisce uno scaling efficace, integrando l'alta disponibilità fornita dal bilanciatore del carico esterno e dalla distribuzione di calcolo sottostante. Questo approccio viene spesso utilizzato per le applicazioni a più livelli in cui i frontend devono comunicare con le API o i database di backend all'interno del cluster Kubernetes.

Per ulteriori informazioni, consulta Configurare i bilanciatori del carico interni.

Deployment di app ad alta disponibilità tra zone con archiviazione asincrona

GDC ti consente di eseguire l'infrastruttura e le applicazioni più vicino alle tue origini dati o agli utenti finali. Ottenere l'alta disponibilità nel tuo universo GDC è fondamentale per i carichi di lavoro critici. Puoi eseguire il deployment di applicazioni HA in più zone all'interno del tuo universo GDC, implementando la replica asincrona dell'archiviazione per la persistenza dei dati e il ripristino di emergenza.

Le zone rappresentano domini in 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 a errori hardware localizzati o eventi di manutenzione.

Passaggi successivi