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

LaBRI Université de Bordeaux I

Jean-François Méhaut

GRIMAAG Université 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é  … Proc. 0 Application Programme parallèle 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é !

Applications Interface de programmation (API) Support d’exécution Systèmes d’exploitation (OS) Grappes, grilles, machines parallèles, réseaux,…

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, … Applications Interface de programmation (API) Support d’exécution Systèmes d’exploitation (OS) Grappes, grilles, machines parallèles, réseaux

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 X Portabilité Efficacité

PM2 : support pour les grappes

Applications Régulation HPF, C* C++//, Java Interface de programmation (RPC, migration, allocation iso-adresse) Marcel PM2 Madeleine Unix (~10 versions) Architecture (grappes, machines parallèles)  Légende  Marcel : noyau de processus légers  Madeleine : module de communication

Globus : support pour les grilles

Applications

GlobusView DUROC MPI

Boite à outils Application

Condor-G HPC++ Nimrod/G Testbed Status globusrun I/O Nexus MDS

Services de la Grille

GSI GSI-FTP HBM GRAM GASS Condor LSF MPI PBS NQE

Base de la Grille

Linux NT Solaris TCP UDP DiffServ

Communications dans les grappes hautes performances

Raymond Namyst LaBRI Université 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…

Technologies maté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, … Memory TX-ring PCI Bus PCI Bridge DMA TX reg RX reg Packet Interface NIC Network

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 PCI Bus PCI Bridge DMA NIC SRAM RISC Packet Interface LANai Network

SCI

 S calable C oherent I nterface  Norme IEEE (1993)  Société Dolphin  Fonctionnement par accès mémoire distants  Projections d’espaces d’adressage

Mémoire Bus PCI Machine A Réseau SCI Machine B Bus PCI Mémoire

Carte à capacité d ’addressage

BUS PCI Pci req: addr+ data TLB Paquet SCI Interface paquet Partie émission Interface paquet BUS PCI TLB Paquet SCI Pci req: addr+ data Partie réception

Adressage à distance

  Projections e ffectué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

Processus A Processus B

Espace d'adressage virtuel Bus PCI PCI-SCI Interconnexion SCI PCI-SCI Bus PCI Mémoire physique Espace d'adressage virtuel

SCI : mécanisme d’adressage

Table de Translation des Adresses 16 bits Destinataire 30 bits Adresse Virtuelle MMU 32 bits Adresse Physique (E/S) Bus d’E/S 32 bits 10 bits 18 bits 18 bits Réseau

SCI : mécanisme d’adressage

30 bits Réseau 18 bits Adresse Physique (E/S) Bus d’E/S 32 bits Mémoire

SCI : performances

   Latence : 2.5 m s (écriture de processus à processus) Débit : Verrou : 45 Mo/s < 10 m 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

Programme Interface Initialisation Réseau Espace utilisateur Système Transferts

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  Bande passante  85  4 us Mo/s (difficilement !)

SCI : optimisations matérielles

 Caches dans la carte  Read Prefetching  Write Combining :

Processus A Processus B

Espace d'adressage virtuel Bus PCI PCI-SCI Interconnexion SCI PCI-SCI Bus PCI Mémoire physique Espace d'adressage virtuel

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

 V irtual I nterface A rchitecture  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  Target Environment by User Process  LANs and “SAN”s at Gigabit Speeds  No Reliability of Underlying Media Assumed

VI Architecture

Host NIC

VI Consumer Sockets, MPI, Legacy, etc. VI User Agent (“libvia”) VI Kernel Agent (Slow) User-Level (Fast) Descriptor Read, Write VI

S R

VI

S R

VI

S R

C

C O M P Requests Completed VI-Capable 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 Functions Creation/Destruction of Vis VI Connection setup/tear-down Management of System Memory used by the VI NIC

A Virtual Interface

VI Consumer Send Q Descriptor Descriptor Status Recv Q Descriptor Descriptor Status

VI-Capable NIC

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 Descriptors Transmit and Receive Completions and Errors May Reside on Host or NIC (Unspecified) Doorbells “Addresses” of Descriptors, Small and Fast Allows NIC to Use Descriptors… Future “VIA-NICs” May Have Hardware Support

