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 E-Business Suite de Vários Nós Usando o OCI Full Stack Disaster Recovery

Introdução

O OCI Full Stack Disaster Recovery conta com equipes de engenharia de aplicações para projetar, escrever e manter seus próprios recursos e recursos de recuperação de desastres. Se uma equipe de engenharia de aplicações tiver recursos integrados de recuperação de desastres nativos da OCI que incluem APIs SDK (Software Development Kit, Kit de desenvolvimento de software) da OCI para recuperação de desastres, essa aplicação poderá ser adicionada ao Full Stack DR como um recurso de membro nativo.

O Oracle E-Business Suite não tem recursos ou recursos de recuperação de desastres nativos do OCI e, como tal, não é um recurso de membro nativo no Full Stack DR. No entanto, a equipe de engenharia do Oracle E-Business Suit documentou um processo para implementar e recuperar manualmente o EBS nas regiões da OCI. O processo manual pode ser automatizado usando o Full Stack DR. Este documento explica como automatizar o processo de recuperação manual adicionando grupos de planos personalizados e definidos pelo usuário e etapas a planos básicos de DR para failover, alternância e drills.

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 as aplicações existentes.

O Oracle E-Business Suite suporta os modelos de negócios em evolução atuais, impulsiona a produtividade e atende às demandas do usuário móvel moderno. Com base em uma história de 30 anos de inovação, o Oracle E-Business Suite continua a oferecer novas funcionalidades de aplicativos e expandir os recursos existentes, ajudando você a obter todos os benefícios da OCI.

O Oracle E-Business Suite normalmente faz parte de um sistema maior

Oracle E-Business Suite é normalmente a base de um sistema de negócios mais complexo que inclui vários bancos de dados adicionais, aplicativos de marketplace da OCI e serviços da OCI que precisam ser recuperados como uma única unidade. Para manter as coisas simples e focadas no Oracle E-Business Suite, este tutorial mostra apenas as tarefas relacionadas ao Oracle E-Business Suite. Mas é muito incomum que o Oracle E-Business Suite seja o único aplicativo que faz parte do Grupo de Proteção de DR e dos planos de DR.

Cuidado ao Implementar Incrementalmente

A adição ou exclusão de mais membros a um Grupo de Proteção de DR após a criação de planos de DR atualizará os planos de DR existentes nos grupos de proteção em ambas as regiões. Para obter mais informações, consulte Atualizar um Plano de Recuperação de Desastres.

O OCI Full Stack DR foi projetado com o pressuposto de que toda a pilha de aplicativos para um determinado sistema de negócios já esteja implementada em regiões da OCI e o DR manual já tenha funcionado. Se o seu sistema de negócios incluir mais do que o Oracle E-Business Suite, adicione todos os outros serviços de computação, armazenamento, bancos de dados, aplicativos ou 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 do Oracle E-Business Suite requer que o OCI Full Stack DR execute uma série de scripts bash personalizados durante uma operação de recuperação, como failover, switchover ou drill-s. Neste tutorial, usaremos os nós de aplicativo do Oracle E-Business Suite como o nó de controle para hospedar e executar scripts.

Os scripts referenciados neste tutorial são fornecidos pela equipe de especialistas do Oracle Apps to OCI do Oracle EMEA Cloud Engineering e disponíveis em scripts do Oracle E-Business Suite para OCI Full Stack Disaster Recovery. Os scripts bash podem precisar ser modificados um pouco para atender às necessidades exclusivas da sua implantação.

Figura 1: Scripts do Oracle E-Business Suite disponíveis no repositório GitHub de amostra da Oracle

Este tutorial explica como fazer download dos scripts e como usá-los em uma etapa posterior. Este tutorial usa a Opção 1 para hospedar os scripts bash somente porque o tutorial não inclui nada além do Oracle E-Business Suite.

Observação: os seguintes scripts são fornecidos para orientação genérica. Você pode usar seus próprios scripts ou personalizar os scripts de acordo com sua política corporativa e requisitos de segurança.

Opção 1 para scripts de hospedagem

Instale os scripts bash nos servidores de aplicativos do Oracle E-Business Suite em execução em ambas as regiões. Este tutorial fará referência às instâncias de computação nas quais você instala os scripts como Nó de Controle ou Nó de DR, mesmo que seja um ou mais servidores de aplicativos do Oracle E-Business Suite em sua pilha de aplicativos.

Opção 2 para scripts de hospedagem

Crie um Nó de Controle ou um Nó de DR especializado para hospedar todos os scripts do Oracle E-Business Suite, além dos scripts necessários para outros aplicativos ou serviços do OCI.

O Oracle E-Business Suite na maioria das vezes faz parte de um sistema de negócios maior e mais complexo que inclui aplicativos internos personalizados, aplicativos do Oracle Cloud Marketplace, Oracle Business Analytics e outros bancos de dados, instâncias de computação e aplicativos internos. Nesse caso, basta escolher qualquer uma das instâncias de computação que já fazem parte do sistema de negócios para hospedar os scripts. A instância de computação selecionada pode ser qualquer coisa em que o Oracle Linux esteja instalado e provavelmente será uma VM existente que atenda a outra finalidade, como um servidor de aplicativos ou um servidor de administração de algum tipo.

Normalmente, o OCI Full Stack DR não requer nenhum servidor de gerenciamento especializado para automatizar as operações de recuperação. No entanto, você criará uma instância de computação que atuará como um servidor de gerenciamento especializado nesse caso. O servidor de gerenciamento especializado é visto em todo este documento como Nó de Controle ou Nó de DR. Todo o propósito do nó de controle é simplesmente agir como um servidor onde todos os scripts personalizados podem residir e ser chamados pelo OCI Full Stack DR durante uma operação de recuperação.

Observação: neste tutorial, usaremos a Opção 1, na qual armazenaremos os scripts personalizados relacionados ao aplicativo Oracle E-Business Suite nos servidores do aplicativo Oracle E-Business Suite.

Arquitetura de Implantação do Oracle E-Business Suite

O Oracle E-Business Suite deve ser implementado primeiro para recuperação de desastres (DR) em regiões da OCI antes de introduzir o OCI Full Stack DR. É muito importante que as etapas manuais para executar uma recuperação sejam testadas e funcionem corretamente antes de tentar automatizar o processo de recuperação usando o OCI Full Stack DR.

Qualquer uma das duas arquiteturas de referência a seguir mostradas abaixo pode ser seguida ao implementar o Oracle E-Business Suite for DR em regiões da OCI. Ambas as arquiteturas de referência ilustram uma topologia multicamadas com recursos redundantes distribuídos em duas regiões da OCI.

Os bancos de dados de várias instâncias são criados com o Oracle Real Application Clusters (Oracle RAC) e usam o Oracle Data Guard para manter o banco de dados em sincronia entre duas regiões da OCI.

Arquitetura de Referência para o Oracle E-Business Suite usando o Oracle Base Database Service

Escolha esta arquitetura de implantação se o Oracle E-Business Suite estiver usando o Oracle Base Database Service. O Oracle E-Business Suite deve ser implantado para DR em duas regiões da OCI, conforme explicado em Business Continuity for Oracle E-Business Suite Release 12.2 with Oracle Database 19c on Oracle Base Database Service DB Systems (Doc ID 2875417.1). A ilustração mostrada na Figura 1 foi obtida do ID do Documento 2875417.1.

Figura 1: Arquitetura de implantação de DR do Oracle E-Business Suite usando o OCI Base Database (consulte o Doc ID 2875417.1 para obter mais detalhes)

Arquitetura de referência para o Oracle E-Business Suite usando o Oracle Exadata Database Service on Dedicated Infrastructure

Escolha esta arquitetura de implantação se o Oracle E-Business Suite estiver usando o Oracle Exadata Database Service on Dedicated Infrastructure. O Oracle E-Business Suite deve ser implantado para DR em duas regiões da OCI, conforme explicado em Business Continuity for Oracle E-Business Suite Release 12.2 with Oracle Database 19c on Oracle Exadata Database Service on Dedicated Infrastructure (Doc ID 2919723.1). A ilustração mostrada na Figura 1 foi obtida do ID do Documento 2919723.1.

Figura 2: Arquitetura de implantação de DR do Oracle E-Business Suite com OCI Exadata Database (consulte o Doc ID 2919723.1 para obter mais detalhes)

Diferença entre Nomes de Host Lógicos e Nomes de Host Físicos

O Oracle E-Business Suite sugere fortemente que nomes de host lógicos sejam usados para os servidores de aplicativos e nomes de host físicos sejam usados para o banco de dados. Tanto o Business Continuity for Oracle E-Business Suite Release 12.2 with Oracle Database 19c on Oracle Base Database Service DB Systems (Doc ID 2875417.1) quanto o Business Continuity for Oracle E-Business Suite Release 12.2 with Oracle Database 19c on Oracle Base Database Service DB Systems (Doc ID 2919723.1) escrito pela engenharia do Oracle E-Business Suite exigem que a camada de aplicativos use nomes de host lógicos, enquanto a camada de banco de dados usa nomes de host físicos.

O OCI Full Stack DR não tem requisitos para usar nomes de host lógicos ou físicos, mas recomendamos seguir os requisitos do Oracle E-Business Suite para garantir o suporte do Oracle E-Business Suite em caso de problemas. Alguns clientes usam nomes de host lógicos para as camadas de aplicativo e banco de dados. Os scripts fornecidos com esta solução foram projetados para serem usados com nomes de host lógicos para a camada de aplicativo e a camada de banco de dados de nomes de host físicos; consulte a Tarefa 1.2 para obter instruções de download.

Arquitetura de Implantação do OCI Full Stack DR

As ilustrações a seguir mostram os recursos de computação adicionados como membros de cada Grupo de Proteção de DR (DRPG) para o OCI Full Stack DR. Eles representam os vários componentes que o OCI Full Stack DR pode gerenciar fora do aplicativo Oracle E-Business Suite.

O OCI Full Stack DR tem automação integrada para lidar com OCI Compute, OCI Block Storage, OCI File Storage, bancos de dados Oracle, OCI Load Balancer, clusters do Oracle Cloud Infrastructure Kubernetes Engine (OKE) e muitos outros recursos durante uma recuperação, mas não tem automação integrada para o próprio Oracle E-Business Suite. A recuperação do Oracle E-Business Suite é controlada por uma série de scripts bash que podem ser baixados de um repositório GitHub dedicado a este tutorial. Os scripts bash precisam ser instalados em uma instância de computação de sua escolha, seguindo qualquer uma das seguintes opções para posicionamento e controle dos scripts.

Opção 1: Automatizar a Recuperação do Oracle E-Business Suite usando o Oracle Base Database Service

Essa arquitetura de implantação não é típica e foi projetada para situações muito raras em que o Oracle E-Business Suite é o único aplicativo recuperado pelo OCI Full Stack DR. Nesse caso, hospedaremos os scripts personalizados nos nós de aplicativos do Oracle E-Business Suite.

Figura 3: Arquitetura de implantação do Full Stack DR usando o serviço OCI Base Database

Opção 2: Automatizar a Recuperação do Oracle E-Business Suite usando o Oracle Exadata Database Service on Dedicated Infrastructure

A arquitetura de implantação simplista mostrada na Figura 4 é um exemplo de uma implantação mais comum do Oracle E-Business Suite, na qual é simplesmente um componente de uma pilha de aplicativos maior e mais complexa, na qual muitos serviços e aplicativos precisam ser recuperados juntos. A maioria dos sistemas de negócios é muito mais complexa do que a fictícia mostrada na imagem a seguir e geralmente inclui bancos de dados adicionais, outras aplicações Oracle e/ou não Oracle, juntamente com outros serviços da OCI, como OIC, ODI, OHS, OCI IAM e assim por diante.

Figura 4: Arquitetura de implantação do Full Stack DR usando o Oracle Exadata Database Service on Dedicated Infrastructure

Definições e Premissas em todo o Tutorial

Regiões

A atribuição de principal e stand-by é uma função dos grupos de proteção do OCI Full Stack DR, não das próprias regiões. Uma região pode funcionar como principal para uma pilha de aplicativos e, ao mesmo tempo, como stand-by para uma pilha de aplicativos completamente diferente. O papel do principal e do stand-by é fluido.

Este tutorial começa com a pilha de aplicativos do Oracle E-Business Suite em execução no Phoenix e todos os recursos stand-by em execução no Ashburn. Essas duas regiões são apenas exemplos; as duas regiões do OCI que suportam sua pilha de aplicações podem ser usadas na prática.

• A Região 1 é Phoenix.

  • Phoenix começará como a região principal.
  • Phoenix começa como região principal porque:
    • O aplicativo Oracle E-Business Suite está em execução em Phoenix.
    • O job rsync cron do Oracle E-Business Suite está copiando dados do /u01 nos servidores de aplicativos (VMs) do Oracle E-Business Suite em Phoenix para os servidores de aplicativos em execução em Ashburn.
    • O banco de dados em Phoenix tem a atribuição principal do Oracle Data Guard.
  • Phoenix eventualmente se tornará o stand-by depois que você for instruído a executar um switchover em tarefas posteriores.

• A região 2 é Ashburn.

  • Ashburn começará como a região stand-by.
  • Ashburn começa como região stand-by porque:
    • Os servidores de aplicativos stand-by (VMs) do Oracle E-Business Suite estão em execução em Ashburn.
    • O aplicativo Oracle E-Business Suite não está em execução em Ashburn.
    • Os dados no /u01 estão sendo copiados do Phoenix para as VMs em Ashburn.
    • O banco de dados em Ashburn tem a atribuição de standby do Oracle Data Guard.
  • Ashburn acabará se tornando o principal depois que você for instruído a executar um switchover em tarefas posteriores.

