PacemakerEtCorosync

Introduction
Pacemaker un un outils serveur qui gère des ressources (une VIP, un service) pour vos cluster. Son rôle principale c'est de gérer la haute disponibilité

 en s'occupant de leur démarrage, redémarrage, arrêt. La communication entre vos noeuds et la gestion du cluster en lui-même seront assurées par une brique dédiée 
 comme par exemple Corosync. Son rôle est de se charger du heartbeat (battement de cœur de notre cluster) et d'avertir Pacemaker du changement d’état des 
 nœuds.

 Il faut également garder en tête que le fait d'avoir un cluster pour le service DHCP n'exclut pas d'avoir des problèmes. Un cluster peut se trouver confronté à 
 un problème de taille : le split-brain. C'est le principal problème à éviter.

 Le split-brain peut intervenir quand chaque nœud de votre cluster croit son voisin hors service. Il va alors prendre la main : chaque nœud est donc maître et 
 fournit le service. Les effets de bords peuvent être gênants dès lors qu’on utilise une ressource partagée.
Pour se protéger un maximum de ce problème, il est fortement recommandé d’utiliser deux liens réseau différents pour la communication entre les nœuds (ou de faire du bonding, agrégation de plusieurs Interfaces réseaux en une Interface logique). Installation d'un Cluster qui contiendra deux serveurs physiques pour assurer les services de routage d'un réseau NAT (192.168.1.0/24) et d'un '''service DHCP''' pour les clients natter.

Installation :

 # apt-get install corosync

 # apt-get install pacemaker

 # apt-get install crmsh

Crmsh est un CLI permettant de configurer votre Cluster.

 Avant d'effectuer la configuration, ouvrir les ports nécessaires à Corosync et autoriser le multicast :

 # iptables -A INPUT -p udp --dport 5404 -j ACCEPT
 # iptables -A INPUT -p udp --dport 5405 -j ACCEPT
 # iptables -A INPUT -m pkttype --pkt-type multicast -j ACCEPT
 # iptables-save > /etc/iptables_rules.save

Configuration de Corosync :
Editez le fichier de configuration de Corosync.

Remarque :

 Ce fichier doit être le même sur l'ensemble de vos nœuds. Lorsque la configuration du fichier sera terminé, une copie sera nécessaire sur l'autre nœud.

 # vi /etc/corosync/corosync.conf

 totem {
      version: 2
      threads: 0
      cluster_name: ntp_route
      token: 5000
      token_retransmits_before_loss_const: 20
      join: 1000
      consensus: 7500
      max_messages: 20
      secauth: on # On utilise une clé pour autoriser un nœud à se connecter au cluster.

      interface {
               ringnumber: 0
               bindnetaddr: 192.168.1.0
               mcastaddr: 226.94.1.1
               mcastport: 5405
               ttl: 1
      }
 }

      logging {
             to_logfile: yes
             logfile: /var/log/corosync/corosync.log
             to_syslog: yes
             debug: off
	     timestamp: on
	     logger_subsys {
		          subsys: QUORUM
		          debug: off
	     }
 }

 quorum {
       provider: corosync_votequorum
       expected_votes: 2
 }

 Pour éviter le split-brain, il faut déclarer une deuxième interface.
Pour ce faire, ajoutez un deuxième bloc "interface", incrémentez-le "ringnumber" et renseignez l’adresse de votre deuxième réseau ainsi qu’une nouvelle adresse de multicast. Il faudra positionner le "rrp_mode" à active. Vos deux interfaces réseau fonctionneront en même temps. Si vous mettez le "rrp_mode" à passive. La deuxième interface réseau ne s’activera que si la première est en échec.

Exemple :

 rrp_mode: active
 interface {
   ringnumber: 0
   bindnetaddr: 194.214.124.0
   mcastaddr: 226.94.1.1
   mcastport: 5405
 }

 interface {
   ringnumber: 1
   bindnetaddr: 192.168.1.0
   mcastaddr: 226.94.2.1
   mcastport: 5405
 }

Remarque :
Si une des deux interfaces réseaux ne fonctionnent pas, vous aurez un message d'erreur dans les logs :

 [TOTEM ] Marking seqid 3608 ringid 1 interface 192.168.0.2 FAULTY
 administrative intervention required.

 La commande suivante, permet de donner l'état de vos interfaces :

Intégration de Pacemaker et activation de corosync :
En premier, créer le répertoire /etc/corosync/service.d/

 # mkdir /etc/corosync/service.d/

 Nous allons maintenant ajouter le service Pacemaker dans notre cluster Corosync.
A la fin du fichier /etc/corosync/corosync.conf, ajoutez les lignes suivantes :
service { # Load the Pacemaker Cluster Resource Manager name: pacemaker ver: 1 } Activation du service corosync : Positionnez le paramètre START à yes du fichier /etc/default/corosync : START=yes dans le même fichier, décommentez les lignes suivantes :
 Démarrez le service corosync
 # systemctl start corosync

Authentification :

 Lors de l'installation de Corosync, une clé a été généré pour permettre l'authentification de vos noeuds.
 Nous allons écraser cette clé et en construisant sur le noeud PRIMAIRE la clé à partager entre les noeuds du cluster (en utilisant le paquet haveged).
Sur le serveur PRIMAIRE : PRIMAIRE# apt-get install haveged PRIMAIRE# corosync-keygen PRIMAIRE# chown root:root /etc/corosync/authkey PRIMAIRE# chmod 400 /etc/corosync/authkey A partir du serveur PRIMAIRE, vous pouvez désinstaller le paquet haveged et copiez la clé vers le serveur SECONDAIRE : PRIMAIRE# apt-get remove --purge haveged PRIMAIRE# apt-get autoremove PRIMAIRE# apt-get clean PRIMAIRE# scp /etc/corosync/authkey user@SECONDAIRE:/tmp SECONDAIRE# mv /tmp/authkey /etc/corosync SECONDAIRE# chown root:root /etc/corosync/authkey SECONDAIRE# chmod 400 /etc/corosync/authkey A la fin du fichier /etc/corosync/corosync.conf ajoutez une section nodelist. Le nom des noeuds est récupéré par la commande uname -a | awk '{print $2}' nodelist { node { ring0_addr: 194.214.124.89 name: nat1 node: 1 } node { ring0_addr: 194.214.124.94 name: nat2 node: 2 } } A partir de ce moment, votre cluster est démarré. Vous pouvez vous connecter au moniteur de Pacemaker via la commande crm_mon -1.
Cependant, le cluster n'est pas encore opérationnel dans le cas d'une défaillance matériel ou logiciel d'un des serveurs. Pour cela, il faut activer
stonithd.

Le servcie PACEMAKER

  • cib : Cluster Information Base, gère la base de configuration et d’information du cluster. C’est par lui que la configuration est modifiée et synchronisée sur l’ensemble des nœuds.
  • crmd : Cluster Resource Management Daemon, est un service qui, lorsqu’il est élu maître, ordonne l’activité du cluster dont l’arrêt et la relance des ressources.
  • pengine : calcule à chaque instant et selon les informations qu’il reçoit de crmd le prochain état du cluster selon un graphe d’actions et de dépendances entre celles-ci.
  • stonithd : Shoot The Other Node In The Head Daemon, qui permet d’éteindre mécaniquement un nœud jugé indisponible.
  • lrmd : Local Resource Management Daemon, interface entre le cluster et les ressources locales avec lesquelles il interagit, notamment via des scripts.
  • attrd : Attributes Daemon, qui permet de modifier les attributs d’un nœud.
 Dans les logs, tail -f /var/log/corosync/corosync.conf, vous pourrez voire le bon fonctionnement du cluster, également lors d'une vérification 
 du status de Corosync, systemctl status corosync

 La commande ps va nous permettre de retrouver ces processus, ici avec "version" à 1 dans le fichier /etc/corosync/corosync.conf :

 # ps -e f

Surveiller l'état du Cluster :

 La commande crm_mon est un moniteur en temps réel pour afficher l’état du cluster. Avec cette outil vous allez retrouver la liste des nœuds, leur état, 
 le nom du coordinateur désigné (DC), le hearbeat utilisé, etc.
 # crm_mon -1

Voir la configuration initiale de PACEMAKER :

 # crm config show
 # crm config show xml
 ATTENTION ! Veillez à ne JAMAIS modifier le fichier de configuration /var/lib/heartbeat/crm/cib.xml à la main. C’est une règle 
 de base.

Paramétrage du Cluster :

 Attribution d'une adresse IP virtuelle au cluster.
 Nous utiliserons la cli CRM (Cluster Resource Manager) pour créer notre configuration du cluster. 
 # crm
 crm(live)# cib new ma-config-cluster
 INFO: cib.new: ma-config-cluster shadow CIB created

 On désactive STONITH. Dans notre cas, STONITH est une fonction de sécurité des données lors du basculement entre les deux serveurs d'un cluster. Il est 
 garant de l’intégrité des données à chaque bascule. 
 Ici nous n’en avons pas besoin pour un cluster de serveur NAT/DHCP.
 crm(ma-config-cluster)# configure 
 crm(ma-config-cluster)configure# property stonith-enabled=false

 Et enfin on assigne une adresse IP virtuelle au cluster et on gère la bascule entre les noeuds :
 crm(ma-config-cluster)configure# primitive failover-ip ocf:heartbeat:IPaddr params ip=192.168.1.2 op monitor interval=10s

Descriptions des arguments :

  • primitive, argument pour ajouter une primitive. Mais une primitive c’est quoi ? Un paramètre renseignant plusieurs valeurs indiquant au cluster quels scripts utiliser pour la resource, où le trouver et à quel standard il correspond.
  • failover-ip est le nom de la primitive
  • ocf, classe de la resource
  • hearbeat, provider de la resource
  • IPaddr, RA (Resource Agent) gérant les adresses IPv4 virtuelles
  • params, déclaration des paramètres
  • ip=192.168.1.2, IP du failover
  • op, les options
  • monitor, action à effectuer, ici le monitoring de la ligne de vie
  • interval=10s, on définit l’interval auquel on effectue l’action de monitoring.
 On vérifie et valide les commandes :
 crm(ma-config-cluster)configure# verify
 crm(ma-config-cluster)configure# end
 There are changes pending. Do you want to commit them? y
 crm(ma-config-cluster)#
 crm(ma-config-cluster)# cib use live
 crm(live)# cib commit ma-config-cluster
 INFO: commited 'ma-config-cluster' shadow CIB to the cluster
 crm(live)# quit
 bye

 Le cluster est maintenant activé et fonctionnel !
 # crm_mon --one-shot -V

 # crm_mon -1
 Nettoyage du message Actions ayant échoué dans la configuration du cluster Pacemaker / Corosync.
 # crm_mon -1
 Pour supprimer les erreurs, exécutez la commande suivante :
 # crm_resource -P

Sur le serveur secondaire :

 S'assurer que la clé authkey a bien été copié sur le serveur secondaire avec comme utilisateur et groupe root et avec les droits 400.
 # ls -l /etc/corosync
 Redémarrez les services pacemaker et corosync :
 # systemctl restart pacemaker
 # systemctl restart corosync
 # update-rc.d pacemaker defaults
 # crm_mon -1

Tester le basculement de l’IP sur le second noeud :

 Positionnez le noeud midir en standbye :
 # crm node standby midir

Autres documentations :

 C’est une commande incontournable pour récupérer à n’importe quel moment l’état du cluster. Il peut générer du html, propose une interface cgi, peut dialoguer avec 
 d’autres outils de monitoring (centreon, nagios…). Le paramètre -1 permet d’obtenir une seule sortie :
 STONITH
Comme son nom l'indique,
STONITH clôture les noeuds défaillants en réinitialisant ou en mettant hors tension le noeud défaillant. Une contention à plusieurs nœuds avec un risque d'erreurs dans un cluster peut avoir des résultats catastrophiques, par exemple si les deux nœuds essayent d'écrire sur une ressource de stockage partagée. STONITH fournit une protection efficace, assez drastique contre ces problèmes. Les systèmes à nœud unique utilisent un mécanisme comparable appelé un chien de garde. Un temporisateur de surveillance réinitialisera le nœud si celui-ci ne dit pas au circuit de surveillance qu'il fonctionne bien. Une décision STONITH peut être basée sur diverses décisions qui peuvent être des plugins spécifiques au client. # crm_attribute --attr-name stonith-enabled --attr-value true # cibadmin -Q | grep stonith