Implementar a Replicação do OCI Block Volumes

Essa implementação usa o recurso de replicação entre regiões do OCI Block Volumes para replicar os volumes em blocos.

Estas são as vantagens de implementar a replicação do OCI Block Volumes:

• Não há necessidade de criar e executar scripts periodicamente, como em outros casos de replicação. Depois que você configurar a replicação, ela será executada automaticamente pelo Oracle Cloud Infrastructure.
• É uma solução de uso geral aplicável a qualquer volume em blocos de qualquer instância de computação (exceto para os volumes de inicialização). Se você tiver vários sistemas, poderá usar a mesma abordagem em todos eles.
• As informações sobre os volumes em blocos replicados são uma cópia exata dos volumes em blocos primários; todos os arquivos no volume em blocos são replicados.

Considere o seguinte antes de usar a replicação do OCI Block Volumes:

• Requer etapas para montar os volumes em blocos replicados no sistema secundário. Não é possível montar diretamente a réplica dos volumes em blocos; primeiro você precisa ativá-los para criar volumes em blocos clonados, que podem ser montados. Isto não é complexo em sistemas com poucos nós, mas a complexidade aumenta quando há muitos nós. E especialmente em sistemas que não têm a mesma distribuição de nós nos domínios de disponibilidade do principal e do stand-by.

  No entanto, você pode superar essa complexidade usando o serviço Oracle Cloud Infrastructure Full Stack Disaster Recovery para automatizar essas etapas nas operações de switchover, failover e validação.

• Esta tecnologia pode não ser suficiente para muitos sistemas. Se o sistema tiver mais tipos de armazenamento (por exemplo, sistemas de arquivos compartilhados do OCI File Storage), você precisará usar outra tecnologia de réplica para eles.

Configurar Replicação para OCI Block Volumes

Para implementar a replicação do OCI Block Volumes, são necessárias as seguintes etapas:

• Use a Console do OCI para definir os Grupos de Volumes na região principal, agrupando os volumes em blocos que você precisa replicar.

  Um grupo de volumes só pode conter volumes em blocos que estão no mesmo domínio de disponibilidade (AD), e todos os volumes em blocos do grupo são replicados para apenas um AD de destino. Se seus volumes em blocos estiverem localizados em mais de um AD, crie um Grupo de Volumes em Blocos para cada combinação de ADs de origem e de destino.

• Ative a réplica nos Grupos de Volumes para os ADs apropriados da região secundária.
• Conecte-se aos hosts de camada intermediária no sistema secundário e desmonte os volumes em blocos que serão replicados do principal.
• Use a Console do OCI para desanexar e descartar todos os volumes em blocos que serão replicados do sistema principal. Eles não serão mais usados.
• Implemente uma maneira de gerenciar as informações específicas do site que residem nos volumes em blocos, atualizando-as com as informações apropriadas após a réplica.

Essa implementação se aplica a qualquer volume em blocos, exceto volumes de inicialização. A replicação de volume de inicialização tem outras implicações e está fora do escopo desta implementação.

Exemplo 1: Usar a replicação do OCI Block Volumes para replicar o volume em blocos de configuração de camada intermediária

Observação:

Este exemplo se aplica a qualquer sistema de camada intermediária. Como referência, ele explica como replicar os volumes em blocos que contêm a configuração do Oracle WebLogic de uma pilha do Oracle WebLogic Server for OCI. Mas você pode seguir as mesmas etapas para replicar outros volumes em blocos em um sistema de camada intermediária, exceto os volumes de inicialização.

A imagem a seguir é um exemplo de um sistema Oracle WebLogic Server com réplica de região cruzada do OCI Block Volumes.

Descrição da ilustração wls-bv-cross-replica.png

wls-bv-cross-replica-oracle.zip

Para configurar a réplica entre regiões para os volumes em blocos, siga estas etapas:

1. Faça backup das informações específicas de cada site.

   O volume em blocos pode conter arquivos com informações específicas de cada site, por exemplo, strings de conexão com bancos de dados ou servidores LDAP.

   Ao usar a réplica de volume em blocos, os volumes em blocos replicados são uma cópia exata dos volumes em blocos principais; você não pode ignorar arquivos ou pastas específicos da réplica. Assim, você deve gerenciar essas diferenças adaptando as informações em cada site. Existem várias abordagens:

   • É possível realizar uma pesquisa e substituição de string nos arquivos com informações específicas do local.
   • Você pode fazer backup dessas informações antes da réplica e restaurá-las depois.

   Neste ponto, antes de ativar a réplica, identifique e faça backup de qualquer arquivo com informações específicas do site que reside nos volumes em blocos que são replicados. Faça a cópia de backup em um local que não esteja sob o volume em blocos replicado; caso contrário, ela será substituída.

   Dica:

   Exemplo de Oracle WebLogic Server

   Por exemplo, ao replicar volumes em blocos que contêm um domínio WebLogic, há arquivos com informações para estabelecer conexão com o banco de dados. Essas informações estão na pasta de administração do TNS. Verifique a propriedade tns_admin nas origens de dados WebLogic para identificar a pasta. Este documento fornece scripts para gerenciar isso, seguindo a abordagem apropriada, dependendo do cenário:

   • Se o sistema se conectar a um Oracle Base Database Service ou Oracle Exadata Database Service, você poderá apenas atualizar a string de conexão do banco de dados no arquivo tnsnames.ora do sistema de camada intermediária secundário durante as operações de switchover e failover. Este documento fornece um script de exemplo para isso.
   • Se o sistema se conectar a um Oracle Autonomous Database, a pasta de administração do TNS conterá mais artefatos (um armazenamento confiável e um armazenamento de chaves). Eles são diferentes em principal e em espera, e não podem ser atualizados com uma simples substituição de string. Este documento fornece um script que restaura a cópia de backup da pasta TNS.

   Neste ponto, você só precisa executar um backup das informações da pasta TNS.

2. Identifique os Volumes em Blocos dos principais hosts de camada intermediária.
   1. Vá para a Console do OCI, selecione sua região Principal e escolha seu compartimento.
   2. Navegue até Armazenamento e, em seguida, Volumes em Blocos. Identifique os volumes em blocos e os pontos de montagem.
   3. Anote os nomes, o AD em que estão localizados, o host ao qual estão anexados e o ponto de montagem.

   Dica:

   Exemplo do Oracle WebLogic

   Por exemplo, os volumes em blocos que contêm o domínio WebLogic no Oracle WebLogic Server para OCI e as pilhas do Oracle SOA Suite on Marketplace são os volumes em blocos de dados. Seus nomes são: prefix-data-block-N (em que N é o número do nó do host) e são montados em /u01/data em cada host.

   Volume em Blocos no Principal	AD	Host	Ponto de Montagem
   prefix-data-block-0	AD1	prefix-wls-0	/u01/data
   prefix-data-block-1	AD2	prefix-wls-1	/u01/data

   Você pode ter volumes em blocos adicionais para armazenar os homes do produto Oracle. Por exemplo, em uma pilha do Oracle WebLogic Server para OCI, os cálculos também têm os volumes em blocos prefix-mw-block-N, montados em /u01/app.

   Se você criar o secundário com a estrutura WLS-HYDR para uma pilha primária, ele terá dois sistemas de arquivos redundantes do OCI File Storage para armazenar os produtos Oracle em vez de volumes em blocos. Portanto, para produtos, o principal usa volumes em blocos e o OCI File Storage secundário. Se desejar, você também pode configurar a replicação contínua para os Volumes em Blocos "mw". Basta configurar a réplica do serviço Block Volume para eles no principal e descartar os sistemas de arquivos do OCI File Storage do produto do secundário. No entanto, como esses itens contêm os homes de produtos Oracle, não é obrigatório replicar esses itens continuamente. Consulte "Artefatos de Arquivo de Nível Médio" para obter mais informações.

