Tarefas do Ciclo de Vida

É necessária uma manutenção regular do ciclo de vida para manter o site secundário sincronizado com o site principal. Durante todo o ciclo de vida, você poderá fazer um switchover planejado para alternar as funções dos sites principal e secundário e responder a operações inesperadas ou não planejadas.

Sobre a Replicação de Configuração

Uma replicação inicial do conteúdo que reside nos sistemas de arquivos foi realizada durante a configuração do DR. Repita a replicação do sistema de arquivos regularmente para manter o site secundário atualizado com o site principal.

Você pode usar os mesmos scripts criados durante a configuração do DR, Replicar os Artefatos do Sistema de Arquivos para o OCI e programar a réplica dos sistemas de arquivos com as seguintes considerações para cada artefato:

Replicação de Oracle Homes durante o ciclo de vida
Este é um artefato estático. Não muda com frequência, por isso não há necessidade de replicá-lo regularmente. Somente quando você executa uma modificação no Oracle Home (como atividade de aplicação de patch) é necessário replicá-la.
Replicação da configuração compartilhada do domínio WebLogic durante o ciclo de vida
Este é um artefato dinâmico. Entre outras coisas, ele contém o ASERVER_HOME, que é a fonte da verdade da configuração de domínio do WebLogic Server, e o APPLICATION_HOME, que é atualizado toda vez que um aplicativo é implantado, não implantado, atualizado etc.

Espera-se que essa configuração compartilhada do domínio WebLogic seja alterada com frequência. Programe uma réplica regular deste artefato, que deve ser mais ou menos frequente, dependendo da frequência com que as alterações de configuração ocorrem no sistema. Outra abordagem controlada é executar uma réplica sempre que você executa uma alteração de configuração no principal.
Replicação da configuração privada do domínio WebLogic durante o ciclo de vida
Este também é um artefato dinâmico; ele contém MSERVER_HOME e NM_HOME. Não é esperado ter atualizações frequentes no home nodemanager após a configuração inicial. O conteúdo do MSERVER_HOME será alterado com a frequência que ASERVER_HOME, porque contém a pasta de domínio usada pelos servidores gerenciados. No entanto, a maioria de seu conteúdo (o ASERVER_HOME/config) é atualizada e baixada do AdminServer quando os servidores gerenciados são iniciados e quando as alterações de configuração são aplicadas usando o WebLogic Scripting Tool (WLST) ou a Console de Administração do Oracle WebLogic Server. Não é tão crítico replicar esse artefato tão frequentemente quanto a configuração compartilhada. É obrigatório replicar isso somente quando as modificações são executadas em outras pastas no MSERVER_HOME (por exemplo, uma modificação na pasta MSERVER_HOME/bin).
Replicação da pasta de runtime compartilhada
Se você armazenar qualquer artefato de runtime nesta pasta, programe a réplica para stand-by, de acordo com as suas necessidades de negócios.

Em vez de usar o sistema de arquivos do Oracle Cloud Infrastructure File Storage e replicar com rsync, você pode usar uma montagem do Oracle Database File System (DBFS) para o conteúdo de runtime compartilhado. Dessa forma, o conteúdo reside no banco de dados e é automaticamente replicado para o secundário com a réplica subjacente do Oracle Data Guard. Consulte Sobre o Oracle Database File System em Saiba Mais para obter detalhes sobre como usar o DBFS.

A tabela a seguir é um resumo das recomendações para a replicação de artefatos do sistema de arquivos durante o ciclo de vida.

Artefato	Contém	Recomendação
Oracle Homes	FMW home, JDK, inventário	Replicar somente sob demanda (por exemplo, após a aplicação de patches)
WebLogic Configuração Compartilhada do Domínio	`ASERVER_HOME`, aplicativos, planos de implantação, áreas de armazenamento de chaves	Programar replicação, talvez alta frequência seja necessária. A frequência depende da frequência com que as alterações de configuração são executadas no sistema WebLogic Server.
WebLogic Configuração Privada do Domínio	`MSERVER_HOMES`, `nodemanager config`	Programar replicação. Normalmente, a alta frequência não é necessária.
Runtime Compartilhado	Artefatos de runtime específicos do cliente (não JMS, não TLOGS)	Determinado pelos seus requisitos. Se esta for uma montagem do DBFS, o conteúdo será replicado automaticamente pelo Oracle Data Guard.

Executar um Switchover

