Sobre a Configuração do JD Edwards Disaster Recovery Usando o OCI Full Stack Disaster Recovery

Arquitetura do JD Edwards

Esta ilustração descreve a arquitetura de implantação do aplicativo JD Edwards, com regiões principal e secundária.

Veja a seguir a descrição do jdr-dr-fsdr.png

Descrição da ilustração jdr-dr-fsdr.png de

Região Principal

Na região principal, o ambiente JDE é implantado em uma Rede Virtual na Nuvem (VCN) que é segmentada em três sub-redes dedicadas, que são segregadas pela funcionalidade de recursos do aplicativo, conforme descrito abaixo.

Camada do balanceador de carga
A camada do balanceador de carga hospeda o balanceador de carga do OCI, que fornece acesso aos serviços Web JDE para usuários finais.
Camada de aplicações
A camada de aplicativos contém os principais componentes do aplicativo, incluindo o servidor empresarial, o servidor Web e o servidor AIS (Application Interface Services)
Camada de gerenciamento
A camada de gerenciamento inclui ferramentas e serviços para gerenciamento e administração do JDE, como o servidor de implantação e o servidor da Console do Server Manager
Camada de banco de dados
Na camada do banco de dados, o banco de dados JDE é implantado no Autonomous Transaction Processing – Compartilhado (ATP-S). Os servidores de aplicativos se conectam ao banco de dados usando pontos finais. O Oracle Autonomous Data Guard está ativado, criando um banco de dados stand-by na região secundária e garantindo replicação de dados em tempo real para alta disponibilidade e recuperação de desastres.
Armazenamento e proteção de dados
Os grupos de volumes em blocos usados pelas instâncias de computação são protegidos pela replicação do grupo de volumes entre regiões, com a região secundária configurada como o destino da replicação.

Região Secundária

A região secundária serve como local de recuperação de desastres e espelha os componentes críticos do region.It principal que contém:

Uma estrutura de VCN replicada que corresponde ao layout de rede da região principal.
Um balanceador de carga de réplica para garantir a continuidade do acesso durante o failover.
Um banco de dados ATP-S stand-by que é mantido em sincronização com o principal usando o Autonomous Data Guard.
Réplicas de grupos de volumes, que garantem a disponibilidade de dados no caso de uma falha na região principal.

Compreender Arquivos Relacionados à Configuração do JD Edwards

O JDE conta com vários arquivos de configuração para gerenciar a conectividade entre seus componentes e outras camadas participantes, como bancos de dados e serviços de autenticação. Esses arquivos desempenham um papel crítico na definição de parâmetros de conexão, configurações de tempo de execução e comportamento de integração. Ter uma compreensão adequada desses arquivos e seu conteúdo é essencial ao configurar o cenário de DR (Recuperação de Desastres) para garantir a funcionalidade perfeita do aplicativo.

Veja a seguir um resumo dos principais arquivos de configuração:

sqlnet.ora

Finalidade: Armazena a configuração do Oracle Wallet usada pelo aplicativo para se conectar com segurança ao banco de dados.

Local: Servidores JDE Enterprise/Batch. DR

Consideração: Certifique-se de que o caminho da wallet aponte para a localização válida da wallet do banco de dados de DR.

Caminho do arquivo: Oracle_ClientHome/network/admin

tnsnames.ora

Finalidade: Armazena Nomes de Serviço de Rede, que atuam como aliases para endereços de rede de banco de dados.

Local: Servidores JDE Enterprise, Batch e Web.

Consideração de DR: Atualize com o endereço de rede correto (FQDN/IP) do banco de dados de DR.

Caminho do arquivo nos Servidores Enterprise/Batch: Oracle_ClientHome/network/admin

Caminho do arquivo em Servidores Web: SM_Agent_Home/SCFHA/Target/Managed Instance/config

jde.ini

Finalidade: Armazena a configuração de runtime do aplicativo JDE, incluindo detalhes de conexão do banco de dados e definições de segurança.

Local: Servidores JDE Enterprise e Batch.

Consideração de DR: Atualize a seção DB SYSTEM SETTINGS com o nome de servidor correto para o ambiente de DR.

