1. Configurar uma solução de DR híbrida para o Oracle WebLogic Server
  2. Replicar os Artefatos do Sistema de Arquivos para o OCI

Replicar os Artefatos do Sistema de Arquivos para o OCI

As camadas intermediárias secundárias devem ter uma réplica dos artefatos usados pelo domínio do WebLogic Server em principal. Os artefatos podem ser estáticos ou dinâmicos, dependendo da frequência com que são modificados. Como parte da configuração do DR, uma replicação inicial dos artefatos deve ser feita. Essa réplica inicial é atualizada durante o ciclo de vida do sistema.

Sobre Artefatos

Determine o tipo de artefatos que você precisa replicar.

  • Artefatos estáticos: são arquivos e diretórios que não são alterados com frequência. Elas incluem:
    • Oracle Home: geralmente consiste em um Oracle home e em um Oracle WebLogic Server. O Oracle Fusion Middleware permite criar vários Servidores Gerenciados do Oracle WebLogic Server a partir de uma única instalação de arquivo binário. Você pode instalar arquivos binários em um único local em um armazenamento compartilhado e reutilizar essa instalação por servidores em diferentes nós. Para obter disponibilidade máxima, a Oracle recomenda o uso de instalações binárias redundantes.
    • Oracle Inventory: orainventory é uma pasta que contém uma lista dos Oracle Homes existentes e está localizada em uma pasta separada separada separada do Oracle Home. O arquivo /etc/oraInst.loc determina qual é o local do orainventory.
  • Artefatos dinâmicos: são arquivos que mudam com frequência. Esses artefatos incluem:
    • Home do domínio: Diretórios de domínio do Servidor de Administração e dos Servidores Gerenciados. Em uma topologia EDG, ASERVER_HOME está em um local compartilhado e MSERVER_HOME está em um local privado e cada servidor tem seu próprio MSERVER_HOME (embora possa ser armazenado em um NFS também).
    • Artefatos do aplicativo, como arquivos .ear ou .war.
    • Artefatos de banco de dados, como o repositório MDS e os esquemas de aplicação.
    • Armazenamentos persistentes, como provedores JMS e logs de transação. A Oracle recomenda armazenar esses artefatos no banco de dados. Essa é a abordagem recomendada na topologia do EDG e especialmente útil para ambientes de recuperação de desastres (DR), porque eles são replicados automaticamente no site stand-by por meio do Oracle Data Guard subjacente.
    • Planos de implantação, usados para atualizar adaptadores de tecnologia, como adaptadores de arquivo e JMS. Eles precisam ser salvos em um local acessível a todos os nós do cluster nos quais os artefatos estão sendo implantados.
    • Outros artefatos de runtime, como arquivos usados por adaptadores de arquivo, arquivos transferidos pelo MFT ou outros artefatos de runtime personalizados.

Todo o conteúdo que reside no banco de dados (como o repositório MDS, esquemas de aplicação, JMS e TLOGs e dados personalizados) é automaticamente replicado para o site secundário por meio do Oracle Data Guard.

Para replicar o conteúdo que reside no sistema de arquivos (como o Oracle Home e a configuração do Domínio WebLogic) em uma topologia de recuperação de desastres, você pode usar diferentes abordagens. Os mais comuns são replicação em nível de armazenamento, réplica baseada em rsync ou réplica baseada em DBFS.

O modelo de DR Híbrido, descrito aqui, é onde a instância principal está no local e a secundária está na OCI. A replicação do nível de armazenamento não está disponível no modelo de DR híbrido. Em vez disso, rsync é a abordagem recomendada para replicar os artefatos do principal para o stand-by. Você pode usar a réplica baseada no DBFS (Oracle Database File System) para replicar alguns artefatos; consulte os detalhes em Sobre o Oracle Database File System em Saiba Mais.

Identificar as Pastas e os Artefatos do Sistema de Arquivos

Identifique os volumes e pastas NFS usados pelos hosts WebLogic Server principais do ambiente principal e seu conteúdo.

As tabelas a seguir fornecem um exemplo dos artefatos principais do sistema de arquivos usados neste exemplo.

