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.

Automate Recovery para Oracle Integration usando o OCI Full Stack Disaster Recovery

Parte 1: Introdução

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

O Oracle Integration é uma plataforma segura e unificada que permite conectar aplicativos na nuvem e locais, automatizar processos de negócios, obter informações sobre seus negócios por meio de análise de métricas de negócios e desenvolver aplicativos web e móveis. O Oracle Integration está disponível em uma região do OCI governada por contratos de nível de serviço (SLAs). Este tutorial detalha o procedimento para criar uma solução de recuperação de desastres gerenciada pelo cliente entre regiões para o Oracle Integration, especificamente para o recurso de integrações no Oracle Integration.

O Oracle Integration é uma oferta gerenciada do OCI Platform as a Service (PaaS), que não é algo que o OCI Full Stack DR possa gerenciar de forma nativa, pois o próprio Oracle Integration não expõe computação, armazenamento ou banco de dados aos usuários do OCI. Mas, o OCI Full Stack DR pode automatizar a recuperação para ofertas PaaS, desde que a equipe de engenharia de um determinado serviço, como o Oracle Integration, tenha documentado uma maneira de provisionar, configurar e recuperar seu serviço para recuperação de desastres entre regiões da OCI. A equipe de engenharia do Oracle Integration documentou Configurando uma Solução de Recuperação de Desastres para o Oracle Integration Generation 2 explicando como provisionar, configurar e recuperar manualmente o Oracle Integration.

O OCI Full Stack Disaster Recovery (DR) não é usado para provisionar ou configurar o Oracle Integration. O Oracle Integration deve ser provisionado e configurado para DR entre regiões, seguindo as instruções passo a passo encontradas em Configurando uma Solução de Recuperação de Desastres para o Oracle Integration Generation 2 antes de tentar usar o OCI Full Stack DR de qualquer maneira.

As etapas manuais de failover prescritas pela engenharia do Oracle Integration nesta documentação: Configurando uma Solução de Recuperação de Desastre para o Oracle Integration Generation 2 também devem ser testadas com sucesso para switchover e switchback antes de usar o OCI Full Stack DR.

O Oracle Integration normalmente faz parte de um sistema maior

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

Este tutorial é incomum no fato de que apenas o Oracle Integration é mostrado e discutido em todo o documento para manter as coisas simples. Normalmente, o Oracle Integration será simplesmente uma pequena parte de um sistema de negócios muito maior e mais complexo que inclui muitos serviços e aplicativos diferentes em um único grupo de proteção de DR do OCI Full Stack e um conjunto de planos de DR. É altamente provável que você siga tutoriais semelhantes do Oracle Help Center (OHC) para outros aplicativos e serviços, como PeopleSoft, WebLogic Server, Oracle Analytics Cloud etc.

Observação: As etapas deste tutorial foram testadas usando o Oracle Integration Generation 2. Este tutorial mostra apenas como implementar o DR para o recurso de integração de aplicativos do Oracle Integration Generation 2, porque não queremos sobrecarregar o leitor introduzindo muitas partes e peças móveis.

Cuidado com a implementação incremental

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

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

Como funciona a recuperação

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

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

Além disso, para garantir que sua instância principal seja atualizada com os parâmetros programados mais recentes, certifique-se de que o arquivo integrations.json seja atualizado com todos os nomes de integração, juntamente com os detalhes da versão, juntamente com o arquivo integration_parameters.json, que precisa ser mantido atualizado com os valores de parâmetro programados mais recentes para todas as integrações programadas. Você pode empregar o processo CI/CD preferido para conseguir isso.

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

Opção 1 para scripts de hospedagem

Na maioria das vezes, o Oracle Integration faz parte de um sistema de negócios maior e mais complexo que inclui um aplicativo como Oracle E-Business Suite, PeopleSoft ou JD Edwards Enterprise, além de outros bancos de dados, instâncias de computação e aplicativos internos. Nesse caso, basta escolher qualquer uma das instâncias de computação "movíveis" que já façam 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 atende a outra finalidade, como um servidor de aplicativos ou um servidor admin de algum tipo.

Este tutorial fará referência a essa instância de computação específica como Nó de Controle ou Nó de DR, mesmo que ela realmente atenda a outra finalidade na pilha de aplicativos.

Opção 2 para scripts de hospedagem

Se essa for uma circunstância incomum em que o Oracle Integration será o único serviço de aplicativo que o OCI Full Stack DR gerenciará durante uma operação de recuperação, uma instância de computação precisará ser criada apenas para hospedar os scripts.

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, pois o Oracle Integration não é algo que o OCI Full Stack DR possa gerenciar nativamente. 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 atuar como um servidor em que scripts personalizados podem residir e ser chamados pelo OCI Full Stack DR durante uma operação de recuperação. Este tutorial explicará como criar grupos e etapas de planos de DR personalizados e definidos pelo usuário como parte de seus planos de DR para chamar os scripts instalados no Nó de Controle.

Arquitetura de Implantação do Oracle Integration

Conforme mostrado na figura, a arquitetura de DR do Oracle Integration Generation 2 inclui duas instâncias do Oracle Integration, distintas como principal e secundária, operando simultaneamente. No entanto, o tráfego é direcionado para apenas uma instância por vez. Inicialmente, o tráfego flui para a instância principal. Se a instância principal ficar indisponível, o registro de DNS será ajustado para redirecionar o tráfego para a instância secundária.

Fig. 1: Arquitetura de referência de DR do Oracle Integration

Depois que as instâncias forem provisionadas, exporte os metadados da instância principal para a instância stand-by. Você pode fazer isso usando a apis REST ou aproveitando a IU do Oracle Integration para exportar e importar os metadados. Após a conclusão dessa migração inicial única dos metadados, você deverá manter os metadados sincronizados entre as instâncias usando o CICD. Você pode usar o Jenkins ou uma ferramenta semelhante para implementar o CICD para suas instâncias e sincronizar os metadados. Você também pode usar uma instância do OCI Compute como servidor de CI Jenkins e hub de CD.

O Oracle Integration deve primeiro ser provisionado e configurado para recuperação de desastres (DR) entre regiões do OCI antes de introduzir o OCI Full Stack DR. É extremamente importante que as etapas manuais para alternar o Oracle Integration, conforme documentado pela engenharia do Oracle Integration, sejam testadas e funcionem corretamente antes de tentar automatizar o processo de switchover/failover usando o OCI Full Stack DR.

Familiarizar-se com todo o processo

A equipe de engenharia do Full Stack Disaster Recovery criou uma série de vídeos complementares para este tutorial para entender todo o fluxo do processo. Esses vídeos fazem parte de uma lista de reprodução do OCI Full Stack DR Oracle Integration em YouTube que pode ser acessada usando os seguintes links:

Parte 2: Instruções Passo a Passo

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

Objetivos

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

Tarefa 1: Implantar o Oracle Integration for DR em regiões do OCI
1. Preparar Nó de Controle do Oracle Integration DR
2. Fazer download de scripts personalizados para o Nó de Controle DR
3. Instale e implante manualmente o Oracle Integration for DR em duas regiões da OCI
4. Teste manualmente todas as etapas de recuperação da região desejada 1 para a região 2
5. Teste manualmente todas as etapas de recuperação da região desejada 2 para a região 1
Tarefa 2: Preparação para o OCI Full Stack DR
1. Criar políticas do IAM para o OCI Full Stack DR
2. Criar políticas do IAM para outros serviços do OCI
3. Criar buckets do armazenamento de objetos para logs
Tarefa 3: Criar Grupos de Proteção de DR (DRPG)
Tarefa 4: Adicionar membros à região 1 DRPG
Tarefa 5: Criar planos de DR na região 2 (Phoenix)
1. Criar plano de switchover
2. Criar plano de failover
Tarefa 6: Personalizar o plano de switchover na região 2 (Phoenix)
Tarefa 7: Personalizar o plano de failover na região 2 (Phoenix)
Tarefa 8: Executar o plano de switchover na região 2 (Phoenix)
Tarefa 9: Criar planos de DR básicos na região 1 (Ashburn)
1. Criar plano de switchover
2. Criar plano de failover
Tarefa 10: Personalizar o plano de switchover na região 1 (Ashburn)
Tarefa 11: Personalizar o plano de failover na região 1 (Ashburn)

