Articles

livre blanc

Superviser un serveur OpenStack

Cet article est le premier d’une série orientée technique afin de montrer ce qu’il est possible de faire avec les outils de la communauté.

Remarque: Somone proposant une solution basée sur Centreon de la société Merethis, nous allons donc utiliser Centreon (CES [1]) pour cet article, cependant, il est applicable à d’autres solutions comme Zabbix.

 

Qu’est ce que OpenStack ?

Selon la définition Wikipedia :

OpenStack est un ensemble de logiciels open source permettant de déployer des infrastructures de cloud computing (Infrastructure as a service). La technologie possède une architecture modulaire composée de plusieurs projets corrélés (Nova, Swift, Glance…) qui permettent de contrôler les différentes ressources des machines virtuelles tels que la puissance de calcul, le stockage ou encore le réseau inhérent au datacenter sollicité.

De nombreuses entreprises ont rejoint la fondation OpenStack. Parmi celles-ci on retrouve :Canonical,Red Hat,SUSE Linux,eNovance,AT&T,Cisco,Dell,HP,IBM,Yahoo!,Oracle,Orange,Cloudwatt,EMC,VMware,Intel.

Architecture OpenStack :

Ci-dessous un schéma résumant l’architecture OpenStack et de ses principaux composants (description extraite de Wikipédia):

  • Compute : Nova (Hyperviseur)
  • Object Storage : Swift (stockage d’objet)
  • Image Service : Glance (service d’image)
  • Dashboard : Horizon (interface Web de paramétrage et gestion)
  • Identity : Keystone (gestion des utilisateurs, rôles et accès)
  • Network : Neutron (auparavant nommé Quantum) (gestion des réseaux à la demande)
  • Storage : Cinder (service de disques persistants pour les instances)

Remarque: ces composants ne sont (pour la plupart) que des couches d’abstraction à d’autres composants plus concrets comme un hyperviseur KVM ou Xen pour Compute, un stockage LVM ou Ceph pour Cinder ou Swift et un pont réseau Linux classique pour Neutron.

D’autres composants annexes comme une queue de messages RabbitMQ et une base de données MySQL sont requis.

Supervision OpenStack 1/3 (Composants de base):

La base d’OpenStack repose sur un certain nombre de processus et d’Endpoints HTTP :

– Exemple de supervision d’un processus via l’agent NRPE (ici nova-api):

[centreon-engine@ces3 ~]# /usr/lib/nagios/plugins/check_nrpe -H 10.0.3.1 -c check_procs -a « 1:10 » « 1:100 » nova-api
PROCS WARNING: 13 processes with args ‘nova-api’ | procs=13;1:10;1:100;0;

 

– Exemple de supervision d’un endpoint HTTP (ici l’API Keystone pour l’authentification):

[centreon-engine@ces3 ~]# /usr/lib/nagios/plugins/check_http -H 10.0.3.1 -p 5000 -u « /v2.0 » -e 200 -s stable
HTTP OK: Status line output matched « 200 » – 783 bytes in 0.006 second response time |time=0.005710s;;;0.000000 size=783B;;;0

 

Ce qui donnera une liste de modèles de services comparable à celle-ci (à adapter suivant votre convention de nommage):

  • OpenStack-Dashboard-Web-Server
  • OpenStack-Dashboard-NoVNC_Proxy
  • OpenStack-Block_Storage-Scheduler
  • OpenStack-Block_Storage-API
  • OpenStack-Block_Storage-Volume
  • OpenStack-Image_Service-API
  • OpenStack-Image_Service-Registry
  • OpenStack-Compute_Service-Compute
  • OpenStack-Compute_Service-Libvirtd
  • OpenStack-Identity-Service-Keystone
  • OpenStack-Network_Service-Network
  • OpenStack-Nova-API
  • OpenStack-Nova-Conductor
  • OpenStack-Nova-Scheduler
  • OpenStack-Nova-ConsoleAuth
  • OpenStack-Nova-EC2_Endpoint
  • OpenStack-Nova-Keystone_Endpoint

Les sous-composants mentionnés dans le chapitre précédent (kvm, lvm, etc.) ont généralement des indicateurs de supervision recommandés à mettre en place (non traité dans cet article).

Une supervision système correctement paramétrée est également nécessaire afin de s’assurer du bon fonctionnement de la plate-forme (CPU, Mémoire, SWAP, Espaces disques locaux et points de montage, I/O disques et réseaux, etc.).

Supervision OpenStack 2/3 (Logs et middlewares):

