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 per Oracle Integration utilizzando OCI Full Stack Disaster Recovery

Parte 1: Introduzione

Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) orchestra la transizione di computazione, database e applicazioni tra le region Oracle Cloud Infrastructure (OCI) di tutto il mondo con un semplice 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.

Oracle Integration è una piattaforma unificata e sicura che ti consente di connettere applicazioni cloud e on-premise, automatizzare i processi aziendali, ottenere insight sul tuo business attraverso l'analisi delle metriche aziendali e sviluppare applicazioni Web e mobile. Oracle Integration è disponibile in un'area OCI governata dagli SLA (Service-Level Agreement). Questa esercitazione descrive in dettaglio la procedura per creare una soluzione di disaster recovery gestita dal cliente e tra più aree per Oracle Integration, in particolare per la funzione di integrazione in Oracle Integration.

Oracle Integration è un'offerta OCI Platform as a Service (PaaS) gestita che non è qualcosa che OCI Full Stack DR può gestire in modo nativo poiché Oracle Integration stesso non espone la computazione, lo storage o il database agli utenti OCI. Tuttavia, OCI Full Stack DR può automatizzare il ripristino per le offerte PaaS a condizione che il team di progettazione per un determinato servizio come Oracle Integration abbia documentato un modo per eseguire il provisioning, configurare e recuperare il servizio per il disaster recovery tra le region OCI. Il team di progettazione di Oracle Integration ha documentato Configuring a Disaster Recovery Solution for Oracle Integration Generation 2 spiegando come eseguire manualmente il provisioning, configurare e recuperare Oracle Integration.

OCI Full Stack Disaster Recovery (DR) non viene utilizzato per eseguire il provisioning o configurare Oracle Integration. È necessario eseguire il provisioning e la configurazione di Oracle Integration per il DR in più aree seguendo le istruzioni dettagliate riportate in Configuring a Disaster Recovery Solution for Oracle Integration Generation 2 prima di tentare di utilizzare il DR OCI Full Stack in qualsiasi modo.

I passi di failover manuale prescritti dal team di progettazione di Oracle Integration nella presente documentazione: Configuring a Disaster Recovery Solution for Oracle Integration Generation 2 devono essere testati correttamente per lo switchover e lo switchback prima di utilizzare OCI Full Stack DR.

Oracle Integration fa normalmente parte di un sistema più grande

In questa esercitazione si presuppone che Oracle Integration sia l'unica applicazione aggiunta ai gruppi di protezione DR. Ciò non è normale.

Questa esercitazione è insolita perché solo Oracle Integration viene mostrato e discusso nel documento per semplificare le operazioni. In genere, Oracle Integration sarà semplicemente una piccola parte di un sistema aziendale molto più grande e complesso che include molti servizi e applicazioni diversi in un singolo gruppo di protezione DR OCI Full Stack e set di piani DR. È molto probabile che si seguano esercitazioni simili a Oracle Help Center (OHC) per altre applicazioni e servizi quali PeopleSoft, WebLogic Server, Oracle Analytics Cloud e così via.

Nota: i passi di questa esercitazione sono stati testati utilizzando Oracle Integration Generation 2. Questa esercitazione spiega come implementare il DR per le funzionalità di integrazione delle applicazioni di Oracle Integration Generation 2, perché non vogliamo sopraffare il lettore introducendo troppe parti e pezzi in movimento.

Attenzione all'implementazione incrementale

L'aggiunta di più membri a un gruppo di protezione DR dopo la creazione dei piani DR eliminerà tutti i piani DR esistenti nei gruppi di protezione in entrambe le aree.

OCI Full Stack DR è progettato con il presupposto che l'intero stack di applicazioni per un determinato sistema aziendale sia già distribuito nelle region OCI e che il DR manuale abbia già dimostrato di funzionare. Se il sistema aziendale include più di Oracle Integration, aggiungere tutti i membri per tutte le altre applicazioni o servizi OCI ai gruppi di protezione DR prima di creare qualsiasi piano DR.

Come funziona il recupero

La soluzione di recupero per Oracle Integration richiede OCI Full Stack DR per eseguire una serie di script bash personalizzati durante un'operazione di recupero, ad esempio un failover o uno switchover. Gli script a cui si fa riferimento in questa esercitazione vengono forniti dal team degli specialisti di Oracle Integration e sono disponibili in un repository GitHub specifico per questa soluzione DR di Oracle Integration. Gli script bash vengono scaricati in un'istanza di computazione che fa parte dello stack di applicazioni che OCI Full Stack DR gestirà durante un'operazione di recupero.

Per una guida generica sono disponibili i seguenti script. È possibile utilizzare script personalizzati o personalizzarli in base ai criteri aziendali e ai requisiti di sicurezza. È necessario installare l'interfaccia CLI OCI e configurare le credenziali per utilizzare gli script.

Inoltre, per assicurarsi che l'istanza primaria venga aggiornata con i parametri pianificati più recenti, assicurarsi che il file integrations.json venga aggiornato con tutti i nomi di integrazione insieme ai dettagli della versione, insieme al file integration_parameters.json, che deve essere mantenuto aggiornato con i valori dei parametri pianificati più recenti per tutte le integrazioni pianificate. È possibile utilizzare il processo CI/CD preferito per raggiungere questo obiettivo.

Questa esercitazione spiega come scaricare gli script e come utilizzarli in un passo successivo. Questa esercitazione utilizza l'opzione 2 riportata di seguito per ospitare gli script bash solo perché l'esercitazione non include altro che Oracle Integration.

Opzione 1 per gli script di hosting

Oracle Integration è spesso parte di un sistema aziendale più grande e complesso che include un'applicazione come Oracle E-Business Suite, PeopleSoft o JD Edwards Enterprise, oltre ad altri database, istanze di computazione e applicazioni sviluppate internamente. In questo caso, è sufficiente scegliere una qualsiasi delle istanze di computazione "mobili" che fanno già parte del sistema aziendale per ospitare gli script. L'istanza di computazione selezionata può essere qualsiasi istanza in cui è installato Oracle Linux e molto probabilmente sarà una VM esistente che ha un altro scopo, ad esempio un server applicazioni o un server di amministrazione di qualche tipo.

Questa esercitazione fa riferimento a questa particolare istanza di computazione come Nodo di controllo o Nodo DR anche se in realtà soddisfa un altro scopo nello stack di applicazioni.

Opzione 2 per gli script di hosting

Se si tratta di una circostanza insolita in cui Oracle Integration sarà l'unico servizio applicativo che OCI Full Stack DR gestirà durante un'operazione di recupero, sarà necessario creare un'istanza di computazione solo per ospitare gli script.

In genere, OCI Full Stack DR non richiede alcun server di gestione specializzato per automatizzare le operazioni di ripristino. Tuttavia, in questo caso, creerai un'istanza di computazione che fungerà da server di gestione specializzato poiché Oracle Integration non è qualcosa che OCI Full Stack DR può gestire in modo nativo. Il server di gestione specializzato viene visualizzato in questo documento come Nodo di controllo o Nodo DR. L'intero scopo del nodo di controllo è semplicemente quello di fungere da server in cui gli script personalizzati possono risiedere ed essere richiamati da OCI Full Stack DR durante un'operazione di recupero. Questa esercitazione spiega come creare gruppi e passi di piani DR personalizzati e definiti dall'utente nell'ambito dei piani DR per richiamare gli script installati sul nodo di controllo.

Architettura di distribuzione di Oracle Integration

Come illustrato nella figura, l'architettura DR di Oracle Integration Generation 2 include due istanze di Oracle Integration, distinte come primarie e secondarie, che operano contemporaneamente. Tuttavia, il traffico viene indirizzato a una sola istanza alla volta. Inizialmente, il traffico passa all'istanza primaria. Se l'istanza primaria diventa non disponibile, il record DNS viene modificato per reindirizzare il traffico all'istanza secondaria.

Figura 1: Architettura di riferimento DR di Oracle Integration

Una volta eseguito il provisioning delle istanze, esportare i metadati dall'istanza primaria all'istanza di standby. Puoi farlo utilizzando le API REST o utilizzando l'interfaccia utente di Oracle Integration per esportare e importare i metadati. Una volta completata questa migrazione iniziale e una tantum dei metadati, è necessario mantenere sincronizzati i metadati tra le istanze utilizzando CICD. Puoi utilizzare Jenkins o uno strumento simile per implementare CICD per le tue istanze e sincronizzare i metadati. Puoi anche utilizzare un'istanza di OCI Compute come server CI Jenkins e hub CD.

Prima di introdurre OCI Full Stack DR, è necessario eseguire il provisioning e la configurazione di Oracle Integration per il disaster recovery (DR) nelle region OCI. È estremamente importante che i passi manuali per lo switchover di Oracle Integration come documentato dalla progettazione di Oracle Integration vengano testati e funzionino correttamente prima di tentare di automatizzare il processo di switchover/failover utilizzando OCI Full Stack DR.

Acquisire familiarità con l'intero processo

Il team di ingegneri di Full Stack Disaster Recovery ha creato una serie di video complementari per questo tutorial per comprendere l'intero flusso di processo. Questi video fanno parte di una playlist di OCI Full Stack DR Oracle Integration in YouTube alla quale è possibile accedere utilizzando i seguenti collegamenti:

Parte 2: Istruzioni dettagliate

Questa parte inizia con le istruzioni dettagliate necessarie per aggiungere Oracle Integration a OCI Full Stack DR.

Obiettivi

Questa esercitazione descrive come automatizzare il ripristino per Oracle Integration utilizzando OCI Full Stack DR:

Task 1: Distribuire Oracle Integration per il recupero da errori irreversibili nelle region OCI
1. Prepara nodo controllo DR Oracle Integration
2. Scarica script personalizzati nel nodo di controllo DR
3. Installa e distribuisci manualmente Oracle Integration for DR in due region OCI
4. Test manuale di tutti i passi di recupero dalla regione desiderata 1 alla regione 2
5. Test manuale di tutti i passi di recupero dalla regione desiderata 2 alla regione 1
Task 2: Preparati per OCI Full Stack DR
1. Crea criteri IAM per OCI Full Stack DR
2. Crea criteri IAM per altri servizi OCI
3. Crea bucket di storage degli oggetti per i log
Task 3: Creare gruppi di protezione DR (DRPG)
Task 4: Aggiungi membri a DRPG area 1
Task 5: Creare piani DR nella regione 2 (Phoenix)
1. Crea piano switchover
2. Crea piano di failover
Task 6: Personalizzare il piano di switchover nella regione 2 (Phoenix)
Task 7: Personalizzare il piano di failover nell'area 2 (Phoenix)
Task 8: Esegui il piano di switchover nella regione 2 (Phoenix)
Task 9: Creare piani DR di base nell'area 1 (Ashburn)
1. Crea piano switchover
2. Crea piano di failover
Task 10: Personalizzare il piano di switchover nell'area 1 (Ashburn)
Task 11: Personalizzare il piano di failover nell'area 1 (Ashburn)