Definições e suposições ao longo do tutorial

Regiões

A região 1 é Ashburn
- Ashburn começará como a região principal.
- Essa atribuição será alterada para stand-by depois que você for instruído a executar um switchover em etapas posteriores.
A região 2 é Phoenix
- Phoenix começará como a região em espera.
- Essa função será alterada para principal depois que você for instruído a executar um switchover em etapas posteriores.

Compartimentos

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

Organizar 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 erros humanos e aumenta a velocidade na qual os planos de DR podem ser encontrados e executados
- Compartimento para o Oracle Integration: OIC-demo. O compartimento do próprio OIC, armazenamento, buckets de armazenamento, computação e banco de dados relacionados ao OIC é demo do OIC neste tutorial.
- Compartimento para o OCI Full Stack DR: demonstração do OIC O compartimento para grupos e planos de proteção do OCI Full Stack DR é demonstração do OIC neste tutorial.

Nó de Controle DR do Oracle Integration

O Nó de Controle de DR é qualquer instância de computação designada para hospedar scripts bash personalizados que executam tarefas específicas para recuperar o Oracle Integration. Os scripts são chamados pelo OCI Full Stack DR durante uma operação de recuperação. Este tutorial explica como adicionar os scripts ao OCI Full Stack DR nas etapas 6, 7, 10 e 11.

Para o Oracle Integration como um aplicativo independente: Esta será uma instância de computação especializada criada para atuar como host para os scripts personalizados.
Para o Oracle Integration como parte de uma pilha de aplicativos: Esta será qualquer instância de computação existente que seja membro de um grupo de proteção de DR (DRPG). Por exemplo, o Oracle E-Business Suite ou PeopleSoft terão servidores de aplicativos que são membros dos mesmos DRPGs que estão gerenciando a recuperação do Oracle Integration; qualquer um deles pode cumprir a função de Nó de Controle de DR neste tutorial.

Pré-requisitos

O Oracle Integration 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 abaixo.

Tarefa 1: Implantar o Oracle Integration for Disaster Recovery

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

Tarefa 1.1: Preparar o Nó de Controle de DR para executar a automação personalizada

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

Opção 1: Oracle Integration como um aplicativo independente

Este tutorial pressupõe que o Oracle Integration seja um serviço independente; portanto, você criará uma instância de computação com o Oracle Linux na região 1. Use a configuração de menor custo com o Oracle Linux, pois ela só será usada para hospedar os scripts bash personalizados. A necessidade de uma instância de computação especializada dedicada ao cumprimento dessa função é incomum; a opção 2 é o cenário mais comum para a maioria das organizações.

A instância de computação especializada será adicionada como membro do grupo de proteção de DR na região 1 em uma etapa posterior.

Opção 2: Oracle Integration como parte de uma pilha de aplicativos

Você pode usar qualquer computação móvel existente que faça parte de qualquer aplicativo Oracle ou não Oracle que esteja sendo gerenciado pelo OCI Full Stack DR na região 1. Isso cumprirá a função do Nó de Controle de DR sempre que este tutorial se referir ao Nó de Controle de DR.

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

Opção 3: Oracle Integration como parte de uma pilha de aplicativos com várias ofertas PaaS

Talvez seu sistema de negócios também tenha o Oracle HTTP Server (OHS), o Oracle Integration e o Oracle Data Integrator (ODI). Nesse caso, você pode considerar a criação de uma instância de computação especializada, como faria com a Opção 1, para hospedar scripts de recuperação de DR para todos os vários serviços PaaS.

Tarefa 1.2: Garantir que o grupo de volumes seja replicado para a região 2

Certifique-se de que o volume de inicialização do nó de Controle de DR seja membro de um grupo de volumes em blocos e que o grupo de volumes em blocos seja replicado para a região 2.

Certifique-se de que qualquer outra inicialização e bloco pertencente a qualquer outra computação móvel para este projeto de DR do OCI Full Stack também pertença a grupos de volumes em blocos replicados para a região 2. Se precisar de mais detalhes, consulte a documentação do OCI Block Storage

Tarefa 1.3: Fazer download de scripts bash para o Nó de Controle DR

Faça download dos scripts bash personalizados do github que foram criados especificamente para esta solução de DR do Oracle Integration. Os scripts mostrados abaixo devem ser copiados para qualquer subdiretório na instância de computação que atua como o Nó de Controle de DR do Oracle Integration

O link acima deve ser resolvido para o repositório GitHub:

Mostra o caminho do repositório onde os scripts bash estão localizados em GitHub.
Isso mostra o repositório que contém os scripts bash.

Figura 2-4: Captura de tela do repositório github contendo scripts bash para o Oracle Integration

Tarefa 1.4: Implantar o Oracle Integration for DR

Implemente o Oracle Integration para DR em regiões do OCI usando as instruções passo a passo fornecidas pela equipe do Oracle Integration Engineering.

Tarefa 1.5: Testar Manualmente a Recuperação do Oracle Integration

É uma prática recomendada garantir as etapas de recuperação manual. As etapas manuais para recuperar o Oracle Integration documentadas na Configuração do Disaster Recovery para o Oracle Integration devem ser bem-sucedidas antes de trabalhar com o OCI Full Stack DR.

Tarefa 1.6: Próximas etapas

Retorne a este documento para começar a trabalhar com o OCI Full Stack DR depois que os requisitos a seguir tiverem sido concluídos.

Implante manualmente o Oracle Integration for DR em duas regiões do OCI desejadas.
Teste manualmente todas as etapas de recuperação da região 1 (Ashburn) para a região 2 (Phoenix).
Teste manualmente todas as etapas de recuperação da região 2 (Phoenix) para a região 1 (Ashburn).

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

O OCI Full Stack DR não está envolvido em nenhuma parte desta etapa. As etapas a seguir preparam a tenancy, o compartimento, os serviços do OCI e o Oracle Integration para recuperação automatizada pelo OCI Full Stack DR.

Tarefa 2.1: Criar políticas de IAM para o OCI Full Stack DR

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

Tarefa 2.2: Criar políticas do OCI IAM para outros serviços gerenciados pelo OCI Full Stack DR

O OCI Full Stack DR deve ter a capacidade de controlar e gerenciar outros serviços importantes do OCI, como computação, rede, armazenamento, vaults, bancos de dados e outros serviços diversos. Configure as políticas necessárias do OCI IAM para outros serviços, conforme explicado no documento a seguir.

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

Tarefa 2.3: Criar buckets do OCI Object Storage para logs DRPG

Observação: Ignore a Tarefa 2.3 inteiramente se estiver adicionando o Oracle Integration 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: Object Storage.

Tarefa 2.3.1: Navegar até o OCI Object Storage

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

Certifique-se de que o contexto do browser esteja definido como região 1 (Ashburn).
Selecionar Armazenamento.
Selecionar Buckets.

Figura 2-1: Navegue até o armazenamento de objetos

Tarefa 2.3.2: Bucket de armazenamento do OCI na região 1

Crie um bucket de armazenamento de objetos na região 1. O bucket será designado ao grupo de proteção de DR na região 1 em uma etapa posterior.

Selecione o compartimento que contém recursos relacionados ao OIC.
Selecione Criar Bucket.
Dê ao bucket 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 de DR do OCI Full Stack relacionados a operações de DR para o OIC.
Use o valor padrão para camada e Criptografia.
Selecione Criar para criar o bucket.

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

