Mise en place d’un cluster OpenLDAP avec Corosync / Pacemaker [3/3]

cluster_openldap

Précédemment, nous avons mis en place la base de notre cluster : deux nœuds entre lesquels les échanges sont sécurisés (chiffrés). Si vous avez manqué ces étapes :

La dernière étape afin de qualifier notre installation de cluster consiste à mettre en place une adresse IP virtuelle flottante qui pointera vers l’un ou l’autre des nœuds en fonction de l’état du service slapd sur ceux-ci.

Pour mettre en place cette solution, j’ai choisi d’utiliser Corosync. Corosync est un gestionnaire de cluster dérivé du projet OpenAIS. OpenAIS quant à lui est une implémentation libre des spécifications d’interface applicative (Application Interface Specification, AIS) définies par le forum de disponibilité des services (Service Availability Forum, SAF). AIS est une API qui permet de créer des application nécessitant une haute disponibilité en cas de défaillance.

Avec Corosync est fourni Heartbeat, qui va notifier via son API divers services de l’état des différents nœuds. C’est en fait un gestionnaire de ressources cluster entièrement libre lui aussi. Qu’est-ce qu’une ressource ? Un service, une adresse IP, un utilisateur, un répertoire, un lecteur… Tout ce qui peut être surveillé par un script.

La force de Heartbeat est qu’il s’appuie sur les recommandations de l’OCF (Open Cluster Framework) qui définissent la manière dont les ressources doivent être implémentées. Un grand nombre de classes appelées Resources Agents sont donc fournies pour surveiller la plupart des ressources courantes.

Installation et pré-requis

Avant de commencer, nous avons deux ou trois petites choses à faire :

  1. Désactiver SELinux, ouvrir les ports nécessaires à Heartbeat 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/sysconfig/iptables
  2. Ajouter un nouveau dépôt contenant les outils nécessaires :
    wget -P /etc/yum.repos.d/ http://download.opensuse.org/repositories/network:/ha-clustering:/Stable/CentOS_CentOS-6/network:ha-clustering:Stable.repo
  3. Et installer les outils :
    yum install corosync pacemaker crmsh

Configuration de Corosync

Corosync va se charger du heartbeat (battement de cœur de notre cluster) et avertit Pacemaker du changement d’état des nœuds.
Le fichier de configuration de Corosync se nomme corosync.conf et se situe dans /etc/corosync. Voici une proposition pour bien démarrer :

# Please read the corosync.conf.5 manual page
compatibility: whitetank
 
totem {
	version: 2
	secauth: off
	threads: 0
	interface {
		ringnumber: 0
		bindnetaddr: 192.168.0.0
		mcastaddr: 226.94.1.1
		mcastport: 5405
		ttl: 1
	}
}
 
logging {
	fileline: off
	to_stderr: no
	to_logfile: yes
	to_syslog: yes
	logfile: /var/log/cluster/corosync.log
	debug: off
	timestamp: on
	logger_subsys {
		subsys: AMF
		debug: off
	}
}
 
amf {
	mode: disabled
}

Je dois vous avouer que j’ai un peu la flemme d’écrire un pavé sur toutes les directives mais n’hésitez pas à utiliser les commentaires si vous êtes perdus 🙂

Il reste la section « service » qui va définir le CRM (Cluster Resource Manager) qui doit être utilisé. Il s’agit ici de Pacemaker, que nous configurons avec, par exemple, /etc/corosync/service.d/pacemaker :

service {
	# Load the Pacemaker Cluster Resource Manager
	name: pacemaker
	ver: 1
}

La ligne « ver » définit le mode de démarrage de Pacemaker. Placé sur 1, Pacemaker devra être démarré manuellement ou en tant que service, après le démarrage de Corosync. Si la valeur est à 0, Pacemaker est démarré (ou arrêté) par le Heartbeat.

Comme tous les fichiers de configuration du cluster, ceux-ci doivent évidemment être dupliqués sur le second nœud.

Lorsque « ver » est à 0, vous pouvez voir apparaître des erreurs de permissions dans /var/log/messages. Il suffit alors de mettre la valeur « to_logfile: » à « no », ou bien d’autoriser l’écriture sur corosync.log.

Et si on démarrait notre cluster ?

