Portrait de Philippe PradosPrados.FRProgrammation, architecture & sécurité — depuis 1998

Les technologies GRID

Une exploitation optimum du système d’informations peut être une source de profit ou d’économie pour les entreprises. Les technologies GRID permettent de mutualiser les ressources données ou traitements, afin d’exploiter plus efficacement les serveurs ou les postes de travails, et ainsi, améliorer la productivité ou la qualité des résultats d’analyses. Nous allons effectuer un tour d’horizon des différentes approches permettant d’intégrer dès aujourd’hui ces technologies. Nous identifierons des démarches d’intégrations progressives

Par Philippe PRADOS - 2005
www.prados.fr

Les entreprises doivent développer des initiatives leur permettant de maintenir leurs compétitivités, sans y consacrer des budgets importants. Les automatisations poussées des processus, combinées à la numérisation de plus de plus d’informations, permettent d’espérer la découverte de nouvelles sources de profits, d’optimisation de processus, une meilleure adaptation aux demandes du marché, une meilleure visibilité sur les évolutions à venir, voir une capacité à anticiper les changements. Les entreprises ayant réussi à exploiter au mieux les informations disponibles, à les enrichir ou à les corréler, seront capables de créer de la valeur plus efficacement que leurs concurrents.

De nombreux exemples montrent qu’il existe des analyses pertinentes, insoupçonnées, permettant d’offrir de nouveaux produits sur le marché. Des contrats d’assurances ou des nouveaux produits financiers sont nés d’une étude poussée, de simulations numériques ou d’analyses multidimensionnelles. Des campagnes marketing sont optimisées en exploitant les profils des cibles potentielles. Les exploitations plus fines des modèles numériques permettent de découvrir des améliorations, de nouvelles démarches de conception ou de nouvelles approches commerciales.

Comment justifier des investissements vers ces nouveaux horizons incertains ? Ce n’est pas facile. Souvent, les entrepreneurs savent ce qu’ils doivent faire, mais sont incapables de savoir combien cela coûtera ou si leurs souhaits sont réalisables. Les études théoriques sont d’un faible secours pour faciliter la prise de décisions ou la gestion des risques. Il faut investir une somme raisonnable pour maquetter les différentes idées et pourvoir ainsi, sacrifier une idée pour en exploiter une autre.

Certains projets existent, sont utilisés, mais les résultats sont insatisfaisants. Les temps de calculs les rendent concrètement inexploitables. Leurs complexités ne permettent pas d’en tirer bénéfice. Une meilleure exploitation des ressources devrait permettre d’améliorer la satisfaction des utilisateurs et de rentabiliser les investissements antérieurs.

La loi de Moore, proposée en 1965, indique que les puissances des processeurs doubleront tous les 18 mois. Elle arrive rapidement aux limites technologiques. Nous atteindrons rapidement un mur, nous interdisant d’espérer des machines plus puissantes. Dans quelques années, à moins d’une découverte technologique révolutionnaire, nous aurons atteint les limites de la miniaturisation.

Les besoins de calculs sont de plus en plus importants. Paradoxalement, la plupart des machines sont sous-utilisées. Les mainframes ont une charge moyenne de 40 %, les Unix de 10 % et les PC de 5 %. En effet, les règles de dimensionnement sont surdimensionnées pour pouvoir encaisser les pics de charges. À certains moments de la journée, les machines sont très sollicitées, et à d’autres, elles ne travaillent pas beaucoup. Toutes ces puissances disponibles pourraient permettre d’améliorer les temps ou la qualité des calculs, d’analyser plus finement les informations pour découvrir des niches de profits. Les objectifs à atteindre n’étant pas toujours très clairs, les retours sur investissements ne sont pas calculables. Il n’est pas question d’investir démesurément pour un gain hypothétique. Comment réduire les risques tout en prospectant de nouvelles approches afin de maintenir sa compétitivité ?

Les technologies de grille de calculs cherchent à répondre à cette problématique : mieux exploiter les ressources existantes pour améliorer les processus exigeants ou découvrir de nouvelles applications exploitant mieux les données disponibles. En cours d'analyse, certaines pistes seront abandonnées, d’autres seront approfondies ou découvertes automatiquement.

En utilisant des machines en grille, il est possible de dépasser les limites technologiques. Il s’agit d’organiser l’ensemble des machines d’une entreprise pour permettre l’exécution de traitement là où les ressources sont disponibles. Une sorte d’ordinateur virtuel s’occupe d’exécuter tous les traitements exigeant des ressources importantes en disque ou en CPU.

Pour pouvoir offrir cela, il faut utiliser un ordonnanceur, un moteur d’exécution présent sur chaque machine. Il en existe deux types : les ordonnanceur de tâche pour les traitements rapides d’une durée comptée en secondes ou en minutes et les ordonnanceurs pour les traitements par lots, sans interaction avec l’utilisateur.

Les algorithmes doivent être adaptés à ces technologies pour répartir au mieux les traitements sur tous les nœuds disponibles. Quels sont les algorithmes candidats ? Il en existe de nombreux, dont certains encore insoupçonnés.

Dans l’industrie, les modèles numériques pour construire des voitures ou des avions doivent subir des analyses mathématiques pour vérifier que les pièces n’entrent pas en collision ou ne sont pas trop proches les unes des autres. Pour effectuer ces calculs, il faut comparer chaque pièce avec toutes les autres. Cela prend un temps de calcul très important, exprimé en jours avec des serveurs puissants. En réorganisant les calculs à l’aide de technologies GRID, il est possible de calculer l’intégralité des collisions des pièces d’un véhicule en quatre heures à la place de soixante-douze heures ! Cela a un impact direct sur le processus de conception. Les ingénieurs peuvent, dès le lendemain, corriger les pièces en conflit. Ainsi, le délai pour la mise en production est réduit, apportant un avantage concurrentiel. Pour des raisons pratiques, avant l’utilisation des technologies GRID, aucune voiture dans son ensemble n’avait été calculée. Seules des parties du véhicule avaient subi ces calculs. C’est lors de la réalisation d’un premier prototype que les problèmes furent identifiés. Entraînant, évidemment, des coûts très importants.

