TechfreeA Tecnologia pode ser livre

Para quem não sabe o que é um sistema de alta disponibilidade, aconselho que leia esse verbete do Wikipédia.

Nesse artigo irei explicar como criar um ambiente de alta disponibilidade do apache em servidor Gnu/Linux, utilizando somente ferramentas sob licenças livres.

Meu ambiente é o seguinte

Servidor 1

Nome : server1

Distro: Debian Etch

IP : 192.168.1.1

Servidor 2

Nome: server2

Distro: Debian Etch

IP : 192.168.1.2

Vamos lá! Mãos a obra.

Execute o seguinte comando em ambas máquinas:

# aptitude install mon heartbeat-2 -y

Pronto! Agora já temos os pacotes necessários instalados.

Vamos começar pela configuração do heartbeat.

Em ambas máquinas o arquivo de configuração /etc/ha.d/ha.cf deve estar com o mesmo conteúdo:

logfile      /var/log/ha-log
logfacility   local0
keepalive   2
deadtime   10
warntime   5
initdead   20
udpport      694
bcast      eth0
auto_failback   yes
ping    <coloque aqui o ip do gateway>
node      server1
node      server2

Agora vamos para o arquivo /etc/ha.d/authkeys, que também deve ser igual em ambas máquinas:

auth 1
1 md5 teste

Agora no /etc/ha.d/haresources existe uma pequena diferença entre os servidores

No servidor 1 coloque o seguinte conteúdo:

server1 192.168.1.1 apache2
server2 192.168.1.2

No servidor 2 coloque o seguinte conteúdo:

server1 192.168.1.1
server2 192.168.1.2 apache2

Agora fica a pergunta; “por que a diferença?” Irei explicar mais abaixo.

Execute /etc/init.d/heartbeat start (primeiro no server1 e depois no server2).

Vamos a explicação geral de como o heartbeat irá funcionar:

Os dois daemons estarão conversando pela porta udp informada no ha.cf, que nesse caso foi udp 694. Dessa forma eles saberão se o outro está ativo. Uma vez não conseguindo se comunicar com o outro, ele fará um teste com o gateway, por isso que precisamos especificá-lo no ha.cf.

Após todos os testes de comunicação com o gateway retornando sucesso, o host irá tomar pra sí a responsabilidade dos recursos do outro host. No nosso caso o endereço ip do server2.

No caso do server1 descobrir que ele está fora, pois não consegue se comunicar com o gateway, ele mesmo irá desliga seus recursos.

Agora vem a melhor parte. Após o analista verificar o que aconteceu e resolver o problema. É apenas executar /etc/init.d/heartbeat start na maquina afetada, que ela automaticamente retornará a suas atividades automaticamente.

Atente para NÃO deixar o apache2 setado para iniciar automaticamente e nem o ip informado no haresource esteja em nenhuma interface ativa da máquina, pois o próprio heartbeat irá gerenciar esses recursos. Executando o heartbeat, automaticamente estará executando a interface virtual com o ip informado e o serviço do apache2.

Vamos usar um cenário hipotético para facilitar o entendimento:

O server1 está executando sem problemas suas atividades, porém o server 2 não está respondendo na porta UDP 694.

O server2 está ok, porém o estagiário esbarrou no cabo de rede e ele perdeu conectividade. O próprio server2 irá perceber que não consegue se comunicar com o gateway e então ele mesmo irá desligar o serviço do heartbeat, assim desligando junto a ele todos os recursos informados no haresource, nesse caso a interface virtual e o serviço apache2.

Nesse mesmo momento o server1 estará verificando o arquivo haresource, para saber qual é o recurso do server2 para que ele possa ser o responsável agora. Sendo assim o server1 agora terá duas interfaces virtuais com seus respectivos ips virtuais.

O analista foi ao CPD e verificou que o problema era apenas o cabo de rede e reconectou. Bastou ele acessar o server2 e executar o seguinte comando para que o server2 voltasse a ativa:

# /etc/init.d/heartbeat start

O server2 irá solicitar ao server1 seus recursos. Novamente o server1 irá consultar no haresource, quais os recursos do server2. Se houvesse o nome apache2 depois do ip. O server1 iria desligar seu servidor apache2, achando que somente o server2 pode ter esse serviço. Por isso tiramos o apache2 do outro nó.

Após isso o server2 estará de volta funcionando sem problemas com seu ip virtual.

Agora vamos ao Mon.

Ambos os servidores devem ter o arquivo /etc/mon/mon.cf com o seguinte conteúdo:

alertdir   = /usr/lib/mon/alert.d
mondir     = /usr/lib/mon/mon.d
maxprocs   = 20
histlength = 100
randstart  = 60s

hostgroup www 192.168.1.1 (no caso de ser o server1) ou 192.168.1.2 (no caso de ser o server2)

watch www
service http
interval 30s
monitor http.monitor
allow_empty_group
period wd {Sun-Sat}
alert heartbeat.alert
alert mail.alert -S “web server is down” seu@email.com
upalert mail.alert -S “web server is up” seu@email.com
alertevery 1m

Um detalhe importante antes de executar o mon é baixar esse arquivo e colocá-lo na pasta /usr/lib/mon/alert.d

Após isso abra o arquivo /usr/lib/mon/alert.d/heartbeat.alert e edite a seguinte linha:

De:

# shutdown heartbeat
system (“/etc/init.d/heartbeat stop”);

Para

# shutdown heartbeat
system (“sudo /etc/init.d/heartbeat stop”);

Como percebeu agora precisaremos configurar o sudo. Entre em /etc/sudoers e adicione a seguinte informação:

daemon  ALL=NOPASSWD:/etc/init.d/heartbeat stop

Pronto, agora execute o daemon do mon com o comando /etc/init.d/mon start e fique mais tranquilo com dois apache rodando ao mesmo tempo em um ambiente de alta disponibilidade.

Obs: Lembre-se de verificar se os daemons estão devidamente configurados para iniciarem sozinhos (no caso do mon e heartbeat) e para NÃO iniciar sozinho (que é o caso do apache2).