1. Configure o Oracle Fusion Middleware DR no Oracle Cloud com um banco de dados autônomo
  2. Configurar a Topologia de DR

Configurar a Topologia de DR

Configure a topologia de recuperação de desastres (DR). Os scripts estão disponíveis para agilizar o processo.

Fazer Download dos Scripts

Obtenha os scripts de configuração mais recentes no repositório GitHub.

Observação:

Coloque todos os scripts baixados na mesma pasta.
  1. Vá para o repositório GitHub.
  2. Faça download de todos os scripts no diretório maa/fmw-wls-with-adb-dr.
  3. Faça download de todos os scripts no diretório maa/app_dr_common.
    Esses scripts fazem chamadas entre si. Apesar da operação específica ser executada em um momento específico, faça download de todos os diretórios e coloque todos os scripts na mesma pasta. Você precisará dos scripts nos sites principal e secundário.
  4. Siga as instruções deste documento e leia as variáveis necessárias em cada script para cada operação realizada.

O arquivo baixado inclui scripts para executar as seguintes tarefas:

  1. Configurar um Alias de TNS para origens de dados
  2. Configurar a configuração inicial do DR
  3. Configurar replicação contínua
  4. Altere as wallets de um sistema Oracle WebLogic Server, Oracle SOA ou Oracle Fusion Middleware.
Cada script fornece automação para diferentes partes da configuração e do ciclo de vida de um sistema de proteção contra desastres. A tabela a seguir fornece um resumo dos utilitários:
Nome do Script Descrição
fmwadb_config_replica.sh Replicar a configuração entre sites.
fmwadb_dr_prim.sh Prepara um local principal para a configuração do DR.
fmwadb_dr_stby.sh Prepara um site secundário para a configuração do DR.
fmwadb_rest_api_listabds.sh Obtenha a base de atribuição do Autonomous Database no ID do ADB e nas informações da tenancy.
fmwadb_switch_db_conn.sh Substitui as informações de conexão existentes por um novo WALLET ADBS.
fmw_change_to_tns_alias.sh Substitua as strings de conexão usadas pelas origens de dados do Oracle WebLogic e pelos arquivos jps config por um alias tns.
fmw_dec_pwd.sh Decriptografa uma senha criptografada pelo Oracle WebLogic.
fmw_enc_pwd.sh Criptografa uma senha usando a criptografia do Oracle WebLogic.
fmw_get_connect_string.sh Retorna a string de conexão que uma origem de dados do Oracle WebLogic, do Oracle SOA ou do Oracle Fusion Middleware está usando.
fmw_get_ds_property.sh Retorna o valor de uma propriedade de origem de dados específica.

Preparar a camada intermediária principal para o front-end virtual

Se a camada intermediária principal ainda não estiver configurada com um nome de front-end virtual, execute essas ações para prepará-la para a configuração de recuperação de desastres (DR).

  1. Adicione o nome de front-end virtual e o IP ao arquivo /etc/hosts em todos os hosts de camada intermediária principais.
    Cada site deve sempre resolver o nome front-end com seu balanceador de carga local, independentemente da resolução voltada para o cliente por meio do DNS (Domain Name System). Como usuário root, edite o arquivo /etc/hosts e mapeie o IP público do balanceador de carga principal para o nome de domínio totalmente qualificado (FQDN) front-end virtual. Repita todos os hosts principais do Oracle WebLogic. Por exemplo: 
    [oracle@wlsociprefix-wls-0 ~]$ more /etc/hosts
(...)
# Front-end virtual name
111.111.111.111 mywebapps.example.com

    Observação:

    O arquivo /etc/hosts dos hosts principais do Oracle WebLogic não deve ser alterado quando houver um switchover ou failover. Os hosts Oracle WebLogic principais sempre resolverão o nome front-end virtual com seu IP front-end. A atualização de DNS necessária durante os procedimentos de switchover e failover é executada nos arquivos de host ou DNS usados pelos clientes.

  2. Configure o nome front-end como front-end de cluster.
    1. Faça log-in na Console do Oracle WebLogic da sua instância.
    2. Navegue até Ambiente, Clusters e selecione o cluster.
    3. Vá até Configuração e HTTP.
    4. Defina o host Frontal como o FQDN front-end.
      Por exemplo, mywebapps.example.com.
    5. Certifique-se de que as portas Frontend para HTTP e HTTPS estejam configuradas corretamente com valores.
    6. Clique em Salvar e depois em Ativar.
  3. Reinicie o cluster para implementar as alterações.

Modificar as Origens de Dados Principais e a Configuração do JPS para Usar um Alias do TNS

O uso de um alias TNS (Transparent Network Substrate) em URLs de Conectividade de Banco de Dados Java (JDBC) facilita a reconfiguração das origens de dados do Oracle WebLogic Server for Oracle Cloud Infrastructure usando clones atualizáveis remotos para mover entre principal e standby.

Observação:

As instâncias do Oracle SOA Suite on Marketplace provisionadas com a versão 23.1.1 (fevereiro de 2023) ou posterior são configuradas com a abordagem de alias TNS pronta para uso. Nesse caso, você pode ignorar esta tarefa.

O uso de um alias TNS requer que as origens de dados e os arquivos jps incluam a variável oracle.net.tns_admin nos arquivos de configuração do Oracle Fusion Middleware.

  1. Use o comando grep para procurar a variável oracle.net.tns_admin no arquivo de configuração do Oracle Fusion Middleware. 
    [oracle@soarefr-soa-0 ~]$ grep oracle.net.tns_admin ${DOMAIN_HOME}/config/fmwconfig/jps-config.xml 
<property name="oracle.net.tns_admin" value="/u01/data/domains/soarefr_domain/config/atp"/>