Memory Registration

 Data buffers and descriptors must reside of “ registered memory ” within a region  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  Receive émission d’un message réception d’un message  Points forts  Simple à mettre en oeuvre  Permet d’émuler les autres paradigmes

PVM

 P arallel V irtual M achine  Laboratoire National d’Oak Ridge (Tennessee)  1989  Caractéristiques  Notion de machine virtuelle  Ensemble de machines physiques  Construction 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

 M essage P assing I nterface  MPI-Forum v 1.0

1994 v 2.0

1997  Caractéristiques  Un standard, pas une bibliothèque  Diverses implémentations  MPI-CH  LAM-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 récepteur a priori par le   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 Réseau Processus B Message Acquittement

Préparation mémoire DMA

Entête Données

Et la réactivité alors ?

 Problèmes  Assurer la progression des communications asynchrones  Réagir rapidement aux sollicitations extérieures proc proc proc réseau proc

Envois asynchrones

 ?

Parvient-on vraiment à assurer du recouvrement

MPI_Isend MPI_recv Acquittement MPI_test Processus A Processus B

Interfaces de niveau 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

Interface

 Construction des messages mad_begin_packing mad_pack mad_end_packing mad_begin_unpacking mad_unpack mad_end_unpacking  Gestion des canaux (~

communicators

)  Choix explicite du dispositif physique

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

Pack Modification Send_SAFER Send_LATER Send_CHEAPER End_packing Version transmise

Réception : mode de déballage (1)

 RECV_EXPRESS Unpack Tampon Après Unpack

Données disponibles

End_packing

Réception : mode de déballage (2)

 RECV_CHEAPER Unpack Tampon Après Unpack

Données disponibles ???

End_packing

Données disponibles

Exemple

Sending side int n; char *s = "Hello, World !"; p_mad_connection_t cnx; cnx = mad_begin_packing(channel, dest); n = strlen(s) + 1; mad_pack(cnx, &n, sizeof(int), send_CHEAPER, receive_EXPRESS); mad_pack(cnx, s, n, send_CHEAPER, receive_CHEAPER); mad_end_packing(cnx); Receiving side int n; char *s = NULL; p_mad_connection_t cnx; cnx = mad_begin_unpacking(channel); mad_unpack(cnx, &n, sizeof(int), send_CHEAPER,receive_EXPRESS); s = malloc(n); mad_unpack(cnx, s, n, send_CHEAPER,receive_CHEAPER); mad_end_unpacking(cnx);

Exemple

Sending side int n; char *s = "Hello, World !";

p_mad_connection_t cnx;

cnx = mad_begin_packing(channel, dest); n = strlen(s) + 1; mad_pack(cnx, &n, sizeof(int), send_CHEAPER, receive_EXPRESS); mad_pack(cnx, s, n, send_CHEAPER, receive_CHEAPER); mad_end_packing(cnx); Receiving side int n; char *s = NULL;

p_mad_connection_t cnx;

cnx = mad_begin_unpacking(channel); mad_unpack(cnx, &n, sizeof(int), send_CHEAPER,receive_EXPRESS); s = malloc(n); mad_unpack(cnx, s, n, send_CHEAPER,receive_CHEAPER); mad_end_unpacking(cnx);

Exemple

Sending side int n; char *s = "Hello, World !"; p_mad_connection_t cnx;

cnx = mad_begin_packing(channel, dest);

n = strlen(s) + 1; mad_pack(cnx, &n, sizeof(int), send_CHEAPER, receive_EXPRESS); mad_pack(cnx, s, n, send_CHEAPER, receive_CHEAPER); mad_end_packing(cnx); Receiving side int n; char *s = NULL; p_mad_connection_t cnx;

cnx = mad_begin_unpacking(channel);

mad_unpack(cnx, &n, sizeof(int), send_CHEAPER,receive_EXPRESS); s = malloc(n); mad_unpack(cnx, s, n, send_CHEAPER,receive_CHEAPER); mad_end_unpacking(cnx);

