Nota

• Questa esercitazione richiede l'accesso a Oracle Cloud. Per iscriversi 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. Quando completi il tuo laboratorio, sostituisci questi valori con quelli specifici del tuo ambiente cloud.

Automatizza il recupero per Oracle E-Business Suite multi-nodo utilizzando OCI Full Stack Disaster Recovery

Introduzione

OCI Full Stack Disaster Recovery si affida ai team di progettazione delle applicazioni per progettare, scrivere e gestire le proprie funzionalità e funzionalità di disaster recovery. Se un team di progettazione delle applicazioni dispone di funzionalità di disaster recovery native OCI che includono API SDK (Software Development Kit) OCI per il disaster recovery, tale applicazione può essere aggiunta a Full Stack DR come risorsa membro nativa.

Oracle E-Business Suite non dispone attualmente di funzionalità o funzionalità di disaster recovery native OCI e, come tale, non è una risorsa membro nativa in Full Stack DR. Tuttavia, il team di progettazione Oracle E-Business Suit ha documentato un processo per la distribuzione e il recupero manuali di EBS nelle region OCI. Il processo manuale può essere automatizzato utilizzando Full Stack DR. Questo documento spiega come automatizzare il processo di ripristino manuale aggiungendo gruppi di piani e passi personalizzati e definiti dall'utente ai piani DR di base per failover, switchover ed espansioni.

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.

Oracle E-Business Suite supporta i modelli di business in continua evoluzione di oggi, aumenta la produttività e soddisfa le esigenze dell'utente mobile moderno. Basandosi su una storia di innovazione di 30 anni, Oracle E-Business Suite continua a fornire nuove funzionalità applicative ed espandere le funzionalità delle funzioni esistenti, aiutandoti a ottenere tutti i vantaggi di OCI.

Oracle E-Business Suite è normalmente parte di un sistema più grande

Oracle E-Business Suite è in genere la base di un sistema aziendale più complesso che include una serie di database aggiuntivi, applicazioni di marketplace OCI e servizi OCI che devono essere tutti recuperati come una singola unità. Per semplificare e focalizzarsi su Oracle E-Business Suite, questa esercitazione descrive solo i task correlati a Oracle E-Business Suite. Tuttavia, è molto insolito che Oracle E-Business Suite sia l'unica applicazione che fa parte del DR Protection Group e dei piani DR.

Attenzione all'implementazione incrementale

L'aggiunta o l'eliminazione di più membri a un gruppo di protezione DR dopo la creazione dei piani DR aggiornerà i piani DR esistenti nei gruppi di protezione in entrambe le aree. Per ulteriori informazioni, vedere Aggiornamento di un piano di disaster recovery.

OCI Full Stack DR è progettato ipotizzando che l'intero stack di applicazioni per un determinato sistema aziendale sia già distribuito in tutte le aree OCI e che la riconfigurazione dinamica manuale sia già stata dimostrata efficace. Se il sistema aziendale include più di Oracle E-Business Suite, aggiungere tutti gli altri servizi di computazione, storage, database, applicazioni o OCI ai gruppi di protezione DR prima di creare piani DR.

Come funziona il recupero

La soluzione di ripristino per Oracle E-Business Suite richiede OCI Full Stack DR per eseguire una serie di script bash personalizzati durante un'operazione di ripristino, ad esempio un failover o uno switchover o un'espansione. In questa esercitazione verranno utilizzati i nodi dell'applicazione Oracle E-Business Suite come nodo di controllo per l'hosting e l'esecuzione degli script.

Gli script a cui viene fatto riferimento in questa esercitazione sono forniti dalle applicazioni Oracle EMEA Cloud Engineering Oracle al team di esperti OCI e disponibili negli script Oracle E-Business Suite per OCI Full Stack Disaster Recovery. È possibile che gli script bash debbano essere modificati leggermente per soddisfare le esigenze specifiche della distribuzione.

Figura 1: Script di Oracle E-Business Suite disponibili nel repository GitHub di esempio di Oracle

Questa esercitazione spiega come scaricare gli script e come utilizzarli in un passo successivo. Questa esercitazione utilizza l'opzione 1 per l'hosting degli script bash solo perché l'esercitazione non include altro che Oracle E-Business Suite.

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

Opzione 1 per gli script di hosting

Installare gli script bash nei server applicazioni Oracle E-Business Suite in esecuzione in entrambe le aree. Questa esercitazione fa riferimento all'istanza o alle istanze di computazione in cui vengono installati gli script come nodo di controllo o nodo DR, anche se si tratta di uno o più server applicazioni Oracle E-Business Suite nello stack di applicazioni.

Opzione 2 per gli script di hosting

Crea un nodo di controllo o un nodo DR specializzato per ospitare tutti gli script di Oracle E-Business Suite e gli script necessari per altre applicazioni o servizi OCI.

Oracle E-Business Suite fa spesso parte di un sistema aziendale più ampio e complesso che include applicazioni interne personalizzate, applicazioni Oracle Cloud Marketplace, Oracle Business Analytics e altri database, istanze di computazione e applicazioni di produzione domestica. In questo caso, è sufficiente scegliere una qualsiasi delle istanze di computazione che fanno già parte del sistema aziendale per ospitare gli script. L'istanza di computazione selezionata può essere qualsiasi cosa in cui Oracle Linux è installato e molto probabilmente sarà una VM esistente che serve un altro scopo come un application server o un server di amministrazione di qualche tipo.

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. Il Management Server 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 tutti gli script personalizzati possono risiedere ed essere richiamati da OCI Full Stack DR durante un'operazione di ripristino.

Nota: in questa esercitazione verrà utilizzata l'opzione 1, in cui verranno memorizzati gli script personalizzati correlati all'applicazione Oracle E-Business Suite nei server applicazioni Oracle E-Business Suite.

Architettura di distribuzione di Oracle E-Business Suite

Prima di introdurre OCI Full Stack DR, Oracle E-Business Suite deve essere distribuito per il disaster recovery (DR) in tutte le region OCI. È molto importante che i passi manuali per eseguire un ripristino vengano testati e funzionino correttamente prima di tentare di automatizzare il processo di recupero utilizzando OCI Full Stack DR.

È possibile seguire una delle due architetture di riferimento riportate di seguito durante la distribuzione di Oracle E-Business Suite per il recupero da errori irreversibili in tutte le aree OCI. Entrambe le architetture di riferimento illustrano una topologia a più livelli con risorse ridondanti distribuite in due region OCI.

I database a più istanze sono creati con Oracle Real Application Clusters (Oracle RAC) e utilizzano Oracle Data Guard per mantenere sincronizzato il database in due aree OCI.

Architettura di riferimento per Oracle E-Business Suite mediante Oracle Base Database Service

Scegliere questa architettura di distribuzione se Oracle E-Business Suite utilizza Oracle Base Database Service. Oracle E-Business Suite deve essere distribuito per il DR in due aree OCI, come descritto in Business Continuity for Oracle E-Business Suite Release 12.2 con Oracle Database 19c sui sistemi DB Oracle Base Database Service (ID documento 2875417.1). L'illustrazione illustrata nella Figura 1 è stata ottenuta da ID documento 2875417.1.