Caminho do arquivo: JDE_HOME/e920/ini

jdbj.ini

Finalidade: Contém definições do driver JDBj e parâmetros de conexão do banco de dados para aplicativos JDE.

Local: Servidores JDE Web e AIS.

Consideração de DR: Certifique-se de que o nome do servidor correto seja especificado na seção JDBj-BOOTSTRAP DATA SOURCE.

Caminho do arquivo: SM_Agent_Home/SCFHA/Target/Managed Instance/config

jas.ini

Finalidade: Armazena a configuração para o componente Servidor HTML de clientes Web EnterpriseOne.

Local: Servidores Web JDE.

Consideração de DR: Atualize o seguinte:

Seção FORMSERVICE com o host e a porta AIS corretos.
Seção Security com o OracleAccessSSOSignOffURL apropriado se o SSO estiver ativado.

Caminho do arquivo: SM_Agent_Home/SCFHA/Target/Managed Instance/config

rest.ini

Finalidade: Contém a configuração do Servidor AIS, incluindo caminhos da API REST, definições de autenticação e links do servidor JAS.

Local: servidores JDE AIS.

Consideração de DR: Atualize o seguinte:

Seção BASIC CONFIG com o host e a porta JAS corretos.
Seção Security com o IDCSSSOSignOffURL atualizado se o SSO estiver ativado.

Caminho do arquivo: SM_Agent_Home/SCFHA/Target/Managed Instance/config

gerenciamento-console.xml

Finalidade: Este arquivo XML tem informações sobre os diferentes servidores, suas configurações e permissões de acesso do usuário.

Local: Servidor do Gerenciador de Servidores

Consideração de DR: Certifique-se de que o nome do host correto seja especificado no management-console.xml

Caminho do arquivo: SM_Console_Home/SCFMC/targets/home

agente. propriedades

Finalidade: Arquivo de configuração que tem definições para o Agente de Gerenciamento, um componente que interage com a Console de Gerenciamento e gerencia servidores EnterpriseOne

Local: Servidor do Gerenciador de Servidores

Consideração de DR: Certifique-se de que o nome correto do servidor seja especificado na seção agent.properties.

Caminho do arquivo: SM_Console_Home/ SCFMC/config

Atualizações adicionais no nível do sistema

Além dos arquivos de configuração do aplicativo, os seguintes arquivos de sistema também devem ser revisados e atualizados durante uma implementação de DR:

Hosts Linux e arquivos fstab: Garanta que endereços IP e FQDNs válidos estejam definidos.
Arquivo de hosts do Windows: Atualize com os mapeamentos de IP e FQDN atuais, conforme necessário.
Arquivos da wallet WebLogic: Deve ser atualizado para refletir a wallet do banco de dados específica do DR para garantir a conectividade se o banco de dados for Autônomo.

Manter e atualizar adequadamente esses arquivos de configuração garante que o JDE continue a funcionar corretamente em um ambiente de Recuperação de Desastres, minimizando o tempo de inatividade e mantendo uma conectividade de aplicativo segura e consistente.

Compreender os Conceitos do Full Stack Disaster Recovery

Ao configurar e implementar o FSDR, você precisará entender os seguintes conceitos e terminologias.

