cluster on binbash.fr https://binbash.fr/tags/cluster/ Recent content in cluster on binbash.fr https://binbash.fr/img/logo-large-binbash-black-nobackground.png https://binbash.fr/img/logo-large-binbash-black-nobackground.png Hugo -- gohugo.io fr-fr Tue, 21 Aug 2012 00:00:00 +0000 Pacemaker 1.1 https://binbash.fr/posts/pacemaker-1-1/ Tue, 21 Aug 2012 00:00:00 +0000 https://binbash.fr/posts/pacemaker-1-1/ <p>Il existe aujourd&rsquo;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&rsquo;est sur cette version que sera basé Pacemaker 1.2 qui devrait sortir en fin d&rsquo;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&rsquo;utilisation de votre serveur, gestion des ACLs&hellip;).</p> 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…).

Les versions de Pacemaker

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
}

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. Plus de détails ici.

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

]]> Cluster Pacemaker : group/colocation/order https://binbash.fr/posts/cluster-pacemaker-groupcolocationorder/ Mon, 23 Apr 2012 00:00:00 +0000 https://binbash.fr/posts/cluster-pacemaker-groupcolocationorder/ <p>Dans les <a href="https://binbash.fr/tags/pacemaker/">précédents articles</a> sur le thème clusters/Pacemaker, nous avons aperçu rapidement une solution qui permet de regrouper les ressources sur un seul et même nœud (une VIP et son service par exemple) : l&rsquo;utilisation de la commande <em>group</em>. J&rsquo;avais alors évoqué la problématique liée à son utilisation et le fait qu&rsquo;il était parfois préférable d&rsquo;utiliser une solution à base de <em>colocation/order</em>. Le but étant d&rsquo;éviter l&rsquo;arrêt en cascade des ressources groupées. Je vais essayer ici de détailler la problématique et d&rsquo;y apporter une solution.</p> Dans les précédents articles sur le thème clusters/Pacemaker, nous avons aperçu rapidement une solution qui permet de regrouper les ressources sur un seul et même nœud (une VIP et son service par exemple) : l’utilisation de la commande group. J’avais alors évoqué la problématique liée à son utilisation et le fait qu’il était parfois préférable d’utiliser une solution à base de colocation/order. Le but étant d’éviter l’arrêt en cascade des ressources groupées. Je vais essayer ici de détailler la problématique et d’y apporter une solution.

Pourquoi grouper les ressources

Si vous ne groupez pas vos ressources, elles vont être lancées sur des nœuds différents (c’est le fonctionnement par défaut de Pacemaker qui va chercher à optimiser votre cluster). Si je reprends l’exemple de la VIP et de son service et que je ne groupe pas les ressources, il y a de fortes chances pour que la VIP se retrouve sur un nœud et le service sur l’autre. C’est ce qu’il se passe avec cet exemple : je déclare deux ressources VIP et SERVICE (deux ressources qui ne font rien, c’est juste pour tester le comportement du cluster).

La configuration :

property no-quorum-policy="ignore"
property stonith-enabled="false"
primitive VIP ocf:heartbeat:Dummy
primitive SERVICE ocf:heartbeat:Dummy

On obtient ce résultat visible via crm_mon :

============
Last updated: Wed Apr 17 11:15:25 2012
Stack: openais
Current DC: test-ha1 - partition with quorum
Version: 1.0.9
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Online: [ test-ha1 test-ha2 ]

VIP       (ocf::heartbeat:Dummy): Started test-ha1
SERVICE   (ocf::heartbeat:Dummy): Started test-ha2

La VIP et le SERVICE sont sur deux nœuds différents. Pour corriger ce comportement, on peut :

  • Utiliser la commande group : les ressources doivent fonctionner ensemble.
  • Utiliser des contraintes sur les ressources avec colocation et order : on lie une ressource à une autre.

Grouper les ressources

Une première solution est de grouper les ressources avec la commande group (attention l’ordre des ressources est important) :

group NOM_DU_GROUPE VIP SERVICE

Quand je groupe des ressources, ici la VIP et le SERVICE, je signifie que :

  • La VIP et le SERVICE doivent fonctionner ensemble sur le même nœud.
  • Dans cet exemple la VIP doit démarrer avant le SERVICE.
  • Le SERVICE à besoin de la VIP pour fonctionner.
  • Si la VIP est arrêtée (volontairement ou pas), le SERVICE s’arrête.
  • L’inverse n’est pas vrai : la VIP peut fonctionner sans le SERVICE.

Je groupe ma VIP et mon SERVICE :

crm(live)configure# group MON_SERVICE_HA VIP SERVICE
crm(live)configure# commit

Et j’obtiens dans mon crm_mon :

============
Last updated: Wed Apr 17 12:52:28 2012
Stack: openais
Current DC: test-ha1 - partition with quorum
Version: 1.0.9
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ test-ha1 test-ha2 ]

 Resource Group: MON_SERVICE_HA
     VIP        (ocf::heartbeat:Dummy): Started test-ha1
     SERVICE    (ocf::heartbeat:Dummy): Started test-ha1

J’ai le comportement recherché. Les deux ressources fonctionnent sur le même noeud. On va tester l’arrêt du SERVICE, la VIP ne doit pas s’arrêter :

root@test-ha1:~# crm resource stop SERVICE
root@test-ha1:~# crm_mon -1
============
Last updated: Wed Apr 17 12:56:47 2012
Stack: openais
Current DC: test-ha1 - partition with quorum
Version: 1.0.9
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ test-ha1 test-ha2 ]

 Resource Group: MON_SERVICE_HA
     VIP	(ocf::heartbeat:Dummy):	Started test-ha1
     SERVICE	(ocf::heartbeat:Dummy):	Stopped

La VIP fonctionne toujours… Je redémarre le SERVICE et je coupe cette fois la VIP :

root@test-ha1:~# crm resource stop VIP
root@test-ha1:~# crm_mon -1
============
Last updated: Wed Apr 17 12:57:54 2012
Stack: openais
Current DC: test-ha1 - partition with quorum
Version: 1.0.9
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ test-ha1 test-ha2 ]

Tout a été arrêté. En effet, le SERVICE a besoin de la VIP pour fonctionner.

Pour illustrer ce problème, je reprends ma configuration précédente et je rajoute une VIP :

crm(live)configure# property no-quorum-policy="ignore"
crm(live)configure# property stonith-enabled="false"
crm(live)configure# primitive VIP1 ocf:heartbeat:Dummy
crm(live)configure# primitive VIP2 ocf:heartbeat:Dummy
crm(live)configure# primitive SERVICE ocf:heartbeat:Dummy
crm(live)configure# group MON_SERVICE_HA VIP1 VIP2 SERVICE
crm(live)configure# commit

La sortie du crm_mon :

============
Last updated: Wed Apr 17 13:10:55 2012
Stack: openais
Current DC: test-ha1 - partition with quorum
Version: 1.0.9
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ test-ha1 test-ha2 ]

 Resource Group: MON_SERVICE_HA
     VIP1       (ocf::heartbeat:Dummy): Started test-ha1
     VIP2       (ocf::heartbeat:Dummy): Started test-ha1
     SERVICE    (ocf::heartbeat:Dummy): Started test-ha1

J’ai une intervention à faire sur la VIP2. Je souhaite l’arrêter et dans l’idéal ne pas impacter mon SERVICE qui utilise aussi la VIP1 :

root@test-ha1:~# crm resource stop VIP2

root@test-ha1:~# crm_mon -1
============
Last updated: Wed Apr 17 13:12:49 2012
Stack: openais
Current DC: test-ha1 - partition with quorum
Version: 1.0.9
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ test-ha1 test-ha2 ]

 Resource Group: MON_SERVICE_HA
     VIP1	(ocf::heartbeat:Dummy):	Started test-ha1
     VIP2	(ocf::heartbeat:Dummy):	Stopped
     SERVICE	(ocf::heartbeat:Dummy):	Stopped

Conclusion : ce n’est pas possible avec cette configuration. Elle est à privilégier dans le cas d’un cluster qui utilise des relations simples entre ses ressources. Dans le cas contraire, ici dans mon exemple, il est préférable d’utiliser des contraintes sur les ressources avec colocation.

Lier les ressources avec colocation

L’alternative à la commande group est la contrainte colocation : le principe est le même, on va lier des ressources entre elles. A la différence que nous allons pouvoir ici utiliser la notion de “score” pour décrire plus précisément l’emplacement des ressources entre elles. La syntaxe de la commande :

crm(live)configure# help colocation

This constraint expresses the placement relation between two
or more resources. If there are more than two resources, then the
constraint is called a resource set. Collocation resource sets have
an extra attribute to allow for sets of resources which don't depend
on each other in terms of state. The shell syntax for such sets is
to put resources in parentheses.

Usage:
...............
        colocation <id> <score>: <rsc>[:<role>] <rsc>[:<role>] ...
...............
Example:
...............
        colocation dummy_and_apache -inf: apache dummy
        colocation c1 inf: A ( B C )
...............

Si je reprends mon exemple de configuration avec mes deux VIPs, la configuration devient :

crm(live)configure# property no-quorum-policy="ignore"
crm(live)configure# property stonith-enabled="false"
crm(live)configure# primitive VIP1 ocf:heartbeat:Dummy
crm(live)configure# primitive VIP2 ocf:heartbeat:Dummy
crm(live)configure# primitive SERVICE ocf:heartbeat:Dummy
crm(live)configure# colocation SERVICE-avec-VIP inf: VIP1 VIP2 SERVICE
crm(live)configure# commit

Quelques explications sur la syntaxe de colocation et sur la gestion du score :

  • SERVICE-avec-VIP est l’id de ma contrainte.
  • Le score mandatory va décrire le fonctionnement de notre contrainte : mandatory est équivalent à INFINITY (traduit par inf si vous faites un crm configure show). Cela signifie que vos ressources fonctionneront toujours ensemble. A l’inverse, si j’utilise le mot clé -INFINITY, les ressources ne seront jamais ensemble. Le mot clé advisory est lui équivalent à un score de 0 et peut se traduire par les ressources devraient fonctionner ensemble. Ce cas-là sera moins utilisé en tout cas pas seul et fera intervenir d’autres contraintes ou éléments de la configuration.
  • Enfin la liste des ressources à lier… Encore une fois l’ordre est important. Dans cet exemple, je me retrouve avec le même fonctionnement que précédemment à savoir :
  • Si je coupe VIP1, tout s’arrête.
  • Si je coupe VIP2, SERVICE s’arrête et VIP1 fonctionne toujours.
  • Si je coupe SERVICE, VIP1 et VIP2 fonctionnent toujours.

Arrêt VIP1