Les organismes financiers sont également exigeants en simulation numérique. À l’aide de programmes spécialisés, ils modélisent les interactions des indicateurs financiers (devises, taux d’intérêts), des indicateurs statistiques (mortalités) et leurs différents contrats. En utilisant la méthode Monte-Carlo, proposée par David Hertz du cabinet de conseil McKinsey & Co, ils estiment les risques financiers. (À titre de démonstration, une applet permet d’approcher la valeur de PI.) À l’aide de tirage aléatoire sur la réalisation des différents risques, les assureurs peuvent simuler l’évolution de leurs portefeuilles sur trente ans, et obtenir des courbes de risques statistiques. Plus les simulations sont nombreuses, plus les résultats sont pertinents. Actuellement, pour réduire les temps de calculs, ils extraient des représentants de leurs différents contrats afin de réduire leur nombre. Ils limitent également le nombre d’indicateurs et leurs interactions. L’objectif est d’obtenir une courbe plus ou moins en forme de cloche. Ils s’intéressent alors aux extrémités de la courbe, les cas rares entraînant le plus de risque. Par exemple, ils ont modélisé l’impact d’une inondation de Paris. En améliorant les simulations, ils peuvent démontrer que les risques sont maîtrisables et peuvent ainsi, réduire leurs réserves de fond propre en proportion. Cela représente un gain, directement traduit en valorisation de leurs titres. Ils envisagent de publier les résultats de ces simulations dans leurs rapports trimestriels. Pour pouvoir effectuer ces calculs avec une volumétrie suffisante, les technologies de GRID permettent d’optimiser l’utilisation de leurs ressources internes ou d’obtenir des résultats inatteignables sans une nouvelle organisation des calculs. Lors des périodes de pointe, il est même envisageable de louer des puissances CPU le temps d’effectuer les calculs de trimestre ou de fin d’années par exemple.

Ce type de calcul présente la particularité d’être peu exigeant sur la complétude des résultats. En effet, si un processus ponctuel n’aboutit pas, cela ne remet pas fondamentalement en cause les résultats. Au contraire, plus il y a de machines disponibles, plus les résultats sont précis. Il est possible de lancer un calcul avec une limite basse permettant d’avoir des résultats statistiquement valables, et de limiter le temps global de calcul en utilisant toutes les ressources disponibles. Suivant les ressources utilisées le nombre de chiffres après la virgule sera plus ou moins important.

Cette approche peut s’appliquer à tous les algorithmes stochastiques. Les calculs déterministes atteignent leurs limites car leurs complexités ne permettent pas d’avoir des convictions sur les résultats. Au contraire, les calculs probabilistes permettent de dégager des tendances, suffisantes pour la prise de décision.

Un site WEB souhaite proposer un calcul de devis d’assurance personnalisé en temps réel aux internautes. C’est un processus très complexe, faisant intervenir de nombreux paramètres. Il faut en effet effectuer des projections sur trente ans pour estimer la réalité du risque que représente le client. Les modélisations sont propres à chaque assureur, ce qui explique les écarts de prix. Effectuer ce calcul directement dans le serveur WEB risque de le faire tomber et ne permet pas de donner une réponse rapidement. Pourquoi ne pas utiliser une architecture GRID pour faire cela ? Il existe sûrement des machines dormantes chez l’assureur. Ainsi, le traitement pourra s’effectuer beaucoup plus rapidement, permettant une réponse quasi instantanée pour l’utilisateur. Il obtient son devis individualisé immédiatement, ce qui facilite la prise de décision lors de la signature d’un nouveau contrat.

Analyser la complexité d’un mot de passe n’est pas une chose triviale. Il faut vérifier de nombreuses variations à partir des mots des dictionnaires en plusieurs langues. Ce traitement peut également être distribué sur une grille, afin d’indiquer immédiatement à l’utilisateur que son mot de passe ne respecte pas les contraintes de sécurités imposées. Il est possible alors de détecter les astuces mnémotechniques, que les pirates savent exploiter. Par exemple, découvrir que le mot de passe "monsieuremadamc4r1b0v" contient le mot monsieur, l'inverse du mot madame (emadam) et une version Elit du mot caribou (c4r1b0v).

Effectuer une analyse complète d’un disque à la recherche de virus éventuels est un processus long, que les utilisateurs débranchent souvent. Les technologies de GRID permettent de déporter cette analyse sur des postes moins sollicités. IBM a transformé ce processus pour améliorer la sécurité à l’aide de technologies GRID. L’analyse est déportée sur des nœuds disponibles.

Les musiciens utilisent des logiciels de simulations d'instruments. Ces programmes exploitent beaucoup de ressources. Pour simuler un orchestre philharmonique, un seul Mac ne suffit plus. L’extension LOGIC NODE du programme LOGIC PRO d’Apple permet de distribuer les simulations sur plusieurs machines, repoussant les limitations techniques.

D’autres exemples célèbres sont de bons candidats pour les technologies de GRID. Citons la recherche de vie dans l’espace par le projet SETI@Home ou les recherches en science de la vie comme le projet Téléthon. Des hôpitaux utilisent les cycles perdus des postes des administratifs ou des médecins (pauses, nuités, week end) afin d’analyser des mammographies. Une nouvelle grille généraliste s’est ouverte récemment, afin d’exploiter les cycles perdus des machines individuelles pour des projets de recherche scientifique à vocation universelle (science de la vie, prévision des tremblements de terre, simulations de tsunami, etc.). Les résultats de ces calculs ne pourront être brevetés et resteront dans le domaine public.