3. Identifique os Volumes em Blocos nos hosts secundários de camada intermediária.
   Repita as etapas descritas na etapa anterior para obter os nomes e os Domínios de Disponibilidade (ADs) dos volumes em blocos dos hosts de camada intermediária secundários.

   Dica:

   Exemplo do Oracle WebLogic

   Se você criar o sistema secundário com a estrutura WLS-HYDR, os hosts e os nomes de volume em blocos poderão ter uma numeração de sufixo diferente da principal. As pilhas de marketplace usam sufixos 0,1,2,3, enquanto um sistema criado com a estrutura WLS-HYDR usa sufixos 1,2,3,4. Certifique-se de identificar corretamente os nós e volumes pares. Por exemplo:

   Volume em Blocos em Secundário	AD	Host	Ponto de Montagem
   prefixBV1	AD1	prefixhost-1	/u01/data
   prefixBV2	AD2	prefixhost-2	/u01/data

4. Crie Grupos de Volumes em Blocos no principal e ative a réplica entre regiões.
   Crie Grupos de Volumes em Blocos no principal para agrupar todos os volumes em blocos que serão replicados de um AD específico para um AD específico no secundário. A réplica é ativada no nível do Grupo de Volumes; portanto, se aplica a todos os Volumes em Blocos desse grupo. Um grupo de volumes só pode conter volumes em blocos que estão no mesmo AD, e todos os volumes em blocos do grupo são replicados apenas para um AD de destino. Portanto, se suas instâncias de computação estiverem localizadas em mais de um AD, crie um Grupo de Volumes em Blocos para cada combinação de ADs de origem e de destino.

   Execute as seguintes etapas para criar um Grupo de Volumes em Blocos e ativar a réplica entre regiões:

   1. Faça log-on na Console do OCI na região principal.
   2. Navegue até Armazenamento, em seguida, Grupos de Volumes.
   3. Crie um grupo de volumes em blocos.
      Por exemplo: prefix-BVGroup-region1AD1-region2AD1
   4. Adicione os volumes em blocos que você replicará dentro do grupo de volumes.

      Observação:

      Não adicione Volumes de Inicialização. Eles não são replicados.
   5. Ativar replicação entre regiões no grupo Volumes.
      • Região de destino: Selecione a região secundária.
      • Domínio de disponibilidade: selecione o AD na região secundária em que os computadores que montarão os volumes replicados estão localizados.
      • Nome da Réplica do Grupo de Volumes: Informe o nome do grupo de Volumes em Blocos da réplica. Para fins de clareza, use o mesmo grupo de Volumes em Blocos que no principal.
   6. Salve as alterações.
5. Verifique se as réplicas são criadas na região secundária.
   1. Na Console do OCI, selecione a região secundária.
   2. Navegue até Armazenamento, clique em Armazenamento em Blocos e, em seguida, em Réplicas do Grupo de Volumes.
