Prototypage et mesures de performance sur Grid'5000

Dans ce billet, je tâcherai de présenter Grid'5000, i.e. ses ressources et les outils pour s'en servir, selon l'expérience que j'en ai eue au cours de mon stage 4IF.

1. Contexte du stage
2. Grid'5000 : ressources et outils
3. Grid'5000 comme plateforme de test et environnement de développement

1. Ce dont il s'agissait

Au sein de l'équipe DRIM du LIRIS , j'ai eu deux missions principales, chacune traitant de protocoles de communications anonymes et "accountable", i.e. où le comportement des nœuds participant à la session est contrôlé, sans pour autant compromettre l'anonymat. Ces missions étaient :

1. évaluer les performances d'un protocole existant ;
2. implémenter un nouveau protocole conçu par des chercheurs de Grenoble et de Lyon, dont des membres de DRIM.

Les performances de ces deux protocoles avaient déjà été évaluées par les concepteurs du second, mais par modélisation seulement. Afin de vérifier ces comportements théoriques, la première tâche allait consister à récupérer le code du protocole existant pour le déployer sur un vrai réseau, l'instrumenter puis observer l'évolution du débit et de la latence en fonction de la charge ; la seconde allait être de coder le nouveau protocole pour, à terme, le soumettre à la même évaluation.

Que vient faire Grid'5000 dans tout ça ?
D'une part, le nombre de machines disponibles permet une simulation à grande échelle : la grille représente donc une plateforme de test très intéressante.
D'autre part, les machines pouvant partager le même espace de données, il est possible de déployer le même code sur plusieurs nœuds : Grid'5000 est donc un bon environnement de développement pour prototyper des applications réseau.

2. man grid5000

Avant de m'étendre sur mon utilisation de Grid'5000 dans le cadre de ce stage, voici une brève présentation de la plateforme.

"It is a core, wrapped in a CPU, inside a node, ..."

Grid'5000 est une grille regroupant 21 laboratoires de recherche sur 10 villes différentes.

Un peu de terminologie : chacune de ces villes représente un site. Un site abrite plusieurs clusters :

Un cluster représente un ensemble de machines (ou nœuds) généralement homogènes. On caractérise donc un cluster par les ressources de ces nœuds : par exemple, le cluster Genepi à Grenoble regroupe 34 nœuds sur lesquels tournent deux CPU à 2.5 GHz chacun, un CPU possédant quatre cœurs ; chaque nœud de ce cluster a 8 Go de mémoire vive et une carte réseau 1 GbE.

Un utilisateur possédant un compte sur Grid'5000 a accès à un espace personnel de 25 Go sur chacun de ces sites, auquel il peut se connecter par SSH. Ces espaces ne sont pas synchronisés automatiquement : l'utilisateur doit donc avoir recours à des outils comme rsync s'il souhaite coordonner ses différents espaces.

Ooooh les jolies interfaces web

Le site web de Grid'5000 est riche non seulement en documentation, mais également en tableaux de bord permettant de connaître l'état de la grille, et donc de planifier ses expériences en fonction.
Parmi les différents outils webs disponibles, notons :

• un recensement du matériel disponible, i.e. les ressources (CPU, GPU, mémoire, réseau, espace disque...) des nœuds de chaque cluster ;
• une documentation sur les différents environnements déployables (Debian stable et oldstable) et leurs variantes :
  • min : le minimum de paquets possibles, image la plus légère ;
  • base : comme min, avec des pilotes plus performants pour certains équipements ;
  • nfs : comme base, avec (entre autres) l'espace utilisateur monté en NFS ;
  • ...
• un diagramme de Gantt qui affiche, selon les nœuds, les jobs soumis :
  
• un flux informant des différents événements (pannes, incidents, maintenance, ...) prévus ou venant de se produire ; le flux est lié à une interface de suivi de bugs.

Et sinon, à part les tableaux de bord ?

Ayant vu brièvement la nature des ressources ainsi que certains des outils auxiliaires disponibles, nous allons maintenant passer au cœur des fonctionnalités de Grid'5000 : la réservation puis l'accès aux machines de la grille.