Definizioni e ipotesi in tutta l'esercitazione

Aree

La regione 1 è Ashburn
- Ashburn inizierà come regione primaria.
- Questo ruolo verrà modificato in standby dopo aver ricevuto l'istruzione di eseguire uno switchover nei passi successivi.
La regione 2 è Phoenix
- Phoenix inizierà come standby region.
- Questo ruolo alla fine passerà a primario dopo aver ricevuto istruzioni per eseguire uno switchover nei passi successivi.

Compartimenti

Puoi organizzare Oracle Integration e OCI Full Stack DR in qualsiasi schema compartimento che funzioni all'interno degli standard per la governance IT. Abbiamo scelto di organizzare le applicazioni nei propri compartimenti individuali, quindi organizzare tutti i gruppi di protezione DR in un unico compartimento in cui è possibile visualizzare tutti i sistemi aziendali completamente diversi a colpo d'occhio.

Organizzare tutti i gruppi di protezione DR in un unico compartimento a parte le applicazioni rende molto più facile per il personale IT individuare ed eseguire piani di DR per molti sistemi aziendali completamente diversi.
Avere un unico compartimento per tutti i gruppi di protezione DR aiuta a eliminare l'errore umano e aumenta la velocità con cui è possibile trovare ed eseguire i piani DR
- Compartimento per Oracle Integration: OIC-demo. In questa esercitazione, il compartimento per OIC stesso, lo storage, i bucket di storage, la computazione e il database correlati a OIC è OIC-demo.
- Compartimento per OCI Full Stack DR: OIC-demo Il compartimento per i piani e i gruppi di protezione DR OCI Full Stack è OIC-demo in questa esercitazione.

Nodo di controllo DR di Oracle Integration

Il nodo DR Control è qualsiasi istanza di computazione designata per ospitare script bash personalizzati che eseguono task specifici per recuperare Oracle Integration. Gli script vengono richiamati da OCI Full Stack DR durante un'operazione di ripristino. Questa esercitazione spiega come aggiungere gli script a OCI Full Stack DR nei passi 6, 7, 10 e 11.

Per Oracle Integration come applicazione standalone: si tratta di un'istanza di computazione specializzata creata per fungere da host per gli script personalizzati.
Per Oracle Integration come parte di uno stack di applicazioni: si tratterà di qualsiasi istanza di computazione esistente membro di un gruppo di protezione DR (DRPG). Ad esempio, Oracle E-Business Suite o PeopleSoft disporrà di server applicazioni che sono membri degli stessi DRPG che gestiscono il recupero per Oracle Integration; uno di questi può svolgere il ruolo di nodo di controllo DR in questa esercitazione.

Prerequisiti

Oracle Integration deve essere distribuito per il disaster recovery in entrambe le aree prima di iniziare a lavorare con OCI Full Stack DR. Questo è descritto nel seguente Task 1.

Task 1: Distribuire Oracle Integration per il disaster recovery

OCI Full Stack DR non è coinvolto in alcuna parte di questo passo.

Task 1.1: preparare il nodo di controllo DR per eseguire l'automazione personalizzata

Designare un'istanza di computazione per fungere da nodo di controllo DR per OIC. Può essere un'istanza di computazione esistente oppure un'istanza di computazione creata solo per questo scopo. Vedere le opzioni riportate di seguito per maggiori dettagli. Assicurarsi che le istanze di computazione che fungono da nodo di controllo DR siano state configurate per eseguire i comandi utilizzando l'agente cloud OCI: Esecuzione dei comandi su un'istanza.

Opzione 1: Oracle Integration come applicazione standalone

Questa esercitazione presuppone che Oracle Integration sia un servizio standalone, pertanto creerai un'istanza di computazione con Oracle Linux nell'area 1. Utilizza la forma a basso costo con Oracle Linux poiché verrà utilizzata solo per ospitare gli script bash personalizzati. La necessità di un'istanza di computazione specializzata dedicata a svolgere questo ruolo è insolita; l'opzione 2 è lo scenario più comune per la maggior parte delle organizzazioni.

L'istanza di computazione specializzata verrà aggiunta come membro del gruppo di protezione DR nell'area 1 in un passo successivo.

Opzione 2: Oracle Integration come parte di uno stack di applicazioni

Puoi utilizzare qualsiasi singola computazione mobile esistente che fa parte di qualsiasi applicazione Oracle o non Oracle gestita da OCI Full Stack DR nell'area 1. Questo adempirà al ruolo del nodo di controllo DR ogni volta che questa esercitazione fa riferimento al nodo di controllo DR.

È preferibile utilizzare un'istanza di computazione mobile, ma puoi anche designare un'istanza di computazione non mobile nell'area 1 e un'altra nell'area 2 se non hai alcuna computazione mobile come parte della tua soluzione DR. Se per questo ruolo viene utilizzata la computazione non mobile per questo ruolo, dovrai modificare gli script o il sistema operativo guest in entrambe le aree.

Opzione 3: Oracle Integration come parte di uno stack di applicazioni con più offerte PaaS

Forse il tuo sistema aziendale dispone anche di Oracle HTTP Server (OHS), Oracle Integration e Oracle Data Integrator (ODI). In questo caso, potresti prendere in considerazione la creazione di un'istanza di computazione specializzata come si farebbe con l'opzione 1 per ospitare gli script di recupero DR per tutti i vari servizi PaaS.

Task 1.2: assicurarsi che il gruppo di volumi sia replicato nell'area 2

Assicurarsi che il volume di avvio per il nodo DR Control sia membro di un gruppo di volumi a blocchi e che il gruppo di volumi a blocchi venga replicato nell'area 2.

Assicurarsi che qualsiasi altro avvio e blocco appartenga a qualsiasi altra computazione mobile per questo progetto DR OCI Full Stack appartenga anche ai gruppi di volumi a blocchi replicati nell'area 2. Se hai bisogno di ulteriori dettagli, consulta la documentazione sullo storage a blocchi OCI

Task 1.3: Scarica script bash nel nodo di controllo DR

Scarica gli script bash personalizzati da github scritti in modo specifico per questa soluzione DR di Oracle Integration. Gli script mostrati di seguito devono essere copiati in qualsiasi sottodirectory dell'istanza di computazione che funge da nodo di controllo DR per Oracle Integration

Il collegamento sopra riportato dovrebbe risolvere il problema con il repository GitHub:

Mostra il percorso del repository in cui si trovano gli script bash in GitHub.
Questo mostra il repository che contiene gli script bash.

Figura 2-4: Screenshot del repository github contenente script bash per Oracle Integration

Task 1.4: Distribuire Oracle Integration per DR

Distribuisci Oracle Integration per il recupero da errori irreversibili nelle region OCI utilizzando le istruzioni dettagliate fornite dal team di progettazione di Oracle Integration.

Task 1.5: Test manuale del recupero di Oracle Integration

È consigliabile assicurarsi che i passi di ripristino manuale I passi manuali per recuperare Oracle Integration documentati in Configurazione di disaster recovery per Oracle Integration devono avere successo prima di utilizzare OCI Full Stack DR.

Task 1.6: Passi successivi

Tornare a questo documento per iniziare a lavorare con OCI Full Stack DR una volta completati i seguenti requisiti.

Distribuisci manualmente Oracle Integration for DR in due region OCI desiderate.
Test manuale di tutti i passi di recupero dall'area 1 (Ashburn) all'area 2 (Phoenix).
Test manuale di tutti i passi di recupero dall'area 2 (Phoenix) all'area 1 (Ashburn).

Task 2: Preparati per OCI Full Stack DR

OCI Full Stack DR non è coinvolto in alcuna parte di questo passo. I passi riportati di seguito preparano la tenancy, il compartimento, i servizi OCI e Oracle Integration per il recupero automatico da parte di OCI Full Stack DR.

Task 2.1: Creare criteri IAM per OCI Full Stack DR

Configura i criteri IAM OCI necessari per Full Stack Disaster Recovery, come descritto nei documenti riportati di seguito.

Task 2.2: 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, vault, database e altri servizi vari. Configurare i criteri IAM OCI necessari per altri servizi come spiegato nel seguente documento.

Criteri per altri servizi gestiti da Full Stack Disaster Recovery.

Task 2.3: Creare bucket di storage degli oggetti OCI per i log DRPG

Nota: ignorare completamente il task 2.3 se si aggiunge Oracle Integration ai gruppi di protezione DR esistenti.

Crea bucket di storage degli oggetti OCI nelle region primarie e standby per memorizzare i log generati da DR Full Stack OCI durante le operazioni di recupero: Storage degli oggetti.

Task 2.3.1: passare a OCI Object Storage

Inizia passando a Storage degli oggetti e Storage di archivio come mostrato nella Figura 2-1 di seguito

Assicurarsi che il contesto del browser sia impostato sull'area 1 (Ashburn).
Seleziona memorizzazione.
Seleziona bucket.

Figura 2-1: Passare allo storage degli oggetti

Task 2.3.2: bucket di storage OCI nella region 1

Creare un bucket di storage degli oggetti nell'area 1. Il bucket verrà assegnato al gruppo di protezione DR nell'area 1 in un passo successivo.

Selezionare il compartimento che contiene le risorse correlate a OIC.
Selezionare Crea bucket.
Assegnare al bucket un nome significativo che identifichi facilmente l'applicazione e lo scopo a cui serve; non c'è motivo di includere l'area come parte del nome. Ad esempio, questo nome indica che viene utilizzato per i log DR di OCI Full Stack correlati alle operazioni DR per OIC.
Utilizzare il valore predefinito per il livello e la cifratura.
Selezionare Crea per creare il bucket.

Figura 2-2: Creare un bucket di storage degli oggetti nell'area 1

