Supports d’exécution parallèles et répartis

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 à trouverFonctionalité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 regPacket InterfacePCI

Bridge

PCI Bus

DMA

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

DMA

PCI

Bridge

PCI Bus

LANai

SRAM

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

paquetPaquet

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 ConsumerVI User Agent (“libvia”)

Ope

n, C

onne

ct,

Map

Mem

ory

Descriptor Read, Write

VI-Capable NIC

Sockets, MPI,Legacy, etc.

RequestsCompleted

VI VI CS S S C

OMP

R R RVI

Doo

rbel

ls

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

Send

Doo

rbel

l

Descriptor

Descriptor

Recv Q

Rec

eive

Doo

rbel

l

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);


char *s = "Hello, World !";

int n;

Sending side Receiving side

Exemple




s = malloc(n);





char *s = NULL;

int n;

mad_pack(cnx, s, n,





n = strlen(s) + 1;




int n;


Exemple




s = malloc(n);





char *s = NULL;

int n;

mad_pack(cnx, s, n,





n = strlen(s) + 1;




int n;


Exemple




s = malloc(n);





char *s = NULL;

int n;

mad_pack(cnx, s, n,





n = strlen(s) + 1;




int n;


Exemple




s = malloc(n);





char *s = NULL;

int n;

mad_pack(cnx, s, n,





n = strlen(s) + 1;




int n;


Exemple




s = malloc(n);





char *s = NULL;

int n;

mad_pack(cnx, s, n,





n = strlen(s) + 1;




int n;


Exemple




s = malloc(n);





char *s = NULL;

int n;

mad_pack(cnx, s, n,





n = strlen(s) + 1;




int n;


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 128Packet size (bytes)

Late

ncy

(µs)

BIP/Myrinet

Bandwidth: Madeleine II/BIP

0

20

40

60

80

100

120

4 16 64 256

1024

4096

1638

465

536

2621

44

1048

576

Packet size (bytes)

Band

wid

th (M

B/s)

SISCI/SCI

Latency: Madeleine II/SCI

0123456789

10

0 64 128Packet size (bytes)

Late

ncy

(µs)

SISCI/SCI

Bandwidth: Madeleine II/SCI

0102030405060708090

1 4 16 64 256

1024

4096

1638

465

536

2621

44

1048

576

4194

304

1,7E+07

Packet size (bytes)

Band

wid

th (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 IImulti-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 1000Packet size (bytes)

Late

ncy

(µs)

SCI-MPICHSCA-MPIMPI/ 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

465

536

2621

44

1048

576

Packet size (bytes)

Band

wid

th (M

B/s)

SCI-MPICHSCA-MPIMPI/ 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 performancesPing-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 jobs

queue

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épendantesau 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 PM2Linux 2.2/PII 450 0.540 0.130 - 0.006Solaris 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 est

exé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 :


OS Kernel


Scheduler

User Space

Multithreading mixte Deux ordonnanceurs coopérants


OS Kernel


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

PerformancesMono 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) !


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


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


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 MadeleineLRPC, 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érationen 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 NetworksExternal

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=Warrencn=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)

http://www.globus.org/

http://www.gridforum.org/

http://www.mkp.com/grids

Date post:	20-Mar-2016
Category:	Documents
Upload:	denna
View:	42 times
Download:	1 times

Supports d’exécution parallèles et répartis

Documents