La recherche fondamentale est également très exigeante en calcul et en volume de données. Des réseaux GRID se mettent en place à l’échelle mondiale afin d’utiliser au mieux les ressources des universités et des centres de recherche. Les résultats des tirs des accélérateurs de particules, les analyses météorologiques ou les simulations sismologiques bénéficient de ces techniques. Des grilles européennes utilisent des réseaux à larges bandes et les centres de calculs les plus puissants pour améliorer la compétitivité de nos entreprises.

Il est possible de virtualiser les nœuds d’un Cluster, pour simuler une machine unique. Le projet MOSIX propose une approche pour Linux. Les processus sont automatiquement distribués sur les différents nœuds du Cluster. Ils sont également capables de migrer dynamiquement d’un système plus lent ou saturé en mémoire, vers un autre nœud, sans que le développeur modifie son application. Un processus est associé à un seul nœud. Si une application lance de nombreux fork(), les traitements sont répartis sur les nœuds. Par contre, si l’application lance des tâches et non des processus, elles restent sur le même nœud. Il n’est pas possible de répartir automatiquement les traitements sur tous les nœuds pour optimiser les algorithmes. Bien que très séduisante, cette approche oblige à installer des clusters sur mesure. Elle ne permet pas d’exploiter des ressources réparties autour du monde.

Utiliser une technologie GRID, par rapport à augmenter les capacités d’un Cluster, permet de mieux exploiter les ressources. Les machines ne sont pas dédiées à certains calculs. Tous les ordinateurs deviennent une partie d’un ordinateur virtuel plus puissant que la somme de chaque partie. La distribution des traitements peut s’adapter aux différents besoins, aux différentes priorités et aux différents calculs. Tous les postes d’une entreprise peuvent, provisoirement, faire partie de la grille. Des technologies de provisionning dynamiques permettent une très grande souplesse pour l’adaptation du parc information aux besoins des traitements. Les postes sont dynamiquement associés aux calculs, intègrent ou se détachent de la grille, offrent plus ou moins de ressources suivant les heures ou des dates, etc. Les capacités d’adaptations des technologies GRID permettent de moins solliciter l’exploitation.

Ces nombreux exemples montrent que l’approche GRID s’applique à de nombreux sujets, des plus triviaux au plus complexes, de l’anecdotique aux plus fondamentaux.

L’industrie ayant pris conscience d’un besoin de standardisation, des initiatives ouvertes se mettent en place. C’est le sens de l’initiative de OGSA avec www.globus.org .

La grille en entreprise

Utiliser les technologies GRID pour optimiser un où plusieurs traitements est une première étape. Ensuite, il faut envisager de mutualiser toutes les données de l’entreprise avec une grille de données, pour arriver finalement à une grille d’entreprise, mutualisant toutes les ressources pour plusieurs applications.

L’objectif est d’arriver à une virtualisation complète de l’informatique. Les données sont réparties sur les machines disponibles, rapatriées dans des caches lorsque c’est nécessaire ; les traitements sont parallélisés sans que l’utilisateur sache vraiment où ils tournent. Pour augmenter la puissance globale de l’entreprise, il faut ajouter de nouvelles machines et les déclarer dans la grille. Inversement, la panne d’une ressource ou son retrait pour maintenance ne perturbe plus personne.

Une notion de nom global des ressources de l’entreprise permet de mutualiser les données de l’entreprise. Les URI sont généralement utilisées pour identifier les fichiers de façon unique, et les URL pour les différentes duplications.

Des technologies de provisionning permettent d’organiser les configurations des machines au cours du temps, d’installer dynamiquement les machines pour les préparer à des traitements de la grille. Lorsqu’un traitement exige plus de machine, des nœuds sont sacrifiés sur des traitements moins importants pour les associer à d’autres calculs. IBM Tivoli Provisioning Manager et IBM Tivoli Intelligent ThinkDynamic Orchestrator permettent de réorganiser l’infrastructure dynamiquement, à l’aide de règle et d’indicateur de performance. Un poste Windows peut devenir un poste Unix en fin de trimestre.

Décomposition d’un traitement GRID

Le lancement d’un traitement GRID s’effectue en plusieurs étapes dont le détail est décrit plus bas. Il faut dans un premier temps sélectionner les nœuds participants au calcul. Ensuite, les initialiser avec différents fichiers, programmes ou paramètres. Il est alors possible de lancer les traitements en parallèle. Les résultats intermédiaires sont remontés au fur et à mesure, et synthétisés par un processus peu gourmand en ressource. Sur la figure suivante, les couleurs représentent les traitements effectués sur des nœuds différents.

Identifier les nœuds

Nous allons traiter de l’identification des nœuds candidats pour exécuter un traitement. Plusieurs critères permettent de sélectionner les machines. Nous aborderons les problèmes de sécurité dans un autre chapitre.

Avant de lancer un traitement, il faut identifier les machines pouvant l’accueillir. Pour cela, il est nécessaire d’avoir un référentiel dynamique indiquant les ressources disponibles sur chaque machine. Cela comprend la présence de logiciels, les versions des compilateurs, l’accès à des bases de données, etc.

Il faut obtenir l’état de la machine cible. On y trouve des informations statiques (nombre de CPU, ressource mémoire, type et version du système d’exploitation, version des compilateurs, distance réseau, pays) et des informations dynamiques ( % CPU, mémoire, mémoire virtuelle et place disque disponible). Cela permet de sélectionner les machines candidates. De nombreux ordonnanceurs permettent ceci : Globus, Condor, DataSynapse, Dollar Universe, LoadLeveler, Platform Computing LSF, PBS Pro, Sun Grid Engine, United Device, etc.

Si une machine ne possède pas les ressources nécessaires, il est envisageable de les installer dynamiquement. Les technologies comme InstallAnywhere [IA] ou IBM Tivoli Intelligent ThinkDynamic Orchestrator permettent de s’affranchir de l’OS utilisé sur la cible. Des applications Javas ou des programmes compilés pour différentes plates-formes peuvent se déployer automatiquement et silencieusement.

