mercredi 26 juin 2019
 

 

HEARTBEAT V2 : Un monitoring pour le coeur des clusters

par La rédaction - Test publié dans le magazine L'Informaticien le 01/07/2009 Article Rating
Le projet open source Heartbeat a été lancé en 1998 comme un cluster de haute disponibilité. Depuis récemment, une v2 est disponible. Elle s'adapte à l'utilisation de Pacemaker, un gestionnaire de ressources de cluster.

La pile logicielle cluster a changé. Elle permet désormais d'utiliser Heartbeat ou OpenAIS pour gérer les communications internoeuds. OpenAIS implémente une API standard de l'industrie : l’Application Interface Specifi cation (AIS). Cette API est publiée par le Service Availability Forum. Le gestionnaire de ressources du cluster a été maintenu mais a été considérablement amélioré (en reposant sur OpenAIS) et il est désormais connu sous le nom de Pacemaker.

Cluster_heartbeat

Mise en oeuvre
En premier lieu nous avons déjà créé un cluster sous Heartbeat v1, mais le principal problème de cette version est la limitation à 2 noeuds. Depuis la v2, le cluster supporte jusqu'à 16 noeuds avec l'utilisation d'OpenAIS.
La transition n'est pas si facile, la principale différence concerne l'utilisation du fi chier de ressources. Sous la v1, c'était relativement simple. Il fallait éditer le fichier haresources (/etc/ha.d/haresources). Avec la v2, il faut éditer le fichier cib.xml (/var/lib/heartbeat/crm/cib.xml) qui comporte beaucoup plus de paramètres. Commençons donc par le début... Sur notre plateforme sous Debian, nous téléchargeons les derniers packages disponibles (2.99.x) :
heartbeat_2.99.2-1_i386.deb
libopenais2_0.80.5-1_i386.deb
libpils0_2.99.2-1_i386.deb
libstonith0_2.99.2-1_i386.deb
pacemaker_1.0.2-1_i386.deb
pacemaker-mgmt_1.99.1-1_i386.deb
pacemaker-mgmt-client_1.99.1-1_i386.deb
Ensuite, l'installation se réalise avec la
commande : dpkg -i nom_de_fi chier.deb
Certaines dépendances ne sont pas satisfaites. Il est donc nécessaire d'exécuter la commande :
apt-get -f install
La configuration est à peu prêt similaire à l'installation d'une v1. Trois fi chiers sont importants et doivent être identiques sur les 2 noeuds :
/etc/ha.d/authkeys
/etc/ha.d/ha.cf
/var/lib/heartbeat/crm/cib.xml


Le répertoire /etc/ha.d/ ne contenant pas les fichiers dont nous avons besoin, il est nécessaire soit de les créer et les éditer manuellement, soit de partir d'un fichier pré-rempli (contenant des instructions) que l'on obtient à partir des commandes suivantes :
cp /usr/share/doc/heartbeat/authkeys /etc/ha.
d/authkeys
zcat
/usr/share/doc/heartbeat/ha.cf.gz > /etc/ha.d/ha.
cf


Contenu du fi chier authkeys :
auth 1
1 md5 "motdepasse"

