OpenShift su Google Cloud: strategie di ripristino di emergenza per configurazioni active-passive e active-inactive

Questo documento descrive come pianificare e implementare ripristino di emergenza attivo-passivo e attivo-inattivo per le implementazioni OpenShift su Google Cloud per aiutarti a ottenere tempi di inattività minimi e un ripristino rapido in caso di emergenza. Fornisce best practice per il backup dei dati, la gestione della configurazione come codice e la gestione dei secret per garantire il rapido recupero delle applicazioni in caso di emergenza.

Questo documento è destinato ad amministratori di sistema, architetti cloud e sviluppatori di applicazioni responsabili del mantenimento della disponibilità e della resilienza delle applicazioni su una piattaforma OpenShift Container Platform distribuita su Google Cloud.

Questo documento fa parte di una serie incentrata sulle strategie a livello di applicazione che garantiscono che i carichi di lavoro rimangano altamente disponibili e rapidamente recuperabili in caso di errori. Si presuppone che tu abbia letto Best practice per ripristino di emergenza con OpenShift. I documenti di questa serie sono i seguenti:

Architetture per il ripristino di emergenza

Questa sezione descrive le architetture per scenari di ripristino di emergenza attivo/passivo e attivo/inattivo.

Prodotti utilizzati

Deployment attivo/passivo

Il seguente diagramma mostra uno scenario di deployment attivo/passivo per OpenShift su Google Cloud.

Deployment attivo-passivo, spiegato nel testo seguente.

Come mostrato nel diagramma precedente, in un deployment attivo-passivo per il ripristino di emergenza, un cluster OpenShift nella regione primaria gestisce tutto il traffico di produzione. Un cluster secondario in una regione diversa viene mantenuto pronto a subentrare in caso di errore del cluster principale. Questa configurazione garantisce tempi di inattività minimi, in quanto il cluster secondario è pre-provisioning e in stato warm, il che significa che è configurato con l'infrastruttura e i componenti dell'applicazione necessari, ma non gestisce attivamente il traffico fino a quando non è necessario. I dati dell'applicazione vengono replicati nel cluster passivo per ridurre al minimo la perdita di dati, in linea con l'RPO.

Uno dei cluster regionali funge da sito principale (attivo) e gestisce tutto il traffico di produzione. Un cluster secondario, in un'altra regione, è lo standby per il ripristino di emergenza. Il cluster secondario viene mantenuto in uno stato caldo ed è pronto a subentrare con un ritardo minimo in caso di errore del cluster principale.

Descrizione dei componenti in uno scenario di RE attivo-passivo

L'architettura ha la seguente configurazione:

  • Cluster OpenShift principale (attivo): situato nella regioneGoogle Cloud principale, questo cluster esegue il workload di produzione e gestisce attivamente tutto il traffico degli utenti in condizioni operative normali.
  • Cluster OpenShift secondario (passivo): situato in una regioneGoogle Cloud separata per l'isolamento degli errori, questo cluster funge da cluster di standby attivo. È parzialmente configurato e in esecuzione ed è pronto a subentrare in caso di guasto del sistema principale. Dispone dell'infrastruttura, della configurazione OpenShift e dei componenti dell'applicazione necessari, ma non gestisce il traffico di produzione live finché non viene attivato un evento di failover.
  • Google Cloud Regioni: località geograficamente isolate che forniscono le basi per il ripristino di emergenza. L'utilizzo di regioni separate garantisce che un evento su larga scala che interessa una regione non influenzi il cluster di standby.
  • Bilanciatore del carico HTTPS esterno globale: funge da punto di ingresso globale singolo per il traffico dell'applicazione. In condizioni normali, è configurato per instradare tutto il traffico al cluster primario (attivo). I suoi controlli di integrità monitorano la disponibilità del cluster primario.
  • Meccanismo di replica dei dati: processo o strumenti continui responsabili della copia dei dati essenziali delle applicazioni dal cluster primario al cluster secondario (ad esempio, database o stato dei volumi permanenti). Questo approccio garantisce la coerenza dei dati e riduce al minimo la perdita di dati durante un failover, aiutandoti a soddisfare il tuo RPO.
  • Monitoraggio e controlli di integrità:sistemi che valutano continuamente l'integrità e la disponibilità del cluster principale e delle relative applicazioni, ad esempio Cloud Monitoring, controlli di integrità del bilanciatore del carico, monitoraggio interno del cluster. Questi sistemi sono importanti per il rilevamento rapido di eventuali guasti.
  • Meccanismo di failover:un processo predefinito (manuale, semiautomatico o completamente automatico) per reindirizzare il traffico dal cluster primario a quello secondario al rilevamento di un errore non recuperabile nel cluster primario. Questo processo in genere comporta l'aggiornamento della configurazione di backend del bilanciatore del carico globale in modo che abbia come target il cluster secondario, rendendolo il nuovo sito attivo.
  • Rete VPC: l'infrastruttura di rete Google Cloud sottostante che crea la connettività necessaria tra le regioni per la replica e la gestione dei dati.

