JBoss/Wildfly - Um cluster sem multicast, mod_cluster ou mod_jk
Autor: Gabriel Prestes | Publicado: 2016-06-23T21:38:00-03:00




 Diversas publicações na Internet apresentam uma forma de realizar a configuração no Wildfly de um cluster com replicação de sessão e com balanceamento de carga quando temos no ambiente a composição de Wildfly(infinispan, jgroups), Apache e mod_cluster ou mod_jk. Também outro cenário comum nas publicações é que é permitido o multicast, ou seja, a propagação de informações para diversos destinatários usando UDP. 



 Em datacenters privados é possível tal configuração, mas vamos levar para a realidade do VPC da Amazon, onde temos o Overlay Multicast como opção para fazer Multicast que para a habilitação deve ser seguido um roteiro de ajustes, instalações de pacotes e etc, que não julguei interessante uma vez que podemos utilizar um meio mais simples de configurar o reconhecimento de host-controller do cluster. 

Caso sua necessidade seja trabalhar com AutoScale, então o Overlay se justifica principalmente por não fixar configurações no domain.xml, deixando mais dinâmica sua configuração, entretanto se este não é sua necessidade, vamos simplificar e transformar o multicast em uma lista de hosts de host-controllers. 

Mais um item interessante de mencionar, citando replicação de sessão, é alterarmos a comunicação dos objetos de sessão de UDP para TCP, pois isso transformará a replicação em algo mais confiável.

Mas quais ajustes são necessários e em quais arquivos? 

Na minha publicação não tratarei de como configurar um cluster, pois isto podes achar em diversos sites com a correta orientação, mas vou citar especificamente as configurações que citei acima do initial_hosts do jgroups e também do método TCP com TCPPING. Para realizar estes ajustes segue um exemplo de configuração do domain.xml que podes adaptar a tua realidade de ambiente: 
















IMPORTANTE: Aplique as configurações abaixo no profile utilizado, no HA ou Full-HA, onde o que está em negrito são os ajustes realizados.



Observe que o nome ‘master’ e ‘slave1’ são os node identifier no host.xml. Também libere a porta 7600 nos SecurityGroups.

Mas por que não utilizar o mod_cluster ou mod_jk? Quando estamos um ambiente AWS* podemos utilizar o próprio LoadBalancer(ELB) como balanceador e health-check* das instâncias, semelhante a funcionalidade do mod_cluster, e que também é baseado em loadfactor para distribuir as conexões. Ao fazemos isto precisamos necessariamente não expor a interface de gerenciamento(bmanagement) deixando-a apenas como loopback ainda que possas contar com as regras de SecurityGroups, também precisaremos uma página simples de teste dentro do WAR/EAR para &nbsp;o ELB, uma que pode retornar ‘OK’ após fazer alguns testes funcionais na aplicação para termos a certeza de funcionamento de DataSource e demais componentes relacionados a aplicação. &nbsp;

Certificados SSL também podem ser instalados no ELB, assim como a camada de cache pode ser CloudFront, mas se precisar envolver redirecionamentos para atender o negócio da aplicação então não tem como fugir de um webserver, então poderá utilizar o Apache com mod_cluster ou mod_jk como frontend para o ELB. Sugiro o uso do mod_cluster como balanceador em função do loadfactor mais eficiente com relação ao mod_j.

Qualquer outra dúvida pertinente ao Wildfly também podes recorrer à documentação do produto que é bem rica em detalhes, seja para o analista de infraestrutura como para o desenvolvedor. O link está disponível nas referências da publicação. 



* Wildfly - chamarei nesta publicação somente assim e não mais de JBoss apesar de eu particularmente não gostar do novo nome

* AWS - Amazon Web Services

* health-check - modelo que checagem para saber se o serviço da instance está ativo e funcional, respondendo as condições que especificaste no ELB



Referências:



https://aws.amazon.com/articles/6234671078671125

https://docs.jboss.org/author/display/WFLY10/Documentation



Publicação também disponível em: http://ilegra.com/beyonddata/