Task 2.3.3: bucket di storage OCI nella region 2

Segui lo stesso processo per creare un bucket di storage degli oggetti nell'area 2 (Phoenix). Il bucket verrà assegnato al gruppo di protezione DR nell'area 2 in un passo successivo.

Modificare il contesto nell'area 2.
Selezionare il compartimento che contiene le risorse correlate a OIC nell'area 2.
Utilizza lo stesso nome esatto assegnato al bucket nell'area 1. Ciò semplificherà l'identificazione in un passo successivo.
Selezionare Crea per creare il bucket.

Figura 2-3: Creare un bucket di storage degli oggetti nell'area 2

Task 3: Creare gruppi di protezione DR in entrambe le aree

Nota: ignorare completamente il task 3 se Oracle Integration viene aggiunto ai gruppi di protezione DR esistenti.

Creare 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 3.1: Passare ai gruppi di protezione DR

Inizia passando a Gruppi di protezione DR (OCI Full Stack DR) come mostrato nella Figura 3-1 di seguito.

Assicurarsi che il contesto dell'area OCI sia impostato sull'area 1 (Ashburn).
Selezionare Migrazione e disaster recovery.
Selezionare i gruppi di protezione DR.

Figura 3-1: Passare ai gruppi di protezione DR

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

Creare un gruppo di protezione DR di base (DRPG) nella regione 1 come illustrato nella figura 3-2 riportata di seguito. Il peer, il ruolo e i membri verranno assegnati nei passi successivi.

Selezionare il compartimento in cui si desidera creare il DRPG. Può trattarsi dello stesso compartimento in cui esistono risorse Oracle Integration o, come in questo caso, di un compartimento che funge da repository contenente DRPG per molti sistemi aziendali diversi.
Selezionare Create DR Protection Group per aprire la finestra di dialogo.

Figura 3-2: Iniziare a creare un gruppo di protezione DR nell'area 1

Aggiungere un nome e un bucket di storage degli oggetti per i log, come illustrato nella Figura 3-3 riportata di seguito.

Utilizzare un nome semplice e significativo per il DRPG. Questo esempio mostra il nome del sistema aziendale e dell'area.
Selezionare il bucket di storage degli oggetti creato nel task 2 per l'area 1.

Figura 3-3: Parametri necessari per creare un gruppo di protezione DR nell'area 1

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

Creare un gruppo di protezione DR di base (DRPG) nella regione 2 come illustrato nella figura 3-4 di seguito. Il peer, il ruolo e i membri verranno assegnati nei passi successivi.

Modifica il contesto dell'area OCI nell'area 2.
Selezionare il compartimento in cui si desidera creare il DRPG. Può trattarsi dello stesso compartimento in cui esistono risorse Oracle Integration o, come in questo caso, di un compartimento che funge da repository contenente DRPG per molti sistemi aziendali diversi.
Selezionare Crea gruppo di protezione DR per aprire la finestra di dialogo

Figura 3-4: Iniziare a creare un gruppo di protezione DR nell'area 2

Aggiungere un nome e un bucket di storage degli oggetti per i log, come illustrato nella Figura 3-5 riportata di seguito.

Utilizzare un nome semplice e significativo per il DRPG. Questo esempio mostra il nome del sistema aziendale e dell'area.
Selezionare il bucket di storage degli oggetti creato nel task 2 per l'area 2

Figura 3-5: Parametri necessari per creare un gruppo di protezione DR nell'area 2

Task 3.4: Associare i 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. Ecco come OCI Full Stack DR saprà quali due region lavorano insieme per il ripristino di Oracle Integration. 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.

Task 3.4.1: Iniziare l'associazione

Assicurarsi che il contesto dell'area OCI sia impostato sull'area 1 (Ashburn).
Selezionare Associa per iniziare il processo.

Figura 3-6: Avvio dell'associazione DRPG

Task 3.4.2: Associare i gruppi di protezione nella regione 1 e nella regione 2

Fornire i parametri come illustrato nella figura 3-7 di seguito.

Selezionare il ruolo principale. OCI Full Stack DR assegnerà automaticamente il ruolo in standby alla region 2.
Selezionare l'area 2 (Phoenix) in cui è stato creato l'altro DRPG.
Selezionare il DRPG peer in cui è stato creato.

Figura 3-7: Parametri necessari per associare i DRPG

Task 3.4.3: Cosa dovresti vedere dopo il completamento dell'associazione

OCI Full Stack DR mostrerà qualcosa come la Figura 3-8 di seguito una volta completata l'associazione.

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

Figura 3-8: 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 Figura 3-9 di seguito.

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

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

Task 4: aggiungere membri al gruppo di protezione DR

