Nota

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

Automatizza il recupero per Oracle Enterprise Performance Management utilizzando OCI Full Stack Disaster Recovery

Parte 1: Introduzione

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

Questa esercitazione descrive le procedure per l'utilizzo del servizio OCI Full Stack DR per gestire i processi di switchover e failover per un ambiente di sistema Oracle Enterprise Performance Management 11.1.2.x e 11.2.x all'interno di una struttura di disaster recovery OCI. È importante notare che la configurazione della topologia del sistema e altre attività del ciclo di vita (come l'applicazione di patch, il test, l'espansione e così via) non rientrano nell'ambito di OCI Full Stack DR.

La strategia di disaster recovery (DR) utilizza una replica completa dei volumi di avvio e a blocchi per l'applicazione e Oracle Data Guard per il database dall'ambiente di produzione al sito in standby, semplificando notevolmente la configurazione della posizione in standby. Questo metodo si allinea alle linee guida DR descritte nel manuale EPM System Deployment Options Guide (in lingua inglese), che aderisce ai suggerimenti per il disaster recovery forniti per Fusion Middleware.

Nell'esercitazione vengono utilizzati in modo intercambiabile Oracle Enterprise Performance Management (Oracle EPM) e Hyperion EPM.

Oracle Enterprise Performance Management fa normalmente parte di un sistema più grande

In questa esercitazione si presuppone che Oracle EPM sia l'unica applicazione aggiunta ai gruppi di protezione DR. Non è normale.

Questa esercitazione è incentrata esclusivamente su Oracle EPM System per motivi di chiarezza. In pratica, Oracle EPM è in genere un componente di un sistema aziendale più grande che include vari servizi e applicazioni all'interno di un singolo gruppo di protezione OCI Full Stack DR e set di piani DR. È probabile che si seguano esercitazioni simili a Oracle Help Center (OHC) per altre applicazioni e servizi come PeopleSoft,Oracle WebLogic Server,Oracle Analytics Cloud,Oracle Integration.

Attenzione all'implementazione in modo incrementale

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

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

Come funziona il recupero

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

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

Per una guida generica sono disponibili i seguenti script. È possibile utilizzare script personalizzati o personalizzarli in base ai criteri aziendali e ai requisiti di sicurezza.

Architettura di distribuzione di Oracle EPM

In questa esercitazione verrà utilizzata la topologia delle istanze di spostamento per l'applicazione Oracle EPM. Nella terminologia generale, le istanze in movimento sono denominate topologia DR light VM/Pilot Cold. Le VM delle applicazioni vengono distribuite solo nell'area primaria. Durante il runtime DR, le VM verranno create nella standby region. Il sistema Oracle DB con Oracle Data Guard deve essere creato nella region primaria e in standby. Per poter implementare la soluzione OCI Full Stack DR, è necessario installare e configurare completamente Hyperion EPM System primario in un'unica area OCI.

Questo design si basa sull'architettura DR di riferimento per Hyperion su OCI, che può essere rivista in dettaglio. Per ulteriori informazioni, vedere Progettare l'infrastruttura per distribuire Oracle Enterprise Performance Management nel cloud.

Load balancer OCI privato

Il traffico proveniente dai tuoi utenti interni e on premise scorre attraverso tunnel IPSec VPN o circuiti virtuali FastConnect fino al gateway di instradamento dinamico (DRG) collegato alla VCN. Un load balancer privato intercetta le richieste e le distribuisce al livello Web privato.

Il livello Web è ospitato in un'istanza di computazione collegata a una subnet privata.

Livello applicazione

Tutte le istanze di computazione nel livello applicazione sono collegate a una subnet privata. Questo isolamento a livello di rete protegge le applicazioni dall'accesso di rete non autorizzato e da altre risorse nella topologia.

Il gateway di servizi consente alle istanze di computazione private nel livello applicazione di accedere a server Yum e WSUS all'interno dell'area per ottenere aggiornamenti del sistema operativo e package aggiuntivi. Inoltre, il gateway di servizi ti consente di eseguire il backup delle applicazioni nello storage degli oggetti OCI all'interno dell'area, senza attraversare la rete Internet pubblica.

I dati memorizzati nei volumi a blocchi e nei file system vengono replicati in una standby region utilizzando la replica tra più aree (CRR, Cross-Region Replication).

Livello database

Oracle Base Database Service ospita gli schemi di EPM System. I dati vengono sincronizzati nella standby region utilizzando Data Guard.

Figura 1: Architettura di riferimento di Oracle EPM

Acquisire familiarità con l'intero processo

I team di progettazione OCI Specialist EMEA e OCI Full Stack DR hanno creato una serie di video complementari per questo tutorial per comprendere l'intero flusso di processo. Questi video fanno parte di una listino OCI Full Stack DR Oracle EPM in YouTube alla quale è possibile accedere utilizzando i seguenti collegamenti:

• Video 1: Distribuisci Oracle EPM per il disaster recovery
• Video 2: Automatizza le operazioni di disaster recovery per Oracle EPM utilizzando OCI Full Stack DR
• Video 3: Script utilizzati per automatizzare il ripristino per Oracle EPM

Parte 2: Istruzioni dettagliate

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

Obiettivi

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

1. Task 1: Distribuire Oracle EPM per il disaster recovery
   1. Configurare un Oracle Data Guard tra più aree per Oracle Base Database Service
   2. Preparare il nodo di controllo DR per eseguire l'automazione personalizzata
   3. Crea gruppo di volumi a blocchi
   4. Crea criteri Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) per Full Stack DR
   5. Crea criteri IAM OCI per altri servizi OCI
   6. Crea bucket di storage degli oggetti OCI per i log
   7. Crea load balancer di standby (facoltativo)
2. Task 2: Creare gruppi di protezione DR (DRPG)
3. Task 3: aggiungere membri a DRPG area 1 e area 2
4. Task 4: creare piani DR di base nella regione 2 (Newport)
   1. Crea piano switchover
   2. Crea piano di failover
5. Task 5: Personalizzare il piano di switchover nella regione 2 (Newport)
6. Task 6: Personalizzare il piano di failover nell'Area 2 (Newport)
7. Task 7: eseguire il piano di switchover nella regione 2 (Newport)
8. Task 8: creare piani DR di base nella regione 1 (Londra)
   1. Crea piano switchover
   2. Crea piano di failover
9. Task 9: Personalizzare il piano di switchover nella regione 1 (Londra)
10. Task 10: Personalizzare il piano di failover nella regione 1 (Londra)

Definizioni e ipotesi in tutta l'esercitazione

