De plus en plus puissants, les supercalculateurs ne suffisent pourtant pas toujours à absorber les besoins des nouvelles applications scientifiques. Dès le début des années quatre-vingt-dix, certains universitaires ont eu une idée astucieuse pour résoudre ce problème : mutualiser la puissance de calcul répartie dans le monde, mais pas forcément utilisée, comme s’il s’agissait d’une seule et gigantesque machine. Cela concerne les ordinateurs, les unités de stockage, les robots, et autres appareils scientifiques (télescopes, etc.) reliés par des réseaux. Un nom pour ce concept : le grid ou la grille, par analogie avec les réseaux électriques (power grids). Lorsqu’on branche un appareil dans une prise électrique, le courant provient des sources disponibles à un moment donné sur la grille. Souvent associés à ce concept, le partage de fichiers en mode peer to peer de Napster, ou le téléchargement d’un programme en économiseur d’écran de SETI@home n’en sont que des sous-ensembles simples.
Des questions complexes à résoudre
La grille devrait permettre de répartir la charge applicative sur un réseau aussi étendu que possible.Mais la maintenance des applications réparties, la sécurisation de l’information et la configuration dynamique de cet “ordinateur géant” sont autant de questions complexes à résoudre. La première exige de mettre au point des applications qui sachent identifier et exploiter au mieux les ressources disponibles. Certains projets en proposent déjà. Parmi les plus avancés, Globus ?” de l’université d’Argonne, en Californie ?” se compose de services articulés autour d’une base d’information des ressources disponibles, elle-même répartie. La Globus Architecture for Reservation and Allocation (Gara) fournit des mécanismes communs de réservation et d’allocation de différents types d’entités distribuées (la machine où se trouve les données, le supercalculateur capable de réaliser l’analyse, les réseaux pour transférer les résultats, etc.) avec, en ligne de mire, la gestion de la qualité de service. Le projet d’Argonne intègre d’autres travaux, tel Condor, mené par des chercheurs en optimisation de l’université de Madison, dans le Wisconsin. “Il existe aussi des freins sociologiques au déploiement de grids. Condor en efface quelques-uns “, explique Jean-Pierre Goux, chef de projet optimisation chez Artelys, qui a travaillé sur la grille dans ces universités. “Une application basée sur Condor prend en compte la présence du propriétaire de la ressource et, surtout, les règles qu’il a définies pour son utilisation : créneau horaire, utilisateurs prioritaires, etc.” Enfin, le projet Master Worker (MW) gère, lui, l’état des différents n?”uds de la grille (en marche, éteints, redémarrage, etc.), ainsi que le démarrage et l’arrêt des tâches en fonction de ces états afin de les redistribuer. “Bien sûr, une forte optimisation est indispensable, insiste Jean-Pierre Goux. Il faut parfois traiter un grand nombre de petites tâches. Une tâche peut en générer quatre nouvelles, qui vont elles-mêmes en générer d’autres. Il faut éviter qu’une tâche qui ne prend qu’une milliseconde effectue un trajet qui lui demandera une seconde…” De plus, cette parallélisation des tâches ne convient pas à tout. Difficile pour le crash-test automobile ou la physique nucléaire, par exemple, constitués de tâches nombreuses et interdépendantes. La grille est une méthode trop massive pour de simples applications industrielles.
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