Deployment attivi/inattivi

RE attivo-passivo prevede il mantenimento di una regione secondaria come standby, che viene attivata solo in caso di disastri. A differenza delle configurazioni active-passive, in cui i dati vengono replicati continuamente, questa strategia si basa su backup periodici archiviati in Cloud Storage, con il provisioning dell'infrastruttura e il ripristino dei dati durante il failover. Puoi utilizzare strumenti come Velero, integrato con l'API OpenShift per la protezione dei dati (OADP), per eseguire backup periodici. Questo approccio riduce al minimo i costi, il che lo rende ideale per le applicazioni che possono tollerare tempi di ripristino più lunghi. Può anche aiutare le organizzazioni ad allinearsi con RTO (Recovery Time Objective) ed RPO (Recovery Point Objective) estesi.

In uno scenario di RE attivo-passivo, viene eseguito regolarmente il backup dei dati nella regione di standby, ma non vengono replicati attivamente. L'infrastruttura viene sottoposta a provisioning nell'ambito del processo di failover e i dati vengono ripristinati dal backup più recente. Puoi utilizzare l'API OpenShift for Data Protection (OADP), basata sul progetto open source Velero, per eseguire backup regolari. Ti consigliamo di archiviare questi backup in bucket Cloud Storage con il controllo delle versioni abilitato. In caso di emergenza, puoi utilizzare OADP per ripristinare i contenuti del cluster. Questo approccio riduce al minimo i costi continui, ma comporta un RTO più lungo e un RPO potenzialmente più elevato rispetto all'approccio attivo-passivo. Questa configurazione è adatta alle applicazioni con obiettivi di tempo di ripristino più lunghi.

Il seguente diagramma mostra un deployment attivo/non attivo e il processo di failover.

Processo di failover.

La procedura di failover è la seguente:

  1. Un evento di RE viene attivato quando un servizio monitorato non è più disponibile.
  2. Una pipeline esegue automaticamente il provisioning dell'infrastruttura nella regione di RE.
  3. Viene eseguito il provisioning di un nuovo cluster OpenShift.
  4. I dati, i secret e gli oggetti dell'applicazione vengono ripristinati dall'ultimo backup tramite OADP.
  5. Il record Cloud DNS viene aggiornato in modo che punti ai bilanciatori del carico regionali nella regione di RE.

Come mostrato nel diagramma precedente, vengono implementati due cluster regionali OpenShift separati, ciascuno in una regione Google Cloud diversa, ad esempio us-central1 e europe-west1. Ogni cluster deve essere a disponibilità elevata all'interno della sua regione e utilizzare più zone per consentire la ridondanza.

Descrizione dei componenti in uno scenario di RE attivo-inattivo