Aree

La regione 1 è Londra

• Londra sarà la prima regione. Questo ruolo verrà modificato in standby dopo aver ricevuto l'istruzione di eseguire uno switchover nei passi successivi.

La regione 2 è Newport

• Newport inizierà come standby region. Questo ruolo alla fine passerà a primario dopo aver ricevuto l'istruzione di eseguire uno switchover nei passi successivi.

Compartimenti

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

Nodo controllo DR

Il nodo DR Control è qualsiasi istanza di computazione designata per ospitare script personalizzati che eseguono task specifici per recuperare EPM System. Gli script vengono richiamati da Full Stack DR durante un'operazione di ripristino. Qualsiasi istanza di computazione esistente membro di un gruppo di protezione DR (DRPG, DR Protection Group) può essere il nodo di controllo. In questo esempio, il server applicazioni EPM System ospita tutti gli script personalizzati utilizzati nel processo di recupero. In questa esercitazione, sia il nodo applicazione che il nodo controllo sono uguali.

Prerequisiti

• Un EPM System completamente configurato deve essere distribuito in un'unica area OCI. Dovrebbe utilizzare un Oracle Base Database Service con una licenza che consenta la distribuzione di un Oracle Data Guard tra più aree.
• VCN e subnet nella standby region. Si consiglia di eseguire il mirroring della topografia di rete dall'area primaria nella standby region. Per la replica Oracle Data Guard tra più aree, è necessario abilitare il peering VCN tra le region primarie e standby, pertanto le VCN non devono avere intervalli CIDR IP sovrapposti.

Task 1: Distribuire Oracle EPM per il disaster recovery

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

Task 1.1: configurare un Oracle Data Guard tra più aree per Oracle Base Database Service

Per distribuire Oracle Data Guard per Oracle Base Database Service tra più aree, vedere Usa Oracle Data Guard su un sistema DB.

Quando si sincronizzano i database nel sistema con Oracle Data Guard, è fondamentale utilizzare lo stesso nome di servizio di database o lo stesso alias TNS per i database primari e in standby. Questa pratica riduce al minimo le modifiche necessarie a livello di applicazione dopo uno switchover, garantendo una transizione fluida. Per istruzioni dettagliate, fare riferimento alla sezione "Considerazioni sul database" nella documentazione Fusion Middleware DR, in cui vengono descritti in modo esaustivo vari approcci.

Task 1.2: Preparare il nodo di controllo DR per eseguire l'automazione personalizzata

Designare un'istanza di computazione per fungere da nodo di controllo DR per EPM Full Stack DR. Può essere un'istanza di computazione esistente oppure un'istanza di computazione creata solo per questo scopo. Per ulteriori informazioni, vedere le opzioni riportate di seguito. Assicurarsi che l'istanza o le istanze di computazione che fungono da nodo di controllo DR siano state configurate per eseguire i comandi utilizzando l'agente Oracle Cloud: esecuzione dei comandi in un'istanza.

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

Scaricare nel nodo DR Control gli script personalizzati da qui: Script Github di Oracle EPM scritti in modo specifico per questo esempio DR di EPM System. Gli script mostrati di seguito devono essere copiati in qualsiasi sottodirectory dell'istanza di computazione che funge da nodo di controllo DR. In questa esercitazione verrà utilizzato anche il nodo dell'applicazione EPM come nodo di controllo DR. Gli script sono stati creati appositamente per questo esempio di ripristino di EPM System e dovranno essere modificati per essere utilizzati nella soluzione di ripristino. In questa esercitazione l'applicazione EPM è in esecuzione su una VM Windows e vengono quindi utilizzati gli script Powershell (ps1). Se si utilizza una VM Linux, gli script shell sono disponibili nello stesso repository github. Poiché si utilizza EPM VM per l'esecuzione degli script, al nodo DR Control viene fatto riferimento alla stessa VM EPM.

Task 1.3: Crea gruppo di volumi a blocchi

Crea un gruppo di volumi a blocchi nell'area 1 e assicurati che venga replicato nell'area 2. Assicurarsi che il volume di avvio per il nodo di controllo DR sia membro di un gruppo di volumi a blocchi e che il gruppo di volumi a blocchi venga replicato nell'area 2. Per ulteriori informazioni, vedere Creazione di un gruppo di volumi.

Assicurarsi che qualsiasi altro avvio e blocco appartenga a qualsiasi altra computazione mobile per questo progetto DR OCI Full Stack appartenga anche al gruppo di volumi a blocchi replicato nell'area 2.

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

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

• Criteri per OCI Full Stack DR
• Configurazione dei criteri IAM (Identity and Access Management) per l'utilizzo di DR Full Stack

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

OCI Full Stack DR deve avere la possibilità di controllare e gestire altri servizi OCI chiave come computazione, networking, storage, vault, database e altri servizi vari. Configurare i criteri IAM OCI necessari per altri servizi illustrati qui: Criteri per altri servizi gestiti da Full Stack Disaster Recovery.

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

Task 1.6.1: passare a OCI Object Storage

Inizia passando a Storage degli oggetti e storage di archivio come mostrato nella Figura 1.1.

1. Assicurarsi che il contesto del browser sia impostato sull'area 1 (Londra).
2. Selezionare Memorizzazione.
3. Selezionare Bucket.

Figura 1.1: Passare allo storage degli oggetti

Task 1.6.2: Bucket di storage degli oggetti OCI nell'area 1

Creare un bucket di storage degli oggetti OCI nell'area 1. In un passo successivo, il bucket verrà assegnato al gruppo di protezione DR nell'area 1.

1. Selezionare il compartimento che contiene le risorse correlate a EPM System.
2. Fare clic su Crea bucket.
3. Dare al bucket un nome significativo che identifichi facilmente quale applicazione e scopo serve.
4. Utilizzare il valore predefinito per Livello di storage predefinito e Cifratura.
5. Fare clic su Crea per creare il bucket.

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

Task 1.6.3: Bucket di storage degli oggetti OCI nell'area 2

Segui lo stesso processo per creare un bucket di storage degli oggetti nell'area 2 (Newport). Assicurarsi di selezionare l'area Newport. In un passo successivo, il bucket verrà assegnato al gruppo di protezione DR nell'area 2.

1. Modificare il contesto nell'area 2.
2. Selezionare il compartimento che contiene le risorse correlate a EPM System nell'area 2.
3. Fare clic su Crea per creare il bucket.

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

Task 1.7: (facoltativo) creare il load balancer OCI nella standby region

L'uso di OCI Load Balancer è facoltativo. Se EPM System non lo include, ignorare questo task.

