Strategie di disaster recovery per configurazioni attiva-passiva

Questo documento descrive come pianificare e implementare il disaster recovery attivo-passivo per i deployment di OpenShift su Google Cloud to per aiutarti a ottenere tempi di inattività minimi e un ripristino rapido in caso di emergenza. Fornisce le best practice per il backup dei dati, la gestione della configurazione come codice e la gestione dei secret per garantire che tu possa ripristinare rapidamente le applicazioni in caso di emergenza.

Questo documento è destinato agli amministratori di sistema, agli architetti cloud e agli sviluppatori di applicazioni responsabili del mantenimento della disponibilità e della resilienza delle applicazioni su Red Hat OpenShift Container Platform di cui è stato eseguito il deployment su Google Cloud.

Questo documento fa parte di una serie incentrata sulle strategie a livello di applicazione che garantiscono che i tuoi workload rimangano a elevata disponibilità e rapidamente recuperabili in caso di guasti. Si presuppone che tu abbia letto Best practice per il disaster recovery. I documenti di questa serie sono i seguenti:

Architettura per il ripristino di emergenza

Il seguente diagramma dell'architettura 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 disaster recovery, un cluster OpenShift nella regione principale gestisce tutto il traffico di produzione. Un cluster secondario in un'altra regione è pronto a subentrare in caso di guasto 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, è in standby per il ripristino di emergenza. Il cluster secondario viene mantenuto in stato warm ed è pronto a subentrare con un ritardo minimo in caso di guasto del cluster principale.

Descrizione dei componenti in uno scenario di RE attivo-passivo

Questa architettura ha la seguente configurazione:

  • Cluster OpenShift principale (attivo): situato nella regione principale Google Cloud , questo cluster esegue il workload di produzione e gestisce attivamente tutto il traffico utente in condizioni operative normali.
  • Cluster OpenShift secondario (passivo): situato in una Google Cloud regione separata per l'isolamento dei guasti, questo cluster funge da cluster di standby warm. È parzialmente configurato e in esecuzione ed è pronto a subentrare in caso di guasto del sistema principale. Dispone dell'infrastruttura, della configurazione di OpenShift e dei componenti dell'applicazione necessari, ma non gestisce il traffico di produzione live fino all'attivazione di 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 influisca sul cluster di standby.
  • Bilanciatore del carico HTTP(S) esterno globale: funge da punto di ingresso singolo e globale per il traffico delle applicazioni. In condizioni normali, è configurato per instradare tutto il traffico al cluster principale (attivo). I suoi controlli di integrità monitorano la disponibilità del cluster principale.
  • Meccanismo di replica dei dati: processo o strumenti continui responsabili della copia dei dati essenziali dell'applicazione dal cluster principale al cluster secondario (ad esempio, stato dei database o dei volumi permanenti). Questo approccio garantisce la coerenza dei dati e riduce al minimo la perdita di dati durante un failover, aiutandoti a soddisfare l'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, semi-automatico o completamente automatico) per reindirizzare il traffico dal cluster principale al cluster secondario al rilevamento di un guasto non recuperabile nel cluster principale. In genere, questo processo prevede l'aggiornamento della configurazione del backend del bilanciatore del carico globale in modo che punti al cluster secondario, rendendolo il nuovo sito attivo.
  • Rete VPC: l'infrastruttura di rete sottostante che Google Cloud crea la connettività necessaria tra le regioni per la replica e la gestione dei dati.

Prodotti utilizzati

Casi d'uso

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 tempi di inattività rigorosi e applicazioni aziendali critiche in cui il costo di manutenzione di un cluster di standby warm è giustificato dall'impatto aziendale dei tempi di inattività.

Note sul layout

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

Protezione dello stato e della configurazione dell'applicazione

OpenShift Container Platform fornisce OADP e offre una protezione completa per il disaster recovery delle 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 sull'archiviazione a blocchi e sugli archivi NFS utilizzati dalle applicazioni. Puoi eseguire queste operazioni utilizzando strumenti come 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 l'RPO e l'RTO in una configurazione attiva-passiva, ti consigliamo di configurare la replica dei dati tra le regioni principale 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 principali a quelli secondari dipende dal tipo di archiviazione utilizzato dall'applicazione.

Archiviazione a blocchi (volumi permanenti)