L'architettura ha la seguente configurazione:

  • Regione principale (regione A): contiene il cluster OpenShift completamente operativo che gestisce il traffico di produzione.
  • Regione secondaria (regione B): inizialmente contiene risorse minime (VPC e subnet). L'infrastruttura (istanze Compute Engine e OCP) viene sottoposta a provisioning durante il failover.
  • Archiviazione di backup: i bucket Google Cloud Storage archiviano backup periodici (OADP o Velero per gli oggetti applicazione, nonché PV e backup del database). Ti consigliamo di utilizzare il controllo delle versioni e la replica tra regioni per il bucket.
  • Gestione della configurazione: il repository Git archivia l'infrastruttura come codice (IaC, ad esempio Terraform) e i manifest Kubernetes o OpenShift (per GitOps).
  • Strumenti di backup: OADP (Velero) configurato nel cluster primario per eseguire backup pianificati su Cloud Storage.
  • Orchestrazione: script o strumenti di automazione attivano i processi di provisioning e ripristino dell'infrastruttura durante il failover.

Casi d'uso

Questa sezione fornisce esempi dei diversi casi d'uso per i deployment attivo-passivo e attivo-inattivo.

Casi d'uso di RE attivo-passivo

RE attivo-passivo è consigliato per i seguenti casi d'uso:

  • Applicazioni che richiedono un RTO inferiore (ad esempio, da minuti a ore) rispetto a quello ottenibile con i ripristini a freddo, in cui i dati vengono ripristinati da un backup non immediatamente accessibile.
  • Sistemi in cui la replica continua dei dati è fattibile e l'RPO deve essere ridotto al minimo (ad esempio, da minuti a secondi).
  • Settori regolamentati con limiti di inattività rigorosi e applicazioni aziendali critiche in cui il costo di manutenzione di un cluster di standby attivo è giustificato dall'impatto dell'inattività sull'attività.

Casi d'uso di RE attivo-inattivo

RE emergenza attivo-inattivo è consigliato per i seguenti casi d'uso:

  • Applicazioni che possono tollerare RTO più lunghi (ad esempio, da diversi minuti a ore).
  • Ambienti in cui l'ottimizzazione dei costi è importante e la spesa per un cluster di standby in esecuzione continua è proibitiva. Il costo principale continuo riguarda l'archiviazione di oggetti piuttosto che l'esecuzione di istanze di calcolo.
  • Workload di sviluppo, test o produzione meno critici.
  • Sistemi di archiviazione o di elaborazione batch in cui il tempo di recupero è meno critico.

Considerazioni sulla progettazione

Questa sezione descrive i fattori di progettazione, le best practice e i consigli di progettazione da prendere in considerazione quando utilizzi questa architettura di riferimento per sviluppare una topologia che soddisfi i tuoi requisiti specifici di sicurezza, affidabilità, costi e prestazioni.

Considerazioni sulla progettazione attiva/passiva

Questa sezione descrive le considerazioni di progettazione per uno scenario di RE attivo-passivo.

Protezione dello stato e della configurazione dell'applicazione

OpenShift Container Platform fornisce OADP e offre una protezione completa per il ripristino di emergenza per le applicazioni in esecuzione nei cluster. Puoi utilizzarlo per eseguire il backup degli oggetti Kubernetes e OpenShift utilizzati sia dalle applicazioni containerizzate sia dalle macchine virtuali (ad esempio deployment, servizi, route, PVC, ConfigMap, secret e CRD). Tuttavia, OADP non supporta il backup e il ripristino completi del cluster. Per scoprire come configurare e pianificare i backup e come ripristinare le operazioni, consulta la documentazione di Red Hat.

OADP fornisce processi di backup e ripristino per i volumi permanenti che si basano sui negozi di archiviazione a blocchi e NFS utilizzati dalle applicazioni. Puoi eseguire questi processi utilizzando gli strumenti Restic o Kopia per creare snapshot o eseguire backup a livello di file.

OADP è utile per eseguire il backup delle definizioni degli oggetti, garantire la coerenza della configurazione e, se necessario, ripristinare applicazioni o spazi dei nomi specifici, integrando la replica dei dati.

Per ridurre ulteriormente RPO e RTO in una configurazione attiva-passiva, ti consigliamo di configurare la replica dei dati tra le regioni primaria e secondaria.