En complément des indicateurs mis en place ci-dessus, certains fichiers logs sont à surveiller:

  • Services OpenStack (Les API d’OpenStack étant au format HTTP, il faut rechercher les patterns qui ne contiennent pas “ status: 200 “)
2014-09-10 15:29:28.516 26742 INFO nova.api.ec2 [-] 0.605s 10.0.47.2 GET /services/Cloud None:None 400 [check_http/v1.4.16 (nagios-plugins 1.4.16)] text/plain text/xml
2014-09-10 15:29:28.517 26742 INFO nova.ec2.wsgi.server [-] 10.0.47.2 « GET /services/Cloud HTTP/1.1 » status: 400 len: 332 time: 0.0017200

 

  • MySQL
  • RabbitMQ
  • Systèmes (cron, etc.)

Remarque : la supervision de Log peut se faire de différentes manières via différents outils et pourrait faire l’objet d’un article à part entière. Ici, il est recommandé de procéder avec vos propres outils et à défaut, ceux-ci seront parfaits[2].

Au delà des logs, il est indispensable de mettre en place une métrologie (puis une supervision dans un second temps) sur MySQL[3]:

  • MySQL_Server-Qcache_Hitrate
  • MySQL_Server-Queries
  • MySQL_Server-Connection_Time
  • MySQL_Server-Slow_Queries
  • MySQL_Server-Threads_Connected
  • MySQL_Server-Innodb_Bufferpool_Hitrate
  • MySQL_Server-Databases_Size
  • MySQL_Server-MyISAM_Keycache_Hitrate
  • MySQL_Server-Uptime
  • MySQL_Server-Open_Files

ainsi que sur RabbitMQ[4]:

  • RabbitMQ-Aliveness
  • RabbitMQ-Connections
  • RabbitMQ-Objects
  • RabbitMQ-Overview
  • RabbitMQ-Partition
  • RabbitMQ-Server
  • RabbitMQ-Watermark

L’ensemble de ces indicateurs va  permettre de voir comment est utilisée la plate-forme ainsi que de placer / ajuster les seuils en fonction de l’utilisation. Ci-dessous, un exemple d’implémentation :

Bac à évènements part 1

Bac à évènements part 2

Supervision OpenStack 3/3 (Simulation d’une demande) :

Les indicateurs mis en place dans les chapitres précédents vont permettre d’identifier la cause du problème mais pas de détecter une panne du service car un indicateur peut passer CRITIQUE sans pour autant affecter le service.

Il faut donc simuler une demande d’utilisateur, soit en ligne de commande via la commande “nova”, soit via le portail Horizon.

La communication entre les différents composants se faisant par HTTP, il est en théorie possible de suivre cette demande de test de bout en bout puis réaliser une connexion SSH vers cette instance et enfin de la détruire.

Déroulement :

  • Création de l’instance via nova-manage
  • Attribution de l’adresse IP flottante (étape optionnelle)
  • Test de connexion en SSH
  • Restitution de l’adresse IP flottante (étape optionnelle)
  • Destruction de l’instance

Note: Ce scénario est à automatiser pour envoyer de manière passive le retour des différentes étapes.

Conclusion :

Superviser un serveur OpenStack n’est pas compliqué en soi, la documentation est très complète[5], de plus, la solution se base sur des composants connus et maîtrisés de longue date.

Il faut cependant ne surtout pas perdre de vue que ce sont les applications et leur disponibilité dans notre “cloud” qui sont prioritaires, l’infrastructure sous-jacente l’est moins.

Cet article a pour but de mettre en place une solution de monitoring simple afin de pouvoir déterminer rapidement la cause racine d’une dégradation de performance ou même d’un arrêt complet d’une ou plusieurs applications métier par exemple.

À l’exception de la dernière partie, les indicateurs utilisés peuvent remonter un certain nombre de faux positifs, il vous appartient maintenant d’améliorer ces indicateurs en les affinant ou en les remplaçant.

 

Notes :

[1] Centreon Entreprise Server (Centreon packagé par Merethis)

[2] TeeM Application Monitoring, Check_logfiles, Logstash, etc.

[3] https://forge.centreon.com/projects/centreon-plugins

[4] https://github.com/jamesc/nagios-plugins-rabbitmq

[5] http://docs.openstack.org/openstack-ops/content/logging_monitoring.html

 

news

News du mois de Mai

 

Sorties

Informations

Lectures

DSC_9821-1024x683

Convention CRIP 2013 : Merci d’être venus nombreux !

