Configure a recuperação de desastres para o Oracle JD Edwards EnterpriseOne com o AWS Elastic Disaster Recovery - Recomendações da AWS
ResumoPré-requisitos e limitaçõesArquiteturaFerramentasPráticas recomendadasÉpicosSolução de problemasRecursos relacionados

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Configure a recuperação de desastres para o Oracle JD Edwards EnterpriseOne com o AWS Elastic Disaster Recovery

Criado por Thanigaivel Thirumalai () AWS

Ambiente: produção

Tecnologias: infraestrutura; migração; rede

Workload: Oracle

AWSserviços: AWS Elastic Disaster Recovery; Amazon EC2

Resumo

Desastres desencadeados por catástrofes naturais, falhas de aplicativos ou interrupção de serviços prejudicam a receita e causam tempo de inatividade para aplicativos corporativos. Para reduzir as repercussões de tais eventos, o planejamento da recuperação de desastres (DR) é fundamental para empresas que adotam os sistemas de planejamento de recursos EnterpriseOne corporativos (ERP) da JD Edwards e outros softwares de missão crítica e de negócios. 

Esse padrão explica como as empresas podem usar o AWS Elastic Disaster Recovery como uma opção de DR para seus aplicativos JD Edwards EnterpriseOne . Também descreve as etapas para usar o failover e o failback do Elastic Disaster Recovery para criar uma estratégia de DR entre regiões para bancos de dados hospedados em uma instância do Amazon Elastic Compute Cloud (EC2Amazon) na nuvem. AWS

Observação: esse padrão exige que as regiões primária e secundária nas quais a implementação de DR entre regiões seja hospedada. AWS

O Oracle JD Edwards EnterpriseOne é uma solução de ERP software integrada para empresas de médio a grande porte em uma ampla variedade de setores.

AWSO Elastic Disaster Recovery minimiza o tempo de inatividade e a perda de dados com a recuperação rápida e confiável de aplicativos locais e baseados na nuvem, usando armazenamento acessível, computação e recuperação mínimas. point-in-time

AWSfornece quatro padrões principais de arquitetura de DR. Este documento se concentra na instalação, configuração e otimização usando a estratégia de piloto leve. Essa estratégia ajuda você a criar um ambiente de DR de baixo custo em que provisiona inicialmente um servidor de replicação para replicar dados do banco de dados de origem e provisiona o servidor de banco de dados real somente quando inicia uma simulação e uma recuperação de DR. Essa estratégia elimina as despesas de manutenção de um servidor de banco de dados na região de DR. Em vez disso, você paga por uma EC2 instância menor que serve como servidor de replicação.

Pré-requisitos e limitações

Pré-requisitos

  • Uma conta da AWS ativa.

  • Um EnterpriseOne aplicativo JD Edwards executado no Oracle Database ou no Microsoft SQL Server com um banco de dados compatível em um estado de execução em uma instância gerenciadaEC2. Esse aplicativo deve incluir todos os componentes EnterpriseOne básicos do JD Edwards (Enterprise Server, HTML Server e Database Server) instalados em uma AWS região.

  • Uma função de AWS Identity and Access Management (IAM) para configurar o serviço Elastic Disaster Recovery.

  • A rede para executar o Elastic Disaster Recovery configurada de acordo com as configurações de conectividade necessárias.

Limitações

  • Você pode usar esse padrão para replicar todos os níveis, a menos que o banco de dados esteja hospedado no Amazon Relational Database Service (AmazonRDS). Nesse caso, recomendamos que você use a funcionalidade de cópia entre regiões da Amazon. RDS

  • O Elastic Disaster Recovery não é compatível com o CloudEndure Disaster Recovery, mas você pode fazer o upgrade do CloudEndure Disaster Recovery. Para obter mais informações, consulte a documentação do FAQElastic Disaster Recovery.

  • O Amazon Elastic Block Store (AmazonEBS) limita a taxa na qual você pode tirar snapshots. Você pode replicar um número máximo de 300 servidores em uma única AWS conta usando o Elastic Disaster Recovery. Para replicar mais servidores, você pode usar várias AWS contas ou várias AWS regiões de destino. (Você precisará configurar o Elastic Disaster Recovery separadamente para cada conta e região.) Para obter mais informações, consulte Práticas recomendadas na documentação do Elastic Disaster Recovery.

  • As cargas de trabalho de origem (o EnterpriseOne aplicativo e o banco de dados do JD Edwards) devem ser hospedadas nas instâncias. EC2 Esse padrão não é compatível com workloads on-premises ou em outros ambientes de nuvem.

  • Esse padrão se concentra nos componentes do JD Edwards EnterpriseOne . Um plano completo de DR e continuidade de negócios (BCP) deve incluir outros serviços essenciais, incluindo:

    • Rede (nuvem privada virtual, sub-redes e grupos de segurança)

    • Active Directory

    • Amazon WorkSpaces

    • Elastic Load Balancing

    • Um serviço de banco de dados gerenciado, como o Amazon Relational Database Service (AmazonRDS)

