Observação:

• Este tutorial requer acesso ao Oracle Cloud. Para se inscrever em uma conta gratuita, consulte Conceitos básicos do Oracle Cloud Infrastructure Free Tier.
• Ele usa valores de exemplo para credenciais, tenancy e compartimentos do Oracle Cloud Infrastructure. Ao concluir seu laboratório, substitua esses valores por valores específicos do seu ambiente de nuvem.

Automatize a Recuperação para o Oracle Enterprise Performance Management usando o OCI Full Stack Disaster Recovery

Parte 1: Introdução

O Oracle Cloud Infrastructure Full Stack Disaster Recovery (OCI Full Stack DR) orquestra a transição de computação, banco de dados e aplicativos entre regiões da Oracle Cloud Infrastructure (OCI) de todo o mundo com um único clique. Os clientes podem automatizar as etapas necessárias para recuperar um ou mais sistemas de negócios sem reprojetar ou rearquitetar a infraestrutura, os bancos de dados ou os aplicativos existentes.

Este tutorial descreve os procedimentos para utilizar o serviço OCI Full Stack DR para gerenciar processos de switchover e failover para um ambiente de sistema do Oracle Enterprise Performance Management 11.1.2.x e 11.2.x em um framework de recuperação de desastres do OCI. É importante observar que a configuração da topologia do sistema e outras atividades de ciclo de vida (como aplicação de patches, teste, expansão etc.) estão fora do escopo do OCI Full Stack DR.

A estratégia de recuperação de desastre (DR) emprega uma replicação abrangente de volumes de inicialização e em blocos para o aplicativo e o Oracle Data Guard para banco de dados do ambiente de produção para o site stand-by, simplificando bastante a configuração do local stand-by. Esse método está alinhado com as diretrizes de DR descritas no Guia de Opções de Implantação do EPM System, que segue as recomendações para recuperação de desastres fornecidas para o Fusion Middleware.

O Oracle Enterprise Performance Management (Oracle EPM) e o Hyperion EPM são usados de forma intercambiável no tutorial.

O Oracle Enterprise Performance Management Normalmente Faz Parte de um Sistema Maior

Este tutorial pressupõe que o Oracle EPM seja o único aplicativo que está sendo adicionado aos grupos de proteção de DR. Isto não é normal.

Este tutorial se concentra exclusivamente no Oracle EPM System por uma questão de clareza. Na prática, o Oracle EPM geralmente é um componente de um sistema de negócios maior que inclui vários serviços e aplicativos em um único grupo de proteção de DR de pilha completa do OCI e conjunto de planos de DR. Você provavelmente seguirá tutoriais semelhantes do Oracle Help Center (OHC) para outros aplicativos e serviços, como PeopleSoft,Oracle WebLogic Server,Oracle Analytics Cloud,Oracle Integration.

Cuidado com a implementação incremental

A adição de mais membros a um grupo de proteção de DR após a criação de planos de DR excluirá todos os planos de DR existentes nos grupos de proteção em ambas as regiões.

O OCI Full Stack DR foi projetado com a suposição de que toda a pilha de aplicativos para um determinado sistema de negócios já está implantada nas regiões da OCI e o DR manual já foi comprovado para funcionar. Se o seu sistema de negócios incluir mais do que o Oracle EPM, adicione todos os membros de todos os outros aplicativos ou serviços do OCI aos Grupos de Proteção de DR antes de criar qualquer plano de DR.

Como Funciona a Recuperação

A solução de recuperação para o Oracle EPM requer que o OCI Full Stack DR execute uma série de scripts shell personalizados durante uma operação de recuperação, como failover ou switchover. Os scripts mencionados neste tutorial são fornecidos pela equipe de Especialistas em Arquitetura de Nuvem da EMEA e estão disponíveis no repositório do Oracle EPM GitHub especificamente adaptado para esta solução Hyperion EPM DR. Os scripts são transferidos por download para uma instância de computação que faz parte da pilha de aplicativos que o OCI Full Stack DR gerenciará durante uma operação de recuperação.

Este tutorial explica como fazer download dos scripts e como usá-los em uma etapa posterior.

Os scripts a seguir são fornecidos para orientação genérica. Você pode usar seus próprios scripts ou personalizá-los de acordo com a política corporativa e os requisitos de segurança.

Arquitetura de Implantação do Oracle EPM

Neste tutorial, usaremos a topologia de instâncias móveis para o aplicativo Oracle EPM. Em terminologia geral, as instâncias em movimento são chamadas de topologia DR de luz VM/Piloto Fria. As VMs dos aplicativos são implantadas apenas na região principal. Durante o runtime de DR, as VMs serão criadas na região stand-by. O sistema Oracle DB com o Oracle Data Guard deve ser criado na região principal e stand-by. Para que a solução OCI Full Stack DR possa ser implementada, o Hyperion EPM System principal deve ser instalado e totalmente configurado em uma região do OCI.

Esse design é baseado na arquitetura de DR de referência para Hyperion no OCI, que pode ser revisada em detalhes. Para obter mais informações, consulte Projetar a infraestrutura para implantar o Oracle Enterprise Performance Management na nuvem.

Balanceador de Carga do OCI Privado

O tráfego de seus usuários internos e locais flui por meio de túneis IPSec VPN ou circuitos virtuais FastConnect para o gateway de roteamento dinâmico (DRG) anexado à VCN. Um balanceador de carga privado intercepta as solicitações e as distribui para a camada web privada.

A camada Web é hospedada em uma instância de computação anexada a uma sub-rede privada.

Camada de Aplicativos

Todas as instâncias de computação na camada de aplicativos são anexadas a uma sub-rede privada. Esse isolamento no nível da rede protege os aplicativos contra acesso não autorizado à rede e outros recursos na topologia.

O gateway de serviço permite que as instâncias de computação privadas na camada de aplicativos acessem servidores Yum e WSUS na região para obter atualizações do sistema operacional e pacotes adicionais. Além disso, o gateway de serviço permite fazer backup dos aplicativos no OCI Object Storage na região, sem percorrer a internet pública.

Os dados armazenados em volumes em blocos e no sistema de arquivos são replicados para uma região stand-by usando a Replicação entre Regiões (CRR).

Camada do Banco de Dados

O Oracle Base Database Service hospeda os esquemas do EPM System. Os dados são sincronizados com a região stand-by usando o Data Guard.

Fig. 1: Arquitetura de referência do Oracle EPM

Familiarizar-se com todo o processo

As equipes de engenharia de DR EMEA OCI Specialist e OCI Full Stack criaram uma série de vídeos complementares para este tutorial para entender todo o fluxo do processo. Esses vídeos fazem parte de uma lista de reprodução do OCI Full Stack DR Oracle EPM em YouTube que pode ser acessada usando os seguintes links:

• Vídeo 1: Implemente o Oracle EPM para Recuperação de Desastres
• Vídeo 2: Automatize as operações de Recuperação de Desastres para o Oracle EPM usando o OCI Full Stack DR
• Vídeo 3: Scripts usados para automatizar a recuperação do Oracle EPM

Parte 2: Instruções Passo-a-passo

Esta parte inicia as instruções passo a passo necessárias para adicionar o Oracle EPM ao OCI Full Stack DR.

Objetivos

As etapas a seguir serão abordadas neste tutorial explicando como automatizar a recuperação para o Oracle EPM usando o Full Stack DR:

1. Tarefa 1: Implantar o Oracle EPM para Recuperação de Desastres
   1. Configurar um Oracle Data Guard entre regiões para o Oracle Base Database Service
   2. Preparar o Nó de Controle de DR para executar a automação personalizada
   3. Criar grupo de volumes em blocos
   4. Criar políticas do Oracle Cloud Infrastructure Identity and Access Management (OCI IAM) para o Full Stack DR
   5. Criar políticas do OCI IAM para outros serviços do OCI
   6. Criar buckets do OCI Object Storage para logs
   7. Criar balanceador de carga stand-by (opcional)
2. Tarefa 2: Criar Grupos de Proteção de DR (DRPG)
3. Tarefa 3: Adicionar membros a DRPGs da Região 1 e da Região 2
4. Tarefa 4: Criar planos de DR básicos na Região 2 (Newport)
   1. Criar plano de switchover
   2. Criar plano de failover
5. Tarefa 5: Personalizar o plano de switchover na Região 2 (Newport)
6. Tarefa 6: Personalizar o plano de failover na Região 2 (Newport)
7. Tarefa 7: Executar o plano de switchover na Região 2 (Newport)
8. Tarefa 8: Criar planos de DR básicos na Região 1 (Londres)
   1. Criar plano de switchover
   2. Criar plano de failover
