Ganglia est une solution distribuée multiplateforme utilisée par de nombreuses organisations pour surveiller les performances de leurs clusters.L'objectif de l'article est de vous faire découvrir le logiciel à travers la mise en place de la surveillance d'un « cluster » composé de serveurs sous Linux et OpenSolaris et ainsi vous montrer qu'il peut aussi être une solution de choix pour un parc informatique plus classique.
1. Description de Ganglia
1.1 Description du projet
Ganglia a été développé initialement à l'université de Berkeley sous licence BSD. Son but était de fournir une solution robuste et peu consommatrice en ressources pour le monitoring des performances de clusters de calcul. Ces clusters pouvant comporter plusieurs centaines voire milliers de nœuds, on comprend donc vite la préoccupation du projet sur le trafic réseau et la charge induite sur les nœuds.
Une démonstration valant mieux qu'un long discours, je vous conseille de visiter le site de surveillance de Wikimédia (la fondation derrière Wikipédia) pour voir une démonstration du produit.
Fig. 1 : Le grid de la fondation Wikimédia
Les possibilités de configuration de Ganglia lui permettent aussi d'être utilisé en environnement de production classique. On peut adapter la notion de cluster de Ganglia à un simple regroupement par rôle applicatif (1 groupe par serveurs web, mail, bases de données...), par ensemble de machines virtuelles sur un serveur physique ou tout simplement par rôle (Production, Recette, Développement).
De plus, il a été porté sur un grand nombre de plateformes (Unix propriétaires, Linux et BSD et même Windows,... ), ce qui permet d'utiliser un outil unique pour surveiller les performances de l'ensemble de son parc informatique.
Un avantage par rapport à d'autres solutions est de pouvoir disposer des informations en quasi temps réel.
1.2 concept
Ganglia est composé de deux services principaux :
- gmond : un service tournant sur chaque nœud/serveur surveillé et collectant les différentes métriques.
- gmetad : un service qui consolide les données des services gmond et les stockent dans une base RRD.
Les nœuds d'un cluster Ganglia hébergent le service gmond et communiquent leur statut par UDP.
gmetad a des nœuds gmond de référence pour chaque cluster qu'il gère et les interrogent de manière régulière pour récupérer l'état de l'ensemble.
Les bases RRD (Round Robin Databases) sont des bases de données conçues pour stocker des données évoluant au cours du temps à intervalle régulier. RRDtool est un outil assez célèbre qui est utilisé comme backend par un grand nombre de projets(Cacti par exemple). Ganglia n'est donc pas une exception.
La communication entre les nœuds gmond d'un cluster utilise le protocole XDR. Ce protocole est un standard de l'IETF permettant à des OS différents de communiquer entre eux (pas de problème avec la taille des indiens ;-). Cela permet de mettre en place des « clusters » hétérogènes.
2. Exemple de déploiement
Cette partie va décrire la mise en place de Ganglia et la surveillance d'un premier cluster composé d'un serveur Fedora 10 hébergeant les services web, gmetad et gmond. Ce dernier nous servira de console d'accès à Ganglia.
Le cluster sera composé d'un serveur Debian, d'un serveur OpenSolaris, ainsi que du serveur Fedora 10. Voir le schéma pour avoir une idée des flux.
Fig. 2 : Flux du cluster
Ce cluster utilisera à la fois une communication UDP unicast et multicast entre les nœuds gmond pour illustrer les configurations possibles.
Il est vivement conseillé que l'ensemble des serveurs utilisent un serveur de temps NTP pour être à la même heure.
2.1 Installation
gmetad et gmond sous Fedora 10
L'installation sous Fedora 10 s'effectue sans aucun problème, la distribution incluant une version récente de Ganglia dans ses dépôts officiels. Les packages à installer par Yum ou l'interface graphique sont ganglia-gmetad et ganglia-gmond.
2.2 Compilation de gmond sous OpenSolaris
J'ai choisi OpenSolaris pour illustrer l'installation de gmond à partir des sources. Cela décrit certains des problèmes que l'on peut rencontrer sur des architectures pour lesquels des paquetages n'existent pas.
Il existe aussi une archive sur Sunfreeware pour Solaris 10, mais il ne s'agissait pas de la dernière version et elle n'est pas packagée.
Pour pouvoir compiler le module, il est nécessaire d'installer l'environnement de compilation, ainsi que la bibliothèque APR(Apache runtime) :
$ pfexec pkg install SUNWgcc SUNWgmake SUNWapr13dev
Une autre dépendance est la bibliothèque confuse, mais il n'existe pas de package officiel à l'heure actuelle (c'est prévu pour avril 2009). Il faut donc télécharger la bibliothèque sur le site http://www.nongnu.org/confuse/. La version utilisée ici est la 2.6.
Une fois le fichier confuse-2.6.tar.gz désarchivé, on se met dans le répertoire et on lance le configure classique. Il est nécessaire de rajouter certains paramètres pour que la compilation se déroule bien :
$ ./configure CFLAGS=-fPIC --disable-nls
Le NLS doit être désactivé à cause d'un problème lors de la compilation sous OpenSolaris.
Le reste de l'installation s'effectue normalement :
$ make
$ pfexec make install
La bibliothèque est installée par défaut dans /usr/local.
Il faut ensuite télécharger le fichier ganglia-3.1.1.tar.gz sur le site officiel. On désarchive le fichier et on lance configure en spécifiant /usr/local comme répertoire d'installation :
$ ./configure --with-libconfuse=/usr/local --prefix=/usr/local CC="gcc -std=gnu99"
La variable CC permet de faire prendre en compte par gcc le standard C99. Cela évite une erreur lors de la compilation. Après le désormais classique make, pfexec make install, gmond est compilé et installé. Si on désirait compiler gmetad, il aurait été nécessaire d'ajouter l'option –with-gmetadà configure (il y a d'autres dépendances à gérer).
La première fois que l'on exécute gmond, on peut tomber sur ce message :
$ pfexec /usr/local/sbin/gmond
ld.so.1: gmond: fatal: libapr-1.so.0: open failed: No such file or directory
Killed
C'est assez surprenant, mais le chemin d'accès à libapr-1.so.0 n'est pas dans le système. On pourrait paramétrer la variable d'environnement LD_LIBRARY_PATH pour le prendre en compte, mais, sur OpenSolaris, une solution plus propre est d'utiliser la commande crle. C'est la commande qui permet de paramétrer le link lors de l'exécution. Il suffit donc de rajouter le répertoire nécessaire :
$ pfexec crle -u -l /usr/apr/1.3/lib
On peut aussi vérifier la configuration avec la même commande :
$ pfexec crle
Configuration file [version 4]: /var/ld/ld.config
Platform: 32-bit LSB 80386
Default Library Path (ELF): /lib:/usr/lib:/usr/local/lib:/usr/apr/1.3/lib
Trusted Directories (ELF): /lib/secure:/usr/lib/secure (system default)
Command line:
crle -c /var/ld/ld.config -l /lib:/usr/lib:/usr/local/lib:/usr/apr/1.3/lib
Pour terminer l'installation, il est nécessaire de créer le répertoire et le fichier de configuration par défaut (avec l'option -t de gmond) :
$ pfexec mkdir -p /etc/ganglia/conf.d
$ pfexec sh -c "/usr/local/sbin/gmond -t >/etc/ganglia/gmond.conf"
À noter l'utilisation de sh -c pour pouvoir rediriger correctement la sortie de gmond en utilisant pfexec.
La dernière partie consiste à créer un service SMF pour gmond.
Voici un fichier XML contenant la configuration simplifiée du service :
<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="manifest" name="gmond">
<service
name="network/ganglia/gmond"
type="service"
version="1" >
<single_instance/>
<!--
Dependencies. network must be enabled before gmond start.
-->
<dependency name='net-loopback'
grouping='require_all'
restart_on='none'
type='service'>
<service_fmri value='svc:/network/loopback' />
</dependency>
<dependency name='net-physical'
grouping='require_all'
restart_on='none'
type='service'>
<service_fmri value='svc:/network/physical' />
</dependency>
<instance name="default" enabled="false">
<!-- Start method: start gmond -->
<exec_method
type="method"
name="start"
exec="/usr/local/sbin/gmond"
timeout_seconds="30"/>
<!-- Stop method: kill gmond -->
<exec_method
type="method"
name="stop"
exec=":kill"
timeout_seconds="30" />
</instance>
<template>
<common_name>
<loctext xml:lang="C">
Ganglia Monitoring daemon
</loctext>
</common_name>
</template>
</service>
</service_bundle>
Pour le mettre en place, on crée le répertoire /var/svc/manifest/network/ganglia et on y copie le fichier gmond.xml. Il suffit ensuite d'importer le fichier pour créer le service :
$ pfexec svccfg import /var/svc/manifest/network/ganglia/gmond.xml
On active le service, puis on vérifie son statut :
$ pfexec svcadm enable network/ganglia/gmond
$ svcs -l network/ganglia/gmond
fmri svc:/network/ganglia/gmond:default
name Ganglia Monitoring daemon
enabled true
state online
next_state none
state_time Sun Jan 11 17:52:18 2009
logfile /var/svc/log/network-ganglia-gmond:default.log
restarter svc:/system/svc/restarter:default
contract_id 126
dependency require_all/none svc:/network/loopback (online)
dependency require_all/none svc:/network/physical (multiple)
Le statut doit être online. On peut aller voir le log du service dans le fichier spécifié à la ligne logfile.
2.3 gmond sous Debian Stable
Sous Debian (et Ubuntu), la version de Ganglia fournie est la 2.5.7 qui a plus de 4 ans. Cette version bien qu'ancienne peut être gérée par les versions récentes de gmetad.
Si vous souhaitez profiter des différentes améliorations apportées à Ganglia depuis, vous pouvez toujours compiler Ganglia comme dans l'exemple précédent ou convertir les packages rpm du site officiel avec la commande alien.
À savoir que la situation devrait s'améliorer rapidement, car la version 3.1 est dans les pseudo-dépôts « experimental ».
Dans notre cas, j'ai utilisé une version compilée.
2.4 Configuration de gmond
La configuration de gmond s'effectue dans le fichier gmond.conf situé dans /etc/ganglia.
Comme vue lors de l'installation de gmond sous OpenSolaris, on peut générer un fichier de configuration par défaut avec la commande gmond -t.
Les paramètres sont regroupés en sections distinctes. Une section suit le format suivant :
nom_section {
parameter = value
}
Une section peut contenir des sous-sections qui respectent le même format.
On va passer en revue les différents paramètres à modifier pour avoir une configuration minimale du cluster. Les paramètres sont à appliquer sur tout les nœuds sauf mention contraire.
La section globals permet de définir le comportement de gmond tel que le niveau de debug, l'utilisateur sous lequel il se lance ainsi que si le processus se met en background avec l'option daemonize.
Les options par défaut conviendront dans notre cas.
Un paramètre intéressant à modifier est host_dmax. Il spécifie le temps au bout duquel le cluster considère qu'un nœud qui ne communique plus est à supprimer. Par défaut, un nœud ne disparaît jamais et il est nécessaire de redémarrer l'ensemble des nœuds du cluster pour que sa disparition soit prise en compte. Cette opération est ennuyeuse si vous surveillez par un autre moyen la présence des nœuds (Nagios par exemple). On peut alors spécifier un délai de 24H :
host_dmax = 86400 /*secs */
En ce qui concerne la section cluster :
cluster {
name = "mes_serveurs"
owner = "system_team"
latlong = "unspecified"
url = "unspecified"
}
Ici, on nomme notre cluster mes_serveurs et on spécifie comme propriétaire system_team. L'association entre ces deux éléments doit être unique dans l'ensemble du grid. Un grid représente l'ensemble des clusters gérés par un service gmetad.
Les champs url et latlong (latitude et longitude du serveur) sont plus informatifs qu'autre chose.
La section udp_send_channel définit où seront envoyées les métriques collectées. Par défaut, la configuration pointe sur une adresse multicast. Cela permet d'informer un grand nombre de nœuds du même cluster en émettant les paquets une seule fois à partir de la source.
Nous allons spécifier une adresse multicast pour notre cluster sur les nœuds feddy et osol.
udp_send_channel {
mcast_join = 239.2.11.70
mcast_if = eth1
port = 8649
ttl = 1
}
L'option ttl positionnée à 1 est très importante, car elle évite que les paquets multicast soient routés sur d'autres réseaux.
On peut aussi indiquer une interface spécifique (utilisation d'un réseau privé) en utilisant l'option mcast_if.
Sous Ganglia 3.1.1, il y a un bug et l'option mcast_if n'est pas prise en compte. Il est nécessaire d'ajouter une route manuellement sur le serveur surveillé.
route add -net 224.0.0.0 netmask 240.0.0.0 dev eth1
Dans notre cluster de test, nous considérons que le serveur debby est dans un sous-réseau où le multicast n'est pas toléré (certains administrateurs réseau ne l'apprécient pas). On se replie donc sur l'utilisation d'adresses unicast classiques.
On crée une section udp_send_channel spécifique au serveur debby :
udp_send_channel {
host = feddy10
port = 8660
}
Le ttl n'est alors plus utile.
Dans un environnement de production, on définirait au moins 2 sections udp_send_channel lorsque l'on utilise de l'unicast, afin d'avoir un niveau de redondance en contactant aux moins deux nœuds différents.
La section udp_recv_channel indique que le service gmond récupère les métriques des autres nœuds. Elle est donc nécessaire au minimum sur les nœuds interrogés par le service gmetad.
Voici la section sur feddy10 pour recevoir les données multicastées du nœud osol :
udp_recv_channel {
mcast_join = 239.2.11.70
mcast_if = eth1
port = 8649
}
Et voici la section pour recevoir les données envoyées directement par debby (on spécifie IPv4 uniquement) :
udp_recv_channel {
port = 8660
family = inet4
}
La section tcp_accept_channel sert à donner le port TCP sur lequel on peut obtenir une description au format XML de l'état du cluster. Les nœuds gmond spécifiés à gmetad doivent avoir cette section. Dans notre cas, on conserve le port par défaut (8649).
Bonnes pratiques
Une bonne pratique est d'avoir le même fichier de configuration sur l'ensemble des nœuds d'un cluster. On diverge ici uniquement afin d'illustrer les possibilités de configuration de Ganglia.
Configuration gmond 2.5.7
Le format du fichier de configuration a changé entre les versions 3 et les versions 2.5, mais les noms des options restent identiques. Un grand nombre d'options ne sont pas présentes en 2.5.7, mais les fonctionnalités principales y sont.
Voici les paramètres à positionner en 2.5.7 :
- name "debians" : nom du cluster
- owner "system_team" : contact du cluster
- mcast_channel 239.2.11.72 : choisir une adresse différente du cluster en 3.1.1.
- mcast_if ethX : l'interface réseau à utiliser pour le multicast.
Vue la facilité d'installation des versions 3 de Ganglia, je n'utilise personnellement pas cette version, mais il faut savoir que cela reste une possibilité.
Le service gmetad en version 3.1 n'a aucun problème pour récupérer ces données.
2.5 Configuration de gmetad
Cette configuration s'effectue sur feddy10. Le fichier de configuration de gmetad se nomme /etc/ganglia/gmetad.conf. Les paramètres sont spécifiés ligne par ligne.
Le paramètre le plus important est data_sourcequi donne à gmetad les serveurs à interroger pour avoir un état du cluster. La syntaxe est du type :
data_source "nom_cluster" nom_serveur:port
Le nom de cluster sur cette ligne doit correspondre à celui spécifié dans le fichier gmond.conf. Si le port défini dans gmond est celui par défaut, il n'est pas nécessaire de l'indiquer.
Dans le cas de notre cluster, le paramètre est :
data_source "mes_serveurs" feddy10
Le paramètre rrd_rootdir spécifie l'endroit où seront stockées les bases RRD. Lorsqu'on commence à avoir plusieurs dizaines de serveurs monitorés, la valeur par défaut de /var/lib/ganglia/rrds n'est pas souhaitable. Il vaut mieux avoir un système de fichiers dédié pour cela.
Ici, on spécifie et on crée le répertoire /ganglia/rrds :
rrd_rootdir /ganglia/rrds
Le propriétaire du répertoire doit être Ganglia.
Le dernier paramètre que l'on modifiera ici est RRAs :
RRAs "RRA:AVERAGE:0.5:1:244" "RRA:AVERAGE:0.5:4:1440" "RRA:AVERAGE:0.5:20:504" "RRA:AVERAGE:0.5:24:1680" \
"RRA:AVERAGE:0.5:40:13464"
Ce paramètre est expliqué dans le chapitre qui suit.
2.5.1 Les bases RRD
Les bases RRD ont une taille définitive dès leur création et il y a une base par métrique. Lors de l'ajout de métrique, une nouvelle base est créée.
Le délai de rétention est contrôlé par le paramètre RRAs. Une base RRA correspond à une base d'archive. On peut créer plusieurs bases d'archive pour une base source RRD. Par exemple, on peut avoir une base qui archive les données des dernières 24 heures avec une consolidation des valeurs toutes les minutes, une autre sur sept jours avec une consolidation sur 5 minutes, etc. Ces bases sont stockées dans le même fichier.
La syntaxe RRDtool est du type :
RRA:CF:xff:step:rows
CF correspond au type de consolidation réalisé. Par défaut, c'est AVERAGE qui est proposé par Ganglia. Cela correspond à la moyenne des valeurs de l'intervalle demandé, mais il est en théorie possible de choisir MINIMUM, MAXIMUM ou LAST. Je dis, en théorie, car cette définition est valable pour l'ensemble des métriques collectées et ces 3 choix ne sont pas vraiment adaptés à ceux-ci.
- step précise le nombre d'intervalles de temps de consolidation des mesures. Ganglia travaille avec un pas de 15 secondes donc 4 correspondent à 1 minute.
- rows correspond au nombre d'enregistrements que contiendra la base. C'est une valeur fixe. Lorsque la base sera remplie, les premiers enregistrements seront écrasés.
- xff est le “Xfile factor” et correspond au pourcentage de valeurs qui peuvent être inconnues lors de la consolidation sans générer d'erreur. Par défaut, on considère que 50% de valeurs manquantes est tolérable.
L'archivage par défaut de Ganglia consiste en ces RRA (période/moyenne) :
- heure/15 secondes ;
- journée/10 minutes ;
- semaine/42 minutes ;
- 28 jours/2h48 ;
- 374 jours/24h.
Lors de la génération d'un graphique, RRDtool est appelé et utilise automatiquement la base d'archives contenant en totalité la période demandée avec l'intervalle de temps le plus petit.
La configuration par défaut est utile pour économiser de la place, mais on perd rapidement en précision, et ce, dès la semaine précédente : 1 moyenne sur 42 minutes élimine pas mal de « détails » ;-).
Voici un exemple si l’on veut quelque chose de plus précis en conservant le concept des bases d'archives séparées :
RRAs "RRA:AVERAGE:0.5:1:244" "RRA:AVERAGE:0.5:4:1440" "RRA:AVERAGE:0.5:20:504" "RRA:AVERAGE:0.5:24:1680" \
"RRA:AVERAGE:0.5:40:13464"
Ce qui donne :
- heure/15 secondes ;
- journée/1 minute ;
- semaine/5 minutes ;
- 28 jours/6 minutes ;
- 374 jours/10 minutes.
On pourrait aussi diminuer le nombre de bases d'archives et prendre une seule base avec une précision d'1 minute sur 10 ans.
RRAs "RRA:AVERAGE:0.5:4:5270400"
Le choix du nombre de bases d'archives est dicté par des questions de performance.
La taille du fichier RRD peut ainsi varier de quelques kilooctets à plusieurs dizaines de mégaoctets. Une bonne pratique est de mettre en place toutes les métriques supplémentaires que l'on désire avant de toucher à RRAs (cela nécessite de supprimer les bases existantes). Pour indication, le répertoire d'un client Fedora avec les métriques par défaut fait 6,8 Mo avec le paramétrage proposé au lieu de 580 ko par défaut.
2.6 Configuration de l'interface web
Sous Fedora 10, le mieux est d'installer le package ganglia-web à l'aide de Yum. Le package ganglia-web ne contient pas l'interface web que l'on utilisera au final, mais permet d'installer les dépendances nécessaires.
Je conseille l'utilisation de l'interface web améliorée que propose le site www.perlz.org. Elle possède deux caractéristiques très intéressantes :
- le patch Jscalendar qui propose un calendrier javascript pour sélectionner l'intervalle de temps des graphiques ;
- le patch custom graph qui permet de créer ces graphiques selon ses propres critères et même de sauvegarder ses templates.
Par défaut, l'interface web Ganglia permet d'avoir une vue des serveurs sur la dernière heure, la semaine, le mois ou l’année. Les addons jscalendar et custom graph permettent d'en augmenter la portée en rendant possible le choix de la période de temps observée. Cela permet d'effectuer des investigations sur les problèmes de performance de serveurs et de trouver depuis quand ils existent. Ces addons font une grande partie de l'intérêt de Ganglia pour une utilisation hors-monde HPC.
Une fois la version téléchargée, il faut renommer le répertoire /usr/share/gangliaen /usr/share/orig_ganglia, puis copier le répertoire ganglia de l'archive dans /usr/share et changer le propriétaire des fichiers à ganglia.
Cette interface web est prévue pour incorporer des informations spécifiques à la plateforme Power5 d'IBM. Si vous ne disposez pas de ce matériel, il faut exécuter ce script :
cd /usr/share/ganglia
./setup-web-without-POWER5.sh
Si vous avez modifié l'emplacement des bases RRDs, il est aussi nécessaire de modifier la variable $rrds dans le fichier /usr/share/ganglia/conf.php pour refléter le changement.
La version proposée sur ce site est basée sur la version 3.0.5 de l'interface web de Ganglia et pas sur la 3.1.1. En connaissant un peu PHP, ce n'est pas très difficile de porter les modifications à la 3.1.1, mais on sortirait largement du sujet de l'article.
2.6.1 Spécifique fedora
Il est nécessaire d'ajouter les règles firewall permettant au serveur feddy10 de recevoir les informations des autres nœuds en UDP et l'accès en http :
# iptables -I INPUT -p udp --dport 8649 -j ACCEPT
# iptables -I INPUT -p udp --dport 8660 -j ACCEPT
# iptables -I INPUT -p tcp –dport 80 -j ACCEPT
# service iptables save
iptables: Saving firewall rules to /etc/sysconfig/iptables:[ OK ]
Un autre souci possible est SELinux qui bloque l'utilisation de RRDtool dans l'interface web de Ganglia avec un message de ce type sur le browser :
There was an error collecting ganglia data (127.0.0.1:8652): fsockopen error: Permission denied
Le mieux est de passer en mode permissif et d'utiliser les différents menus de l'interface web pour inventorier les règles.
# setenforce permissive
Ensuite, on vérifie les règles qui seraient nécessaires pour que cela fonctionne en vérifiant les alertes dans le fichier d'audit (il peut être nécessaire de le purger avant de tester l'interface).
root # audit2allow -i /var/log/audit/audit.log
#============= httpd_t ==============
allow httpd_t default_t:dir { read search getattr };
allow httpd_t default_t:file { read getattr };
allow httpd_t port_t:tcp_socket name_connect;
On peut rajouter l'option -w pour connaître pourquoi la règle doit être ajoutée.
Ensuite, on crée le module de règle pour Ganglia et on le charge :
# grep avc /var/log/audit/audit.log | audit2allow -M ganglia
# semodule -i ganglia.pp
Conclusion
Et voilà, on peut enfin observer le résultat de l'installation :
Cet article avait pour but de mettre en place une installation de Ganglia tout en abordant quelques éléments d'installation spécifiques à OpenSolaris et Fedora. Le but était de vous donner une vision réaliste de l'implémentation de Ganglia. Personnellement, je n'ai jamais eu la chance de pouvoir le déployer dans un environnement sans avoir à « bricoler » l'installation sur une machine ou deux :-)
Références :
- http://ganglia.info : site officiel de Ganglia
- http://www.perzl.org/ganglia/webinterface.html : site contenant l'interface web modifiée.
