Cluster Linux in test con Pacemaker, Corosync e pcs

Introduzione

Con questo articolo realizziamo un cluster su Linux con Pacemaker e Corosync tramite i comandi pcs (Pacemaker/Corosync Configuration System) in modo da semplificare un po’ la vita durante la configurazione.

Inizialmente, analizziamo passo passo la realizzazione di un cluster Linux su un ambiente di test virtualizzato con VirtualBox infine automatizziamo tutto usando Vagrant.

Le esigenze principali per decidere di creare un cluster invece che di un singolo server o singolo servizio per un’azienda possono essere riassunte con queste considerazioni:

avere una ridondanza dei server/servizi nel caso in cui si verifichi un guasto;
aver la possibilità di poter aggiornare agevolmente il server oppure un servizio lavorando prima su un nodo (messo in manutenzione) ed infine sull’altro senza interrompere il funzionamento agli utilizzatori;
poter fare un backup completo e consistente su un nodo in manutenzione mentre sono attivi i servizi negli altri nodi.

Istallazione nodo principale del cluster

Supponiamo di avere già installato Virtualbox e scaricato l’iso di Centos 7 quindi creiamo una nuova vm Centos7 con:

almeno 1GB di memoria;
con nome centos7-minimal (Linux – RedHat 64 bit);
con 3 schede di rete e precisamente:
- la prima “NAT” per la normale navigazione;
- la seconda come “Rete interna” per gestire la rete di cluster (useremo la sotto rete 192.168.33.0/24);
- l’ultima come “Rete interna” per gestire i collegamenti alle operazioni di fence/stonith dopo un guasto ad un nodo per poterlo riavviare o spegnere del tutto in base alla configurazione scelta (useremo la sotto rete 192.168.43.0/24);
aggiungiamo 1 disco al controller IDE/SATA di almeno 15GB.

Modalità grafica

Cluster linux: installazione nodo 1 (SO) — Nome vm e SO

Cluster linux: installazione nodo 1 (ram) — Nome vm e SO

Se vogliamo abilitare l’integrazione con il mouse bisogna selezionare in “Sistema” e nella voce “Dispositivo di puntamento” il mouse come “Tavoletta di puntamento” e non il default “~~Mouse PS/2~~” dato che con Centos 7 sembra ci siano dei problemi.
Così ci possiamo spostare con il mouse anche al di fuori della finestra della nuova vm senza dover premere il tasto “Home” assegnato da VirtualHost in base al sistema operativo in cui gira oppure in alternativa come impostato nelle sue “Preferenze“.

Modalità alternativa: da terminale

Utilizzando il comando “VBoxManage” possiamo fare le stesse operazioni fatte sopra in modalità grafica ma più velocemente quindi sostituiamo alla variabile “ISO” qui sotto il percorso valido dov’è l’iso della centos7-minimal.

VBoxManage createvm --name centos7-minimal --ostype RedHat_64 --register
VBoxManage modifyvm centos7-minimal --vram 15
VBoxManage modifyvm centos7-minimal --mouse usbtablet --usbehci on
VBoxManage modifyvm centos7-minimal --nic1 nat
VBoxManage modifyvm centos7-minimal --nic2 intnet
VBoxManage modifyvm centos7-minimal --nic3 intnet
VBoxManage modifyvm centos7-minimal --memory 1024

cfg_row=$(VBoxManage showvminfo --machinereadable "centos7-minimal" | grep '^CfgFile')
eval "$cfg_row"
vm_basedir=$(dirname "$CfgFile")
VBoxManage createmedium disk --filename "${vm_basedir}/centos7-minimal.vdi" --size 15360 --format VDI
VBoxManage storagectl centos7-minimal --name "SATA Controller" --add sata --controller IntelAhci
VBoxManage storageattach centos7-minimal --storagectl "SATA Controller" --port 0 --device 0 --type hdd --medium "${vm_basedir}/centos7-minimal.vdi"
VBoxManage storagectl centos7-minimal --name "IDE Controller" --add ide --controller PIIX4
ISO="/dati1/lavoro/iso/CentOS-7-x86_64-Minimal-1810.iso"
VBoxManage storageattach centos7-minimal --storagectl "IDE Controller" --port 1 --device 0 --type dvddrive --medium "$ISO"