Compartimentos

Você é livre para organizar o Oracle E-Business Suite e o OCI Full Stack DR em qualquer esquema de compartimento que funcione dentro dos seus padrões de governança de TI. Optamos por organizar 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.

• A organização de todos os grupos de proteção de DR em um único compartimento, além dos aplicativos, torna muito mais fácil para a equipe de TI localizar e executar planos de DR para muitos sistemas de negócios completamente diferentes.
• Ter um único compartimento para todos os grupos de proteção de DR ajuda a eliminar o erro humano e aumenta a velocidade na qual os planos de DR podem ser encontrados e executados.
  • Compartimento do Oracle E-Business Suite (ebstesting). O compartimento do próprio Oracle E-Business Suite, armazenamento, buckets de armazenamento, computação e banco de dados relacionados ao Oracle E-Business Suite é ebstesting neste tutorial.
  • Compartimento para OCI Full Stack DR myprojects. O compartimento para grupos e planos de proteção do OCI Full Stack DR é myprojects neste tutorial.

Objetivos

As tarefas a seguir serão abordadas neste tutorial explicando como automatizar a recuperação do Oracle E-Business Suite usando o OCI Full Stack DR.

Observação: Começamos com a Região 1 (Phoenix) e a Região 2 (Ashburn). O aplicativo Production Oracle E-Business Suite é executado na Região 1 e o DR é configurado na Região. Isso é realmente importante, pois em todo o tutorial, nos referimos como Região 1 e Região 2, em vez da região real name.If, sua implantação usa diferentes regiões do OCI. Em seguida, certifique-se de fazer referência às respectivas regiões de Produção e DR.

1. Tarefa 1: Implantar o Oracle E-Business Suite para DR em regiões da OCI.

   1. Instale e implemente manualmente o Oracle E-Business Suite for DR em duas regiões da OCI.
   2. Teste manualmente todas as etapas de recuperação da Região 1 desejada para a Região 2.
   3. Teste manualmente todas as etapas de recuperação da Região 2 desejada para a Região 1.

2. Tarefa 2: Preparação para o OCI Full Stack DR.

   1. Configure políticas do OCI IAM para o Full Stack DR.
   2. Configurar políticas do OCI IAM para outros serviços do OCI.
   3. Faça download e instale scripts personalizados do Oracle E-Business Suite nos servidores de aplicativos do Oracle E-Business Suite.
   4. Certifique-se de que os servidores de aplicativos do Oracle E-Business Suite possam executar scripts e comandos.
   5. Criar segredos do vault para o banco de dados do Oracle E-Business Suite.
   6. Criar buckets de armazenamento de objetos para logs.

3. Tarefa 3: Criar e associar Grupos de Proteção de DR.

4. Tarefa 4: Adicionar membros de banco de dados e computação do Oracle E-Business Suite aos grupos de proteção de DR da região 1 e 2.

5. Tarefa 5: Criar os planos de DR na região 2 (Ashburn).

   1. Criar plano de switchover.
   2. Criar plano de failover.
   3. Criar plano de detalhamento inicial.

6. Tarefa 6: Personalizar os planos de DR na região 2 (Ashburn).

7. Tarefa 7: Executar o plano de switchover na região 2 (Ashburn).

8. Tarefa 8: Criar planos de DR básicos na região 1 (Phoenix) e personalizar os planos de DR na região 1 (Phoenix).

   1. Crie um plano de switchover e personalize o plano de switchover na região 1 (Phoenix).
   2. Crie um plano de failover e personalize o plano de failover na região 1 (Phoenix).
   3. Crie o plano de drill inicial e personalize o plano de drill inicial na região 1 (Phoenix).

Pré-requisitos

O Oracle E-Business Suite deve ser implantado para recuperação de desastres em ambas as regiões antes de começar a trabalhar com o OCI Full Stack DR. Isso é abordado na Tarefa 1.

Tarefa 1: Implantar o Oracle E-Business Suite para Recuperação de Desastres

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

O Oracle E-Business Suite deve ser implantado para recuperação de desastres em regiões da OCI usando um dos dois artigos de conhecimento diferentes do My Oracle Support (MOS) (notas KM) antes de iniciar qualquer trabalho com o OCI Full Stack DR.

Também é muito importante que as etapas manuais descritas nas notas do KM, juntamente com os scripts/automação personalizados necessários para recuperar o Oracle E-Business Suite, tenham sido totalmente testadas antes de iniciar qualquer trabalho com o OCI Full Stack DR.

O Oracle E-Business Suite atualmente suporta os serviços Oracle Base Database Service e Oracle Exadata Database Service on Dedicated Infrastructure. O serviço Oracle Autonomous Database não é suportado no momento com o Oracle E-Business Suite. Siga as instruções encontradas em uma ou outra das seguintes notas do KM:

• ID do Documento 2875417.1: Implantar o Oracle E-Business Suite para DR usando BaseDB

• ID do Documento 2919723.1: Implantar o Oracle E-Business Suite para DR usando ExaDB-D

Tarefa 2: Preparar a Tenancy para o OCI Full Stack DR

O OCI Full Stack DR não está envolvido em nenhuma parte desta tarefa. As etapas a seguir preparam a tenancy, o compartimento, os serviços da OCI e o Oracle E-Business Suite para recuperação automatizada pelo OCI Full Stack DR. A maioria das tarefas articuladas nesta seção é discutida em Pré-requisitos para o Full Stack Disaster Recovery.

Tarefa 2.1: Configurar Políticas do OCI IAM para o OCI Full Stack DR

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

• Políticas para o Full Stack Disaster Recovery.
• Configurando políticas de IAM (Identity and Access Management) necessárias para o Full Stack Disaster Recovery.

Tarefa 2.2: Configurar Políticas do IAM do OCI 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 da OCI, como computação, rede, armazenamento, vaults, bancos de dados e outros serviços diversos. Configurar as políticas de IAM do OCI necessárias para outros serviços conforme explicado no documento a seguir

• Políticas para Outros Serviços Gerenciados pelo Full Stack Disaster Recovery.

Tarefa 2.3: Fazer Download e Instalar o Oracle E-Business Personalizado SuiteScripts nos servidores de Aplicativos do Oracle E-Business Suite

O OCI Full Stack DR tem inteligência integrada para orquestrar a recuperação de recursos do OCI Infrastructure as a Service (IaaS) e Platform as a Service (PaaS). O OCI Full Stack DR não tem inteligência integrada para orquestrar a recuperação do Oracle E-Business Suite, pois o Oracle E-Business Suite não fornece APIs de recuperação de desastres nativas do OCI para implementar ou gerenciar sua própria recuperação de desastres integrada.

No entanto, o OCI Full Stack DR ainda pode orquestrar a recuperação do Oracle E-Business Suite adicionando Grupos de Planos de DR definidos pelo usuário e etapas aos planos de DR base criados posteriormente neste tutorial. Conforme discutido na Parte 1 deste tutorial, as etapas definidas pelo usuário chamarão uma série de scripts personalizados que executam várias tarefas necessárias para recuperar o Oracle E-Business Suite. Os scripts devem ser baixados e instalados em todas as instâncias de computação nos servidores de aplicativos do Oracle E-Business Suite nas duas regiões:

1. Faça download dos scripts do Oracle E-Business Suite aqui: scripts do Oracle E-Business Suite para OCI Full Stack Disaster Recovery.
2. Copie os scripts para qualquer diretório em cada um dos servidores de aplicativos Oracle E-Business Suite na região 1.
3. Copie os scripts para o mesmo local de diretório em cada um dos servidores de aplicativos do Oracle E-Business Suite na região 2.
4. Garantir que os arquivos pertençam ao usuário oracle.
5. Certifique-se de que os arquivos sejam executáveis.

Tarefa 2.4: Garantir que os Servidores de Aplicativos do Oracle E-Business Suite possam Executar Scripts e Comandos

O OCI Full Stack DR precisará executar os scripts do Oracle E-Business Suite que foram baixados para os servidores de aplicativos do Oracle E-Business Suite. O OCI Full Stack DR executa os scripts usando o Oracle Cloud Agent em cada instância de computação. É muito importante que todas as instâncias de computação usadas como servidores de aplicativos do Oracle E-Business Suite em ambas as regiões possam executar comandos por meio da Console do OCI usando o Oracle Cloud Agent.

Para obter mais informações, consulte Preparando Instâncias do Serviço Compute para Full Stack Disaster Recovery. Preste especial atenção às instruções de Execução de Comandos com Privilégios de Administrador.

Validar se os Comandos podem ser Executados na Console do OCI

Observação: Esta tarefa apenas garante que o Oracle Could Agent possa executar comandos. Ele não valida se as políticas apropriadas estão em vigor para permitir que o Full Stack DR execute comandos por meio do Oracle Cloud Agent. Isso ficará evidente nas etapas posteriores quando o tutorial explicar como validar o Plano de DR de switchover na região 2.

Use o recurso de comando Executar da computação instanciada para validar se o Oracle Cloud Agent é capaz de executar comandos. As imagens a seguir mostram o comando Executar na página de detalhes das instâncias de computação na Console do OCI.

1. Selecione Executar comando.
2. Selecione Criar comando e digite qualquer comando Linux válido, como data. Altere o timeout para algo razoável como 3 minutos antes de executar o comando.

Figura 2.4.1.1: Execute um comando na console do OCI

Tarefa 2.5: Criar Segredos do OCI Vault para o Banco de Dados Oracle E-Business Suite

O OCI Full Stack DR precisará da senha sys do banco de dados para que possa acionar automaticamente o Oracle Data Guard durante failovers e switchovers. Adicione a senha do banco de dados sys a um segredo do vault nas duas regiões, conforme explicado aqui: Preparando Bancos de Dados Oracle para o Full Stack Disaster Recovery.

Tarefa 2.6: Criar Buckets do OCI Object Storage para Logs

Observação: Ignore totalmente a Tarefa 2.3 se estiver adicionando o Oracle E-Business Suite aos Grupos de Proteção de DR existentes.

Crie Buckets do OCI Object Storage nas regiões principal e stand-by para armazenar logs gerados pelo OCI Full Stack DR durante operações de recuperação, conforme explicado aqui: Preparando a Localização de Log para Logs de Operação.

Tarefa 2.6.1: Navegar até o OCI Object Storage

Comece navegando até Object Storage & Archive Storage, conforme mostrado na Figura 2-1.

1. Verifique se o contexto do navegador está definido como a região 1 (Phoenix).
2. Clique em Armazenamento.
3. Clique em Buckets.

Figura 2.6.1.1: Navegue até o armazenamento de objetos

Tarefa 2.6.2: Criar um Bucket do OCI Object Storage nas Regiões 1 e 2

Criar um Bucket do OCI Object Storage na região 1. Em seguida, crie um bucket de armazenamento idêntico na região 2. Os buckets serão designados aos grupos de proteção de DR nas regiões 1 e 2 em uma tarefa posterior.

1. Selecione o compartimento que contém os recursos relacionados ao Oracle E-Business Suite. O compartimento pode ser diferente em cada região.
2. Clique em Criar Bucket.
3. Dê ao bloco um nome significativo que identifique facilmente qual aplicativo e finalidade ele serve; não há motivo para incluir a região como parte do nome. Por exemplo, esse nome indica que ele é usado para os logs do OCI Full Stack DR relacionados às operações de DR do Oracle E-Business Suite.
4. Use o valor padrão para Camada e Criptografia.
5. Clique em Criar para criar o bucket.

Figura 2.6.2.1: Criar um bucket de armazenamento de objetos nas regiões 1 e 2

Tarefa 3: Criar e Associar Grupos de Proteção de DR

Essa será a primeira tarefa que envolve o Full Stack DR. Crie grupos de proteção de DR na região 1 e na região 2 se os grupos de proteção desta pilha de aplicativos ainda não existirem.

Observação: Ignore totalmente a Tarefa 3 se o Oracle E-Business Suite estiver sendo adicionado aos Grupos de Proteção de DR existentes.

Esta tarefa começa a primeira etapa de configuração do OCI Full Stack DR para a pilha de aplicativos que inclui o Oracle E-Business Suite. Os Grupos de Proteção de DR informam ao OCI Full Stack DR quais serviços do OCI IaaS e PaaS fazem parte de uma única pilha de aplicativos e quais duas regiões atuarão como principal e stand-by para o sistema de negócios. Os grupos de proteção de DR formam a base sobre a qual todo o resto é construído.

Todos os recursos do OCI IaaS e PaaS que pertencem à pilha de aplicativos em ambas as regiões serão adicionados como parte da Tarefa 4.

Observação: Embora este tutorial inclua somente o Oracle E-Business Suite, os Grupos de Proteção de DR normalmente contêm serviços OCI IaaS e PaaS para muitos aplicativos Oracle e não Oracle diferentes e além daqueles necessários ao Oracle E-Business Suite.

Tarefa 3.1: Criar um Grupo de Proteção na Região Stand-by 2 (Ashburn)

Comece criando um Grupo de Proteção de DR não associado na região 2. Não há exigência de que o grupo de proteção seja criado na região stand-by, o processo flui um pouco melhor iniciando na região 2.

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

Comece navegando até os Grupos de Proteção de DR (OCI Full Stack DR) conforme mostrado na Figura 3.1.1.

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

Figura 3.1.1: Navegue até grupos de proteção de DR

Tarefa 3.1.2: Criar o Grupo de Proteção

Crie um grupo básico de proteção de DR (DRPG) na região 2, conforme mostrado na Figura 3-1-2. 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 Oracle E-Business Suite ou qualquer outro compartimento relacionado ao projeto.
2. Selecione Criar grupo de proteção de DR para abrir a caixa de diálogo na qual você informará os parâmetros para criar o grupo de proteção.