root@test-ha1:~# crm resource stop VIP1

root@test-ha1:~# crm_mon -1
============
Last updated: Thu Apr 18 15:23:35 2012
Stack: openais
Current DC: test-ha1 - partition with quorum
Version: 1.0.9
2 Nodes configured, 2 expected votes
3 Resources configured.
============

Online: [ test-ha1 test-ha2 ]

Arrêt VIP2

root@test-ha1:~# crm resource stop VIP2

root@test-ha1:~# crm_mon -1
============
Last updated: Thu Apr 18 15:24:55 2012
Stack: openais
Current DC: test-ha1 - partition with quorum
Version: 1.0.9
2 Nodes configured, 2 expected votes
3 Resources configured.
============

Online: [ test-ha1 test-ha2 ]

 VIP1	(ocf::heartbeat:Dummy):	Started test-ha1

Arrêt SERVICE

root@test-ha1:~# crm resource stop SERVICE

root@test-ha1:~# crm_mon -1
============
Last updated: Thu Apr 18 15:25:22 2012
Stack: openais
Current DC: test-ha1 - partition with quorum
Version: 1.0.9
2 Nodes configured, 2 expected votes
3 Resources configured.
============

Online: [ test-ha1 test-ha2 ]

 VIP1	(ocf::heartbeat:Dummy):	Started test-ha1
 VIP2	(ocf::heartbeat:Dummy):	Started test-ha1

Pour y parvenir nous utilisons les parenthèses pour indiquer les ressources qui n’ont pas de dépendances entre elles. Exemple :

colocation SERVICE-avec-VIP inf: ( VIP1 VIP2 ) SERVICE

Je précise donc que :

  • Je peux couper indépendamment la VIP1 et/ou la VIP2 sans impacter le SERVICE
  • Si je coupe le SERVICE, les deux VIPs s’arrêtent.

Arrêt VIP1

root@test-ha1:~# crm resource stop  VIP1

root@test-ha1:~# crm_mon -1
============
Last updated: Thu Apr 18 15:36:14 2012
Stack: openais
Current DC: test-ha1 - partition with quorum
Version: 1.0.9
2 Nodes configured, 2 expected votes
3 Resources configured.
============

Online: [ test-ha1 test-ha2 ]

VIP2    (ocf::heartbeat:Dummy): Started test-ha1
SERVICE (ocf::heartbeat:Dummy): Started test-ha1

Arrêt VIP2

root@test-ha1:~# crm resource stop  VIP2

root@test-ha1:~# crm_mon -1
============
Last updated: Thu Apr 18 15:36:45 2012
Stack: openais
Current DC: test-ha1 - partition with quorum
Version: 1.0.9
2 Nodes configured, 2 expected votes
3 Resources configured.
============

Online: [ test-ha1 test-ha2 ]

VIP1    (ocf::heartbeat:Dummy): Started test-ha1
SERVICE (ocf::heartbeat:Dummy): Started test-ha1

Arrêt SERVICE

root@test-ha1:~# crm resource stop  SERVICE

root@test-ha1:~# crm_mon -1
============
Last updated: Thu Apr 18 15:37:36 2012
Stack: openais
Current DC: test-ha1 - partition with quorum
Version: 1.0.9
2 Nodes configured, 2 expected votes
3 Resources configured.
============

Online: [ test-ha1 test-ha2 ]

Donner un ordre de démarrage aux ressources

Pour s’assurer qu’un service démarre avant un autre, il faut utiliser la contrainte order. Comme nous l’avons vu précédemment, contrairement à la commande group, la contrainte colocation ne définit par d’ordre de démarrage (et d’arrêt) de vos ressources. Je reprends l’exemple précédent du SERVICE qui a besoin de ses deux VIPs pour fonctionner et je rajoute qu’il faut si possible (la nuance est importante) démarrer les VIPs avant le SERVICE :

order SERVICE-apres-VIPs advisory: ( VIP1 VIP2 ) SERVICE

La syntaxe est semblable à celle de colocation modulo l’interprétation des parenthèses : dans cet exemple, on indique que VIP1 et VIP2 peuvent démarrer en parallèle. En résumé :

  • Je rajoute une contrainte order avec “SERVICE-apres-VIPs” comme id.
  • Le SERVICE démarrera, de préférence, après les VIP1 et VIP2.
  • Les VIP1 et VIP2 peuvent démarrer en parallèle.

Avec un score infini, on indique que la VIP doit absolument démarrer avant le SERVICE : très bien c’est ce qu’on cherche. Mais cela implique que le SERVICE devra être arrêté avant de couper la VIP. On retombe sur un des problèmes précédents que l’on cherche à éviter.

Avec un score mandatory (0), Pacemaker essaye de démarrer la VIP avant le SERVICE et de stopper la VIP après le SERVICE à condition de ne pas impacter la ressource suivante dans la contrainte définie. Clairement, en cas d’arrêt d’une des VIPs, il ne coupera pas le SERVICE.

Pour finir, la configuration finale de ce cluster :

crm(live)configure# property no-quorum-policy="ignore"
crm(live)configure# property stonith-enabled="false"
crm(live)configure# primitive VIP1 ocf:heartbeat:Dummy
crm(live)configure# primitive VIP2 ocf:heartbeat:Dummy
crm(live)configure# primitive SERVICE ocf:heartbeat:Dummy
crm(live)configure# colocation SERVICE-avec-VIP inf: ( VIP1 VIP2 ) SERVICE
crm(live)configure# order SERVICE-apres-VIP 0: ( VIP1 VIP2 ) SERVICE
crm(live)configure# commit