6. Repita as etapas para criar Grupos de Volumes em Blocos adicionais se suas instâncias de computação principais residirem em mais de um AD.

   Dica:

   Exemplos do Oracle WebLogic

   Quando o primário é uma pilha do Marketplace e o secundário é criado com WLS-HYDR:

   Em pilhas do Oracle WebLogic Server para OCI e do Oracle SOA Suite on Marketplace: se a região tiver vários domínios de disponibilidade (3), ela distribuirá as instâncias de computação entre elas. Por exemplo, nó0 em AD1, node1 em AD2, node2 em AD3, node3 em AD1.

   Em um sistema criado pelo WLS-HYDR: se a região tiver vários domínios de disponibilidade (3), o usuário poderá optar por distribuir as instâncias de computação entre elas ou não. Em caso afirmativo, ele distribui as instâncias de computação entre 2 ADs. Por exemplo, node1 em AD1, node2 em AD2, node3 em AD1, node4 em AD2.

   Defina os grupos BV adequadamente para agrupar volumes em blocos que são replicados para o mesmo AD no destino. Um grupo de volumes só pode conter volumes em blocos que estejam no mesmo AD, e todos os volumes em blocos do grupo só podem ser replicados para um AD de destino. Se houver misturas (OCI Block Volumes no mesmo AD de origem, mas outro AD de destino e vice-versa), crie quantos Grupos de Volumes em Blocos forem necessários para gerenciar todas as combinações de réplicas. Veja alguns exemplos de cenários:

   • Exemplo 2, Dois nós, somente 1 AD em primário e secundário
     • região principal: node0 no AD1, node1 no AD1
     • região secundária: node1 no AD1, node2 no AD1

     Solução:

     1 Grupo de Volumes no primário, replicando para 1 Grupo de Volumes no secundário

   • Exemplo 3, Dois nós, mais de 1 AD em primário e secundário
     • Na região principal: node0 na AD1, node1 na AD2
     • Na região secundária: node1 no AD1, node2 no AD2

     Solução:

     O principal terá estes grupos de volumes:

     • volume-group-AD1 (com o BV de node0) replicado para AD1 secundário (para node1 secundário)
     • volume-group-AD2 (com o BV de node1) replicado para AD2 secundário (para node2 secundário)
   • Exemplo 4, Seis nós, mais de 1 AD em primário e secundário
     • Na região principal: node0 in AD1, node1 in AD2, node2 in AD3, node3 in AD1, node4 in AD2, node5 in AD3
     • Na região secundária: node1 in AD1, node2 in AD2, node3 in AD1, node4 in AD2, node5 in AD1, node6 in AD2

     Solução:

     O principal precisa de vários grupos de volumes: (o mesmo, por outro lado, após um switchover)

     • volume-group-reg1AD1-reg2AD1 com o BV de node0 replicado para AD1 secundário (para node1 secundário)
     • volume-group-reg1AD2-reg2AD2 com o BV de node1 replicado para AD2 secundário (para node2 secundário)
     • volume-group-reg1AD3-reg2AD1 com o BV de node2 replicado para AD1 secundário (para node3 secundário)
     • volume-group-reg1AD1-reg2AD2 com o BV de node3 replicado para AD2 secundário (para node4 secundário)
     • volume-group-reg1AD2-reg2AD1 com o BV de node4 replicado para AD1 secundário (para node5 secundário)
     • volume-group-reg1AD3-reg2AD2 com o BV de node5 replicado para AD2 secundário (para node6 secundário)
7. Desanexe os Volumes em Blocos originais dos hosts secundários de camada intermediária.

   Observação:

   Os Volumes de Inicialização NÃO devem ser desmontados ou desanexados.

   Execute o seguinte para cada host de camada intermediária no secundário:
   1. Desmonte o volume em blocos de dados que é replicado do principal.
      Verificar se nenhum processo oracle está em execução; caso contrário, a desmontagem falhará.
      Por exemplo,

      [opc@host ~]$ sudo umount /u01/data

   2. Como usuário do root, edite o arquivo /etc/fstab e remova a entrada do volume em blocos desmontado.
      Isso o impede de tentar montar os volumes em blocos originais na próxima reinicialização. Exemplo de entrada para o volume montado em /u01/data:

      ..
      #Remove this entry:
      #UUID=9e87cf72-a75c-4dff-9825-432f1668d8f9 /u01/data ext4 auto,defaults,_netdev,nofail 0 2

   3. Desanexe o volume em blocos da Console do OCI.
      Vá para cada Block Volume, Instâncias Anexadas e Desanexar da Instância. A Console do OCI solicitará que você execute alguns comandos ISCSI antes de concluir a desanexação.
   4. Repita essas etapas em todos os nós de camada intermediária no secundário.
8. Exclua ou renomeie o OCI Block Volumes desanexado no secundário.
   Os volumes de bloco de dados originais desanexados dos hosts de camada intermediária secundários não são mais usados. Você pode excluí-los agora ou renomeá-los e excluí-los posteriormente.
9. Reinicie o daemon systemd nos hosts secundários de camada intermediária.
   Para atualizar as referências armazenadas em cache para os dispositivos montados anteriormente, execute este comando:

   sudo systemctl daemon-reload

10. Se necessário, prepare os scripts para substituir as informações específicas de cada local.

    Esta ação se aplica somente quando os Volumes em Blocos contêm informações específicas de cada site. Caso contrário, nenhuma ação será necessária.

    Crie scripts para substituir as informações do local, de acordo com seus requisitos específicos. Por exemplo, realizar uma pesquisa e substituir, ou restaurar uma cópia de backup dos dados específicos do site. Certifique-se de armazenar esses scripts em uma pasta que NÃO esteja replicada.

    Não execute os scripts neste momento. Você usará os scripts da próxima vez que executar uma validação, um switchover ou um failover.

    Dica:

    Exemplo do Oracle WebLogic

    Por exemplo, quando você replica Volumes em Blocos que contêm um domínio WebLogic. Durante um switchover ou failover, você precisa executar uma substituição na configuração para apontar para o banco de dados local. Este documento fornece exemplos de scripts para automatizar essa substituição.

    Tipo de Banco de Dados	Etapas de Download e Script de Substituição	Preparar Etapas
    Oracle Base Database Service ou Oracle Exadata Database Service	replacement_script_BVmodel.sh Vá para o repositório MAA em GitHub https://github.com/oracle-samples/maa Faça download de todos os scripts no diretório wls_mp_dr. O script está localizado na pasta wls_mp_dr/Block_Volume_Replica_Method Copie para todos os hosts de camada intermediária.	Este script substitui as strings de conexão do banco de dados. Ele também limpa os arquivos de estado dos servidores WebLogic (.lck e .state) para uma inicialização limpa. Edite e personalize-o em cada host com os valores apropriados, fornecendo os valores locais e remotos para o banco de dados em cada site. Observe que os valores são diferentes dependendo do site. Quando você o personaliza nos hosts site1, os valores "LOCAL" se referem aos valores do site1 e os valores "REMOTE" se referem aos valores do site2. Quando você personaliza o script nos hosts site2, os valores "LOCAL" se referem ao site2 e aos valores "REMOTE" ao site1.
    Autonomous Database	fmwadb_switch_db_conn.sh Vá para o repositório 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.	Não é necessário editar o script. Os valores da pasta e da senha são passados como entradas. 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. Não execute o script neste ponto.

Validar Replicação para OCI Block Volumes

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).

A imagem mostra como a ativação cria Volumes em Blocos do OCI anexáveis com base nas réplicas.

Descrição da ilustração activation-create-bv.png

activação-criar-bv-oracle.zip

Execute o seguinte para disponibilizar e usar os volumes replicados no sistema stand-by:

1. Ative as réplicas no site stand-by.
   As réplicas do OCI Block Volumes não podem ser montadas diretamente; você deve ativá-las primeiro. Quando você ativa uma réplica de volume em blocos (BV), um BV "anexável" é criado como um clone do BV replicado. Em seguida, você pode anexar o BV clonado às instâncias de computação.
   Execute as seguintes etapas para ativar as réplicas no site stand-by:
   1. Na Console do OCI, vá para a região do site stand-by. Selecione Armazenamento em Blocos e, em seguida, Réplicas do Grupo de Volumes.
   2. Clique na réplica do Grupo de Volumes e, em seguida, clique em Ativar.
   3. Nomeie o Grupo de Volumes criado como resultado dessa ativação. Para simplificar, use o mesmo nome que na região principal.
   4. Repita as mesmas etapas para todas as réplicas do Grupo de Volumes no site stand-by.
2. Anexe os volumes em blocos replicados aos hosts de camada intermediária no site stand-by.
   1. Na Console do OCI, selecione Armazenamento, depois Volume em Blocos para localizar os Volumes em Blocos do OCI anexáveis criados como resultado da ativação no site stand-by.
   2. Anexe o Volume em Blocos apropriado ao host apropriado. Clique em Block Volume, depois em Instâncias Anexadas e, em seguida, em Anexar à Instância. Para simplificar o procedimento, selecione usar o Oracle Cloud Agent para conectar-se automaticamente a volumes anexados ao iSCSI.
      O Cloud Agent executará automaticamente comandos iSCSI, para que você não precise executá-los. Para usar isso, certifique-se de ativar o plug-in de gerenciamento de volumes em blocos no host.
   3. Se você não usar o Oracle Cloud Agent, execute os comandos iSCSI manualmente. Clique em Comandos e Informações de ISCSI do volume em blocos anexado e execute os comandos ISCSI fornecidos em "Comandos para conexão" no host de camada intermediária.