Exemple

Sending side int n; char *s = "Hello, World !"; p_mad_connection_t cnx; cnx = mad_begin_packing(channel, dest); n = strlen(s) + 1;

mad_pack(cnx, &n, sizeof(int), send_CHEAPER, receive_EXPRESS);

mad_pack(cnx, s, n, send_CHEAPER, receive_CHEAPER); mad_end_packing(cnx); Receiving side int n; char *s = NULL; p_mad_connection_t cnx; cnx = mad_begin_unpacking(channel);

mad_unpack(cnx, &n, sizeof(int), send_CHEAPER,receive_EXPRESS);

s = malloc(n); mad_unpack(cnx, s, n, send_CHEAPER,receive_CHEAPER); mad_end_unpacking(cnx);

Exemple

Sending side int n; char *s = "Hello, World !"; p_mad_connection_t cnx; cnx = mad_begin_packing(channel, dest); n = strlen(s) + 1; mad_pack(cnx, &n, sizeof(int), send_CHEAPER, receive_EXPRESS); mad_pack(cnx, s, n, send_CHEAPER, receive_CHEAPER); mad_end_packing(cnx); Receiving side int n; char *s = NULL; p_mad_connection_t cnx; cnx = mad_begin_unpacking(channel); mad_unpack(cnx, &n, sizeof(int), send_CHEAPER,receive_EXPRESS);

s = malloc(n);

mad_unpack(cnx, s, n, send_CHEAPER,receive_CHEAPER); mad_end_unpacking(cnx);

Exemple

Sending side int n; char *s = "Hello, World !"; p_mad_connection_t cnx; cnx = mad_begin_packing(channel, dest); n = strlen(s) + 1; mad_pack(cnx, &n, sizeof(int), send_CHEAPER, receive_EXPRESS);

mad_pack(cnx, s, n, send_CHEAPER, receive_CHEAPER);

mad_end_packing(cnx); Receiving side int n; char *s = NULL; p_mad_connection_t cnx; cnx = mad_begin_unpacking(channel); mad_unpack(cnx, &n, sizeof(int), send_CHEAPER,receive_EXPRESS); s = malloc(n);

mad_unpack(cnx, s, n, send_CHEAPER,receive_CHEAPER);

mad_end_unpacking(cnx);

Exemple

Sending side int n; char *s = "Hello, World !"; p_mad_connection_t cnx; cnx = mad_begin_packing(channel, dest); n = strlen(s) + 1; mad_pack(cnx, &n, sizeof(int), send_CHEAPER, receive_EXPRESS); mad_pack(cnx, s, n, send_CHEAPER, receive_CHEAPER);

mad_end_packing(cnx);

Receiving side int n; char *s = NULL; p_mad_connection_t cnx; cnx = mad_begin_unpacking(channel); mad_unpack(cnx, &n, sizeof(int), send_CHEAPER,receive_EXPRESS); s = malloc(n); mad_unpack(cnx, s, n, send_CHEAPER,receive_CHEAPER);

mad_end_unpacking(cnx);

Interfaces de niveau intermédiaire

Madeleine : implantation

Proposition

Interface Gestion des tampons Gestion de protocole

Pack Send Unpack Receive

Madeleine – structure

Application BMM 1 Switch BMM n Generic Buffer Management Modules TM 1 Selection TM n Specific Transmission Modules Network Application BMM 1 Switch BMM m TM 1 Selection TM n

Adaptativité

 Sélection du mode de transmission adéquat

Interface Gestion des tampons Gestion de protocole

?

Pack

Implementation

 Madeleine II a été portée sur :       SISCI/SCI BIP/Myrinet MPI VIA TCP SBP

12 10 8 6 4 2 0

0

BIP/Myrinet

Latency: Madeleine II/BIP

64 Packet size (bytes) 128

BIP/Myrinet

Bandwidth: Madeleine II/BIP 120 100 80 60 40 20 0

4 16 64 256 1024 4096 16384 Packet size (bytes) 65536 26 21 44 10 48 57 6

10 9 8 3 2 1 0 7 6 5 4

0

SISCI/SCI

