Configurando mod_cluster no EAP 6 – RHEL/CentOS/Fedora

modcluster_logo_450pxJBoss EAP 6 provê mecanismos de cluster com a ajuda de algumas extensões: JGroups, Infinispan e modcluster.

  • JGroups: responsável pela comunicação entre as instâncias
  • Infinispan: responsável por cache e replicação de sessão
  • modcluster: permite a utilização do httpd como load balancer

Características

  • Alta Disponibilidade (HA): execução sem interrupção
  • Escalabilidade: capacidade de manipular um grande número de requisições
  • Failover: até quando instâncias falharem, as requisições dos clientes serão atendidas
  • Tolerância à falha: o serviço é garantido até mesmo se failover ocorrer

Post anterior

Este post é continuação do post Configurando Domain Mode no EAP 6 – RHEL/CentOS/Fedora.

O link anterior é um pré-requisito e ensina a configurar algumas instâncias do EAP 6 em modo Domain. Depois de ter feito toda a configuração descrita no post, continue a partir daqui.

Ambiente clusterizado

As funcionalidades do mod_cluster estarão diponíveis entre as instâncias de um determinado grupo de servidores, no nosso caso utilizaremos o main-server-group. Assim, todas as instâncias deste grupo farão parte do ambiente clusterizado.

Arquitetura

arq_modcluster

High Availability

Podemos utlizar tanto o perfil ha quanto o full-ha, pois ambos provêm as funcionalidades específicas de cluster fornecidas por modcluster e jGroups.

Escolhi o perfil full-ha (poderia ter escolhido ha sem problema algum) para demonstrar como uma modificação na configuração é feita de maneira simples.

No arquivo domain.xml altere o perfil do grupo para full-ha e o socket-binding para full-ha-sockets. Se quiser copiar/colar o trecho depois, ele já está alterado corretamente:

Antes

<server-groups>
<server-group name=”main-server-group” profile=”full”>
<jvm name=”default”>
<heap size=”1303m” max-size=”1303m”/>
<permgen max-size=”256m”/>
</jvm>
<socket-binding-group ref=”full-sockets”/>
</server-group>
<server-group name=”other-server-group” profile=”full-ha”>
<jvm name=”default”>
<heap size=”1303m” max-size=”1303m”/>
<permgen max-size=”256m”/>
</jvm>
<socket-binding-group ref=”full-ha-sockets”/>
</server-group>
</server-groups>

Depois

<server-groups>
<server-group name=”main-server-group” profile=”full-ha“>
<jvm name=”default”>
<heap size=”1303m” max-size=”1303m”/>
<permgen max-size=”256m”/>
</jvm>
<socket-binding-group ref=”full-ha-sockets“/>
</server-group>
<server-group name=”other-server-group” profile=”full-ha“>
<jvm name=”default”>
<heap size=”1303m” max-size=”1303m”/>
<permgen max-size=”256m”/>
</jvm>
<socket-binding-group ref=”full-ha-sockets“/>
</server-group>
</server-groups>

Agora temos que definir uma senha para o HornetQ no perfil full-ha (que é o perfil do nosso main-server-group).

Procure pela linha:

<cluster-password>${jboss.messaging.cluster.password:CHANGE ME!!}</cluster-password>

Obs: preste atenção neste momento, pois existem vários perfis (default, full e ha) neste mesmo arquivo. No nosso caso iremos alterar o <profile name=”full-ha”> que fica aproximadamente na linha 1099 e a altere para:

<cluster-password>123456</cluster-password>

Esta modificação é necessária porque o sistema de mensageria HornetQ utiliza um sistema de cluster separado do jGroups. Assim que habilitamos o cluster, precisamos definir uma senha.

jboss.node.name

Existe um recurso muito interessante, principalmente quando o utilizamos em cluster, pois podemos saber exatamente “quem é quem” no sistema.

Adicione o atributo instance-id=”${jboss.node.name}” subsystem web:

<profile name=”full-ha”>

Aprox. linha 1254:

Antes

<subsystem xmlns=”urn:jboss:domain:web:1.1″ default-virtual-server=”default-host” native=”false”>

Depois

<subsystem xmlns=”urn:jboss:domain:web:1.1″ default-virtual-server=”default-host” instance-id=”${jboss.node.name}” native=”false”>

Instalando o mod_cluster

Baixe o mod_cluster versão 1.2.0: http://www.jboss.org/mod_cluster/downloads/1-2-0-Final

Baixe o pacote correspondente ao seu sistema operacional. No meu caso eu baixei o mod_cluster-1.2.0.Final-linux2-x64-ssl, pois a arquitetura do meu RHEL 6 é x86_64.

Os arquivos que iremos utilizar estão no diretório mod_cluster-1.2.0.Final-linux2-x64-ssl/opt/jboss/httpd/lib/httpd/modules, porém utilizaremos somente os seguinte módulos:

  • mod_proxy_cluster.so
  • mod_advertise.so
  • mod_slotmem.so
  • mod_manager.so

Extraia os arquivos acima para o diretório /etc/httpd/modules. No meu caso instalei na minha máquina física RHEL 6.4 que tem o IP 192.168.122.0.

Depois de copiar os arquivos para o diretório modules, edite o arquivo /etc/httpd/conf/httpd.conf.

O primeiro passo é comentar o módulo abaixo adicionando no início da linha o caracter #:

# LoadModule proxy_balancer_module modules/mod_proxy_balancer.so

O segundo passo é comentar a linha Listen 127.0.0.1:80 adicionando #. Vamos comentá-la, pois adicionaremos outra customizada a seguir:

# Listen 127.0.0.1:80

Obs: Pode ser que ao invés de Listen 127.0.0.1:80 esteja Listen localhost:80

No fim do arquivo httpd.conf, cole o seguinte trecho:

LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule advertise_module modules/mod_advertise.so

Listen 192.168.122.0:10001
<VirtualHost 192.168.122.0:10001>

<Location /mod_cluster-manager>
SetHandler mod_cluster-manager
Order deny,allow
Deny from all
Allow from 192.168.122.
</Location>

KeepAliveTimeout 60
MaxKeepAliveRequests 0

ManagerBalancerName mycluster
ServerAdvertise On
EnableMCPMReceive

</VirtualHost>

Testando o Cluster

Primeiramente, vamos acessar todas as instâncias diretamente:

http://host1:8080/cluster-demo

http://host1:8230/cluster-demo

http://host1:8330/cluster-demo

Obs: o server-three está definido com auto-start=false, portanto está fora do ar.

http://host2:8440/cluster-demo

http://host2:8580/cluster-demo

Agora vamos acessar o Apache Web Server (httpd) que irá receber todas as requisições e as encaminhará para as instâncias que estão no grupo main-server-group:

http://host1/cluster-demo

Se a URL acima responder normalmente, o mod_cluster está funcionando perfeitamente. Para testar basta acessar de vários navegadores diferentes e visualizar nos terminais quais instâncias que estão recebendo as requisições. O interessante é acessar através do link acima e verificar qual instância recebeu a requisição e em seguida derrubá-la. Se o mod_cluster foi configurado corretamente, mesmo com algumas instâncias fora do ar, o sistema estará disponível para o usuário.

mod_cluster-manager

Para acessar o mod_cluster-manager acesse a URL:

http://192.168.122.0:10001/mod_cluster-manager

Espero ter ajudado!



Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s