Figura 3.1.2: Comece a criar o grupo de proteção de DR na região 2

Tarefa 3.1.3: Adicionar Parâmetros Necessários para Criar o Grupo de Proteção

Adicione um nome e um bucket do OCI Object Storage para os logs, conforme mostrado na Figura 3.1.3.

1. Use um nome simples e significativo para o DRGP; este exemplo mostra o nome do sistema de negócios e a região.
2. Selecione o compartimento no qual deseja que o DRPG seja criado na região 2.
3. Selecione o bucket de armazenamento de objetos criado na Tarefa 2 para a região 2. Talvez você precise alterar o compartimento se tiver criado o bucket em outro compartimento.

Não insira nenhum parâmetro adicional. Clique em Criar na parte inferior da caixa de diálogo (não mostrado aqui).

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

O que você deve ver após criar o grupo de proteção

O primeiro grupo de proteção de DR será criado conforme mostrado na Figura 3-2.3. As atribuições e as informações de mesmo nível serão designadas como parte da Tarefa 3.4.

Figura 3.1.4: Mostrando o grupo de proteção DR recém-criado na região 2

Tarefa 3.2: Criar um grupo de Proteção na Região Principal 1 (Phoenix)

Crie um grupo de proteção na região 1. Em uma tarefa posterior, você adicionará todos os recursos do OCI que pertencem à pilha de aplicativos nesta região. É assim que o OCI Full Stack DR sabe quais ativos são considerados parte de um sistema de negócios nesta região.

Tarefa 3.2.1: Criar o Grupo de Proteção

Crie um grupo básico de proteção de DR (DRPG) na região 1, conforme mostrado na Figura 3.2.1. 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 1.
2. Selecione o compartimento no qual você deseja que o DRPG seja criado. As pessoas normalmente escolhem o mesmo compartimento que foi usado para criar o DRPG na região 2.
3. Selecione Criar grupo de proteção de DR para abrir a caixa de diálogo na qual você informará os parâmetros para criar o grupo de proteção.

Figura 3.2.1: Comece a criar o grupo de proteção de DR na região 1

Tarefa 3.2.2: Adicionar Parâmetros Necessários para Criar o Grupo de Proteção

Adicione um nome e um bucket de armazenamento de objetos para os logs conforme mostrado na Figura 3-5.

1. Use um nome simples e significativo para o grupo PRotection de DR; este exemplo mostra o nome do sistema de negócios e a região.
2. Selecione o compartimento no qual deseja que o DRPG seja criado na região 1. As pessoas geralmente usam o mesmo compartimento em ambas as regiões.
3. Selecione o bucket de armazenamento de objetos criado na Tarefa 2 para a região 1. Talvez você precise alterar o compartimento se tiver criado o bucket em outro compartimento.

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

O que você deve ver após criar o grupo de proteção

O segundo grupo de proteção de DR será criado conforme mostrado na Figura 3.2.3. As atribuições e as informações de mesmo nível serão designadas como parte da Tarefa 3.3.

Figura 3.2.3: Mostrando o grupo de proteção DR recém-criado na região 2

Tarefa 3.3: 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 atribua as atribuições de principal e stand-by. É assim que o OCI Full Stack DR saberá quais duas regiões trabalham juntas para a recuperação do Oracle E-Business Suite. 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 depois que os DRPGs recebem suas atribuições iniciais nesta tarefa.

Tarefa 3.3.1: Iniciar a associação

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

Figura 3.3.1: Iniciar associação de DRPG

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

Indicar os parâmetros indicados na figura 3.3.2.

1. Selecione a função principal. O OCI Full Stack DR designará a atribuição stand-by à região 2 automaticamente.
2. Selecione a região 2 (Phoenix) onde o outro DRPG foi criado.
3. Selecione o DRPG correspondente que foi criado.

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

O que você deve ver após a associação ser concluída:

O OCI Full Stack DR mostrará algo como a Figura 3.3.3 quando a associação for concluída.

1. O atual par principal DRPG é Phoenix (região 1).
2. O atual DRPG stand-by é Ashburn (região 2).

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

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

1. O atual par principal DRPG é Phoenix (região 1).
2. O atual DRPG stand-by é Ashburn (região 2).

Figura 3.4.3.2: Mostrando o relacionamento de pares da perspectiva DRPG global

Tarefa 4: Adicionar Membros do Oracle E-Business Suite aos Grupos de Proteção de DR da Região 1 e da Região 2

Adicione o banco de dados e os servidores de aplicativos Oracle E-Business Suite estáticos como membros do grupo de proteção de DR (DRPG) em ambas as regiões. Computação imóvel significa que os servidores de aplicativos do Oracle E-Business Suite existentes na região 1 nunca são iniciados ou iniciados na região 2. Os volumes de inicialização para computação não móvel não são replicados usando a replicação do OCI Storage para a região 2 e não são adicionados como membros de nenhum dos grupos de proteção de DR.

Este tutorial mostra apenas as etapas relacionadas ao Oracle E-Business Suite, mas você também deve aproveitar esta oportunidade para adicionar outros serviços OCI IaaS e PaaS que precisam ser recuperados com o Oracle E-Business Suite. Por exemplo, pode haver outra computação móvel, computação não móvel, bancos de dados, balanceadores de carga, sistemas de arquivos, armazenamento em blocos ou armazenamento de objetos associados a outros aplicativos internos ou Oracle que fazem parte do ecossistema do Oracle E-Business Suite.

Observação: Esta tarefa atualizará todos os planos de DR existentes nas duas regiões ao adicionar membros aos Grupos de Proteção de DR existentes. Para obter mais informações, consulte Atualizar um Plano de Recuperação de Desastres.

Tarefa 4.1: Adicionar Recursos do Membro ao Grupo de Proteção de DR à Região 1 (Phoenix)

Você adicionará os recursos a seguir como membros do DRPG principal na região 1.

1. Dois servidores de aplicativos Oracle E-Business Suite estáticos (Oracle E-Business Suite instalado e em execução).
2. O banco de dados Oracle RAC para Oracle E-Business Suite (par principal do Oracle Data Guard).

Tarefa 4.1.1: Navegar até o Grupo de Proteção de DR Principal

Navegue até o Grupo de Proteção de DR na região 1, conforme mostrado na Figura 4.1.1.

1. Certifique-se de que o contexto da região do OCI seja a região 1 (Phoenix).
2. Selecione o Grupo de Proteção de DR na região 1.

Figura 4.1.1: Navegue até o grupo de proteção de DR na região 1

Tarefa 4.1.2: Adicionar o Oracle E-Business Suite Application Server 1

Comece abrindo a caixa de diálogo Adicionar membro para adicionar o primeiro servidor de aplicativos.

1. Clique em Membros.
2. Clique em Adicionar membro.

Figura 4.1.2.1: Abra a caixa de diálogo Adicionar membros

Selecione o servidor de aplicativos 1 na região 1, conforme mostrado na Figura 4.1.2.2. Não é necessário adicionar grupos de volumes em blocos nem especificar propriedades de rede, pois essa é uma instância não móvel.

1. Selecione Compute como Tipo de Recurso.
2. Escolha o compartimento que contém os servidores de aplicativos do Oracle E-Business Suite e selecione a instância de computação designada como servidor de aplicativos 1.
3. Selecione Instância não móvel. Isso informa ao OCI Full Stack DR que ele não deve tentar iniciar uma máquina virtual replicada na região stand-by durante uma operação de DR.
4. Clique em Adicionar para adicionar a instância de computação ao DRPG (não mostrado).

Figura 4.1.2.2: Especifique parâmetros para o servidor de aplicações 1

Tarefa 4.1.3: Adicionar o Oracle E-Business Suite Application Server 2

1. Clique em Adicionar membro.

   
   Figura 4.1.3.1: Abra a caixa de diálogo Adicionar membros

Selecione o servidor de aplicativos 2 na região 1, conforme mostrado na Figura 4.1.3.2. Não é necessário adicionar grupos de volumes em blocos nem especificar propriedades de rede, pois essa é uma instância não móvel.

1. Selecione Compute como Tipo de Recurso.
2. Escolha o compartimento que contém os servidores de aplicativos do Oracle E-Business Suite e selecione a instância de computação designada como servidor de aplicativos 2.
3. Selecione Instância não móvel. Isso informa ao OCI Full Stack DR que ele não deve tentar iniciar uma máquina virtual replicada na região stand-by durante uma operação de DR.
4. Clique em Adicionar para adicionar a instância de computação ao DRPG (não mostrado).

Figura 4.1.3.2: Especifique parâmetros para o servidor de aplicações 2

Tarefa 4.1.4: Adicionar Oracle Database Clusterizado Principal

1. Clique em Adicionar membro para adicionar o banco de dados como membro.

   
   Figura 4.1.4.1: Abra a caixa de diálogo Adicionar membros

Selecione o banco de dados RAC do Oracle E-Business Suite na região 1, conforme mostrado na Figura 4.1.4.2. Isso também funciona exatamente da mesma forma para bancos de dados de uma única instância.

1. Escolha Banco de Dados como o Tipo de Recurso. O tipo de recurso Banco de Dados permite a escolha do Oracle Base Database Service ou do Oracle Exadata Database Service on Dedicated Infrastructure, que são suportados pela engenharia do Oracle E-Business Suite como opções válidas.
2. A imagem da figura mostra o Oracle Base Database Service, mas você também pode usar o popular Oracle Exadata Database Service on Dedicated Infrastructure.
3. Selecione os valores desses campos que correspondem à sua implantação. Pergunte ao administrador do banco de dados se você não souber as respostas para essas seleções.
4. Selecione o compartimento e o segredo do vault que contêm a senha do banco de dados. Você deve ter criado um vault e um segredo semelhantes na região 2 como parte da Tarefa 2.4. Esse parâmetro está na caixa de diálogo para compatibilidade com outras APIs DBaaS, mas a senha não é realmente usada.
5. Clique em Adicionar para adicionar o banco de dados como um membro (não mostrado).

Figura 4.1.4.2: Especifique parâmetros para o banco de dados RAC na região 1

A lista de membros no Grupo de Proteção de DR deve ser semelhante à captura de tela mostrada na Figura 4.1.4.3. Sua lista poderá ser diferente se você estiver adicionando mais do que o Oracle E-Business Suite a este Grupo de Proteção de DR específico ou estiver adicionando recursos de membro do Oracle E-Business Suite a um grupo de proteção de DR existente.

Figura 4.1.4.3: Lista completa de membros necessários para o Oracle E-Business Suite na região 1

Tarefa 4.2: Adicionar Recursos do Membro ao DRPG na Região 2 (Ashburn)

Você adicionará os recursos mostrados na lista como membros do DRPG stand-by na região 2.

1. Os dois servidores de aplicativos móveis do Oracle E-Business Suite (Oracle E-Business Suite instalado, mas não em execução).
2. O banco de dados RAC para Oracle E-Business Suite (par stand-by do Oracle Data Guard).

O Oracle E-Business Suite requer que os servidores de aplicativos existam nas duas regiões com o aplicativo instalado. O(s) servidor(es) de aplicativos deve(m) estar sempre em execução na região stand-by com o aplicativo Oracle E-Business Suite instalado, mas não em execução na região stand-by.

Isso significa que atualizações, patches e outras manutenções de rotina do Sistema Operacional e do aplicativo devem ser executados de forma independente em ambas as regiões.

O OCI Full Stack DR se refere a esse modelo de computação imóvel, pois as VMs não são replicadas para outra região e nunca movem para nenhuma outra região durante uma operação de DR. Os dispositivos de inicialização para instâncias de computação designadas como computação não móvel no OCI Full Stack DR não devem ser replicados para a região stand-by. Portanto, nenhum grupo de volumes em blocos replicado que contenha dispositivos de inicialização para computação não móvel é adicionado aos Grupos de Proteção de DR (DRPG).

Observação: Como mencionado anteriormente, é incomum que o Oracle E-Business Suite seja o único aplicativo ou serviço associado a um par de Grupos de Proteção de DR de Pilha Completa do OCI. Você também pode ter outros recursos IaaS e PaaS como membros do Grupo de Proteção de DR na região stand-by.

Tarefa 4.2.1: Navegar até o Grupo de Proteção de DR Stand-by

Navegue até o Grupo de Proteção de DR na região 2, conforme mostrado na Figura 4.2.1.

1. Certifique-se de que o contexto da região do OCI seja a região 2 (Ashburn).
2. Selecione o Grupo de Proteção de DR na região 2.

Figura 4.2.1: Navegue até o grupo de proteção de DR na região 2

Tarefa 4.2.2: Adicionar o Oracle E-Business Suite Application Server 1

Comece abrindo a opção Adicionar membro para adicionar o primeiro servidor de aplicativos.

1. Selecione Membros.
2. Clique em Adicionar membro.

Figura 4.2.2.1: Abra a caixa de diálogo Adicionar membros

Selecione o servidor de aplicativos 1 na região 2, conforme mostrado na Figura 4.2.2.2. Não é necessário adicionar grupos de volumes em blocos nem especificar propriedades de rede, pois essa é uma instância não móvel.

1. Selecione Compute como Tipo de Recurso.
2. Escolha o compartimento que contém os servidores de aplicativos do Oracle E-Business Suite e selecione a instância de computação designada como servidor de aplicativos 1.
3. Selecione Instância não móvel. Isso informa ao OCI Full Stack DR que ele não deve tentar iniciar uma máquina virtual replicada na região stand-by durante uma operação de DR.
4. Clique em Adicionar para adicionar a instância de computação ao DRPG (não mostrado).

Figura 4.2.2.2: Especifique parâmetros para o servidor de aplicações 1

Tarefa 4.2.3: Adicionar o Oracle E-Business Suite Application Server 2

