Installation et configuration d'un cluster Heartbeat V2

1 Introduction

Heartbeat est l'un des cluster software les plus utilisés car il est très souple, puissant et stable. Nous allons donc voir comment précéder à une installation, configuration et surveillance des services pour Heartbeat 2. Heartbeat 2 va permettre par rapport à la version 1 de gérer plus de 2 noeuds.

Contrairement à la version 1 de Heartbeat, cette solution ne peut être montée en 30 min. Il faudra passer quelques heures dessus...

2 Installation

2.1 Via les depots officiels

Allez hop, comme dab, c'est relativement simple :

apt-get install heartbeat-2

2.2 Via des packages externes

Pour ceux qui ne veulent pas utiliser les packages Debian car pas assez complet, allez sur ce site http://download.opensuse.org/repositories/server:/ha-clustering/ et téléchargez les packages pour votre distribution (j'ai par exmemple prit ceux de Debian 64bits). Créer vous un dossier dans lequel vous aurez mis tous les packages et placez vous dedans, puis :

dpkg -i *
apt-get -f install

Ceci installera tous les packages ainsi que les dépendances.

Si vous souhaitez utiliser l'interface graphique, vous aurez également besoin d'installer ces packages :

apt-get install python-central python python-glade2 python-xml python-gtk2 python-gtkmvc 

Effectuez ceci sur les 2 noeuds. Ici ils s'appellent :

• deb-node1
• deb-node2

2.3 hosts

Pour faciliter la configuration et les transactions ha, configurez correctement votre fichier /etc/hosts sur tous les noeuds :

192.168.0.155   deb-node1
192.168.0.150   deb-node2

Un serveur DNS peut également faire l'affaire !

2.4 NTP

Veillez à ce que tous les serveurs aient la même heure. Il est donc conseillé de les synchroniser sur le même serveur NTP (ex : ntpdate 0.pool.ntp.org)

2.5 sysctl.conf

Nous allons modifier la gestion des fichiers "core". Heartbeat recommande de modifier la configuration par défaut en ajoutant la ligne suivante dans /etc/sysctl.conf :

kernel/core_uses_pid=1

Il faut ensuite appliquer cette configuration:

/etc/init.d/procps.sh restart

3 Configuration

Dans un premier temps, nous allons récupérer les fichiers de conf d'exemple :

cd /usr/share/doc/heartbeat-2
gzip -d ha.cf.gz haresources.gz
cp authkeys ha.cf haresources /etc/ha.d/

Ensuite nous allons commencer à editer les fichiers de configuration. Allez dans /etc/ha.d/

3.1 ha.cf

Un exemple de fichier de configuration du ha.cf peut être trouvé dans /usr/share/doc/heartbeat/ha.cf.gz.

Voici le contenu du fichier /etc/ha.d/ha.cf une fois modifié :

logfacility     local0 # Pour l'integration au syslog
auto_failback   off # Les services ne rebasculent pas automatiquement quand un noeud revient up
rtprio          5 # Assigne la priorité au service heartbeat
deadping        20 # Problème de noeud si il ne réponds pas au bout de 20 sec
 
autojoin        other # Autorise la connexions d'autres noeuds au cluster
node            deb-node1 # Mon premier noeud
node            deb-node2 # Mon second noeud
 
crm             on # On autorise les connexions via GUI
apiauth	mgmtd	uid=root
respawn	root	/usr/lib/heartbeat/mgmtd -v
 
respawn hacluster /usr/lib/heartbeat/ipfail # Lance une commande au boot du noeud
apiauth ipfail gid=haclient uid=root # On autorise root du group haclient

3.2 authkeys

Ce fichier sert à l'échange d'information entre les différents noeuds. Je peux choisir le sha1 comme algorithme de cryptage, suivit de ma passphrase :

