View
107
Download
2
Category
Tags:
Preview:
Citation preview
Supports d’exécution parallèles et répartis
Raymond NamystLaBRIUniversité de Bordeaux I
Jean-François MéhautGRIMAAGUniversité des Antilles-Guyane
Plan
Introduction Supports d’exécution, environnements,
middlewares, intergiciels, …
Communications dans les grappes (RN) Technologies, interfaces, hétérogène,…
Multithreading (JFM) Rappels, exploitation des SMP, …
Grilles de calcul (JFM) Toolkit Globus, gestion de ressources,…
Programmation parallèle et répartie
Conception Modélisation Algorithmique Langage Compilation
Exécution Gestion d’activités Communications Mise au point Régulation de charge Gestion de données Sécurité …
Application
Programme parallèle
Proc. 0 Proc. 1 Proc. 2 Proc. 3
Supports et environnements d’exécution (1)
Pour les utilisateurs et leurs applications Abstractions de haut niveau Portabilité Efficacité !
Support d’exécution
Grappes, grilles, machines parallèles, réseaux,…
Systèmes d’exploitation (OS)
Interface de programmation (API)
Applications
Supports et environnements d’exécution (2)
Etendre et spécialiser les OS Centralisés et complétés pour le “distribué” Nouveaux modèles (tâches, communication, fichiers,…) Exemple: Stockage de fichiers, réplication, cache, …
Support d’exécution
Grappes, grilles, machines parallèles, réseaux
Systèmes d’exploitation (OS)
Interface de programmation (API)
Applications
Discussions
Souplesse par rapport à des développement au niveau système
Définition d’interface standard Exemples: POSIX Threads, MPI, CORBA,
OpenMP… Difficulté de faire évoluer les standards
Implémentation basée sur des standards Exemple: Globus-MDS basé sur LDAP
Compromis à trouver
Fonctionalités
Portabilité Efficacité
X
PM2 : support pour les grappes
Légende Marcel : noyau de processus légers Madeleine : module de communication
Marcel PM2 Madeleine
Architecture (grappes, machines parallèles)
Unix (~10 versions)
Interface de programmation (RPC, migration, allocation iso-adresse)
Régulation HPF, C* C++//, Java
Applications
Globus : support pour les grilles
Applications
Boite à outils Application
DUROC globusrunMPI Nimrod/GCondor-G HPC++
GlobusView Testbed Status
Base de la Grille
LSF
Condor MPI
NQEPBS
TCP
NTLinux
UDP
Solaris DiffServ
Services de la GrilleGRAM
GSI HBM
Nexus
I/O GASSGSI-FTPMDS
Communications dans les grappes hautes performances
Raymond NamystLaBRIUniversité de Bordeaux I
Plan
Technologies matérielles Ethernet, Myrinet, SCI
Interfaces de bas niveau BIP, SISCI, VIA
Interfaces de haut niveau MPI et les communications irrégulières
Interfaces de niveau intermédiaire FM, Madeleine
Vers les grappes hétérogènes…
Technologiesmatérielles
Cartes passives, actives,réseaux à capacité d’adressage
(Fast|Giga)-Ethernet
Interconnexion Hub ou switch
Câblage Cuivre ou fibre optique
Latence ~20 µs
Débit 100 Mb/s et 1Gb/s
Note Compatibilité avec l’Ethernet classique
Hub
Switch
Ethernet
Cartes passives (sauf Giga-Ethernet) Interfaces : TCP, SBP, GAMMA, VIA, …
Network
TX reg
RX reg
Packet InterfacePacket InterfacePCI
Bridge
PCI
Bridge
PCI Bus
DMADMA
Memory
TX-ring
NIC
Myrinet
Société Myricom (C. Seitz) Interconnexion
Switch
Câblage Nappes courtes
Cartes équipées d’un processeur Latence
1~2 µs
Débit 1 Gb/s
Note Durée de vie limitée des messages (50 ms)
LANai
Myrinet
Routage Réseau commuté, routage wormhole
Carte programmable Protocoles de transmission « intelligents »
Stratégie adaptée à la taille des messages Déclenchement d’interruptions
NetworkRISC
Packet
Interface
DMADMA
PCI
Bridge
PCI
Bridge
PCI Bus
LANai
SRAMSRAM
NIC
SCI
Scalable Coherent Interface Norme IEEE (1993) Société Dolphin
Fonctionnement par accès mémoire distants Projections d’espaces d’adressage
Machine A Machine B
Réseau SCI
Mémoire
MémoireBus PCI Bus PCI
Carte à capacité d ’addressage
BUS PCI
TLB
Interface
paquetPaquet
SCI
Pci req:
addr+data
BUS PCI
TLB
Interface
paquet
Paquet SCI
Pci req:
addr+data
Partie émission Partie réception
Adressage à distance
Projections effectués par le pilote (SISCI) Zones de mémoire physiques souvent spécifiques
Accès mémoire effectués par le processeur Le processeur distant n’est pas (forcément)
interrompu
Interconnexion SCI
Processus A
Espace d'adressage
virtuel
Bus PCI
PCI-SCI
Processus B
Espace d'adressage
virtuel
Bus PCI
PCI-SCI
Mémoire physique
SCI : mécanisme d’adressage
Adresse Virtuelle 32 bits
MMU
Adresse Physique (E/S)
Bus d’E/S
32 bits
10 bits 18 bits
Table de Translationdes Adresses
16 bits 30 bits 18 bitsDestinataire
Réseau
30 bits 18 bits
Réseau
Adresse Physique (E/S)
Bus d’E/S
32 bits
Mémoire
SCI : mécanisme d’adressage
SCI : performances
Latence : 2.5 s (écriture de processus à processus) Débit : 45 Mo/s Verrou : < 10 s (fetch&add)
Interfaces de bas niveau
BIP, SISCI, VIA
Communications performantes
Comment exploiter les réseaux rapides ? Faible latence
Quelques microsecondes
Bande passante élevée De l’ordre du Gb/s
Tendance actuelle Interaction directe avec la carte réseau
Communication en « mode utilisateur »
Transmissions zéro-copie La carte récupère/dépose les données au bon endroit
Interfaces
Initialisation Réservée au système Uniquement en
début de session
Transferts Directs depuis
l’espace utilisateur Pas d’appels
systèmes Pas de transitions Transmissions zéro-
copie
Interface
Programme
Réseau
Système
Espace utilisateur
TransfertsInitialisation
Streamline Buffer Protocol
UNH (R. Russell & P. Hatcher) Principe
Partage de tampons entre noyau/processus Tampons préformatés (trames ethernet)
Deux jeux de files de tampons : RQ & SQ Performances (Linux, P133)
Latence : 24 us, débit : ~ 12 Mo/s
Basic Interface for Parallelism: BIP
L. Prylli & B. Tourancheau Principe
Envoi de message “classique” (asynchrone) Pas de contrôle de flux Pas de detection d’erreur
Performances Latence : 4.8us, débit : 126 Mo/s
BIP
Fonctionnalités réduites au minimum Messages courts : recopiés à l’arrivée Messages longs : mode zéro-copie (RDV)
Contrôle de flux minimal Matériel (msgs “évaporés” au dela de 50ms)
Interface Dolphin pour SCI
Deux niveaux : Interface orientée “fichiers projetés” Interface orientée “VIA” (cf + loin)
Fichiers projetés Utilisation de “mmap”
Synchronisation Segments spéciaux “fetch & add”
SISCI: principe
Communications Accés mémoire distants
Implicites (après projection) Explicites (remote DMA)
Support matériel pour une MVP (?)
Performances Ecriture 2 us, lecture 4 us Bande passante 85 Mo/s (difficilement !)
SCI : optimisations matérielles
Caches dans la carte : Read Prefetching Write Combining
Interconnexion SCI
Processus A
Espace d'adressage
virtuel
Bus PCI
PCI-SCI
Processus B
Espace d'adressage
virtuel
Bus PCI
PCI-SCI
Mémoire physique
Conséquences
Une Grappe SCI est une NC-NUMA Non-Coherent Non-uniform Memory Arch. Cohérence séquentielle non vérifiée
Plus gênant : ordre des écritures modifié Pb d’atomicité des transactions PCI Assez inhabituel (?)
VIA
Virtual Interface Architecture
Tentative de standardisation Beaucoup d’industriels impliqués
Caractéristiques Principe d’interfaces virtuelles Zones de transmission protégées Lectures/Ecritures distantes
VIA: Basic Principles
Use the Kernel for Set-Up……and Get It Out of the Way for Send/Receive!
The “Virtual Interface” (VI) Protected Application-Application Channel Memory Directly Accessible by User Process
Target Environment LANs and “SAN”s at Gigabit Speeds No Reliability of Underlying Media Assumed
VI Architecture
VI Consumer
VI User Agent (“libvia”)O
pen,
Con
nect
, M
ap M
emor
y
Descriptor Read, Write
VI-Capable NIC
Sockets, MPI,Legacy, etc.
RequestsCompleted
VI VI C
S S S COMP
R R R
VI
Do
orb
ells
Und
eter
min
ed
VI Kernel Agent (Slow) User-Level (Fast)
Host
NIC
VI Kernel Agent
A Privileged Part of Operating System (driver)Usually supplied by the VI NIC vendor Possibly supplied by research groups (UCB,…)
Setup and Resource Management FunctionsCreation/Destruction of VisVI Connection setup/tear-downManagement of System Memory used by the VI NIC
A Virtual Interface
VI Consumer
VI-Capable NIC
Descriptor
Descriptor
Send Q
Sen
d D
oo
rbel
l
Descriptor
Descriptor
Recv Q
Rec
eive
Do
orb
ell
Status Status
Descriptors
Descriptors Contain: Address and Length of Data Buffer Status Fields Memory Protection Information Multiple Segments to Allow Scatter/Gather etc., etc., etc.
A minimum of 45 bytes long Many messages may only be a few bytes...
Queues and Doorbells
Queues of DescriptorsTransmit and ReceiveCompletions and Errors May Reside on Host or NIC (Unspecified)
Doorbells“Addresses” of Descriptors, Small and FastAllows NIC to Use Descriptors…Future “VIA-NICs” May Have Hardware Support
Memory Registration
Data buffers and descriptors must reside within a region of “registered memory”
Call VipRegisterMemory Pins the specified pages into physical memory Communicates the addresses to the NIC
To allow DMA I/O from the NIC
Ce qu’il faut retenir
Interfaces de très bas niveau ! Fonctionnalités proches du matériel
Grande efficacité Paradigmes très différents Approche non généralisable
Pas de consensus Tentative de standard : VIA
- Virtual Interface Architecture (Intel, Microsoft, Compaq)- But : dénominateur commun- Bas niveau, peu adapté à certaines technologies
Portabilité ???
Interfaces de haut niveau
MPI : la solution idéale ?
Bibliothèques
Paradigme passage de message Les nœuds se synchronisent et communiquent
par messages
Deux instructions de base Send émission d’un message Receive réception d’un message
Points forts Simple à mettre en oeuvre Permet d’émuler les autres paradigmes
PVM
Parallel Virtual Machine Laboratoire National d’Oak Ridge (Tennessee) 1989
Caractéristiques Notion de machine virtuelle
Ensemble de machines physiquesConstruction préalable au lancement de la session
Disponibilité très large Réseaux
UDP + protocole de réémission Support de l’hétérogénéité
XDR
MPI
Message Passing Interface MPI-Forum v1.0 1994 v2.0 1997
Caractéristiques Un standard, pas une bibliothèque Diverses implémentations
MPI-CHLAM-MPI…
Supplante PVM Version 2.0 encore peu implémentée
MPI répond-t-il aux besoins ?
Implantations efficaces existantes MPICH/BIP, MPICH/SISCI, etc.
Quid des schémas de communication de la vraie vie ?
Messages dont le contenu est inconnu a priori par le récepteur
- Transmissions zéro-copie ? Messages asynchrones
- Recouvrement des communications ? Accès mémoire distants (PUT/GET)
- Temps de réponse ?
Transmissions zéro-copie
Processus A Processus BRéseau
Préparation mémoire
Acquittement
Message
EntêteDonnées
DMA
Et la réactivité alors ?
Problèmes Assurer la progression des communications
asynchrones Réagir rapidement aux sollicitations extérieures
procproc proc proc
réseau
Envois asynchrones
Parvient-on vraiment à assurer du recouvrement ?
Processus A Processus B
Acquittement
MPI_Isend
MPI_recv
MPI_test
Interfaces deniveau intermédiaire
Madeleine : principe et interface
Madeleine
Interface de communication Efficace et portable
Double objectif Support de multiples paradigmes/modes Support de multiples réseaux simultanément
Proposition Programmation par « contrat »
Contrôle du niveau d’optimisation Transferts immédiats possibles
Statut Disponible sur BIP, SISCI, TCP et MPI. Portage en cours sur VIA
Construction des messages
Gestion des canaux (~ communicators) Choix explicite du dispositif physique
Interface
mad_begin_packing
mad_pack
mad_end_packing
mad_begin_unpacking
mad_unpack
mad_end_unpacking
Packing et Unpacking
Commandes : mad_pack (cnx, buffer, len, pack_mode, unpack_mode) mad_unpack (cnx, buffer, len, pack_mode, unpack_mode)
Modes :
Send_SAFER
Send_CHEAPER
Send_LATER
Receive_EXPRESS
Receive_CHEAPER
Emission : modes d’empaquetage
Version transmise
Pack
Modification
End_packing
Send_SAFER Send_LATER Send_CHEAPER
Réception : mode de déballage (1)
Unpack
Après Unpack
End_packing
Tampon
Données disponibles
RECV_EXPRESS
Réception : mode de déballage (2)
RECV_CHEAPER
Unpack
Après Unpack
End_packing
Tampon
Données disponibles ???
Données disponibles
Exemple
mad_end_unpacking(cnx);
send_CHEAPER,receive_CHEAPER);
mad_unpack(cnx, s, n,
s = malloc(n);
send_CHEAPER,receive_EXPRESS);
mad_unpack(cnx, &n, sizeof(int),
cnx = mad_begin_unpacking(channel);
p_mad_connection_t cnx;
char *s = NULL;
int n;
mad_pack(cnx, s, n,
send_CHEAPER, receive_CHEAPER);
mad_end_packing(cnx);
send_CHEAPER, receive_EXPRESS);
mad_pack(cnx, &n, sizeof(int),
n = strlen(s) + 1;
cnx = mad_begin_packing(channel, dest);
p_mad_connection_t cnx;
char *s = "Hello, World !";
int n;
Sending side Receiving side
Exemple
mad_end_unpacking(cnx);
send_CHEAPER,receive_CHEAPER);
mad_unpack(cnx, s, n,
s = malloc(n);
send_CHEAPER,receive_EXPRESS);
mad_unpack(cnx, &n, sizeof(int),
cnx = mad_begin_unpacking(channel);
p_mad_connection_t cnx;
char *s = NULL;
int n;
mad_pack(cnx, s, n,
send_CHEAPER, receive_CHEAPER);
mad_end_packing(cnx);
send_CHEAPER, receive_EXPRESS);
mad_pack(cnx, &n, sizeof(int),
n = strlen(s) + 1;
cnx = mad_begin_packing(channel, dest);
p_mad_connection_t cnx;
char *s = "Hello, World !";
int n;
Sending side Receiving side
Exemple
mad_end_unpacking(cnx);
send_CHEAPER,receive_CHEAPER);
mad_unpack(cnx, s, n,
s = malloc(n);
send_CHEAPER,receive_EXPRESS);
mad_unpack(cnx, &n, sizeof(int),
cnx = mad_begin_unpacking(channel);
p_mad_connection_t cnx;
char *s = NULL;
int n;
mad_pack(cnx, s, n,
send_CHEAPER, receive_CHEAPER);
mad_end_packing(cnx);
send_CHEAPER, receive_EXPRESS);
mad_pack(cnx, &n, sizeof(int),
n = strlen(s) + 1;
cnx = mad_begin_packing(channel, dest);
p_mad_connection_t cnx;
char *s = "Hello, World !";
int n;
Sending side Receiving side
Exemple
mad_end_unpacking(cnx);
send_CHEAPER,receive_CHEAPER);
mad_unpack(cnx, s, n,
s = malloc(n);
send_CHEAPER,receive_EXPRESS);
mad_unpack(cnx, &n, sizeof(int),
cnx = mad_begin_unpacking(channel);
p_mad_connection_t cnx;
char *s = NULL;
int n;
mad_pack(cnx, s, n,
send_CHEAPER, receive_CHEAPER);
mad_end_packing(cnx);
send_CHEAPER, receive_EXPRESS);
mad_pack(cnx, &n, sizeof(int),
n = strlen(s) + 1;
cnx = mad_begin_packing(channel, dest);
p_mad_connection_t cnx;
char *s = "Hello, World !";
int n;
Sending side Receiving side
Exemple
mad_end_unpacking(cnx);
send_CHEAPER,receive_CHEAPER);
mad_unpack(cnx, s, n,
s = malloc(n);
send_CHEAPER,receive_EXPRESS);
mad_unpack(cnx, &n, sizeof(int),
cnx = mad_begin_unpacking(channel);
p_mad_connection_t cnx;
char *s = NULL;
int n;
mad_pack(cnx, s, n,
send_CHEAPER, receive_CHEAPER);
mad_end_packing(cnx);
send_CHEAPER, receive_EXPRESS);
mad_pack(cnx, &n, sizeof(int),
n = strlen(s) + 1;
cnx = mad_begin_packing(channel, dest);
p_mad_connection_t cnx;
char *s = "Hello, World !";
int n;
Sending side Receiving side
Exemple
mad_end_unpacking(cnx);
send_CHEAPER,receive_CHEAPER);
mad_unpack(cnx, s, n,
s = malloc(n);
send_CHEAPER,receive_EXPRESS);
mad_unpack(cnx, &n, sizeof(int),
cnx = mad_begin_unpacking(channel);
p_mad_connection_t cnx;
char *s = NULL;
int n;
mad_pack(cnx, s, n,
send_CHEAPER, receive_CHEAPER);
mad_end_packing(cnx);
send_CHEAPER, receive_EXPRESS);
mad_pack(cnx, &n, sizeof(int),
n = strlen(s) + 1;
cnx = mad_begin_packing(channel, dest);
p_mad_connection_t cnx;
char *s = "Hello, World !";
int n;
Sending side Receiving side
Exemple
mad_end_unpacking(cnx);
send_CHEAPER,receive_CHEAPER);
mad_unpack(cnx, s, n,
s = malloc(n);
send_CHEAPER,receive_EXPRESS);
mad_unpack(cnx, &n, sizeof(int),
cnx = mad_begin_unpacking(channel);
p_mad_connection_t cnx;
char *s = NULL;
int n;
mad_pack(cnx, s, n,
send_CHEAPER, receive_CHEAPER);
mad_end_packing(cnx);
send_CHEAPER, receive_EXPRESS);
mad_pack(cnx, &n, sizeof(int),
n = strlen(s) + 1;
cnx = mad_begin_packing(channel, dest);
p_mad_connection_t cnx;
char *s = "Hello, World !";
int n;
Sending side Receiving side
Interfaces deniveau intermédiaire
Madeleine : implantation
Proposition
Interface
Gestion des
tampons
Gestionde
protocole
UnpackPack
ReceiveSend
Madeleine – structure
BMM1 BMMn
TM1 TMn
Network
Application
Generic BufferManagement
ModulesSwitch
Selection
BMM1 BMMm
TM1 TMn
Application
Switch
Selection
Specific Transmission Modules
Adaptativité
Sélection du mode de transmission adéquat
Interface
Gestion des
tampons
Gestionde
protocole
Pack
??
Implementation
Madeleine II a été portée sur : SISCI/SCI BIP/Myrinet MPI VIA TCP SBP
BIP/Myrinet
Latency: Madeleine II/BIP
0
2
4
6
8
10
12
0 64 128
Packet size (bytes)
Lat
ency
(µ
s)
Latency: Madeleine II/BIP
0
2
4
6
8
10
12
0 64 128
Packet size (bytes)
Lat
ency
(µ
s)
BIP/Myrinet
Bandwidth: Madeleine II/BIP
0
20
40
60
80
100
120
4 16 64 256
1024
4096
1638
4
6553
6
2621
44
1048
576
Packet size (bytes)
Ban
dw
idth
(M
B/s
)
Bandwidth: Madeleine II/BIP
0
20
40
60
80
100
120
4 16 64 256
1024
4096
1638
4
6553
6
2621
44
1048
576
Packet size (bytes)
Ban
dw
idth
(M
B/s
)
SISCI/SCI
Latency: Madeleine II/SCI
0123456789
10
0 64 128
Packet size (bytes)
Lat
ency
(µ
s)
Latency: Madeleine II/SCI
0123456789
10
0 64 128
Packet size (bytes)
Lat
ency
(µ
s)
SISCI/SCI
Bandwidth: Madeleine II/SCI
0
10
20
30
40
50
60
70
80
90
1 4 16 64 256
1024
4096
1638
4
6553
6
2621
44
1048
576
4194
304
1,7E
+07
Packet size (bytes)
Ban
dw
idth
(M
B/s
)
Bandwidth: Madeleine II/SCI
0
10
20
30
40
50
60
70
80
90
1 4 16 64 256
1024
4096
1638
4
6553
6
2621
44
1048
576
4194
304
1,7E
+07
Packet size (bytes)
Ban
dw
idth
(M
B/s
)
Quelques résultats
Latence 7 µs sur BIP/Myrinet 4 µs sur SISCI/SCI
Bande passante 125 Mo/s sur BIP/Myrinet 80 Mo/s sur SISCI/SCI
Migration (PM2) 24 µs sur SISCI/SCI 52 µs sur BIP/Myrinet
MPICH/Madeleine II
MPICH: general-purpose portable MPI implementation well-defined protocol interface Abstract Device
Madeleine: cluster-specific high-performance communication generic structure available on Gigabit networks highly optimized implementation
The best of both worlds! Madeleine as a MPICH device
MPICH/Madeleine II
MPI API
ADI
ProtocolInterface
Generic part (collective operations, context/group management, ...)
Generic ADI code, datatype management, request queues management
SMP_PLUG device
intra-node communication
CH_SELF device
self communication
CH_MAD device
inter-node communication
polling loopseager protocol rendez-vous-
protocol
Madeleine II
multi-protocol management
Fast-Ethernet SCI Myrinet
TCP SISCI BIP
Latency
Comparison: various MPI/SCI implementations
0
5
10
15
20
25
30
35
40
1 10 100 1000
Packet size (bytes)
Lat
ency
(µ
s)
SCI-MPICH
SCA-MPI
MPI/ MadII/ SCI
Comparison: various MPI/SCI implementations
0
5
10
15
20
25
30
35
40
1 10 100 1000
Packet size (bytes)
Lat
ency
(µ
s)
SCI-MPICH
SCA-MPI
MPI/ MadII/ SCI
Bandwidth
Comparison: various MPI/SCI implementations
0
10
20
30
40
50
60
70
80
1 4 16 64 256
1024
4096
1638
4
6553
6
2621
44
1048
576
Packet size (bytes)
Ban
dw
idth
(M
B/s
)
SCI-MPICH
SCA-MPI
MPI/ MadII/ SCI
Comparison: various MPI/SCI implementations
0
10
20
30
40
50
60
70
80
1 4 16 64 256
1024
4096
1638
4
6553
6
2621
44
1048
576
Packet size (bytes)
Ban
dw
idth
(M
B/s
)
SCI-MPICH
SCA-MPI
MPI/ MadII/ SCI
Vers les grappes degrappes
Objectifs
Support des grappes de grappes Communications hétérogènes Transparence Efficacité du routage sur les machines
« passerelles » Minimisation des copies Maintien du débit par techniques de pipeline Utilisation des threads !
PC/MyrinetPC/SCI
Réseau rapide
PACX-MPI
2 nœuds sacrifiés pour les communications
Transparence pour l’application
Protocole TCP/IP entre les grappes
MPI MPI
TCP
Globus
Principe : Appel de Procédure à Distance Librairie de communication : Nexus
Multiprotocole Multithreading non nécessairement préemptif La passerelle est sacrifiée
Tout est à faire par l’utilisateur Pas de gestion explicite des grappes de grappes
Pas adapté au problème
Madeleine II
Bibliothèque de communication Multiprotocole Canaux de communication indépendants Un canal correspond à un adaptateur réseau
Canal TCP
Canal TCP
Canal SCI
Structure interne
Couche générique de gestion de tampons Couche de portabilité avec les protocoles
Réseau
Application
MGT1 MGTnMGT2
MT1 MTnMT2
Structure interne
MGT1 MGTn
MT1 MTn
Réseau
Application
Couche de
gestion de tampons
Couche de portabilité
Aiguillage
Sélection
MGT1 MGTn
MT1 MTn
Réseau
Application
Aiguillage
Sélection
Structure (suite)
Organisation des données Madeleine : données globales Driver : spécifique à un protocole Adapter : virtualisation d’une carte réseau Channel : isolation des communications Connection : connexion point à point Link : virtualisation d’une méthode de transfert
Ce qui manque
Utilisation de réseaux qui ne sont pas présents sur tous les nœuds
Envoi de messages entre des machines non directement reliées
SCI Myrinet
Intégration dans Madeleine
MTs : pas portable
MGTs : problèmes de conversion
Au-dessus : perte d’efficacité
Application
MGT1 MGT2 MGTn
MT1 MT2
Réseau
Solution retenue
MT générique entre les MTs et les MGTs
Pas de MGT au niveau de la passerelle MT générique
MGT1 MGT2 MGTn
MT1 MT2
Réseau
Application
Canaux virtuels
Contiennent plusieurs canaux réels
Permettent de séparer les messages à retransmettre des messages normaux (canaux réels différents)
1 2 3 4
Canaux SCI
Canaux Myrinet
Canal spécial
Canal normal
Canal
virtuel
Réactivité et parallélisme
Retransmission des messages par des threads dédiés Une paire de threads par réseau physique Mécanisme de pipeline
Réception des messages normaux sur la passerelle Pas d’informations à priori sur la provenance Threads de scrutation
Principe de la passerelle
Application
Threads de
retransmission
Thread de scrutation
SCI
Myrinet
Tests de performances
Ping-pong entre 2 machines séparées par une passerelle
SCI Myrinet
321
Évaluation
SCI
BIP
BIP/SCI Avec une passerelle
Bande passante
80 Mo/s
116 Mo/s
41 Mo/s
Latence
5,3 μs
7,8 μs
32,5 μs
Intégration des threadset des communications
Réactivité des nœuds aux E/S
Progression des communications
Problème Comment assurer la progression des
communications ?
procproc proc proc
réseau
Scrutation et interruptions
La scrutation est nécessaire API réseau ne fournissant pas d’appels bloquants OS ne fournissant pas “d’activations”
Problème Fréquence difficile à assurer Coûteux en présence de multiple “pollers ”
Les interruptions sont nécessaires Réactivité
Problème Outils de synchronisation “interrupt safe” ?
Support de l’ordonnanceur
Ordonnanceur = serveur de scrutation Choix de la méthode d’accès (scrutation/intr.)
Support pour la scrutation Fréquence contrôlée Factorisation des scrutations multiples
Support pour les interruptions Utilisation possible des activations Verrous spécifiques « interrupt-safe »
Scrutation par l’ordonnanceur
Ordonnanceurdes threads
Création d’une catégoriede polling (ex: MPI), assignation d’une fréquence et enregistrement de callbacks.
Polling jobsqueue
MPI
MPI_IsendMarcel_poll
Chaque thread candidat à une opération de polling adresse une requête à l’ordonnanceur et se bloque.
MPI_IrecvMarcel_poll
callbackcallback
Régulièrement, l’ordonnanceur appelle la fonction de scrutation définie par l’utilisateur...
Polling( )
Multithreading
Introduction et rappels
Rappel : les processus lourds
Caractéristiques Entité active directement supportée par l’OS
Flot d’exécution Espace d’adressage privé Ressources systèmes
Exécution séquentielle
Coût de gestion élevé Allocation des ressources Appels systèmes
Processus lourds
Ressources “noyau” + données “utilisateur”
processeur processeur processeur
Noyau
Processus
Ordonnanceur
Espace utilisateur
Processus Processus
Threads : Motivations
Difficulté de programmation Fil d’exécution unique
une seule chose à la fois !
Partage de données laborieux Réactivité aux sollicitations externes
Performances Opérations de base coûteuses Recouvrement des opérations d’E/S difficiles
Simplicité de programmation
Objectif Mener plusieurs activités indépendantes
au sein d’un processus
Exemples Simulations Serveurs de fichiers Systèmes d’exploitation (!)
Seule solution (?) Automate à états finis implanté « à la main »
(sauvegardes d’états)
Structure d’un OS monolytique
Exemple
Séquence infinie d’opérations courtes Ordre et fréquence des scrutations ?
for (;;) {
if(networkMsgIn()) getNetworkMsg();
if(kbdReady()) getKey();
if(diskBlockReady()) handleDiskBlock();
…
}
Systèmes multiprogrammés
Exécution indépendante des activités Concurrence entre les différents traitements
for (;;) {
wait for network msg;
getNetworkMsg();
}
for (;;) {
wait for key stroke;
getKey();
}
for (;;) {
wait for disk block;
handleDiskBlock();
}
Processus serveur classique
Sérialisation des requêtes
Pas de recouvrement des E/S Exploitation SMP délicate Prise en compte de priorités ?
OS OS
client serveur
Sur l’efficacité des E/S
Caractéristiques du serveur de fichiers Tps de traitement d’une requête = 15ms Tps supplémentaire pour l’accès disque = 75ms
(pour 1/3 des requêtes)
Débit sans/avec recouvrement des E/S Sans recouvrement
25 requêtes/seconde
Avec recouvrement 33.33 requêtes/seconde (+33%)
Les processus légers
Principe Détacher flot d’exécution et ressources
Introduits dans divers langages & systèmes Programmation concurrente Recouvrement des E/S Exploitation des architectures SMP
thread
ressources
Caractéristiques de base
Thread = pile + contexte Partage de ressources
Code, tas, … : espace d’adressage Fichiers ouverts Etc.
Opérations de base performantes Création, destruction Synchronisation, commutation de contextes
Création d’un processus léger Adresse de fonction à exécuter + paramètres
Performance des threads
Opérations critiques Création/destruction (gestion mémoire) Changement de contexte (temps-
partagé) Synchronisation (mode utilisateur)
Programme d’évaluation Création d’une activité (processus,
thread)+ synchronisation (terminaison de l’activité)
OS/Processeur Processus Thread noyau Thread utilisateur PM2
Linux 2.2/PII 450 0.540 0.130 - 0.006
Solaris 2.7/PII 350 8.622 0.214 0.160 0.009
Repères historiques
L’ancêtre : les coroutines Entrelacement explicite des exécutions Langages : Simula (67), Modula2 (82) Primitives clés : create + resume
Les threads dans les systèmes Cthread (Mach) -> DecThread -> PThread (~90) Chorus, Solaris (87), winNT, IRIX, Linux, etc.
Les threads dans les langages Ada (83), Java, etc. C++ //, Eiffel //, etc.
Multithreading
Premier contact
L’interface POSIX-Threads
Interface de programmation standard pour Unix Portabilité des applications Solaris, IRIX, HP-UX, Linux, Etc.
Fonctionnalités Création/destruction de threads Synchronisation Ordonnancement, priorités Signaux Etc.
Exemple: création
Création d’un nouveau thread Éventuels attributs dans la structure attr Exécution de start_func avec le paramètre arg *pid est l’identificateur du thread créé
int pthread_create( pthread_t *pid,
pthread_attr_t *attr,
void * (*start_func)(void *),
void *arg);
Attente de fin d’exécution
Attente de la terminaison du thread pid Récupération de son code de retour status On peut contourner ce mécanisme en
« détachant » les threads :
int pthread_join( pthread_t pid,
void **status);
int pthread_detach( pthread_t pid);
« Hello World! »
#include <stdio.h>#include <pthread.h>
void *func(void *arg){
printf(“Thread %x says %s\n”, pthread_self(), arg);return NULL;
}
int main(void){
pthread_t pid;
pthread_create(&pid, NULL, func, “Hello World!”);printf(“This is the main thread\n”);pthread_join(pid, NULL);return 0;
}
Attributs
Ensemble fixé de caractéristiques Utilisé à l’initialisation Threads, verrous, variables de condition, etc.
Threads Priorité Pile : taille, emplacement Détaché : oui/non Type d’ordonnancement
Verrous Inversion de priorités, récursivité
Attributs : exemple
#include <stdio.h>#include <pthread.h>
void *handle_request(void *arg){
…}
int main(void){ …
pthread_attr_t attr;
for(;;) {fd = accept(sock, …);pthread_attr_init(&attr);pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);pthread_create(NULL, &attr, handle_request, fd);
}}
Exemple bis : pile
À manipuler avec précaution ! Quelle taille de pile choisir ? Comment prévenir/détecter les débordements ?
pthread_attr_t attr;
pthread_attr_init(&attr);pthread_attr_setstacksize(&attr, 128*1024);pthread_create(NULL, &attr, func, NULL);
Le standard OpenMP
Interface pour écrire des applications multithreads portables (sur SMP) Directives de compilation (C, C++, Fortran)
+ routines Objectif = simplicité + portabilité Constructeurs + fabricants de logiciels + etc.
Modèle de programmation « Fork-Join » Parallélisation des boucles (#pragma omp)
Multithreading
Partage mémoire efficace
Les threads et la mémoire
Chaque thread possède sa propre pile Variables locales « privées » ( visibilité)
Les threads partagent l’espace d’adressage Variables globales Tas (malloc) Variables locales (piles) également !
Intérêt Communications par pointeurs ! Parallélisation de programmes séquentiels aisée ?
Outils pour la synchronisation
Exclusion mutuelle : les verrous
Synchronisations plus complexes : Variables de condition (cf moniteurs de Hoare) pthread_cond_wait pthread_cond_signal, pthread_cond_bcast
int glob = 0;
void *inc(void *arg){
for(i=0; i<100; i++) {pthread_mutex_lock(&mutex);glob++;pthread_mutex_unlock(&mutex);
}}
Code réentrant
« code demeurant correct lorsqu’il estexécuté simultanément par plusieurs threads
»
Exemples typiques Fonction n’utilisant que des variables locales Code protégé par un verrou
Quid du code que l’on écrit pas soi-même ? Malloc, free, …, la bibliothéque standard Fonctions « MT-safe »
Option –D_REENTRANT Certains prototypes changent…
Importance de la synchro.
Cohérence séquentielle de la mémoire ? Compilateurs/Optimiseurs
Instructions réordonnées
Processeurs modernes Ecritures réordonnées
On ne peut pas supposer l’ordre des écritures
Primitives de synchronisation Agissent comme des « barrières mémoire »
Variables spécifiques
Pb : comment gérer les variables globales « privées »
int my_x;
void g(void){
…my_x…}
void f(void){
my_x = do_compute();…g();
}
Variables spécifiques
Principe Variable accessible à partir d’une clé Allocation globale (souvent à l’initialisation)
pthread_setspecific(clé, valeur) pthread_getspecific(clé) -> valeur
Exemple : la variable errno Fichier errno.h
#ifdef _REENTRANT#define errno (*__errno_location())
#elseextern int errno;
#endif
Exploitation efficacedes machines SMP
Quelle catégorie de threads ?
Multithreading utilisateur
Deux ordonnanceurs indépendants :
processor processor processor
OS Kernel
Process Process Process
Scheduler
User Space
Scheduler Scheduler
Multithreading noyau
Un seul ordonnanceur :
processor processor processor
OS Kernel
Process Process Process
Scheduler
User Space
Multithreading mixte
Deux ordonnanceurs coopérants
processor processor processor
OS Kernel
Process Process Process
Scheduler
User Space
Scheduler Scheduler
Note: Quid des appels systèmes bloquants ?
E/S et ordonnancement
Threads noyaux : OK Threads utilisateurs
Appel bloquant -> blocage du processus entier
Threads mixtes Idem au bout d’un certain nombre !
Solutions ? Appels toujours non-bloquants (polling) Appels effectués par des threads dédiés Support système spécifique
Exploitation efficacedes machines SMP
Scheduler Activations
Recouvrement des E/S
Au lieu de
Espace noyau
Espace utilisateur
Matériel
syscall
…on voudrait :
Espace noyau
Espace utilisateur
Matériel
I/O request interrupt
Temps CPU perdu
CPU utilisé
Scheduler Activations
Introduit par [Anderson et al. 91] Idée: la coopération entre les deux
ordonnanceurs est bidirectionnelle L’ordonnanceur utilisateur utilise des appels
systèmes L’ordonnanceur noyau utilise des upcalls!
Upcalls Informe l’application des événements noyaux
Activations Autant d’activations en exécution que de
processeurs Contrôlées par le noyau
Principe mis en œuvre dans Solaris
Difficultés de mise en œuvre
Retour d’un appel bloquant Un « unblock upcall » nécessite deux appels
systèmes supplémentaires… La généricité coûte cher !!
Perte du processeur Signalée par un upcall particulier
Objectif = éviter les attentes actives !
Conséquences L’ordonnanceur de niveau utilisateur doit se prémunir
contre ces interruptions intempestives Le coût est prohibitif !
Un modèle revisité
Contexte = calcul haute performance Une application // à la fois sur la grappe Optimisations pour ce cas de figure
Les activations perdent rarement le processeur
Propositions Suppression des évènements « preempt » Utilisation d’une pile par processeur
Implantation Linux 2.2.x Bibliothèque de threads Marcel
A propos de réactivité…
Problèmes liés aux évènements « unblock » Coût important, réactivité non-garantie
Proposition Pour les notifications non-urgentes
Positionnement d’une variable partagée Test à chaque changement de contexte
Pour les notifications critiques Lors du retour en mode utilisateur :
- Déviation vers le thread « client » de l’événement Déviation éventuellement différée…
Modifications du noyau Linux
Parties du noyau modifiées schedule(), do_fork() and do_exit()
Implantation des transitions
task_struct structure Nouveaux champs (état des activations, etc.)
Code ajouté Appels systèmes + API pour les upcalls Gestion des upcalls (~signaux) Code pour les changements d’état des
activations
Performances
Mono processeur Bi processeur
Bibliothèque Opérations surles threadsintensives
Entrées/Sorties
Calcul intensif
Marcel/mono 330 us 40000 ms 6932 ms
Marcel/SMP 440 us 15 ms 3807 ms
Marcel/activation 320 us / 440 us 11 ms 3551 ms
LinuxThread 15000 us 15 ms 3566 ms
Meilleure réactivité au réseau
Illustration : MPI et les communications asynchrones
Processus A Processus B
Acquittement
MPI_Isend
MPI_recv
MPI_test
MultithreadingDistribué
Principe et Enjeux
Principe
Introduire les threads dans les applications distribuées et parallèles
procproc proc proc
réseau
Enjeux
Bénéfices escomptés Meilleur support du parallélisme à grain fin Recouvrement naturel des communications Uniformisation de la configuration
Machines monoprocesseur/machines SMP
Intérêts
Apports des threads Virtualisation de l’architecture
Threads = processeurs virtuels Passage à l’échelle (scalability) Bonne cible pour des compilateurs
Meilleure réactivité au réseau Traitement asynchrone des messages
Équilibrage de charge par migration de threads Équilibrage dynamique Régulateur indépendant de l’application (plug-ins) !
MultithreadingDistribué
Quel modèle de programmation ?
Approche par juxtaposition
Principe : pas de modèle ! Simplement utiliser conjointement
Une bibliothèque de communication (ex: MPI) Une bibliothèque de multithreading
Problèmes Conceptuels
Pas de visibilité globale des threads Sémantique des communications ?
Techniques Compatibilité entre les bibliothèques Travail d’intégration spécifique -> non réutilisable
Approche intégrée
Threads communicants A0, Chant
Pthreads + extensions Rthreads
Pthreads DSM-threads
Appels de procédure à distance « threadés » A0, Nexus, PM2
Threads communicants
Principe Envoi de message entre threads
Modèle « MPI-like » Modèle « Acteurs »
Nommage Nommage global des threads Ports de communication
Exemples Chant (M. Haines, ICASE) Athapascan-0b (J. Briat, INRIA Grenoble)
Modèle Pthreads étendu
Principe Threads + primitives étendues
Create/Join à distance Synchronisations distribuées
Particularités Nommage global des threads Restriction du modèle Pthreads
Exemples Chant (M.Haines, ICASE),
Rthreads (M. Zahn, Allemagne)
Modèle Pthreads distribué
Principe Adaptation complète (?) de Pthreads
Threads + mémoire virtuellement partagée
Transparence Cohérence assurée lors des défauts de pages Restriction sur les E/S
Extensions Cohérences mémoires relâchées
Exemple DSM-Threads (F. Mueller, Berlin)
Modèle dérivé des RPC
Principe Appel de procédure à distance (A. Birell)
Extension du concept aux threads Création de threads pour exécuter les
procédures
Désignation globale des services Numéro fonction Souches (stubs) pour la transmission des
paramètres
Exemples Nexus (I. Foster, Argonne), PM2
MultithreadingDistribué
L’environnement PM2
Premières réflexions sur PM2
Parallel Multithreaded Machine (R. Namyst) Virtualisation de l’architecture Régulateurs génériques de charge (Y. Denneulin) Plateformes usuelles (COW, NOW), machines
parallèles Distribution du logiciel, assistance, documentation:-(
InterPRC Stratagème (C. Roucairol) Applications irrégulières
Optimisation combinatoire Algèbre linéaire creuse (J. Roman)
Ordonnancement, régulation Fortement irrégulière : placement + migration
Projet PM2 (95-xx)
Objectif ambitieux : virtualisation Indépendance de la machine cible
(#processeurs) Degré de parallélisme important (#processus) Parler de “traitement” / “processus”
mécanismes de décomposition parallèle
Propositions Mécanisme de décomposition
Appel de procédure à distance léger (LRPC)
Support des activités Processus légers (threads)
Régulateur dynamique de charge Placement + Migration
Appel de procédure à distance
Différentes déclinaisons Synchrone Attente différée Asynchrone
PM2 PM2
LRPC
Nos concurrents... Nexus : RSR Athapascan : appels de service
Hello World!#include <pm2.h>unsigned SAMPLE;void sample_func(void){ char msg[128];
pm2_unpack_byte(SEND_CHEAPER, RECV_CHEAPER, msg, 128);pm2_rawrpc_waitdata();printf(“%s\n”, msg);
}void main(int argc, char **argv){ int module[MAX_MODULES], nb_modules;
pm2_rawrpc_register(&SAMPLE, sample_func);pm2_init(&argc, argv, 2, module, &nb_modules);if(pm2_self() == les_modules[0]) {
pm2_rawrpc_begin(module[1], SAMPLE, NULL);pm2_pack_byte(SEND_CHEAPER, RECV_CHEAPER, “Hello World!”,
128);pm2_rawrpc_end();pm2_kill_modules(module, nb_modules);
}pm2_exit();
}
Threaded “Hello world!”
Création d’un thread Obligatoirement par pm2_thread_create
positionnement d’un certain nombre d’attributs héritage du “droit” de faire unpack
...void thread_func(void *arg){ char msg[128];
pm2_unpack_byte(SEND_CHEAPER, RECV_CHEAPER, msg, 128);pm2_rawrpc_waitdata();printf(“%s\n”, msg);
}
void sample_func(void){
pm2_thread_create(thread_func, NULL);}...
Mobilité des activités
Migration de processus légers
PM2 PM2
Pourquoi ? Régulation de charge Localité des données
Comment ? Transfert du contexte Programmes SPMD
MultithreadingDistribué
Communications dans un environnement multithreads
Appel de procédure à distance
RPC
Intensivement utilisé Accès mémoire distants, migration, etc.
Consensus (?) Athapascan, Nexus, Panda, PM2
Transmission zéro-copie
Processus A Processus BRéseau
Préparation mémoire
Acquittement
Message
EntêteVecteur
DMA
Portabilité
Bibliothèques de haut niveau MPI
Pas adapté aux interactions de type « RPC »
Bibliothèques de bas niveau BIP (Myrinet), SISCI (SCI), GAMMA (Ethernet)
Paradigmes très différents ! Portabilité ??
Niveau intermédiaire Exemple: Fast-Messages (Illinois)
Adapté aux RPC Trop souple (surcoûts inutiles)
RPC efficaces avec Madeleine
LRPC, Migration
Madeleine
Gestion générique de tampons
Gestion des transmissions
BIP, SISCI, VIA, TCP, MPI
Construction des messages
Gestion des canaux (~ communicators) Choix explicite du dispositif physique
Interface de Madeleine
mad_begin_packing
mad_pack
mad_end_packing
mad_begin_unpacking
mad_unpack
mad_end_unpacking
Packing et Unpacking
Commandes: mad_pack (cnx, buffer, len, pack_mode, unpack_mode) mad_unpack (cnx, buffer, len, pack_mode, unpack_mode)
Modes:
Send_SAFER
Send_CHEAPER
Send_LATER
Receive_EXPRESS
Receive_CHEAPER
Conclusion
Multithreading Exploitation efficace des architectures SMP Contrôle fin de l’ordonnancement
Conditionné par les fonctionnalités du système
Multithreading distribué Communications de type RPC
Support spécifique nécessaire
Intégration des threads et des communications Délicate !! Mieux maîtrisée si fonctionnement coopératif
Contexte technologique Architecture homogène, faiblement hétérogène
Grappes (Cluster, COW), machines // PC, stations de travail Ethernet, Myrinet, SCI, ...
Protocoles de communicationBIP, SISCI, SciOS, VIA, TCP, UDP, ...
Myrinet/BIP
PC
Commutateur
Contexte technologique
Infrastructure hétérogène Grilles
Supercalculateurs (Superordinateur virtuel) Grappes (grappes hiérarchiques, HNOW) PC
Interconnexion à plus large échelle Ressources hétérogènes
Processeurs (puissance, cache, mémoire) Réseaux (latence, bande passante, protocoles)
Multi-protocoles, déploiement, algorithmique, ...
PowerPC/Switch/MPI
Bordeaux
PC/Myrinet/BIP
Lyon
PC/SCI/sciOS
Grenoble
Internet
Superordinateur virtuel (Globus)
Grappes hiérarchiques
Distributed ASCI Supercomputer (DAS) Plate-forme commune pour la recherche Informatique parallèle (à grande échelle) et
applications distribuées Novembre 1998, 4 universités, 200 nœuds Nœud
Pentium Pro 200 MHz128 MB de mémoire, 2.5 GB de disqueMyrinet 1.28 Gbit/s (full duplex)Système d’exploitation : BSD
Réseau ATM
Grappes hiérarchiques
Ressources
Ressource entité capable de lancer un ou plusieurs
processus pour le compte d’un utilisateur. Désigne également des composants matériels
(mémoire, réseau, senseurs, etc.) Composants logiciels (fichiers, softs, …)
Partage Contrôlé des Ressources Informations, disponibilité Allocation, co-allocation Sécurité Administration, politiques d’accès…
Application Programming Interface
Spécification d’un ensemble de fonctions pour faciliter le développement d’applications Définition, pas d’implementation Exemples: il y a plusieurs implémentations MPI
Spécifique pour certains langages Noms des routines, nombre, type des paramètres Comportement de la fonction
Exemples GSS API (sécurité), MPI (échange de messages)
Software Development Kit
Une instantiation particulière d’une API
SDK est constitué de bibliothèques et d’outils Fournir une implémentation de la spécification
d’une API
Plusieurs SDKs pour une même API
Exemples de SDKs MPICH, Motif Widgets
Pourquoi les Grilles ?
Evolution des réseaux à très haut débit
Nouvelles applications basées sur le couplage rapide de personnes, d’ordinateurs, de bases de données, d’instruments,... Instruments en ligne Ingénierie collaborative Calcul parallèle distribué Utilisation de ressources distantes Simulations à très grande échelle Applications classiques du parallélisme faiblement couplé
Laboratoires virtuels
Instruments en ligne
Reconstruction tomographique
récupération
en temps réel
Dissémination
à grande échelle
Bureaux & clients de RV à contrôle partagés
Source de photons
Stockage
pour
archive
Ingénierie Collaborative
Manipulation d’espaces virtuels partagés avec Composants de simulation Flots multiples : Contrôle, Texte, Vidéo, Audio, Base de
données, Simulation, Tracking, Rendering
Problèmes associés : uni/multi-diffusion fiable (ou non fiable) Sécurité (comptes, accès, transferts de données) Réservation et Qualité de Service
Calcul parallèle distribué
Problèmes associés Découverte de ressources
(matérielles et logicielles) Ordonnancement (on-line
& off-line) Visualisation de données Plusieurs bibliothèques de
communications Passage de messages Passage à l’échelle Tolérance aux pannes Réservation de ressources Sécurité
RennesRocquencourt
Nancy
Grenoble
Sophia
Challenges techniques
Applications complexes qui combinent des aspects du parallélisme, du multimédia et du système distribué
Ressources dont les caractéristiques varient en fonction du temps et de l’espace
Besoin de performances « end-to-end » bonnes et garanties, malgré l’hétérogénéité et le manque de contrôle global
Problèmes de sécurité, de politique et de paiement entre les domaines
Les défis logiciels
Administration Sécurité, équité, disponibilité, équilibrage des
charges Hétérogénéité
Réseaux, processeurs, hiérarchie mémoire Équilibrage des charges Distribution des données Informations sur la charge en temps réel Évaluation des performances Modélisation des architectures Couplage de codes
Globus
Le projet Globus
Recherches sur les technologies liées aux grilles Gestion des données et des ressources, sécurité,
Qualité de Service, communication, adaptation, ...
Développement de la boite à outils Globus Services de base pour les outils et applications de
la grille
Construction de grilles
Expérimentations des applications
L’approche Globus
Une boite à outils et plein de services pour résoudre des problèmes techniques cruciaux « sac à malices » modulaire Middleware applicable dans différents domaines
d’application
Faire interopérer plusieurs « mondes » existants au lieu de les fusionner
Différenciation des services locaux et globaux
Approche Technique
Permettre le développement incrémental d’outils et d’applications pour la grille Support de nombreux langages, modèles de
programmations, outils, applications Évoluer en fonction des besoins de l’utilisateur
Se déployer à l’échelle internationale Développements et tests à grande échelle
Fournir un environnement riche en informations
Les grilles Globus
Grilles et Plates-formes de tests EMERGE : Pré-réservation & QoS GUSTO : Globus Ubiquitous Supercomputing
Testbed Organization Particle Physics Data Grid
Grilles de production NSF PACIs National Technology Grid NASA Information Power Grid DOE ASCI European Grid
Plate-forme GUSTO durant SC’98
Globus Ubiquitous Supercomputing Testbed Organization (GUSTO) 02/00: 125 sites dans 23 pays L’un des plus grands environnements de calcul jamais
construits
The 13.6 TF TeraGrid:Computing at 40 Gb/s
26
24
8
4 HPSS
5
HPSS
HPSS UniTree
External Networks
External Networks
External Networks
External Networks
Site Resources Site Resources
Site ResourcesSite ResourcesNCSA/PACI8 TF240 TB
SDSC4.1 TF225 TB
Caltech Argonne
TeraGrid/DTF: NCSA, SDSC, Caltech, Argonne www.teragrid.org
Le Sablier Globus
Un ensemble de services comme infrastructure de base
Utilisables pour construire des solutions spécifiques de haut niveau
Buts: Limiter l’implication des
utilisateurs Permettre un contrôle local
Divers services globaux
Cœur des Services Globus
OS Local
A p p l i c a t i o n s
Architecture en couche
Applications
Boite à outils Application
DUROC globusrunMPI Nimrod/GCondor-G HPC++
GlobusView Testbed Status
Base de la Grille
LSF
Condor MPI
NQEPBS
TCP
NTLinux
UDP
Solaris DiffServ
Services de la GrilleGRAM
GSI HBM
Nexus
I/O GASSGSI-FTPMDS
Différents services Globus
Services d’information (MDS)
Gestion des ressources (GRAM & DUROC)
Gestion distante des fichiers (GASS)
Communication (Nexus, MPI) Sécurité (GSI)
Surveillance des processus (HBM)
Le besoin d’informations
Système d’information point crucial pour les opérations sur la grille et la construction d’applications Comment une application détermine quelles
ressources sont disponibles ? Quel est « l’état » de la grille
Besoin d’un système d’information général pour répondre à ces questions
Quelques informations utiles
Caractéristiques d’un serveur de calcul Adresse IP, logiciels disponibles, administrateur
système, connections aux réseaux, version d’OS, charge
Caractéristiques d’un réseau Bande passante et latence, protocoles, topologie
logique
Caractéristiques de l’infrastructure Globus Hôtes, gestionnaires de ressources
Utilisation de l’information pour le courtage des ressources
“10 GFlops,20 Mb/sec pendant 20 mins”
MetacomputingDirectoryService
GRAMGRAMGRAM
Courtierressources
Service Info :localisation + selection
Globus ResourceAllocation Managers
GRAM
ForkLSFEASYLLCondoretc.
“Quelles machines?”“Quelle vitesse?”“Dispo quand?”
“50 processeurs + disques de 22h20 à 22h40”
“20 Mb/sec”
Service d’information
Fournir un accès à des informations statiques et dynamiques sur les composants
Base pour la configuration et l’adaptation de systèmes dynamiques et hétérogènes
Besoins et caractéristiques Accès uniforme et flexible à l’information Accès efficace et extensible aux données
dynamiques Accès à des sources d’informations multiples Maintenance décentralisée
Approche MDS
Basée sur LDAP Lightweight Directory Access
Protocol v3 (LDAPv3) Modèle de données standard Protocole de requête standard
Schéma spécifique à Globus Représentation centrée sur l’hôte
Outils spécifiques Globus GRIS, GIIS Découverte, publication de données
GRIS
NIS
NWS
LDAP
API LDAP
Middleware
…
Application
GIIS…
SNMP
Le MDS
Metacomputing Directory Service Annuaire de ressource de Globus Contient toutes les informations sur tous les
nœuds globus Consultable sur Internet
http://www.globus.org/mds
Distribué depuis la version 1.1.3 Permet de créer son propre « sous-Globus »
Metacomputing directory service
nn=SP-switch
MDSRepresentation
Carl Steve
Switch
Ethernet
Ian Gregor SteveWarren
sunny
hot
IBMSP
dark coldLAN
LANWAN
USC/ISI ANL/MCS
c=US
o=globus
o=USC o=ANL
ou=MCSou=ISI
nn=WAN
cn=Iancn=Gregor
cn=Warren
cn=Steve
nn=SP-ether
nn=MCS-lan
hn=sp1.mcs.anl.gov
hn=spN.mcs.anl.gov
cn=Carl
cn=Steve…
…
……
Structure physique
Gestion de ressources
Un langage de spécification de ressources flexible qui fournit la puissance nécessaire pour exprimer les contraintes requises
Des services pour la co-allocation de ressources, l’organisation d’exécutables, l’accès à des données distantes et la gestion des flux d’entrées/sorties
Intégration de ces services dans des outils de haut niveau MPICH-G: un MPI pour la grille globus-job-*: commandes flexible d’exécution à
distance
Gestion de ressources
Resource Specification Language (RSL) est utilisé pour communiquer les besoins
L’API du Globus Resource Allocation Manager (GRAM) permet de lancer les programmes sur des ressources distantes, sans tenir compte de l’hétérogénéité locale
Une architecture en couche permet de définir des courtiers de ressources et des co-allocateurs spécifiques aux applications comme étant des services GRAM
Modèle d’ordonnancement
GRAM supporte le modèle suivant
suspendu actif terminé
échec
Suspendu : ressources non encore allouées Actif : ressources allouées, exécution en cours Échec : terminaison prématurée (erreur ou
arrêt) Terminé : terminaison avec succès
Composants GRAM
Globus SecurityInfrastructure
Job Manager
Appels GRAM pour requête d’allocation de ressources et création de processus.
Appels MDS pour localiser les ressources
Requête sur l’état de la ressource
Création
Bibliothèque RSL
Parse
RequêteAllocation &
création des processus
Processus
Processus
Processus
Monitoring &contrôle
Limite du site
Client MDS: Grid Index Info Server
Gatekeeper
MDS: Grid Resource Info Server
Local Resource Manager
Appels MDS pour avoir des infos sur les ressources
Mise à jour GRAM
GRAM GRAM GRAM
LSF EASY-LL NQE
Application
RSL
Simple ground RSL
Service d’Information
Gestionnairesde ressourceslocaux
spécialisation RSLCourtier
Ground RSL
Co-allocateur
Requêtes
& Info
Architecture de la gestion de ressources
Langage de spécification de ressource
Notation commune pour l’échange d’information entre composants
RSL fournit deux types d’informations : Besoins en ressources : type de machine,
nombre de nœuds, mémoire, etc. Configuration d’un job : Répertoire, exécutable,
arguments, environnement
API fournie pour manipuler RSL
Syntaxe RSL
Forme élémentaire : clauses parenthésées (attribut op valeur [ valeur … ] )
Opérateurs supportés: <, <=, =, >=, > , !=
Quelques attributs supportés : exécutable, arguments, environnement, stdin,
stdout, stderr, resourceManagerContact,resourceManagerName
Les attributs inconnus sont ignorés Peut-être gérés par d’autres outils
Contraintes : “&”
Par exemple :& (count>=5) (count<=10) (max_time=240) (memory>=64) (executable=myprog)
“Créer entre 5-10 instances de myprog, chacune sur une machine with ayant au moins 64 MB de mémoire et disponible pour moi pendant 4 heures”
Multi-requêtes : “+”
Une multi-requête permet de spécifier plusieurs besoins de ressources, par exemple :+ (& (count=5)(memory>=64) (executable=p1)) (&(network=atm) (executable=p2)) Exécuter 5 instances de p1 sur une machine ayant
au moins 64Mb de mémoire Exécuter p2 sur une machine ayant une connexion
ATM
Multi-requêtes sont le cœur de la co-allocation
GRAM
Globus Resource Allocation Manager
Permet à un programme d’être lancé sur des ressources distantes malgré l’hétérogénéité locale
Utilise le langage de spécification de ressources (RSL)
DUROC
Dynamically Updated Request Online Co-allocator
Co-allocation : allocation simultanée d’un ensemble de ressources
Basée sur des prédictions concernant les nœuds libres et la taille des files d’attentes
GASS
Global Access to Secondary Storage open/close globus_gass_open/close :
lectures/écritures directement à distance URLs pour nommer les exécutables, les flux
d’entrée et de sortie. Utilitaire de gestion de caches distants
Chargement transparent de données distantes, cache de données, ...
Supprimer laréférence cache
Mettre à jour les changements
Modifié non
Oui
globus_gass_open()/close()
Charger le fichier dans le
cache
Ouvrir le fichier caché, ajouter une reference cache
URL dans le cache? non
oui
globus_gass_open()
globus_gass_close()
Nexus
Dans un système tel que Globus, la meilleure méthode de communication peut changer Nexus Support pour des communications multi-méthodes Principes de base : lien de communication et RSR
(Remote Service Request)
startpoint
endpoint
GSI
Grid Security Infrastructure Basé sur le système de clé publique
certificats au standard X.509 (comme sur Internet)
Chaque utilisateur a : un identificateur d’utilisateur de la grille, une clé privée, un certificat en bonne et due forme.
Un fichier « globusmap » sur chaque site fait la correspondance entre grid-id et local-id
HBM et GloPerf
HeartBeat Monitor : outil de surveillance des composants Globus. Détection de l’échec d’un nœud de calcul Monitoring de processus système depuis Globus Utilisé par d’autres applications (ex : NetSolve)
comme module de tolérance aux pannes GloPerf : Globus Network Performance
Measurement Tool Mesure de la bande passante et de la latence
entre chaque site du MDS Pas très évolué et un peu lourd
Compléments d’information
Globus Project™ www.globus.org
Grid Forum www.gridforum.org
Livre (Morgan Kaufman) www.mkp.com/grids
Globus 2.2 Maintenu jusque fin 2003
Globus 3 Web Services Janvier 2003 (GlobusWorld)
Recommended