Para obter informações adicionais sobre pré-requisitos, configurações e limitações, consulte a documentação do Elastic Disaster Recovery.

Versões do produto

  • Oracle JD Edwards EnterpriseOne (versões compatíveis com Oracle e SQL Server com base nos requisitos técnicos mínimos da Oracle)

Arquitetura

Pilha de tecnologias de destino

  • Uma única região e uma única nuvem privada virtual (VPC) para produção e não produção, e uma segunda região para DR

  • Zonas de disponibilidade únicas para garantir baixa latência entre servidores

  • Um Application Load Balancer que distribui o tráfego de rede para melhorar a escalabilidade e a disponibilidade de seus aplicativos em várias zonas de disponibilidade

  • Amazon Route 53 fornecerá a configuração do Sistema de Nomes de Domínio (DNS)

  • Amazon fornecerá WorkSpaces aos usuários uma experiência de desktop na nuvem

  • Use o Amazon Simple Storage Service (Amazon S3) para armazenar backups, arquivos e objetos

  • Amazon CloudWatch para registro, monitoramento e alarmes de aplicativos

  • Amazon Elastic Disaster Recovery para recuperação de desastres

Arquitetura de destino

O diagrama a seguir mostra a arquitetura de recuperação de desastres entre regiões para a JD Edwards EnterpriseOne usando o Elastic Disaster Recovery.

Arquitetura para DR EnterpriseOne entre regiões do JD Edwards em AWS

Procedimento

Aqui está uma análise de alto nível do processo. Consulte a seção Épicos  para obter detalhes.

  • A replicação do Elastic Disaster Recovery começa com uma sincronização inicial. Durante a sincronização inicial, o Agente de AWS Replicação replica todos os dados dos discos de origem para o recurso apropriado na sub-rede da área de armazenamento.

  • A replicação contínua continua indefinidamente após a conclusão da sincronização inicial.

  • Você revisa os parâmetros de lançamento, que incluem configurações específicas do serviço e um modelo de EC2 lançamento da Amazon, após a instalação do agente e o início da replicação. Quando o servidor de origem é indicado como pronto para recuperação, você pode iniciar as instâncias.

  • Quando o Elastic Disaster Recovery emite uma série de API chamadas para iniciar a operação de lançamento, a instância de recuperação é iniciada imediatamente de AWS acordo com suas configurações de execução. O serviço ativa automaticamente um servidor de conversão durante a inicialização.

  • A nova instância é ativada AWS após a conclusão da conversão e está pronta para uso. O estado do servidor de origem no momento da execução é representado pelos volumes associados à instância executada. O processo de conversão envolve alterações nos drivers, na rede e na licença do sistema operacional para garantir que a instância seja inicializada de forma nativa. AWS

  • Após o lançamento, os volumes recém-criados não são mais mantidos em sincronia com os servidores de origem. O Agente AWS de Replicação continua replicando rotineiramente as alterações feitas em seus servidores de origem nos volumes da área de armazenamento, mas as instâncias iniciadas não refletem essas alterações.

  • Quando você inicia uma nova instância de simulação ou recuperação, os dados são sempre refletidos no estado mais recente que foi replicado do servidor de origem para a sub-rede da área de simulação.

  • Quando o servidor de origem é marcado como sendo preparado para recuperação, você pode iniciar instâncias.

