Nota

Questa esercitazione richiede l'accesso a Oracle Cloud. Per iscriverti a un account gratuito, consulta Inizia a utilizzare Oracle Cloud Infrastructure Free Tier.
Utilizza valori di esempio per le credenziali, la tenancy e i compartimenti di Oracle Cloud Infrastructure. Al termine del laboratorio, sostituisci questi valori con quelli specifici del tuo ambiente cloud.

Automatizza il recupero da errori irreversibili per Oracle HeatWave MySQL utilizzando OCI Full Stack Disaster Recovery

Introduzione

Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) orchestra la transizione di computazione, database e applicazioni tra le region OCI di tutto il mondo con un solo clic. I clienti possono automatizzare i passaggi necessari per recuperare uno o più sistemi aziendali senza riprogettare o riprogettare l'infrastruttura, i database o le applicazioni esistenti e senza dover ricorrere a server di gestione o conversione specializzati.

Oracle HeatWave MySQL è un servizio di database completamente gestito distribuito all'interno di Oracle Cloud Infrastructure (OCI) che supporta operatori e sviluppatori che desiderano implementare rapidamente applicazioni sicure e native nel cloud. Oracle HeatWave MySQL è l'unica offerta MySQL che include la possibilità di utilizzare HeatWave, un acceleratore di query in-memory integrato e ad alte prestazioni. HeatWave consente ai clienti di eseguire analisi sofisticate direttamente sul proprio database operativo MySQL, eliminando i requisiti per la migrazione e l'integrazione dei dati complessi, dispendiosi in termini di tempo e costosi con un database di analisi separato. HeatWave accelera notevolmente le prestazioni di MySQL per analytics e carichi di lavoro misti. HeatWave è completamente ottimizzato per OCI e Oracle HeatWave MySQL è stato creato, gestito e supportato al 100% dai team di progettazione OCI e MySQL.

In questa esercitazione verrà descritto come automatizzare un recupero in seguito a calamità a freddo per Oracle HeatWave MySQL in OCI. Vengono descritte le procedure per l'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, che lo rende più adatto per applicazioni non critiche in cui i requisiti aziendali per gli obiettivi RTO (Recovery Time Objectives) e RPO (Recovery Point Objectives) non sono eccessivamente impegnativi.

Descrizione architettura

L'architettura presentata in questa esercitazione mostra un'applicazione WordPress in esecuzione sulle virtual machine (VM) OCI perfettamente integrata con Oracle HeatWave MySQL. Inoltre, l'impostazione sfrutta il servizio OCI File Storage come condivisione NFS (Network File System) per memorizzare il contenuto WordPress. Questo storage condiviso viene eseguito il MOUNT di ogni VM, garantendo l'accesso immediato e sincronizzato a tutti i nuovi contenuti nell'ambiente.

Un load balancer OCI viene distribuito all'interno di una subnet pubblica per gestire in modo efficiente le connessioni utente esterne, distribuendo il traffico in entrata tra le VM WordPress.

Descrizione dell'architettura per il disaster recovery

La strategia di DR per le VM dell'applicazione WordPress prevede un approccio completo, che include la replica completa di ogni volume di avvio di VM con replica del gruppo di volumi e l'utilizzo della replica dello storage di file per garantire la sincronizzazione del contenuto WordPress.

Viene eseguito il provisioning di un load balancer nell'area remota, garantendo che sia pronto a gestire il traffico senza problemi quando le VM WordPress vengono passate all'area remota durante uno scenario di switchover o failover.

Per Oracle HeatWave MySQL, i backup vengono copiati regolarmente nell'area remota per garantire la protezione dei dati e la disponibilità del disaster recovery. Questo processo può essere avviato da una VM dell'applicazione utilizzando uno script personalizzato, che può essere pianificato tramite crontab per un'esecuzione automatizzata e coerente.

Il diagramma riportato di seguito illustra il workflow per la copia dell'ultimo backup MySQL disponibile dall'area primaria all'area remota.

fsdr_mds_copy_restore_bkp-Logical_Workflow_Copy_Backup_to_Remote.png

L'impostazione di crontab seguente è stata configurata nell'utente opc nell'applicazione WordPress VM1 per eseguire lo script mds_copy_bkp.py ogni 4 ore. Ciò garantisce la sincronizzazione automatica del backup nella standby region, contribuendo a migliorare il disaster recovery:

15 */4 * * * /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01

Questo job esegue lo script al minuto 15 dopo ogni 4 ore.

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

Nota: assicurarsi di pianificare questo script (o uno simile) in base ai requisiti aziendali per copiare regolarmente il backup MySQL 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 opererà nell'area 1. L'architettura apparirà come segue:

fsdr_mds_copy_restore_bkp-Physical_Switchover_Architecture.png

Nell'impostazione corrente, utilizziamo il servizio DNS privato OCI per gestire un record DNS che indirizza il traffico all'endpoint Oracle HeatWave MySQL attivo. Durante il processo di recupero, questo record DNS viene aggiornato tramite uno script personalizzato per riflettere il nuovo Oracle HeatWave MySQL, garantendo failover e continuità del servizio senza interruzioni.

Il diagramma riportato di seguito illustra il workflow per il ripristino del backup MySQL più recente nella standby region.

fsdr_mds_copy_restore_bkp-Logical_Workflow_Restore_Backup_to_Remote.png