Volume do Sistema de Arquivos Host Pasta do Ponto de Montagem Comentários Tipo de Artefato
NFS VOLFMW1 /export/wls/products1 AFOST1 /u01/oracle/products Volume para os arquivos binários JDK e FMW. Estático
NFS VOLFMW2 /export/wls/products2 AFOST2 /u01/oracle/products Volume para os arquivos binários JDK e FMW. Estático
VOLADMIN DO NFS/export/wls/config AFOST1, AFOST2 /u01/oracle/config Volume para diretório de domínio do Servidor de Administração e outras configurações compartilhadas, como Planos de Implantação, aplicativos e áreas de armazenamento de chaves. Dinâmico
LOCAL* /u02/oracle/config AFOST1 /u02/oracle/config Volume para configuração privada em APPHOST1 Dinâmico
LOCAL* /u02/oracle/config AFOST2 /u02/oracle/config Volume para configuração privada em APPHOST2 Dinâmico
VOLRUNTIME NFS /export/wls/runtime AFOST1, AFOST2 /u01/oracle/runtime

Volume para conteúdo de runtime compartilhado, como arquivos usados por adaptadores de arquivo e outros artefatos de runtime.

Observação: é recomendável armazenar mensagens JMS e TLOGS no banco de dados, usando armazenamentos persistentes JDBC, em vez de nesta pasta.

Dinâmico

* Os volumes do sistema de arquivos local podem ser montagens privadas (não compartilhadas) no NFS, em vez de armazenamento local.

A tabela a seguir é um exemplo das variáveis EDG para locais de pastas.

Variáveis EDG Valor
ORACLE_BASE /u01/oracle/products
ORACLE_HOME /u01/oracle/products/fmw
JAVA_HOME /u01/oracle/products/jdk
SHARED_CONFIG_DIR /u01/oracle/config
APPLICATION_HOME /u01/oracle/config/applications/mydomain
DEPLOY_PLAN_HOME /u01/oracle/config/dp
KEYSTORE_HOME /u01/oracle/config/keystores
ASERVER_HOME /u01/oracle/config/domains/mydomain
PRIVATE_CONFIG_DIR /u02/oracle/config
MSERVER_HOME /u02/oracle/config/domains/mydomain
NM_HOME /u02/oracle/config/nodemanager
ORACLE_RUNTIME /u01/oracle/runtime

Verificar Conectividade entre os Hosts Principal e Standby

Os hosts principais do WebLogic Server devem estabelecer conexão com os hosts stand-by remotos do Oracle Cloud Infrastructure (OCI) WebLogic Server e vice-versa,

Os nomes físicos dos hosts remotos do Servidor WebLogic podem ser resolvidos no DNS ou você pode incluir os nomes físicos e IPs dos hosts remotos do Servidor WebLogic nos arquivos /etc/hosts. Ou seja, adicione os nomes físicos dos hosts secundários do Servidor WebLogic e seus IPs ao arquivo /etc/hosts dos hosts primários do Servidor WebLogic. Da mesma forma, adicione os nomes físicos dos hosts principais do Servidor WebLogic e seus IPs ao arquivo /etc/hosts dos hosts secundários do Servidor WebLogic.

Observação:

Se o principal não estiver usando nomes de host virtuais e usar os nomes de host de nó físico como endereços de listening dos servidores, não execute estas etapas. Como nesse cenário, os nomes de host do nó físico principal devem ser resolvidos pelos IPs dos hosts do WebLogic Server do OCI em standby. Nesse cenário, em vez de executar as etapas a seguir, use os IPs dos hosts para estabelecer conexão com o SSH para os nós remotos.
  1. Edite o arquivo /etc/hosts nos hosts locais principais do WebLogic Server para incluir os nomes físicos e endereços IP dos hosts remotos do WebLogic Server.
    Veja a seguir um exemplo dos aliases nos hosts locais.
    