Observação: o processo funciona nos dois sentidos: para failover de uma AWS região primária para uma região de DR e para retornar ao site primário, quando ele for recuperado. Você pode se preparar para o failback revertendo a direção da replicação de dados da máquina de destino para a máquina de origem de uma forma totalmente orquestrada.

Os benefícios desse processo descritos nesse padrão incluem:

  • Flexibilidade: os servidores de replicação aumentam e reduzem de escala horizontalmente, com base no conjunto de dados e no tempo de replicação, para que você possa realizar testes de DR sem interromper os workload de origem ou a replicação.

  • Confiabilidade: a replicação é robusta, sem interrupções e contínua.

  • Automação: essa solução fornece um processo unificado e automatizado para teste, recuperação e failback.

  • Otimização de custos: você pode replicar somente os volumes necessários e pagar por eles, e pagar pelos recursos computacionais no local de DR somente quando esses recursos forem ativados. Você pode usar uma instância de replicação com custo otimizado (recomendamos usar um tipo de instância otimizado para computação) para várias fontes ou uma única fonte com um grande volume. EBS

Automação e escala

Quando você executa a recuperação de desastres em grande escala, os EnterpriseOne servidores JD Edwards terão dependências de outros servidores no ambiente. Por exemplo:

  • Os servidores de EnterpriseOne aplicativos JD Edwards que se conectam a um banco de dados EnterpriseOne compatível com o JD Edwards na inicialização têm dependências desse banco de dados.

  • EnterpriseOne Os servidores JD Edwards que exigem autenticação e precisam se conectar a um controlador de domínio na inicialização para iniciar os serviços têm dependências do controlador de domínio.

Por esse motivo, recomendamos que você automatize as tarefas de failover. Por exemplo, você pode usar o AWS Lambda ou o AWS Step Functions para automatizar os scripts de EnterpriseOne inicialização do JD Edwards e as alterações do balanceador de carga para automatizar o processo de failover. end-to-end Para obter mais informações, consulte a postagem do blog Criação de um plano de recuperação de desastres escalável com o AWS Elastic Disaster Recovery.

Ferramentas

AWSserviços

Práticas recomendadas

Práticas recomendadas gerais

  • Tenha um plano escrito sobre o que fazer no caso de um evento real de recuperação.

  • Depois de configurar o Elastic Disaster Recovery corretamente, crie um AWS CloudFormation modelo que possa criar a configuração sob demanda, caso seja necessário. Determine a ordem na qual os servidores e aplicativos devem ser iniciados e registre isso no plano de recuperação.

  • Faça um exercício regular (aplicam-se EC2 as tarifas padrão da Amazon).

  • Monitore a integridade da replicação contínua usando o console do Elastic Disaster Recovery ou programaticamente.

  • Proteja os point-in-time instantâneos e confirme antes de encerrar as instâncias.

  • Crie uma IAM função para a instalação do AWS Replication Agent.

  • Habilite a proteção contra encerramento para instâncias de recuperação em um cenário real de DR.

  • Não use a AWS ação Disconnect from no console do Elastic Disaster Recovery para servidores para os quais você iniciou instâncias de recuperação, mesmo no caso de um evento real de recuperação. Executar uma desconexão encerra todos os recursos de replicação relacionados a esses servidores de origem, incluindo seus point-in-time (PIT) pontos de recuperação.

  • Altere a PIT política para alterar o número de dias para retenção de instantâneos.

  • Edite o modelo de lançamento nas configurações de execução do Elastic Disaster Recovery para definir a sub-rede, o grupo de segurança e o tipo de instância corretos para seu servidor de destino.

  • Automatize o processo de end-to-end failover usando o Lambda ou o Step Functions para automatizar os scripts de inicialização e as alterações do balanceador de carga do JD Edwards EnterpriseOne .

EnterpriseOne Otimização e considerações do JD Edwards

  • Vá PrintQueuepara o banco de dados.

  • Vá MediaObjectspara o banco de dados.

  • Exclua os registros em log e a pasta temporária dos servidores lógicos e de lote.

  • Exclua a pasta temporária do Oracle WebLogic.

  • Crie scripts para inicialização após o failover.

  • Exclua o tempdb do Server. SQL

  • Exclua o arquivo temporário do Oracle.

Épicos