La soluzione di recupero per questa distribuzione richiede OCI Full Stack DR per eseguire una serie di script Python personalizzati durante un'operazione di recupero come un failover o uno switchover. Gli script a cui si fa riferimento in questa esercitazione sono forniti dal team EMEA Cloud Architecture Specialist e sono disponibili qui: full-stack-disaster-recovery, appositamente studiato per questa soluzione di DR.

Questa esercitazione spiega come scaricare gli script e come utilizzarli in un'attività successiva.

Nota: per le linee guida generiche sono disponibili gli script riportati di seguito. È possibile utilizzare script personalizzati o personalizzarli in base ai criteri aziendali e ai requisiti di sicurezza.

Definizioni e ipotesi in tutta l'esercitazione

Aree:
- La regione 1 è Dubai: Dubai sarà inizialmente la regione principale. Tuttavia, questo ruolo passerà alla modalità standby durante il processo di switchover, che verrà eseguito nei task successivi nell'ambito del piano di disaster recovery.
- La regione 2 è Abu Dhabi: Abu Dhabi inizialmente funzionerà come standby region. Questo ruolo passerà in seguito al processo di switchover primario, che verrà eseguito nei task successivi nell'ambito della procedura di disaster recovery.
Compartimenti: puoi organizzare questa distribuzione e OCI Full Stack DR in qualsiasi schema compartimento che funzioni all'interno degli standard per la governance IT. Abbiamo scelto di organizzare tutte le risorse OCI per questa esercitazione in un unico compartimento.

WordPress VM delle applicazioni e storage di file OCI

L'architettura utilizzata in questa esercitazione si basa su OCI File Storage per garantire che tutte le VM delle applicazioni abbiano accesso condiviso allo stesso contenuto WordPress.

Per ulteriori informazioni su come eseguire correttamente il MOUNT del file system nelle istanze Linux, vedere Configurazione di un file system per l'attivazione automatica (istanze Linux).

Di seguito è riportato un esempio di configurazione del file /etc/fstab per l'attivazione del file system sulla VM dell'applicazione WordPress.

xxx.xxx.xxx.xxx:/wordpress /var/www/html nfs nfsvers=3,noacl,nosuid,nofail 0 0

Sostituire xxx.xxx.xxx.xxx con l'indirizzo IP della destinazione di accesso situata nell'area 1 per garantire la connettività corretta.

Obiettivi

In questa esercitazione verranno trattati 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: Crea piani DR di base nell'area 2
Task 5: Personalizzare il piano di switchover nell'area 2
Task 6: Personalizzazione del piano di failover nell'area 2
Task 7: eseguire i controlli preliminari dei piani DR nella regione 2
Task 8: eseguire il piano di switchover nell'area 2
Task 9: creare e personalizzare i piani DR 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 le VM dell'applicazione WordPress nell'area 1 e assicurarsi che venga replicato nell'area 2. Assicurarsi che il volume di avvio per ogni VM dell'applicazione (WordPress) sia membro del gruppo di volumi e che il gruppo di volumi sia replicato nell'area 2.

L'immagine seguente mostra la visualizzazione del gruppo di volumi creato, che include i volumi di avvio delle due VM dell'applicazione WordPress, con la replica abilitata nell'area 2. Per ulteriori informazioni, vedere Creazione di un gruppo di volumi.

Task 1.2: Abilitare la replica dello storage di file per il contenuto WordPress

Nell'area 2, creare un file system designato specificamente per la replica. Questo file system verrà utilizzato per replicare senza problemi i dati dall'Area 1 all'Area 2.
Nell'area 2, creare una destinazione di accesso che verrà utilizzata durante il processo di recupero dall'area 1 all'area 2.
Utilizzare il file system creato nel passo 1 per abilitare e configurare la replica dallo storage di file OCI di origine nell'area 1.

L'immagine riportata di seguito illustra i dettagli della replica dello storage di file nell'area 2.

Per ulteriori informazioni, vedere Replica del file system.

Task 1.3: Preparare le VM delle applicazioni per eseguire l'automazione personalizzata

Installare e configurare l'interfaccia della riga di comando di Oracle Cloud Infrastructure (OCI CLI). Per questa esercitazione, Oracle Linux 8 viene utilizzato per la VM dell'applicazione WordPress. Per ulteriori informazioni, vedere Installazione dell'interfaccia CLI.
Distribuire lo script dal repository GitHub (mds_colddr_scripts) nella cartella /home/opc.
Installare i panda e tabulare i moduli utilizzati dallo script fornito.
```
pip install pandas
pip install tabulate
```
Aggiornare il file config.csv con i dettagli necessari per Oracle HeatWave MySQL nell'area 1.
- Sostituire MYSQL_DB_SYSTEM_OCID con l'OCID di Oracle HeatWave MySQL. È possibile mantenere o personalizzare l'etichetta MySQL per allinearla ai requisiti specifici.
- Sostituire COMPARTMENT_OCID con l'OCID del compartimento in cui si trova il sistema MySQL.
- Sostituire PRIMARY_SUBNET_OCID e STANDBY_SUBNET_OCID con gli OCID della subnet in entrambe le aree.
- Sostituire PRIMARY_DNS_VIEW_OCID e STANDBY_DNS_VIEW_OCID con gli OCID delle viste DNS private associate alla zona DNS privata che gestisce il record endpoint Oracle HeatWave MySQL.
Nota: assicurarsi che tutti i valori siano aggiornati in modo accurato.

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

Task 1.4: Creare criteri IAM OCI per OCI Full Stack DR