Des priorités peuvent être appliquées aux traitements. Cela permet d’associer plus ou moins de machines, d’interrompre des traitements moins prioritaires, voire de les arrêter pour les relancer plus tard. Les ordonnanceurs savent généralement traiter ces situations complexes.

Livrer les fichiers d’entrées

Ensuite, il faut vérifier que les ressources spécifiques au traitement à exécuter sont disponibles sur le nœud de la grille. Cela comprend l’accès aux fichiers d’entrées, aux bases de données, aux programmes à exécuter, etc.

Pour les rendre disponibles, il y a plusieurs approches: partager un répertoire ou dupliquer les fichiers. Le réseau peut alors constituer un goulet d’étranglement. De nombreux mécanismes techniques permettent de repousser ces limites.

Pour les fichiers, il est souvent suffisant de partager un répertoire avec tous les fichiers nécessaires aux traitements à paralléliser, programmes et données. Les protocoles Common Internet File System ou NFS sont généralement utilisés.

Si les fichiers peuvent évoluer dans le temps, où avoir plusieurs versions, des technologies comme ClearCase permettent de proposer une vue sur une version des fichiers. Des règles d’accès et une sélection de versions sont envoyées avec le traitement. Les nœuds doivent posséder un client ClearCase qui est initialisé avec les paramètres avant de lancer le traitement.

IBM GPFS, General Parallel File System, permet également d’offrir un accès efficace aux ressources fichiers en mutualisant les serveurs pour répartir les morceaux de fichiers sur les différents disques et en utilisant des algorithmes de caches complexes pour optimiser les accès et les verrous.

Malgré les nombreuses stratégies d’améliorations pour mutualiser les disques, le réseau ou le serveur de fichiers peuvent entraîner une dégradation des performances. Avec une grille, il n’est pas rare d’atteindre les limites du nombre de connexions ouvertes sur le serveur de fichier ou de saturer le réseau. Les différents processus peuvent passer plus de temps à accéder aux données d’entrée ou à écrire les résultats qu’à calculer. Par exemple, pour les simulations numériques évoquées lors des calculs financiers, les données de chaque simulation peuvent avoir des tailles conséquences de plusieurs giga octets.

Pour contourner cette limitation, il est envisageable de copier localement, en totalité ou partiellement, les informations sur chaque station, avant d’exécuter les traitements. La copie peut s’effectuer à partir d’un référentiel intermédiaire comme un portail, ou directement chez l’initiateur du traitement, juste avant d’exécuter les traitements.

De nombreuses technologies émergentes de type « point à point » permettent de dupliquer des données sur de nombreux nœuds, en mutualisant les informations présentes sur chacun. La technologie bittorrent par exemple, permet de dupliquer le même fichier sur de nombreuses machines, bien plus rapidement que des transferts individuels. Dès qu’un morceau de fichier est disponible sur une machine, celle-ci peut devenir serveur de ce morceau. Ainsi, par capillarité, les machines proches s’échangent des informations, limitant le nombre de routeurs à traverser.

GridFTP est une extension au protocole FTP pour permettre le transfert de fichier en parallèle, la reprise sur erreur, le transfert entre serveurs, etc.

Si des versions antérieures des fichiers sont déjà disponibles sur les nœuds, il est envisageable de les rafraîchir à l’aide d'algorithmes intelligents permettant de détecter les évolutions entre deux versions d’un même fichier, sans avoir recours à un transfert complet d’un des fichiers. Rsync ou le prototype IBM downloadGRID permettent cela. Il est parfois nécessaire de dupliquer un répertoire complet, en supprimant les fichiers en trop et en rafraîchissant les autres fichiers.

Pour une duplication sur des réseaux mondiaux, des serveurs distribués autour du monde peuvent se dupliquer, et servir de référentiel lors de la copie des fichiers sur les différents nœuds. Des statistiques, mises à jours continuellement, permettent d’identifier les chemins les plus efficaces pour récupérer un fichier. Le prototype IBM downloadGRID permet cela, divisant les temps de transfert par quatre. Il permet également de travailler en mode point à point ou de détecter les mises à jour des fichiers afin de ne transférer que certaines parties.

Avec des machines multiprocesseurs, il est possible de partager le disque local. Avec des clusters et les technologies Blades d’IBM il est également possible d’utiliser un réseau spécialisé pour les accès disques. Un Storage Area Network est installé dans le socle des Blades.

D’autres technologies se proposent de servir d’intermédiaire, s’occupant d’agréger et de publier intelligemment les fichiers ou les bases de données. Avaki propose une technologie de grille de données permettant d’unifier toutes les ressources de type données de l’entreprise, sans revoir les applications lors d’un changement d’organisation comme la fusion/acquisition d’une nouvelle entité ou la vente d’un département. Cela facilite l’intégration lorsque les technologies sont hétérogènes.

Pour donner l’accès aux bases de données, il existe également des technologies d’installation dynamique de réplication, complète ou partielle. Ensuite, un lien est maintenu entre la copie locale et la base originale. DB2 propose DataPropagator.

Si les pare-feux des postes utilisateurs interdisent l’utilisation de ces technologies avancées, il est possible d’exploiter le protocole http comme fournisseur de fichier. Pour mémoire, il a initialement était conçu pour cela. Une connexion ftp peut également faire l’affaire.

Ces différentes technologies peuvent être combinées suivant les caractéristiques de chaque fichier :

Bien entendu, les technologies de compression doivent être utilisées pour tous ces transferts. Cela peut s’effectuer par une décompression locale des fichiers d’entrée et une compression locale des fichiers de sortie, ou l’utilisation de protocoles intégrant la compression. Par exemple, HTTP permet une compression dynamique lors de transfert à l’aide l’en-tête Content-Encoding valorisé à gzip .