Installazione Centos 7 minimal

Per istallare facciamo infine partire la vm graficamente tramite l’interfaccia di Virtualbox oppure in alternativa tramite il comando

VBoxManage start centos7-minimal

dove “centos7-minimal” è il nome che abbiamo dato alla nostra vm quindi seguiamo le semplici schermate dell’installatore di Centos 7.

Cluster linux: installazione nodo 1 (boot centos 7) — Menù di avvio

Configurazione nodo principale del cluster

Entriamo in una shell bash della vm appena installata quindi iniziamo la configurazione che sarà valida per tutti e tre i nodi del cluster e che va fatta una volta solamente.

Ambiente: tastiera e lingua locale

Se abbiamo bisogno di configurare un layout di tastiera diverso da quello dell’installazione, ad esempio per l’italiano lanciamo il comando:

localectl set-keymap it

Potremmo scegliere anche altri layout per l’italiano in base alla nostra tastiera come ad esempio “it2” o “it-winkeys” oppure vedere l’elenco completo dei layout lanciare il comando

 localectl list-keymaps

Se necessario impostiamo il “locale” in modo che il funzionamento della console tramite i comandi:

localectl set-locale LANG=en_US.utf8
localectl status

Interfaccia di rete per la navigazione

Se abbiamo fatto l’installazione minima della Centos 7, la rete non sarà stata configurata quindi testiamola con il comando:

ip a

Cluster Centos 7 minimal: scheda di rete non configurata — Centos 7 minimal: scheda di rete non configurata

Verifichiamo che l’interfaccia di NAT, la prima in elenco esclusa “lo” sia enp0s3 ed abilitiamola mettendo il parametro ONBOOT=yes nel file /etc/sysconfig/network-scripts/ifcfg-enp0s3 e riavviamo il servizio di rete:

sed -i 's/ONBOOT=no/ONBOOT=yes/' /etc/sysconfig/network-scripts/ifcfg-enp0s3
/etc/init.d/network restart

Ricontrolliamo che la rete funzioni bene in modo da poter prosequire utilizzando i comandi:

ip a
ping -c 1 google.com

Aggiornamento pacchetti software:

yum update -y

Pacchetti relativi al cluster

Istalliamo i pacchetti per il cluster e se necessario infine eliminiamo il cluster presente di default:

yum install -y pacemaker pcs httpd wget
pcs cluster destroy --force

Virtualbox Guest Additions (facoltativo)

Riavviamo la vm per utilizzare il nuovo kernel dopo gli aggiornamenti altrimenti sarà difficile compilare i “Guest Additions“:

shutdown -r now

L’installare dei “Guest Additions” di VirtualBox avviene inserendo il disco nella vm tramite il menù in alto “Dispositivi” quindi facendo il “mount” del cdrom da shell Linux:

mount /dev/cdrom /mnt
yum install -y perl gcc dkms kernel-devel kernel-headers make bzip2 tar
/mnt/VBoxLinuxAdditions.run --nox11

Fine prima parte: nodo principale del cluster

A questo punto la configurazione principale è terminata, possiamo spegnere la vm per clonarla per 2 volte tramite interfaccia di VirtualBox in modo tale da avere tutti e 3 i nodi del cluster.

shutdown -h now

Clonazione nodo principale del cluster

Nel paragrafo precedente abbiamo creato il nodo1 del cluster ora lo cloniamo per ottenere immediatamente il il nodo 2 ed il nodo 3 quindi da VirtualBox selezioniamo la nostra vm Centos 7 e clicchiamo sul tasto “Clona macchina virtuale“

Nel campo “Nome” inseriamo cl-c7-node-2 per il secondo nodo e cl-c7-node-3 per il terzo nodo. Inoltre in “Criterio indirizzi MAC” mettiamo l’opzione per generare nuovi indirizzi MAC ed infine selezioniamo “Clone completo“.

Se invece vogliamo fare i cloni da linea di comando usiamo:

vboxmanage clonevm cl-c7-node-1 --name="cl-c7-node-2" --register
vboxmanage clonevm cl-c7-node-1 --name="cl-c7-node-3" --register