[oracle@soarefr-soa-0 ~]$ grep oracle.net.tns ${DOMAIN_HOME}/config/jdbc/opss-datasource-jdbc.xml  -A1 | grep value 
<value>/u01/data/domains/soarefr_domain/config/atp</value>
[oracle@soarefr-soa-0 ~]$
    O diretório refletido em jps-config.xml (e origens de dados) deve estar disponível e acessível de todos os nós no domínio do WebLogic Server.
    • No Oracle SOA Suite on Marketplace, esse diretório está no diretório $DOMAIN_HOME/config/atp (antes da release 23.1.1) ou no diretório $DOMAIN_HOME/config/tnsadmin (para a release 23.1.1 e posterior) e é automaticamente replicado pelo WebLogic Server para todos os outros nós quando os servidores gerenciados são iniciados.

      Observação:

      Se o seu Oracle SOA Suite on Marketplace principal estiver antes da versão 23.1.1, é recomendável mover a pasta para o diretório $DOMAIN_HOME/config/tnsadmin para torná-la consistente com o standby.
    • No Oracle WebLogic Server for Oracle Cloud Infrastructure, ele está localizado em $DOMAIN_HOME/atpwallet.

      Observação:

      Se a wallet não estiver localizada no diretório DOMAIN_HOME/config, as alterações no conteúdo do diretório da wallet NÃO serão replicadas pela infraestrutura do Oracle WebLogic Server para outros nós automaticamente. Nesses casos, você deve alterar o diretório da wallet (e atualizar as configurações de origens de dados necessárias) ou copiá-lo manualmente para outros nós quando ele for atualizado.
    • Em outras configurações, você pode colocar o diretório no armazenamento compartilhado.
    Em todos os casos, o mesmo diretório tns_admin deve ser acessível por todos os diferentes membros de um domínio do WebLogic Server. Esse diretório conterá um arquivo tnsnames.ora com diferentes aliases para os diferentes serviços criados no Oracle Autonomous Database.

    Veja a seguir um arquivo tnsnames.ora de amostra e a configuração do Oracle Fusion Middleware com o Oracle Autonomous Database Serverless. 

    [oracle@soarefr-soa-0 ~]$ cat 
$DOMAIN_HOME}}/config/tnsadmin/tnsnames.ora
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

    As modificações no arquivo tnsnames.ora são consumidas dinamicamente pelas origens de dados WLS. Isso significa que você pode alterar o arquivo tnsnames.ora (por exemplo, para apontar para outro serviço) sem exigir a reinicialização da origem de dados.

  2. Para modificar uma configuração de origem de dados padrão para usar um alias TNS em um sistema Oracle SOA Suite on Marketplace ou Oracle WebLogic Server for Oracle Cloud Infrastructure que use o Autonomous Database, use o script fmw_change_to_tns_alias.sh.

    O alias deve ser usado em todos os arquivos de origem de dados em $DOMAIN_HOME/config/jdbc e nos arquivos jps config em $DOMAIN_HOME/config/fmwconfig.

    Observação:

    Este script só alterará a string de conexão e a propriedade tns_admin. Se você adicionar outras origens de dados personalizadas, elas também precisarão usar um alias TNS como os internos para Oracle WebLogic, Oracle SOA Suite on Marketplace e Oracle Fusion Middleware.
    Quando o Oracle WebLogic Server for Oracle Cloud Infrastructure ou o Oracle SOA Suite on Marketplace são provisionados usando o Oracle Autonomous Database, a configuração da wallet do banco de dados é incluída nas origens de dados (local da área de armazenamento de confiança, local da área de armazenamento de chaves, etc.). Esses parâmetros NÃO são modificados pelo script fmw_change_to_tns_alias.sh e são válidos se o alias TNS estiver sendo usado ou não. Um diretório de wallet é criado pelo Oracle WebLogic Server for Oracle Cloud Infrastructure e pelo Oracle SOA Suite on Marketplace durante o provisionamento e já contém um arquivo tnsnames.ora. Você também pode obter a wallet do Oracle Autonomous Database na interface de usuário do banco de dados autônomo no OCI.

    Observação:

    A wallet do Oracle Autonomous Database usada pelo Oracle WebLogic Server for Oracle Cloud Infrastructure e pelo Oracle SOA Suite on Marketplace é baixada para o nó do servidor de Administração quando ele é provisionado. Você pode atualizar a wallet dos sistemas principal e stand-by fazendo o download novamente da interface do usuário do Oracle Autonomous Database e atualizando a senha da wallet no diretório $DOMAIN_HOME/config/jdbc e nos arquivos jps config em $DOMAIN_HOME/config/fmwconfig. O uso da mesma senha para wallets do clone principal, stand-by e atualizável facilitará a manipulação da configuração da origem de dados em ambos os sites; no entanto, os scripts fornecidos abaixo poderão lidar com senhas diferentes. Use o script fmwadb_switch_db_conn.sh para atualizar o sistema com uma nova wallet.

    Quando seu sistema principal foi provisionado, você escolheu (nas telas de provisionamento) um dos níveis de serviço do Oracle Autonomous Database. Execute o script fmw_change_to_tns_alias.sh com o mesmo nível de serviço. Os níveis de serviço de um serviço de BD no Oracle Autonomous Database são: baixo, médio, alto tp, tpurgente. Veja a seguir um exemplo de alteração do Oracle Fusion Middleware para o alias TNS: 

    [oracle@soarefr-soa-0 ~]$ grep url /u01/data/domains/soarefr_domain/config/fmwconfig/jps-config.xml
<property name="jdbc.url" value="jdbc:oracle:thin:@(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))"/>
[oracle@soarefr-soa-0 ~]$ grep url /u01/data/domains/soarefr_domain/config/jdbc/opss-datasource-jdbc.xml
<url>jdbc:oracle:thin:@(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))</url>
 
NOTICE the "low" label in g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com, that is the service flag that will allow you identify the tns alias that needs to be used
 
[oracle@soarefr-soa-0 good]$ cat $DOMAIN_HOME/config/atp/tnsnames.ora | grep low | awk -F '=' '{print $1}'
soaadb1_low
 