1. Clique em Adicionar membro para adicionar o 2º servidor de aplicativos.

   
   Figura 4.2.3.1: Abra a caixa de diálogo Adicionar membros

Selecione o servidor de aplicativos 2 na região 2, conforme mostrado na Figura 4.2.3.2. Não é necessário adicionar grupos de volumes em blocos nem especificar propriedades de rede, pois essa é uma instância não móvel.

1. Selecione Compute como Tipo de Recurso.
2. Escolha o compartimento que contém os servidores de aplicativos do Oracle E-Business Suite e selecione a instância de computação designada como servidor de aplicativos 2.
3. Selecione Instância não móvel. Isso informa ao OCI Full Stack DR que ele não deve tentar iniciar uma máquina virtual replicada na região stand-by durante uma operação de DR.
4. Clique em Adicionar para adicionar a instância de computação ao DRPG (não mostrado).

Figura 4.2.3.2: Especifique parâmetros para o servidor de aplicações 2

Tarefa 4.2.4: Adicionar Banco de Dados em Cluster Stand-by da Oracle

1. Clique em Adicionar membro para adicionar o banco de dados como membro.

   
   Figura 4.2.4.1: Abra a caixa de diálogo Adicionar membros

Selecione o banco de dados RAC do Oracle E-Business Suite na região 2, conforme mostrado na Figura 4.2.4.2. Isso também funciona exatamente da mesma forma para bancos de dados de uma única instância.

1. Escolha Banco de Dados como o Tipo de Recurso. O tipo de recurso Banco de Dados permite a escolha do Oracle Base Database Service ou do Oracle Exadata Database Service on Dedicated Infrastructure, que são suportados pela engenharia do Oracle E-Business Suite como opções válidas.
2. A figura abaixo mostra o Oracle Base Database Service, mas você também pode usar o popular Oracle Exadata Database Service on Dedicated Infrastructure.
3. Escolha os valores desses campos que correspondem à sua implantação. Pergunte ao administrador do banco de dados se você não souber as respostas para essas seleções.
4. Selecione o compartimento e o segredo do vault que contêm a senha do banco de dados. Você deve ter criado um vault e um segredo semelhantes na região 2 como parte da Tarefa 2.4. Esse parâmetro está na caixa de diálogo para compatibilidade com outras APIs DBaaS, mas a senha não é realmente usada.
5. Clique em Adicionar para adicionar o banco de dados como um membro (não mostrado).

Figura 4.2.4.2: Especifique parâmetros para o banco de dados RAC na região 2

A lista de membros no Grupo de Proteção de DR deve ser semelhante à captura de tela mostrada na Figura 4.2.4.3. Sua lista poderá ser diferente se você estiver adicionando mais do que o Oracle E-Business Suite a este Grupo de Proteção de DR específico ou estiver adicionando recursos de membro do Oracle E-Business Suite a um grupo de proteção de DR existente.

Figura 4.2.4.3: Lista completa de membros necessários para o Oracle E-Business Suite na região 2

Tarefa 5: Criar os Planos de DR na Região 2

Esta tarefa cria planos básicos de switchover, failover e início de drill associados ao Grupo de Proteção de DR stand-by na região 2 (Ashburn).

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 automaticamente revertidas 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 ambos os planos com etapas incorporadas com base nos recursos dos membros adicionados nas tarefas anteriores. Os planos serão personalizados em etapas posteriores para tratar todas as tarefas relacionadas ao Oracle E-Business Suite System durante uma operação de recuperação.

Os planos de DR 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 Ashburn.

Crie planos básicos selecionando o DRPG na região 2, conforme mostrado na Figura 5-1.

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

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

Tarefa 5.1: Criar Plano de DR para Switchover na Região 2

A criação de um plano de DR é simples, conforme mostrado na Figura 5-2.

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 Tipo de plano. Há apenas quatro tipos de plano no momento desta redação.

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

Tarefa 5.2: Criar Plano de DR para Failover na Região 2

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

1. Torne o nome do plano de failover simples, mas significativo.
2. Selecione Tipo de plano. Há apenas quatro tipos de plano no momento desta redação.

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

Tarefa 5.3: Criar Plano de DR para Iniciar Drill na Região 2

Siga o mesmo processo para criar um plano de drill inicial, conforme mostrado na Figura 5-3.

1. Torne o nome do plano de detalhamento inicial simples, mas significativo.
2. Selecione Tipo de plano. Há apenas quatro tipos de plano no momento desta redação.

Figura 5-3: Os parâmetros necessários para criar o plano de drill inicial de DR

O Grupo de Proteção de DR stand-by na região 2 agora deve ter os três planos de DR, conforme mostrado na imagem a seguir. Isso tratará da 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 das cargas de trabalho da região 2 de volta para a região 1 em uma tarefa posterior.

Figura 5-4: Mostrando os três planos básicos de DR que devem existir na região 2 antes de prosseguir

Observação: O OCI Full Stack DR só suportará a criação de um plano de interrupção de drill após a execução bem-sucedida do plano de inicialização de drill. Para o tutorial, está fora do escopo criar um plano de detalhamento de interrupção, mas é altamente recomendável que um detalhamento de interrupção também seja criado nos dois grupos de proteção de DR.

Tarefa 6: Personalizar os Planos de DR na Região 2 (Ashburn)

O OCI Full Stack DR tem inteligência integrada para orquestrar a recuperação de recursos do OCI Infrastructure as a Service (IaaS) e Platform as a Service (PaaS). O OCI Full Stack DR não tem inteligência integrada para orquestrar a recuperação do Oracle E-Business Suite, pois o Oracle E-Business Suite não fornece APIs de recuperação de desastres nativas do OCI para implementar ou gerenciar sua própria recuperação de desastres integrada.

No entanto, o OCI Full Stack DR ainda pode orquestrar a recuperação para o Oracle E-Business Suite adicionando Grupos de Planos de DR definidos pelo usuário e etapas aos planos de DR base criados como parte da Tarefa 5. As etapas definidas pelo usuário chamam os scripts do Oracle E-Business Suite que foram baixados e instalados nos servidores de aplicativos do Oracle E-Business Suite em ambas as regiões ou no nó de controle de DR dedicado como parte da Tarefa 2.3. A seguir estão os grupos de planos definidos pelo usuário em alto nível. Os grupos de planos que precisam ser adicionados variarão dependendo dos tipos de plano de DR.

1. Faça shutdown do Oracle E-Business Suite e desative jobs de rsync em node2 na região 1.
2. Faça shutdown do Oracle E-Business SuiteS e desative jobs de rsync em node1 na região 1.
3. Limpe os nomes de nós nas tabelas fnd do banco de dados na região 2.
4. Configure o contexto do aplicativo no banco de dados em node1 na região 2.
5. Configure o contexto do aplicativo no banco de dados em node2 na região 2.
6. Execute autoconfig no node1 na região 2.
7. Execute autoconfig no node2 na região 2.
8. Inicie o Oracle E-Business Suite e ative jobs de rsync em node1 na região 2.
9. Inicie o Oracle E-Business Suite e ative jobs de rsync em node2 na região 2.

Tarefa 6.1: Selecionar o Plano de Switchover

Comece navegando até o plano de alternância criado na Tarefa 5.

Figura 6.1: Selecione o plano de switchover na região 2

O OCI Full Stack DR gerará os grupos de planos Prechecks-Built in e Databases-Switchover. Isso foi gerado com base nos membros que adicionamos aos grupos de proteção de DR na região 1 e na região 2.

Figura 6.1.1: Grupos de planos padrão para o plano de switchover na região 2

Tarefa 6.2: Criar Grupo de Planos para Fazer Shutdown do Oracle E-Business Suite e Desativar Jobs de Rsync no Nó 2 na Região 1

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

O primeiro grupo de planos definido pelo usuário fará shutdown do Oracle E-Business Suite e desativará os jobs rsync em node2 na região 1. Esse grupo de planos conterá duas etapas que chamam os scripts bash shutdownapps.sh e fsdr-rsync-ebs.sh que foram transferidos por download para os nós do servidor de aplicativos do Oracle E-Business Suite na Tarefa 2.3.

Tarefa 6.2.1: Selecionar Adicionar grupo de planos

Inicie o processo para adicionar um grupo de planos.

1. Clique em Adicionar grupo para começar.

   
   Figura 6-2.1: Comece a adicionar o grupo de planos para fazer shutdown do Oracle E-Business Suite e desative jobs rsync em node2

Tarefa 6.2.2: Fornecer Nome do Grupo de Planos, Ordenar e Adicionar Etapa

Um Grupo de Planos de DR pode conter muitas etapas que são todas executadas em paralelo. Vamos adicionar duas etapas para executar scripts bash para interromper o Oracle E-Business Suite no node2 e desativar jobs rsync cron no node2 na região 1. No nosso exemplo, o nome node2 é ebshaapp02phx.

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 adicionar antes do grupo de planos Databases-Switchover.
3. Selecione o grupo de planos Bancos de Dados - Switchover integrado.
4. Vamos adicionar dois passos. A primeira etapa é interromper o Oracle E-Business Suite no nó 2 e o segundo script é desativar jobs de rsync no nó 2.
5. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para interromper o Oracle E-Business Suite no node2.

Figura 6.2.2: Grupo de planos para encerrar o Oracle E-Business Suite e interromper jobs rsync

Tarefa 6.2.3: Fornecer Nomes de 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. Vamos adicionar duas etapas neste grupo de planos.

• A Etapa 1 é interromper o aplicativo Oracle E-Business Suite em node2.
• Etapa 2: é desativar jobs rysnc em node2.

Para essa configuração, o nó 2 é ebshaapp02phx

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

1. Um nome descritivo que explica qual tarefa esta etapa executa.

2. Selecione a Região 1, então no nosso caso é Phoenix..

3. Selecione Executar script local.

4. Selecione o compartimento correto que contém o aplicativo node2 do Oracle E-Business Suite e selecione o nó 2. No nosso caso, ele é ebshaapp02phx.

5. Cole no caminho absoluto em que você instalou o script shutdownapps.sh no aplicativo node2 do Oracle E-Business Suite com os parâmetros corretos. Você pode consultar os detalhes do arquivo readme no link GitHub fornecido na Tarefa 2.3 para obter a sintaxe exata.

6. Especifique oracle como o usuário para executar o script.

7. O plano de DR deverá ser interrompido se o script falhar ao interromper o aplicativo Oracle E-Business Suite em node2. Isso permitirá que qualquer um veja que há um problema e corrija-o. O OCI Full Stack DR oferece a oportunidade de continuar executando o plano de switchover após corrigir o problema.

8. O valor padrão antes de o OCI Full Stack DR declarar que uma falha é de 60 minutos (3600 segundos). Este valor pode ser alterado para 1800 segundos ou o que for considerado um valor de tempo limite mais realista.

9. Clique em Adicionar Etapa para adicionar esta etapa ao grupo de planos.

   
   Figura 6.2.3.1: Parâmetros para criar a etapa do plano para interromper o Oracle E-Business Suite no nó 2

10. Ele será exibido como abaixo quando a etapa 1 for adicionada.

    
    Figura 6.2.3.2: A etapa Interromper Oracle E-Business Suite no nó 2 foi adicionada

11. Clique em Adicionar Etapa para adicionar a segunda etapa a esse grupo de planos.

12. Um nome descritivo que explica qual tarefa esta etapa executa.

13. Selecione a Região 1, portanto, no nosso caso, é Phoenix.

14. Selecione Executar script local.

15. Selecione o compartimento correto que contém o aplicativo node2 do Oracle E-Business Suite e selecione o nó 2. No nosso caso, ele é ebshaapp02phx.

16. Cole no caminho absoluto em que você instalou o script fsdr-rsync-ebs.sh no aplicativo node2 do Oracle E-Business Suite com os parâmetros corretos. Você pode consultar os detalhes do arquivo readme no link GitHub fornecido na Tarefa 2.3 para obter a sintaxe exata.

17. Especifique oracle como o usuário para executar o script.

18. O plano de DR deverá ser interrompido se o script falhar ao desativar jobs rsync no node2. Isso permitirá que qualquer um veja que há um problema e corrija-o. O OCI Full Stack DR oferece a oportunidade de continuar executando o plano de switchover após corrigir o problema.

19. O valor padrão antes de o OCI Full Stack DR declarar que uma falha é de 60 minutos (3600 segundos). Este valor pode ser alterado para 300 segundos ou o que for considerado um valor de tempo limite mais realista.

20. Clique em Adicionar Etapa para adicionar esta etapa ao grupo de planos.

    
    Figura 6.2.3.1: Parâmetros para criar a etapa do plano para desativar jobs rysnc no nó 2

21. Ele será exibido como abaixo quando a etapa 2 for adicionada.

    
    Figura 6.2.3.2: Desativar jobs rysnc no nó 2 é adicionado

Tarefa 6.2.4: Concluir a adição de grupo de planos e etapas

Os jobs interromper o aplicativo Oracle E-Business Suite e desativar rsync no node2 são adicionados ao grupo de planos de DR.

1. Clique em Adicionar para adicionar o grupo de planos de DR e as etapas ao plano de DR.

   
   Figura 6.2.4.1: Finalize a adição de grupo de planos e etapas para interromper o Oracle E-Business Suite e desativar o job de rsync em node1

2. Verifique se o grupo de planos adicionado está disponível no plano de alternância.

   
   Figura 6.2.4.1: Interrompa o Oracle E-Business Suite e desative o job de rsync no grupo de planos node1 adicionado

Tarefa 6.3: Criar Grupo de Planos para Fazer Shutdown do Oracle E-Business Suite e Desativar Jobs de Rsync no Nó 1 na Região 1