successivamente abbiamo 3 vm Centos 7: cl-c7-node-1, cl-c7-node-2 e cl-c7-node-3 tutte con gli aggiornamenti fatti i con il software di cluster installato (modifichiamo il nome originale di centos7-minimal in cl-c7-node-1).

Reindirizzamento porte

Se vogliamo lavorare nelle vm collegandoci in ssh (in modo da poter fare copia ed incolla ed avere un terminale con l’history dei comandi) senza dover aggiungere una ulteriore scheda di rete “hostonly” e se vogliamo vedere l’http interno basta lanciare le seguenti righe di comando:

VBoxManage modifyvm cl-c7-node-1 --natpf1 "ssh,tcp,,2022,,22"
VBoxManage modifyvm cl-c7-node-1 --natpf1 "http,tcp,,7080,,80"
VBoxManage modifyvm cl-c7-node-2 --natpf1 "ssh,tcp,,3022,,22"
VBoxManage modifyvm cl-c7-node-2 --natpf1 "http,tcp,,8080,,80"
VBoxManage modifyvm cl-c7-node-3 --natpf1 "ssh,tcp,,4022,,22"
VBoxManage modifyvm cl-c7-node-3 --natpf1 "http,tcp,,9080,,80"

Quindi per collegarci in ssh al nodo 1 usiamo:

ssh -p 2022 root@localhost

mentre per il nodo 2 e 3 basta sostituire la porta 2022 con 3022 e 4022

Configurazione parallela dei 3 nodi del cluster

Per proseguire la configurazione del cluster lavoriamo su ogni nodo in parallelo, ovvero eseguiremo gli stessi comandi su tutti e 3 i nodi cioè in base al nodo in cui stiamo lanciando i comandi dobbiamo sostituire:

cl-c7-node-X con il nome del nodo (ad esempio per il secondo cl-c7-node-2).
192.168.33.1X con l’ip associato al nodo per la rete di cluster (ad esempio per il terzo 192.168.33.13)
192.168.43.1X con l’ip associato al nodo per la rete di fence (ad esempio per il terzo 192.168.43.13)

Configurazione dell’hostname

hostnamectl set-hostname cl-c7-node-X.localhost

Configurazione Apache Web Server

Configuriamo Apache Web Server per rispondere all’agent del cluster (all’URL relativo /server-status) e disabilitiamolo come servizio da systemd e creiamo una pagina html di test:

cat <<EOF >>/etc/httpd/conf/httpd.conf
<Location /server-status>
SetHandler server-status
Require local
</Location>
EOF
systemctl stop httpd
systemctl disable httpd

Salviamo la pagina di cortesia di Apache Web Server già esistente:

if [ -e "/var/www/html/index.html" ]; then
  mv /var/www/html/index.html /var/www/html/index.html.orig
  chmod 600 /var/www/html/index.html.orig
fi

Aggiungiamo la nuova pagina di cortesia e per capir meglio durante lo switch tra un nodo e l’altro usiamo il comando hostname per distinguere la pagina tra i 3 nodi.

cat <<EOF >/var/www/html/index.html
<html><head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<style id='linux-text-cluster-inline-quolltech-css' type='text/css'>
  body {margin: 0;} 
  #top { position:fixed; top:86px; left:72px; transform:rotate(90deg); transform-origin:0% 0%; background-color: #f94701; background-image: linear-gradient(to right,#a6a6a6,#c9c925,#1e73be,#fe36f9,#0fe22a,#fe4809); text-align:center; padding:5px; border-radius:5px; opacity:0.9;} 
  #top div {font-size:14px;} 
  h2 { font-size:20px; margin-bottom:10px; margin-top:10px; } 
  #test_frame {width:100vw;height:99vh;border:0px hidden;margin:0;padding:0;}
</style></head>
<body>
<div id="top"> Linux Cluster Test: Cps, Pacemaker, Corosync</h2>
$(hostname) - by Quoll Tech</div></div>
<iframe id="test_frame" src="https://quoll.it/servizi-chiedi-un-preventivo/"></iframe>
<script type="text/javascript"> 
  function quoll_resize() {
   el=document.getElementById("top"); 
   el_h=el.offsetHeight; 
   el.style.left = el_h +"px";
  } 
  quoll_resize();
  window.onresize = quoll_resize;
