RHEL7 Failover Cluster
In questo tutorial vedremo come creare un cluster tra due macchine virtuali Red Hat Enterprise Linux (RHEL) 7. Io le ho installate su piattaforma ESXi, con 2 vPCU e 2 GB di RAM ciascuna, ma questo è un dettaglio. Sono necessari tre indirizzi IP, uno per ciascun server RHEL ed uno come IP virtuale, il cluster appunto. Le macchine virtuali devono comunicare tra loro.
Nella mia architettura gli elementi in gioco sono questi:
- Server 1
- Name: vm-rh74-svr1
- IP: 192.168.0.124
- Server 2
- Name: vm-rh74-svr2
- IP: 192.168.0.125
- Cluster VIP
- IP: 192.168.0.126
Installazione
Installiamo il sistema operativo RHEL 7.x con una configurazione minima su entrambi i server e configuriamoli con un indirizzo IP statico. Per evitare problemi di comunicazione tra i nodi disabilitiamo SELinux e disattiviamo il firewall su entrambi.
Una volta installato, inseriamo una voce per ciascun nodo all’interno del file /etc/hosts per la risoluzione dei nomi, su entrambe le macchine virtuali.
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.0.124 vm-rh74-svr1 vm-rh74-svr1.localdomain
192.168.0.125 vm-rh74-svr2 vm-rh74-svr2.localdomain
Se non si dispone di una Subscription RHEL attiva, configuriamo il repository locale per yum, uno per i pacchetti RHEL standard e uno per il gruppo di pacchetti HighAvailability.
# echo "[rhel-dvd]" > /etc/yum.repos.d/rhel-dvd.repo
# echo "name=rhel-dvd" >> /etc/yum.repos.d/rhel-dvd.repo
# echo "baseurl=file:///mnt/cdrom" >> /etc/yum.repos.d/rhel-dvd.repo
# echo "enabled=1" >> /etc/yum.repos.d/rhel-dvd.repo
# echo "gpgcheck=0" >> /etc/yum.repos.d/rhel-dvd.repo
# echo "[rhel-ha-dvd]" > /etc/yum.repos.d/rhel-ha-dvd.repo
# echo "name=rhel-ha-dvd" >> /etc/yum.repos.d/rhel-ha-dvd.repo
# echo "baseurl=file:///mnt/cdrom/addons/HighAvailability" >> /etc/yum.repos.d/rhel-ha-dvd.repo
# echo "enabled=1" >> /etc/yum.repos.d/rhel-ha-dvd.repo
# echo "gpgcheck=0" >> /etc/yum.repos.d/rhel-ha-dvd.repo
Installiamo pcs pacemaker fence-agents-all su entrambe le macchine virtuali.
# yum --disablerepo=\* --enablerepo=rhel-dvd,rhel-ha-dvd install pcs pacemaker fence-agents-all
Per poter utilizzare pcs per la configurazione del cluster e permettere la comunicazione tra i nodi, è necessario impostare una password su ogni nodo per lo user ID hacluster, che è l’account di pcs administration. E’ consigliato usare la stessa password per l’utente hacluster su ciascun nodo.
# passwd hacluster
Changing password for user hacluster.
New password:
Retype new password:
A questo punto avviamo pscd, corosync e pacemaker su entrambi i nodi.
# systemctl start pcsd.service
# systemctl enable pcsd.service
# systemctl daemon-reload
# systemctl start corosync.service
# systemctl enable corosync.service
# systemctl daemon-reload
# systemctl start pacemaker.service
# systemctl enable pacemaker.service
# systemctl daemon-reload
A questo punto procediamo con l’autenticazione dell’utente psc hacluster per ciascun nodo.
# pcs cluster auth vm-rh74-svr1 vm-rh74-svr2
Username: hacluster
Password:
vm-rh74-svr1: Authorized
vm-rh74-svr2: Authorized
Configurazione del Cluster
Una volta installato pcs, è necessario eseguire il seguente comando da vm-rh74-svr1 per creare il cluster vm-rh74-cluster composto dai due nodi vm-rh74-svr1 e vm-rh74-svr2. Questo propagherà i file di configurazione del cluster a entrambi i nodi.
# pcs cluster setup --start --name vm-rh74-cluster vm-rh74-svr1 vm-rh74-svr2
Quindi controlliamo lo stato del cluster.
# pcs cluster status
Cluster Status:
Stack: corosync
Current DC: vm-rh74-svr2 (version 1.1.16-12.el7-94ff4df) - partition with quorum
Last updated: Mon Jun 18 17:06:32 2018
Last change: Mon Jun 18 17:06:07 2018 by hacluster via crmd on vm-rh74-svr2
2 nodes configured
0 resources configured
PCSD Status:
vm-rh74-svr1: Online
vm-rh74-svr2: Online
Aggiungiamo la risorsa VirtualIP.
# pcs resource create VirtualIP IPaddr2 ip=192.168.0.126 cidr_netmask=24 --group mygroup
Quindi controlliamo nuovamente lo stato del cluster.
# pcs status
Cluster name: vm-rh74-cluster
WARNING: no stonith devices and stonith-enabled is not false
Stack: corosync
Current DC: vm-rh74-svr2 (version 1.1.16-12.el7-94ff4df) - partition with quorum
Last updated: Mon Jun 18 17:23:59 2018
Last change: Mon Jun 18 17:19:19 2018 by root via cibadmin on vm-rh74-svr1
2 nodes configured
1 resource configured
Online: [ vm-rh74-svr1 vm-rh74-svr2 ]
Full list of resources:
Resource Group: mygroup
VirtualIP (ocf::heartbeat:IPaddr2): Stopped
Daemon Status:
corosync: active/disabled
pacemaker: active/disabled
pcsd: active/enabled
Il messaggio sopra indica che la risorsa VirtualIP è stata arrestata e ciò significa che ci sono errori con il cluster. Per verificare la presenza di errori nella configurazione e se ce ne sono ancora possiamo utilizzare il seguente comando.
# 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
Dal messaggio sopra c’è ancora un errore relativo a STONITH (Shoot The Other Node In The Head), che è un meccanismo utilizzato per garantire di non trovarsi nella situazione in cui entrambi i nodi pensano di essere attivi e proprietari dell’IP virtuale, chiamata anche situazione split brain. Poiché noi abbiamo un cluster semplice, disabiliteremo semplicemente l’opzione stonith.
# pcs property set stonith-enabled=false
Possiamo anche configurare le impostazioni del quorum. Il quorum descrive il numero minimo di nodi nel cluster che devono essere attivi affinché il cluster sia disponibile e, per impostazione predefinita, il quorum è considerato troppo basso se il numero totale di nodi è inferiore al doppio del numero di nodi attivi . Ciò significa che per un cluster a 2 nodi entrambi i nodi devono essere disponibili affinché il cluster sia disponibile. Nel nostro caso questo non avrebbe senso, perché stiamo sperimentando un cluster a due nodi, quindi disabilitiamo il controllo sul quorum.
# pcs property set no-quorum-policy=ignore
Per evitare situazioni di split brain, possiamo configurare un vincolo di posizione per le risorse del cluster in modo da preferire un nodo. Un valore INFINITY per lo score indica che la risorsa preferirà quel nodo se il nodo è disponibile, ma non impedisce l’esecuzione della risorsa su un altro nodo se il nodo specificato non è disponibile.
# pcs constraint location mygroup prefers vm-rh74-svr1 INFINITY
# pcs constraint --full
Location Constraints:
Resource: mygroup
Enabled on: vm-rh74-svr1 (score:INFINITY) (id:location-mygroup-vm-rh74-svr1-INFINITY)
Enabled on: INFINITY (score:INFINITY) (id:location-mygroup-INFINITY-INFINITY)
Ordering Constraints:
Colocation Constraints:
Ticket Constraints:
Controlliamo lo stato con entrambi i nodi attivi.
# pcs status
Cluster name: vm-rh74-cluster
Stack: corosync
Current DC: vm-rh74-svr2 (version 1.1.16-12.el7-94ff4df) - partition with quorum
Last updated: Tue Jun 19 11:11:05 2018
Last change: Tue Jun 19 10:45:09 2018 by root via cibadmin on vm-rh74-svr1
2 nodes configured
1 resource configured
Online: [ vm-rh74-svr1 vm-rh74-svr2 ]
Full list of resources:
Resource Group: mygroup
VirtualIP (ocf::heartbeat:IPaddr2): Started vm-rh74-svr1
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
Dal messaggio precedente il cluster è online e la risorsa VirtualIP è assegnata al nodo vm-rh74-svr1.
Ora spegniamo il nodo vm-rh74-svr1 e controlliamo lo stato.
# pcs status
Cluster name: vm-rh74-cluster
Stack: corosync
Current DC: vm-rh74-svr2 (version 1.1.16-12.el7-94ff4df) - partition with quorum
Last updated: Tue Jun 19 11:18:59 2018
Last change: Tue Jun 19 10:45:09 2018 by root via cibadmin on vm-rh74-svr1
2 nodes configured
1 resource configured
Online: [ vm-rh74-svr2 ]
OFFLINE: [ vm-rh74-svr1 ]
Full list of resources:
Resource Group: mygroup
VirtualIP (ocf::heartbeat:IPaddr2): Started vm-rh74-svr2
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
Dal messaggio precedente il cluster è ancora online e la risorsa VirtualIP è ora avviata sul secondo nodo vm-rh74-svr2.
Riavviamo quindi il nodo vm-rh74-svr1 e, dopo l’avvio, controlliamo nuovamente lo stato.
# pcs status
Cluster name: vm-rh74-cluster
Stack: corosync
Current DC: vm-rh74-svr2 (version 1.1.16-12.el7-94ff4df) - partition with quorum
Last updated: Tue Jun 19 11:20:55 2018
Last change: Tue Jun 19 10:45:09 2018 by root via cibadmin on vm-rh74-svr1
2 nodes configured
1 resource configured
Online: [ vm-rh74-svr1 vm-rh74-svr2 ]
Full list of resources:
Resource Group: mygroup
VirtualIP (ocf::heartbeat:IPaddr2): Started vm-rh74-svr1
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
Come possiamo vedere il cluster è online e la risorsa VirtualIP è ora avviata sul primo nodo vm-rh74-svr1. Ciò è accaduto perché abbiamo configurato un vincolo di posizione per le risorse del cluster per preferire il nodo vm-rh74-svr1.
Concludiamo dicendo che i test di migrazione del cluster possono essere eseguiti anche con il seguente comando:
# pcs cluster stop vm-rh74-svr1
vm-rh74-svr1: Stopping Cluster (pacemaker)...
vm-rh74-svr1: Stopping Cluster (corosync)...
# pcs cluster start vm-rh74-svr1
vm-rh74-svr1: Starting Cluster...