Automatizza il cold disaster recovery per il database OCI con PostgreSQL utilizzando OCI Full Stack Disaster Recovery

Introduzione

Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) gestisce la transizione di elaborazione, database e applicazioni tra le region OCI in tutto il mondo con un solo clic. I clienti possono automatizzare i passi necessari per ripristinare uno o più sistemi aziendali senza riprogettare o riprogettare l'infrastruttura, i database o le applicazioni esistenti e senza aver bisogno di server di gestione o conversione specializzati.

OCI Database con PostgreSQL è un servizio completamente gestito compatibile con PostgreSQL con dimensionamento intelligente, ottimizzazione e durabilità elevata. Il servizio ridimensiona automaticamente lo storage man mano che le tabelle di database vengono create ed eliminate, semplificando la gestione e ottimizzando la spesa per lo storage. I dati vengono cifrati sia in transito che in archivio. OCI Database con PostgreSQL è progettato per l'alta disponibilità offrendo durabilità anche in caso di errore del dominio di disponibilità (AD).

In questa esercitazione verrà descritto come automatizzare un disaster recovery a freddo per OCI Database con PostgreSQL. Descrive le procedure di utilizzo del servizio OCI Full Stack DR per gestire i processi di switchover e failover.

Nota: questo tipo di strategia di Disaster Recovery (DR) si basa su un meccanismo di backup e ripristino, rendendolo più adatto per applicazioni non critiche in cui i requisiti aziendali per Recovery Time Objectives (RTO) e Recovery Point Objectives (RPO) non sono eccessivamente impegnativi.

Descrizione architettura

L'architettura presentata in questa esercitazione mostra un'applicazione Web tipica in esecuzione su virtual machine (VM) OCI perfettamente integrata con il database OCI con PostgreSQL.

Un load balancer OCI viene distribuito all'interno di una subnet pubblica in entrambe le aree per gestire in modo efficiente le connessioni utente esterne. Gli utenti dell'applicazione vengono instradati ai backend attualmente attivi nell'area X tramite lo sterzo del traffico DNS.

Descrizione dell'immagine fsdr_psql_backup_restore_dr-Physical_Architecture.png

Descrizione dell'architettura per il disaster recovery

La strategia DR per questa applicazione Web prevede un approccio completo, inclusa la replica completa del volume di avvio della VM con replica del gruppo di volumi.

Per OCI Database con PostgreSQL, la copia di backup è abilitata per copiare regolarmente il backup automatico nell'area remota per garantire la protezione dei dati e la disponibilità del disaster recovery.

fsdr_psql_backup_restore_dr-Physical_DR_Architecture.png

Descrizione dell'immagine fsdr_psql_backup_restore_dr-Physical_DR_Architecture.png

La soluzione di recupero per questa distribuzione richiede che OCI Full Stack DR esegua una serie di script Python personalizzati durante un'operazione di recupero, ad esempio un failover o uno switchover.

Gli script a cui si fa riferimento in questa esercitazione vengono forniti dal team di ingegneria tecnologica dell'area EMEA e sono disponibili qui: ripristino di emergenza completo dello stack, creato appositamente per questa soluzione di DR.

Questa esercitazione spiega come scaricare gli script e come utilizzarli in un task successivo.

Nota: per indicazioni generiche vengono forniti gli script riportati di seguito. È possibile utilizzare script personalizzati o personalizzarli in base ai criteri aziendali e ai requisiti di sicurezza.

Viene eseguito il pre-provisioning di un load balancer nell'area remota, assicurandosi che sia pronto a gestire il traffico senza problemi quando la VM dell'applicazione Web viene passata all'area remota durante uno switchover o un failover scenario, come visibile nel diagramma riportato di seguito, lo switchover continuo del load balancer è garantito da un criterio di indirizzamento DNS con un instradamento associato al controllo dello stato al set backend del load balancer attualmente disponibile. Per ulteriori informazioni, vedere Gestione del traffico OCI.

Il listener del load balancer viene impostato sulle porte 80 (frontend) e 8000 (API) e viene instradato rispettivamente alle porte 3000 e 8585 nella configurazione predefinita.

fsdr_psql_backup_restore_dr-Physical_Network_Architecture.png

Descrizione dell'immagine fsdr_psql_backup_restore_dr-Physical_Network_Architecture.png

Il diagramma seguente illustra il flusso di lavoro per la copia di backup automatico dall'area primaria all'area remota.

fsdr_psql_backup_restore_dr-Logical_Workflow_Auto_Copy_Backup_to_Remote.png

Descrizione dell'immagine fsdr_psql_backup_restore_dr-Logical_Workflow_Auto_Copy_Backup_to_Remote.png

In questo caso, è possibile pianificare l'esecuzione giornaliera dei backup e quindi copiarli in un'area remota per un'ulteriore ridondanza, con conseguente RPO (Recovery Point Objective) di 24 ore.

Nota:

Assicurarsi di abilitare il backup automatico e abilitare la copia di backup nell'area remota. Senza questo passo, il processo di ripristino potrebbe non riuscire a causa della mancata disponibilità del backup nell'area secondaria.

In questa esercitazione ci concentriamo sull'automazione delle attività di creazione, trasferimento in un'altra area e creazione di un nuovo sistema di database dal backup. Questi stessi passi possono essere eseguiti manualmente seguendo il nostro database OCI con la documentazione PostgreSQL descritta.

Backup manuale di un sistema di database.

Copia di un database OCI con backup PostgreSQL in un'altra area.

Creazione di un sistema di database da un backup.

Se il caso d'uso richiede un RPO più breve, la soluzione sarebbe quella di pianificare backup più frequenti e utilizzare gli script forniti (psql_create_bkp.py e psql_copy_bkp.py) per attivare manualmente i backup e copiarli nell'area remota, in base ai requisiti aziendali. Inoltre, è possibile utilizzare psql_copy_config.py per copiare il database OCI con la configurazione PostgreSQL nell'area remota, necessaria per ripristinare le estensioni e i parametri dei sistemi di database.

