Depuis octobre 2003, je suis très fortement impliqué au niveau national dans deux projets d'envergure auxquels participent les équipes RESO et REMAP du LIP. Il s'agit d'une part du projet Data Grid Explorer de l'ACI MD Masses de Données et d'autre part du projet GRID'5000 de l'ACI GRID. L'objectif de Data Grid Explorer est la mise en oeuvre d'un grand instrument d'émulation de grilles et de réseaux pair-à-pair pour permettre aux diverses communautés du domaine de mener des expériences grandeur nature. GRID'5000 vise à la réalisation d'une grille expérimentale à l'échelle nationale composée d'une douzaine de sites géographiquement répartis en France, chaque site devant à terme être équipé d'une grappe d'au moins 256 processeurs. J'ai participé à l'ensemble des réunions nationales de ces deux projets et je suis membre du comité technique national de GRID'5000. J'ai été impliqué dans la rédaction des appels d'offres visant à l'achat du matériel pour ces deux projets et en particulier dans les choix des équipements du pôle lyonnais de GRID'5000 qui a été financé pour un montant supérieur à 150Keuros lors de l'appel à proposition 2003. D'autre part, je suis responsable pour le pôle lyonnais dans le cadre de GRID'5000, de la mise en place d'un prototype de grille expérimentale entre une dizaine de sites permettant de faire des études de faisabilité, de sécurité et d'évaluation de performances qui orienteront les décisions futures concernant la mise en place de la future grille expérimentale nationale. Enfin, dans le cadre de Data Grid Explorer, je co-encadre, avec Pascale Vicat-Blanc Primet, un étudiant de l'Ecole Centrale de Lyon pour son projet de fin d'études. Son travail consiste à étudier et à intégrer les différents outils permettant d'émuler de manière flexible et précise un nuage réseau de grille pour l'évaluation des performances des transferts de données d'un nombre important de processus clients. Il devra aboutir à la conception d'un outil logiciel complet qui sera à terme intégré à la plate-forme Data Grid Explorer et qui permettra l'émulation de réseaux dans un contexte haute-performance et grande échelle.
Mes recherches actuelles concernent différents aspects des systèmes d'exploitation et des réseaux : elles visent à l'optimisation des couches de communications se trouvant à l'interface entre les applications et le matériel réseau et ce, dans le contexte des grappes de PCs ou des grilles de calcul. Dans les grappes ou les grilles de calcul haute-performances, les mécanismes de communication sont souvent implantés de manière très efficace au niveau du matériel réseau. L'objectif est de faire bénéficier les applications de la très faible latence matérielle et des très haut-débits fournis par ce type de réseau rapide, en minimisant le temps de traversée des couches logicielles qui sépare l'appel à une primitive de communication au niveau applicatif de la prise en compte du transfert par le matériel réseau. Je me suis donc assez naturellement inséré dans les travaux de l'axe 1 de RESO visant à proposer des optimisations locales pour le traitement des communications dans les systèmes d'extrémités : grappes de PCs, serveurs, noeuds de calcul communicants... Ces travaux s'inscrivent en particulier dans le cadre de la thèse de doctorat de Brice Goglin que je co-encadre avec Pascale Vicat-Blanc Primet depuis octobre 2003, suite au départ de Loïc Prylli qui a co-encadré Brice en 2002/2003 pendant sa première année de thèse. Le but est d'étudier et de proposer des optimisations dans la distribution de fichiers à travers une grappe de PCs disposant d'un réseau de communication rapide tel que Myrinet. En effet, dans ce type d'infrastructures, les applications nécessitent un accès performant aux fichiers distants et rendent difficile l'utilisation de protocoles usuels tels que NFS. Plusieurs projets tels que PVFS, GPFS et Lustre ont été proposés pour subvenir aux grands besoins des applications parallèles en terme de stockage de données. Ils se basent sur la répartition de la charge de travail et des données sur différents serveurs pour supporter le passage à l'échelle, en particulier en terme de nombre de requêtes adressées au(x) serveur(s). Mais, ils ne profitent pas efficacement du matériel réseau très performant qui est disponible dans les grappes. Nous nous intéressons à l'optimisation de l'accès aux fichiers distants en cherchant à utiliser au mieux ce réseau haute-performances pour transférer les données entre un système de stockage distant et les applications clientes. Les réseaux rapides tels que Myrinet disponibles dans les grappes de PCs disposent au niveau matériel d'une primitive d'écriture en mémoire distante performante. Le contrôleur réseau accède directement à la mémoire physique (DMA) sur le noeud émetteur et sur le noeud récepteur pour transférer les données. Il est donc nécessaire d'effectuer des conversions d'adresses (virtuelles/physiques) lors du transfert des données. Pour répondre aux exigences de performances des applications, une méthode maintenant classique est d'utiliser une bibliothèque de communication (telle que GM fournie par la société Myricom) se chargeant de poster/recevoir les ordres d'écritures distantes et permettant des communications en mode utilisateur de type zéro-copie : lors du premier transfert, les tampons de communication de l'application sont vérouillés en mémoire physique et les correspondances entre les adresses virtuelles et physiques des tampons sont stockées dans un cache d'enregistrement mémoire (souvent implanté dans la carte d'interface réseau) ; lors des communications suivantes impliquants ces mêmes tampons, l'application se contente de fournir l'adresse virtuelle du tampon d'émission ou de réception impliqué dans le transfert. La performance des couches de communications logicielles est assurée non seulement par des transferts directs depuis le tampon d'émission vers le tampon de réception sans copie intermédiaire des données de l'application, mais aussi par la non-traversée du système d'exploitation dans les phases de communication. Dans le cas d'un système de fichiers distribués, notre première idée a été d'utiliser le chemin le plus rapide entre un programme utilisateur client et les données stockées sur un serveur distant : communications en espace utilisateur, pas de passage par le système d'exploitation, pas de cache sur le client. Une liaison haute performance est ainsi réalisée entre les tampons de l'application utilisateur sur la machine cliente et le système de stockage sur la machine serveur, par exemple des disques durs. Dans un deuxième temps, nous nous sommes rendu compte que la suppression du cache côté client, en particulier pour les méta-données (attributs des fichiers distants), est néfaste pour les performances de certaines applications. Par ailleurs, nous souhaitons conserver la transparence d'accès au système de fichiers distants qui permet son utilisation par n'importe quelle application cible sans nécessité sa réécriture ou sa recompilation. Cela était la motivation principale d'implantation du client NFS dans le système d'exploitation. Nous avons donc décidé de déporter l'implantation de notre client de système de fichiers distribués dans le noyau Linux afin de faire bénéficier aux applications, quand cela est nécessaire, de la transparence et des caches déjà fournis par le Virtual File System (VFS). Cette décision n'est pas sans soulever certains problèmes dans la mesure où les interfaces de programmation des réseaux haute-performances disponibles dans les grappes n'ont pas été prévues pour des communications entre l'espace noyau (côté client) et l'espace utilisateur (côté serveur) : elles ont été optimisées pour des communications entre espaces utilisateur comme nous venons de l'expliquer. Il s'agit en particulier de proposer des mécanismes permettant une gestion efficace des opérations d'enregistrement ou de désenregistrement mémoire qui sont très coûteuses et qui supposent d'être informé depuis le système d'exploitation des éventuelles modifications des espaces d'adressage des processus impliqués dans les communications. Dans le cas des accès bufferisés, les données transitent par le "buffer cache" qui est déjà verrouillé en mémoire physique et dont les adresses physiques sont connues. Il s'agit alors de permettre le transfert de ces données en fournissant directement au contrôleur réseau les adresses physiques des zones à transférer. Last modified: |