segunda-feira, 5 de junho de 2017
Dois servidores:
SERVER01 192.168.10.1
SERVER02 192.168.10.2
IP Virtual: 192.168.10.10
Aqui vamos usar como nome dos servidores: “SERVER01” e “SERVER02”. Os nomes devem corresponder aos nomes das próprias máquinas (hostname).
O IP Virtual corresponde ao ip que será compartilhado entre os dois servidores. Através do IP Virtual 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 SERVER01
192.168.10.2 SERVER02
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 SERVER01
node SERVER02
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
SERVER01 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 Virtual 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:
SERVER01 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.
via
