Boas práticas para Cluster Web com JBoss AS

Com a cada vez maior e sempre crescente de adoção de soluções JBoss é cada vez mais frequente encontrar clientes com o mesmo tipo de dúvidas: Quando utilizar o Cluster JBoss ? A resposta é: Depende do que se busca no cluster JBoss. Balanceamento de carga ou tolerância a falhas ?

Com o uso do JBoss EAP (Enterprise Application Platform) em aplicações cada vez mais críticas, muitas vezes surgem discussões sobre o uso de replicação de sessão. Há um mito de que uma vez que a aplicação e a infraestrutura suporte a replicação de sessão, é possível colocar o balanceador de cargas distribuindo as requisições de um mesmo cliente entre diferentes instâncias do servidor de aplicações.

Uma outra corrente, afirma que mesmo com replicação de sessão, é recomendado que a requisição de um cliente sempre caia na mesma instância (Session Sticky habilitado). Este post é uma espécie de tradução e síntese das boas práticas de uso de Web Cluster com JBoss AS buscando disponibilidade das aplicações e consistência dos dados em caso de falhas. Abaixo estão diferentes combinações da configuração de Session Sticky e o modo de replicação da sessão (Cache Mode):

1. Stiky Session habilitado e Cache Mode REPL_ASYNC: A combinação destas configurações garante uma responsividade da aplicação uma vez que a sessão http do servidor que originou a requisição não tem que aguardar pela replicação da sessão antes de retornar o controle ao cliente, e ao mesmo tempo, reduz a possibilidade de dados expirados serem lidos em caso de falhas. Enquanto não houver falhas, as requisições de uma sessão irá sempre ser atendida pelo mesmo nó, o que previne qualquer possibilidade obter dados expirados em condições normais de utilização. A integridade dos dados não é de 100% nesta configuração, mas é o melhor que você pode conseguir sem causar uma grande degradação de performance e por este motivo é a combinação mais recomendada para nossos clientes.
2. Stiky Session habilitado e Cache Mode REPL_SYNC: Esta configuração é a que garante a maior integridade dos dados. Em condições normais de operação, toda requisição irá sempre cair no mesmo nó, então não existe possibilidade de se obter dados expirados. Quando acontece uma falha e pelo fato da sessão ser replicada de forma síncrona, os dados são replicados corretamente para os outros nós em comparação com a replicação assíncrona por quê o servidor aguarda a finalização da replicação antes de retornar o controle ao cliente. Entretanto, devido ao sincronismo na replicação dos dados, e ainda a necessidade de ficar aguardando a resposta de todos os demais nós no qual o dado foi replicado, a aplicação deverá responder muito mais lentamente causando um impacto diretamente na usabilidade do usuário final em relação à primeira opção.
3. Stiky Session desabilitado e Cache Mode REPL_SYNC: Os usuários geralmente interpretam mal esta combinação. Apesar de sofrer dos mesmo problemas de performance da segunda opção, esta combinação não garante o mesmo nível de integridade e pode até mesmo levar a aplicação a não ser condicente com a especificação de Servlets: Mesmo com a replicação síncrona, é possível que o cliente leia porções da resposta, especialmente os headers, antes da replicação completar. Também não é possível garantir que um browser é executado realizando requisições em série. Usando REPL_SYNC sem Sticky Session, as requisições multi-threads podem levar a replicação REPL_SYNC a entrar em Deadlock, uma vez que cada requisição pode cair em uma instância diferente. Por estes motivos é sempre recomendado utilizar Sticky Session
4. Stiky Session desabilidade e Cache Mode REPL_ASYNC: Esta é sem dúvida nenhuma, a pior das combinações. Ela sofre dos mesmo problemas da opção 3 por não usar session sticky e ainda existe uma grande chance de se obter dados expirados pela natureza assíncrona da replicação.

Referência: http://community.jboss.org/wiki/WebClusteringBestPractices