Cluster de alta disponibilidade para servidores web com Debian 7.1 + Corosync + Pacemaker + DRBD

Tutorial completo sobre Cluster de Alta Disponibilidade (HA) Debian Wheezy 7.1 + Corosync + Pacemaker + DRBD.

[ Hits: 47.536 ]

Por: Danilo Menzanoti Fugi em 09/03/2015 | Blog: http://www.drmusical.vai.la


Configurações



SSH com troca de chaves



Com o servidor SSH instalado, vamos gerar as chaves de SSH, em todos os nós, para efetuarmos a conexão via troca de chaves:

# ssh-keygen -t rsa

Agora temos que copiar as chaves do no01 para os nós no02 e no03, e assim por diante, até que todos os nós possuam todas as chaves dos outros nós. Na máquina no01, podemos executar o seguinte comando:

# ssh-copy-id 192.168.0.2
# ssh-copy-id 192.168.0.3

Nas demais máquinas, devemos executar o comando trocando os números dos endereços IPs dos respectivos nós. Desta forma, já temos comunicação SSH entre todas os nós do cluster.

Configuração do Corosync

Ainda na máquina no01, iremos gerar a chave de autenticação para o Corosync com o seguinte comando:

# corosync -keygen

Assim que geradas as chaves na máquina no01 para o Corosync, iremos copiá-las para as máquinas no02 e no03 com o comando:

# scp /etc/corosync/authkey 192.168.0.2:/etc/corosync/authkey
# scp /etc/corosync/authkey 192.168.0.3:/etc/corosync/authkey

Iremos configurar o Corosync para que fique ativo na inicialização:

# sed -i 's/START=no/START=yes/g' /etc/default/corosync

Fazer backup do arquivo de configuração:

# cp -a /etc/corosync/corosync.conf{,.bkp}

Agora faremos a edição do arquivo de configuração /etc/corosync/corosync.conf utilizando o editor nano, aproveitaremos os dados já inseridos no arquivo, alterando somente onde precisamos para nossa configuração:

# nano /etc/corosync/corosync.conf

bindnetaddr: 192.168.0.0
to_syslog: no

Vamos copiar o arquivo alterado para o no02 e para o no03:

# scp /etc/corosync/corosync.conf 192.168.0.2:/etc/corosync/
# scp /etc/corosync/corosync.conf 192.168.0.3:/etc/corosync/

Vamos reiniciar o corosync em todos os nós:

# service corosync restart

Configuração do Pacemaker

Com a configuração do Corosync terminada e o serviço iniciado corretamente, já podemos utilizar o Pacemaker para disponibilizar os serviços do cluster, agora vamos testar se o cluster está funcionando.

Para o Pacemaker ser configurado, utilizaremos a linha de comando crm.

# crm_mon --one-shot -V

Desta forma, teremos o retorno dos nós ativos: Online [no01 no02 no03]

Agora no no01, vamos desabilitar o stonith para que ele não fique gerando erros, com o comando:

# crm configure property stonith-enabled=false

Podemos verificar se nosso cluster não tem nenhum problema da seguinte forma:

# crm_verify -L

Caso não encontre erros, ele não retorna nada.

Agora vamos desabilitar o quorum para não recebermos erros durante a configuração dos recursos, podemos executar em algum dos nós pois o cluster já está ativo e funcionando, pois as configurações serão replicadas para os outros nós:

# crm configure property no-quorum-policy=ignore

Para ser possível a movimentação de serviços entre os nós do cluster, sem a necessidade de alterarmos o endereço IP do serviço, o endereço IP associado ao serviço deverá ser configurado como um recurso do cluster para que ele possa ser movido livremente entre os nós do cluster junto com o serviço.

Iremos criar um recurso do tipo endereço IP 192.168.0.100 usando o RA IPaddr2, este IP será o endereço do Cluster, isto é, poderemos acessar o cluster e seus serviços através desse endereço, para configurar este recurso utilizaremos o comando:

