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


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ó:


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