Configurare i criteri IAM OCI necessari per OCI Full Stack DR come descritto nei documenti riportati di seguito.

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

OCI Full Stack DR deve avere la possibilità di controllare e gestire altri servizi OCI chiave come computazione, networking, storage e altri servizi vari. Per configurare i criteri IAM OCI necessari per altri servizi, vedere Criteri per altri servizi gestiti da Full Stack Disaster Recovery e Criteri IAM OCI.

Task 2: Creare 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 a OCI Console e andare a Gruppi di protezione DR come mostrato nella Figura 2.1.
1. Assicurarsi che il contesto dell'area OCI sia impostato su Area 1 (Dubai).
2. Fare clic su Migrazione e recupero da errori irreversibili.
3. Fare clic su Gruppi di protezione DR.
Figura 2.1: Passare ai gruppi di protezione DR
Creare un gruppo di protezione DR di base (DRPG) nella regione 1 come illustrato nella figura 2.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. Utilizzare un nome significativo per il DRPG.
4. Selezionare il bucket di storage degli oggetti OCI per i log DR dello stack completo OCI.
5. Fare clic su Crea.
Figura 2.2: Parametri necessari per creare un gruppo di protezione DR nell'area 1

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

Andare a OCI Console, andare a Gruppi di protezione DR come mostrato nella figura 2.3.
1. Assicurarsi che il contesto dell'area OCI sia impostato su Area 2 (Abu Dhabi).
2. Fare clic su Migrazione e recupero da errori irreversibili.
3. Fare clic su Gruppi di protezione DR.
Figura 2.3: Passare ai gruppi di protezione DR
Creare un gruppo di protezione DR di base (DRPG) nella regione 2 come illustrato nella figura 2.4. 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. Utilizzare un nome significativo per il DRPG.
4. Selezionare il bucket di storage degli oggetti OCI per i log DR dello stack completo OCI.
5. Fare clic su Crea.
Figura 2.4: Parametri necessari per creare un gruppo di protezione DR nell'area 2

Task 2.3: Associa gruppi di protezione nella regione 1 e nella regione 2

Associa i DRPG in ogni region come peer gli uni degli altri e assegna i ruoli peer di database primario e standby. I ruoli di database 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 di 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.
Figura: Avvio dell'associazione DRPG
Specificare i parametri come illustrato nella seguente immagine.
1. Ruolo: selezionare il ruolo Principale. OCI Full Stack DR assegnerà automaticamente il ruolo in standby all'area 2.
2. Area peer: selezionare Area 2 (Abu Dhabi), in cui è stato creato l'altro DRPG.
3. Gruppo di protezione DR peer: selezionare il DRPG peer creato.
4. Fare clic su Associazione.
Figura: Parametri necessari per associare i DRPG

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

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

Figura: Visualizzazione della relazione peer dalla prospettiva DRPG individuale

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 nella seguente immagine.

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

Figura: Visualizzazione della relazione peer dal punto di vista DRPG globale

Task 3: aggiungere membri al gruppo di protezione DR

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

Le due istanze di computazione che ospitano l'applicazione WordPress verranno aggiunte come VM in movimento. Accertarsi inoltre che la sezione File system nella sezione Opzioni avanzate sia configurata correttamente.
Gruppo di volumi contenente il volume di avvio dei nodi di calcolo dell'applicazione WordPress.
Storage di file OCI contenente il contenuto WordPress.
Il load balancer primario.

Task 3.1: Aggiungi membri a DRPG nella regione 1

Selezionare il DRPG nella regione 1 come mostrato nella seguente immagine.
1. Assicurarsi che il contesto dell'area OCI sia Region 1 (Dubai).
2. Selezionare il DRPG nella regione 1.
3. Selezionare Membri.
4. Fare clic su Aggiungi membro per avviare il processo.
Figura: Come iniziare ad aggiungere membri al gruppo di protezione DR nell'area 1
Aggiungere un'istanza di computazione per le VM dell'applicazione WordPress.
1. Conferma avvertenza relativa ai piani DR.
2. Immettere Computazione come tipo di risorsa membro.
3. Selezionare l'istanza di computazione che ospita l'applicazione WordPress.
4. Selezionare Istanza di spostamento.
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 Mostra opzioni avanzate.
7. In Impostazioni, selezionare Mantieni dominio di errore.
8. In File system, completare la sezione Mapping esportazione in base all'impostazione, come mostrato nelle immagini riportate di seguito.
Figura: Parametri necessari per aggiungere la VM dell'applicazione WordPress

Figura: Parametri necessari per mappare la VNIC nell'area 2

Figura: Opzioni avanzate, Conserva dominio di errore

Figura: Opzioni avanzate, mapping dei file system

Figura: Istanza di computazione aggiunta al DRPG nell'area 1

Nota: ripetere i passi secondari precedenti per tutte le istanze di computazione per le VM dell'applicazione WordPress.

Figura: Due istanze di computazione aggiunte al DRPG nell'area 1
Aggiungere il gruppo di volumi a blocchi contenente il volume di avvio delle VM dell'applicazione WordPress.
1. Conferma avvertenza relativa ai piani DR.
2. Selezionare Gruppo di volumi come tipo di risorsa membro.
3. Assicurarsi che sia selezionato il compartimento corretto contenente il gruppo di volumi e selezionare il gruppo di volumi.
Figura: Parametri necessari per aggiungere il gruppo di volumi per la computazione WordPress