D’autres projets travails sur ces besoins, en proposant différentes approches plus innovantes les unes des autres : DataCutter, Distributed-Parallel Storage System, Quick File System, GridExpand, Secure Grid File System, Storage Resource Broker, etc.

Une fois la ressource installée sur un nœud, il est pertinent de la déclarer dans un référentiel de réplication. Un moteur de recherche permet alors de retrouver les nœuds possédant les ressources nécessaires aux traitements.

Pendant la phase d’initialisation des nœuds, il est déjà possible de lancer les traitements. Dès qu’une machine est prête, il faut l’exploiter. Il ne sert à rien d’attendre l’initialisation complète de toutes les machines avant de commencer le calcul.

Virtualisation des données

Les technologies de grille de données comme la solution proposée par Avaki, permettent de distribuer les données sur différents serveurs, de les convertir dynamiquement, sans qu’il soit besoin de modifier les applications. Les fichiers ou les répertoires sont publiés dans un disque virtuel Avaki. Les fichiers restent à leurs emplacements d’origine. Le disque virtuel garde un lien vers les fichiers originaux. Par une utilisation d’un disque réseau, l’utilisateur manipule les fichiers du disque virtuel. Celui-ci se charge de déléguer les accès aux emplacements d’origine. Ainsi, il est facile de réorganiser l’entreprise. Lors d’une acquisition d’entreprise, par exemple, les nouveaux fichiers sont publiés sur le disque virtuel. Si des conversions sont nécessaires pour permettre aux applications de les utiliser, des extensions peuvent être écrites (en XSL ou Java) afin d’adapter la visibilité d’un fichier sur le disque virtuel.

Une technologie équivalente est proposée pour l’accès aux bases de données. Il est possible de mutualiser virtuellement plusieurs bases ayant des schémas différents. L’utilisateur de la base virtuelle n’a pas connaissance des traitements intermédiaires. Une requête vers la base virtuelle peut être déléguée vers plusieurs bases. Le résultat global est retourné. Ainsi, les fusions/acquisitions ou la cession de départements s’effectuent en douceur. C’est un point important pour les opérateurs téléphoniques qui achètent et revendent des opérateurs locaux rapidement. Ils vendent un opérateur d’un pays pour en acheter un autre plus rentable.

Gérer les ressources rares

Certaines ressources sont rares comme les jetons des licences logicielles ou des périphériques particuliers. Nous allons voir comment les gérer au niveau de l’entreprise, du pays, du continent ou du monde.

Il est nécessaire de maîtriser ces informations globalement pour anticiper sur la réussite de l’exécution d’un traitement. Chaque traitement indique le nombre et la quantité de ressource rare utilisée. Ainsi, l’ordonnanceur peut maintenir des compteurs permettant d’anticiper sur la réussite d’une exécution et étendre le périmètre d’exploitation de ces ressources.

Il est également possible de procéder à des réservations de ressource. Un traitement sait qu’il a besoin de dix-sept nœuds avec 10 Mo de mémoire, 0M de mémoire virtuelle, 50 % de CPU, 1G de disque et cinq licences d’un logiciel particulier, et cela, pendant deux heures. Il peut réserver ces ressources à l’avance pour ne lancer les traitements que si elles sont disponibles, et être certain qu’elles le seront un jour. Les ordonnanceurs doivent organiser la grille pour tenir compte de ces impératifs.

Exécution du traitement

Nous allons regarder comment contrôler les différents traitements. La transformation des algorithmes pour les paralléliser sera traitée plus loin.

Une fois les données d’entrées disponibles, le traitement peut commencer. Il fonctionne dans les cycles perdus s’il s’agit de poste utilisateur, ou avoir une priorité standard s’il s’agit de grappes de serveurs dédiés.

Comment contrôler le processus ? Les technologies de GRID permettent généralement de garder des liens dynamiques entre les flux d’entrée (stdin) et les flux de sortie (stdout, stderr). Cette approche permet de contrôler le traitement, mais est difficile à utiliser si celui-ci est découpé en plusieurs centaines de travaux en parallèle. Qui sait maîtriser cent claviers ? Des automates peuvent simuler les interactions utilisateurs et obtenir des informations sur les traitements dynamiquement. Plus classiquement, les flux sont sauvés sur des fichiers locaux et récupérés par le soumissionnaire à la fin du processus.

Il faut également pouvoir contrôler les travaux pour pouvoir les interrompre prématurément. Les priorités peuvent être associées aux différents traitements. Si un travail plus prioritaire est demandé, l’ordonnanceur peut interrompre ou tuer en catastrophe et brutalement un travail moins prioritaire, afin de récupérer les ressources d’une machine. Il sera repris plus tard sur la même machine ou sur une autre.

Certains traitements parallélisés modifient simultanément les mêmes ressources (base de données, fichier partagé, etc.) Ils sont plus complexes à intégrer dans une grille, car il faut prévoir les interruptions inopinées d’un traitement, si un utilisateur débranche une prise par exemple. Les traitements doivent être transactionnels. Il est préférable de limiter au minimum les effets de bords.

Des optimisations peuvent s’appliquer à l’architecture en grille. Par exemple, si les ressources disponibles sont suffisantes ou pour des raisons de sécurité ou de tolérance aux pannes, le même traitement peut être demandé à plusieurs nœuds. Le premier qui a terminé a gagné. C’est généralement le cas pour les derniers traitements. Imaginez qu’un calcul doit s’effectuer en onze traitements alors que dix nœuds sont disponibles. Une fois que les dix premiers traitements ont été exécutés, il est envisageable de demander le onzième aux dix nœuds disponibles. Ainsi, le nœud le plus rapide en pratique sera exploité, même si la théorie aurait sélectionné une machine particulière.

