Veille technologique et sorties sur des solutions libres

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