</script>
</body></html>
EOF

Configurazione della rete di cluster

Interfaccia di rete 192.168.33.0/24

Per configurare la rete dobbiamo prima controlla la presenza delle interfaccie di rete con il comando

ip a

e quindi verificare che l’interfaccia di rete (la seconda dopo il loopback “lo“) sia enp0s8, altrimenti sostituiamo il suo valore ad enp0s8 nel seguente comando:

cat <<EOF >/etc/sysconfig/network-scripts/ifcfg-enp0s8
DEVICE="enp0s8"
ONBOOT="yes"
BOOTPROTO=static
IPADDR=192.168.33.1X
NETMASK=255.255.255.0
NM_CONTROLLED=no
TYPE=Ethernet
EOF
/etc/sysconfig/network-scripts/ifup enp0s8

Nomi dei nodi del cluster

echo -e "192.168.33.11\t cl-c7-node-1" >>/etc/hosts
echo -e "192.168.33.12\t cl-c7-node-2" >>/etc/hosts
echo -e "192.168.33.13\t cl-c7-node-3" >>/etc/hosts

Password utente hacluster

L’utente hacluster che gestisce parti delle operazioni di cluster deve necessariamente avere la password uguale su tutti i nodi in modo da essere autorizzato a far parte dello stesso cluster.
Supponiamo che “<password sicurissima>” sia la password da mettere all’utente hacluster allora usiamo il seguente comando per impostarla:

echo "hacluster:<password sicurissima>" | chpasswd

Configurazione dei fence agents

Per gestire anche la rete di fence e di conseguenza abilitare gli agent del cluster che tenteranno di spegnere o disabilitare un nodo nel momento in cui tale nodo non funziona più bene a causa di uno o più guasti dobbiamo seguire anche questo paragrafo.

Interfaccia di rete fence 192.168.43.0/24

Stesso ragionamento vale anche per la rete di fence quindi controlliamo con il comando

ip a

che l’interfaccia di fence (la terza dopo il loopback “lo“) sia enp0s9, altrimenti sostituiamo il suo valore ad enp0s9 nel seguente comando:

cat <<EOF >/etc/sysconfig/network-scripts/ifcfg-enp0s9
DEVICE="enp0s9"
ONBOOT="yes"
BOOTPROTO=static
IPADDR=192.168.43.1X
NETMASK=255.255.255.0
NM_CONTROLLED=no
TYPE=Ethernet
EOF
/etc/sysconfig/network-scripts/ifup enp0s9

Istallazione dei fence agents

yum install -y "fence-agents-all"

Nomi dei nodi nella rete di fence

echo -e "192.168.43.11\t cl-c7-nodefence-1" >>/etc/hosts
echo -e "192.168.43.12\t cl-c7-nodefence-2" >>/etc/hosts
echo -e "192.168.43.13\t cl-c7-nodefence-3" >>/etc/hosts

Fence agent di test

Per questo ambiente di test utilizziamo l’agent fence ssh mentre in produzione dovremmo usarne uno più opportuno magari basato sulle api messe a disposizione dal nostro ups o sull’interfaccia iLO se abbiamo un server HP o compatibile. Comunque sia, l’agent fence dovrà esser in grado in maniera certa di poter spegnere o escludere il nodo dal cluster fisicamente.

wget -q -O /usr/sbin/fence_ssh https://raw.githubusercontent.com/nannafudge/fence_ssh/master/fence_ssh
chmod +x /usr/sbin/fence_ssh

Perché funzioni correttamente l’agent “fence_ssh” deve potersi connettere in ssh agli altri 2 nodi sulla rete di fence e non su quella di cluster o su quella di NAT (dove il guasto potrebbe generarsi).

Creiamo, quindi, un utente apposito con la password uguale per tutti i nodi “<password sicurissima fence>“:

useradd -c "Fence ssh user" -m -s /bin/bash fence
echo "fence:<password sicurissima fence>" | chpasswd