Tarefa 2.3.3: Bucket de armazenamento do OCI na região 2

Siga o mesmo processo para criar um bucket de armazenamento de objetos na região 2 (Phoenix). O bucket será designado ao grupo de proteção de DR na região 2 em uma etapa posterior.

Altere o contexto para a região 2.
Selecione o compartimento que contém recursos relacionados ao OIC na região 2.
Use o mesmo nome exato que foi designado ao bucket na região 1. Isso facilitará a identificação em uma etapa posterior.
Selecione Criar para criar o bucket.

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

Tarefa 3: Criar Grupos de Proteção de DR em ambas as regiões

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

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

Tarefa 3.1: Navegar até os 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 abaixo.

Certifique-se de que o contexto da região do OCI esteja definido como região 1 (Ashburn).
Selecione Migration & Disaster Recovery.
Selecione os Grupos de Proteção de DR.

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

Tarefa 3.2: Criar um grupo de proteção na região 1

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

Selecione o compartimento no qual você deseja que o DRPG seja criado. Pode ser o mesmo compartimento no qual existem recursos do Oracle Integration ou, nesse caso, um compartimento que atua como um repositório contendo DRPGs para muitos sistemas de negócios diferentes.
Selecione Create DR protection group para abrir a caixa de diálogo.

Figura 3-2: Comece a criar o grupo de proteção de DR na região 1

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

Use um nome simples e significativo para o DRPG; este exemplo mostra o nome do sistema de negócios e a região.
Selecione o bucket de armazenamento de objetos criado na Tarefa 2 para a região 1.

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

Tarefa 3.3: Criar um grupo de proteção na região 2

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

Altere o contexto da região do OCI para a região 2.
Selecione o compartimento no qual você deseja que o DRPG seja criado. Pode ser o mesmo compartimento no qual existem recursos do Oracle Integration ou, nesse caso, um compartimento que atua como um repositório contendo DRPGs para muitos sistemas de negócios diferentes.
Selecione Create DR protection group para abrir a caixa de diálogo

Figura 3-4: Comece a criar o grupo de proteção de DR na região 2

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

Use um nome simples e significativo para o DRPG; este exemplo mostra o nome do sistema de negócios e a região.
Selecione o bucket de armazenamento de objetos criado na Tarefa 2 para a região 2

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

Tarefa 3.4: Associar grupos de proteção na região 1 e região 2

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

Tarefa 3.4.1: Iniciar a associação

Certifique-se de que o contexto da região do OCI esteja definido como região 1 (Ashburn).
Selecione Associar para iniciar o processo.

Figura 3-6: Iniciar associação DRPG

Tarefa 3.4.2: Associar grupos de proteção na região 1 e região 2

Forneça os parâmetros conforme mostrado na Figura 3-7 abaixo.

Selecione a função principal. O OCI Full Stack DR designará automaticamente a atribuição stand-by à região 2.
Selecione a região 2 (Phoenix) na qual o outro DRPG foi criado.
Selecione o DRPG par no qual foi criado.

Figura 3-7: Parâmetros necessários para associar os DRPGs

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

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

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

Figura 3-8: Mostrando o relacionamento de pares da perspectiva DRPG individual

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

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

Figura 3-9: Mostrando o relacionamento de pares da perspectiva global de DRPG

Tarefa 4: Adicionar membros ao Grupo de Proteção de DR

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

Adicione o Nó de Controle de DR como membros ao grupo de proteção de DR Principal. O Nó de Controle de DR é uma instância de computação criada apenas para controlar o Oracle Integration ou é uma instância de computação que faz parte da pilha de aplicativos que você deseja gerenciar com o OCI Full Stack DR.

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

O Nó de Controle DR,
O grupo de volumes que contém o volume de inicialização do Nó de Controle de DR.

Tarefa 4.1: Começar a adicionar membros ao DRPG na região 1

Comece selecionando o DRPG na região 1 conforme mostrado na Figura 4-1 abaixo.

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

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

Tarefa 4.1.1: Adicionar instância de computação para o nó DR

Adicione a instância de computação do Nó de Controle de DR conforme mostrado na figura 4-2 abaixo.

Confirme o aviso sobre planos de DR.
Selecione Calcular como tipo de recurso do membro.
Selecione a instância de computação que você deseja usar o nó de controle DR.
Selecione a instância móvel.
Informe ao OCI Full Stack DR qual VCN e sub-rede designar à(s) VNIC(s) na região 2 durante uma recuperação. A Figura 4-2 mostra uma única VNIC. O OCI Full Stack DR não se importa com quantas VNICs você tem ou como elas são configuradas em qualquer região; especifique o que você precisa que atenda aos seus requisitos.

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

Tarefa 4.1.2: Adicionar grupo de volumes em blocos para o nó DR

Adicione o grupo de volumes em blocos que contém a inicialização do Nó de Controle DR. O grupo de volumes em blocos já deve ter uma replicação entre regiões configurada entre as duas regiões antes de adicioná-lo ao grupo de proteção de DR.

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

Figura 4-3: Parâmetros necessários para adicionar o grupo de volumes de inicialização para o Nó de Controle de DR

Tarefa 4.1.3: Verificar recursos do membro para a região 1

O DRPG para a região 1 deve ter no mínimo dois recursos membros, conforme mostrado na Figura 4-5 abaixo. Os nomes dos recursos dos membros serão diferentes.

A instância de computação móvel e o grupo de volumes em blocos da instância de computação que designamos para atuar no Nó de Controle de DR do OIC.

Figura 4-5: Mostrando membros do DRPG na região 1

Não há necessidade de adicionar membros ao grupo de proteção de DR Stand-by, pois estamos usando a movimentação da instância de computação como nó de DR para hospedar os scripts do Oracle Integration

Tarefa 5: Criar planos de DR básicos na região 2 (Phoenix)

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

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

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

Os planos de switchover são sempre criados no grupo de proteção com a atribuição standby; a região 2 é atualmente o grupo de proteção standby; portanto, começaremos em Phoenix.

Tarefa 5.1: Começar a criar planos de DR

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

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

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

Tarefa 5.1.1: Criar um plano de switchover

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

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.
Escolha o 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 switchover de DR

Tarefa 5.1.2: Criar um plano de failover

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

Torne o nome do plano de failover simples, mas significativo. O nome deve ser o mais curto possível, mas fácil de entender rapidamente para ajudar a reduzir a confusão e o erro humano durante uma crise.
Escolha o tipo de plano. Há apenas dois tipos de plano no momento da redação.

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

O Grupo de Proteção de DR stand-by na região 2 agora deve ter os dois planos de DR, conforme mostrado abaixo. Eles tratarão 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 de cargas de trabalho da região 2 de volta para a região 1 em uma etapa posterior.

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

Tarefa 6: Personalizar o plano de switchover na região 2 (Phoenix)

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

Sincronizar parâmetros programados da região 1 para a região 2
Ative integrações relevantes na região 2
Iniciar integrações programadas na região 2
Atualizar registro de DNS na região 2
Desativar integrações programadas na região 1

Tarefa 6.1: Selecionar o plano de switchover

Comece navegando até o plano de switchover criado na etapa anterior.

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

Tarefa 6.2: Ativar Grupos de Planos de DR que encerram artefatos (opcional)

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

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

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

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

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

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

Este grupo de planos encerra artefatos de instâncias de computação que são deixados para trás na região 1 após as versões replicadas das VMs terem sido iniciadas na região 2 durante a operação de armazenamento em blocos do OCI para reverter a replicação da região 2 de volta para a região 1 como parte do switchover. As VMs restantes não são usadas durante um switchback porque a operação para reverter a replicação de volume em blocos cria todas as novas VMs em grupos de volumes em blocos completamente novos.
Este grupo de planos encerra artefatos de grupos de volumes em blocos (VGs) que são deixados para trás na região 1 depois que as versões replicadas dos VGs foram ativadas na região 2 e a replicação do grupo de volumes foi revertida durante o switchover. Os grupos de volumes em blocos restantes nunca são usados novamente, nem mesmo como parte de um switchover da região 2 de volta para a região 1.