9. Tarefa 9: Personalizar o plano de switchover na Região 1 (Londres)
10. Tarefa 10: Personalizar o plano de failover na Região 1 (Londres)

Definições e Suposições em todo o Tutorial

Regiões

Região 1 é Londres

• Londres começa como a principal região. Essa atribuição será alterada para stand-by depois que você for instruído a executar um switchover em etapas posteriores.

Região 2 é Newport

• Newport começará como a região stand-by. Essa função será alterada para principal depois que você for instruído a executar um switchover em etapas posteriores.

Compartimentos

Você pode organizar o Oracle EPM e o OCI Full Stack DR em qualquer esquema de compartimento que funcione de acordo com seus padrões de governança de TI. Optamos por organizar os aplicativos em seus próprios compartimentos individuais e, em seguida, organizar todos os Grupos de Proteção de DR em um único compartimento no qual sistemas de negócios completamente diferentes podem ser vistos rapidamente.

Nó de Controle de DR

O Nó de Controle de DR é qualquer instância de computação designada para hospedar scripts personalizados que executam tarefas específicas para recuperar o EPM System. Os scripts são chamados pelo Full Stack DR durante uma operação de recuperação. Qualquer instância de computação existente que seja membro de um grupo de proteção de DR (DRPG) pode ser o nó de controle. Neste exemplo, o servidor de aplicativos do EPM System hospeda todos os scripts personalizados usados no processo de recuperação. Neste tutorial, o nó do aplicativo e o nó de controle são os mesmos.

Pré-requisitos

• Um EPM System totalmente configurado deve ser implantado em uma região do OCI. Ele deve utilizar um Oracle Base Database Service com uma licença que permita a implantação de um Oracle Data Guard entre regiões.
• VCN e sub-redes na região stand-by. É recomendável espelhar a topografia de rede da região principal na região stand-by. Para replicação do Oracle Data Guard entre regiões, o pareamento de VCN entre regiões principal e stand-by deve ser ativado; portanto, as VCNs não devem ter faixas de CIDR de IP sobrepostas.

Tarefa 1: Implantar o Oracle EPM para Recuperação de Desastres

O OCI Full Stack DR não está envolvido em nenhuma parte desta etapa.

Tarefa 1.1: Configurar um Oracle Data Guard entre Regiões para o Oracle Base Database Service

Para implantar o Oracle Data Guard para Oracle Base Database Service entre regiões, consulte Usar o Oracle Data Guard em um Sistema de Banco de Dados.

Ao sincronizar bancos de dados no sistema com o Oracle Data Guard, é crucial usar o mesmo nome de serviço de banco de dados ou alias TNS para os bancos de dados principal e stand-by. Esta prática minimiza as alterações necessárias na camada de aplicação após um switchover, garantindo uma transição suave. Para obter orientação detalhada, consulte a seção "Considerações do Banco de Dados" na documentação do Fusion Middleware DR, na qual várias abordagens são descritas detalhadamente.

Tarefa 1.2: Preparar o Nó de Controle de DR para Executar a Automação Personalizada

Designe uma instância de computação para atuar como um Nó de Controle de DR para o EPM Full Stack DR. Pode ser uma instância de computação existente ou pode ser uma instância de computação criada apenas para essa finalidade. Consulte as opções abaixo para obter mais detalhes. Certifique-se de que a(s) instância(s) de computação que atua(m) como o Nó de Controle de DR tenha sido configurada para executar comandos usando o Oracle Cloud Agent: Executando Comandos em uma Instância.

É melhor usar uma instância de computação móvel, mas você também poderá designar uma instância de computação não móvel na região 1 e outra na região 2 se não tiver nenhuma computação móvel como parte de sua solução de DR. Você precisará manter as alterações feitas nos scripts ou no sistema operacional convidado em ambas as regiões se a computação não móvel for usada para essa função.

Faça download para o Nó de Controle de DR dos scripts personalizados aqui: Scripts do Oracle EPM Github que foram gravados especificamente para este exemplo de DR do EPM System. Os scripts mostrados abaixo devem ser copiados para qualquer subdiretório na instância de computação que atua como o Nó de Controle de DR. Neste tutorial, vamos usar o nó do aplicativo EPM como nó de controle de DR também. Os scripts foram criados especificamente para este exemplo de recuperação do EPM System e terão que ser modificados para uso em sua solução de recuperação. Neste tutorial, o aplicativo EPM está sendo executado em uma VM do Windows e, portanto, os scripts Powershell (ps1) são usados. Se você usar uma VM Linux, os scripts shell estarão disponíveis no mesmo repositório github. Como estamos usando o EPM VM para executar os scripts, o Nó de Controle de DR é referenciado à mesma VM de EPM.

Tarefa 1.3: Criar Grupo de Volumes em Blocos

Crie um grupo de volumes em blocos na região 1 e certifique-se de que ele seja replicado na região 2. Certifique-se de que o volume de inicialização do Nó de Controle de DR seja membro de um grupo de volumes em blocos e que o grupo de volumes em blocos seja replicado para a região 2. Para obter mais informações, consulte Criando um Grupo de Volumes.

Certifique-se de que qualquer outra inicialização e bloco que pertença a qualquer outra computação móvel para este projeto de DR do OCI Full Stack também pertença ao grupo de volumes em blocos replicado para a região 2.

Tarefa 1.4: Criar Políticas do OCI IAM para o OCI Full Stack DR

Configure as políticas necessárias do OCI IAM para o OCI Full Stack DR, conforme descrito nos documentos a seguir.

• Políticas do OCI Full Stack DR
• Configurando políticas do IAM (Identity and Access Management) para usar o Full Stack DR

Tarefa 1.5: Criar Políticas do OCI IAM para outros Serviços gerenciados pelo OCI Full Stack DR

O OCI Full Stack DR deve ter a capacidade de controlar e gerenciar outros serviços importantes do OCI, como computação, rede, armazenamento, vaults, bancos de dados e outros serviços diversos. Configure as políticas necessárias do OCI IAM para outros serviços explicados aqui: Políticas para Outros Serviços Gerenciados pelo Full Stack Disaster Recovery.

Tarefa 1.6: Criar Buckets do OCI Object Storage para Logs DRPG

Tarefa 1.6.1: Navegar até o OCI Object Storage

Comece navegando até Object Storage & Archive Storage, conforme mostrado na Figura 1.1.

1. Certifique-se de que o contexto do navegador esteja definido como a região 1 (Londres).
2. Selecione Armazenamento.
3. Selecione Buckets.

Figura 1.1: Navegue até o armazenamento de objetos

Tarefa 1.6.2: Bucket do OCI Object Storage na Região 1

Crie um bucket do OCI Object Storage na região 1. Em uma etapa posterior, o bucket será designado ao grupo de proteção de DR na região 1.

1. Selecione o compartimento que contém recursos relacionados ao EPM System.
2. Clique em Criar Bucket.
3. Dê ao bucket um nome significativo que identifique facilmente qual aplicativo e finalidade ele serve.
4. Use o valor padrão para Camada de Armazenamento Padrão e Criptografia.
5. Clique em Criar para criar o bucket.

Figura 1.2: Criar um bucket de armazenamento de objetos na região 1

Tarefa 1.6.3: Bucket do OCI Object Storage na Região 2

Siga o mesmo processo para criar um bucket de armazenamento de objetos na região 2 (Newport). Certifique-se de selecionar a região Newport. Em uma etapa posterior, o bucket será designado ao grupo de proteção de DR na região 2.

1. Altere o contexto para a região 2.
2. Selecione o compartimento que contém recursos relacionados ao EPM System na região 2.
3. Clique em Criar para criar o bucket.

Figura 1.3: Crie um bucket de armazenamento de objetos na região 2

Tarefa 1.7: (Opcional) Criar o Balanceador de Carga do OCI na região stand-by

O uso do Balanceador de Carga do OCI é opcional, se o EPM System não o incluir, ignore esta tarefa.

Crie um Balanceador de Carga do OCI na Região Stand-by:

1. Espelhe a configuração do balanceador de carga principal.
2. Crie um conjunto de backend vazio dentro deste balanceador de carga. Neste ponto da região stand-by, não há backends a serem incluídos na configuração; portanto, apenas um conjunto de backend vazio deve ser criado.

Configuração Durante o Switchover ou o Failover:

1. A configuração do conjunto de backend principal do EPM System será copiada para o conjunto de backend stand-by vazio.

Certificados e Listeners:

1. Se você usar seus próprios certificados, carregue-os no balanceador de carga stand-by.
2. Configure listeners para corresponder à configuração do balanceador de carga principal.

Atualização Pós-Switchover:

1. Após o switchover, atualize as informações de DNS para apontar para o endereço IP do balanceador de carga stand-by.

Para obter mais informações, consulte Visão Geral do Serviço Load Balancer.

Tarefa 2: Criar Grupos de Proteção de DR (DRPG) em ambas as Regiões

Observação: Ignore a Tarefa 2 inteiramente se o Oracle EPM estiver sendo adicionado aos Grupos de Proteção de DR existentes.

Crie grupos de proteção de DR nas regiões 1 e 2 se os grupos de proteção para esta pilha de aplicativos ainda não existirem.

Tarefa 2.1: Navegar até os Grupos de Proteção de DR

Comece navegando até Grupos de Proteção de DR (OCI Full Stack DR), conforme mostrado na Figura 2-1 abaixo.

1. Certifique-se de que o contexto da região do OCI esteja definido como região 1 (Londres).
2. Clique em Migração e Recuperação de Desastre.
3. Clique em Grupos de Proteção de DR.

Figura 2-1: Navegue até grupos de proteção de DR

Tarefa 2.2: Criar um Grupo de Proteção na Região 1

Crie um grupo de proteção de DR (DRPG) básico na região 1, conforme mostrado na Figura 2-2 abaixo. O par, a atribuição e os membros serão designados em etapas posteriores.

1. Selecione o compartimento no qual você deseja que o DRPG seja criado. Pode ser o mesmo compartimento no qual existem recursos do EPM System.
2. Clique em Criar grupo de proteção de DR para abrir a caixa de diálogo.
3. Use um nome significativo para o DRPG.
4. Selecione o bucket de armazenamento de objetos criado na Tarefa 2 para a região 1.
5. Clique em Criar.

Figura 2.2: Parâmetros necessários para criar o grupo de proteção de DR na região 1

Tarefa 2.3: Criar um Grupo de Proteção na Região 2

Crie um grupo de proteção de DR (DRPG) básico na região 2, conforme mostrado na Figura 2-3 abaixo. O par, a atribuição e os membros serão designados em etapas posteriores.

1. Altere o contexto da região do OCI para a região 2 (Newport).
2. Selecione o compartimento no qual você deseja que o DRPG seja criado. Pode ser o mesmo compartimento no qual existem recursos do EPM System.
3. Clique em Criar grupo de proteção de DR para abrir a caixa de diálogo.
4. Use um nome significativo para o DRPG.
5. Selecione o bucket de armazenamento de objetos criado na Tarefa 2 para a região 2.
6. Clique em Criar.

Figura 2-3: Parâmetros necessários para criar o grupo de proteção de DR na região 2

Tarefa 2.4: Associar Grupos de Proteção na Região 1 e na Região 2

Associe os DRPGs em cada região como pares um do outro e designe as atribuições de pares de principal e stand-by. É assim que o OCI Full Stack DR saberá quais duas regiões funcionam juntas para a recuperação do Oracle EPM System. As atribuições principal e stand-by são alteradas automaticamente pelo OCI Full Stack DR como parte de qualquer operação de DR/execução do plano de DR; não há necessidade de gerenciar as atribuições manualmente a qualquer momento.

Tarefa 2.4.1: Iniciar a associação

1. Certifique-se de que o contexto da região do OCI esteja definido como região 1 (Londres).
2. Clique em Associar para iniciar o processo.

Figura 2.4.1: Iniciar associação DRPG

Tarefa 2.4.2: Associar Grupos de Proteção na Região 1 e na Região 2

Forneça os parâmetros conforme mostrado na Figura 2.4.2.

1. Selecione a função principal. O OCI Full Stack DR designará automaticamente a atribuição stand-by à região 2.
2. Selecione a região 2 (Newport), onde o outro DRPG foi criado.
3. Selecione o DRPG par no qual foi criado.
4. Clique em Associar.

Figura 2.4.2: Parâmetros necessários para associar os DRPGs

Tarefa 2.4.3: O que você deve ver após a conclusão da associação

O OCI Full Stack DR mostrará algo como a Figura 2.4.3, depois que a associação for concluída.

1. O atual par primário DRPG é Londres (região 1).
2. O DRPG de par stand-by atual é Newport (região 2).

Figura 2.4.3: Mostrando o relacionamento de pares da perspectiva DRPG individual

As mesmas informações podem ser encontradas sempre que o contexto/exibição for de uma perspectiva global mostrando todos os grupos de proteção de DR, conforme mostrado na Figura 2.4.4 abaixo.

1. O atual par primário DRPG é Londres (região 1).
2. O DRPG de par stand-by atual é Newport (região 2).

Figura 2.4.4: Mostrando o relacionamento de pares da perspectiva global do DRPG

Tarefa 3: Adicionar Membros ao Grupo de Proteção de DR

Observação: Esta tarefa excluirá todos os planos de DR existentes nas duas regiões ao adicionar membros aos Grupos de Proteção de DR existentes. O OCI Full Stack DR não pode salvar cópias ou fazer backups de grupos de proteção de DR no momento desta gravação. Certifique-se de ter registrado todas as informações sobre quaisquer grupos de planos e etapas de DR em um arquivo de texto ou planilha para ajudar a recriar os grupos de planos e etapas personalizados definidos pelo usuário. Você também pode criar scripts bash que chamem comandos da CLI do OCI Full Stack DR para recriar os grupos de planos e as etapas personalizados e definidos pelo usuário (isso está além do escopo deste tutorial).

Adicione o banco de dados e o(s) nó(s) de computação do aplicativo Oracle EPM System como membros dos grupos de proteção de DR. O Nó de Controle de DR é uma instância de computação criada apenas para suportar a orquestração de DR ou uma instância de computação que faz parte da pilha de aplicativos que você deseja gerenciar com o Full Stack DR. Neste exemplo, o nó do aplicativo EPM System também executa a função do Nó de Controle de DR.

Você adicionará os seguintes recursos ao DRPG principal na região 1:

1. O nó de computação do aplicativo EPM System, que também executa a função do nó de Controle de DR.
2. O grupo de volumes contém o volume de inicialização do nó de computação do aplicativo EPM System. Se estiver presente, quaisquer volumes em blocos adicionais anexados aos nós de computação deverão ser incluídos no grupo de volumes.
3. O Oracle Base Database Service principal.
4. O balanceador de carga principal.

Tarefa 3.1: Começar a Adicionar Membros ao DRPG na Região 1

Comece selecionando o DRPG na região 1, conforme mostrado na Figura 3-1.

1. Certifique-se de que o contexto da região do OCI seja a região 1 (Londres).
2. Selecione o DRPG na região 1.
3. Selecione Membros.
4. Clique em Adicionar Membro para iniciar o processo.

Figura 3-1: Como começar a adicionar membros ao grupo de proteção de DR na região 1

Tarefa 3.1.1: Adicionar Instância de Computação para o Nó de Controle DR

Adicione uma instância de computação para o EPM System, que também serve como Nó de Controle de DR, conforme ilustrado na Figura 3.1.1. Neste exemplo, uma única instância de computação hospeda todos os módulos do EPM System. Se o EPM System estiver implantado em um ambiente distribuído com vários nós de computação, certifique-se de que cada nó esteja incluído nesta etapa.

1. Confirme o aviso sobre planos de DR.
2. Informe o serviço Compute como um Tipo de recurso do membro.
3. Selecione a instância de computação do aplicativo EPM System. Essa mesma instância de computação também será usada para executar scripts definidos pelo usuário.
4. Selecione Movendo instância.
5. Adicione o OCI Full Stack DR que a VCN e a sub-rede devem designar à(s) VNIC(s) na região 2 durante uma recuperação. A Figura 4-2 mostra uma única VNIC. O OCI Full Stack DR não se importa com quantas VNICs você tem ou como elas são configuradas em qualquer região; especifique o que você precisa que atenda aos seus requisitos. Certifique-se de fornecer um endereço IP válido da sub-rede de destino na região stand-by. Isso simplificará a atualização de arquivos de host após o switchover, pois a instância de computação usará consistentemente o mesmo endereço IP conhecido.

Figura 3.1.1: Parâmetros necessários para adicionar o Nó de Controle DR

Tarefa 3.1.2: Adicionar Grupo de Volumes em Blocos para o Nó de Controle DR

Adicione o grupo de volumes em blocos que contém volumes em blocos e de inicialização anexados ao nó do aplicativo EPM System. O grupo de volumes em blocos já deve ter uma replicação entre regiões configurada entre as duas regiões antes de adicioná-la ao grupo de proteção de DR.

