Implementar rsync com um Local de Preparação Central

Essa implementação usa a tecnologia rsync e segue o modelo com base em um local de preparação central. Neste modelo, há um nó bastion host que atua como um coordenador. Ele se conecta a cada host que precisa ser replicado e copia o conteúdo para um local de preparação comum.

As vantagens de implementar o rsync com um local de preparação central são:

  • É uma solução de uso geral aplicável a qualquer camada intermediária, portanto, se você tiver vários sistemas, poderá usar a mesma abordagem em todos eles.
  • Ele não depende do tipo de armazenamento subjacente; é válido para replicar artefatos de arquivo que residem em volumes em blocos, em NFS e assim por diante.
  • O armazenamento pode permanecer montado nos nós secundários. Portanto, não é necessário executar etapas adicionais para anexar ou montar o armazenamento no secundário em cada operação de switchover ou failover.
  • Em comparação com a implementação peer-to-peer, a manutenção é mais simples, já que há um nó central para executar os scripts.

As considerações para implementar o rsync com um local de estadiamento central são:

  • É responsabilidade do usuário criar os scripts personalizados para cada ambiente e executá-los periodicamente.
  • É responsabilidade do usuário implementar uma maneira de reverter a direção da réplica.
  • Este modelo requer um host e armazenamento adicionais para o local de preparação central.

Semelhante ao modelo peer-to-peer, os scripts rsync podem usar um modelo pull ou push. No modelo "pull", o script copia os arquivos do nó remoto para o nó local. No modelo "push", o script copia o arquivo do nó local para o nó remoto. A Oracle recomenda o uso de um modelo pull para recuperar o conteúdo dos hosts principais, porque ele descarrega os nós principais da sobrecarga das cópias.

Configurar Replicação para rsync com Tabela Intermediária Central

É necessário implementar o rsync com um local de preparação central:

  • Um bastion host com conectividade SSH para todos os hosts (principal e secundário).
  • Uma pasta de preparação no bastion host, com espaço suficiente para armazenar o conteúdo do sistema de arquivos de camada intermediária que é replicado.
  • Scripts que usam rsync para copiar os artefatos do arquivo de camada intermediária de e para essa pasta de preparação. Os scripts rsync podem ignorar determinadas pastas da cópia (como arquivos de bloqueio, logs, arquivos temporários etc.).
  • Uma forma de gerenciar as informações específicas do site, excluindo essas informações da cópia ou atualizando-as com as informações apropriadas após a réplica.
  • Programe esses scripts para serem executados periodicamente.
  • Um mecanismo para alterar a direção da réplica após um switchover ou failover. Esse mecanismo pode ser uma verificação dinâmica que identifica a função do site, ou uma alteração manual após um switchover ou failover (por exemplo, desabilitar e habilitar os scripts apropriados).
Este documento apresenta dois exemplos de implementação diferentes deste modelo:
  • Exemplo 1: Usar os scripts do Oracle Fusion Middleware Disaster Recovery Guide
  • Exemplo 2: Usar o framework WLS-HYDR
Exemplo 1: Usar os scripts do Oracle Fusion Middleware Disaster Recovery Guide

Observação:

Este exemplo se aplica a qualquer sistema de camada intermediária. Como referência, ele usa os scripts fornecidos pelo Oracle Fusion Middleware Disaster Recovery Guide para executar a réplica de camada intermediária de um sistema Oracle WebLogic DR: rsync_for_WLS.sh e rsync_copy_and_validate.sh. Mas esses scripts geralmente são aplicáveis e fornecem flexibilidade suficiente para sincronizar os artefatos do sistema de arquivos de camada intermediária na OCI.

O Oracle Fusion Middleware Disaster Recovery Guide fornece scripts rsync para executar cópias remotas em um sistema de camada intermediária. Esses scripts são válidos para qualquer modelo rsync. Este exemplo específico mostra como usá-los para o modelo de preparação central. Esta implementação usa operações pull em duas etapas:

  • Um bastion host extrai o conteúdo de todos os hosts principais e os armazena na preparação central.
  • Em seguida, todos os nós secundários executam uma operação de extração para reunir o conteúdo da preparação central.

