meta données pour cette page

Mise en place d'un cluster PaceMaker

Pacemaker est un gestionnaire de ressource automatisé dans un cluster. Il gère la haute disponibilité de services en détectant et répartissant les charges si besoin. Pour synchroniser les données entre les machines, il utilise son propre système de fichier distribué appelé OCFS2.

ressources :

Pré-requis

Pour que le tout fonctionne correctement sans qu'il y ait de “pollution” sur le réseau. On choisira de déployer deux cartes réseaux sur les machines de manière à pouvoir dédié une interface à la communication entre les machines du cluster.

Pour facilité le déploiement des machines, on utile Vagrant voici son script :

Cliquez pour afficher ⇲

Cliquez pour masquer ⇱

Vagranfile
Vagrant.configure("2") do |config|
  config.vm.box = "debian/contrib-jessie64"
 
   config.vm.provision "shell", inline: "sudo -p vagrant apt-get install htop tmux multitail -y; sudo -p vagrant apt-get autoremove --purge exim4-base mutt -y;"
 
  config.vm.box_check_update = false
  config.ssh.insert_key=false
 
  config.vm.define "node1" do |server|
    server.vm.hostname = "node1"
    server.vm.network "public_network", adapter: 2, bridge: "eth0"
    server.vm.network "private_network", adapter:3, ip: "192.168.50.3", virtualbox__intnet: "mynetwork"
  end
 
  config.vm.define "node2" do |server|
    server.vm.hostname = "node2"
    server.vm.network "public_network", adapter: 2, bridge: "eth0"
    server.vm.network "private_network", adapter:3, ip: "192.168.50.4", virtualbox__intnet: "mynetwork"
  end
end
 
end

Ainsi nous avons deux machines dont node1 (ip publique : 192.168.1.10, ip privé : 192.168.50.3) et node2 (ip publique : 192.168.1.11, ip privé : 192.168.50.4).

Installation

Admettons que nous utilisons deux serveurs ayant tous les deux les même configurations (2cores, 512Mo de RAM et 9,2Go de disque).

Commençons d'abord par installer les dépendances : 

echo "deb http://debian.univ-lorraine.fr/debian/ jessie-backports main contrib non-free" >> /etc/apt/sources.list
apt-get update 
apt-get install -t jessie-backports pacemaker crmsh

On génère ensuite la clé d'authentification sur le nœud maitre : 

corosync-keygen
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 = 920).
Press keys on your keyboard to generate entropy (bits = 1000).
Writing corosync key to /etc/corosync/authkey.

On copie la clé sur chacun des noeuds : 

scp /etc/corosync/authkey node2:/etc/corosync/

Manuellement sur tous les nodes, on déclare le réseau privé dont les nodes l'utiliserons pour discuter entre-eux : 

nano /etc/corosync/corosync.conf

Vérifions que ces lignes soient existantes : 

totem {
#...
        interface {
                ringnumber: 0
                bindnetaddr: 192.168.50.0
                mcastaddr: 239.255.1.1
                mcastport: 5405
        }
#...
}

Puis on démarre le service : 

service corosync restart

Pour prouver son bon fonctionnement : 

crm_mon --one-shot -V
Stack: corosync
[...]

2 nodes and 0 resource configured

Online: [ node1 node2 ]

Créer une IP failover

On va maintenant déclarer une IP virtuelle qui va être liée à une ressource que l'on va déclarer. Pour se faire, on se connecte au logiciel client et créons une nouvelle configuration : 

crm
cib new mon-cluster

On désactive le stonith car on a pas besoin de vérifier l'intégrité des données sur les nœuds : 

configure property stonith-enabled=false

On désactive le quorum vu que nous n'avons pas au moins les 3 nodes (mais juste 2) : 

configure property no-quorum-policy=ignore

On définit enfin l'IP que l'on veut et qui sera présent sur le réseau local : 

configure primitive failover-ip ocf:heartbeat:IPaddr2 params ip=192.168.0.100 op monitor interval=10s

On vérifie que l'on a pas fait d'erreur syntaxique et on sauvegarde le tout : 

configure verify
cib use live
cib commit mon-cluster
quit

Ainsi on peut voir qu'il y a un nouvelle ressource de configuré avec son interface virtuelle : 

crm_mon --one-shot -V
Stack: corosync
[...]

2 nodes and 1 resource configured

Online: [ node1 node2 ]

 failover-ip    (ocf::heartbeat:IPaddr2):       Started node1

On peut également obtenir une réponse au ping : 

ping 192.168.0.100
PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
64 bytes from 192.168.0.100: icmp_seq=1 ttl=64 time=1.10 ms
^C
--- 192.168.0.100 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.740/0.924/1.108/0.184 ms

Créer une redondance Apache

Les commandes sont globalement les même vu que notre cluster est composé que de deux machines : 

crm
cib new apache-cluster

On déclare ainsi la primitive suivante : 

configure primitive httpd ocf:heartbeat:apache params configfile="/etc/apache2/apache2.conf" statusurl="http://192.168.1.100/server-status" op start timeout="60s" op stop timeout="60s" op monitor interval="10s"

Puis on vérifie et on enregistre le tout : 

configure verify
cib use live
cib commit apache-cluster
quit

Ainsi on peut voir apparaitre une seconde ressource : 

crm_mon --one-shot -V
Stack: corosync
[...]
2 nodes and 2 resources configured

Online: [ node1 node2 ]

 failover-ip    (ocf::heartbeat:IPaddr2):       Started node1
 httpd  (ocf::heartbeat:apache):        Started node2

Modifier le comportement du cluster

Lors de la création de la précédente ressource, il faut indiquer à Corosync de démarrer les groupes de ressource que l'on veut. Par exemple la commande ci-dessous cite les deux ressources construire précédemment : 

crm configure group Cluster httpd failover-ip meta target-role="Started"

A ce moment là, sur chacun des noeuds, on peut voir ces directives apparaître : 

 crm configure show
[...]
group Cluster httpd failover-ip \
        meta target-role=Started
[...]

Sinon pour le stopper : 

crm configure group Cluster httpd failover-ip meta target-role="Stopped"

Migrer une ressource

Par exemple on veut déplacer une ressource du node1 vers le node2 : 

crm resource migrate failover-ip node2

Ainsi lorsque l'on liste les interface réseaux des machines, on verra que l'interface détenant l'IP 192.168.1.100 se retrouve sur le node2 et non plus sur le node1.