[oracle@soarefr-soa-0 good]$ ./fmw_change_to_tns_alias.sh soaadb1_low                                                                                          
Getting variables from current datasource ...............
An existing tns_admin property was found in /u01/data/domains/soarefr_domain/config/jdbc/opss-datasource-jdbc.xml and will be used
Found soaadb1_low  as tns_alias
No modifications will be required in /u01/data/domains/soarefr_domain/config/atp/tnsnames.ora
*******************WILL USE THESE SETTINGS********************
**************************************************************
TNS admin:........................./u01/data/domains/soarefr_domain/config/atp
TNS alias:........................ soaadb1_low
Current connect string:............(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
Current jps connect string:........(description=(retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
Current tnsnames.ora:..............
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
**************************************************************
Taking backup of existing config...
************** Replacing DB connect information **************
Replacing jdbc url in config/jdbc files...
Replacing jdbc url in config/fmwconfig files...
Replacement complete!
 
[oracle@soarefr-soa-0 ~]$ grep url $DOMAIN_HOME/config/fmwconfig/jps-config.xml
<property name="jdbc.url" value="jdbc:oracle:thin:@soaadb1_low "/>
[oracle@soarefr-soa-0 ~]$ grep url /u01/data/domains/soarefr_domain/config/jdbc/opss-datasource-jdbc.xml
    <url>jdbc:oracle:thin:@soaadb1_low </url>
<property name="jdbc.url" value="jdbc:oracle:thin:@soaadb1_low "/>
[oracle@soarefr-soa-0 ~]$
  3. Reinicie todos os Servidores do Oracle WebLogic no domínio para consumir as alterações executadas pelo script.

Criar uma VCN e uma Sub-rede na Região Secundária

Se você ainda não tiver feito isso, crie uma VCN na região stand-by com um CIDR que não entre em conflito com o CIDR da região principal. Por exemplo, se a VCN principal usar 10.1.0.0/16, a VCN secundária poderá usar 10.2.0.0/16.

  1. Crie uma VCN e uma sub-rede na região secundária.
    Você pode criar uma pilha de serviços em nuvem para provisionar um grupo de serviços em nuvem relacionados.
  2. Certifique-se de que as listas de segurança permitam as comunicações apropriadas entre as camadas.

    Verifique a seguinte comunicação:

    • Do balanceador de carga do OCI para o Servidor WebLogic
    • Do Servidor WebLogic para o banco de dados
    • Do Servidor WebLogic para o armazenamento compartilhado

    Além disso, inclua as regras necessárias para permitir comunicações entre os nós do servidor de administração por meio do Gateway de Roteamento Dinâmico (DRG) quando ele for criado.

Configurar um DRG entre as VCNs Primárias e Secundárias

A configuração da recuperação de desastres exige que os Nós de Administração primários e secundários do Oracle WebLogic Server se comuniquem entre si para receber a configuração do domínio por meio de cópias do Oracle Cloud Infrastructure File Storage. Para isso, você deve criar um gateway de roteamento dinâmico (DRG) entre as VCNs de camada intermediária.

  1. Crie um DRG entre as VCNs de camada intermediária.
  2. Verifique se o novo DRG aparece na página Gateways de Roteamento Dinâmico do compartimento ou região escolhida.
    Os scripts de configuração de DR verificarão se as conexões necessárias podem ser estabelecidas.
  3. Configure as rotas e as regras de segurança apropriadas nas VCNs principal e standby para permitir conexões SSH entre as camadas intermediárias.
  4. Verifique se você pode estabelecer uma conexão SSH do nó do Oracle WebLogic Administration Server em principal para o nó do Oracle WebLogic Administration Server em secundário.
    Por exemplo, se 10.2.1.104 for o IP do nó do Servidor de Administração do secundário, execute o seguinte no nó do Servidor de Administração do principal.
    [opc@soarefr-soa-0 ~]$ ssh -i KeySOAMAA.ppk opc@10.2.1.104
Last login: Wed Dec 14 16:59:15 2022 from 10.2.0.83
[opc@soarefr-soa-0 ~]$

Criar um Standby do Oracle Autonomous Data Guard na Região Secundária

Crie um banco de dados stand-by para o Oracle Autonomous Database principal existente.

  1. Para o Oracle Autonomous Database Serverless, crie um Oracle Autonomous Database Serverless stand-by na região secundária.
    1. Na Console do OCI, clique em Oracle Database no menu de navegação esquerdo para navegar até o Oracle Autonomous Database principal.
    2. Na página Detalhes do Autonomous Database, em Recursos, clique em Recuperação de Desastres e, em seguida, clique em Adicionar banco de dados de mesmo nível.
    3. Use a VCN e as sub-redes privadas que você criou anteriormente.
  2. Para o Oracle Autonomous Database on Dedicated Exadata Infrastructure Dedicado
    1. Na Console do OCI, navegue até a página de detalhes do Autonomous Container Database e selecione o recurso de associações do Autonomous Data Guard na seção Recursos.
    2. Clique em Ativar Autonomous Data Guard.
    3. Digite as informações do Cluster de VMs Autônomas de pareamento, o modo de proteção e a opção de failover automático. Depois de especificar todas as informações necessárias, clique em Ativar Autonomous Data Guard.
      Como parte desse workflow, um novo Autonomous Container Database stand-by é criado com todos os bancos de dados autônomos stand-by no Cluster de VMs Autônomas selecionado.

Preparar o Autonomous Database Standby para a Configuração de DR

Esta tarefa depende se você está usando a abordagem Snapshot Stand-by ou Clone Remoto Atualizável.

Para a abordagem Stand-by Snapshot, consulte Converter o Stand-by em um Stand-by Snapshot.

Para a abordagem Clone Atualizável Remoto, consulte Criar um Clone Atualizável Remoto na Região Secundária.

Converter o Standby em Standby Snapshot

Usando a abordagem Standby Snapshot, converta seu banco de dados autônomo standby em Standby Snapshot.

  1. No menu de navegação esquerdo da Console do Oracle Cloud Infrastructure, clique em Autonomous Database.
  2. Na região secundária, selecione o Autonomous Database standby.
  3. Na lista drop-down Mais Ações, clique em Converter em um banco de dados stand-by de snapshot.
  4. Se você estiver usando uma Infraestrutura Dedicada, selecione Usar serviços de banco de dados principais.

Observação:

Quando um Snapshot Stand-by no Oracle Dedicated Exadata Infrastructure não é convertido em stand-by físico dentro de 7 dias, o Snapshot Stand-by é automaticamente convertido em stand-by físico.

Quando um Stand-by de Snapshot no Oracle Autonomous Database Serverless não é convertido em stand-by físico em 2 dias, o Stand-by de Snapshot é convertido automaticamente em stand-by físico.

Criar um Clone Remoto Atualizável na Região Secundária

Usando a abordagem Clone Atualizável Remoto, crie um clone atualizável com base no Oracle Autonomous Database Serverless principal existente na região remota.

  1. Crie um clone atualizável com base no Oracle Autonomous Database Serverless principal existente.
    Coloque o clone atualizável na região secundária (remota) dentro da VCN e da sub-rede privada que você criou anteriormente.

    Observação:

    Não é possível usar o mesmo nome do BD que o principal, pois esse nome já está sendo usado pelo Standby Físico.
  2. Use Private Endpoint Access Only para acessar o banco de dados.

    Uma vez criado, o clone atualizável permanecerá conectado e no modo somente para leitura. Os sistemas Oracle WebLogic Server, Oracle SOA e Oracle Fusion Middleware não podem ser provisionados para ele SEM que seja convertido em leitura-gravação (desconectado do principal).

  3. Desconecte o clone atualizável do banco de dados autônomo principal e converta-o no modo de leitura/gravação.

    Observação:

    O clone atualizável remoto não pode permanecer desconectado por mais de 24 horas. Por exemplo, não pode levar mais de 24 horas para criar as camadas intermediárias secundárias apontando para o banco de dados clone atualizável remoto.
    1. No menu de navegação à esquerda do Oracle Cloud Infrastructure, clique em Autonomous Database.
    2. Selecione o nome do clone atualizável.
    3. Selecione o banco de dados de origem e clique em Desconectar.

Provisionar o Sistema Secundário

Provisione o Oracle WebLogic Server for Oracle Cloud Infrastructure secundário, o Oracle SOA Suite on Marketplace ou outro serviço Oracle Cloud Infrastructure (OCI) de camada intermediária que use o Oracle Fusion Middleware (sistema) apontando para o banco de dados secundário (para abordagem Snapshot Standby) ou para o clone atualizável (para abordagem de clone atualizável remoto).

  1. Siga as recomendações padrão de sub-rede, CIDR, regras de segurança e prefixo da instância para recuperação de desastres.

    O Nome da Pilha pode ser diferente, mas você deve usar o mesmo prefixo de nome de recurso EXACT usado em seu local principal. A Oracle recomenda que você use exatamente a mesma capacidade e configuração de computação nos locais principal e standby para obter o comportamento ideal de failover/switchover.

    Certifique-se de que a versão e o nível de patch do Oracle WebLogic Server for OCI a serem provisionados no local secundário correspondam ao que está sendo executado no site principal.

    Se você precisar de mais detalhes, consulte a tabela que resume as opções do assistente de provisionamento para a DR configurada na seção "Provisionar WLS para OCI no Site Secundário" do Oracle WebLogic Server for Oracle Cloud Infrastructure Disaster Recovery ou na seção "Provisionar SOA Suite no Marketplace no Site Secundário" do SOA Suite no Oracle Cloud Infrastructure Marketplace Disaster Recovery.

  2. Crie o sistema de camada intermediária secundária de acordo com o processo de provisionamento padrão.
  3. Verifique o Oracle WebLogic Server for Oracle Cloud Infrastructure padrão, o Oracle SOA Suite on Marketplace ou qualquer outro serviço Oracle Cloud Infrastructure (OCI) de camada intermediária que use URLs do Oracle Fusion Middleware (por exemplo, Console, soa-infra etc.) para validar se o sistema foi criado corretamente.
  4. Uma vez validado, interrompa os processos do Oracle WebLogic no stand-by: servidores gerenciados, servidor de administração e gerenciadores de nó.
  5. Se estiver usando clone atualizável remoto, você poderá reconectá-lo à origem. Se você estiver usando um stand-by de snapshot, poderá convertê-lo em um stand-by físico novamente.
    Não tente iniciar os processos do Oracle WebLogic em secundário até que a configuração do DR seja concluída.

Modificar as Strings de Conexão de Alias TNS do Secundário

Modifique o alias usado no sistema secundário para ser o mesmo alias do sistema principal.

Assim como no sistema principal, você deve usar um alias TNS (Transparent Network Substrate) em todos os arquivos de origem de dados em $DOMAIN_HOME/config/jdbc e nos arquivos jps config em $DOMAIN_HOME/config/fmwconfig. O alias usado no sistema secundário (standby) será o mesmo do sistema principal porque as origens de dados são replicadas do principal que contém o alias criado anteriormente.

Esta tarefa depende se você está usando uma abordagem Snapshot Stand-by ou Clone Remoto Atualizável.

Modificar as Strings de Conexão de Alias TNS do Secundário para Abordagem de Standby de Snapshot

Para a abordagem Standby Snapshot, espera-se que os aliases no arquivo tnsnames.ora sejam os mesmos do principal (embora as strings de conexão apontem para o endereço do banco de dados stand-by). Você não precisa modificá-los.

  1. Se as strings no arquivo tnsnames.ora forem duplas (onde elas contêm hosts de banco de dados autônomos locais e remotos), a Oracle recomenda que você as modifique para apontar SOMENTE para o banco de dados local.
    Isso pode acontecer quando você está usando o Oracle Autonomous Database na Infraestrutura Dedicada. Você só precisa fazer essa alteração uma vez, pois o arquivo tnsnames.ora para standby não é alterado pela replicação de configuração e outras operações de ciclo de vida.

    Veja a seguir um exemplo em que as entradas no arquivo tnsnames.ora são duplas: 

    adbd1_tp=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST= host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)) (ADDRESS = (PROTOCOL=TCP)(HOST=host-xwgo9-scan.primarysubnet.primaryvcn.oraclevcn.com)(PORT=1521)) )(CONNECT_DATA = (SERVICE_NAME = ADBD1_tp.atp.oraclecloud.com)))