1. Selecione Grupo de volumes como Tipo de recurso do membro.
2. Certifique-se de que o compartimento correto que contém o grupo de volumes esteja selecionado e, em seguida, selecione o grupo de volumes.

Figura 3.1.2: Parâmetros necessários para adicionar o grupo de volumes de inicialização para Computação EPM

Tarefa 3.1.3: Adicionar Oracle Base Database Service Principal

Nesse ponto, o Oracle Data Guard já deve estar configurado para o sistema de serviço do Oracle Base Database como parte da Tarefa 1. Adicione o banco de dados principal como membro do DRPG na região 1.

1. Selecione Banco de Dados como Tipo de recurso do membro.
2. Certifique-se de que o compartimento correto do banco de dados esteja selecionado.
3. Forneça detalhes do segredo no OCI Vault que contém a senha do usuário SYS do banco de dados do EPM. Você criou esse segredo durante a configuração do Oracle Data Guard na Tarefa 1.

Figura 3.1.3: Parâmetros necessários para adicionar o BD Principal em execução do serviço de BD Base

Tarefa 3.1.4: Adicionar Balanceador de Carga do OCI

Neste exemplo, estamos adicionando o balanceador de carga como membro do DRPG na região 1.

1. Selecione Balanceador de Carga como Tipo de recurso do membro.
2. Certifique-se de que os compartimentos corretos do balanceador de carga estejam selecionados.
3. Selecione Conjunto de Backend de Origem: Este é o conjunto de backend usado pelo aplicativo EPM System. Um Balanceador de Carga do OCI pode ser compartilhado entre vários aplicativos e pode ter vários conjuntos de backend configurados. Durante um switchover de DR, somente os conjuntos de backend especificados aqui terão sua configuração movida para a região stand-by.
4. Selecione Conjunto de Backend de Destino: Este é o conjunto de backend vazio criado na Tarefa 1.7 na região 2.

Figura 3.1.4: Parâmetros necessários para adicionar o Balanceador de Carga

Tarefa 3.1.5: Verificar Recursos do Membro para a Região 1

O DRPG para a região 1 agora deve ter quatro recursos membros, conforme mostrado na Figura 3.1.5. Os nomes dos recursos dos membros serão diferentes.

1. O banco de dados principal.
2. A instância de computação móvel.
3. Grupo de volumes em blocos para a instância de computação.
4. Balanceador de carga do OCI

Figura 3.1.5: Mostrando membros do DRPG na região 1

Tarefa 3.2: Começar a Adicionar Membros ao DRPG na Região 2

Comece selecionando o DRPG na região 2.

1. Certifique-se de que o contexto da região do OCI seja a região 2 (Newport).
2. Selecione o DRPG na região 2.
3. Clique em Membros.
4. Clique em Adicionar Membro para iniciar o processo.

Você adicionará os seguintes recursos ao DRPG stand-by na região 2 seguindo etapas semelhantes à da região principal:

1. O sistema stand-by/remoto do Oracle Base Database Service.
2. Balanceador de Carga do OCI Stand-by.

Uma vez concluída a tarefa, o DRPG para a região 2 deve ter dois recursos membros, conforme mostrado na Figura 3.2 abaixo.

Figura 3.2: Mostrando membros do DRPG na região 2

Tarefa 4: Criar Planos Básicos de DR na Região 2 (Newport)

Esta etapa cria planos básicos de switchover e failover associados ao Grupo de Proteção de DR stand-by na região 2 (Newport).

O objetivo de cada plano é fazer a transição da carga de trabalho da região principal 1 para a região stand-by 2. As atribuições dos grupos de proteção de DR em ambas as regiões são revertidas automaticamente como parte de qualquer operação de DR; portanto, o grupo de proteção na região 1 se tornará o stand-by e o grupo de proteção na região 2 se tornará principal após um failover ou switchover.

O OCI Full Stack DR preencherá previamente os dois planos com etapas incorporadas com base nos recursos de membro adicionados nas tarefas anteriores. Os planos serão personalizados em etapas posteriores para lidar com todas as tarefas relacionadas ao EPM System durante uma operação de recuperação.

Os planos de switchover são sempre criados no grupo de proteção com a atribuição stand-by; no momento, a região 2 é o grupo de proteção stand-by; portanto, começaremos em Newport.

Tarefa 4.1: Criar Planos de DR

Crie um plano básico selecionando o DRPG na região 2 (Newport)

1. Certifique-se de que o contexto da região do OCI seja a região 2 (Newport).
2. Selecione o DRPG stand-by na região 2.
3. Selecione Planos.
4. Clique em Criar Plano para iniciar o processo.

Figura 4-1: Como começar a criar planos básicos de DR na região 2

Tarefa 4.1.1: Criar um Plano de Switchover

A criação de um plano de DR é simples, conforme mostrado na Figura 4.1.1 abaixo.

1. Torne o nome do plano de switchover simples, mas significativo. O nome deve ser o mais curto possível, mas fácil de entender rapidamente para ajudar a reduzir a confusão e o erro humano durante uma crise.
2. Selecione o tipo de plano como Switchover (planejado). Há apenas quatro tipos de plano no momento desta redação.

Figura 4.1.1: Os parâmetros necessários para criar o plano de switchover de DR

Tarefa 4.1.2: Criar um Plano de Failover

Siga o mesmo processo para criar um plano de failover básico, conforme mostrado na Figura 4.1.2 abaixo.

1. Torne o nome do plano de failover simples, mas significativo. O nome deve ser o mais curto possível, mas fácil de entender rapidamente para ajudar a reduzir a confusão e o erro humano durante uma crise.
2. Selecione o tipo de plano como Failover (não planejado). Há apenas quatro tipos de plano no momento desta redação.

Figura 4.1.2: Os parâmetros necessários para criar o plano de failover de DR

O Grupo de Proteção de DR stand-by na região 2 agora deve ter os dois planos de DR, conforme mostrado na imagem a seguir. Eles lidarão com a transição de cargas de trabalho da região 1 para a região 2. Você criará planos semelhantes na região 1 para fazer a transição de cargas de trabalho da região 2 de volta para a região 1 em uma tarefa posterior.

Figura 4.1.3: Mostrando os dois planos básicos de DR que devem existir na região 2 antes de continuar

Tarefa 5: Personalizar o Plano de Switchover na Região 2 (Newport)

Os planos básicos de DR criados na Tarefa 4 contêm etapas pré-preenchidas para tarefas de recuperação que são incorporadas ao Full Stack DR e não contêm nada para gerenciar tarefas de recuperação específicas do aplicativo EPM System. Esta etapa explica como adicionar Grupos de Planos de DR personalizados e definidos pelo usuário e etapas para gerenciar as tarefas que precisam ser realizadas durante um switchover para o EPM System:

• Interrompa os serviços do EPM System na região principal 1 atual antes de interromper qualquer VM.
• Atualize os arquivos do host no nó de computação para mapear endereços IP stand-by para nomes de host da região principal.
• Inicie os serviços do EPM System na região stand-by 2 atual após iniciar qualquer VM.

Tarefa 5.1: Selecionar o Plano de Switchover

Navegue até o plano de switchover criado na Tarefa 4.

Figura 5.1: Como começar a personalizar o plano de switchover na região 2

Tarefa 5.2: (Opcional) Ativar Grupos de Planos de DR que Encerram Artefatos

Há dois grupos de planos que são desativados por padrão nos planos de switchover, conforme mostrado na captura de tela a seguir. Eles são desativados para fornecer um nível de conforto durante o teste de que nada está realmente sendo excluído e você ainda tem uma cópia viável dos artefatos como backup no caso de algo dar errado durante o teste.

No entanto, esses dois grupos de planos encerram (excluem) artefatos que nunca serão usados novamente como parte de qualquer operação de DR no futuro. Os artefatos simplesmente continuarão a se acumular ao longo do tempo à medida que você alterna entre as duas regiões, causando confusão sobre quais instâncias de computação e grupos de volumes são as que realmente devem estar ativas.

Esses grupos de planos devem ser ativados assim que o OCI Full Stack DR entrar em produção. Todos os artefatos que foram deixados no local durante o teste de switchovers e switchbacks enquanto esses dois grupos de planos foram desativados devem ser encerrados e limpos antes de entrar em produção para reduzir a confusão e a probabilidade de erro humano durante operações normais.

Opcionalmente, esses grupos de planos podem ser ativados agora para evitar a necessidade de limpar manualmente os artefatos supérfluos antes de entrar em produção.

Figura 5.2: Grupos de planos desativados por padrão

Veja o que os grupos de planos desativados fazem quando estão ativados:

1. Este grupo de planos encerra artefatos de instâncias de computação que são deixados para trás na região 1 depois que as versões replicadas das VMs foram iniciadas na região 2 durante a operação do OCI Object Storage para reverter a replicação da região 2 de volta para a região 1 como parte do switchover. As VMs restantes não são usadas durante um switchback porque a operação para reverter a replicação de volume em blocos cria todas as novas VMs em grupos de volumes em blocos completamente novos.

2. Este grupo de planos encerra artefatos de grupos de volumes em blocos (VGs) que são deixados para trás na região 1 depois que as versões replicadas dos VGs foram ativadas na região 2 e a replicação do grupo de volumes foi revertida durante o switchover. Os grupos de volumes em blocos restantes nunca são usados novamente, nem mesmo como parte de um switchover da região 2 de volta para a região 1.

Tarefa 5.2.1: Ativar Encerrar Grupo de Planos de Computação

Ative o grupo de planos.

1. Selecione Ativar todas as etapas no menu de contexto à direita do nome do grupo de planos.

   
   Figura 5.2.1: Como ativar instâncias de computação de encerramento

Tarefa 5.2.2 Ativar grupo de planos de grupos de volumes de encerramento

Ative o grupo de planos.

1. Selecione Ativar todas as etapas no menu de contexto à direita do nome do grupo de planos.

   
   Figura 5.2.2: Como ativar grupos de volumes de encerramento

Tarefa 5.3: Criar um grupo de Planos para Executar Scripts Personalizados na Região 1 (principal)

Comece a adicionar Grupos de Planos de DR personalizados e definidos pelo usuário.

O primeiro grupo de planos definido pelo usuário executará scripts personalizados para interromper a execução dos serviços do EPM System na região principal 1. Esse grupo de planos conterá uma única etapa que chama o script PowerShell do Windows stop_services.ps1, que foi baixado para a pasta c:/scripts no nó do Aplicativo EPM na Tarefa 1.2.

Tarefa 5.3.1: Selecionar Adicionar Grupo de Planos

Inicie o processo de adição de um grupo de planos.

1. Clique em Adicionar grupo para começar.
2. Dê ao grupo de planos um nome simples, mas descritivo. Isso é opcional, mas a melhor prática é adicionar uma observação sobre qual região o grupo de planos executará as etapas.
3. Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Nesse caso, vamos inserir nosso grupo de planos definido pelo usuário antes do grupo de planos incorporado que interrompe as VMs na região 1.
4. Selecione o grupo de planos incorporado Interromper Instâncias do Serviço Compute (principal).
5. Clique em Adicionar Etapa para abrir a caixa de diálogo em que especificaremos o script para interromper o EPM System.

Figura 5.3.1: Parâmetros para criar grupo de planos e adicionar etapa para interromper o EPM

Tarefa 5.3.2: Fornecer Nome da Etapa e Parâmetros de Script Local

A caixa de diálogo Adicionar etapa do grupo de planos nos permite especificar parâmetros sobre o que essa etapa executará e como ela se comportará durante a recuperação. Nesse caso, ele interromperá os serviços do EPM System na região 1.

Explicaremos todos os campos nesta caixa de diálogo, mas deixaremos de fora esse detalhe em todas as capturas de tela restantes nas etapas subsequentes, pois estamos apenas executando o mesmo processo repetidamente.

1. Um Nome da etapa descritivo que explica qual tarefa essa etapa executa.
2. Sempre selecione a região em que o nó do Aplicativo EPM está sendo executado agora, não onde ele estará sendo executado durante um switchover. O OCI Full Stack DR rastreará onde a VM está em execução; portanto, você só precisa especificar onde ela está no momento. Nesse caso, o nó do Aplicativo EPM está em execução na região 1 (Londres).
3. Selecione o compartimento correto que contém o Nó de Controle DR. Em seguida, selecione a instância de computação designada como o Nó de Controle de DR; neste exemplo, é a computação do aplicativo do EPM system.
4. Selecione Executar script local para informar ao OCI Full Stack DR que o script será encontrado em uma instância de computação. Os scripts PowerShell do Windows foram transferidos por download para o Nó de Controle DR na Tarefa 1.2.
5. Cole no caminho absoluto em que você instalou o script stop_services.ps1 no Nó de Controle DR. Adicione stop como o primeiro parâmetro e o ID da região do OCI como o segundo.
6. O plano de DR deverá ser interrompido se o script falhar ao interromper o EPM Services. Isso permitirá que qualquer pessoa veja que há um problema e corrija-o. O OCI Full Stack DR fornece a oportunidade de continuar executando o plano de switchover após corrigir o problema.
7. O valor padrão antes de o Full Stack DR declarar uma falha é de uma hora. Esse valor pode ser alterado para 30 minutos ou o que for considerado um valor de tempo limite mais realista.
8. Clique em Adicionar etapa para adicioná-la ao grupo de planos.

Figura 5.3.2: Parâmetros para criar a etapa do plano para interromper o EPM

Tarefa 5.3.3: Concluir Adição de Grupo de Planos e Etapa

A etapa para interromper o EPM System agora foi adicionada ao grupo de planos de DR, conforme mostrado na Figura 5.3.3 abaixo.

Isso mostra a etapa do plano que acabou de ser adicionada. É possível adicionar etapas adicionais a um grupo de planos de DR, mas esse grupo de planos incluirá apenas a etapa para interromper o EPM Services. Clique em Adicionar para adicionar o grupo de planos de DR e a etapa ao plano de DR.

Figura 5.3.3: Finalize a adição de grupo de planos e etapa para interromper o EPM

Tarefa 5.4: Criar Grupo de Planos para Executar Scripts Personalizados na Região 2 (Stand-by)

O segundo grupo de planos definido pelo usuário atualizará os arquivos do host nos nós de computação e iniciará os serviços do EPM System depois que o Nó de Controle de DR for iniciado na região stand-by 2. Este grupo de planos conterá duas etapas que chamam os scripts host_switch_failover.ps1 e start_services.ps1 PowerShell que foram submetidos a download para o Nó de Controle de DR na Tarefa 1.2.

Tarefa 5.4.1 Criar um Grupo de Planos de DR para Atualizar o Arquivo de Host após o Switchover para a Região Stand-by

1. Dê ao grupo de planos um Nome de grupo simples, mas descritivo.
2. Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Nesse caso, vamos inserir nosso grupo de planos definido pelo usuário após o grupo de planos incorporado que inicia a versão replicada do nó do aplicativo EPM System, que também executa a função do nó de controle DR na região 2.
3. Selecione o grupo de planos Iniciar Instâncias de Computação incorporado
4. Clique em Adicionar etapa para abrir a caixa de diálogo em que especificaremos o script para atualizar o arquivo do host.

Figura 5.4.1: Parâmetros para criar a etapa do plano para iniciar o EPM

Tarefa 5.4.2: Fornecer Nome da Etapa e Parâmetros de Script Local para o Script de Atualização do Arquivo do Host

A caixa de diálogo Adicionar etapa do grupo de planos nos permite especificar parâmetros sobre o que essa etapa executará e como ela se comportará durante a recuperação. O script host_switch_failover.ps1 atualiza o arquivo do host no nó de computação para que os novos endereços IP das instâncias de computação e banco de dados na região 2 sejam mapeados para o nome do host da região 1 original. Isso permitirá que o aplicativo seja iniciado sem modificações adicionais na camada do aplicativo.

Esta etapa é a mesma que a Tarefa 5.3.2, exceto para os itens mostrados na Figura 5.4.2 abaixo.

1. Um Nome da etapa descritivo que explica qual tarefa essa etapa executa.
2. Cole no caminho absoluto para PowerShell.exe e onde você instalou o script host_switch_failover.ps1 no nó do Aplicativo EPM.
3. Clique em Adicionar etapa para adicioná-la ao grupo de planos.

Figura 5.4.2: Parâmetros para atualizar o arquivo do host

Tarefa 5.4.3: Fornecer Nome da Etapa e Parâmetros de Script Local para o Script Inicial do EPM System Service

A caixa de diálogo Adicionar etapa do grupo de planos nos permite especificar parâmetros sobre o que essa etapa executará e como ela se comportará durante a recuperação. Nesse caso, os serviços do sistema EPM começarão na região 2.

1. Um Nome da etapa descritivo que explica qual tarefa essa etapa executa.
2. Cole no caminho absoluto para PowerShell.exe e onde você instalou o script start_services.ps1 no nó do Aplicativo EPM.
3. Clique em Adicionar etapa para adicioná-la ao grupo de planos.
4. Clique em Adicionar para adicionar o grupo de planos que agora contém duas etapas para executar dois scripts personalizados.