La replica dei dati è importante per garantire che il cluster secondario possa subentrare senza problemi. Come descritto nella sezione seguente, l'implementazione della replica dei dati dai cluster primari a quelli secondari dipende dal tipo di archiviazione utilizzato dall'applicazione.

Archiviazione a blocchi (volumi permanenti)

Utilizza la replica asincrona di Google Persistent Disk per copiare i dati dalla regione primaria a quella secondaria. Con questo approccio, crei un disco primario nella regione primaria, un disco secondario nella regione secondaria e configuri la replica tra i due. L'utilizzo di gruppi coerenti garantisce che entrambi i dischi contengano dati di replica di un momento specifico comune, che vengono poi utilizzati per RE. Per saperne di più, consulta Configura la replica asincrona di Persistent Disk.

Oggetti PersistentVolume

In OpenShift, crea oggetti PersistentVolumes in entrambi i cluster che collegano questi dischi e assicurati che le applicazioni utilizzino le stesse richieste di volumi permanenti (PVC) in entrambi i cluster.

Replica a livello di applicazione

Alcune applicazioni (ad esempio, database e code di messaggi) hanno funzionalità di replica integrate che puoi configurare nei cluster. Puoi anche utilizzare un servizio gestito come Pub/Sub per facilitare la replica di tipi specifici di dati o eventi dell'applicazione. ad esempio database e code di messaggi.

Backup dei database

Le applicazioni possono dipendere da diversi tipi di prodotti di database. Per illustrare le considerazioni di progettazione per i backup del database, questo documento utilizza PostgreSQL come database di esempio.

Backup self-hosted utilizzando un operatore di database in-cluster

Gli operatori di database come CloudNative PostgreSQL Operator possono facilitare i backup pianificati e il ripristino di emergenza per i cluster PostgreSQL. CloudNative PostgreSQL Operator si integra in modo nativo con strumenti come pg_basebackup e supporta i backup della replica in streaming. Puoi archiviare i backup in servizi di spazio di archiviazione sul cloud come Google Cloud Storage (Cloud Storage) per la durabilità e il ripristino.

Puoi configurare la replica in streaming tra i cluster regionali primari e secondari per assicurarti che, anche in caso di interruzione nella regione primaria, i dati siano disponibili. Questa replica in streaming è in genere sincrona all'interno di una regione e asincrona tra le regioni. Per i passaggi di configurazione dettagliati, consulta la documentazione di CloudNativePG.

In caso di emergenza, puoi ripristinare i backup in un nuovo cluster PostgreSQL, garantendo tempi di inattività e perdita di dati minimi. Di seguito è riportato un esempio di snippet di configurazione per l'attivazione dei backup pianificati utilizzando l'operatore CloudNative PostgreSQL:

        apiVersion: postgresql.cnpg.io/v1
        kind: ScheduledBackup
        metadata:
        name: backup-example
        spec:
        schedule: "0 0 0 * * *"
        backupOwnerReference: self
        cluster:
            name: pg-backup

Servizi gestiti

I database gestiti come Cloud SQL dispongono di funzionalità di backup e replica integrate. Ti consigliamo di configurare la replica asincrona dall'istanza di database principale a una replica nella regione secondaria. Per saperne di più, consulta la sezione Informazioni sulla replica in Cloud SQL. In OpenShift, configura i secret o le mappe di configurazione in modo che puntino alle stringhe di connessione al database corrette per ogni cluster.

Poiché la replica asincrona comporta un RPO diverso da zero, esiste la possibilità di perdita delle scritture di dati più recenti. Devi progettare la tua applicazione per ridurre il rischio di perdita di dati. In alternativa, puoi utilizzare un altro metodo di replica.

Ti consigliamo inoltre di abilitare i backup automatici di Cloud SQL. Per saperne di più, consulta Creazione e gestione dei backup on demand e automatici.

Processo di failover

In caso di errore del cluster primario, Cloud DNS reindirizza automaticamente il traffico al cluster secondario regionale in base ai controlli di integrità e alle policy di failover.