Je vérifie l’ordre effectif de démarrage des mes ressources :

root@test-ha1:~# grep "Initiating action" /var/log/daemon.log
Apr 19 14:01:55 test-ha1 crmd: [789]: info: te_rsc_command: Initiating action 13: start VIP1_start_0 on test-ha1 (local)
Apr 19 14:01:55 test-ha1 crmd: [789]: info: te_rsc_command: Initiating action 14: start VIP2_start_0 on test-ha1 (local)
Apr 19 14:01:55 test-ha1 crmd: [789]: info: te_rsc_command: Initiating action 15: start SERVICE_start_0 on test-ha1 (local)

Si je coupe la VIP2 par exemple, je ne dois pas impacter mon SERVICE :

root@test-ha1:~# crm resource stop VIP2

root@test-ha1:~# crm_mon -1
============
Last updated: Mon Apr 19 14:08:57 2012
Stack: openais
Current DC: test-ha1 - partition with quorum
Version: 1.0.9
2 Nodes configured, 2 expected votes
3 Resources configured.
============

Online: [ test-ha1 test-ha2 ]

 VIP1	  (ocf::heartbeat:Dummy):	Started test-ha1
 SERVICE  (ocf::heartbeat:Dummy):	Started test-ha1

Quand je relance la VIP2, rien n’est impacté…

Si je coupe le SERVICE, dans ce cas là, tout s’arrête :

root@test-ha1:~# crm resource stop SERVICE

root@test-ha1:~# crm_mon -1
============
Last updated: Mon Apr 19 14:11:42 2012
Stack: openais
Current DC: test-ha1 - partition with quorum
Version: 1.0.9
2 Nodes configured, 2 expected votes
3 Resources configured.
============

Online: [ test-ha1 test-ha2 ]

Conclusion

J’espère avoir éclairci un peu ces notions… On peut essayer de résumer en se disant qu’il est préférable d’utiliser le couple colocation/order à la place de la commande group. Une utilisation généraliste dans le cas d’un SERVICE et de ses n VIPs serait :

colocation SERVICE-avec-VIP inf: ( VIP1 VIP2 VIPn) SERVICE
order SERVICE-apres-VIP 0: ( VIP1 VIP2 VIPn) SERVICE

Il faudra se poser la question de qui doit démarrer avant qui mais également l’impact que peut avoir l’arrêt puis la relance d’une ressource sur la ressource qui suit dans la contrainte de colocation/order. Dans l’exemple de cet article, il faudrait se demander comment se comportera le SERVICE qui a été démarré avec n VIPs si on en coupe une ? Le SERVICE devient HS (il a perdu une VIP sur laquelle il est en écoute) ? Et quand la VIP est redémarrée, le SERVICE se remet en écoute sur cette adresse ?

Bons tests !

]]> Cluster Pacemaker Apache actif/actif avec partage de charge simple https://binbash.fr/posts/cluster-pacemaker-apache-actifactif-avec-partage-de-charge-simple/ Fri, 18 Nov 2011 00:00:00 +0000 https://binbash.fr/posts/cluster-pacemaker-apache-actifactif-avec-partage-de-charge-simple/ <p>Dans un <a href="https://binbash.fr/posts/cluster-pacemaker-apache-actif-passif/">article précédent</a>, je vous ai présenté un cluster Apache en actif/passif. Nous allons voir ici comment le transformer rapidement en actif/actif avec un partage de charge simple. Je ne vais pas refaire tous les rappels de l&rsquo;article précédent : si vous arrivez directement sur cet article et que vous souhaitez en savoir plus sur la configuration qui sera présentée dans cet article (ou sur le <strong>stonith</strong>, le <strong>quorum</strong>&hellip;), jetez un oeil à l&rsquo;article <a href="https://binbash.fr/posts/cluster-pacemaker-apache-actif-passif/">Cluster Pacemaker Apache actif/passif</a>.</p> Dans un article précédent, je vous ai présenté un cluster Apache en actif/passif. Nous allons voir ici comment le transformer rapidement en actif/actif avec un partage de charge simple. Je ne vais pas refaire tous les rappels de l’article précédent : si vous arrivez directement sur cet article et que vous souhaitez en savoir plus sur la configuration qui sera présentée dans cet article (ou sur le stonith, le quorum…), jetez un oeil à l’article Cluster Pacemaker Apache actif/passif.

La configuration de base

Je reprends pour les besoins de cet article cette configuration :

property no-quorum-policy="ignore"
property stonith-enabled="false"
property default-resource-stickiness="10"

primitive VIP1 ocf:heartbeat:IPaddr2 \
    params ip="192.168.0.10" broadcast="192.168.0.255" \
    nic="eth1" cidr_netmask="24" iflabel="VIP1" \
    op monitor interval="30s" timeout="20s"

primitive APACHE ocf:heartbeat:apache \
    params configfile="/etc/apache2/apache2.conf" \
    op monitor interval="30s" timeout="20s" \
    op start interval="0" timeout="40s" \
    op stop interval="0" timeout="60s"

On obtient quelque chose comme :

============
Last updated: Thu Nov 17 20:28:22 2011
Stack: openais
Current DC: ha-test1 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Online: [ ha-test2 ha-test1 ]