Agora, vamos adicionar o próximo grupo de planos definido pelo usuário.

Este grupo de planos definido pelo usuário fará Shutdown do Oracle E-Business Suite e desativará os jobs rsync em node1 na região 1. Esse grupo de planos conterá duas etapas que chamam os scripts bash shutdownapps.sh e fsdr-rsync-ebs.sh que foram transferidos por download para os nós do servidor de aplicativos do Oracle E-Business Suite na Tarefa 2.3.

Tarefa 6.3.1: Selecionar Adicionar Grupo de Planos

Inicie o processo para adicionar um grupo de planos.

1. Clique em Adicionar grupo para começar.

   
   Figura 6-3.1: Comece a adicionar grupo de planos para fazer shutdown do Oracle E-Business Suite e desative jobs rsync em node1

Tarefa 6.3.2: Fornecer Nome do Grupo de Planos, Ordenar e Adicionar Etapa

Um Grupo de Planos de DR pode conter muitas etapas que são todas executadas em paralelo. Vamos adicionar duas etapas para executar scripts bash para interromper o Oracle E-Business Suite no node1 e desativar jobs rsync cron no node1 na região 1. No nosso exemplo, o nome node1 é ebshaapp01phx.

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 adicionar após o grupo de planos EBS de Shutdown em node2 no PHX.
3. Selecione o grupo de planos Fazer Shutdown do EBS em node2 no PHX definido pelo usuário.
4. Vamos adicionar dois passos. A primeira etapa é interromper o Oracle E-Business Suite no nó 1 e o segundo script é desativar jobs de rsync no nó 1.
5. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para interromper o Oracle E-Business Suite no node2.

Figura 6.3.2: Grupo de planos para encerrar o Oracle E-Business Suite e interromper jobs rsync

Tarefa 6.3.3: Fornecer Nomes de 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. Vamos adicionar duas etapas neste grupo de planos.

• A Etapa 1 é interromper o aplicativo Oracle E-Business Suite em node1.
• A Etapa 2 é desativar jobs rysnc em node1.

Para essa configuração, o nó 1 é ebshaapp01phx

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

1. Um nome descritivo que explica qual tarefa esta etapa executa.

2. Selecione o tipo definido pelo usuário como Executar script local.

3. Selecione a Região 1, portanto, no nosso caso, é Phoenix.

4. Selecione o compartimento correto que contém o aplicativo node1 do Oracle E-Business Suite e selecione o nó 1. No nosso caso, ele é ebshaapp01phx.

5. Cole no caminho absoluto em que você instalou o script shutdownapps.sh no aplicativo node2 do Oracle E-Business Suite com os parâmetros corretos. Você pode consultar os detalhes do arquivo readme no link GitHub fornecido na Tarefa 2.3 para obter a sintaxe exata.

6. Especifique oracle como o usuário para executar o script.

7. O plano de DR deverá ser interrompido se o script falhar ao interromper o aplicativo Oracle E-Business Suite em node1. Isso permitirá que qualquer um veja que há um problema e corrija-o. O OCI Full Stack DR oferece a oportunidade de continuar executando o plano de switchover após corrigir o problema.

8. O valor padrão antes de o OCI Full Stack DR declarar que uma falha é de 60 minutos (3600 segundos). Este valor pode ser alterado para 1800 segundos ou o que for considerado um valor de tempo limite mais realista.

9. Clique em Adicionar Etapa para adicionar esta etapa ao grupo de planos.

   
   Figura 6.3.3.1: Parâmetros para criar a etapa do plano para interromper o Oracle E-Business Suite no nó 1

10. Ele será exibido como abaixo quando a etapa 1 for adicionada.

    
    Figura 6.3.3.2: A etapa Interromper Oracle E-Business Suite no nó 1 foi adicionada

11. Clique em Adicionar Etapa para adicionar a segunda etapa a esse grupo de planos.

12. Um nome descritivo que explica qual tarefa esta etapa executa.

13. Selecione a Região 1, portanto, no nosso caso, é Phoenix.

14. Selecione Executar script local.

15. Selecione o compartimento correto que contém o aplicativo node1 do Oracle E-Business Suite e selecione o nó 1. No nosso caso, ele é ebshaapp02phx.

16. Cole no caminho absoluto em que você instalou o script fsdr-rsync-ebs.sh no aplicativo node2 do Oracle E-Business Suite com os parâmetros corretos. Você pode consultar os detalhes do arquivo readme no link GitHub fornecido na Tarefa 2.3 para obter a sintaxe exata.

17. Especifique oracle como o usuário para executar o script.

18. O plano de DR deverá ser interrompido se o script falhar ao desativar jobs rsync no node1. Isso permitirá que qualquer um veja que há um problema e corrija-o. O OCI Full Stack DR oferece a oportunidade de continuar executando o plano de switchover após corrigir o problema.

19. O valor padrão antes de o OCI Full Stack DR declarar que uma falha é de 60 minutos (3600 segundos). Este valor pode ser alterado para 300 segundos ou o que for considerado um valor de tempo limite mais realista.

20. Clique em Adicionar Etapa para adicionar esta etapa ao grupo de planos.

    
    Figura 6.3.3.1: Parâmetros para criar a etapa do plano para desativar jobs rysnc no nó 1

21. Ele será exibido como abaixo quando a etapa 2 for adicionada.

    
    Figura 6.3.3.2: Desativar jobs rysnc no nó 1 é adicionado

Tarefa 6.3.4: Concluir a adição de grupo de planos e etapas

Os jobs interromper o aplicativo Oracle E-Business Suite e desativar rsync no node2 são adicionados ao grupo de planos de DR.

1. Clique em Adicionar para adicionar o grupo de planos de DR e as etapas ao plano de DR.

   
   Figura 6.3.4.1: Finalize a adição de grupo de planos e etapas para interromper o Oracle E-Business Suite e desativar o job de rsync em node1

2. Verifique se o grupo de planos adicionado está disponível no plano de alternância.

   
   Figura 6.3.4.1: Interrompa o Oracle E-Business Suite e desative o job de rsync no grupo de planos node1 adicionado

Tarefa 6.4: Criar Grupo de Planos para Limpar Nomes de Nós nas Tabelas fnd do Banco de Dados na Região 2

Agora, vamos adicionar o próximo grupo de planos definido pelo usuário.

Este grupo de planos definido pelo usuário limpará os nomes dos nós nas tabelas fnd do banco de dados na região 2. Esse grupo de planos conterá uma etapa que chama o script bash fndnodeclean.sh que foi baixado para os nós do servidor de aplicativos do Oracle E-Business Suite na Tarefa 2.3.

Tarefa 6.4.1: Selecionar adicionar grupo de planos

Inicie o processo para adicionar um grupo de planos.

1. Clique em Adicionar grupo para começar.

   
   Figura 6.4.1: Comece a adicionar grupo de planos para fazer shutdown do Oracle E-Business Suite e desative jobs rsync em node1

Tarefa 6.4.2: Fornecer Nome do Grupo de Planos, Ordem e Adicionar Etapa

Vamos adicionar um para executar o script bash para limpar nomes de nós nas tabelas fnd do banco de dados em node1 na região 1. No nosso exemplo, o nome node1 é ebshaapp01iad.

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 adicionar após o grupo de planos Bancos de Dados - Switchover.
3. Selecione o grupo de planos Bancos de Dados - Switchover integrado.
4. Estaremos adicionando uma etapa para limpar nomes de nós nas tabelas fnd do banco de dados.
5. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para limpar nomes de nós nas tabelas fnd do banco de dados.

Figura 6.4.2: Grupo de planos para limpar nomes de nós nas tabelas fnd do banco de dados.

Tarefa 6.4.3: Fornecer Nomes de 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. Vamos adicionar um único neste grupo de planos.

• A Etapa deve executar fndnodeclean no node1.

Para essa configuração, o nó 1 é ebshaapp01iad

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

1. Um nome descritivo que explica qual tarefa esta etapa executa.

2. Selecione o tipo definido pelo usuário como Executar script local.

3. Selecione a Região 2, portanto, no nosso caso, é Ashburn.

4. Selecione o compartimento correto que contém o aplicativo node1 do Oracle E-Business Suite e selecione o nó 1. No nosso caso, ele é ebshaapp01iad.

5. Cole no caminho absoluto em que você instalou o script fndnodeclean.sh no aplicativo node1 do Oracle E-Business Suite com os parâmetros corretos. Você pode consultar os detalhes do arquivo readme no link GitHub fornecido na Tarefa 2.3 para obter a sintaxe exata.

6. Especifique oracle como o usuário para executar o script.

7. O plano de DR deverá ser interrompido se o script falhar ao interromper o aplicativo Oracle E-Business Suite em node1. Isso permitirá que qualquer um veja que há um problema e corrija-o. O OCI Full Stack DR oferece a oportunidade de continuar executando o plano de switchover após corrigir o problema.

8. O valor padrão antes de o OCI Full Stack DR declarar que uma falha é de 60 minutos (3600 segundos). Este valor pode ser alterado para 900 segundos ou o que for considerado um valor de tempo limite mais realista.

9. Clique em Adicionar Etapa para adicionar esta etapa ao grupo de planos.

   
   Figura 6.4.3.1: Parâmetros para criar a etapa do plano para limpar nomes de nós nas tabelas fnd do banco de dados

10. Ele será exibido como abaixo quando a etapa 1 for adicionada.

    
    Figura 6.4.3.2: Limpar nomes de nós nas tabelas fnd do banco de dados

Tarefa 6.4.4: Concluir a adição de grupo de planos e etapas

Etapa para limpar nomes de nó nas tabelas fnd do banco de dados adicionada ao grupo de planos de DR.

1. Clique em Adicionar para adicionar o grupo de planos de DR e as etapas ao plano de DR.

   
   Figura 6.4.4.1: Finalize a adição de grupo de planos e etapa para limpar nomes de nós nas tabelas fnd do banco de dados

2. Verifique se o grupo de planos adicionado está disponível no plano de alternância.

   
   Figura 6.4.4.2: Para limpar nomes de nós nas tabelas fnd do banco de dados no grupo de planos node1 adicionado

Tarefa 6.5: Criar Grupo de Planos para Configurar o Contexto do Aplicativo no Banco de Dados em node1 na Região 2

Agora, vamos adicionar o próximo grupo de planos definido pelo usuário.

Este grupo de planos definido pelo usuário configurará o contexto do aplicativo no banco de dados em node1 na região 2. Esse grupo de planos conterá uma etapa que chama o script bash dbtxkconfig.sh que foi baixado para os nós do servidor de aplicativos do Oracle E-Business Suite na Tarefa 2.3.

Tarefa 6.5.1: Selecionar Adicionar Grupo de Planos

Inicie o processo para adicionar um grupo de planos.

1. Clique em Adicionar grupo para começar.

   
   Figura 6.5.1: Comece a adicionar o grupo de planos para configurar o contexto do aplicativo no banco de dados em node1

Tarefa 6.5.2: Fornecer Nome do Grupo de Planos, Ordenar e Adicionar Etapa

Vamos adicionar uma etapa para executar o script bash para configurar o contexto do aplicativo no banco de dados no node1 na região 2. No nosso exemplo, o nome node1 é ebshaapp01iad.

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 adicionar após o grupo de planos Limpar nomes de nó nas tabelas fnd do banco de dados no grupo de planos IAD.
3. Selecione o grupo de planos Limpar nomes de nó nas tabelas fnd do banco de dados no IAD.
4. Vamos adicionar uma etapa para configurar o contexto do aplicativo no banco de dados em node1.
5. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para configurar o contexto do aplicativo no banco de dados em node1.

Figura 6.5.2: Grupo de planos para configurar o contexto do aplicativo no banco de dados em node1

Tarefa 6.5.3: Fornecer Nomes de 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. Vamos adicionar um único neste grupo de planos.

• A Etapa é executar dbtxkconfig no node1 (alterar nomes de host físicos).

Para essa configuração, o nó 1 é ebshaapp01iad

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

1. Um nome descritivo que explica qual tarefa esta etapa executa.

2. Selecione o tipo definido pelo usuário como Executar script local.

3. Selecione a Região 2, portanto, no nosso caso, é Ashburn.

4. Selecione o compartimento correto que contém o aplicativo node1 do Oracle E-Business Suite e selecione o nó 1. No nosso caso, ele é ebshaapp01iad.

5. Cole no caminho absoluto em que você instalou o script dbtxkconfig.sh no aplicativo node1 do Oracle E-Business Suite com os parâmetros corretos. Você pode consultar os detalhes do arquivo readme no link GitHub fornecido na Tarefa 2.3 para obter a sintaxe exata. É extremamente importante fornecer todos os detalhes com os parâmetros corretos.

6. Especifique oracle como o usuário para executar o script.

7. O plano de DR deverá ser interrompido se o script não configurar o contexto do aplicativo no banco de dados node1. Isso permitirá que qualquer um veja que há um problema e corrija-o. O OCI Full Stack DR oferece a oportunidade de continuar executando o plano de switchover após corrigir o problema.

8. O valor padrão antes de o OCI Full Stack DR declarar que uma falha é de 60 minutos (3600 segundos). Este valor pode ser alterado para 900 segundos ou o que for considerado um valor de tempo limite mais realista.

9. Clique em Adicionar Etapa para adicionar esta etapa ao grupo de planos.

   
   Figura 6.5.3.1: Parâmetros para criar a etapa do plano para configurar o contexto do aplicativo no banco de dados node1

10. Ele será exibido como abaixo quando a etapa 1 for adicionada.

    
    Figura 6.5.3.2: Para configurar o contexto do aplicativo no banco de dados node1

Tarefa 6.5.4: Concluir a adição de grupo de planos e etapas