All’utente fence appena creato gli diamo i diritti con sudo di fare lo shutdown del server:

cat <<EOF >/etc/sudoers.d/fence
fence ALL = NOPASSWD: /sbin/shutdown
EOF

in modo da poter utilizzare sia “/sbin shutdown -r” per fare il reboot che “shutdown -h” per fare spegnere la vm.

Per sicurezza, anche se dovrebbe esser già attivo, abilitiamo l’uso di ssh con password se non attivo:

sed -i 's/^PasswordAuthentication.*/PasswordAuthentication yes/' /etc/ssh/sshd_config
systemctl restart sshd

Autenticazione in ssh senza password con chiave privata/pubblica:

Generazioni chiavi (da fare solo su un singolo nodo ad esempio il cl-c7-node-1)

su - fence
rm -rf .ssh
ssh-keygen -q -C "fence_agent_key" -f $HOME/.ssh/id_rsa -N ''
cp -a .ssh/id_rsa.pub .ssh/authorized_keys
cat <<EOF >.ssh/config
Host 192.168.43.* cl-c7-nodefence-*
StrictHostKeyChecking no
EOF
chmod 600 .ssh/config
exit

Copia chiave nei 2 restanti nodi (cl-c7-node2 e cl-c7-node-3)

Bisogna copiare la cartella .ssh dell’utente fence negli altri 2 nodi, a tal fine supponiamo di essere nel nodo 1 (cl-c7-node-1) e che entrambi i nodi 2 e 3 siano accesi ed abbiano configurato il nodo almeno sino al paragrafo precedente relativo all’utente fence:

su - fence
tar cf - .ssh | ssh fence@cl-c7-nodefence-2 tar xf - --warning=no-timestamp
tar cf - .ssh | ssh fence@cl-c7-nodefence-3 tar xf - --warning=no-timestamp
exit

Fatto questo da qualunque dei 3 nodi con l’utente fence si dovrebbe riuscire ad entrare in ssh sugli altri 2 nodi, senza password utilizzando la chiave pubblica, in modo che l’agent fence_ssh funzioni correttamente.
Proviamo a fare un test ad esempio dal nodo 2 collegandoci in ssh sul nodo 1 e 3:

ssh fence@cl-c7-nodefence-1 hostname
ssh fence@cl-c7-nodefence-3 hostname

Firewall

Abilitazione del Firewall

systemctl unmask firewalld
systemctl start firewalld
systemctl enable firewalld

SSH: regole Firewall

firewall-cmd --permanent --add-service=ssh
firewall-cmd --add-service=ssh

Cluster: regole Firewall

firewall-cmd --permanent --add-service=high-availability
firewall-cmd --add-service=high-availability

Apache Web Server: regole Firewall

firewall-cmd --permanent --add-service=http
firewall-cmd --add-service=http

Attivazione del servizio per il cluster

systemctl start pcsd.service
systemctl enable pcsd.service

Configurazione cluster ed agents

Questa parte di configurazione va fatta su un singolo nodo dopo che sono state fatte tutte le precedenti configurazioni su tutti e 3 i nodi.

Supponiamo quindi di lavorare sul nodo 1.

cluster_nodes="cl-c7-node-1 cl-c7-node-2 cl-c7-node-3"
echo -e "\tinizializing the cluster on nodes ${cluster_nodes}"
pcs cluster auth ${cluster_nodes} -u hacluster -p "<password sicurissima>"
pcs cluster setup --start --name "quolltech_cluster" ${cluster_nodes} --force
pcs cluster enable --all
# disable stonith
pcs property set stonith-enabled=false
sleep 5

e se tutto è andato per il meglio il cluster dovrebbe essere attivo e configurato su tutti e 3 i nodi infine per controllare lo stato proviamo il comando:

pcs cluster status
pcs status
pcs quorum status

Se qualcosa non funziona magari perché un nodo risulta “OFFLINE” proviamo a controllare in quel nodo se tutte le regole di firewall sono attive in special modo quella del servizio “high-availability”.
Supponiamo che il problema si presenta sul nodo 2 in modo da lanciare il comando:

firewall-cmd --list-all