Um switchover é uma operação planejada na qual um administrador reverte as funções dos dois sites. Depois de um switchover, o sistema principal se torna secundário e o sistema secundário se torna principal. A execução de um switchover causará tempo de inatividade no site principal.

Antes de executar um switchover em uma configuração de DR Híbrida do WebLogic Server, propague as alterações de configuração pendentes. Certifique-se de que não haja alterações replicadas para o site secundário pendente.

Desative qualquer replicação programada enquanto o switchover for executado, uma vez que ele pode falhar e interferir na própria operação de switchover.
Interrompa os sistemas Oracle HTTP Server no site principal.
Interrompa os servidores no site principal.
Use o(s) Console(s) do Servidor de Administração WebLogic para interromper os servidores WebLogic no site principal.

Observação:
O servidor Admin do site principal pode permanecer ativo durante a alternância. No entanto, é recomendável interrompê-lo quando o site estiver na atribuição stand-by porque espera-se que a configuração de domínio no site stand-by seja substituída pela configuração principal durante o ciclo de vida. Se o servidor Admin estiver ativo enquanto isso acontecer, ele será executado com uma configuração desatualizada.
Alterne o nome do DNS front-end.

Execute o envio de DNS necessário no servidor DNS que hospeda os nomes usados pelo sistema ou altere a resolução do host de arquivo nos clientes para apontar o nome virtual front-end do sistema para o IP público usado pelo Balanceador de Carga no site secundário.

Para cenários em que o DNS é usado para a resolução de front-end externa (como DNS do OCI ou DNS comercial), você pode usar uma API para enviar a alteração. Para ver um exemplo que envia essa alteração em um DNS do OCI, vá para GitHub, por exemplo, scripts.

