Exporters : détecter les micro-incidents pour améliorer la performance de stockage

L’opensource, la transparence et l’infrastructure sont trois notions intrinsèquement liées chez Gandi. L’un de nos objectifs récents était de détecter plus vite et mieux des problèmes localisés, impactant la qualité de service que l’on propose à nos utilisateurs.

Nicolas Belouin, ingénieur Système dans l’équipe Hosting, a développé des outils pour améliorer le suivi des performances des unités de stockage chez Gandi. 

Pour les plus intéressés, ces développements sont open source et disponibles sur le github Gandi.

Rappel de l’organisation de l’infrastructure de stockage chez Gandi

L’infrastructure de stockage Gandi est composée de 2 environnements : un pour le IaaS, un pour le PaaS. Tous deux sont basés sur des unités de stockage (= filers) à base de FreeBSD, qui vont stocker chaque volume (disque) client comme étant un volume ZFS.

Pour l’exposer aux utilisateurs, il existe deux méthodes différentes :

• Pour le Cloud (IaaS) Gandi utilise du iSCSI. Cela nous permet d’exposer directement un volume de type « block » à l’utilisateur. De cette manière, nos clients peuvent utiliser leur volume comme bon leur semble. Sur FreeBSD, le service (démon) qui gère cela se nomme « CTLD ».

• Pour Simple Hosting (PaaS), Gandi a fait le choix d’exporter via NFS un système de fichiers qui est mis à disposition de l’utilisateur. Ici, nous utilisons « Ganesha » comme démon NFS.

Pourquoi avoir été amenés à travailler sur ces exporters ?

Pour la maintenance des différents services (CTLD ou Ganesha), Gandi avait déjà les outils permettant de détecter un incident majeur (exemple : « l’unité de stockage ne répond plus »). Par contre, il n’existait pas de solution simple pour détecter des incidents localisés ou mineurs (exemple : « dégradation de la performance d’une unité de stockage »). Il fallait un système nous informant d’une baisse anormale de la quantité de données client qui transitent, et donc de la probabilité d’un incident. Pour le moment l’objectif est de pouvoir détecter le moment où il y n’a plus de lectures/écritures sur l’unité de stockage. Le démon est encore actif, mais dans un état instable.

Bien entendu, nous ne surveillons pas directement chacun des volumes d’un filer car le client peut avoir un volume sur lequel il ne fait rien. Le monitoring est fait à l’échelle du filer si le taux « d’actions » diminue à un niveau trop bas, ou de façon trop brusque.

Et c’est bien là le but de ces exporters Ganesha et CTLD : permettre de détecter mieux et plus rapidement les problèmes localisés, afin d’améliorer la qualité de service que l’on propose à nos clients.

S’ajoutent à cela quelques effets bonus :

• Avoir une vision plus fine de la capacité de nos filers
• Récupérer facilement certaines métriques qui étaient plus complexes à avoir avant, comme le nombre précis, et en quasi temps réel, de volumes en cours d’utilisation sur un filer
• Prévoir plus rapidement quand un filer arrivera à saturation

Enfin concernant le choix des exporters, il s’agit d’exporters Prometheus car c’est la technologie utilisée en interne chez Gandi. 

Comment fonctionnent les exporters ?

Tous les exporters réalisés sont codés en Golang. Ce langage est compilé statiquement et permet d’avoir un déploiement simplifié. Il dispose d’une bibliothèque native de Prometheus et s’intègre donc facilement avec d’autres technologies pour aller interroger les démons.Dans le cas du serveur NFS Ganesha, l’intégration est relativement simple en utilisant D-Bus pour exporter les statistiques.

Pour CTLD, l’exporter utilise des appels systèmes pour obtenir les informations.

Concrètement les exporters fonctionnent tous les deux sur le même principe : ils vont créer un serveur HTTP sur un port particulier et normalisé. Le projet Prometheus a une page wiki où chaque créateur d’exporter va enregistrer le port qu’il utilise pour son projet afin de coordonner la communauté.

De cette façon, il écoute sur ce port « réservé ». Quand il reçoit une requête, il va interroger le système sous-jacent (Ganesha ou CTLD) en demandant les statistiques puis en les formatant et en les renvoyant au demandeur.