adbd1_medium=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)) (ADDRESS = (PROTOCOL=TCP)(HOST=host-xwgo9-scan.primarysubnet.primaryvcn.oraclevcn.com)(PORT=1521)) )(CONNECT_DATA = (SERVICE_NAME = ADBD1_medium.atp.oraclecloud.com)))

adbd1_tpurgent=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)) (ADDRESS = (PROTOCOL=TCP)(HOST=host-xwgo9-scan.primarysubnet.primaryvcn.oraclevcn.com)(PORT=1521)) )(CONNECT_DATA = (SERVICE_NAME = ADBD1_tpurgent.atp.oraclecloud.com)))
…
  2. Se você tiver entradas duplas, modifique-as para apontar apenas para o Autonomous Database local removendo o ENDEREÇO do banco de dados remoto.

    O arquivo tnsnames.ora em secundário deve incluir apenas o ENDEREÇO do banco de dados stand-by. Por exemplo: 

    adbd1_tp=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST= host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)))(CONNECT_DATA = (SERVICE_NAME = ADBD1_tp.atp.oraclecloud.com)))

adbd1_medium=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)))(CONNECT_DATA = (SERVICE_NAME = ADBD1_medium.atp.oraclecloud.com)))

adbd1_tpurgent=(DESCRIPTION =(CONNECT_TIMEOUT = 90)(RETRY_COUNT = 50)(RETRY_DELAY = 3)(TRANSPORT_CONNECT_TIMEOUT = 3)(ADDRESS_LIST =(LOAD_BALANCE = ON)(ADDRESS = (PROTOCOL=TCP)(HOST=host-kyzm3-scan.secondarysubnet.secondaryvcn.oraclevcn.com)(PORT=1521)))(CONNECT_DATA = (SERVICE_NAME = ADBD1_tpurgent.atp.oraclecloud.com)))
…

Modificar as Strings de Conexão de Alias TNS do Secundário para a Abordagem de Clone Atualizável Remoto

Para a abordagem Clone Atualizável Remoto, modifique o alias usado no sistema secundário para ser o mesmo alias do sistema principal.