Pour invoquer des traitements GRID interactif, des évolutions à base de Web Services sont proposées. Il s’agit de normaliser l’invocation de traitements sur les nœuds, à l’aide des protocoles standard tels que HTTP et XML. Les nœuds participent immédiatement aux traitements, sans avoir besoin d’ordonnanceur. Les spécifications proposées par www.globus.org ajoutent des concepts supplémentaires permettant de distribuer des traitements sans connaître leurs localisations. Il est alors possible d’exploiter les ressources disponibles des serveurs Web pour contribuer aux calculs. La dernière génération du serveur d’application WebSphere Application Server XA permet d’exploiter les ressources du serveur, sans sacrifier les performances des applications Web.

Il faut également pouvoir détecter les erreurs. Pour cela, les traitements sont sous le contrôle d’un processus de lancement, se chargeant de les surveiller et de capturer les flux standard. Par exemple, si le calcul prend trop de temps ou trop de ressources, celui-ci peut être interrompu automatiquement. Cette information est transmise au gestionnaire GRID qui peut alors relancer le traitement sur une autre machine ou considérer que cette partie du traitement pose problème et générer une alarme.

Un traitement peut également être envoyé simultanément sur plusieurs machines et les résultats comparés. Si l’algorithme utilisé est déterministe, les résultats sont censés être identiques. Si ce n’est pas le cas, un vote à la majorité peut être pratiqué afin d’éliminer les erreurs. Cette stratégie est utilisée pour les calculs effectués sur les PC des particuliers. Elle permet d’éliminer les pirates cherchant à perturber les résultats.

Lors d’un traitement complexe, il est possible de mémoriser des points de stabilités intermédiaires, afin de permettre des reprises partielles. Il faut prévoir cela dans les algorithmes. Par exemple, si un traitement doit effectuer dix itérations et plantes à la huitième, il n’est pas judicieux de reprendre tout le travail. Les résultats intermédiaires sont exploitables. L’algorithme de distribution doit tenir compte de ces situations.

Récupération des résultats

Ensuite, il faut récupérer les résultats des calculs. Nous allons voir quelles sont les technologies disponibles pour cette étape.

Les mêmes technologies que lors de la copie des fichiers d’entrées peuvent être utilisées pour le rapatriement : une copie de fichier, la récupération d’un delta sur l’évolution d’un fichier, etc.

Parfois, un accès direct aux fichiers sur les différents serveurs ayant participé aux calculs permet aux utilisateurs de sélectionner les résultats à rapatrier. Il doit ensuite nettoyer tous les résultats inutiles afin de récupérer de la place sur les différents nœuds. Cela évite un rapatriement massif, lorsqu’une seule portion est pertinente.

Parfois, des traitements différents génèrent les mêmes résultats, ou bien, volontairement, pour des raisons de sécurité ou de tolérance aux pannes, les mêmes traitements sont effectués sur plusieurs nœuds. Dans ce cas, un calcul de hash local permet de comparer les résultats avant de rapatrier les fichiers.

Si un pare-feux limite les possibilités de communication d’un nœud, les protocoles standard peuvent être utilisés : FTP ou WebDAV.

Un des avantages des grilles de calculs est de pouvoir utiliser les résultats intermédiaires avant que l’ensemble du traitement ne soit terminé. Cela permet aux ingénieurs de traiter les pièces géométriques en conflit le plus rapidement possible, ou aux analystes financiers de découvrir un biais dans les résultats, leurs permettant d’interrompre prématurément un calcul.

Est-ce que les résultats doivent rester sur les différents serveurs ou être rapatriés vers un serveur central ? Parfois, les données résultantes sont très volumineuses. L’utilisateur désire les consulter pour sélectionner un ou deux traitements pertinents. Tous les autres résultats sont alors abandonnés. Cela a comme inconvénient de consommer des ressources sur les serveurs, en attendant que l’utilisateur sélectionne les résultats.

En général, les résultats sont directement rapatriés sur un serveur centralisé ou sur le poste du soumissionnaire du traitement et détruit sur les serveurs de calcul. Cela permet de libérer immédiatement les ressources, afin d’être prêt pour un nouveau calcul. Un e-mail ou un événement peut être envoyé pour signaler la fin du processus.

Sécurité

Les grilles ne sont utilisables que si la sécurité est optimale. Nous allons étudier une approche particulière à base de certificat numérique.

Il faut pouvoir identifier les utilisateurs demandant un traitement, permettre la propagation de l’identifiant de serveur en serveur, etc. Les différents produits permettent de sous-traiter les authentifications à différents annuaires (LDAP ou autre).

Différentes approches ont été proposées, dont une, très intéressante, à base de certificat numérique. Elle permet de gérer l’authentification sans avoir une base mondiale d’habilitation. Un couple clef privée/clef publique est associé à chaque utilisateur. La clef publique est signée par une autorité de certification, garantissant les accès à la grille. Lors d’une demande de service dans la grille, le certificat public est présenté. Celui-ci est vérifié, les habilitations nécessaires sont alors appliquées pour permettre l’exécution du traitement.

Pour ouvrir la communication, l’utilisateur doit entrer le mot de passe permettant l’accès à sa clef privée. Cela est faisable si une seule communication est ouverte. Avec les technologies GRID, ce n’est pas le cas. En effet, les travaux doivent être distribués sur de nombreuses machines, souvent en mode batch, la nuit. L’utilisateur ne peut pas raisonnablement entrer plusieurs fois son mot de passe, un par traitement exécuté. Les scénarios du GRID entraînent des authentifications multiples pendant une courte période de temps. Il est nécessaire d’avoir un mécanisme de signature unique pour les différents processus mis en jeu.

Pour résoudre cette difficulté, un certificat temporaire est créé avec son couple clef privée/clef publique. Le certificat a une durée de vie courte de quelques heures. La clef privée n’est pas cryptée et n’utilise pas de mot de passe. La clef publique est signée par la clef privée de l’utilisateur. C’est le seul moment où l’utilisateur doit entrer son mot de passe. Concrètement, cela s’effectue une à deux fois par jour. Dans la terminologie Globus, ce certificat est appelé « Certificat proxy » et est généralement placé dans un fichier. Pendant la période de validité, les programmes qui exploitent la clef privée du proxy n’ont pas besoin de demander le mot de passe.

