Automatizza le modifiche ai ruoli del database per Oracle Data Guard configurato manualmente nei servizi di database OCI utilizzando OCI Full Stack DR e script personalizzati

Introduzione

Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) gestisce la transizione di elaborazione, database e applicazioni tra le region di Oracle Cloud Infrastructure (OCI) da 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 Full Stack DR offre supporto completamente integrato per vari servizi Oracle Database su OCI. Questi database possono essere aggiunti come membri di un gruppo di protezione OCI Full Stack DR, consentendo operazioni di disaster recovery coordinate.

Per i servizi gestiti dai database Oracle in OCI, si consiglia di configurare Oracle Data Guard utilizzando OCI Console, Oracle Cloud Infrastructure Command Line Interface (OCI CLI) o OCI SDK. In questo modo, OCI Full Stack DR può rilevare automaticamente la configurazione Data Guard e generare gruppi di piani integrati per le transizioni dei ruoli nell'ambito del piano DR.

Tuttavia, ci sono scenari in cui la configurazione manuale di Oracle Data Guard (al di fuori delle interfacce native di OCI) diventa necessaria a causa di requisiti tecnici o operativi specifici, come:

Vincoli specifici dell'applicazione.
Configurazioni standby in cascata.
Uso di versioni precedenti del database a causa della compatibilità delle applicazioni.

In questi casi, anche se il piano di controllo dei servizi di database OCI potrebbe non riconoscere l'impostazione di Oracle Data Guard, OCI Full Stack DR offre ancora flessibilità. È possibile gestire le transizioni dei ruoli creando script personalizzati e integrandoli in gruppi di piani definiti dall'utente all'interno dei piani DR.

Tenere presente che questa soluzione non è compatibile con i servizi Oracle Database Cloud in cui le configurazioni Data Guard vengono gestite tramite la console OCI, gli SDK o le API.

In questa esercitazione illustreremo un approccio standardizzato per la gestione delle transizioni dei ruoli di Oracle Data Guard utilizzando script di handler di database personalizzati per i servizi di database OCI in cui Oracle Data Guard è stato configurato manualmente.

Nota: questa soluzione di script personalizzato si applica ai seguenti servizi di database OCI:

Oracle Base Database Service

Oracle Exadata Database Service on Dedicated Infrastructure

Oracle Exadata Database Service su infrastruttura Exascale

Oracle Exadata Database Service on Cloud@Customer

Descrizione architettura

In questa esercitazione, utilizzeremo Oracle Base Database Service con due sistemi DB distribuiti in due aree OCI, in cui Oracle Data Guard è stato configurato manualmente.

configurazione-guard-dati personalizzata
Figura A: Configurazione di Data Guard personalizzata mediante Oracle Base Database Service

Definizioni e ipotesi in tutta l'esercitazione

Aree:
- Area 1 (Ashburn): Ashburn fungerà inizialmente da area principale.
- Area 2 (Phoenix): Phoenix inizialmente funzionerà come standby region.
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.

Obiettivi

Questa esercitazione descrive i task riportati di seguito.

Task 1: verificare la configurazione di Oracle Data Guard e aggiornare le tag.
Task 2: creare e associare i gruppi di protezione DR.
Task 3: aggiungere membri ai gruppi di protezione DR.
Task 4: creare e personalizzare i piani DR nell'area 2.
Task 5: eseguire i controlli preliminari per i piani DR nell'area 2.
Task 6: eseguire il piano di switchover nell'area 2.
Task 7: creare e personalizzare i piani DR nell'area 2.

Prerequisiti

Useremo le seguenti risorse per iniziare con il tutorial.

Risorse	Regione 1 - Ashburn	Regione 2 - Phoenix
Compartimento	app	app
Sistema DB	adghol-12345	adghol-12345
Nome DB	adghol	adghol
Nome univoco DB	adghol-site0	adghol-site1
Ruolo DB	primari	standby
VM di computazione	ID script	script-phx
Bucket	IAD	PHX

Nota: completare tutti i prerequisiti necessari prima di continuare. Questi passi gettano le basi per un'impostazione OCI Full Stack DR fluida e di successo.

Accesso di amministrazione o criteri necessari per Oracle Cloud Infrastructure Identity and Access Management (OCI IAM).

Assicurarsi di disporre dei privilegi di amministratore o configurare i criteri IAM OCI e i gruppi dinamici necessari per utilizzare OCI Full Stack DR. In questa soluzione, lo script dell'handler di database avvia internamente un'istanza del contenitore OCI, quindi è necessario aggiungere i criteri di conseguenza.

Nota: sostituire tutte le occorrenze di <compartment_ocid> e <compartment_name> con l'OCID e il nome effettivi del compartimento OCI.

Creare un gruppo dinamico: creare un gruppo dinamico con il nome di esempio (FullStackDR_Database_DG) e aggiungere le seguenti regole di corrispondenza:

 Any {instance.compartment.id = '<compartment_ocid>'}
 Any {resource.type = 'instance', resource.compartment.id = '<compartment_ocid>'}
 Any {resource.type = 'computecontainerinstance', resource.compartment.id = '<compartment_ocid>'}
 Any {resource.type = 'drprotectiongroup', resource.compartment.id = '<compartment_ocid>'}