fsdr_psql_backup_restore_dr-Logical_Workflow_Manual_Backup_Copy_to_Remote.png

Descrizione dell'immagine fsdr_psql_backup_restore_dr-Logical_Workflow_Manual_Backup_Copy_to_Remote.png

Tutti gli script sono disponibili su GitHub e sono dettagliati nelle seguenti sezioni.

Nota: assicurarsi di pianificare questo script (o uno simile) in base ai requisiti aziendali per eseguire regolarmente un backup e copiarlo nell'area remota. Senza questo passo, il processo di ripristino potrebbe non riuscire a causa della mancata disponibilità del backup nell'area secondaria.

Come funziona il recupero?

Dopo l'esecuzione di uno switchover pianificato, i ruoli verranno invertiti: il carico di lavoro primario verrà eseguito nell'Area 2, mentre lo standby funzionerà nell'Area 1. L'architettura apparirà come segue:

fsdr_psql_backup_restore_dr-Physical_Switchover_Architecture.png

Descrizione dell'immagine fsdr_psql_backup_restore_dr-Physical_Switchover_Architecture.png

Nell'impostazione corrente, utilizziamo il servizio DNS privato OCI per gestire un record DNS che indirizza il traffico al database OCI attivo con l'endpoint PostgreSQL. Durante il processo di recupero, questo record DNS viene aggiornato tramite uno script personalizzato (psql_update_dns.py) per riflettere il nuovo database OCI con PostgreSQL, garantendo switchover o failover senza interruzioni e continuità del servizio.

Il diagramma riportato di seguito illustra il workflow per il ripristino del database OCI più recente con il backup PostgreSQL nella standby region, che diventa quindi la nuova region primaria.

fsdr_psql_backup_restore_dr-Logical_Workflow_Switchover_to_Remote.png

Descrizione dell'immagine fsdr_psql_backup_restore_dr-Logical_Workflow_Switchover_to_Remote.png

Definizioni e ipotesi in tutta l'esercitazione

Aree:
- Area 1 (Dubai): Dubai fungerà inizialmente da regione principale. Tuttavia, questo ruolo passerà allo standby durante il processo di switchover, che verrà eseguito nei task successivi nell'ambito del piano di disaster recovery.
- Area 2 (Abu Dhabi): Abu Dhabi inizialmente funzionerà come standby region. Questo ruolo passerà successivamente a primario dopo il processo di switchover, che verrà eseguito nei task successivi nell'ambito della procedura di disaster recovery.
Compartimenti: sei libero di organizzare questa distribuzione e OCI Full Stack DR in qualsiasi schema di compartimento che funzioni all'interno dei tuoi standard per la governance IT. Abbiamo scelto di organizzare tutte le risorse OCI per questa esercitazione in un unico compartimento.

Virtual machine applicazione Web

L'applicazione Web in questa esercitazione ha lo scopo di mostrare l'architettura dello scenario end-to-end, un singolo script di distribuzione (deploy_application_demo.sh) configurerà e distribuirà lo stack dell'applicazione nella VM dell'applicazione Web. Ulteriori istruzioni sulla distribuzione dell'applicazione sono disponibili nel repository qui: link-to-web-app-sample

Anteprima frontend: le righe visibili nel report provengono direttamente dal database OCI con PostgreSQL.

webapp frontend-preview.png

Descrizione dell'illustrazione webapp-frontend-preview.png

Obiettivi

Questa esercitazione descrive i task riportati di seguito.

Task 1: Preparare l'ambiente per il disaster recovery.
Task 2: Creare gruppi di protezione DR (DRPG) in entrambe le aree.
Task 3: Aggiungere membri al gruppo di protezione DR.
Task 4: Creazione di piani DR di base nell'area 2.
Task 5: Personalizzare il piano di switchover nell'area 2.
Task 6: Personalizzare il piano di failover nell'area 2.
Task 7: eseguire i controlli preliminari dei piani DR nell'area 2.
Task 8: eseguire il piano di switchover nell'area 2.
Task 9: Creazione e personalizzazione dei piani DR nell'area 1.
Task 10: eseguire il piano di failover nell'area 1.

Task 1: Preparare l'ambiente per il disaster recovery

Task 1.1: Creare gruppi di volumi e abilitare la replica

Creare un gruppo di volumi per la VM dell'applicazione Web di esempio nell'area 1 e assicurarsi che venga replicato nell'area 2. Assicurarsi che il volume di avvio per ogni VM dell'applicazione (esempio WebApp) sia un membro del gruppo di volumi e che il gruppo di volumi sia replicato nell'area 2.

Le immagini seguenti mostrano il gruppo di volumi creato, che include i volumi di avvio della VM dell'applicazione Web, con la replica abilitata all'area 2. Per ulteriori informazioni, vedere Creazione di un gruppo di volumi.

Descrizione dell'illustrazione psql-webapp-create-vol-grp.png

Descrizione dell'illustrazione psql-webapp-create-vol-grp-2.png

Descrizione dell'illustrazione psql-webapp-create-vol-grp-3.png

Dopo aver configurato la replica tra più aree, fare clic su Successivo finché non si accede a Riepilogo e fare clic su Crea.

Task 1.2: Preparare la VM dell'applicazione Web per la distribuzione automatica

