Como Escolher entre as Recuperações Automatizada e Manual do Período de Transação
Seu tipo de sistema de arquivos é o fator dominante na decisão do tipo de recuperação do período de transação a ser utilizado. Sistemas de arquivos diferentes apresentam comportamentos diferentes e o comportamento de bloqueio do arquivo, especificamente, é importante ao escolher entre as recuperações automatizada e manual do período.
O suporte de alta disponibilidade (HA) do WebSphere Application Server utiliza um mecanismo de pulsação para determinar se os servidores ainda estão em execução. Os servidores serão considerados com falha se pararem de responder a pedidos de pulsações. Alguns cenários, como sobrecarga do sistema e particionamento da rede (explicados em outro lugar deste tópico), podem fazer com que os servidores parem de responder às pulsações, embora continuem a ser executados. O WebSphere Application Server utiliza a tecnologia de bloqueio de arquivo para impedir que esses eventos causem acesso simultâneo aos logs de recuperação de transação, porque o acesso a um log de recuperação por mais de um servidor pode levar a perda da integridade dos dados.
No entanto, nem todos os sistemas de arquivos fornecem a semântica necessária de trava de arquivo, especificamente, a liberação das travas de arquivos na falha de um servidor. Por exemplo, o NFSv4 (Network File System Versão 4) fornece esse comportamento de release, enquanto que o NFSv3 (Network File System Versão 3) não.
É possível testar se um sistema de arquivos compartilhado pode suportar o failover de logs de transação executando o Teste de Protocolo de Bloqueio de Sistema de Arquivos para o WebSphere Application Server. Para executar o teste, consultehttp://www-01.ibm.com/support/docview.wss?uid=swg24010222.
O NFSv4 libera as travas mantidas de um host no caso de falha. A recuperação do peer pode ocorrer automaticamente sem a necessidade de reiniciar o hardware falho. Portanto, essa versão do NFS é melhor adaptada para uso com a recuperação automatizada do período.
O NFSv3 mantém as travas de arquivo de um host com falha até esse host poder ser reiniciado. Nesse contexto, o host é a máquina física que está executando o servidor de aplicativos que solicitou a trava, e é a reinicialização do host, não o servidor de aplicativos, que eventualmente ativa as travas a serem liberadas.
- O servidor H está em execução no host H e mantém uma trava de arquivo exclusiva para seus próprios arquivos de registro de recuperação.
- O servidor P está em execução no host P e mantém uma trava de arquivo exclusiva para seus próprios arquivos de registro de recuperação.
- O host H falha, levando o servidor H com ele. O gerenciador de trava do NFS no servidor de arquivos mantém as travas concedidas ao servidor H em seu nome.
- Um evento de recuperação no mesmo nível é acionado no servidor P para o servidor H pelo WebSphere Application Server.
- O servidor P tenta obter uma trava de arquivo exclusiva para esse registro de recuperação de período, mas não consegue, umas vez que está retido em nome do servidor H. O processo de recuperação de período é bloqueado.
- Em um horário não especificado, o host H é reiniciado. As travas mantidas em seu nome são liberadas.
- O processo de recuperação de peer no servidor P é desbloqueado, recebendo os bloqueios de arquivo exclusivos necessários para executar a recuperação do peer.
- A recuperação do período ocorre no servidor P para o servidor H.
- O servidor H é reiniciado.
- Se a recuperação do período ainda estiver em progresso no servidor P, ela será interrompida.
- O servidor P libera a trava exclusiva nos logs de recuperação e retorna a propriedade dos logs de recuperação ao servidor H.
- O servidor H obtém o bloqueio exclusivo e pode agora executar o registro de transações padrão.
Por causa desse comportamento, você deve desativar a trava de arquivos no NFSv3 para utilizar a recuperação de período automatizada. A desativação da trava de arquivo pode levar a acesso simultâneo dos logs de recuperação, portanto, é vital proteger o sistema contra sobrecarga e particionamento da rede antes. Alternativamente, você pode configurar a recuperação do peer manualmente, impedindo o acesso simultâneo pelo acionamento manual do processamento de recuperação do peer apenas para os servidores que realmente falharam.
- Sobrecarga do sistema
- A sobrecarga do sistema ocorre quando uma máquina torna-se excessivamente carregada, de tal forma
que os tempos de resposta são extremamente lentos e os tempos limite dos pedidos começam a esgotar. Existem
várias causas potenciais para essa sobrecarga, incluindo:
- O servidor perde a potência e não pode manipular a carga de trabalho.
- O servidor recebeu um aumento temporário de pedidos.
- A memória física disponível é insuficiente. Como resultado, o sistema operacional está muito ocupado executando paginação para fornecer ao servidor de aplicativos o tempo necessário de CPU.
- Particionamento de rede
- O particionamento de rede ocorre quando uma falha na comunicação em uma rede resulta em duas redes menores independentes que não podem entrar em contato entre si.

Durante a execução normal, dois servidores na rede trocam pulsações. Durante a sobrecarga do sistema, o tempo limite das operações de pulsação se esgotam, aparentando falha do servidor. Após o particionamento da rede, cada servidor está em uma rede separada e as pulsações não podem ser transmitidas entre elas, também aparentando uma falha do servidor.