Para configurar a replicação de camada intermediária com esses scripts, consulte Replicating the Primary File Systems to the Secondary Site no Oracle Fusion Middleware Disaster Recovery Guide, e a seção Rsync Replication Approach e, em particular, as etapas Using a Staging Location.


Veja a seguir a descrição da réplica-rsync-scripts.png
Descrição da ilustração replica-rsync-scripts.png

replica-rsync-scripts-oracle.zip

Exemplo 2: Usar o framework WLS-HYDR

Observação:

Este exemplo se aplica a um sistema Oracle WebLogic Server. Ele usa o módulo de replicação da estrutura WLS-HYDR, mas se aplica a qualquer ambiente de DR do Oracle WebLogic Server, independentemente de ter sido criado com a estrutura WLS-HYDR ou não.

Neste modelo, um nó de host central atua como um coordenador total, executando operações de pull e push. Ele se conecta a cada host que precisa ser replicado e copia o conteúdo para um local de preparação comum. Este nó também coordena a cópia do local de preparação para os hosts de destino. Essa abordagem descarrega os nós individuais da sobrecarga das cópias.

A estrutura WLS-HYDR usa essa abordagem para a cópia inicial durante a configuração do DR. Em seguida, você pode reutilizar o módulo de replicação do framework para repetir o pull e push periodicamente. Consulte Explore Mais neste manual para obter links para a estrutura WLS-HYDR e outros recursos.

O nó bastion executa a réplica em duas etapas:

  • Uma operação de extração, na qual ela se conecta aos hosts principais e copia o conteúdo do sistema de arquivos para uma pasta de preparação no bastion host.
  • Uma operação push, na qual ele copia o conteúdo da pasta de preparação do bastion para todos os hosts secundários.

Um nó central executa todas as operações, de modo que a programação, os logs, a manutenção, etc., são centralizados nesse nó. Quando o sistema tem muitos nós, isso é mais eficiente em comparação com o modelo peer-to-peer ou o exemplo anterior.


Segue-se a descrição da réplica-wls-hydr-framework.png
Descrição da ilustração Replica-wls-hydr-framework.png

replica-wls-hydr-framework-oracle.zip