Latency: Madeleine II/SCI

64 Packet size (bytes) 128

SISCI/SCI

Bandwidth: Madeleine II/SCI

50 40 30 20 10 0 90 80 70 60 1 4 16 64 25 6 10 24 40 96 16 38 4 Packet size (bytes) 65 53 6 26 21 44 10 48 57 6 41 94 30 4 1, 7E+ 07

Quelques résultats

  Latence  7 µs  4 µs sur BIP/Myrinet sur SISCI/SCI Bande passante  125 Mo/s  80 Mo/s sur BIP/Myrinet sur SISCI/SCI  Migration (PM2)  24 µs  52 µs sur SISCI/SCI 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 Protocol Interface Generic part (collective operations, context/group management, ...) Generic ADI code, datatype management, request queues management

CH_MAD device

inter-node communication polling loops eager protocol rendez-vous-protocol

SMP_PLUG device CH_SELF device

intra-node communication self communication

TCP

Fast-Ethernet

Madeleine II multi-protocol management SISCI

SCI

BIP

Myrinet

Latency

40 35 30 25 20 15 10 5 0

1

Comparison : various MPI/SCI implementations

10 Packet size (bytes) 100 SCI-MPICH SCA-MPI MPI/MadII/SCI 1000

Bandwidth

Comparison : various MPI/SCI implementations

80 70 60 50 40 30 20 10 0 1 4 16 SCI-MPICH SCA-MPI MPI/MadII/SCI 64 25 6 10 24 40 96 16 38 4 Packet size (bytes) 65 53 6 26 21 44 10 48 57 6

Vers les grappes de grappes

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 !

Réseau rapide PC/SCI PC/Myrinet

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 SCI Canal TCP Canal TCP

Structure interne

 Couche générique de gestion de tampons  Couche de portabilité avec les protocoles Application MGT 1 MGT 2 MGT n MT 1 MT 2 Réseau MT n

Structure interne

Application Aiguillage MGT 1 MGT n Couche de gestion de tampons Application Aiguillage MGT 1 MGT n Sélection MT 1 MT n Réseau Couche de portabilité Sélection MT 1 MT n Réseau

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 MGT 1 MGT 2 MGT n MT 1 Réseau MT 2

Solution retenue

 MT générique entre les MTs et les MGTs  Pas de MGT au niveau de la passerelle Application MGT 1 MGT 2 MGT n MT générique MT 1 Réseau MT 2

Canaux virtuels

 Contiennent plusieurs canaux réels  Permettent de séparer les messages à retransmettre des messages normaux (canaux réels différents) Canal virtuel 1 2 3 4 Canaux SCI Canaux Myrinet Canal spécial Canal normal

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  Threads de scrutation sur la provenance

Principe de la passerelle

Application Thread de scrutation Threads de retransmission Myrinet SCI

Tests de performances

Ping-pong entre 2 machines séparées par une passerelle 1 SCI 2 Myrinet 3

Évaluation

Bande passante Latence SCI BIP 80 Mo/s 116 Mo/s BIP/SCI Avec une passerelle

41

Mo/s 5,3

μ

s 7,8

μ

s

32,5

μ

s

Intégration des threads et des communications

Réactivité des nœuds aux E/S

Progression des communications

 Problème  Comment assurer la progression des communications ?

proc proc proc réseau proc

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

 Création d’une

catégorie

de polling (ex: MPI), assignation d’une

fréquence

et enregistrement de

callbacks.

 Chaque thread candidat à une opération de polling adresse une requête à l’ordonnanceur et se bloque.

MPI_Isend Marcel_poll MPI_Irecv Marcel_poll Polling jobs queue

MPI

Polling( )  Régulièrement, l’ordonnanceur appelle la fonction de scrutation définie par l’utilisateur...

Ordonnanceur des threads

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”

Processus

Espace utilisateur

Processus Processus

processeur Ordonnanceur Noyau processeur processeur

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

for (;;) { if(networkMsgIn()) getNetworkMsg(); if(kbdReady()) getKey(); if(diskBlockReady()) handleDiskBlock(); … }

 Séquence infinie d’opérations courtes  Ordre et fréquence des scrutations ?