Grupo de Proteção do DR
- Definição: Um grupo de proteção de DR inclui todos os recursos necessários do OCI, como instâncias de computação, grupos de volumes, balanceadores de carga e bancos de dados que, juntos, formam uma pilha completa de aplicativos.
- Vantagem: Um grupo de proteção de DR é tratado como uma única unidade para failover, failback e em cenários de teste. Ele garante que todos os recursos sejam recuperados juntos, o que minimiza o tempo de inatividade e a perda de dados.
Plano de DR
Um plano de DR é um manual automatizado criado pelo FSDR para executar a recuperação de desastre de todos os recursos do grupo de proteção de DR principal. Ele consiste em etapas que definem como todos os recursos em uma região de grupo de proteção de DR principal são transferidos para sua região de grupo de proteção de DR secundária de pareamento. Estes são os vários tipos de planos de DR:
- Failover (não planejado): Use um plano de failover quando quiser executar uma transição imediata, trazendo a pilha de aplicativos na região stand-by, sem tentar fazer shutdown do serviço na região principal. Os planos de failover geralmente são usados para executar transições de DR quando uma interrupção ou um desastre afeta a região principal.
- Switchover (planejado): Use um plano de switchover quando quiser executar uma transição ordenada, fazendo shutdown da pilha de aplicativos na região principal e, em seguida, colocando-a na região stand-by. Os planos de switchover são normalmente usados para fins de manutenção de site planejada, aplicação de patches de software, teste de DR e validação.
- Iniciar drill: Um drill inicial gera um plano para executar o drill de DR sem interromper os recursos do grupo de proteção de DR principal. Ele cria uma réplica de recursos no grupo de proteção de DR stand-by.
- Interromper drill: Este plano de DR interrompe o drill de DR removendo a réplica de recursos criada pelo drill inicial.
Instância Móvel
- Definição: instâncias implantadas somente na região principal.
- Caso de Uso: Comum em topologias de DR frias, nas quais pouquíssimos ou nenhum dos componentes de um aplicativo ou serviço precisa ser pré-implantado na região standby, em preparação para uma futura transição da DR.
- Comportamento: Durante um evento de desastre, a movimentação de instâncias é movida do grupo de proteção de DR da região principal para o grupo de proteção de DR da região stand-by.
- Vantagem: Eficiência de custo, pois os recursos na região stand-by não estão em execução continuamente.
- Consideração: Este método requer tempos de recuperação mais longos devido à necessidade de provisionar e iniciar instâncias na região stand-by.
Instância Não Móvel
- Definição: Instâncias pré-implantadas nas regiões principal e stand-by.
- Caso de Uso: Comum nas topologias de DR ativo-passivo, em que alguns ou todos os componentes de um aplicativo ou serviço são pré-implantados na região stand-by, a fim de se preparar para uma transição futura de DR.
- Comportamento: Durante as operações de DR, essas instâncias são iniciadas ou interrompidas conforme necessário para fazer a transição do serviço entre regiões.
- Vantagem: Este método fornece recuperação mais rápida devido à infraestrutura pré-existente na região stand-by.
- Consideração: Isso pode resultar em custo mais alto porque a infraestrutura precisa ser mantida em ambas as regiões.

Pré-requisitos do Full Stack Disaster Recovery

Antes de prosseguir com o processo FSDR, você precisa concluir os seguintes pré-requisitos:

Provisione uma VCN, sub-redes, tabelas de roteamento, listas de segurança e gateways de rede na região de DR. Para oferecer suporte à funcionalidade e conectividade de failover, verifique se as configurações de rede espelham as da região principal.
Defina um grupo dinâmico para permitir políticas que concedam privilégios de administrador a instâncias criadas como parte do ambiente de DR.
Você precisa de direitos de administrador para executar scripts em instâncias de computação. O plug-in Executar Comando usa o usuário ocarun para executar esses scripts. Certifique-se de que esse usuário tenha as permissões adequadas.
1. Abra o oracle-cloud-agent-run-command para edição:
```
 vi ./101-oracle-cloud-agent-run-command
```
2. Adicione as seguintes linhas no arquivo de configuração:
```
ocarun ALL=(ALL) 
NOPASSWD:ALL
```
3. Depois, execute:
```
vi sudo -cf ./101-oracle-cloud-agent-run-command
```
4. Adicione o arquivo de configuração ao /etc/sudoers.d:
```
sudo cp ./101-oracle-cloud-agent-run-command /etc/sudoers.d/
```
Ative a funcionalidade de backup entre regiões para grupos de volumes.
Implante um balanceador de carga na região secundária. Como parte da configuração do FSDR, somente o conjunto de backend (instâncias) será movido do principal para a região stand-by; o próprio balanceador de carga deverá ser criado manualmente na região stand-by com antecedência.
Configure uma instância de banco de dados correspondente (par) na região de DR para suportar failover de aplicativo.
Crie um bucket de armazenamento de objetos para logs na região principal. Este bucket armazenará logs e artefatos de DR específicos do ambiente.
Crie um bucket de armazenamento de objetos adicional na região stand-by. Esse bucket será usado para fins de replicação ou log para garantir a prontidão do DR na região stand-by.
Coloque os seguintes scripts personalizados no local adequado.