#################################
# ALIASES in on-prem
#################################
10.10.10.20   host-vip1.myopnetwork.com    host-vip1          ADMINVHN.example.com   ADMINVHN 
10.10.10.13   host3.myopnnetwork.com       host3              APPHOST1.example.com    APPHOST1
10.10.10.14   host4.myopnnetwork.com       host4              APPHOST2.example.com    APPHOST2
# Front-end name (resolved but primary Load Balancer IP
10.10.10.100    wlsfrontend.example.com
# Remote OCI wls hosts physical names (without virtual host name aliases!)
100.70.10.13    hydrwls1.midTiersubnet.hydrvcn.oraclevcn.com      hydrwls1        
100.70.10.14   hydrwls2.midTiersubnet.hydrvcn.oraclevcn.com       hydrwls2
  2. Edite o arquivo /etc/hosts nos hosts stand-by do WebLogic Server do OCI para incluir os nomes físicos dos hosts remotos e locais do WebLogic Server. Não inclua os aliases de nome de host virtual.
    Veja a seguir um exemplo dos aliases nos hosts do WebLogic Server do OCI stand-by. 
    #################################
# ALIASES in OCI
#################################
100.70.10.20   hydrwls-vip.midTiersubnet.hydrvcn.oraclevcn.com   hydrwls-vip    ADMINVHN.example.com    ADMINVHN
100.70.10.13   hydrwls1.midtiersubnet.hydrvcn.oraclevcn.com      hydrwls1       APPHOST1.example.com    APPHOST1
100.70.10.14   hydrwls2.midtiersubnet.hydrvcn.oraclevcn.com      hydrwls2       APPHOST2.example.com    APPHOST2
# Front-end name (resolved by secondary OCI LBR IP)
1070.70.70    wlsfrontend.example.com
# Remote on-prem wls hosts physical names (without virtual host name aliases!)
10.10.10.13   host3.myopnnetwork.com       host3
10.10.10.14   host4.myopnnetwork.com       host4
  3. Use o comando SSH para verificar a conectividade cruzada dos hosts principais do Servidor WebLogic local para os hosts secundários do Servidor WebLogic do OCI.
    Uma chave ssh é necessária ao estabelecer conexão com instâncias de computação do OCI.
    ssh -i my_private_key oracle@hydrwls1.midtiersubnet.hydrvcn.oraclevcn.com
ssh -i my_private_key oracle@hydrwls2.midtiersubnet.hydrvcn.oraclevcn.com
  4. Use o comando SSH para verificar a conectividade cruzada entre os hosts secundários do OCI WebLogic Server e os hosts principais do WebLogic Server local.
    Uma chave ssh pode não ser necessária.
    ssh  oracle@host3.myopnnetwork.com
ssh  oracle@host4.myopnnetwork.com

Duplicar a Estrutura de Pastas nos Hosts Secundários do OCI

Nesse ponto, as instâncias de computação do Oracle Cloud Infrastructure (OCI) WebLogic Server já têm o FSS montado. Antes de replicar o conteúdo, crie a estrutura de pastas apropriada para o EDG.

O exemplo a seguir mostra os comandos para criar a estrutura de pastas EDG que é usada pelo ambiente EDG deste documento.
  1. Como usuário oracle, crie as pastas no OCI APPHOST1.
    mkdir -p  /u01/oracle/products/fmw
mkdir -p  /u01/oracle/products/jdk
mkdir -p  /u01/oracle/products/oraInventory
mkdir -p /u02/oracle/config
mkdir -p /u01/oracle/config/domains/mydomain
mkdir -p /u01/oracle/config/applications/mydomain
mkdir -p /u01/oracle/config/dp/mydomain
mkdir -p /u01/oracle/config/keystores
  2. Como usuário oracle, crie as pastas no OCI APPHOST2.
    mkdir -p  /u01/oracle/products/fmw
mkdir -p  /u01/oracle/products/jdk
mkdir -p  /u01/oracle/products/oraInventory
mkdir -p /u02/oracle/config

Copie ORACLE_HOME e JAVA_HOME para os Hosts Secundários

Copie ORACLE_HOME e JAVA_HOME dos hosts principais para os hosts secundários.