Systèmes multiprogrammés

for (;;) { wait for network msg; getNetworkMsg(); } for (;;) { wait for key stroke; getKey(); } for (;;) { wait for disk block; handleDiskBlock(); }

 Exécution indépendante des activités  Concurrence entre les différents traitements

Processus serveur classique

 Sérialisation des requêtes client serveur OS  Pas de recouvrement des E/S  Exploitation SMP délicate  Prise en compte de priorités ?

OS

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

thread

ressources  Introduits dans divers langages & systèmes  Programmation concurrente  Recouvrement des E/S  Exploitation des architectures SMP

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 Linux 2.2/PII 450 Solaris 2.7/PII 350

Processus

0.540

8.622

Thread noyau

0.130

0.214

Thread utilisateur

0.160

PM2

0.006

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

int pthread_create( pthread_t * pid , pthread_attr_t * attr , void * (* start_func )(void *), void * arg );  Création d’un nouveau thread  Éventuels attributs dans la structure attr  Exécution de start_func  *pid avec le paramètre est l’identificateur du thread créé arg

Attente de fin d’exécution

int pthread_join( pthread_t pid , void ** status );  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_detach( pthread_t pid );

« Hello World! »

} #include #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 #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

pthread_attr_t attr; pthread_attr_init (&attr); pthread_attr_setstacksize (&attr, 128*1024 ); pthread_create ( NULL , &attr, func, NULL );  À manipuler avec précaution !

 Quelle taille de pile choisir ?

 Comment prévenir/détecter les débordements ?

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  int glob = 0; } { void *inc(void *arg) for(i=0; i<100; i++) { pthread_mutex_lock(&mutex); glob++; pthread_mutex_unlock(&mutex); }  Synchronisations plus complexes :  Variables de condition (cf moniteurs de Hoare)   pthread_cond_wait pthread_cond_signal, pthread_cond_bcast

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()) #else extern int errno; #endif

Exploitation efficace des machines SMP

Quelle catégorie de

threads

?

Multithreading utilisateur

 Deux ordonnanceurs indépendants :

Process

User Space

Process Process

Scheduler Scheduler processor Scheduler OS Kernel processor processor

Multithreading noyau

 Un seul ordonnanceur :

Process

User Space

Process Process

processor Scheduler OS Kernel processor processor

Multithreading mixte

 Deux ordonnanceurs coopérants

Process

User Space

Process Process

Scheduler Scheduler Scheduler OS Kernel processor processor Note: Quid des appels systèmes bloquants ?

processor

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 efficace des machines SMP Scheduler Activations

Recouvrement des E/S



Au lieu de

syscall

Espace utilisateur Temps CPU perdu Espace noyau

I/O request interrupt

Matériel  …on voudrait : Espace utilisateur Espace noyau Matériel 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 Marcel/mono Marcel/SMP Opérations sur les threads intensives 330 us 440 us Marcel/activation 320 us / 440 us LinuxThread 15000 us Entrées/ Sorties 40000 ms 15 ms 11 ms 15 ms Calcul intensif 6932 ms 3807 ms 3551 ms 3566 ms

Meilleure réactivité au réseau

 Illustration : MPI et les communications asynchrones

MPI_Isend MPI_recv Acquittement MPI_test Processus A Processus B

Multithreading Distribué

Principe et Enjeux

Principe

 Introduire les threads dans les applications distribuées et parallèles proc proc proc réseau proc

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

Multithreading Distribué

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

Multithreading Distribué

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  Support des activités  Processus légers (threads)  Régulateur dynamique de charge  Placement + Migration (LRPC)

Appel de procédure à distance

PM 2 LRPC PM 2  Différentes déclinaisons    Synchrone Attente différée Asynchrone  Nos concurrents...

  Nexus : RSR Athapascan : appels de service

Hello World!

#include 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 PM 2 PM 2  Pourquoi ?

 Régulation de charge  Localité des données  Comment ?

 Transfert du contexte  Programmes SPMD

Multithreading Distribué

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 Réseau Processus B Message Acquittement