Creare un criterio IAM OCI: creare un criterio con il nome di esempio (FullStackDR_Database_Group_Policies) e aggiungere le istruzioni di inclusione riportate di seguito.

 Allow dynamic-group FullStackDR_Database_DG to read secret-family in compartment <compartment_name>
 Allow dynamic-group FullStackDR_Database_DG to manage virtual-network-family in compartment <compartment_name>
 Allow dynamic-group FullStackDR_Database_DG to manage instance-agent-command-family in compartment <compartment_name>
 Allow dynamic-group FullStackDR_Database_DG to manage instance-agent-command-execution-family in compartment <compartment_name>
 Allow dynamic-group FullStackDR_Database_DG to manage objects in compartment <compartment_name>
 Allow dynamic-group FullStackDR_Database_DG to manage database-family in compartment <compartment_name>
 Allow dynamic-group FullStackDR_Database_DG to manage compute-container-family in compartment <compartment_name>

Per ulteriori informazioni, vedere OCI Disaster Recovery Policies - Documenti ufficiali e Configurazione dei criteri IAM (Oracle Blog).

Eseguire il provisioning delle istanze di OCI Compute in entrambe le aree: crea un'istanza di OCI Compute in ogni area per fungere da Jumphost per l'hosting e l'esecuzione dei passi dettagliati di scripts.For. Vedere Crea istanza OCI. Per semplicità, ci riferiremo a questa istanza di OCI Compute come Jumphost in tutta la tutorial.If in cui hai già istanze di OCI Compute esistenti che possono funzionare come Jumphost, puoi saltare questo passo. Assicurarsi che Jumphost disponga dell'agente Oracle Cloud in esecuzione e che il plugin di comando di esecuzione sia abilitato. Per ulteriori dettagli, vedere Agente Oracle Cloud.
Accesso all'esecuzione di comandi sulle istanze di OCI Compute: assicurarsi di impostare i prerequisiti del comando di esecuzione in jumphost, poiché si utilizzano gruppi di piani definiti dall'utente per l'esecuzione degli script durante le operazioni di DR. Per ulteriori informazioni, vedere Esecuzione di comandi in un'istanza.
Installa OCI CLI in jumphost in entrambe le region: in base al sistema operativo di jumphost, installa OCI CLI in entrambe le region e assicurati di poter richiamare i comandi OCI CLI, nello script useremo il principal dell'istanza. Per ulteriori informazioni, vedere Installazione dell'interfaccia CLI OCI.
Imposta le reti VCN in entrambe le aree con peering VCN remoto: crea le reti VCN sia nelle aree primarie che in standby e imposta il peering VCN remoto. Questa operazione è necessaria per impostare Oracle Data Guard tra più aree. Per ulteriori informazioni, vedere Configurazione della rete OCI Base DB.
Configurazione manuale di Oracle Data Guard: configura manualmente l'impostazione di Oracle Data Guard in base ai requisiti con il broker Oracle Data Guard. Per ulteriori informazioni, vedere Oracle Data Guard Broker e Oracle Clusterware.
Scarica gli script dell'handler di database in Jumphost: gli script devono essere scaricati e mantenuti in jumphost in entrambe le regioni.
1. Scaricare gli script dell'handler di database Oracle Data Guard dal repository seguente: Script dell'handler di database Data Guard.
2. Copiare gli script nella directory /home/opc/ (o in qualsiasi altro percorso preferito) in jumphost in entrambe le aree.
3. Assicurarsi che i file di script dispongano delle autorizzazioni eseguibili.
4. full_stack_dr_non_std_db_handler.py è lo script Python responsabile della gestione degli script bash associati al ruolo transitions.The di Oracle Data Guard forniti come modelli e che possono essere modificati in base alle esigenze specifiche dell'utente. Non modificare lo script di modifica del ruolo Python stesso.
Crea vault e segreti OCI: è necessario creare un vault OCI e memorizzare le credenziali del database come segreti in entrambe le aree.
1. Creare un vault OCI in ogni area utilizzando la console OCI o l'interfaccia CLI.
2. Creare un segreto nel vault per memorizzare la password utente SYS per il database.
Per ulteriori informazioni, vedere Vault OCI.
Controlli della connettività da Jumphost: assicurati che il servizio OCI Database, il servizio OCI Vault e il servizio OCI Container Instance siano accessibili dall'istanza di computazione. Questa operazione è necessaria perché gli script OCI Full Stack DR eseguono l'introspezione per recuperare i dettagli del database da entrambe le aree Principale e In standby.
1. La connettività deve funzionare dal jumphost. Eseguire i seguenti comandi da jumphost.
```
  # Primary Region
  curl -v telnet://database.<primary_region>.oraclecloud.com:443
  curl -v telnet://secrets.vaults.<primary_region>.oci.oraclecloud.com:443
  curl -v telnet://iaas.<primary_region>.oraclecloud.com:443
  curl -v telnet://compute-containers.<primary_region>.oci.oraclecloud.com:443

  # Standby Region
  curl -v telnet://database.<standby_region>.oraclecloud.com:443
  curl -v telnet://secrets.vaults.<standby_region>.oci.oraclecloud.com:443
  curl -v telnet://iaas.<standby_region>.oraclecloud.com:443
  curl -v telnet://compute-containers.<standby_region>.oci.oraclecloud.com:443
```
  Nota: sostituire <primary_region> e <standby_region> con identificativi di area OCI effettivi.
  Ad esempio:
  - us-ashburn-1 per Ashburn
  - us-phoenix-1 per Phoenix
  Per un elenco completo, vedere Identificativi area OCI.
  
  Output previsto: ogni comando deve restituire un messaggio simile a Connected to ....
  
  Se una connessione non riesce, controllare le liste di sicurezza, le tabelle di instradamento e la configurazione del gateway di servizio della VCN o delle subnet di jumphost.