Scaricare/chiudere il repository GitHub da qui: (oci-postgressql-colddr) nella cartella /home/opc.
Rendere eseguibile lo script.
```
chmod +x deploy_application_demo.sh
```
Aggiornare lo script deploy_application_demo.sh con i dettagli necessari per l'applicazione Web e il database OCI con PostgreSQL in entrambe le aree.
- WEBAPP_HOME: posizione root della distribuzione (posizione da cui viene eseguito lo script). Ad esempio, /home/opc.
- WEBAPP_URL: URL che punta alla computazione con l'API http://webapi.yoururl.eu:8000.
- PRIMARY_REGION: area principale OCI. Il formato è eu-frankfurt-1.
- STANDBY_REGION: standby region OCI.
- PRIMARY_SECRET_OCID: l'OCID segreto del vault OCI con la password PostgreSQL nell'area primaria (ocid1.vaultsecret.oc1.me-dubai-1.xxxxxx).
- STANDBY_SECRET_OCID: l'OCID segreto del vault OCI con la password PostgreSQL nell'area di standby (ocid1.vaultsecret.oc1.me-abudhabi-1.xxxxxx).
- PG_USER: l'utente del database utilizzato per caricare i dati di esempio (postgresql_sample.sql).
- PG_DB: il database utilizzato per caricare i dati di esempio. Il valore predefinito è postgres.
- PG_HOST: FQDN della voce della zona privata per il database.
Nota:
- Assicurarsi che tutti i valori siano aggiornati in modo accurato.
- Quando si utilizza la configurazione predefinita, è possibile lasciare invariati altri parametri.
Eseguire lo script deploy_application_demo.sh.
```
./deploy_application_demo.sh
```
In questo modo verranno distribuiti il frontend, il backend, i servizi di configurazione e il firewall.

Dopo la distribuzione riuscita, viene visualizzato il messaggio Distribuzione completata.

Come parte dell'esercitazione, utilizzeremo questa stessa VM per eseguire script definiti dall'utente. Assicurarsi che la VM che funge da nodo di controllo DR sia stata configurata per l'esecuzione dei comandi. Per ulteriori informazioni, vedere Richiamare script personalizzati utilizzando il comando di esecuzione con Oracle Cloud Infrastructure Full Stack Disaster Recovery.

Task 1.3: Crea criterio di indirizzamento Web

Per garantire che la nostra applicazione punti sempre all'area attiva, è possibile utilizzare un criterio di indirizzamento per la gestione del traffico failover. Il criterio di indirizzamento in combinazione con il servizio OCI Health Checks convalida l'endpoint dell'applicazione ogni 60 secondi (TTL predefinito) tramite il monitoraggio HTTP.

Andare alla console OCI e andare a Networking.
Fare clic su Criteri di indirizzamento per la gestione di traffico.

Descrizione dell'illustrazione oci-web-steering-policies-nav.png
Fare clic su Crea criterio di indirizzamento per la gestione di traffico.

Descrizione dell'illustrazione psql-webapp-dns-create.png
1. Selezionare Failover come tipo di criterio.
  1. Immettere un Nome per il criterio di indirizzamento.
  2. Selezionare il compartimento per il criterio di indirizzamento.
  3. Selezionare un TTL in base alle proprie esigenze.
  Descrizione dell'illustrazione psql-webapp-dxb-dns-create-failover.png
2. Configurare il pool di risposte 1, puntando al load balancer nell'area 1.
  1. Immettere un nome significativo per il pool.
  2. Selezionare Un record come Tipo.
  3. Immettere l'IP del load balancer dell'applicazione Web nell'area 1.
  Descrizione dell'illustrazione psql-webapp-dxb-dns-create-pool-1.png
3. Configurare il pool di risposte 2, puntando al load balancer nell'area 2.
  1. Immettere un nome per il pool.
  2. Selezionare Un record come Tipo.
  3. Immettere l'IP del load balancer dell'applicazione Web nell'area 2.
  Descrizione dell'illustrazione psql-webapp-dxb-dns-create-pool-2.png
4. Configurare Priorità pool. Questa priorità di contesto viene assegnata all'area 1.
  
  Descrizione dell'illustrazione psql-webapp-dxb-dns-create-pool-priority.png
5. Fare clic su Aggiungi nuovo per allegare un criterio di controllo dello stato OCI.
  1. Selezionare Tipo richiesta come HTTP.
  2. Immettere un nome per il controllo dello stato.
  3. Selezionare il compartimento per il controllo dello stato.
  Descrizione dell'illustrazione psql-webapp-dxb-dns-create-healthcheck.png
6. Fare clic su Opzioni avanzate.
  1. Immettere la porta dell'applicazione Web, in questo caso 80.
  2. Immettere il percorso dell'applicazione Web, in questo caso /.
  3. Selezionare GET come Metodo.
  4. Selezionare un timeout per la richiesta.
  Descrizione dell'illustrazione psql-webapp-dxb-dns-create-healthcheck-details.png
7. Configurare i domini collegati.
  1. Immettere il sottodominio per l'endpoint webapi.
  2. Selezionare il compartimento contenente la zona (dominio).
  3. Selezionare la zona appropriata.
  4. Ripetere i passi da 1 a 3 per l'endpoint webapp.
  Descrizione dell'illustrazione psql-webapp-dxb-dns-create-domains.png
8. Verificare che tutti i dettagli siano corretti e fare clic su Crea criterio di indirizzamento di gestione del traffico. Dopo un po' di tempo, la creazione dovrebbe mostrare il valore completato.
  
  Descrizione dell'illustrazione psql-webapp-dxb-dns-create-complete.png
9. È possibile visualizzare la panoramica della creazione successiva al criterio di indirizzamento. Alla fine della pagina è possibile visualizzare il controllo dello stato allegato.
  
  Descrizione dell'illustrazione psql-webapp-dxb-dns-create-details.png
  1. Fare clic su Controllo dello stato associato.
  2. Andare a Cronologia controllo stato.
  3. Qui puoi visualizzare il load balancer attualmente disponibile e la disponibilità passata.
    
    Descrizione dell'illustrazione psql-webapp-dxb-healthcheck-history.png

Task 1.4: Creare criteri di Oracle Cloud Infrastructure Identity and Access Management per OCI Full Stack DR

Per configurare i criteri IAM OCI necessari per OCI Full Stack DR, vedere:

Task 1.5: creare criteri IAM OCI per altri servizi gestiti da OCI Full Stack DR

OCI Full Stack DR deve avere la capacità di controllare e gestire altri servizi OCI principali come computazione, rete, storage e altri servizi vari. Per configurare le policy IAM OCI necessarie per altri servizi, consulta le policy per altri servizi gestiti da Full Stack Disaster Recovery e le policy IAM OCI.

Task 2: Creazione di gruppi di protezione DR (DRPG) in entrambe le aree