Creare un load balancer OCI nell'area di standby:

1. Eseguire il mirroring della configurazione del load balancer primario.
2. Creare un set backend vuoto all'interno di questo load balancer. A questo punto nella standby region non sono presenti backend da includere nella configurazione, pertanto è necessario creare solo un set backend vuoto.

Configurazione durante lo switchover o il failover:

1. La configurazione del set backend primario di EPM System verrà copiata nel set backend di standby vuoto.

Certificati e listener:

1. Se si utilizzano i propri certificati, caricarli nel load balancer di standby.
2. Configurare i listener in modo che corrispondano alla configurazione del load balancer primario.

Aggiornamento post-switchover:

1. Dopo lo switchover, aggiornare le informazioni DNS in modo che puntino all'indirizzo IP del load balancer in standby.

Per ulteriori informazioni, vedere Panoramica del load balancer.

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

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

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

Task 2.1: passare ai gruppi di protezione DR

Per iniziare, passare a Gruppi di protezione DR (OCI Full Stack DR) come illustrato nella figura 2-1 riportata di seguito.

1. Assicurarsi che il contesto dell'area OCI sia impostato sull'area 1 (Londra).
2. Fare clic su Migrazione e recupero da errori irreversibili.
3. Fare clic su Gruppi di protezione DR.

Figura 2-1: Passare ai gruppi di protezione DR

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

Creare un gruppo di protezione DR di base (DRPG) nella regione 1, come illustrato nella figura 2-2 riportata di seguito. 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 EPM System.
2. Fare clic su Crea gruppo di protezione DR per aprire la finestra di dialogo.
3. Utilizzare un nome significativo per il DRPG.
4. Selezionare il bucket di storage degli oggetti creato nel task 2 per l'area 1.
5. Fare clic su Crea.

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

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

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

1. Modifica il contesto dell'area OCI nell'area 2 (Newport).
2. Selezionare il compartimento in cui si desidera creare il DRPG. Può essere lo stesso compartimento in cui esistono risorse di EPM System.
3. Fare clic su Crea gruppo di protezione DR per aprire la finestra di dialogo.
4. Utilizzare un nome significativo per il DRPG.
5. Selezionare il bucket di storage degli oggetti creato nel task 2 per l'area 2.
6. Fare clic su Crea.

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

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

Associa i DRPG in ogni region come peer gli uni degli altri e assegna i ruoli peer di database primario e standby. Ecco come OCI Full Stack DR saprà quali due region lavorano insieme per il ripristino di Oracle EPM System. I ruoli di database primario e standby vengono modificati automaticamente da OCI Full Stack DR nell'ambito di qualsiasi operazione di DR/esecuzione del piano DR; non è necessario gestire i ruoli manualmente in qualsiasi momento.

Task 2.4.1: Iniziare l'associazione

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

Figura 2.4.1: Avvio dell'associazione DRPG

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

Fornire i parametri come illustrato nella figura 2.4.2.

1. Selezionare il ruolo principale. OCI Full Stack DR assegnerà automaticamente il ruolo in standby alla region 2.
2. Selezionare l'area 2 (Newport), in cui è stato creato l'altro DRPG.
3. Selezionare il DRPG peer in cui è stato creato.
4. Fare clic su Associazione.

Figura 2.4.2: Parametri necessari per associare i DRPG

Task 2.4.3: Cosa si dovrebbe vedere dopo il completamento dell'associazione

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

1. L'attuale peer primario DRPG è Londra (regione 1).
2. L'attuale peer in standby DRPG è Newport (regione 2).

Figura 2.4.3: Visualizzazione della relazione peer dalla prospettiva DRPG individuale

Le stesse informazioni possono essere trovate ogni volta che il contesto/vista è da una prospettiva globale che mostra tutti i gruppi di protezione DR come mostrato nella figura 2.4.4 di seguito.

1. L'attuale peer primario DRPG è Londra (regione 1).
2. L'attuale peer in standby DRPG è Newport (regione 2).

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

Task 3: aggiungere membri al gruppo di protezione DR

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

Aggiungere il database e i nodi di calcolo dell'applicazione Oracle EPM System come membri dei gruppi di protezione DR. Il nodo DR Control è un'istanza di computazione creata solo per supportare l'orchestrazione DR o un'istanza di computazione che fa parte dello stack di applicazioni che si desidera gestire con Full Stack DR. In questo esempio, il nodo dell'applicazione EPM System esegue anche la funzione del nodo DR Control.

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

1. Il nodo di calcolo dell'applicazione EPM System, che esegue anche la funzione del nodo DR Control.
2. Il gruppo di volumi contiene il volume di avvio del nodo di calcolo dell'applicazione EPM System. Se presente, eventuali volumi a blocchi aggiuntivi collegati ai nodi di calcolo devono essere inclusi nel gruppo di volumi.
3. Oracle Base Database Service primario.
4. Il load balancer primario.

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

Inizia selezionando il DRPG nella regione 1 come mostrato nella Figura 3-1.

1. Assicurarsi che il contesto dell'area OCI sia l'area 1 (Londra).
2. Selezionare il DRPG nella regione 1.
3. Selezionare Membri.
4. Fare clic su Aggiungi membro per avviare il processo.

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

Task 3.1.1: Aggiungi istanza di computazione per il nodo di controllo DR

Aggiungere un'istanza di computazione per EPM System, che funge anche da nodo di controllo DR, come illustrato nella figura 3.1.1. In questo esempio, una singola istanza di computazione ospita tutti i moduli di EPM System. Se EPM System viene distribuito in un ambiente distribuito con più nodi di calcolo, assicurarsi che ogni nodo sia incluso in questo passo.

1. Conferma avvertenza relativa ai piani DR.
2. Immettere Computazione come tipo di risorsa membro.
3. Selezionare l'istanza di computazione dell'applicazione EPM System. Questa stessa istanza di computazione verrà utilizzata anche per l'esecuzione di script definiti dall'utente.
4. Selezionare Istanza di spostamento.
5. Aggiungi OCI Full Stack DR che VCN e subnet devono assegnare alle VNIC nell'area 2 durante un recupero. La Figura 4-2 mostra una singola VNIC. OCI Full Stack DR non si preoccupa del numero di VNIC disponibili o del modo in cui vengono configurate in entrambe le aree; specifica ciò di cui hai bisogno che si adatti alle tue esigenze. Assicurarsi di fornire un indirizzo IP valido dalla subnet di destinazione nella standby region. Ciò semplificherà l'aggiornamento dei file host dopo lo switchover, poiché l'istanza di computazione utilizzerà in modo coerente lo stesso indirizzo IP noto.