TarefaDescriçãoHabilidades necessárias

Configure a rede de replicação.

Implemente seu EnterpriseOne sistema JD Edwards na AWS região principal e identifique a AWS região para DR. Siga as etapas na seção Requisitos de rede de replicação da documentação do Elastic Disaster Recovery para planejar e configurar sua rede de replicação e DR.

AWSadministrador

Determine RPO RTO e.

Identifique o objetivo de tempo de recuperação (RTO) e o objetivo do ponto de recuperação (RPO) para seus servidores de aplicativos e banco de dados.

Arquiteto de nuvem, arquiteto de DR

Habilite a replicação para a AmazonEFS.

Se aplicável, habilite a replicação da região AWS primária para a região de DR para sistemas de arquivos compartilhados, como o Amazon Elastic File System (AmazonEFS) AWS DataSync, usando rsync ou outra ferramenta apropriada.

Administrador de nuvem

Gerencie DNS em caso de DR.

Identifique o processo para atualizar o Sistema de Nomes de Domínio (DNS) durante o treinamento de DR ou o DR. real

Administrador de nuvem

Crie uma IAM função para configuração.

Siga as instruções na seção de inicialização e permissões do Elastic Disaster Recovery da documentação do Elastic Disaster Recovery para criar uma IAM função para inicializar e gerenciar o AWS serviço.

Administrador de nuvem

Configure o VPC peering.

Certifique-se de que a origem e o destino VPCs estejam emparelhados e acessíveis um ao outro. Para obter instruções de configuração, consulte a VPCdocumentação da Amazon.

AWSadministrador
TarefaDescriçãoHabilidades necessárias

Inicializar o Elastic Disaster Recovery.

Abra o console do Elastic Disaster Recovery, escolha a AWS região de destino (onde você replicará dados e iniciará instâncias de recuperação) e, em seguida, escolha Definir configurações de replicação padrão.

AWSadministrador

Configure os servidores de replicação.

  1. No painel Set up replication servers (Configurar servidores de replicação), insira a sub-rede da área de armazenamento e o tipo de instância do servidor de replicação. O tipo de instância t3.small é selecionado por padrão. Defina essa configuração com base em seus requisitos e lembre-se de considerar os preços das instâncias. Para obter mais informações, consulte os EC2preços da Amazon.

  2. Na seção Acesso ao serviço, selecione Exibir detalhes para revisar o perfil vinculado ao serviço e as políticas adicionais criadas durante a inicialização do serviço.

  3. Escolha Próximo.

AWSadministrador

Configure volumes e grupos de segurança.

  1. No painel Volumes e grupos de segurança, selecione o tipo de EBS volume para o servidor de replicação e defina a EBS criptografia da Amazon como Padrão.

  2. Selecione Sempre usar o grupo de segurança AWS Elastic Disaster Recovery para que o Elastic Disaster Recovery anexe e monitore automaticamente o grupo de segurança padrão.

  3. Escolha Próximo.

AWSadministrador

Defina configurações adicionais.

  1. No painel Configurações adicionais, configure o roteamento e a limitação de dados, a PIT política e as tags.

    • O roteamento e o controle de utilização de dados controlam como os dados fluem do servidor externo para os servidores de replicação. Selecione Use private IP for data replication (Usar IP privado para replicação de dados). Caso contrário, os servidores de replicação receberão automaticamente um IP público e os dados fluirão pela Internet pública.

    • Na seção Política Point in time (PIT), configure uma política de retenção que determine a duração após a qual os instantâneos não são necessários. O período de retenção padrão é de sete dias.

    • Na seção Tags, adicione tags personalizadas aos recursos criados pelo Elastic Disaster Recovery em sua AWS conta.

  2. Selecione Next (Próximo), analise as configurações no próximo painel e selecione Create default (Criar padrão) para criar o modelo padrão.

AWSadministrador
TarefaDescriçãoHabilidades necessárias

Crie uma IAM função.

Crie uma IAM função que contenha a AWSElasticDisasterRecoveryAgentInstallationPolicy política. Na seção Selecionar tipo de AWS acesso, ative o acesso programático. Anote o ID de chave de acesso e a chave de acesso secreta. Você precisará dessas informações durante a instalação do Agente de AWS Replicação.

