Catégorie regroupant tous les sujets de veille technologique

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

teem

Innovation : la révolution TeeM E-Control

Madame, Monsieur,

SOMONE,
Partenaire agora du CRIP depuis 2012,
Société OSEO Excellence,
Jeune Entreprise Innovante,
société retenue par Pacte PME,
société retenue par PM’Up,
a investi sur l’année 2013 pour répondre de manière innovante à des problématiques actuelles:

  • Le besoin énoncé par vos clients (internes ou externes) d’être rassurés sur votre maîtrise des applications et de leur disponibilité
  • Les fortes attentes client sur le sujet de l’innovation efficiente, notamment sur le thème de la supervision qui reste bien souvent une « boîte noire » dont les seules maîtrise et visibilité reviennent aux équipes supervision et pilotage
  • Le sujet de la mobilité, qui n’est pas un gadget mais une réelle réponse à un besoin de maîtrise de l’information « anytime, anywhere, any device »
  • Vos propres remontées concernant les coûts élevés de licences et la complexité de certains produits pour répondre à des besoins qui pour vous semblent évidents

De ces problématiques est née la solution E-Control, que nous vous laissons découvrir dans l’image ci-dessous:

E-Control

L’accent premier a été porté sur la réponse aux 3 premières problématiques:

L’outil vous fournit une vue simple d’utilisation, esthétique et pertinente des applications de votre SI et des couches qui la composent,
L’outil s’adresse autant aux responsables de supervision et aux équipes pilotage, qu’aux managers, responsables d’équipes applicatifs, responsables de production, clients, etc.
La solution suit bien les différents préceptes de la mobilité.

Les fonctionnalités du produit sont nombreuses:

  • Facilité de connexion à différentes sources de données en fonction de vos besoins (supervision, hypervision, gestion d’incidents …)
  • Valorisation des cases par répartition des états instantanés 100% paramétrable
  • Gestion des états « non-supervisés » dans l’interface (Afin de maîtriser les faiblesses de votre SI)
  • Affichage et gestion des criticités des applications
  • Possibilité de décrire les applications de manière simple et visuelle dans l’interface
  • Fonctionnalités de tri
  • Gestion de groupes d’applications arborescente
  • Création de « vues différenciées » reposant sur des profils différents (afin que chacune de vos équipes ou de vos clients ne voient que leur périmètre)
  • Possibilités de différents niveaux de vues : Groupes, toutes les applications, uniquement les applications d’un groupe
  • Vues multiples du bac à événements : juste les alarmes contenues dans une case de la matrice, la totalité des alarmes d’un groupe ou d’nue application, la totalité des alarmes d’une couche
  • Possibilité de rendre visible/invisible les applications dans l’interface (pour les applications que vous souhaiteriez ne pas voir apparaître
  • Import simplifié de la liste des applications et des couches

Et bien d’autres à venir.

SIMPLICITÉ. INNOVATION. PERFORMANCE. MOBILITÉ. VUE SERVICE.

E CONTROL

 

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