#
#       Authentication file.  Must be mode 600
#
#
#       Must have exactly one auth directive at the front.
#       auth    send authentication using this method-id
#
#       Then, list the method and key that go with that method-id
#
#       Available methods: crc sha1, md5.  Crc doesn't need/want a key.
#
#       You normally only have one authentication method-id listed in this file
#
#       Put more than one to make a smooth transition when changing auth
#       methods and/or keys.
#
#
#       sha1 is believed to be the "best", md5 next best.
#
#       crc adds no security, except from packet corruption.
#               Use only on physically secure networks.
#
auth 1
1 sha1 This is my key !

On oublies pas de mettre les bons droits sur ce fichier :

chmod 0600 authkeys

3.3 Réplications et tests

Maintenant que nos fichiers sont prêts, nous allons les uploader sur les autres noeuds :

scp ha.cf autkeys deb-node2:/etc/ha.d/

Maintenant, il ne reste plus qu'a redémarrer les noeuds :

/etc/init.d/heartbeat restart
ssh root@deb-node2 /etc/init.d/heartbeat restart

Maintenant nous allons vérifier si tout fonctionne :

crm_mon -i 5

Le chiffre 5 correspond au nombre de secondes que le moniteur va essayer de regarder l'état du cluster. Si il essaye de se connecter continuellement et que vous n'avez rien de concluant, regardez vos logs :

$ tail /var/log/syslog
Jun 25 13:35:40 deb-node1 cib: [2739]: info: #========= Input message message start ==========#
Jun 25 13:35:40 deb-node1 cib: [2739]: info: MSG: Dumping message with 6 fields
Jun 25 13:35:40 deb-node1 cib: [2739]: info: MSG[0] : [t=cib]
Jun 25 13:35:40 deb-node1 cib: [2739]: info: MSG[1] : [cib_op=cib_query]
Jun 25 13:35:40 deb-node1 cib: [2739]: info: MSG[2] : [cib_callid=3]
Jun 25 13:35:40 deb-node1 cib: [2739]: info: MSG[3] : [cib_callopt=256]
Jun 25 13:35:40 deb-node1 cib: [2739]: info: MSG[4] : [cib_clientid=bc414c54-4630-456c-ad8a-6ab01b7e2152]
Jun 25 13:35:40 deb-node1 cib: [2739]: info: MSG[5] : [cib_clientname=2775]

Là nous rencontrons donc un problème qui apparait si heartbeat s'est lancé et a gardé en mémoire une ancienne configuration. Arrêtez donc tous les noeuds et supprimez le contenu du dossier /var/lib/heartbeat/crm :

