Articles

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 du mois de Mai

 

Sorties

Informations

Lectures

Consultant supervision

Consultant Junior en Supervision Open Source

Missions

Nous recherchons un(e) Consultant Junior en Supervision souhaitant développer ses compétences dans le domaine et ensuite et nous accompagner nos clients sur toute la chaîne de valeur du projet (conseil, intégration, outsourcing).

 

Après une formation complète à nos méthodes et outils, vous porterez l’offre de services de Somone  en partenariat avec un consultant confirmé :

 

  • Mise en œuvre de solutions de supervision Open Source
  • Définition d’architecture et rédaction de propositions techniques.
    Missions de conseil et de support avancé autour des solutions de supervision,
  • Participation à l’avant-vente
  • Participation à notre veille technologique ainsi qu’à l’évolution de notre offre technique et de notre méthodologie
Votre profil

De formation supérieure en informatique, bac+4/5 idéalement systèmes et réseaux, vous avez une expérience en supervision d’au minimum 3 mois (inclus stage).

Vous connaissez une ou plusieurs solutions telles que :

è Open Sources : Nagios, Centreon, ZenOss, Zabix, Hobbit, Big Brother, Shinken…

 

Vos connaissances générales en informatique :

  • Maîtrise des systèmes Linux / Unix
  • Connaissance du Shell (Bash) ou autres langages de script (Bash, Perl, Ruby, Python…)
  • Compétences en technologie web (html, php, javascript, ajax, …)
  • Connaissance du protocole SNMP
  • Etc.

Un anglais de bon niveau professionnel est requis.
Toutes les autres solutions connues en supervision seront un plus dans votre candidature.

Les qualités recherchées sont l’autonomie, un bon relationnel, la curiosité, l’ouverture mais aussi la qualité de service, la persévérance, la rigueur.
Chaque collaborateur est attaché à un manager technique, pour lui assurer un suivi RH de qualité et non orienté business.

 

Cliquez ici pour postuler !

Déposez-nous votre CV

Votre nom*

Votre email*

Intitulé de l'offre

Votre CV (au format PDF)*

Votre lettre de motivation (au format PDF)

Merci pour votre confiance !

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!

Somone: News du mois de Mai

Sorties

Salons

Lectures

News du mois de Mars…

Sorties

Informations

Lectures

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