Figura 3.1.1: Parametri necessari per aggiungere il nodo di controllo DR

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

Aggiungere il gruppo di volumi a blocchi contenente volumi di avvio e a blocchi collegati al nodo dell'applicazione EPM System. Il gruppo di volumi a blocchi deve già avere una replica tra più aree configurata tra le due aree prima di aggiungerla al gruppo di protezione DR.

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

Figura 3.1.2: Parametri necessari per aggiungere il gruppo di volumi di avvio per EPM Compute

Task 3.1.3: Aggiungi Oracle Base Database Service primario

A questo punto, Oracle Data Guard deve essere già configurato per il sistema di servizi Oracle Base Database nell'ambito del task 1. Aggiungere il database primario come membro del DRPG nell'area 1.

1. Selezionare Database come tipo di risorsa membro.
2. Assicurarsi che sia selezionato il compartimento corretto per il database.
3. Fornire i dettagli del segreto nel vault OCI contenente la password utente SYS del database EPM. Questo segreto è stato creato durante la configurazione di Oracle Data Guard nel task 1.

Figura 3.1.3: Parametri necessari per aggiungere il database primario in esecuzione dal servizio Base DB

Task 3.1.4: Aggiungi load balancer OCI

In questo esempio, il load balancer viene aggiunto come membro del DRPG nell'area 1.

1. Selezionare Load balancer come tipo di risorsa membro.
2. Assicurarsi che siano selezionati i compartimenti corretti per il load balancer.
3. Selezionare Set backend di origine: si tratta del set backend utilizzato dall'applicazione EPM System. Un load balancer OCI può essere condiviso tra più applicazioni e può avere più set backend configurati. Durante uno switchover DR, la configurazione dei set backend specificati qui verrà spostata nella standby region.
4. Selezionare Set backend di destinazione: si tratta del set backend vuoto creato nel task 1.7 nell'area 2.

Figura 3.1.4: Parametri necessari per aggiungere il load balancer

Task 3.1.5: Verifica risorse membro per area 1

Il DRPG per la regione 1 dovrebbe ora disporre di quattro risorse membro, come illustrato nella figura 3.1.5. I nomi delle risorse membro saranno diversi.

1. Il database primario.
2. L'istanza di calcolo mobile.
3. Gruppo di volumi a blocchi per l'istanza di computazione.
4. Load balancer OCI

Figura 3.1.5: Visualizzazione dei membri di DRPG nell'area 1

Task 3.2: Iniziare ad aggiungere membri a DRPG nell'area 2

Inizia selezionando il DRPG nella regione 2.

1. Assicurarsi che il contesto dell'area OCI sia l'area 2 (Newport).
2. Selezionare il DRPG nella regione 2.
3. Fare clic su Membri.
4. Fare clic su Aggiungi membro per avviare il processo.

Aggiungerete le seguenti risorse al DRPG in standby nella region 2 seguendo i passi simili riportati nella region primaria:

1. Sistema Oracle Base Database Service in standby/remoto.
2. Load balancer OCI in standby.

Una volta completata l'attività, il DRPG per la regione 2 dovrebbe avere due risorse membro come mostrato nella Figura 3.2 di seguito.

Figura 3.2: Visualizzazione dei membri di DRPG nell'area 2

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

Questo passo crea piani di switchover e failover di base associati al gruppo di protezione DR in standby nella region 2 (Newport).

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

OCI Full Stack DR preinserirà entrambi i piani con passi integrati basati sulle risorse membro aggiunte nei task precedenti. I piani verranno personalizzati in passi successivi per gestire tutti i task correlati a EPM System durante un'operazione di ripristino.

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

Task 4.1: Crea piani DR

Creare un piano di base selezionando il DRPG nell'area 2 (Newport)

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

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

Task 4.1.1: Creare un piano di switchover

La creazione di un piano DR è semplice come illustrato nella figura 4.1.1 di seguito.

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 il tipo di piano come Switchover (pianificato). Ci sono solo quattro tipi di piano al momento di questa scrittura.

Figura 4.1.1: Parametri necessari per creare un piano di switchover DR

Task 4.1.2: Creare un piano di failover

Seguire lo stesso processo per creare un piano di failover di base come mostrato nella figura 4.1.2 di seguito.

1. Rendere il nome del piano di failover semplice ma significativo. Il nome dovrebbe essere il più breve possibile, ma facile da capire a colpo d'occhio per contribuire a ridurre la confusione e l'errore umano durante una crisi.
2. Selezionare il tipo di piano come Failover (non pianificato). Ci sono solo quattro tipi di piano al momento di questa scrittura.

Figura 4.1.2: Parametri necessari per creare un piano di failover DR

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

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

Task 5: Personalizzare il piano di switchover nell'area 2 (Newport)

I piani DR di base creati nel task 4 contengono passi precompilati per i task di ripristino integrati in Full Stack DR e non contengono nulla per gestire i task di recupero specifici dell'applicazione EPM System. Questo passo spiega come aggiungere gruppi di piani DR personalizzati e definiti dall'utente e i passi per gestire i task da eseguire durante uno switchover per EPM System:

• Arrestare i servizi EPM System nell'area primaria corrente 1 prima di arrestare qualsiasi VM.
• Aggiornare i file host nel nodo di calcolo per eseguire il mapping degli indirizzi IP di standby ai nomi host dell'area primaria.
• Avviare i servizi EPM System nella standby region 2 corrente dopo aver avviato qualsiasi VM.

Task 5.1: selezionare il piano di switchover

Passare al piano di switchover creato nel task 4.

Figura 5.1: Come iniziare a personalizzare il piano di switchover nell'area 2

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

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

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

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

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

Figura 5.2: Gruppi di piani disabilitati per impostazione predefinita

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

1. Questo gruppo di piani termina gli artifact delle istanze di computazione rimaste indietro nell'area 1 dopo che le versioni replicate delle VM sono state avviate nell'area 2 durante l'operazione di storage degli oggetti OCI per annullare la replica dall'area 2 all'area 1 come parte dello switchover. Le VM rimanenti non vengono utilizzate durante uno switchback perché l'operazione di inversione della replica del volume a blocchi crea tutte le nuove VM in gruppi di volumi a blocchi completamente nuovi.

2. Questo gruppo di piani termina gli artifact dei gruppi di volumi a blocchi (VG) lasciati indietro nell'area 1 dopo che le versioni replicate dei VG sono state attivate nell'area 2 e la replica dei gruppi di volumi è stata invertita durante lo switchover. I gruppi di volumi a blocchi rimanenti non vengono mai più utilizzati, nemmeno come parte di uno switchover dalla regione 2 alla regione 1.

