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:
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 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.
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.
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 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.
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:
Publicação também disponível em: http://ilegra.com/beyonddata/
Nenhum comentário:
Postar um comentário