Figura: Gruppo di volumi per la computazione WordPress aggiunto al DRPG nell'area 1
Aggiungere lo storage di file OCI contenente il contenuto WordPress.
1. Conferma avvertenza relativa ai piani DR.
2. Selezionare File system come tipo di risorsa membro.
3. Assicurarsi che sia selezionato il compartimento corretto contenente il file system e selezionare il file system.
4. Selezionare Dominio di disponibilità destinazione da utilizzare nell'area 2.
5. Selezionare Percorso di esportazione di origine per questo file system. Questo percorso di esportazione viene creato nell'area di destinazione 2 dopo il ripristino del file system.
6. Selezionare Destinazione di accesso nell'area 2 utilizzata per creare un'esportazione per il file system ripristinato.
Figura: Parametri necessari per aggiungere il file system per il contenuto WordPress

Figura: File system per il contenuto WordPress aggiunto al DRPG nell'area 1
Aggiungere OCI Load Balancer.

In questo esempio, il load balancer verrà aggiunto come membro del DRPG nell'area 1.
1. Conferma avvertenza relativa ai piani DR.
2. Selezionare Load balancer come tipo di risorsa membro.
3. Assicurarsi che siano selezionati i compartimenti corretti per il load balancer e selezionare il load balancer che si desidera aggiungere.
4. Selezionare il load balancer di destinazione da utilizzare nell'area 2.
5. Selezionare Set backend di origine, ovvero il set backend utilizzato dalle VM dell'applicazione WordPress. Un load balancer OCI può essere condiviso tra più applicazioni e può avere più set backend configurati. Durante uno switchover DR, la configurazione dei set backend specificati qui verrà spostata nella standby region.
6. Selezionare Set backend di destinazione, ovvero il set backend vuoto creato nell'area 2.
Figura: Parametri necessari per aggiungere il load balancer

Figura: Load balancer aggiunto al DRPG nell'area 1

Task 3.2: Aggiungi membri a DRPG nella regione 2

Selezionare il DRPG nella regione 2 come mostrato nella seguente immagine.
1. Assicurati che il contesto dell'area OCI sia Region 1 (Abu Dhabi).
2. Selezionare il DRPG nella regione 2.
3. Selezionare Membri.
4. Fare clic su Aggiungi membro per avviare il processo.
Figura: Come iniziare ad aggiungere membri al gruppo di protezione DR nell'area 2
Aggiungere OCI Load Balancer.

In questo esempio, il load balancer verrà aggiunto come membro del DRPG nell'area 2.
1. Conferma avvertenza relativa ai piani DR.
2. Selezionare Load balancer come tipo di risorsa membro.
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 dalle VM dell'applicazione WordPress. Un load balancer OCI può essere condiviso tra più applicazioni e può avere più set backend configurati. Durante uno switchover DR, la configurazione dei set backend specificati qui verrà spostata nella standby region.
6. Selezionare Set backend di destinazione. Questo set backend viene creato nell'area 2.
Figura: Parametri necessari per aggiungere il load balancer

Figura: Load balancer aggiunto al DRPG nell'area 2

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

In questo task verranno creati 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). Nell'ambito di qualsiasi operazione di DR, i ruoli dei gruppi di protezione DR in entrambe le aree vengono invertiti automaticamente: il gruppo di protezione nella regione 1 diventa il gruppo in standby, mentre il gruppo di protezione nella regione 2 assume il ruolo primario dopo un failover o uno switchover.

OCI Full Stack DR prepopola questi piani con passi integrati derivati dalle risorse membro aggiunte durante i task precedenti. Questi piani verranno successivamente personalizzati per gestire i task specifici di Oracle HeatWave MySQL durante il processo di recupero.

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

Task 4.1: Crea piani DR

Creare un piano di base selezionando il DRPG nella Regione 2 (Abu Dhabi)
1. Assicurati che il contesto dell'area OCI sia Region 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.
Figura: Avvio della creazione di piani DR di base nella regione 2
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 di piano come Switchover (pianificato).
Figura: Parametri necessari per creare un piano di switchover DR
Creare un piano di failover.

Seguire lo stesso processo per creare un piano di failover di base, come mostrato nella seguente immagine.
1. Immettere il nome del piano di failover semplice ma significativo. 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 di piano come Failover (non pianificato).
Figura: Parametri necessari per creare un piano di failover DR

Il gruppo di protezione DR in standby nella regione 2 dovrebbe ora disporre dei due piani DR, come mostrato nella seguente immagine. Questi gestiranno la transizione dei carichi di lavoro dall'Area 1 all'Area 2. I piani simili verranno creati nell'Area 1 per eseguire la transizione dei carichi di lavoro dall'Area 2 all'Area 1 in un task successivo.

Figura: Visualizzazione dei due piani DR di base che devono esistere nella regione 2 prima di procedere ulteriormente

Task 5: Personalizzare il 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 Oracle HeatWave MySQL. Questo task spiega come aggiungere gruppi di piani DR personalizzati e definiti dall'utente e come gestire i task da eseguire durante uno switchover:

Crea un backup del database dopo aver chiuso in modo normale le VM dell'applicazione per garantire la coerenza dei dati.
Trasferisci il backup del database più recente nell'OCI Region 2 remota per la ridondanza e il disaster recovery.
Ripristinare il backup del database più recente nell'area 2 per preparare l'ambiente allo switchover.
Aggiorna il record DNS del database privato, consentendo alle VM dell'applicazione di connettersi senza problemi al database nell'area 2.
Arrestare il database MySQL di origine nell'area 1.