Démarrage du cluster

Ça se passe comme pour n’importe quel service :

[root@ldap1 ~]# service corosync start
Démarrage de corosync :          [ OK ]

Comme Corosync n’a pas été configuré de manière à démarrer Pacemaker, il faut aussi le faire à la main :

[root@ldap1 ~]# service pacemaker start
Démarrage de pacemaker :          [ OK ]

Si le nœud a correctement démarré, le deuxième peut démarrer à son tour avec les même commandes. Vous devriez observer un peu d’animation dans les logs lorsque ldap2 rejoint le cluster :

Jul 29 14:36:49 [24013] ldap1.guillaume-leduc.fr crmd: info:
	peer_update_callback:
	Client ldap2.guillaume-leduc.fr/peer now has status [online]
(DC=<null>)

Note : pensez à désactiver SELinux (/etc/selinux/config) et à automatiser le démarrage des services avec chkconfig…

Les services de Pacemaker

Si toutes les traces montrent que Corosync fonctionne, on peut maintenant vérifier son état. Le processus Corosync peut s’occuper de lancer les services le composant si le numéro de version du service dans la configuration de celui-ci est à 0. Ils sont par défaut au nombre de six :

  • 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.

La commande ps va nous permettre de retrouver ces processus, ici avec « version » à 1 :

[root@ldap1 ~]# ps -e f
31382 ?     Ssl  0:05 corosync
31401 pts/0 S    0:00 pacemakerd
31407 ?     Ss   0:01 \_ /usr/libexec/pacemaker/cib
31408 ?     Ss   0:00 \_ /usr/libexec/pacemaker/stonithd
31409 ?     Ss   0:01 \_ /usr/libexec/pacemaker/lrmd
31410 ?     Ss   0:00 \_ /usr/libexec/pacemaker/attrd
31411 ?     Ss   0:00 \_ /usr/libexec/pacemaker/pengine
31412 ?     Ss   0:00 \_ /usr/libexec/pacemaker/crmd

Surveiller l’état du cluster

La commande crm_mon est un moniteur en temps réel de 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.

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 :

#crm_mon -1
Last updated: Wed Aug 7 09:19:04 2013
Last change: Wed Aug 7 09:15:54 2013 via crmd on ldap1
Stack: classic openais (with plugin)
Current DC: ldap1 - partition with quorum
Version: 1.1.9-55.5-2db99f1
2 Nodes configured, 2 expected votes
0 Resources configured.
 
 
Online: [ ldap1 ldap2 ]

Si on coupe le deuxième nœud (en stoppant le service Pacemaker par exemple) alors crm_mon reporte le changement :

#crm_mon -1
Last updated: Wed Aug 7 09:19:04 2013
Last change: Wed Aug 7 09:15:54 2013 via crmd on ldap1
Stack: classic openais (with plugin)
Current DC: ldap1 - partition with quorum
Version: 1.1.9-55.5-2db99f1
2 Nodes configured, 2 expected votes
0 Resources configured.
 
 
Online: [ ldap1 ]
OFFLINE: [ ldap2 ]

À ce stade vous pouvez en être convaincu : votre cluster fonctionne ! Les deux serveurs partagent leurs informations d’état. Corosync notifie Pacemaker des changements, ce dernier peut alors agir sur les différents nœuds et ressources qu’il gère.

Configuration de Pacemaker

Configuration initiale

Vous l’avez peut-être deviné (après avoir installé crmsh…), l’outil de configuration central se nomme crm. Il s’utilise en ligne de commande ou comme interpréteur de commande. Par exemple pour obtenir la configuration actuelle du cluster, vous pouvez taper ceci :

#crm configure show
node ldap1
node ldap2
property $id="cib-bootstrap-options" \
	dc-version="1.1.9-55.5-2db99f1" \
	cluster-infrastructure="classic openais (with plugin)" \
	expected-quorum-votes="2"

il est aussi possible d’obtenir le résultat en XML en ajoutant « xml » à la fin de la commande :