Quando il cluster secondario viene promosso da replica di lettura a principale, diventa un sito attivo e gestisce il traffico di produzione. Questa promozione è necessaria per poter accettare le scritture del database.

Per configurare RE per Cloud SQL, segui i passaggi descritti nella documentazione sul ripristino di emergenza di Google Cloud SQL. L'utilizzo della replica asincrona del database o dell'archiviazione causa un RPO diverso da zero per contribuire a garantire che l'applicazione possa tollerare la perdita delle scritture più recenti. In alternativa, puoi utilizzare un altro metodo di replica.

Gestione sicura dei secret

I secret come password di database, chiavi API e certificati TLS sono aspetti importanti del RE. Devi essere in grado di ripristinarli in modo sicuro e affidabile in un nuovo cluster.

Di seguito sono riportati alcuni approcci comuni alla gestione dei secret:

  • Utilizza secret esterni: utilizza uno strumento come l'operatore di secret esterni per estrarre i secret da Google Secret Manager.
  • Esegui il backup dei secret con l'operatore OADP: se non utilizzi un archivio esterno, assicurati che i secret siano inclusi nei backup.
  • Rotazione regolare: ruota regolarmente i secret e assicurati che la tua strategia di gestione dei secret preveda scenari di RE.
  • Test: testa il ripristino dei secret in un ambiente di staging per verificare che tutti i servizi possano essere avviati con le credenziali fornite.
  • Convalida: verifica che il cluster di RE disponga dei ruoli IAM o dei metodi di autenticazione necessari per recuperare i secret dagli archivi esterni.

Networking e gestione del traffico

Utilizza il bilanciatore del carico HTTPS esterno globale di Google Cloudcome punto di ingresso principale per distribuire il traffico tra più cluster OpenShift (ad esempio, cluster primari e secondari). Questo servizio globale indirizza le richieste degli utenti al cluster di backend appropriato in base a prossimità, integrità e disponibilità.

Per connettere il bilanciatore del carico globale ai cluster OpenShift, puoi utilizzare uno dei seguenti approcci:

  • Utilizza bilanciatori del carico regionali (NEG internet): configura Google Cloud i gruppi di endpoint di rete (NEG) internet in modo che puntino agli indirizzi IP esterni dei bilanciatori del carico regionali che espongono ciascuno dei servizi di ingresso (router OCP) dei tuoi cluster OpenShift. Il bilanciatore del carico globale indirizza il traffico a questi indirizzi IP del bilanciatore del carico regionale. Questo approccio fornisce un livello di astrazione, ma comporta un hop a una rete aggiuntiva.
  • Direct Pod Routing (Compute Engine_VM_IP_PORT NEGs): Configura l'integrazione di OpenShift Ingress Controller per utilizzare i Google Cloud Network Endpoint Group (NEG) di tipo Compute Engine_VM_IP_PORT. Questo approccio consente al bilanciatore del carico globale di scegliere come target i pod del controller Ingress (router) di OpenShift direttamente utilizzando il loro PodIP:TargetPort interno. Questo metodo bypassa l'hop aggiuntivo e il proxy aggiuntivo del nodo. In genere, si traduce in una latenza inferiore e consente un controllo di integrità più diretto dal bilanciatore del carico globale.

Entrambe le configurazioni consentono al bilanciatore del carico globale di gestire la distribuzione del traffico in modo efficace tra i cluster in diverse regioni. Per saperne di più, consulta Configura un bilanciatore del carico delle applicazioni esterno globale con un backend esterno.

VPC

Ti consigliamo i seguenti approcci per la gestione del VPC:

  • VPC condiviso: utilizza un VPC condiviso per centralizzare la gestione della rete per i cluster primari e secondari. Questo approccio semplifica l'amministrazione e garantisce criteri di rete coerenti tra le regioni.
  • Routing dinamico globale: abilita il routing dinamico globale all'interno dei tuoi VPC per propagare automaticamente le route tra le regioni, garantendo una connettività perfetta tra i cluster.
  • VPC in modalità personalizzata: utilizza i VPC in modalità personalizzata e crea subnet specifiche nelle regioni in cui vengono eseguiti i cluster. Ciò è spesso necessario per il networking dei pod nativo VPC richiesto da metodi come il routing Compute Engine_VM_IP_PORT.
  • Peering di rete VPC: se è necessario utilizzare reti VPC separate per ogni regione e cluster, utilizza il peering di rete VPC per connettere le regioni e i cluster.

