TARDITI Richard Mise en place d une Haute Disponibilité Dans le cadre du projet GSB j ai mis en place un cluster de deux machines virtuelles Apache sous Linux, avec une haute disponibilité produite grâce à Heartbeat et Pacemaker.
1) Introduction La «haute disponibilité» regroupe de nombreuses techniques et processus permettant de garantir un certain pourcentage de disponibilité d'un service. Par exemple, un taux de 99 % de disponibilité assure une disponibilité d environ 361 jours sur 364 alors qu un taux de 99.5 % assure une disponibilité de plus de 363 jours sur 365. La réalité économique fait que les organisations tendent de plus en plus vers des taux encore plus grande comme 99.9 % ou 99.99 % notamment sur certains services critiques. En effet, les conséquences d une interruption de services sont innombrables et peuvent coûter très cher à tous point de vue. 2) Fonctionnement L algorithme utilisé pour la Haute Disponibilité est basé sur la tachycardie, il s appelle «Heartbeat». Un cluster est mis en place de minimum 2 machines, il y aura une machine actif est une autre en écoute, la machine actif émet des battements de cœur qu écoute l autre machine, lorsque le cœur de la machine actif ne bat plus il est considéré comme mort, c est donc la machine en écoute qui bascule et émet des battements de cœur et l autre machine se met en écoute. Cela permet que n importe quelle machine tombe en panne sans pénaliser l ensemble. 3) Installation Dans ma situation j ai installé «Heartbeat» sur une Debian Wheezy à l aide de la commande : Apt-get install heartbeat En complément de Heartbeat j ai utilisé «Pacemaker» qui s installe en même temps que vous installez Heartbeat, c est un gestionnaire de ressources. Il est chargé de créer, démarrer, arrêter et superviser les ressources du Cluster c est-à-dire les services gérés en Cluster et donc inclus dans la continuité de services. 4) Configuration Heartbeat est installé en démon et il se charge, grâce à Pacemaker, d activer l adresse IP virtuelle sur le serveur qui joue le rôle de maître ainsi que le lancement des services mis en haute disponibilité. Ces derniers, lancés par Pacemaker, doivent donc être supprimés du démarrage automatique de Linux. Exemple pour apache : Update-rc.d -f apache2 remove Les fichiers de configurations se trouvent dans le répertoire «/etc/ha.d/» et dans «/var/lib/heartbeat/crm/». C est dans le fichier «ha.cf» que l on indiquera qu il travaillera avec Pacemaker : 1
C est dans le fichier «authkeys» qu est déterminé le niveau de sécurité des échanges entre les différents nœuds du Cluster. Lorsque ces informations passent par le réseau, il vaut mieux crypter l échange avec md5 sha. Dans ce cas, il faut fournir une passphrase : Il ne faut pas oublier de restreindre les droits de lectures/écritures qu à l utilisateur root : Chmod 600 /etc/ha.d/authkeys Une fois tout ceci fais j ai tout simplement cloné mon premier serveur et configuré par la suite pour obtenir mon serveur en écoute. Après avoir lancé heartbeat sur les deux machines on peut vérifier s il est bien lancé : 2
Service heartbeat status Nous obtenons ceci sur les deux machines : Grâce à quelque commande utile j ai pu vérifier l état du Cluster : Crm status Crm_mon Cette commande permet de suivre l évolution de la configuration du Cluster en temps réelle. Crm configure show 3
Crm_verify L -V Cette commande permet de vérifier la validité du fichier de configuration XML, la première exécution de cette commande génère des erreurs. Par mesure de simplicité j ai désactivé STONITH avec la commande suivante : Crm configure property stonith-enabled=false Persiste encore un petit problème à régler concernant le QUORUM qui 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 faut donc demander à Pacemaker d ignorer le QUORUM dans cette situation car le fonctionnement par défaut, quand le QUORUM n est pas atteint, est de couper toutes les ressources. Crm configure property no-quorum-policy= ignore 4
5) Création d une source La création d une ressource s effectue avec une entrée nommée «primitive» dans la CIB. On trouvera au minimum dans la commande : Crm configure primitive nom de la resource espace de nom:nom du script Il existe deux type de script : -OCF, qui est un script développé pour Pacemaker. Ils sont pour la plupart dans le répertoire «/usr/lib/ocf/resource.d/heartbeat ou /usr/lib/ocf/resource.d/pacemaker» -LSB, c est un script de démarrage sur Linux présent dans «/etc/init.d». Le type lsb:service utilise au minimum les capacités start, stop, status des scripts de démarrage système de /etc/init.d. Pour en vérifier la compatibilité minimum, les scripts doivent répondre à une commande start, stop et status. La configuration passe donc par la commande «crm» que l on peut utiliser directement en ligne de commande ou en interactif. La commande se propage sur tous les nœuds et modifie le fichier xml sur chaque nœud. J ai créé un service que j ai appelé «IPFailover» qui fais le basculement de l adresse IP virtuelle du serveur maître vers le serveur en écoute si le premier venait à tomber. Pour attribuer une adresse IP virtuelle j ai entré la commande suivante : Crm configure primitive IPFailover ocf:heartbeat:ipaddr2 params ip= 192.168.1.5 cidr_netmask= 255.255.0.0 nic= eth2 iflabel= VIP Primitive : argument pour ajouter une primitive regroupant plusieurs valeurs indiquant au Cluster quels scripts utiliser pour la ressource, où le trouver et à quel standard il correspond. IPFaillover : le nom de la ressource (il est évidemment libre...) Ocf : classe de la ressource (ça pourrait donc aussi être lsb) Hearbeat : fournisseur de la ressource IPaddr2 : ressource gérant les adresses IPv4 virtuelles ==> le script appelé Params : déclaration des paramètres nécessaires à la ressource ip= «192.168.1.5» : nom et valeurs du paramètre «ip» cidr_netmask= «255.255.0.0» : masque de sous-réseau nic= «eth2» : carte réseau sur laquelle est appliquée l'adresse IP virtuelle iflabel= «VIP» permet de donner un label à la carte réseau virtuelle. 5
Grâce à la commande «crm_mon» on peut constater la configuration de la ressource : On constate que le service est lancé aléatoirement car il a été lancé sur le serveur en écoute, vérifions l adressage ip avec la commande «ip addr show» : J ai pu modifier ma ressource grâce à la commande «crm configure edit IPFailover» et j ai rajouté les paramètres suivant «op monitor interval= 30s timeout= 20s» : op définit des options et monitor est l action de monitoring du Pacemaker. J ai par la suite défini une contrainte «locative» qui va définir une préférence d une ressource sur un nœud, on migre la ressource sur le nœud que l on veut et Pacemaker comprend qu on a une préférence pour ce nœud : Crm resource move IPFailover server Le service est donc bien sur le bon nœud, nous allons à présent simuler une panne sur le serveur maître en le mettant en «standby» : 6
Crm node standby L adresse IP à bien été récupéré par le serveur «hdserver», relançons le serveur maître : Crm node online Le serveur maître étant à nouveau opérationnel il reprend son statut. J ai ensuite créé une nouvelle ressource que j ai nommé «serviceweb», nous allons la configurer en interactif : Crm configure Primitive serviceweb ocf:heartbeat:apache params configfile= /etc/apache2/apache2.conf op monitor interval= 60s op start timeout= 40s op stop timeout= 40s Commit quit Avant de valider la ressource on peut la consulter grâce à la commande : Crm configure show 7
A la validation il est possible de rencontrer cette avertissement «WARNING : serviceweb specified timeout 40s for stop is smaller than the advised 60s», on ignorera cette avertissement car il ne nui pas à la ressource. Sur la console avec «crm_mon» nous pouvons constater que la ressource est bien apparut : Mais comme on peut le voir la ressource n est pas démarré sur le bon nœud, par défaut Pacemaker répartit les services sur les nœuds. Pour que les deux service soient sur le même nœud on va les mettre dans un groupe : Crm configure Group servserver IPFailover serviceweb meta migration-threshold= 5 Commit quit 8
Nous avons donc créé un groupe nommé servserver qui regroupe les deux resource qui seront toujours démarrées dans l ordre des entrées du groupe. Les deux services sont à présent sur le même nœud nous allons simuler une panne sur le serveur maître: Le serveur esclave à bien pris le relai des deux ressources. 9