Pour démarrer un service sur la grille c’est le certificat proxy qui est utilisé. Le service GRID peut vérifier qu’il est bien signé par un certificat, lui-même signé par une autorité de confiance.

Une deuxième difficulté est à résoudre dans cette architecture. En effet, un service GRID peut lui-même déléguer un ou plusieurs traitements à un autre serveur. Le client CHERCHEUR invoque le serveur PORTAIL qui invoque le serveur CALCUL. Comment CALCUL peut savoir qu’il travaille pour CHERCHEUR ? Les clefs privées de CHERCHEUR ou du proxy de CHERCHEUR ne sont pas visibles sur le serveur PORTAIL. Il faut un certificat de délégation. Pour contourner la difficulté, le serveur PORTAIL génère un couple clef privée/clef publique temporaire. La clef publique est envoyée à CHERCHEUR pour être signée. CHERCHEUR vérifie que la demande de PORTAIL concerne une connexion vers le serveur CALCUL, et retourne alors la clef publique générée par PORTAIL, signée par CHERCHEUR. PORTAIL peut alors utiliser ce certificat pour communiquer avec CALCUL, au nom de CHERCHEUR.

Ces problèmes sont très importants. En effet, un pirate qui arriverait à obtenir les privilèges nécessaires sur une grille de calcul pourrait l’utiliser pour casser un certificat numérique par exemple, en utilisant les puissances des meilleurs centres de calculs de la planète.

Une fois identifié, sous quel utilisateur exécuter le traitement ? Généralement, il y a un mappage entre l’identification du certificat et un utilisateur local. Cela permet de bénéficier des technologies de sécurités des systèmes d'accueil, limitant les accès disques, imposant des quotas, etc. Un programme de surveillance est généralement chargé de contrôler le processus GRID. Cela permet de le tuer en cas d’utilisation excessive des ressources. Une approche « bac à sable » permet de limiter plus finement les possibilités du traitement. Au même titre qu’une applet s’exécutant dans un navigateur, le processus GRID ne peut pas faire n’importe quoi. Seules certaines API lui sont proposées. Par exemple, il ne peut communiquer avec le réseau, lire des fichiers sur les disques, ouvrir des fenêtres, etc.

Adapter les algorithmes

Nous allons regarder comment adapter les algorithmes pour leur faire bénéficier des architectures en grilles. Pourquoi l’optimisation maximale est un Graal difficile à atteindre, comment gérer les plantages, les reprises ?

Comment intégrer les technologies à base de grille dans une application ? Les traitements par lots manipulent des données d’entrées pour générer des données en sortie.

Il est généralement possible de traiter les fichiers d’entrée pour les découper judicieusement et distribuer les traitements sur les différents nœuds. Au terme des ces exécutions, un post-traitement permet d’agréger les résultats Ce mécanisme permet une intégration en douceur, car le traitement GRID ressemble comme deux gouttes d’eau à un traitement sans exploitation d’une grille de calcul.

Pour les traitements interactifs, il faut revoir les algorithmes pour respecter les interfaces d’appels en découpant les traitements. Les technologies à base d’objets facilitent grandement cela. Il est aisé de proposer une nouvelle classe qui se chargera de GRIDifier un processus. Java et C++ sont généralement utilisés, mais cela peut également s’effectuer sur des technologies de type ORB (invocation d’objet distant) comme CORBA ou DCOM. En respectant les interfaces d’appels, un traitement peut être optimisé à l’aide des technologies à base de grille. De nouvelles normes proposent d’enrichir les services Web pour pouvoir les utiliser dans une architecture GRID.

Comment optimiser les traitements ? À première vue, il suffit simplement de couper une boucle en tranches pour les distribuer. Si une boucle a deux cents itérations et que la grille nous propose dix machines, il suffit d’effectuer dix boucles de vingt itérations sur chaque machine pour optimiser le calcul. Le temps sera divisé, en théorie, par dix.

Dans les faits, c’est plus compliqué. En effet, il faut tenir compte du temps d’initialisation des boucles. Cela comprend : l’envoi des fichiers d’entrées et le lancement des traitements. Les traitements parallèles peuvent créer des goulets d’étranglements sur l’accès aux fichiers. Parfois, les volumes sont trop importants pour pouvoir obtenir un gain. Il existe une limite technique, généralement imposé par le réseau, pour pouvoir découper un traitement En général, les phases d’initialisations et de récupération des résultats sont difficiles à paralléliser.

De plus, cette approche ne fonctionne que si chaque cycle de la boucle a un temps de traitement équivalent aux autres cycles. Ce qui reste à démontrer. Ce n’est généralement pas le cas. Certaines itérations sont beaucoup plus longues que d’autres. Le temps global du calcul est alors équivalent au temps du groupe d’itération le plus long.

En découpant les traitements autrement, il est possible d’améliorer grandement les choses. Par exemple, pour calculer les collisions des pièces d’un avion gros porteur, 90 % des pièces sont calculées en dix heures. Il faut encore trois jours pour traiter les dernières pièces. Sans les technologies de GRID, ce même calcul n’aboutit pas après six jours ! La complexité des pièces peut fortement influencer les temps de calculs. En installant une grille et en adaptant les algorithmes de calcul, IBM a permis à un grand constructeur aéronautique d’améliorer considérablement le processus de production, et des découvrir des pièces en collisions qui n’avaient pas été détectées. Les outils étaient disponibles, mais étant inexploitables sur des modèles aussi complexes, ils n’étaient pas utilisés.

Avant de découper un traitement en morceaux, il faut effectuer une analyse fine des données pour identifier les éléments ayant le plus d’impact sur le temps de calcul. Est-ce le chargement des pièces géométriques ? Dans ce cas, il faut organiser les traitements pour limiter le nombre de pièces à charger en mémoire. Est-ce la complexité des pièces ? Il faut alors imposer moins d’itérations aux pièces aux formes complexes et volumineuses et plus avec des pièces simples. Des points de reprise doivent être envisagés pour tolérer les plantages partiels.