Préparation mémoire DMA

Entête Vecteur

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  Adapté aux RPC  (Illinois) 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

Interface de Madeleine

 Construction des messages mad_begin_packing mad_pack mad_end_packing mad_begin_unpacking mad_unpack mad_end_unpacking  Gestion des canaux (~ communicators)  Choix explicite du dispositif physique

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 communication  BIP, SISCI, SciOS, VIA, TCP, UDP, ...

PC Commutateur Myrinet/BIP

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, ...

PC/Myrinet/BIP Lyon Internet Bordeaux PowerPC/Switch/MPI PC/SCI/sciOS Grenoble

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 MHz  128 MB de mémoire, 2.5 GB de disque  Myrinet 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

Source de photons Dissémination à grande échelle récupération en temps réel Stockage pour archive Bureaux & clients de RV à contrôle partagés Reconstruction tomographique

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é

Rennes Rocquencourt Nancy Grenoble Sophia  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é

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 d’application  applicable dans différents domaines  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

Site Resources HPSS External Networks

Caltech

Site Resources HPSS External Networks

Argonne

5

External Networks Site Resources HPSS

SDSC 4.1 TF 225 TB NCSA/PACI 8 TF 240 TB

External Networks Site Resources UniTree 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

A p p l i c a t i o n s

Divers services globaux Cœur des Services Globus OS Local

Architecture en couche

Applications

GlobusView DUROC MPI

Boite à outils Application

Condor-G HPC++ Nimrod/G Testbed Status globusrun I/O Nexus MDS

Services de la Grille

GSI GSI-FTP HBM GRAM GASS Condor LSF MPI PBS NQE

Base de la Grille

Linux NT Solaris TCP UDP DiffServ

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 d’applications  point crucial pour les opérations sur la grille et la construction  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” Service Info : localisation + selection “20 Mb/sec” Courtier ressources “Quelles machines?” “Quelle vitesse?” “Dispo quand?” Metacomputing Directory Service GRAM Globus Resource Allocation Managers “50 processeurs + disques de 22h20 à 22h40” GRAM Fork LSF EASYLL Condor etc.

GRAM GRAM

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 Application Middleware API LDAP GRIS SNMP … GIIS NWS NIS LDAP …

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 »

sunny hot LAN Carl Steve

USC/ISI

Metacomputing directory service

c=

US

MDS Representation

Ethernet

o=

globus WAN Switch IBM SP LAN

o=

USC

o=

ANL

nn=

WAN dark cold Ian Gregor SteveWarren

ANL/MCS

Structure physique

… ou=

ISI

cn=

Carl

cn=

Steve

… cn=

Ian

cn=

Gregor

cn=

Steve

cn=

Warren

ou=

MCS

… nn=

MCS-lan

nn= SP-switch nn= SP-ether hn= sp1.mcs.anl.gov

… hn= spN.mcs.anl.gov

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

Client

Composants GRAM

Appels MDS pour localiser les ressources Appels MDS pour avoir des infos sur les ressources MDS: Grid Index Info Server Limite du site Appels GRAM pour requête d’allocation de ressources et création de processus.

Globus Security Infrastructure

Gatekeeper Création Mise à jour GRAM

Job Manager

MDS: Grid Resource Info Server Requête sur l’état de la ressource Local Resource Manager Requête Allocation & création des processus Parse Monitoring & contrôle Processus Processus

Bibliothèque RSL

Processus

Architecture de la gestion de ressources

Courtier spécialisation RSL RSL Application Gestionnaires de ressources locaux Ground RSL GRAM LSF Requêtes & Info Service d’Information Co-allocateur Simple ground RSL GRAM EASY-LL GRAM NQE

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 pendant 4 heures” myprog , chacune sur une machine with ayant au moins 64 MB de mémoire et disponible pour moi

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, ...

globus_gass_open()/close()

URL dans le cache?

oui non Charger le fichier dans le cache Ouvrir le fichier caché, ajouter une reference cache globus_gass_open() globus_gass_close() Modifié Oui Mettre à jour les changements non Supprimer la référence cache

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)

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)