Task 5.1: selezionare il piano di switchover

Passare al piano di switchover creato nel task 4.

Figura: Avvio della personalizzazione del piano di switchover nell'area 2

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 nella seguente immagine. Questi gruppi di piani sono disabilitati per garantire la sicurezza durante il test, garantendo che non vengano eliminati artifact 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 DR. Senza questi gruppi di piani abilitati, gli artifact inutilizzati continueranno ad accumularsi nel tempo man mano che si eseguono switchover tra le due aree, il che può generare confusione sulle istanze di computazione, sullo storage dei file OCI e sui gruppi di volumi che devono essere attivi.

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

Figura: Gruppi di piani disabilitati per impostazione predefinita

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

Figura: Come abilitare l'interruzione del file system

Figura: Fare clic su Abilita per convalidare.

Figura: Procedura di abilitazione dell'arresto delle istanze di computazione

Figura: Fare clic su Abilita per convalidare.

Figura: Come abilitare l'interruzione del gruppo di volumi

Figura: Fare clic su Abilita per convalidare.

Task 5.3: Riordina gruppi piani DR

È necessario eseguire il MOUNT del file system sulle nuove VM spostate nell'area 2 prima di aggiornare i set backend del load balancer. Ciò garantisce che l'applicazione disponga del corretto accesso alle risorse di storage necessarie, facilitando una transizione agevole durante il processo di switchover.

riordino plan-custom-so-auh-initial.png
Figura: Screenshot che mostra l'ordine iniziale del piano di switchover e come iniziare a riordinare

riordino plan-custom-so-auh-start.png
Figura: Avviare il riordinamento

Spostare File system - Installa su istanze di computazione prima di Load balancer - Aggiorna set backend di destinazione.
Fare clic su Salva modifiche.

riordino plan-custom-so-auh-final.png
Figura: Ordine del piano di switchover finale

Task 5.4: creare un gruppo di piani per eseguire script personalizzati

Inizia aggiungendo gruppi di piani DR personalizzati e definiti dall'utente per adattare il flusso di lavoro DR alle esigenze specifiche del processo MySQL Backup/Ripristino DR.

Questi gruppi di piani richiamano gli script necessari da WordPress VM1 nell'area 1 e devono essere posizionati nel workflow DR prima di avviare le VM dell'applicazione WordPress. Ciò garantisce che il database MySQL sia completamente ripristinato e operativo prima che le VM dell'applicazione vengano messe in linea.

Al piano di switchover preinserito deve essere aggiunto il seguente piano personalizzato: Crea backup MySQL Database, Copia backup MySQL Database, Ripristina backup MySQL Database, Aggiorna DNS MySQL Database e Termina origine MySQL Database.

Aggiungere un gruppo di piani personalizzato per creare il backup del database MySQL.
1. Fare clic su Aggiungi gruppo.
2. Immettere un Nome per il gruppo di piani semplice ma descrittivo. In questo esempio verrà utilizzato Create MySQL DB Backup.
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 - Avvia.
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per creare il backup del database MySQL.
Figura: Parametri per creare il gruppo di piani Crea backup DB MySQL

In Aggiungi passo gruppo di piani, immettere le informazioni riportate di seguito.
1. Immettere un nome di passo semplice ma descrittivo. In questo esempio verrà utilizzato Create MySQL DB Backup. Uguale al nome del gruppo di piani.
2. Selezionare un'area contenente l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito sull'applicazione WordPress VM1 nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare Istanza di destinazione, ovvero l'applicazione WordPress VM1 nell'area 1.
5. In Parametri script, immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/mds_copy_restore_bkp/mds_create_bkp.py mds01.
6. In Run as user immettere opc.
7. Fare clic su Aggiungi passo.
Figura: Parametri per creare Aggiungi passo Crea backup DB MySQL

Fare clic su Aggiungi.

Figura: Aggiungi un gruppo di piani Crea backup DB MySQL
Aggiungere un gruppo di piani personalizzato per copiare il backup del database MySQL.
1. Fare clic su Aggiungi gruppo.
2. Immettere un nome per il gruppo di piani semplice ma descrittivo. In questo esempio verrà utilizzato Copy MySQL DB Backup.
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 Crea backup DB MySQL.
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per copiare il backup del database MySQL.
Figura: Parametri per creare il gruppo di piani Copia backup DB MySQL

In Aggiungi passo gruppo di piani, immettere le informazioni riportate di seguito.
1. Immettere un nome di passo semplice ma descrittivo. In questo esempio verrà utilizzato Copy MySQL DB Backup. Uguale al nome del gruppo di piani.
2. Selezionare un'area contenente l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito sull'applicazione WordPress VM1 nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero l'applicazione WordPress VM1 nell'area 1.
5. In Parametri script, immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/mds_copy_restore_bkp/mds_copy_bkp.py mds01.
6. In Run as user immettere opc.
7. Fare clic su Aggiungi passo.
Figura: Parametri per aggiungere una copia passo MySQL Backup DB

Fare clic su Aggiungi.

Figura: Aggiungi un gruppo di piani Copia backup DB MySQL
Aggiungere un gruppo di piani personalizzato per ripristinare il backup del database MySQL.
1. Fare clic su Aggiungi gruppo.
2. Immettere un Nome per il gruppo di piani semplice ma descrittivo. In questo esempio verrà utilizzato Restore MySQL DB Backup.
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 Copia backup DB MySQL.
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per ripristinare il backup del database MySQL.
Figura: Parametri per creare il gruppo di piani Ripristina backup DB MySQL