Tarefa 6.2.1: Ativar encerramento do grupo de planos de computação

Ative o grupo de planos.

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

Figura 6-3: Como ativar instâncias de computação de encerramento

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

Ative o grupo de planos.

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

Figura 6-4: Como ativar grupos de volumes de encerramento

Tarefa 6.3: Criar grupo de planos para sincronizar parâmetros programados da região 1 para a região 2

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

O primeiro grupo de planos definido pelo usuário sincronizará os parâmetros programados da região 1 para a região. Este grupo de planos conterá uma única etapa que chama o script bash oic-sync-schedule-parameters.sh que foi baixado para o Nó de Controle de DR na Tarefa 1.4.

Tarefa 6.3.1: Selecionar adicionar grupo de planos

Inicie o processo para adicionar um grupo de plano.

Clique em Adicionar grupo para começar.

Figura 6-5: Comece a adicionar o grupo de planos para sincronizar parâmetros programados

Tarefa 6.3.2: Fornecer nome do grupo de planos, prescrever e adicionar etapa

Um Grupo de Planos de DR pode conter muitas etapas que são todas executadas em paralelo. Estamos apenas adicionando uma única etapa para executar um script bash para sincronizar parâmetros agendados.

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

Figura 6-6: Parâmetros para criar grupo de planos e adicionar etapa para sincronizar parâmetros programados

Tarefa 6.3.3: Fornecer o nome da etapa e os parâmetros do script local

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

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

Um nome descritivo que explica qual tarefa esta etapa executa.
Sempre selecione a região em que o Nó de Controle de DR está sendo executado agora, não em que ele será executado durante um switchover. O OCI Full Stack DR rastreará onde a VM está sendo executada, portanto, você só precisa especificar onde ela está agora. Nesse caso, o Nó de Controle de DR está em execução na região 1 (Ashburn).
Selecione Executar script local para informar ao OCI Full Stack DR que o script será encontrado em uma instância de computação. Os scripts bash foram transferidos por download para o Nó de Controle DR na Tarefa 1.3.
Selecione o compartimento correto que contém o Nó de Controle DR - ele pode ser qualquer compartimento. Selecione a instância de computação designada como o Nó de Controle de DR (pode ser um servidor de aplicativos ou uma VM criada apenas para este projeto/tutorial).
Cole no caminho absoluto em que você instalou o script oic-sync-schedule-parameters.sh no Nó de Controle de DR. Adicione PHX como o parâmetro. Esta é a região de destino na qual queremos sincronizar os parâmetros programados. Talvez você precise fornecer parâmetros de região corretos se estiver usando diferentes regiões do OCI e atualizar scripts.
Especifique opc como o usuário para executar o script.
O plano de DR deverá ser interrompido se o script falhar na sincronização dos parâmetros programados. Isso permitirá que qualquer pessoa veja que há um problema e corrija-o. O OCI Full Stack DR fornece a oportunidade de continuar executando o plano de switchover após corrigir o problema.
O valor padrão antes de o OCI Full Stack DR declarar uma falha é de uma hora. Esse valor pode ser alterado para 30 minutos ou o que for considerado um valor de tempo limite mais realista.
Clique em Adicionar etapa para adicioná-la ao grupo de planos.

Figura 6-7: Parâmetros para criar a etapa do plano para sincronizar parâmetros programados

Tarefa 6.3.4: Conclua a adição do grupo de planos e da etapa

A etapa para interromper os parâmetros programados de sincronização agora é adicionada ao grupo de planos de DR, conforme mostrado na figura 6-8 abaixo.

Isso mostra a etapa do plano que acabou de ser adicionada. É possível adicionar etapas adicionais a um grupo de planos de DR, mas esse grupo de planos só incluirá a etapa para sincronizar parâmetros programados.
Clique em Adicionar para adicionar o grupo de planos de DR e a etapa ao plano de DR.

Figura 6-8: Finalize a adição de grupo de planos e etapa para sincronizar parâmetros programados

Tarefa 6.4: Criar grupo de planos para ativar integrações relevantes no stand-by

O segundo grupo de planos definido pelo usuário ativará integrações relevantes no stand-by depois que o Nó de Controle de DR for iniciado na região stand-by 2. Este grupo de planos conterá uma única etapa que chama o script bash oic-integration-switch.sh que foi baixado para o Nó de Controle de DR na Tarefa 1.3.

Tarefa 6.4.1: Selecionar adicionar grupo de planos

Como antes, clique em Adicionar grupo para começar.

Figura 6-9: Comece a adicionar o grupo de planos para ativar integrações relevantes no stand-by

Tarefa 6.4.2: Fornecer nome do grupo de planos, prescrever e adicionar etapa

Crie um grupo de planos de DR para iniciar a ativação de integrações relevantes no stand-by.

Dê ao grupo de planos um nome simples, mas descritivo.
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 depois do grupo de planos incorporado que inicia a versão replicada do nó de controle DR na região 2
Selecione o grupo de planos Iniciar Instâncias de Computação (Stand-by) incorporado
Clique em Adicionar etapa para abrir a caixa de diálogo em que especificaremos o script para ativar integrações relevantes no stand-by.

Figura 6-10: Parâmetros para criar grupo de planos e adicionar etapa para ativar integrações relevantes no stand-by

Tarefa 6.4.3: Fornecer o nome da etapa e os parâmetros do script local

Tudo nesta etapa é o mesmo que a Tarefa 6.3.3, exceto para os itens mostrados na Figura 6-11 abaixo.

Um nome descritivo que explica qual tarefa esta etapa executa.
Cole no caminho absoluto em que você instalou o script oic-integration-switch.sh no Nó de Controle DR. Adicione activate como o primeiro parâmetro e PHX como second.This é a região de destino na qual queremos ativar integrações relevantes. Talvez você precise fornecer parâmetros de região corretos se estiver usando diferentes regiões do OCI e atualizar scripts.
Clique em Adicionar etapa para adicioná-la ao grupo de planos.

Figura 6-11: Parâmetros para criar a etapa do plano para ativar integrações relevantes no stand-by

Tarefa 6.4.4: Conclua a adição do grupo de planos e da etapa

A etapa para ativar integrações relevantes no stand-by agora é adicionada ao grupo de planos de DR, conforme mostrado na figura 6-12 abaixo.

Isso mostra a etapa do plano que acabou de ser adicionada.
Clique em Adicionar para adicionar o grupo de planos de DR e a etapa ao plano de DR.

Figura 6-12: Finalize a adição de grupo de planos e etapa para ativar integrações relevantes no stand-by

Tarefa 6.5: Criar grupo de planos para iniciar integrações programadas na região 2

O terceiro grupo de planos definido pelo usuário iniciará integrações programadas no stand-by depois que o Nó de Controle de DR for iniciado na região stand-by 2. Este grupo de planos conterá uma única etapa que chama o script bash oic-integration-schedule.sh que foi baixado para o Nó de Controle de DR na Tarefa 1.3.

Tarefa 6.5.1: Selecionar adicionar grupo de planos

Como antes, clique em Adicionar grupo para começar.

Figura 6-13: Comece a adicionar o grupo de planos para iniciar integrações programadas no stand-by

Tarefa 6.5.2: Fornecer nome do grupo de planos, prescrever e adicionar etapa

Crie um grupo de planos de DR para iniciar integrações programadas na região stand-by 2.

Dê ao grupo de planos um nome simples, mas descritivo.
Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Nesse caso, insira o grupo de planos definido pelo usuário após o grupo de planos definido pelo usuário criado na tarefa anterior para ativar integrações relevantes.
Selecione o grupo de planos Ativar integrações relevantes no stand-by incorporado
Clique em Adicionar etapa para abrir a caixa de diálogo em que especificaremos o script para iniciar integrações programadas no stand-by.