Task 5.2.1: Abilita interruzione gruppo di piani di calcolo

Abilitare il gruppo di piani.

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

   
   Figura 5.2.1: Come abilitare l'interruzione delle istanze di computazione

Task 5.2.2 Abilita cessazione gruppo di piani gruppi di volumi

Abilitare il gruppo di piani.

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

   
   Figura 5.2.2: Come abilitare l'interruzione dei gruppi di volumi

Task 5.3: creare un gruppo di piani per eseguire script personalizzati nell'area 1 (principale)

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

Il primo gruppo di piani definito dall'utente eseguirà script personalizzati per interrompere l'esecuzione dei servizi EPM System nell'area principale 1. Questo gruppo di piani conterrà un singolo passo che richiama lo script PowerShell di Windows stop_services.ps1, scaricato nella cartella c:/scripts nel nodo dell'applicazione EPM nel task 1.2.

Task 5.3.1: Seleziona Aggiungi gruppo di piani

Inizia il processo di aggiunta di un gruppo di piani.

1. Fare clic su Aggiungi gruppo per iniziare.
2. Assegnare al gruppo di piani un nome semplice ma descrittivo. Questa opzione è facoltativa, ma si consiglia di aggiungere una nota sull'area in cui il gruppo di piani eseguirà i passi.
3. Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, inseriremo il nostro gruppo di piani definito dall'utente prima del gruppo di piani incorporato che arresta le VM nell'area 1.
4. Selezionare il gruppo di piani Arresta istanze di computazione (principale) incorporato.
5. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per arrestare EPM System.

Figura 5.3.1: Parametri per creare un gruppo di piani e aggiungere un passo per arrestare EPM

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

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi alle prestazioni di questo passo e alle modalità di funzionamento durante il recupero. In questo caso, interromperà i servizi EPM System nella regione 1.

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

1. Un nome passo descrittivo che spiega il task eseguito da questo passo.
2. Selezionare sempre l'area in cui è in esecuzione il nodo dell'applicazione EPM in questo momento, non la posizione in cui verrà eseguito durante uno switchover. OCI Full Stack DR terrà traccia di dove è in esecuzione la VM, quindi devi solo specificare dove si trova in questo momento. In questo caso, il nodo dell'applicazione EPM è in esecuzione nell'area 1 (Londra).
3. Selezionare il compartimento corretto che contiene il nodo di controllo DR. Quindi selezionare l'istanza di computazione designata come nodo DR Control; in questo esempio, si tratta di computazione dell'applicazione EPM System.
4. Selezionare Esegui script locale per informare OCI Full Stack DR che lo script verrà trovato in un'istanza di computazione. Gli script PowerShell di Windows sono stati scaricati nel nodo di controllo DR nel task 1.2.
5. Incollare il percorso assoluto in cui è stato installato lo script stop_services.ps1 sul nodo di controllo DR. Aggiungere l'arresto come primo parametro e l'ID dell'area OCI come secondo.
6. Il piano DR deve essere interrotto se lo script non riesce ad arrestare i servizi EPM. 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.
7. Il valore predefinito prima che Full Stack DR dichiari un errore è di un'ora. Questo valore può essere modificato in 30 minuti o qualsiasi cosa si ritenga essere un valore di timeout più realistico.
8. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

Figura 5.3.2: Parametri per la creazione del passo del piano per l'arresto di EPM

Task 5.3.3: Completare l'aggiunta del gruppo di piani e della fase

Il passo per arrestare EPM System è stato ora aggiunto al gruppo di piani DR, come illustrato nella figura 5.3.3 riportata di seguito.

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

Figura 5.3.3: Finalizzare l'aggiunta di gruppo di piani e passo per arrestare EPM

Task 5.4: creare un gruppo di piani per eseguire script personalizzati nell'area 2 (in standby)

Il secondo gruppo di piani definito dall'utente aggiornerà i file host sui nodi di calcolo e avvierà i servizi EPM System dopo l'avvio del nodo DR Control nella standby region 2. Questo gruppo di piani conterrà due passi che richiamano gli script host_switch_failover.ps1 e start_services.ps1 PowerShell scaricati nel nodo di controllo DR nel task 1.2.

Task 5.4.1 Creare un gruppo di piani DR per aggiornare il file host dopo lo switchover nell'area di standby

1. Assegnare al gruppo di piani un nome di gruppo 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 dopo il gruppo di piani incorporato che avvia la versione replicata del nodo dell'applicazione EPM System, che esegue anche la funzione del nodo di controllo DR nell'area 2.
3. Selezionare il gruppo di piani Avvia istanze di computazione integrato
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per aggiornare il file host.

Figura 5.4.1: Parametri per creare il passo del piano per avviare EPM

Task 5.4.2: fornire il nome del passo e i parametri dello script locale per lo script di aggiornamento del file host

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi alle prestazioni di questo passo e alle modalità di funzionamento durante il recupero. Lo script host_switch_failover.ps1 aggiorna il file host nel nodo di calcolo in modo che i nuovi indirizzi IP per le istanze di computazione e database nell'area 2 vengano mappati al nome host dell'area 1 originale. Ciò consentirà di avviare l'applicazione senza ulteriori modifiche nel livello dell'applicazione.

Questo passaggio è lo stesso del Task 5.3.2 ad eccezione degli elementi illustrati nella Figura 5.4.2 di seguito.

1. Un nome passo descrittivo che spiega il task eseguito da questo passo.
2. Incollare nel percorso assoluto di PowerShell.exe e nel punto in cui è stato installato lo script host_switch_failover.ps1 sul nodo dell'applicazione EPM.
3. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

Figura 5.4.2: Parametri per aggiornare il file host

Task 5.4.3: fornire il nome del passo e i parametri dello script locale per lo script di avvio del servizio EPM System

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi alle prestazioni di questo passo e alle modalità di funzionamento durante il recupero. In questo caso, i servizi EPM System inizieranno dalla region 2.

1. Un nome passo descrittivo che spiega il task eseguito da questo passo.
2. Incollare nel percorso assoluto di PowerShell.exe e nel punto in cui è stato installato lo script start_services.ps1 sul nodo dell'applicazione EPM.
3. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.
4. Fare clic su Aggiungi per aggiungere il gruppo di piani che ora contiene due passi per eseguire due script personalizzati.

Figura 5.4.3: Parametri per avviare EPM

