Architecture logicielle pour le calcul distribué
Le terme de « grille » (grid en anglais) a été répandu en 1998 par Ian Foster et Carl Kesselman [FK98]. Dans cet ouvrage, les auteurs expliquent qu’ils ont choisi le terme de « grille » par analogie avec le réseau de distribution électrique américain, car une grille informatique fournit de la puissance (de calcul ou de stockage de données) de façon transparente comme le réseau de distribution électrique fournit de la puissance électrique.Une grille de calcul est donc une organisation virtuelle qui exploite la puissance de calcul d’un nombre très important de machines hétérogènes (pouvant aller jusqu’à plusieurs milliers) et permet de réaliser des calculs distribués. La conception d’applications pour ce type de système est complexe. Les applications sont com- posées de processus distribués géographiquement qui s’exécutent sur les nœuds appartenant aux grilles. Lors de l’exécution d’une application distribuée, les processus qui la composent coopèrent notamment en partageant des données. L’IEEE donne la définition suivante (IEEE Std 1471- 2000) :Les exigences fonctionnelles décrivent les fonctionnalités que le système doit remplir, ou celles de chacun des composants du système. Les exigences fonctionnelles explicitent le comportement at- tendu du système, ainsi que ses entrées et ses sorties. De leur coté, les exigences non fonctionnelles servent à spécifier les caractéristiques du système, ses atouts.
Des études ont été menées pour normaliser ces concepts. La norme RM-ODP (Reference Model of Open Distributed Processing) [ISO09] a donné un cadre pour la spécification de systèmes dis- tribués. Nous ne rentrons pas dans les détails de cette norme mais il nous a semblé intéressant de présenter la notion de transparence, qui est la capacité de cacher à l’utilisateur les aspects techniques et organisationnels d’un système distribué. Cela permet à un utilisateur de bénéficier des services offerts par le système sans en connaître les détails techniques et la localisation des ressources qui fournissent ces services. La norme RM-ODP définit plusieurs types de transpa- rences : Une des qualités essentielles d’un système distribué est la capacité à se rapprocher le plus possible d’une transparence totale : plus celle-ci est proche, plus le système est vu comme une application unique et cohérente. A partir de la liste de ces transparences, il est possible de définir trois exigences non fonctionnelles d’un système distribué : La disponibilité d’un système est sa capacité à délivrer correctement le ou les services de manière conforme à sa spécification. Pour rendre un système disponible, il faut donc le rendre capable de répondre à tout problème qui peut compromettre son bon fonctionnement.Un système ou un composant est dit autonome si son fonctionnement ou son intégration dans un système existant ne nécessite aucune modification des composants du système hôte. L’auto- nomie des composants d’un système favorise l’adaptabilité, l’extensibilité et la réutilisation des ressources de ce système.
Rendre un algorithme parallèle consiste, le plus souvent, à découper les données sur lesquelles il travaille et à définir une tâche pour chaque partie des données. Chaque tâche est alors affectée à une machine particulière. Bien entendu, sauf dans le cas où les calculs d’une tâche ne dépendent pas des autres tâches, il faut mettre en œuvre des communications entre les machines exécu- tant des tâches dépendantes. On peut donc décomposer ces algorithmes en étapes de calculs et en étapes de communications. L’objectif recherché dans la distribution d’un algorithme étant d’accélérer sa vitesse d’exécution, nous aurons constamment à vérifier deux exigences souventL’approche la plus simple pour créer une application distribuée est le paradigme « Maître- Travailleurs ». Celui-ci consiste à créer un programme « maître » qui déclenche d’autres pro- grammes, dit « travailleurs », et attend la fin de leur exécution pour récupérer leurs résultats. Le processus exécutant le programme maître traite alors les résultats au cas par cas, ou les agrège, pour à nouveau lancer des sous-programmes (travailleurs) ou alors finaliser le calcul.Dans la suite, nous présentons différents modèles de programmation pouvant être utilisés pour mettre en place une application distribuée sur une grille de calcul. Pour chaque modèle, nous présentons un exemple d’implémentation. Cette liste n’est pas exhaustive mais donne une vue globale des possibilités d’utilisation des ressources d’une grille de calcul.Le modèle SPMD permet d’organiser l’exécution d’un cas de calcul sur un ensemble de proces- sus comme le propose les grilles de calcul. Dans ce modèle, un programme unique est chargé sur chaque nœud de calcul. Chaque copie du programme est exécutée indépendamment et se synchronise avec les autres processus à l’aide de messages. Chaque processus est identifié par un numéro de rang. Cet identifiant unique est utilisé, par exemple, afin de connaître sur quelle partie des données est exécuté le programme.