ASR-UV5 Grilles

Dépt. INF - INT
Présentation
Bibliographie
ASR-UV5
Grilles
• Ouvrages :
– F. Berman, G. Fox, A. Hey, Grid Computing : Making the Global
Infrastructure a Reality, Wiley, 2003
D. Millot
[email protected]
– I. Foster and C. Kesselman editors. The Grid 2: Blueprint for a
New Computing Infrastructure. Morgan Kaufmann, 2004
2009-2010
– J. Nabrzyski, J. Schopf, J. Weglarz, Grid Resource Management:
State of the Art and Future Trends, Kluwer, 2004
– Special Issue on Grid Computing, Proceedings of the IEEE, Vol
93, No 3, Mars 2005
• URL :
http://www-inf.int-evry.fr/∼millot/urlparall.html
2009-2010
Dépt. INF - INT
Présentation
D. Millot
Dépt. INF - INT
2
Présentation
Plan du support
Objectifs
• Introduction
– Eléments de contexte
– Rappels : modèles de programmation et principaux standards
• Dégager les principes d’organisation et de fonctionnement des grilles
• Vers le calcul à grande échelle
• Savoir mettre en œuvre un environnement de programmation sur une grille
– Concept de grille
• Évaluer les possibilités offertes par Internet pour le calcul hautes
performances,
– Exemple de globus 2
• Calcul à grande échelle
• Identifier les problèmes posés par le passage à l’échelle induit par
l’utilisation d’Internet.
– Calcul global : desktop computing
– Modèles de programmation pour grille
– Services de grille
2009-2010
D. Millot
1
2009-2010
D. Millot
3
Dépt. INF - INT
Introduction
Dépt. INF - INT
Contexte
Évolution de la demande
• augmentation ininterrompue de la puissance de calcul nécessaire
- volume des données à traiter (10 à 50 Go/appli, 2 à 600 Go dans 2 ans)
- complexité des données (multimedia...)
- qualité des résultats attendus
⇒ plus de données : nombre de paramètres, finesse des maillages...
⇒ plus de calcul : méthodes multi-échelles, multi-physiques,
combinaison de méthodes...
Introduction
• Introduction
– Éléments de contexte
– Rappels : modèles de programmation et principaux
standards
• recherche de rationalisation des coûts
- machines spécialisées trop chères
- utilisation très ponctuelle de grosse puissance de calcul
⇒ tendance à la fédération/mutualisation/externalisation de ressources
- coût en énergie excessif
• Vers le calcul à grande échelle
• Calcul à grande échelle
• élargissement du marché
- BD parallèles, multimédia, graphique, ...
2009-2010
D. Millot
Dépt. INF - INT
4
Contexte
2009-2010
Dépt. INF - INT
Le temps révolu des supercalculateurs
Contexte
• prise en compte accrue du parallélisme au niveau matériel
- microprocesseur avec support multiprocesseur
- cartes et serveurs multiprocesseurs
- processeurs multicœurs, GPU...
• plates-formes coûteuses
- technologies spécifiques, produites en petites séries
- systèmes peu évolutifs
- systèmes dédiés à quelques applications seulement
• diffusion des technologies hautes performances
- microprocesseurs puissants
- liens de communication rapides
• une mise en œuvre difficile
- approche différente de la programmation
- pas/peu de portabilité entre machines de même type
- aucune portabilité entre machines de types différents
• évolutions générales liées à Internet et aux logiciels libres
- interconnexion généralisée des ressources
- progression de l’interopérabilité
- standardisation d’environnements parallèles
OpenMP (Open specification for MultiProcessing), MPI...
• peu de souplesse logicielle
- pas/peu de bibliothèques
- chaque développement reprend au niveau de l’analyse
- calcul scientifique essentiellement
D. Millot
6
Moyens disponibles et tendances
Dédiés à la niche du calcul scientifique
2009-2010
D. Millot
• exploitation industrielle d’applications parallèles
- google, AOL, Météo France, Dreamworks, Pixar, George Lucas...
5
2009-2010
D. Millot
7
Dépt. INF - INT
Contexte
Dépt. INF - INT
Comment exploiter ces architectures multiprocesseur ?
Les architectures des années 2000
• cluster (grappe) :
ensemble (a priori homogène) de stations de travail sur un réseau
local, éventuellement interconnectées par un réseau haut débit,
utilisées globalement comme une ressource de calcul unique
• Poursuivre les objectifs traditionnels du parallélisme :
– Faire contribuer aux traitements toutes les ressources utilisées
– Minimiser les périodes d’inactivité
– Maximiser l’efficacité
• grid (grille) :
ensemble (a priori hétérogène) de ressources de calcul administrées
indépendamment et reliées par Internet, dont l’usage est à la fois
soumis à une autorité de certification et coordonné
• Problèmes à résoudre pour le programmeur :
– Opter pour une approche par les traitements ou par les données
– Découper les traitements et/ou les données
⇒ définir les tâches à assigner aux processeurs
• desktop grid :
ensemble (a priori hétérogène) de PCs reliés par Internet participant
de façon sporadique au partage de la fourniture d’un service
– Assigner les lots aux différents processeurs/cœurs
– Coordonner les traitements
– Concilier performance des traitements et confort d’utilisation
⇒ parallélisme explicite vs implicite
• cloud :
est à l’infrastructure ce que le SaaS est aux applications
2009-2010
D. Millot
Dépt. INF - INT
8
Contexte
2009-2010
10
Contexte
Différentes formes de parallélisme
• Parallélisme de contrôle
Faire plusieurs choses à la fois
- association : ressources de calcul ↔ tâches indépendantes
- concurrence : taille des antichaînes maximales (6= parallélisme
réalisé)
• Donner accès à un maximum de ressources (cpu, ram, disques...)
⇒ constituer des architectures virtuelles par interconnection de
ressources exploitables individuellement par ailleurs :
– PCs + réseau haut débit → grappe
• Parallélisme de données
Répéter une même action sur des données similaires
- association : ressources de calcul ↔ données
- un seul flot de contrôle
– grappes + Internet → grille
– PCs + Internet → desktop grid
• Simplifier au maximum l’utilisation
⇒ utiliser ces ressources fédérées comme une ressource unique :
• Parallélisme de flux
Travailler à la chaîne
- association : ressources de calcul ↔ étapes de calcul
- recouvrement des étapes
– grappe : système à image unique (Kerrighed, Mosix...)
– grille : authentification unique, portail...
D. Millot
D. Millot
Dépt. INF - INT
Objectifs de l’usage de ces architectures
2009-2010
Contexte
9
2009-2010
D. Millot
11
Dépt. INF - INT
Contexte
Dépt. INF - INT
Différents choix possibles pour l’expression du parallélisme
Contexte
Directives de compilation
• Types de langages
Fragment de code séquentiel :
– langages dédiés parallélisme (Ada, Occam)
for (i=0;i<N;i++) A[i]=b[i]*b[i+1];
for (i=0;i<N;i++) c[i]=A[i]+A[i+1];
– extensions de langages séquentiels (C, Fortran, java)
• Approches de programmation (liées au modèle d’architecture)
– données parallèles vs processus parallèles
Equivalent en OpenMP :
– EAU vs EAM (shared variables vs message passing)
#pragma omp parallel private(i), shared(A,b,c)
{
#pragma omp for
for (i=0;i<N;i++) A[i]=b[i]*b[i+1];
#pragma omp for
for (i=0;i<N;i++) c[i]=A[i]+A[i+1];
}
– SPMD vs MPMD (1 seul code vs plusieurs codes, séq ou par)
• Types de chaîne de production (avec ou sans nouveau compilateur)
– nouvelles constructions dans le langage ⇒ vérification exhaustive
– directives de compilation ⇒ OK pour compilateur séquentiel
– fonctions de bibliothèques (MPI, Pthreads, ...)
2009-2010
D. Millot
Dépt. INF - INT
12
Contexte
2009-2010
D. Millot
Dépt. INF - INT
Nouvelles constructions dans le langage
14
Contexte
Bibliothèques
Exemple de fragment de code séquentiel :
Fragment de code séquentiel :
for (i=0;i<N;i++) A[i]=b[i]*b[i+1];
for (i=0;i<N;i++) c[i]=A[i]+A[i+1];
for (i=0;i<N;i++) A[i]=b[i]*b[i+1];
for (i=0;i<N;i++) c[i]=A[i]+A[i+1];
Equivalent utilisant une bibliothèque :
nouvelles constructions ⇒ nouveau compilateur
id = my_process_id();
p = number_of_processes();
for (i=id;i<N;i=i+p) A[i]=b[i]*b[i+1];
barrier();
for (i=id;i<N;i=i+p) c[i]=A[i]+A[i+1];
Code Fortran 90 équivalent, avec opérations sur les tableaux :
A(0:N-1)=b(0:N-1)*b(1:N)
c(0:N-1)=A(0:N-1)+A(1:N)
2009-2010
D. Millot
13
2009-2010
D. Millot
15
Dépt. INF - INT
Modèles de programmation
Dépt. INF - INT
Modèle data-parallel
Modèle de programmation data-parallel
Modèles pour la programmation d’architectures multiprocesseur
• caractéristiques
– flot de contrôle unique ⇒ programmation séquentielle
• Modèle séquentiel, parallélisme extrait automatiquement
Parallélisation (SMP)/vectorisation (vectoriel/SIMD)
⇒transformations de programmes
– structures de données/opérations parallèles
– opérations de réduction (combinaison à résultat scalaire)
– programme = séquence d’opérations usuelles/parallèles
• Modèle de programmation data parallel (natif sur SIMD)
• un standard de fait : HPF (High Performance Fortran)
• Modèles à flots de contrôle multiples
- Modèle shared variables (natif sur SMP = SM-MIMD)
- Modèle de programmation message passing (DM-MIMD)
- Modèle de programmation BSP
– compilation avec insertion par le compilateur d’instructions :
- de synchronisation pour les SMP
- de transfert de données en cas de mémoire distribuée
– maîtrise de la distribution des données (cf règle owner computes)
- DISTRIBUTE, ALIGN : découpage en lots, répartition et
alignement des données
• Modèles de calcul à grande échelle
2009-2010
D. Millot
Dépt. INF - INT
16
Parallélisation automatique
2009-2010
D. Millot
Dépt. INF - INT
18
Modèles à flots de contrôle multiples
Modèles à flots de contrôle multiples
Parallélisation automatique de codes FORTRAN
Le programmeur gère explicitement des flots de contrôle
Vectorisation versus Parallélisation
• Modèles de programmation similaire au multitâche (temps partagé),
les processus étant exécutés par des processeurs différents
Recherche d’actions (instructions ou séquences) indépendantes dans les
nids de boucles (ensemble de boucles imbriquées)...
• distinction tâche (ou processus) vs fil d’exécution (ou thread) :
tâche : à la fois unité d’allocation de ressources et unité d’exécution
thread : unité d’exécution seulement
• Vectorisation : code “scalaire” → code “vectoriel”
spatialisation du parallélisme ⇒ tableau 1D = vecteur
boucles les plus internes → instructions vectorielles
⇒ exploitation d’un parall. à grain fin sur archi. vectorielle
• primitives de manipulation de processus :
- gestion : création, destruction, suspension, ...
- interaction : communication, synchronisation
• Parallélisation : code “scalaire” → code “parallèle”
boucles les plus externes → processus parallèles
⇒ exploitation d’un parall. à grain moyen/gros sur MIMD
2009-2010
D. Millot
• parallélisme statique (blocs ou boucles parallèles) ou dynamique
• création de processus statique vs dynamique
• mise en parallèle structurée ou non (parbegin/parend, fork/join)
17
2009-2010
D. Millot
19
Dépt. INF - INT
Modèle shared variables
Dépt. INF - INT
Le standard OpenMP
Modèle shared variables
• modèle proposé pour les architectures EAU (SMP, CC-NUMA)
- facilite le portage d’applis (séquentielles vers EAU, entre OS/EAU)
- multi-langage, multi-plateforme et indépendant du constructeur
Partage d’une partie de l’espace d’adressage par les différents flots de
contrôle (process ou threads) qui disposent de données privées et de
données partagées (modèle natif des SMP, disponible aussi en DSM)
• ensemble de directives de compilation (pragma C), une bibliothèque
de fonctions et des variables d’environnement permettant de :
- spécifier du parallélisme d’exécution (de type parbegin/parend)
avec répartition possible des itérations d’une boucle
- gérer les variables (privées ou non) pour les threads
- spécifier des synchronisations entre threads
- contrôler l’exécution (nombre de threads, scheduling, ...)
• déclaration explicite des variables partagées
• partage de données ⇒ exclusion mutuelle
⇒ sections critiques (sémaphores), moniteurs de Hoare
• dépendances ⇒ synchronisations ⇒ barrières
• possibilité de gestion des flots de contrôle :
- explicite (Pthreads, par exemple) ou
- implicite (OpenMP)
2009-2010
• contrôle d’exécution possible
- statiquement : variables d’environnement
- dynamiquement : fonctions de bibliothèque
D. Millot
Dépt. INF - INT
20
Modèle shared variables
2009-2010
D. Millot
Dépt. INF - INT
22
Modèle shared variables
Modèle PGAS (Partionned Global Address Space)
Threads POSIX
Modèle multi-flot SPMD où chaque thread dispose de mémoire privée
(locale) et de mémoire partagée (locale (cf affinité) ou distante)
Standard IEEE : fonctionnalités et interface similaires à celles des
threads Solaris, qui ne spécifie pas le type de thread, i.e. user ou kernel
(vrai parallélisme possible uniquement avec un système “multi-threadé”)
– C → UPC (Unified Parallel C), testé sur BG/L (> 105 cpus)
– Fortran 90 → CAF (Co-Array Fortran)
• gestion des threads (de type fork/join)
– java → Titanium, X10
– pthread_create, avec attributs fixant les modalités d’exécution
– pthread_exit, pthread_join
• partitionnement des tableaux déclarés shared entre les threads
(round-robin, avec facteur de bloc de 1 par défaut)
• synchronisation des threads
• partage des itérations d’une boucle upc_forall selon l’affinité
– pthread_mutex_init/destroy, pthread_mutex_lock/unlock,
pthread_mutex_trylock
• spécification explicite globale ou locale du modèle de cohérence
mémoire (strict/relaxed), locks, barrières de synchronisation
– pthread_cond_init/destroy, pthread_cond_wait,
pthread_cond_signal, pthread_cond_broadcast
2009-2010
Modèle shared variables
D. Millot
L’explicitation permet au compilateur de procéder à des optimisations
21
2009-2010
D. Millot
23
Dépt. INF - INT
Programmation de grappes
Dépt. INF - INT
Modèle de programmation pour les grappes
La bibliothèque PVM en bref
• Mémoire partagée :
• identification et contrôle des processus
– facile à utiliser, mais scalable physiquement seulement pour
quelques dizaines (jusqu’à une centaine ?) de processeurs (SMP)
– pvm_mytid, pvm_parent, pvm_spawn
• communication
– difficile à implanter efficacement par logiciel (SSI)
– pvm_send, pvm_mcast, pvm_recv, pvm_nrecv, pvm_probe
– surtout utilisable quand il existe un dispositif matériel de partage
(architecture SMP, réseau SCI, ...)
• gestion explicite de tampons
• Réseaux standards :
– pvm_initsend, pvm_pk*, pvm_upk*, pvm_bufinfo
– font plutôt de l’envoi de messages
∗ en local : Myrinet, FastEthernet, ...
∗ à grande échelle : TCP/IP protocole de transfert de messages
• gestion et communication de groupes de processus
– pvm_joingroup, pvm_lvgroup, pvm_bcast, pvm_barrier
• configuration de la machine virtuelle
• Modèles de programmation parallèle les plus utilisés sur grappe :
– pvm_config, pvm_addhosts, pvm_delhosts
– pour l’instant, plutôt ceux basés sur l’envoi de messages
2009-2010
Modèle message passing
D. Millot
Dépt. INF - INT
24
Modèle message passing
2009-2010
D. Millot
Dépt. INF - INT
26
Modèle message passing
La bibliothèque MPI en bref
Bibliothèques de Message Passing
• initialisation/terminaison, identification
– MPI_Init, MPI_Comm_size, MPI_Comm_rank, MPI_Finalize
Programmation de type MPMD/SPMD en C/Fortran
• communication
Fonctionnalités communes aux bibliothèques :
– MPI_Send, MPI_Recv et non bloquant MPI_Isend, MPI_Irecv,
MPI_Wait, MPI_Wait_any, MPI_Wait_some
• initialisation/finalisation de l’utilisation de la bibliothèque
• communications collectives
• identification et contrôle des processus
– MPI_Barrier, MPI_Bcast, MPI_Gather, MPI_Scatter,
MPI_Reduce
• routines de communication point à point (send/receive, put/get)
• gestion de groupes de processus (statiques/dynamiques)
• création de topologies logiques et repérage
– MPI_Graph_create, MPI_Cart_create, MPI_Cart_coords, ...
• communications collectives
• gestion de contextes de communication
Bibliothèques génériques : PVM, MPI
2009-2010
D. Millot
– MPI_Comm_create, MPI_Comm_split, MPI_Comm_free
25
2009-2010
D. Millot
27
Dépt. INF - INT
Modèle de programmation BSP
Dépt. INF - INT
Vers le calcul à grande échelle
Modèle de programmation BSP
• modèle multi-flot SPMD, avec mémoire locale, mécanismes de
synchronisation globale et d’accès aux données non locales
Vers le calcul à grande échelle
• modèle intermédiaire entre synchrone et asynchrone
• pas d’interférence sur les données au sein d’un super-pas
• la fin d’un super-pas garantit la fin des accès distants
• Introduction
• primitives essentielles (bibliothèques C/FORTRAN) :
– démarrage/terminaison de copies parallèles
• Vers le calcul à grande échelle
– Concept de grille
∗ bsp_begin, bsp_end
– Exemple de globus 2
– barrière de synchronisation globale
• Calcul à grande échelle
∗ bsp_sync
– lecture/écriture distante
∗ bsp_get, bsp_put
2009-2010
D. Millot
Dépt. INF - INT
28
Modèles à flots de contrôle multiples
2009-2010
Dépt. INF - INT
Vers le calcul à grande échelle
Utilisation combinée de différents modèles de programmation pour des
raisons matérielles et logicielles
MPI-2 : extension du modèle de programmation par messages, avec plus
de souplesse et de robustesse
• au niveau matériel
- architectures hybrides pour lesquelles on n’a pas de modèle de
programmation natif
→ interconnection de clusters de multiprocesseurs multi-cœurs avec
accélérateurs (GPU, Cell...)
• primitives one-sided d’accès distant (put/get de BSP)
• gestion dynamique de processus (spawn de PVM)
SPMD ou MPMD, établissement dynamique de connexions
• prise en compte explicite des threads
→ intégration de threads OpenMP
• au niveau logiciel
- une même application peut souvent exploiter différentes sources de
parallélisme donc utiliser plusieurs modèles de programmation
- interopérabilité à travers TCP/IP
• entrées-sorties parallèles
primitives d’IO collectives, motifs d’accès, optimisation
Des outils existent, mais pour l’instant mise en œuvre essentiellement
manuelle (gestion de la liste des ressources, installation des binaires...)
OpenMP-3 : introduction des tâches
D. Millot
30
Hybridation/méta-computing
Vers une synthèse ?
2009-2010
D. Millot
29
2009-2010
D. Millot
31
Dépt. INF - INT
Vers le calcul à grande échelle
Dépt. INF - INT
Vers le calcul à grande échelle
Calcul distribué à grande échelle
Émergence du calcul à grande échelle
Utilisation de la puissance de machines reliées par l’Internet
Deux types de systèmes distribués de calcul à grande échelle
• Des réalisations effectives :
• Grilles de calcul → centres de calcul virtuel
– couplage de codes : simulations multi-physiques, visualisation...
– serveurs de calcul en ligne : Netsolve, NINF, DIET
– grands centres de calcul, clusters, réseaux haut débit, QoS...
– récupération de périodes d’inactivité
→ global/Internet computing : SETI@home, decrypthon
– moins de 100 nœuds stables
– identification individuelle ⇒ confiance
– partage de ressources
→ pair-à-pair (chaque machine est client et serveur) : Gnutella...
• Internet computing (Desktop grid) et systèmes pair-à-pair
– communauté importante et fluctuante de PC linux ou windows
• Normalisation déjà bien avancée pour les grilles : OGSA, WSRF
– plusieurs dizaines de milliers de nœuds volatiles
• Recherche active sur le “calcul global”
– pas d’authentification ⇒ pas de confiance
– pas vraiment de modèle bien arrêté : Xtrem Web (LRI) ?
2009-2010
D. Millot
32
Dépt. INF - INT
Vers le calcul à grande échelle
2009-2010
D. Millot
Dépt. INF - INT
34
Grilles
D’où viennent les grilles ?
Grands systèmes parallèles et distribués
Fondamentalement de la rencontre entre :
s
pg
skt
o
Grands
systèmes
distribués
De
ille
Gr
au
d
rid
es
tat
Roadrunner
www.research.ibm.com
Ré
se
e
app
Gr
architectures plutôt homogènes
2009-2010
• des besoins
- le supercalcul : applis scientifiques traditionnelles
- de nouveaux besoins : A3xx, LHC (15 Po/an)...
- de nouvelles exigences : volume et complexité des données, qualité
des résultats, temps de réponse...
ion
èle
all
par
ne
chi
Ma
Systèmes
massivement
parallèles
• et des moyens...
- le phénomène PC : standard de fait, puissance accrue, prix réduit,
mise en réseau local
- Internet : interconnexion généralisée des ressources, standard
ouvert pour communiquer (IP), partage de ressources
- le logiciel libre : ouverture (FSF), émergence et respect des
standards, garantie d’interopérabilité
architectures plutôt hétérogènes
BOINC
http://boinc.berkeley.edu
• 122K cores, 98 To mémoire
• 565K machines
• 1.02 Pflop/s soutenu
• de l’ordre de 800 Tflop/s
D. Millot
33
2009-2010
D. Millot
35
Dépt. INF - INT
Grilles
Dépt. INF - INT
Grilles
Besoins communs des grilles
Grilles = systèmes distribués à grande échelle ?
• Système d’information
• Des problèmes génériques et spécifiques
– données et applications disponibles, matériels utilisables
– hétérogénéité machine/réseau/système/...
– accès à des ressources de différents domaines d’administration
• Système de description des travaux
– volatilité de certaines ressources
• Système de lancement des travaux sur des sites distants
– nouveaux modèles à définir pour l’écriture des programmes
– interrogation de bases de données, exécution de programmes
• Des environnements dédiés aux grilles
• Système de gestion des tâches
– Globus, Legion, Unicore, gLite...
– suivi, transfert des données, récupération des résultats
• Différents types d’usage des grilles
• Système assurant une sécurité minimale
– calcul, données, information
2009-2010
– authentification, négociation des autorisations
D. Millot
Dépt. INF - INT
36
Grilles
2009-2010
D. Millot
Dépt. INF - INT
38
Globus 2
Le projet globus
Différents usages des grilles
• Grille Haute Performance (analogie : power grid)
• premières expérimentations en 1995 (projet I-WAY)
– agrégation de puissance de calcul et de capacité de stockage
• objectifs initiaux :
• Grille d’entreprise (intragrille)
– recherche : compréhension des besoins des applications vis-à-vis
des grilles → architecture en couche et protocoles
– rationnalisation de l’utilisation de l’outil informatique,
communication, coopération
– développement : technologies requises et outils de haut niveau
→ globus toolkit
• Grille d’entreprises
– vente ou échange de temps de calcul
– prototypage : construction d’une plate-forme de test à grande
échelle → plate-forme GUSTO (1997-98)
• Portail thématique
– partage de connaissances et savoir faire dans une communauté
• contributeur important d’une évolution vers les services : Open Grid
Service Architecture (OGSA)
Point commun :
→ utilisation transparente de ressources distantes hors contrôle
2009-2010
D. Millot
37
2009-2010
D. Millot
39
Dépt. INF - INT
Globus 2
Dépt. INF - INT
Boîte à outils globus
Rôles des machines dans une grille globus
• infrastructure logicielle permettant aux applications d’utiliser comme
une unique machine virtuelle un ensemble de ressources de calcul
distribuées hétérogènes administrées indépendamment ⇒ “grid OS”
Le fonctionnement de globus repose sur deux types de machines :
• machine ressource de la grille (serveur)
– en attente de demande de service (gatekeeper du GRAM)
• ensemble de services utilisables ± indépendamment et organisés en
couches :
– mapping des demandes de service sur un user local
– services de haut niveau proposés au niveau global de la grille
– exécution d’un serveur GRIS pour contribuer au MDS
– services de bas niveau implantés localement sur chaque ressource
– autres services éventuels : GridFTP, GIIS,
• machine point d’accès à la grille (client)
• pas de structure administrative hiérarchique (± pair-à-pair)
– demande (puis hébergement) de certificat d’utilisateur
• une implémentation grille de MPI : MPICH-G2
– authentification ⇒ mise en place d’un proxy (single sign-on)
• free software depuis nov 98 (V 1.0), actuellement GT4
I. Foster, C. Kesselman (Argonne)
2009-2010
Globus 2
D. Millot
Dépt. INF - INT
– lancement de commandes/jobs...
40
Globus 2
2009-2010
D. Millot
42
Dépt. INF - INT
Globus 2
Principaux services proposés par globus 2
Traitement d’une requête par globus
• authentification unique, certificats → Grid Security Infrastructure
• spécification des ressources → Resource Specification Language
GRAM
MDS
reporter
GIIS
• localisation des ressources → Metacomputing Directory Service
• allocation des ressources → Globus Resource Allocation Manager
user
jobmanager
proxy
GSI
process
proxy
• surveillance → Heartbeat et Network performance monitors
requete
création
gatekeeper
Essentiellement trois groupes de composants : gestion de ressources
(GSI, GRAM, DUROC), service d’information (MDS sur 2 niveaux :
GRIS et GIIS), et gestion des données (GASS, GridFTP)
D. Millot
...
authentification
• accès aux données distantes → Global Access to Secondary Storage
2009-2010
enregistrement
process
• co-allocation → Dynamic Updating Resource On-line Co-allocator
Accès
41
2009-2010
process
GridFTP
Ressources
D. Millot
43
Dépt. INF - INT
Globus 2
Dépt. INF - INT
Mise en place des certificats
Grid Security Infrastructure (GSI)
• Demande de certificat
grid-cert-request [-service nomService -host FQDN]
→ création de trois fichiers :
XXXcert_request.pem, XXXcert.pem (vide), XXXkey.pem
Cette infrastructure de sécurité :
• maintient la sécurité à travers les frontières d’organisations
(i.e. domaines d’administration)
• Validation d’un certificat par le CA
grid-ca-sign -in XXXcert_request.pem -out XXXcert.pem
• offre des communications sûres entre composants de la grille
Elle repose sur la cryptographie à clé publique :
• Mise en place des certificats
• certificats X509 établis par un CA (Certification Authority)
– machine : /etc/grid-security
• authentification mutuelle
– service : /etc/grid-security/ldap
– utilisateur : $HOME/.globus (créé lors de la demande)
• signature unique, délégation avec une chaîne de confiance
• Renouvellement de certificat
grid-cert-renew
⇒ une grille = un CA !
2009-2010
D. Millot
Dépt. INF - INT
44
Globus 2
2009-2010
D. Millot
Dépt. INF - INT
Certificats au format X509
46
Globus 2
Mapping des utilisateurs
Chaque participant à la grille dispose d’une paire de clés (publique,
privée protégée par passphrase) et d’un certificat au format normalisé
X509 reconnu par les navigateurs web et comportant :
Après authentification de son certificat par une ressource, les
commandes de l’utilisateur sont exécutées sous une identité locale
• mapping des certificats sur des comptes locaux
• le sujet (utilisateur, hôte ou service) représenté par le certificat
• maintien du mapping par l’administrateur globus
• la clé publique appartenant au sujet
• exemple de fichier grid-mapfile :
• une durée de validité
"/O=GET/OU=GrillePoet/OU=simpleCA-augite.int-evry.fr/OU=intevry.fr/CN=xerxes globus user" globus
"/O=GET/OU=GrillePoet/OU=simpleCA-augite.int-evry.fr/OU=intevry.fr/CN=Compte travail CNG" cng
"/O=GET/OU=GrillePoet/OU=simpleCA-augite.int-evry.fr/OU=intevry.fr/CN=Compte local D. Millot" invite
• l’identité de l’autorité de certification (CA)
• la signature numérique du CA
Le lien entre le sujet et la clé publique est certifié par le CA, autorité de
confiance, au moyen d’une signature par sa clé privée.
Pour pouvoir utiliser une ressource distante, un utilisateur doit de plus
être associé à un compte utilisateur sur l’hôte correspondant.
2009-2010
Globus 2
D. Millot
45
2009-2010
D. Millot
47
Dépt. INF - INT
Globus 2
Dépt. INF - INT
Session globus
Globus 2
Démarrage d’une application MPICH-G2
• Paramétrage : définir $GLOBUS_LOCATION, compléter le PATH
mpirun
locates
hosts
MDS
globusrun
stages
executables
GASS
• Gestion du proxy :
– grid-proxy-init, grid-proxy-info, grid-proxy-destroy
• Test d’accessibilité de ressources :
– globusrun -a -r augite
authenticates
DUROC
coordinates startup
• Exécution d’application :
detects termination
fork
• Fichiers de log :
PBS
LSF
monitors/controls
– $GLOBUS_LOCATION/var/globus-gatekeeper.log
P0
– ∼mapping_account/gram_job_mgr_xxx.log
D. Millot
Dépt. INF - INT
48
Globus 2
2009-2010
P1
P2
P3
P4
P5
D. Millot
Dépt. INF - INT
MPI sur globus : MPICH-G2
50
Globus 2
Optimisation des communications avec MPICH-G2
Différents modes de communication inter-processus avec des
performances très différentes :
- à l’aide d’une bibliothèque MPI propriétaire optimisée,
- au niveau TCP à travers globus (SAN, LAN, WAN).
⇒ en tenir compte pour réaliser les opérations collectives et/ou
organiser les communications entre processus d’une application
• MPICH (Argonne) :
– implémentation portable de MPI (paramétrée par un device)
– ADI (Abstract Device Interface)
∗ macros et fonctions permettant l’implémentation de l’API MPI
∗ une partie générique
∗ une partie propre au type de réseau (device) s’appuyant
éventuellement sur l’API Channel Interface de niveau inférieur
• Chaque noeud a une profondeur de topologie (différents réseaux
accessibles) et une couleur pour chaque niveau
– un portage de MPICH = une implémentation de la partie propre
pour un device particulier
• Accès à ces informations sous forme d’attributs de communicateurs
(MPICHX_TOPOLOGY_DEPTHS, MPICHX_TOPOLOGY_COLORS)
• MPICH-G2 :
2009-2010
GRAM
initates jobs
– mpirun -machinefile monFichier monExecutable
2009-2010
GRAM
GRAM
– globus-job-run augite /bin/hostname
– device = globus2 dédié à l’exploitation de grilles globus
• Utilisation par la bibliothèque pour les opérations collectives
– nouvelles options de mpirun : -stage, -dumprsl, -globusrsl
• Construction de communicateurs appropriés (MPI_Comm_split)
D. Millot
49
2009-2010
D. Millot
51
Dépt. INF - INT
Globus 2
Dépt. INF - INT
Globus 2
Profondeur et couleurs d’une topologie MPICH-G2
Cluster 1
IBM SP
0
2
Authentification d’un certificat
SITE B
SITE A
4
6
WAN
1
3
5
Chaque partenaire potentiel a un certificat de sa clé publique signé par le
CA choisi, et dispose également de la clé publique du CA
Cluster 2
LAN
7
8 9
10 11
1111
0000
0000
1111
hash
résumé
Rank
0
1
2
3
4
5
6
7
8
9
10
11
Depth
4
4
4
4
3
3
3
3
3
3
3
3
WAN
0
0
0
0
0
0
0
0
0
0
0
0
Colors
LAN
0
0
0
0
1
1
1
1
1
1
1
1
SAN
0
0
0
0
1
1
1
1
2
2
2
2
vMPI
0
0
0
0
2009-2010
D. Millot
Dépt. INF - INT
sujet
clé publique
durée
identité CA
sujet
clé publique
durée
identité CA
signature CA
signature CA
encryptage par
clé privée CA
Signature du certificat par le CA
52
Globus 2
2009-2010
11111
00000
00000
11111
00000
11111
?
hash
résumé
résumé
décryptage par
clé publique CA
Vérification du certificat
D. Millot
Dépt. INF - INT
54
Globus 2
Problèmes essentiels du passage à la grille de MPI
Authentification mutuelle dans globus
• Assurer les communications entre domaines différents :
Globus utilise le protocole d’authentification mutuelle de SSL / TLS :
– au démarrage, à la terminaison de l’application
– pour les échanges de messages pendant l’exécution
• authentification de A par B :
– A transmet son certificat à B qui l’authentifie en vérifiant la
signature électronique du CA (en utilisant la clé publique du CA)
• Franchissement des pare-feux
⇒ GLOBUS_TCP_PORT_RANGE "min max"
– B génère un message aléatoire et le transmet à A
• Routage pour les nœuds d’une grappe (adresses IP privées)
– A encrypte le message avec sa clé privée et le retourne à B
– problèmes liés au manque d’IP publiques, à la réticence à
l’exposition, à l’effort nécessaire lors de reconfigurations
– B doit pouvoir décrypter le message avec la clé publique de A
• authentification de B par A :
– PACX-MPI (démons en mode user), NAT-based (NAT en sortie,
démons en entrée), RSIP (Realm-Specific IP) alternative à NAT
2009-2010
D. Millot
– en cas de succès, la même opération a lieu en sens inverse
53
2009-2010
D. Millot
55
Dépt. INF - INT
Globus 2
Dépt. INF - INT
Sécurisation des communications et des clés
Délégation
Création par un proxy P1 d’un proxy P2 sur une ressource distante, i.e.
une autre ressource que la machine d’accès :
Globus permet à l’utilisateur de choisir les garanties apportées :
• Intégrité assurée
• une paire de clés est générée sur le serveur distant pour le proxy P2
à créer sur cette machine
– par défaut, cryptage du hash du message
⇒ garantie d’intégrité, i.e. garantie de non-modification
(overhead négligeable et supprimable)
• une demande de certificat de proxy est générée et adressée par le
serveur au proxy P1 (initialement, celui de la machine d’accès)
• Confidentialité possible
– communications non encryptées par défaut
• le proxy P1 signe le certificat et le retourne au serveur
– possiblité d’encryptage du message entier
⇒ overhead important
• le serveur stocke le certificat du proxy P2 (en général sous /tmp)
Mise en place d’une chaîne de confiance
• Sécurisation des clés
• permet aux processus distants créés de proche en proche d’agir pour
le compte de l’utilisateur (accès à des fichiers, etc)
– le fichier contenant la clé privée est encrypté (pass phrase)
2009-2010
D. Millot
Dépt. INF - INT
56
Globus 2
2009-2010
58
Globus 2
Metacomputing Directory Service (MDS)
Système hiérarchique qui repose sur :
L’authentification est déléguée à un proxy à durée de vie limitée
• des serveurs au niveau local (un par ressource) : Grid Resource
Information Service (GRIS)
→ maintient des informations sur la capacité et l’état courant de la
ressource : nœuds de calcul, systèmes de stockage, liaisons réseaux,
bases de données, ... (“pages blanches”)
• création d’un proxy (commande grid-proxy-init) :
– génération d’une paire de clés (privée, publique)
– certificat contenant la clé publique créé, signé par la clé privée de
l’utilisateur (utilisation validée au moyen de la pass phrase)
– stockage dans un fichier protégé en lecture sous /tmp
• des serveurs d’agrégation : Grid Index Information Service (GIIS)
→ fournit une image cohérente à un niveau plus global (un site, par
exemple), et un mécanisme d’identification des ressources qui
satisfaisont certains critères (“pages jaunes”)
• utilisation du proxy :
– la ressource distante reçoit les certificats proxy et utilisateur
– la clé publique du CA est utilisée pour valider le certificat de
l’utilisateur en vérifiant sa signature
Coopération entre les différents éléments de l’infrastructure :
– la clé publique de l’utilisateur est ensuite utilisée pour valider le
certificat du proxy en vérifiant sa signature
D. Millot
D. Millot
Dépt. INF - INT
Signature unique, chaîne de confiance
2009-2010
Globus 2
• authentification mutuelle entre GRIS et GIIS
• authentification mutuelle entre GIIS de différents niveaux
57
2009-2010
D. Millot
59
Dépt. INF - INT
Globus 2
Dépt. INF - INT
Globus 2
Exemple de jobmanager : pbs
Architecture de gestion des ressources (GRAM/DUROC)
• gestion locale de chaque ressource : GRAM
- gatekeeper : équivalent de inetd,
- jobmanager (rôle joué par PBS, LSF, Condor, NQE, ...) :
évaluation de la requête et allocation effective,
- reporter : mise à jour du MDS
• gestion de files d’attente de jobs (queues)
• fonctionnement maître-esclave
• Trois types de démon :
• co-allocation (coordonnation au niveau global) : DUROC
- raffinement et soumission des subjobs aux GRAMs locaux
- barrière de synchro pour assurer l’atomicité du démarrage
– serveur : contrôle la soumission et l’exécution des jobs
– scheduler : ordonnance les jobs
– mom : démon local sur chaque noeud responsable du démarrage
et de la terminaison des jobs
Deux modes d’interaction :
• lancement interactif
• commandes dédiées : qsub, qdel, qstat, pbsnodes, qmgr, pbsdsh
globus-job-run localhost:2345/jobmanager-pbs /bin/date
• soumission par scripts (pbsdsh/mpirun)
• lancement en batch
globus-job-submit ’contact’ ’requête RSL’
2009-2010
D. Millot
Dépt. INF - INT
60
Globus 2
2009-2010
Dépt. INF - INT
Traitement par un GRAM de la soumission d’un job
Globus 2
Langage de spécification de ressources inspiré des filtres ldap :
• authentification par le gatekeeper, puis
• valorisation d’attributs sous la forme de relations (attribut=valeur)
destinées au GRAM et/ou au DUROC (resourceManagerContact,
subjobStartType, ...)
• mapping de l’utilisateur et vérification des droits,
• transmission de la requête RSL à un gestionnaire de job,
• notation préfixée d’opérateurs sur des requêtes ou des relations
• analyse de la requête par ce gestionnaire (jobmanager),
• requête : conjonction (&) ou disjonction (|) de relations
• interfaçage avec l’ordonnanceur local qui crée les processus,
• multi-requête pour DUROC : introduite par l’opérateur +
• gestion de l’exécution par le jobmanager qui peut se terminer avec le
job,
& (executable = a.out )
(directory = /home/nobody )
(arguments = arg1 "arg 2")
(count = 1)
• stockage des sorties dans un cache géré par le GASS,
• avertissement par le jobmanager des changements d’état du job
D. Millot
62
Langage RSL de globus
L’émission d’une requête vers une machine cible implique :
2009-2010
D. Millot
61
2009-2010
D. Millot
63
Dépt. INF - INT
Globus 2
Dépt. INF - INT
Globus 2
Gestion des replica
Global Access to Secondary Storage (GASS)
Pour utiliser directement les primitives de lecture/écriture de la
bibliothèque standard sur des fichiers distants et les redirections :
Pour faciliter l’accès aux très gros ensembles de données (de l’ordre du
peta octet, i.e. 1015 octets) :
• espace de noms global pour les fichiers, utilisant la syntaxe des url
pour le support de serveurs HTTP, FTP, GASS :
http://SERVER-NAME/REMOTE-PATHNAME,
ftp://SERVER-NAME/REMOTE-PATHNAME,
x-gass://SERVER-NAME:SERVER-PORT/REMOTE-PATHNAME
• création de copies partielles ou totales de l’ensemble des données
• enregistrement des copies dans un catalogue de répliques
• recherche dans le catalogue de copies d’un fichier ou d’un ensemble
particulier de fichiers
• copie dans un cache local des fichiers ouverts en lecture
• sélection du meilleur réplica en fonction de prédictions de
performances réseau/stockage à partir d’infos fournies par le MDS
• comptage des références pour assurer le vidage du cache
• création locale des fichiers ouverts en écriture, recopie sur la
destination à la fermeture
• contenu d’un catalogue : collections logiques de fichiers,
localisations, fichiers logiques (localisations multiples)
• mode ajout, avec communication des données dès l’écriture
2009-2010
D. Millot
Dépt. INF - INT
64
Globus 2
2009-2010
D. Millot
Dépt. INF - INT
Globus 2
Packaging de globus
GridFTP
Outil GPT (Grid Packaging Toolkit) développé par le NCSA.
⇒ regroupement des modules (src/bin) en packages :
Extension du standard FTP pour des déplacements de données sûrs et
performants dans un environnement grille :
• par type d’usage
• modes client-serveur usuel et serveur-serveur sous le contrôle d’un
tiers (globus-url-copy)
– client : pour une machine servant de point d’accès à la grille,
– server : pour une machine ressource ou hébergeant des services,
• utilisation de plusieurs flots TCP en parallèle
– SDK : pour modification de globus, développement d’applications
• transfert en parallèle de données éclatées sur plusieurs serveurs
• par type de services supportés
• transfert de portions de fichiers seulement
– Ressource Management : GSI, GRAM, DUROC
• réglage manuel ou automatique de la taille des tampons/fenêtres
TCP pour optimiser les performances
– Data Management : GASS, GridFTP
– Information Services : GRIS, GIIS
• récupération sur erreur pour gérer les problèmes temporaires de
réseaux et/ou serveurs
2009-2010
D. Millot
66
Services annexes : Job Manager Scheduler Support (condor, pbs, lsf) et
Reporter Scheduler Support associés, Simple CA, Replica, ...
65
2009-2010
D. Millot
67
Dépt. INF - INT
Globus 2
Dépt. INF - INT
Globus 2
Déploiement de globus
Synthèse sur globus 2
• Point forts
• Installation d’une machine (client et/ou serveur) :
– Installer GPT
– prise en compte effective de l’hétérogénéité
– Installer les packages choisis du globus Toolkit
– utilisation possible sur différents domaines d’administration
– Mettre en place le CA local
– extensibilité
– Mettre en place sur la machine un certificat hôte (et un certificat
pour chaque service utilisé si la machine est un serveur)
– dynamicité, adaptabilité
• Point faibles
– Démarrer les services (machine serveur seulement)
– l’utilisateur est responsable de la validité de l’environnement
d’exécution, et ses codes vont sans contrôle vers les ressources
• Utilisation à partir d’une machine client :
– Obtention d’un certificat personnel d’utilisateur auprès du CA,
stocké dans un répertoire .globus sous le $HOME de l’utilisateur
– “usine à gaz”
– Enregistrement dans le grid-mapfile de chaque ressource
– pas de standardisation pour l’invocation, la notification, etc
2009-2010
D. Millot
Dépt. INF - INT
– recours à des technologies hétérogènes
68
Globus 2
2009-2010
D. Millot
Dépt. INF - INT
70
Desktop Grids
Développements autour de globus
Calcul à grande échelle
• Environnements de développement
– Commodity Grid toolkits (CoG) pour Java, C/C++, Perl, Python
– MPICH-G2
• Introduction
– IBM Grid Toolbox
• Vers le calcul à grande échelle
• Projets de recherche et production
– EGEE (http://www.eu-egee.org) → gLite
• Calcul à grande échelle
– Eurogrid (http://www.eurogrid.org)
– Calcul global : desktop computing
– EU Datagrid (www.eu-datagrid.org)
– Modèles de programmation pour grille
– GriPhyN (http://www.griphyn.org)
– Services de grille
– Particle Physics Data Grid (http://www.ppdg.net)
2009-2010
D. Millot
69
2009-2010
D. Millot
71
Dépt. INF - INT
Desktop Grids
Dépt. INF - INT
Desktop grid de calcul distribué à grande échelle
Le coordinateur
- Récupération de cycles CPU inutilisés de PC volontaires
- Plusieurs millions de PC participants
• Son rôle :
- découpler totalement les clients et les workers
- coordonner l’exécution des tâches sur les workers
• SETI@home : Search for Extra Terrestrial Intellingence
• Ses actions :
- accepter les requêtes des différents clients
- transférer le code des applications quand c’est nécessaire
- distribuer les tâches selon une politique d’ordonnancement
- détecter les crashes/déconnections de workers
- relancer les tâches avortées sur des workers disponibles
- collecter et stocker les résultats
- délivrer les résultats aux clients sur requête
• BOINC (Berkeley Open Infrastructure for Network Computing) :
étude des changements climatiques, LHC@home, etc
http://boinc.berkeley.edu
• Folding@Home : repliement des protéines
http://folding.stanford.edu
• Decrypthon : cartographie des protéines
http://www.decrypthon.fr/
2009-2010
D. Millot
Dépt. INF - INT
72
Desktop Grids
2009-2010
requests
client
en
reg
serveur
coordinateur
results
i
en
em
str
d
co
t
e
Internet
results
dispo
PC volontaires
2009-2010
params
74
Desktop Grids
Calcul global et sécurité
• Objectifs de sécurité (Clients/Service/Participants) :
- intégrité/confidentialité des données (C)
- correction des résultats (C)
- intégrité de l’infrastructure (S)
- intégrité/confidentialité des ressources utilisées (P)
Interactions coordinator-workers
:
• enregistrement initial
⇒ download du code de
l’appli
• Sources potentielles de problèmes de sécurité :
- les clients qui soumettent des jobs (C)
- les participants qui proposent des ressources (cpu, fichiers, etc) (P)
- l’infrastructure interconnectant clients et participants (S)
- les applications exécutées sur les PC participants (C)
• notification de disponibilité
⇒ download des paramètres
• retour de résultat
D. Millot
D. Millot
Dépt. INF - INT
Exemple type d’organisation de calcul global : XtremWeb
applis
params
Desktop Grids
73
2009-2010
D. Millot
75
Dépt. INF - INT
Desktop Grids
Dépt. INF - INT
Desktop Grids
Desktop grid de partage de données à grande échelle
Calcul global : les risques
Récupération d’espace disque inutilisé de PC volontaires
• Stockage et accès aux données stockées sur les PC participants
• Risques pour un client (vis-à-vis des participants) :
- reverse engineering de son application par un participant
- espionnage de ses données, corruption de résultats...
• Principe du stockage :
– éclatement en segments stockés séparément
• Risques pour un participant :
- exécution d’autres applications que celles pour lesquelles il s’est
inscrit (i.e. usurpation de PC)
- abus de ressources par une application (e.g. disque...)
– réplication des segments pour augmenter la disponibilité
– récupération et intégration des segments depuis différentes
sources
Projets de recherche
- OceanStore (http://oceanstore.cs.berkeley.edu)
- Pastis (http://regal.lip6.fr/projects/pastis)
• Eléments de solution :
- certification de résultat, sandboxing...
2009-2010
D. Millot
Dépt. INF - INT
76
Desktop Grids
2009-2010
D. Millot
Dépt. INF - INT
Desktop grid de partage de fichiers à grande échelle
78
Desktop Grids
Calcul : desktop grid vs grille
• Partage des données en lecture
– les données sont immuables
Avantage à l’un ou l’autre selon le critère
⇒ pas de mécanisme de cohérence pour les copies multiples
• volatilité des ressources : desktop grid
• Stockage des fichiers
• protection des ressources : grille (certificats, log, révocation)
– les serveurs stockent des fichiers complets
• insensibilité à des attaques coordonnées : grille
– les clients agissent aussi comme serveur dans une logique
pair-à-pair
• scalabilité : desktop grid
• Accès à un fichier
• confidentialité : grille
– consultation d’un annuaire centralisé ou non (flooding, DHT)
• authentification : grille
⇒ obtention de l’adresse d’un serveur ou de pairs
• sécurité des informations (données, résultats) : grille
Napster, eMule, Kazaa, ...
2009-2010
D. Millot
77
2009-2010
D. Millot
79
Dépt. INF - INT
Desktop Grids
Dépt. INF - INT
Accès aux données : pair-à-pair vs client-serveur
Grid programming
Modèles de programmation pour la grille
Avantage à l’un ou l’autre selon le critère
• nombre d’utilisateurs que le système peut servir : P2P
Essentiellement quatre types de modèle pour l’instant.
• résistance aux défaillances : P2P (intègre la volatilité)
Par niveau croissant d’abstraction :
• latence d’accès : client-serveur
• Modèles à base de processus séquentiels communicants
• débit cumulé : P2P
• Modèles à base d’objets distribués
• scalabilité : P2P
• Modèles à base de composants
• cohérence : client-serveur
• Modèles à base de services
• sécurité : client-serveur
2009-2010
D. Millot
Dépt. INF - INT
80
Grid programming
Spécificités de la programmation sur grille
2009-2010
Dépt. INF - INT
Grid programming
Modèles séquentiels augmentés d’un mécanisme d’interaction entre
entités distribuées ; trois types d’implémentation :
• Shared space (Linda, Javaspaces Jini)
- le shared space correspond à une forme d’état global
- peut supporter H et D. Pas d’implémentation adressant S.
• H : Hétérogénéité (ressources de calcul, données...)
• D : Dynamicité (disponibilité, état, comportement...)
• I : Incertitude (dynamicité, pannes, état global...)
• Message passing (MPI, PVM)
- MPI ne supporte ni H ni D, sauf MPICH-G2 de globus (masque H)
et MPI-2 (introduit D), ni S car les processus sont supposés fiables
- pour I, quelques systèmes supportent la panne (i.e. arrêt) de
processus si les communications sont fiables
• S : Sécurité et confiance nécessaires (partage à travers des frontières
d’organisation...)
⇒ construire des applications capables de détecter (et de réagir à) des
changements d’état
⇒ composer des composants autogérables, aux comportements
fonctionnel et non-fonctionnel spécifiés indépendamment
D. Millot
82
Modèles à base de processus séquentiels communicants
Caractéristiques des environnements d’exécution et des applications à
prendre en compte pour la programmation sur grille :
2009-2010
D. Millot
• RPC
- supporte H, mais classiquement pas D ni S
81
2009-2010
D. Millot
83
Dépt. INF - INT
Grid programming
Dépt. INF - INT
Grid programming
RPC sur la grille
API GridRPC
• Gestion de handles de fonctions distantes
monitor
grpc_function_handle_init, grpc_get_handle
server
• Appel de fonctions et contrôle d’appels asynchrones
agent
database
grpc_call, grpc_call_async, grpc_probe, grpc_cancel
server
• Attente de retour d’appels asynchrones
...
scheduler
grpc_wait, grpc_wait_and, grpc_wait_or, grpc_wait_all,
grpc_wait_any
call
client
Plusieurs implémentations :
server
result
• Gridsolve (http://icl.cs.utk.edu/gridsolve) avec des sockets TCP/IP
• Ninf-G (http://ninf.apgrid.org) au-dessus de globus
Couplage possible avec OpenMP (cf OmniRPC)
• DIET (http://graal.ens-lyon.fr/DIET) au-dessus de corba
2009-2010
D. Millot
Dépt. INF - INT
84
Grid programming
2009-2010
Dépt. INF - INT
Standard émergeant de RPC sur grille : GridRPC
Grid programming
Interaction sécurisée entre objets distribués à l’aide d’un middleware
approprié (e.g. CORBA)
• function handle : mapping d’un nom de fonction sur une instance,
i.e. un serveur capable d’exécuter la fonction
• En plus des communications, support de :
- gestion du cycle de vie
- localisation/découverte
- interaction/synchronisation
- sécurité/défaillance
• session id : identificateur représentant un appel GridRPC non
bloquant ; utilisable pour vérifier l’état de l’appel, l’annuler, attendre
sa terminaison, interroger son code d’erreur
Modèle de programmation mixte qui autorise à la fois :
- parallélisme de tâches au niveau des appels asynchrones
- parallélisme de données au niveau des serveurs
Problèmes essentiels du RPC sur grille :
• support de H, D (liaison tardive au déploiement) et S
- gestion des données ⇒ persistance entre les étapes de calcul
- scalabilité
D. Millot
86
Modèles à base d’objets distribués
Un mécanisme RPC dédié à la grille et utilisant deux concepts clé :
2009-2010
D. Millot
• couplage fort entre objets interagissant
85
2009-2010
D. Millot
87
Dépt. INF - INT
Grid programming
Dépt. INF - INT
OGSA
java pour la grille : Proactive
De globus à la grille de services
Permet la programmation en java d’applications exploitables à la fois
dans un contexte parallèle, distribué et de mobilité
Grille : infrastructure (matérielle/logicielle) de partage de ressources
pour la résolution de problèmes de façon coordonnée au sein
d’organisations virtuelles multi-institutionnelles dynamiques caractérisée
par :
• active object : 1 thread et plusieurs objets passifs
• RMI asynchrones, variables futures avec wait-by-necessity
• communications de groupe ⇒ appel de méthode sur un groupe
d’objets actifs
• l’absence de contrôle et d’administration centralisés
• l’utilisation de protocoles et d’interfaces standard, ouverts
• migration entre JVM
• la fourniture de services de qualité non triviaux
• IC2D : Interactive Control & Debug for Distribution : visualisation
et gestion du mapping des objets actifs
⇒ ensemble intégré/extensible de services/ressources accessible
de n’importe où (virtualisation)...
http://www-sop.inria.fr/oasis/ProActive
Evolution vers un modèle hiérarchique/dynamique à base de composants
Fractal
2009-2010
D. Millot
Dépt. INF - INT
metacomputing → grille de ressources → grille de services
88
Grid programming
2009-2010
D. Millot
Dépt. INF - INT
Modèles à base de composants ou de services
90
OGSA
Services de grille
Convergence des besoins des applications scientifiques et e-business
service de grille = instance (persistante ou non) de service à état,
• Modèles à base de composants (CCM, JavaBeans)
– assemblage de composants réutilisables
supportant :
– comme Corba, support de H, S et D (instanciation dynamique)
mais interfaces et interactions fixées à la compilation
• l’invocation fiable et (si nécessaire) sécurisée,
• la gestion de la durée de vie,
• la notification des changements
• Modèles à base de services
→ une spécification en constante évolution : OGSA, qui s’appuie sur
– pour la construction (par composition) de systèmes à couplage
lâche et hautement dynamiques
• l’expérience du projet Globus
• les recherches d’IBM sur l’autonomic computing
2009-2010
D. Millot
89
2009-2010
D. Millot
91
Dépt. INF - INT
OGSA
Dépt. INF - INT
Objectifs d’OGSA (Open Grid Services Architecture)
Exemple de l’ordonnancement d’un job
• une sémantique unifiée de services de grille (service à état),
Etapes d’élaboration et de réalisation de l’ordonnancement d’un job :
• des mécanismes standard pour créer, nommer, découvrir des
instances de tels services (majoritairement non persistants)
• soumission du job (info sur les besoins en tâches, données, réseau)
• collecte d’informations statiques sur les ressources
• la transparence vis-à-vis de la localisation des services, et leur
liaison pour de multiples protocoles
• pré-selection de ressources
• requête d’infos dynamiques sur les ressources pré-sélectionnées (1)
• l’intégration des facilités natives des plates-formes utilisées
• requête sur l’accès aux données (disponibilité, ressources réseaux)
• la création et la composition facilitées de systèmes distribués
sophistiqués
• génération d’un ordonnancement et lancement des réservations
• la prise en compte de la gestion de la durée de vie, ainsi que la
gestion et la notification des changements
2009-2010
D. Millot
Dépt. INF - INT
OGSA
• itération sur (1) en cas d’échec
• délégation du suivi du job au superviseur
92
OGSA
2009-2010
D. Millot
94
Dépt. INF - INT
OGSA
Protocoles nécessaires pour les services de grille
Similitude avec les services Web
protocole : ensemble de règles utilisées par deux partenaires pour
échanger de l’information
service : protocole + comportement attendu en réponse aux différents
échanges de messages prévus par le protocole
Annuaire
de service
découverte
description de service
description de service
description de service
publication
Principaux protocoles pour une grille :
description de service
client
• protocoles pour assurer une connectivité sécurisée
→ authentification, communication
• protocoles pour le partage de ressources indépendantes
→ obtention d’informations, négociation de l’accès, gestion de
l’usage
D. Millot
association
Fournisseur
de service
service
service
WS : système logiciel à modalités d’utilisation (interfaces publiques/
liaisons) décrites en XML, identifié par URI et supportant l’interaction
machine-machine à travers un réseau (web transactionnel) ; assimilable à
un processeur de messages...
• protocoles d’utilisation coordonnée d’une collection de ressources
→ co-allocation, réplication de données, gestion de la charge, ...
2009-2010
Demandeur
de services
93
2009-2010
D. Millot
95
Dépt. INF - INT
OGSA
Dépt. INF - INT
Web Services Description Language (WSDL)
Caractéristiques des services Web
service Web : service persistant (assuré par des composants logiciels)
accessible par le web et techno-neutre, i.e. indépendant du :
Permet la description au niveau fonctionnel d’un service Web dans un
format normalisé traitable par une machine en spécifiant :
• langage de programmation
• un portType : ensemble d’opérations sur des messages (interfaces)
• modèle de programmation
• la nature du contenu des messages (documents ou requêtes RPC)
• système d’exploitation
• la structure de ces messages
La description d’un service Web (composants logiciels assurant le
service, méthodes d’accès et de découverte des fournisseurs du service)
est fondée sur les standards Internet (XML) et principalement :
• les séquences de messages échangés
Ces descriptions ont un double objectif :
• SOAP → interaction entre services
• permettre aux fournisseurs d’informer directement les clients
• WSDL → description fonctionnelle de services
• constituer les entrées d’annuaires UDDI
• WS-Inspection et UDDI → enregistrement et découverte de services
2009-2010
D. Millot
Dépt. INF - INT
96
OGSA
2009-2010
D. Millot
Dépt. INF - INT
Simple Object Acces Protocol (SOAP)
98
OGSA
Web Services Inspection Language (WS-I)
Fournit un moyen :
Permet l’enregistrement de services dans des répertoires centralisateurs
UDDI (Universal Description, Discovery and Integration) à travers :
• de formater une invocation de service Web
• l’association des différentes sources d’information concernant un
service :
• d’échanger des messages entre un fournisseur de service et un
demandeur de service
– descriptions fonctionnelles en WSDL,
reposant sur :
– références à des entrées de registres UDDI
• l’emballage XML d’informations (enveloppe, règles d’encodage)
• une grammaire XML facilitant l’aggrégation de références à
différents types de documents décrivant des services
• une convention de représentation des appels/réponses pour
l’invocation distante (RPC)
• le référencement et l’utilisation de dépôts de descriptions de services
indépendant du protocole de transport (HTTP, FTP, JMS, ...)
...Service Oriented Architecture Protocol ?
2009-2010
OGSA
D. Millot
⇒ moyen d’inspecter des sites pour consulter leur offre de services
97
2009-2010
D. Millot
99
Dépt. INF - INT
OGSA
Dépt. INF - INT
Invocation d’un service Web
OGSA
Architecture de services de grille
Modèle proposé par OGSA :
annuaire
• Un système est constitué à la fois de quelques services persistants et
de nombreux services non persistants créés à la demande (beaucoup)
UDDI
1. qui sait
• Ces services disposent tous à la fois d’un ensemble d’interfaces et de
comportements communs conformes aux spécifications de standards
(invocation fiable, gestion de la durée de vie, découverte,
notification, etc) et de comportements spécifiques.
2. A sait faire !
UDDI
faire X ?
?
je t’invoque
3. comment
WSDL
machine
cliente
serveur
4. lis ça !
• Interfaces dédiées à la gestion des instances de services : Factory
(création d’instances de service), Registry (enregistrement), ...
A
5. fais X !
Chaque service a un état à la fois consultable et modifiable, et dont les
changements peuvent être notifiés ⇒ gestion fiable et sécurisée d’un
état distribué du système.
SOAP
6. résultat de X !
2009-2010
D. Millot
100
Dépt. INF - INT
OGSA
2009-2010
D. Millot
Dépt. INF - INT
Implémentation type d’un service Web
102
OGSA
Caractéristiques OGSI d’un service de grille
• Description d’un service = serviceType (gwsdl, i.e. WSDL étendu) :
– définition des interfaces supportées (dont l’interface GridService)
et des données
HTTP engine/Web server
SOAP
engine
Request
transport
Response
SOAP
processing
• Interface = portTypes de WSDL + mécanisme d’héritage
– un ensemble d’opérations, définies en terme de messages
WS container
– un ensemble d’attributs ou Service Data Elements (SDE)
Service
dispatcher
• SDE = caractéristiques du service décrites en XML
Web service
– informations d’état du service,
– informations sur la version de l’implantation,
Administration & registry services
– infos de compatibilité de services en cas de maj d’interfaces, etc
• Instance = instantiation adressable de la description du service
⇒ chaque utilisateur peut utiliser des instances différentes
2009-2010
D. Millot
101
2009-2010
D. Millot
103
Dépt. INF - INT
OGSA
Dépt. INF - INT
Interface OGSI d’un service de grille
Autres interfaces OGSI de service de grille
PortType : GridService
Opération
Description
findServiceData
recherche d’infos sur le service → doc WS-I avec GSHs
setServiceData
modifications de valeurs de SDE
requestTermination
gestion de la date de terminaison
PortType
Opération
Description
Factory
createService
création d’instance → GSHandle
Registry
registerService
enregistrement de service
unregisterService
suppression de l’entrée
subscribe
abonnement aux notifications
NotificationSource
d’événements (push) d’un service
After/Before
destroy
terminaison
NotificationSink
deliverNotification
récupération d’infos d’état (pull)
HandleResolver
findByHandle
obtention d’une référence (GSR)
ServiceGroup
add
ajout d’entrée à un ServiceGroup
remove
suppression d’entrée
Registration
SDE
interface, serviceDataName, factoryLocator, gridServiceHandle,
Interfaces sans opérations :
gridServiceReference, findServiceDataExtensibility, setServiceDataExtensibility,
NotificationSubscription, ServiceGroup, ServiceGroupEntry
terminationTime
2009-2010
OGSA
D. Millot
Dépt. INF - INT
104
OGSA
2009-2010
D. Millot
Dépt. INF - INT
Accès à un service de grille (OGSI)
106
OGSA
Service Factory
• GSHandle = nom abstrait unique, global, stable :
Service de création de services non persistants qui appartiennent au client
– <scheme>://<hostname>[:<port>]/<path>/<GSInstanceID>
– retourné par l’opération de création de service (interface Factory)
• un Service Factory est un service persistant, sans état
– à mapper sur une référence (GSR) pour utiliser le service
−→ un get http sur GSH+”.wsdl” retourne une telle référence
• capable de créer des instances de services non persistants
(éventuellement avec état)
• reçoit de la part du client les paramètres nécessaires à l’instanciation
• GSReference = document en WSDL étendu, contenant toutes les
infos nécessaires pour communiquer avec le service et l’utiliser
(méthode d’accès, destination des messages, mode d’emploi) :
• chaque instance créée est associée/dédiée à un client et ne peut
interagir qu’avec celui-ci (cf GSI)
– référence du serviceType, spécif des liaisons (protocol bindings),
• l’instanciation est faite dans un environnement d’exécution
spécifique au client
– GSH et date d’expiration de la référence
– renouvelable par un service de mapping en cas d’expiration
2009-2010
D. Millot
105
2009-2010
D. Millot
107
Dépt. INF - INT
OGSA
Dépt. INF - INT
OGSA
Première version de globus compatible OGSI : GT3
Implémentation GT3 du GRAM (1/3)
client
registre
Version mixte mêlant composants WS et composants pre-WS
createService
publish
• introduction de composants Web Services et transition vers java
UserHE
MasterHE
• chaque service agit comme son propre GRIS (à travers les SDE)
⇒ plus de MDS
FSFS
stdout
stderr
FSS
Redirector
MMJFS
• les informations ex-MDS sont au format XML et non plus LDIF de
ldap, les descriptions RSL sont encapsulées en XML
GRIdMap
Scheduling
startUHE
grid−mapfile
launch
MJFS
MJS
system
• un registre gardant trace des instances est associé à chaque factory
Ressource
2009-2010
D. Millot
Dépt. INF - INT
108
OGSA
2009-2010
Dépt. INF - INT
Apports de GT3
OGSA
Le GRAM est implanté par cinq composants différents :
• Master Managed Job Factory Service (MasterHE)
• introduction d’un contexte d’exécution utilisateur (UHE, User
Hosting Environnement), propre à chaque utilisateur
– expose le service virtuel GRAM (permet la découverte)
– réoriente les requêtes vers le UserHE de l’utilisateur
• un UHE est créé sur une ressource s’il n’y en a pas déjà un pour
l’utilisateur à l’arrivée d’une requête
• Managed Job Factory Service (UHE)
– prépare la soumission de job à partir d’une spécification RSL sous
forme de document XML
• les instances de service d’un utilisateur s’exécutent dans l’UHE de
l’utilisateur, environnement d’accueil qui lui est propre sur chacune
des ressources utilisées
– paramètres de son opération createService :
in : document XML de spécification RSL
out : GSH pour le Managed Job Service (MJS) créé
• un service Managed Job Factory joue le rôle du gatekeeper dans
chaque UHE
D. Millot
110
Implémentation GT3 du GRAM (2/3)
• introduction d’un contexte d’exécution maître (MHE, Master
Hosting Environnement), commun à tous les utilisateurs
2009-2010
D. Millot
109
2009-2010
D. Millot
111
Dépt. INF - INT
OGSA
Dépt. INF - INT
Implémentation GT3 du GRAM (3/3)
WS-Resource Framework
Modélisation d’une ressource à état proposée par OASIS (Organization
for the Advancement of Structured Information Standards)
WS-Resource = WS + ressource à état
• Managed Job Service (UHE)
– opération : start
– SDE : job status, GSH pour stdout/stderr
• composition caractérisée par un ensemble de données d’état
exprimables sous forme d’un document XML (WS-R properties),
• File Stream Factory Service (UHE)
– prépare le streaming de stdout/stderr
• ayant un cycle de vie bien défini,
– paramètres de son opération createService :
• connue et manipulée par un (ou éventuellement plusieurs) WS.
in : url
out : GSH pour le FSS créé
Une WS-Resource est donc l’association d’un document XML de type
bien défini et d’un portType de WS.
• File Stream Service (UHE)
⇒ reformulation des concepts et interfaces définies par OGSI
(essentiellement qq messages changés ainsi que la sémantique associée)
– opération : startStreaming
2009-2010
OGSA
D. Millot
Dépt. INF - INT
112
OGSA
2009-2010
D. Millot
Dépt. INF - INT
Problèmes avec OGSI
114
OGSA
Spécifications du WS-Resource Framework
• WS-Resource Properties (cf service data elements de OGSI)
• trop d’aspects dans une seule spécification
– accès/modification de propriétés publiques des WS-ressources
• trop en avance sur les outils WS existant (utilisation agressive des
schémas XML, extension WSDL qui pose problème à JAX-RPC, etc)
• WS-Resource Lifetime (cf gestion OGSI de la durée de vie)
• trop orienté objet : notions d’état et d’instance de service mal
comprises ⇒ distinguer WS et ressources manipulées par le WS
• WS-Renewable References (cf GSH et GSR de OGSI)
– destruction immédiate/programmée de WS-R
– annotation d’une référence de WS-addressing endpoint pour
permettre le retrait d’une nouvelle référence
Ressource à état : ressource sensible à l’historique de ses manipulations
(e.g. fichier, tuple d’une BD relationnelle, Java Beans, etc)
⇒ nécessité de modéliser l’état dans un contexte WS : rendre ± visibles
les ressources à état impliquées dans une interaction avec un WS, en
rendant accessibles certaines propriétés de ces ressources ⇒ WS-RF.
2009-2010
D. Millot
• WS-Service Group
– accès à un groupe de services par un point d’entrée unique
• WS-BaseNotification (publish/subscribe pour une hiérarchie de
thèmes), WS-BaseFault...
113
2009-2010
D. Millot
115
Dépt. INF - INT
OGSA
Dépt. INF - INT
Des standards pour les grid services
OGSA
Développement de services avec GT4 : C WS Core
Le C WS Core est une boîte à outils en C pour la création de WS et de
clients conformes à WS-RF et WS-N. Elle comporte :
WSRF
WS−notification
• un conteneur de services autonome
UDDI*
WS−addressing
• une API pour l’immersion de services dans une application C
• une API Resource pour la gestion de ressources depuis un service
WSDL*
SCHEMAS*
• le support de clients et serveurs HTTP/1.1
SOAP*
DTD
• la génération, à partir de schémas WSDL, de stubs en C pur
(bloquants ou asynchrones)
XML*
noyau WS
• des modules de service chargeables dynamiquement
GT4 est disponible en version stable depuis l’été 2005
2009-2010
D. Millot
Dépt. INF - INT
116
OGSA
2009-2010
Dépt. INF - INT
Une version de globus compatible WSRF : GT4
OGSA
• gestion de données distribuées (fichiers ou BD) :
accès, transaction, gestion de réplicats, déplacement
• Web Services Resource Framework (WSRF)
• workflow :
exécution coordonnée de tâches multiples sur de multiples ressources
• Web Service Notification (WSN) qui remplace source/sink
Spécifie également de nouveaux composants :
• audit :
enregistrement de données d’utilisation, contrôle (fraude, intrusion)
• WS Authentication Authorization remplace GSI et se compose de :
– Message level security : WS-Security et WS-SecureConversation
(encryptage des messages SOAP, intégrité, et protection contre
le replay)
• instrumentation et monitoring :
découverte de capteurs, génération d’alertes en cas de problème
• localisation de problèmes :
dump, traces, log avec marquage d’événements et corrélations
– Authorization framework : différents schémas d’autorisation
(grid-mapfile, access control lists (ACL), custom authorization
handlers via le protocole SAML).
D. Millot
118
Évolution vers des services de plus haut niveau
GT4 implante deux nouveaux standards (dans le WS Core) :
2009-2010
D. Millot
• autonomic computing ?
117
2009-2010
D. Millot
119
Dépt. INF - INT
OGSA
Dépt. INF - INT
Comparaison avec CORBA, EJB, J2EE ou DCOM
Vers une gestion scalable des utilisateurs
– interfaces standard d’accès à des ressources,
Non passage à l’échelle du mapping des certificats sur des comptes
locaux pour l’accès des utilisateurs aux ressources des grilles
=> Virtual Organisation Management System proposé par gLite
– mécanisme d’invocation distante,
– service de recherche et découverte d’instances
• Avantage des technologies de grille :
Définition de VO regroupant des utilisateurs et des ressources
– mécanismes de partage complétement dynamiques, non limités à
une seule et même organisation, orientés grande échelle (web).
• enregistrement d’un utilisateur auprès de différentes VO
→ adhésion, appartenance à un groupe de la VO, rôle
– forme d’interaction non limitée au client-serveur mais orientée
vers l’utilisation coordonnée de ressources multiples.
• enregistrement d’une ressource auprès de différentes VO
→ association d’un pool de comptes à chaque VO
– techno-neutre (utilisation systématique de XML)
– transport par http qui franchit sans problème les pare-feux
voms-proxy-init : création de certificat de proxy comportant des infos
supplémentaires liées à la VO
=> mapping automatique sur un compte du pool
2009-2010
D. Millot
Dépt. INF - INT
Grilles
– abstration des utilisateurs et des ressources
Peer-to-peer/Desktop grid computing : a priori plus limités
120
Grilles
2009-2010
D. Millot
Dépt. INF - INT
122
Grilles
Problèmes à résoudre pour les grilles
Normalisation/industrialisation des services de grille
• Open Grid Forum (OGF) (http://www.ogf.org)
• déploiement et maintenance d’intergiciel sur des centaines ou
milliers de nœuds
• IBM :
– Grid Toolkit basé sur globus avec documentation et scripts
utilisateur, optimisé pour l’architecture eServer sous AIX ou linux
• localisation de services, interopérabilité
– technologie grille dans des produits (DB2, WebSphere, stockage)
• accès aux données à travers des réseaux longue distance
– solution “Grid and Grow Express”
• performances, QoS, dynamicité
– élément clé de la stratégie “on demand”
• sûreté de fonctionnement, tolérance aux défaillances
• Parabon (Frontier, Pioneer)
• accès aux informations sur les travaux en cours
• United Devices (Grid MP, Enterprise/on Demand/Global)
• mesure et facturation des ressources consommées
• GridXpert (intégré à United Devices), DataSynapse, univa...
2009-2010
D. Millot
121
2009-2010
D. Millot
123
Dépt. INF - INT
Perspectives du calcul à grande échelle
Dépt. INF - INT
Grandes tendances
Logiciel : conjuguer efficacité/portabilité
Perspectives du calcul à grande échelle
• des mécanismes qui court–circuitent le système :
– processus légers, communications légères
• Grandes tendances
• des solutions faciles à maîtriser et/ou efficaces :
– Matériel : vers des architectures modulaires, hybrides et
extensibles
– modèle data-parallel pour les applications régulières
– modèle shared-variables pour les applications irrégulières
– Logiciel : conjuguer efficacité et portabilité
– modèle message passing pour les applications à gros grain
• une bonne portabilité à travers des standards reconnus et implantés
efficacement :
• Directions de recherche
– maîtriser le passage à l’échelle
– HPF, OpenMP, MPI
– maîtriser l’hétérogénéité
Mais... pas encore de modèle de programmation hybride !!!
2009-2010
D. Millot
Dépt. INF - INT
124
Grandes tendances
2009-2010
D. Millot
Dépt. INF - INT
Matériel : vers des architectures hybrides/extensibles
126
Directions de recherche
Directions de recherche
• des composants performants à moindre coût :
– processeurs intégrant des mécanismes de cohérence
Subsistent des problèmes difficiles ou imparfaitement résolus :
– cartes multiprocesseur, processeurs multicœur, GPGPU
• traitement efficace des applications irrégulières,
– réseaux rapides (faible latence, haut débit)
• gestion d’un état global sur grappe et grille
⇒ point de reprise, debugging,
– intégration renforcée de l’interface de communication
• organisation physique orientée extensibilité :
– mémoire distribuée (grappes)
• déploiement et maintenance de grappes, d’applis sur grappes,
– regroupement hiérarchisé de machines (clumps)
• ordonnancement d’applications sur grille,
• le logiciel peut a priori estomper certaines différences :
• prise en compte des multi-cœurs et passage à la grande échelle
– send/recv supporté sur machine EAU (utilisation de buffers)
• modèle de programmation hybride...
– shared virtual memory sur architectures EAM (DSM)
2009-2010
D. Millot
125
2009-2010
D. Millot
127