Se você usou a estrutura WLS-HYDR para criar o sistema secundário, o bastion host já estará preparado para executar a réplica. Caso contrário, você poderá configurá-lo neste momento. Siga estas etapas para configurar a réplica:

  1. Prepare o bastião.

    Se você usou a estrutura WLS-HYDR para criar o sistema secundário, o bastion host já estará preparado para executar a réplica. Caso contrário, verifique README no repositório GitHub da estrutura WLS-HYDR para preparar um bastion host.

  2. Verifique os arquivos de configuração WLS-HYDR.
    Certifique-se de que os arquivos de configuração WLS-HYDR (replication.properties, oci.env e prem.env) contenham as informações corretas para o sistema.
  3. Execute o módulo de replicação WLS-HYDR.
    Você pode usar o módulo de replicação da estrutura para sincronizar todos os itens (o domínio e os produtos do Oracle WebLogic Server) ou pode sincronizar esses itens de forma independente. Em todos os casos, a sincronização completa consiste em duas operações: uma operação de pull, para recuperar o conteúdo do primário e uma operação de push, para copiar o conteúdo para o secundário.

    Observação:

    Sempre execute a operação PULL antes do PUSH. Caso contrário, você não enviará a versão mais recente do conteúdo.
    1. Para sincronizar todo o conteúdo:
      • Para extrair todo o conteúdo dos hosts principais para a preparação do bastion host:
        WLS-HYDR_BASE/lib/DataReplication.py pull
      • Para enviar todo o conteúdo da preparação do bastion host para os hosts secundários:
        WLS-HYDR_BASE/lib/DataReplication.py push
    2. Para sincronizar somente artefatos de produtos:
      • Para extrair os produtos dos hosts principais para a preparação do bastion host: 
        WLS-HYDR_BASE/lib/DataReplication.py pull -d products
      • Para enviar os produtos da preparação do bastion host para os hosts secundários:
        WLS-HYDR_BASE/lib/DataReplication.py push -d products
    3. Para sincronizar somente a configuração (o domínio WebLogic).
      • Para recuperar a configuração dos hosts principais para a preparação do bastion host, execute esta operação de extração:
        WLS-HYDR_BASE/lib/DataReplication.py pull -d private_config
      • Para copiar a configuração do bastion host na área temporária para os hosts secundários, execute esta operação de push:
        WLS-HYDR_BASE/lib/DataReplication.py push -d private_config
    4. Para casos em que há uma pasta de configuração compartilhada (domínio compartilhado do Oracle WebLogic em um sistema de arquivos do OCI File Storage):
      • Para recuperar a configuração compartilhada dos hosts principais para a preparação do bastion host, execute esta operação de extração:
        WLS-HYDR_BASE/lib/DataReplication.py pull -d shared_config
      • Para copiar a configuração compartilhada do ambiente intermediário do bastion host para os hosts secundários, execute esta operação de push:
        WLS-HYDR_BASE/lib/DataReplication.py push -d shared_config
  4. Prepare-se para as substituições de string de conexão do banco de dados.
    As operações de pull e push WLS-HYDR regulares que copiam a configuração WebLogic ignoram o arquivo tnsnames.ora das cópias, para que você não precise atualizar o tnsnames.ora em cada replicação subsequente.

    No entanto, a abordagem é diferente quando o banco de dados é um Autonomous Database. Para estabelecer conexão com um banco de dados autônomo, a pasta de administração do TNS também contém um armazenamento de chaves e arquivos de armazenamento confiável, que são diferentes para os bancos de dados principal e stand-by.

    A tabela a seguir resume como você pode gerenciar as informações de conexão do banco de dados em cada cenário:
    Tipo de Banco de Dados Etapas de Download e Script de Substituição Utilização
    Oracle Base Database Service ou Oracle Exadata Database Service O script para gerenciar o tnsnames.ora está incluído no módulo de replicação de estrutura WLS-HYDR.

    Certifique-se de que a seção JDBC no arquivo replication.properties contenha os dados corretos.

    Essa operação é executada no bastion e executa a extração, a atualização e o envio do arquivo tnsnames.ora. Para executar a operação completa: WLS-HYDR/lib/DataReplication.py tnsnames

    Não é necessário executar a menos que você execute alterações no tnsnames.ora (por exemplo, adicionando um alias).

    Autonomous Database

    fmwadb_switch_db_conn.sh

    Vá para o repositório do Oracle MAA em GitHub https://github.com/oracle-samples/maa

    Faça download de todos os scripts no diretório app_dr_common.

    Faça download de todos os scripts no diretório fmw-wls-with-adb-dr.

    Copie para todos os hosts de camada intermediária. Os scripts fazem chamadas uns aos outros. Coloque todos os scripts de ambos os diretórios na mesma pasta.

    Este script deve ser executado em todos os hosts de camada intermediária stand-by. Ela deve ser executada antes de iniciar os servidores WebLogic no stand-by para uma operação de validação, switchover ou failover.

    Ele substitui a pasta de administração TNS usada por WebLogic pela pasta fornecida como entrada. Ele também atualiza as propriedades de senha da wallet nas origens de dados.

    Sintaxe para executar o script: 
    fmwadb_switch_db_conn.sh WALLET_DIR WALLET_PASSWORD
    Em que WALLET_DIR é uma pasta que contém os arquivos tnsnames.ora, keystore e truststore para estabelecer conexão com o banco de dados local. Certifique-se de que a pasta WALLET_DIR não seja substituída na réplica.

Validar Replicação para rsync com Tabela Intermediária Central

Em uma operação de switchover ou failover, as informações replicadas devem estar disponíveis e utilizáveis no site stand-by antes do início dos processos. Isso também é necessário quando você valida o sistema secundário (abrindo o banco de dados stand-by no modo snapshot).