VIP1    (ocf::heartbeat:IPaddr2):       Started ha-test2
APACHE  (ocf::heartbeat:apache):        Started ha-test1

Apache en mode actif/actif

On va maintenant passer Apache en mode actif/actif : Apache sera démarré, supervisé sur tous les noeuds qui composent le clusteur. Pour passer une ressource en mode actif/actif, c’est très simple : il faut utiliser la fonction “clone”. Il y a 3 types de clones :

  • Le clone “Anonymous” : des ressources identiques sur chaque noeud, c’est le clone classique que je vais utiliser ici. La ressource fonctionnera de façon identique sur chaque noeud. Si un noeud est indisponible, il n’y a pas de bascule de cette ressource puisqu’elle est déjà fonctionnelle et identique sur l’autre noeud. Dans ce fonctionnement, il n’y aura donc qu’un clone “actif” par noeud.
  • Le clone avec l’option “globally-unique=true” : contrairement au cas précédent, les ressources ne sont pas identiques d’un noeud à l’autre. Elles peuvent par exemple, avoir des données différentes. Dans ce cas, on peut avoir plus d’un clone par noeud : s’il y a une bascule, la ressource clonée sera alors reprise par un autre noeud.
  • Le “multi-state” : c’est une ressource qui peut être dans 2 états différents : “master” ou “slave”. J’y reviendrais dans un prochain article.

Pour transformer notre Apache actif/passif en actif/actif, on clone la ressource APACHE :

clone cAPACHE APACHE

La syntaxe est : clone identifiant ressource. On obtient :

============
Last updated: Thu Nov 17 20:36:31 2011
Stack: openais
Current DC: ha-test1 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Online: [ ha-test2 ha-test1 ]

VIP1    (ocf::heartbeat:IPaddr2):       Started ha-test2
 Clone Set: cAPACHE
     Started: [ ha-test1 ha-test2 ]

On voit que la ressource Apache est démarrée sur les deux noeuds : ha-test1 et ha-test2. Clone peut avoir les options suivantes (options par défaut entre [ ] pour la version 1.0.9):

options valeur
clone-max le nombre de copies de votre ressource. Par défaut, il y a autant de copies que de noeuds dans votre cluster. Dans mon exemple, clone-max est à 2.
clone-node-max le nombre de copies qui peuvent être démarrées sur un seul noeud. Dans le cas d’un clone “Anonymous”, cette valeur vaut automatiquement 1. Si vous utilisez un clone avec “globally-unique=true”, vous pouvez avoir une valeur supérieure à 1.
notify prévenir les autres noeuds des actions en cours sur le clone de la ressource. Cela permet d’interagir avec des scripts OCF en fonction de l’état du clone. [true]/false.
globally-unique est-ce que les clones ont un fonctionnement différent ? true/[false]
ordered est-ce qu’il faut démarrer les clones en série (true) ou en parallèle [false].
interleave permet de changer le comportement de l’ordre de démarrage des ressources. Si vous demandez à une ressource A de démarrer après votre clone B, la ressource A démarrera sur votre noeud quand tous les clones seront lancés avec [false] ou sans attendre les autres clones avec true.

La VIP

Il est également possible de cloner la VIP grâce à iptables et à la cible CLUSTERIP. Cela permet de créer un ensemble de serveurs qui vont répondre à la même adresse IP/MAC : chaque serveur recevra alors le paquet mais seul l’un d’entre eux y répondra. C’est une solution très simple et rapide pour faire un partage de charge basique. Ce partage de charge à trois algorithmes différents :

  • sourceip : les clients ayant la même IP source seront toujours envoyés sur le même serveur. C’est utile quand il est important de garder une session.
  • sourceip-sourceport : le partage sur les noeuds se fait en fonction du couple IP source, port source. Le partage est donc un peu plus équitable. Les sessions ne sont plus conservées.
  • sourceip-sourceport-destport : rajoute à l’algorithme précédent le port destination. Cela permet un partage de charge différent en fonction du service utilisé.

Pour cloner la VIP : (l’algorithme par défaut est sourceip-sourceport si vous ne spécifiez rien) :

clone cVIP VIP1

Pour changer l’algorithme :

clone cVIP VIP1 meta clusterip_hash="sourceip"

On obtient :

============
Last updated: Thu Nov 17 20:45:03 2011
Stack: openais
Current DC: ha-test1 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Online: [ ha-test2 ha-test1 ]

 Clone Set: cAPACHE
     Started: [ ha-test1 ha-test2 ]
 Clone Set: cVIP
     Started: [ ha-test2 ha-test1 ]

Chaque Apache sert une page basique sur laquelle il affiche son hostname. On vérifie que le partage de charge fonctionne correctement : curl -s

]]> Cluster Pacemaker Apache actif/passif https://binbash.fr/posts/cluster-pacemaker-apache-actif-passif/ Thu, 27 Oct 2011 00:00:00 +0000 https://binbash.fr/posts/cluster-pacemaker-apache-actif-passif/ <p>Suite de l&rsquo;article <a href="https://binbash.fr/posts/des-clusters-avec-pacemaker/">des clusters avec pacemaker</a> : nous allons voir ici comment mettre en place un cluster de deux noeuds, en actif / passif avec deux ressources : une VIP et Apache. Le besoin est le suivant : apporter de la haute disponibilité au serveur http Apache. La VIP (adresse IP virtuelle) et Apache devront fonctionner sur le même noeud, basculer sur l&rsquo;autre noeud en cas de panne du noeud actif ou si une ressource est en erreur au-delà de la valeur définie.</p> Suite de l’article des clusters avec pacemaker : nous allons voir ici comment mettre en place un cluster de deux noeuds, en actif / passif avec deux ressources : une VIP et Apache. Le besoin est le suivant : apporter de la haute disponibilité au serveur http Apache. La VIP (adresse IP virtuelle) et Apache devront fonctionner sur le même noeud, basculer sur l’autre noeud en cas de panne du noeud actif ou si une ressource est en erreur au-delà de la valeur définie.