Nota: in questo passo verranno eliminati tutti i piani DR esistenti in entrambe le aree quando si aggiungono membri a gruppi di protezione DR esistenti. OCI Full Stack DR non può salvare copie o eseguire backup dei gruppi di protezione DR al momento della scrittura. Assicurarsi di aver registrato tutte le informazioni su gruppi di piani DR e passi in un file di testo o in un foglio di calcolo per ricreare i passi e i gruppi di piani personalizzati definiti dall'utente. È inoltre possibile creare script bash che richiamino i comandi CLI OCI Full Stack DR per ricreare i passi e i gruppi di piani personalizzati definiti dall'utente (che esulano dall'ambito di questa esercitazione).

Aggiungere il nodo di controllo DR come membri al gruppo di protezione DR principale. Il nodo DR Control è un'istanza di computazione creata solo per controllare Oracle Integration oppure è un'istanza di computazione che fa parte dello stack di applicazioni che si desidera gestire con OCI Full Stack DR.

Le risorse seguenti verranno aggiunte al DRPG principale nell'area 1:

Il nodo di controllo DR,
Gruppo di volumi contenente il volume di avvio del nodo DR Control.

Task 4.1: Iniziare ad aggiungere membri a DRPG nell'area 1

Inizia selezionando il DRPG nella regione 1 come mostrato nella Figura 4-1 di seguito.

Assicurati che il contesto dell'area OCI sia l'area 1 (Ashburn).
Selezionare il DRPG nella regione 1.
Seleziona membri.
Fare clic su Aggiungi membro per iniziare il processo.

Figura 4-1: Come iniziare ad aggiungere membri al gruppo di protezione DR nell'area 1

Task 4.1.1: aggiungere un'istanza di computazione per il nodo DR

Aggiungere un'istanza di computazione per il nodo di controllo DR come illustrato nella figura 4-2 riportata di seguito.

Conferma avvertenza relativa ai piani DR.
Selezionare Compute come tipo di risorsa membro.
Selezionare l'istanza di computazione che si desidera utilizzare per il nodo di controllo DR.
Selezionare l'istanza in movimento.
Indica a OCI Full Stack DR quale VCN e subnet assegnare alle VNIC nell'area 2 durante un recupero. La Figura 4-2 mostra una singola VNIC. OCI Full Stack DR non si preoccupa del numero di VNIC disponibili o del modo in cui vengono configurate in entrambe le aree; specifica ciò di cui hai bisogno che si adatti alle tue esigenze.

Figura 4-2: Parametri necessari per aggiungere il nodo di controllo DR

Task 4.1.2: Aggiungi gruppo di volumi a blocchi per il nodo DR

Aggiungere il gruppo di volumi a blocchi contenente l'avvio per il nodo di controllo DR. Il gruppo di volumi a blocchi deve già avere una replica tra più aree configurata tra le due aree prima di aggiungerlo al gruppo di protezione DR.

Selezionare il gruppo di volumi come tipo di risorsa membro.
Assicurarsi che sia selezionato il compartimento corretto contenente il gruppo di volumi, quindi selezionare il gruppo di volumi.

Figura 4-3: Parametri necessari per aggiungere il gruppo di volumi di avvio per il nodo di controllo DR

Task 4.1.3: Verifica delle risorse membro per l'area 1

Il DRPG per la regione 1 dovrebbe avere almeno due risorse membro come mostrato nella figura 4-5 di seguito. I nomi delle risorse membro saranno diversi.

L'istanza di computazione mobile e il gruppo di volumi a blocchi per l'istanza di computazione designata per agire sul nodo di controllo DR OIC.

Figura 4-5: Visualizzazione dei membri di DRPG nell'area 1

Non è necessario aggiungere membri nel gruppo di protezione DR in standby poiché stiamo utilizzando lo spostamento dell'istanza di computazione come nodo DR per ospitare gli script di Oracle Integration

Task 5: Creare piani DR di base nella regione 2 (Phoenix)

Questo passo crea piani di switchover e failover di base associati al gruppo di protezione DR in standby nell'area 2 (Phoenix).

Lo scopo di ogni piano è quello di eseguire la transizione del carico di lavoro dalla region primaria 1 alla standby region 2. I ruoli dei gruppi di protezione DR in entrambe le aree vengono invertiti automaticamente come parte di qualsiasi operazione di DR, pertanto il gruppo di protezione nella regione 1 diventerà il gruppo in standby e il gruppo di protezione nella regione 2 diventerà primario dopo un failover o uno switchover.

OCI Full Stack DR prepopola entrambi i piani con passi integrati in base alle risorse membro aggiunte nel passo precedente. I piani verranno personalizzati nei passi successivi per gestire tutti i task correlati a Oracle Integration durante un'operazione di recupero.

I piani di switchover vengono sempre creati nel gruppo di protezione con il ruolo standby; la region 2 è attualmente il gruppo di protezione standby, quindi inizieremo a Phoenix.

Task 5.1: Iniziare a creare piani DR

Creare un piano di base selezionando il DRPG nella regione 2 come mostrato nella figura 5-1 di seguito.

Assicurati che il contesto dell'area OCI sia l'area 2 (Phoenix).
Selezionare il DRPG in standby nella region 2.
Seleziona piani.
Fare clic su Crea piano per iniziare il processo.

Figura 5-1: Come iniziare a creare piani DR di base nella regione 2

Task 5.1.1: Creare un piano di switchover

La creazione di un piano DR è semplice come illustrato nella figura 5-2 di seguito.

Rendere il nome del piano di switchover semplice ma significativo. Il nome dovrebbe essere il più breve possibile ma facile da capire a colpo d'occhio per aiutare a ridurre la confusione e l'errore umano durante una crisi.
Scegliere il tipo di piano. Ci sono solo quattro tipi di piano al momento di questa scrittura.

Figura 5-2: Parametri necessari per creare un piano di switchover DR

Task 5.1.2: Creare un piano di failover

Seguire lo stesso processo per creare un piano di failover di base come illustrato nella figura 5-3 riportata di seguito.

Rendere 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 aiutare a ridurre la confusione e l'errore umano durante una crisi.
Scegliere il tipo di piano. Esistono solo due tipi di piano al momento della scrittura.

Figura 5-3: 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 riportati di seguito. Questi gestiranno la transizione dei carichi di lavoro dalla region 1 alla region 2. Creerai piani simili nell'area 1 per eseguire la transizione dei carichi di lavoro dall'area 2 all'area 1 in un passo successivo.

Figura 5-4: Visualizzazione dei due piani DR di base che devono esistere nell'area 2 prima di procedere ulteriormente

Task 6: Personalizzare il piano di switchover nella regione 2 (Phoenix)

I piani DR di base creati nel task 5 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 Integration. Questo passo spiega come aggiungere gruppi di piani DR personalizzati e definiti dall'utente e come gestire le operazioni da eseguire durante uno switchover per Oracle Integration:

Sincronizza i parametri schedulati dall'area 1 all'area 2
Attiva le integrazioni pertinenti nell'area 2
Avvia integrazioni pianificate nell'area 2
Aggiorna record DNS nell'area 2
Disattiva integrazioni pianificate nell'area 1

Task 6.1: Selezionare il piano di switchover

Per iniziare, passare al piano di switchover creato nel passo precedente.

Figura 6-1: Come iniziare a personalizzare il piano di switchover nell'area 2

Task 6.2: Abilita gruppi di piani DR che terminano gli artifact (facoltativo)

Esistono due gruppi di piani disabilitati per impostazione predefinita nei piani di switchover, come mostrato nello screenshot riportato di seguito. Sono disabilitati per fornire un livello di comfort durante i test che nulla viene effettivamente eliminato e si dispone ancora di una copia valida degli artifact come backup nel caso in cui qualcosa vada storto durante i test.

Tuttavia, questi due gruppi di piani interrompono (elimina) gli artifact che non verranno più utilizzati come parte di alcuna operazione DR in futuro. Gli artifact continueranno semplicemente ad accumularsi nel tempo man mano che si passa avanti e indietro tra le due aree, causando confusione sulle istanze di calcolo e sui gruppi di volumi che dovrebbero essere effettivamente attivi.

Questi gruppi di piani devono essere abilitati una volta che OCI Full Stack DR entra in produzione. Tutti gli artifact lasciati in essere durante il test degli switchover e dei switchback mentre questi due gruppi di piani erano disabilitati devono essere terminati e ripuliti prima di entrare in produzione per ridurre la confusione e la probabilità di errore umano durante le normali operazioni.

Facoltativamente, questi gruppi di piani possono ora essere abilitati per evitare di dover pulire manualmente gli artefatti superflui prima di entrare in produzione.

Figura 6-2: gruppi di piani disabilitati per impostazione predefinita

Di seguito sono riportate le operazioni eseguite dai gruppi di piani disabilitati quando sono abilitati.

Questo gruppo di piani termina gli artifact delle istanze di computazione rimaste indietro nell'area 1 dopo che le versioni replicate delle VM sono state avviate nell'area 2 durante l'operazione di storage a blocchi OCI per invertire la replica dall'area 2 all'area 1 come parte dello switchover. Le VM rimanenti non vengono utilizzate durante uno switchback perché l'operazione di annullamento della replica del volume a blocchi crea tutte le nuove VM in gruppi di volumi a blocchi completamente nuovi.
Questo gruppo di piani termina gli artifact dei gruppi di volumi a blocchi (VG) lasciati indietro nell'area 1 dopo che le versioni replicate dei VG sono state attivate nell'area 2 e la replica dei gruppi di volumi è stata invertita durante lo switchover. I gruppi di volumi a blocchi rimanenti non vengono mai più utilizzati, nemmeno come parte di uno switchover dalla regione 2 alla regione 1.

Task 6.2.1: Abilita interruzione gruppo di piani di calcolo

Abilitare il gruppo di piani.

Selezionare Abilita tutti i passi dal menu di scelta rapida a destra del nome del gruppo di piani

Figura 6-3: Come abilitare l'interruzione delle istanze di computazione

Task 6.2.2 Abilita cessazione gruppo di piani gruppi di volumi

Abilitare il gruppo di piani.

Selezionare Abilita tutti i passi dal menu di scelta rapida a destra del nome del gruppo di piani

Figura 6-4: Come abilitare l'interruzione dei gruppi di volumi

Task 6.3: creare un gruppo di piani per sincronizzare i parametri programmati dall'area 1 all'area 2

Ora inizia ad aggiungere gruppi di piani DR personalizzati definiti dall'utente.

Il primo gruppo di piani definito dall'utente sincronizzerà i parametri programmati dall'area 1 all'area. Questo gruppo di piani conterrà un singolo passo che richiama lo script bash oic-sync-schedule-parameters.sh scaricato nel nodo di controllo DR nel task 1.4.

Task 6.3.1: Selezionare Aggiungi gruppo di piani

Avviare il processo per aggiungere un gruppo di piani.

Fare clic su Aggiungi gruppo per iniziare.

Figura 6-5: Iniziare ad aggiungere un gruppo di piani per sincronizzare i parametri pianificati

Task 6.3.2: fornire il nome, l'ordine e il passo del gruppo di piani

Un gruppo di piani DR può contenere molti passi che vengono tutti eseguiti in parallelo. Stiamo solo aggiungendo un singolo passo per eseguire uno script bash per sincronizzare i parametri pianificati.

Assegnare al gruppo di piani un nome semplice ma descrittivo.
Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, verrà inserito il gruppo di piani definito dall'utente prima del gruppo di piani integrato che arresta le VM nell'area 1.
Selezionare il gruppo di piani Arresta istanze di computazione (principale) integrato.
Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per sincronizzare i parametri pianificati.

Figura 6-6: Parametri per creare un gruppo di piani e aggiungere un passo per sincronizzare i parametri pianificati

Task 6.3.3: fornire il nome del passo e i parametri dello script locale

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi alle prestazioni di questo passo e alle modalità di funzionamento durante il recupero. In questo caso, sincronizzerà i parametri programmati dall'area 1 all'area 2.

Spiegheremo tutti i campi in questa finestra di dialogo, ma tralasceremo questo dettaglio in tutti gli screenshot rimanenti nei passaggi successivi poiché stiamo semplicemente eseguendo lo stesso processo ripetutamente.

Nome descrittivo che spiega il task eseguito da questo passo.
Selezionare sempre l'area in cui è in esecuzione il nodo di controllo DR in questo momento, non in cui verrà eseguito durante uno switchover. OCI Full Stack DR terrà traccia di dove è in esecuzione la VM, quindi devi solo specificare dove si trova in questo momento. In questo caso, il nodo di controllo DR è in esecuzione nell'area 1 (Ashburn).
Selezionare Esegui script locale per informare OCI Full Stack DR che lo script verrà trovato in un'istanza di computazione. Gli script bash sono stati scaricati nel nodo di controllo DR nel task 1.3.
Selezionare il compartimento corretto che contiene il nodo di controllo DR. Può essere qualsiasi compartimento. Selezionare l'istanza di computazione designata come nodo di controllo DR (può essere un Application Server o una VM creata solo per questo progetto/esercitazione).
Incollare il percorso assoluto in cui è stato installato lo script oic-sync-schedule-parameters.sh sul nodo di controllo DR. Aggiungere PHX come parametro. Questa è l'area di destinazione in cui si desidera sincronizzare i parametri pianificati. Potrebbe essere necessario fornire i parametri corretti dell'area se si utilizzano aree geografiche OCI diverse e si aggiornano gli script.
Specificare opc come utente per eseguire lo script.
Il piano DR deve essere interrotto se lo script non riesce a sincronizzare i parametri programmati. Questo permetterà a chiunque di vedere che c'è un problema e risolverlo. OCI Full Stack DR offre l'opportunità di continuare a eseguire il piano di switchover dopo aver risolto il problema.
Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di un'ora. Questo valore può essere modificato in 30 minuti o qualsiasi cosa si ritenga essere un valore di timeout più realistico.
Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

Figura 6-7: Parametri per creare il passo del piano per i parametri programmati di sincronizzazione

Task 6.3.4: Completare l'aggiunta del gruppo di piani e del passo

Il passo per interrompere la sincronizzazione dei parametri pianificati viene ora aggiunto al gruppo di piani DR come illustrato nella figura 6-8 riportata di seguito.

Mostra il passo del piano appena aggiunto. È possibile aggiungere ulteriori passi a un gruppo di piani DR, ma questo gruppo di piani includerà solo il passo per sincronizzare i parametri pianificati.
Fare clic su Aggiungi per aggiungere il gruppo di piani DR e il passo al piano DR.

Figura 6-8: Finalizzare l'aggiunta del gruppo di piani e del passo per sincronizzare i parametri pianificati

Task 6.4: creare un gruppo di piani per attivare le integrazioni pertinenti in standby

Il secondo gruppo di piani definito dall'utente attiverà le integrazioni pertinenti in standby dopo l'avvio del nodo di controllo DR nella standby region 2. Questo gruppo di piani conterrà un singolo passo che richiama lo script bash oic-integration-switch.sh scaricato nel nodo di controllo DR nel task 1.3.

Task 6.4.1: Selezionare Aggiungi gruppo di piani

Come in precedenza, fare clic su Aggiungi gruppo per iniziare.

Figura 6-9: Iniziare ad aggiungere un gruppo di piani per attivare le integrazioni pertinenti in standby

Task 6.4.2: fornire il nome, l'ordine e il passo del gruppo di piani

Creare un gruppo di piani DR per avviare l'attivazione delle integrazioni pertinenti in standby.

Assegnare al gruppo di piani un nome semplice ma descrittivo.
Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, verrà inserito il gruppo di piani definito dall'utente dopo il gruppo di piani incorporato che avvia la versione replicata del nodo di controllo DR nell'area 2
Selezionare il gruppo di piani Avvia istanze di computazione (in standby) incorporato
Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per attivare le integrazioni pertinenti in standby.

Figura 6-10: Parametri per creare un gruppo di piani e aggiungere un passo per attivare le integrazioni pertinenti in standby

Task 6.4.3: fornire il nome del passo e i parametri dello script locale

Tutto in questo passaggio è lo stesso del Task 6.3.3 ad eccezione degli elementi mostrati nella Figura 6-11 di seguito.

Nome descrittivo che spiega il task eseguito da questo passo.
Incollare il percorso assoluto in cui è stato installato lo script oic-integration-switch.sh sul nodo di controllo DR. Aggiungere activate come primo parametro e PHX come second.This è l'area di destinazione in cui si desidera attivare le integrazioni pertinenti. Potrebbe essere necessario fornire i parametri corretti dell'area se si utilizzano aree geografiche OCI diverse e si aggiornano gli script.
Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

Figura 6-11: Parametri per creare il passo del piano per l'attivazione delle integrazioni pertinenti in standby

Task 6.4.4: Completare l'aggiunta del gruppo di piani e del passo

Il passo per attivare le integrazioni pertinenti in standby viene ora aggiunto al gruppo di piani DR come illustrato nella figura 6-12 riportata di seguito.

Mostra il passo del piano appena aggiunto.
Fare clic su Aggiungi per aggiungere il gruppo di piani DR e il passo al piano DR.

Figura 6-12: Finalizzare l'aggiunta del gruppo di piani e del passo per attivare le integrazioni pertinenti in standby

Task 6.5: creare un gruppo di piani per avviare le integrazioni pianificate nell'area 2

Il terzo gruppo di piani definito dall'utente avvierà le integrazioni pianificate in standby dopo l'avvio del nodo di controllo DR nella standby region 2. Questo gruppo di piani conterrà un singolo passo che richiama lo script bash oic-integration-schedule.sh scaricato nel nodo di controllo DR nel task 1.3.

Task 6.5.1: Selezionare Aggiungi gruppo di piani

Come in precedenza, fare clic su Aggiungi gruppo per iniziare.

Figura 6-13: Iniziare ad aggiungere un gruppo di piani per avviare le integrazioni pianificate in standby

Task 6.5.2: fornire il nome, l'ordine e il passo del gruppo di piani

Crea un gruppo di piani DR per avviare integrazioni pianificate nella standby region 2.

Assegnare al gruppo di piani un nome semplice ma descrittivo.
Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, inserire il gruppo di piani definito dall'utente dopo il gruppo di piani definito dall'utente creato nel task precedente per attivare le integrazioni pertinenti.
Selezionare il gruppo di piani Attiva integrazioni pertinenti in standby integrato
Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per avviare le integrazioni pianificate in standby.

Figura 6-14: Parametri per creare un gruppo di piani e aggiungere un passo per avviare integrazioni pianificate in standby

Task 6.5.3: fornire il nome del passo e i parametri dello script locale

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi alle prestazioni di questo passo e alle modalità di funzionamento durante il recupero. In questo caso, avvierà le integrazioni pianificate nella standby region 2.

Tutto in questo compito è lo stesso del Task 6.3.3 ad eccezione degli elementi mostrati nella Figura 6-15 di seguito.

Nome descrittivo che spiega il task eseguito da questo passo.
Incollare il percorso assoluto in cui è stato installato lo script oic-integration-schedule.sh sul nodo di controllo DR. Aggiungere start come primo parametro e PHX come secondo.
Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

Figura 6-15: Parametri per creare il passo del piano per avviare le integrazioni pianificate in standby

Task 6.5.4: Completare l'aggiunta del gruppo di piani e del passo

Il passo per avviare le integrazioni pianificate in standby viene ora aggiunto al gruppo di piani DR, come illustrato nella figura 6-16 riportata di seguito.

Mostra il passo del piano appena aggiunto.
Fare clic su Aggiungi per aggiungere il gruppo di piani DR e il passo al piano DR.

Figura 6-16: Finalizzare l'aggiunta di un gruppo di piani e avviare le integrazioni pianificate in standby

Task 6.6: creare un gruppo di piani per aggiornare il record DNS nell'area 2

Il quarto gruppo di piani definito dall'utente aggiornerà il record DNS in standby dopo l'avvio del nodo di controllo DR nella standby region 2. Questo gruppo di piani conterrà un singolo passo che richiama lo script bash dns_record_update.sh scaricato nel nodo di controllo DR nel task 1.3.

Task 6.6.1: Selezionare Aggiungi gruppo di piani

Come in precedenza, fare clic su Aggiungi gruppo per iniziare.

Figura 6-17: Iniziare ad aggiungere un gruppo di piani per aggiornare il record DNS in standby

Task 6.6.2: fornire il nome, l'ordine e il passo del gruppo di piani

Creare un gruppo di piani DR per aggiornare il record DNS nell'area 2.

Assegnare al gruppo di piani un nome semplice ma descrittivo.
Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, verrà inserito il gruppo di piani definito dall'utente dopo il gruppo di piani integrato per avviare le integrazioni pianificate in standby
Selezionare il gruppo di piani Avvia integrazioni pianificate in standby incorporato.
Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per aggiornare il record DNS in standby.

Figura 6-18: Parametri per creare un gruppo di piani e aggiungere un passo per aggiornare il record DNS in standby

Task 6.6.3: Fornire il nome del passo e i parametri dello script locale

Tutto in questo compito è lo stesso del Task 6.3.3 ad eccezione degli elementi mostrati nella Figura 6-19 di seguito.

Nome descrittivo che spiega il task eseguito da questo passo.
Incollare il percorso assoluto in cui è stato installato lo script dns_record_update.sh sul nodo di controllo DR. Aggiungere la chiave dell'area OCI per l'area 2 (PHX in questo esempio) come parametro.
Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

Figura 6-19: Parametri per creare il passo del piano per aggiornare il record DNS in standby

Task 6.6.4: Completare l'aggiunta del gruppo di piani e del passo

Il passo per aggiornare il record DNS in standby viene ora aggiunto al gruppo di piani DR come illustrato nella figura 6-20 riportata di seguito.

Mostra il passo del piano appena aggiunto.
Fare clic su Aggiungi per aggiungere il gruppo di piani DR e il passo al piano DR.

Figura 6-20: Finalizzare l'aggiunta del gruppo di piani e del passo per aggiornare il record DNS in standby

Task 6.7: creare un gruppo di piani per disattivare le integrazioni pianificate nell'area 1

Il gruppo di piani definito dall'utente finale disattiverà le integrazioni pianificate nell'area 1 dopo l'avvio del nodo di controllo DR nella standby region 2. Questo gruppo di piani conterrà un singolo passo che richiama lo script oic-integration-switch.sh scaricato nel nodo di controllo DR nel task 1.3.

Task 6.7.1: Selezionare Aggiungi gruppo di piani

Come in precedenza, fare clic su Aggiungi gruppo per iniziare.

Figura 6-21: Iniziare ad aggiungere un gruppo di piani per disattivare le integrazioni pianificate nell'area 1

Task 6.7.2: fornire il nome, l'ordine e il passo del gruppo di piani

Creare un gruppo di piani DR per disattivare le integrazioni pianificate nell'area 1

Assegnare al gruppo di piani un nome semplice ma descrittivo.
Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, verrà inserito il gruppo di piani definito dall'utente dopo il gruppo di piani incorporato per aggiornare il record DNS in standby
Selezionare il gruppo di piani Aggiorna record DNS in standby incorporato.
Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per disattivare le integrazioni pianificate nell'area 1

Figura 6-22: Parametri per creare un gruppo di piani e aggiungere un passo per disattivare le integrazioni pianificate nell'area 1

Task 6.7.3: fornire il nome del passo e i parametri dello script locale

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi alle prestazioni di questo passo e alle modalità di funzionamento durante il recupero. In questo caso, disattiverà le integrazioni pianificate nell'area 1

Tutto in questo compito è lo stesso del Task 6.3.3 ad eccezione degli elementi mostrati nella Figura 6-23 di seguito.

Nome descrittivo che spiega il task eseguito da questo passo.
Incollare il percorso assoluto in cui è stato installato lo script oic-integration-switch.sh sul nodo di controllo DR. Aggiungere la chiave dell'area OCI per la regione 1 (IAD in questo esempio) come parametro.
Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

Figura 6-23: Parametri per creare il passo del piano per disattivare le integrazioni pianificate nell'area 1

Task 6.7.4: Completare l'aggiunta del gruppo di piani e del passo

Il passo per disattivare le integrazioni pianificate nell'area 1 viene ora aggiunto al gruppo di piani DR come illustrato nella figura 6-20 riportata di seguito.

Mostra il passo del piano appena aggiunto.
Fare clic su Aggiungi per aggiungere il gruppo di piani DR e il passo al piano DR.

Figura 6-24: Finalizzare l'aggiunta del gruppo di piani e del passo per disattivare le integrazioni pianificate nell'area 1

Il piano di switchover dovrebbe ora includere i cinque gruppi di piani DR per Oracle Integration, come mostrato nello screenshot riportato di seguito. È possibile disporre di gruppi di piani aggiuntivi se il gruppo di protezione include altre applicazioni o altri servizi OCI insieme a Oracle Integration

Figura 6-25: Visualizzazione dei cinque gruppi di piani definiti dall'utente aggiunti al piano di switchover

Task 7: Personalizzare il piano di failover nell'area 2 (Phoenix)

Questo task spiega come aggiungere gruppi di piani DR personalizzati e definiti dall'utente e i passi per gestire le operazioni da eseguire durante un failover per Oracle Integration nell'area 2 durante un'interruzione o una perdita di accesso effettiva all'area 1. Si tratta di un sottoinsieme degli stessi passi appena aggiunti al piano di switchover nel precedente task 6. Tuttavia, solo i passi eseguiti nella standby region 2 verranno aggiunti al piano di failover poiché si presume che la region 1 sia completamente inaccessibile durante un failover.

Attiva le integrazioni pertinenti nell'area 2
Aggiorna i parametri schedulati nell'area 2
Avvia integrazioni pianificate nell'area 2
Aggiorna record DNS nell'area 2

Task 7.1: selezionare il piano di failover

Per iniziare, passare al piano di failover creato nel task 5.

Assicurati che la standby region 2 sia ancora il contesto della region corrente nella console.
Selezionare il piano di failover.

Figura 7-1: Come iniziare a personalizzare il piano di failover nell'area 2

Task 7.2: Selezionare Aggiungi gruppo di piani

Il primo gruppo di piani definito dall'utente attiverà le integrazioni pertinenti nell'area 2. Questo gruppo di piani conterrà un singolo passo che richiama lo script bash oic-integration-switch.sh scaricato nel nodo di controllo DR nel task 1.3.

Fare clic su Aggiungi gruppo per iniziare.

Figura 7-2: Iniziare ad aggiungere un gruppo di piani per attivare le integrazioni pertinenti

Task 7.2.1: fornire il nome, l'ordine e il passo del gruppo di piani

Un gruppo di piani DR può contenere molti passi che vengono tutti eseguiti in parallelo. Stiamo solo aggiungendo un singolo passo per eseguire uno script bash per attivare integrazioni pertinenti.

Assegnare al gruppo di piani un nome semplice ma descrittivo.
Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, verrà inserito il gruppo di piani definito dall'utente dopo il gruppo di piani integrato che avvia le VM replicate nell'area 2
Selezionare il gruppo di piani Avvia istanze di computazione (in standby) incorporato
Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per attivare le integrazioni pertinenti

Figura 7-3: Parametri per creare un gruppo di piani e aggiungere un passo per attivare le integrazioni pertinenti in standby

Task 7.2.2: fornire il nome del passo e i parametri dello script locale

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi alle prestazioni di questo passo e alle modalità di funzionamento durante il recupero. In questo caso, attiverà le integrazioni pertinenti nell'area 2 come mostrato nella Figura 7-4 di seguito.

Nome descrittivo che spiega il task eseguito da questo passo.
Il piano DR deve essere interrotto se lo script non riesce ad attivare le integrazioni pertinenti. Questo permetterà a chiunque di vedere che c'è un problema e risolverlo. OCI Full Stack DR offre l'opportunità di continuare a eseguire il piano di switchover dopo aver risolto il problema.
Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di un'ora. Questo valore può essere modificato in 30 minuti o qualsiasi cosa si ritenga essere un valore di timeout più realistico.
Selezionare sempre l'area in cui è in esecuzione il nodo di controllo DR in questo momento, non in cui verrà eseguito durante uno switchover. OCI Full Stack DR terrà traccia di dove è in esecuzione la VM, quindi devi solo specificare dove si trova in questo momento. In questo caso, il nodo di controllo DR è in esecuzione nell'area 1 (Ashburn).
Selezionare Esegui script locale per informare OCI Full Stack DR che lo script verrà trovato in un'istanza di computazione. Gli script bash sono stati scaricati nel nodo di controllo DR nel task 1.3.
Selezionare il compartimento corretto che contiene il nodo di controllo DR. Può essere qualsiasi compartimento. Selezionare l'istanza di computazione designata come nodo di controllo DR (può essere un Application Server o una VM creata solo per questo progetto/esercitazione).
Incollare il percorso assoluto in cui è stato installato lo script oic-integration-switch.sh sul nodo di controllo DR. Aggiungere activate come primo parametro e PHX come secondo.
Specificare opc come utente per eseguire lo script.
Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

Figura 7-4: Parametri per creare il passo del piano per attivare le integrazioni pertinenti in standby

Task 7.2.3: Completare l'aggiunta del gruppo di piani e del passo

Il passo per attivare le integrazioni pertinenti viene ora aggiunto al gruppo di piani DR come illustrato nella figura 7-5 riportata di seguito.

Mostra il passo del piano appena aggiunto.
Fare clic su Aggiungi per aggiungere il gruppo di piani DR e il passo al piano DR.

Figura 7-5: Finalizzare l'aggiunta del gruppo di piani e del passo per attivare le integrazioni pertinenti

Task 7.3: creare un gruppo di piani per aggiornare i parametri programmati nell'area 2

Il secondo gruppo di piani definito dall'utente aggiorna i parametri pianificati nella standby region 2. Questo gruppo di piani conterrà un singolo passo che richiama lo script bash oic-update-parameters.sh scaricato nel nodo di controllo DR nel task 1.3.

Task 7.3.1: Selezionare Aggiungi gruppo di piani

Come in precedenza, fare clic su Aggiungi gruppo per iniziare.

Figura 7-6: Iniziare ad aggiungere un gruppo di piani per aggiornare i parametri pianificati in standby

Task 7.3.2: fornire il nome, l'ordine e il passo del gruppo di piani

Creare un gruppo di piani DR per aggiornare i parametri schedulati nell'area 2.

Assegnare al gruppo di piani un nome semplice ma descrittivo.
Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, inserire il gruppo di piani definito dall'utente dopo il gruppo di piani definito dall'utente creato nel task precedente per attivare le integrazioni pertinenti.
Selezionare Attiva integrazioni pertinenti nel gruppo di piani in standby.
Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per aggiornare i parametri pianificati in standby.

Figura 7-7: Parametri per creare un gruppo di piani e aggiungere un passo per aggiornare i parametri pianificati in standby

Task 7.3.3: fornire il nome del passo e i parametri dello script locale

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi alle prestazioni di questo passo e alle modalità di funzionamento durante il recupero. In questo caso, recupererà i parametri pianificati di aggiornamento nell'area 2.

Tutto in questo compito è lo stesso del Task 7.3.2 ad eccezione degli elementi mostrati nella Figura 7-8 di seguito.

Nome descrittivo che spiega il task eseguito da questo passo.
Incollare il percorso assoluto in cui è stato installato lo script oic-update-parameters.sh sul nodo di controllo DR. Aggiungere PHX come unico parametro (PHX in questo esempio).
Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani

Figura 7-8: Parametri per creare il passo del piano per l'aggiornamento dei parametri pianificati in standby

Task 7.3.4: Completare l'aggiunta del gruppo di piani e del passo

Il passo per aggiornare i parametri pianificati in standby viene ora aggiunto al gruppo di piani DR come illustrato nella figura 7-9 riportata di seguito.

Mostra il passo del piano appena aggiunto.
Fare clic su Aggiungi per aggiungere il gruppo di piani DR e il passo al piano DR.

Figura 7-9: Finalizzare l'aggiunta del gruppo di piani e l'aggiornamento dei passi dei parametri pianificati in standby

Task 7.4: creare un gruppo di piani per avviare le integrazioni pianificate nell'area 2

Task 7.4.1: Selezionare Aggiungi gruppo di piani

Come in precedenza, fare clic su Aggiungi gruppo per iniziare.

Figura 7-10: Iniziare ad aggiungere un gruppo di piani per avviare le integrazioni pianificate in standby

Task 7.4.2: fornire il nome, l'ordine e il passo del gruppo di piani

Creare un gruppo di piani DR per avviare integrazioni pianificate in standby

Assegnare al gruppo di piani un nome semplice ma descrittivo.
Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, verrà inserito il gruppo di piani definito dall'utente dopo l'aggiornamento dei parametri programmati nei gruppi di piani in standby.
Selezionare il gruppo di piani Aggiorna parametri pianificati in standby incorporato.
Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per avviare le integrazioni pianificate in standby

Figura 7-11: Parametri per creare un gruppo di piani e aggiungere un passo per avviare integrazioni pianificate in standby

Task 7.4.3: fornire il nome del passo e i parametri dello script locale

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi alle prestazioni di questo passo e alle modalità di funzionamento durante il recupero.

Tutto in questo compito è lo stesso del Task 7.2.2 ad eccezione degli elementi mostrati nella Figura 6-19 di seguito.

Nome descrittivo che spiega il task eseguito da questo passo.
Incollare il percorso assoluto in cui è stato installato lo script oic-integration-schedule.sh sul nodo di controllo DR. Aggiungere start come primo parametro e PHX come secondo.
Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

Figura 7-12: Parametri per creare il passo del piano per avviare le integrazioni pianificate in standby

Task 7.4.4: Completare l'aggiunta del gruppo di piani e del passo

Il passo per avviare le integrazioni pianificate in standby viene ora aggiunto al gruppo di piani DR, come illustrato nella figura 7-13 riportata di seguito.

Mostra il passo del piano appena aggiunto.
Fare clic su Aggiungi per aggiungere il gruppo di piani DR e il passo al piano DR.

Figura 7-13: Finalizzare l'aggiunta di gruppo di piani e passo per avviare integrazioni pianificate in standby

Task 7.5: creare un gruppo di piani per aggiornare il record DNS nell'area 2

Task 7.5.1: Selezionare Aggiungi gruppo di piani

Come in precedenza, fare clic su Aggiungi gruppo per iniziare.

Figura 7-14: Iniziare ad aggiungere un gruppo di piani per aggiornare il record DNS in standby

Task 7.5.2: fornire il nome, l'ordine e il passo del gruppo di piani

Creare un gruppo di piani DR per aggiornare il record DNS nell'area 2.

Assegnare al gruppo di piani un nome semplice ma descrittivo.
Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, verrà inserito il gruppo di piani definito dall'utente dopo il gruppo di piani integrato per avviare le integrazioni pianificate in standby
Selezionare il gruppo di piani Avvia integrazioni pianificate in standby incorporato.
Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per aggiornare il record DNS in standby.

Figura 7-14: Parametri per creare un gruppo di piani e aggiungere un passo per aggiornare il record DNS in standby

Task 7.5.3: fornire il nome del passo e i parametri dello script locale

Tutto in questo compito è lo stesso del Task 6.3.3 ad eccezione degli elementi mostrati nella Figura 7-15 di seguito.

Nome descrittivo che spiega il task eseguito da questo passo.
Incollare il percorso assoluto in cui è stato installato lo script dns_record_update.sh sul nodo di controllo DR. Aggiungere la chiave dell'area OCI per l'area 2 (PHX in questo esempio) come parametro.
Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

Figura 7-15: Parametri per creare il passo del piano per aggiornare il record DNS in standby

Task 7.5.4: Completare l'aggiunta del gruppo di piani e del passo

Il passo per aggiornare il record DNS in standby viene ora aggiunto al gruppo di piani DR come illustrato nella figura 7-16 riportata di seguito.

Mostra il passo del piano appena aggiunto.
Fare clic su Aggiungi per aggiungere il gruppo di piani DR e il passo al piano DR.

Figura 7-16: Finalizzare l'aggiunta del gruppo di piani e del passo per aggiornare il record DNS in standby

Il piano di failover dovrebbe ora includere i quattro gruppi di piani DR per Oracle Integration, come mostrato nello screenshot riportato di seguito. È possibile disporre di gruppi di piani aggiuntivi se il gruppo di protezione include altre applicazioni o servizi OCI insieme a Oracle Integration.

Figura 7-14: Visualizzazione dei quattro gruppi di piani definiti dall'utente aggiunti al piano di failover

Task 8: Esegui il piano di switchover nella regione 2 (Phoenix)

I piani DR di switchover e failover sono stati completati sia nella standby region 2 (Phoenix). I piani DR nella region 2 consentono a OCI Full Stack DR di eseguire la transizione dei carichi di lavoro dalla region 1 alla region 2. Il task successivo consiste nel creare piani di switchover e failover nel gruppo di protezione per l'area 1 (Ashburn) in modo che OCI Full Stack DR possa trasferire i carichi di lavoro dall'area 2 all'area 1.

Tuttavia, i piani DR possono essere creati e modificati solo nel gruppo di protezione con il ruolo in standby. Il gruppo di protezione DR nella regione 1 è attualmente il principale, il che significa che i piani DR non possono essere creati nella regione 1.

Pertanto, dobbiamo invertire i ruoli dei gruppi di protezione in modo che la region 1 sia la standby e la region 2 sia la primaria. Esegui il piano di switchover appena creato per eseguire la transizione del carico di lavoro dall'area 1 (Ashburn) all'area 2 (Phoenix).

Task 8.1: Inizio dell'esecuzione del piano

Esegui il piano DR per avviare il processo di transizione del carico di lavoro Oracle Integration dall'area 1 all'area 2.

Assicurati che il contesto della region sia ancora impostato sulla standby region 2 (Phoenix).
Utilizzare gli indicatori di percorso nella parte superiore della console per garantire che i dettagli del gruppo di protezione DR siano il contesto del piano corrente.
Assicurarsi che sia selezionato il gruppo di protezione DR corretto nell'area 2, ovvero il ruolo Standby.
Assicurarsi che i piani di failover e switchover esistano prima di continuare. In caso contrario, tornare ai passi precedenti per creare e personalizzare entrambi i piani DR.
Fare clic su Esegui piano DR.

Figura 8-1: Visualizzazione di come eseguire uno switchover nella standby region

Task 8.2: Selezionare il piano di switchover ed eseguire

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

Selezionare il piano di switchover.
Assicurarsi che l'opzione Abilita controlli preliminari sia selezionata.
Fare clic su Esegui piano DR per iniziare.

Figura 8-2: Scegliere ed eseguire il piano di switchover

Task 8.3: passi successivi

Monitora il piano di switchover fino a quando il carico di lavoro di Oracle Integration non è stato completamente trasferito dall'area 1 all'area 2. OCI Full Stack DR si occuperà del cleanup degli artifact e della modifica dei ruoli di primario e standby tra le region.

La region 2 (Phoenix) sarà la region primaria e la region 1 (Ashburn) sarà la standby region una volta che OCI Full Stack DR avrà completato lo switchover.

Task 9: Creare piani DR nell'area 1 (Ashburn)

Creare gli stessi piani di switchover e failover di base nel gruppo di protezione DR per l'area 1 (Ashburn), che ora è il peer in standby.

Lo scopo di ogni piano è quello di eseguire la transizione del carico di lavoro dalla region 2 alla region 1 ogni volta che la region 2 è il peer primario. I ruoli dei gruppi di protezione DR in entrambe le aree vengono invertiti automaticamente come parte di qualsiasi operazione di DR, pertanto il gruppo di protezione nella regione 2 diventerà il gruppo in standby e il gruppo di protezione nella regione 1 diventerà primario dopo un failover o uno switchover.

I piani DR vengono sempre creati nel gruppo di protezione con il ruolo standby; la region 1 è attualmente il gruppo di protezione in standby dopo aver eseguito il piano di switchover nel task 8.

Task 9.1: Iniziare a creare piani DR

Creare un piano di base selezionando il DRPG nella regione 1 come mostrato nella figura 9-1 di seguito.

Assicurati che il contesto dell'area OCI sia l'area 1 (Ashburn).
Selezionare il DRPG in standby nella region 1.
Seleziona piani.
Fare clic su Crea piano per iniziare il processo.

Figura 9-1: Come iniziare a creare piani DR di base nella regione 1

Task 9.1.1: Creare un piano di switchover

La creazione di un piano DR è semplice come illustrato nella figura 9-2 riportata di seguito.

Rendere il nome del piano di switchover semplice ma significativo. Il nome dovrebbe essere il più breve possibile ma facile da capire a colpo d'occhio per aiutare a ridurre la confusione e l'errore umano durante una crisi.
Scegliere il tipo di piano. Esistono solo due tipi di piano al momento della scrittura.

Figura 9-2: Parametri necessari per creare un piano di switchover DR
Fare clic su Crea per creare un piano di switchover di base precompilato con passi incorporati di base.

Task 9.2: Creare un piano di failover

Seguire lo stesso processo per creare un piano di failover di base come illustrato nella figura 9-3 riportata di seguito.

Rendere 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 aiutare a ridurre la confusione e l'errore umano durante una crisi.
Scegliere il tipo di piano. Esistono solo due tipi di piano al momento della scrittura.
Fare clic su Crea per creare un piano di failover di base prepopolato con passi incorporati di base.

Figura 9-3: Parametri necessari per creare un piano di failover DR

Il gruppo di protezione DR in standby nella regione 1 dovrebbe ora disporre dei due piani DR riportati di seguito. Questi gestiranno la transizione dei carichi di lavoro dalla region 2 alla region 1.

Figura 9-4: Visualizzazione dei due piani DR di base che devono esistere nell'area 2 prima di procedere ulteriormente

Task 10: Personalizzare il piano di switchover nell'area 1 (Ashburn)

Tutto su questo compito è quasi esattamente lo stesso di quello che abbiamo fatto nel Task 6 per la regione 2, tranne che questo viene fatto nella regione 1.

I piani DR di base creati nel task 9 non contengono nulla per gestire i task di recupero specifici di Oracle Integration. Questo task spiega come aggiungere gruppi di piani DR personalizzati e definiti dall'utente e come gestire gli elementi da eseguire durante uno switchover per Oracle Integration:

Sincronizza i parametri schedulati dall'area 1 all'area 2.
Attiva le integrazioni pertinenti nell'area 2.
Avviare le integrazioni pianificate nell'area 2.
Aggiorna record DNS nell'area 2.
Disattiva integrazioni pianificate nell'area 1.

Task 10.1: selezionare il piano di switchover

Per iniziare, passare al piano di switchover creato nel passo precedente.

Figura 10-1: Come iniziare a personalizzare il piano di switchover nell'area 1

Task 10.2: Abilita gruppi di piani DR che terminano gli artifact (facoltativo)

Queste sono le stesse fasi eseguite per la regione 2 in una fase precedente; lo stesso processo deve essere seguito per la regione 1.

Due gruppi di piani sono disabilitati per impostazione predefinita nei piani di switchover come mostrato nello screenshot riportato di seguito. Sono disabilitati per fornire un livello di comfort durante i test che nulla viene effettivamente eliminato e si dispone ancora di una copia valida degli artifact come backup nel caso in cui qualcosa vada storto durante i test.

Tuttavia, questi due gruppi di piani interrompono (elimina) gli artifact che non verranno più utilizzati come parte di alcuna operazione DR in futuro. Gli artifact continueranno semplicemente ad accumularsi nel tempo man mano che si passa avanti e indietro tra le due aree causando confusione per gli esseri umani su quali istanze di calcolo e gruppi di volumi sono quelli che dovrebbero essere effettivamente attivi.

Facoltativamente, questi gruppi di piani possono ora essere abilitati per evitare di dover pulire manualmente gli artefatti superflui prima di entrare in produzione.

Figura 10-2: gruppi di piani disabilitati per impostazione predefinita

Di seguito sono riportate le operazioni eseguite dai gruppi di piani disabilitati quando sono abilitati.

Questo gruppo di piani termina gli artifact delle istanze di computazione rimaste indietro nell'area 2 dopo che le versioni replicate delle VM sono state avviate nell'area 1 durante l'operazione di storage a blocchi OCI per invertire la replica dall'area 1 all'area 2 come parte dello switchover. Le VM rimanenti non vengono utilizzate durante uno switchback perché l'operazione di annullamento della replica del volume a blocchi crea tutte le nuove VM in gruppi di volumi a blocchi completamente nuovi.
Questo gruppo di piani termina gli artifact dei gruppi di volumi a blocchi (VG) lasciati indietro nell'area 2 dopo che le versioni replicate dei VG sono state attivate nell'area 1 e la replica del gruppo di volumi è stata invertita durante lo switchover. I gruppi di volumi a blocchi rimanenti non vengono mai più utilizzati, nemmeno come parte di uno switchover dalla regione 1 alla regione 2.

Task 10.2.1: Abilita interruzione gruppo di piani di calcolo

Abilitare il gruppo di piani.

Selezionare Abilita tutti i passi dal menu di scelta rapida a destra del nome del gruppo di piani.

Figura 10-3: Come abilitare l'interruzione delle istanze di computazione

Task 10.2.2 Abilita cessazione gruppo di piani gruppi di volumi

Abilitare il gruppo di piani.

Selezionare Abilita tutti i passi dal menu di scelta rapida a destra del nome del gruppo di piani.

Figura 10-4: Come abilitare l'interruzione dei gruppi di volumi

Task 10.3: Creare vari piani definiti dall'utente per il piano di switchover

Abbiamo già mostrato come creare il piano definito dall'utente per il piano di switchover da Task 6.3 a 6.7. Utilizzando un processo simile, creare cinque gruppi di piani personalizzati definiti dall'utente. Per eseguire gli script, è necessario utilizzare l'istanza di computazione in esecuzione nell'area Phoenix.

Sincronizza parametri pianificati da IAD primario a /home/opc/oic-scripts/oic-sync-schedule-parameters.sh in standby.
Attivare le integrazioni pertinenti in standby /home/opc/oic-scripts/oic-integration-switch.sh per attivare IAD.
Avviare le integrazioni pianificate in standby /home/opc/oic-scripts/oic-integration-schedule.sh per avviare IAD.
Aggiorna record DNS in standby /home/opc/oic-scripts/dns-record-update.sh IAD.
Disattiva integrazioni pianificate all'indirizzo /home/opc/oic-scripts/oic-integration-switch.sh primario disattiva IAD.

Una volta creati, il piano di switchover dovrebbe ora includere i cinque gruppi di piani DR per l'integrazione Oracle, come mostrato nello screenshot riportato di seguito. Potresti avere gruppi di piani aggiuntivi se il tuo gruppo di protezione include altre applicazioni o servizi OCI insieme all'integrazione Oracle.

Figura 10-21: Visualizzazione dei cinque gruppi di piani definiti dall'utente aggiunti al piano di switchover

Task 11: Personalizzare il piano di failover nell'area 1 (Ashburn)

Questo task spiega come aggiungere gruppi di piani DR personalizzati e definiti dall'utente e i passi per gestire gli elementi da eseguire durante un failover per Oracle Integration nell'area 1 durante un'interruzione o una perdita di accesso effettiva all'area 2. Si tratta di un sottoinsieme degli stessi passi appena aggiunti al piano di switchover nel precedente task 10. Tuttavia, solo i passi eseguiti nella standby region 1 verranno aggiunti al piano di failover poiché si presume che la region 2 sia completamente inaccessibile durante un failover.

Attiva le integrazioni pertinenti nell'area 1.
Aggiornare i parametri schedulati nell'area 1.
Avviare le integrazioni pianificate nell'area 1.
Aggiorna record DNS nell'area 1.

Task 11.1: selezionare il piano di switchover

Per iniziare, passare al piano di failover creato nel task 9.

Assicurati che la standby region 2 sia ancora il contesto della region corrente nella console.
Selezionare il piano di failover.

Figura 7-1: Come iniziare a personalizzare il piano di failover nell'area 2

Task 11.2: creare più gruppi di piani definiti dall'utente nell'area 1 (standby)

Abbiamo già mostrato come creare il piano definito dall'utente per il piano di failover da Task 7.2 a 7.5. Utilizzando il processo simile, creare i quattro gruppi di piani personalizzati definiti dall'utente riportati di seguito. Per eseguire gli script, è necessario utilizzare l'istanza di computazione in esecuzione nell'area Phoenix.

Attivare le integrazioni pertinenti in standby /home/opc/oic-scripts/oic-integration-switch.sh per attivare IAD.
Aggiornare i parametri pianificati in standby /home/opc/oic-scripts/oic-update-parameters.sh IAD.
Avviare le integrazioni pianificate in standby /home/opc/oic-scripts/oic-integration-schedule.sh per avviare IAD.
Aggiorna record DNS in standby /home/opc/oic-scripts/dns-record-update.sh IAD.

Una volta creati, il piano di failover dovrebbe ora includere i quattro gruppi di piani DR per l'integrazione Oracle, come mostrato nello screenshot riportato di seguito. Potresti avere gruppi di piani aggiuntivi se il tuo gruppo di protezione include altre applicazioni o servizi OCI insieme all'integrazione Oracle.

Figura 11-14: Visualizzazione dei quattro gruppi di piani definiti dall'utente aggiunti al piano di failover

Passi successivi

OCI Full Stack DR per Oracle Integration deve essere implementato completamente a questo punto. Tuttavia, è necessario convalidare tutte le funzionalità prima di utilizzare OCI Full Stack DR per la produzione. Tutti i piani di failover e switchover devono essere eseguiti per verificare che tutto funzioni come previsto e che il team di recupero comprenda completamente l'intero processo.

Test dei piani di switchover

I piani di switchover sono progettati per eseguire il cleanup di tutti gli artifact e garantire che tutti i ruoli per i passi di recupero integrati come il load balancer, lo storage a blocchi, i file system, BaseDB, ExaCS e Autonomous Data Base siano pronti per il recupero dalla standby region senza intervento umano.

Test dei piani di failover

I failover sono diversi. I failover non possono eseguire il cleanup degli artifact né garantire che i servizi e i database nell'area con errori siano pronti per la transizione dei carichi di lavoro all'area 1. Il team di recupero deve comprendere ed eseguire i task per garantire che Data Guard sia nello stato corretto, che gli artifact per le istanze di storage e computazione siano stati interrotti e così via. Per comprendere il processo, leggere Reimpostazione della configurazione DR dopo un failover nella documentazione di OCI Full Stack DR.

Convalida tutti i piani DR per l'accettazione finale

Il team di ripristino deve eseguire una convalida finale per dimostrare la disponibilità dei gruppi di protezione DR OCI Full Stack e dei piani per i carichi di lavoro di produzione. La regione 2 (Phoenix) deve essere la regione principale a questo punto del processo. Iniziare la convalida finale di tutti i piani completando i passi riportati di seguito.

Switchover di prova dall'area 2 (principale) all'area 1 (in standby).
Failover dei test dall'area 1 (principale) all'area 2 (in standby).
Prepara area 1 (primaria) per il failover dall'area 2.
Failover dei test dall'area 2 (principale) all'area 1 (in standby).
Prepara area 2 (primaria) per un failover o uno switchover all'area 2.
I gruppi di protezione DR e lo stack di applicazioni devono trovarsi in uno stato operativo normale e pronti per un failover o uno switchover in questo momento.

Nota: per assicurarsi che la stessa applicazione client possa essere utilizzata per autenticare le altre API per entrambe le istanze di Oracle Integration, è possibile aggiungere l'ambito di entrambe le istanze, ovvero Primario e Secondario, all'applicazione client OAuth. Per l'impostazione dell'applicazione client OAuth, è possibile fare riferimento alla documentazione ufficiale.

Riconoscimenti

Autore - Suraj Ramesh (Full Stack Disaster Recovery Product Manager)
Contributor - Bonnie Rockey (Cloud Engineering, Oracle Integration Specialist), Akshay Saxena (Cloud Engineering, Oracle Integration Specialist)

Video 1: Distribuisci Oracle Integration per Disaster Recovery Video 2: Automatizza le operazioni di Disaster Recovery per Oracle Integration utilizzando OCI Full Stack DR Video 3: Script utilizzati per automatizzare il ripristino per Oracle Integration

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 Oracle Learning Explorer.

Per la documentazione del prodotto, visitare Oracle Help Center.

Titolo e informazioni sul copyright

Automate Recovery for Oracle Integration using OCI Full Stack Disaster Recovery

F99105-01

May 2024

Oracle e/o relative consociate.

Automatizza il recupero per Oracle Integration utilizzando OCI Full Stack Disaster Recovery

Parte 1: Introduzione

Oracle Integration fa normalmente parte di un sistema più grande

Attenzione all'implementazione incrementale

Come funziona il recupero

Opzione 1 per gli script di hosting

Opzione 2 per gli script di hosting

Architettura di distribuzione di Oracle Integration

Acquisire familiarità con l'intero processo

Parte 2: Istruzioni dettagliate

Obiettivi

Definizioni e ipotesi in tutta l'esercitazione

Aree

Compartimenti

Nodo di controllo DR di Oracle Integration

Prerequisiti

Task 1: Distribuire Oracle Integration per il disaster recovery

Task 1.1: preparare il nodo di controllo DR per eseguire l'automazione personalizzata

Opzione 1: Oracle Integration come applicazione standalone

Opzione 2: Oracle Integration come parte di uno stack di applicazioni

Opzione 3: Oracle Integration come parte di uno stack di applicazioni con più offerte PaaS

Task 1.2: assicurarsi che il gruppo di volumi sia replicato nell'area 2

Task 1.3: Scarica script bash nel nodo di controllo DR

Task 1.4: Distribuire Oracle Integration per DR

Task 1.5: Test manuale del recupero di Oracle Integration

Task 1.6: Passi successivi

Task 2: Preparati per OCI Full Stack DR

Task 2.1: Creare criteri IAM per OCI Full Stack DR

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

Task 2.3: Creare bucket di storage degli oggetti OCI per i log DRPG

Task 3: Creare gruppi di protezione DR in entrambe le aree

Task 3.1: Passare ai gruppi di protezione DR

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

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

Task 3.4: Associare i gruppi di protezione nella regione 1 e nella regione 2

Task 4: aggiungere membri al gruppo di protezione DR

Task 4.1: Iniziare ad aggiungere membri a DRPG nell'area 1

Task 5: Creare piani DR di base nella regione 2 (Phoenix)

Task 5.1: Iniziare a creare piani DR

Task 6: Personalizzare il piano di switchover nella regione 2 (Phoenix)

Task 6.1: Selezionare il piano di switchover

Task 6.2: Abilita gruppi di piani DR che terminano gli artifact (facoltativo)

Task 6.3: creare un gruppo di piani per sincronizzare i parametri programmati dall'area 1 all'area 2

Task 6.4: creare un gruppo di piani per attivare le integrazioni pertinenti in standby

Task 6.5: creare un gruppo di piani per avviare le integrazioni pianificate nell'area 2

Task 6.6: creare un gruppo di piani per aggiornare il record DNS nell'area 2

Task 6.7: creare un gruppo di piani per disattivare le integrazioni pianificate nell'area 1

Task 7: Personalizzare il piano di failover nell'area 2 (Phoenix)

Task 7.1: selezionare il piano di failover

Task 7.2: Selezionare Aggiungi gruppo di piani

Task 7.3: creare un gruppo di piani per aggiornare i parametri programmati nell'area 2

Task 7.4: creare un gruppo di piani per avviare le integrazioni pianificate nell'area 2

Task 7.5: creare un gruppo di piani per aggiornare il record DNS nell'area 2

Task 8: Esegui il piano di switchover nella regione 2 (Phoenix)

Task 8.1: Inizio dell'esecuzione del piano

Task 8.2: Selezionare il piano di switchover ed eseguire

Task 8.3: passi successivi

Task 9: Creare piani DR nell'area 1 (Ashburn)

Task 9.1: Iniziare a creare piani DR

Task 9.2: Creare un piano di failover

Task 10: Personalizzare il piano di switchover nell'area 1 (Ashburn)

Task 10.1: selezionare il piano di switchover

Task 10.2: Abilita gruppi di piani DR che terminano gli artifact (facoltativo)

Task 10.3: Creare vari piani definiti dall'utente per il piano di switchover

Task 11: Personalizzare il piano di failover nell'area 1 (Ashburn)

Task 11.1: selezionare il piano di switchover

Task 11.2: creare più gruppi di piani definiti dall'utente nell'area 1 (standby)

Passi successivi

Test dei piani di switchover

Test dei piani di failover

Convalida tutti i piani DR per l'accettazione finale

Collegamenti correlati

Riconoscimenti

Altre risorse di apprendimento