O arquivo tnsnames.ora incluído na criação secundária do sistema Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace ou Oracle Fusion Middleware conterá um alias com base no nome do clone atualizável remoto. Por exemplo, se um clone atualizável remoto for criado com o nome soaadb1rc2, o arquivo tnsnames.ora (no diretório da wallet criado durante o provisionamento) conterá o seguinte alias: soaadb1rc2_high, soaadb1rc2_low, soaadb1rc2_medium, soaadb1rc2_tp, soaadb1rc2_tpurgent. Para simplificar a configuração, você deve usar o mesmo nome de alias no arquivo tnsnames.ora nos sistemas principal e secundário; portanto, modifique o alias TNS com o qual o domínio Oracle WebLogic Server for Oracle Cloud Infrastructure, Oracle SOA Suite on Marketplace ou Oracle Fusion Middleware está configurado (clone atualizável remoto) para usar o mesmo nome de alias como principal. Você pode obter o nome do alias em principal no arquivo $tns_admin/tsnames.ora. Aliases diferentes são criados para serviços diferentes e todos inferirão um prefixo do nome do BD. Observe que você deseja modificar apenas o nome do alias, não os serviços. Não use uma pesquisa global e substitua-a no arquivo, pois isso provavelmente também alterará os nomes de serviço nas strings de conexão no arquivo tnsnames.ora.

  • Modifique o arquivo tnsnames.ora do sistema secundário para usar o mesmo alias do sistema principal.

    Veja a seguir um arquivo tnsnames.ora de amostra para uma configuração do Oracle Fusion Middleware com o Oracle Autonomous Database Serverless no sistema principal. 

    [oracle@soarefr-soa-0 ~]$ cat $DOMAIN_HOME/config/tnsadmin/tnsnames.ora
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

    Veja a seguir um arquivo tnsnames.ora de amostra para uma configuração do Oracle Fusion Middleware com o Oracle Autonomous Database Serverless no secundário com Clone Atualizável. 

    oracle@soarefr-soa-0 ~]$ cat $DOMAIN_HOME/config/tnsadmin/tnsnames.ora
rcsoaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
rcsoaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

    Como é uma operação única, a maneira mais fácil de alterar o alias do clone atualizável é editar o arquivo. Você pode modificar o alias do nível de serviço em uso ou todos eles para consistência.

    Observação:

    Isso deve ser feito toda vez que um novo clone atualizável for usado para testes ou validações e uma nova wallet for usada.

    Veja a seguir um arquivo tnsnames.ora de amostra para uma configuração do Oracle Fusion Middleware com o Oracle Autonomous Database Serverless no secundário com Clone Atualizável usando o alias do Principal. 

    [oracle@soarefr-soa-0 ~]$ cat $DOMAIN_HOME/config/tnsadmin/tnsnames.ora
soaadb1_high = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_low = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_medium = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tp = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
 
soaadb1_tpurgent = (description= (retry_count=20)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=rcsoaadb1.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_rcsoaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))

Da mesma forma que no sistema principal, todos os arquivos de origem de dados em $DOMAIN_HOME/config/jdbc e nos arquivos de configuração jps em $DOMAIN_HOME/config/fmwconfig usam o alias escolhido. Espera-se que o mesmo nível de serviço tenha sido escolhido com o clone atualizável remoto como no sistema principal (low, mid, high, tp ou tpurgent). Como o alias e as origens de dados são copiados do sistema principal, você não precisa executar o script fmw_change_to_tns_alias.sh no sistema secundário. A configuração da recuperação de desastres tratará das substituições necessárias.

Se você tiver aliases adicionais para apontar para outros bancos de dados no arquivo tnsnames.ora principal, adicione-os de acordo no arquivo tnsnames.ora do sistema secundário.

Atualizar os Aliases de Nome de Host e o Endereço de Front-End nas Camadas Primária e Stand-by

A configuração do domínio WebLogic na secundária será uma cópia do domínio WebLogic principal quando a configuração do DR for concluída. Portanto, os nomes de host usados como endereços de listening pelos Servidores Oracle WebLogic principais (que são os nomes de host dos hosts principais) devem ser válidos no local secundário, mas mapeamento para os IPs secundários.

O mesmo endereço front-end deve ser usado no principal e no stand-by. Durante a operação normal, esse nome de host front-end será mapeado para o IP do Balanceador de Carga principal do Oracle Cloud Infrastructure (OCI). Quando executado de secundário (depois de um switchover ou failover), esse nome de host front-end será mapeado para o IP do Balanceador de Carga secundário do OCI.

Observação:

O arquivo /etc/hosts dos hosts da camada intermediária não deve ser alterado quando há um switchover ou failover. Os hosts da camada intermediária sempre resolverão o nome do front-end virtual com seu IP front-end. A atualização de DNS necessária durante os procedimentos de switchover e failover é executada nos arquivos de host ou DNS usados pelos clientes.

Você pode implementar esse alias de host das seguintes maneiras:

  • Adicione os nomes de host como aliases aos arquivos /etc/hosts das instâncias de computação do Oracle WebLogic Server for OCI
  • Usar uma view de DNS privado na VCN secundária do OCI

Usar Arquivos /etc/hosts

Os nomes de host usados pelo Oracle WebLogic Server principal são adicionados aos arquivos /etc/hosts dos hosts secundários do Oracle WebLogic Server, apontando para os endereços IP dos hosts secundários do Oracle WebLogic Server. Esse modo é válido quando o servidor DNS é o mesmo nos sites principal e secundário do Oracle Cloud Infrastructure (OCI) e também quando servidores DNS separados são usados nos sites principal e secundário. As entradas no arquivo /etc/hosts têm precedência sobre a resolução de DNS, porque essa é a precedência definida pronta para uso nos "hosts" da diretiva do arquivo /etc/nsswitch.conf.
  1. Edite o arquivo /etc/oci-hostname.conf de cada instância de computação do WebLogic Server e defina a propriedade PRESERVE_HOSTINFO=3 para preservar entradas /etc/hosts nas reinicializações da instância.
  2. Use o comando hostname --fqdn para identificar os nomes de host completos das instâncias de computação do WebLogic Server do OCI.
  3. Adicione as seguintes entradas ao arquivo /etc/hosts das instâncias de computação de camada intermediária:
    #################################
# ALIASES on OCI for DR
#################################
apphost1_compute_instance_IP  apphost1_fqdn   apphost1_hostname   ALIAS_OF_APPHOST1 
apphost2_compute_instance_IP  apphost2_fqdn   apphost2_hostname   ALIAS_OF_APPHOST2 
#################################
# Frontend name 
#################################
IP_OF_LBR  frontend_name_fqdn
    Veja a seguir um exemplo do arquivo /etc/hosts dos hosts Oracle WebLogic Server principais:
    # Aliases for DR in primary region
10.0.2.10 wlsociprefix-wls-0.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-0 
10.0.2.11 wlsociprefix-wls-1.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-1