A etapa para configurar o contexto do aplicativo no banco de dados node1 é adicionada ao grupo de planos de DR.

1. Clique em Adicionar para adicionar o grupo de planos de DR e as etapas ao plano de DR.

   
   Figura 6.5.4.1: Finalize a adição do grupo de planos e da etapa para configurar o contexto do aplicativo no banco de dados node1

2. Verifique se o grupo de planos adicionado está disponível no plano de alternância.

   
   Figura 6.5.4.2: Para configurar o contexto do aplicativo no grupo de planos node1 do banco de dados adicionado

Tarefa 6.6: Criar Grupo de Planos para Configurar o Contexto do Aplicativo no Banco de Dados em node2 na Região 2

Agora, vamos adicionar o próximo grupo de planos definido pelo usuário.

Este grupo de planos definido pelo usuário configurará o contexto do aplicativo no banco de dados em node2 na região 2. Esse grupo de planos conterá uma etapa que chama o script bash dbtxkconfig.sh que foi baixado para os nós do servidor de aplicativos do Oracle E-Business Suite na Tarefa 2.3.

Tarefa 6.6.1: Selecionar Adicionar grupo de planos

Inicie o processo para adicionar um grupo de planos.

1. Clique em Adicionar grupo para começar.

   
   Figura 6.6.1: Comece a adicionar o grupo de planos para configurar o contexto do aplicativo no banco de dados em node2

Tarefa 6.6.2: Fornecer Nome do Grupo de Planos, Ordenar e Adicionar Etapa

Vamos adicionar uma etapa para executar o script bash para configurar o contexto do aplicativo no banco de dados no node2 na região 2. No nosso exemplo, o nome node2 é ebshaapp02iad.

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 adicionar após o grupo de planos Configurar contexto do aplicativo no banco de dados em node1 no IAD.
3. Selecione o contexto do aplicativo de Configuração no banco de dados em node1 no grupo de planos do IAD.
4. Vamos adicionar uma etapa para configurar o contexto do aplicativo no banco de dados em node2.
5. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para configurar o contexto do aplicativo no banco de dados em node1.

Figura 6.6.2: Grupo de planos para configurar o contexto do aplicativo no banco de dados em node2

Tarefa 6.6.3: Fornecer Nomes de 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. Vamos adicionar um único neste grupo de planos.

• A Etapa é executar dbtxkconfig no node2 (alterar nomes de host físicos).

Para essa configuração, o nó 2 é ebshaapp02iad

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

1. Um nome descritivo que explica qual tarefa esta etapa executa.

2. Selecione o tipo definido pelo usuário como Executar script local.

3. Selecione a Região 2, portanto, no nosso caso, é Ashburn.

4. Selecione o compartimento correto que contém o aplicativo node1 do Oracle E-Business Suite e selecione o nó 1. No nosso caso, ele é ebshaapp02iad.

5. Cole no caminho absoluto em que você instalou o script dbtxkconfig.sh no aplicativo node1 do Oracle E-Business Suite com os parâmetros corretos. Você pode consultar os detalhes do arquivo readme no link GitHub fornecido na Tarefa 2.3 para obter a sintaxe exata. É extremamente importante fornecer todos os detalhes com os parâmetros corretos.

6. Especifique oracle como o usuário para executar o script.

7. O plano de DR deverá ser interrompido se o script não configurar o contexto do aplicativo no banco de dados node2. Isso permitirá que qualquer um veja que há um problema e corrija-o. O OCI Full Stack DR oferece a oportunidade de continuar executando o plano de switchover após corrigir o problema.

8. O valor padrão antes de o OCI Full Stack DR declarar que uma falha é de 60 minutos (3600 segundos). Este valor pode ser alterado para 900 segundos ou o que for considerado um valor de tempo limite mais realista.

9. Clique em Adicionar Etapa para adicionar esta etapa ao grupo de planos.

   
   Figura 6.6.3.1: Parâmetros para criar a etapa do plano para configurar o contexto do aplicativo no banco de dados node2

10. Ele será exibido como abaixo quando a etapa 1 for adicionada.

    
    Figura 6.6.3.2: Para configurar o contexto do aplicativo no banco de dados node2

Tarefa 6.6.4: Concluir a adição de grupo de planos e etapas

A etapa para configurar o contexto do aplicativo no banco de dados node1 é adicionada ao grupo de planos de DR.

1. Clique em Adicionar para adicionar o grupo de planos de DR e as etapas ao plano de DR.

   
   Figura 6.6.4.1: Finalize a adição do grupo de planos e da etapa para configurar o contexto do aplicativo no banco de dados node2

2. Verifique se o grupo de planos adicionado está disponível no plano de alternância.

   
   Figura 6.6.4.2: Para configurar o contexto do aplicativo no grupo de planos node2 do banco de dados adicionado

Tarefa 6.7: Criar Grupo de Planos para Executar autoconfig no Aplicativo node1 na Região 2

Agora, vamos adicionar o próximo grupo de planos definido pelo usuário.

Este grupo de planos definido pelo usuário executará o autoconfig no aplicativo node1 na região 2. Esse grupo de planos conterá uma etapa que chama o script bash autoconfigapps.sh que foi baixado para os nós do servidor de aplicativos do Oracle E-Business Suite na Tarefa 2.3.

Tarefa 6.7.1: Selecionar Adicionar Grupo de Planos

Inicie o processo para adicionar um grupo de planos.

1. Clique em Adicionar grupo para começar.

   
   Figura 6.7.1: Comece a adicionar o grupo de planos para executar a configuração automática no aplicativo node1

Tarefa 6.7.2: Fornecer Nome do Grupo de Planos, Ordem e Adicionar Etapa

Vamos adicionar uma etapa para executar o script bash para executar autoconfig no aplicativo node1 na região 2. No nosso exemplo, o nome node1 é ebshaapp01iad.

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 adicionar após o grupo de planos Configurar contexto do aplicativo no banco de dados em node2 no IAD.
3. Selecione o contexto do aplicativo de Configuração no banco de dados em node2 no grupo de planos do IAD.
4. Vamos adicionar uma etapa para configurar o contexto do aplicativo no banco de dados em node2.
5. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para executar o autoconfig no aplicativo node1.

Figura 6.7.2: Grupo de planos para executar autoconfiguração no aplicativo node1

Tarefa 6.7.3: Fornecer nomes de etapas e parâmetros de script locais

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. Vamos adicionar um único neste grupo de planos.

• A Etapa deve executar autoconfig no node1.

Para essa configuração, o nó 1 é ebshaapp01iad

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

1. Um nome descritivo que explica qual tarefa esta etapa executa.

2. Selecione o tipo definido pelo usuário como Executar script local.

3. Selecione a Região 2, portanto, no nosso caso, é Ashburn.

4. Selecione o compartimento correto que contém o aplicativo node1 do Oracle E-Business Suite e selecione o nó 1. No nosso caso, ele é ebshaapp01iad.

5. Cole no caminho absoluto em que você instalou o script autoconfigapps.sh no aplicativo node1 do Oracle E-Business Suite com os parâmetros corretos. Você pode consultar os detalhes do arquivo readme no link GitHub fornecido na Tarefa 2.3 para obter a sintaxe exata. É extremamente importante fornecer todos os detalhes com os parâmetros corretos.

6. Especifique oracle como o usuário para executar o script.

7. O plano de DR deverá ser interrompido se o script falhar ao executar autoconfig no aplicativo node1. Isso permitirá que qualquer um veja que há um problema e corrija-o. O OCI Full Stack DR oferece a oportunidade de continuar executando o plano de switchover após corrigir o problema.

8. O valor padrão antes de o OCI Full Stack DR declarar que uma falha é de 60 minutos (3600 segundos). Este valor pode ser alterado para 900 segundos ou o que for considerado um valor de tempo limite mais realista.

9. Clique em Adicionar Etapa para adicionar esta etapa ao grupo de planos.

   
   Figura 6.7.3.1: Parâmetros para criar a etapa do plano para executar a autoconfiguração no aplicativo node1

10. Ele será exibido como abaixo quando a etapa 1 for adicionada.

    
    Figura 6.7.3.2: Para executar a autoconfiguração no aplicativo node1

Tarefa 6.7.4: Concluir a adição de grupo de planos e etapas

A etapa para executar o autoconfig no aplicativo node1 é adicionada ao grupo de planos de DR.

1. Clique em Adicionar para adicionar o grupo de planos de DR e as etapas ao plano de DR.

   
   Figura 6.7.4.1: Finalize a adição de grupo de planos e etapa para executar a autoconfiguração no aplicativo node1

2. Verifique se o grupo de planos adicionado está disponível no plano de alternância.

   
   Figura 6.7.4.2: Para executar autoconfiguração no grupo de planos node1 do aplicativo adicionado

Tarefa 6.8: Criar Grupo de Planos para Executar autoconfig no Aplicativo node2 na Região 2

Agora, vamos adicionar o próximo grupo de planos definido pelo usuário.

Este grupo de planos definido pelo usuário executará o autoconfig no aplicativo node2 na região 2. Esse grupo de planos conterá uma etapa que chama o script bash autoconfigapps.sh que foi baixado para os nós do servidor de aplicativos do Oracle E-Business Suite na Tarefa 2.3.

Tarefa 6.8.1: Selecionar Adicionar Grupo de Planos

Inicie o processo para adicionar um grupo de planos.

1. Clique em Adicionar grupo para começar.

   
   Figura 6.8.1: Comece a adicionar o grupo de planos para executar a configuração automática no aplicativo node2

Tarefa 6.8.2: Fornecer Nome do Grupo de Planos, Ordem e Adicionar Etapa

Vamos adicionar uma etapa para executar o script bash e executar o autoconfig no aplicativo node2 na região 2. No nosso exemplo, o nome node2 é ebshaapp02iad.

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 adicionar após a Executar autoconfiguração no aplicativo node1 no grupo de planos do IAD.
3. Selecione o grupo de planos Executar autoconfiguração no aplicativo node1 no IAD integrado.
4. Vamos adicionar uma etapa para configurar o contexto do aplicativo no banco de dados em node2.
5. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para executar o autoconfig no aplicativo node2.

Figura 6.8.2: Grupo de planos para executar autoconfiguração no aplicativo node2

Tarefa 6.8.3: Fornecer Nomes de 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. Vamos adicionar um único neste grupo de planos.

• A Etapa deve executar autoconfig no node2.

Para essa configuração, o nó 1 é ebshaapp02iad

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

1. Um nome descritivo que explica qual tarefa esta etapa executa.

2. Selecione o tipo definido pelo usuário como Executar script local.

3. Selecione a Região 2, portanto, no nosso caso, é Ashburn.

4. Selecione o compartimento correto que contém o aplicativo node2 do Oracle E-Business Suite e selecione o nó 2. No nosso caso, ele é ebshaapp02iad.

5. Cole no caminho absoluto em que você instalou o script autoconfigapps.sh no aplicativo node1 do Oracle E-Business Suite com os parâmetros corretos. Você pode consultar os detalhes do arquivo readme no link GitHub fornecido na Tarefa 2.3 para obter a sintaxe exata. É extremamente importante fornecer todos os detalhes com os parâmetros corretos.

6. Especifique oracle como o usuário para executar o script.

7. O plano de DR deverá ser interrompido se o script falhar ao executar a configuração automática no aplicativo node2. Isso permitirá que qualquer um veja que há um problema e corrija-o. O OCI Full Stack DR oferece a oportunidade de continuar executando o plano de switchover após corrigir o problema.

8. O valor padrão antes de o OCI Full Stack DR declarar que uma falha é de 60 minutos (3600 segundos). Este valor pode ser alterado para 900 segundos ou o que for considerado um valor de tempo limite mais realista.

9. Clique em Adicionar Etapa para adicionar esta etapa ao grupo de planos.

   
   Figura 6.8.3.1: Parâmetros para criar a etapa do plano para executar a autoconfiguração no aplicativo node2

10. Ele será exibido como abaixo quando a etapa 1 for adicionada.

    
    Figura 6.8.3.2: Para executar a autoconfiguração no aplicativo node2

Tarefa 6.8.4: Concluir a adição de grupo de planos e etapas

A etapa para executar o autoconfig no aplicativo node2 é adicionada ao grupo de planos de DR.

1. Clique em Adicionar para adicionar o grupo de planos de DR e as etapas ao plano de DR.

   
   Figura 6.8.4.1: Finalize a adição de grupo de planos e etapa para executar a autoconfiguração no aplicativo node2

2. Verifique se o grupo de planos adicionado está disponível no plano de alternância.

   
   Figura 6.8.4.2: Para executar autoconfiguração no grupo de planos node2 do aplicativo adicionado

Tarefa 6.9: Criar Grupo de Planos para Iniciar o Oracle E-Business Suite e Ativar Jobs de Rsync no nó 1 na Região 2

Agora, vamos adicionar o próximo grupo de planos definido pelo usuário.

Este grupo de planos definido pelo usuário iniciará o Oracle E-Business Suite e ativará jobs de rsync em node1 na região 2. Esse grupo de planos conterá duas etapas que chamam os scripts bash startapps.sh e fsdr-rsync-ebs.sh que foram transferidos por download para os nós do servidor de aplicativos do Oracle E-Business Suite na Tarefa 2.3.

Tarefa 6.9.1: Selecionar Adicionar Grupo de Planos

Inicie o processo para adicionar um grupo de planos.

1. Clique em Adicionar grupo para começar.

   
   Figura 6-9.1: Comece a adicionar o grupo de planos à inicialização do Oracle E-Business Suite e ative jobs rsync em node1

Tarefa 6.9.2: Fornecer Nome do Grupo de Planos, Ordem e Adicionar Etapa