Crea bucket di storage degli oggetti: crea bucket di storage degli oggetti OCI nelle aree primarie e in standby per memorizzare i log generati da OCI Full Stack DR durante le operazioni di recupero, come spiegato qui: Preparazione della posizione di log per i log delle operazioni.

Uso e personalizzazione dello script dell'handler di database: è possibile scaricare gli script dell'handler di database dal repository GitHub indicato. Ecco l'uso dello script dell'handler del database e i parametri richiesti.

Figura B: Utilizzo dello script dell'handler DB

Le opzioni --db_operation supportate sono:

SWITCHOVER
SWITCHOVER_PRECHECK
FAILOVER
FAILOVER_PRECHECK
CONVERT_PHYSICAL_TO_SNAPSHOT_STANDBY
CONVERT_PHYSICAL_TO_SNAPSHOT_STANDBY_PRECHECK
REVERT_SNAPSHOT_TO_PHYSICAL_STANDBY_PRECHECK
REVERT_SNAPSHOT_TO_PHYSICAL_STANDBY

OCI Full Stack DR prevede che tutti i parametri necessari vengano passati durante l'esecuzione dello script dell'handler del database. Per una migliore usabilità e ripetibilità, si consiglia di creare uno script bash wrapper che:

Fornisce i parametri richiesti.
Abilita la registrazione per il controllo e la risoluzione dei problemi.

Esempio: script di switchover del database (db-switchover-iad-phx.sh).

#!/bin/bash

# Define log file with date and time
LOG_FILE="db-switchover-iad-phx-$(date +%Y%m%d_%H%M%S).log"

# Define Python script and argument
PYTHON_SCRIPT="full_stack_dr_non_std_db_handler.py"
ARGUMENT="--database_ocid="ocid1.database.oc1.phx.xxxxxxxx" --vault_ocid="ocid1.vaultsecr
et.oc1.phx.xxxxx" --region="us-phoenix-1" --primary_db_unique_name="adghol_site0" --st
andby_db_unique_name="adghol_site1" --drpg_ocid="ocid1.drprotectiongroup.oc1.phx.axxxxxxax
" --db_operation="SWITCHOVER" --auth_type=INSTANCE_PRINCIPAL"

# Execute Python script and log output
echo "Executing Python script: $PYTHON_SCRIPT with argument: $ARGUMENT" | tee -a $LOG_FILE
/usr/bin/python3 $PYTHON_SCRIPT $ARGUMENT 2>&1 | tee -a $LOG_FILE

echo "Execution completed. Logs saved in $LOG_FILE"

Nota: memorizzare questo script wrapper nella stessa posizione degli script dell'handler di database e assicurarsi che sia eseguibile. Gli OCID vengono resi anonimi nello script.
chmod +x db-switchover-wrapper.sh

Mapping script piano DR in cui il database in esecuzione nell'area 1 (Ashburn) è primario e l'area 2 (Phoenix) è in standby

Tipo di piano DR	Istanza destinazione	Nome dello script	Commenti
`Switchover`	`script-phx`	`db-prechk-switchover-iad-phx.sh`	Eseguire il backup preliminare dello switchover del database da IAD a PHX
`Switchover`	`script-phx`	`db-switchover-iad-phx.sh`	Switchover DB da IAD a PHX
`Failover`	`script-phx`	`db-prechk-failover-iad-phx.sh`	Eseguire il backup preliminare del failover del database da IAD a PHX
`Failover`	`script-phx`	`db-failover-iad-phx.sh`	Failover DB da IAD a PHX
`Start drill`	`script-phx`	`db-prechk-startdrill-phx.sh`	Prechk Avvia DR Drill in PHX
`Start drill`	`script-phx`	`db-startdrill-phx.sh`	Avvia DR Drill in PHX
`Stop drill`	`script-phx`	`db-prechk-stopdrill-phx.sh`	Prechk Stop DR Drill in PHX
`Stop drill`	`script-phx`	`db-stopdrill-phx.sh`	Arresta DR Drill in PHX