Creare i gruppi di protezione DR nell'area 1 e nell'area 2 se i gruppi di protezione per questo stack di applicazioni non esistono ancora.

Task 2.1: Creare un gruppo di protezione nell'area 1

Andare alla console OCI e andare a Gruppi di protezione DR.
1. Assicurarsi che il contesto dell'area OCI sia impostato su Area 1 (Dubai).
2. Fare clic su Migrazione e disaster recovery.
3. Fare clic su Gruppi di protezione DR.
Descrizione dell'illustrazione psql-webapp-dxb-drpg-intro.png
Creare un gruppo di protezione DR (DRPG) di base nell'area 1. Il peer, il ruolo e i membri verranno assegnati nei passi successivi.
1. Selezionare il compartimento in cui si desidera creare il DRPG.
2. Fare clic su Crea gruppo di protezione DR per aprire la finestra di dialogo.
3. Inserire Nome per DRPG.
4. Selezionare Bucket di storage degli oggetti OCI per i log OCI Full Stack DR.
5. Fare clic su Crea.
Descrizione dell'illustrazione psql-webapp-dxb-drpg.png

Task 2.2: Creare un gruppo di protezione nell'area 2

Andare alla console OCI e andare a Gruppi di protezione DR.
1. Assicurati che il contesto dell'area OCI sia impostato su Area 2 (Abu Dhabi).
2. Fare clic su Migrazione e disaster recovery.
3. Fare clic su Gruppi di protezione DR.
Descrizione dell'illustrazione psql-webapp-dxb-drpg-intro.png
Creare un gruppo di protezione DR (DRPG) di base nell'area 2. Il peer, il ruolo e i membri verranno assegnati nei passi successivi.
1. Selezionare il compartimento in cui si desidera creare il DRPG.
2. Fare clic su Crea gruppo di protezione DR per aprire la finestra di dialogo.
3. Inserire Nome per DRPG.
4. Selezionare Bucket di storage degli oggetti OCI per i log OCI Full Stack DR.
5. Fare clic su Crea.
Descrizione dell'illustrazione psql-webapp-auh-drpg.png

Task 2.3: Associa gruppi di protezione nell'area 1 e nell'area 2

Associa i DRPG in ogni region come peer e assegna i ruoli peer di database primario e standby. I ruoli primario e standby vengono modificati automaticamente da OCI Full Stack DR nell'ambito di qualsiasi operazione di DR/esecuzione del piano DR; non è necessario gestire i ruoli manualmente in qualsiasi momento.

Andare alla pagina Dettagli gruppo protezione DR.
1. Assicurarsi che il contesto dell'area OCI sia impostato su Area 1 (Dubai).
2. Fare clic su Associa per avviare il processo.
Descrizione dell'illustrazione psql-webapp-dxbauh-drpg.png
Immettere i parametri come mostrato nell'immagine seguente.
1. Ruolo: selezionare il ruolo Principale. OCI Full Stack DR assegnerà automaticamente il ruolo di standby all'area 2.
2. Area peer: selezionare l'area 2 (Abu Dhabi), dove è stato creato l'altro DRPG.
3. Gruppo di protezione Peer DR: selezionare il gruppo DRPG peer creato.
4. Fare clic su Associa.
Descrizione dell'illustrazione psql-webapp-dxbauh-drpg-associate.png

OCI Full Stack DR mostrerà qualcosa come mostrato nell'immagine seguente, una volta completata l'associazione.

L'attuale principale peer DRPG è Dubai (regione 1).
L'attuale peer di standby DRPG è Abu Dhabi (regione 2).

Descrizione dell'illustrazione psql-webapp-dxbauh-drpg-primary.png

Le stesse informazioni possono essere trovate ogni volta che il contesto/vista è da una prospettiva globale che mostra tutti i gruppi di protezione DR come mostrato nell'immagine seguente.

L'attuale principale peer DRPG è Dubai (regione 1).
L'attuale peer di standby DRPG è Abu Dhabi (regione 2).

Descrizione dell'illustrazione psql-webapp-dxbauh-drpg-standby.png

Task 3: Aggiunta di membri al gruppo di protezione DR

In questo task, aggiungeremo le seguenti risorse OCI al DRPG principale nell'area 1.

Le istanze di computazione che ospitano l'applicazione Web verranno aggiunte come VM in movimento.
Gruppo di volumi contenente il volume di avvio del nodo di calcolo dell'applicazione Web.
Il load balancer principale.

Task 3.1: Aggiungi membri a DRPG nell'area 1

Selezionare il DRPG nell'area 1 come mostrato nell'immagine seguente.
1. Assicurarsi che il contesto dell'area OCI sia Area 1 (Dubai).
2. Selezionare il DRPG nell'area 1.
3. Selezionare Membri.
4. Fare clic su Aggiungi membro per avviare il processo.
Descrizione dell'illustrazione psql-webapp-dxb-drpg-add.png
Aggiungere un'istanza di computazione per la VM dell'applicazione Web.
1. Confermare l'avvertenza relativa ai piani DR.
2. Immettere Computazione come membro Tipo di risorsa.
3. Selezionare l'istanza di computazione che ospita l'applicazione Web.
4. Selezionare Spostamento istanza.
5. Fare clic su Aggiungi mapping VNIC per selezionare la VCN e la subnet da assegnare alle VNIC nell'area 2 durante un recupero.
6. Fare clic su Visualizza opzioni avanzate.
7. In Impostazioni, selezionare Mantieni dominio di errore.
8. Verificare i dettagli e fare clic su Aggiungi.
Descrizione dell'illustrazione psql-webapp-dxb-drpg-add-compute.png

Descrizione dell'illustrazione psql-webapp-dxb-drpg-add-compute-vnic.png

Descrizione dell'illustrazione psql-webapp-dxb-drpg-add-compute-vnic-details.png