Aplicar Scripts Personalizados

Esses scripts personalizados são executados durante o processo FSDR.

update_rest

Servidor aplicável: AIS

#Define the old and new file names
old_file1="rest_dr.ini"
new_file1="rest.ini"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"
 # Copy the new second file back to the original name, preserving attributes
 cp -p "$new_file1" "$old_file1"
 echo "Copied $new_file1 back to $old_file1 (preserving attributes)"

else
 echo "One or both of the old files do not exist in the folder."
fi

update_tnsnames_jdbj

Servidores aplicáveis: JAS, AIS

#Define the old and new file names
old_file1="tnsnames_dr.ora"
old_file2="jdbj_dr.ini"
old_file3="jas_dr.ini"
new_file1="tnsnames.ora"
new_file2="jdbj.ini"
new_file3="jas.ini"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"

 # Rename the second file
 mv "$old_file2" "$new_file2"
 echo "Renamed $old_file2 to $new_file2"

 # Rename the third file
 mv "$old_file3" "$new_file3"
 echo "Renamed $old_file3 to $new_file3"

else
 echo "One or both of the old files do not exist in the folder."
fi

update_wallet

Servidores aplicáveis: Todos os Servidores JDE (Enterprise, AIS, JAS, Fatclient, Integrações etc.)

# Define old and new wallet folder names
old_wallet="Wallet_jdeorcl_hyderabad"
new_wallet="Wallet_jdeorcl"

# Check if the old wallet directory exists
if [ -d "$old_wallet" ]; then
  # Remove any existing new_wallet directory to avoid conflict
  if [ -d "$new_wallet" ]; then
    echo "Removing existing $new_wallet directory..."
    rm -rf "$new_wallet"
  fi

  # Rename the old wallet to the new name
  mv "$old_wallet" "$new_wallet"
  echo "Renamed $old_wallet to $new_wallet"

  # Copy the new wallet back to the old wallet directory for reuse
  cp -r "$new_wallet" "$old_wallet"
  echo "Copied $new_wallet back to $old_wallet for reuse"

else
  echo "Directory $old_wallet does not exist. Aborting operation."
fi

update_ini

Servidor aplicável: Enterprise

# Define the old and new file names
old_file2="JDE_DR.INI"
old_file3="jdbj_dr.ini"
new_file2="JDE.INI"
new_file3="jdbj.ini"

# Check if the old files exist in the folder
if [ -e "$old_file2" ] && [ -e "$old_file3" ] ; then
    # Rename the second file
    mv "$old_file2" "$new_file2"
    echo "Renamed $old_file2 to $new_file2"

    # Rename the third file
    mv "$old_file3" "$new_file3"
    echo "Renamed $old_file3 to $new_file3"
else
    echo "Old files do not exist in the folder."
fi

update_tnsnames_sqlnet

Servidores aplicáveis: Enterprise, Deployment, Fatclients

#Define the old and new file names
old_file1="tnsnames_dr.ora"
old_file2="sqlnet_dr.ora"
new_file1="tnsnames.ora"
new_file2="sqlnet.ora"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"

 # Rename the second file
 mv "$old_file2" "$new_file2"
 echo "Renamed $old_file2 to $new_file2"
else
 echo "One or both of the old files do not exist in the folder."
fi

update_agent_properties

Servidores aplicáveis: Todos os servidores gerenciados pelo Gerenciador de Servidores

# Define the old and new file names
old_file1="agent.properties"
new_file1="agent_dr.properties"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
# Rename the first file
mv "$old_file1" "$new_file1"
echo "Renamed $old_file1 to $new_file1"
else
echo "One or both of the old files do not exist in the folder."
fi

update_management_console

Servidor aplicável: Gerenciador de servidor

# Define the old and new file names
old_file1="management-console_dr.xml"
new_file1="management-console.xml"

# Check if the old files exist in the folder
if [ -e "$old_file1" ]; then
# Rename the first file
mv "$old_file1" "$new_file1"
echo "Renamed $old_file1 to $new_file1"
else
echo "One or both of the old files do not exist in the folder."
fi