In Aggiungi passo gruppo di piani, immettere le informazioni riportate di seguito.
1. Immettere un nome di passo semplice ma descrittivo. In questo esempio verrà utilizzato Restore MySQL DB Backup. Uguale al nome del gruppo di piani.
2. Selezionare un'area contenente l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito sull'applicazione WordPress VM1 nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero l'applicazione WordPress VM1 nell'area 1.
5. In Parametri script, immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config --switch.
6. In Run as user immettere opc.
7. Fare clic su Aggiungi passo.
Figura: Parametri per aggiungere un backup DB di ripristino dei passi MySQL

Fare clic su Aggiungi.

Figura: Aggiungi un gruppo di piani Ripristina backup DB MySQL
Aggiungere un gruppo di piani personalizzato per aggiornare il DNS del database MySQL.
1. Fare clic su Aggiungi gruppo.
2. Immettere un nome per il gruppo di piani semplice ma descrittivo. In questo esempio verrà utilizzato Update MySQL DB 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 Ripristina backup DB MySQL.
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per aggiornare il DNS del database MySQL.
Figura: Parametri per creare il gruppo di piani Aggiorna MySQL DNS DB

In Aggiungi passo gruppo di piani, immettere le informazioni riportate di seguito.
1. Immettere un nome di passo semplice ma descrittivo. In questo esempio verrà utilizzato Update MySQL DB DNS. Uguale al nome del gruppo di piani.
2. Selezionare un'area contenente l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito sull'applicazione WordPress VM1 nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero l'applicazione WordPress VM1 nell'area 1.
5. In Parametri script, immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local --remote.
6. In Run as user immettere opc.
7. Fare clic su Aggiungi passo.
Figura: Parametri per aggiungere un DNS DB di aggiornamento passo MySQL

Fare clic su Aggiungi.

Figura: Aggiungi un gruppo di piani Aggiorna MySQL DNS DB
Aggiungere un gruppo di piani personalizzato per arrestare il database di origine MySQL.
1. Fare clic su Aggiungi gruppo.
2. Immettere un Nome per il gruppo di piani semplice ma descrittivo. In questo esempio verrà utilizzato Terminate MySQL DB Source.
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 File system - 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 MySQL.
Figura: Parametri per creare il gruppo di piani Termina database di origine MySQL

In Aggiungi passo gruppo di piani, immettere le informazioni riportate di seguito.
1. Immettere un nome di passo semplice ma descrittivo. In questo esempio verrà utilizzato Terminate MySQL Source DB. Uguale al nome del gruppo di piani.
2. Selezionare un'area contenente l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito sull'applicazione WordPress VM1 nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero l'applicazione WordPress VM1 nell'area 1.
5. In Parametri script, immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/mds_copy_restore_bkp/mds_terminate_db.py mds01.
6. In Run as user immettere opc.
7. Fare clic su Aggiungi passo.
Figura: Parametri per aggiungere un passo Termina database di origine MySQL

Fare clic su Aggiungi.

Figura: Aggiungi un gruppo di piani Termina database di origine MySQL
(Facoltativo) Aggiungere un gruppo di piani personalizzato per arrestare l'applicazione WordPress.
1. Fare clic su Aggiungi gruppo.
2. Immettere un Nome per il gruppo di piani semplice ma descrittivo. In questo esempio verrà utilizzato Application - Stop.
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 alla fine dopo il gruppo di piani incorporato Load balancer - Aggiorna set backend di origine.
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per l'arresto dell'applicazione.
Figura: Parametri per creare un gruppo di piani Applicazione - Arresta

In Aggiungi passo gruppo di piani, immettere le informazioni riportate di seguito.
1. Immettere un nome di passo semplice ma descrittivo. In questo esempio verrà utilizzato Application - Stop - VM1.
2. Selezionare un'area contenente l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito sull'applicazione WordPress VM1 nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero l'applicazione WordPress VM1 nell'area 1.
5. In Parametri script, immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/fsdrscripts/wdp_stop.sh.
6. In Run as user immettere opc.
7. Fare clic su Aggiungi passo.
Figura: Parametri per creare un'applicazione passo - Arresta - VM1

Fare clic su Aggiungi passo per aggiungere un secondo passo per arrestare l'applicazione in VM2.

Figura: Aggiungi un'applicazione passo - Arresta - VM2

In Aggiungi passo gruppo di piani, immettere le informazioni riportate di seguito.
1. Immettere un nome di passo semplice ma descrittivo. In questo esempio verrà utilizzato Application - Stop - VM2.
2. Selezionare un'area contenente l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito sull'applicazione WordPress VM2 nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero l'applicazione WordPress VM2 nell'area 1.
5. In Parametri script, immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/fsdrscripts/wdp_stop.sh.
6. In Run as user immettere opc.
7. Fare clic su Aggiungi passo.
Figura: Parametri per creare un'applicazione passo - Arresta - VM2

Fare clic su Aggiungi.

