Strategie di disaster recovery per configurazioni attivo-inattivo

Questo documento descrive come pianificare e implementare il disaster recovery attivo-inattivo per i deployment di OpenShift Google Cloud per aiutarti a ridurre al minimo i tempi di inattività e a eseguire un recupero rapido in caso di disastro. 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 workload rimangano a elevata disponibilità e rapidamente recuperabili in caso di guasti. Si presuppone che tu abbia letto le best practice per il ripristino di emergenza. I documenti di questa serie sono i seguenti:

Architettura per il ripristino di emergenza

RE attivo-inattivo prevede la manutenzione di una regione secondaria come standby, che viene attivata solo durante le emergenze. A differenza delle configurazioni attivo-passive, in cui i dati vengono replicati continuamente, questa strategia si basa su backup periodici archiviati in Cloud Storage, con l'infrastruttura di cui è stato eseguito il provisioning e i dati ripristinati 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 obiettivi di tempo di ripristino (RTO) e obiettivi di punto di ripristino (RPO) estesi.

In uno scenario di RE attivo-inattivo, i dati vengono sottoposti a backup regolarmente nella regione di standby, ma non vengono replicati attivamente. Il provisioning dell'infrastruttura viene eseguito nell'ambito del processo di failover e i dati vengono ripristinati dall'ultimo backup. Puoi utilizzare l'API OpenShift per la protezione dei dati (OADP), basata sul progetto open source Velero, per eseguire backup regolari. Ti consigliamo di archiviare questi backup nei 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 RTO più lunghi e RPO potenzialmente più elevati rispetto a quelli attivo-passivi. Questa configurazione è adatta per applicazioni con obiettivi di tempo di ripristino più lunghi.

Il seguente diagramma mostra un deployment attivo-inattivo e il processo di failover:

Processo di failover.

La procedura di failover è la seguente:

  1. Viene attivato un evento di RE 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 da puntare ai bilanciatori del carico a livello di regione nella regione di RE.

Come mostrato nel diagramma precedente, vengono sottoposti a deployment due cluster regionali OpenShift separati, ognuno in una regione diversa, Google Cloud ad esempio us-central1 e europe-west1. Ogni cluster deve essere a elevata disponibilità 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). Il provisioning dell'infrastruttura (istanze Compute Engine e OCP) viene eseguito durante il failover.
  • Archiviazione di backup: i bucket Google Cloud Storage archiviano i backup periodici (OADP o Velero per gli oggetti dell'applicazione, nonché i backup dei PV e dei 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 principale per eseguire backup pianificati in Cloud Storage.
  • Orchestrazione: gli script o gli strumenti di automazione attivano i processi di provisioning e ripristino dell'infrastruttura durante il failover.

Prodotti utilizzati

Casi d'uso

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

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

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 tuoi requisiti specifici in termini di sicurezza, affidabilità, costi e prestazioni.

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 abilitando la sincronizzazione con uno stato noto per essere in esecuzione in modo affidabile in un altro cluster. I backup assicurano di avere snapshot dello stato di runtime, ma è anche necessario un modo affidabile per eseguire rapidamente il redeployment della logica dell'applicazione, dei manifest e delle definizioni dell'infrastruttura dopo un'emergenza.

Utilizzare l'operatore OpenShift GitOps

L'operatore OpenShift GitOps, basato su Argo CD, fornisce un modo supportato da Red Hat per implementare i 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 mancano, le riconcilia automaticamente. Per saperne di più, consulta Informazioni su Red Hat OpenShift GitOps.

Esecuzione dello scenario di RE

In caso di disastro, procedi come segue:

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

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

Per evitare problemi durante RE, ti consigliamo di:

  • Mantieni strategie di ramificazione e tagging rigorose nel repository Git in modo da poter identificare le 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 che devi 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