Um Grupo de Planos de DR pode conter muitas etapas que são todas executadas em paralelo. Vamos adicionar duas etapas para executar scripts bash para iniciar o Oracle E-Business Suite no node1 e ativar jobs rsync cron no node1 na região 2. No nosso exemplo, o nome node1 é ebshaapp01iad.

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 adicionar após a Executar autoconfiguração no aplicativo node2 no grupo de planos do IAD.
3. Selecione o grupo de planos Executar autoconfiguração no aplicativo node2 definido pelo usuário no IAD.
4. Vamos adicionar dois passos. O primeiro passo é iniciar o Oracle E-Business Suite no nó 1 e o segundo script é ativar jobs rsync no nó 1.
5. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para iniciar o Oracle E-Business Suite no node2.

Figura 6.9.2: Grupo de planos para inicializar ebs e ativar jobs rsync em node1

Tarefa 6.9.3: Fornecer Nomes de 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. Vamos adicionar duas etapas neste grupo de planos.

• A Etapa 1 é iniciar o aplicativo Oracle E-Business Suite em node1.
• Etapa 2 é ativar jobs rysnc em node1.

Para essa configuração, o nó 1 é ebshaapp01iad.

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

1. Um nome descritivo que explica qual tarefa esta etapa executa.

2. Selecione o tipo definido pelo usuário como Executar script local.

3. Selecione a Região 2, por isso, no nosso caso, é Ashburn.

4. Selecione o compartimento correto que contém o aplicativo node1 do Oracle E-Business Suite e selecione o nó 1. No nosso caso, ele é ebshaapp01iad.

5. Cole no caminho absoluto em que você instalou o script startapps.sh no aplicativo node1 do Oracle E-Business Suite com os parâmetros corretos. Você pode consultar os detalhes do arquivo readme no link GitHub fornecido na Tarefa 2.3 para obter a sintaxe exata.

6. Especifique oracle como o usuário para executar o script.

7. O plano de DR deverá ser interrompido se o script falhar ao iniciar o aplicativo Oracle E-Business Suite em node1. Isso permitirá que qualquer um veja que há um problema e corrija-o. O OCI Full Stack DR oferece a oportunidade de continuar executando o plano de switchover após corrigir o problema.

8. O valor padrão antes de o OCI Full Stack DR declarar que uma falha é de 60 minutos (3600 segundos). Este valor pode ser alterado para 1800 segundos ou o que for considerado um valor de tempo limite mais realista.

9. Clique em Adicionar Etapa para adicionar esta etapa ao grupo de planos.

   
   Figura 6.9.3.1: Parâmetros para criar a etapa do plano para iniciar o Oracle E-Business Suite no nó 1

10. Ele será exibido como abaixo quando a etapa 1 for adicionada.

    
    Figura 6.9.3.2: A etapa Iniciar Oracle E-Business Suite no nó 1 foi adicionada

11. Clique em Adicionar Etapa para adicionar a segunda etapa a esse grupo de planos.

12. Um nome descritivo que explica qual tarefa esta etapa executa.

13. Selecione a Região 2, por isso, no nosso caso, é Ashburn.

14. Selecione Executar script local.

15. Selecione o compartimento correto que contém o aplicativo node1 do Oracle E-Business Suite e selecione o nó 1. No nosso caso, ele é ebshaapp0iad.

16. Cole no caminho absoluto em que você instalou o script fsdr-rsync-ebs.sh no aplicativo node1 do Oracle E-Business Suite com os parâmetros corretos. Você pode consultar os detalhes do arquivo readme no link GitHub fornecido na Tarefa 2.3 para obter a sintaxe exata.

17. Especifique oracle como o usuário para executar o script.

18. O plano de DR deverá ser interrompido se o script falhar ao ativar jobs rsync em node1. Isso permitirá que qualquer um veja que há um problema e corrija-o. O OCI Full Stack DR oferece a oportunidade de continuar executando o plano de switchover após corrigir o problema.

19. O valor padrão antes de o OCI Full Stack DR declarar que uma falha é de 60 minutos (3600 segundos). Este valor pode ser alterado para 300 segundos ou o que for considerado um valor de tempo limite mais realista.

20. Clique em Adicionar Etapa para adicionar esta etapa ao grupo de planos.

    
    Figura 6.9.3.1: Parâmetros para criar a etapa do plano para ativar jobs rysnc no nó 1

21. Ele será exibido como abaixo quando a etapa 2 for adicionada.

    
    Figura 6.9.3.2: Ativar jobs rysnc no nó 1 foi adicionado

Tarefa 6.9.4: Concluir a adição de grupo de planos e etapas

Ambos iniciam o aplicativo Oracle E-Business Suite e ativam jobs de rsync em node1 são adicionados ao grupo de planos de DR.

1. Clique em Adicionar para adicionar o grupo de planos de DR e as etapas ao plano de DR.

   
   Figura 6.9.4.1: Finalize a adição de grupo de planos e etapas para iniciar o Oracle E-Business Suite e ativar o job rsync em node1

2. Verifique se o grupo de planos adicionado está disponível no plano de alternância.

   
   Figura 6.9.4.1: Iniciar o Oracle E-Business Suite e ativar o job rsync no grupo de planos node1 adicionado

Tarefa 6.10: Criar Grupo de Planos para Iniciar o Oracle E-Business Suite e Ativar Jobs de Rsync no nó 2 na Região 2

Agora, vamos adicionar o próximo grupo de planos definido pelo usuário.

Este grupo de planos definido pelo usuário iniciará o Oracle E-Business Suite e ativará jobs de rsync em node2 na região 2. Esse grupo de planos conterá duas etapas que chamam os scripts bash startapps.sh e fsdr-rsync-ebs.sh que foram transferidos por download para os nós do servidor de aplicativos do Oracle E-Business Suite na Tarefa 2.3.

Tarefa 6.10.1: Selecionar Adicionar grupo de planos

Inicie o processo para adicionar um grupo de planos.

1. Clique em Adicionar grupo para começar.

   
   Figura 6-10.1: Comece a adicionar o grupo de planos à inicialização do Oracle E-Business Suite e ative jobs rsync em node2

Tarefa 6.10.2: Fornecer Nome do Grupo de Planos, Ordenar e Adicionar Etapa

Um Grupo de Planos de DR pode conter muitas etapas que são todas executadas em paralelo. Vamos adicionar duas etapas para executar scripts bash para iniciar o Oracle E-Business Suite no node1 e ativar jobs rsync cron no node1 na região 2. No nosso exemplo, o nome node1 é ebshaapp02iad.

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 adicionar após o grupo de planos Iniciar EBS no node1 no IAD.
3. Selecione o grupo de planos Startup EBS em node1 no IAD definido pelo usuário.
4. Vamos adicionar dois passos. O primeiro passo é iniciar o Oracle E-Business Suite no nó 2 e o segundo script é ativar jobs rsync no nó 2.
5. Clique em Adicionar Etapa para abrir a caixa de diálogo na qual especificaremos o script para iniciar o Oracle E-Business Suite no node2.

Figura 6.10.2: Grupo de planos para iniciar o Oracle E-Business Suite e ativar jobs rsync em node2

Tarefa 6.10.3: Fornecer Nomes de 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. Vamos adicionar duas etapas neste grupo de planos.

• A Etapa 1 é iniciar o aplicativo Oracle E-Business Suite em node2.
• Etapa 2 é ativar jobs rysnc em node2.

Para essa configuração, o nó 2 é ebshaapp02iad

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

1. Um nome descritivo que explica qual tarefa esta etapa executa.

2. Selecione o tipo definido pelo usuário como Executar script local.

3. Selecione a Região 2, por isso, no nosso caso, é Ashburn.

4. Selecione o compartimento correto que contém o aplicativo node1 do Oracle E-Business Suite e selecione o nó 2. No nosso caso, ele é ebshaapp02iad.

5. Cole no caminho absoluto em que você instalou o script startapps.sh no aplicativo node1 do Oracle E-Business Suite com os parâmetros corretos. Você pode consultar os detalhes do arquivo readme no link GitHub fornecido na Tarefa 2.3 para obter a sintaxe exata.

6. Especifique oracle como o usuário para executar o script.

7. O plano de DR deverá ser interrompido se o script falhar ao iniciar o aplicativo Oracle E-Business Suite em node2. Isso permitirá que qualquer um veja que há um problema e corrija-o. O OCI Full Stack DR oferece a oportunidade de continuar executando o plano de switchover após corrigir o problema.

8. O valor padrão antes de o OCI Full Stack DR declarar que uma falha é de 60 minutos (3600 segundos). Este valor pode ser alterado para 1800 segundos ou o que for considerado um valor de tempo limite mais realista.

9. Clique em Adicionar Etapa para adicionar esta etapa ao grupo de planos.

   
   Figura 6.10.3.1: Parâmetros para criar a etapa do plano para iniciar o Oracle E-Business Suite no nó 2

10. Ele será exibido como abaixo quando a etapa 1 for adicionada.

    
    Figura 6.10.3.2: A etapa Iniciar Oracle E-Business Suite no nó 2 foi adicionada

11. Clique em Adicionar Etapa para adicionar a segunda etapa a esse grupo de planos.

12. Um nome descritivo que explica qual tarefa esta etapa executa.

13. Selecione a Região 2, por isso, no nosso caso, é Ashburn.

14. Selecione Executar script local.

15. Selecione o compartimento correto que contém o aplicativo node1 do Oracle E-Business Suite e selecione o nó 2. No nosso caso, ele é ebshaapp0iad.

16. Cole no caminho absoluto em que você instalou o script fsdr-rsync-ebs.sh no aplicativo node1 do Oracle E-Business Suite com os parâmetros corretos. Você pode consultar os detalhes do arquivo readme no link GitHub fornecido na Tarefa 2.3 para obter a sintaxe exata.

17. Especifique oracle como o usuário para executar o script.

18. O plano de DR deverá ser interrompido se o script falhar ao ativar jobs rsync em node2. Isso permitirá que qualquer um veja que há um problema e corrija-o. O OCI Full Stack DR oferece a oportunidade de continuar executando o plano de switchover após corrigir o problema.

19. O valor padrão antes de o OCI Full Stack DR declarar que uma falha é de 60 minutos (3600 segundos). Este valor pode ser alterado para 300 segundos ou o que for considerado um valor de tempo limite mais realista.

20. Clique em Adicionar Etapa para adicionar esta etapa ao grupo de planos.

    
    Figura 6.10.3.1: Parâmetros para criar a etapa do plano para ativar jobs rysnc no nó 2

21. Ele será exibido como abaixo quando a etapa 2 for adicionada.

    
    Figura 6.10.3.2: Ativar jobs rysnc no nó 2 é adicionado

Tarefa 6.10.4: Concluir a adição de grupo de planos e etapas

Ambos iniciam o aplicativo Oracle E-Business Suite e ativam jobs de rsync em node2 são adicionados ao grupo de planos de DR.

1. Clique em Adicionar para adicionar o grupo de planos de DR e as etapas ao plano de DR.

   
   Figura 6.10.4.1: Finalize a adição de grupo de planos e etapas para iniciar o Oracle E-Business Suite e ativar o job rsync em node2

2. Verifique se o grupo de planos adicionado está disponível no plano de alternância.

   
   Figura 6.10.4.1: Iniciar o Oracle E-Business Suite e ativar o job rsync no grupo de planos node2 adicionado

Observação: com isso, concluímos todos os grupos de planos definidos pelo usuário necessários para o Plano de Transferência. Certifique-se de verificar se você tem os grupos de plano na ordem certa, isso é realmente importante.

Depois que o plano de switchover for personalizado, ele deverá ter esta aparência:

Figura 6.10.5.1: Todos os grupos de planos para o plano de switchover na região 2

Observação: é possível reordenar o grupo de planos caso você não tenha ordenado na ordem correta.

Tarefa 6.11: Selecionar o plano de Failover

Comece navegando até o plano de failover criado na tarefa anterior.

Figura 6.11: Selecione o plano de failover na região 2

O OCI Full Stack DR gerará os grupos de planos Prechecks-Built in e Databases-Failover. Isso foi gerado com base nos membros que adicionamos aos grupos de proteção de DR na região 1 e na região 2.

Figura 6.11.1: Grupos de planos padrão para plano de Failover na região 2

Assim como personalizamos o plano de switchover, adicionaremos os grupos de planos definidos pelo usuário necessários para o plano de failover.

Adicione os seguintes grupos de planos definidos pelo usuário após o grupo de planos integrado Bancos de Dados-Failover.

1. Limpe os nomes de nós nas tabelas fnd do banco de dados na região 2.
2. Configure o contexto do aplicativo no banco de dados em node1 na região 2.
3. Configure o contexto do aplicativo no banco de dados em node2 na região 2.
4. Execute autoconfig no node1 na região 2.
5. Execute autoconfig no node2 na região 2.
6. Inicie o Oracle E-Business Suite e ative jobs de rsync em node1 na região 2.
7. Inicie o Oracle E-Business Suite e ative jobs de rsync em node2 na região 2.

Observação: não estamos executando as etapas para adicionar os grupos de planos definidos pelo usuário novamente. Para obter instruções detalhadas, consulte Tarefa 6.4 a 6.9.

Depois que o plano de failover for personalizado, ele deverá ter a seguinte aparência:

Figura 6.11.1: Todos os grupos de planos para plano de failover na região 2

Observação:

• É possível reordenar os grupos de planos caso você não tenha prescrito na ordem correta.

• Você também pode personalizar o plano Iniciar Drill.

  Observe que, para o plano de drill inicial, não haverá grupos de planos incorporados criados para o Banco de Dados.

  Crie um grupo de planos definido pelo usuário para converter o stand-by físico em um banco de dados stand-by snapshot. Você pode usar comandos padrão do broker do Oracle Data Guard para executar essa operação e colocar em um script wrapper.

  Além disso, você pode adicionar grupos de planos definidos pelo usuário relacionados ao aplicativo, semelhantes ao que você faz para um plano de Failover.