La convention, démarrée mardi tambour battant pour SOMONE s’est achevée hier soir avec la remise de l’Ipad Mini au gagnant du tirage au Sort, Dominique Desmars (IT-CE).

Photographie de Cheikh Deme et Dominique Desmars

Cheikh Deme a remis l’Ipad mini au gagnant du salon, Dominique Desmars de IT-CE

Stand de la société Somone, spécialisée dans la supervision et l'hypervision, lors de la convention du CRIP

Stand de la société Somone lors de la convention du CRIP

Le salon a été une grande réussite pour SOMONE, les clients sont venus nombreux pour nous présenter leur problématique et nous avons été heureux de pouvoir échanger avec eux sur notre domaine de prédilection.

Les problématiques sont souvent proches: réaliser des économies, améliorer la qualité du service délivrer, pouvoir répondre à des attentes de clients qui évoluent chaque jour, et ce tout en réfléchissant à de l’industrialisation. Bref, tous les secteurs dans lesquels SOMONE souhaite aujourd’hui se démarquer grâce à son expertise!

Un grand merci au CRIP pour nous avoir permis d’être présent et d’aller à la rencontre des besoins de nos clients. Nous avons appris avec une joie à peine contenue l’ouverture prochaine du groupe de travail sur la supervision, qui nous l’espérons permettra à nos clients d’échanger les bonnes pratiques… En attendant, vous pouvez toujours faire appel à nous!


Convention CRIP 2013 : L'équipe Somone

L’équipe Somone à votre écoute


En attendant, vous pouvez toujours faire appel à nous!

news

Somone: News du mois de Mai

Sorties

Salons

Lectures

news

News du mois de Mars…

Sorties

Informations

Lectures

news

Somone : News du mois de Mars

Sorties

Informations

Lectures

TeeM Monitoring Lifecycle Management, et son module d’industrialisation

TeeM Monitoring Lifecycle Management permet entre autre l’industrialisation de la configuration de la supervision et l’insertion en masse d’équipements ou objets de supervision.

Avec TeeM MLM (Module d’industrialisation), les exploitants de la supervision évitent le travail manuel de première configuration de la supervision,notamment par le biais de l’outil d’inventaire “GLPI”. TeeM MLM (Module d’industrialisation) permet d’importer en masse les équipements et applications de l’outil d’inventaire vers la solution de supervision.

TeeM MLM (Module d’industrialisation) aide aussi au maintien en condition opérationnelle et mise-à-jour de la solution de supervision. En effet, grâce à un système de gestion des changements, les exploitants de la supervision peuvent recharger la configuration pratiquement en temps réel.

Le projet TeeM MLM (module d’industrialisation) a démarré en Mai 2010 quand des scripts d’industrialisation ont été développés pour le compte d’un client en utilisant une première API de Centreon CLAPI. Équivalent à une version alpha, d’énormes efforts ont été consenti pour le debuggage en collaboration avec Merethis. Ces scripts ont donné naissance à l’actuel TeeM MLM (Module d’industrialisation).

Avec ces scripts, nous passions d’un fichier CSV à de la configuration Nagios. Suite a cela, nous avons voulu utiliser ces scripts avec comme source de données l’inventaire du client via GLPI, pour créer les hôtes dans un premier temps, puis leur assigner des services templates en utilisant les applications connues dans GLPI. Dans les spécifications, nous devions avoir une étape intermédiaire que le client validait. Cela se traduisait par un fichier Excel.

Toutes ces actions étaient regroupées dans un Job Talend en deux parties. La première partie consiste à générer un fichier Excel à partir d’une liste de serveurs (Input : liste de serveur en CSV, Talend : CSV => SQL, Talend : vues SQL => plusieurs CSV, Perl : CSVs => Excel). Puis, s’en suivait une étape de validation client faite à partir du fichier Excel généré. Enfin la seconde partie du Talend était lancée (Input : Excel, Perl : Excel => CSVs, Perl : CSVs => Clapi).

Quelques temps après, suite à une volonté de rationaliser et de simplifier «l’industrialisation», toute la mécanique a été reprise dans un unique script, utilisant comme brique les classes python développées chez le client pour accéder à CLAPI. Suite à cela, les options de TeeM MLM (Module d’industrialisation) ont été simplifiées pour faciliter son utilisation.

A. BUFFET

shinken_logo

Etude Shinken / Centreon