Figura 5.4.3: Parâmetros para iniciar o EPM

O plano de switchover agora deve incluir ambos os Grupos de Planos de DR, conforme mostrado na captura de tela a seguir.

Figura 5.4.4: Script personalizado após a inicialização

Tarefa 6: Personalizar o Plano de Failover na Região 2 (Newport)

Esta tarefa explica como adicionar Grupos de Planos de DR personalizados e definidos pelo usuário e etapas para gerenciar as tarefas que precisam ser realizadas durante um failover para o EPM System na região 2 durante uma interrupção real ou perda de acesso à região 1. Essas etapas serão um subconjunto das mesmas etapas que foram adicionadas ao plano de switchover na Tarefa 5 acima. No entanto, somente as etapas executadas na região stand-by 2 serão adicionadas ao plano de failover, pois supõe-se que a região 1 esteja completamente inacessível durante um failover.

Tarefa 6.1: Selecionar o Plano de Failover

Comece navegando até o plano de failover criado na Tarefa 5.

1. Certifique-se de que a região stand-by 2 ainda seja o contexto da região atual na console.
2. Selecione o plano de failover.

Figura 6-1: Como criar a personalização inicial do plano de failover na região 2.

Tarefa 6.1.2: Adicionar Etapas ao novo grupo de Planos definido pelo usuário

1. Clique em Adicionar Grupo.

   
   Figura 6.1.2 Parâmetros para criar a etapa do plano para iniciar o EPM

2. Siga as instruções da tarefa 5.4 para adicionar duas etapas ao grupo de planos definido pelo usuário para executar scripts personalizados: host_switch_failover.ps1 e start_services.ps1.

3. Depois de adicionar etapas e o grupo de planos definido pelo usuário, seu plano de failover deve ter esta aparência:

   
   Figura 6.1.3 Parâmetros para criar a etapa do plano para iniciar o EPM e atualizar hosts

Tarefa 7: Executar o Plano de Switchover na Região 2 (Newport)

Os planos de DR de switchover e failover foram concluídos na região stand-by 2 (Newport). Os planos de DR na região 2 permitem que o OCI Full Stack DR faça a transição de cargas de trabalho da região 1 para a região 2. A próxima tarefa é criar planos de switchover e failover no grupo de proteção para a região 1 (Londres) para que o OCI Full Stack DR possa fazer a transição de cargas de trabalho da região 2 de volta para a região 1.

No entanto, os planos de DR só podem ser criados e modificados no grupo de proteção com a atribuição stand-by. O grupo de proteção de DR na região 1 é atualmente o principal, o que significa que os planos de DR não podem ser criados na região 1.

Portanto, precisamos reverter as atribuições dos grupos de proteção para que a região 1 seja a stand-by e a região 2 seja a principal. Execute o plano de switchover que acabou de ser criado para fazer a transição da carga de trabalho da região 1 (Londres) para a região 2 (Newport).

Tarefa 7.1: Iniciar Execução do Plano

Execute o plano de DR para iniciar o processo de transição da carga de trabalho do EPM System da região 1 para a região 2.

1. Certifique-se de que o contexto da região ainda esteja definido como região stand-by 2 (Newport).
2. Use as trilhas de navegação na parte superior da console para ajudar a garantir que os detalhes do grupo de proteção de DR sejam o contexto do plano atual.
3. Certifique-se de que o grupo de proteção de DR correto na região 2 esteja selecionado; ele deve ser a atribuição stand-by.
4. Antes de continuar, certifique-se de que os planos de failover e switchover existam; caso contrário, volte às tarefas anteriores para criar ambos os planos de DR.
5. Clique em Executar plano de DR.

Figura 7-1: Mostrando como executar um switchover para a região stand-by

Tarefa 7.2: Selecionar Plano de Switchover e Executar

Esta tarefa executa o plano de switchover na região 2.

1. Selecione o plano de switchover.
2. Selecione Ativar pré-verificações.
3. Clique em Executar plano de DR para começar.

Figura 7.2: Escolha e execute o plano de switchover

Tarefa 7.3: Próximas etapas

Monitore o plano de switchover até que a carga de trabalho do EPM System tenha sido totalmente transferida da região 1 para a região 2. O Full Stack DR limpará artefatos e alterará as atribuições principal e stand-by entre as regiões. No caso, se a execução do plano de switchover falhar, verifique os logs e certifique-se de que o plano seja executado com sucesso.

Depois que o Full Stack DR concluir o switchover, a região 2 (Newport) se tornará a região principal e a região 1 (Londres) será a região stand-by.

Tarefa 8: Criar planos de DR na região 1 (Londres)

Crie os mesmos planos básicos de switchover e failover no Grupo de Proteção de DR para a região 1 (Londres), que agora é o par stand-by.

Cada plano tem como objetivo fazer a transição da carga de trabalho da região 2 para a região 1 sempre que a região 2 for a principal par. Como parte de qualquer operação de DR, as atribuições dos grupos de proteção de DR em ambas as regiões são revertidas automaticamente, de modo que o grupo de proteção de DR na região 2 se tornará o stand-by e o grupo de proteção de DR na região 1 se tornará o principal após um failover ou switchover.

O OCI Full Stack DR preencherá previamente os dois planos com etapas incorporadas com base nos recursos do membro adicionados na tarefa anterior. Em etapas posteriores, os planos serão personalizados para lidar com todas as tarefas relacionadas ao EPM System durante uma operação de recuperação.

Os planos de switchover são sempre criados no grupo de proteção com a atribuição stand-by; no momento, a região 1 é o grupo de proteção stand-by após a execução do plano de switchover na Tarefa 8.

Tarefa 8.1: Criar planos de DR

Crie um plano básico selecionando o DRPG na região 1, conforme mostrado na Figura 8.1.

1. Certifique-se de que o contexto da região do OCI seja a região 1 (Londres).
2. Selecione o DRPG stand-by na região 1.
3. Selecione Planos.
4. Clique em Criar Plano para iniciar o processo.
5. Torne o nome do plano de switchover simples, mas significativo. O nome deve ser o mais curto possível, mas fácil de entender rapidamente para ajudar a reduzir a confusão e o erro humano durante uma crise.
6. Selecione Tipo de plano como Switchover (planejado). Há apenas quatro tipos de plano no momento desta redação.
7. Clique em Criar para criar um plano de switchover básico pré-preenchido com etapas básicas incorporadas.

Figura 8.1: Os parâmetros necessários para criar o plano de switchover de DR

Tarefa 8.2: Criar um Plano de Failover

Siga o mesmo processo para criar um plano de failover básico, conforme mostrado na Figura 8.2.

1. Torne o Nome do plano de failover simples, mas significativo. O nome deve ser o mais curto possível, mas fácil de entender rapidamente para ajudar a reduzir a confusão e o erro humano durante uma crise.

2. Selecione Tipo de plano como Failover (não planejado). Há quatro tipos de plano no momento da redação.

3. Clique em Criar para criar um plano de failover básico pré-preenchido com etapas básicas incorporadas.

Figura 8.2: Os parâmetros necessários para criar o plano de failover de DR

O Grupo de Proteção de DR stand-by na região 1 agora deve ter os dois planos de DR, conforme mostrado abaixo. Eles tratarão da transição de cargas de trabalho da região 2 de volta para a região 1.

Figura 8.3: Mostrando os dois planos básicos de DR que devem existir na região 2 antes de continuar

Tarefa 9: Personalizar o Plano de Switchover na Região 1 (Londres)

Tudo sobre esta tarefa é quase exatamente o mesmo que fizemos na Tarefa 5 para a região 2, exceto que isso está sendo feito na região 1.

Os planos básicos de DR criados na Tarefa 8 contêm etapas pré-preenchidas para tarefas de recuperação que são incorporadas ao OCI Full Stack DR e não contêm nada para gerenciar tarefas de recuperação específicas do aplicativo EPM System. Esta etapa explica como adicionar Grupos de Planos de DR personalizados e definidos pelo usuário e etapas para gerenciar as tarefas que precisam ser realizadas durante um switchover para o EPM System:

• Interrompa os serviços do EPM System na região principal 1 atual antes de interromper qualquer VM.
• Atualize os arquivos do host no nó de computação para mapear endereços IP stand-by para nomes de host da região principal.
• Inicie os serviços do EPM System na região stand-by 2 atual após iniciar qualquer VM.

Tarefa 9.1: Selecionar o Plano de Switchover

Navegue até o plano de switchover criado na tarefa anterior.