ORACLE_HOME e JAVA_HOME normalmente estão na mesma pasta de produtos, juntamente com oraInventory. Consulte Identificar as Pastas e os Artefatos do Sistema de Arquivos para obter os locais identificados anteriormente.

  1. Copie a pasta de produtos do APPHOST1 principal local para o APPHOST1 remoto.
  2. Copie a pasta home de produtos do APPHOST2 principal local e salve-a no APPHOST2 remoto. Repita para qualquer outra instância de computação.
  3. Copie o arquivo /etc/oraInst.loc dos hosts principais e salve-o nos hosts secundários.
    Esse arquivo simplesmente contém a localização de oraInventory e não é alterado com o passar do tempo, portanto, essa cópia é uma ação única.

    No exemplo fornecido, oraInventory está em /u01/oracle/products e é copiado junto com o jdk e o Oracle home. Se o seu oraInventory estiver em um local diferente, certifique-se de também copiá-lo para os hosts secundários.

    Observação:

    Você pode encontrar um exemplo de script que usa rsync para copiar a pasta de produtos do APPHOST1 principal local para o APPHOST1 remoto em Fazer Download do Código. Repita o mesmo para copiar o home dos produtos para o restante das instâncias de computação secundárias (ou seja, de APPHOST2 para APPHOST2 remoto).

Copiar as Pastas de Configuração de Domínio WebLogic para os Hosts Standby

Copie a pasta de configuração compartilhada do Domínio WebLogic e a pasta de configuração privada para os hosts do Servidor Oracle Cloud Infrastructure (OCI) WebLogic.

  1. Copie a pasta de configuração compartilhada do Domínio WebLogic do APPHOST1 principal local para o APPHOST1 remoto do OCI.
    A configuração compartilhada do Domínio WebLogic reside no local projetado pela variável SHARED_CONFIG_DIR e inclui as pastas de configuração compartilhadas, como APPLICATION_HOME, DEPLOY_PLAN_HOME, KEYSTORE_HOME e ASERVER_HOME.

    Observação:

    Você pode copiar a pasta de configuração compartilhada do APPHOST1 principal local para o APPHOST1 remoto. Esta é uma pasta compartilhada. Portanto, você só precisa copiá-la para um dos hosts do WebLogic Server do OCI.

    Um exemplo de script está disponível em Fazer Download do Código.

  2. Copie a pasta de configuração privada do Domínio WebLogic do APPHOST1 principal local e salve-a no OCI remoto APPHOST1
    A configuração privada WebLogic reside no local especificado pela variável PRIVATE_CONFIG_DIR e contém as pastas MSERVER_HOME e NM_HOME. Essas pastas não são compartilhadas, são específicas (privadas) para cada host do WebLogic Server. Portanto, você deve executar a cópia para cada servidor - copie a configuração privada de APPHOST1 local para APPHOST1 do OCI, a configuração privada do APPHOST2 local para o APPHOST2 do OCI e assim por diante.

    Observação:

    Em Fazer Download do Código, você pode encontrar um exemplo de script que usa rsync para copiar a pasta de configuração privada do APPHOST1 principal local para o APPHOST1 remoto.

Copiar a Pasta de Runtime Compartilhada

Copie a pasta de runtime compartilhada para os hosts do Oracle Cloud Infrastructure (OCI) WebLogic Server, se necessário.

A pasta de runtime compartilhada reside no local especificado pela variável ORACLE_RUNTIME. Consulte Identificar as Pastas e os Artefatos do Sistema de Arquivos para obter os locais identificados anteriormente.

Observação:

É recomendável armazenar os armazenamentos persistentes JMS e TLOGS no banco de dados, usando armazenamentos persistentes JDBC. Como eles estão no banco de dados, eles são replicados automaticamente para o sistema secundário com o Oracle Data Guard.
  • Como essas informações são de tempo de execução, normalmente você não precisa replicá-las durante a fase de configuração. No entanto, se você precisar replicar essa pasta para os hosts stand-by, poderá copiar o conteúdo seguindo uma abordagem semelhante que você usou para copiar o arquivo de configuração compartilhado do Domínio WebLogic.