3. Monte os volumes em blocos replicados nos hosts stand-by.
   Execute o seguinte para cada volume em blocos:
   1. Obtenha o UUID do novo volume em blocos anexado.
      É o mesmo UUID que o Block Volume tem no site principal. Por exemplo:

      [root@prefix-wls-0 opc]# sudo blkid
      /dev/sda3: UUID="974147f5-d731-41de-bba8-56ff78ed1c9c" TYPE="xfs"    PARTUUID="4a95c68a-bc70-4be9-bce8-b15e995fcf46"
      /dev/sda1: SEC_TYPE="msdos" UUID="593B-B893" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="c5ac3089-6a91-40e0-bcc1-212ba0b43418"
      /dev/sda2: UUID="9ca12daa-d7ea-44a2-8680-5b676488b054" TYPE="swap" PARTUUID="682a63d1-d3ec-4019-b372-43720aaae717"
      /dev/sdb: UUID="35e72262-979a-4d84-85ce-a6f91e3b1250" TYPE="ext4" 
      /dev/sdc: UUID="c293b5b5-005c-43e9-8c2f-02e873b76926" TYPE="ext4" 
      

   2. Se ainda não estiver, adicione uma entrada para o UUID apropriado no arquivo /etc/fstab no host para montar e persistir a montagem após as reinicializações.
      Certifique-se de usar o mesmo formato de sistema de arquivos (por exemplo, ext4) que no site principal. Por exemplo:

      UUID=c293b5b5-005c-43e9-8c2f-02e873b76926 /u01/data ext4  auto,defaults,_netdev,nofail

      O UUID de cada volume em blocos replicado permanece o mesmo valor. A Oracle recomenda manter a entrada recém-adicionada no arquivo /etc/fstab para o futuro. Portanto, o daemon systemd montará automaticamente o volume em blocos na próxima vez que for anexado durante uma operação de switchover ou failover.
   3. Montar o novo volume em blocos anexado. Se a entrada apropriada já existir no arquivo /etc/fstab quando o dispositivo estiver anexado, o volume em blocos será montado automaticamente depois de ser anexado.
      O exemplo a seguir é para como montar o novo volume em blocos anexado.

      [root@prefix-wls-0 opc]# mount -a
      [root@prefix-wls-0 opc]# df -h| grep /u01/data
      /dev/sdb 49G 1.4G 46G 3% /u01/data

   4. Repita as etapas para anexar todos os volumes em blocos ativados.
4. Substitua as informações que são específicas do local nos hosts secundários de camada intermediária.
   O script de substituição substitui as informações específicas do local nos hosts secundários de camada intermediária.

   Dica:

   Exemplo para volumes em blocos que contêm o domínio WebLogic

   Atualize as informações de conexão do banco de dados para apontar para o banco de dados local executando o script de substituição em todos os hosts de camada intermediária stand-by:

   1. Se o sistema usar o Oracle Base Database Service ou o Oracle Exadata Database Service, execute o script replacement_script_BVmodel.sh.

      Certifique-se de que ele usa os valores apropriados.

   2. Se o sistema usar o Oracle Autonomous Database, execute o script fmwadb_switch_db_conn.sh.

      O script requer, como entradas, o caminho onde está a wallet original secundária e a senha da wallet.

      Se a pasta tns_admin estiver na pasta DOMAIN_HOME/config, você só poderá executar o script no host de administração. O restante dos nós fará download do tnsnames.ora atualizado quando os servidores gerenciados forem iniciados. Caso contrário, execute o script em todos os hosts de camada intermediária.