Figura 6-14: Parâmetros para criar grupo de planos e adicionar etapa para iniciar integrações programadas no stand-by

Tarefa 6.5.3: Fornecer o nome da etapa e os parâmetros do script local

A caixa de diálogo Adicionar etapa do grupo de planos nos permite especificar parâmetros sobre o que essa etapa executará e como ela se comportará durante a recuperação. Nesse caso, ele iniciará as integrações programadas na região stand-by 2.

Tudo nesta tarefa é o mesmo que a Tarefa 6.3.3, exceto para os itens mostrados na Figura 6-15 abaixo.

Um nome descritivo que explica qual tarefa esta etapa executa.
Cole no caminho absoluto em que você instalou o script oic-integration-schedule.sh no Nó de Controle DR. Adicione start como o primeiro parâmetro e PHX como o segundo.
Clique em Adicionar etapa para adicioná-la ao grupo de planos.

Figura 6-15: Parâmetros para criar a etapa do plano para iniciar integrações programadas no stand-by

Tarefa 6.5.4: Conclua a adição do grupo de planos e da etapa

A etapa para iniciar integrações programadas no stand-by agora é adicionada ao grupo de planos de DR, conforme mostrado na figura 6-16 abaixo.

Isso mostra a etapa do plano que acabou de ser adicionada.
Clique em Adicionar para adicionar o grupo de planos de DR e a etapa ao plano de DR.

Figura 6-16: Finalize a adição de grupo de planos e inicie integrações programadas no stand-by

Tarefa 6.6: Criar grupo de planos para atualizar o registro de DNS na região 2

O quarto grupo de planos definido pelo usuário atualizará o registro de DNS no stand-by depois que o Nó de Controle de DR for iniciado na região stand-by 2. Este grupo de planos conterá uma única etapa que chama o script bash dns_record_update.sh que foi baixado para o Nó de Controle de DR na Tarefa 1.3.

Tarefa 6.6.1: Selecionar adicionar grupo de planos

Como antes, clique em Adicionar grupo para começar.

Figura 6-17: Comece a adicionar o grupo de planos para atualizar o registro de DNS no stand-by

Tarefa 6.6.2: Fornecer nome do grupo de planos, prescrever e adicionar etapa

Crie um grupo de planos de DR para atualizar o registro de DNS para a região 2.

Dê ao grupo de planos um nome simples, mas descritivo.
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 depois do grupo de planos incorporado para iniciar integrações programadas no stand-by
Selecione o grupo de planos incorporado Iniciar integrações programadas no stand-by.
Clique em Adicionar etapa para abrir a caixa de diálogo em que especificaremos o script para atualizar o registro de DNS no stand-by.

Figura 6-18: Parâmetros para criar grupo de planos e adicionar etapa para atualizar o registro de DNS no stand-by

Tarefa 6.6.3: Fornecer o nome da etapa e os parâmetros do script local

Tudo nesta tarefa é o mesmo que a Tarefa 6.3.3, exceto para os itens mostrados na Figura 6-19 abaixo.

Um nome descritivo que explica qual tarefa esta etapa executa.
Cole no caminho absoluto em que você instalou o script dns_record_update.sh no Nó de Controle DR. Adicione a chave de região do OCI para a região 2 (PHX neste exemplo) como um parâmetro.
Clique em Adicionar etapa para adicioná-la ao grupo de planos.

Figura 6-19: Parâmetros para criar a etapa do plano para atualizar o registro DNS no stand-by

Tarefa 6.6.4: Conclua a adição do grupo de planos e da etapa

A etapa para atualizar o registro de DNS em espera agora é adicionada ao grupo de planos de DR, conforme mostrado na figura 6-20 abaixo.

Isso mostra a etapa do plano que acabou de ser adicionada.
Clique em Adicionar para adicionar o grupo de planos de DR e a etapa ao plano de DR.

Figura 6-20: Finalize a adição de grupo de planos e etapa para atualizar o registro de DNS no stand-by

Tarefa 6.7: Criar grupo de planos para desativar integrações programadas na região 1

O grupo de planos final definido pelo usuário desativará as integrações programadas na região 1 depois que o Nó de Controle de DR for iniciado na região stand-by 2. Este grupo de planos conterá uma única etapa que chama o script oic-integration-switch.sh que foi baixado para o Nó de Controle de DR na Tarefa 1.3.

Tarefa 6.7.1: Selecionar adicionar grupo de planos

Como antes, clique em Adicionar grupo para começar.

Figura 6-21: Comece a adicionar grupo de planos para desativar integrações programadas na região 1

Tarefa 6.7.2: Fornecer nome do grupo de planos, prescrever e adicionar etapa

Criar um grupo de planos de DR para desativar integrações programadas na região 1

Dê ao grupo de planos um nome simples, mas descritivo.
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 depois do grupo de planos incorporado para atualizar o registro de DNS no stand-by
Selecione o grupo de planos Atualizar registro de DNS no stand-by incorporado.
Clique em Adicionar etapa para abrir a caixa de diálogo na qual especificaremos o script para desativar integrações programadas na região 1

Figura 6-22: Parâmetros para criar grupo de planos e adicionar etapa para desativar integrações programadas na região 1

Tarefa 6.7.3: Fornecer o nome da etapa e os parâmetros do script local

A caixa de diálogo Adicionar etapa do grupo de planos nos permite especificar parâmetros sobre o que essa etapa executará e como ela se comportará durante a recuperação. Nesse caso, ele desativará as integrações programadas na região 1

Tudo nesta tarefa é o mesmo que a Tarefa 6.3.3, exceto para os itens mostrados na Figura 6-23 abaixo.

Um nome descritivo que explica qual tarefa esta etapa executa.
Cole no caminho absoluto em que você instalou o script oic-integration-switch.sh no Nó de Controle DR. Adicione a chave de região do OCI para a região 1 (IAD neste exemplo) como um parâmetro.
Clique em Adicionar etapa para adicioná-la ao grupo de planos.

Figura 6-23: Parâmetros para criar a etapa do plano para desativar integrações programadas na região 1

Tarefa 6.7.4: Conclua a adição do grupo de planos e da etapa

A etapa para desativar integrações programadas na região 1 agora é adicionada ao grupo de planos de DR, conforme mostrado na figura 6-20 abaixo.

Isso mostra a etapa do plano que acabou de ser adicionada.
Clique em Adicionar para adicionar o grupo de planos de DR e a etapa ao plano de DR.

Figura 6-24: Finalize a adição de grupo de planos e etapa para desativar integrações programadas na região 1

O plano de switchover agora deve incluir os cinco Grupos de Planos de DR para o Oracle Integration, conforme mostrado na captura de tela abaixo. Você poderá ter grupos de planos adicionais se seu grupo de proteção incluir outros aplicativos ou outros serviços do OCI junto com o Oracle Integration

Figura 6-25: Mostrando os cinco grupos de planos definidos pelo usuário adicionados ao plano de switchover

Tarefa 7: Personalizar o plano de failover na região 2 (Phoenix)

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

Ative integrações relevantes na região 2
Atualizar parâmetros programados na região 2
Iniciar integrações programadas na região 2
Atualizar registro de DNS na região 2

Tarefa 7.1: Selecionar o plano de failover

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

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

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

Tarefa 7.2: Selecionar adicionar grupo de planos

O primeiro grupo de planos definido pelo usuário ativará integrações relevantes na região 2. Este grupo de planos conterá uma única etapa que chama o script bash oic-integration-switch.sh que foi baixado para o Nó de Controle de DR na Tarefa 1.3.

Clique em Adicionar grupo para começar.

Figura 7-2: Comece a adicionar o grupo de planos para ativar integrações relevantes