Figura 9-1: Como começar a personalizar o plano de switchover na região 1

Tarefa 9.2: (Opcional) Ativar Grupos de Planos de DR que Encerram Artefatos

Estas são as mesmas etapas executadas para a região 2 em uma tarefa anterior; o mesmo processo precisa ser seguido para a região 1.

Dois grupos de planos são desativados por padrão nos planos de switchover, conforme mostrado na captura de tela abaixo. Eles são desativados para fornecer um nível de conforto durante o teste de que nada está realmente sendo excluído, e você ainda tem uma cópia viável dos artefatos como backup no caso de algo dar errado durante o teste.

No entanto, esses dois grupos de planos encerram (excluem) artefatos que nunca serão usados novamente como parte de qualquer operação de DR no futuro. Os artefatos simplesmente continuarão a se acumular ao longo do tempo à medida que você alterna entre as duas regiões, causando confusão para os humanos sobre quais instâncias de computação e grupos de volumes são os que realmente devem estar ativos.

Esses grupos de planos devem ser ativados assim que o OCI Full Stack DR entrar em produção. Todos os artefatos que foram deixados no local durante o teste de switchovers e switchbacks enquanto esses dois grupos de planos foram desativados devem ser encerrados e limpos antes de entrar em produção para reduzir a confusão e a probabilidade de erro humano durante operações normais.

Opcionalmente, esses grupos de planos podem ser ativados agora para evitar a necessidade de limpar manualmente os artefatos supérfluos antes de entrar em produção.

Figura 9-2: Grupos de planos desativados por padrão

Veja o que os grupos de planos desativados fazem quando estão ativados:

1. Este grupo de planos encerra artefatos de instâncias de computação que são deixados para trás na região 2 depois que as versões replicadas das VMs foram iniciadas na região 1 durante a operação de armazenamento em blocos do OCI para reverter a replicação da região 1 de volta para a região 2 como parte do switchover. As VMs restantes não são usadas durante um switchback porque a operação para reverter a replicação de volume em blocos cria todas as novas VMs em grupos de volumes em blocos completamente novos.

2. Este grupo de planos encerra artefatos de grupos de volumes em blocos (VGs) que são deixados para trás na região 2 depois que as versões replicadas dos VGs foram ativadas na região 1 e a replicação do grupo de volumes foi revertida durante o switchover. Os grupos de volumes em blocos restantes nunca são usados novamente, nem mesmo como parte de um switchover da região 1 de volta para a região 2.

Tarefa 9.2.1: Ativar grupo Encerrar Plano de Computação

Ative o grupo de planos.

1. Selecione Ativar todas as etapas no menu de contexto à direita do nome do grupo de planos

   
   Figura 9.2.1: Como ativar instâncias de computação de encerramento

Tarefa 9.2.2 Ativar grupo de planos de grupos de volumes de encerramento

Ative o grupo de planos.

1. Selecione Ativar todas as etapas no menu de contexto à direita do nome do grupo de planos

   
   Figura 9.2.2: Como ativar grupos de volumes de encerramento

Tarefa 9.3: Criar Grupo de Planos para Executar Scripts Personalizados na Região 2 (Principal)

Comece a adicionar Grupos de Planos de DR personalizados e definidos pelo usuário.

O primeiro grupo de planos definido pelo usuário executará scripts personalizados para interromper a execução dos serviços do EPM System na região principal 2. Este grupo de planos conterá uma única etapa que chama o script PowerShell do Windows stop_services.ps1 baixado para a pasta c:/scripts no Nó de Controle de DR na Tarefa 1.2.

Tarefa 9.3.1: Selecionar Adicionar Grupo de Planos

Inicie o processo para adicionar um grupo de planos.

1. Clique em Adicionar grupo para começar.
2. Dê ao grupo de planos um nome simples, mas descritivo.
3. Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Nesse caso, vamos inserir nosso grupo de planos definido pelo usuário antes do grupo de planos incorporado que interrompe as VMs na região 2.
4. Selecione o grupo de planos Interromper Instâncias de Computação (Principal) incorporado.
5. Clique em Adicionar etapa para abrir a caixa de diálogo em que especificaremos o script para interromper o EPM System.

Figura 9.3.1: Parâmetros para criar grupo de planos e adicionar etapa para interromper os serviços do sistema EPM

Tarefa 9.3.2: Fornecer Nome da Etapa e Parâmetros de Script Local

A caixa de diálogo Adicionar etapa do grupo de planos nos permite especificar parâmetros sobre o que essa etapa executará e como ela se comportará durante a recuperação. Nesse caso, ele interromperá os serviços do EPM System na região 2.

Explicaremos todos os campos nesta caixa de diálogo, mas deixaremos de fora esse detalhe em todas as capturas de tela restantes nas etapas subsequentes, pois estamos apenas executando o mesmo processo repetidamente.

1. Um Nome da etapa descritivo que explica qual tarefa essa etapa executa.
2. O plano de DR deverá ser interrompido se o script falhar ao interromper o EPM Services. Isso permitirá que qualquer pessoa veja que há um problema e corrija-o. O Full Stack DR fornece a oportunidade de continuar executando o plano de switchover após corrigir o problema.
3. O valor padrão antes de o OCI Full Stack DR declarar uma falha é de uma hora. Esse valor pode ser alterado para 30 minutos ou o que for considerado um valor de tempo limite mais realista.
4. Sempre selecione a região em que o Nó de Controle DR está em execução no momento, e não a região em que ele estará em execução durante um switchover. O OCI Full Stack DR rastreará onde a VM está em execução; portanto, você só precisa especificar onde ela está no momento. Nesse caso, o Nó de Controle DR está em execução na região 1 (Londres).
5. Selecione Executar script local para informar ao Full Stack DR que o script será encontrado em uma instância de computação. Os scripts PowerShell do Windows foram transferidos por download para o Nó de Controle DR na Tarefa 1.2.
6. Selecione o compartimento correto que contém o Nó de Controle DR. Em seguida, selecione a instância de computação que foi designada como o Nó de Controle de DR. Neste exemplo, é a computação do aplicativo do sistema EPM.
7. Cole no caminho absoluto em que você instalou o script stop_services.ps1 no Nó de Controle DR. Adicione stop como o primeiro parâmetro e o ID da região do OCI como o segundo.
8. Clique em Adicionar etapa para adicioná-la ao grupo de planos.

Figura 9.3.2: Parâmetros para criar grupo de planos e adicionar etapa para iniciar serviços do sistema EPM

Tarefa 9.3.3: Concluir Adição de Grupo de Planos e Etapa

1. A etapa para interromper o EPM System agora é adicionada ao grupo de planos de DR, conforme mostrado na figura 9.3.3.

   
   Figura 9.3.3: Parâmetros para criar grupo de planos e adicionar etapa aos serviços Interromper sistema EPM

2. Isso mostra a etapa do plano que acabou de ser adicionada. É possível adicionar etapas adicionais a um grupo de planos de DR, mas esse grupo de planos incluirá apenas a etapa para interromper o EPM Services.

3. Clique em Adicionar para adicionar o grupo de planos de DR e a etapa ao plano de DR.

   
   Figura 9.3.4: Parâmetros para criar grupo e grupo de planos adicionados aos serviços Stop EPM system

Tarefa 9.4: Criar grupo de Planos para Executar Scripts Personalizados na Região 1 (Stand-by)

O segundo grupo de planos definido pelo usuário atualizará os arquivos do host nos nós de computação e iniciará os serviços do EPM System depois que o Nó de Controle de DR for iniciado na região stand-by 1. Este grupo de planos conterá duas etapas que chamam os scripts host_switch_failback.ps1 e start_services.ps1 PowerShell que foram submetidos a download para o Nó de Controle de DR na Tarefa 1.2. O script host_switch_failback.ps1 reverte as alterações introduzidas pelo script host_switch_failover.ps1 na região Newport e restaura os arquivos do host original nos nós de computação depois que eles são movidos de volta para a região principal original de Londres.

Tarefa 9.4.1 Criar um Grupo de Planos de DR para Atualizar o arquivo Host após o Switchover para a Região Stand-by

1. Dê ao grupo de planos um nome simples, mas descritivo.
2. Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Nesse caso, vamos inserir nosso grupo de planos definido pelo usuário após o grupo de planos incorporado que inicia a versão replicada do nó do aplicativo EPM System, que também executa a função do nó de controle DR na região 1.
3. Selecione o grupo de planos Iniciar Instâncias de Computação (Stand-by) incorporado.
4. Clique em Adicionar etapa para abrir a caixa de diálogo em que especificaremos o script para atualizar o arquivo do host.