#crm configure show xml
<?xml version="1.0" ?>
<cib num_updates="6" dc-uuid="ldap1" update-origin="ldap1" crm_feature_set="3.0.7" validate-with="pacemaker-1.2" update-client="crmd" epoch="5" admin_epoch="0" cib-last-written="Wed Aug 7 09:15:54 2013" have-quorum="1">
  <configuration>
    <crm_config>
      <cluster_property_set id="cib-bootstrap-options">
        <nvpair id="cib-bootstrap-options-dc-version" name="dc-version" value="1.1.9-55.5-2db99f1"/>
        <nvpair id="cib-bootstrap-options-cluster-infrastructure" name="cluster infrastructure" value="classic openais (with plugin)"/>
        <nvpair id="cib-bootstrap-options-expected-quorum-votes" name="expected-quorum votes" value="2"/>
      </cluster_property_set>
    </crm_config>
 
    <nodes>
      <node id="ldap1" uname="ldap1"/>
      <node id="ldap2" uname="ldap2"/>
    </nodes>
    <resources/>
    <constraints/>
  </configuration>
</cib>

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

Si vous avez vérifié l’état du cluster avec crm_verify vous avez dû constater quelques erreurs relatives à STONITH. Nous n’allons pas utiliser ce service que nous pouvons désactiver :

#crm configure property stonith-enabled=false

Réutilisez crm configure show. Les changements ont été apportés !

Ajouter une ressource

Une ressource est ce qu’un cluster sait gérer : par exemple un service, un volume de données, une adresse IP, etc. Les nœuds ldap1 et ldap2 disposent de leur propre adresse IP. Or le service LDAP qui va être proposé par le cluster doit être accessible depuis une adresse unique qui basculera automatiquement d’une nœud à l’autre selon leur état. C’est la première ressource que nous allons configurer : l’adresse IP virtuelle du service.

Cette ressource a un nom et un intervalle de vérification par le heartbeat :

  • L’adresse est 192.168.100.10.
  • Le masque est /24
  • Le nom de la ressource est VIP (Wouh original !)
  • L’intervalle de vérification est de 10 secondes.

La commande suivante ajoute la ressource au cluster :

#crm configure primitive VIP ocf:heartbeat:IPaddr2 params \
|-> ip=192.168.100.10 \
|-> cidr_netmask=24 \
|-> nic=eth0 \
`-> op monitor interval=10s

Évidemment c’est à adapter en fonction de votre installation… Vous pouvez vérifier que la ressource est directement mise en place :

#ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 1000
	link/ether 00:50:56:06:a2:2c brd ff:ff:ff:ff:ff:ff
	inet 192.168.100.10/24 brd 192.168.0.255 scope global eth0
	inet 192.168.100.10/24 brd 192.168.0.255 scope global secondary
eth0
	inet6 fe80::250:56ff:fe06:a22c/64 scope link
		valid_lft forever preferred_lft forever

Explications. Le type de ressource a été défini par la partie « ocf:heartbeat:IPaddr2 ».

OCF est une classe de ressources qui propose un certain nombre de ressources intitulées Resources Agents, définies par le projet Open Cluster Framework. Leur site web fournit de nombreuses informations à ce sujet et n’hésitez pas à aller y faire un tour. Ces ressources sont très nombreuses et répondent à un grand nombre de besoins. Pour rappel, le but d’OCF est que toute solution de clustering libre ou non s’appuie sur ses recommandations pour fonctionner. (Voir le GitHub de ClusterLabs).

Pacemaker s’appuie sur OCF mais aussi d’autres classes de ressources dont la liste est simplement accessible :

sudo crm classes
lsb
ocf / heartbeat pacemaker redhat
service
stonith

Pacemaker propose ici trois types de ressources OCF : heartbeat, pacemaker et redhat. C’est ce qui correspond à la seconde valeur de la directive : heartbeat. La commande suivante permet de connaître toutes les ressources OCF proposées par Heartbeat et installées sur votre machine :

sudo crm ra list ocf heartbeat

Le nom de nombreuses ressource parle de lui-même. Les ressources sont des scripts (généralement shell) dont les paramètres d’entrée et sortie et les traitements sont standardisés. Vous pouvez les retrouver dans différents endroits de votre machine, chez moi elles sont toutes dans /usr/lib/ocf/resource.d/heartbeat/.

Dernier élément : la ressource, IPaddr2. Comme sont nom l’indique cette ressource permet la gestion d’une adresse IP virtuelle et prend plusieurs paramètres. Comme les développeurs ont pensé à tout, chaque ressource dispose d’un manuel accessible via la commande… man.

man ocf_heartbeat_IPaddr2

La mise en place d’un service modifie automatiquement la configuration du cluster. Cette configuration est automatiquement diffusée et appliquée sur l’ensemble des noeuds 🙂

Quorum du cluster

D’après Wikipédia, le quorum est, en droit, le nombre minimal de membres d’un corps délibératif nécessaire à la validité d’une décision.

En clustering c’est pareil le quorum est le nombre minimal de nœuds devant être disponibles pour que notre cluster fonctionne. Celui-ci est atteint si plus de la moitié des nœuds sont actifs.

Du coup si la moitié de nœuds tombe en panne, notre cluster tombe aussi tant que le quorum n’est pas de nouveau atteint. On va donc couper cette fonctionnalité pour notre cluster à 2 nœuds…

sudo crm configure property no-quorum-policy=ignore

Configuration de la ressource OpenLDAP

La première ressource étant configurée, nous allons pouvoir passer à la configuration de la ressource relative au service OpenLDAP, slapd, qui vous allez le voir est un peu particulière.

On commence par mettre en place la ressource OCF :

sudo crm resource primitive LDAP ocf:heartbeat:slapd params \
|-> config="/etc/openldap/slapd.conf" \
|-> pidfile="/var/run/openldap/slapd.pid" \
|-> user="ldap" group="ldap" \
|-> services="ldaps:///" \
|-> watch_suffix="dc=guillaume-leduc,dc=fr" \
|-> bind_dn="cn=Manager,dc=guillaume-leduc,dc=fr" \
|-> password="password_du_manager" \
`-> op monitor interval=10s