# crm configure primitive IPdoApache ocf:heartbeat:IPaddr2 params ip="192.168.0.100" cidr_netmask="24" nic=eth1 op monitor interval=10s

Para verificar o serviço, utilizaremos:

# crm_mon -1

Teremos um retorno do tipo:

IPdoApache (ocf::heartbeat:IPaddr2): Started no01

Iremos definir em qual servidor o recurso deve ser alocado, com isso o Pacemaker já fez isso automaticamente elegendo um dos nós como padrão. Consultaremos o endereço IP configurado no servidor no01:

# ip addr show dev eth1

Note que no retorno, temos a configuração da interface eth1 com IP 192.168.0.1/24 e 192.168.0.100/24 como configuração secundária.

inet 192.168.0.1/24 brd 192.168.0.255 scope global eth1
inet 192.168.0.100/24 brd 192.168.0.255 scope global secondary eth1


Iremos fazer os testes desligando o servidor no01, onde está o nosso recurso alocado, com o comando:

# shutdown -h now

Testando a configuração no no02:

# crm_mon -1

Teremos os seguintes retornos:

2 Nodes configured, 2 expected votes
1 Resources configured.
============
Online: [ no02 no03]
OFFLINE: [ no01 ]
IPdoApache (ocf::heartbeat:IPaddr2): Started no02


Neste momento, o Pacemaker já notou que a conexão com o no01 foi perdida por algum motivo e já passou o serviço para o no02. Lembrando que o no02 assumiu o serviço por decisão do Pacemaker e poderia ser o no03, mas isso podemos definir o nível de prioridade dos nós.

Mas antes, vamos religar a máquina do no01 e refazer o teste de comportamento:

# crm_mon -1
2 Nodes configured, 2 expected votes
1 Resources configured.
Online: [ no01 no02 no03]
IPdoApache (ocf::heartbeat:IPaddr2): Started no02


Note que o serviço continua alocado no no02 e o Pacemaker poderia voltar o serviço para o no01, no entanto, as prioridades de serviço estão no mesmo nível, então só voltará ao no01 quando o serviço for desalocado do no02 por desligamento ou parada do serviço.

Configuração de recurso para monitoramento

Vamos começar o monitoramento com a instalação do Apache em todos os nós do cluster, com o seguinte comando:

# aptitude -y isntall apache2

Depois do Apache instalado, as requisições de protocolo HTTP via navegador de internet já funcionam com a resposta de "It works!" na tela do navegador. Antes de fazer os testes, vamos alterar o teor do arquivo "index.html" que fica no local /var/www de cada nó do cluster.

Para isso, usaremos o editor nano:

# nano /var/www/index.html

O conteúdo do arquivo deve ser configurado para a seguinte forma, apenas trocando "It works" para "No 01" e nos outros nós, o número específico de cada nó:

<html>
<body>
<h1>No 01</h1>
</body>
</html>

Para fins de testes, podemos ter em nossa rede, um terminal com qualquer Sistema Operacional que contenha interface gráfica para facilitar as operações. Assim podemos utilizar o navegador e acessar os nós digitando http://192.168.0.1 para o no01, http://192.168.0.2 para o no02, http://192.168.0.3 para o no03 e sucessivamente para mais nós, caso existam.

Com estas alterações, teremos visivelmente as respostas de requisição de cada servidor Apache, e podemos identificar qual é o servidor ativo no momento. Agora vamos configurar um recurso do Cluster para monitorar o Apache2:

# crm configure primitive RecursoApache lsb:apache2

Consultando, outra vez os recursos do Cluster:

# crm_mon -1
Online: [ nodo1 nodo2 no03]
IPdoApache (ocf::heartbeat:IPaddr2): Started no02
RecursoApache (lsb:apache2): Started no01