Observe que o valor de TTL da entrada de DNS afetará o RTO do switchover: se o TTL for alto (exemplo, 20 min), a alteração de DNS levará esse tempo para ser efetiva nos clientes. O uso de valores de TTL mais baixos tornará esse procedimento mais rápido; no entanto, isso poderá causar uma sobrecarga, pois os clientes afetarão o DNS com mais frequência, em vez de usar nomes em cache. Uma boa abordagem é definir o TTL para um valor baixo temporariamente (por exemplo, 1 minuto), antes da alteração no DNS. Em seguida, execute a alteração e, assim que o procedimento de switchover for concluído, reverta o TTL para seu valor original novamente.
Como usuário oracle, use o broker do Oracle Data Guard no host do banco de dados principal para executar o switchover do banco de dados.
Você precisará da senha do sistema e do nome exclusivo do seu banco de dados principal.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> switchover to secondary_db_unqname
```
Se ainda não estiverem ativos, inicie os sistemas Oracle HTTP Server no site secundário (novo principal).
Inicie o Servidor Admin no site secundário (novo principal) ou reinicie o servidor se ele já tiver sido iniciado.
Iniciar o Servidor Admin permite alterações de configuração que foram replicadas enquanto este era um standby para entrar em vigor.
Inicie os servidores gerenciados secundários no site secundário (novo principal).
Use a Console ou os scripts WebLogic para iniciar os servidores gerenciados secundários.

Executar um Failover

Em geral, uma operação de failover é uma operação não planejada que é executada quando o site principal fica indisponível. Você pode fazer a transição de uma atribuição de banco de dados standby para a atribuição de banco de dados principal quando o banco de dados principal original falhar e não houver possibilidade de recuperá-lo em tempo hábil. Pode haver perda de dados, dependendo de seus bancos de dados principal e stand-by de destino estarem consistentes no momento da falha do banco de dados principal.

Propague as alterações de configuração pendentes, se possível.
Consulte Replicar os Artefatos do Sistema de Arquivos para o OCI para replicar alterações no site secundário.
Desative qualquer replicação programada enquanto o switchover for executado, uma vez que ele pode falhar e interferir na própria operação de switchover.
Interrompa os sistemas Oracle HTTP Server no site principal.
Interrompa os servidores gerenciados no site principal, se possível.

Use a Console ou os scripts do Servidor de Administração WebLogic para interromper os servidores gerenciados no principal.
Alterne o nome do DNS front-end.

Execute o envio de DNS necessário no servidor DNS que hospeda os nomes usados pelo sistema ou altere a resolução do host de arquivo nos clientes para apontar o nome virtual front-end do sistema para o IP público usado pelo Balanceador de Carga no site secundário.

Para cenários em que o DNS é usado para a resolução de front-end externa (OCI DNS, DNS comercial etc.), use a API apropriada para enviar a alteração. Para ver um exemplo que envia essa alteração em um DNS do OCI, vá aqui.

Observação:
o valor TTL da entrada de DNS afetará o RTO do switchover. Se o TTL for alto (por exemplo, 20 min), a alteração de DNS levará esse tempo para ser efetiva nos clientes. O uso de valores de TTL mais baixos tornará isso mais rápido; no entanto, isso poderá causar uma sobrecarga, pois os clientes afetarão o DNS com mais frequência, em vez de usar nomes em cache. Uma boa abordagem é definir o TTL para um valor baixo temporariamente (por exemplo, 1 minuto), antes da alteração no DNS. Em seguida, execute a alteração e, assim que o procedimento de switchover for concluído, reverta o TTL para seu valor original.
Como usuário oracle, use o broker do Oracle Data Guard no host do banco de dados secundário para executar o failover.
Você precisará da senha do sistema e do nome exclusivo do seu banco de dados principal.
```
[oracle@hydrdb1 ~]$ dgmgrl sys/your_sys_password@secondary_db_unqname
DGMGRL> failover to secondary_db_unqname
```
Se ainda não estiverem ativos, inicie os sistemas Oracle HTTP Server no site secundário (novo principal).
Inicie o Servidor Admin no site secundário (novo principal) ou reinicie o servidor se ele já tiver sido iniciado.
Iniciar o Servidor Admin permite alterações de configuração que foram replicadas enquanto este era um standby para entrar em vigor.
Inicie os servidores gerenciados secundários no site secundário (novo principal).
Use a Console ou os scripts WebLogic para iniciar os servidores gerenciados secundários.

Abrir o Secundário para Validação

Você pode validar o site stand-by sem executar um switchover completo convertendo o banco de dados stand-by no snapshot standby. Isso permite que os servidores secundários do WebLogic Server sejam iniciados no site stand-by e verifique o sistema secundário. Qualquer alteração executada no banco de dados do site stand-by enquanto ele estiver no modo stand-by de snapshot será descartada assim que for convertido para stand-by físico novamente. Os dados principais não são afetados por validações de sites secundários.

Observação:

Esta operação deve ser feita com cuidado: se houver mensagens JMS pendentes no banco de dados quando ele for convertido em snapshot, os servidores do site stand-by os processarão quando forem iniciados. Verifique se não há ações pendentes no banco de dados principal ao converter em stand-by de snapshot.

Como usuário oracle, use o broker do Oracle Data Guard no host de bd principal e converta o secundário em um stand-by de snapshot.
```
[oracle@dbhost1~]$ dgmgrl sys/your_sys_password@primary_db_unqname
DGMGRL> convert database secondary_db_unqname to snapshot standby
```
Use o comando show configuration para verificar se a conversão foi executada corretamente.
Se ainda não estiverem ativos, inicie os sistemas Oracle HTTP Server no site secundário.
Inicie o Servidor Admin no site secundário.
Inicie os servidores gerenciados secundários no site secundário.
Use a Console ou os scripts WebLogic para iniciar os servidores gerenciados secundários.
Valide o site secundário.

Como esse não é um switchover e o site principal ainda está ativo, o nome do front-end virtual será resolvido para o endereço IP do balanceador de carga do site principal; portanto, qualquer acesso do browser será, por padrão, redirecionado para o site principal ativo.

Para acessar diretamente os aplicativos do Servidor WebLogic do site secundário, atualize o arquivo /etc/hosts em um cliente controlado (por exemplo, um laptop), defina o nome do front-end virtual para resolver o endereço IP do balanceador de carga front-end do site secundário e execute qualquer validação desse cliente.

Observação:
Verifique se o cliente usado para validações não acessa o sistema por meio de um proxy HTTP, porque o proxy HTTP pode continuar a resolver o nome front-end virtual com o endereço IP do balanceador de carga do site principal, independentemente do nome no /etc/hosts do cliente.

Os clientes que não são Linux podem exigir uma redefinição de seu cache DNS local antes que um navegador resolva o endereço IP usando a entrada personalizada do arquivo de host.

Depois que o site secundário tiver sido validado, vá para a próxima etapa para revertê-lo para a atribuição standby.

Observação:
Pode levar algum tempo para validar o site secundário.
Interrompa os servidores gerenciados e os servidores de administração no site secundário.
Use a Console secundária WebLogic para fazer shutdown dos servidores gerenciados e do servidor Admin no site secundário.
Como usuário oracle, use o broker do Oracle Data Guard no host de banco de dados principal e converta o secundário para stand-by físico novamente.
Você precisará da senha do sistema e do nome exclusivo do seu banco de dados principal.
```
[oracle@dbhost1 ~]$ dgmgrl sys/your_sys_password@primary_db_unqname
    DGMGRL> convert database secondary_db_unqname to physical standby