e quindi se la regola di firewall manca abilitiamola in base al paragrafo sopra.

Aggiungiamo le risorse al cluster

httpd_conf="/etc/httpd/conf/httpd.conf"
pcs resource create first_test_ip IPaddr2 ip=192.168.33.31 cidr_netmask=24 --group apachegroup
pcs resource create Web1 apache configfile="$httpd_conf" statusurl="http://127.0.0.1/server-status" --group apachegroup
pcs resource create second_test_ip IPaddr2 ip=192.168.33.32 cidr_netmask=24 --group group_second_test_ip
pcs resource create last_test_ip IPaddr2 ip=192.168.33.33 cidr_netmask=24 --group group_last_test_ip

In sintesi abbiamo creato 3 gruppi di risorse (o resource group):

cluster: pcs status dopo la creazione delle risorse

apachegroup
con 2 risorse, la prima di tipo IPaddr2 con nome first_test_ip e l’altra di tipo apache con nome Web1;
group_second_test_ip
con una risorsa di tipo IPaddr2 con nome second_test_ip;
group_last_test_ip
con una risorsa di tipo IPaddr2 con nome last_test_ip.

Controlliamo quindi con il comando:

pcs status

Aggiungiamo le risorse di tipo fence

pcs stonith create stonith-ssh-1 fence_ssh user=fence sudo=true private-key="/home/fence/.ssh/id_rsa" hostname="cl-c7-nodefence-1" pcmk_host_list="cl-c7-node-1" --force --disabled
pcs stonith create stonith-ssh-2 fence_ssh user=fence sudo=true private-key="/home/fence/.ssh/id_rsa" hostname="cl-c7-nodefence-2" pcmk_host_list="cl-c7-node-2" --force --disabled
pcs stonith create stonith-ssh-3 fence_ssh user=fence sudo=true private-key="/home/fence/.ssh/id_rsa" hostname="cl-c7-nodefence-3" pcmk_host_list="cl-c7-node-3" --force --disabled

Per ogni fence resource facciamo in modo che non si attivi nel nodo stesso, che in genere non ha molto senso:

pcs constraint location stonith-ssh-1 avoids cl-c7-node-1
pcs constraint location stonith-ssh-2 avoids cl-c7-node-2
pcs constraint location stonith-ssh-3 avoids cl-c7-node-3

Abilitiamo le risorse fence con le costrizioni in modo che partano in un nodo giusto (ad esempio “stonith-node-1” dovrà partire o sul nodo 2 o sul 3, mentre “stonith-node-2” dovrà partire o sul nodo 1 o sul 3):

pcs stonith enable stonith-ssh-1
pcs stonith enable stonith-ssh-2
pcs stonith enable stonith-ssh-3

A questo punto possiamo abilitare il cluster ad usare il fence agent (lo avevamo disabilitato precedentemente per non avere degli errori dato che non erano stati configurati i fence):

pcs property set stonith-enabled=true

Test di funzionamento

Stato cluster

A questo punto il cluster è pronto e funzionante, possiamo utilizzare i comandi seguenti per vedere lo stato del cluster e delle risorse collegate:

pcs cluster status
pcs status
pcs quorum status

Possiamo verificare anche che le risorse siano effettivamente attive nei rispettivi nodi.
Ad esempio se la risorsa “second_test_ip” risulta attiva nel nodo 1 allora da tale nodo possiamo lanciare il comando

ip a

per verificare che l’ip sia effettivamente attivo.
Stessa cosa vale anche per la risorsa “first_test_ip” e “last_test_ip“.

Per verificare la risorsa “Web1” che naturalmente deve stare sullo stesso nodo di “first_test_ip” perché fanno parte dello stesso gruppo “apachegroup” basta andare con il browser all’indirizzo:

http://localhost:7080/ se “Web1” è sul nodo 1;
http://localhost:8080/ se “Web1” è sul nodo 2;
http://localhost:9080/ se “Web1” è sul nodo 3.

Se la pagina web non funziona bisogna ritornare indietro in modo da rivedere i passaggi al paragrafo relativo al reindizzamento delle porte.