Percebam que os recursos estão no servidor no02 e no01, isto é, separados, o recurso de monitoramento do Apache2 está iniciado em no01 e monitoramento do IP do cluster em no02, assim para facilitar a movimentação e o gerenciamento de recursos associados a um serviço, podemos agrupar todos esses recursos em um único grupo, onde podemos definir o local de prioridade alta, média e baixa, sendo que todos os recursos serão movidos para a localização que desejamos e não mais decidido pelo Pacemaker.

Vamos utilizar o comando:

# crm configure group GrupodoServidor RecursoApache IPdoApache

Novamente, vamos consultar os recursos:

# crm_mon -1

Teremos o retorno da seguinte forma:

Resource Group: GrupodoServidor
   RecursoApache (lsb:apache2): Started no01
   IPdoApache (ocf::heartbeat:IPaddr2): Started no01


Podemos perceber que os recursos estão agora alocados somente no servidor no01 e o grupo se encarrega de mantê-los unidos, assim podemos definir a prioridade dos nós do cluster. Neste modelo de configuração não havia necessidade de definir prioridades de nós no cluster, pois todas as máquinas são iguais em memória RAM, CPU e espaço em disco, mas em máquinas reais nem sempre conseguiremos montar um Cluster com máquinas idênticas, pois alguma que seja adicionada posteriormente, pode ter melhorias e evoluções de hardware.

Um exemplo seria um cluster formado com três nós de computadores convencionais, onde cada um deles é diferente do outro, sendo o nó 01 um computador de última geração com memória RAM e CPU muito rápidos, nó 02 um computador intermediário com a metade dos recursos de hardware do nó 01 e o nó 03 um computador bem simples com a metade dos recursos de hardware do nó 02.

Assim ficaria interessante se manipulássemos os recursos do cluster para que se aloquem no nó que possua o melhor hardware, fazendo que as requisições sejam resolvidas mais rápidas, como nó 01 - 100, nó 02 - 80 e nó 03 - 60, sendo que a prioridade 100 é mais alta e 0 a mais baixa.

Caso o nó 01 venha a falhar, caracterizando failover, quem assumiria seria o nó 02 (intermediário em hardware), somente se o nó 02 falhar é que o nó 03 seria ativado, ainda que o hardware seja bem obsoleto, as requisições seriam resolvidas e teríamos a caracterização do Cluster HA (alta disponibilidade).

Nas falhas dos nós 01 e 02, que puderam ser recuperadas e o servidor voltou a ativa o Pacemaker percebe que o nó 01 retornou ao cluster e analisa a prioridade do nó 01, sendo a prioridade do nó 01 -100 e a do nó 03 - 60 a alocação de recurso é transferida de volta para o nó 01 caracterizando failback.

Assim, para configurarmos as prioridades, utilizaremos o comando colocando após o grupo de recursos a prioridade e o nó:

# crm configure location HTTP_Server GrupodoServidor 100: no02

Podemos consultar a configuração do Pacemaker utilizando:

# crm configure show

E veremos que: location HTTP_Server GrupodoServidor 100: no02

Teste de Corosync e Pacemaker

Com todas as configurações realizadas, o Cluster HA está disponível e configurado, os recursos do cluster já estão disponíveis e seu endereço é http://192.168.0.100 e podemos acessá-lo no terminal apenas digitando no navegador de internet o endereço acima.

Podemos perceber que na requisição de protocolo HTTP, aparece no navegador a configuração que fizemos no arquivo /var/www/index.html, que é o arquivo padrão do Apache2, neste caso, é mostrado no navegador "No 02", pois os serviços estão alocados no servidor no02.

Agora podemos testar desligando o no02 ou interrompendo seu recurso:
  • Para desligar, usamos: shutdown -s now
  • Para parar o recurso, usamos: crm node standby nodo2

Assim que um dos dois comandos sejam realizados, podemos atualizar a página no navegador do terminal e veremos que o serviço continua ativo, embora o servidor no02 esteja com falha, mas podemos notar que a página mudou e agora mostra "No 01", ao religar o servidor no02 o serviço retorna ao nó com maior prioridade, neste caso no02, como já mencionado.