Descrizione dell'illustrazione psql-webapp-dxb-drpg-add-compute-detail.png
Aggiungere il gruppo di volumi a blocchi contenente il volume di avvio della VM dell'applicazione Web.
1. Confermare l'avvertenza relativa ai piani DR.
2. Selezionare Gruppo di volumi come membro Tipo di risorsa.
3. Assicurarsi che sia selezionato il compartimento corretto contenente il gruppo di volumi e selezionare il gruppo di volumi.
4. Verificare i dettagli e fare clic su Aggiungi.
Descrizione dell'illustrazione psql-webapp-dxb-drpg-add-volgrp.png
In questo esempio, aggiungeremo OCI Load Balancer come membro del DRPG nell'area 1.
1. Confermare l'avvertenza relativa ai piani DR.
2. Selezionare Load balancer come membro Tipo di risorsa.
3. Assicurarsi che siano selezionati i compartimenti corretti per il load balancer e selezionare il load balancer che si desidera aggiungere.
4. Selezionare Destination Load balancer da utilizzare nell'area 2.
5. Selezionare Set backend di origine, ovvero il set backend utilizzato dalla VM dell'applicazione Web. Un load balancer OCI può essere condiviso tra più applicazioni e può avere più set backend configurati. Durante uno switchover DR, solo i set backend specificati qui verranno spostati nella standby region.
6. Selezionare Set backend di destinazione, ovvero il set backend vuoto creato nell'area 2.
7. Verificare i dettagli e fare clic su Aggiungi.
Descrizione dell'illustrazione psql-webapp-dxb-drpg-add-lb.png

Descrizione dell'illustrazione psql-webapp-dxb-drpg-add-lb-details.png
Verificare che la sezione Membri contenga il load balancer, il gruppo di volumi e l'istanza di computazione.

Descrizione dell'illustrazione psql-webapp-dxb-drpg-members.png

Task 3.2: Aggiungi membri a DRPG nell'area 2

Selezionare il DRPG nell'area 2 come mostrato nell'immagine seguente.
1. Assicurati che il contesto dell'area OCI sia l'Area 2 (Abu Dhabi).
2. Selezionare il DRPG nell'area 2.
3. Selezionare Membri.
4. Fare clic su Aggiungi membro per avviare il processo.
Descrizione dell'illustrazione psql-webapp-auh-drpg-add.png
In questo esempio, aggiungeremo OCI Load Balancer come membro del DRPG nell'area 2.
1. Confermare l'avvertenza relativa ai piani DR.
2. Selezionare Load balancer come membro Tipo di risorsa.
3. Assicurarsi che sia selezionato il compartimento corretto per il load balancer e selezionare il load balancer che si desidera aggiungere.
4. Selezionare il load balancer di destinazione da utilizzare nell'area 1.
5. Selezionare Set backend di origine, ovvero il set backend utilizzato dalla VM dell'applicazione Web. Un load balancer OCI può essere condiviso tra più applicazioni e può avere più set backend configurati. Durante uno switchover DR, solo i set backend specificati qui verranno spostati nella standby region.
6. Selezionare Set backend destinazione. Questo set backend viene creato nell'area 2.
7. Verificare i dettagli e fare clic su Aggiungi.
Descrizione dell'illustrazione psql-webapp-aux-drpg-add-lb.png

Descrizione dell'illustrazione psql-webapp-dxb-drpg-add-lb-details.png
Verificare che la sezione Membri contenga il load balancer.

Descrizione dell'illustrazione psql-webapp-aux-drpg-members.png

Task 4: Creazione di piani DR di base nell'area 2

In questa attività, creeremo i piani di switchover e failover iniziali associati al gruppo di protezione DR in standby nell'area 2 (Abu Dhabi).

Lo scopo di questi piani è quello di trasferire senza problemi il carico di lavoro dalla region primaria (Regione 1) alla standby region (Regione 2). Come parte di qualsiasi operazione di DR, i ruoli dei gruppi di protezione DR in entrambe le aree vengono automaticamente invertiti: il gruppo di protezione nell'Area 1 diventa lo standby, mentre il gruppo di protezione nell'Area 2 assume il ruolo primario dopo un failover o uno switchover.

OCI Full Stack DR precompilerà questi piani con passi integrati derivati dalle risorse dei membri aggiunte durante i task precedenti. Questi piani verranno in seguito personalizzati per gestire task specifici del database OCI con PostgreSQL durante il processo di recupero.

I piani di switchover vengono sempre creati all'interno del gruppo di protezione che detiene il ruolo di standby. Poiché la Regione 2 (Abu Dhabi) è attualmente il gruppo di protezione standby, inizieremo a creare i piani lì.

Task 4.1: Creazione di piani DR

Creare un piano di base selezionando il DRPG nella Regione 2 (Abu Dhabi)
1. Assicurati che il contesto dell'area OCI sia l'Area 2 (Abu Dhabi).
2. Selezionare il DRPG in standby nell'area 2.
3. Selezionare Piani.
4. Fare clic su Crea piano per avviare il processo.
Descrizione dell'illustrazione psql-webapp-auh-drpg-create.png
Creare un piano di switchover.
1. Immettere un nome semplice ma significativo per il piano di switchover. Il nome dovrebbe essere il più breve possibile, ma facile da capire a colpo d'occhio per contribuire a ridurre la confusione e l'errore umano durante una crisi.
2. Selezionare Tipo piano come Switchover (pianificato).
3. Fare clic su Crea.
Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover.png
Creare un piano di failover. Seguire lo stesso processo per creare un piano di failover di base come mostrato nell'immagine seguente.
1. Immettere il nome del piano di failover.
2. Selezionare Tipo di piano come Failover (non pianificato).
3. Fare clic su Crea.
Descrizione dell'illustrazione psql-webapp-auh-drpg-create-failover.png

Il gruppo di protezione DR in standby nell'area 2 ora dovrebbe avere i due piani DR come mostrato nell'immagine seguente. Questi gestiranno la transizione dei carichi di lavoro dall'area 1 all'area 2. Si creeranno piani simili nell'area 1 per eseguire la transizione dei carichi di lavoro dall'area 2 all'area 1 in un task successivo.

Descrizione dell'illustrazione psql-webapp-auh-drpg-plans.png

Task 5: Personalizzazione del piano di switchover nell'area 2