# Front-end virtual name to primary LBR IP
111.111.111.111 mywebapps.mycompany.com

    Veja a seguir um exemplo do arquivo /etc/hosts na instância de computação do Servidor do OCI WebLogic secundário.

    Observação:

    Os nomes de host principais são adicionados como aliases dos nós secundários e esse nome virtual front-end aponta para o IP do balanceador de carga secundário:

    # Aliases for DR in secondary region
10.1.2.5 wlsociprefix-wls-0.subnetfra.vcnfra.oraclevcn.com wlsociprefix-wls-0 wlsociprefix-wls-0.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-0
10.1.2.4 wlsociprefix-wls-1. subnetfra.vcnfra.oraclevcn.com wlsociprefix-wls-1 wlsociprefix-wls-1.subnetlon.vcnlon.oraclevcn.com wlsociprefix-wls-0

# Front-end virtual name to secondary LBRIP
222.222.222.222 mywebapps.example.com

Usar o DNS (Dain Name System) do OCI

Os nomes de host usados pelos hosts principais do Oracle WebLogic Server são adicionados ao resolvedor de DNS usado pela VCN dos servidores de camada intermediária secundária, apontando para os endereços IP dos hosts secundários do Oracle WebLogic Server. Esse modo é válido quando servidores DNS separados são usados em sites principais e secundários do Oracle Cloud Infrastructure (OCI). Caso contrário, ele poderá causar conflitos na resolução de nomes. O servidor de cada site deve resolver esses nomes com seus próprios IPs. A vantagem desse método é que você pode adicionar todas as entradas a uma view DNS privada, em vez de adicioná-las a todos os /etc/hosts de todos os hosts do Oracle WebLogic Server.

Veja a seguir as etapas para criar a view privada na VCN secundária e resolver os nomes de host usados por principal com os IPs secundários:

  1. Na Console do OCI, vá para a região secundária e crie a view privada para resolver os nomes dos hosts PRIMARY COM os endereços IP SECONDARY.
    1. Clique em Rede, Gerenciamento de DNS, Views Privadas e, em seguida, em Criar View Privada.
      Por exemplo, você pode nomear a view privada: PRIMARY_HOSTNAMES_PRIVATE_VIEW
    2. Clique em Criar Zona na view privada.
      Para o nome da zona, você deve usar o domínio completo dos hosts. Por exemplo: subnetpri.vcnpri.oraclevcn.com
    3. Adicione os nomes de host principais a esta zona (nome curto), mas resolvidos com o endereço IP dos hosts secundários do Oracle WebLogic Server.
    4. Clique em Publicar alterações.
  2. Adicione a view privada ao resolvedor de VCN secundário.
    1. Clique no recurso Resolvedor de DNS na VCN.
    2. Adicione a view privada de DNS criada anteriormente.
      Os hosts na VCN secundária resolverão os nomes de host usados pelos hosts principais do Oracle WebLogic Server usando a view privada.
  3. Valide os hosts SECONDARY de resolução, fazendo ping e nslookup dos nomes de host.
    Eles devem ser resolvidos com os IPs SECONDARY equivalentes.

    Observação:

    Você pode encontrar o código do Terraform para criar essa view privada do OCI e registros em GitHub.

Configurar o Sistema Secundário

Para configurar o sistema como secundário, copie a configuração de domínio do WebLogic Server do principal para o domínio do sistema secundário WebLogic Server, Oracle SOA Suite ou Oracle Fusion Middleware.
A configuração de recuperação de desastres (DR) substitui todo o domínio secundário, exceto diretórios e arquivos específicos que devem permanecer localmente válidos. Esses diretórios são explicitamente excluídos pelos scripts. Além disso, o script substitui os arquivos de origem de dados de modo que o secundário use os mesmos nomes de esquema do BD que no principal, mas com o jdbc url existente apontando para o banco de dados local (clone atualizável durante a configuração do DR e standby na preparação para switchover) com as wallets necessárias.
  1. Execute o script fmwadb_dr_prim.sh no Nó de Administração do Servidor WebLogic principal.
    O script verificará a conectividade entre os nós do Servidor de Administração do WebLogic Server por meio do Gateway de Roteamento Dinâmico e copiará o domínio para o diretório de preparação em uma montagem do Oracle Cloud Infrastructure File Storage na região secundária.

    Use os seguintes parâmetros:

    • REMOTE_ADMIN_NODE_IP

      O endereço IP do nó secundário do servidor de Administração do WebLogic Server.

      Este IP deve estar acessível neste HOST (o nó principal do servidor de Administração do Oracle WebLogic Server.)

      É recomendável que você use o Dynamic Routing Gateway para interconectar os sites principal e secundário, permitindo que você forneça o endereço IP privado.

    • REMOTE_SSH_PRIV_KEYFILE

      O arquivo de chaves ssh privado para estabelecer conexão com o nó remoto do servidor de Administração do Oracle WebLogic.

    • FSS_MOUNT

      O diretório montado do Armazenamento de Arquivos do OCI que é usado para preparar a cópia da configuração do domínio do WebLogic Server. 

    ./fmwadb_dr_prim.sh [REMOTE_ADMIN_NODE_IP] [REMOTE_SSH_PRIV_KEYFILE] [FSS_MOUNT]
    Este é um exemplo do comando e da saída:
    [oracle@soarefr-soa-0 ~]$ ./fmwadbs_dr_prim.sh '10.2.1.104' '/u01/soacs/dbfs/share/KeyWithoutPassPhraseSOAMAA.ppk' /u01/soacs/dbfs/share/
 Checking ssh connectivity to remote WebLogic Administration server node....
    Connectivity to 10.2.1.104 is OK
    REMOTE_ADMIN_HOSTNAME...... soarefr-soa-0.sub09051735411.soaadbvcnstby.oraclevcn.com
 Checking local FSS mount folder readiness........
     The FSS is expected to be mounted in /u01/soacs/dbfs/share
     The folder for the copy of the domain is expected to be /u01/soacs/dbfs/share/domain_config_copy
     Local folder /u01/soacs/dbfs/share/domain_config_copy exists.
 Checking remote FSS mount folder readiness........
     Remote folder 10.2.1.104:/u01/soacs/dbfs/share/domain_config_copy exists.
 
----------- Rsyncing from local domain to local FSS folder ---------------
 
Local rsync output to /u01/soacs/dbfs/share/domain_config_copy/last_primary_update_local_06-10-2022-09-47-50.log ....
Source and target directories are in sync. ALL GOOD!
 
----------- Local rsync complete -----------------------------------------
 