/etc/init.d/heartbeat stop
rm /var/lib/heartbeat/crm/*
/etc/init.d/heartbeat start

Et maintenant nous allons regarder de nouveau l'état de notre cluster :

<nowiki>$ crm_mon -i5
 
Refresh in 5s...
============
Last updated: Tue Jun 26 06:58:38 2007
Current DC: deb-node2 (18ef92e2-cff0-469b-ab77-a2ef0e45ebd7)
2 Nodes configured.
0 Resources configured.</nowiki>

4 Configuration de services cluster

Le fichier qui va nous intéresser est /var/lib/heartbeat/crm/cib.xml (alias CIB).

4.1 crm_config

<nowiki>   <configuration>
     <crm_config>
       <cluster_property_set id="cib-bootstrap-options">
         <attributes>
           <nvpair name="default_resource_stickiness" id="options-default_resource_stickiness" value="0"/>
           <nvpair id="options-transition_idle_timeout" name="transition_idle_timeout" value="61s"/>
           <nvpair id="symmetric_cluster" name="symmetric_cluster" value="true"/>
           <nvpair id="no_quorum_policy" name="no_quorum_policy" value="stop"/>
           <nvpair id="default_resource_failure_stickiness" name="default_resource_failure_stickiness" value="0"/>
           <nvpair id="stonith_enabled" name="stonith_enabled" value="false"/>
           <nvpair id="stop_orphan_resources" name="stop_orphan_resources" value="true"/>
           <nvpair id="stop_orphan_actions" name="stop_orphan_actions" value="true"/>
           <nvpair id="remove_after_stop" name="remove_after_stop" value="true"/>
           <nvpair id="is_managed_default" name="is_managed_default" value="true"/>
           <nvpair id="short_resource_names" name="short_resource_names" value="true"/>
         </attributes>
       </cluster_property_set>
     </crm_config></nowiki>

• default_resource_stickiness : vous préférez garder votre service le noeud actuel ou le bouger sur un qui a plus de ressources disponibles ? Cette option est équivalent à "auto_failback on" à l'exeption que les ressources peuvent bouger sur d'autres noeuds que celui sur lesquel elles étaitent activées.
  • 0 : Si la valeur est à 0, des ressources y seront automatiquement assignées.
  • > 0 : La ressource préfèrera retourner elle même à son noeud d'origine, mais elle peut également bouger si ce noeud n'est pas disponible. Une valeur plus forte renforcera la ressource à rester là où elle est actuellement.
  • < 0 : La ressource préfèrera bouger ailleur que là où elle est actuellement. Une valeur plus forte entrainera le déplacement de cette ressource.
  • INFINITY : La ressource retournera toujours à sa place initiale à moins qu'elle y soit forcée (noeud éteint, stand bye...). Cette option est équivalente à "auto_failback off" à l'exeption que les ressources peuvent bouger sur d'autres noeuds que celui sur lesquel elles étaitent activées.
  • -INFINITY : Les ressources iront automatiquement sur un autre noeud.

• options-transition_idle_timeout (60s par défaut) : Si aucunes action n'a été détectée pendant ce temps, la transition est considérée comme échouée. Si chaque opérations initialisées à un timeout plus élevé, alors il sera prit en compte.

• symmetric_cluster (true par défaut) : Spécifie que les ressources peuvent être lancées sur n'importe quel noeud. Sinon, il faudra créer des "constraints" spécifique pour chaque ressources.

• no_quorum_policy (stop par défaut) :
  • ignore : Prétend que nous avons un quorum
  • freeze : ne démarre aucunes ressources non présentes dans notre partition. Les ressources dans notre partition peuvent être déplacer sur un autre noeud avec la partition (fencing désactivé).
  • stop : stop toutes les ressources activées dans notre partition (fencing désactivé)

• default_resource_failure_stickiness : forcer une ressource à migrer après un échec.

• stonith_enabled (false par défaut) : Les noeuds en échec seront fencés.

• stop_orphan_resources (true par défaut) : Si une ressource est trouvée n'ayant pas de définition.
  • true : arrête l'action
  • false : ignore l'action

Cela affecte plus le comportement de CRM quand la ressource est supprimée par un admin sans qu'il l'ai arrêtée au préalable.

• stop_orphan_actions (true par défaut) : Si une action récursive est trouvée et qu'il n'y a pas de définition :
  • true : arrête l'action
  • false : ignore l'action

Cela affecte plus le comportement de CRM quand l'intervalle pour une action récurente est modifiée.

• remove_after_stop : Cela supprime la ressource de la section "status" du CIB.

• is_managed_default (true par défaut) : A moins que la définition de la ressource dise autrement :
  • true : la ressource sera démarrée, arrêtée, monitorée et déplacée sir besoin.
  • false : la ressource ne sera pas démarrée si arrêtée, arrêtée si démarrée et non plus si elle a des action récurentes planifiées.

• short_resource_names (false par défaut, true recommandé) : Cette option est pour avoir une compatibilitée avec les versions antérieures à 2.0.2

4.2 nodes

<nowiki>     <nodes>
       <node id="cdd9b426-ba04-4bcd-98a8-76f1d5a8ecb0" uname="deb-node3" type="normal"/>
       <node id="18ef92e2-cff0-469b-ab77-a2ef0e45ebd7" uname="deb-node2" type="normal"/>
       <node id="08f85a1b-291f-46a7-b2d8-cab46788e23d" uname="deb-node1" type="normal"/>
     </nodes></nowiki>

Ici nous allons donc définir nos neuds.

• id : il est automatiquement généré au lancement de heartbeat et change en fonction de plusieurs critères.
• uname : nom des noeuds.
• type : normal, member ou ping.

Si vous ne savez pas quoi mettre car les id n'ont pas été encore générés, mettez ceci :

      <node/>

4.3 ressources

<nowiki> 26      <resources>
 27        <group id="group_1">
 28          <primitive class="ocf" id="IPaddr_192_168_0_90" provider="heartbeat" type="IPaddr">
 29            <operations>
 30              <op id="IPaddr_192_168_0_90_mon" interval="5s" name="monitor" timeout="5s"/>
 31            </operations>
 32            <instance_attributes id="IPaddr_192_168_0_90_inst_attr">
 33              <attributes>
 34                <nvpair id="IPaddr_192_168_0_90_attr_0" name="ip" value="192.168.0.90"/>
 35              </attributes>
 36            </instance_attributes>
 37            <instance_attributes id="IPaddr_192_168_0_90">
 38              <attributes>
 39                <nvpair id="IPaddr_192_168_0_90-apache2" name="apache2" value="started"/>
 40              </attributes>
 41            </instance_attributes>
 42          </primitive>
 43          <primitive class="lsb" provider="heartbeat" type="apache2" id="apache2_2">
 44            <operations>
 45              <op id="apache2_2_mon" interval="120s" name="monitor" timeout="60s"/>
 46            </operations>
 47            <instance_attributes id="apache2_2">
 48              <attributes>
 49                <nvpair id="apache2_2-deb-node2" name="deb-node2" value="started"/>
 50                <nvpair id="apache2_2-group_1" name="group_1" value="stopped"/>
 51                <nvpair name="target_role" id="apache2_2-target_role" value="started"/>
 52              </attributes>
 53            </instance_attributes>
 54          </primitive>
 55          <instance_attributes id="group_1">
 56            <attributes>
 57              <nvpair id="group_1-deb-node2" name="deb-node2" value="started"/>
 58              <nvpair id="group_1-apache2_2" name="apache2_2" value="stopped"/>
 59            </attributes>
 60          </instance_attributes>
 61        </group>
</nowiki>

• L26 : Ici nous avons donc créer un groupe. Je vous le conseil fortement, pour éviter de faire des conneries. Le groupe s'appelle "group_1".

• L27 : Ensuite nous lui insérons "IPaddr_192_168_0_90" comme nom pour la définition d'une adresse IP. Le type étant "IPaddr".
  
• L29 : Nous lui insérons une opération de monitoring pour qu'il check toutes les 5 sec si tout se passe bien avec un timeout de 5 sec.
  
• L34 : Au niveau des attributs, nous lui mettons l'adresse IP virtuelle que nous souhaitons utiliser.
  
• L39 : On va lui définir une instance qui va permettre de faire fonctionner apache2 (non configuré encore) et l'adresse IP.

• L43 : Maintenant on créer la primitive pour Apache2
• L45 : On va monitorer apache2 toutes les 120s avec un timeout de 60s
• L49 : Apache2 doit démarrer sur le noeud2 par défaut
• L50 : On lui indique que group
• L51 : L'état d'Apache2 doit être démarré par défaut

Le plus simple, pour éviter de se prendre la tête, c'est d'utilier le GUI heartbeat. Il vous fera la configuration :-)

4.4 constraints

<nowiki> 98      <constraints>
 99        <rsc_location id="rsc_location_group_1" rsc="group_1">
100          <rule id="prefered_location_group_1" score="100">
101            <expression attribute="#uname" id="prefered_location_group_1_expr" operation="eq" value="deb-node1"/>
102          </rule>
103        </rsc_location>
104        <rsc_location id="cli-prefer-apache2_2" rsc="apache2_2">
105          <rule id="cli-prefer-rule-apache2_2" score="INFINITY">
106            <expression id="cli-prefer-expr-apache2_2" attribute="#uname" operation="eq" value="deb-node2" type="string"/>
107          </rule>
108        </rsc_location>
109      </constraints>
110    </configuration>
111  </cib>
</nowiki>

Les contrataints servent à indiquer qui doit démarrer avant qui. A vous de voir selon vos besoins.

5 Management des Services Cluster

Pour commencer, je vous invite fortement à consulter cette page.

Pour lister les services, voici la commande :

crm_resource -L

5.1 Préparation d'un service cluster

Avant de continuer, assurez-vous que les fichiers de configuration des deux serveurs sont identiques, et que les services sont arrêtés (ici apache2):

/etc/init.d/apache2 stop

Il faut ensuite faire en sorte que les services gérés par Heartbeat ne soient plus lancés automatiquement au démarrage de Linux :

update-rc.d -f apache2 remove

Vous pouvez maintenant taper (sur les 2 serveurs) :

/etc/init.d/heartbeat start

Au bout de quelques instants, les services se sont normalement lancés sur la première machine, pendant que l'autre est en attente.

5.2 Basculer un service sur un autre noeud

Pour basculer par exemple notre service apache2 (apache2_2) sur le deuxième noeud (deb-node2) :

crm_resource -M -r apache2_2 -H deb-node2

Si vous voulez basculer un service d'un noeud sur lui même, vous aurez l'erreur suivante :

Error performing operation: apache2_2 is already active on deb-node2

5.3 Démarrer un service

Pour démarrer un service cluster c'est assez simple. Ici nous voulons démarrer apache2 (apache2_2)

crm_resource -r apache2_2 -p target_role -v started

Si jamais vous souhaitez faire démarrer apache2 sur le deuxième noeud, vous devez d'abord le réalouer avant de le démarrer (documentation ici). Ex :

crm_resource -M -r apache2_2 -H deb-node2
crm_resource -r apache2_2 -p target_role -v started

Ceci va donc basculer apache2_2 qui tournait (donc actuellement arrêté) sur le deuxième noeud, mais ça ne va pas le démarrer pour autant. Il faudra donc lancer la deuxième ligne pour le démarrer.

5.4 Ajout d'un noeud supplémentaire

Alors voilà, il existe plusieurs solutions. Je vous donne celle qui à mon sens me semble la meilleure. Dans le fichier /etc/ha.d/ha.cf vérifiez ceci (sinon il faudra reloader la conf de votre heartbeat, ce qui entrainera une petite coupure) :

autojoin        other # Autorise la connexions d'autres noeuds au cluster

Ceci va donc autoriser des noeuds qui ne sont pas entrés dans le fichier ha.cf à se connecter.

Pour celà, un minimum de sécurité est obligatoire, c'est pour ca qu'il faut quand même copier les fichier ha.cf et authkeys sur deb-node3 (mon nouveau noeud).
Note : Editez d'abord le fichier ha.cf pour le rajouter le nouveau noeud. Ce qui pourra vous permettre au prochain démarrage d'avoir ce noeud en dur :

autojoin        other # Autorise la connexions d'autres noeuds au cluster
node            deb-node1 # Mon premier noeud
node            deb-node2 # Mon second noeud
node            deb-node3 # Mon 3eme noeud

Maintenant on envoie tout ça sur le nouveau noeud et on oublies pas de lui mettre les bons droits :

cd /etc/ha.d/
scp ha.cf authkeys deb-node3:/etc/ha.d/
ssh deb-node3 chown hacluster:haclient /var/lib/heartbeat/crm/*

Et maintenant le 3ème noeud rejoint le cluster :

$ /etc/init.d/heartbeat restart
$ crm_mon -i5
Node: deb-node2 (18ef92e2-cff0-469b-ab77-a2ef0e45ebd7): online
Node: deb-node1 (08f85a1b-291f-46a7-b2d8-cab46788e23d): online
Node: deb-node3 (cdd9b426-ba04-4bcd-98a8-76f1d5a8ecb0): online

Et voilà, c'est intégré et sans coupures :-)

En cas de création d'une nouvelle machine par "rsync" d'une machine du cluster, il faut impérativement supprimer les fichiers suivants sur la nouvelle machine :

rm /var/lib/heartbeat/hb_uuid

6 FAQ

FAQ Clusterlab (Excellent site)

7 Ressources

Documentation sur la mise en place d'Heartbeat 2
Documentation on Setting up a Web Server with Apache, LVS and Heartbeat 2
Documentation on Heartbeat2 Xen cluster with drbd8 and OCFS2
Enable high availability for composite applications
http://en.wikipedia.org/wiki/High_availability