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 usa 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 usa a tecnologia de bloqueio de arquivo para evitar que tais 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 à perda de integridade de 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 arquivo compartilhado pode suportar o failover de logs de transações executando o Teste de Protocolo de Bloqueio do sistema de arquivos para o WebSphere Application Server Para executar o teste consulte http://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 com falha. 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.

Para ilustrar o travamento de arquivo no NFSv3, considere o comportamento quando um membro de cluster falhar:
  1. 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.
  2. 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.
  3. 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.
  4. Um evento de recuperação no mesmo nível é acionado no servidor P para o servidor H pelo WebSphere Application Server.
  5. O servidor P tenta obter um bloqueio de arquivo exclusivo para este log de recuperação de peer, mas não pode fazer isso, pois ele é mantido em nome do servidor H. O processo de recuperação de peer está bloqueado.
  6. Em um horário não especificado, o host H é reiniciado. As travas mantidas em seu nome são liberadas.
  7. 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.
  8. A recuperação do período ocorre no servidor P para o servidor H.
  9. O servidor H é reiniciado.
  10. Se a recuperação do período ainda estiver em progresso no servidor P, ela será interrompida.
  11. O servidor P libera a trava exclusiva nos logs de recuperação e retorna a propriedade dos logs de recuperação ao servidor H.
  12. 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 usar 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. Como alternativa, é possível 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.
Figura 1. As pulsações em um sistema em execução normal, se comparado com as pulsações depois das falhas aparentes do servidor resultantes da sobrecarga do sistema e do particionamento de rede
As pulsações em um sistema em execução normal, se comparado com as pulsações depois das falhas aparentes do servidor resultantes da sobrecarga do sistema e do particionamento de rede

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.