Pacemaker actif/passif

Rappels et définitions

  • Un cluster actif/passif fonctionne de cette façon : les ressources sont démarrées et supervisées par Pacemaker sur un seul noeud : le noeud actif (appelé également master ou maître). Si ce noeud rencontre une panne, les ressources sont basculées sur l’autre noeud, le noeud passif (ou le slave, l’esclave), qui devient alors le noeud actif. Quand l’autre noeud est de nouveau fonctionnel, deux possibilités :
  • Rien ne change : le cluster reste dans cette configuration. Le noeud réparé devient le noeud passif du cluster. Cela évite une nouvelle bascule et une nouvelle interruption du service. On parle alors de “manual failback” ou “d’auto_failback à off”.
  • On retourne dans l’état précédent : il y a une nouvelle bascule. Le noeud réparé redevient le noeud actif du cluster. Il y a une nouvelle interruption du service. Cela correspond à activer “l’auto_failback”.
  • Votre service, Apache ici, est démarré et supervisé par Pacemaker. Il est donc inutile (voir problématique dans certains cas) de démarrer le service au boot de votre serveur. C’est uniquement à Pacemaker de gérer maintenant ce service. Pour désactiver le démarrage du service sur une Debian :
  • Sur une debian Squeeze si vous utilisez les dépendances entre les scripts d’init :
insserv  -r -v apache2
  • Sur une version inférieure à la 6.0 (Squeeze) :
update-rc.d -f apache2 remove
  • Le service, Apache ici, doit être installé et configuré de façon identique sur les deux noeuds. Il ne faudra jamais oublier de reporter toute modification de la configuration sur l’ensemble des noeuds sous peine d’avoir, le jour d’une bascule, un service potentiellement dégradé.
  • Pour les problématiques liées au stonith et au quorum que j’ai détaillé ici, nous allons ignorer le quorum et désactiver le stonith. C’est la base de toutes les configurations que je vais vous présenter.
  • Au sujet des exemples de configuration qui vont suivre : tout doit se faire sur une seule ligne. Vous pouvez couper les lignes longues via “" suivi d’un retour à la ligne (comme dans les exemples) ou tout saisir sur une ligne. Par exemple plus bas, la syntaxe primitive commence avec “primitive” et se termine après la définition du “timeout”, le tout, sur une ligne.

La configuration de base

Vous avez donc configuré Corosync, Apache sur vos deux noeuds. Corosync est démarré et la commande crm_mon -1 renvoie quelque chose de semblable à :

root@ha-test1:~# crm_mon -1
============
Last updated: Mon Oct 24 23:50:20 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 ]

On a donc 2 noeuds en ligne, pas de ressources configurées. On va commencer par configurer stonith et le quorum de ce cluster comme expliqué dans le paragraphe précédent. On injecte la configuration suivante via crm configure :

crm(live)configure# property no-quorum-policy="ignore"
crm(live)configure# property stonith-enabled="false"
crm(live)configure# commit

On vérifie la configuration via la commande show du mode configure :

crm(live)configure# show
node ha-test1
node ha-test2
property $id="cib-bootstrap-options" \
	dc-version="1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b" \
	cluster-infrastructure="openais" \
	expected-quorum-votes="2" \
	no-quorum-policy="ignore" \
	stonith-enabled="false"

crm configure en image : Fonctionnement de crm configure

Le cluster est prêt pour recevoir la définition des ressources…

La VIP

La VIP est l’adresse de service de votre cluster. C’est l’adresse virtuelle à utiliser pour accéder à votre service en haute disponibilité. Cette adresse IP sera ajoutée comme adresse secondaire sur l’interface réseau de votre choix. Pour configurer ce service, toujours dans crm configure, injectez la configuration suivante puis validez via la commande commit :

primitive VIP1 ocf:heartbeat:IPaddr2 \
	  params ip="192.168.0.10" broadcast="192.168.0.255" nic="eth1" cidr_netmask="24" iflabel="VIP1" \
	  op monitor interval="30s" timeout="20s"

Le détail de cette syntaxe :

  • On commence avec primitive qui sert à déclarer une ressource. VIP1 est le nom de votre ressource. ocf:heartbeat:IPaddr2 est le script utilisé pour gérer cette ressource. Dans cette syntaxe on retrouve ocf pour le type de script : c’est un script qui sait gérer le start/stop d’une ressource comme avec un script lsb, mais il permet en plus et c’est très utile, la supervision de la ressource via monitor (ou encore la promotion d’une ressource dans le cadre d’un cluster actif/actif…). Suit ensuite heartbeat le “fournisseur” du script puis le nom du script IPaddr2. Pour information, il existe également un script IPaddr. Je vous encourage à utiliser IPaddr2 qui permet d’utiliser des interfaces cachées ou encore, par exemple, de cloner une VIP (article à venir).
  • Toujours sur la même ligne, on a une liste de paramètres avec params qui définit l’adresse IP de cette VIP. Déclarez votre VIP avec son adresse, son broadcast, son masque et l’interface réseau sur laquelle sera rajoutée cette VIP. Le paramètre iflabel permet de donner un label à votre VIP. Sans ce label, la VIP n’est pas visible avec la commande “ifconfig” mais seulement avec “ip addr show”.
  • Pour finir, op monitor défini un moniteur pour cette ressource : toutes les 30 secondes, Pacemaker va appeler le script ocf avec comme paramètre monitor. Avant le timeout de 20 secondes, on devra avoir un code retour à 0 pour que Pacemaker considère la ressource comme fonctionnelle. Dans le cas contraire, il arrêtera/relancera la ressource ou effectuera une bascule (idem si la fonction monitor n’a pas répondu avant le timeout).