Figura 1: Architettura di distribuzione DR di Oracle E-Business Suite che utilizza OCI Base Database (per ulteriori dettagli, vedere l'ID doc 2875417.1)

Architettura di riferimento per Oracle E-Business Suite utilizzando Oracle Exadata Database Service on Dedicated Infrastructure

Scegli questa architettura di distribuzione se Oracle E-Business Suite utilizza Oracle Exadata Database Service on Dedicated Infrastructure. Oracle E-Business Suite deve essere distribuito per il DR in due aree OCI, come spiegato in Business Continuity for Oracle E-Business Suite Release 12.2 con Oracle Database 19c su Oracle Exadata Database Service on Dedicated Infrastructure (ID documento 2919723.1). L'illustrazione illustrata nella figura 1 è stata ottenuta da ID documento 2919723.1.

Figura 2: Architettura di distribuzione DR di Oracle E-Business Suite con OCI Exadata Database (per ulteriori dettagli, consultare l'ID documento 2919723.1)

Differenza tra nomi host logici e nomi host fisici

Oracle E-Business Suite suggerisce di utilizzare nomi host logici per gli Application Server e nomi host fisici per il database. Sia Business Continuity for Oracle E-Business Suite Release 12.2 con Oracle Database 19c sui sistemi DB Oracle Base Database Service (ID documento 2875417.1) che Business Continuity for Oracle E-Business Suite Release 12.2 con Oracle Database 19c sui sistemi DB Oracle Base Database Service (ID documento 2919723.1) scritto dai tecnici di Oracle E-Business Suite richiedono che il livello dell'applicazione utilizzi nomi host logici mentre il livello del database utilizzi nomi host fisici.

OCI Full Stack DR non richiede l'uso di nomi host logici o fisici, ma si consiglia di seguire i requisiti di Oracle E-Business Suite per garantire il supporto di Oracle E-Business Suite in caso di problemi. Alcuni clienti utilizzano nomi host logici sia per i livelli dell'applicazione che per quelli del database. Gli script forniti con questa soluzione sono progettati per essere utilizzati con nomi host logici per il livello dell'applicazione e il livello del database dei nomi host fisici. Per istruzioni sul download, vedere Task 1.2.

Architettura di distribuzione Full Stack DR OCI

Le illustrazioni riportate di seguito mostrano le risorse di computazione aggiunte come membri a ogni DR Protection Group (DRPG) per OCI Full Stack DR. Questi rappresentano i vari componenti che OCI Full Stack DR può gestire all'esterno dell'applicazione Oracle E-Business Suite.

OCI Full Stack DR ha l'automazione integrata per gestire OCI Compute, OCI Block Storage, OCI File Storage, database Oracle, OCI Load Balancer, cluster Oracle Cloud Infrastructure Kubernetes Engine (OKE) e molte altre risorse durante un ripristino, ma non dispone di automazione integrata per Oracle E-Business Suite stessa. Il ripristino di Oracle E-Business Suite è controllato da una serie di script bash che è possibile scaricare da un repository GitHub dedicato a questa esercitazione. Gli script bash devono essere installati su un'istanza di computazione di tua scelta seguendo una delle seguenti opzioni per il posizionamento e il controllo degli script.

Opzione 1: automatizzare il recupero per Oracle E-Business Suite utilizzando Oracle Base Database Service

Questa architettura di distribuzione non è tipica ed è stata ideata per le situazioni molto rare in cui Oracle E-Business Suite è l'unica applicazione recuperata da OCI Full Stack DR. In questo caso, verranno ospitati gli script personalizzati nei nodi dell'applicazione Oracle E-Business Suite.

Figura 3: Architettura di distribuzione Full Stack DR utilizzando il servizio OCI Base Database

Opzione 2: automatizza il recupero per Oracle E-Business Suite utilizzando Oracle Exadata Database Service on Dedicated Infrastructure

L'architettura di distribuzione semplicistica illustrata nella Figura 4 è un esempio di distribuzione più comune di Oracle E-Business Suite in cui si tratta semplicemente di un componente di uno stack di applicazioni più ampio e complesso in cui è necessario recuperare insieme molti servizi e applicazioni. La maggior parte dei sistemi aziendali è molto più complessa di quella fittizia mostrata nell'immagine seguente e in genere include database aggiuntivi, altre applicazioni Oracle e/o non Oracle, oltre ad altri servizi OCI come OIC, ODI, OHS, OCI IAM e così via.

Figura 4: Architettura di distribuzione Full Stack DR utilizzando Oracle Exadata Database Service on Dedicated Infrastructure

Definizioni e ipotesi in tutta l'esercitazione

Aree

Il ruolo di primario e standby è una funzione dei gruppi di protezione OCI Full Stack DR, non delle region stesse. Un'area può funzionare come primaria per uno stack di applicazioni e allo stesso tempo come standby per uno stack di applicazioni completamente diverso. Il ruolo di primario e standby è fluido.

Questa esercitazione inizia con lo stack di applicazioni Oracle E-Business Suite in esecuzione in Phoenix e con tutte le risorse di standby in esecuzione in Ashburn. Queste due aree sono solo esempi; è possibile utilizzare in pratica due region OCI che supportano lo stack di applicazioni.

• La regione 1 è Phoenix.

  • Phoenix inizierà come regione principale.
  • Phoenix inizia come regione primaria perché:
    • L'applicazione Oracle E-Business Suite è in esecuzione a Phoenix.
    • Il job cron rsync di Oracle E-Business Suite sta copiando i dati da /u01 sui server delle applicazioni (VM) di Oracle E-Business Suite a Phoenix negli application server in esecuzione ad Ashburn.
    • Il database di Phoenix ha il ruolo primario di Oracle Data Guard.
  • Phoenix alla fine diventerà lo standby dopo che ti verrà chiesto di eseguire uno switchover nelle attività successive.

• La regione 2 è Ashburn.

  • Ashburn inizierà come standby region.
  • Ashburn inizia come standby region perché:
    • Gli application server (VM) in standby di Oracle E-Business Suite sono in esecuzione in Ashburn.
    • L'applicazione Oracle E-Business Suite non è in esecuzione in Ashburn.
    • I dati in /u01 vengono copiati da Phoenix alle VM di Ashburn.
    • Il database in Ashburn ha il ruolo di standby Oracle Data Guard.
  • Ashburn alla fine diventerà il principale dopo che ti viene chiesto di eseguire uno switchover nelle attività successive.

Compartimenti

Sei libero di organizzare Oracle E-Business Suite 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 le applicazioni nei loro singoli compartimenti, quindi organizzare tutti i gruppi di protezione DR in un unico compartimento in cui tutti i sistemi aziendali completamente diversi possono essere visti a colpo d'occhio.

• L'organizzazione di 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 DR per molti sistemi aziendali completamente diversi.
• Avere un singolo 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 la Oracle E-Business Suite (ebstesting). In questa esercitazione, il compartimento per Oracle E-Business Suite stesso, lo storage, i bucket di storage, il calcolo e il database relativi a Oracle E-Business Suite è ebstesting.
  • Compartimento per OCI Full Stack DR myprojects. In questa esercitazione, il compartimento per i gruppi e i piani di protezione OCI Full Stack DR è myprojects.

Obiettivi

In questa esercitazione verranno descritti i task seguenti in cui viene spiegato come automatizzare il recupero per Oracle E-Business Suite utilizzando OCI Full Stack DR.

Nota: iniziamo con la Regione 1 (Phoenix) e la Regione 2 (Ashburn). La produzione dell'applicazione Oracle E-Business Suite viene eseguita nell'area 1 e il recupero da errori irreversibili è configurato nell'area, poiché durante l'esercitazione si fa riferimento all'area 1 e all'area 2 anziché all'area name.If effettiva in cui la distribuzione utilizza diverse aree OCI, quindi assicurarsi di fare riferimento a tali rispettive aree di produzione e recupero da errori irreversibili.

1. Task 1: Implementa Oracle E-Business Suite per il DR nelle aree OCI.

   1. Installare e distribuire manualmente Oracle E-Business Suite for DR in due region OCI.
   2. Eseguire manualmente il test di tutti i passi di recupero dall'area 1 desiderata all'area 2.
   3. Eseguire manualmente il test di tutti i passi di recupero dall'area 2 desiderata all'area 1.

2. Task 2: Preparazione per OCI Full Stack DR.

   1. Impostare i criteri IAM OCI per Full Stack DR.
   2. Impostare i criteri IAM OCI per altri servizi OCI.
   3. Scaricare e installare script Oracle E-Business Suite personalizzati sui server applicazioni Oracle E-Business Suite.
   4. Assicurati che gli application server di Oracle E-Business Suite possano eseguire script e comandi.
   5. Creare segreti del vault per il database Oracle E-Business Suite.
   6. Creare bucket di storage degli oggetti per i log.

3. Task 3: Creare e associare i gruppi di protezione DR.

4. Task 4: aggiungere i membri del database e del calcolo Oracle E-Business Suite ai gruppi di protezione DR dell'area 1 e dell'area 2.

5. Task 5: Creare i piani DR nell'area 2 (Ashburn).

   1. Creare un piano di switchover.
   2. Creare un piano di failover.
   3. Crea il piano di espansione iniziale.

6. Task 6: Personalizzare i piani DR nell'area 2 (Ashburn).

7. Task 7: eseguire il piano di switchover nell'area 2 (Ashburn).

8. Task 8: Creare piani DR di base nella regione 1 (Phoenix) e personalizzare i piani DR nella regione 1 (Phoenix).

   1. Crea il piano di switchover e personalizza il piano di switchover nell'area 1 (Phoenix).
   2. Crea un piano di failover e personalizza il piano di failover nell'area 1 (Phoenix).
   3. Creare un piano di espansione iniziale e personalizzare il piano di espansione iniziale nell'area 1 (Phoenix).

Prerequisiti

Oracle E-Business Suite deve essere distribuito per il disaster recovery in entrambe le region prima di iniziare a lavorare con OCI Full Stack DR. Questo è coperto dal task 1.

Task 1: Implementa Oracle E-Business Suite per il disaster recovery

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

Oracle E-Business Suite deve essere distribuito per il disaster recovery nelle aree OCI utilizzando uno dei due diversi articoli di documentazione su My Oracle Support (MOS) (note KM) prima di iniziare qualsiasi lavoro con OCI Full Stack DR.

È inoltre molto importante che i passi manuali descritti nelle note KM e gli script/l'automazione personalizzati necessari per recuperare Oracle E-Business Suite siano stati completamente testati prima di iniziare qualsiasi lavoro con OCI Full Stack DR.

Oracle E-Business Suite attualmente supporta Oracle Base Database Service e i servizi Oracle Exadata Database Service on Dedicated Infrastructure. Il servizio Oracle Autonomous Database non è attualmente supportato con Oracle E-Business Suite. Seguire le istruzioni riportate in una o nell'altra delle seguenti note KM:

• ID documento 2875417.1: distribuire Oracle E-Business Suite per DR utilizzando BaseDB

• ID documento 2919723.1: distribuire Oracle E-Business Suite per DR utilizzando ExaDB-D

Task 2: Preparazione della tenancy per OCI Full Stack DR

OCI Full Stack DR non è coinvolto in alcuna parte di questo task. I passi riportati di seguito preparano la tenancy, il compartimento, i servizi OCI e Oracle E-Business Suite per il recupero automatico da parte di OCI Full Stack DR. La maggior parte delle attività articolate in questa sezione sono discusse in Prerequisiti per Full Stack Disaster Recovery.

Task 2.1: Impostare i criteri IAM OCI per OCI Full Stack DR

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

• Politiche per Full Stack Disaster Recovery.
• Configurazione dei criteri IAM (Identity and Access Management) necessari per Full Stack Disaster Recovery.

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

• Policy per altri servizi gestiti da Full Stack Disaster Recovery.

Attività 2.3: download e installazione di Oracle E-Business personalizzato SuiteScripts su Oracle E-Business Suite Application Server

OCI Full Stack DR ha un'intelligence integrata per orchestrare il ripristino per le risorse OCI Infrastructure as a Service (IaaS) e Platform as a Service (PaaS). OCI Full Stack DR non dispone di intelligence integrata per orchestrare il recupero per Oracle E-Business Suite poiché Oracle E-Business Suite non fornisce al momento API di disaster recovery native OCI per distribuire o gestire il proprio disaster recovery integrato.

Tuttavia, OCI Full Stack DR può ancora orchestrare il ripristino per Oracle E-Business Suite aggiungendo gruppi di piani DR definiti dall'utente e passi ai piani DR di base creati in seguito in questa esercitazione. Come illustrato nella Parte 1 di questa esercitazione, i passi definiti dall'utente richiederanno una serie di script personalizzati che eseguono vari task necessari per recuperare Oracle E-Business Suite. Gli script devono essere scaricati e installati su tutte le istanze di computazione nei server applicazioni Oracle E-Business Suite in entrambe le aree:

1. Scarica gli script Oracle E-Business Suite da qui: Script Oracle E-Business Suite per OCI Full Stack Disaster Recovery.
2. Copiare gli script in qualsiasi directory di ciascun server applicazioni Oracle E-Business Suite nell'area 1.
3. Copiare gli script nella stessa posizione di directory in ciascuno dei server applicazioni di Oracle E-Business Suite nell'area 2.
4. Assicurarsi che i file siano di proprietà dell'utente oracle.
5. Assicurarsi che i file siano eseguibili.

Task 2.4: assicurarsi che gli Application Server Oracle E-Business Suite possano eseguire script e comandi

OCI Full Stack DR dovrà eseguire gli script di Oracle E-Business Suite scaricati negli application server di Oracle E-Business Suite. OCI Full Stack DR esegue gli script utilizzando l'agente Oracle Cloud su ogni istanza di computazione. È molto importante che tutte le istanze di computazione utilizzate come server applicazioni Oracle E-Business Suite in entrambe le aree siano in grado di eseguire comandi tramite OCI Console utilizzando Oracle Cloud Agent.

Per ulteriori informazioni, vedere Preparazione delle istanze di computazione per Full Stack Disaster Recovery. Prestare particolare attenzione alle istruzioni per l'esecuzione di comandi con privilegi di amministratore.

Verificare che i comandi possano essere eseguiti dalla console OCI

Nota: questo task garantisce solo che l'agente Oracle Could possa eseguire i comandi. Non convalida l'esistenza di criteri appropriati per consentire a Full Stack DR di eseguire i comandi tramite l'agente Oracle Cloud. Questo diventerà evidente nei passi successivi quando l'esercitazione spiega come convalidare il piano DR di switchover nell'area 2.

Utilizzare la funzione Esegui comando dell'istanza di computazione per convalidare che Oracle Cloud Agent sia in grado di eseguire i comandi. Le immagini riportate di seguito mostrano il comando Esegui nella pagina dei dettagli per le istanze di computazione in OCI Console.

1. Selezionare Run command.
2. Selezionare Crea comando e digitare qualsiasi comando Linux valido, ad esempio date. Modificare il timeout su qualcosa di ragionevole, ad esempio 3 minuti prima di eseguire il comando.

Figura 2.4.1.1: eseguire un comando dalla console OCI

Task 2.5: Creare i segreti di OCI Vault per il database Oracle E-Business Suite

OCI Full Stack DR avrà bisogno della password sys del database in modo che possa attivare automaticamente Oracle Data Guard durante i failover e gli switchover. Aggiungere la password del database sys a un segreto vault in entrambe le aree, come spiegato qui: Preparazione dei database Oracle per Full Stack Disaster Recovery.

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

Nota: ignorare completamente il task 2.3 se si sta aggiungendo Oracle E-Business Suite ai gruppi di protezione DR esistenti.

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.

Task 2.6.1: Passare a OCI Object Storage

Iniziare passando a Storage degli oggetti e storage di archivio, come mostrato nella Figura 2-1.

1. Assicurarsi che il contesto del browser sia impostato sull'area 1 (Phoenix).
2. Fare clic su Memorizzazione.
3. Fare clic su Bucket.

Figura 2.6.1.1: Passare allo storage degli oggetti

Task 2.6.2: creare un bucket di storage degli oggetti OCI nelle aree 1 e 2

Creare un bucket di storage degli oggetti OCI nell'area 1. Quindi creare un bucket di storage identico nell'area 2. I bucket verranno assegnati ai gruppi di protezione DR nell'area 1 e 2 in un task successivo.

1. Selezionare il compartimento che contiene le risorse correlate a Oracle E-Business Suite. Il compartimento può essere diverso in ogni area.
2. Fare clic su Crea bucket.
3. Assegnare al bucket un nome significativo che identifichi facilmente l'applicazione e lo scopo utilizzati; non vi è alcun motivo per includere l'area come parte del nome. Ad esempio, questo nome indica che viene utilizzato per i log Full Stack DR OCI relativi alle operazioni DR per Oracle E-Business Suite.
4. Utilizzare il valore predefinito per Livello e Cifratura.
5. Fare clic su Crea per creare il bucket.

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

Task 3: Creazione e associazione di gruppi di protezione DR

Questa sarà la prima attività che prevede Full Stack DR. 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.

Nota: ignorare completamente il task 3 se Oracle E-Business Suite viene aggiunto ai gruppi di protezione DR esistenti.

Questo task inizia il primo passo della configurazione di OCI Full Stack DR per lo stack di applicazioni che include Oracle E-Business Suite. I gruppi di protezione DR informano OCI Full Stack DR su quali servizi OCI IaaS e PaaS fanno parte di un singolo stack di applicazioni e quali due region agiranno come primarie e standby per il sistema aziendale. I gruppi di protezione DR costituiscono la base su cui si basa tutto il resto.

Tutte le risorse OCI IaaS e PaaS che appartengono allo stack di applicazioni in entrambe le aree verranno aggiunte come parte del task 4.

Nota: sebbene questa esercitazione includa solo Oracle E-Business Suite, i gruppi di protezione DR in genere contengono servizi OCI IaaS e PaaS per molte applicazioni Oracle e non Oracle diverse e in aggiunta a quelle necessarie a Oracle E-Business Suite.

Task 3.1: Creare un gruppo di protezione nell'area di standby 2 (Ashburn)

Iniziare creando un gruppo di protezione DR non associato nell'area 2. Non è richiesto che il gruppo di protezione venga creato nella standby region, il processo scorre leggermente meglio iniziando dalla region 2.

Task 3.1.1: Passare ai gruppi di protezione DR

Iniziare passando a DR Protection Groups (OCI Full Stack DR) come mostrato nella Figura 3.1.1.

1. Assicurarsi che il contesto dell'area OCI sia impostato sull'area 2 (Ashburn).
2. Fare clic su Migrazione e disaster recovery.
3. Fare clic su Gruppi di protezione DR.

Figura 3.1.1: Passare ai gruppi di protezione DR

Task 3.1.2: Creare il gruppo di protezione

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

1. Selezionare il compartimento in cui si desidera creare il DRPG. Può essere lo stesso compartimento in cui esistono risorse di Oracle E-Business Suite o qualsiasi altro compartimento correlato al progetto.
2. Selezionare Crea gruppo di protezione DR per aprire la finestra di dialogo in cui immettere i parametri per creare il gruppo di protezione.

Figura 3.1.2: Inizia a creare un gruppo di protezione DR nell'area 2

Task 3.1.3: Aggiungere i parametri necessari per creare il gruppo di protezione

Aggiungere un nome e un bucket di storage degli oggetti OCI per i log, come mostrato nella Figura 3.1.3.

1. Utilizzare un nome semplice e significativo per il DRGP; in questo esempio viene visualizzato il nome del sistema aziendale e dell'area.
2. Selezionare il compartimento in cui si desidera creare il DRPG nell'area 2.
3. Selezionare il bucket di storage degli oggetti creato nel task 2 per l'area 2. Potrebbe essere necessario modificare il compartimento se il bucket è stato creato in un compartimento diverso.

Non inserire parametri aggiuntivi. Fare clic su Crea nella parte inferiore della finestra di dialogo (non visualizzata qui).

Figura 3.1.3: Parametri necessari per creare un gruppo di protezione DR nell'area 2

Cosa dovresti vedere dopo aver creato il gruppo di protezione

Il primo gruppo di protezione DR verrà creato come mostrato nella Figura 3-2.3. I ruoli e le informazioni peer verranno assegnati nell'ambito del task 3.4.

Figura 3.1.4: Visualizzazione del gruppo di protezione DR appena creato nell'area 2

Task 3.2: Creare un gruppo di protezione nella regione primaria 1 (Phoenix)

Creare un gruppo di protezione nell'area 1. In un task successivo, verranno aggiunte tutte le risorse OCI che appartengono allo stack di applicazioni in quest'area. In questo modo OCI Full Stack DR sa quali asset vengono considerati parte di un sistema aziendale in quest'area.

Task 3.2.1: Creare il gruppo di protezione

Creare un gruppo di protezione DR di base (DRPG) nella regione 1, come mostrato nella Figura 3.2.1. Il peer, il ruolo e i membri verranno assegnati nei passi successivi.

1. Modificare il contesto dell'area OCI in area 1.
2. Selezionare il compartimento in cui si desidera creare il DRPG. Le persone di solito scelgono lo stesso compartimento utilizzato per creare il DRPG nell'area 2.
3. Selezionare Crea gruppo di protezione DR per aprire la finestra di dialogo in cui immettere i parametri per creare il gruppo di protezione.

Figura 3.2.1: Inizio della creazione del gruppo di protezione DR nell'area 1

Task 3.2.2: Aggiungere i parametri necessari per creare il gruppo di protezione

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

1. Utilizzare un nome semplice e significativo per il gruppo DR PRotection. In questo esempio viene visualizzato il nome del sistema aziendale e dell'area.
2. Selezionare il compartimento in cui si desidera che venga creato il DRPG nell'area 1. Le persone in genere utilizzano lo stesso compartimento in entrambe le aree.
3. Selezionare il bucket di storage degli oggetti creato nel task 2 per l'area 1. Potrebbe essere necessario modificare il compartimento se il bucket è stato creato in un compartimento diverso.

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

Cosa dovresti vedere dopo aver creato il gruppo di protezione

Il secondo gruppo di protezione DR verrà creato come mostrato nella Figura 3.2.3. I ruoli e le informazioni peer verranno assegnati nell'ambito del task 3.3.

Figura 3.2.3: Visualizzazione del gruppo di protezione DR appena creato nell'area 2

Task 3.3: Gruppi di protezione associati nell'area 1 e nell'area 2

Associare i DRPG in ogni area come peer e assegnare i ruoli di database primario e standby. Ecco in che modo OCI Full Stack DR saprà quali due region lavorano insieme per il ripristino di Oracle E-Business Suite. I ruoli primario e standby vengono modificati automaticamente da OCI Full Stack DR nell'ambito di qualsiasi esecuzione del piano DR/operazione di DR; non è necessario gestire i ruoli manualmente in qualsiasi momento dopo l'assegnazione dei ruoli iniziali ai DRPG in questo task.

Task 3.3.1: Iniziare l'associazione

1. Assicurati che il contesto dell'area OCI sia impostato sull'area 1 (Phoenix).
2. Fare clic su Associa per avviare il processo.

Figura 3.3.1: Inizio dell'associazione DRPG

Task 3.3.2: Gruppi di protezione associati nell'area 1 e nell'area 2

Fornire i parametri come illustrato nella figura 3.3.2.

1. Selezionare il ruolo principale. OCI Full Stack DR assegnerà automaticamente il ruolo di standby all'area 2.
2. Selezionare la regione 2 (Phoenix) in cui è stato creato l'altro DRPG.
3. Selezionare il DRPG peer in cui è stato creato.

Figura 3.3.2: Parametri necessari per associare i DRPG

Cosa dovresti vedere dopo che l'associazione è stata completata:

OCI Full Stack DR mostrerà qualcosa come la Figura 3.3.3 una volta completata l'associazione.

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

Figura 3.3.3: Visualizzazione della relazione tra pari dal punto di vista dei singoli DRPG

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 in Figura 3.4.3.2.

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

Figura 3.4.3.2: Visualizzazione della relazione tra peer dalla prospettiva DRPG globale

Task 4: aggiungere membri Oracle E-Business Suite ai gruppi di protezione DR dell'area 1 e dell'area 2

Aggiungere il database e gli application server Oracle E-Business Suite non mobili come membri del gruppo di protezione DR (DRPG) in entrambe le aree. Il calcolo non mobile significa che gli application server di Oracle E-Business Suite esistenti nell'area 1 non vengono mai avviati o avviati nell'area 2. I volumi di avvio per la computazione non mobile non vengono replicati utilizzando la replica dello storage OCI nell'area 2 e non vengono aggiunti come membri dei gruppi di protezione DR.

In questa esercitazione vengono illustrati solo i passi relativi a Oracle E-Business Suite, ma è consigliabile cogliere questa opportunità per aggiungere eventuali servizi OCI IaaS e PaaS aggiuntivi da recuperare insieme a Oracle E-Business Suite. Ad esempio, potrebbero esserci altri processi di computazione mobile, computazione non mobile, database, load balancer, file system, storage a blocchi o storage degli oggetti associati ad altre applicazioni interne o Oracle che fanno parte dell'ecosistema Oracle E-Business Suite.

Nota: questo task aggiornerà i piani DR esistenti in entrambe le aree quando si aggiungono membri a gruppi di protezione DR esistenti. Per ulteriori informazioni, vedere Aggiornamento di un piano di disaster recovery.

Task 4.1: Aggiungi risorse membro al gruppo di protezione DR all'area 1 (Phoenix)

Le risorse seguenti verranno aggiunte come membri del DRPG principale nell'area 1.

1. Due application server Oracle E-Business Suite non mobili (Oracle E-Business Suite installato ed in esecuzione).
2. Database Oracle RAC per Oracle E-Business Suite (peer primario Oracle Data Guard).

Task 4.1.1: Passare al gruppo di protezione DR principale

Passare al gruppo di protezione DR nell'area 1, come illustrato nella figura 4.1.1.

1. Assicurati che il contesto dell'area OCI sia l'area 1 (Phoenix).
2. Selezionare il gruppo di protezione DR nell'area 1.

Figura 4.1.1: Passare al gruppo di protezione DR nell'area 1

Task 4.1.2: Aggiungi Oracle E-Business Suite Application Server 1

Per aggiungere il primo server applicazioni, aprire la finestra di dialogo Aggiungi membro.

1. Fare clic su Membri.
2. Fare clic su Aggiungi membro.

Figura 4.1.2.1: Aprire la finestra di dialogo Aggiungi membri

Selezionare Application Server 1 nell'area 1 come illustrato nella figura 4.1.2.2. Non è necessario aggiungere gruppi di volumi a blocchi o specificare proprietà di rete poiché si tratta di un'istanza non mobile.

1. Selezionare Computazione come Tipo di risorsa.
2. Scegliere il compartimento contenente gli application server di Oracle E-Business Suite e selezionare l'istanza di computazione designata come application server 1.
3. Selezionare Istanza non mobile. In questo modo OCI Full Stack DR informa che non dovrebbe tentare di avviare una virtual machine replicata nella standby region durante un'operazione di DR.
4. Fare clic su Aggiungi per aggiungere l'istanza di computazione al DRPG (non visualizzato).

Figura 4.1.2.2: Specificare i parametri per Application Server 1

Task 4.1.3: Aggiungi Oracle E-Business Suite Application Server 2

1. Fare clic su Aggiungi membro.

   
   Figura 4.1.3.1: Aprire la finestra di dialogo Aggiungi membri

Selezionare Application Server 2 nell'area 1 come illustrato nella figura 4.1.3.2. Non è necessario aggiungere gruppi di volumi a blocchi o specificare proprietà di rete poiché si tratta di un'istanza non mobile.

1. Selezionare Computazione come Tipo di risorsa.
2. Scegliere il compartimento contenente gli application server di Oracle E-Business Suite e selezionare l'istanza di computazione designata come application server 2.
3. Selezionare Istanza non mobile. In questo modo OCI Full Stack DR informa che non dovrebbe tentare di avviare una virtual machine replicata nella standby region durante un'operazione di DR.
4. Fare clic su Aggiungi per aggiungere l'istanza di computazione al DRPG (non visualizzato).

Figura 4.1.3.2: Specificare i parametri per Application Server 2

Task 4.1.4: Aggiungi Oracle Database in cluster primario

1. Fare clic su Aggiungi membro per aggiungere il database come membro.

   
   Figura 4.1.4.1: Aprire la finestra di dialogo Aggiungi membri

Selezionare il database RAC per Oracle E-Business Suite nell'area 1, come illustrato nella figura 4.1.4.2. Funziona esattamente lo stesso anche per i database a istanza singola.

1. Scegliere Database come Tipo di risorsa. Il tipo di risorsa Database consente di scegliere Oracle Base Database Service o Oracle Exadata Database Service on Dedicated Infrastructure, entrambi supportati dalla progettazione di Oracle E-Business Suite come scelte valide.
2. L'immagine di figura mostra Oracle Base Database Service, ma è anche possibile utilizzare il popolare Oracle Exadata Database Service on Dedicated Infrastructure.
3. Selezionare i valori per questi campi corrispondenti alla distribuzione. Chiedere all'amministratore del database se non si conoscono le risposte a queste selezioni.
4. Selezionare il compartimento e il segreto vault contenenti la password per il database. Avresti dovuto creare un vault e un segreto simili nell'area 2 nell'ambito del task 2.4. Questo parametro si trova nella finestra di dialogo per la compatibilità con altre API DBaaS, ma la password non viene effettivamente utilizzata.
5. Fare clic su Aggiungi per aggiungere il database come membro (non visualizzato).

Figura 4.1.4.2: Specificare i parametri per il database RAC nell'area 1

L'elenco dei membri del gruppo di protezione DR dovrebbe essere simile allo screenshot mostrato nella figura 4.1.4.3. L'elenco potrebbe avere un aspetto diverso se si aggiungono più risorse di Oracle E-Business Suite a questo specifico gruppo di protezione DR o se si aggiungono risorse di membri Oracle E-Business Suite a un gruppo di protezione DR esistente.

Figura 4.1.4.3: Lista completa dei membri necessari per Oracle E-Business Suite nell'area 1

Task 4.2: Aggiungi risorse membro a DRPG nell'area 2 (Ashburn)

Aggiungerai le risorse mostrate nella lista come membri del DRPG in standby nell'area 2.

1. I due application server Oracle E-Business Suite non mobili (Oracle E-Business Suite installato, ma non in esecuzione).
2. Database RAC per Oracle E-Business Suite (peer di standby Oracle Data Guard).

Oracle E-Business Suite richiede l'esistenza di application server in entrambe le aree in cui è installata l'applicazione. Gli application server devono essere sempre in esecuzione nella standby region con l'applicazione Oracle E-Business Suite installata, ma non in esecuzione nella standby region.

Ciò significa che gli aggiornamenti del sistema operativo e delle applicazioni, le patch e altre attività di manutenzione ordinaria devono essere eseguite in modo indipendente in entrambe le aree.

OCI Full Stack DR si riferisce a questo modello di computazione non mobile poiché le VM non vengono replicate in un'altra area e non si spostano in altre aree durante un'operazione di DR. I dispositivi di avvio per le istanze di computazione designate come computazione non mobile in OCI Full Stack DR non devono essere replicati nella standby region. Pertanto, ai gruppi di protezione DR (DRPG) non vengono aggiunti gruppi di volumi a blocchi replicati contenenti dispositivi di avvio per la computazione non mobile.

Nota: come accennato in precedenza, è insolito che Oracle E-Business Suite sia l'unica applicazione o servizio associata a una coppia di gruppi di protezione DR Full Stack OCI. Potresti anche avere altre risorse IaaS e PaaS come membri del gruppo di protezione DR nella standby region.

Task 4.2.1: Passare al gruppo di protezione DR in standby

Passare al gruppo di protezione DR nell'area 2, come illustrato nella figura 4.2.1.

1. Assicurarsi che il contesto dell'area OCI sia l'area 2 (Ashburn).
2. Selezionare il gruppo di protezione DR nell'area 2.

Figura 4.2.1: Passare al gruppo di protezione DR nell'area 2

Task 4.2.2: Aggiungi Oracle E-Business Suite Application Server 1

Aprire Aggiungi membro per aggiungere il primo server applicazioni.

1. Selezionare Membri.
2. Fare clic su Aggiungi membro.

Figura 4.2.2.1: Aprire la finestra di dialogo Aggiungi membri

Selezionare Application Server 1 nell'area 2 come illustrato nella figura 4.2.2.2. Non è necessario aggiungere gruppi di volumi a blocchi o specificare proprietà di rete poiché si tratta di un'istanza non mobile.

1. Selezionare Computazione come Tipo di risorsa.
2. Scegliere il compartimento contenente gli application server di Oracle E-Business Suite e selezionare l'istanza di computazione designata come application server 1.
3. Selezionare Istanza non mobile. In questo modo OCI Full Stack DR informa che non dovrebbe tentare di avviare una virtual machine replicata nella standby region durante un'operazione di DR.
4. Fare clic su Aggiungi per aggiungere l'istanza di computazione al DRPG (non visualizzato).

Figura 4.2.2.2: Specificare i parametri per Application Server 1

Task 4.2.3: Aggiungi Oracle E-Business Suite Application Server 2

1. Fare clic su Aggiungi membro per aggiungere il 2° server applicazioni.

   
   Figura 4.2.3.1: Aprire la finestra di dialogo Aggiungi membri

Selezionare Application Server 2 nell'area 2 come illustrato nella figura 4.2.3.2. Non è necessario aggiungere gruppi di volumi a blocchi o specificare proprietà di rete poiché si tratta di un'istanza non mobile.

1. Selezionare Computazione come Tipo di risorsa.
2. Scegliere il compartimento contenente gli application server di Oracle E-Business Suite e selezionare l'istanza di computazione designata come application server 2.
3. Selezionare Istanza non mobile. In questo modo OCI Full Stack DR informa che non dovrebbe tentare di avviare una virtual machine replicata nella standby region durante un'operazione di DR.
4. Fare clic su Aggiungi per aggiungere l'istanza di computazione al DRPG (non visualizzato).

Figura 4.2.3.2: Specificare i parametri per Application Server 2

Task 4.2.4: Aggiungi database in cluster in standby Oracle

1. Fare clic su Aggiungi membro per aggiungere il database come membro.

   
   Figura 4.2.4.1: Aprire la finestra di dialogo Aggiungi membri

Selezionare il database RAC per Oracle E-Business Suite nell'area 2, come illustrato nella figura 4.2.4.2. Funziona esattamente lo stesso anche per i database a istanza singola.

1. Scegliere Database come Tipo di risorsa. Il tipo di risorsa Database consente di scegliere Oracle Base Database Service o Oracle Exadata Database Service on Dedicated Infrastructure, entrambi supportati dalla progettazione di Oracle E-Business Suite come scelte valide.
2. La figura riportata di seguito mostra Oracle Base Database Service, ma puoi anche utilizzare il popolare Oracle Exadata Database Service on Dedicated Infrastructure.
3. Scegliere i valori per questi campi corrispondenti alla distribuzione. Chiedere all'amministratore del database se non si conoscono le risposte a queste selezioni.
4. Selezionare il compartimento e il segreto vault contenenti la password per il database. Avresti dovuto creare un vault e un segreto simili nell'area 2 nell'ambito del task 2.4. Questo parametro si trova nella finestra di dialogo per la compatibilità con altre API DBaaS, ma la password non viene effettivamente utilizzata.
5. Fare clic su Aggiungi per aggiungere il database come membro (non visualizzato).

Figura 4.2.4.2: Specificare i parametri per il database RAC nell'area 2

L'elenco dei membri del gruppo di protezione DR dovrebbe essere simile allo screenshot mostrato nella figura 4.2.4.3. L'elenco potrebbe avere un aspetto diverso se si aggiungono più risorse di Oracle E-Business Suite a questo specifico gruppo di protezione DR o se si aggiungono risorse di membri Oracle E-Business Suite a un gruppo di protezione DR esistente.

Figura 4.2.4.3: Lista completa dei membri necessari per Oracle E-Business Suite nell'area 2

Task 5: Creazione dei piani DR nell'area 2

Questa attività crea piani di switchover, failover e startdrill di base associati al gruppo di protezione DR in standby nell'area 2 (Ashburn).

Lo scopo di ogni piano è quello di trasferire il 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 DR, quindi il gruppo di protezione nell'area 1 diventerà lo standby e il gruppo di protezione nell'area 2 diventerà primario dopo un failover o uno switchover.

OCI Full Stack DR precompilerà entrambi i piani con passi integrati in base alle risorse dei membri aggiunte nei task precedenti. I piani verranno personalizzati nei passi successivi per gestire tutti i task correlati a Oracle E-Business Suite System durante un'operazione di recupero.

I piani DR vengono sempre creati nel gruppo di protezione con il ruolo standby; l'area 2 è attualmente il gruppo di protezione standby, quindi inizieremo ad Ashburn.

Creare un piano di base selezionando il DRPG nell'area 2 come mostrato nella Figura 5-1.

1. Assicurarsi che il contesto dell'area OCI sia l'area 2 (Ashburn).
2. Selezionare il DRPG in standby nell'area 2.
3. Selezionare Piani.
4. Fare clic su Crea piano per avviare il processo.

Figura 5-0: Come iniziare a creare piani DR di base nell'area 2

Task 5.1: Crea piano DR per lo switchover nell'area 2

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

1. 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 contribuire a ridurre la confusione e l'errore umano durante una crisi.
2. Selezionare Tipo di piano. Ci sono solo quattro tipi di piano al momento di questa scrittura.

Figura 5-1: Parametri necessari per creare il piano di switchover DR

Task 5.2: Crea piano DR per failover nell'area 2

Seguire lo stesso processo per creare un piano di failover di base come mostrato nella Figura 5-2.

1. Rendere il nome del piano di failover semplice ma significativo.
2. Selezionare Tipo di piano. Ci sono solo quattro tipi di piano al momento di questa scrittura.

Figura 5-2: Parametri necessari per creare il piano di failover DR

Task 5.3: Crea piano DR per avvio espansione nell'area 2

Seguire lo stesso processo per creare un piano di espansione iniziale come mostrato nella Figura 5-3.

1. Rendere il nome del piano di espansione iniziale semplice ma significativo.
2. Selezionare Tipo di piano. Ci sono solo quattro tipi di piano al momento di questa scrittura.

Figura 5-3: Parametri necessari per creare il piano startdrill DR

Il gruppo di protezione DR in standby nell'area 2 ora dovrebbe 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 5-4: Visualizzazione dei tre piani DR di base che devono esistere nell'area 2 prima di procedere ulteriormente

Nota: OCI Full Stack DR supporterà la creazione di un piano stopdrill solo dopo che il piano startdrill sarà stato eseguito correttamente. Per l'esercitazione, è fuori portata creare un piano stopdrill, ma si consiglia vivamente di creare anche un stopdrill in entrambi i gruppi di protezione DR.

Task 6: Personalizzazione dei piani DR nell'area 2 (Ashburn)

OCI Full Stack DR ha un'intelligence integrata per orchestrare il ripristino per le risorse OCI Infrastructure as a Service (IaaS) e Platform as a Service (PaaS). OCI Full Stack DR non dispone di intelligence integrata per orchestrare il recupero per Oracle E-Business Suite poiché Oracle E-Business Suite non fornisce al momento API di disaster recovery native OCI per distribuire o gestire il proprio disaster recovery integrato.

Tuttavia, OCI Full Stack DR può ancora orchestrare il ripristino per Oracle E-Business Suite aggiungendo gruppi di piani DR definiti dall'utente e passi ai piani DR di base creati nell'ambito del task 5. I passi definiti dall'utente richiamano gli script di Oracle E-Business Suite scaricati e installati nei server applicazioni Oracle E-Business Suite in entrambe le aree o nel nodo di controllo DR dedicato nell'ambito del task 2.3. Di seguito sono riportati i gruppi di piani definiti dall'utente ad alto livello. I gruppi di piani da aggiungere variano a seconda dei tipi di piano DR.

1. Chiudere Oracle E-Business Suite e disabilitare i job rsync in node2 nell'area 1.
2. Chiudere Oracle E-Business SuiteS e disabilitare i job rsync in node1 nell'area 1.
3. Cancellare i nomi dei nodi nelle tabelle FND del database nell'area 2.
4. Imposta il contesto dell'applicazione nel database su node1 nell'area 2.
5. Imposta il contesto dell'applicazione nel database su node2 nell'area 2.
6. Eseguire autoconfig su node1 nell'area 2.
7. Eseguire autoconfig su node2 nell'area 2.
8. Avviare Oracle E-Business Suite e abilitare i job rsync su node1 nell'area 2.
9. Avviare Oracle E-Business Suite e abilitare i job rsync su node2 nell'area 2.

Task 6.1: Selezionare il piano di switchover

Iniziare passando al piano di switchover creato nel task 5.

Figura 6.1: Selezionare il piano di switchover nell'area 2

OCI Full Stack DR genererà i gruppi di piani Prechecks-Built in e Databases-Switchover, che sono stati generati in base ai membri aggiunti ai gruppi di protezione DR nell'area 1 e nell'area 2.

Figura 6.1.1: Gruppi di piani predefiniti per il piano di switchover nell'area 2

Task 6.2: Creare un gruppo di piani per chiudere Oracle E-Business Suite e disabilitare i job di sincronizzazione sul nodo 2 nell'area 1

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

Il primo gruppo di piani definito dall'utente chiuderà Oracle E-Business Suite e disabiliterà i job rsync in node2 nell'area 1. Questo gruppo di piani conterrà due passi che richiamano gli script bash shutdownapps.sh e fsdr-rsync-ebs.sh scaricati nei nodi del server applicazioni Oracle E-Business Suite nel task 2.3.

Task 6.2.1: Seleziona Aggiungi gruppo di piani

Avviare il processo per aggiungere un gruppo di piani.

1. Fare clic su Aggiungi gruppo per iniziare.

   
   Figura 6-2.1: Iniziare ad aggiungere un gruppo di piani per chiudere Oracle E-Business Suite e disabilitare i job rsync su node2

Task 6.2.2: Fornire il nome del gruppo di piani, ordinare e aggiungere il passo

Un gruppo di piani DR può contenere molti passi che vengono tutti eseguiti in parallelo. Verranno aggiunti due passi per eseguire script bash per arrestare Oracle E-Business Suite su node2 e disabilitare i job cron rsync su node2 nell'area 1. Nel nostro esempio il nome node2 è ebshaapp02phx.

1. Assegnare al gruppo di piani un nome semplice ma descrittivo.
2. 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 aggiungere prima il gruppo di piani Switchover database.
3. Selezionare il gruppo di piani Database - Switchover built-in.
4. Aggiungeremo due passi. Il primo passo consiste nell'arresto di Oracle E-Business Suite nel nodo 2 e il secondo script consiste nel disabilitare i job rsync nel nodo 2.
5. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per arrestare Oracle E-Business Suite su node2.

Figura 6.2.2: Gruppo di piani per arrestare Oracle E-Business Suite e arrestare i job rsync

Task 6.2.3: Fornire i nomi dei passi e i parametri degli script locali

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi all'esecuzione di questo passo e al relativo comportamento durante il recupero. In questo gruppo di piani verranno aggiunti due passi.

• Il Passo 1 consiste nell'arresto dell'applicazione Oracle E-Business Suite su node2.
• Passo 2: consente di disabilitare i job rysnc in node2.

Per questa impostazione, il nodo 2 è ebshaapp02phx

Spiegheremo tutti i campi di questa finestra di dialogo, ma lasceremo fuori questo dettaglio in tutte le schermate rimanenti nei passaggi successivi poiché stiamo eseguendo lo stesso processo ripetutamente.

1. Nome descrittivo che spiega il task eseguito da questo passo.

2. Seleziona la Regione 1, quindi nel nostro caso è Phoenix..

3. Selezionare Esegui script locale.

4. Selezionare il compartimento corretto contenente l'applicazione Oracle E-Business Suite node2 e selezionare il nodo 2, nel nostro caso è ebshaapp02phx.

5. Incollare il percorso assoluto in cui è stato installato lo script shutdownapps.sh nell'app node2 di Oracle E-Business Suite con i parametri corretti. È possibile fare riferimento ai dettagli del file readme dal collegamento GitHub fornito nel task 2.3 per la sintassi esatta.

6. Specificare oracle come utente per eseguire lo script.

7. Il piano DR deve essere interrotto se lo script non riesce ad arrestare l'app Oracle E-Business Suite su node2. 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.

8. Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di 60 minuti (3600 secondi). Questo valore può essere modificato in 1800 secondi o qualsiasi valore ritenuto più realistico di timeout.

9. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

   
   Figura 6.2.3.1: Parametri per creare il passo del piano per arrestare Oracle E-Business Suite sul nodo 2

10. Verrà visualizzato come di seguito una volta aggiunto il passo 1.

    
    Figura 6.2.3.2: viene aggiunta l'interruzione di Oracle E-Business Suite nel nodo 2

11. Fare clic su Aggiungi passo per aggiungere il secondo passo al gruppo di piani.

12. Nome descrittivo che spiega il task eseguito da questo passo.

13. Seleziona la Regione 1, quindi nel nostro caso è Phoenix.

14. Selezionare Esegui script locale.

15. Selezionare il compartimento corretto contenente l'applicazione Oracle E-Business Suite node2 e selezionare il nodo 2, nel nostro caso è ebshaapp02phx.

16. Incollare il percorso assoluto in cui è stato installato lo script fsdr-rsync-ebs.sh nell'app node2 di Oracle E-Business Suite con i parametri corretti. È possibile fare riferimento ai dettagli del file readme dal collegamento GitHub fornito nel task 2.3 per la sintassi esatta.

17. Specificare oracle come utente per eseguire lo script.

18. Il piano DR dovrebbe essere interrotto se lo script non riesce a disabilitare i job rsync su node2. 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.

19. Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di 60 minuti (3600 secondi). Questo valore può essere modificato in 300 secondi o qualsiasi valore ritenuto più realistico di timeout.

20. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

    
    Figura 6.2.3.1: Parametri per la creazione del passo del piano per disabilitare i job Rysnc nel nodo 2

21. Verrà visualizzato come sotto una volta aggiunto il passaggio 2.

    
    Figura 6.2.3.2: viene aggiunta la disabilitazione dei job rysnc nel nodo 2

Task 6.2.4: Completa aggiunta gruppo piano e passi

Al gruppo di piani DR vengono aggiunti sia l'applicazione di arresto di Oracle E-Business Suite che i job di disabilitazione rsync su node2.

1. Fare clic su Aggiungi per aggiungere il gruppo di piani DR e i passi al piano DR.

   
   Figura 6.2.4.1: Finalizzare l'aggiunta del gruppo di piani e dei passi per arrestare Oracle E-Business Suite e disabilitare il job rsync su node1

2. Verificare che il gruppo di piani aggiunto sia disponibile nel piano di switchover.

   
   Figura 6.2.4.1: Arrestare Oracle E-Business Suite e disabilitare il job rsync sul gruppo di piani node1 aggiunto

Task 6.3: Creare un gruppo di piani per chiudere Oracle E-Business Suite e disabilitare i job di sincronizzazione sul nodo 1 nell'area 1

Ora aggiungiamo il prossimo gruppo di piani definito dall'utente.

Questo gruppo di piani definito dall'utente chiuderà Oracle E-Business Suite e disabiliterà i job rsync su node1 nell'area 1. Questo gruppo di piani conterrà due passi che richiamano gli script bash shutdownapps.sh e fsdr-rsync-ebs.sh scaricati nei nodi del server applicazioni Oracle E-Business Suite nel task 2.3.

Task 6.3.1: Seleziona Aggiungi gruppo di piani

Avviare il processo per aggiungere un gruppo di piani.

1. Fare clic su Aggiungi gruppo per iniziare.

   
   Figura 6-3.1: Iniziare ad aggiungere un gruppo di piani per chiudere Oracle E-Business Suite e disabilitare i job rsync su node1

Task 6.3.2: Fornire il nome del gruppo di piani, ordinare e aggiungere il passo

Un gruppo di piani DR può contenere molti passi che vengono tutti eseguiti in parallelo. Verranno aggiunti due passi per eseguire script bash per arrestare Oracle E-Business Suite su node1 e disabilitare i job cron rsync su node1 nell'area 1. Nel nostro esempio il nome node1 è ebshaapp01phx.

1. Assegnare al gruppo di piani un nome semplice ma descrittivo.
2. Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, inseriremo il gruppo di piani definito dall'utente aggiungi dopo il gruppo di piani Chiudi EBS su node2 in PHX.
3. Selezionare il gruppo di piani Chiudi EBS in node2 in PHX definito dall'utente.
4. Aggiungeremo due passi. Il primo passo consiste nell'arresto di Oracle E-Business Suite nel nodo 1 e il secondo script consiste nel disabilitare i job rsync nel nodo 1.
5. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per arrestare Oracle E-Business Suite su node2.

Figura 6.3.2: Gruppo di piani per arrestare Oracle E-Business Suite e arrestare i job rsync

Task 6.3.3: Fornire i nomi dei passi e i parametri degli script locali

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi all'esecuzione di questo passo e al relativo comportamento durante il recupero. In questo gruppo di piani verranno aggiunti due passi.

• Il Passo 1 consiste nell'arresto dell'applicazione Oracle E-Business Suite su node1.
• Il punto 2 consente di disabilitare i job rysnc in node1.

Per questa impostazione, il nodo 1 è ebshaapp01phx

Spiegheremo tutti i campi di questa finestra di dialogo, ma lasceremo fuori questo dettaglio in tutte le schermate rimanenti nei passaggi successivi poiché stiamo eseguendo lo stesso processo ripetutamente.

1. Nome descrittivo che spiega il task eseguito da questo passo.

2. Selezionare il tipo definito dall'utente Esegui script locale.

3. Seleziona la Regione 1, quindi nel nostro caso è Phoenix.

4. Selezionare il compartimento corretto contenente l'applicazione Oracle E-Business Suite node1 e selezionare il nodo 1, nel nostro caso è ebshaapp01phx.

5. Incollare il percorso assoluto in cui è stato installato lo script shutdownapps.sh nell'app node2 di Oracle E-Business Suite con i parametri corretti. È possibile fare riferimento ai dettagli del file readme dal collegamento GitHub fornito nel task 2.3 per la sintassi esatta.

6. Specificare oracle come utente per eseguire lo script.

7. Il piano DR deve essere interrotto se lo script non riesce ad arrestare l'app Oracle E-Business Suite su node1. 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.

8. Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di 60 minuti (3600 secondi). Questo valore può essere modificato in 1800 secondi o qualsiasi valore ritenuto più realistico di timeout.

9. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

   
   Figura 6.3.3.1: Parametri per creare il passo del piano per arrestare Oracle E-Business Suite sul nodo 1

10. Verrà visualizzato come di seguito una volta aggiunto il passo 1.

    
    Figura 6.3.3.2: viene aggiunta l'interruzione di Oracle E-Business Suite nel nodo 1

11. Fare clic su Aggiungi passo per aggiungere il secondo passo al gruppo di piani.

12. Nome descrittivo che spiega il task eseguito da questo passo.

13. Seleziona la Regione 1, quindi nel nostro caso è Phoenix.

14. Selezionare Esegui script locale.

15. Selezionare il compartimento corretto contenente l'applicazione Oracle E-Business Suite node1 e selezionare il nodo 1, nel nostro caso è ebshaapp02phx.

16. Incollare il percorso assoluto in cui è stato installato lo script fsdr-rsync-ebs.sh nell'app node2 di Oracle E-Business Suite con i parametri corretti. È possibile fare riferimento ai dettagli del file readme dal collegamento GitHub fornito nel task 2.3 per la sintassi esatta.

17. Specificare oracle come utente per eseguire lo script.

18. Il piano DR dovrebbe essere interrotto se lo script non riesce a disabilitare i job rsync su node1. 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.

19. Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di 60 minuti (3600 secondi). Questo valore può essere modificato in 300 secondi o qualsiasi valore ritenuto più realistico di timeout.

20. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

    
    Figura 6.3.3.1: Parametri per la creazione del passo del piano per disabilitare i job Rysnc nel nodo 1

21. Verrà visualizzato come sotto una volta aggiunto il passaggio 2.

    
    Figura 6.3.3.2: viene aggiunta la disabilitazione dei job rysnc nel nodo 1

Task 6.3.4: Completa aggiunta gruppo piano e passi

Al gruppo di piani DR vengono aggiunti sia l'applicazione di arresto di Oracle E-Business Suite che i job di disabilitazione rsync su node2.

1. Fare clic su Aggiungi per aggiungere il gruppo di piani DR e i passi al piano DR.

   
   Figura 6.3.4.1: Finalizzare l'aggiunta del gruppo di piani e dei passi per arrestare Oracle E-Business Suite e disabilitare il job rsync su node1

2. Verificare che il gruppo di piani aggiunto sia disponibile nel piano di switchover.

   
   Figura 6.3.4.1: Arrestare Oracle E-Business Suite e disabilitare il job rsync sul gruppo di piani node1 aggiunto

Task 6.4: Creare un gruppo di piani per cancellare i nomi dei nodi nelle tabelle fnd del database nell'area 2

Ora aggiungiamo il prossimo gruppo di piani definito dall'utente.

Questo gruppo di piani definito dall'utente cancellerà i nomi dei nodi nelle tabelle fnd del database nell'area 2. Questo gruppo di piani conterrà un passo che chiama lo script bash fndnodeclean.sh scaricato nei nodi dell'app server Oracle E-Business Suite nel task 2.3.

Task 6.4.1: Selezionare Aggiungi gruppo di piani

Avviare il processo per aggiungere un gruppo di piani.

1. Fare clic su Aggiungi gruppo per iniziare.

   
   Figura 6.4.1: Iniziare ad aggiungere un gruppo di piani per chiudere Oracle E-Business Suite e disabilitare i job rsync su node1

Task 6.4.2: Fornire il nome del gruppo di piani, ordinare e aggiungere il passo

Si aggiungerà uno script bash per cancellare i nomi dei nodi nelle tabelle fnd del database in node1 nell'area 1. Nel nostro esempio il nome node1 è ebshaapp01iad.

1. Assegnare al gruppo di piani un nome semplice ma descrittivo.
2. 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 aggiungere dopo il gruppo di piani Database - Switchover.
3. Selezionare il gruppo di piani Database - Switchover built-in.
4. Verrà aggiunto un passo per cancellare i nomi dei nodi nelle tabelle FND del database.
5. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per cancellare i nomi dei nodi nelle tabelle fnd del database.

Figura 6.4.2: Gruppo di piani per cancellare i nomi dei nodi nelle tabelle FND del database.

Task 6.4.3: Fornire i nomi dei passi e i parametri degli script locali

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi all'esecuzione di questo passo e al relativo comportamento durante il recupero. Aggiungeremo un singolo in questo gruppo di piani.

• Step consente di eseguire fndnodeclean su node1.

Per questa impostazione, il nodo 1 è ebshaapp01iad

Spiegheremo tutti i campi di questa finestra di dialogo, ma lasceremo fuori questo dettaglio in tutte le schermate rimanenti nei passaggi successivi poiché stiamo eseguendo lo stesso processo ripetutamente.

1. Nome descrittivo che spiega il task eseguito da questo passo.

2. Selezionare il tipo definito dall'utente Esegui script locale.

3. Selezionare l'area 2, quindi nel nostro caso è Ashburn.

4. Selezionare il compartimento corretto contenente l'applicazione Oracle E-Business Suite node1 e selezionare il nodo 1, nel nostro caso è ebshaapp01iad.

5. Incollare il percorso assoluto in cui è stato installato lo script fndnodeclean.sh nell'app node1 di Oracle E-Business Suite con i parametri corretti. È possibile fare riferimento ai dettagli del file readme dal collegamento GitHub fornito nel task 2.3 per la sintassi esatta.

6. Specificare oracle come utente per eseguire lo script.

7. Il piano DR deve essere interrotto se lo script non riesce ad arrestare l'app Oracle E-Business Suite su node1. 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.

8. Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di 60 minuti (3600 secondi). Questo valore può essere modificato in 900 secondi o qualsiasi valore ritenuto più realistico di timeout.

9. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

   
   Figura 6.4.3.1: Parametri per creare il passo del piano per cancellare i nomi dei nodi nelle tabelle FND del database

10. Verrà visualizzato come di seguito una volta aggiunto il passo 1.

    
    Figura 6.4.3.2: Cancellare i nomi dei nodi nelle tabelle FND del database

Task 6.4.4: Completa aggiunta gruppo piano e passi

Il passo per cancellare i nomi dei nodi nelle tabelle FND del database viene aggiunto al gruppo di piani DR.

1. Fare clic su Aggiungi per aggiungere il gruppo di piani DR e i passi al piano DR.

   
   Figura 6.4.4.1: Finalizzare l'aggiunta del gruppo di piani e del passo per cancellare i nomi dei nodi nelle tabelle FND del database

2. Verificare che il gruppo di piani aggiunto sia disponibile nel piano di switchover.

   
   Figura 6.4.4.2: per cancellare i nomi dei nodi nelle tabelle FND del database nel gruppo di piani node1 aggiunto

Task 6.5: Creare un gruppo di piani per impostare il contesto applicazione nel database in node1 nell'area 2

Ora aggiungiamo il prossimo gruppo di piani definito dall'utente.

Questo gruppo di piani definito dall'utente imposterà il contesto dell'applicazione nel database in node1 nell'area 2. Questo gruppo di piani conterrà un passo che chiama lo script bash dbtxkconfig.sh scaricato nei nodi dell'app server Oracle E-Business Suite nel task 2.3.

Task 6.5.1: Seleziona Aggiungi gruppo di piani

Avviare il processo per aggiungere un gruppo di piani.

1. Fare clic su Aggiungi gruppo per iniziare.

   
   Figura 6.5.1: Iniziare ad aggiungere un gruppo di piani per impostare il contesto dell'applicazione nel database su node1

Task 6.5.2: Fornire il nome del gruppo di piani, ordinare e aggiungere il passo

Aggiungeremo un passo per eseguire lo script bash per impostare il contesto dell'applicazione nel database su node1 nell'area 2. Nel nostro esempio il nome node1 è ebshaapp01iad.

1. Assegnare al gruppo di piani un nome semplice ma descrittivo.
2. Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, inseriremo il gruppo di piani definito dall'utente aggiungere dopo il gruppo di piani Cancella nomi nodo nelle tabelle FND del database in IAD.
3. Selezionare il gruppo di piani Cancella nomi nodo nelle tabelle FND del database in IAD built-in.
4. Verrà aggiunto un passo per impostare il contesto dell'applicazione nel database su node1.
5. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per impostare il contesto dell'applicazione nel database in node1.

Figura 6.5.2: Gruppo di piani per la configurazione del contesto dell'applicazione nel database in node1

Task 6.5.3: Fornire i nomi dei passi e i parametri degli script locali

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi all'esecuzione di questo passo e al relativo comportamento durante il recupero. Aggiungeremo un singolo in questo gruppo di piani.

• Il punto consente di eseguire dbtxkconfig su node1 (modificare i nomi host fisici).

Per questa impostazione, il nodo 1 è ebshaapp01iad

Spiegheremo tutti i campi di questa finestra di dialogo, ma lasceremo fuori questo dettaglio in tutte le schermate rimanenti nei passaggi successivi poiché stiamo eseguendo lo stesso processo ripetutamente.

1. Nome descrittivo che spiega il task eseguito da questo passo.

2. Selezionare il tipo definito dall'utente Esegui script locale.

3. Selezionare l'area 2, quindi nel nostro caso è Ashburn.

4. Selezionare il compartimento corretto contenente l'applicazione Oracle E-Business Suite node1 e selezionare il nodo 1, nel nostro caso è ebshaapp01iad.

5. Incollare il percorso assoluto in cui è stato installato lo script dbtxkconfig.sh nell'app node1 di Oracle E-Business Suite con i parametri corretti. È possibile fare riferimento ai dettagli del file readme dal collegamento GitHub fornito nel task 2.3 per la sintassi esatta. Fornire tutti i dettagli con i parametri giusti è estremamente importante.

6. Specificare oracle come utente per eseguire lo script.

7. Il piano DR dovrebbe arrestarsi se lo script non riesce a impostare il contesto dell'applicazione nel database node1. 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.

8. Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di 60 minuti (3600 secondi). Questo valore può essere modificato in 900 secondi o qualsiasi valore ritenuto più realistico di timeout.

9. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

   
   Figura 6.5.3.1: Parametri per creare il passo del piano per impostare il contesto dell'applicazione nel database node1

10. Verrà visualizzato come di seguito una volta aggiunto il passo 1.

    
    Figura 6.5.3.2: Per impostare il contesto dell'applicazione nel database node1

Task 6.5.4: Completa aggiunta gruppo piano e passi

Il passo per impostare il contesto dell'applicazione nel database node1 viene aggiunto al gruppo di piani DR.

1. Fare clic su Aggiungi per aggiungere il gruppo di piani DR e i passi al piano DR.

   
   Figura 6.5.4.1: Finalizzare l'aggiunta del gruppo di piani e del passo per impostare il contesto dell'applicazione nel database node1

2. Verificare che il gruppo di piani aggiunto sia disponibile nel piano di switchover.

   
   Figura 6.5.4.2: Per impostare il contesto dell'applicazione nel gruppo di piani node1 del database aggiunto

Task 6.6: Creare un gruppo di piani per impostare il contesto dell'applicazione nel database in node2 nell'area 2

Ora aggiungiamo il prossimo gruppo di piani definito dall'utente.

Questo gruppo di piani definito dall'utente imposterà il contesto dell'applicazione nel database in node2 nell'area 2. Questo gruppo di piani conterrà un passo che chiama lo script bash dbtxkconfig.sh scaricato nei nodi dell'app server Oracle E-Business Suite nel task 2.3.

Task 6.6.1: Seleziona Aggiungi gruppo di piani

Avviare il processo per aggiungere un gruppo di piani.

1. Fare clic su Aggiungi gruppo per iniziare.

   
   Figura 6.6.1: Iniziare ad aggiungere un gruppo di piani per impostare il contesto dell'applicazione nel database su node2

Task 6.6.2: Fornire il nome del gruppo di piani, ordinare e aggiungere il passo

Aggiungeremo un passo per eseguire lo script bash per impostare il contesto dell'applicazione nel database su node2 nell'area 2. Nel nostro esempio il nome node2 è ebshaapp02iad.

1. Assegnare al gruppo di piani un nome semplice ma descrittivo.
2. 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 aggiungere dopo il contesto dell'applicazione di configurazione nel database in node1 nel gruppo di piani IAD.
3. Selezionare il contesto dell'applicazione built-in Imposta nel database in node1 nel gruppo di piani IAD.
4. Verrà aggiunto un passo per impostare il contesto dell'applicazione nel database su node2.
5. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per impostare il contesto dell'applicazione nel database in node1.

Figura 6.6.2: Gruppo di piani per impostare il contesto dell'applicazione nel database su node2

Task 6.6.3: Fornire i nomi dei passi e i parametri degli script locali

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi all'esecuzione di questo passo e al relativo comportamento durante il recupero. Aggiungeremo un singolo in questo gruppo di piani.

• Il punto consente di eseguire dbtxkconfig su node2 (modificare i nomi host fisici).

Per questa impostazione, il nodo 2 è ebshaapp02iad

Spiegheremo tutti i campi di questa finestra di dialogo, ma lasceremo fuori questo dettaglio in tutte le schermate rimanenti nei passaggi successivi poiché stiamo eseguendo lo stesso processo ripetutamente.

1. Nome descrittivo che spiega il task eseguito da questo passo.

2. Selezionare il tipo definito dall'utente Esegui script locale.

3. Selezionare l'area 2, quindi nel nostro caso è Ashburn.

4. Selezionare il compartimento corretto contenente l'applicazione Oracle E-Business Suite node1 e selezionare il nodo 1, nel nostro caso è ebshaapp02iad.

5. Incollare il percorso assoluto in cui è stato installato lo script dbtxkconfig.sh nell'app node1 di Oracle E-Business Suite con i parametri corretti. È possibile fare riferimento ai dettagli del file readme dal collegamento GitHub fornito nel task 2.3 per la sintassi esatta. Fornire tutti i dettagli con i parametri giusti è estremamente importante.

6. Specificare oracle come utente per eseguire lo script.

7. Il piano DR dovrebbe arrestarsi se lo script non riesce a impostare il contesto dell'applicazione nel database node2. 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.

8. Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di 60 minuti (3600 secondi). Questo valore può essere modificato in 900 secondi o qualsiasi valore ritenuto più realistico di timeout.

9. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

   
   Figura 6.6.3.1: Parametri per creare il passo del piano per impostare il contesto dell'applicazione nel database node2

10. Verrà visualizzato come di seguito una volta aggiunto il passo 1.

    
    Figura 6.6.3.2: Per impostare il contesto dell'applicazione nel database node2

Task 6.6.4: Completa aggiunta gruppo di piani e passi

Il passo per impostare il contesto dell'applicazione nel database node1 viene aggiunto al gruppo di piani DR.

1. Fare clic su Aggiungi per aggiungere il gruppo di piani DR e i passi al piano DR.

   
   Figura 6.6.4.1: Finalizzare l'aggiunta del gruppo di piani e del passo per impostare il contesto dell'applicazione nel database node2

2. Verificare che il gruppo di piani aggiunto sia disponibile nel piano di switchover.

   
   Figura 6.6.4.2: Per impostare il contesto dell'applicazione nel gruppo di piani node2 del database aggiunto

Task 6.7: Crea gruppo di piani per eseguire autoconfig nell'applicazione node1 nell'area 2

Ora aggiungiamo il prossimo gruppo di piani definito dall'utente.

Questo gruppo di piani definito dall'utente eseguirà autoconfig nell'app node1 nell'area 2. Questo gruppo di piani conterrà un passo che chiama lo script bash autoconfigapps.sh scaricato nei nodi dell'app server Oracle E-Business Suite nel task 2.3.

Task 6.7.1: Seleziona Aggiungi gruppo di piani

Avviare il processo per aggiungere un gruppo di piani.

1. Fare clic su Aggiungi gruppo per iniziare.

   
   Figura 6.7.1: Inizia ad aggiungere un gruppo di piani per eseguire autoconfig su app node1

Task 6.7.2: Fornire il nome del gruppo di piani, ordinare e aggiungere il passo

Aggiungeremo un passo per eseguire lo script bash per eseguire autoconfig sull'applicazione node1 nell'area 2. Nel nostro esempio il nome node1 è ebshaapp01iad.

1. Assegnare al gruppo di piani un nome semplice ma descrittivo.
2. 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 aggiungere dopo il contesto dell'applicazione di configurazione nel database in node2 nel gruppo di piani IAD.
3. Selezionare il contesto dell'applicazione built-in Imposta nel database in node2 nel gruppo di piani IAD.
4. Verrà aggiunto un passo per impostare il contesto dell'applicazione nel database su node2.
5. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per eseguire autoconfig nell'applicazione node1.

Figura 6.7.2: Gruppo di piani per eseguire autoconfig su app node1

Task 6.7.3: Fornire i nomi dei passi e i parametri degli script locali

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi all'esecuzione di questo passo e al relativo comportamento durante il recupero. Aggiungeremo un singolo in questo gruppo di piani.

• Step consente di eseguire autoconfig su node1.

Per questa impostazione, il nodo 1 è ebshaapp01iad

Spiegheremo tutti i campi di questa finestra di dialogo, ma lasceremo fuori questo dettaglio in tutte le schermate rimanenti nei passaggi successivi poiché stiamo eseguendo lo stesso processo ripetutamente.

1. Nome descrittivo che spiega il task eseguito da questo passo.

2. Selezionare il tipo definito dall'utente Esegui script locale.

3. Selezionare l'area 2, quindi nel nostro caso è Ashburn.

4. Selezionare il compartimento corretto contenente l'applicazione Oracle E-Business Suite node1 e selezionare il nodo 1, nel nostro caso è ebshaapp01iad.

5. Incollare il percorso assoluto in cui è stato installato lo script autoconfigapps.sh nell'app node1 di Oracle E-Business Suite con i parametri corretti. È possibile fare riferimento ai dettagli del file readme dal collegamento GitHub fornito nel task 2.3 per la sintassi esatta. Fornire tutti i dettagli con i parametri giusti è estremamente importante.

6. Specificare oracle come utente per eseguire lo script.

7. Il piano DR deve essere interrotto se lo script non riesce a eseguire autoconfig sull'app node1. 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.

8. Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di 60 minuti (3600 secondi). Questo valore può essere modificato in 900 secondi o qualsiasi valore ritenuto più realistico di timeout.

9. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

   
   Figura 6.7.3.1: Parametri che consentono di creare il passo del piano per eseguire la configurazione automatica nell'applicazione node1

10. Verrà visualizzato come di seguito una volta aggiunto il passo 1.

    
    Figura 6.7.3.2: Per eseguire autoconfig su app node1

Task 6.7.4: Completa aggiunta gruppo piano e passi

Il passo per eseguire autoconfig nell'applicazione node1 viene aggiunto al gruppo di piani DR.

1. Fare clic su Aggiungi per aggiungere il gruppo di piani DR e i passi al piano DR.

   
   Figura 6.7.4.1: Finalizzare l'aggiunta del gruppo di piani e del passo per eseguire autoconfig su app node1

2. Verificare che il gruppo di piani aggiunto sia disponibile nel piano di switchover.

   
   Figura 6.7.4.2: Per eseguire autoconfig sul gruppo di piani node1 dell'applicazione aggiunto

Task 6.8: Crea gruppo di piani per eseguire autoconfig nell'applicazione node2 nell'area 2

Ora aggiungiamo il prossimo gruppo di piani definito dall'utente.

Questo gruppo di piani definito dall'utente eseguirà autoconfig nell'app node2 nell'area 2. Questo gruppo di piani conterrà un passo che chiama lo script bash autoconfigapps.sh scaricato nei nodi dell'app server Oracle E-Business Suite nel task 2.3.

Task 6.8.1: Seleziona Aggiungi gruppo di piani

Avviare il processo per aggiungere un gruppo di piani.

1. Fare clic su Aggiungi gruppo per iniziare.

   
   Figura 6.8.1: Inizia ad aggiungere un gruppo di piani per eseguire autoconfig su app node2

Task 6.8.2: Fornire il nome del gruppo di piani, ordinare e aggiungere il passo

Aggiungeremo un passo per eseguire lo script bash per eseguire autoconfig nell'app node2 nell'area 2. Nel nostro esempio il nome node2 è ebshaapp02iad.

1. Assegnare al gruppo di piani un nome semplice ma descrittivo.
2. Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, inseriremo il gruppo di piani definito dall'utente aggiungi dopo il gruppo di piani Esegui autoconfig su app node1 in IAD.
3. Selezionare il gruppo di piani Esegui autoconfig nell'applicazione node1 in IAD integrato.
4. Verrà aggiunto un passo per impostare il contesto dell'applicazione nel database su node2.
5. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per eseguire autoconfig nell'applicazione node2.

Figura 6.8.2: Gruppo di piani per eseguire autoconfig su app node2

Task 6.8.3: Fornire i nomi dei passi e i parametri degli script locali

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi all'esecuzione di questo passo e al relativo comportamento durante il recupero. Aggiungeremo un singolo in questo gruppo di piani.

• Step consente di eseguire autoconfig su node2.

Per questa impostazione, il nodo 1 è ebshaapp02iad

Spiegheremo tutti i campi di questa finestra di dialogo, ma lasceremo fuori questo dettaglio in tutte le schermate rimanenti nei passaggi successivi poiché stiamo eseguendo lo stesso processo ripetutamente.

1. Nome descrittivo che spiega il task eseguito da questo passo.

2. Selezionare il tipo definito dall'utente Esegui script locale.

3. Selezionare l'area 2, quindi nel nostro caso è Ashburn.

4. Selezionare il compartimento corretto contenente l'applicazione Oracle E-Business Suite node2 e selezionare il nodo 2, nel nostro caso è ebshaapp02iad.

5. Incollare il percorso assoluto in cui è stato installato lo script autoconfigapps.sh nell'app node1 di Oracle E-Business Suite con i parametri corretti. È possibile fare riferimento ai dettagli del file readme dal collegamento GitHub fornito nel task 2.3 per la sintassi esatta. Fornire tutti i dettagli con i parametri giusti è estremamente importante.

6. Specificare oracle come utente per eseguire lo script.

7. Il piano DR dovrebbe arrestarsi se lo script non riesce ad eseguire autoconfig sull'app node2. 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.

8. Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di 60 minuti (3600 secondi). Questo valore può essere modificato in 900 secondi o qualsiasi valore ritenuto più realistico di timeout.

9. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

   
   Figura 6.8.3.1: Parametri che consentono di creare il passo del piano per eseguire la configurazione automatica nell'applicazione node2

10. Verrà visualizzato come di seguito una volta aggiunto il passo 1.

    
    Figura 6.8.3.2: Per eseguire autoconfig su app node2

Task 6.8.4: Completa aggiunta gruppo piano e passi

Il passo per eseguire autoconfig nell'applicazione node2 viene aggiunto al gruppo di piani DR.

1. Fare clic su Aggiungi per aggiungere il gruppo di piani DR e i passi al piano DR.

   
   Figura 6.8.4.1: Finalizzare l'aggiunta del gruppo di piani e del passo per eseguire autoconfig su app node2

2. Verificare che il gruppo di piani aggiunto sia disponibile nel piano di switchover.

   
   Figura 6.8.4.2: Per eseguire autoconfig sul gruppo di piani node2 dell'applicazione aggiunto

Task 6.9: Creare un gruppo di piani per avviare Oracle E-Business Suite e abilitare i job di sincronizzazione nel nodo 1 nell'area 2

Ora aggiungiamo il prossimo gruppo di piani definito dall'utente.

Questo gruppo di piani definito dall'utente avvierà Oracle E-Business Suite e abiliterà i job rsync su node1 nell'area 2. Questo gruppo di piani conterrà due passi che richiamano gli script bash startapps.sh e fsdr-rsync-ebs.sh scaricati nei nodi del server applicazioni Oracle E-Business Suite nel task 2.3.

Task 6.9.1: Seleziona Aggiungi gruppo di piani

Avviare il processo per aggiungere un gruppo di piani.

1. Fare clic su Aggiungi gruppo per iniziare.

   
   Figura 6-9.1: Iniziare ad aggiungere un gruppo di piani all'avvio di Oracle E-Business Suite e abilitare i job rsync su node1

Task 6.9.2: Fornire il nome del gruppo di piani, ordinare e aggiungere il passo

Un gruppo di piani DR può contenere molti passi che vengono tutti eseguiti in parallelo. Si aggiungeranno due passaggi per eseguire script bash per avviare Oracle E-Business Suite su node1 e abilitare i job cron rsync su node1 nell'area 2. Nel nostro esempio il nome node1 è ebshaapp01iad.

1. Assegnare al gruppo di piani un nome semplice ma descrittivo.
2. Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, inseriremo il gruppo di piani definito dall'utente aggiungi dopo il gruppo di piani Esegui autoconfig su app node2 in IAD.
3. Selezionare il gruppo di piani Esegui autoconfig nell'applicazione node2 in IAD definito dall'utente.
4. Aggiungeremo due passi. Il primo passo consiste nell'avviare Oracle E-Business Suite nel nodo 1 e il secondo script consiste nell'abilitare i job rsync nel nodo 1.
5. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per avviare Oracle E-Business Suite su node2.

Figura 6.9.2: Gruppo di piani per l'avvio di ebs e l'abilitazione dei job rsync su node1

Task 6.9.3: Fornire i nomi dei passi e i parametri degli script locali

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi all'esecuzione di questo passo e al relativo comportamento durante il recupero. In questo gruppo di piani verranno aggiunti due passi.

• Passo 1: avviare l'applicazione Oracle E-Business Suite su node1.
• Il punto 2 consente di abilitare i job rysnc in node1.

Per questa impostazione, il nodo 1 è ebshaapp01iad.

Spiegheremo tutti i campi di questa finestra di dialogo, ma lasceremo fuori questo dettaglio in tutte le schermate rimanenti nei passaggi successivi poiché stiamo eseguendo lo stesso processo ripetutamente.

1. Nome descrittivo che spiega il task eseguito da questo passo.

2. Selezionare il tipo definito dall'utente Esegui script locale.

3. Seleziona la Regione 2, quindi nel nostro caso è Ashburn.

4. Selezionare il compartimento corretto contenente l'applicazione Oracle E-Business Suite node1 e selezionare il nodo 1, nel nostro caso è ebshaapp01iad.

5. Incollare il percorso assoluto in cui è stato installato lo script startapps.sh nell'app node1 di Oracle E-Business Suite con i parametri corretti. È possibile fare riferimento ai dettagli del file readme dal collegamento GitHub fornito nel task 2.3 per la sintassi esatta.

6. Specificare oracle come utente per eseguire lo script.

7. Il piano DR deve essere interrotto se lo script non riesce ad avviare l'app Oracle E-Business Suite su node1. 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.

8. Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di 60 minuti (3600 secondi). Questo valore può essere modificato in 1800 secondi o qualsiasi valore ritenuto più realistico di timeout.

9. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

   
   Figura 6.9.3.1: Parametri per creare il passo del piano per avviare Oracle E-Business Suite nel nodo 1

10. Verrà visualizzato come di seguito una volta aggiunto il passo 1.

    
    Figura 6.9.3.2: viene aggiunto il passo Avviare Oracle E-Business Suite nel nodo 1

11. Fare clic su Aggiungi passo per aggiungere il secondo passo al gruppo di piani.

12. Nome descrittivo che spiega il task eseguito da questo passo.

13. Seleziona la Regione 2, quindi nel nostro caso è Ashburn.

14. Selezionare Esegui script locale.

15. Selezionare il compartimento corretto contenente l'applicazione Oracle E-Business Suite node1 e selezionare il nodo 1, nel nostro caso è ebshaapp0iad.

16. Incollare il percorso assoluto in cui è stato installato lo script fsdr-rsync-ebs.sh nell'app node1 di Oracle E-Business Suite con i parametri corretti. È possibile fare riferimento ai dettagli del file readme dal collegamento GitHub fornito nel task 2.3 per la sintassi esatta.

17. Specificare oracle come utente per eseguire lo script.

18. Il piano DR deve essere interrotto se lo script non riesce ad abilitare i job rsync su node1. 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.

19. Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di 60 minuti (3600 secondi). Questo valore può essere modificato in 300 secondi o qualsiasi valore ritenuto più realistico di timeout.

20. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

    
    Figura 6.9.3.1: Parametri che consentono di creare il passo del piano per abilitare i job Rysnc nel nodo 1

21. Verrà visualizzato come sotto una volta aggiunto il passaggio 2.

    
    Figura 6.9.3.2: viene aggiunta l'abilitazione dei job rysnc nel nodo 1

Task 6.9.4: Completa aggiunta gruppo piano e passi

Al gruppo di piani DR vengono aggiunti sia l'applicazione di avvio di Oracle E-Business Suite che l'abilitazione dei job rsync su node1.

1. Fare clic su Aggiungi per aggiungere il gruppo di piani DR e i passi al piano DR.

   
   Figura 6.9.4.1: Finalizzare l'aggiunta del gruppo di piani e dei passi per avviare Oracle E-Business Suite e abilitare il job rsync su node1

2. Verificare che il gruppo di piani aggiunto sia disponibile nel piano di switchover.

   
   Figura 6.9.4.1: avviare Oracle E-Business Suite e abilitare il job rsync sul gruppo di piani node1 aggiunto

Task 6.10: Creare un gruppo di piani per avviare Oracle E-Business Suite e abilitare i job di sincronizzazione nel nodo 2 nell'area 2

Ora aggiungiamo il prossimo gruppo di piani definito dall'utente.

Questo gruppo di piani definito dall'utente avvierà Oracle E-Business Suite e abiliterà i job rsync su node2 nell'area 2. Questo gruppo di piani conterrà due passi che richiamano gli script bash startapps.sh e fsdr-rsync-ebs.sh scaricati nei nodi del server applicazioni Oracle E-Business Suite nel task 2.3.

Task 6.10.1: Seleziona Aggiungi gruppo di piani

Avviare il processo per aggiungere un gruppo di piani.

1. Fare clic su Aggiungi gruppo per iniziare.

   
   Figura 6-10.1: Iniziare ad aggiungere un gruppo di piani all'avvio di Oracle E-Business Suite e abilitare i job rsync su node2

Task 6.10.2: Fornire il nome del gruppo di piani, ordinare e aggiungere il passo

Un gruppo di piani DR può contenere molti passi che vengono tutti eseguiti in parallelo. Si aggiungeranno due passaggi per eseguire script bash per avviare Oracle E-Business Suite su node1 e abilitare i job cron rsync su node1 nell'area 2. Nel nostro esempio il nome node1 è ebshaapp02iad.

1. Assegnare al gruppo di piani un nome semplice ma descrittivo.
2. Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, inseriremo il gruppo di piani definito dall'utente aggiungere dopo il gruppo di piani Startup EBS su node1 in IAD.
3. Selezionare il gruppo di piani Avvia EBS in node1 in IAD definito dall'utente.
4. Aggiungeremo due passi. Il primo passo consiste nell'avviare Oracle E-Business Suite nel nodo 2, mentre il secondo è abilitare i job rsync nel nodo 2.
5. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per avviare Oracle E-Business Suite su node2.

Figura 6.10.2: Gruppo di piani per l'avvio di Oracle E-Business Suite e l'abilitazione dei job rsync su node2

Task 6.10.3: Fornire i nomi dei passi e i parametri degli script locali

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi all'esecuzione di questo passo e al relativo comportamento durante il recupero. In questo gruppo di piani verranno aggiunti due passi.

• Passo 1: avviare l'applicazione Oracle E-Business Suite su node2.
• Il punto 2 consente di abilitare i job rysnc in node2.

Per questa impostazione, il nodo 2 è ebshaapp02iad

Spiegheremo tutti i campi di questa finestra di dialogo, ma lasceremo fuori questo dettaglio in tutte le schermate rimanenti nei passaggi successivi poiché stiamo eseguendo lo stesso processo ripetutamente.

1. Nome descrittivo che spiega il task eseguito da questo passo.

2. Selezionare il tipo definito dall'utente Esegui script locale.

3. Seleziona la Regione 2, quindi nel nostro caso è Ashburn.

4. Selezionare il compartimento corretto contenente l'applicazione Oracle E-Business Suite node1 e selezionare il nodo 2, nel nostro caso è ebshaapp02iad.

5. Incollare il percorso assoluto in cui è stato installato lo script startapps.sh nell'app node1 di Oracle E-Business Suite con i parametri corretti. È possibile fare riferimento ai dettagli del file readme dal collegamento GitHub fornito nel task 2.3 per la sintassi esatta.

6. Specificare oracle come utente per eseguire lo script.

7. Il piano DR deve essere interrotto se lo script non riesce ad avviare l'app Oracle E-Business Suite su node2. 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.

8. Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di 60 minuti (3600 secondi). Questo valore può essere modificato in 1800 secondi o qualsiasi valore ritenuto più realistico di timeout.

9. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

   
   Figura 6.10.3.1: Parametri per creare il passo del piano per avviare Oracle E-Business Suite nel nodo 2

10. Verrà visualizzato come di seguito una volta aggiunto il passo 1.

    
    Figura 6.10.3.2: viene aggiunto il passo Avvia Oracle E-Business Suite nel nodo 2

11. Fare clic su Aggiungi passo per aggiungere il secondo passo al gruppo di piani.

12. Nome descrittivo che spiega il task eseguito da questo passo.

13. Seleziona la Regione 2, quindi nel nostro caso è Ashburn.

14. Selezionare Esegui script locale.

15. Selezionare il compartimento corretto contenente l'applicazione Oracle E-Business Suite node1 e selezionare il nodo 2, nel nostro caso è ebshaapp0iad.

16. Incollare il percorso assoluto in cui è stato installato lo script fsdr-rsync-ebs.sh nell'app node1 di Oracle E-Business Suite con i parametri corretti. È possibile fare riferimento ai dettagli del file readme dal collegamento GitHub fornito nel task 2.3 per la sintassi esatta.

17. Specificare oracle come utente per eseguire lo script.

18. Il piano DR deve essere interrotto se lo script non riesce ad abilitare i job rsync su node2. 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.

19. Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di 60 minuti (3600 secondi). Questo valore può essere modificato in 300 secondi o qualsiasi valore ritenuto più realistico di timeout.

20. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

    
    Figura 6.10.3.1: Parametri che consentono di creare il passo del piano per abilitare i job Rysnc nel nodo 2

21. Verrà visualizzato come sotto una volta aggiunto il passaggio 2.

    
    Figura 6.10.3.2: viene aggiunta l'abilitazione dei job rysnc nel nodo 2

Task 6.10.4: Completa aggiunta gruppo di piani e passi

Al gruppo di piani DR vengono aggiunti sia l'applicazione di avvio di Oracle E-Business Suite che l'abilitazione dei job rsync su node2.

1. Fare clic su Aggiungi per aggiungere il gruppo di piani DR e i passi al piano DR.

   
   Figura 6.10.4.1: Finalizzare l'aggiunta del gruppo di piani e dei passi per avviare Oracle E-Business Suite e abilitare il job rsync su node2

2. Verificare che il gruppo di piani aggiunto sia disponibile nel piano di switchover.

   
   Figura 6.10.4.1: avviare Oracle E-Business Suite e abilitare il job rsync sul gruppo di piani node2 aggiunto

Nota: sono stati completati tutti i gruppi di piani definiti dall'utente necessari per il piano di transizione. Assicurati di verificare di aver ottenuto i gruppi di piani nell'ordine giusto, questo è davvero importante.

Una volta personalizzato il piano di switchover, dovrebbe essere simile al seguente:

Figura 6.10.5.1: Tutti i gruppi di piani per il piano di switchover nell'area 2

Nota: è possibile riordinare il gruppo di piani se non è stato effettuato l'ordine corretto.

Task 6.11: Selezionare il piano di failover

Iniziare passando al piano di failover creato nel task precedente.

Figura 6.11: Selezionare il piano di failover nell'area 2

OCI Full Stack DR genererà i gruppi di piani Prechecks-Built in e Databases-Failover, che sono stati generati in base ai membri aggiunti ai gruppi di protezione DR nell'area 1 e nell'area 2.

Figura 6.11.1: Gruppi di piani predefiniti per il piano di failover nell'area 2

Analogamente a come abbiamo personalizzato il piano di switchover, aggiungeremo i gruppi di piani definiti dall'utente necessari per il piano di failover.

È necessario aggiungere i seguenti gruppi di piani definiti dall'utente dopo il gruppo di piani built-in Databases-Failover.

1. Cancellare i nomi dei nodi nelle tabelle fnd del database nell'area 2.
2. Imposta il contesto dell'applicazione nel database su node1 nell'area 2.
3. Imposta il contesto dell'applicazione nel database su node2 nell'area 2.
4. Eseguire autoconfig su node1 nell'area 2.
5. Eseguire autoconfig su node2 nell'area 2.
6. Avviare Oracle E-Business Suite e abilitare i job rsync su node1 nell'area 2.
7. Avviare Oracle E-Business Suite e abilitare i job rsync su node2 nell'area 2.

Nota: non vengono eseguiti i passi per aggiungere di nuovo i gruppi di piani definiti dall'utente. Per istruzioni dettagliate, fare riferimento al Task 6.4 to 6.9.

Una volta personalizzato il piano di failover, dovrebbe essere simile al seguente:

Figura 6.11.1: Tutti i gruppi di piani per il piano di failover nell'area 2

Nota:

• È possibile riordinare i gruppi di piani nel caso in cui non siano stati ordinati nell'ordine corretto.

• È inoltre possibile personalizzare il piano Avvia espansione.

  Si noti che per il piano di espansione iniziale non verranno creati gruppi di piani integrati per il database.

  È necessario creare un gruppo di piani definito dall'utente per convertire lo standby fisico in un database di standby snapshot. È possibile utilizzare i comandi standard del broker Oracle Data Guard per eseguire tali operazioni e inserire uno script wrapper.

  Inoltre, è possibile aggiungere gruppi di piani definiti dall'utente correlati all'applicazione, in modo simile a quello che si fa per un piano Failover.

• OCI Full Stack DR consentirà di creare un piano stopdrill una volta eseguito il piano startdrill. Per ulteriori informazioni, vedere Piani di espansione DR. Il piano Interrompi espansione sta stornando le operazioni eseguite nel piano di espansione iniziale.

• È inoltre possibile personalizzare il piano Interrompi espansione.

  Si noti che per il piano stopdrill non verranno creati gruppi di piani integrati per il database.

  È necessario creare un gruppo di piani definito dall'utente per convertire lo standby snapshot in un database fisico. È possibile utilizzare i comandi standard del broker Oracle Data Guard per eseguire tali operazioni e inserire uno script wrapper.

  È inoltre possibile aggiungere gruppi di piani definiti dall'utente correlati all'applicazione per arrestare tutte le applicazioni correlate a Oracle E-Business Suite.

Come parte di questa esercitazione, verrà eseguito un piano **Switchover nei task successivi.**

Task 7: Esecuzione del piano di switchover nell'area 2 (Ashburn)

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

Tuttavia, i piani DR possono essere creati e modificati solo nel gruppo di protezione con il ruolo standby. Il gruppo di protezione DR nell'area 1 è attualmente il principale, pertanto non è possibile creare piani DR nell'area 1.

Pertanto, dobbiamo invertire i ruoli dei gruppi di protezione in modo che l'area 1 sia lo standby e l'area 2 sia il primario. Esegui il piano di switchover appena creato per trasferire il carico di lavoro dall'area 1 (Phoenix) all'area 2 (Ashburn).

Task 7.1: Inizio esecuzione piano

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

1. Assicurarsi che il contesto dell'area sia ancora impostato su standby region 2 (Ashburn).
2. Utilizzare gli indicatori di percorso nella parte superiore della console per assicurarsi che i dettagli del gruppo di protezione DR siano il contesto del piano corrente.
3. Assicurarsi che sia selezionato il gruppo di protezione DR corretto nell'area 2; che sia il ruolo In standby.
4. Assicurarsi che siano presenti sia i piani di failover che quelli di switchover prima di continuare; in caso contrario, tornare ai passi precedenti per creare e personalizzare entrambi i piani DR.
5. Fare clic su Esegui piano DR.

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

Task 7.2: Seleziona piano di switchover ed esegui

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

1. Selezionare il piano di switchover.
2. Selezionare Abilita controlli preliminari.
3. Fare clic su Esegui piano DR per iniziare.

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

Task 7.3: Monitorare l'esecuzione del piano DR

Monitora il piano di switchover fino a quando il carico di lavoro di Oracle E-Business Suite non è stato completamente trasferito dall'area 1 all'area 2. Una volta completato correttamente il piano di switchover, OCI Full Stack DR si occuperà di ripulire la modifica dei ruoli dei gruppi di protezione DR primari e in 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.

1. Verificare l'esecuzione riuscita del piano di switchover.

   
   Figura 7-2: Piano di switchover completato correttamente nell'area 2

2. Verificare la modifica del ruolo nel gruppo di protezione DR. L'area 2 (Phoenix) avrà ora il ruolo di standby e l'area 1 (Ashburn) avrà ora il ruolo primario.

   
   Figura 7-2: modifica del ruolo del gruppo di protezione DR dopo il piano di switchover

Task 8: Creazione DR e personalizzazione dei piani DR nell'area 1 (Phoenix)

Creare i piani DR nel gruppo di protezione DR nell'area 1 (Phoenix) che ora è il peer in standby.

Lo scopo di ogni piano è quello di trasferire il carico di lavoro dall'area 2 all'area 1 ogni volta che l'area 2 è il peer principale. I ruoli dei gruppi di protezione DR in entrambe le aree vengono invertiti automaticamente come parte di qualsiasi operazione DR, quindi il gruppo di protezione nell'area 2 diventerà lo standby e il gruppo di protezione nell'area 1 diventerà primario dopo un failover o uno switchover.

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

I piani DR vengono sempre creati nel gruppo di protezione con il ruolo standby; l'area 1 è attualmente il gruppo di protezione in standby dopo l'esecuzione del piano di switchover nel task 7.

Seguire lo stesso processo del task 5 per creare i piani DR nell'area 1. Una volta creati i piani, verificare i piani.

Figura 8-1: piani DR nell'area 1

Seguire lo stesso processo di cui al Task 6 per personalizzare i piani DR nell'area 1. Assicurarsi di aggiungere i gruppi di piani definiti dall'utente. È estremamente importante selezionare le VM dell'applicazione Oracle E-Business Suite appropriate per le aree di produzione e DR per l'esecuzione degli script.

1. Chiudere Oracle E-Business Suite e disabilitare i job rsync in node2 nell'area 2.
2. Chiudere Oracle E-Business Suite e disabilitare i job rsync in node1 nell'area 2.
3. Cancellare i nomi dei nodi nelle tabelle FND del database nell'area 1.
4. Imposta il contesto dell'applicazione nel database su node1 nell'area 1.
5. Imposta il contesto dell'applicazione nel database su node2 nell'area 1.
6. Eseguire autoconfig su node1 nell'area 1.
7. Eseguire autoconfig su node2 nell'area 1.
8. Avviare Oracle E-Business Suite e abilitare i job rsync su node1 nell'area 1.
9. Avviare Oracle E-Business Suite e abilitare i job rsync su node2 nell'area 1.

Una volta che il piano di switchover è personalizzato, dovrebbe apparire come:

Figura 8.2: Tutti i gruppi di piani per il piano di switchover nell'area 1

Una volta personalizzato il piano di failover, dovrebbe avere l'aspetto seguente:

Figura 8.3: Tutti i gruppi di piani per il piano di failover nell'area 1

Nota:

• È possibile riordinare i gruppi di piani nel caso in cui non siano stati ordinati nell'ordine corretto.

• È inoltre possibile personalizzare il piano Avvia espansione.

  Si noti che per il piano di espansione iniziale non verranno creati gruppi di piani integrati per il database.

  È necessario creare un gruppo di piani definito dall'utente per convertire lo standby fisico in un database di standby snapshot. È possibile utilizzare i comandi standard del broker Oracle Data Guard per eseguire tali operazioni e inserire uno script wrapper.

  Inoltre, è possibile aggiungere gruppi di piani definiti dall'utente correlati all'applicazione, in modo simile a quello che si fa per un piano Failover.

• OCI Full Stack DR consentirà di creare un piano stopdrill una volta eseguito il piano startdrill. Per ulteriori informazioni, vedere Piani di espansione DR. Il piano Interrompi espansione sta stornando le operazioni eseguite nel piano di espansione iniziale.

• È inoltre possibile personalizzare il piano Interrompi espansione.

  Si noti che per il piano stopdrill non verranno creati gruppi di piani integrati per il database.

  È necessario creare un gruppo di piani definito dall'utente per convertire lo standby snapshot in un database fisico. È possibile utilizzare i comandi standard del broker Oracle Data Guard per eseguire tali operazioni e inserire uno script wrapper.

  È inoltre possibile aggiungere gruppi di piani definiti dall'utente correlati all'applicazione per arrestare tutte le applicazioni correlate a Oracle E-Business Suite.

Passi successivi

A questo punto, OCI Full Stack DR per Oracle E-Business Suite dovrebbe essere completamente implementato. 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 ripristino comprenda appieno l'intero processo.

Piani switchover test

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 built-in come OCI Load Balancer, OCI Block Storage, OCI File Systems, Oracle Base Database Service e Oracle Autonomous Database siano pronti per essere recuperati dalla standby region senza l'intervento umano.

Piani di failover test

I failover sono diversi. I failover per loro natura non possono eseguire il cleanup degli artifact o garantire che i servizi e i database nell'area non riuscita 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 Oracle Data Guard sia nello stato corretto, che gli artifact per le istanze di storage e computazione siano stati interrotti e così via. Per ulteriori informazioni, vedere Reimpostazione della configurazione DR dopo un failover.

Convalida tutti i piani DR per accettazione finale

Il team di recupero deve eseguire una convalida finale per dimostrare la preparazione dei gruppi di protezione OCI Full Stack DR e dei piani per i carichi di lavoro di produzione. La regione 2 (Ashburn) dovrebbe essere la regione primaria a questo punto del processo. Inizia la convalida finale di tutti i piani completando i seguenti passi:

• Eseguire il test dello switchover dalla regione 2 (primaria) alla regione 1 (standby).
• Eseguire il test del failover dall'area 1 (primaria) all'area 2 (standby).
• Prepara area 1 (principale) per il failover dall'area 2.
• Eseguire il test del failover dall'area 2 (primaria) all'area 1 (standby).
• Preparare l'area 2 (primaria) per un failover o lo switchover all'area 2.
• I gruppi di protezione DR e lo stack di applicazioni devono trovarsi in uno stato operativo normale ed essere pronti per un failover o uno switchover in questo momento.
• È inoltre possibile eseguire piani di espansione DR in una delle due aree a seconda dei requisiti.

Ottieni supporto per questa soluzione

I tecnici OCI Full Stack DR forniscono supporto di 1° livello per questa soluzione.

Tuttavia, la soluzione e qualsiasi automazione personalizzata presentata in questa esercitazione sono state ideate e implementate dal team di specialisti Oracle Cloud EMEA indipendentemente dall'organizzazione Oracle E-Business Suite o dal team di progettazione OCI Full Stack DR.

Relazione tra Oracle E-Business Suite e OCI Full Stack DR

OCI Full Stack DR non fa parte del processo di installazione o distribuzione di Oracle E-Business Suite e non viene menzionato in alcuna documentazione scritta e gestita da Oracle E-Business Suite. Il metodo per l'installazione, la configurazione e la distribuzione di Oracle E-Business Suite per il disaster recovery tra le aree OCI è stato ideato e scritto byOracle di progettazione E-Business Suite ed è completamente indipendente da questo tutorial o da OCI Full Stack DR.

L'organizzazione Oracle E-Business Suite non ha familiarità con OCI Full Stack DR e può aiutare a risolvere i problemi con il processo Oracle E-Business Suite come descritto nella documentazione scritta da Oracle E-Business Suite per il disaster recovery eseguito manualmente al di fuori di OCI Full Stack DR.

La risoluzione dei problemi con il processo manuale Oracle E-Business Suite documentato da Oracle E-Business Suite è responsabilità del supporto di Oracle E-Business Suite e eseguita indipendentemente da OCI Full Stack DR. OCI Full Stack DR non impedisce ai clienti o al supporto di Oracle E-Business Suite di eseguire manualmente il processo di disaster recovery documentato di Oracle E-Business Suite. Pertanto, il supporto di Oracle E-Business Suite risolverà i problemi con il processo di disaster recovery manuale senza coinvolgere OCI Full Stack DR.

Tuttavia, attenersi al processo di recupero manuale documentato da Oracle E-Business Suite probabilmente lascerà i gruppi di protezione OCI Full Stack DR in uno stato inutilizzabile che dovrà essere reimpostato prima che le operazioni possano riprendere a utilizzare OCI Full Stack DR con Oracle E-Business Suite. Il supporto OCI Full Stack DR aiuterà i clienti a reimpostare i gruppi di protezione DR dopo che il supporto di Oracle E-Business Suite avrà completato qualsiasi risoluzione e risoluzione manuale dei problemi.

Il supporto inizia con OCI Full Stack DR

Il supporto di OCI Full Stack DR è il primo punto di contatto per assistenza in caso di problemi riscontrati nei passi e nei task spiegati in questa esercitazione. Il supporto OCI Full Stack DR isolerà il problema e determinerà quale organizzazione di supporto è più qualificata per risolvere il problema.

1. Il supporto OCI Full Stack DR è responsabile di:
   1. Aiutare i clienti a comprendere il significato e la causa dei messaggi di errore generati durante un'operazione di DR.
   2. Aiutare i clienti a risolvere i problemi con i criteri IAM che impediscono a Full Stack DR di gestire le risorse durante un'operazione di DR.
   3. Problemi durante la creazione o la gestione dei gruppi di protezione DR.
   4. Problemi con la creazione, l'esecuzione o gli errori del piano DR nel chiamare correttamente l'automazione personalizzata fornita da Oracle E-Business Suite o dal team di soluzioni cloud dell'area EMEA.
   5. I clienti sono responsabili della risoluzione dei problemi e della risoluzione di eventuali problemi con script personalizzati scritti dal cliente che non fanno parte di questa esercitazione.
2. Il supporto OCI Full Stack DR aprirà una SR con il supporto di Oracle E-Business Suite per qualsiasi problema direttamente correlato alla stessa Oracle E-Business Suite. I clienti collaboreranno direttamente con il supporto di Oracle E-Business Suite per risolvere i problemi con Oracle E-Business Suite. Oracle E-Business Suite è responsabile di:
   1. Qualsiasi problema relativo alla documentazione di My Oracle Support (MOS) scritto e gestito dalla Oracle E-Business Suite.
   2. Eventuali problemi con gli script forniti ai clienti da Oracle E-Business Suite.
   3. Eventuali problemi relativi al database correlati a Oracle E-Business Suite.
   4. Qualsiasi problema applicativo relativo a Oracle E-Business Suite.
   5. Eventuali problemi con il processo documentato di Oracle E-Business Suite per il recupero manuale di Oracle E-Business Suite all'esterno di OCI Full Stack DR.
3. Il supporto OCI Full Stack DR aprirà una SR con il team interno di Oracle Cloud Solutions appropriato per qualsiasi problema direttamente correlato agli script o al processo descritto in questa esercitazione. I clienti lavoreranno direttamente con il team di Oracle Cloud Solutions per risolvere i problemi con questa esercitazione. Il team di Oracle Cloud Solutions è responsabile di:
   1. Eventuali problemi con gli script personalizzati forniti dal team di soluzioni cloud.
   2. Eventuali problemi con il processo generale come descritto in questo tutorial.

Come aprire una richiesta di assistenza

Utilizza la console OCI per aprire una richiesta di supporto con il supporto OCI Full Stack DR. Prima di avviare questo processo, assicurarsi che nel contesto del browser venga visualizzato il gruppo di protezione DR creato nell'ambito di questa esercitazione.

1. Assicurarsi che il contesto del browser sia impostato sul gruppo di protezione DR appropriato.
2. Selezionare il preserver vita in OCI Console.
3. Selezionare Crea richiesta di supporto.

Figura 5: Utilizzare lo strumento Guida della console OCI per aprire una richiesta di servizio

Figura 6: le richieste di supporto devono essere aperte utilizzando il pulsante Richiedi assistenza

Collegamenti correlati

• Pagina del prodotto OCI Full Stack Disaster Recovery

• Documentazione su OCI Full Stack Disaster Recovery

• Script di Oracle Samples Oracle E-Business Suite

• Full Stack Disaster Recovery - Script di gruppo definiti dall'utente

• Entra nel canale slack pubblico #full-stack-dr

Conferme

• Autori - Chandra Dharanikota (esperto di Oracle Apps to OCI, Oracle Technology Cloud Engineering, EMEA), Suraj Ramesh - (Full Stack DR, revisore tecnico)

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 Recovery for Multi-Node Oracle E-Business Suite Using OCI Full Stack Disaster Recovery

G35484-02

Copyright ©2025, Oracle and/or its affiliates.