----------- Rsyncing from local FSS folder to remote site... --------------
Remote rsync output to /u01/soacs/dbfs/share/domain_config_copy/last_primary_update_remote_06-10-2022-09-47-50.log ....
Source and target directories are in sync. ALL GOOD!
  2. Quando o script fmwadb_dr_prim.sh terminar de executar, se ainda não tiver parado, interrompa todos os sistemas do WebLogic Server e gerenciadores de nó no sistema secundário.
  3. Faça log-in no nó de Administração do WebLogic Server secundário e execute o script fmwadb_dr_stby.sh.

    O script copia o domínio WebLogic Server do diretório de preparação em uma montagem do Armazenamento de Arquivos do OCI para o diretório de domínio secundário do WebLogic Server e substitui as entradas de wallet e senha necessárias. A wallet a ser fornecida é o clone atualizável para que secundário possa ser validado após a configuração inicial do DR.

    Use os seguintes parâmetros:

    • WALLET_DIR

      O diretório de uma wallet do Oracle Autonomous Database descompactada. Nó do servidor de administração do WebLogic Server.

      Esse diretório deve conter pelo menos arquivos tnsnames.ora, keystore.jks e truststore.jks.

      Se você estiver usando a abordagem stand-by de snapshot, essa será apenas a pasta tnsadmin.

    • WALLET_PASSWORD

      A senha fornecida quando o download da wallet foi feito na IU do OCI do Oracle Autonomous Database Serverless.

      Se a wallet for a inicial criada pelo sistema WebLogic Server, Oracle SOA Suite ou Oracle Fusion Middleware ao provisionar. Você pode obtê-lo com o seguinte comando:

      Oracle SOA:
      python /opt/scripts/atp_db_util.py generate-atp-wallet-password
      Oracle WebLogic Server:
      python3 /opt/scripts/atp_db_util.py generate-atp-wallet-password
    • FSS_MOUNT

      O diretório montado do Armazenamento de Arquivos do OCI que é usado para preparar a configuração de domínio do WebLogic Server. 

    ./fmwadb_dr_stby.sh [WALLET_DIR] [WALLET_PASSWORD] [FSS_MOUNT]
    Este é um exemplo da execução e da saída do comando:
    [oracle@wsladbs2-wls-0 scripts]$ ./fmwadb_dr_stby.sh /u01/data/domains/wsladbs2_domain/config/atpwallet/  7f3e3ed8ee7921fed058b481298eca55 /u01/shared/
Backing up current domain...
Backup created at /u01/data/domains/wsladbs2_domain/ /u01/data/domains/wsladbs2_domain_backup_11_42_19-26-10-22
Rsyncing from FSS  mount to domain dir...
 Syncing the Weblogic Administration server node...
Rsync complete!
Switching config to /u01/data/domains/wsladbs2_domain/config/atpwallet/
The password provided for the wallet is valid. Proceeding...
Gathering Data Soure information...
The new wallet is the same as the one being used.
Will maintain existing wallet dir and just replace password
Backing up current config...
Backup created at  /u01/data/domains/wsladbs2_domain/DS_backup_11_42_33-26-10-22
Replacing values in datasources...
Replacement complete!
  4. Execute o script fmwadb_dr_stby.sh nos outros nós do servidor gerenciado WebLogic Server na região secundária.
  5. Certifique-se de que o banco de dados standby esteja acessível no modo de leitura/gravação.
    • Se você estiver usando a abordagem stand-by de snapshot, certifique-se de que o banco de dados stand-by seja convertido no banco de dados stand-by de snapshot; portanto, ele estará acessível no modo de leitura-gravação.
    • Se você estiver usando a abordagem de Clone Remoto Atualizável, certifique-se de que esteja desconectado da origem; portanto, ele esteja acessível no modo de leitura/gravação.
  6. Inicie o Gerenciador de Nós e o Oracle WebLogic Administration Server em secundário. Acesse a Console e inicie os servidores gerenciados do WebLogic Server no domínio.
  7. Valide se os aplicativos existentes e as implantações no principal também estão disponíveis no secundário.
  8. Faça shutdown dos Servidores WebLogics em secundário.
  9. Converta o standby em um standby físico ou reconecte o clone atualizável.

    • Se você estiver usando a abordagem de standby snapshot, converta o banco de dados standby em um banco de dados standby físico.

    • Se você estiver usando o Clone Remoto Atualizável, reconecte o clone atualizável. Lembrete: O clone atualizável não pode permanecer desconectado do principal por mais de 24 horas.

Deixe o sistema pronto para switchover

Depois que o sistema secundário for configurado e validado com um clone atualizável, deixe o sistema pronto para switchover apontando o alias TNS para o Oracle Autonomous Database Serverless stand-by.

Observação:

Essa tarefa só é necessária quando o sistema secundário é configurado e validado com um Clone Remoto Atualizável.

Faça download da wallet do banco de dados stand-by na interface do usuário do banco de dados secundário. Evite strings de conexão duplas (hosts principal e stand-by) em casos de DR remotos porque elas causam novas tentativas desnecessárias.

  1. Faça log-in na interface de usuário do Oracle Autonomous Database Serverless do seu banco de dados stand-by.
  2. Clique em Autonomous Database, selecione autonomous_db_name, clique em Conexão do BD e, em seguida, clique em Fazer Download da Wallet.
  3. Se a wallet contiver strings duplas apontando para o principal, remova a entrada da descrição principal do arquivo tnsnames.ora para que a string de conexão aponte SOMENTE para o BD local na região secundária.

    Veja a seguir um exemplo de modificação do arquivo tnsnames.ora: 

    soaadb1_high = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_low = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_medium = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_tp = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))
soaadb1_tpurgent = (description_list= (failover=on) (load_balance=off) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbvcn.adb.ap-mumbai-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_cert_dn="CN=adb.ap-mumbai-1.oraclecloud.com, OU=Oracle ADB INDIA, O=Oracle Corporation, L=Redwood City, ST=California, C=US"))) (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))))

SHOULD BE

soaadb1_high = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_high.adb.oraclecloud.com))(security=(ssl_server_dn_match=no))) 
soaadb1_low = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_low.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_medium = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_medium.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tp = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tp.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
soaadb1_tpurgent = (description= (retry_count=15)(retry_delay=3)(address=(protocol=tcps)(port=1522)(host=soaadbstby.adb.ap-hyderabad-1.oraclecloud.com))(connect_data=(service_name=g914a2540e8ab6d_soaadb1_tpurgent.adb.oraclecloud.com))(security=(ssl_server_dn_match=no)))
  4. Copie a wallet para uma pasta temporária no nó do Servidor de Administração WebLogic Server da região secundária e navegue até o diretório.
    [oracle@wsladbs2-wls-0 scripts]$ cd /tmp
[oracle@wsladbs2-wls-0 tmp]$ mkdir wallet-stby
[oracle@wsladbs2-wls-0 tmp]$ cd wallet-stby/
  5. Descompacte o wallet.
    [oracle@wsladbs2-wls-0 wallet-stby]$ unzip /tmp/Wallet_soaadb1-standby.zip