Tarefa 7.2.1: Fornecer nome do grupo de planos, prescrever e adicionar etapa

Um Grupo de Planos de DR pode conter muitas etapas que são todas executadas em paralelo. Estamos apenas adicionando uma única etapa para executar um script bash para ativar integrações relevantes.

Dê ao grupo de planos um nome simples, mas descritivo.
Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Nesse caso, vamos inserir nosso grupo de planos definido pelo usuário após o grupo de planos incorporado que inicia as VMs replicadas na região 2
Selecione o grupo de planos Iniciar Instâncias de Computação (Stand-by) incorporado
Clique em Adicionar etapa para abrir a caixa de diálogo em que especificaremos o script para ativar integrações relevantes

Figura 7-3: Parâmetros para criar grupo de planos e adicionar etapa para ativar integrações relevantes no stand-by

Tarefa 7.2.2: Fornecer o nome da etapa e os parâmetros do script local

A caixa de diálogo Adicionar etapa do grupo de planos nos permite especificar parâmetros sobre o que essa etapa executará e como ela se comportará durante a recuperação. Nesse caso, ele ativará integrações relevantes na região 2, conforme mostrado na Figura 7-4 abaixo.

Um nome descritivo que explica qual tarefa esta etapa executa.
O plano de DR deverá ser interrompido se o script não ativar integrações relevantes. Isso permitirá que qualquer pessoa veja que há um problema e corrija-o. O OCI Full Stack DR fornece a oportunidade de continuar executando o plano de switchover após corrigir o problema.
O valor padrão antes de o OCI Full Stack DR declarar uma falha é de uma hora. Esse valor pode ser alterado para 30 minutos ou o que for considerado um valor de tempo limite mais realista.
Sempre selecione a região em que o Nó de Controle de DR está sendo executado agora, não em que ele será executado durante um switchover. O OCI Full Stack DR rastreará onde a VM está sendo executada, portanto, você só precisa especificar onde ela está agora. Nesse caso, o Nó de Controle de DR está em execução na região 1 (Ashburn).
Selecione Executar script local para informar ao OCI Full Stack DR que o script será encontrado em uma instância de computação. Os scripts bash foram transferidos por download para o Nó de Controle DR na Tarefa 1.3.
Selecione o compartimento correto que contém o Nó de Controle DR - ele pode ser qualquer compartimento. Selecione a instância de computação designada como o Nó de Controle de DR (pode ser um servidor de aplicativos ou uma VM criada apenas para este projeto/tutorial).
Cole no caminho absoluto em que você instalou o script oic-integration-switch.sh no Nó de Controle DR. Adicione activate como o primeiro parâmetro e o PHX como o segundo.
Especifique opc como o usuário para executar o script.
Clique em Adicionar etapa para adicioná-la ao grupo de planos.

Figura 7-4: Parâmetros para criar a etapa do plano para ativar integrações relevantes no stand-by

Tarefa 7.2.3: Conclua a adição do grupo de planos e da etapa

A etapa para ativar integrações relevantes agora é adicionada ao grupo de planos de DR, conforme mostrado na figura 7-5 abaixo.

Isso mostra a etapa do plano que acabou de ser adicionada.
Clique em Adicionar para adicionar o grupo de planos de DR e a etapa ao plano de DR.

Figura 7-5: Finalize a adição de grupo de planos e etapa para ativar integrações relevantes

Tarefa 7.3: Criar grupo de planos para atualizar parâmetros programados na região 2

O segundo grupo de planos definido pelo usuário atualizará os parâmetros programados na região standby 2. Este grupo de planos conterá uma única etapa que chama o script bash oic-update-parameters.sh que foi baixado para o Nó de Controle de DR na Tarefa 1.3.

Tarefa 7.3.1: Selecionar adicionar grupo de planos

Como antes, clique em Adicionar grupo para começar.

Figura 7-6: Comece a adicionar o grupo de planos para atualizar parâmetros programados no stand-by

Tarefa 7.3.2: Fornecer nome do grupo de planos, prescrever e adicionar etapa

Crie um grupo de planos de DR para atualizar parâmetros programados na região 2.

Dê ao grupo de planos um nome simples, mas descritivo.
Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Nesse caso, insira o grupo de planos definido pelo usuário após o grupo de planos definido pelo usuário criado na tarefa anterior para ativar integrações relevantes.
Selecione Ativar integrações relevantes no grupo de planos stand-by.
Clique em Adicionar etapa para abrir a caixa de diálogo em que especificaremos o script para atualizar os parâmetros programados no stand-by.

Figura 7-7: Parâmetros para criar grupo de planos e adicionar etapa para atualizar parâmetros programados no stand-by

Tarefa 7.3.3: Fornecer o nome da etapa e os parâmetros do script local

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

Tudo nesta tarefa é o mesmo que a Tarefa 7.3.2, exceto para os itens mostrados na Figura 7-8 abaixo.

Um nome descritivo que explica qual tarefa esta etapa executa.
Cole no caminho absoluto em que você instalou o script oic-update-parameters.sh no Nó de Controle DR. Adicione PHX como o único parâmetro (PHX neste exemplo).
Clique em Adicionar etapa para adicioná-la ao grupo de planos

Figura 7-8: Parâmetros para criar a etapa do plano para atualizar parâmetros programados no stand-by

Tarefa 7.3.4: Conclua a adição do grupo de planos e da etapa

A etapa para atualizar os parâmetros programados no stand-by agora é adicionada ao grupo de planos de DR, conforme mostrado na figura 7-9 abaixo.

Isso mostra a etapa do plano que acabou de ser adicionada.
Clique em Adicionar para adicionar o grupo de planos de DR e a etapa ao plano de DR.

Figura 7-9: Finalize a adição de parâmetros programados de grupo de planos e atualização de etapas no stand-by

Tarefa 7.4: Criar grupo de planos para iniciar integrações programadas na região 2

Tarefa 7.4.1: Selecionar adicionar grupo de planos

Como antes, clique em Adicionar grupo para começar.

Figura 7-10: Comece a adicionar o grupo de planos para iniciar integrações programadas no stand-by

Tarefa 7.4.2: Fornecer nome do grupo de planos, prescrever e adicionar etapa

Criar um grupo de planos de DR para iniciar integrações programadas no stand-by

Dê ao grupo de planos um nome simples, mas descritivo.
Selecione uma posição na qual o grupo de planos será inserido no plano de DR. Nesse caso, vamos inserir nosso grupo de planos definido pelo usuário após a Atualização dos parâmetros programados nos grupos de planos stand-by
Selecione o grupo de planos Atualizar parâmetros programados no stand-by incorporado.
Clique em Adicionar etapa para abrir a caixa de diálogo em que especificaremos o script para iniciar integrações programadas no stand-by

Figura 7-11: Parâmetros para criar grupo de planos e adicionar etapa para iniciar integrações programadas no stand-by

Tarefa 7.4.3: Fornecer o nome da etapa e os parâmetros do 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.

Tudo nesta tarefa é o mesmo que a Tarefa 7.2.2, exceto para os itens mostrados na Figura 6-19 abaixo.

Um nome descritivo que explica qual tarefa esta etapa executa.
Cole no caminho absoluto em que você instalou o script oic-integration-schedule.sh no Nó de Controle DR. Adicione start como o primeiro parâmetro e PHX como o segundo.
Clique em Adicionar etapa para adicioná-la ao grupo de planos.

Figura 7-12: Parâmetros para criar a etapa do plano para iniciar integrações programadas no stand-by

Tarefa 7.4.4: Conclua a adição do grupo de planos e da etapa

A etapa para iniciar integrações programadas no stand-by agora é adicionada ao grupo de planos de DR, conforme mostrado na figura 7-13 abaixo.

Isso mostra a etapa do plano que acabou de ser adicionada.
Clique em Adicionar para adicionar o grupo de planos de DR e a etapa ao plano de DR.