Subnet e indirizzi IP

Crea subnet regionali in ogni regione per mantenere la segmentazione della rete ed evitare conflitti di indirizzi IP.

Assicurati che gli intervalli IP non si sovrappongano tra le regioni per evitare problemi di routing.

Traffico cross-cluster con Red Hat Service Mesh

OpenShift supporta la federazione di mesh di servizi, che consente la comunicazione tra servizi di cui è stato eseguito il deployment in più cluster OpenShift. Questa funzione è particolarmente utile per gli scenariREa in cui i servizi potrebbero dover comunicare tra cluster durante il failover o la replica dei dati.

Per scoprire come configurare la federazione Service Mesh tra cluster primari e secondari, consulta la documentazione di Red Hat.

Considerazioni sulla progettazione attiva/inattiva

Questa sezione descrive le considerazioni di progettazione per una soluzione di RE attiva-inattiva.

Configurazione dell'applicazione come codice (GitOps)

Ti consigliamo di adottare un approccio GitOps per archiviare tutte le configurazioni di cluster e applicazioni in un repository Git. Questo approccio consente un ripristino rapido in uno scenario di RE, consentendo la sincronizzazione con uno stato noto per essere in esecuzione in modo affidabile in un altro cluster. I backup garantiscono di avere snapshot dello stato di runtime, ma è necessario anche un modo affidabile per eseguire nuovamente il deployment della logica dell'applicazione, dei manifest e delle definizioni dell'infrastruttura rapidamente dopo un disastro.

Utilizzare l'operatore OpenShift GitOps

L'operatore OpenShift GitOps, basato su Argo CD, fornisce un modo supportato da Red Hat per implementare pattern GitOps direttamente in un ambiente OpenShift. Automatizza il processo di riconciliazione continua dello stato del cluster con la configurazione scelta e lo archivia in un repository Git.

Il controller dell'operatore OpenShift GitOps garantisce continuamente che lo stato del cluster corrisponda alla configurazione definita in questo repository. Se le risorse cambiano o non sono presenti, le riconcilia automaticamente. Per saperne di più, vedi Informazioni su Red Hat OpenShift GitOps.

Esecuzione dello scenario di RE

In caso di emergenza, segui questi passaggi:

  • Configura un nuovo cluster OpenShift in un'altra regione.
  • Installa l'operatore OpenShift GitOps.
  • Applica lo stesso manifest dell'applicazione che fa riferimento al tuo repository Git.

L'operatore sincronizza lo stato del cluster in modo che corrisponda al repository, eseguendo rapidamente il redeploy di deployment, servizi, route, operatori e qualsiasi altra risorsa definita nel codice.

Per evitare problemi durante RE, ti consigliamo di procedere come segue:

  • Mantieni strategie rigorose di ramificazione e tagging nel tuo repository Git in modo da poter identificare configurazioni stabili adatte al RE.
  • Verifica che il cluster di RE disponga della connettività di rete e delle autorizzazioni appropriate per accedere al repository Git.
  • Includi tutti i tipi di risorse come codice per evitare interventi manuali durante il failover (ad esempio, componenti dell'infrastruttura, workload delle applicazioni e configurazioni).

Regole firewall

Definisci criteri firewall unificati e applicali in modo coerente a entrambi i cluster per controllare il flusso di traffico e migliorare la sicurezza.

Segui il principio del privilegio minimo, il che significa limitare il traffico in entrata e in uscita solo a ciò che è necessario per la funzionalità dell'applicazione.

Deployment

Per scoprire come eseguire il deployment di una topologia basata su questa architettura di riferimento, consulta la documentazione di Red Hat.

Passaggi successivi