Figura: Aggiunta di un gruppo di piani Applicazione - Arresta
(Facoltativo) Aggiungere un gruppo di piani personalizzato per avviare l'applicazione WordPress.
1. Fare clic su Aggiungi gruppo.
2. Immettere un Nome per il gruppo di piani semplice ma descrittivo. In questo esempio verrà utilizzato Application - Start.
3. Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, selezionare Aggiungi dopo per inserire il gruppo di piani definito dall'utente alla fine, dopo il gruppo di piani integrato File system - Attivazione su istanze di computazione.
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per avviare l'applicazione.
Figura: Parametri per creare un gruppo di piani Applicazione - Avvio

In Aggiungi passo gruppo di piani, immettere le informazioni riportate di seguito.
1. Immettere un nome di passo semplice ma descrittivo. In questo esempio verrà utilizzato Application - Start - VM1.
2. Selezionare un'area contenente l'istanza su cui verrà eseguito questo passo. In questo caso lo script verrà eseguito sull'applicazione WordPress VM1 nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero l'applicazione WordPress VM1 nell'area 1.
5. In Parametri script, immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/fsdrscripts/wdp_start.sh.
6. In Run as user immettere opc.
7. Fare clic su Aggiungi passo.
Figura: Parametri per la creazione di un'applicazione passo - Avvio - VM1

Fare clic su Aggiungi passo per aggiungere un secondo passo per avviare l'applicazione in VM2.

Figura: Aggiunta di un'applicazione passo - Avvio - VM2

In Aggiungi passo gruppo di piani, immettere le informazioni riportate di seguito.
1. Immettere un nome di passo semplice ma descrittivo. In questo esempio verrà utilizzato Application - Start - VM2.
2. Selezionare un'area contenente l'istanza su cui verrà eseguito questo passo. In questo caso lo script verrà eseguito sull'applicazione WordPress VM2 nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero l'applicazione WordPress VM2 nell'area 1.
5. In Parametri script, immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/fsdrscripts/wdp_start.sh.
6. In Run as user immettere opc.
7. Fare clic su Aggiungi passo.
Figura: Parametri per la creazione di un'applicazione passo - Avvio - VM2

Fare clic su Aggiungi.

Figura: Aggiunta di un gruppo di piani Applicazione - Avvio

La personalizzazione del piano di switchover è stata completata.

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

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

Ripristinare il backup del database più recente nell'area 2 per preparare l'ambiente allo switchover.
Aggiorna il record DNS del database privato, consentendo alle 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.

Figura: Avvio della personalizzazione del piano di failover nell'area 2

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

Inizia aggiungendo gruppi di piani DR personalizzati e definiti dall'utente per adattare il flusso di lavoro DR alle esigenze specifiche del processo MySQL Backup/Ripristino DR.

Questi gruppi di piani richiamano gli script necessari dalla VM dell'applicazione WordPress e devono essere posizionati nel workflow DR prima di riavviare le VM dell'applicazione WordPress. Ciò garantisce che il database MySQL sia completamente ripristinato e operativo prima che le VM dell'applicazione vengano messe in linea.

Al piano di failover precompilato deve essere aggiunto il seguente piano personalizzato: Ripristina backup MySQL Database e Aggiorna DNS MySQL Database.

Aggiungere un gruppo di piani personalizzato per ripristinare il backup del database MySQL.
1. Fare clic su Aggiungi gruppo per iniziare.
2. Immettere un Nome per il gruppo di piani semplice ma descrittivo. In questo esempio verrà utilizzato Restore MySQL DB Backup.
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 - Avvia.
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per ripristinare il backup del database MySQL.
Figura: Parametri per creare il gruppo di piani Ripristina backup DB MySQL

In Aggiungi passo gruppo di piani, immettere le informazioni riportate di seguito.
1. Immettere un nome di passo semplice ma descrittivo. In questo esempio verrà utilizzato Restore MySQL DB Backup. Uguale al nome del gruppo di piani.
2. Selezionare un'area contenente l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito sull'applicazione WordPress VM1 nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero l'applicazione WordPress VM1 nell'area 1.
5. In Parametri script, immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/mds_copy_restore_bkp/mds_restore_bkp.py mds01 1 --config.
6. In Run as user immettere opc.
7. Fare clic su Aggiungi passo.
Figura: Parametri per aggiungere un backup DB di ripristino dei passi MySQL

Fare clic su Aggiungi.

Figura: Aggiungi un gruppo di piani Ripristina backup DB MySQL
Aggiungere un gruppo di piani personalizzato per aggiornare il DNS del database MySQL.
1. Fare clic su Aggiungi gruppo per iniziare.
2. Immettere un Nome per il gruppo di piani semplice ma descrittivo. In questo esempio verrà utilizzato Update MySQL DB 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 Ripristina backup DB MySQL.
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per aggiornare il DNS del database MySQL.
Figura: Parametri per creare il gruppo di piani Aggiorna MySQL DNS DB

In Aggiungi passo gruppo di piani, immettere le informazioni riportate di seguito.
1. Immettere un nome di passo semplice ma descrittivo. In questo esempio verrà utilizzato Update MySQL DB DNS. Uguale al nome del gruppo di piani.
2. Selezionare un'area contenente l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito sull'applicazione WordPress VM1 nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero l'applicazione WordPress VM1 nell'area 1.
5. In Parametri script, immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/mds_copy_restore_bkp/mds_update_dns.py mds01 demo.local mds01.demo.local.
6. In Run as user immettere opc.
7. Fare clic su Aggiungi passo.
Figura: Parametri per creare Aggiungi un aggiornamento passo MySQL DNS DB

Fare clic su Aggiungi.