Figura 7-13: Finalize a adição de grupo de planos e etapa para iniciar integrações programadas no stand-by

Tarefa 7.5: Criar grupo de planos para atualizar o registro de DNS na região 2

Tarefa 7.5.1: Selecionar adicionar grupo de planos

Como antes, clique em Adicionar grupo para começar.

Figura 7-14: Comece a adicionar o grupo de planos para atualizar o registro de DNS no stand-by

Tarefa 7.5.2: Fornecer nome do grupo de planos, prescrever e adicionar etapa

Crie um grupo de planos de DR para atualizar o registro de DNS para a região 2.

Dê ao grupo de planos um nome simples, mas descritivo.
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 depois do grupo de planos incorporado para iniciar integrações programadas no stand-by
Selecione o grupo de planos incorporado Iniciar integrações programadas no stand-by.
Clique em Adicionar etapa para abrir a caixa de diálogo em que especificaremos o script para atualizar o registro de DNS no stand-by.

Figura 7-14: Parâmetros para criar grupo de planos e adicionar etapa para atualizar o registro de DNS no stand-by

Tarefa 7.5.3: Fornecer o nome da etapa e os parâmetros do script local

Tudo nesta tarefa é o mesmo que a Tarefa 6.3.3, exceto para os itens mostrados na Figura 7-15 abaixo.

Um nome descritivo que explica qual tarefa esta etapa executa.
Cole no caminho absoluto em que você instalou o script dns_record_update.sh no Nó de Controle DR. Adicione a chave de região do OCI para a região 2 (PHX neste exemplo) como um parâmetro.
Clique em Adicionar etapa para adicioná-la ao grupo de planos.

Figura 7-15: Parâmetros para criar a etapa do plano para atualizar o registro DNS no stand-by

Tarefa 7.5.4: Conclua a adição do grupo de planos e da etapa

A etapa para atualizar o registro de DNS em espera agora é adicionada ao grupo de planos de DR, conforme mostrado na figura 7-16 abaixo.

Isso mostra a etapa do plano que acabou de ser adicionada.
Clique em Adicionar para adicionar o grupo de planos de DR e a etapa ao plano de DR.

Figura 7-16: Finalize a adição de grupo de planos e etapa para atualizar o registro de DNS no stand-by

O plano de failover agora deve incluir os quatro Grupos de Planos de DR para o Oracle Integration, conforme mostrado na captura de tela abaixo. Talvez você tenha grupos de planos adicionais se seu grupo de proteção incluir outros aplicativos ou serviços do OCI junto com o Oracle Integration.

Figura 7-14: Mostrando os quatro grupos de planos definidos pelo usuário adicionados ao plano de failover

Tarefa 8: Executar o plano de switchover na região 2 (Phoenix)

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

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

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

Tarefa 8.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 da região 1 para a região 2.

Certifique-se de que o contexto da região ainda esteja definido como região stand-by 2 (Phoenix).
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.
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.
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 ambos os planos de DR.
Clique em Execute o plano de DR.

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

Tarefa 8.2: Selecionar plano de switchover e executar

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

Selecione o plano de switchover.
Certifique-se de selecionar ativar pré-verificações.
Clique em Executar plano de DR para começar.

Figura 8-2: Escolha e execute o plano de switchover

Tarefa 8.3: Próximas etapas

Monitore o plano de switchover até que a carga de trabalho do Oracle Integration tenha sido totalmente transferida da região 1 para a região 2. O OCI Full Stack DR cuidará da limpeza de artefatos e da alteração das funções de 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 concluir o switchover.

Tarefa 9: Criar planos de DR na região 1 (Ashburn)

Crie os mesmos planos básicos de switchover e failover no Grupo de Proteção de DR para a região 1 (Ashburn), 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 revertidas automaticamente 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.

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 8.

Tarefa 9.1: Começar a criar planos de DR

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

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

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

Tarefa 9.1.1: Criar um plano de switchover

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

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.
Escolha o tipo de plano. Há apenas dois tipos de plano no momento da redação.

Figura 9-2: Os parâmetros necessários para criar o plano de switchover de DR
Clique em Criar para criar um plano de switchover básico pré-preenchido com etapas básicas incorporadas.

Tarefa 9.2: Criar um plano de failover

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

Torne o nome do plano de failover simples, mas significativo. O nome deve ser o mais curto possível, mas fácil de entender rapidamente para ajudar a reduzir a confusão e o erro humano durante uma crise.
Escolha o tipo de plano. Há apenas dois tipos de plano no momento da redação.
Clique em Criar para criar o plano de failover básico pré-preenchido com etapas básicas incorporadas.

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

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

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

Tarefa 10: Personalizar o plano de switchover na região 1 (Ashburn)

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

Os planos básicos de DR criados na Tarefa 9 não contêm nada para gerenciar tarefas de recuperação específicas do Oracle Integration. Esta tarefa explica como adicionar Grupos de Planos de DR personalizados e definidos pelo usuário e etapas para gerenciar as coisas que precisam ser realizadas durante um switchover para o Oracle Integration:

Sincronize os parâmetros programados da região 1 para a região 2.
Ative integrações relevantes na região 2.
Inicie as integrações programadas na região 2.
Atualize o registro de DNS na região 2.
Desative integrações programadas na região 1.

Tarefa 10.1: Selecionar o plano de switchover

Comece navegando até o plano de switchover criado na etapa anterior.

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

Tarefa 10.2: Ativar Grupos de Planos de DR que encerram artefatos (opcional)

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

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

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

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

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

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

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

Tarefa 10.2.1: Ativar encerramento do grupo de planos de computação

Ative o grupo de planos.

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

Figura 10-3: Como ativar instâncias de computação de encerramento

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

Ative o grupo de planos.

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

Figura 10-4: Como ativar grupos de volumes de encerramento

Tarefa 10.3: Criar vários planos definidos pelo usuário para o plano de Switchover

Já mostramos como criar os vários planos definidos pelo usuário para o plano de switchover da Tarefa 6.3 para 6.7. Usando o processo semelhante, crie cinco grupos de planos personalizados definidos pelo usuário. Use a instância de computação em execução na região Phoenix para executar scripts.

Sincronizar Parâmetros Programados do IAD /home/opc/oic-scripts/oic-sync-schedule-parameters.sh principal para stand-by.
Ative integrações relevantes no /home/opc/oic-scripts/oic-integration-switch.sh stand-by para ativar o IAD.
Inicie as integrações programadas no /home/opc/oic-scripts/oic-integration-schedule.sh stand-by para iniciar o IAD.
Atualize o registro de DNS no IAD /home/opc/oic-scripts/dns-record-update.sh stand-by.
Desative as integrações programadas no /home/opc/oic-scripts/oic-integration-switch.sh principal para desativar o IAD.

Depois que eles forem criados, o plano de switchover agora deverá incluir os cinco Grupos de Planos de DR para integração da Oracle, conforme mostrado na captura de tela abaixo. Talvez você tenha grupos de planos adicionais se seu grupo de proteção incluir outros aplicativos ou serviços do OCI junto com a integração da Oracle.

Figura 10-21: Mostrando os cinco grupos de planos definidos pelo usuário adicionados ao plano de switchover

Tarefa 11: Personalizar o plano de failover na região 1 (Ashburn)

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

Ative integrações relevantes na região 1.
Atualize os parâmetros programados na região 1.
Inicie as integrações programadas na região 1.
Atualize o registro de DNS na região 1.

Tarefa 11.1: Selecionar o plano de switchover

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

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

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

Tarefa 11.2: Criar vários grupos de planos definidos pelo usuário na região 1 (stand-by)

Já mostramos como criar os vários planos definidos pelo usuário para o plano de failover da Tarefa 7.2 a 7.5. Usando o processo semelhante, crie os quatro grupos de planos personalizados definidos pelo usuário abaixo. Use a instância de computação em execução na região Phoenix para executar scripts.