Normalement la ressource a correctement démarré sur le nœud 2 :

sudo crm_mon -1
Last updated: Wed Aug 7 10:28:08 2013
Last change: Wed Aug 7 10:27:14 2013 via cibadmin on ldap1
Stack: classic openais (with plugin)
Current DC: ldap1 - partition with quorum
Version: 1.1.9-55.5-2db99f1
2 Nodes configured, 2 expected votes
2 Resources configured.
 
Online: [ ldap1 ldap2 ]
 
  VIP	(ocf::heartbeat:IPaddr2):	Started ldap1
  LDAP	(ocf::heartbeat:slapd): 	Started ldap2

Problématique de réplication

À ce point, Pacemaker prendra en charge le démarrage et l’arrêt du service slapd en fonction du noeud sur lequel il sera présent. Sur l’autre, le service sera coupé. Oui mais voilà : la réplication OpenLDAP mise en place précédemment nécessite que le daemon soit démarré sur les deux noeud simultanément. Nous allons devoir utiliser le concept des clones.

Grâce à cela, Pacemaker saura que notre service OpenLDAP devra être démarré en même temps sur tous les noeuds. En d’autres termes… cloné. Cette notion est très utilisée dans le cadre de clusters Actifs / Actifs. Pour la mettre en place c’est très simple :

sudo crm configure clone CLONE-LDAP LDAP

Où CLONE-LDAP est l’identifiant du clone et LDAP l’identifiant de la ressource à cloner. Après cela, le moniteur devrait afficher quelque chose comme :

Last updated: Wed Aug 7 10:37:24 2013
Last change: Wed Aug 7 10:34:57 2013 via cibadmin on ldap1
Stack: classic openais (with plugin)
Current DC: ldap1 - partition with quorum
Version: 1.1.9-55.5-2db99f1
2 Nodes configured, 2 expected votes
3 Resources configured.
 
 
Online: [ ldap1 ldap2 ]
 
VIP	(ocf::heartbeat:IPaddr2):	Started ldap1
Clone Set: CLONE-LDAP [LDAP]
      Started: [ ldap1 ldap2 ]

La ressource est bien démarrée sur les deux noeuds 🙂

Groupes et colocation de ressources

Pourquoi grouper des ressources ?