• O OCI Full Stack DR permitirá criar um plano de drill de parada depois que o plano de drill de início for executado. Para obter mais informações, consulte Planos de Drill de DR. O plano Interromper Drill está estornando as operações que foram feitas no plano iniciar drill.

• Você também pode personalizar o plano Interromper Drill.

  Observe que, para o plano de detalhamento de parada, não haverá grupos de planos incorporados criados para o Banco de Dados.

  Crie um grupo de planos definido pelo usuário para converter o stand-by snapshot em um banco de dados físico. Você pode usar comandos padrão do broker do Oracle Data Guard para executar essa operação e colocar em um script wrapper.

  Além disso, você pode adicionar grupos de planos definidos pelo usuário relacionados ao aplicativo para interromper todos os aplicativos relacionados ao Oracle E-Business Suite.

Como parte deste tutorial, executaremos um plano de **Switchover nas tarefas subsequentes.**

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

Os planos de DR de switchover e failover foram criados na região stand-by 2 (Ashburn). Os planos de DR na região 2 permitem que o OCI Full Stack DR faça a transição das cargas de trabalho da região 1 para a região 2. A próxima tarefa é criar planos de switchover, failover e início de drill no grupo de proteção para a região 1 (Phoenix) para que o OCI Full Stack DR possa fazer a transição das 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 (Phoenix) para a região 2 (Ashburn).

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 Oracle Integration Cloud 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 (Ashburn).
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. Certifique-se de que os planos de failover e switchover existam antes de continuar; caso contrário, volte às etapas anteriores para criar e personalizar os dois 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: Monitorar a Execução do Plano de DR

Monitore o plano de switchover até que a carga de trabalho do Oracle E-Business Suite tenha sido totalmente transferida da região 1 para a região 2. Depois que o plano de switchover for concluído com sucesso, o OCI Full Stack DR cuidará da limpeza da alteração das atribuições dos grupos de proteção de DR principal e stand-by entre as regiões.

A Região 2 (Phoenix) será a região principal e a região 1 (Ashburn) será a região stand-by depois que o OCI Full Stack DR tiver concluído o switchover.

1. Verifique a execução bem-sucedida do plano de switchover.

   
   Figura 7-2: Plano de switchover concluído com sucesso na Região 2

2. Verifique a alteração de atribuição no grupo de proteção de DR. A Região 2 (Phoenix) terá a atribuição stand-by agora e a Região 1 (Ashburn) terá a atribuição principal agora.

   
   Figura 7-2: Alteração da atribuição do grupo de proteção de DR após o plano de switchover

Tarefa 8: Criar DR e Personalizar Planos de DR na Região 1 (Phoenix)

Crie os planos de DR no Grupo de Proteção de DR na região 1 (Phoenix), que agora é o par stand-by.

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

O OCI Full Stack DR preencherá previamente ambos os planos com etapas incorporadas com base nos recursos do membro adicionados na etapa anterior. Os planos serão personalizados em etapas posteriores para tratar todas as tarefas relacionadas ao Oracle Integration Cloud durante uma operação de recuperação.

Os planos de DR 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 7.

Siga o mesmo processo da Tarefa 5 para criar os planos de DR na região 1. Depois de criar os planos, verifique-os.

Figura 8-1: Planos de DR na região 1

Siga o mesmo processo de acordo com a Tarefa 6 para personalizar os planos de DR na região 1. Certifique-se de adicionar os grupos de planos definidos pelo usuário. É super importante selecionar as VMs certas do aplicativo Oracle E-Business Suite para regiões de produção e DR para executar os scripts.

1. Faça shutdown do Oracle E-Business Suite e desative jobs de rsync em node2 na região 2.
2. Faça shutdown do Oracle E-Business Suite e desative jobs de rsync em node1 na região 2.
3. Limpe os nomes dos nós nas tabelas fnd do banco de dados na região 1.
4. Configure o contexto do aplicativo no banco de dados em node1 na região 1.
5. Configure o contexto do aplicativo no banco de dados em node2 na região 1.
6. Execute autoconfig no node1 na região 1.
7. Execute autoconfig no node2 na região 1.
8. Inicie o Oracle E-Business Suite e ative jobs de rsync em node1 na região 1.
9. Inicie o Oracle E-Business Suite e ative jobs de rsync em node2 na região 1.

Depois que o plano de switchover for personalizado, ele deverá ter a seguinte aparência:

Figura 8.2: Todos os grupos de planos para o plano de switchover na região 1

Depois que o plano de failover for personalizado, ele deverá ter a seguinte aparência:

Figura 8.3: Todos os grupos de planos para plano de failover na região 1

Observação:

• É possível reordenar os grupos de planos caso você não tenha prescrito na ordem correta.

• Você também pode personalizar o plano Iniciar Drill.

  Observe que, para o plano de drill inicial, não haverá grupos de planos incorporados criados para o Banco de Dados.

  Crie um grupo de planos definido pelo usuário para converter o stand-by físico em um banco de dados stand-by snapshot. Você pode usar comandos padrão do broker do Oracle Data Guard para executar essa operação e colocar em um script wrapper.

  Além disso, você pode adicionar grupos de planos definidos pelo usuário relacionados ao aplicativo, semelhantes ao que você faz para um plano de Failover.

• O OCI Full Stack DR permitirá criar um plano de drill de parada depois que o plano de drill de início for executado. Para obter mais informações, consulte Planos de Drill de DR. O plano Interromper Drill está estornando as operações que foram feitas no plano iniciar drill.

• Você também pode personalizar o plano Interromper Drill.

  Observe que, para o plano de detalhamento de parada, não haverá grupos de planos incorporados criados para o Banco de Dados.

  Crie um grupo de planos definido pelo usuário para converter o stand-by snapshot em um banco de dados físico. Você pode usar comandos padrão do broker do Oracle Data Guard para executar essa operação e colocar em um script wrapper.

  Além disso, você pode adicionar grupos de planos definidos pelo usuário relacionados ao aplicativo para interromper todos os aplicativos relacionados ao Oracle E-Business Suite.

Próximas Etapas

O OCI Full Stack DR para Oracle E-Business Suite deve ser totalmente implementado neste momento. No entanto, a funcionalidade completa deve ser validada antes de usar o OCI Full Stack DR para produção. Todos os planos de failover e switchover devem ser executados para validar se tudo funciona conforme o esperado e a equipe de recuperação entende totalmente todo o processo.

Testar Planos de Switchover

Os planos de switchover foram projetados para limpar todos os artefatos e garantir que todas as atribuições para etapas de recuperação incorporadas, como OCI Load Balancer, OCI Block Storage, OCI File Systems, Oracle Base Database Service e Oracle Autonomous Database, estejam prontas para serem recuperadas da região stand-by sem intervenção humana.

Testar Planos de Failover

Failovers são diferentes. Failovers por sua própria natureza não podem limpar artefatos ou garantir serviços e bancos de dados na região com falha estão prontos para fazer a transição de 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 para instâncias de armazenamento e computação tenham sido encerrados etc. 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 do OCI Full Stack DR para cargas de trabalho de produção. A Região 2 (Ashburn) 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).
• Preparar 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.
• 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.
• Você também pode executar planos de drill de DR em qualquer uma das regiões, dependendo do requisito.

Obter Suporte para esta Solução

A engenharia do OCI Full Stack DR fornece suporte de 1º nível para esta solução.

No entanto, a solução e qualquer automação personalizada apresentada neste tutorial foi desenvolvida e implementada pela equipe de especialistas da Oracle Cloud EMEA, independentemente da organização do Oracle E-Business Suite ou da equipe de engenharia do OCI Full Stack DR.

Relacionamento entre o Oracle E-Business Suite e o OCI Full Stack DR

O OCI Full Stack DR não faz parte do processo de instalação ou implantação do Oracle E-Business Suite e não é mencionado em nenhuma documentação escrita e mantida pelo Oracle E-Business Suite. O método para instalar, configurar e implantar o Oracle E-Business Suite para recuperação de desastres entre regiões da OCI foi desenvolvido e escrito em byOracle a engenharia do E-Business Suite e é completamente independente deste tutorial ou do OCI Full Stack DR.

A organização do Oracle E-Business Suite não está familiarizada com o OCI Full Stack DR e só pode ajudar a resolver problemas com o processo do Oracle E-Business Suite conforme descrito na documentação escrita pelo Oracle E-Business Suite para recuperação de desastres executada manualmente fora do OCI Full Stack DR.

A solução de problemas com o processo manual do Oracle E-Business Suite documentado pelo Oracle E-Business Suite é de responsabilidade do suporte do Oracle E-Business Suite e feita de forma independente do OCI Full Stack DR. O OCI Full Stack DR não impede que os clientes ou o suporte do Oracle E-Business Suite executem o processo de recuperação de desastres documentado do Oracle E-Business Suite manualmente. Portanto, o suporte ao Oracle E-Business Suite resolverá problemas com seu processo manual de recuperação de desastres sem envolver o OCI Full Stack DR.

No entanto, percorrer o processo de recuperação manual documentado pelo Oracle E-Business Suite provavelmente deixará os grupos de proteção do OCI Full Stack DR em um estado inutilizável que precisará ser redefinido para que as operações possam ser retomadas usando o OCI Full Stack DR com o Oracle E-Business Suite. O suporte ao OCI Full Stack DR ajudará os clientes a redefinir os grupos de proteção de DR após o suporte ao Oracle E-Business Suite concluir qualquer solução manual de problemas e resolução.

O suporte começa com o OCI Full Stack DR

O suporte ao OCI Full Stack DR é o primeiro ponto de contato para obter ajuda com qualquer problema encontrado com as etapas e tarefas explicadas neste tutorial. O suporte ao OCI Full Stack DR isolará o problema e determinará qual organização de suporte é melhor qualificada para resolver o problema.

1. O suporte ao OCI Full Stack DR é responsável por:
   1. Ajudando os clientes a entender o significado e a causa das mensagens de erro geradas durante uma operação de DR.
   2. Ajudando os clientes a resolver problemas com políticas do IAM que impedem o Full Stack DR de gerenciar recursos durante uma operação de DR.
   3. Problemas ao criar ou gerenciar grupos de proteção de DR.
   4. Problemas com a criação, execução ou falhas do Plano de DR para chamar corretamente a automação personalizada fornecida pelo Oracle E-Business Suite ou pela equipe de Soluções em Nuvem da EMEA.
   5. Os clientes são responsáveis por solucionar e solucionar quaisquer problemas com scripts personalizados escritos pelo cliente que não fazem parte deste tutorial.
2. O suporte ao OCI Full Stack DR abrirá uma SR com suporte ao Oracle E-Business Suite para quaisquer problemas diretamente relacionados ao próprio Oracle E-Business Suite. Os clientes trabalharão diretamente com o suporte do Oracle E-Business Suite para resolver problemas do Oracle E-Business Suite. O Oracle E-Business Suite é responsável por:
   1. Qualquer problema com a documentação do My Oracle Support (MOS) escrita e mantida pelo Oracle E-Business Suite.
   2. Qualquer problema com scripts fornecidos aos clientes pelo Oracle E-Business Suite.
   3. Quaisquer problemas de banco de dados relacionados ao Oracle E-Business Suite.
   4. Quaisquer problemas de aplicativo relacionados ao Oracle E-Business Suite.
   5. Quaisquer problemas com o processo documentado do Oracle E-Business Suite para recuperar o Oracle E-Business Suite manualmente fora do OCI Full Stack DR.
3. O suporte ao OCI Full Stack DR abrirá uma SR com a equipe interna apropriada do Oracle Cloud Solutions para quaisquer problemas diretamente relacionados aos scripts ou processos descritos neste tutorial. Os clientes trabalharão diretamente com a equipe do Oracle Cloud Solutions para resolver problemas com este tutorial. A equipe do Oracle Cloud Solutions é responsável por:
   1. Quaisquer problemas com os scripts personalizados fornecidos pela equipe de soluções em nuvem.
   2. Quaisquer problemas com o processo geral, conforme descrito neste tutorial.

Como Abrir uma Solicitação de Suporte

Use a console do OCI para abrir uma solicitação de suporte com o suporte ao OCI Full Stack DR. Certifique-se de que o contexto do browser esteja mostrando o grupo de proteção de DR que você criou como parte deste tutorial antes de iniciar este processo.

1. Certifique-se de que o contexto do browser esteja definido como o Grupo de Proteção de DR apropriado.
2. Selecione o servidor de vida útil na Console do OCI.
3. Selecione Criar uma Solicitação de Suporte.

Figura 5: Use a ferramenta de ajuda da console do OCI para abrir uma solicitação de serviço

Fig 6: As solicitações de suporte devem ser abertas usando o botão de ajuda da solicitação

Links Relacionados

• Página do Produto OCI Full Stack Disaster Recovery

• Documentação do OCI Full Stack Disaster Recovery

• Scripts do Oracle Samples Oracle E-Business Suite

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

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

Confirmações

• Autores - Chandra Dharanikota (Especialista em Aplicativos Oracle para OCI, Oracle Technology Cloud Engineering, EMEA), Suraj Ramesh - (Full Stack DR, Revisor técnico)

Mais Recursos de Aprendizagem

Explore outros laboratórios em docs.oracle.com/learn ou acesse mais conteúdo de aprendizado gratuito no canal do Oracle Learning YouTube. Além disso, acesse 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 Multi-Node Oracle E-Business Suite Using OCI Full Stack Disaster Recovery

G35487-02

Copyright ©2025, Oracle and/or its affiliates.