Mapping script piano DR in cui il database in esecuzione nell'area 2 (Phoenix) è primario e l'area 2 (Ashburn) è in standby

Tipo di piano DR	Istanza destinazione	Nome dello script	Commenti
`Switchover`	`script-iad`	`db-prechk-switchover-phx-iad.sh`	Eseguire il backup preliminare dello switchover del database da PHX a IAD
`Switchover`	`script-iad`	`db-switchover-phx-iad.sh`	Switchover DB da PHX a IAD
`Failover`	`script-iad`	`db-prechk-failover-phx-iad.sh`	Eseguire il backup preliminare del failover del database da PHX a IAD
`Failover`	`script-iad`	`db-failover-phx-iad.sh`	Failover DB da PHX a IAD
`Start drill`	`script-iad`	`db-prechk-startdrill-iad.sh`	Avvia drilling DR in IAD
`Start drill`	`script-iad`	`db-startdrill-iad.sh`	Avvia espansione DR in IAD
`Stop drill`	`script-iad`	`db-prechk-stopdrill-iad.sh`	Esegui drilling DR di arresto preliminare in IAD
`Stop drill`	`script-iad`	`db-stopdrill-iad.sh`	Arresta espansione DR in IAD

Nota: per una maggiore chiarezza e usabilità, abbiamo creato più script bash wrapper personalizzati in base a specifici tipi e aree di piano DR. Questi script utilizzano uno script Python condiviso per le transizioni dei ruoli di database, che è possibile personalizzare in base alle proprie esigenze e al proprio ambiente.

Task 1: verificare la configurazione di Oracle Data Guard e aggiornare la tag

In questo task, verificheremo la configurazione manuale di Oracle Data Guard utilizzando Oracle Base Database Service. Creeremo un *tag** nel database per indicare un'impostazione non standard di Oracle Data Guard. Ciò consente a OCI Full Stack DR di creare un piano di DR senza fare affidamento su gruppi di piani integrati.

Eseguire il login a OCI Console e andare a Oracle Database e fare clic su Oracle Base Database Service.
Assicurarsi che il contesto dell'area OCI sia impostato su Area 1 (Ashburn).
Selezionare il sistema DB, nel nostro esempio è adghol0-12345.

Figura 1.1: Sistema DB nell'area 1
Passare alla scheda Database e selezionare il database adghol.

Figura 1.2: Database nell'area 1
Verificare che lo stato Data Guard sia Non abilitato. Ciò conferma che Oracle Data Guard non è impostato utilizzando OCI Console.

Figura 1.3: Stato del piano di controllo Data Guard nell'area 1

Andare alla scheda Tag e creare le tag in formato libero. È necessario sostituire il valore di Peer DB OCID in base all'impostazione. In questo esempio, è necessario aggiungere l'OCID del database dell'area Phoenix.

Chiave tag	Valore
`FsdrNonStandardDataGuardPeerDatabaseId`	`Peer DB OCID`
`FsdrNonStandardDataGuardFlag`	`True`

tag iad-db-dataguard
Figura 1.4: tag DB nell'area 1

Andare a Sistemi DB e selezionare Nodi.

Figura 1.5: nodo DB nell'area 1

Nota: questa è un'impostazione Non RAC, pertanto verrà visualizzato un singolo nodo di database. Se si tratta di un'impostazione di Oracle Real Application Clusters, vengono visualizzati due nodi.
Connettersi al nodo del database e passare all'utente oracle. Utilizzare il broker Oracle Data Guard per verificare i ruoli.
```
dgmgrl
show configuration
```
Figura 1.6: Stato di Data Guard nell'area 1

Output previsto:
- adghol_site0 deve essere visualizzato come Database principale.
- adghol_site1 deve essere visualizzato come Database di standby fisico.
- Configuration Status deve essere visualizzato come Operazione riuscita.
In caso di errori e i ruoli del database non sono quelli previsti, è necessario correggere gli errori utilizzando la documentazione di Oracle Data Guard.
Eseguire il login a OCI Console e andare a Oracle Database e fare clic su Oracle Base Database Service.
Assicurati che il contesto dell'area OCI sia impostato su Area 2 (Phoenix).
Selezionare il sistema DB, nel nostro esempio è adghol1-12345

Figura 1.7: Sistema DB nell'area 2
Passare alla scheda Database e selezionare il database adghol.

Figura 1.8: Database nell'area 2
Verificare che lo stato Data Guard sia Non abilitato. Ciò conferma che Oracle Data Guard non è impostato utilizzando OCI Console.

Figura 1.9: Stato del piano di controllo Data Guard nell'area 2

Chiave tag	Valore
`FsdrNonStandardDataGuardPeerDatabaseId`	`Peer DB OCID`
`FsdrNonStandardDataGuardFlag`	`True`