Voici la sortie de crm_mon -1 :

============
Last updated: Mon Oct 24 23:51:33 2011
Stack: openais
Current DC: ha-test1 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ ha-test1 ha-test2 ]

 VIP1	(ocf::heartbeat:IPaddr2):	Started ha-test1

Une ressource configurée dans mon cluster qui fonctionne sur le noeud ha-test1. Je contrôle via ifconfig :

eth1:VIP1 Link encap:Ethernet  HWaddr 00:01:02:03:04:05
          inet addr:192.168.0.10  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

Apache

Nous avons vu précédemment comment rajouter une adresse IP virtuelle pour accéder au service en haute disponibilité. Reste maintenant le service en question : Apache. De la même manière que nous avons défini la VIP, nous allons rajouter Apache :

primitive APACHE ocf:heartbeat:apache \
	params configfile="/etc/apache2/apache2.conf" \
	op monitor interval="30s" timeout="20s" \
	op start interval="0" timeout="40s" \
	op stop interval="0" timeout="60s"

Je ne reviens pas sur le détail complet de cette configuration. Comme pour la VIP, on définit la primitive APACHE avec pour paramètre le fichier de configuration d’apache de la Debian. Pour information, pour connaître la liste complète des paramètres d’une primitive, utilisez la commande crm ra list ocf:heartbeat:apache. Vous obtenez la liste des timeout par défaut, des paramètres et de leurs valeurs par défaut, les paramètres obligatoires et facultatifs… Par rapport à la configuration de la VIP, nous avons :

  • op start qui va définir le timeout par défaut pour la fonction start du script ocf.
  • op stop pour la fonction stop du script ocf.

Vérifions l’état du cluster suite à l’ajout de cette nouvelle ressource :

============
Last updated: Mon Oct 24 23:52:42 2011
Stack: openais
Current DC: ha-test1 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
2 Resources configured.
============

Online: [ ha-test1 ha-test2 ]

VIP1    (ocf::heartbeat:IPaddr2):       Started ha-test1
APACHE  (ocf::heartbeat:apache):        Started ha-test2

Ajustements

Quelques ajustements s’imposent : il faut que l’ensemble des ressources fonctionnent ensemble, sur le même noeud et en cas d’échec sur l’une des ressources (au 3ème échec), il faudra basculer sur l’autre noeud. Il y a donc deux cas de bascule :

  • Le noeud actif à une panne : les ressources sont basculées sur le noeud passif.
  • Une ressource échoue au delà de la valeur configurée, les ressources basculent. Si un problème est rencontré au moment du démarrage d’une ressource, la bascule sur l’autre noeud est immédiate.

La configuration se passe toujours via crm configure :

crm(live)configure# group APACHE-HA VIP1 APACHE meta migration-threshold="3"
crm(live)configure# commit

On utilise la syntaxe group pour grouper nos ressources VIP1 et APACHE sous le nom de groupe APACHE-HA. Au troisième échec d’une des ressource de ce groupe, il y aura une bascule du cluster. Dans le cas contraire, la ressource en échec est relancée.

Attention à l’ordre de vos ressources (primitives) dans le groupe ! Quand vous groupez vos ressources, vous indiquez que vous souhaitez les faire fonctionner ensemble, ce qui se traduit dans notre exemple par :

  • APACHE doit fonctionner sur le même noeud que la VIP1.
  • APACHE a alors une dépendance à la ressource qui le précède : la VIP VIP1.
  • Si la VIP1 bascule, APACHE bascule. C’est le fonctionnement recherché. Mais si la VIP1 ne fonctionne plus, elle sera arrêtée puis relancée impliquant l’arrêt relance d’APACHE qui dépend de cette VIP ! Idem si vous coupez volontairement cette ressource, APACHE ser>a coupé.
  • On a le schéma de démarrage/relance des ressources suivant : START VIP -> START APACHE et si problème sur la VIP : STOP APACHE -> STOP VIP -> START VIP -> START APACHE. Si la ressource APACHE est relancée, pas d’impact : APACHE n’a pas de dépendance dans cette dé>claration du groupe.
  • C’est peu contraignant dans notre exemple à une seule VIP puisque APACHE écoute sur celle-ci : si la VIP ne fonctionne pas, inutile qu’Apache fonctionne. Mais dès qu’il y aura plusieurs VIPs, ce fonctionnement peut être problématique. En effet, dans le cas où nou>s aurions le groupe suivant : group APACHE-HA VIP1 VIP2 APACHE, si on souhaite changer/couper/faire une intervention sur la VIP1, l’arrêt de celle-ci engendrera l’arrêt des ressources au-dessus : VIP2 et APACHE. Pour éviter ce comportement, il existe une autre solu>tion à base de colocation/order (que nous verrons dans un prochain article). C’est un détail du group à garder en tête !

