Des clusters avec Pacemaker



  • Pacemaker est un outil de gestion de ressources (une VIP, un service) pour vos clusters. Il va gérer la haute disponibilité en s’occupant de leur démarrage, redémarrage, arrêt. La communication entre vos nœuds et la gestion du cluster en lui-même seront assurées par une brique dédiée comme par exemple Corosync (ou une technologie plus ancienne mais dont le nom est plus connu : heartbeat). Grâce à ce couple, il est possible de monter rapidement des clusters à n nœuds et de gérer n’importe lequel de vos services. La seule “contrainte” est d’avoir un script pour lancer votre service qui doit répondre à une commande start, stop et status. Une autre possibilité sympathique : le mode actif/actif. Mais aussi la gestion des quorums, le stonith…

    0_1522745777547_pcmk-active-passive.png
    1_1522745799545_Pacemaker-n-plus-1.png
    0_1522745799543_Pacemaker-n-to-n.png

    Problèmes rencontrés : rappels

    Il faut bien garder en tête que ce n’est pas parce que le service A ou B est dans un cluster qu’il n’y aura plus jamais de problème. Un cluster, de par son concept, peut se retrouver confronté à un problème de taille : le “split-brain”. C’est le principal problème qu’il faut absolument é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).
    • Un autre problème possible : quand votre nœud maître rencontre un problème, le cluster “bascule” . Un autre nœud prend la main et devient maître à son tour : il fournit le service. Mais dans quel état est l’autre nœud ? Comment s’assurer qu’il ne fournit pas encore le service au risque de bloquer/corrompre des ressources partagées ? Il n’y a pas vraiment de réponse à ce problème mais une solution, pas forcement évidente à mettre en place : Stonith.
      Stonith ou “Shoot The Other Node In The Head” ou encore “Shoot The Offending Node In The Head”. C’est une méthode d’isolation d’un nœud (fencing) qui pour une raison ou une autre ne répond plus. L’idée est d’éviter à tout prix le fameux split-brain qui peut amener tous vos nœuds à fournir le même service (ou à ne plus le fournir du tout). Le nœud jugé hors service sera donc, en général, redémarré ou arrêté électriquement (via IPMI par exemple). Voir l’article suivant pour plus d’informations : STONITH Deathmatch Explained.
    • Pour finir, un autre point bloquant peut être le quorum : c’est le nombre minimum de nœuds en ligne pour être capable de valider une décision. Dans le cas d’un cluster avec Pacemaker, il faut que plus de la moitié des nœuds soit en ligne. Avec un cluster à deux nœuds, il n’y a plus de quorum dès qu’un nœud est perdu. Il va donc falloir demander à Pacemaker d’ignorer le quorum dans cette situation. Le fonctionnement par défaut quand le quorum n’est pas atteint est de couper toutes les ressources !

    Pour résumer :

    • Utilisez toujours deux liens réseau différents pour la communication entre vos nœuds.
    • Si vous utilisez des ressources partagées, utilisez Stonith. Si vous le pouvez, utilisez systématiquement Stonith.
    • Ignorez la perte du quorum si vous n’en avez pas besoin.

    Corosync et Pacemaker

    Installation

    Nous allons voir ici l’installation et la configuration de Corosync. Corosync va s’occuper de la mise en cluster de vos serveurs. Corosync est disponible dans de nombreuses distributions. Sur une Debian Squeeze, il s’installe via :

    apt-get install corosync
    

    Maintenant que la couche de communication entre les nœuds est installée, passons à l’installation de la couche de gestion des ressources. Pacemaker a été intégré dans le projet Debian depuis la Squeeze. Le paquet est également disponible sur d’autres distributions. Pour l’installer sur une Debian Squeeze :

    apt-get install pacemaker
    

    Configuration de Corosync

    Editer le fichier de configuration de Corosync : /etc/corosync/corosync.conf (ce fichier doit être le même sur l’ensemble de vos noeuds). L’idée est d’augmenter un peu certains timers qui sont un petit peu bas (risque de déclarer un nœud hors service à tort par exemple) :

    paramètre valeur
    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.

    Il faut maintenant déclarer une interface réseau qui servira à la communication entre vos nœuds. Si vous ne faites pas de bonding, il faudra en déclarer une seconde pour éviter un “split-brain”.

    Pour déclarer une interface réseau :

    interface {
    ringnumber: 0
    bindnetaddr: 10.0.0.0
    mcastaddr: 226.94.1.1
    mcastport: 5405
    }
    

    Il vous faudra remplacer/rajouter :

    • Votre adresse de réseau au niveau de bindnetaddr. Si par exemple, votre eth0 porte l’adresse IP 192.168.1.10 avec un netmask de 24, renseignez 192.168.1.0.
    • Votre adresse de diffusion multicast et son port (ou utiliser celle là).
    • Pour rajouter une deuxième interface, rajoutez 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 changer 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: 10.0.0.0
      mcastaddr: 226.94.1.1
      mcastport: 5405
    }
    
    interface {
      ringnumber: 1
      bindnetaddr: 192.168.0.0
      mcastaddr: 226.94.2.1
      mcastport: 5405
    }
    

    A savoir : si une de ces interfaces est en erreur, on a un message d’erreur dans les logs :

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

    Il peut arriver de devoir remonter l’interface manuellement quand le problème est résolu via corosync-cfgtool -r (c’est le cas si on a désactivé manuellement l’interface). corosync-cfgtool -s vous donne l’état de vos interfaces.

    Il est déconseillé de faire du broadcast, préférez le multicast. Si vous utilisez du broadcast pour la communication entre vos nœuds et que vous avez plusieurs clusters différents sur le même VLAN, vos différents nœuds vont tenter de se connecter au cluster voisin (sans y parvenir, car ils n’ont pas la bonne clé) et générer des erreurs d’authentification visibles dans les logs.

    Intégration de Pacemaker

    Il faut maintenant rajouter le service Pacemaker dans votre cluster Corosync. Rajoutez le bloc suivant dans votre fichier de configuration Corosync s’il n’a pas été rajouté à l’installation de Pacemaker :

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

    Authentification

    • A l’installation du paquet, une clé a été générée pour authentifier votre nœud sur le cluster. Si vous souhaitez la recréer :
    corosync-keygen
    
    • Il faut ensuite envoyer la clé sur les nœuds qui composent votre cluster :
    scp /etc/corosync/authkey root@mon_autre_nœud:/etc/corosync
    

    La configuration du cluster est terminée. Activez le démarrage de corosync dans le fichier /etc/default/corosync. Il se démarre ensuite via /etc/init.d/corosync start. Nous verrons plus bas pour la configuration de Pacemaker.

    crm_mon

    Votre cluster est démarré : vous pouvez vous connecter au moniteur de Pacemaker via la commande crm_mon -1. Vous obtiendrez quelque chose de semblable :

    ============
    Last updated: Fri Sep  9 23:38:26 2011
    Stack: openais
    Current DC: ha-test1 - partition with quorum
    Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
    2 Nodes configured, 2 expected votes
    0 Resources configured.
    ============
    
    Online: [ ha-test1 ha-test2 ]
    

    Cet utilitaire remonte un certain nombre d’informations sur l’état général de votre cluster (nœuds ok, hs, offline ou en standby) mais aussi sur l’état de vos ressources (quel nœud gère quelle ressource, les éventuels problèmes rencontrés lors du lancement ou du monitoring de vos ressources…). Dans cet exemple, on peut lire :

    • Last updated et stack : la dernière mise à jour des informations du moniteur et la couche de message utilisée. Openais car Corosync est dérivé d’Openais.
    • Current DC : c’est le nœud qui va coordonner les actions sur le cluster. Les autres nœuds remonteront leurs informations au nœud DC. Ce nœud n’est pas nécessairement le nœud “maître” de votre cluster.
    • Nodes & votes : le nombre de nœuds et le nombre de votes disponibles pour le quorum.
    • Resources configured : le nombre de ressources configurées dans votre cluster.
    • Online : la liste des nœuds online. On pourra trouver ici, la liste des nœuds offline ou en stand-by.

    Configuration de Pacemaker

    Avant de déclarer vos ressources, il faut configurer Pacemaker pour décrire le fonctionnement attendu de votre cluster : action en cas de perte du quorum, utilisation de stonith… Ce sont les deux points que nous allons voir dans l’exemple qui suit.

    Pour configurer votre cluster, nous allons nous connecter au cli Pacemaker (sur le nœud de votre choix) via la commande crm :

    root@ha-test2:~# crm
    crm(live)# help
    This is the CRM command line interface program.
    Available commands:
    	cib              manage shadow CIBs
    	resource         resources management
    	node             nodes management
    	options          user preferences
    	configure        CRM cluster configuration
    	ra               resource agents information center
    	status           show cluster status
    	quit,bye,exit    exit the program
    	help             show help
    	end,cd,up        go back one level
    
    crm(live)#
    

    L’aide via help est disponible pour chaque commande. Passez dans le menu configure et tapez show. C’est votre configuration par défaut.

    crm(live)configure# show
    node ha-test1
    node ha-test2
    

    La liste de vos nœuds est affichée. Une commande edit permet d’éditer ce fichier. On peut aussi utiliser un certain nombre de commandes (voir help) pour modifier le comportement du cluster. On va ici désactiver le stonith et ignorer la perte du quorum : dans votre cli crm, en mode configure, tapez la commande suivante :

    property stonith-enabled="false" no-quorum-policy="ignore"
    
    • Vérifiez avec show que la configuration est ok.
    • Il faut ensuite pousser les modifications sur l’ensemble des nœuds via la commande commit.

    Pour résumer :

    crm(live)configure# property stonith-enabled="false" \
    	 no-quorum-policy="ignore"
    
    crm(live)configure# show
    node ha-test1
    node ha-test2
    property $id="cib-bootstrap-options" \
    	stonith-enabled="false" \
    	no-quorum-policy="ignore"
    
    crm(live)configure# commit
    WARNING: CIB changed in the meantime: won't touch it!
    Do you still want to commit? y
    

    Vous pouvez ignorer le WARNING au moment du commit. Votre cluster est maintenant prêt à recevoir les ressources : Apache, MySQL, DRBD, des VIPs… A suivre dans une série d’articles autour de Pacemaker.

    Plus d’informations sur ClusterLabs