Nous avons vu tout à l’heure lors de la déclaration de la ressource LDAP que celle-ci était automatiquement démarrée sur le deuxième noeud. Ce comportement de Pacemaker est tout à fait normal puisqu’il cherche à optimiser la charge de calcul du cluster, et donc à en répartir les ressources en fonction des noeuds. Cependant, et c’est notre cas, nous pouvons avoir besoin de lier des ressources afin que le comportement de l’une influe sur l’état de l’autre.

En effet, quel serait l’intérêt d’avoir la VIP pointant sur un noeud où OpenLDAP ne fonctionne plus ?

Pour lier nos ressources VIP et CLONE-LDAP entre elles, nous allons faire appel à la notion de colocation de ressources. Celle-ci se configure aussi de manière très simple :

sudo crm configure colocation VIP-LDAP INFINITY: VIP CLONE-LDAP

Où :

  • VIP-LDAP : est l’identifiant de la colocation.
  • INFINITY : est la « note » qui définit la force du lien entre les ressources.
  • VIP CLONE-LDAP : la liste de ressources à lier.

Le score INFINITY (ou inf) signifie que nos ressources fonctionneront toujours ensemble. À l’inverse, le mot clé INFINITY indique que les ressources ne fonctionneront jamais ensemble.

L’ordre des ressources listées influe sur le comportement de Pacemaker. Il faut donc bien faire attention.

Noeud de préférence

Nous pouvons configurer Pacemaker pour qu’il démarre nos ressources sur l’un ou l’autre des noeuds en priorité, et dans la mesure du possible. Si par exemple nous souhaitons que la VIP soit démarrée par défaut sur le maître :

sudo crm configure location LDAP-MASTER CLONE-LDAP 50: ldap1
sudo crm configure location VIP-MASTER VIP 50: ldap1

Le poids d’indice 50 est ici tout à fait arbitraire mais dépend des autres priorités définies sur votre cluster. Il peut très bien être remplacé par INFINITY. Pour connaîter l’état actuel des priorités de positionnement des ressources, c’est avec la commande :

ptest -sL

Exploitation du cluster

Petite section pour terminer regroupant différentes commandes et conseils utiles lors de la mise en production.

Migration d’une ressource

Permet de déplacer une ressource d’un nœud à l’autre, en toute transparence.

sudo crm resource migrate <id-resource> <noeud>

Maintenance d’une nœud

Vous pouvez placer un nœud en mode maintenance pour le sortir temporairement du cluster et y faire des opérations en toute sécurité.

sudo crm node standby <nœud>

Une fois les opérations terminées :

sudo crm node online <nœud>

Pour des opérations affectant le cluster (style mises à jour), je vous conseille de commencer par le nœud passif afin de vérifier que cela n’affecte par son comportement dans le cluster avant de passer à l’actif.

Reprise d’activité après basculement ou erreur

Chaque ressource dispose d’un compteur d’erreur. Si celui-ci atteint un certain nombre, la ressource n’est plus considérée comme fiable et la bascule est réalisée. Pour réinitialiser ce compteur et nettoyer les erreurs de tous les nœuds :

sudo crm resource failcount <id-ressource> delete <nœud>
sudo crm resource cleanup <id-ressource>

Conclusion

Pfiouuu !! Après tout ça vous devriez être en présence d’un truc plutôt sympa. Pour reprendre le schéma du début :

La couche SSL n'apparait pas sur le schéma...

La couche SSL n’apparait pas sur le schéma…

Franchement, j’ai pu m’amuser un peu avec ces technologies et c’est vraiment robuste. Entre le remplissage de la partition contenant la base de données OpenLDAP, l’arrêt violent de nœud, les coupures réseau… Le couple Corosync / Pacemaker fait vraiment très bien son travail et pour le coup, Linux est bluffant.

Sources

Cet article étant un peu plus long / technique que d’habitude, je me suis appuyé sur différentes ressources que je vous recommande chaudement :

  • Le livre Linux – Solutions de Haute-Disponibilité est un ouvrage de référence écrit par Sébastien Rohaut. Je cite quelques paragraphes donc j’espère que je n’enfreins pas son droit d’auteur…
  • Les excellents articles de Rémi sur binbash.fr. Là aussi beaucoup de choses intéressantes. Je le remercie d’ailleurs pour toutes les réponses apportées à mes questions 🙂
  • La documentation Red Hat, Corocync et Pacemaker.
  • La machine à café.

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email