Quem já foi a um estabelecimento comercial – supermercado, por exemplo – e presenciou uma interrupção momentânea no fornecimento de energia elétrica, presenciou provavelmente um exemplo de alta disponibilidade. Ou seja, a rápida restauração do serviço – fornecimento de energia elétrica – minimizando nesse caso o tempo no escuro. Esse é o conceito. Para se ter alta disponibilidade é preciso redundância – rede elétrica e gerador de energia – e um mecanismo capaz de detectar falhas no fornecimento da rede elétrica e ligar o gerador automaticamente – chave de transferência automática. Dito isso, a proposta desse post é substituindo a energia elétrica por uma página web, a rede elétrica e o gerador de energia por duas placas Raspberry Pi e o mecanismo de detecção de falhas por softwares – Corosync e Pacemaker – criar um conjunto de dois ou mais computadores, um cluster de alta disponibilidade Linux.
Com isso, minimizamos o tempo fora do ar da página web, pois parafraseando um ditado conhecido “quem tem dois tem um, que tem um não tem nenhum”, que poderia ser o slogan de alta disponibilidade e deveria ser a política de quem trabalha com administração de sistemas e infraestrutura de redes.
Material necessário
Para realizar este projeto, vamos precisar de:
- 2 x Raspberry Pi 3 Modelo B+
- 2 x Cartão SD
- 2 x Fonte 5 V
Nos cartões SD é necessário estar gravado o sistema operacional Raspbian, de preferência o Lite. Qualquer dúvida de como isso deve ser feito, você pode consultar este post.
O que são Corosync e Pacemaker?
O Corosync é responsável pela associação, sincronismo e detecção de falhas do membros do cluster de alta disponibilidade Linux – também conhecidos como nodes ou nós, nesse post referidos como nodes. O Pacemaker é um gerenciador de recursos de cluster (cluster resource manager), um sistema que administra recursos – endereço IP e servidor web, por exemplo – disponibilizados pelo cluster.
Configurando Corosync e Pacemaker
Para começar precisamos de algum tipo de acesso ao terminal, seja remoto via ssh ou local via teclado. Tudo certo? Então vamos lá!
A convenção seguida é que [TODOS] indica um comando que precisa ser executado em todas as máquinas do cluster de alta disponibilidade Linux. [NODE1] e [NODE2] indica um comando que precisa ser executado individualmente na respectiva máquina.
É uma boa prática atribuir manualmente o endereço IP dos nodes, para isso vamos editar o arquivo. [TODOS]
|
1 |
vim /etc/dhcpcd.conf |
E incluir o conteúdo abaixo no final (fique atento aos comentários). [TODOS]
|
1 2 3 4 5 |
interface eth0 # SUBSTITUA "192.168.0.1" PELO ENDEREÇO IP DO SEU RASPBERRY PI. static ip_address=192.168.0.1/24 # SUBSTITUA "192.168.0.1" PELO ENDEREÇO IP DO SEU ROTEADOR. static routers=192.168.0.1 |
Agora vamos instalar os pacotes, nosso cluster será baseado no Corosync e Pacemaker. [TODOS]
|
1 2 |
apt-get update apt-get install pacemaker corosync crmsh |
É uma boa prática fazer uma cópia do arquivo de configuração antes de editá-lo. [TODOS]
|
1 |
cp -p /etc/corosync/corosync.conf /etc/corosync/corosync.conf.default |
Agora iremos limpar o conteúdo do arquivo. [TODOS]
|
1 |
echo "" > /etc/corosync/corosync.conf |
Editá-lo. [TODOS]
|
1 |
vim /etc/corosync/corosync.conf |
E incluir o conteúdo abaixo (fique atento aos comentários!). [TODOS]
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 |
totem { # Especifica a versão do arquivo de configuração. # Atualmente, a única versão válida para esta diretiva é 2. version: 2 # Especifica o nome do cluster. cluster_name: pacemaker1 # Quanto tempo antes de declarar um token perdido (ms). token: 3000 # Quantos tokens são retransmitidos antes de formar uma nova configuração. token_retransmits_before_loss_const: 10 # Limita nodeids a 31 bits (números inteiros com sinal positivo). clear_node_high_bit: yes # Usado para autenticação mútua dos nodes. # Necessário criar uma chave compartilhada com "corosync-keygen". # Habilitar crypto_cipher, requer também a habilitação de crypto_hash. crypto_cipher: aes256 crypto_hash: sha1 # Esta diretiva controla o mecanismo de transporte usado. # Unicast (udpu), que requer uma lista de membros na seção nodelist {}. transport: udpu # Define a interface para se comunicar. interface { # O ringnumber deve ser numerado consecutivamente, começando em 0. ringnumber: 0 # Especifica o endereço onde o Corosync deve se vincular. # O bindnetaddr deve ser o endereço IP configurado no sistema ou o endereço de rede. # Por exemplo, se o endereço IP configurado no sistema for 192.168.0.1 com a máscara de # rede 255.255.255.0, você deve definir bindnetaddr como 192.168.0.1 ou 192.168.0.0. # Definindo bindnetaddr como endereço de rede poderemos usar esse mesmo arquivo # de configuração para todos os outros nós do cluster. # SUBSTITUA O ENDEREÇO DE REDE 192.168.0.0 DE ACORDO COM SUA REDE. bindnetaddr: 192.168.0.0 } } logging { # Em caso de dúvida, deixe "off". fileline: off # Em caso de dúvida, deixe "no". to_stderr: no # Em caso de dúvida, deixe "no". to_logfile: no # Em caso de dúvida, deixe "yes". to_syslog: yes # Em caso de dúvida, deixe "daemon". syslog_facility: daemon # Em caso de dúvida, deixe "off". debug: off # Em caso de dúvida, deixe "on". timestamp: on logger_subsys { subsys: QUORUM debug: off } } quorum { # O serviço votequorum faz parte do projeto Corosync. # Esse serviço pode ser opcionalmente carregado nos nodes do cluster Corosync para evitar situações de split-brain. # Isso é feito atribuíndo um número de votos esperados e garantindo que somente com a maioria dos votos # as operações do cluster possam prosseguir. provider: corosync_votequorum # votequorum requer um valor de votos esperados para funcionar, isso pode ser fornecido de duas maneiras. # O número de votos esperados será calculado automaticamente quando a seção nodelist {} estiver presente em # corosync.conf ou quando expected_votes estiver presente na seção de quorum {}. # A falta de ambos desativará o voto. Se ambos estiverem presentes ao mesmo tempo, o valor expected_votes # substituirá o calculado a partir da lista de nodes. expected_votes: 2 # O cluster de dois nodes (two node cluster) é um caso de uso que requer atenção especial. # Com um cluster de dois nodes, cada node com um voto, há dois votos no cluster. # Usando o cálculo da maioria simples (50% dos votos + 1) para calcular o quórum, o quórum seria 2. # Isso significa que os dois nodes sempre precisariam estar ativos para que o cluster operasse. # Ativando two_node: 1, o quorum é definido artificialmente como 1. two_node: 1 } # Dentro da seção nodelist {}, é possível especificar informações sobre os nodes do cluster. nodelist { node { # Especifica o endereço IP do node. # SUBSTITUA O ENDEREÇO IP 192.168.0.1 PELO ENDEREÇO IP DO PRIMEIRO NODE. ring0_addr: 192.168.0.1 } node { # Especifica o endereço IP do node. # SUBSTITUA O ENDEREÇO IP 192.168.0.2 PELO ENDEREÇO IP DO SEGUNDO NODE. ring0_addr: 192.168.0.2 } } |
Para garantir a autenticidade e a privacidade das mensagens trocadas entre os nodes do cluster, iremos gerar uma chave privada. [NODE1]
|
1 |
corosync-keygen |
Se o resultado for algo parecido com.
|
1 2 3 4 5 6 |
Corosync Cluster Engine Authentication key generator. Gathering 1024 bits for key from /dev/random. Press keys on your keyboard to generate entropy. Press keys on your keyboard to generate entropy (bits = 928). Press keys on your keyboard to generate entropy (bits = 1000). Writing corosync key to /etc/corosync/authkey. |
Tudo certo, podemos seguir.
Precisamos enviar o arquivo contendo a chave para o outro node do cluster. [NODE1]
Atenção! Não esqueça de substituir o nome de usuário (pi) e o endereço IP (192.168.0.2), caso necessário.
|
1 |
rsync -avz /etc/corosync/authkey pi@192.168.0.2:/tmp/ |
Vamos mover o arquivo para o diretório correto. [NODE2]
|
1 |
mv /tmp/authkey /etc/corosync/ |
Corrigir as permissões. [NODE2]
|
1 |
chown root. /etc/corosync/authkey |
E reiniciar os serviços. [TODOS]
|
1 2 |
systemctl restart corosync systemctl restart pacemaker |
Verificando a instalação do Corosync
Primeiro vamos verificar se a comunicação do cluster está funcionando. [TODOS]
|
1 |
corosync-cfgtool -s |
Podemos ver que tudo parece normal, o nosso endereço IP listado como o id (não o endereço 127.0.0.1) e sem falhas para o status.
|
1 2 3 4 5 |
Printing ring status. Local node ID 1217522751 RING ID 0 id = 192.168.0.1 status = ring 0 active with no faults |
Em seguida, verificar as APIs de associação e o quórum. [NODE1] ou [NODE2]
|
1 |
corosync-cmapctl | grep members |
Se o resultado for algo parecido com.
|
1 2 3 4 5 6 7 8 |
runtime.totem.pg.mrp.srp.members.1217522751.config_version (u64) = 0 runtime.totem.pg.mrp.srp.members.1217522751.ip (str) = r(0) ip(192.168.0.1) runtime.totem.pg.mrp.srp.members.1217522751.join_count (u32) = 1 runtime.totem.pg.mrp.srp.members.1217522751.status (str) = joined runtime.totem.pg.mrp.srp.members.1217522754.config_version (u64) = 0 runtime.totem.pg.mrp.srp.members.1217522754.ip (str) = r(0) ip(192.168.0.2) runtime.totem.pg.mrp.srp.members.1217522754.join_count (u32) = 1 runtime.totem.pg.mrp.srp.members.1217522754.status (str) = joined |
Tudo certo.
Verificando a instalação do Pacemaker
Agora que confirmamos que o Corosync está funcionando, podemos verificar o restante da pilha. [NODE1] ou [NODE2]
|
1 |
crm status |
O resultado deve ser algo como.
|
1 2 3 4 5 6 7 8 9 10 11 |
Stack: corosync Current DC: node2 (version 1.1.16-94ff4df) - partition with quorum Last updated: Mon Jul 29 09:33:22 2019 Last change: Mon Jul 29 09:31:03 2019 by hacluster via crmd on node2 2 nodes configured 0 resources configured Online: [ node1 node2 ] No resources |
Antes de fazermos qualquer alteração, é uma boa ideia verificar a validade da configuração do cluster de alta disponibilidade Linux. [NODE1] ou [NODE2]
|
1 |
crm_verify -L -V |
Como você pode ver, a ferramenta encontrou alguns erros.
|
1 2 3 4 |
error: unpack_resources: Resource start-up disabled since no STONITH resources have been defined error: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option error: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity Errors found during check: config not valid |
A fim de garantir a segurança de seus dados, fencing (STONITH) é habilitado por padrão.
No entanto, ele também sabe quando nenhuma configuração STONITH foi fornecida e relata isso como um problema.
Desativaremos esse recurso por enquanto. [NODE1] ou [NODE2]
|
1 |
crm configure property stonith-enabled=false |
Adicionando recurso – endereço IP
Independentemente de onde os serviços do cluster estão sendo executados, os usuários precisam de um endereço IP consistente para contatá-los. Aqui, vou escolher 192.168.0.10 como o endereço flutuante, dar-lhe o nome de FloatIP e dizer ao cluster para verificar se ele está em execução a cada 10 segundos.
Atenção! Não se esqueça de substituir o endereço IP (192.168.0.10) de acordo com sua rede. O endereço escolhido não deve estar em uso na rede. [NODE1] ou [NODE2]
|
1 |
crm configure primitive FloatIP ocf:heartbeat:IPaddr2 params ip=192.168.0.10 nic=eth0 cidr_netmask=24 op monitor interval=10s |
Agora, vamos verificar se o recurso IP foi adicionado. [NODE1] ou [NODE2]
|
1 |
crm status |
Como você pode ver, o endereço IP (FloatIP) foi iniciado no node1.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
Stack: corosync Current DC: node2 (version 1.1.16-94ff4df) - partition with quorum Last updated: Mon Jul 29 09:38:10 2019 Last change: Mon Jul 29 09:38:02 2019 by root via cibadmin on node1 2 nodes configured 1 resource configured Online: [ node1 node2 ] Full list of resources: FloatIP (ocf::heartbeat:IPaddr2): Started node1 |
Para verificar, no node onde o endereço IP foi iniciado, nesse exemplo node1.
|
1 |
ip a |
Veremos então dois endereços IP: o endereço IP do node e o endereço IP flutuante.
|
1 2 3 4 |
inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0 valid_lft forever preferred_lft forever inet 192.168.0.10/24 brd 192.168.0.255 scope global secondary eth0 valid_lft forever preferred_lft forever |
Adicionando recurso – servidor web
Agora que temos um cluster básico mas funcional, estamos prontos para adicionar um serviço real. Mais especificamente um servidor web, pois além de ser usado em muitos clusters é relativamente simples de configurar.
Nosso servidor web será baseado no Apache, vamos a instalação. [TODOS]
|
1 2 |
apt-get update apt-get install apache2 |
Os serviços devem ser gerenciados pelo cluster nunca pelo sistema operacional. Por isso, iremos parar e desativar o serviço do Apache na inicialização do sistema. [TODOS]
|
1 2 |
systemctl stop apache2 systemctl disable apache2 |
Precisamos criar uma página para o Apache servir. [TODOS]
|
1 2 3 4 5 |
cat <<-END >/var/www/html/index.html <html> <body> Site Teste - $(hostname)</body> </html> END |
Neste ponto, o Apache está pronto para funcionar e tudo o que precisa ser feito é adicioná-lo ao cluster de alta disponibilidade Linux . Dando-lhe o nome de WebSite e dizendo ao cluster para verificar se ele está em execução a cada 60 segundos. [NODE1] ou [NODE2]
|
1 2 3 4 |
crm configure primitive WebSite ocf:heartbeat:apache params \ configfile=/etc/apache2/apache2.conf \ statusurl="http://localhost/server-status" \ op monitor interval=60s |
Após alguns segundos, devemos ver o cluster iniciar o Apache. [NODE1] ou [NODE2]
|
1 |
crm status |
O resultado deve ser algo como.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
Stack: corosync Current DC: node2 (version 1.1.16-94ff4df) - partition with quorum Last updated: Mon Jul 29 10:46:55 2019 Last change: Mon Jul 29 10:46:35 2019 by root via cibadmin on node1 2 nodes configured 2 resources configured Online: [ node1 node2 ] Full list of resources: FloatIP (ocf::heartbeat:IPaddr2): Started node1 WebSite (ocf::heartbeat:apache): Started node2 |
Espere um momento, o servidor web (WebSite) não está sendo executado no mesmo node que o endereço IP (FloatIP)!
Por otimização, o Pacemaker geralmente distribuirá os recursos entre os nodes do cluster. No entanto, podemos dizer ao cluster que dois recursos estão relacionados e precisam ser executados no mesmo node. Vamos informar o cluster que o WebSite deve executar apenas no node em que o FloatIP está ativo. [NODE1] ou [NODE2]
|
1 |
crm configure colocation WebSite-with-FloatIP inf: WebSite FloatIP |
E verificar se a alteração ocorreu com sucesso. [NODE1] ou [NODE2]
|
1 |
crm status |
O resultado deve ser algo como.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
Stack: corosync Current DC: node2 (version 1.1.16-94ff4df) - partition with quorum Last updated: Mon Jul 29 10:49:52 2019 Last change: Mon Jul 29 10:49:41 2019 by root via cibadmin on node1 2 nodes configured 2 resources configured Online: [ node1 node2 ] Full list of resources: FloatIP (ocf::heartbeat:IPaddr2): Started node1 WebSite (ocf::heartbeat:apache): Started node1 |
Para ter certeza de que nossa página responda independentemente da configuração de endereço do Apache, precisamos fazer com que o FloatIP seja iniciado antes do WebSite. [NODE1] ou [NODE2]
|
1 |
crm configure order FloatIP-before-WebSite inf: FloatIP WebSite |
Para verificar se a alteração ocorreu com sucesso. [NODE1] ou [NODE2]
|
1 |
crm configure show |
Aqui podemos ver toda configuração que fizemos até agora.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
node 1217522751: node1 node 1217522754: node2 primitive FloatIP IPaddr2 \ params ip=192.168.0.10 nic=eth0 cidr_netmask=24 \ op monitor interval=10s primitive WebSite apache \ params configfile="/etc/apache2/apache2.conf" statusurl="http://localhost/server-status" \ op monitor interval=60s order FloatIP-before-WebSite inf: FloatIP WebSite colocation WebSite-with-FloatIP inf: WebSite FloatIP property cib-bootstrap-options: \ have-watchdog=false \ dc-version=1.1.16-94ff4df \ cluster-infrastructure=corosync \ cluster-name=debian \ stonith-enabled=false |
Testando o cluster de alta disponibilidade linux
Em primeiro lugar, localize o node onde o endereço IP flutuante (FloatIP) e a página web (WebSite) estão sendo executados. [NODE1] ou [NODE2]
|
1 |
crm status |
Nesse exemplo, node1.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
Stack: corosync Current DC: node2 (version 1.1.16-94ff4df) - partition with quorum Last updated: Mon Jul 29 11:35:09 2019 Last change: Mon Jul 29 10:53:09 2019 by root via cibadmin on node1 2 nodes configured 2 resources configured Online: [ node1 node2 ] Full list of resources: FloatIP (ocf::heartbeat:IPaddr2): Started node1 WebSite (ocf::heartbeat:apache): Started node1 |
Agora abra um navegador e digite o endereço IP flutuante, no meu caso 192.168.0.10.
Confirmando o cluster (crm status), no momento a página web está sendo servida pelo node1.
Legal, agora vamos simular uma falha no node1 e ver o que acontece. [NODE1]
|
1 |
crm cluster stop |
Localize novamente o node onde o endereço IP flutuante (FloatIP) e a página web (WebSite) estão sendo executados. [NODE2]
|
1 |
crm status |
Agora estão no node2, inclusive podemos ver que o node1 está offline (na visão do cluster).
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
Stack: corosync Current DC: node2 (version 1.1.16-94ff4df) - partition with quorum Last updated: Mon Jul 29 12:08:33 2019 Last change: Mon Jul 29 10:53:09 2019 by root via cibadmin on node1 2 nodes configured 2 resources configured Online: [ node2 ] OFFLINE: [ node1 ] Full list of resources: FloatIP (ocf::heartbeat:IPaddr2): Started node2 WebSite (ocf::heartbeat:apache): Started node2 |
Abra um navegador e digite o endereço IP flutuante, no meu caso 192.168.0.10.
Mesmo com o node1 offline a página web continua disponível, mas agora servida pelo node2.
Não se esqueça de iniciar o cluster novamente após os testes. [NODE1]
|
1 |
crm cluster start |
Esse é um assunto interessante e extenso, mas com certeza é um bom começo.
Gostou de criar um cluster de alta disponibilidade linux com Raspberry Pi? Ajude-nos a melhorar o blog comentando abaixo sobre este tutorial.
Até a próxima!!