Archive:  ../Wallet_soaadb1-standby.zip
  inflating: ewallet.pem
  inflating: README
  inflating: cwallet.sso
  inflating: tnsnames.ora
  inflating: truststore.jks
  inflating: ojdbc.properties
  inflating: sqlnet.ora
  inflating: ewallet.p12
  inflating: keystore.jks
  6. Execute o script fmwadb_switch_db_conn.sh para deixar a camada intermediária pronta com a wallet secundária e a string de conexão.

    Veja a seguir um exemplo da execução do script para apontar para a wallet stand-by do Oracle Autonomous Database Serverless: 

    [oracle@wsladbs2-wls-0 scripts]$ ./fmwadb_switch_db_conn.sh /tmp/wallet-stby/ wallet_password
The password provided for the wallet is valid. Proceeding...
Gathering Data Source information...
The new wallet is the same as the one being used.
Will maintain existing wallet dir and just replace password
Backing up current config...
Backup created at  /u01/data/domains/wsladbs2_domain/DS_backup_10_38_32-27-10-22
Replacing values in datasources...
Replacement complete!

Configurar Replicação da Configuração em Andamento

Quando o ciclo de vida do sistema envolve atualizações de frequências para o sistema de arquivos de domínio, você pode usar um script para automatizar o processo de replicação da configuração. O script fmwadb_config_replica.sh replica as alterações regularmente por meio do diretório de preparação do Oracle Cloud Infrastructure File Storage (OCI File Storage).

A configuração está pronta (preparada) para um switchover após cada replicação.

Quando você estiver usando o Clone Remoto Atualizável, presume-se que a configuração replicada será "adaptada" para o standby físico (não para o clone atualizável). Se você precisar de uma validação ou teste usando clones atualizáveis, poderá alterar a configuração do domínio stand-by para apontar para o clone atualizável.

Você deve executar o script fmwadb_config_replica.sh nos Nós de Administração do WebLogic Server (no principal e no stand-by) para replicar a configuração. Normalmente, esse script é programado com um job cron para replicar a configuração entre um sistema WebLogic Server principal e um stand-by, Oracle SOA Suite ou Oracle Fusion Middleware no sistema Oracle Autonomous Database em intervalos regulares. Este script verifica a atribuição atual do banco de dados local para determinar se ele está em execução no site principal ou stand-by.

  • Quando o script é executado no site PRIMARY, ele copia a configuração do domínio principal para a pasta de assistência local (FSS) e, em seguida, para a pasta de assistência do site secundário (por meio de rsync).
  • Quando o script é executado no site STANDBY, ele copia a configuração do domínio da pasta de assistência secundária (OCI File Storage) para o domínio secundário e faz as substituições necessárias para que as origens de dados funcionem com o banco de dados local.

Você deve reunir diferentes parâmetros da Console do OCI e criptografar a senha para acessar as wallets do Oracle Autonomous Database por motivos de segurança.

Veja a seguir uma descrição das variáveis usadas no script e como obtê-las:

  • REMOTE_WLSADMIN_NODE_IP

    IP do nó do servidor de Administração do WebLogic Server remoto e de pareamento.

    Este é o IP do host de nó no Servidor de Administração do WebLogic Server no site de mesmo nível. Ele deve estar acessível no nó local. É recomendável conectar-se ao IP privado remoto do nó usando um Gateway de Roteamento Dinâmico.

  • REMOTE_SSH_PRIV_KEYFILE

    O arquivo de chaves SSH privado para estabelecer conexão com o nó remoto do servidor de Administração do Oracle WebLogic.

  • TENANCY_OCID

    O OCID da tenancy em que o Oracle Autonomous Database reside. Você pode obter o OCID da interface de usuário (UI) do Oracle Cloud Infrastructure (OCI).

  • USER_OCID

    O OCID do usuário que possui a instância do banco de dados autônomo. Você pode localizar o OCID na IU do OCI.

  • PRIVATE_KEY

    Caminho para a chave de formato PEM privado deste usuário.

  • LOCAL_ADB_OCID

    O OCID do Oracle Autonomous Database que está sendo inspecionado. Você pode encontrar o OCID na tela do Oracle Autonomous Database na Console do OCI.

  • WALLET_DIR

    O diretório da wallet local do Oracle Autonomous Database (descompacte a wallet baixada da Console do OCI). Esse diretório deve conter pelo menos os arquivos tnsnames.ora, keystore.jks e truststore.jks. Quando você usa a abordagem Standby Snapshot, esta é a pasta tnsadmin

  • ENC_WALLET_PASSWORD

    A encarnação WLS ENCRYPTED da senha fornecida quando o download da wallet foi feito na interface do usuário do OCI do Oracle Autonomous Database.

    Se a wallet for a inicial criada pelo WebLogic Server, pelo Oracle SOA Suite ou pelo Oracle Fusion Middleware durante o provisionamento do WebLogic Server, você poderá usar os seguintes comandos para obter a senha:

    Para WebLogic:
    [oracle@wsladbs2-wls-1 ~]$ python3 /opt/scripts/atp_db_util.py generate-atp-wallet-password
    Para SOA:
    [oracle@soarefr-soa-0 ~]$ python /opt/scripts/atp_db_util.py generate-atp-wallet-password
    Para criptografar a senha, seja a fornecida na Console do OCI ou a usada durante o provisionamento, você pode usar o script fmw_enc_pwd.sh.
    ./fmw_enc_pwd.sh UNENC_WALLET_PASSWORD

    Use a string obtida para a variável ENC_WALLET_PASSWORD.

  • FSS_MOUNT

    O diretório Montado do Armazenamento de Arquivos do OCI que será usado para preparar a configuração de domínio do WebLogic Server.

Depois de coletar as informações para as variáveis, execute as seguintes etapas para copiar e personalizar os scripts do seu ambiente:

  1. Criptografe a senha para acessar as wallets do Oracle Autonomous Database por motivos de segurança.
  2. Copie o script para o site principal e edite o script completando as variáveis necessárias para o site principal.
    Consulte acima a descrição das variáveis usadas no script.
  3. Copie o script para o site stand-by e edite o script preenchendo as variáveis necessárias para o site stand-by.
    Consulte acima a descrição das variáveis usadas no script.
  4. Uma vez personalizado para cada região (você deve fornecer o OCID do Banco de Dados LOCAL para cada região), execute as seguintes tarefas:
    1. Execute o script no host de Administração do Oracle WebLogic em principal.
    2. Execute o script no host de Administração do Oracle WebLogic na região secundária.
  5. Adicione o script a um job cron em cada região.