Bom dia e Feliz Ano Novo!!
Hoje vou fazer um post sobre um principio muito importante aplicado e usado ao nível empresarial: A alta disponibilidade.
Embora tipicamente faça posts em RHEL ou CentOS, o post de hoje é mais abrangente, podendo ser utilizado em RHEL, CentOS e até Fedora 23.
O que é o conceito de HA (alta disponibilidade)?
Em termos muito abrangentes a techtarget define o mesmo como sendo:
Outra função extremamente útil dos mecanismos de HA é a capacidade de se poder efetuar manutenções na infra-esturtura sem causar indisponibilidade: Consegue-se efetuar manutenção num dos nós da solução enquanto o outro (ou outros nós) assumem a carga do serviço.
- A aplicação (ou aplicações) correm apenas num nó de forma ativa.
- A aplicação (ou aplicações) podem migrar de forma automática entre nós de forma a reagir a falhas de hardware ou software.
- A aplicação (ou aplicações) são agnósticas dos servidores onde estão em execução podendo executar da mesma forma em todos os membros do cluster.
Para o exemplo, utilizarei duas VPS CentOS 7.1 que assumo que já tenham instaladas.
Em primeiro lugar, será necessário que ambos os servidores se conheçam por FQDN e short host, adicionado em /etc/hosts:
172.16.3.151 xfvlab5.vfarm.net.xpto xfvlab5
172.16.3.152 xfvlab11.vfarm.net.xpto xfvlab11
Em seguida, é necessário configurar os users root de ambas as máquinas para que consigam aceder uma a outra via ssh sem password conforme descrito aqui.
Nota: Caso utilizem IDM/IPA e tenham cometido o erro de colocar o utilizador root como parte do mesmo, lembrem-se que a chave ssh tem de ser colocada no IDM/IPA.
Em seguida e após confirmarem que conseguem entrar em ambas as máquinas sem password efetuar:
# yum install -y pacemaker pcs psmisc policycoreutils-python
Em seguida e em ambos todos os membros do cluster será necessário habilitar comunicação em vários portos de forma a que os daemons de rede comuniquem entre eles:
# firewall-cmd –permanent –add-service=high-availability
success
# firewall-cmd –reload
success
Podemos caso optemos para tal, não utilizar firewall, em nenhum dos nossos sistemas, pelo que deveremos efetuar:
# systemctl disable firewalld.service
# systemctl stop firewalld.service
# iptables –flush
Nota: APENAS para despiste de problemas, caso necessitem desativar o SELinux efetuar:
# setenforce 0
# sed -i.bak “s/SELINUX=enforcing/SELINUX=permissive/g” /etc/selinux/config
(Não se esqueçam de reverter a configuração assim que possivel).
Em seguida, está na altura de arrancar com o servico em todos os membros do cluster:
# systemctl start pcsd.service
# systemctl enable pcsd.service
Nota: Os pacotes instalados criam um utilizador hacluster, com password bloqueada. Será necessário desbloquearem esse utilizador para continuar a instalação:
# echo hacluster:passw0rd | chpasswd
# ssh root@xfvlab11 ‘echo hacluster:passw0rd | chpasswd’
Em seguida, chegou a altura de configurar o mecanismo de Corosync do nosso cluster.
# pcs cluster auth xfvlab5 xfvlab11
Username: hacluster
Password:
xfvlab11: Authorized
xfvlab5: Authorized
Inicializando o ficheiro de configuração do Corosync e atribuindo o nome de cluster1 ao nosso ambiente de cluster:
# pcs cluster setup –name cluster1 xfvlab5 xfvlab11
Shutting down pacemaker/corosync services…
Redirecting to /bin/systemctl stop pacemaker.service
Redirecting to /bin/systemctl stop corosync.service
Killing any remaining services…
Removing all cluster configuration files…
xfvlab5: Succeeded
xfvlab11: Succeeded
Synchronizing pcsd certificates on nodes xvpar5, xvpar11…
xfvlab11: Success
xfvlab5: Success
Restaring pcsd on the nodes in order to reload the certificates…
xfvlab11: Success
xfvlab5: Success
Chegamos agora á parte de configuração dos recursos do cluster (as aplicações, IP’s, discos partilhados).
Este componente tem o nome de pacemaker, e é responsavel pela gestão de recursos.
O pacemaker pode ser configurado de duas formas, ou webGUI ou por CLI, sendo que neste post iremos apenas utilizar o CLI.
Em primeiro lugar iremos arrancar com o cluster:
# pcs cluster start –all
xfvlab5: Starting Cluster…
xfvlab11: Starting Cluster…
E em seguida colocamos os mecanismos de cluster activos em ambos os membros do mesmo:
# systemctl enable pacemaker.service
Created symlink from /etc/systemd/system/multi-user.target.wants/pacemaker.service to /usr/lib/systemd/system/pacemaker.service.
# systemctl enable corosync.service
Created symlink from /etc/systemd/system/multi-user.target.wants/corosync.service to /usr/lib/systemd/system/corosync.service.
Nota: o comando de enable para ambos os serviços tem de ser executado em ambos os membros do cluster.
Verificando o status do cluster:
# corosync-cfgtool -s
Printing ring status.
Local node ID 1
RING ID 0
id = 10.0.0.1
status = b
# corosync-cmapctl | grep members
runtime.totem.pg.mrp.srp.members.1.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.1.ip (str) = r(0) ip(10.0.0.1)
runtime.totem.pg.mrp.srp.members.1.join_count (u32) = 1
runtime.totem.pg.mrp.srp.members.1.status (str) = joined
runtime.totem.pg.mrp.srp.members.2.config_version (u64) = 0
runtime.totem.pg.mrp.srp.members.2.ip (str) = r(0) ip(10.0.0.2)
runtime.totem.pg.mrp.srp.members.2.join_count (u32) = 1
runtime.totem.pg.mrp.srp.members.2.status (str) = joined
# pcs status
Cluster name: cluster1
WARNING: no stonith devices and stonith-enabled is not false
Last updated: Thu Dec 17 15:18:35 2015 Last change: Thu Dec 17 15:11:06 2015 by hacluster via crmd on xfvlab5
Stack: corosync
Current DC: xfvlab5 (version 1.1.13-3.fc23-44eb2dd) – partition with quorum
2 nodes and 0 resources configured
Online: [ xfvlab11 xfvlab5 ]
Full list of resources:
PCSD Status:
xvpar5 member (xvpar5): Online
xvpar11 member (xvpar11): Online
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
Finalmente:
# journalctl | grep -i error
Dec 17 15:11:08 xfvlab5 [4017]: error: NOTE: Clusters with shared data need STONITH to ensure data integrity
Dec 17 15:11:08 xfvlab5 [4017]: notice: Configuration ERRORs found during PE processing. Please run “crm_verify -L” to identify issues.
Dec 17 15:11:08 xfvlab5 [4017]: error: Resource start-up disabled since no STONITH resources have been defined
Dec 17 15:11:08 xfvlab5 [4017]: error: Either configure some or disable STONITH with the stonith-enabled option
Dec 17 15:11:08 xfvlab5 [4017]: error: NOTE: Clusters with shared data need STONITH to ensure data integrity
Dec 17 15:11:08 xfvlab5 [4017]: notice: Configuration ERRORs found during PE processing. Please run “crm_verify -L” to identify issues.
Notem que o mecanismo de validação de configuração do cluster notou que há um erro na configuração (causado por não ter um stonith device – na pratica um fencing device).
É igualmente sugerido pela stack de cluster, uma forma de entender o que se está a passar: Please run “crm_verify -L”
# crm_verify -L -V
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
Por defeito, é sempre recomendado um fence device, mas pode haver configurações onde não se aplica, ou não é necessário por não existir shared storage.
By default, o pacemaker implementa a configuração de fencing mas com a multitude de configurações possiveis, um descritivo das mesmas será abordado num post só seu, pelo que agora iremos desactivar o mecanismo:
# pcs property set stonith-enabled=false
Validando:
# crm_verify -L -V
(já não aparecem erros)
Nota: Não utilizem em produção e com dados importantes um cluster sem o fence device configurado sob pena de corrupção séria ou destruição dos vossos dados.
Finalmente chegamos ao fim de este post longo, mas que toca num campo extremamente utilizado em ambientes criticos de alta disponibilidade.
Em breve irei efetuar a conclusão desta configuração, até lá um abraço
Se tiverem duvidas, já sabem como me contactar.
Nuno Higgs