Jour 3, Vendredi 22 Juillet: Conférences

Le vendredi 22 juillet, c'était mon anniversaire. Pour mes 22 ans le 22 juillet, j'étais donc à Ottawa autour de nombreux hackers du noyau Linux. Pour l'anniversaire d'un geek, que demander de mieux ?

Linux Virtualization on Virtual Iron Vfe

Pendant cette journée de vendredi ont eu lieu dans la plus grande salle de conférences un ensemble de conférences sur le thème de la virtualisation, certainement LE thème de cette année. Des présentations de sur Virtual Iron, Xen ou UML, ainsi qu'un atelier sur le sujet.

Pour ma part, je n'ai assisté qu'à la première présentation de la journée, sur Virtual Iron. C'était la seule conférence qui m'intéressait à cette heure-là, donc c'est un peu à défaut que je suis allé la voir.

Une église d'Ottawa au clocher métallique

Virtual Iron est un produit propriétaire, qui se propose de résoudre les problèmes de gestion des datacenter. Ceux-ci, constitués de dizaines, ou plutôt centaines de machines sont complexes, coûteux et surtout difficile à gérer. Virtual Iron propose de virtualiser toutes les ressources, à la fois de stockage, de mémoire et de réseau, pour faciliter leur gestion. Le datacenter est alors vu comme un ensemble de ressources, et Virtual Iron permet de créer, configurer et déployer des serveurs virtuels puisants dans les ressources du datacenter. Pour les applications, Virtual Iron est transparent, elles ont simplement l'impression de tourner sur une machine multi-processeur.

J'ai beaucoup de notes au sujet de cette conférence, mais elles sont finalement assez floues. Je vais tâcher d'en extraire quelque chose de cohérent.
Leur système, appelé CVMM (Clustered Virtual Machine Monitor), permet de créer un espace d'adressage mémoire logique unique et uniforme à partir de plusieurs machines, de manière indépendante du type de réseau utilisé. Le modèle de virtualisation utilisé, dit hybride, permet aux applications utilisateur de fonctionner comme d'habitude avec un niveau de protection 3 (le niveau le plus faible sur les processeurs type Intel). Sur chaque machine fonctionne en niveau de privilège 0 un Virtual Machine Monitor. Le noyau Linux, lui, tourne en niveau de privilège 1 (alors que sur une machine classique il tourne en niveau de privilège 0).

CVMM doit virtualiser 4 entités :

• le processeur
  Virtual Iron virtualise les processeurs physiques : le noyau hôte n'a accès qu'à un processeur virtuel, géré entièrement par Virtual Iron. Un processeur virtuel est en réalité un thread tournant sur un processeur physique, CVMM s'occupant d'ordonnanceur ces processeurs virtuels.
  
• la mémoire
  En terme de mémoire, CVMM gère les tables de pages, auxquelles le système fonctionnant dans le serveur virtuel n'a pas accès. CVMM s'occupe donc de migrer les pages sur le noeud où elles sont nécessaires, sauf les pages en lecture seule qui peuvent être dupliquées sur différents noeuds.
  
• les interruptions
• les périphériques d'entrées-sorties

Pour faire fonctionner le noyau Linux au dessus de CVMM, il a fallu effectuer diverses modifications de ce dernier. Le portage a été effectué comme une sous-architecture de l'architecture i386.