Il piano di switchover dovrebbe ora includere entrambi i gruppi di piani DR come mostrato nello screenshot seguente.

Figura 5.4.4: Script personalizzato dopo l'avvio

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

Questo task spiega come aggiungere gruppi di piani DR personalizzati e definiti dall'utente e i passi per gestire i task che devono essere eseguiti durante un failover per EPM System nell'area 2 durante un'interruzione effettiva o una perdita di accesso all'area 1. Questi passi costituiranno un sottoinsieme degli stessi passi appena aggiunti al piano di switchover nel precedente task 5. Tuttavia, solo i passi eseguiti nella standby region 2 verranno aggiunti al piano di failover poiché si presume che la region 1 sia completamente inaccessibile durante un failover.

Task 6.1: selezionare il piano di failover

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

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

Figura 6-1: inizio della personalizzazione del piano di failover nell'area 2.

Task 6.1.2: aggiungere passi al nuovo gruppo di piani definito dall'utente

1. Fare clic su Aggiungi gruppo.

   
   Figura 6.1.2 Parametri per creare il passo del piano per avviare EPM

2. Seguire le istruzioni del task 5.4 per aggiungere due passi al gruppo di piani definito dall'utente per eseguire gli script personalizzati: host_switch_failover.ps1 e start_services.ps1.

3. Dopo aver aggiunto i passi e il gruppo di piani definito dall'utente, il piano di failover deve essere simile al seguente:

   
   Figura 6.1.3 Parametri per creare il passo del piano per avviare EPM e aggiornare gli host

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

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

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

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

Task 7.1: Inizio esecuzione piano

Eseguire il piano DR per avviare il processo di transizione del carico di lavoro di EPM System dalla region 1 alla region 2.

1. Assicurati che il contesto della region sia ancora impostato sulla standby region 2 (Newport).
2. Utilizzare gli indicatori di percorso nella parte superiore della console per garantire che i dettagli del gruppo di protezione DR siano il contesto del piano corrente.
3. Assicurarsi che sia selezionato il gruppo di protezione DR corretto nella region 2; deve essere il ruolo standby.
4. Prima di procedere, assicurarsi che siano presenti sia i piani di failover che di switchover. In caso contrario, tornare ai task precedenti per creare 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 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: Passi successivi

Monitora il piano di switchover fino a quando il carico di lavoro di EPM System non è stato completamente trasferito dall'area 1 all'area 2. Full Stack DR eseguirà il cleanup degli artifact e modificherà i ruoli primario e standby tra le aree. Se l'esecuzione del piano di switchover non riesce, verificare i log e assicurarsi che il piano venga eseguito correttamente.

Una volta completato lo switchover, Full Stack DR, la region 2 (Newport) diventerà la region primaria e la region 1 (Londra) sarà la standby region.

Task 8: Creare piani DR nell'area 1 (Londra)

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

Ogni piano mira a trasferire il carico di lavoro dalla region 2 alla region 1 ogni volta che la region 2 è il peer primario. Nell'ambito di qualsiasi operazione di DR, i ruoli dei gruppi di protezione DR in entrambe le aree vengono invertiti automaticamente, pertanto il gruppo di protezione DR nella regione 2 diventerà in standby e il gruppo di protezione DR nella regione 1 diventerà il principale dopo un failover o uno switchover.

OCI Full Stack DR preinserirà entrambi i piani con passi integrati in base alle risorse membro aggiunte nel task precedente. Nei passi successivi, i piani verranno personalizzati per gestire tutti i task correlati a EPM System durante un'operazione di ripristino.

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

Task 8.1: Creare piani DR

Creare un piano di base selezionando il DRPG nella regione 1 come mostrato nella Figura 8.1.

1. Assicurarsi che il contesto dell'area OCI sia l'area 1 (Londra).
2. Selezionare il DRPG in standby nella region 1.
3. Selezionare Piani.
4. Fare clic su Crea piano per avviare il processo.
5. 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.
6. Selezionare Tipo di piano come Switchover (pianificato). Ci sono solo quattro tipi di piano al momento di questa scrittura.
7. Fare clic su Crea per creare un piano di switchover di base precompilato con passi built-in di base.

Figura 8.1: Parametri necessari per creare un piano di switchover DR

Task 8.2: Crea un piano di failover

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

1. Rendere il nome del piano di failover semplice ma significativo. Il nome dovrebbe essere il più breve possibile, ma facile da capire a colpo d'occhio per contribuire a ridurre la confusione e l'errore umano durante una crisi.

2. Selezionare Tipo di piano come Failover (non pianificato). Ci sono quattro tipi di piano al momento di questa scrittura.

3. Fare clic su Crea per creare un piano di failover di base prepopolato con i passi built-in di base.

Figura 8.2: Parametri necessari per creare un piano di failover DR

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

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

Task 9: Personalizzare il piano di switchover nell'area 1 (Londra)

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

I piani DR di base creati nel task 8 contengono passi precompilati per i task di recupero integrati in OCI Full Stack DR e non contengono nulla per gestire i task di recupero specifici dell'applicazione EPM System. Questo passo spiega come aggiungere gruppi di piani DR personalizzati e definiti dall'utente e i passi per gestire i task da eseguire durante uno switchover per EPM System:

• Arrestare i servizi EPM System nell'area primaria corrente 1 prima di arrestare qualsiasi VM.
• Aggiornare i file host nel nodo di calcolo per eseguire il mapping degli indirizzi IP di standby ai nomi host dell'area primaria.
• Avviare i servizi EPM System nella standby region 2 corrente dopo aver avviato qualsiasi VM.

Task 9.1: selezionare il piano di switchover

Passare al piano di switchover creato nel task precedente.

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

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

Questi sono gli stessi passi eseguiti per la regione 2 in un task precedente; lo stesso processo deve essere seguito per la regione 1.

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

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

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

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

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

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

1. Questo gruppo di piani termina gli artifact delle istanze di computazione rimaste indietro nell'area 2 dopo che le versioni replicate delle VM sono state avviate nell'area 1 durante l'operazione di storage a blocchi OCI per invertire la replica dall'area 1 all'area 2 come parte dello switchover. Le VM rimanenti non vengono utilizzate durante uno switchback perché l'operazione di inversione della replica del volume a blocchi crea tutte le nuove VM in gruppi di volumi a blocchi completamente nuovi.

2. Questo gruppo di piani termina gli artifact dei gruppi di volumi a blocchi (VG) lasciati indietro nell'area 2 dopo che le versioni replicate dei VG sono state attivate nell'area 1 e la replica del gruppo di volumi è stata invertita durante lo switchover. I gruppi di volumi a blocchi rimanenti non vengono mai più utilizzati, nemmeno come parte di uno switchover dalla regione 1 alla regione 2.

Task 9.2.1: Abilita arresto gruppo di piani di calcolo

Abilitare il gruppo di piani.

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

   
   Figura 9.2.1: Come abilitare l'interruzione delle istanze di computazione

Task 9.2.2 Abilita cessazione gruppo di piani gruppi di volumi

Abilitare il gruppo di piani.

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

   
   Figura 9.2.2: Come abilitare l'interruzione dei gruppi di volumi

Task 9.3: Crea gruppo di piani per eseguire script personalizzati nell'area 2 (principale)

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

Il primo gruppo di piani definito dall'utente eseguirà script personalizzati per interrompere l'esecuzione dei servizi EPM System nell'area principale 2. Questo gruppo di piani conterrà un singolo passo che chiama lo script PowerShell di Windows stop_services.ps1 scaricato nella cartella c:/scripts nel nodo di controllo DR nel task 1.2.

Task 9.3.1: Seleziona Aggiungi gruppo di piani

Avviare il processo per aggiungere un gruppo di piani.

1. Fare clic su Aggiungi gruppo per iniziare.
2. Assegnare al gruppo di piani un nome semplice ma descrittivo.
3. Selezionare una posizione in cui il gruppo di piani verrà inserito nel piano DR. In questo caso, inseriremo il nostro gruppo di piani definito dall'utente prima del gruppo di piani incorporato che arresta le VM nell'area 2.
4. Selezionare il gruppo di piani Arresta istanze di computazione (principale) incorporato.
5. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per arrestare EPM System.

Figura 9.3.1: Parametri per creare un gruppo di piani e aggiungere un passo per arrestare i servizi di EPM System

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

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi alle prestazioni di questo passo e alle modalità di funzionamento durante il recupero. In questo caso, interromperà i servizi EPM System nella regione 2.

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

1. Un nome passo descrittivo che spiega il task eseguito da questo passo.
2. Il piano DR deve essere interrotto se lo script non riesce ad arrestare i servizi EPM. Questo permetterà a chiunque di vedere che c'è un problema e risolverlo. Full Stack DR offre l'opportunità di continuare a eseguire il piano di switchover dopo aver risolto il problema.
3. Il valore predefinito prima che OCI Full Stack DR dichiari un errore è di un'ora. Questo valore può essere modificato in 30 minuti o qualsiasi cosa si ritenga essere un valore di timeout più realistico.
4. Selezionare sempre l'area in cui il nodo di controllo DR è in esecuzione in questo momento, non quella in cui verrà eseguito durante uno switchover. OCI Full Stack DR terrà traccia di dove è in esecuzione la VM, quindi devi solo specificare dove si trova in questo momento. In questo caso, il nodo di controllo DR è in esecuzione nell'area 1 (Londra).
5. Selezionare Esegui script locale per informare Full Stack DR che lo script verrà trovato in un'istanza di computazione. Gli script PowerShell di Windows sono stati scaricati nel nodo di controllo DR nel task 1.2.
6. Selezionare il compartimento corretto che contiene il nodo di controllo DR. Quindi selezionare l'istanza di computazione designata come nodo DR Control, in questo esempio si tratta di computazione dell'applicazione EPM System.
7. Incollare il percorso assoluto in cui è stato installato lo script stop_services.ps1 sul nodo di controllo DR. Aggiungere l'arresto come primo parametro e l'ID dell'area OCI come secondo.
8. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

Figura 9.3.2: Parametri per creare un gruppo di piani e aggiungere un passo per avviare i servizi di EPM System

Task 9.3.3: Completare l'aggiunta del gruppo di piani e della fase

1. Il passo per arrestare EPM System viene ora aggiunto al gruppo di piani DR come illustrato nella figura 9.3.3.

   
   Figura 9.3.3: Parametri per creare un gruppo di piani e aggiungere un passo ai servizi di arresto di EPM System

2. Mostra il passo del piano appena aggiunto. È possibile aggiungere ulteriori passi a un gruppo di piani DR, ma questo gruppo di piani includerà solo il passo per arrestare i servizi EPM.

3. Fare clic su Aggiungi per aggiungere il gruppo di piani DR e il passo al piano DR.

   
   Figura 9.3.4: Parametri per creare il gruppo di piani e il gruppo aggiunti ai servizi Stop EPM System

Task 9.4: creare un gruppo di piani per eseguire script personalizzati nell'area 1 (in standby)

Il secondo gruppo di piani definito dall'utente aggiornerà i file host sui nodi di calcolo e avvierà i servizi EPM System dopo l'avvio del nodo DR Control nella standby region 1. Questo gruppo di piani conterrà due passi che richiamano gli script host_switch_failback.ps1 e start_services.ps1 PowerShell scaricati nel nodo di controllo DR nel task 1.2. Lo script host_switch_failback.ps1 inverte le modifiche introdotte dallo script host_switch_failover.ps1 nell'area Newport e ripristina i file host originali sui nodi di calcolo dopo che sono stati spostati di nuovo nell'area primaria originale di Londra.

Task 9.4.1 Creare un gruppo di piani DR per aggiornare il file host dopo lo switchover nell'area di standby

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 dopo il gruppo di piani incorporato che avvia la versione replicata del nodo dell'applicazione EPM System, che esegue anche la funzione del nodo di controllo DR nell'area 1.
3. Selezionare il gruppo di piani Avvia istanze di computazione (in standby) incorporato.
4. Fare clic su Aggiungi passo per aprire la finestra di dialogo in cui verrà specificato lo script per aggiornare il file host.

Figura 9.4.1: Parametri per creare il gruppo di piani e il gruppo aggiunti al file host di aggiornamento

Task 9.4.2: fornire il nome del passo e i parametri dello script locale per lo script di aggiornamento del file host

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi alle prestazioni di questo passo e alle modalità di funzionamento durante il recupero. Lo script host_switch_failback.ps1 aggiorna il file host nel nodo di calcolo. Inverte le modifiche introdotte dallo script host_switch_failback.ps1 nell'area Newport e ripristina il file host originale per l'area 1 (Londra). Ciò consentirà l'avvio dell'applicazione senza ulteriori modifiche nel livello dell'applicazione.

Questo passaggio è lo stesso del task 9.3.2, ad eccezione degli elementi mostrati nella figura.

1. Nome descrittivo che spiega il task eseguito da questo passo.
2. Incollare nel percorso assoluto di PowerShell.exe e nel punto in cui è stato installato lo script host_switch_failover.ps1 sul nodo di controllo DR.
3. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.