Utilizza la replica asincrona di Persistent Disk di Google per copiare i dati dalla regione principale a quella secondaria. In questo approccio, crei un disco principale nella regione principale, un disco secondario nella regione secondaria e configuri la replica tra di essi. L'utilizzo di gruppi coerenti garantisce che entrambi i dischi contengano dati di replica di un momento specifico comune, che viene poi utilizzato per RE. Per saperne di più, consulta Configurare la replica asincrona di Persistent Disk.

Oggetti PersistentVolume

In OpenShift, crea oggetti PersistentVolume in entrambi i cluster che si collegano a questi dischi e assicurati che le applicazioni utilizzino le stesse Persistent Volume Claims (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 tra i cluster. Puoi anche utilizzare un servizio gestito come Pub/Sub per facilitare la replica di tipi specifici di dati o eventi dell'applicazione.

Backup dei database

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

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

Gli operatori di database come l'operatore CloudNative PostgreSQL possono facilitare i backup pianificati e ripristino di emergenza per i cluster PostgreSQL. L'operatore CloudNative PostgreSQL si integra in modo nativo con strumenti come pg_basebackup e supporta i backup di 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 principali e secondari per garantire che i dati siano disponibili anche in caso di interruzione nella regione principale. In genere, questa replica in streaming è 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 hanno funzionalità di backup e replica integrate. Ti consigliamo di configurare la replica asincrona dall'istanza del database principale a una replica nella regione secondaria. Per saperne di più, consulta Informazioni sulla replica in Cloud SQL. In OpenShift, configura i secret o le config map in modo che puntino alle stringhe di connessione del database corrette per ogni cluster.

Poiché la replica asincrona genera un RPO diverso da zero, esiste la possibilità di perdere le scritture di dati più recenti. Devi progettare l'applicazione in modo da mitigare la perdita di dati. In alternativa, puoi utilizzare un altro metodo di replica.

Ti consigliamo inoltre di attivare i backup automatici di Cloud SQL. Per saperne di più, consulta Creare e gestire backup on demand e automatici.

Processo di failover

In caso di guasto del cluster principale, Cloud DNS reindirizza automaticamente il traffico al cluster regionale secondario in base ai controlli di integrità e ai criteri 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 di Google Cloud SQL ripristino di emergenza recovery. L'utilizzo della replica asincrona del database o dell'archiviazione causa un RPO diverso da zero per 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 le password dei database, le chiavi API e i certificati TLS sono aspetti importanti del RE Devi essere in grado di ripristinare questi secret in modo sicuro e affidabile in un nuovo cluster.

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

  • Utilizzare secret esterni: utilizza uno strumento come l' operatore di secret esterni per recuperare i secret da Google Secret Manager.
  • Eseguire 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 strategia di gestione dei secret supporti gli 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 HTTP(S) esterno globale di Google Cloudcome punto di ingresso principale per distribuire il traffico tra più cluster OpenShift (ad esempio, cluster principali 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:

  • Utilizzare i bilanciatori del carico regionali (NEG internet): configura Google Cloud i gruppi di endpoint di rete (NEG) internet in modo che puntino a gli indirizzi IP esterni dei bilanciatori del carico regionali che espongono ciascuno dei servizi di ingresso (router OCP) dei cluster OpenShift. Il bilanciatore del carico globale instrada quindi il traffico a questi IP del bilanciatore del carico regionale. Questo approccio fornisce un livello di astrazione, ma comporta un hop a una rete aggiuntiva.
  • Routing diretto dei pod (Compute Engine_VM_IP_PORT NEGs): configura l'integrazione del controller Ingress di OpenShift in modo che utilizzi Google Cloud i gruppi di endpoint di rete (NEG) di tipo Compute Engine_VM_IP_PORT. Questo approccio consente al bilanciatore del carico globale di indirizzare direttamente i pod del controller Ingress di OpenShift (router) utilizzando il relativo PodIP:TargetPort interno. Questo metodo ignora l'hop aggiuntivo e il proxying dei nodi aggiuntivi. In genere, comporta 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 in modo efficace la distribuzione del traffico tra i cluster in regioni diverse. Per saperne di più, consulta Configurare 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 sia per i cluster principali sia per quelli secondari. Questo approccio semplifica l'amministrazione e garantisce criteri di rete coerenti tra le regioni.
  • Routing dinamico globale: attiva il routing dinamico globale all'interno dei VPC per propagare automaticamente le route tra le regioni, garantendo una connettività senza interruzioni 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. Questo è spesso necessario per il networking dei pod nativo del 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 non ci siano intervalli IP sovrapposti tra le regioni per evitare problemi di routing.

Traffico tra cluster con Red Hat Service Mesh

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

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

Deployment

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

Passaggi successivi