I piani DR di base creati nel Task 4 contengono passi precompilati per i task di recupero integrati in OCI Full Stack DR e non contengono nulla per gestire i task di recupero specifici di OCI Database con PostgreSQL. Questo task spiega come aggiungere gruppi di piani DR personalizzati e definiti dall'utente e i passi per gestire i task da eseguire durante uno switchover:

Creare un backup del database dopo la chiusura normale della VM dell'applicazione Web per garantire la coerenza dei dati.
Trasferisci il backup del database più recente nell'area OCI 2 remota per la ridondanza e il disaster recovery.
Ripristinare il backup del database più recente nell'area 2 per preparare l'ambiente per lo switchover.
Aggiorna il record DNS del database privato, consentendo alla VM dell'applicazione di connettersi senza problemi al database nell'area 2.
Arrestare il database OCI di origine con il database PostgreSQL nell'Area 1.

Task 5.1: Selezionare il piano di switchover

Passare al piano di switchover creato nel task 4. Nel task 5.3 verranno aggiunti nuovi gruppi.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-add.png

Task 5.2: (Facoltativo) Abilitare i gruppi di piani DR che terminano gli artifact

Esistono tre gruppi di piani disabilitati per impostazione predefinita nei piani di switchover, come mostrato nell'immagine seguente. Questi gruppi di piani sono disabilitati per fornire sicurezza durante i test, assicurando che nessun artifact venga eliminato e che una copia di backup valida rimanga intatta in caso di problemi durante la fase di test.

Tuttavia, questi tre gruppi di piani sono progettati per terminare (eliminare) gli artifact che non saranno più necessari per le future operazioni di DR. Senza questi gruppi di piani abilitati, gli artifact non utilizzati continueranno ad accumularsi nel tempo durante l'esecuzione degli switchover tra le due aree, il che può causare confusione sulle istanze di computazione e sui gruppi di volumi che devono essere attivi.

Facoltativamente, l'abilitazione di questi gruppi di piani ora consentirà di evitare la necessità di eseguire il cleanup manuale degli artifact non necessari prima di entrare in produzione. Questo passo proattivo può semplificare la transizione alla produzione e mantenere un ambiente più pulito e gestibile.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-details-1.png

Per abilitare i gruppi di piani, selezionare Abilita tutti i passi dal menu di scelta rapida a destra del nome del gruppo di piani.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-enable.png

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-enable-check.png
Verificare che tutti i gruppi di piani siano abilitati.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-enable-complete.png

Task 5.3: Creare un gruppo di piani per eseguire script personalizzati

Inizia aggiungendo gruppi di piani DR personalizzati e definiti dall'utente per personalizzare il workflow DR in base alle esigenze specifiche del database OCI con il processo DR di backup/ripristino PostgreSQL.

Questi gruppi di piani richiameranno gli script necessari dalla VM dell'applicazione Web nell'area 1. Ciò garantirebbe che il database OCI con PostgreSQL sia completamente ripristinato e operativo prima che la VM dell'applicazione venga connessa.

Il seguente piano personalizzato deve essere aggiunto al piano di switchover precompilato: PostgreSQL - Switchover, PostgreSQL - Aggiorna DNS e PostgreSQL - Termina.

Aggiungere un gruppo di piani personalizzati per eseguire lo switchover per il database OCI con PostgreSQL. Questa operazione comporta il backup del database nell'area primaria, la copia della configurazione del database nell'area di standby, la copia del backup del database nell'area di standby e infine il ripristino del database nell'area di standby.
1. Fare clic su Aggiungi gruppo
2. Immettere un nome gruppo di piani semplice ma descrittivo. In questo esempio verrà eseguita l'operazione PostgreSQL - Switchover.
3. Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo esempio, selezionare Aggiungi dopo per inserire il gruppo di piani definito dall'utente dopo il gruppo di piani incorporato Istanze di computazione - Avvio.
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per eseguire lo switchover PostgreSQL.
Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-add-psql-so.png

In Aggiungi passo gruppo di piani immettere le informazioni riportate di seguito.
1. Immettere Nome passo. In questo esempio verrà eseguita l'operazione PostgreSQL - Switchover. Uguale al nome del gruppo di piani.
2. Selezionare un'area che contiene l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito nella VM dell'applicazione Web nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare Istanza di destinazione, ovvero la VM dell'applicazione Web nell'area 1.
5. In Parametri script immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/full-stack-dr-scripts-main/oci-postgresql/backup-restore/psql_exec_cold_dr.py -c amo-psql-dbs.json -o switchover.
6. In Esegui come utente immettere opc.
7. Fare clic su Aggiungi passo.
Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-add-psql-so-details.png

Fare clic su Aggiungi.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-add-psql-details.png
Aggiungere un gruppo di piani personalizzati per aggiornare il DNS del database PostgreSQL.
1. Fare clic su Aggiungi gruppo
2. Immettere un nome per il gruppo di piani. In questo esempio, verrà utilizzato PostgreSQL - Update DNS.
3. Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo esempio, selezionare Aggiungi dopo per inserire il gruppo di piani definito dall'utente dopo il gruppo di piani incorporato PostgreSQL - Switchover.
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per aggiornare il DNS del database PostgreSQL.
Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-add-psql-dns.png

In Aggiungi passo gruppo di piani immettere le informazioni riportate di seguito.
1. Immettere Nome passo. In questo esempio, verrà utilizzato PostgreSQL - Update DNS. Uguale al nome del gruppo di piani.
2. Selezionare un'area che contiene l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito nella VM dell'applicazione Web nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero la VM dell'applicazione Web nell'area 1.
5. In Parametri script immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/full-stack-dr-scripts-main/oci-postgresql/backup-restore/psql_update_dns.py -c amo-psql-dbs.json -d amo-psql-dbs.amo.vcn01.internal -o switchover.
6. In Esegui come utente immettere opc.
7. Fare clic su Aggiungi passo.
Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-add-psql-dns-details.png