AWSadministrador

Verifique os requisitos.

Verifique e preencha os pré-requisitos na documentação do Elastic Disaster Recovery para instalar o AWS Replication Agent.

AWSadministrador

Instale o Agente de AWS Replicação.

Siga as instruções de instalação do seu sistema operacional e instale o Agente de AWS Replicação.

  • Para Microsoft Windows: baixe os arquivos de instalação e execute o arquivo .exe como administrador.  Responda às solicitações para concluir a instalação.

  • Para Linux: copie os comandos a seguir (na ordem apresentada) e cole-os na sessão do Secure Shell (SSH). O primeiro comando baixa o instalador e o segundo comando o executa.

    wget -O ./aws-replication-installer-init.py https://aws-elastic-disaster-recovery-us-west-2.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py

    Observação: altere o URL para refletir sua região.

    sudo python3 aws-replication-installer-init.py

    Responda às solicitações para concluir a instalação.

Repita essas etapas para o servidor restante.

AWSadministrador

Monitore a replicação.

Retorne ao painel Source servers (Servidores de origem) do Elastic Disaster Recovery para monitorar o status da replicação. A sincronização inicial levará algum tempo, dependendo do tamanho da transferência de dados.

Quando o servidor de origem estiver totalmente sincronizado, o status do servidor será atualizado para Ready (Pronto). Isso significa que um servidor de replicação foi criado na área de armazenamento e os EBS volumes foram replicados do servidor de origem para a área de armazenamento.

AWSadministrador
TarefaDescriçãoHabilidades necessárias

Edite as configurações de lançamento.

Para atualizar as configurações de inicialização das instâncias de simulação e recuperação, no console do Elastic Disaster Recovery, selecione o servidor de origem e, em seguida, selecione Actions (Ações), Edit launch settings (Editar configurações de lançamento). Ou você pode escolher suas máquinas de origem de replicação na página Source servers (Servidores de origem) e, em seguida, escolher a guia Launch Settings (Configurações de inicialização). Essa guia tem duas seções: Configurações gerais de lançamento e modelo de EC2 lançamento.

AWSadministrador

Defina as configurações gerais de lançamento.

Revise as configurações gerais de inicialização de acordo com seus requisitos.

  • Dimensionamento correto do tipo de instância: se você escolher Básico, o Elastic Disaster Recovery ignora o tipo de instância selecionado no modelo de EC2 lançamento da Amazon e escolhe automaticamente o tipo de instância com base no sistema operacional e no servidor RAM de origem. CPU

  • Copiar IP privado: selecione se você deseja que o Elastic Disaster Recovery garanta que o IP privado usado pela simulação ou pela instância de recuperação corresponda ao IP privado usado pelo servidor de origem. Se você escolher Sim, certifique-se de que o intervalo de IP da sub-rede que você definiu no modelo de EC2 lançamento da Amazon inclua o endereço IP privado.

Para obter mais informações, consulte Configurações gerais de lançamento na documentação do Elastic Disaster Recovery.

AWSadministrador

Configure o modelo de EC2 lançamento da Amazon.

O Elastic Disaster Recovery usa modelos de EC2 lançamento da Amazon para iniciar instâncias de detalhamento e recuperação para cada servidor de origem. O modelo de lançamento é criado automaticamente para cada servidor de origem que você adiciona ao Elastic Disaster Recovery depois de instalar o Agente de AWS Replicação.

Você deve definir o modelo de EC2 lançamento da Amazon como o modelo de lançamento padrão se quiser usá-lo com o Elastic Disaster Recovery.

Para obter mais informações, consulte EC2Launch Template na documentação do Elastic Disaster Recovery.

AWSadministrador
TarefaDescriçãoHabilidades necessárias