tag phx-db-dataguard
Figura 1.10: tag DB nell'area 2

Ripetere i passi 7 e 8, ma questa volta connettersi al nodo del database nell'area 2 (area in standby).
- Assicurarsi di aver eseguito il login come utente oracle nel nodo del database Region 2.
- Verifica i ruoli di Oracle Data Guard utilizzando dgmgrl proprio come nel passo 8.

Task 2: Creazione e associazione di gruppi di protezione DR

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 come mostrato nella Figura 2.1.
1. Assicurarsi che il contesto dell'area OCI sia impostato su Area 1 (Ashburn).
2. Fare clic su Migrazione e disaster recovery.
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 nella regione 1 come mostrato 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 gruppo di protezione DR.
2. Fare clic su Crea gruppo di protezione DR.
3. Utilizzare un nome significativo per il gruppo di protezione DR.
4. Selezionare Bucket di storage degli oggetti OCI per i log OCI Full Stack DR.
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 alla console OCI, 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 (Phoenix).
2. Fare clic su Migrazione e disaster recovery.
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 nella regione 2 come mostrato 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 gruppo di protezione DR.
2. Fare clic su Crea gruppo di protezione DR.
3. Utilizzare un nome significativo per DRPG.
4. Selezionare Bucket di storage degli oggetti OCI per i log OCI Full Stack DR.
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 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 (Ashburn).
2. Fare clic sul menu a discesa Azioni e fare clic su Associa per avviare il processo.
Figura 2.5: Inizio dell'associazione DRPG
Immettere le informazioni riportate di seguito.
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 (Phoenix), in cui è stato creato l'altro gruppo di protezione DR.
3. Gruppo di protezione DR peer: selezionare il gruppo di protezione DR peer creato.
4. Fare clic su Associa.
Figura 2.6: Parametri necessari per associare i DRPG

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

L'attuale peer primario DRPG è Ashburn (regione 1).
Il peer di standby corrente DRPG è Phoenix (regione 2).

Figura 2.7: 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 nell'immagine seguente.

L'attuale peer primario DRPG è Ashburn (regione 1).
Il peer di standby corrente DRPG è Phoenix (regione 2).

Figura 2.8: Visualizzazione della relazione tra colleghi dal punto di vista DRPG globale

Task 3: Aggiunta di membri ai gruppi di protezione DR

In questo task, verranno aggiunte le risorse OCI riportate di seguito al gruppo di protezione DR primario nell'area 1.

L'istanza di OCI Compute che ospita lo script dell'handler del database verrà aggiunta come VM non mobile.
Il sistema DB principale.

Task 3.1: Aggiungi membri al gruppo di protezione DR nell'area 1

Selezionare il gruppo di protezione DR nell'area 1 come mostrato nell'immagine seguente.
1. Assicurarsi che il contesto dell'area OCI sia Area 1 (Ashburn).
2. Selezionare il gruppo di protezione DR nell'area 1.
3. Passare alla scheda Membri.
4. Fare clic su Gestisci membri.
Figura 3.1: Come iniziare ad aggiungere membri al gruppo di protezione DR nell'area 1
Aggiungere un'istanza di computazione per gli script dell'handler di database.
1. Selezionare Aggiungi membro
2. Selezionare Istanza in Computazione come membro Tipo di risorsa.
3. Selezionare l'istanza di computazione che ospita gli script dell'handler di database.
4. Selezionare Istanza non mobile.
5. Fare clic su Aggiungi.
Figura 3.2: Aggiunta dell'istanza di computazione a DRPG nell'area 1

Verificare l'istanza di computazione aggiunta.

Figura 3.2: Istanza di computazione aggiunta a DRPG nell'area 1
Aggiungere il database primario. Fare clic su Aggiungi membro
1. Selezionare Aggiungi membro
2. Selezionare Oracle Database -> Database (Base DB,ExaDB-D,ExaCC,ExaXS) come membro Tipo di risorsa.
3. Selezionare Oracle Base Database come Tipo di database.
4. Selezionare Sistema di database.
5. Selezionare Home database.
6. Selezionare Database.
7. Selezionare Segreto password del database
8. Fare clic su Aggiungi.
Figura 3.3: Parametri necessari per aggiungere il database primario

Verificare il database primario aggiunto e pubblicare entrambi i membri.

Figura 3.4: DB primario aggiunto a DRPG nell'area 1

Figura 3.5: Pubblicare i membri in DRPG nell'area 1

Dopo pochi minuti entrambi i membri dovrebbero essere disponibili sotto i membri.

Figura 3.6: Membri aggiunti al gruppo DRPG nell'area 1

Task 3.2: Aggiungere membri al gruppo di protezione DR nell'area 2

