Solution SUSE/Xymon de Malavix informatique pour Raspberry Pi

M. Malenfant nous con e qu’à son retour de la SUSECON organisée à Washington, il ne pensait pas que le Raspberry Pi serait capable de répondre à ses besoins. « Je pensais que Xymon allait mettre à genoux cette machine minuscule », explique-t-il. En e et, Xymon allait devoir écrire toutes ses données de monitoring sur une petite carte SD du Raspberry Pi, à moins que celuici soit connecté à un périphérique de stockage USB externe pour booster les E/S. M. Malenfant était cependant curieux de connaître ses véritables capacités. Il a donc testé l’appareil avec Xymon et, à sa grande surprise, a constaté que « la machine pouvait gérer une grande quantité de données avant de ralentir ».

Malavix devait néanmoins encore régler quelques problèmes avant de proposer à ses clients une solution fonctionnelle, en particulier l’absence d’horloge matérielle du Raspberry Pi ou encore la nécessité de déterminer le nombre optimal de systèmes que le Raspberry Pi pouvait surveiller avant de ralentir. Malavix a tout d’abord pensé résoudre le problème d’horloge en ajoutant simplement une horloge matérielle à l’un des ports de l’appareil, mais aucune horloge disponible ne possédait de pilote pour Raspberry Pi. Pour déconnecter ou redémarrer le Raspberry Pi, un client doit actuellement le synchroniser avec un serveur NTP (Network Time Protocol) avant de lancer Xymon et ses packages requis. Ces packages incluent notamment un serveur Web et un navigateur Web pour la prise en charge de l’interface utilisateur de Xymon, qui propose des versions graphiques et alphanumériques des données provenant des systèmes surveillés (Malavix utilise le serveur Web Apache 2). Pour une liste complète des prérequis logiciels de Xymon, consultez la page d’installation : http://xymon.sourceforge.net/xymon/ help/install.html. En plus des packages, le déploiement de Xymon par Malavix inclut le logiciel Korn Shell pour assurer la prise en charge des plugins de monitoring externe basés sur Korn .

Pour déterminer les limites exactes du Raspberry Pi en termes d’évolutivité, M. Malenfant et son équipe ont progressivement ajouté des tests obligeant l’appareil à véri er les résultats toutes les trois à cinq minutes. Malavix a ainsi découvert que l’évolutivité du Raspberry Pi variait en fonction de l’endroit où le traitement de l’état était e ectué. Ainsi, lorsque le traitement était réalisé par des extensions d’applications dans les machines du client, le Raspberry Pi pouvait gérer plus de tests que lorsqu’il e ectuait le traitement luimême, comme c’était le cas quand Xymon interrogeait des périphériques distants par un protocole SNMP (Simple Network Management Protocol). Les limites d’évolutivité dépendaient également du volume de données RRD (Round Robin Database) que le Raspberry Pi devait stocker sur sa carte SD. Par exemple, si une mise à jour de l’état imposait de modi er 20 chiers RRD, son impact était plus grand que celui d’une mise à jour sans données RRD.

Malavix a soumis le Raspberry Pi à un test de résistance avec jusqu’à 3 000 tests d’état, dont Xymon a collecté les données via SNMP en utilisant un grand nombre de ports Ethernet. « Sans surprise, c’était trop pour le Pi », explique M. Malenfant. Cependant, Malavix a réussi à transférer l’ensemble de la configuration Xymon depuis le Raspberry Pi vers un PC autonome exécutant SUSE Linux Enterprise Server 12, preuve que la solution Xymon peut s’affranchir des limitations inhérentes au Raspberry Pi. « En conservant SLES [SUSE Linux Enterprise Server] 12 (d’ARM à x86), nous pouvons réutiliser presque tout le travail e ectué sur le Pi », conclutil.

Le test sur le déploiement client initial étant désormais terminé, Malavix a évalué la capacité du serveur Xymon sur Raspberry Pi à environ 1 500 tests d’état. Malavix pense que ce chi re approximatif sera valable pour 80 % de ses clients.

Bien que le Raspberry Pi prenne en charge plusieurs systèmes d’exploitation, SUSE Linux Enterprise Server 12 constitue pour Malavix un choix évident car, comme l’explique M. Malenfant, « la plupart de nos clients utilisent SAP », en particulier SAP HANA, sur SUSE Linux Enterprise Server. « Aujourd’hui, la majorité des infrastructures HANA sont déployées sur SLES [SUSE Linux Enterprise Server] », ajoute- t-il. Pour cette raison, il semble donc logique de pro ter de l’expertise des clients en déployant un système de monitoring exécuté sur SUSE Linux Enterprise Server.