Figura 9.4.1: Parâmetros para criar grupo e grupo de planos adicionados ao arquivo de host de atualização

Tarefa 9.4.2: Fornecer Nome da Etapa e Parâmetros do Script Local para o Script de atualização do arquivo do host

A caixa de diálogo Adicionar etapa do grupo de planos nos permite especificar parâmetros sobre o que essa etapa executará e como ela se comportará durante a recuperação. O script host_switch_failback.ps1 atualiza o arquivo do host no nó de computação. Ele reverte as alterações introduzidas pelo script host_switch_failback.ps1 na região Newport e restaura o arquivo de host original para a região 1 (Londres). Isso permitirá que o aplicativo seja iniciado sem modificações adicionais na camada do aplicativo.

Esta etapa é a mesma que a Tarefa 9.3.2, exceto para os itens mostrados na Figura.

1. Um nome descritivo que explica qual tarefa esta etapa executa.
2. Cole no caminho absoluto para PowerShell.exe e no local em que instalou o script host_switch_failover.ps1 no Nó de Controle DR.
3. Clique em Adicionar etapa para adicioná-la ao grupo de planos.

Figura 9.4.2: Parâmetros para criar detalhes do grupo de planos e da etapa adicionados para atualizar o arquivo do host

Tarefa 9.4.3: Fornecer Nome da Etapa e Parâmetros de Script Local para o Script Inicial do EPM System Service

A caixa de diálogo Adicionar etapa do grupo de planos nos permite especificar parâmetros sobre o que essa etapa executará e como ela se comportará durante a recuperação. Nesse caso, os serviços do sistema EPM começarão na região 2.

1. Um nome descritivo que explica qual tarefa esta etapa executa.
2. Cole no caminho absoluto para PowerShell.exe e no local em que instalou o script start_services.ps1 no Nó de Controle DR.
3. Clique em Adicionar etapa para adicioná-la ao grupo de planos.
4. Clique em Adicionar para adicionar o grupo de planos que agora contém duas etapas para executar dois scripts personalizados.

O plano de switchover agora deve incluir ambos os Grupos de Planos de DR, conforme mostrado na captura de tela a seguir.

Figura 9.4.3: Grupos de planos definidos pelo usuário Swichover

Tarefa 10: Personalizar o Plano de Failover na Região 1 (Londres)

Esta tarefa explica como adicionar Grupos de Planos de DR personalizados e definidos pelo usuário e etapas para gerenciar as tarefas que precisam ser realizadas durante um failover para o EPM System na região 1 durante uma interrupção real ou perda de acesso à região 2. Estes serão um subconjunto das mesmas etapas que foram adicionadas ao plano de switchover na Tarefa 9 acima. No entanto, somente as etapas executadas na região stand-by 1 serão adicionadas ao plano de failover, pois supõe-se que a região 2 esteja completamente inacessível durante um failover.

Tarefa 10.1: Adicionar Grupo de Planos Definido pelo Usuário ao Plano de Failover

Navegue até o plano de failover criado na Tarefa 8.

Figura 10.1: Plano de failover na Região 1

Tarefa 10.1.1: Adicionar Grupo de Planos

1. Certifique-se de que a região stand-by 2 ainda seja o contexto da região atual na console.
2. Selecione o plano de failover.
3. Clique em Adicionar grupo.
4. Especifique o nome do grupo.
5. Adicione-o ao plano após a etapa incorporada Iniciar Instância de Computação.

Figura 10.1: Parâmetros para criar grupo de planos para executar scripts personalizados após failover para a região 2.

Tarefa 10.1.2: Adicionar Etapas ao Novo Grupo de Planos Definido pelo Usuário

1. Siga as instruções da Tarefa 9.4 para adicionar duas etapas ao grupo de planos definido pelo usuário para executar o script personalizado: host_switch_failback.ps1.

   
   Figura 10.2: Parâmetros para criar etapa do grupo de planos para o script que atualiza o arquivo do host.

2. Adicione uma segunda etapa no grupo de planos para iniciar os serviços usando o script start_services.ps1.

   
   Figura 10.3: Parâmetros para criar etapa do grupo de planos para o script que atualiza o arquivo do host.

3. Após adicionar etapas, o grupo de planos definido pelo usuário deverá ter esta aparência e clicar em Adicionar.

   
   Figura 10.4: Grupo de planos mostrando as etapas configuradas para executar dois scripts locais após a inicialização da instância de computação.

4. O plano de failover agora deve incluir o Grupo de Planos de DR definido pelo usuário para o EPM System, conforme mostrado na captura de tela a seguir. Talvez você tenha grupos de planos adicionais se seu grupo de proteção incluir outros aplicativos ou serviços do OCI junto com o EPM System.

   
   Figura 10.5: Plano de failover mostrando grupos de planos definidos pelo usuário

Próximas Etapas

O OCI Full Stack DR para o EPM System deve ser totalmente implementado neste momento. No entanto, a funcionalidade completa deve ser validada antes de usá-la em produção. Todos os planos de failover e switchover devem ser executados para validar que tudo funciona conforme o esperado e que a equipe de recuperação entenda completamente todo o processo.

Testando Planos de Switchover

Os planos de switchover são projetados para limpar todos os artefatos e garantir que todas as atribuições de etapas de recuperação incorporadas, como balanceador de carga, armazenamento em blocos, sistemas de arquivos, BaseDB, ExaCS e Autonomous Database, estejam prontas para serem recuperadas da região stand-by sem intervenção humana.

Testando Planos de Failover

Failovers são diferentes. Os failovers por sua própria natureza não podem limpar artefatos ou garantir que serviços e bancos de dados na região com falha estejam prontos para fazer a transição das cargas de trabalho de volta para a região 1. A equipe de recuperação precisa entender e executar tarefas para garantir que o Oracle Data Guard esteja no estado correto, que os artefatos das instâncias de armazenamento e computação tenham sido encerrados e assim por diante. Para obter mais informações, consulte Redefinindo a Configuração de DR Após um Failover.

Validar Todos os Planos de DR para Aceitação Final

A equipe de recuperação precisa executar uma validação final para demonstrar a prontidão dos grupos de proteção e planos de DR do OCI Full Stack para cargas de trabalho de produção. A Região 2 (Newport) deve ser a região principal neste ponto do processo. Inicie a validação final de todos os planos executando as seguintes etapas:

• Teste o switchover da região 2 (principal) de volta para a região 1 (stand-by).

• Teste o failover da região 1 (principal) para a região 2 (stand-by).

• Prepare a região 1 (principal) para failover da região 2.

• Teste o failover da região 2 (principal) para a região 1 (stand-by).

• Prepare a região 2 (principal) para um failover ou switchover para a região 2.

• Opcionalmente, você também pode criar e testar planos Iniciar Drill e Interromper Drill com base nos requisitos.

• Os grupos de proteção de DR e a pilha de aplicativos devem estar em um estado operacional normal e prontos para um failover ou switchover neste ponto.

Links Relacionados

• Projete a infraestrutura para implantar o Oracle Enterprise Performance Management na nuvem

• Guia de Opções de Implantação: Recuperação de Desastre para o Hyperion EPM System

• Considerações do Banco de Dados: Recuperação de Desastre para o Fusion Middleware

• Localização dos scripts de amostra 1: Faça download dos scripts de amostra do EPM em GitHub

• Localização dos scripts de amostra 2: Faça download dos scripts de amostra do EPM em GitHub

• Lista de reprodução do OCI Full Stack DR Oracle EPM em YouTube

  • Vídeo 1: Implante o Oracle EPM para Recuperação de Desastres

  • Vídeo 2: Automatize as operações de recuperação de desastres para o Oracle EPM usando o OCI Full Stack DR

  • Vídeo 3: Scripts usados para automatizar a recuperação do Oracle EPM

• Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery

• Documentação do OCI Full Stack Disaster Recovery

• OCI Full Stack Disaster Recovery - Scripts de grupo definidos pelo usuário

• Participe do canal público slack #full-stack-dr

Agradecimentos

• Autor - Grzegorz Reizer (Especialista em Oracle EPM)

• Colaborador - Suraj Ramesh (Gerente de Produto para OCI Full Stack DR)

Mais Recursos de Aprendizagem

Explore outros laboratórios em docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal Oracle Learning YouTube. Além disso, visite education.oracle.com/learning-explorer para se tornar um Oracle Learning Explorer.

Para obter a documentação do produto, visite o Oracle Help Center.

---

Título e Informações de Copyright

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

G11413-01

July 2024

Copyright ©2024,

Oracle e/ou suas empresas afiliadas.