Os recursos do Cluster podem ser manipulados, onde é possível parar o recurso:

# crm resource stop NomedoRecurso

Trocando stop por start, faz com que o recurso seja iniciado. Para remover um recurso, utilizamos:

# crm configure delete NomedoRecurso

Página anterior     Próxima página

Páginas do artigo
   1. Introdução
   2. Arquitetura do Cluster de Alta Disponibilidade
   3. Os Softwares Corosync, Pacemaker e Distributed Replicated Block Device (DRBD)
   4. Implementação
   5. Configurações
   6. Configuração do DRBD
   7. Conclusão
Outros artigos deste autor

Configurando servidores DHCP, BIND, Squid, Sarg, Samba e algumas regras IPtables

MikroTik RouterOS 5.20 para provedores - Tutorial completo

Montagem de Cluster Beowulf

Leitura recomendada

GRUB e a senha de root - como atacar e proteger seu sistema

Oracle-XE servidor com acesso ssh - Debian Lenny 5.0

Sistema de arquivos criptografado

Configurando Linux para Desenvolvimento de Sites

Fedora Core 1 :: Firewall e update

  
Comentários
[1] Comentário enviado por fabio em 09/03/2015 - 10:16h

Excelente artigo, meus parabéns pelo trabalho!

[2] Comentário enviado por thyagobrasileiro em 10/03/2015 - 18:07h


Favoritado!

Irei tentar recriar no CentOS

[3] Comentário enviado por danilofugi em 10/03/2015 - 19:06h


[1] Comentário enviado por fabio em 09/03/2015 - 10:16h

Excelente artigo, meus parabéns pelo trabalho!


Obrigado!
ajudando a comunidade!

[4] Comentário enviado por danilofugi em 10/03/2015 - 19:07h


[2] Comentário enviado por thyagobrasileiro em 10/03/2015 - 18:07h


Favoritado!

Irei tentar recriar no CentOS


Obrigado, depois posta ai os resultados!

[5] Comentário enviado por rodrigo.kiyoshi em 10/03/2015 - 21:33h

Olá,
Vale ressaltar que, para este cenário, o uso de 3 interfaces de rede é o recomendável, em virtude do ip virtual.
O fato de não estar utilizando o recurso stonith, em caso de split brain (drbd), a intervenção manual se faz necessária.
Do mais, o artigo tá show de bola!

[6] Comentário enviado por danilofugi em 10/03/2015 - 21:49h


[5] Comentário enviado por rodrigo.kiyoshi em 10/03/2015 - 21:33h

Olá,
Vale ressaltar que, para este cenário, o uso de 3 interfaces de rede é o recomendável, em virtude do ip virtual.
O fato de não estar utilizando o recurso stonith, em caso de split brain (drbd), a intervenção manual se faz necessária.
Do mais, o artigo tá show de bola!


Vlw, pelos comentários e considerações!

[7] Comentário enviado por hevilavio em 12/03/2015 - 09:48h

Ótimo Artigo, parabéns!

[8] Comentário enviado por danilofugi em 12/03/2015 - 12:42h


[7] Comentário enviado por hevilavio em 12/03/2015 - 09:48h

Ótimo Artigo, parabéns!


Obrigado Helvilavio!

[9] Comentário enviado por felippem em 21/05/2015 - 15:32h

Olá amigo, estou tentando montar um cluster como esse so que eu queria utilizar o DRBD e o HeartBeat
Será que é possivel me ajudar?

[10] Comentário enviado por danilofugi em 21/05/2015 - 15:44h


[9] Comentário enviado por felippem em 21/05/2015 - 15:32h

Olá amigo, estou tentando montar um cluster como esse so que eu queria utilizar o DRBD e o HeartBeat
Será que é possivel me ajudar?


Olá felippem, com certeza que dá certo sim, tem um tutorial aqui no forum mesmo, vou te passar

http://www.vivaolinux.com.br/artigo/Alta-disponibilidade-com-Debian-Lenny-+-Heartbeat-+-DRBD8-+-OCFS...

único empasse é que deve utilizar o debian Lenny (5.X)

abraços

[11] Comentário enviado por Adonist em 24/03/2016 - 07:57h

Danilo,

Muito bom o seu tutorial. Porem replicando isso nao funcionou para mim na parte do DRBD.
Nao sei se eh por serem versoes diferentes mas na minha configuracao do r0.res eu tive que fazer o seguinte:

resource r0 {
on no01 {
device /dev/drbd0;
disk /dev/hdb1;
address 192.168.0.1:7793;
meta-disk internal;
}

on no02 {
device /dev/drbd0;
disk /dev/hdb1;
address 192.168.0.2:7793;
meta-disk internal;
}

Sendo que apos a opcao 'on' eh o nome da maquina e no resource eh o nome do arquivo que vc criou (r0.res).
Tambem precisei mudar os IP's pois estava conflitando ter as duas configuracoes no mesmo IP.

Valeu

[12] Comentário enviado por danilofugi em 26/03/2016 - 14:28h


[11] Comentário enviado por Adonist em 24/03/2016 - 07:57h

Danilo,

Muito bom o seu tutorial. Porem replicando isso nao funcionou para mim na parte do DRBD.
Nao sei se eh por serem versoes diferentes mas na minha configuracao do r0.res eu tive que fazer o seguinte:

resource r0 {
on no01 {
device /dev/drbd0;
disk /dev/hdb1;
address 192.168.0.1:7793;
meta-disk internal;
}

on no02 {
device /dev/drbd0;
disk /dev/hdb1;
address 192.168.0.2:7793;
meta-disk internal;
}

Sendo que apos a opcao 'on' eh o nome da maquina e no resource eh o nome do arquivo que vc criou (r0.res).
Tambem precisei mudar os IP's pois estava conflitando ter as duas configuracoes no mesmo IP.

Valeu


Agradeço pelo comentário, acabei esquecendo de editar o arquivo...
Caso se interesse, tente usar o software LCMC, faz toda a configuração de DRBD e Cluster pela interface Visual
vlw
abraços

[13] Comentário enviado por dalvasb em 05/09/2016 - 11:44h

Danilo,
você já montou dispositivos drbd com o pacemaker?
Eu consigo montar um, por exemplo, o drbd0, mas não consigo montar dois, não estou sabendo se preciso configurar de novo o resource drbd, ou apenas o resource de montar.

Dalva

[14] Comentário enviado por danilofugi em 05/09/2016 - 13:01h


[13] Comentário enviado por dalvasb em 05/09/2016 - 11:44h

Danilo,
você já montou dispositivos drbd com o pacemaker?
Eu consigo montar um, por exemplo, o drbd0, mas não consigo montar dois, não estou sabendo se preciso configurar de novo o resource drbd, ou apenas o resource de montar.

Dalva


Oi Dalva
Já montei sim e funcionam muito bem como a descrição acima, imagino o que deve estar acontecendo.
Tente o seguinte: esqueça a configuração do DRBD acima, monte seu cluster apenas instalando os pacotes e baixe um arquivo de configuração que se chama LCMC (executável em windows ou baixar um para linux) abra em outro terminal também conectado a rede
O LCMC irá buscar seus nós do cluster e você pode configurar os serviços de Apache DRBD Mysql do Cluster com simples cliques, acaba sendo mais fácil.
Poderá te auxiliar dando uma busca de video, Configuração LCMC DRBD, assim o Software LCMC fará todas as alterações listadas acima e funcionará perfeitamente

[15] Comentário enviado por llJllNllRll em 15/03/2018 - 18:24h

Durante a configuração do crm, sempre que eu o digitava no meu Debian 9.4, era emitida uma mensagem dizendo: "crm: comando não encontrado".

Só consegui resolver esse problema com a instalação do pacote: "#apt-get install crmsh"

Após, tudo prosseguiu sem problemas.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts