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 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 a elevata disponibilità e rapidamente recuperabili in caso di guasti. I documenti di questa serie sono i seguenti:
- Best practice per il ripristino di emergenza (questa pagina)
- Best practice per l'alta affidabilità
- Strategie di disaster recovery per configurazioni attiva-passiva
- Strategie di disaster recovery per configurazioni attiva-inattiva
Pianificazione del RE
La pianificazione del RE è un componente fondamentale per l'esecuzione dei carichi di lavoro 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 riprendano rapidamente da guasti catastrofici.
Una pianificazione del RE efficace prevede un approccio a più livelli. Inizia definendo obiettivi di tempo di ripristino (RTO) e obiettivi di punto di ripristino (RPO) chiari per l'applicazione e il sistema per un rapido redeployment.
Anche i secret e le 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 a un cluster secondario inattivo. Questo cluster secondario rimane offline fino a quando non si verifica un guasto, a quel punto viene avviato e messo online per assumere le operazioni con tempi di inattività minimi.
Architetture per il RE
Esistono diverse opzioni per le architetture di deployment che puoi utilizzare per il RE con OpenShift su Google Cloud. Ognuna di queste opzioni ha implicazioni diverse per 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. | Adatta per applicazioni con requisiti RTO e RPO moderati. | Più semplice da implementare, costo inferiore per il cluster di standby. | RTO più elevato a causa del tempo di failover, potenziali ritardi nella sincronizzazione dei dati. |
| Attiva-inattiva | Simile ad attiva-passiva, ma il cluster inattivo non viene utilizzato fino a un evento di RE. I dati vengono sottoposti a backup regolarmente. | Ideale per ambienti sensibili ai costi che consentono RTO e RPO più elevati. | Costo operativo inferiore quando è inattivo, adatto per il 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. |
| Attiva-attiva | Entrambi i cluster sono attivi, 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 alta disponibilità. | RTO e RPO più bassi, disponibilità continua. | Complessità e costi più elevati, richiede una rete solida e sincronizzazioni dei dati. |
Passaggi successivi
- Scopri come implementare il monitoraggio e gli avvisi per l'integrità del cluster, lo stato della replica, l'esito positivo del backup e il rendimento delle applicazioni negli ambienti primario e secondario.
- Scopri come installare OpenShift su Google Cloud.
- Scopri di più sulle soluzioni Red Hat su Google Cloud