Replicar os Artefatos do Sistema de Arquivos ao OCI

As camadas intermediárias secundárias devem ter uma réplica dos artefatos usados pelo domínio SOA 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 artefato 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 um home do Oracle WebLogic Server. O Oracle Fusion Middleware permite que você crie vários Servidores Gerenciados do Oracle WebLogic Server a partir de uma única instalação de arquivo binário. É possível 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: O orainventory é uma pasta que contém uma lista dos Oracle Homes existentes e está localizada em uma pasta separada separada do Oracle Home. O arquivo /etc/oraInst.loc determina qual é a localização do orainventory.
  • Artefatos dinâmicos: são arquivos que mudam com frequência. Esses artefatos incluem:
    • Home de domínio: diretórios de domínio do Servidor de Administração e dos Servidores Gerenciados. Em uma topologia EDG, o ASERVER_HOME está em um local compartilhado e o 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 SOAINFRA.
    • 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 EDG e especialmente útil para ambientes de recuperação de desastres (DR), porque eles são replicados automaticamente para o 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 para todos os nós do cluster em que 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 SOAINFRA, 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 SOA 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 de ponto de montagem Comentários Tipo de Artefato
NFS VOLFMW1 /export/soa/products1 SOAHOST1 /u01/oracle/products Volume para os arquivos binários JDK e FMW. Estático
NFS VOLFMW2 /export/soa/products2 SOAHOST2 /u01/oracle/products Volume para os arquivos binários JDK e FMW. Estático
VOLADMIN DO NFS/export/soa/config SOAHOST1, SOAHOST2 /u01/oracle/config Volume do diretório de domínio do Servidor de Administração e outras configurações compartilhadas, como Planos de Implantação, aplicativos e armazenamentos de chaves. Dinâmico
LOCAL* /u02/oracle/config SOAHOST1 /u02/oracle/config Volume para configuração privada em SOAHOST1 Dinâmico
LOCAL* /u02/oracle/config SOAHOST2 /u02/oracle/config Volume para configuração privada em SOAHOST2 Dinâmico
VOLRUNTIME NFS /export/soa/runtime SOAHOST1, SOAHOST2 /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 no armazenamento local.

A tabela a seguir é um exemplo das variáveis EDG para locais da pasta.

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/mysoadomain
DEPLOY_PLAN_HOME /u01/oracle/config/dp
KEYSTORE_HOME /u01/oracle/config/keystores
ASERVER_HOME /u01/oracle/config/domains/mysoadomain
PRIVATE_CONFIG_DIR /u02/oracle/config
MSERVER_HOME /u02/oracle/config/domains/mysoadomain
NM_HOME /u02/oracle/config/nodemanager
ORACLE_RUNTIME /u01/oracle/runtime

Verificar Conectividade entre os Hosts Principal e Standby

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

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

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 SOA 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 principais hosts SOA locais para incluir os nomes físicos e endereços IP dos hosts SOA de par remoto.
    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              SOAHOST1.example.com    SOAHOST1
    10.10.10.14   host4.myopnnetwork.com       host4              SOAHOST2.example.com    SOAHOST2
    # Front-end name (resolved but primary Load Balancer IP
    10.10.10.100    mysoa.example.com
    # Remote OCI soa hosts physical names (without virtual host name aliases!)
    100.70.10.13    hydrsoa1.midTiersubnet.hydrvcn.oraclevcn.com      hydrsoa1        
    100.70.10.14   hydrsoa2.midTiersubnet.hydrvcn.oraclevcn.com       hydrsoa2
  2. Edite o arquivo /etc/hosts nos hosts stand-by do OCI SOA para incluir os nomes físicos dos hosts SOA remotos locais. Não inclua os aliases de nome de host virtual.
    Veja a seguir um exemplo dos aliases nos hosts SOA do OCI stand-by.
    #################################
    # ALIASES in OCI
    #################################
    100.70.10.20   hydrsoa-vip.midTiersubnet.hydrvcn.oraclevcn.com   hydrsoa-vip    ADMINVHN.example.com    ADMINVHN
    100.70.10.13   hydrsoa1.midtiersubnet.hydrvcn.oraclevcn.com      hydrsoa1       SOAHOST1.example.com    SOAHOST1
    100.70.10.14   hydrsoa2.midtiersubnet.hydrvcn.oraclevcn.com      hydrsoa2       SOAHOST2.example.com    SOAHOST2
    # Front-end name (resolved by secondary OCI LBR IP)
    1070.70.70    mysoa.example.com
    # Remote on-prem soa 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 locais do SOA com os hosts secundários do OCI SOA.
    Uma chave ssh é necessária ao estabelecer conexão com instâncias de computação do OCI.
    ssh -i my_private_key oracle@hydrsoa1.midtiersubnet.hydrvcn.oraclevcn.com
    ssh -i my_private_key oracle@hydrsoa2.midtiersubnet.hydrvcn.oraclevcn.com
  4. Use o comando SSH para verificar a conectividade cruzada entre os hosts SOA secundários do OCI e os hosts SOA principais locais.
    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 SOA (OCI) do Oracle Cloud Infrastructure 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 do EDG usada pelo ambiente EDG deste documento.
  1. Como usuário oracle, crie as pastas no SOAHOST1 do OCI.
    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/mysoadomain
    mkdir -p /u01/oracle/config/applications/mysoadomain
    mkdir -p /u01/oracle/config/dp/mysoadomain
    mkdir -p /u01/oracle/config/keystores
  2. Como usuário oracle, crie as pastas no OCI SOAHOST2.
    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 SOAHOST1 principal local para o SOAHOST1 remoto.
  2. Copie a pasta home de produtos do SOAHOST2 principal local e salve-a no SOAHOST2 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 contém apenas o local oraInventory e não muda com o 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 copiá-lo também para os hosts secundários.

    Observação:

    Você pode encontrar um exemplo de script que usa rsync para copiar a pasta de produtos do SOAHOST1 principal local para o SOAHOST1 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 SOAHOST2 para SOAHOST2 remoto).

Copie as Pastas de Configuração do Domínio WebLogic para os Hosts Stand-by

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

  1. Copie a pasta de configuração compartilhada do Domínio WebLogic do SOAHOST1 principal local para o SOAHOST1 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 SOAHOST1 principal local para o SOAHOST1 remoto. Esta é uma pasta compartilhada. Portanto, você só precisa copiá-la para um dos hosts SOA 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 SOAHOST1 principal local e salve-a no SOAHOST1 remoto do OCI
    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 SOA. Portanto, você deve executar a cópia para cada servidor - copie a configuração privada do SOAHOST1 local para o SOAHOST1 do OCI, a configuração privada do SOAHOST2 local para o SOAHOST2 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 SOAHOST1 principal local para o SOAHOST1 remoto.

Copiar a Pasta de Runtime Compartilhada

Copie a pasta de runtime compartilhada para os hosts do SOA (OCI) do Oracle Cloud Infrastructure, 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 os armazenamentos TLOGS no banco de dados, usando armazenamentos persistentes JDBC. Como 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.