L’exporter est installé sur toutes les unités de stockage et il dialogue sur le port standardisé sélectionné.

La donnée est renvoyée au démon Prometheus, qui récupère régulièrement une liste d’adresses réseau à collecter. Il va aller interroger l’ensemble des filers pour récupérer les données sur toute l’infrastructure de stockage.Enfin, ces données sont affichées sur notre Grafana, qui permet aux équipes d’avoir des tableau de bord visuels.

Nous travaillons maintenant sur l’affinage des seuils pour déclencher des alertes. Depuis leur mise en place il y a 3 mois, cela a déjà beaucoup aidé à l’analyse d’incidents.

L’exporter Xen

L’équipe Hosting a aussi travaillé sur un exporter Xen, pour améliorer le suivi de l’utilisation des serveurs « Host » utilisés pour nos solutions PaaS et IaaS. Nous disposions déjà de données concernant les VMs, entre autres pour faire notre service de facturation des ressources Cloud, mais nous n’avions pas suffisamment de données concernant l’état de santé de nos serveurs Host.

Pour des enjeux de sécurité, Gandi n’utilise plus d’Hyperthreading sur les processeurs de son parc IaaS. Nous avions besoin de suivre les performances de façon plus précise afin d’en mesurer l’impact.

Le rôle de l’exporter Xen c’est de remonter toutes les données concernant le Host et les VMs. 
Il y a un bien exporter Xen qui existe, mais il est pour Xen server (la version commerciale de Xen distribuée par Citrix) alors que nous on utilisons libXL qui est l’interface bas niveau de Xen.

Nous avons donc développé l’exporter Xen Exporter pour s’interfacer avec cette interface bas niveau.

Cet exporter a aussi été conçu en Go, car Xen fournit des interfaces Go pour la libXL. Cette interface, bien qu’actuellement assez limitée, est suffisante pour les besoins de l’exporter. 

Dernière précision pour ceux succeptibles de vouloir l’utiliser, le Xen exporter ne compile pas aujourd’hui avec un Xen standard car il requiert certains ajouts que nous avons proposés au projet Xen, qui sont en attente d’être publiés.

Les projets de Gandi sur github

• Xen exporter : https://github.com/Gandi/xenlight_exporter
• CTLD exporter : https://github.com/Gandi/ctld_exporter
• Ganesha exporter : https://github.com/Gandi/ganesha_exporter

L’opensource fait partie de l’ADN de Gandi

En rendant nos projets publics, d’autres sociétés ou individus ayant la même problématique pourront utiliser ce travail et contribuer à l’amélioration des fonctionnalités. Un autre objectif est de construire une communauté de contributeurs qui permette au projet de continuer à vivre indépendamment de Gandi.

De manière générale, sur ces exporters, nous avons essayé d’être toujours au plus proche de ce qui se fait communautairement. On trouve beaucoup d’exporters sur internet qui ne respectent pas forcément ces règles, ce qui ne facilite pas le réemploi et le partage.

C’est pourquoi pour que ce soit facile à être ré-utilisé, Gandi a cherché à être le plus standard possible, et à toujours garder une notion de flexibilité (de manière à ce que ce soit pas spécifique à la manière dont on utilise CTLD ou Ganesha).

Glossaire

• NFS : Network File System, système d’export sur le réseau de système de fichier. Voir https://fr.wikipedia.org/wiki/Network_File_System.
• ZFS : Zettabyte File System, système de fichier. Voir https://fr.wikipedia.org/wiki/ZFS.
• iSCSI : Internet Small Computer System Interface. Voir https://fr.wikipedia.org/wiki/ISCSI.
• CTLD : CAM Target Layer Daemon, logiciel dans FreeBSD permettant de gérer les connections ISCSI. Voir https://www.freebsd.org/cgi/man.cgi?query=ctld&sektion=8&manpath=freebsd-release-ports.
• Ganesha : serveur NFS en espace utilisateur. Voir https://nfs-ganesha.github.io/.
• FreeBSD : système d’exploitation BSD. Voir https://www.freebsd.org/.

Des questions à poser à l’équipe Hosting ? N’hésitez pas à laisser un commentaire sous cet article ou contactez notre équipe sur https://help.gandi.net !

Découvrir les offres d’hébergement Gandi

Tagged in CloudSimple Hosting