On vérifie que le groupe est bien en place et que les ressources sont maintenant sur le même noeud :

============
Last updated: Mon Oct 24 23:53:04 2011
Stack: openais
Current DC: ha-test1 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ ha-test1 ha-test2 ]

 Resource Group: APACHE-HA
     VIP1       (ocf::heartbeat:IPaddr2):       Started ha-test2
     APACHE     (ocf::heartbeat:apache):        Started ha-test2

Pour désactiver l’auto_failback, je donne un poids par défaut à mon noeud actif avec default-resource-stickiness. Le positionnement des ressources sur un noeud se fait en fonction du poids calculé pour chacun d’entre eux. Vous pouvez par exemple privilégier un noeud en lui donnant un poids plus important qu’un autre. Ainsi, les ressources auront pour “préférence” ce noeud. Dans cet exemple, il n’y a pas de préférence sur un noeud, juste un poids de +10 attribué à l’actif. Via crm configure :

property default-resource-stickiness="10"
commit

C’est prêt. Il reste maintenant à valider par des tests, des tests, des tests…

Les tests

Arrêt d’un noeud

Le premier test que je réalise est l’arrêt du noeud actif. Rien de tel qu’un arrêt électrique pour vérifier le comportement du cluster. Avant la coupure, tout va bien comme le confirme la commande crm_mon -1 :

============
Last updated: Tue Oct 25 22:29:29 2011
Stack: openais
Current DC: ha-test1 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ ha-test1 ha-test2 ]

 Resource Group: APACHE-HA
     VIP1       (ocf::heartbeat:IPaddr2):       Started ha-test2
     APACHE     (ocf::heartbeat:apache):        Started ha-test2

Mes deux noeuds sont “online” et mes ressources fonctionnent sur ha-test2. Je coupe ha-test2 électriquement :

============
Last updated: Wed Oct 26 22:58:59 2011
Stack: openais
Current DC: ha-test1 - partition WITHOUT quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ ha-test1 ]
OFFLINE: [ ha-test2 ]

 Resource Group: APACHE-HA
     VIP1       (ocf::heartbeat:IPaddr2):       Started ha-test1
     APACHE     (ocf::heartbeat:apache):        Started ha-test1

On remarquera au passage le partition WITHOUT quorum. Si le quorum n’était pas ignoré, le cluster n’aurait pas basculé ! Quand le serveur est rallumé, il réintègre le cluster automatiquement. Comme l’auto_failback est désactivé, il n’y a pas de bascule, on reste dans cet état :

============
Last updated: Wed Oct 26 23:00:20 2011
Stack: openais
Current DC: ha-test1 - partition with quorum
Version: 1.0.9-74392a28b7f31d7ddc86689598bd23114f58978b
2 Nodes configured, 2 expected votes
1 Resources configured.
============

Online: [ ha-test1 ha-test2 ]

 Resource Group: APACHE-HA
     VIP1       (ocf::heartbeat:IPaddr2):       Started ha-test1
     APACHE     (ocf::heartbeat:apache):        Started ha-test1

Arrêt d’une ressource

Dans l’exemple qui suit, j’arrête apache. Le fonctionnement demandé est de relancer la ressource 2 fois et de basculer sur l’autre noeud au 3ème échec. Pour suivre le comportement de Pacemaker, j’ai fait la capture suivante. Pour ce test, j’ai volontairement réduit l’intervalle du moniteur d’Apache à 5 secondes. J’envoie ensuite 3 killall apache2 sur le noeud actif pour vérifier que le cluster fonctionne correctement. On pourra observer par exemple la ligne APACHE: migration-threshold=3 fail-count=3 avec la valeur de fail-count qui sera incrémenté à chaque relance de la ressource par Pacemaker. killall_apache2

Résultat d’un crm resource cleanup APACHE-HA :

crm_resource_cleanup

Mettre un noeud en standby

Il peut être utile, pour de la maintenance par exemple, de mettre un noeud en standby. Sur l’exemple qui suit, je fais un crm node standby ha-test2, le noeud actif de mon cluster. Dans ce cas, le cluster bascule sur l’autre noeud.

Résultat d’un crm node standby ha-test2 :

crm_node_standby

Conclusion / Liens

Nous avons vu le cas d’un cluster simple actif/passif. Il est possible de monter des clusters plus compliqués à plus de 2 noeuds, en mode actif/actif, avec des conditions sur les ressources (ma ressource doit fonctionner, par exemple, que les jours ouvrés). Idem pour les fonctions de crm. Il existe d’autres possibilités pour migrer les ressources, gérer le fail-count et le cluster en lui-même. A suivre…

Pour la documentation sur Pacemaker :

]]> Des clusters avec Pacemaker https://binbash.fr/posts/des-clusters-avec-pacemaker/ Mon, 19 Sep 2011 00:00:00 +0000 https://binbash.fr/posts/des-clusters-avec-pacemaker/ <p>Pacemaker est un outil de gestion de ressources (une VIP, un service) pour vos clusters. Il va gérer la haute disponibilité en s&rsquo;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&rsquo;importe lequel de vos services. La seule &ldquo;contrainte&rdquo; est d&rsquo;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&hellip;</p> 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…

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 !

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

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

]]>