Dans le cadre d’une mission, j’ai souhaité mettre en avant un produit innovant afin de sortir du couple Nagios / Centreon. En effet, Out Of the Box, Les performances sur environnements virtualisés (VMWare) sont assez médiocres … (1500 checks / 5 min) avec une forte accumulation de maintenance.
J’ai donc déployé Shinken / Centreon avec les problèmes de compatibilité que cela allait supposer et qui étaient connus au moment de la décision.
Shinken est une ré-implémentation de Nagios en Python qui garde la rétro compatibilité avec Nagios, tout en introduisant un certain nombre de fonctionnalités, comme la découverte d’objets, des règles business, etc…

Avant le déploiement voici la liste des pour et des contre :

Les pour :

  • Équilibrage de charge
  • Haute disponibilité
  • Performant
  • Scalable
  • Rétro compatible Nagios
  • Fonctionne bien en environnement virtualisé
  • Codé en langage moderne (Python)

Les contre :

  • Compatibilité moyenne avec Centreon
  • Nécessite beaucoup de dépendances
  • Consomme de la mémoire

Maquette :

Le projet de migration d’un autre produit vers Shinken / Centreon (version 1.2.2) validé, j’ai entrepris de créer une maquette avec les cinq applications les plus importantes afin de me faire une idée concrète.
Globalement l’installation est simple et sans accroc grâce à un script complet qui installe l’ensemble des composants et des dépendances (très nombreuses et qui requièrent les droits root pour yum).
J’ai donc installé et configuré les serveurs suivants :

  • Centreon (8 Go de RAM) : Centreon ; Shinken- Arbiter ; Shinken-Scheduler ; Shinken-Broker ; Shinken-Receiver ; Shinken-Reactionner.
  • DB (8 Go de RAM): MySQL ; MongoDB (pour la rétention des états et la configuration de la WebUI de Shinken).
  • Poller1 (4 Go de RAM) : Shinken-Scheduler ; Shinken-Poller.
  • Poller2 (4 Go de RAM) : Shinken-Scheduler ; Shinken-Poller.

Premier point délicat, l’interfaçage avec Centreon. En effet, lorsque l’on vérifie la configuration, cela échoue car Shinken ne renvoie pas la bonne ligne à la fin de cette vérification. J’ai donc patché et mis en forme la sortie pour la rendre plus lisible.
Un second patch a été réalisé pour pouvoir utiliser les règles Business (autre avantage de Shinken) comme celles de Nagios BPA mais en plus évolué.

Montée en charge et problèmes rencontrés :

Au fur et à mesure de l’avancement du déploiement, je constate une forte montée en RAM due à une forte consommation de Shinken-Broker. Ce rôle étant primordial pour la visibilité (Logs, Livestatus, NDO, Gra- phiques, etc…), le fait que le processus soit tué par un manque de mémoire est relativement gênant.
De plus, deux versions bugfixes sont venues corriger des bugs importants (pour la génération de log et l’ordonnancement ainsi que pour les downtime) et en apporter d’autres.
Au niveau comportement des Pollers, l’utilisation d’agentless consomme beaucoup de ressources au niveau CPU et peu au niveau RAM.
La compatibilité entre Centreon et Shinken est aussi un facteur bloquant car il empêche de distribuer la charge sur plusieurs serveurs car dans la vision Centreon, un Poller représente les rôles d’Arbiter, Scheduler et Broker au minimum et comme ce dernier est le plus important pour dialoguer avec Centreon, il peut difficilement être séparé des autres.

Conclusion et direction prise :

La maquette a été réalisée sur un nombre peu important de services (env. 2300) et la consommation de mémoire était trop importante pour monter au delà. De plus, les deux versions bugfixes ont été sorties avec très peu de temps entre les deux car la 1.2.3 introduisait un bug critique.
Cette situation devenant plus que gênante, j’ai migré la maquette vers Nagios (avec sa RAM divisée par 2) et optimisé ma configuration et mon architecture pour supporter l’utilisation en environnement virtualisé avec les éléments suivants:

  • Utilisation de RAMDISKs.
  • Mettre en mémoire certaines tables NDO.
  • Utilisation de mod_gearman pour déléguer les exécutions des checks à des workers dédiés.

Au passage j’ai rajouté un Poller pour absorber la charge d’exécution et j’ai les indicateurs suivants:

  • Nombre d’hôtes: 630.
  • Nombre de services: 5069.
  • Latence: 0,4s.

Les serveurs Centreon et Nagios sont très peu chargés et avec des workers supplémentaires bien dimensionnés, il peuvent accueillir une charge bien plus grande.
G. LE BRIS