Réservations

La réservation de ressources se fait grâce à l'outil oarsub, une commande du système de ressources OAR qui peut réserver des nœuds à la volée ou à une date donnée selon le souhait de l'utilisateur.
Le job soumis peut être interactif (l'utilisateur devra se connecter au nœud en SSH et soumettre ses tâches) ou passif (l'utilisateur fournit un script à oarsub qui se chargera de l'exécuter sur les nœuds). Plusieurs types de jobs peuvent être spécifiés, tels que deploy pour les utilisateurs souhaitant déployer un environnement spécifique, best-effort pour ceux acceptant que leurs ressources soient réquisitionnées à tout moment, ...
En plus de la durée de la réservation, il est possible de spécifier à oarsub le nombre de ressources souhaitées, à des granularités différentes : cluster, commutateur, nœud, CPU, cœur... ainsi que d'émettre des exigences quant aux capacités des machines à réserver, e.g. sur le CPU, la quantité de mémoire, la présence d'un GPU, la possibilité de mesurer la consommation énergétique...

oargridsub est un programme similaire à oarsub, à ceci près qu'il permet d'effectuer des réservations de nœuds répartis sur plusieurs sites, contrairement à oarsub où les clusters sollicités doivent appartenir au même site.

Gestion des environnements

Il n'est pas rare que les environnements proposés par défaut soient limités au niveau des applications disponibles. Une fois l'environnement déployé, un utilisateur voudra donc se connecter au(x) nœud(s) et y installer des outils nécessaires à ses manipulations : Grid'5000 propose alors à l'utilisateur de sauvegarder l'état de son environnement grâce à tgz-g5k.
Ce programme est capable de créer une image, i.e. une archive contenant le système d'exploitation ainsi que les applications et les changements de configuration mis en place par l'utilisateur, qui a juste à spécifier le nœud dont il souhaite sauvegarder l'état. tgz-g5k créera alors une image capable d'être déployée sur n'importe quel site, et la stockera sur l'espace personnel de l'utilisateur.

Une fois l'archive créée, l'utilisateur pourra gérer ses environnements avec la suite Kadeploy 3. Cette suite logicielle lui permet d'ajouter, de supprimer ou de mettre à jour sa liste d'environnements avec la commande kaenv3, et surtout de déployer des environnements avec kadeploy3, qui peut effectuer efficacement plusieurs déploiements sur un même cluster.

La suite dispose également d'autres outils (kareboot3, kapower3, ...) qui permettent un suivi très fin de l'état des différents nœuds sur lesquels l'utilisateur cherche à déployer.

La suite

Une fois ces outils pris en main, l'utilisateur peut alors mettre en place ses expériences. Les nœuds sont accessibles via SSH, il peut donc s'y connecter directement et piloter le nœud, ou lancer des commandes depuis l'interface du site (i.e. avec ssh -i <key> <user>@<node> <command>). À noter : kadeploy permet de spécifier une clé SSH à ajouter au /root/.ssh/authorized_keys du nœud.

Une fois son travail terminé, s'il a apporté des changements à son environnement, l'utilisateur devra utiliser tgz-g5k puis kaenv3 pour mettre à jour l'image correspondante.

3. "Hey, mais j'pourrais automatiser ça !"

Les objectifs de mon stage énoncés, et l'outil principal examiné, nous pouvons maintenant passer au vif du sujet : l'utilisation de Grid'5000 pour évaluer les performances d'un protocole réseau d'une part, et pour en prototyper un autre d'autre part.

Si les premières expériences que j'ai menées avec Grid'5000 se sont voulues tâtonnantes, avec le temps, l'habitude s'est installée, tant et si bien que progressivement, de plus en plus de tâches liées au déploiement, au lancement des programmes puis à la collecte des résultats, ont pu être automatisées.

Voici donc, en quelques lignes, un résumé de mon utilisation de Grid'5000.

Grid'5000 comme banc de test

La première étape pour tester le protocole existant a été de récupérer, puis d'installer son code sur une machine de Grid'5000, sur laquelle la version nfs de Wheezy a été déployée. Le code compilé et instrumenté (i.e. après avoir ajouté des logs sur l'envoi et la réception de messages), j'ai pu commencer à exécuter le protocole sur quelques machines, coordonnant chacune via un terminal différent, rapatriant les résultats à la main en fin d'expérience...

Très vite, les limites de cette approche fastidieuse se sont fait sentir, surtout une fois qu'il s'est agi de lancer une centaine de clients. launch_nodes.sh est né, dont le rôle a été de :

• créer les futurs dossiers de logs ;
• gérer toutes sortes de paramètres (mode verbeux, mode debug, besoin de déploiement préalable, nombre et taille des messages à faire envoyer aux nœuds, nombre de clients à répartir sur chaque nœud) ;
• déployer (si nécessaire) l'environnement instrumenté sur les nœuds ;
• lancer le protocole en mode client ou serveur selon les effectifs, avec tous les paramètres propres au protocole ;
• attendre (et détecter) la fin de la manipulation ;
• rapatrier les logs de chaque machine ;
• parser ces logs (à l'aide de parse_results.sh) pour mesurer la latence et le débit moyens ;
• écrire un rapport.

Voilà pour ce qui est de lancer automatiquement une expérience, avec un nombre de clients et une charge donnés. Il n'a pas fallu longtemps pour qu'arrive meta_launch.sh, chargé de lancer launch_nodes.sh en faisant varier la charge, puis en regroupant tous les résultats dans un même dossier.

Une fois toutes ces expériences menées, il ne restait plus qu'à récupérer le couple { latence, débit } de chacune, les agréger, puis les utiliser pour générer un graphique.
... D'où parse_reports.sh, qui enregistre tous les couples dans un fichier .csv, et fournit ce fichier à gnuplot qui se charge d'en faire une fantastique courbe latence/débit.

Une fois l'étude des performances du premier protocole terminée (quoiqu'un peu prématurément), il a été temps de passer à la seconde étape : l'implémentation, from scratch, du nouveau protocole.

Grid'5000 comme environnement de développement

N'ayant pas dépassé l'étape du développement des fonctions, je n'ai pas eu l'opportunité d'appliquer la même démarche d'évaluation de performances sur le protocole que j'ai implémenté. En revanche, Grid'5000 s'est révélé être une plateforme tout à fait adéquate pour le développement d'un protocole de communications pair-à-pair.

Concrètement, la possibilité de doter les images de logiciels de contrôle de révisions (e.g. Git) et d'utiliser l'espace utilisateur d'un site comme codebase accessible à tous les nœuds par NFS, ainsi que la présence de toute la chaîne de compilation GNU sur les nœuds fournissent un environnement de développement complet et proche de la plateforme de test.

Au final, je n'ai pas pu tester ce protocole à une aussi large échelle que le premier, en partie parce que mon stage s'est achevé alors que son implémentation était encore loin d'être finie fonctionnellement parlant...

... et en partie, j'imagine, parce que j'ai dû me laisser distraire en route.

En somme

Nous sommes loin d'avoir vu, dans ce billet, toutes les fonctionnalités de Grid'5000 : mon expérience avec cet outil a été somme toute très courte, et mon utilisation sans doute assez étroite par rapport à ce qu'offre cette plateforme.

Tout puissant qu'il soit, Grid'5000 s'adresse principalement à un public d'informaticiens (plus spécifiquement, les chercheurs en informatique parallèle et distribuée à grande échelle), et cela s'en ressent dans la charge d'apprentissage et de développement que l'on attend de l'utilisateur : distinction marquée entre les clusters, cloisonnement des espaces de travail et authentifications séparées entre les sites, ...
Autant d'aspects qui, si ils sont susceptibles de rebuter un utilisateur qui cherche juste à "se brancher à la grille informatique", offrent en fait au chercheur un contrôle très fin des ressources utilisées dans ses travaux.

— Kévin Le Gouguec (kevin dot lg at free dot fr), 20 janvier 2014.