```
Use show configuration para verificar a conversão.
Reverta de volta todos os arquivos /etc/hosts atualizados.
Se você atualizou quaisquer arquivos /etc/hosts em um cliente para apontar para o site secundário para validações, reverta para que o nome do front-end virtual aponte para o endereço IP do front-end principal novamente.

Failover Local do Servidor de Administração no OCI

Você pode iniciar o Servidor de Administração em um nó diferente no mesmo site quando houver uma falha no host em que o Servidor de Administração estava sendo executado originalmente. Não é necessário ter uma alternância completa do sistema para outro site.

Observação:

Esta tarefa do ciclo de vida só é aplicável quando WebLogic Servidores de Administração usam um VIP para fins de alta disponibilidade local e a pasta de configuração do Servidor de Administração (ASERVER_HOME) está em um local compartilhado.

O procedimento para fazer isso é explicado em Verificando Failover Manual do Servidor de Administração. Isso fornece proteção de failover local para o servidor de Administração. Observe que isso não é necessário para os servidores gerenciados, que têm proteção local de alta disponibilidade com base no recurso de Migração Automática de Serviço.

Se você precisar executar um failover do Servidor de Administração para outro host quando o principal estiver em execução no site do OCI, poderá seguir esse procedimento. No entanto, ações adicionais são necessárias relacionadas à etapa "Migrar o endereço IP virtual ADMINVHN para o segundo host".

Execute as seguintes etapas para desanexar o VIP do host WebLogic Server no qual o Servidor de Administração estava em execução e anexá-lo ao host WebLogic Server no qual a Administração está sendo movida (desanexe o VIP de APPHOST1 e anexe-o ao APPHOST2 no site do OCI):

Como o usuário root, execute os comandos a seguir em APPHOST1 para remover o VIP do Servidor de Administração da interface de rede.
1. Interrompa o Servidor de Administração caso ele ainda esteja em execução
2. Confirme onde o VIP está sendo executado.
```
ip addr show dev ens3
```
3. Remova o IP da interface de rede.
```
ip addr del 100.70.8.120/20 dev ens3
```
Desanexe o VIP do Servidor de Administração do APPHOST1 .
1. Conecte-se à Console do OCI e selecione a região e o compartimento apropriados.
2. Navegue até a instância de computação. Clique em Compute, Instâncias e, em seguida, clique em APPHOST1.
3. Clique em VNICs Anexadas e selecione a VNIC na qual o VIP do Servidor de Administração está anexado.
4. Clique em IPv4 Endereços e edite o VIP que o Servidor de Administração usa.
5. Salve o endereço IP e o nome fqdn do VIP em uma nota (por exemplo: 100.70.8.120, hidrwls-vip.midtiersubnet.hydrvcn.oraclevcn.com).
6. Clique em Excluir IP Privado.
Anexe o VIP do Servidor de Administração ao APPHOST2.
1. Navegue até a instância de computação. Clique em Compute, Instâncias e, em seguida, clique em APPHOST2.
2. Clique em VNICs Anexadas e selecione a VNIC na qual o VIP do Servidor de Administração está anexado.
3. Clique em Designar endereço IP privado secundário.
4. Clique em IPv4 Endereços e, em seguida, clique em Designar endereço IP privado secundário.
5. Informe os valores de endereço IP Privado e nome do host que foram usados antes. Por exemplo: 100.70.8.120 para o IP e hydrwls-vip como o nome do host.
Faça log-in em APPHOST2 como usuário root e, em seguida, execute os comandos a seguir para anexar o VIP do servidor de administração à interface de rede.
1. Confirme onde a interface de rede está sendo executada.
```
ip addr show dev ens3
```
2. Adicione o VIP do Servidor de Administração à interface de rede.
```
ip addr add 100.70.8.120/20 dev ens3 label ens3:1
```
Execute o restante das etapas, conforme descrito em Verificando Failover Manual do Servidor de Administração.