Cluster de alta disponibilidade para servidores web com Debian 7.1 + Corosync + Pacemaker + DRBD [Artigo] - página 5
[ Hits: 50.931 ]
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:
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.
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
# 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:
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:
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.
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:
Podemos verificar se nosso cluster não tem nenhum problema da seguinte forma:
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:
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:
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:
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.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:
Testando a configuração no no02:
Teremos os seguintes retornos:
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:
Online: [ no01 no02 no03]
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:
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ó:
<h1>No 01</h1>
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:
Online: [ nodo1 nodo2 no03]
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.
# crm configure group GrupodoServidor RecursoApache IPdoApache
Novamente, vamos consultar os recursos:
Teremos o retorno da seguinte forma:
Resource Group: GrupodoServidor
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ó:
Podemos consultar a configuração do Pacemaker utilizando:
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.