Anche per gli stonith, ovvero gli agent dei fence, verifichiamo che siano partiti sul nodo diverso da quello da controllare.
Ad esempio “stonith-ssh-2” che verifica il nodo 2 non deve partire assolutamente nel nodo 2.

Test

Come test di funzionamento possiamo provare a migrare un servizio da un nodo ad un altro ad esempio proviamo a migrare “last_test_ip” dal nodo 3 al nodo 2 collegandoci ad uno qualunque dei nodi in modo da usare il comando:

pcs resource move last_test_ip cl-c7-node-2
pcs status

Un altra prova potrebbe essere quella di simulare un problema su un nodo per poi verificare che l’agent di fence si attivi e faccia lo shutdown del nodo problematico e che i servizi si redistribuscano nei restanti 2.
Usiamo direttamente il comando pcs per simulare un problema ad un nodo in modo da attivare il fence del nodo 3, per esempio facciamolo dal nodo 1 oppure dal 2:

pcs stonith fence cl-c7-node-3
pcs status

Con questi comandi verrà inizializzato un “fence” al nodo 3 in modo da fargli gli fare un reboot del nodo.
Potrebbe essere che nello stato (pcs status) compaglia che ci sia un “Timeout” per il test sulla risorsa “stonith-ssh-3” in modo da avvertirci per quale motivo è stato fatto il “fence” al nodo.
Se volete quindi eliminare questa nota dallo stato basta lanciare il comando:

pcs stonith cleanup stonith-ssh-3

Se invere del reboot del nodo vogliamo farlo spegnere allora aggiungiamo al comondo precedente l’opzione –off

pcs stonith fence cl-c7-node-3 --off
pcs status

Un test più simile ad un errore hardware potrebbe essere quello di scollegare il cavo della rete di cluster di un nodo, ad esempio al nodo 2 tramite interfaccia grafica di VirtualBox o con il comando (esterno al cluster):

VBoxManage controlvm cl-c7-node-2 setlinkstate2 off

e controllare che il nodo 2 venga messo in “OFFLINE” dal cluster e quindi che il nodo 2 faccia un reboot causato dall’agent di fence.

Se vogliamo che l’agent di fence spenga il nodo (invece del reboot) basta mettere la proprietà del cluster “stonith-action” ad “off” invece del default “reboot“.

pcs property set stonith-action=off

Conclusione

In questo articolo abbiamo visto come fare a testare un cluster su 3 nodi con Linux su distribuzione Centos 7, nel prossimo articolo che è la continuazione di questo vedremmo come automatizzare l’installazione e la configurazione utilizzando Vagrant per avere un cluster già pronto per i test.

Inoltre vedremo come installarlo anche su Ubuntu 18.04 LTS e volendo anche senza utilizzare Virtualbox ma con container tipo LXD.
Infine sempre grazie a Vagrant vedremo come sarà possibile, sempre in automatico, aggiungere o togliere nodi al cluster, utilizzare o meno la rete di “fence“, cambiare gli ip di rete, fare o meno gli upgrade iniziali del software (il tutto parametrizzabile con Vagrant).

Per chi non ha voglia di leggere tutto il prossimo articolo su come automatizzare con Vagrant può semplicemente vedere il mio progetto “linux-cluster-test” su Github.

Riferimenti

Vagrant per installare, configurare e gestire macchine virtuali;
Virtualbox per la virtualizzazione di vm;
Virtualbox Guest Additions (è possibile scaricare l’iso direttamente dal questo link, poi cliccando nella versione di Virtualbox e quindi nel file VBoxGuestAdditions_x.y.z.iso, dove x.y.z è la versione scelta, ad esempio 6.1.10 che è l’ultima in questo momento);
LXD gestore di container Linux;
Pacemaker per la creazione di risorse ad alta disponibilità, open source per piccoli e grandi cluster;
Corosync insieme a Pacemaker aiuta per la parte di alta disponibilità;
Agent di fence fence_ssh per testare la rete di fence del cluster;
comandi di cluster pcs;
Configuring the Red Hat High Availability Add-On with Pacemaker;
linux-cluster-test su Github;
Ubuntu 18.04 LTS;
Centos 7;
RedHat;
Agent di fence per iLO;
systemd.