Selezionare il gruppo di protezione DR nell'area 2 come mostrato nell'immagine seguente.
1. Assicurati che il contesto dell'area OCI sia l'area 2 (Phoenix).
2. Selezionare il gruppo di protezione DR nell'area 2.
3. Passare alla scheda Membri.
4. Fare clic su Gestisci membri.
Figura 3.7: Come iniziare ad aggiungere membri al gruppo di protezione DR nell'area 2
Aggiungere un'istanza di computazione per gli script dell'handler di database.
1. Selezionare Aggiungi membro
2. Selezionare Istanza in Computazione come membro Tipo di risorsa.
3. Selezionare l'istanza di computazione che ospita gli script dell'handler di database.
4. Selezionare Istanza non mobile.
5. Fare clic su Aggiungi.
Figura 3.8: Aggiunta dell'istanza di computazione a DRPG nell'area 2

Verificare l'istanza di computazione aggiunta.

Figura 3.9: Istanza di computazione aggiunta a DRPG nell'area 2
Aggiungere il database in standby. Fare clic su Aggiungi membro
1. Selezionare Aggiungi membro
2. Selezionare Oracle Database -> Database (Base DB,ExaDB-D,ExaCC,ExaXS) come membro Tipo di risorsa.
3. Selezionare Oracle Base Database come Tipo di database.
4. Selezionare Sistema di database.
5. Selezionare Home database.
6. Selezionare Database.
7. Selezionare Segreto password del database
8. Fare clic su Aggiungi.
Figura 3.10: Parametri necessari per aggiungere il DB in standby

Verificare il database di standby aggiunto e pubblicare entrambi i membri.

Figura 3.11: DB in standby aggiunto a DRPG nell'area 2

Figura 3.12: Pubblica i membri in DRPG nell'area 2

Dopo pochi minuti entrambi i membri dovrebbero essere disponibili sotto i membri.

Figura 3.13: Membri aggiunti al gruppo DRPG nell'area 2

Task 4: Creazione e personalizzazione dei piani DR nell'area 2

In questa attività verranno creati i piani Switchover, Failover e Start Drill iniziali associati al gruppo di protezione DR in standby nell'area 2 (Phoenix).

Questi piani sono progettati per eseguire la transizione senza problemi del carico di lavoro dalla region primaria (Regione 1) alla standby region (Regione 2).

OCI Full Stack DR prepara questi piani con passi integrati basati sulle risorse dei membri aggiunte in precedenza.
Tuttavia, in questa esercitazione, poiché Oracle Data Guard è configurato manualmente (al di fuori del piano di controllo del database), non saranno disponibili gruppi di piani built-in per le transizioni dei ruoli del database Oracle.
Pertanto:
- Personalizzare i piani DR con gruppi di piani definiti dall'utente.
- Aggiungere gli script dell'handler di database per la gestione delle transizioni dei ruoli durante ogni tipo di piano (switchover, failover, drill).

I piani DR vengono sempre creati nel gruppo di protezione che detiene il ruolo di standby.

Poiché l'area 2 (Phoenix) è attualmente in standby, verranno creati tutti i piani DR iniziali in tale area.

Task 4.1: Creazione di piani DR

Creare piani DR selezionando il DRPG nell'area 2 (Phoenix)
1. Assicurati che il contesto dell'area OCI sia l'area 2 (Phoenix).
2. Selezionare il DRPG in standby nell'area 2.
3. Passare alla scheda Piani.
4. Fare clic su Crea piano.
Figura 4.1: Come iniziare a creare piani DR di base nell'area 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 piano come Switchover (pianificato).
Figura 4.2: Parametri necessari per creare il piano di switchover DR
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 semplice ma significativo.
2. Selezionare Tipo di piano come Failover (non pianificato).
Figura 4.3: Parametri necessari per creare il piano di failover DR
Creare un piano di drilling iniziale.

Seguire lo stesso processo per creare un piano di failover di base come mostrato nell'immagine seguente.
1. Immettere il Nome del piano di espansione iniziale semplice ma significativo.
2. Selezionare Tipo di piano come Failover (non pianificato).
Figura 4.4: Parametri necessari per creare il piano DR startdrill

Il gruppo di protezione DR in standby nell'area 2 dovrebbe ora avere i tre 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.

Figura 4.5: Visualizzazione dei tre piani DR che devono esistere nell'area 2 prima di procedere ulteriormente

Nota: OCI Full Stack DR consente di creare un piano stopdrill solo dopo che il piano startdrill è stato eseguito correttamente e lo stato del gruppo di protezione DR è Inattivo (drill in corso).

Task 4.2: Personalizzazione dei piani DR con i gruppi di piani definiti dall'utente

I piani DR creati nel task 4.1 non genereranno gruppi di piani integrati per le transizioni dei ruoli del database Oracle poiché l'impostazione di Oracle Data Guard è stata eseguita manualmente.

In questo task verrà descritto quanto segue.

Scopri come aggiungere gruppi di piani DR personalizzati e definiti dall'utente.
Definire i passi necessari per gestire le transizioni dei ruoli di Oracle Data Guard.

Ciò garantisce che i piani DR siano in grado di gestire completamente gli scenari di failover, switchover ed drilling che coinvolgono un ambiente Data Guard configurato manualmente.

Passare al piano di transizione creato nel task 4.1 e selezionare Gruppi di piani.

Figura 4.6: Come iniziare a personalizzare il piano di switchover nell'area 2
Iniziare aggiungendo gruppi di piani DR personalizzati definiti dall'utente per personalizzare il workflow DR in base alle esigenze specifiche delle modifiche apportate ai ruoli del database Oracle. I gruppi di piani richiameranno gli script necessari da jumphost script-iad nell'area 1.
Aggiungere un gruppo di piani definito dall'utente a Switchover DB.
1. Fare clic su Aggiungi gruppo
2. Immettere un nome gruppo di piani semplice ma descrittivo. In questo esempio verrà eseguita l'operazione DB Switchover.
3. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per eseguire la modifica del ruolo DB.
  
  Figura 4.7: Parametri per la creazione di un gruppo di piani per eseguire la modifica del ruolo DB
  
  In Aggiungi passo gruppo di piani immettere le informazioni riportate di seguito.
4. Immettere un nome del passo semplice ma descrittivo. In questo esempio, verrà utilizzato DB Switchover from IAD to PHX.
5. Selezionare l'area Istanza che contiene l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito su jumphost nella regione 2, quindi selezionare Phoenix.
6. Selezionare Esegui script locale.
7. Selezionare l'istanza di destinazione, ovvero l'istanza jumphost script-phx nell'area 2.
8. In Parametri script immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/db-switchover-iad-phx.sh.
9. In Esegui come utente immettere opc.
10. Fare clic su Aggiungi passo.
  
  Figura 4.8: Parametri per aggiungere un passo per la modifica del ruolo DB
11. Verificare il passo aggiunto.
  
  Figura 4.9: Aggiunta per la modifica del ruolo DB
12. Fare clic su Aggiungi.
  
  Figura 4.10: Aggiunta del gruppo di modifica dei ruoli DB
  
  Il gruppo di piani sarà ora disponibile.
  
  Figura 4.11: Gruppo di piani di switchover DB
Aggiungere un passo di controllo preliminare definito dall'utente a un piano DR di switchover. Il controllo predefinito definito dall'utente verrà eseguito insieme ai passi di controllo preliminare integrati.
1. Andare a Gruppi di piani, fare clic su ... prima di Prechecks-Built e selezionare Aggiungi controllo preliminare definito dall'utente.
  
  Figura 4.12: Aggiunta di un controllo preliminare personalizzato per lo switchover del database
2. Immettere un nome del passo semplice ma descrittivo. In questo esempio, verrà utilizzato DB Switchover precheck from IAD to PHX.
3. Selezionare l'area Istanza che contiene l'istanza su cui verrà eseguito questo passo. In questo esempio, lo script verrà eseguito su jumphost nella regione 2, quindi selezionare Phoenix.
4. Selezionare Esegui script locale.
5. Selezionare l'istanza di destinazione, ovvero l'istanza script-phx jumphost nell'area.
6. In Parametri script immettere il percorso completo dello script con i parametri. Ad esempio: /home/opc/db-prechk-switchover-iad-phx.sh.
7. In Esegui come utente immettere opc.
8. Fare clic su Aggiungi passo.
  
  Figura 4.13: Parametri per l'aggiunta di un passo di controllo preliminare personalizzato per la modifica del ruolo DB
9. Verificare il passo aggiunto.
  
  Figura 4.14: Aggiunta del passo di controllo preliminare personalizzato per la modifica del ruolo DB
  
  La personalizzazione del piano di switchover è stata completata.
  
  Figura 4.15: Piano di switchover finale
Personalizzare in modo simile i piani failover e start drill, utilizzare l'istanza di destinazione e gli script corretti utilizzando i dettagli in formato tabella disponibili in Prerequisiti: uso e personalizzazione degli script dell'handler DB.
Una volta aggiunti il gruppo di piani definito dall'utente e il passo di controllo preliminare personalizzato, i piani Failover e Start Drill verranno visualizzati di seguito.

Figura 4.16: Piano di failover finale

Figura 4.17: Piano di espansione iniziale finale

Task 5: Esegui controlli preliminari per piani DR nell'area 2

Con lo switchover, il failover, i piani DR startdrill sono stati creati correttamente nell'area standby 2. Questi piani consentono a OCI Full Stack DR di eseguire la transizione dei carichi di lavoro dall'Area 1 all'Area 2 o eseguire il DR drill. Il task successivo prevede l'esecuzione dei controlli preliminari per i piani DR per garantire la disponibilità e convalidare il processo di transizione.

Task 5.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 menu a discesa Azioni.
Fare clic su Esegui controlli preliminari.
Selezionare il piano Switchover DB da IAD a PHX.
Inserire Nome esecuzione piano, in caso contrario verrà generata automaticamente.
Fare clic su Esegui controlli preliminari.

Figura 5.1: Come eseguire i controlli preliminari del piano di switchover
Verificare lo stato Riuscito nella scheda Esecuzioni piano.