Ative integrações relevantes no /home/opc/oic-scripts/oic-integration-switch.sh stand-by para ativar o IAD.
Atualize os parâmetros programados no IAD /home/opc/oic-scripts/oic-update-parameters.sh stand-by.
Inicie as integrações programadas no /home/opc/oic-scripts/oic-integration-schedule.sh stand-by para iniciar o IAD.
Atualize o registro de DNS no IAD /home/opc/oic-scripts/dns-record-update.sh stand-by.

Depois que eles forem criados, o plano de failover agora deverá incluir os quatro Grupos de Planos de DR para integração com a Oracle, conforme mostrado na captura de tela abaixo. Talvez você tenha grupos de planos adicionais se seu grupo de proteção incluir outros aplicativos ou serviços do OCI junto com a integração da Oracle.

Figura 11-14: Mostrando os quatro grupos de planos definidos pelo usuário adicionados ao plano de failover

Próximas Etapas

O OCI Full Stack DR for Oracle Integration 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 que tudo funciona conforme o esperado e que a equipe de recuperação entenda completamente todo o processo.

Testando planos de switchover

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

Testando planos de failover

Failovers são diferentes. Os failovers por sua própria natureza não podem limpar artefatos ou garantir que serviços e bancos de dados na região com falha estejam prontos para fazer a transição das cargas de trabalho de volta para a região 1. A equipe de recuperação precisa entender e executar tarefas para garantir que o Data Guard esteja no estado correto, que os artefatos das instâncias de armazenamento e computação tenham sido encerrados etc. Leia Redefinindo a Configuração do DR Após um Failover na documentação do OCI Full Stack DR para entender o processo.

Validar todos os planos de DR para aceitação final

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

Teste o switchover da região 2 (principal) de volta para a região 1 (stand-by).
Teste o failover da região 1 (principal) para a região 2 (stand-by).
Prepare a região 1 (principal) para failover da região 2.
Teste o failover da região 2 (principal) para a região 1 (stand-by).
Prepare a região 2 (principal) para um failover ou switchover para a região 2.
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.

Observação: para garantir que o mesmo aplicativo cliente possa ser usado para autenticar as APIs restantes para as instâncias do Oracle Integration, você pode adicionar o escopo das duas instâncias (ou seja, Principal e Secundário) ao aplicativo cliente OAuth. Para configurar o aplicativo cliente OAuth, você pode consultar a documentação oficial.

Confirmação

Autor - Suraj Ramesh (Gerente de Produtos do Full Stack Disaster Recovery)
Colaboradores - Bonnie Rockey (Especialista em Engenharia de Nuvem, Oracle Integration), Akshay Saxena (Especialista em Engenharia de Nuvem, Oracle Integration)

Vídeo 1: Implantar o Oracle Integration for Disaster Recovery Vídeo 2: Automatizar operações de Recuperação de Desastre para o Oracle Integration usando o OCI Full Stack DR Vídeo 3: Scripts usados para automatizar a recuperação para o Oracle Integration

Mais Recursos de Aprendizagem

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

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

Título e Informações de Copyright

Automate Recovery for Oracle Integration using OCI Full Stack Disaster Recovery

F99108-01

May 2024

Oracle e/ou suas empresas afiliadas.

Automate Recovery para Oracle Integration usando o OCI Full Stack Disaster Recovery

Parte 1: Introdução

O Oracle Integration normalmente faz parte de um sistema maior

Cuidado com a implementação incremental

Como funciona a recuperação

Opção 1 para scripts de hospedagem

Opção 2 para scripts de hospedagem

Arquitetura de Implantação do Oracle Integration

Familiarizar-se com todo o processo

Parte 2: Instruções Passo a Passo

Objetivos

Definições e suposições ao longo do tutorial

Regiões

Compartimentos

Nó de Controle DR do Oracle Integration

Pré-requisitos

Tarefa 1: Implantar o Oracle Integration for Disaster Recovery

Tarefa 1.1: Preparar o Nó de Controle de DR para executar a automação personalizada

Opção 1: Oracle Integration como um aplicativo independente

Opção 2: Oracle Integration como parte de uma pilha de aplicativos

Opção 3: Oracle Integration como parte de uma pilha de aplicativos com várias ofertas PaaS

Tarefa 1.2: Garantir que o grupo de volumes seja replicado para a região 2

Tarefa 1.3: Fazer download de scripts bash para o Nó de Controle DR

Tarefa 1.4: Implantar o Oracle Integration for DR

Tarefa 1.5: Testar Manualmente a Recuperação do Oracle Integration

Tarefa 1.6: Próximas etapas

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

Tarefa 2.1: Criar políticas de IAM para o OCI Full Stack DR

Tarefa 2.2: Criar políticas do OCI IAM para outros serviços gerenciados pelo OCI Full Stack DR

Tarefa 2.3: Criar buckets do OCI Object Storage para logs DRPG

Tarefa 3: Criar Grupos de Proteção de DR em ambas as regiões

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

Tarefa 3.2: Criar um grupo de proteção na região 1

Tarefa 3.3: Criar um grupo de proteção na região 2

Tarefa 3.4: Associar grupos de proteção na região 1 e região 2

Tarefa 4: Adicionar membros ao Grupo de Proteção de DR

Tarefa 4.1: Começar a adicionar membros ao DRPG na região 1

Tarefa 5: Criar planos de DR básicos na região 2 (Phoenix)

Tarefa 5.1: Começar a criar planos de DR

Tarefa 6: Personalizar o plano de switchover na região 2 (Phoenix)

Tarefa 6.1: Selecionar o plano de switchover

Tarefa 6.2: Ativar Grupos de Planos de DR que encerram artefatos (opcional)

Tarefa 6.3: Criar grupo de planos para sincronizar parâmetros programados da região 1 para a região 2

Tarefa 6.4: Criar grupo de planos para ativar integrações relevantes no stand-by

Tarefa 6.5: Criar grupo de planos para iniciar integrações programadas na região 2

Tarefa 6.6: Criar grupo de planos para atualizar o registro de DNS na região 2

Tarefa 6.7: Criar grupo de planos para desativar integrações programadas na região 1

Tarefa 7: Personalizar o plano de failover na região 2 (Phoenix)

Tarefa 7.1: Selecionar o plano de failover

Tarefa 7.2: Selecionar adicionar grupo de planos

Tarefa 7.3: Criar grupo de planos para atualizar parâmetros programados na região 2

Tarefa 7.4: Criar grupo de planos para iniciar integrações programadas na região 2

Tarefa 7.5: Criar grupo de planos para atualizar o registro de DNS na região 2

Tarefa 8: Executar o plano de switchover na região 2 (Phoenix)

Tarefa 8.1: Iniciar execução do plano

Tarefa 8.2: Selecionar plano de switchover e executar

Tarefa 8.3: Próximas etapas

Tarefa 9: Criar planos de DR na região 1 (Ashburn)

Tarefa 9.1: Começar a criar planos de DR

Tarefa 9.2: Criar um plano de failover

Tarefa 10: Personalizar o plano de switchover na região 1 (Ashburn)

Tarefa 10.1: Selecionar o plano de switchover

Tarefa 10.2: Ativar Grupos de Planos de DR que encerram artefatos (opcional)

Tarefa 10.3: Criar vários planos definidos pelo usuário para o plano de Switchover

Tarefa 11: Personalizar o plano de failover na região 1 (Ashburn)

Tarefa 11.1: Selecionar o plano de switchover

Tarefa 11.2: Criar vários grupos de planos definidos pelo usuário na região 1 (stand-by)

Próximas Etapas

Testando planos de switchover

Testando planos de failover

Validar todos os planos de DR para aceitação final

Links Relacionados

Confirmação

Mais Recursos de Aprendizagem