Nesta implementação, o armazenamento está sempre disponível no site secundário. Não é necessário anexar ou montar nenhum volume. A única ação que você pode precisar é garantir que ele contenha a versão mais recente do conteúdo é a seguinte.

  1. Execute uma replicação.
    Execute os scripts para replicar a última versão do conteúdo.
  2. Desative as replicações programadas.
    Após a última réplica ser finalizada, desative todos os scripts de réplica. Caso contrário, pode interferir com o switchover, failover ou procedimento de validação. Você ativará os scripts novamente após a operação, na direção apropriada.
  3. Substitua as informações que são específicas do local nos hosts secundários de camada intermediária.
    Se os artefatos do sistema de arquivos que você está replicando contiverem informações específicas do site, certifique-se de que elas não sejam substituídas pela cópia ou sejam atualizadas após a réplica.

    Dica:

    Por exemplo, os scripts rsync do Oracle Fusion Middleware Disaster Recovery Guide e do módulo de replicação WLS-HYDR ignoram o arquivo tnsnames.ora da cópia, para que você não precise alterá-lo após cada replicação.

    Se o sistema usar o Oracle Autonomous Database, restaure a pasta da wallet necessária na secundária para estabelecer conexão com o banco de dados da região secundária. Você pode usar o script de substituição fmwadb_switch_db_conn.sh em todos os hosts de camada intermediária stand-by. Requer, como entradas, o caminho onde a wallet original secundária está localizada e a senha da wallet.

Em seguida, é possível executar etapas adicionais necessárias para validar o sistema.

Executar Replicação Contínua para rsync com Local de Preparação Central

Execute os scripts de replicação periodicamente para manter o domínio secundário em sincronia com o principal.

Siga estas recomendações para a replicação contínua ao usar esta implementação:

  • Use o SO crontab ou outra ferramenta de programação para executar OS scripts de replicação periodicamente. Por exemplo, ao usar os scripts rsync fornecidos pelo guia de recuperação de desastres, siga as etapas na seção Programando Replicação Contínua com Scripts Rsync do Oracle Fusion Middleware Disaster Recovery Guide. Consulte Explore Mais neste manual para obter links para esses e outros recursos. Para a frequência de replicação, siga as diretrizes descritas em Artefatos de Arquivo de Camada Intermediária anteriormente neste playbook.
  • Mantenha os processos de camada intermediária interrompidos no site stand-by. Se os servidores estiverem ativos no site stand-by enquanto as alterações forem replicadas, as alterações entrarão em vigor na próxima vez que forem iniciadas. Inicie-os apenas quando estiver validando o site stand-by ou durante os procedimentos de switchover ou failover.
  • Manter as informações específicas de cada site atualizadas. Por exemplo, se o sistema de arquivos contiver uma pasta com os artefatos para estabelecer conexão com um Autonomous Database, mantenha uma cópia de backup dessa pasta. Certifique-se de atualizar o backup da pasta da wallet quando executar uma atualização na wallet. Dessa forma, ele será restaurado corretamente em switchover e failovers subsequentes.
  • Após um switchover ou failover, reverta a direção da réplica. Isso depende da implementação específica. Isso pode ser feito usando uma verificação dinâmica que identifica quem é o site ativo, ou com uma alteração manual após um switchover ou failover, desativando e ativando os scripts apropriados.

    Dica:

    • Ao usar os scripts rsync fornecidos pelo Guia de DR (exemplo 1), certifique-se de criar os scripts equivalentes para executar a réplica na outra direção. No crontab ou na ferramenta agendada, habilite apenas os scripts apropriados para a função real.
    • Ao usar o WLS-HYDR (exemplo 2), altere a atribuição do principal no framework WLS-HYDR, para que as próximas replicações sigam em outra direção. Para isso, edite a WLS-HYRDR/lib/DataReplication.py e altere uma destas opções:
      if True:
       PRIMARY = PREM 
       STANDBY = OCI
      	 else:
	        PRIMARY = OCI
               STANDBY = PREM
      para o seguinte:
      if False:
	        PRIMARY = PREM
                STANDBY = OCI
       	else:
                PRIMARY = OCI
                STANDBY = PREM