Figura 5.2: Visualizzazione di controlli preliminari completati del piano di switchover

Task 5.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 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 menu a discesa Azioni.
Fare clic su Esegui controlli preliminari.
Selezionare il piano Failover DB da IAD a PHX.
Inserire Nome esecuzione piano, in caso contrario verrà generata automaticamente.
Fare clic su Esegui controlli preliminari.

Figura 5.3: Come eseguire i controlli preliminari del piano di failover
Verificare lo stato Riuscito nella scheda Esecuzioni piano.

Figura 5.4: Visualizzazione di controlli preliminari completati del piano di failover

Task 5.3: Inizia controlli preliminari per il piano di espansione iniziale

Eseguire i controlli preliminari per il piano DR startdrill.

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 menu a discesa Azioni.
Fare clic su Esegui controlli preliminari.
Selezionare il piano Avvia drilling in PHX.
Inserire Nome esecuzione piano, in caso contrario verrà generata automaticamente.
Fare clic su Esegui controlli preliminari.

Figura 5.5: Visualizzazione di come eseguire i controlli preliminari del piano di espansione iniziale
Verificare lo stato Riuscito nella scheda Esecuzioni piano.

Figura 5.6: Visualizzazione di controlli preliminari completati del piano di failover

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

Eseguire il piano di switchover DR per avviare la transizione del ruolo del database Oracle dall'area 1 (principale) all'area 2 (in standby).

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 menu a discesa Azioni.
Fare clic su Esegui piano.

Figura 6.1: Visualizzazione di come eseguire il piano di switchover
Selezionare il piano Switchover DB da IAD a PHX.
Questo task esegue il piano di switchover nell'area 2.
Deselezionare Abilita controlli preliminari, poiché i controlli preliminari sono già stati eseguiti nel task 5. Se si desidera eseguire di nuovo, è possibile abilitarla.
Inserire Nome esecuzione piano, in caso contrario verrà generata automaticamente.
Fare clic su Esegui piano.

Figura 6.2: Visualizzazione di come eseguire il piano di switchover
Passare alla scheda Esecuzioni piano e selezionare l'esecuzione del piano di switchover.

Figura 6.3: Visualizzazione del piano di switchover in corso
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 8 minuti.

Figura 6.4: Visualizzazione di un'esecuzione del piano di switchover completata.
È possibile verificare lo stato del ruolo del database utilizzando i dettagli forniti nel task 1.8.

Figura 6.5: Stato di Data Guard dopo lo switchover

Output previsto:
- adghol_site1 deve essere visualizzato come Database principale.
- adghol_site0 deve essere visualizzato come Database di standby fisico.
- Configuration Status deve essere visualizzato come Operazione riuscita.
Il ruolo nel gruppo di protezione DR verrà scambiato, l'area 2 verrà visualizzata come Principale e l'area 1 verrà visualizzata come In standby.

Figura 6.6: modifica del ruolo di protezione DR dopo lo switchover

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

Con la riuscita esecuzione del piano DR di switchover dall'area 1 all'area 2, l'area 2 ha ora assunto il ruolo di primaria, mentre l'area 1 è passata al ruolo di standby.

Seguire lo stesso approccio descritto nel task 4 per creare e personalizzare i piani di switchover, failover e DR Drill all'interno del gruppo di protezione DR per l'area 1, che ora funge da peer region in standby.

Dopo aver creato e aggiornato questi piani con gruppi di piani definiti dall'utente e un passo di controllo preliminare personalizzato, avranno l'aspetto delle immagini riportate di seguito.

Figura 7.1: Piani DR creati nell'area 1

Figura 7.2: Piano di switchover nell'area 1

Figura 7.3: Piano di failover nell'area 1

Figura 7.4: Avvia piano drill nell'area 1

Se necessario, è possibile eseguire il piano di switchover per promuovere il database nell'area 1 di nuovo al ruolo principale, mentre il database nell'area 2 diventa il standby.

Analogamente, è possibile eseguire il piano start drill per simulare un evento di disaster recovery, quindi creare ed eseguire il piano stop drill per ripristinare lo stato originale del sistema.

Durante il piano start drill, il database viene convertito da un standby fisico a un standby snapshot. Ciò consente alle applicazioni di accedere e interagire temporaneamente con il database in standby a scopo di test.
Durante il piano stop drill, il database viene riconvertito da Standby snapshot a Standby fisico, assicurandosi che venga risincronizzato con il database primario.

Passi successivi

Per ulteriori informazioni, consultare la documentazione di OCI Full Stack DR, Oracle Base Database Service e Oracle Data Guard nella sezione Collegamenti correlati.

Conferme

Autore - Suraj Ramesh (Senior Principal Product Manager per OCI Full Stack DR)
Contributiors - Santhosh Shankaramanchi (Consulting Member dello staff tecnico 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 Role Changes for Manually Configured Oracle Data Guard in OCI Database Services Using OCI Full Stack DR and Custom Scripts

G45726-03

Oracle e/o relative consociate.