Sobre o Gerenciamento de Falhas

A topologia de cluster esticada do Oracle Fusion Middleware (FMW) é resiliente a falhas em qualquer componente individual.

Cada site segue as melhores práticas de alta disponibilidade descritas na topologia de Implantação do Oracle FMW Enterprise, garantindo que a redundância local proteja contra interrupções no nível do componente (como o balanceador de carga, as instâncias do Oracle HTTP Server, o Oracle WebLogic Server ou a instância do banco de dados).

As considerações para abordar cenários, como uma falha de camada completa em um local ou uma falha total do local, são discutidas nas seções a seguir.

Gerenciar a Falha de Todos os Servidores da Web em um Site

Se um site perder todas as instâncias do Oracle HTTP Server, o sistema frontend (seja um balanceador de carga global ou uma política de orientação de gerenciamento de tráfego do Oracle Cloud Infrastructure (OCI)) deverá marcar o site como não íntegro.

Todas as solicitações do cliente, independentemente da preferência do local, serão encaminhadas para o outro local.

Portanto, os servidores Oracle WebLogic do site com os servidores Web com falha não receberão novas solicitações. Eles podem continuar processando (por exemplo, processando compostos do Oracle SOA e mensagens JMS (Serviço de Mensagens java). No entanto, quaisquer callbacks HTTP gerados internamente a partir desses servidores falharão porque apontam para seu próprio site, cujos servidores da Web falharam.

O diagrama a seguir mostra falhas em todos os servidores Web em um site

Descrição da ilustração Failure-all-web-servers-one-site.png

failure-all-web-servers-one-site-oracle.zip

Recuperar-se da Falha

Nenhuma intervenção manual é necessária para a recuperação imediata de uma falha em todos os servidores web em um site.

Os clientes são redirecionados automaticamente para o outro site graças às políticas de orientação do Oracle Cloud Infrastructure (OCI) Traffic Management ou ao GLBR (Global Load Balancer).

Se a restauração das instâncias perdidas do servidor Web não for possível no curto prazo, você poderá executar o seguinte para usar os Servidores WebLogic do site com a camada Web com falha:

1. Configure as instâncias do Oracle HTTP Server (OHS) no outro site para rotear solicitações para as instâncias do Oracle WebLogic Server no site com falha.
   1. Atualize a configuração do OHS e defina o parâmetro DynamicServerList como ON.
   2. Aplique essa alteração reiniciando o OHS de forma contínua para evitar tempo de inatividade.
   3. Além disso, certifique-se de que a comunicação entre regiões seja permitida dos servidores Web para os servidores WebLogic no outro site.
2. Para evitar falhas nos callbacks do protocolo de transferência de hipertexto (HTTP) originados do site com servidores OHS indisponíveis, atualize a entrada do nome do frontend no arquivo /etc/hosts dos hosts do servidor WebLogic ou no sistema de nome de domínio privado (DNS), para apontar para o balanceador de carga no outro site.

Depois que os servidores com falha estiverem disponíveis novamente:

1. Inicie os processos do OHS no site com falha.

   Assim que o Oracle Cloud Infrastructure Health Checks estiver OK novamente, a política de direção do gerenciamento de tráfego balanceará a carga das solicitações do cliente entre os dois sites, de acordo com as regras definidas.

2. Defina o DynamicServerList como OFF novamente no outro site.
3. Reverta qualquer alteração no arquivo /etc/hosts dos servidores WebLogic (ou DNS privado) para que eles apontem para seu próprio balanceador de carga do site novamente.

A imagem a seguir mostra mensagens de fila do JMS (Java Message Service) e solicitações de falha do cliente durante uma falha de todos os servidores Web em um site:

Descrição da ilustração failure-messages-all-web-servers-one-site.png

Objetivo de Tempo de Recuperação Esperado

Ao usar as políticas de direção de gerenciamento de tráfego da Oracle Cloud Infrastructure (OCI) para balanceamento global, erros são observados durante um período de cerca de 1 minuto + tempo de vida do DNS (TTL).

A atualização de DNS afeta clientes cuja preferência de política de orientação está definida para a região com falha. O valor TTL determina por quanto tempo esses clientes continuarão usando a entrada antiga antes de atualizá-la para apontar para o site íntegro. O tempo adicional (cerca de 1 min) depende da frequência e do tempo limite das verificações de integridade configuradas na política de direção do OCI (30 segundos foram usados no teste acima para o intervalo de Verificação de Integridade e um tempo limite de 10 segundos).

Ao usar um GLBR (Global Load Balancer), o tempo de interrupção depende da frequência das verificações de integridade configuradas no GLBR. Assim que o GLBR marcar um pool como não íntegro, as solicitações recebidas serão redirecionadas para o outro site. Com um GLBR, não há atualização de DNS, portanto, o valor TTL da entrada de front-end é irrelevante.

Gerenciar a Falha de Todos os Oracle WebLogic Servers em um Site

Quando todos os servidores WebLogic ficam inativos em um site, o outro site continua processando solicitações.

O balanceador de carga do site com falha retornará uma resposta com falha; portanto, o recurso de balanceamento global de frontend, com base nas políticas de direção de Tráfego do Oracle Cloud Infrastructure (OCI) e nas verificações de integridade, deve marcar o site como não íntegro. Todas as solicitações do cliente, independentemente de sua preferência, serão encaminhadas para o outro local.

Os serviços WebLogic Java Message Service (JMS) e Java Transaction API (JTA) migrarão automaticamente para os servidores no outro site ao usar a Migração Automática de Serviço junto com armazenamentos persistentes Java Database Connectivity (JDBC).

No caso SOA do Oracle Fusion Middleware (FMW), se o mestre do cluster de recuperação automática tiver sido hospedado nos servidores com falha, um novo mestre do cluster surgirá no site disponível. Este servidor executa a recuperação automatizada de instâncias SOA iniciadas no outro site.

O diagrama a seguir mostra a falha de todos os servidores WebLogic em um único site:

Descrição da ilustração Failure-all-weblogic-servers-one-site.png

failure-all-weblogic-servers-one-site-oracle.zip

A imagem a seguir mostra solicitações de falha do cliente e mensagens JMS por servidor quando todos os Servidores WebLogic falham em um site.

Descrição da ilustração failure-messages-all-weblogic-servers-one-site.png

No gráfico de mensagens JMS, há quatro linhas, cada uma representando a fila JMS de um servidor. As linhas verde e azul (que são quase sobrepostas) correspondem aos servidores que foram mortos. O número de mensagens JMS para essas filas não aumenta após o início da interrupção.

As linhas vermelhas e amarelas representam os servidores que permanecem na região 2. Quando todas as solicitações são redirecionadas para esta região, cada servidor restante recebe 50% da carga total. No entanto, a taxa na qual as mensagens se acumulam em suas filas é diferente. Isso ocorre porque os servidores JMS dos servidores com falha migraram para um dos servidores restantes, portanto, as mensagens nesse servidor agora são processadas por três filas. Como resultado, a inclinação aparece menor na amarela (observe que a ferramenta de monitoramento não exibe as contagens de mensagens para as filas migradas).

Recuperar-se da Falha

Nenhuma intervenção manual é necessária para a recuperação imediata de uma falha em todos os servidores Oracle WebLogic Server em um só local.

Depois que os servidores com falha estiverem disponíveis novamente:

1. Inicie os servidores gerenciados no site com falha.
2. Assim que o Oracle Cloud Infrastructure Health Checks estiver íntegro novamente, a política de direção do Gerenciamento de Tráfego balanceará a carga das solicitações do cliente entre os dois sites, de acordo com as regras definidas.

Objetivo de Tempo de Recuperação Esperado

Ao usar políticas de direção de gerenciamento de tráfego da Oracle Cloud Infrastructure (OCI) para balanceamento global, erros são observados durante um período de cerca de 1 minuto + tempo de vida do DNS (TTL).

Isto é semelhante ao cenário em que há uma falha em todos os servidores web em um site,

A atualização de DNS afeta clientes cuja preferência de política de orientação está definida para a região com falha. O valor TTL determina por quanto tempo esses clientes continuarão usando a entrada antiga antes de atualizá-la para apontar para o site íntegro. O tempo adicional (cerca de 1 min) depende da frequência e do tempo limite das verificações de integridade configuradas na política de direção do OCI Traffic Management (30 segundos foram usados no teste para o intervalo de Verificação de Integridade e um tempo limite de 10 segundos).

Ao usar um GLBR (Global Load Balancer), o tempo de interrupção depende da frequência das verificações de integridade configuradas no GLBR. Assim que o GLBR marcar um pool como não íntegro, as solicitações recebidas serão redirecionadas para o outro site. Com um GLBR, não há atualização de DNS, portanto, o valor TTL da entrada de front-end é irrelevante.

Gerenciar Falhas no Banco de Dados: Switchover e Failover do Data Guard

Se um problema afetar apenas o banco de dados principal, execute um switchover ou failover do banco de dados para o outro site o mais rápido possível.

A string de URL do JDBC (Java Database Connectivity) e a configuração do ONS (Oracle Notification Service) fornecidas anteriormente em "Configurar Origens de Dados WebLogic" garantem que a reconexão ocorra automaticamente com o novo banco de dados principal. Para esses testes precisos (usando o FOD SOA do Oracle Fusion Middleware (FMW) e mesmo com altas cargas de trabalho de 160 chamadas simultâneas), o switchover ou failover do banco de dados leva menos de alguns minutos. Esse tempo pode variar de acordo com a configuração e o ambiente do sistema. Em sistemas bem ajustados, os tempos de switchover de 1 a 5 minutos são comuns, mas fatores como tamanho do sistema, recursos, carga de trabalho, sincronização de redo log e desempenho da rede podem afetar a duração total. Consulte a seção Explorar Mais para obter links para a documentação do Oracle Data Guard e outros recursos.

Durante um switchover ou failover do banco de dados, haverá erros de aplicativo. Além disso, os Servidores WebLogic que usam a migração de serviço podem ser encerrados e reiniciados automaticamente pelo Gerenciador de Nós se não puderem atualizar sua tabela de leasing. O comportamento esperado com os parâmetros de leasing padrão é:

1. Se a interrupção do banco de dados for muito curta (<1-2 min), não será esperada a reinicialização automática do servidor WebLogic.
2. Se a interrupção do banco de dados for maior (2-10 min), os servidores WebLogic poderão ser reiniciados automaticamente por causa de "perdeu um leasing" quando o banco de dados for iniciado novamente.

   O limite inferior pode ser aumentado ajustando as novas tentativas de leasing do banco de dados do WebLogic, conforme descrito anteriormente em "Configurar Ajuste do WebLogic Database Leasing".

3. Se a interrupção do banco de dados for muito maior (>10 min), os servidores WebLogic poderão ser reiniciados automaticamente devido a outras falhas, como perder o acesso a armazenamentos JDBC críticos ("o armazenamento JDBC do JTA está indisponível").

O diagrama a seguir mostra o switchover do banco de dados na topologia de clusters estendidos FMW

Descrição da ilustração Alongched-clusters-db-switchover.png

stretch-clusters-db-switchover-oracle.zip

A imagem a seguir mostra o desempenho das solicitações do cliente e as mensagens JMS (Java Message Service) por fila de servidor durante um switchover de banco de dados em um cluster esticado FMW.

Descrição da ilustração Alongched-clusters-db-switchover-messages.png

Recuperar-se da Falha

Para recuperar imediatamente de uma falha de banco de dados:

1. Execute um switchover de banco de dados, usando a Console do Oracle Cloud Infrastructure (OCI) ou a interface de linha de comando do broker do Oracle Data Guard.
2. Se o banco de dados principal não estiver disponível, execute um failover do banco de dados no banco de dados stand-bys.

   Os servidores Oracle WebLogic Server se reconectam automaticamente ao novo banco de dados principal, portanto, nenhuma ação manual é necessária, exceto para recuperar erros específicos do aplicativo conforme necessário (por exemplo, no Oracle SOA Suite, talvez você precise recuperar compostos no Hospital de Erros).

Depois que os servidores com falha estiverem disponíveis novamente:

1. Reintegre o banco de dados com falha se você tiver executado um failover de banco de dados.

   Esta ação não é necessária se você executou um switchover.

2. Execute um switchback de banco de dados para o site original.

Objetivo de Tempo de Recuperação Esperado

Para um switchover planejado, o tempo total de recuperação é curto e depende do tempo que o banco de dados precisa para o switchover ou failover.

Para os testes realizados, o switchover leva menos de 2 minutos.

Para um switchover ou failover não planejado, o tempo de inatividade total depende do tempo de inatividade do banco de dados:

• Se você executar o failover ou o switchover do banco de dados quase imediatamente, o tempo total de recuperação será curto. Depende do tempo que o banco de dados precisa para o switchover ou failover. Para os testes realizados, o switchover leva menos de 2 minutos, de modo que o RTO (Recovery Time Objective) esperado é:

  RTO = DB DOWNTIME + SHORT TIME (1-2 min)

• Se o período de indisponibilidade do banco de dados for maior, poderá haver erros adicionais, como reinicializações automáticas do Oracle WebLogic Server, que aumentam o RTO. Neste caso, o RTO esperado é:

  RTO = DB DOWNTIME + WEBLOGIC START TIME

Gerenciar Falhas no Servidor de Administração WebLogic

As falhas de processo do Servidor de Administração são tratadas pelo Gerenciador de Nós WebLogic nesse nó.

O Gerenciador de Nós reiniciará automaticamente o servidor com falha no local.

No entanto, você precisará fazer failover do Servidor de Administração para outro nó se uma interrupção afetar completamente o host em que o Servidor de Administração é executado.

Essencialmente, isso consiste em reiniciar o Servidor de Administração em um nó diferente, garantindo que ele aponte para o local que contém o diretório de domínio do Servidor de Administração e que ele use um endereço de listening mapeado para o IP virtual (VIP) apropriado.

Esse diretório de domínio do Servidor de Administração pode ser um local de armazenamento compartilhado disponível para diferentes nós na mesma região ou uma restauração de um backup ou replicação do sistema de arquivos disponibilizada para nós em outra região.

Observação:

Independentemente da configuração de cluster estendida, espera-se que os procedimentos de backup apropriados estejam em vigor para o domínio do Oracle WebLogic.

Portanto, em uma topologia de cluster estendida do Oracle Fusion Middleware (FMW), diferentes considerações se aplicam ao migrar o Servidor de Administração para um nó em uma região diferente em vez de migrá-lo para um nó na mesma região.

O diagrama a seguir mostra o failover do servidor de administração para outro site no cluster esticado do FMW

Descrição da ilustração Failure-admin-server.png

fail-admin-server-oracle.zip

Failover para uma Região Diferente

Para fazer failover do Servidor de Administração para outra região, siga estas etapas.

1. Disponibilize o backup do diretório de domínio do Servidor de Administração (ASERVER_HOME) no site de failover.
2. Restaure o diretório ASERVER_HOME (incluindo o diretório de domínio e aplicativos) no site de failover para que a mesma estrutura de diretório de domínio seja consistente com o site original.
3. As sub-redes nas regiões 1 e 2 geralmente usarão diferentes blocos CIDR (Classless Inter-domain Routing). Como resultado, o IP virtual (VIP) usado pelo Servidor de Administração na região 1 (por exemplo, 10.10.10.1) não é válido na região 2. Quando o Servidor de Administração for executado na região 2, ele usará um VIP diferente (por exemplo, 20.20.20.1). Atualize a resolução do nome do host para que o endereço de listening do Servidor de Administração (ADMINHOSTVHN) seja mapeado para o novo VIP.
   1. Designe e anexe um IP virtual ao host que executará o Servidor de Administração na região 2, conforme descrito no blog Usando um IP Virtual (VIP) no Oracle Cloud Infrastructure.
   2. Atualize as exibições privadas /etc/hosts ou DNS (Domain Name System) em ambas as regiões para alterar o registro ADMINHOSTVHN do IP anterior (por exemplo, 10.10.10.1) para o novo IP (por exemplo, 20.20.20.1).
4. Modifique o arquivo $NM_HOME/nodemanager.domains no nó em que o Servidor de Administração será restaurado para incluir o ASERVER_HOME e reinicie o Gerenciador de Nós:

   domain_name=MSERVER_HOME;ASERVER_HOME

5. Inicie o Servidor de Administração no novo host.
6. As instâncias do Oracle HTTP Server usam um cache DNS, controlado pela diretiva WLDNSRefreshInterval no mod_wl_ohs.conf. É 0 por padrão, o que significa "cache para sempre". Reinicie o OHS para atualizar o cache de resolução de DNS. Você tem duas abordagens:
   1. Reinicie os servidores OHS para atualizar o cache de resolução de DNS.
   2. Ou defina um valor diferente de zero para WLDNSRefreshInterval no mod_wl_ohs.conf.

   Caso contrário, o OHS continuará tentando se conectar ao Servidor de Administração com o endereço IP anterior.

Verifique se o Servidor de Administração está funcionando corretamente acessando a WebLogic Console Remota e o Oracle Enterprise Manager Fusion Middleware Control.

Failover para a mesma região

Para fazer failover do Servidor de Administração para um host na mesma região, não é necessário copiar o diretório de domínio do Servidor de Administração e o valor do IP virtual (VIP) não é alterado.

Portanto, o procedimento de failover é o mesmo descrito no Enterprise Deployment Guide para o Servidor de Administração, em Verificando Failover Manual do Servidor de Administração.

Para gerenciar o IP virtual (VIP) do servidor de Administração nos sistemas do Oracle Cloud Infrastructure (OCI), você pode usar as etapas descritas no blog Usando um IP Virtual (VIP) no Oracle Cloud Infrastructure

Gerenciar Falha de Toda a Região que Hospeda o Banco de Dados Principal

Se uma interrupção afetar toda a região 1, execute um switchover ou failover do banco de dados para o outro site/região o mais rápido possível.

As instâncias do Oracle WebLogic Server no site restante se reconectarão automaticamente ao novo banco de dados principal se usarem a configuração recomendada descrita na seção anterior.

O balanceador de carga do site com falha retornará uma resposta com falha, portanto, o recurso de balanceamento global de front-end deve marcar o site como não íntegro. Todas as solicitações do cliente, independentemente de sua preferência, serão encaminhadas para o outro local.

Os serviços JMS e JTA WebLogic migrarão automaticamente para os servidores no outro site ao usar a Migração Automática de Serviço junto com armazenamentos persistentes JDBC. No caso do Oracle SOA Suite do Oracle Fusion Middleware (FMW), se o mestre do cluster de recuperação automática tiver sido hospedado nos servidores com falha, um novo mestre do cluster surgirá no site disponível. O novo gerenciador de clusters executará a recuperação automatizada de instâncias SOA iniciadas no outro site.

O diagrama a seguir mostra a falha de toda a região 1 na topologia de clusters esticados FMW:

Descrição da ilustração Failure-entire-region.png

fail-entire-region-oracle.zip

Recuperar-se da Falha

Para recuperar imediatamente de uma falha completa na região 1:

1. Execute um switchover de banco de dados, usando a Console do Oracle Cloud Infrastructure (OCI) ou a interface de linha de comando do broker do Oracle Data Guard.

   Se o banco de dados principal não estiver disponível, execute um failover do banco de dados no banco de dados stand-bys.

2. As instâncias do Oracle WebLogic Server se reconectam automaticamente ao novo banco de dados principal, portanto, nenhuma ação manual é necessária, exceto para recuperar erros específicos do aplicativo (por exemplo, no Oracle SOA Suite, talvez você precise recuperar compostos no Hospital de Erros).
3. Se necessário, execute um failover do Servidor de Administração para a região 2.

Depois que o site com falha for recuperado e estiver disponível novamente:

1. Reinicie os processos nos hosts com falha: servidores Oracle HTTP, WebLogic Administration Server e servidores Gerenciados.

   Certifique-se de que o IP virtual (VIP) do Servidor de Administração esteja definido e que não existam arquivos órfãos que impeçam a inicialização.

2. Reintegre o banco de dados com falha se você tiver executado um failover de banco de dados.

   Esta ação não é necessária se você executou um switchover.

3. Execute um switchover de banco de dados para o site original.

Objetivo de Tempo de Recuperação Esperado

Enquanto o banco de dados estiver inativo, o sistema ficará indisponível.

Os servidores no site restante podem continuar processando solicitações assim que o banco de dados estiver sendo executado novamente no site restante, portanto, o tempo de inatividade depende do tempo usado antes de alternar o banco de dados.

• Se você executar o failover ou o switchover do banco de dados quase imediatamente, o tempo total de recuperação será curto. Depende do tempo que o banco de dados precisa para o switchover ou failover. Para o teste executado, o switchover leva menos de 2 minutos, de modo que o RTO esperado é:

  RTO = DB DOWNTIME + SHORT TIME (1-2 min).

• Se o período de indisponibilidade do banco de dados for maior, poderá haver erros adicionais, como reinicializações automáticas do Oracle WebLogic Server, que aumentam o RTO. O RTO esperado é:

  RTO = DB DOWNTIME + WEBLOGIC START TIME

Gerenciar Falha de Toda a Região que Hospeda o Banco de Dados Stand-by

Se uma falha afetar toda a região 2, o recurso de balanceamento global de frontend deve marcar o local como não íntegro.

Todas as solicitações do cliente, independentemente da preferência do local, serão encaminhadas para a região 1, que continua processando as solicitações. Os serviços JMS e JTA WebLogic migrarão automaticamente para os servidores no site 1 ao usar a Migração Automática de Serviço junto com armazenamentos persistentes JDBC.

No caso do Oracle Fusion Middleware (FMW) com o Oracle SOA Suite, se o mestre do cluster de recuperação automática tiver sido hospedado nos servidores com falha, um novo mestre do cluster surgirá no site disponível. Este servidor executa a recuperação automatizada de instâncias SOA iniciadas no outro site.

Não há necessidade de executar um switchover de banco de dados, pois a interrupção não afeta o banco de dados principal.

O diagrama a seguir mostra a falha de toda a região 2 na topologia de clusters esticados FMW.

Descrição da ilustração Failure-standby-db-region.png

fail-standby-db-region-oracle.zip

Recuperar-se da Falha

Nenhuma intervenção manual é necessária para a recuperação imediata de uma falha completa na região 2.

Depois que o site com falha estiver disponível novamente, reinicie os processos nos hosts com falha para os servidores Oracle HTTP e os servidores gerenciados WebLogic.

Certifique-se de que não existam arquivos órfãos que impeçam o início do WebLogic.

Graças ao recurso de balanceador de carga global (políticas de direção do Oracle Cloud Infrastructure Traffic Management ou um balanceador de carga global), as solicitações do cliente serão rebalanceadas entre os 2 sites novamente.

Objetivo de Tempo de Recuperação Esperado

Ao usar políticas de direção de tráfego da Oracle Cloud Infrastructure (OCI) para balanceamento global, o período com falhas é cerca de 1 minuto a mais do que o tempo de vida (TTL) da entrada de frontend definida na política de direção.

A atualização do sistema de nomes de domínio (DNS) afeta os clientes que têm a região 2 definida como sua preferência na política de direção de geolocalização. A atualização de DNS afeta clientes cuja preferência de política de orientação está definida para a região com falha. O valor TTL determina por quanto tempo esses clientes continuarão usando a entrada antiga antes de atualizá-la para apontar para o site íntegro. O tempo adicional (cerca de 1 min) depende da frequência e do tempo limite das verificações de integridade configuradas na política de direção do gerenciamento de tráfego do OCI (30 segundos foram usados no teste acima para o intervalo de Verificação de Integridade e um tempo limite de 10 segundos).

Ao usar um GLBR (Global Load Balancer), o tempo de interrupção depende da frequência das verificações de integridade configuradas no GLBR. Assim que o GLBR marcar um pool como não íntegro, as solicitações recebidas serão redirecionadas para o outro site. Com um GLBR, não há atualização de DNS, portanto, o valor TTL da entrada de front-end é irrelevante.