Figura: Aggiungi un gruppo di piani Aggiorna MySQL DNS DB
(Facoltativo) Aggiungere un gruppo di piani personalizzato per riavviare l'applicazione WordPress.
1. Fare clic su Aggiungi gruppo.
2. Immettere un Nome per il gruppo di piani semplice ma descrittivo. In questo esempio verrà utilizzato Application - Restart.
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 integrato File system - Attivazione su istanze di computazione.
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per avviare l'applicazione.
Figura: Parametri per creare un gruppo di piani Applicazione - Riavvia

In Aggiungi passo gruppo di piani, immettere le informazioni riportate di seguito.
1. Immettere un nome di passo semplice ma descrittivo. In questo esempio verrà utilizzato Application - Restart - VM1.
2. Selezionare un'area contenente l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito sull'applicazione WordPress VM1 nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero l'applicazione WordPress VM1 nell'area 1.
5. In Parametri script, immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/fsdrscripts/wdp_restart.sh.
6. In Run as user immettere opc.
7. Fare clic su Aggiungi passo.
Figura: Parametri per creare un'applicazione passo - Riavvia - VM1

Fare clic su Aggiungi passo per aggiungere un secondo passo per riavviare l'applicazione in VM2.

Figura: Aggiungi un'applicazione passo - Riavvia - VM2

In Aggiungi passo gruppo di piani, immettere le informazioni riportate di seguito.
1. Immettere un nome di passo semplice ma descrittivo. In questo esempio verrà utilizzato Application - Start - VM2.
2. Selezionare un'area contenente l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito sull'applicazione WordPress VM2 nell'area 1.
3. Selezionare Esegui script locale.
4. Selezionare l'istanza di destinazione, ovvero l'applicazione WordPress VM2 nell'area 1.
5. In Parametri script, immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/fsdrscripts/wdp_restart.sh.
6. In Run as user immettere opc.
7. Fare clic su Aggiungi passo.
Figura: Parametri per creare un'applicazione passo - Riavvia - VM2

Fare clic su Aggiungi.

Figura: Aggiungi un gruppo di piani Applicazione - Riavvia

La personalizzazione del piano di failover è stata completata.

Task 7: Esegui controlli preliminari nell'area 2

Creazione riuscita di entrambi i piani DR di switchover e failover nella standby region 2. Questi piani consentono a OCI Full Stack DR di eseguire la transizione dei carichi di lavoro dalla region 1 alla region 2. Il task successivo prevede l'esecuzione dei controlli preliminari per i piani di switchover e failover per garantire la prontezza e convalidare il processo di transizione.

Task 7.1: Avvia controlli preliminari per il piano di switchover

Eseguire controlli preliminari per il piano DR di switchover.

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 in standby.
Fare clic sul nome del piano di switchover.
Fare clic su Esegui controlli preliminari.

controlli preliminari-così-auh-begin.png
Figura: Visualizzazione di come eseguire controlli preliminari del piano di switchover

controlli preliminari-così-auh-complete.png
Figura: Visualizzazione di controlli preliminari completati del piano di switchover

Task 7.2: Avvia controlli preliminari per il piano di failover

Eseguire i controlli preliminari per il piano DR di failover.

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

controlli preliminari-fo-auh-begin.png
Figura: Visualizzazione di come eseguire i controlli preliminari del piano di failover

controlli preliminari-fo-auh-complete.png
Figura: Visualizzazione di controlli preliminari completati del piano di failover

Task 8: eseguire il piano di switchover nell'area 2

Eseguire il piano DR di switchover per avviare il processo di transizione dell'applicazione WordPress con Oracle HeatWave MySQL dall'area 1 all'area 2.

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 in standby.
Fare clic sul nome del piano di switchover.
Fare clic su Esegui piano.

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 DR per iniziare.

Figura: Visualizzazione di come eseguire il piano di switchover

Figura: Visualizzazione del piano di switchover in corso

Monitorare 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 in circa 52 minuti.

Figura: Visualizzazione dell'esecuzione di un piano di switchover completato.

Task 9: creare e personalizzare i piani DR nell'area 1

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

Seguire lo stesso approccio descritto nei task da 1 a 8, procedere alla creazione e alla personalizzazione dei piani di switchover e failover all'interno del gruppo di protezione DR per l'area 1, che ora funge da peer region in standby.

Figura: Screenshot che mostra i piani creati nell'area 1

Figura: Screenshot che mostra il piano di switchover nell'area 1

Figura: Screenshot che mostra il piano di failover nell'area 1

Passi successivi

Per ulteriori informazioni, consulta la documentazione su OCI Full Stack DR e Oracle HeatWave MySQL nella sezione Collegamenti correlati.

Recupero in seguito a calamità su Oracle Cloud Infrastructure (OCI) Full Stack
Oracle HeatWave MySQL
Recupero da errori irreversibili di OCI Full Stack
MySQL HeatWave
Unisciti al canale nero #full-stack-dr

Conferme

Autore - Antoun Moubarak (esperto di Hyperscaler in OCI)
Collaboratore - 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 gratuiti sulla formazione su Oracle Learning YouTube channel. Inoltre, visita education.oracle.com/learning-explorer per diventare un Oracle Learning Explorer.

Per la documentazione del prodotto, visita l'Oracle Help Center.

Titolo e informazioni sul copyright

Automate Cold Disaster Recovery for Oracle HeatWave MySQL using OCI Full Stack Disaster Recovery

G24411-01

January 2025

Oracle e/o relative consociate.