5. Limpe os arquivos de bloqueio dos servidores.
   Os volumes em blocos replicados podem conter arquivos de bloqueio do processo de camada intermediária, porque a réplica é executada enquanto os processos principais estão ativos. Antes de iniciar os processos em segundo plano, pode ser necessário limpar esses arquivos. Caso contrário, eles podem impedir que os processos de camada intermediária sejam iniciados

   Dica:

   Exemplo para volumes em blocos que contêm o domínio WebLogic

   Pode haver arquivos .lck, .pid ou .state em pastas ${DOMAIN_HOME}/servers/*/data/nodemanager transportadas do principal. Certifique-se de que esses arquivos estejam limpos antes de tentar iniciar o gerenciador de nós e os servidores. Por exemplo

   rm -f ${DOMAIN_HOME}/servers/*/data/nodemanager/*.lck
   rm -f ${DOMAIN_HOME}/servers/*/data/nodemanager/*.state
   rm -f ${DOMAIN_HOME}/servers/*/data/nodemanager/*.pid
   

   É possível incluir essa ação nos scripts de substituição ou como uma etapa anterior na inicialização do Oracle WebLogic.

   A ativação cria Volumes em Blocos anexáveis a partir das réplicas, conforme mostrado na imagem anterior.
6. Quando o switchover ou failover terminar, os Volumes em Blocos do site com a atribuição stand-by deverão ser desanexados e excluídos. Isso também será necessário quando você tiver concluído uma validação no site stand-by (abrindo o banco de dados stand-by no modo snapshot) e quiser revertê-lo para a atribuição stand-by.
   1. Desmonte todos os volumes em blocos no site stand-by que são replicados do principal.

      [root@prefix-wls-0 opc]# umount /u01/data

   2. Desanexar volumes em blocos no stand-by.
      Use a UI (ou a API) da Console do OCI para desanexar os volumes em blocos desmontados dos hosts de camada intermediária stand-by para prepará-los para o futuro. Se você usou o Oracle Cloud Agent para anexar o volume em blocos, o agente executará os comandos iSCSI para fazer log-off dos destinos iSCSI.
   3. Exclua volumes e grupos em blocos no stand-by.

      Exclua ou renomeie os volumes desanexados dos hosts de camada intermediária stand-by para evitar que eles sejam montados por engano.

      Exclua os grupos de Volumes não utilizados no site stand-by. Eles não serão mais usados.

Executar Replicação Contínua para OCI Block Volumes

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

• A OCI executa automaticamente a replicação do OCI Block Volumes em segundo plano. A única coisa que você precisa fazer durante o ciclo de vida do sistema é garantir que os Grupos de Volumes do sistema com a atribuição principal tenham a réplica entre regiões ativada.
• Considere o uso do OCI Full Stack Disaster Recovery para automatizar as tarefas de switchover e failover. Ele permite executar um plano de switchover ou failover com apenas um clique usando a Console do OCI. É muito útil simplificar a execução de todas as tarefas relacionadas à réplica do Block Volume.
• O recurso de replicação é complementar ao recurso de backup, não uma substituição. Certifique-se de ativar uma política de backup para os volumes em blocos replicados. Isso fornecerá proteção de dados, além da réplica entre regiões, permitindo que você restaure para um ponto no tempo.
• Mantenha as informações específicas de cada site e as mantenha atualizadas. Por exemplo, se o sistema de arquivos contiver uma pasta com os artefatos para estabelecer conexão com um Oracle Autonomous Database, mantenha uma cópia de backup dessa pasta. Certifique-se de atualizar o backup da pasta quando executar uma atualização na wallet. Dessa forma, ele será restaurado corretamente em switchover e failovers subsequentes.
• Após uma operação de switchover ou failover, altere a direção da réplica. Para isso:
  • Ative a réplica nos grupos do OCI Block Volumes do novo principal para o novo site stand-by.
  • Desative a replicação anterior do principal original e exclua os volumes em blocos não usados.