Fare clic su Aggiungi.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-add-dns-details.png
Aggiungere un gruppo di piani personalizzati per arrestare il database di origine PostgreSQL.
1. Fare clic su Aggiungi gruppo
2. Immettere un nome per il gruppo di piani. In questo esempio verrà eseguita l'operazione PostgreSQL - Terminate.
3. Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo esempio, selezionare Aggiungi dopo per inserire il gruppo di piani definito dall'utente dopo il gruppo di piani incorporato Gruppi di volumi - Rimuovi dal gruppo di protezione DR.
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per terminare l'origine del database PostgreSQL.
Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-add-psql-terminate.png

In Aggiungi passo gruppo di piani immettere le informazioni riportate di seguito.
1. Immettere Nome passo. In questo esempio verrà eseguita l'operazione PostgreSQL - Terminate. Uguale al nome del gruppo di piani.
2. Selezionare un'area che contiene l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito nella VM dell'applicazione Web nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero la VM dell'applicazione Web nell'area 1.
5. In Parametri script immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/full-stack-dr-scripts-main/oci-postgresql/backup-restore/psql_exec_cold_dr.py -c amo-psql-dbs.json -o terminate.
6. In Esegui come utente immettere opc.
7. Fare clic su Aggiungi passo.
Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-add-psql-terminate-details.png

Fare clic su Aggiungi.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-add-terminate-details.png
Verificare che i gruppi di piani personalizzati creati mostrino lo stato Abilitato.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-details-2.png

La personalizzazione del piano di switchover è stata completata.

Task 6: Personalizzazione del piano di failover nell'area 2

In questo task aggiungere i gruppi di piani DR personalizzati e definiti dall'utente e i passi per gestire i task da eseguire durante un failover.

Ripristinare il backup del database più recente nell'area 2 per preparare l'ambiente per lo switchover.
Aggiorna il record DNS del database privato, consentendo alla VM dell'applicazione di connettersi senza problemi al database nell'area 2.

Task 6.1: Selezionare il piano di failover

Passare al piano di failover creato nel task 4.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-failover-details-1.png

Task 6.2: Creare un gruppo di piani per eseguire script personalizzati nell'area 2

Questi gruppi di piani richiameranno gli script necessari dalla VM dell'applicazione Web.

Il seguente piano personalizzato deve essere aggiunto al piano di failover precompilato: PostgreSQL - Failover e PostgreSQL - Aggiorna DNS.

Aggiungere un gruppo di piani personalizzati per eseguire lo script di failover PostgreSQL.
1. Fare clic su Aggiungi gruppo
2. Immettere un nome per il gruppo di piani. In questo esempio verrà eseguita l'operazione PostgreSQL - Failover.
3. Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo esempio, selezionare Aggiungi dopo per inserire il gruppo di piani definito dall'utente dopo il gruppo di piani incorporato Istanze di computazione - Avvio.
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per eseguire il failover del database PostgreSQL.
Descrizione dell'illustrazione psql-webapp-auh-drpg-create-failover-add-psql.png

In Aggiungi passo gruppo di piani immettere le informazioni riportate di seguito.
1. Immettere un nome passo. In questo esempio verrà eseguita l'operazione PostgreSQL - Failover. Uguale al nome del gruppo di piani.
2. Selezionare un'area che contiene l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito nella VM dell'applicazione Web nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero la VM dell'applicazione Web nell'area 1.
5. In Parametri script immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/full-stack-dr-scripts-main/oci-postgresql/backup-restore/psql_exec_cold_dr.py -c amo-psql-dbs.json -o failover.
6. In Esegui come utente immettere opc.
7. Fare clic su Aggiungi passo.
Descrizione dell'illustrazione psql-webapp-auh-drpg-create-failover-add-psql-fo-details.png

Fare clic su Aggiungi.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-failover-add-psql-details.png
Aggiungere un gruppo di piani personalizzati per aggiornare il DNS del database PostgreSQL.
1. Fare clic su Aggiungi gruppo
2. Immettere un nome per il gruppo di piani. In questo esempio, verrà utilizzato PostgreSQL - Update DNS.
3. Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo esempio, selezionare Aggiungi dopo per inserire il gruppo di piani definito dall'utente dopo il gruppo di piani incorporato PostgreSQL - Failover.
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per aggiornare il DNS del database PostgreSQL.
Descrizione dell'illustrazione psql-webapp-auh-drpg-create-failover-add-dns.png

In Aggiungi passo gruppo di piani immettere le informazioni riportate di seguito.
1. Immettere un nome passo. In questo esempio, verrà utilizzato PostgreSQL - Update DNS. Uguale al nome del gruppo di piani.
2. Selezionare un'area che contiene l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito nella VM dell'applicazione Web nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero la VM dell'applicazione Web nell'area 1.
5. In Parametri script immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/full-stack-dr-scripts-main/oci-postgresql/backup-restore/psql_update_dns.py -c amo-psql-dbs.json -d xxx-psql-dbs.xxx.vcn01.internal -o failover.
6. In Esegui come utente immettere opc.
7. Fare clic su Aggiungi passo.
Descrizione dell'illustrazione psql-webapp-auh-drpg-create-failover-add-dns-fo-details.png

Fare clic su Aggiungi.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-failover-add-dns-details.png
Verificare che i gruppi di piani personalizzati creati mostrino lo stato Abilitato.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-failover-details-2.png

La personalizzazione del piano di failover è stata completata.

Task 7: Esegui controlli preliminari nell'area 2

Creazione dei piani DR di switchover e failover riuscita nell'area di standby 2. Questi piani consentono a OCI Full Stack DR di eseguire la transizione dei carichi di lavoro dall'Area 1 all'Area 2. Il task successivo prevede l'esecuzione dei controlli preliminari per i piani di switchover e failover per garantire la disponibilità e convalidare il processo di transizione.

Task 7.1: Inizio dei controlli preliminari per il piano di switchover

Eseguire i controlli preliminari per il piano DR di switchover.