Il y a généralement de nombreuses stratégies applicables et combinables. Un maquettage est indispensable pour vérifier les hypothèses et choisir les meilleurs paramètres. Tout repose sur la capacité à prédire le temps d’un calcul à partir des informations d’entrée. L’optimum étant difficile à atteindre, une amélioration notable est facile à obtenir. Le jeu en vaut la chandelle. Les ingénieurs du constructeur aéronautique obtiennent la majorité des résultats en dix heures. Les résultats sont distribués sur toutes les stations de travail. Cela modifie leurs façons de travailler. Chaque matin, ils peuvent revoir les éléments problématiques du modèle numérique.

Les approches sont très diversifiées suivant les spécifications de chaque algorithme. Un algorithme exigeant peu de données mais beaucoup de calculs ne se traite pas comme un algorithme manipulant beaucoup de données. Les projets Seti@Home, Téléthon et World Community Grid sont des projets faciles à installer sur les PC des particuliers, car ils exigent peu de communications réseau. Les résultats sont envoyés aux serveurs une fois tous les deux jours. À l’opposé, les simulations financières exigent généralement un volume important de données (tous les contrats d’une assurance par exemple) et produisent de très gros fichiers. Chaque algorithme doit être étudié au cas par cas, en bénéficiant des expériences acquises sur des algorithmes équivalents.

La vue de l’utilisateur

Pour l’utilisateur, une grille de calcul peut être transparente. Avec une intégration complète dans les applications, il obtient simplement ses résultats plus rapidement. Son devis d’assurance est immédiatement disponible sans qu’il ait conscience que cela a entraîné la mise en place des technologies les plus modernes. Il découvre immédiatement que son mot de passe n’est pas suffisamment sécurisé, etc.

S’il désire contrôler les traitements, il doit généralement passer par un portail d’entreprise pour la grille. Les utilisateurs habilités peuvent soumettre un traitement, suivre son avancement et récupérer les résultats. Différentes approches sont proposées, généralement associées aux produits d’ordonnancement. IBM propose différents portails.

Le portail offre un serveur de fichiers volumineux afin de mémoriser les fichiers d’entrées avant de pouvoir les soumettre aux différents nœuds. Il récupère également les résultats des tirs avant que l’utilisateur ne les consulte. Le portail peut également s’occuper d’archiver les tirs afin de respecter les obligations légales et permettre des audits, par exemple en conformité avec Bales II.

Une autre approche consiste à mémoriser la localisation des données d’entrée et de sortie, et d’aller y puiser les informations juste avant l’exécution d’un traitement. Il faut alors que le poste de l’initiateur soit toujours disponible.

Évolutions

La standardisation du GRID avance à grands pas. Il était nécessaire de proposer une norme permettant d’unifier toutes ces approches. Après de nombreuses circonvolutions, une norme se dégage. Elle s’appuie sur des spécifications et des implémentations Open Source. Il est possible d’installer une grille uniquement avec des outils OpenSources, mais uniquement sur Linux. Le site www.globus.org en est le point de départ. Sur la base des spécifications Web Services Ressource Framework des API standards permettent de lancer des traitements sur différents ordonnanceurs. Les différents produits vont progressivement migrés vers cette approche.

Conclusion

Les technologies GRID existent, fonctionnent en production et apportent de réels services dans de nombreux contextes. Toutes les utilisations n’ont pas encore été explorées. Chaque profession possède des traitements informatiques complexes ou des données à analyser pouvant bénéficier de ces technologies.

De nombreux outils sont disponibles, ayant chacun leurs avantages et leurs inconvénients. Il est très difficile de se retrouver dans ce méandre. Une étude business doit être entreprise par des consultants indépendants avant tout choix technologiques. Une sélection des algorithmes candidats doit être effectuée et une étude approfondie doit permettre de proposer des démarches d’optimisations performantes, en exploitant au mieux les solutions techniques existantes.

Puis, une maquette sera réalisée sur un processus particulier. Cela permettra de vérifier la faisabilité dans le cadre de l’entreprise, d’identifier les modifications à entreprendre dans l’organisation avant d’envisager une grille d’entreprise plus ambitieuse. Par exemple, certains serveurs sont systématiquement redémarrés pendant la nuit. Peut-être faut-il revoir cela. La structure du réseau peut également être revue pour permettre une bonne exécution de la grille de calcul. La maquette permettra également de convaincre les directions du bien-fondé de la démarche.

Il ne faut jamais étudier les grilles comme une technologie, mais comme une source de profit pour l’entreprise, permettant des gains de productivités rapides. Cela permet d’ouvrir des horizons insoupçonnés, une meilleure exploitation des ressources, une plus grande souplesse dans l’organisation du système d’information et une plus grande tolérance dans la gestion des risques majeurs.

Des entreprises mondiales peuvent exploiter les ressources inutilisées pendant la nuit afin d’effectuer des calculs pour une autre région du monde. En période de pic de calcul, des ressources peuvent être louées à l’heure afin d’augmenter ponctuellement la puissance disponible pour l’entreprise, en réduisant l’impact sur le budget informatique. Les offres On Demande d’IBM permettent ces approches business.

Demandez une étude d’opportunités pour intégrer les technologies GRID dans votre entreprise dès maintenant. Cela apportera demain des gains de productivité, enviés par vos concurrents. Le résultat de l’étude peut arriver à la conclusion que cette technologie n’est pas pour vous, mais elle permet généralement de proposer des nouvelles approches insoupçonnées, vous permettant de défricher de nouveaux horizons.

Allez-y maintenant, faites des maquettes pour découvrir ces technologies, organisez votre système d’information en conséquence. Vous découvrirez des pépites d’or !