Il ne faut pas oublier de faire un chmod 600 sur le fichier afin de le protéger, sans quoi il ne sera pas possible de démarrer Heartbeat (message d'erreur). Jusque-là, l'installation se révèle simple. On modifie le contenu du fichier ha.cf :
bcast                                            eth1
debugfile      /var/log/ha-debug
logfile                                           /var/log/ha-log
logfacility      local0
keepalive      2
deadtime      30
warntime      6
initdead         60
udpport                                      694
noeud                                         dMaster
noeud                                         dSlave
auto_failback                          off


Puisqu'il est maintenant possible d'avoir
+ de 2 noeuds dans le cluster
autojoin       any
# On déclare que l'on souhaite fonctionner en v2
crm                                               yes
# Paramètres nécessaires pour interfacer le manager Pacemaker GUI
apiauth                                       mgmtd uid=root
respawn                                     root /usr/lib/heartbeat

Passons maintenant au plus compliqué : la configuration du fichier de ressources.
Précédemment, sous la v1, il suffi sait d'entrer quelques lignes de configuration dans le fichier haresources. Désormais avec la v2, la configuration réside dans le fichier XML de la CIB qui nécessite une structuration rigoureuse et la connaissance des nombreux paramètres. Une recherche sur Internet nous a orientés vers de nombreux guides et supports, qui montrent que de nombreux utilisateurs préfèrent rester sur la version 1, plus simple et suffisamment bien à leurs besoins. Il ne faut toutefois pas se décourager, la confi guration de la version 2 est plus complète et pas plus compliquée que de nombreux projets open source. L'important est de ne pas omettre deux détails : le paramètre crm n'est pas configuré par défaut dans le fichier ha.conf (crm off) et le fichier haresources ne doit plus être utilisé. Outre l'édition directe du fichier cib.xml, il existe plusieurs méthodes de configuration.

1. MÉTHODE DE LA CONVERSION HARESOURCES>CIB.XML
Dans un premier temps, on crée et édite le fichier haresources. Puis, à l'aide d'un script Python présent depuis l'installation de Heartbeat 2, on le convertit en cib.xml.
Voici la procédure :
cd /etc/ha.d
/usr/lib/heartbeat/haresources2cib.py --stdout -c
ha.cf haresources > /var/lib/heartbeat/cib.xml

Ensuite, il suffi t de lancer la commande
crm_mon pour constater l'état du cluster, c'està- dire les noeuds connectés, leur état et les ressources partagées.

2. MÉTHODE DE CONFIGURATION PAR INTERFACE GRAPHIQUE
Au début de cette procédure, nous avions installé pacemaker-mgmt_1.99.1-1_i386.deb ainsi que son client. Il s'agit du GUI.
Pour lancer Pacemaker GUI, il suffi t d'exécuter la commande : crm_gui
Apparaît alors l'interface graphique, on clique sur "Connection". Une boîte apparaît vous demandant l'IP du serveur, votre identifi ant et votre mot de passe (important : l'utilisateur doit être membre du groupe haclient). Vous voici connecté à votre cluster ! Vous avez maintenant la possibilité de monitorer vos noeuds et ressources ainsi que de les configurer.

Architecture du système de haute disponibilité

1/ INFRASTRUCTURE ET COMMUNICATION
La première couche est celle des communications et infrastructures, également connue sous le nom de couche OpenAIS. Celle-ci contient les composants qui envoient les signaux de vie ainsi que d'autres messages. Le programme de l'extension HA repose sur cette couche.

2. RESOURCE ALLOCATION LAYER (couche allocation ressource)
Cette couche est celle comprenant le plus de composants.
• Gestionnaire de ressources du cluster (CRM, Cluster Resource Manager) Toute action réalisée au niveau de la couche d'allocation de ressource passe par le CRM. Si d'autres composants de cette couche (ou du niveau supérieur) doivent communiquer, ils le font à traver le CRM. Sur chaque noeud, le CRM maintient la base d'information du cluster (CIB, Cluster Information Base) contenant les informations de confi guration du cluster, des noeuds, des ressources ainsi que leurs statuts. Un CRM dans le cluster est élu Designated Coordinator (DC), ce qui signifi e qu'il détient le master CIB. Toutes les autres CIB du cluster sont des replicas du master. Les opérations courantes de lectures et écritures de la CIB s'effectuent sur le master. Le DC est la seule entité du cluster qui peut décider qu'un changement global de celui-ci peut être effectué, tel que retirer un noeud ou déplacer des ressources.
• Base d'information du cluster (CIB, Cluster Information Base) La CIB est une représentation XML (en mémoire) de la configuration complète et de l'état courant du cluster. Elle contient la défi nition de toutes les options du cluster, des noeuds, ressources, contraintes et relations internes. La CIB synchronise également les informations sur tous les noeuds du cluster. Il n'y a qu'une base maître (ou master) à la fois et elle est maintenue par le DC. Tous les autres noeuds contiennent une copie de cette base.
• Moteur de gestion des politiques (PE, Policy Engine) Quelle que soit l'action touchant l'ensemble du cluster initié par le DC, le PE calcule l'état résultant de cette action. Il fournit également un graphe de transition contenant la liste des actions et dépendances nécessaires pour atteindre le nouvel état. Le PE s'exécute sur chaque noeud afi n d'accélérer la bascule d'un DC.
• Le gestionnaire de ressources locales (LRM, Local Resource Manager) Le LRM fait appel aux agents de ressources locales à la demande du CRM. Il peut donc effectuer des opérations de démarrage, arrêt, supervision et renvoyer les résultats au CRM. Il masque également les différences entre les scripts standards supportés pour les agents de ressources (OCF, LSB, Heartbeat v1). Le LRM est la source d'autorité pour toutes les ressources du noeud sur lequel il s'exécute.

3. COUCHE RESSOURCE
Il s'agit de la plus haute couche. Elle intègre un ou plusieurs agents ressources. Ces agents sont des programmes (le plus souvent des scripts) écrits pour démarrer, arrêter et vérifier l'état d'une ressource. Les agents sont appelés uniquement par le LRM. Les logiciels tiers peuvent intégrer leurs propres agents et ainsi fournir une intégration automatique de leur application dans le cluster.

avantages_inconvenients
Pour en savoir plus
L’Informaticien et le Competence Center, de Non Stop Systems, sont
partenaires pour la réalisation de tests de logiciels, de matériels ou de
services du marché. Si vous souhaitez obtenir davantage d’informations
sur ces tests, n’hésitez pas à contacter Non Stop Systems à cette adresse :
ZI de la Madeleine, 27, rue de la Maison-Rouge, 77185 LOGNES
Tél. : +33 (0)1 60 95 08 80
Fax : +33 (0)1 60 95 08 81
ou sur le site www.nonstop.fr

Autres tests Tests 2009, Logiciel

/// Actuellement à la Une...
Le nouveau leader mondial de la transformation numérique des entreprises industrielles et de technologie est Français et s'appelle Capgemini.

Mylène Jarossay succède à Alain Bouillé à la présidence du club des RSSI des grandes entreprises et administrations françaises et est chargée de conduire son plan de transformation.

On ne présente plus cette petite carte à tout faire qui évolue régulièrement depuis sa sortie en 2014. Voici qu'arrive la génération 4 avec nouveau processeur et capacités graphiques améliorées. Seul le prix ne change pas : 35$ pour le modèle de base.

Ça continue ! Le Bitcoin poursuit son ascension et dépasse désormais la barre des 10 000 dollars. Cette remontée, après plus d’un an de marasme, est toujours aussi difficilement explicable.

Toujours aussi avare de détails, Mozilla se contente de la rapide description de cette nouvelle vulnérabilité, la deuxième découverte en une semaine. Il faut aller chercher du côté de Coinbase pour apprendre que les deux failles ont été associées pour créer un exploit visant les salariés des plateformes d’échange de cryptomonnaies.

Presque 20 ans après la publication de l’Agile Manifesto , toutes les directions générales veulent pouvoir annoncer que leur DSI a basculé sur les « méthodes agiles ». Les géants du CAC 40 rivalisent dans la communication sur leurs stratégies agiles. Pourtant, derrière les beaux discours, le passage à l’Agile At Scale reste un exercice difficile… et la révolte des développeurs couve. Article paru dans L'Informaticien n°177.

L’éditeur de solutions analytiques propose maintenant un outil pour modéliser simplement des processus de machine learning.

Le cabinet Gartner vient de rendre publique une étude sur le marché du RPA (Robotic Process Automation). Le cabinet s’attend à ce qu’il atteigne 1,3 milliard de dollars à la fin de cette année.

Le NYSE a accueilli hier un nouveau venu : Slack. La plateforme collaborative avait opté pour une cotation directe, ne levant pas de fonds au passage. Mais ses investisseurs historiques ont fait une belle plus-value : le titre a ouvert 50% au-dessus de son prix de référence et a grimpé à près de 42 dollars à la mi-journée.

Le groupe automobile annonce un accord exclusif avec la filiale d’Alphabet dédiée à la conduite autonome. Ce rapprochement se concrétisera dans une première phase d’exploration des services de mobilité autonome en France et au Japon.

Toutes les News