• remplacer les instructions priviligées, puisque le noyau Linux tourne en niveau de privilège 1
• modifier l'interface avec la MMU, qui modifie des tables de pages virtuelles, gérées par CVMM. Le noyau n'a pas accès aux tables de pages réelles, afin - de garantir l'isolation des différents serveurs virtuels
• modifier la gestion des interruptions
• permettre aux processeurs de fonctionner à des fréquences différentes, puisque les processeurs virtuels sont hébergés sur des processeurs physiques de vitesses différentes
• des périphériques d'entrées-sorties virtuels: console virtuelle, interface réseau virtuelle et connexion Fibre Channel virtuelle
• la gestion du temps, qui nécessite de partager la variable jiffies (compteur du nombre d'interruptions horloge) entre tous les noeuds
• de nombreuses optimisations, détaillées dans le papier : optimisation des spinlocks, mécanisme de duplication dans le page cache, etc..
• le support pour l'ajout de processeur, de noeuds ou de mémoire à chaud

La conférence rentrait dans des détails assez techniques, et montrait que les développeurs avaient une bonne connaissance des problématiques du distribué, et avaient résolu un certain nombre de problèmes de performances liés à la distribution. Toutefois, les détails étaient parfois un peu trop techniques, et à mon sens pas suffisamment expliqués pour être réellement compréhensibles, ce qui était peut-être également dû à l'accent anglais de l'orateur.

dmraid – Device-Mapper RAID tool

La présentation de a été réalisée par Heinz Mauelshagen, qui travaille chez RedHat.

Le noyau 2.6 propose un système appelé device mapper, dont nous avons déjà parlé dans le compte-rendu de la conférence sur le multipathing. Device mapper permet sur des périphériques blocs (des disques, notamment), de mapper des blocs virtuels sur des blocs physiques en utilisant différentes méthodes. Cela permet notamment l'implémentation des différents RAID: RAID0 (linéaire), RAID1 (mirroring), RAID5, etc.

Dmraid est un projet visant à utiliser device mapper pour supporter les contrôleurs ATA RAID, de marque HighPoint, Via, nVidia ou Promise, par exemple. Ces contrôleurs RAID sont parfois disponibles par défaut sur des cartes mères et sont des contrôleurs bas de gamme.

Dmraid permet de lire et d'écrire les métadonnées dans les contrôleurs RAID, dont le format varie d'un contrôleur à un autre, et de convertir ces métadonnées dans le format générique utilisé par device mapper. Ceci permet de réutiliser le maximum de code de device mapper, contrairement à ce qui se pratiquait dans le noyau 2.4, où chaque chipset ATARAID avait un support bas niveau différent.

D'après ce que j'ai compris, Dmraid est surtout une bibliothèque utilisateur de traduction de méta-données. Par contre, je n'ai pas bien compris quel était le rôle exact du contrôleur et le rôle exact de device mapper au sein de dmraid. Au départ, j'avais compris que c'est device mapper qui faisait la conversion bloc logique vers bloc physique, comme pour du RAID purement logiciel. Mais dans ce cas, à quoi sert le contrôleur RAID ? En réalité, il semblerait que le contrôleur RAID soit capable de réaliser cette traduction bloc logique vers bloc physique, mais qu'il faille lui donner les tables de conversion, et que device mapper est utilisé pour cette opération. Cela reste néanmoins à vérifier, et la lecture du papier ne m'a pas plus éclairé sur le sujet. J'ai également cherché les spécifications de quelques contrôleurs ATARAID, mais n'ai pas trouvé d'informations concluantes.

Si vous savez comment fonctionnent ces contrôleurs et quel est leur rôle exact, je suis intéressé.

Active Block I/O Scheduling System (ABISS)

La conférence sur ABISS a été donnée par un des ingénieurs de Philipps travaillant sur le projet. Les transparents de la conférence sont disponibles.

Comme l'indique le site Web, ABISS (Active Block I/O Scheduling System) est une extension du sous-système de gestion des entrées-sorties de Linux dont l'objectif est de permettre d'offrir des débits garantis en lecture et en écriture aux applications ainsi qu'une latence d'entrées-sorties bornée. Pour cela, les applications doivent informer ABISS de leurs besoins en entrées-sorties, et ABISS détermine si il est posisble de garantir des performances correspondant aux besoins.

Sans ABISS, les délais d'entrées-sorties ne sont pas bornés et ne sont pas prédictibles, et les applications ne peuvent donc pas dimensionner correctement leurs buffers. Placer des priorités sur les entrées-sorties ne suffit pas, car il y a un risque de famine et il est difficile de garantir l'équité pour les entrées-sorties de faible priorité.

ABISS peut être utile dans un contexte temps réel, comme par exemple la lecture ou l'enregistrement de flux audio ou vidéo. Il peut également être utile dans les systèmes où les ressources sont limitées. Il permet de combiner des flux temps réel avec des flux au meilleur effort (best effort), pour par exemple lire ou enregistrer de la vidéo en temps réel tout en réalisant des copies de fichiers en arrière plan. Pour permettre cela, ABISS doit éléminer le maximum d'attentes dans le système.

En lecture, la plus grosse attente est bien sûr la récupération des blocs depuis le disque. Pour éliminer cette attente, ABISS récupère à l'avance les blocs nécessaires (prefetching). L'idée est similaire au read-ahead classique, mais la réalisation est beaucoup plus pointue: lors de l'ouverture d'un fichier, ABISS consulte la liste des blocs de celui-ci. Ainsi, le prefetching s'effectuera réellement sur les prochains blocs du fichier, et non simplement sur les blocs adjacents sur le disque comme cela fonctionne avec le read-ahead classique. D'autre part, les blocs récupérés en avance sont bloqués en mémoire, afin de garantir à l'application qu'ils seront disponibles à temps. Dans ABISS, c'est un thread noyau qui s'occupe de récupérer ces blocs et de les placer dans le playout buffer.

De plus, les requêtes d'entrées-sorties disque disposent de priorités, afin de limiter la durée du temps pire-cas durant le prefetching. L'ordonnanceur des requêtes peut réordonnancer les requêtes seulement au sein d'un même niveau de priorité, et doit traiter les plus prioritaires d'abord. Toutefois, si les requêtes de haute priorité (temps-réel) sont trop nombreuses, elles peuvent fortement diminuer la performance des entrées-sorties en meilleur effort (best effort), en causant des allers-retours incessant de la tête de lecture, comme le montre le 12ème transparent.

Il est donc nécessaire de regrouper les requêtes de haute-priorité en réalisant ce que le développeur d'ABISS appelle le batching et le synchronizing. Le batching consiste à attendre qu'un certain nombre de requêtes d'entrées-sorties arrivent avant de les effectuer réellement, ce qui permet de les regrouper. Le synchronizing consiste à prendre en compte les requêtes d'entrées-sorties à haute priorité qui sont concurrentes pour les ordonnancer dans un ordre efficace.

Pour l'écriture, le principe du prefetching est également utilisé: au moment de l'écriture, le bloc à écrire est déjà en mémoire, et l'écriture peut avoir lieu. Si un bloc a besoin d'être alloué sur le disque, alors l'allocation est reportée à plus tard: les données sont simplement copiées dans le page cache. Ces pages du cache pour lesquelles la position sur le disque ne sont pas connues sont marquées du drapeau PG_delalloc.

Une rencontre inédite avec un animal d'espèce indéterminée

Un thread noyau s'occupe d'écrire les pages du cache sur le disque. Si la page est marqué du drapeau PG_delalloc, alors le thread sait qu'il faut allouer un bloc sur le disque. Tout ceci s'effectue donc en dehors du chemin critique de l'application. Toutefois, le problème est que l'allocation du bloc sur le disque peut échouer si il n'y a plus de place sur le disque. Or, au moment où l'allocation a lieu, on ne peut plus remonter l'erreur à l'utilisateur. C'est la raison pour laquelle les développeurs d'ABISS envisagent d'utiliser les nouveaux mécanismes d'allocation déportée de ext3 qui ont été présentés dans le compte-rendu de la conférence consacrée à ce système de fichiers.

Le 17ème transparent présente les différents composants intervenants dans le système ABISS. En particulier, un démon utilisateur abissd s'occupe de gérer les ressources, c'est-à-dire de déterminer si il est possible de répondre aux besoins d'une application. L'application, directement au travers d'une interface de type ioctl ou au travers de la bibliothèque libabiss peut indiquer ses besoins en terme de débit.

Le présentateur a ensuité réalisé une petite démonstration en direct d'ABISS. La démonstration était extrêmement bien préparée: en lançant un simple script shell, il a d'abord montré le comportement d'un ordonnanceur d'entrées-sorties classique: il n'y a aucune garantie sur la durée des entrées-sorties. Ensuite, il a répété la même chose avec l'ordonnanceur ABISS, et l'aperçu des graphiques étant sans appel: la durée des entrées-sorties était quasiment constante, et surtout restait bornée, comme le montrent les transparents 20 à 23. J'ai trouvé que la préparation de la démonstration était excellente: les graphiques se construisaient en temps réel devant l'audience, le script shell lançait automatiquement une application, puis deux, puis trois pour montrer l'évolution. Ce n'est pas grand chose, mais une démonstration comme celle-ci est vraiment très efficace !

Pour l'équipe de développement d'ABISS, il ne s'agit pour l'instant que d'une proof-of-concept ayant divers problèmes qui seront prochainement corrigés. Grâce à ces développements, ils ont pu valider leurs hypothèses et leurs idées en ce qui concerne la garantie de débits en lecture et écriture. Le 25ème transparent de leur présentation montre qu'il reste du travail: intégration avec l'ordonnanceur CFQ de Jens Axboe, améliorer l'allocation déportée (en utilisant celle d'ext3), essayer d'utiliser le mécanisme standard de writeback, contrôle dynamique des ressources, etc.

À l'heure actuelle, il s'agit donc plutôt d'un projet de recherche qui n'est pas prêt à être intégré dans la branche officielle du noyau.

Locating System Problems Using Dynamic Instrumentation

Cette conférence était uen présentation de System Tap. Leur papier est disponible.
SystemTap est un mécanisme d'instrumentation dynamique pour le noyau Linux. D'une part, il permet de faciliter le débogage, en évitant au développeur d'avoir à sans cesse recompiler le noyau pour ajouter ou modifier l'affichage d'informations pour déboguer. D'autre part, il permet d'analyser les problèmes de performances du système. SystemTap est prévu pour être utilisable dans un système en production, afin de pouvoir déboguer des problèmes n'apparaissant que dans des conditions particulières.

On peut rapprocher le principe de SystemTap de celui de Dtrace, l'outil de trace dynamique disponible dans Solaris 10 que j'avais évoqué précédemment.

SystemTap repose sur Kprobes, inclus dans le noyau 2.6 depuis le 2.6.9-rc2. Kprobes propose une interface de programmation qui permet d'associer à un point d'instrumentation (probe point) une routine d'analyse (probe handler). Pour cela, le code binaire à l'endroit du point d'instrumentation est modifié dynamiquement afin d'inclure un appel à la routine d'analyse. Ainsi, sans recompilation du noyau, on peut modifier son comportement et ajouter des points d'analyse. Lorsqu'aucun point d'instrumentation n'a été spécifié, le noyau s'exécute sans dégradation de performances, même si Kprobes est activé.

Néanmoins, d'après les auteurs du papier, Kprobes est un mécanisme trop bas niveau pour permettre une instrumentation à la fois simple et sûre du code. SystemTap a été créé pour pallier à ces problèmes.

D'une manière similaire au fonctionnement de DTrace, SystemTap repose sur des fichiers de scripts décrivant l'instrumentation à réaliser. Une fois ce script écrit par le développeur, il est compilé en C, après une phase d'analyse permettant de résoudre les références à des symboles du noyau. Pour cela, les informations de déboguage au format DWARF générées lors de la compilation du noyau sont utilisées. Une fois le code C généré, il est compilé pour former un module noyau. Lors de son insertion, ce module noyau enregistre les points d'instrumentation à partir des informations spécifiées dans le script. Il utilise ensuite un mécanisme de communication noyau vers espace utilisateur afin de faire remonter les traces.

Le papier décrit de manière extensive le langage de script de SystemTap ainsi que les tapsets, des extensions au langage que peut écrire le développeur pour faciliter l'écriture de ces scripts. Ces tapsets sont souvent spécifiques à un sous-système du noyau et peuvent être écrits directement avec le langage de script de SystemTap ou en langage C. La dernière section importante du papier aborde le problème de la fiabilité, très importante lorsque l'on souhaite utiliser SystemTap sur un système en production. SystemTap met en place tout une série de garde-fous pour essayer de s'assurer que l'instrumentation n'influencera pas la stabilité du système en exécution.

L'outil semble donc plutôt convaincant, et sa présentation donnait vraiment envie de l'essayer. J'espère avoir prochainement le temps de tester ça et d'en faire un petit compte-rendu ici.

Flow Based Network Accounting with Linux

Cette conférence était animée par Harald Welte, le développeur principal de Netfilter, le pare-feu de Linux. Il est également très engagé sur le front du respect de la GPL par les entreprises utilisant du Logiciel Libre, au travers du projet Gpl-Violations (voir également cette dépêche LinuxFr ou celle-ci).

En dehors de cela, Harald Welte est un bon orateur. J'avais assisté à une de ses présentations il y a quelques années durant les RMLLs, et bien que le sujet ne m'intéressait pas particulièrement au premier abord, il avait su rendre sa présentation captivante. Il se place au bon niveau technique, compréhensible par le commun des mortels, illustre d'exemple et parle un anglais clair. Cette fois-ci, si j'y suis retourné pour les mêmes raisons: le sujet ne me captivait pas particulièrement, mais les autres conférences au même moment non plus. J'ai donc opté pour celle-ci, connaissant les qualités de présentation d'Harald.

En réalité, je n'ai pas été très attentif pendant la présentation, car je commençais à fatiguer un peu. Pour résumer, la problématique était de pouvoir faire remonter des informations sur les paquets réseau échangés jusque dans l'espace utilisateur, afin de pouvoir réaliser diverses opérations sur ceux-ci : statistiques, comptage, etc.

Une vue de Gatineau, au Québec, depuis Ottawa

Il a tout d'abord présenté les solutions existantes dans ce domaine, à savoir nacctd, ipt_LOG, ipt_ULOG, ipac-ng, ipt_ACCOUNT et ntop, ainsi que leurs problèmes respectifs. Il a ensuite poursuivi en présentant la nouvelle solution qu'il est en train de développer qui repose sur le mécanisme de suivi de connexion existant dans Netfilter. Grâce à ip_conntrack_acct, il maintient des informations (nombre de paquets échangés, nombre d'octets échangés) sur chaque connexion active dans le système. Néanmoins, la lecture de ces informations se faisait pour l'instant uniquement au travers de /proc, en polling, ce qui n'était pas très efficace. En utilisant un mécanisme de notification appelée conntrack notifiers, un mécanisme de communication avec l'espace utilisateur appelé ctnetlink (qui utilise les sockets Netlink) et un démon utilisateur, ulogd2, il est possible de réaliser des statistiques sur les connexions actives. Les différents composants de cette chaîne sont décrits dans le papier, et les patches correspondants commencent à être soumis pour inclusion dans le noyau.

AIO on Linux: Whither to Go From Here ? (BOF)

Cet atelier était animé par Daniel McNeil de l'OSDL et par Suparna Bhattacharya d'IBM. Il concernait l'implémentation des entrées-sorties asynchrones sous Linux. La page Web concernant le support d'AIO sous Linux résume le principe:

En temps normal, lorsqu'une application réalise une opération d'entrée-sortie, la fonction permettant de réaliser l'opération ne retourne que lorsque celle-ci est terminée: elle est synchrone. Avec AIO, il est possible de lancer plusieurs opérations sans attendre leur terminaison, et d'être signalé plus tard qu'elles sont terminées. C'est donc une autre façon de programmer, qui apparemment peut avoir son intérêt pour les applications réalisant beaucoup d'entrées-sorties, comme l'indique cet extrait du papier présenté sur ce sujet en 2003 au Linux Symposium :


La discussion a principalement tourné autour des différentes APIs permettant d'utiliser les entrées-sorties asynchrones sous Linux. Les échanges ont été nombreux, mais très spécifiques, donc difficiles à suivre pour un non-spécialiste du domaine. Je ne pourrais donc pas en dire plus à ce sujet.

Quelques liens:

• API POSIX pour les entrées sorties asynchrones
• API AIO dévelopée par Oracle
• Linux kernel AIO Status/Todo par Suparna Bhattacharya

Linux Cluster Infrastructure (BOF)

Au départ, il ne devait y avoir qu'un seul atelier sur l'infrastructure pour les clusters sous Linux, et suite à un malentendu dans le programme, deux ateliers différents ont eu lieu successivement. Le premier a été animé par Bruce Walker, du projet OpenSSI, un système à image unique pour clusters. Il a rapidement résumé ce qui s'était dit au sujet des clusters au Clustering Summit. La présentation de Bruce Walker ne donnait pas beaucoup de détails: les développeurs de solutions pour clusters souhaitent maintenant mettre en place une infrastructure commune dans Linux pour intégrer leurs solutions. Cette infrastructure permettra aux différentes solutions de partager des composants comme un gestionnaire de verrous distribué, un mécanisme de communication inter-noeuds, un mécanisme de membership, ou d'autres facilités pour les systèmes de fichiers. Il faut donc définir des interfaces pour ces composants, afin qu'ils soient utilisables par tous, et également déterminer quels composants ont leur place dans le noyau, et quels composants doivent rester en espace utilisateur.

Le second atelier a été animé par Daniel Philipps, de RedHat et portait sur exactement le même sujet.

Ces deux ateliers étaient difficiles à suivre: la plupart des gens se connaissaient déjà, et discutaient entre eux, sans vraiment chercher à ouvrir la discussion.

Quelques liens:

• Compte-rendu du Clustering Summit, par Daniel McNeil?
• La liste cluster-sig