Alta disponibilidade no Linux com heartbeat

Posted on abril 17, 2012. Filed under: Linux | Tags:, , |

Introdução

Neste artigo vamos demonstrar como configurar o software heartbeat com a finalidade de criar um sistema de Alta disponibildade no Linux. Vamos usar dois servidores numa solução master/slave onde o heartbeat ficará monitorando a disponibilidade dos nós configurados. Este artigo, de certa forma, serve como um complemento para o artigo Replicação Master-Master no MySQL.

Cenário

Dois servidores:

servidor1 192.168.10.1
servidor2 192.168.10.2

Ip Vip: 192.168.10.10

Para exemplo deste artigo vamos usar como nome dos servidores: “servidor1” e “servidor2”. Os nomes devem corresponder aos nomes das próprias máquinas (hostname).

O IP Vip corresponde ao ip que será compartilhado entre os dois servidores. Através do IP vip na verdade estaremos acessando o servidor que estiver como master no momento do acesso. Esse comportamento será controlado pelo heartbeat.

Insira as linhas abaixo no arquivo /etc/hosts nos dois servidores:

192.168.10.1 servidor1
192.168.10.2 servidor2

Para configurar o heartbeat de forma eficaz, dedique uma interface de rede nos dois servidores que serão conectados diretamente através de um crossover. É através dessa interface que o heartbeat determinará a disponiblidade dos nós.

Instalando heartbeat

A instalação do heartbeat em sistemas baseados em debian é bem simples:

$ sudo apt-get install heartbeat

Configuração do hearbeat

1. Arquivo /etc/ha.d/ha.cf

O conteúdo deve ser idêntico nos dois servidores:

use_logd yes
keepalive 1
deadtime 10
warntime 5
initdead 120
bcast eth4
node servidor1
node servidor2
auto_failback off

Descrição dos parâmetros:

use_logd yes – habilita log do heartbeat.
keepalive 1 – tempo em segundos entre um “heartbeat” e outro.
deadtime 10 – Tempo que o heartbeat aguarda por uma resposta até determinar que o nó esta morto.
warntime 5 – Tempo que o hearbeat aguarda por uma resposta para disparar um aviso de atraso (late warning).
initdead 120 – Quando você reinicia todas as máquinas do cluster ao mesmo tempo, pode haver uma diferença de tempo entre as máquinas até que subam todos os serviços. Esse parâmetro cuida dessa situação. Esse tempo é contado somente quando o heartbeat inicia o seu serviço.
bcast eth4 – eth4 seria a interface usada pelo heartbeat para o envio de broadcast. É através dessa interface que o heartbeat ficará “pingando” os outros nós do cluster. Normalmente esta interface é cross. Pode ser que o valor desse parâmetro mude de servidor para servidor dependendo do nome da interface que foi usada no cross.
node – nomes dos servidores presentes no cluster.
auto_failback off – Com o auto_failback on, quando ocorre uma queda no primeiro nó (master neste momento), o segundo nó assume como master. Quando o primeiro nó voltar da queda, o segundo nó passa o master para o nó 1 novamente. Com a opção off, o primeiro nó ao voltar da queda sobe como slave.

2. Arquivo /etc/ha.d/authkeys

Este arquivo deve ser idêntico para todos os servidores no cluster. Ele controla a autenticação do heartbeat. O dono do arquivo deve ser o root com a permissão 600. No exemplo abaixo, “qualquertexto” pode ser qualquer string da sua escolha, com tanto que esteja idêntica em todos servidores. Além do sha1, outros tipos de autenticação podem ser md5 e crc.

auth 1
1 sha1 qualquertexto

3. Arquivo /etc/ha.d/haresources

servidor1 192.168.10.10 apache2

Este arquivo também deve ser idêntico em todos os servidores do cluster. O primeiro parâmetro é o hostname do nó que você considera como master primário. Ao subir o heartbeat na primeira vez, esse será o nó que assumirá como master.

O segundo parâmetro é o ip vip do cluster, ou o ip “compartilhado” que estará sempre ativo independente do nó que estiver como master. Esse é o ip que você passará para outros servidores/serviços que irão acessar o “cluster”.

O terceiro e consequentes parâmetros são os nomes dos serviços que o heartbeat irá controlar. No caso apache2, como mostra o exemplo abaixo, estará ligado somente no nó master. Nos outros nós estarão desligados. Neste caso, quem controla o start/stop do serviço não será mais o linux através do rc.d e sim o heartbeat. Portanto, todos os serviços configurados no heartbeat devem ser eliminados da inicialização do Linux (rc.d).

PS: O script start/stop do serviço continua no init.d, deve ser removido somente da inicialização (rc.d).
Exemplo:

# update-rc.d -f apache2 remove

Você pode adicinar quantos serviços forem necessários para o devido funcionamento do cluster. Uma exemplo de serviço, seria um script que fica sincronizando arquivos de configuração entre os nós do cluster através de rsync. Quando você muda a configuração em um nó ele automaticamente replica para o outro nó. Exemplo:

servidor1 192.168.10.10 apache2 synconfig

No caso você deve criar um serviço chamado synconfig em /etc/init.d ! Ele irá chamar um daemon que fica sincronizando arquivos através de rsync. O serviço deve receber pelo menos os parâmetros start e stop.

Espero ter ajudado com essa contribuição. Fiquem livres para comentários e boa sorte.

Make a Comment

Deixe um comentário

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 )

Foto do Google

Você está comentando utilizando sua conta Google. 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 )

Conectando a %s

3 Respostas to “Alta disponibilidade no Linux com heartbeat”

RSS Feed for Pasqua Tecnologia Comments RSS Feed

Estou fazendo um tcc em um curso de tecnologia em redes. E o tema é justamente alta disponibilidade. Tentei seguir o seu tutorial, porém quando eu desconecto o cabo de rede do servidor1, o serviço não levanta no outro. Estou usando máquina virtual como o virtual box. Se puder me ajudar eu posso passar mais informações das configurações que eu fiz pra você ver se eu me confundi em alguma coisa

Bom dia Ronaldo,

Eu não cheguei a testar alta disponibilidade com heartbeat em um ambiente virtualizado. De qualquer forma, esse esquema de failover apresentando, o segundo nó, somente assumiria o comando quando o primeiro nó estiver indisponível. Se você desconectou o cabo de rede no primeiro nó, que não seja o cabo da interface configurado no parâmetro do bcast (usado para broadcast), o segundo nó não irá assumir, pois o servidor do primeiro nó ainda esta no ar. O heartbeat não controla indisponibilidade de link de internet, e sim se o servidor ficar inoperante.

Para que você possa testar corretamente o heartbeat, desligue o servidor1. E não remover o cabo de rede somente. Lembre-se que você tem que configurar um interface cross over entre os dois servidores. Essa interface vai ficar “pingando” o outro para identificar indisponibilidade (parâmetro bcast).

Boa sorte!

Estou com o TCC pronto, vou defender no próximo sábado, dia 23. Não me lembro mais como era a configuração antes, mas eu usava uma conexão crossover e a outra na rede local, e quando eu desconectava um cabo, o heartbeat fazia a comunicação pelo outro. Eu tirei o crossover e deixei ele se comunicando entre os servidores e o cliente pela rede local, dessa forma, se eu desconecto o cabo do servidor1 que vai do servidor até o swtich, o servidor2 perde a conexão com o servidor e assume que o servidor1 não está mais funcionando e inicializa o apache.


Where's The Comment Form?

Liked it here?
Why not try sites on the blogroll...

%d blogueiros gostam disto: