Pacemaker 1.1



  • Il existe aujourd’hui plusieurs séries de Pacemaker : la version 1.0 sur laquelle sont basés les précédents tutoriels (la version stable actuelle), la version 1.2 qui sera la future version stable et la version 1.1 qui contient les nouvelles fonctionnalités en provenance de la version de dev et les corrections de bugs. C’est sur cette version que sera basé Pacemaker 1.2 qui devrait sortir en fin d’année. Pour pouvoir utiliser la version 1.1 en production, les développeurs ont rajoutés 2 nouveaux schémas de configuration. Avec cette nouvelle version, vous pouvez utiliser Corosync 2.0, utiliser de nouvelles fonctionnalités (déplacer les ressources en fonction de l’utilisation de votre serveur, gestion des ACLs…).

    0_1522746606676_versions_pacemaker.jpg

    Choix du schéma

    A ce jour, vous avez le choix entre les schémas suivants :

    • pacemaker-1.0 qui correspond d’un point de vue fonctionnalité à la version actuelle (et restera identique).
    • pacemaker-1.1 qui sert de tests pour les nouvelles fonctionnalités.
    • pacemaker-1.2 qui apporte les nouvelles fonctionnalités testées dans la version 1.1. Quand une nouvelle fonctionnalité apparaît dans cette version, sa syntaxe ne changera plus, ni dans la version 1.1, ni dans la version 1.2.

    Vous pouvez donc utiliser sans risque en production la version 1.1 de Pacemaker avec le schéma 1.0 (pour conserver la syntaxe actuelle) ou le schéma 1.2 (pour utiliser de nouvelles fonctionnalités stables). Le schéma 1.1 servira a tester uniquement des fonctionnalités expérimentales : son usage est à proscrire en production !

    Installation

    Pacemaker 1.1 est disponible sur les backports Debian. Pour l’installer, à partir d’une Debian Squeeze fraîchement installée :

    • Activez les backports Squeeze : rajoutez la ligne suivante dans votre sources.list (ou créez le fichier /etc/apt/sources.list.d/backports.list avec ce contenu) :
    deb http://backports.debian.org/debian-backports squeeze-backports main
    
    • Après une mise à jour de la liste des paquets, installez Pacemaker 1.1 :
    apt-get update && apt-get install -t squeeze-backports pacemaker
    

    Configuration

    corosync.conf

    J’utilise une configuration similaire à celle détaillée dans l’article “Des clusters avec Pacemaker”. Avec Corosync < 2.0, seule la partie sur le “plugin” Pacemaker change (le ver passe de 0 à 1). Depuis la version 1.1.3 de Pacemaker, il est possible d’utiliser le master control process (MCP) et un script d’init dédié pour gérer le service Pacemaker. Pacemaker devient indépendant de la couche de message Corosync. Cela évite des problèmes de démarrage ou d’arrêt des process Pacemaker (vécu inside). Au niveau de la configuration, on obtient :

    totem {
        version: 2
        secauth: on
        threads: 0
        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
            }
    
        }
    
    logging {
        fileline: off
        to_stderr: no
        to_logfile: no
        to_syslog: yes
        debug: on
        timestamp: on
    }
    
    amf {
        mode: disabled
    }
    
    service {
        # Load the Pacemaker Cluster Resource Manager
        ver: 1
        name: pacemaker
    }
    

    Avec cette configuration, vous devez démarrer Pacemaker comme un service. Vous ne pouvez pas démarrer Pacemaker si Corosync ne fonctionne pas ou vous ne pouvez pas arrêter Corosync si Pacemaker est en fonctionnement.

    Avant de démarrer Corosync, il faudra générer une clé pour la communication de vos noeuds avec corosync-keygen sur l’un des noeuds. Copiez ensuite le fichier /etc/corosync/authkey sur l’autre noeud.

    Activez ensuite le démarrage de Corosync au boot en modifiant le fichier /etc/default/corosync :

    # start corosync at boot [yes|no]
    START=yes
    

    Vous pouvez démarrer Corosync via /etc/init.d/corosync start sur chaque noeud et vérifier que la communication entre les noeuds fonctionne :

    root@ha1:~# corosync-cfgtool -s
    Printing ring status.
    Local node ID 1097041162
    RING ID 0
    	id	= 10.0.0.0
    	status	= ring 0 active with no faults
    

    Démarrez ensuite Pacemaker avec /etc/init.d/pacemaker start. Votre cluster est prêt pour recevoir sa configuration.

    Attention : à ce jour, le script d’init de Pacemaker ne contient pas les informations nécessaires pour un démarrage de Pacemaker au boot de votre serveur. Il faudra le modifier pour rajouter les runlevels de démarrage et d’arrêt :

    ### BEGIN INIT INFO
    # Provides: pacemaker
    # Required-Start: $network corosync
    # Should-Start: $syslog
    # Required-Stop: $network
    # Default-Start: 2 3 4 5
    # Default-Stop: 0 1 6
    # Short-Description: Starts and stops Pacemaker Cluster Manager.
    # Description: Starts and stops Pacemaker Cluster Manager.
    ### END INIT INFO
    

    Activez ensuite ce script d’init avec insserv -v /etc/init.d/pacemaker.

    A savoir : il existe une alternative à cette configuration en utilisant le plugin Corosync CMAN. J’y reviendrais dans un autre article…

    Choix du schéma

    Après avoir démarré Corosync et Pacemaker, vous pouvez choisir le schéma de configuration à utiliser :

    cibadmin -modify -xml-text '<cib validate-with="pacemaker-1.2"/>'
    

    C’est terminé. Vous pouvez utiliser les configurations proposées dans les tutoriels précédents : rien ne change. A suivre : gestion des ACLs, déplacement des ressources en fonction de l’utilisation des noeuds…
    Source : http://theclusterguy.clusterlabs.org