Disaster recovery per OpenShift su Google Cloud

RE ripristino di emergenza è essenziale per mantenere la continuità delle tue applicazioni di cui è stato eseguito il deployment su OpenShift Container Platform suGoogle Cloud. Questo documento fornisce una panoramica delle opzioni architetturali per il RE con OpenShift su Google Cloud, aiutando la tua organizzazione a ottenere tempi di inattività minimi e un ripristino rapido 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 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 carichi di lavoro rimangano altamente disponibili e rapidamente recuperabili in caso di errori. I documenti di questa serie sono i seguenti:

Pianificazione RE

La pianificazione del RE è un componente fondamentale per l'esecuzione dei workload di produzione nel cloud. Sebbene OpenShift e Google Cloud offrano una solida ridondanza a livello di infrastruttura, devi anche progettare e configurare le tue applicazioni in modo che si ripristinino rapidamente in caso di guasti catastrofici.

Una pianificazione del DR efficace prevede un approccio a più livelli. Inizia definendo obiettivi di tempo di ripristino (RTO) e obiettivi di punto di ripristino (RPO) chiari per la tua applicazione e il tuo sistema per un rapido ripristino.

Infine, i tuoi segreti e le tue credenziali devono essere recuperabili e gestiti in modo sicuro. Tenendo conto di tutti questi fattori, puoi ottenere una postura di RE che ti consenta di creare rapidamente un nuovo cluster OpenShift in una regione diversa o di eseguire il failover su un cluster secondario inattivo. Questo cluster secondario rimane offline finché non si verifica un errore, a quel punto viene avviato e portato online per rilevare le operazioni con tempi di inattività minimi.

Architetture per il RE

Esistono diverse opzioni per le architetture di deployment che puoi utilizzare perREa con OpenShift su Google Cloud. Ciascuna di queste opzioni ha implicazioni diverse in termini di costi, complessità e disponibilità. La tabella seguente fornisce una panoramica di queste architetture:

Architettura Descrizione Caso d'uso Vantaggi Svantaggi
Attiva-passiva Un cluster è attivo, gestisce tutto il traffico, mentre l'altro è passivo e pronto a subentrare. I dati vengono replicati nel cluster passivo. Adatto per applicazioni con requisiti RTO e RPO moderati. Più semplice da implementare, costi inferiori per il cluster di standby. RTO più elevato a causa del tempo di failover, potenziali ritardi nella sincronizzazione dei dati.
Attivo-non attivo Simile ad attivo-passivo, ma il cluster inattivo non viene utilizzato fino a un eventoREa. Viene eseguito regolarmente il backup dei dati. Ideale per ambienti sensibili ai costi che consentono RTO e RPO più elevati. Costo operativo inferiore quando è inattivo, adatto per RE in cui un sistema secondario non è in esecuzione attiva (RE a freddo) . RTO più elevato a causa del tempo di attivazione e sincronizzazione, anche se esiste la possibilità che i dati diventino obsoleti.
Active-active Entrambi i cluster sono attivi e gestiscono il traffico con il bilanciamento del carico e la replica dei dati tra le regioni. Applicazioni critiche che richiedono tempi di inattività minimi e disponibilità elevata. RTO e RPO più bassi, disponibilità continua. Massima complessità e costi, richiede una rete solida e sincronizzazioni dei dati.

Passaggi successivi