Figura 9.4.2: Parametri per creare il gruppo di piani e i dettagli dei passi aggiunti per aggiornare il file host

Task 9.4.3: fornire il nome del passo e i parametri dello script locale per lo script di avvio del servizio EPM System

La finestra di dialogo Aggiungi passo gruppo di piani consente di specificare i parametri relativi alle prestazioni di questo passo e alle modalità di funzionamento durante il recupero. In questo caso, i servizi EPM System inizieranno dalla region 2.

1. Nome descrittivo che spiega il task eseguito da questo passo.
2. Incollare nel percorso assoluto di PowerShell.exe e nel punto in cui è stato installato lo script start_services.ps1 sul nodo di controllo DR.
3. Fare clic su Aggiungi passo per aggiungere questo passo al gruppo di piani.
4. Fare clic su Aggiungi per aggiungere il gruppo di piani che ora contiene due passi per eseguire due script personalizzati.

Il piano di switchover dovrebbe ora includere entrambi i gruppi di piani DR come mostrato nello screenshot seguente.

Figura 9.4.3: Swichover dei gruppi di piani definiti dall'utente

Task 10: personalizzazione del piano di failover nella regione 1 (Londra)

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

Task 10.1: Aggiungi gruppo di piani definito dall'utente al piano di failover

Passare al piano di failover creato nel task 8.

Figura 10.1: Piano di failover nell'area 1

Task 10.1.1: Aggiungi gruppo di piani

1. Assicurati che la standby region 2 sia ancora il contesto della region corrente nella console.
2. Selezionare il piano di failover.
3. Fare clic su Aggiungi gruppo.
4. Specificare il nome del gruppo.
5. Aggiungerlo al piano dopo il passo incorporato Avvia istanza di computazione.

Figura 10.1: Parametri per creare un gruppo di piani per eseguire script personalizzati dopo il failover nell'area 2.

Task 10.1.2: aggiunta di passi al nuovo gruppo di piani definito dall'utente

1. Seguire le istruzioni del task 9.4 per aggiungere due passi al gruppo di piani definito dall'utente per eseguire lo script personalizzato: host_switch_failback.ps1.

   
   Figura 10.2: Parametri per creare il passo del gruppo di piani per lo script di aggiornamento del file host.

2. Aggiungere un secondo passo nel gruppo di piani per avviare i servizi utilizzando lo script start_services.ps1.

   
   Figura 10.3: Parametri per creare il passo del gruppo di piani per lo script di aggiornamento del file host.

3. Dopo aver aggiunto i passi, il gruppo di piani definito dall'utente deve essere simile a questo e fare clic su Aggiungi.

   
   Figura 10.4: gruppo di piani che mostra i passi configurati per eseguire due script locali dopo l'avvio dell'istanza di computazione.

4. Il piano di failover dovrebbe ora includere il gruppo di piani DR definito dall'utente per EPM System, come mostrato nella seguente schermata. È possibile disporre di gruppi di piani aggiuntivi se il gruppo di protezione include altre applicazioni o servizi OCI insieme a EPM System.

   
   Figura 10.5: Piano di failover che mostra i gruppi di piani definiti dall'utente

Passi successivi

A questo punto, OCI Full Stack DR per EPM System dovrebbe essere completamente implementato. Tuttavia, la funzionalità completa deve essere convalidata prima di utilizzarla in produzione. Tutti i piani di failover e switchover devono essere eseguiti per verificare che tutto funzioni come previsto e che il team di recupero comprenda completamente l'intero processo.

Test dei piani di switchover

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

Test dei piani di failover

I failover sono diversi. I failover non possono eseguire il cleanup degli artifact né garantire che i servizi e i database nell'area con errori siano pronti per la transizione dei carichi di lavoro all'area 1. Il team di recupero deve comprendere ed eseguire i task per assicurarsi 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 ripristino deve eseguire una convalida finale per dimostrare la disponibilità dei gruppi di protezione DR OCI Full Stack e dei piani per i carichi di lavoro di produzione. La regione 2 (Newport) deve essere la regione principale in questo punto del processo. Iniziare la convalida finale di tutti i piani completando i passi riportati di seguito.

• Eseguire il test dello switchover dall'area 2 (principale) all'area 1 (in standby).

• Failover dei test dall'area 1 (principale) all'area 2 (in standby).

• Prepara area 1 (primaria) per il failover dall'area 2.

• Failover dei test dall'area 2 (principale) all'area 1 (in standby).

• Prepara area 2 (primaria) per un failover o uno switchover all'area 2.

• Facoltativamente, è inoltre possibile creare e testare i piani Start Drill and Stop Drill in base ai requisiti.

• I gruppi di protezione DR e lo stack di applicazioni devono trovarsi in uno stato operativo normale e pronti per un failover o uno switchover in questo momento.

Collegamenti correlati

• Progetta l'infrastruttura per distribuire Oracle Enterprise Performance Management nel cloud

• Guida alle opzioni di distribuzione: Disaster Recovery per Hyperion EPM System

• Considerazioni sul database: Disaster Recovery per Fusion Middleware

• Posizione script di esempio 1: scaricare gli script di esempio EPM da GitHub

• Posizione script di esempio 2: scaricare gli script di esempio EPM da GitHub

• Playlist di OCI Full Stack DR Oracle EPM in YouTube

  • Video 1: Implementa Oracle EPM per il disaster recovery

  • Video 2: Automatizza le operazioni di disaster recovery per Oracle EPM utilizzando OCI Full Stack DR

  • Video 3: Script utilizzati per automatizzare il ripristino per Oracle EPM

• Recupero in seguito a calamità su Oracle Cloud Infrastructure (OCI) Full Stack

• Documentazione su OCI Full Stack Disaster Recovery

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

• Unisciti al canale slack pubblico #full-stack-dr

Conferme

• Autore - Grzegorz Reizer (esperto Oracle EPM)

• Collaboratore - Suraj Ramesh (Product Manager per OCI Full Stack DR)

Altre risorse di apprendimento

Esplora altri laboratori su docs.oracle.com/learn o accedi a più contenuti gratuiti sulla formazione su Oracle Learning YouTube channel. Inoltre, visita education.oracle.com/learning-explorer per diventare un Oracle Learning Explorer.

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

---

Titolo e informazioni sul copyright

Automate Recovery for Oracle Enterprise Performance Management using OCI Full Stack Disaster Recovery

G11410-01

July 2024

Copyright ©2024,

Oracle e/o relative consociate.