Iniciar simulação

  1. No console do Elastic Disaster Recovery, abra a página Source servers (Servidores de origem) e verifique se o status do servidor de origem está como Ready (Pronto).

  2. Selecione todos os servidores de origem para os quais você deseja realizar a simulação de DR.

  3. No menu Iniciar tarefa de recuperação, escolha Iniciar simulação e selecione o instantâneo apropriado point-in-time. Isso inicia um trabalho de recuperação para os servidores de origem selecionados. Você pode monitorar o status do trabalho na guia Recovery job history (Histórico do trabalho de recuperação).

    Observação: outras alterações no servidor de origem serão sincronizadas com o servidor de replicação, não com a instância de simulação.

    A instância de simulação lançada também aparece na página Recovery instances (Instâncias de recuperação).

  4. Teste e verifique a instância de simulação de DR.

  5. Na página Instâncias de recuperação, selecione a instância de detalhamento e, em seguida, escolha Ações, Desconectar de AWS. Isso exclui o Agente de AWS Replicação da instância de recuperação e remove todos os recursos associados à instância de recuperação do Elastic Disaster Recovery.

  6. Selecione Delete recovery instances (Excluir instâncias de recuperação). Isso exclui a representação da instância do console do Elastic Disaster Recovery e dissocia completamente a instância do serviço Elastic Disaster Recovery. Ela não exclui a EC2 instância subjacente.

  7. Encerre a instância do DR Drill a partir do EC2 console da Amazon.

Para obter mais informações, consulte Preparação para um failover na documentação do Elastic Disaster Recovery.

AWSadministrador

Validar a simulação.

Na etapa anterior, você lançou novas instâncias de destino na região de DR. As instâncias de destino são réplicas dos servidores de origem com base no instantâneo obtido quando você iniciou o lançamento.

Neste procedimento, você se conecta às máquinas de EC2 destino da Amazon para confirmar se elas estão funcionando conforme o esperado.

  1. Abra o EC2console da Amazon.

  2. Selecione Instâncias (execução).

  3. Selecione a instância de destino e anote seu IPv4 endereço privado.

  4. Certifique-se de que você possa se conectar à EC2 instância e de que o JD Edwards EnterpriseOne e os componentes relacionados sejam replicados conforme o esperado.

Iniciar um failover.

Um failover é o redirecionamento do tráfego de um sistema primário para um sistema secundário. O Elastic Disaster Recovery ajuda você a realizar um failover iniciando instâncias de recuperação emAWS. Quando as instâncias de recuperação são iniciadas, você redireciona o tráfego dos seus sistemas primários para essas instâncias.

  1. No console do Elastic Disaster Recovery, abra a página Source servers (Servidores de origem) e verifique se a coluna Ready for recovery (Pronto para recuperação) do servidor de origem mostra Ready (Pronto), e a coluna Data replication status (Status de replicação de dados) mostra Healthy (Saudável).

  2. Selecione o servidor de origem. No menu Initiate recovery job (Iniciar tarefa de recuperação), selecione Initiate recovery (Iniciar recuperação).

  3. Selecione o point-in-time snapshot a partir do qual iniciar a instância de recuperação e, em seguida, escolha Iniciar recuperação.

    Isso inicia um trabalho de recuperação. Você pode monitorar o status do trabalho na página Recovery instances (Instâncias de recuperação).

  4. Teste e verifique a instância de recuperação. Se necessário, ajuste a DNS configuração e conecte seu EnterpriseOne aplicativo JD Edwards ao banco de dados.

  5. Agora você pode desconectar e descomissionar o EnterpriseOne servidor JD Edwards de origem, porque todas as alterações foram gravadas na nova instância de recuperação.

  6. Registre a instância de recuperação como servidor de origem na região de DR seguindo o processo descrito no épico Install the AWS Replication Agent.

Para obter mais informações, consulte Execução de um failover na documentação do Elastic Disaster Recovery.

AWSadministrador

Inicie um failback.

O processo para iniciar um failback é semelhante ao processo para iniciar o failover.

  1. Abra o console do Elastic Disaster Recovery na região primária. Navegue até a página Instâncias de recuperação, selecione a instância de detalhamento e, em seguida, escolha Ações, Desconectar de AWS, Excluir instâncias de recuperação.

  2. Abra o console do Elastic Disaster Recovery na região de DR. Registre seu novo servidor JD Edwards como EnterpriseOne servidor de origem na região de DR instalando o Agente de AWS Replicação. Os dados serão sincronizados com um novo servidor de replicação provisionado na nova sub-rede de teste.

    Observação: quando o novo EnterpriseOne servidor JD Edwards é registrado como servidor de origem, você pode ver dois servidores de origem no console do Elastic Disaster Recovery: um servidor criado a partir da EC2 instância primária e o novo servidor criado a partir da instância de recuperação. Recomendamos que você marque os servidores corretamente para evitar confusão e, de preferência, adicione o novo servidor ao modelo de execução.

  3. Para reiniciar a replicação de DR da região primária, desassocie a instância de recuperação iniciada do console do Elastic Disaster Recovery na região de DR e registre o host como servidor de origem na região primária.