Assicurarsi che il contesto dell'area sia impostato su Area 2 in standby.
Assicurarsi che sia selezionato il gruppo di protezione DR corretto nell'area 2, che sia il ruolo di standby.
Fare clic sul nome del piano di switchover.
Fare clic su Azioni.
Fare clic su Esegui controlli preliminari.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-precheck.png
Fare clic su Esegui controlli preliminari.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-precheck-run.png
Verificare se tutti i controlli preliminari sono stati completati correttamente.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-precheck-details-2.png

Task 7.2: Inizio dei controlli preliminari per il piano di failover

Eseguire i controlli preliminari per il piano DR di failover.

Assicurarsi che il contesto dell'area sia impostato su standby region 2.
Assicurarsi che sia selezionato il gruppo di protezione DR corretto nell'area 2, che sia il ruolo di standby.
Fare clic sul nome del piano di failover.
Fare clic su Azioni.
Fare clic su Esegui controlli preliminari.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-failover-precheck.png
Fare clic su Esegui controlli preliminari.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-failover-precheck-run.png
Verificare se tutti i controlli preliminari sono stati completati correttamente.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-failover-precheck-details-2.png

Task 8: Esecuzione del piano di switchover nell'area 2

Eseguire il piano di switchover DR per avviare il processo di transizione dell'applicazione Web con il database OCI con PostgreSQL dall'Area 1 all'Area 2.

Assicurarsi che il contesto dell'area sia impostato su Area 2 in standby.
Assicurarsi che sia selezionato il gruppo di protezione DR corretto nell'area 2, che sia il ruolo di standby.
Fare clic sul nome del piano di switchover.
Fare clic su Azioni
Fare clic su Esegui piano.

Descrizione dell'illustrazione psql-webapp-auh-drpg-switchover-execute.png

Questo task esegue il piano di switchover nell'area 2.

Deselezionare Abilita controlli preliminari, poiché sono già stati eseguiti nel task 7.
Fare clic su Esegui piano.

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-execute-run.png

Monitora il piano di switchover fino a quando il carico di lavoro completo non è stato completamente trasferito dall'area 1 all'area 2.

L'esecuzione del piano di switchover è stata completata correttamente in circa 39 minuti.

psql-webapp-auh-drpg-create-switchover-execute-details-1.png

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-execute-details-1.png

psql-webapp-auh-drpg-create-switchover-execute-details-2.png

Descrizione dell'illustrazione psql-webapp-auh-drpg-create-switchover-execute-details-2.png

Dopo lo switchover: l'applicazione Web sarà nuovamente accessibile nell'area 2, utilizzando lo stesso URL di prima.

webapp frontend-preview.png

Descrizione dell'illustrazione webapp-frontend-preview.png

Task 9: Creazione e personalizzazione dei piani DR nell'area 1

Con il completamento con successo dello switchover da parte di OCI Full Stack DR, Region 2 ha ora assunto il ruolo della region primaria, mentre Region 1 è passata a servire come standby region.

Segui lo stesso approccio dettagliato nei task da 1 a 8, procedi per creare e personalizzare i piani di switchover e failover all'interno del gruppo di protezione DR per l'area 1, che ora funge da peer region in standby.

Descrizione dell'illustrazione psql-webapp-dxb-drpg-plan-create.png

Nota: PostgreSQL - Terminate non è visibile nello screenshot seguente.

Descrizione dell'illustrazione psql-webapp-dxb-drpg-create-switchover-details-1.png

Descrizione dell'illustrazione psql-webapp-dxb-drpg-create-failover-details-1.png

Task 10: Esecuzione del piano di failover nell'area 1

L'esecuzione del piano di failover è intesa a fini di test, in cui simuliamo uno scenario di emergenza per convalidare l'efficacia della nostra strategia di DR. In questa simulazione, il disastro viene imitato arrestando intenzionalmente la macchina virtuale (VM) nella Regione 2.

Per eseguire il ripristino da questo errore simulato, viene eseguito il piano DR di failover, che avvia il processo di failover, in cui alla VM dell'applicazione Web viene eseguito il backup disponibile più recente del database OCI con PostgreSQL viene ripristinato nell'Area 1.

Nota: il piano DR di failover deve essere utilizzato solo durante un evento non pianificato a errore irreversibile. La perdita di dati può verificarsi durante il processo di failover.

Assicurarsi che il contesto dell'area sia impostato su Area 1 in standby.
Assicurarsi che sia selezionato il gruppo di protezione DR corretto nell'area 1, che sia il ruolo di standby.
Fare clic sul nome del piano di failover.
Fare clic su Azioni.
Fare clic su Esegui piano.

Descrizione dell'illustrazione psql-webapp-dxb-drpg-failover-execute.png

Questo task esegue il piano di failover nell'area 1.

Mantenere deselezionato Abilita controlli preliminari, poiché si tratta di un esercizio di failover effettivo.
Fare clic su Esegui piano per iniziare.

Descrizione dell'illustrazione psql-webapp-dxb-drpg-failover-execute-run.png

Monitora il piano di failover fino a quando il carico di lavoro completo non è stato completamente trasferito dall'Area 2 all'Area 1.

L'esecuzione del piano di failover è stata completata correttamente in circa 10 minuti.

psql-webapp-dxb-drpg-create-failover-execute-details-1.png

Descrizione dell'illustrazione psql-webapp-dxb-drpg-create-failover-execute-details-1.png

psql-webapp-dxb-drpg-create-failover-execute-details-2.png

Descrizione dell'illustrazione psql-webapp-dxb-drpg-create-failover-execute-details-2.png

Conferme

Autori - Antoun Moubarak (Architetto, Ufficio del CTO), Piotr Kurzynoga (Open Source Data Black Belt)
Contributor - Suraj Ramesh (Product Manager per OCI Full Stack DR)

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o accedi a più contenuti di formazione gratuiti sul canale YouTube di Oracle Learning. Inoltre, visitare education.oracle.com/learning-explorer per diventare Oracle Learning Explorer.

Per la documentazione del prodotto, visitare Oracle Help Center.

Titolo e informazioni sul copyright

Automate Cold Disaster Recovery for OCI Database with PostgreSQL using OCI Full Stack Disaster Recovery

G38682-02