Para obter mais informações, consulte Execução de um failback na documentação do Elastic Disaster Recovery.

AWSadministrador

Inicie os componentes do JD Edwards. EnterpriseOne

  1. Inicie o EnterpriseOne banco de dados do JD Edwards fazendo login no servidor do banco de dados.

  2. Quando o banco de dados estiver em execução, inicie a EnterpriseOne lógica e os servidores em lote do JD Edwards.

  3. Comece WebLogic nos servidores web e inicie uma JAS instância nos JAS servidores.

  4. Comece WebLogic no servidor de provisão e no servidor do console SM.

  5. Inicie o SM Agent nos servidores.

  6. Confirme se o login no JD Edwards EnterpriseOne funciona corretamente.

Você precisará incorporar as alterações no Route 53 e no Application Load Balancer para que o link do JD Edwards funcione EnterpriseOne .

Você pode automatizar essas etapas usando Lambda, Step Functions e Systems Manager (Run Command).

Observação: o Elastic Disaster Recovery executa a replicação em nível de bloco dos EBS volumes da EC2 instância de origem que hospedam o sistema operacional e os sistemas de arquivos. Os sistemas de arquivos compartilhados que foram criados usando a Amazon EFS não fazem parte dessa replicação. Você pode replicar sistemas de arquivos compartilhados para a região de DR usando AWS DataSync, conforme observado no primeiro épico, e depois montar esses sistemas de arquivos replicados no sistema de DR.

J. D. Edwards EnterpriseOne CNC

Solução de problemas

ProblemaSolução

O status de replicação de dados do servidor de origem está Paralisado e a replicação está atrasada. Se você verificar os detalhes, o status da replicação de dados exibirá Agent not seen (Agente indisponível).

Verifique se o servidor de origem paralisado está em execução.

Observação: se o servidor de origem ficar inativo, o servidor de replicação será encerrado automaticamente.

Para obter mais informações sobre problemas de atraso, consulte Problemas de atraso de replicação na documentação do Elastic Disaster Recovery.

A instalação do Agente de AWS Replicação na EC2 instância de origem falha na versão RHEL 8.2 após a digitalização dos discos. aws_replication_agent_installer.logrevela que faltam cabeçalhos do kernel.

Antes de instalar o Agente AWS de Replicação no RHEL 8, CentOS 8 ou Oracle Linux 8, execute:

sudo yum install elfutils-libelf-devel

Para obter mais informações, consulte os requisitos de instalação do Linux na documentação do Elastic Disaster Recovery.

No console do Elastic Disaster Recovery, você vê o servidor de origem como Ready (Pronto), com um atraso e o status de replicação de dados como Stalled (Parado).

Dependendo de quanto tempo o Agente de AWS Replicação estiver indisponível, o status pode indicar um alto atraso, mas o problema permanece o mesmo.

Use um comando do sistema operacional para confirmar se o Agente de AWS Replicação está sendo executado na EC2 instância de origem ou confirme se a instância está em execução.

Depois de corrigir qualquer problema, o Elastic Disaster Recovery reiniciará o escaneamento. Espere até que todos os dados tenham sido sincronizados e o status da replicação seja Healthy (Saudável) antes de iniciar um simulação de recuperação de desastres.

Replicação inicial com alto atraso. No console do Elastic Disaster Recovery, você pode ver que o status de sincronização inicial é extremamente lento para um servidor de origem.

Verifique os problemas de atraso de replicação documentados na seção Replication lag issues (Problemas de atraso de replicação) na documentação do Elastic Disaster Recovery.

O servidor de replicação pode não conseguir lidar com a carga devido às operações computacionais intrínsecas. Nesse caso, tente atualizar o tipo de instância depois de consultar a equipe de Suporte AWS Técnico.

Recursos relacionados