Introduction au Grid computing. Introduction au Grid computing. Grid-Computing. 1-Introduction Motivations Différents objectifs Leçons du passé

(1)

Introduction au Grid computing

1

Stéphane Vialle

Stephane.Vialle@supelec.fr http://www.metz.supelec.fr/~vialle

Introduction au Grid computing

2

1. Introduction

2. Exemple d’utilisation d’une Grille 3. Environnements de Grille

4. Une expérience de Grille mondiale pour le CERN 5. Bilan des Grilles

6. Autres exemples de Grilles 7. Acteurs industriels

Grid-Computing

1-Introduction

• Motivations

3

• Motivations

• Différents objectifs

• Leçons du passé

Grid computing: Introduction

Analogie avec distrib. d’électricité

Ian Foster (Globus – 1er middleware de grille)

4

• Infrastructurepour délivrer des capacités de calcul/stockage/

communication de façon transparente à l’utilisateur, quand et où il les demande.

• Plus pragmatique: construire des communautés dynamiques (Virtual Organizations) et fournir à leurs membres l’accès aux ressources partagées.

Réalité invisible à l’utilisateur

L’utilisateur ne perçoit pas l’architecture sous-jacente de la grille (son middlewarela masque).

• Où sont stockées mes données ?

• Où sont lancés mes calculs ? Ne pas s’en soucier !!

5

L’utilisateur se contente de soumettre des requêtes à la grille ! GRID

Grid-Computing

1-Introduction

• Motivations

6

• Motivations

(2)

Grille de Super-Ordinateurs

7

• Grids de super-calculateurs

• Grids de super-clusters de PC

Interconnexion par des réseaux rapides

Pour supporter des calculs plus importants (« size up »)

Grilles de ressources inutilisées

Optimisation de ressources à grande échelle

8

Pour exécuter un grand nombres de calculs indépendants :

• Ex: Seti@Home !!

• Typiquement des grilles de PC à travers Internet

→ “Desktop Grids”

• Grilles hautement dynamiques : les noeuds “disparaissent”

de la grille à tout moment (récupérés par leurs propriétaires)

Grilles de données

Partage de données à grande échelle :

gros volumes et grand nombre de lecteurs distribués

9

lecteurs distribués

Ex : les résultats d’expérience du CERN ! Problématiques :

• migration/réplications de données ?

• catalogue distribué ou centralisé de réplicas ?

• maintien de la cohérence du catalogue et des réplicas ?

Grille collaborative

Réalité virtuelle Réalité augmentée

10

Usage conjugué de réalité virtuelle et de calcul distribué :

• Exemple: réseau de “caves” et de supercalculateurs graphiques

• Aspects temps-réel dans les transmissions

• Grosse demande … mais très complexe !

Grid-Computing

1-Introduction

• Motivations

11

• Motivations

Analogie avec les grilles de gas/élec.

• Dans le passé : production, stockage et consommation locales

• Puis : interconnexion pour “ajustement” (en cas d’imprévu)

• Aujourd’hui: production, stockage et consommation indépendants et réseau d’interconnexion à large débit

→Plus souple, tolérant aux pannes, … 12

GRID !

(3)

Conditions d’émergence d’une grille

Grille Réseau de

ressources Technologie

mature Intérêt du

marché Interêt

industriel Support du

gouvernement

13

Observations des grilles passées (gaz, électricité, eau, …):

• Il faut dépasser les habitudes …

… l’évolution technologique ne suffit pas à l’émergence !

• Pour émerger une grille à besoin :

• d’une technologie mature

• d’intérêts (pressions) de l’industrie et du marché

• d’une impulsion gouvernementale (politique)

Emergence des grilles informatiques

Pb technologique plus complexe que les grilles de gaz/elec/eau : - Ressources et besoins plus variées

- Quelquefois les nœuds peuvent consommer ou produire - Problème de confidentialité des données et traitements

Intérêt du

Intérêt Support du

Technologie

14

Aujourd’hui la technologie logicielle n’est pas complètement mature!

Grille Réseau de

ressources

marché

industriel pp

gouvernement matureg

Hypothèses d’émergence …

La “technologie de l’information” évolue très vite :

• La densité d’intégration des circuits intégrés, la puissance des CPUs, la tailles des disques, la vitesse des réseaux …

… évoluent exponentiellement !

• Evolution plus rapide que celle du gas/électricité/eau

15

Hyp 1: Les grilles informatiques apparaîtront plus vite car leur technologie évolue plus vite Hyp 2: Les grilles informatiques apparaîtront moins

vite car leur technologie est instable !

?

En 2002 :

En 2009 :

Emergence constatée en 2009

En 2009 :

Les «e-science Grids» sont des réalités académiques

• On a interconnecté et globalisé/virtualisé des super-calculateurs (ou gros clusters).

• Les applications et les données n’ont pas un très haut niveau de confidentialité.

• Généralement on déploie un calcul sur un seul site

16

Généralement on déploie un calcul sur un seul site.

Les «enterprise Grids» sont des réalités industrielles :

• On a plongé des technologies de « Grid » dans un réseau d’entreprise sécurisé.

• On utilise des ressources fiables.

Les «clouds» deviennent une réalité industrielles :

•Au sein d’une entreprise : autre nom des « enterprise Grids »

•Des gestionnaires de « clouds » ont de nombreux clients qui leur achète des ressources « à la demande ».

Grid-Computing

2 – Exemple d’utilisation d’une Grille :

17

d une Grille :

data-mining distribué

Un utilisateur veut créer une base de données en fouillant des bases de données “en ligne”, et en utilisant des pgms de fouille optimisés également “en ligne”.

Grid computing: exemple d’utilisation

“Data-Mining” distribué

Utilisateur de la grille

18

p g g

• Il va découvrir, accéder et utiliser des ressources distantes (données, espace disque, capacités de calcul).

• Il va rejoindre le portail d’une

« organisation virtuelle » (V.O.) et exécuter un pgm de haut-niveau.

Portail de

« V.O. »

Grille de ressource

s

(4)

“Data-Mining” distribué

1/6 – L’utilisateur contacte le portail d’une communauté de data-mining.

C’est une “registry” (annuaire) qui sait quels sites peuvent fournir des fonctionnalités de fouille et des capacités de stockage.

19

“Data-Mining” distribué

2/6 – Le portail (“registry”) retourne des références sur des générateurs (“factories”) de pgms de fouille optimisés, et sur des générateurs de bases de données. L’utilisateur ou son programme fait un choix.

20

“Data-Mining” distribué

3/6 – Le programme de l’utilisateur fait des requêtes aux générateurs pour qu’ils assemblent des services de fouille, et qu’ils créent une base de données.

21

“Data-Mining” distribué

4/6 – Deux nouveaux servicessont créés : un service de fouille et une base de données (principe du “tout est service”!)

22

“Data-Mining” distribué

5/6 – Le service de fouille interroge des bases de données distantes. Il agit comme un client qui aurait l’identité de l’utilisateur (délégation d’autorité – ex: Globus-3/OGSA).

23

“Data-Mining” distribué

6/6 – Les résultats des interrogations sont retournés directement à la nouvelle base de données. Le pgm utilisateur envoie des msgs

“keepalive” pour maintenir les servicescréés et les résultats.

24

(5)

Grid-Computing

3 – Environments de Grille

• Globus

25

Globus

• Unicore - EuroGrid

• XtremWeb

• Les “NES” (NetSolve, Diet, Ninf)

• ProActive

• JavaSpaces

Environnements de Grille

GLOBUS

Un middlewareet un projet de grille complet Globus-I, -II, -III, IV:

Low-level toolkit

High-level Grid services Découverte et gestion de ressources

Gestion et transfert de données Authentification et sécurité

…

26

Recherche Testbeds

Développement Applications

Calcul à haute-perf distribué Calcul à haute-perf depuis un PC Télé-immersion Gusto

Data-Grid National Fusion Collaboratory

Meta-Computing Toolkit

GLOBUS

1997-98 2000-01 2002-03

Grid Architecture Open Grid Services Architecture L’architecture de Globus évolue et se complexifie :

27

Application Application

Collective Resource Connectivity

Fabric Application

Globus toolkit modules:

Comms, Resource (al)location Authentication, Data access, Information service, … Globus services:

Adaptive Wide Area Resource Environment

Other Ser- vices Hourglass

model

GLOBUS

2002-03 2004-05

Open Grid Services Architecture

L’architecture de Globus évolue et se complexifie :

OGSA and Web-services

28

Application

Network

OGSA Enabled

Storage

OGSA Enabled

Servers

OGSA Enabled

Messa- ging OGSA Enabled Directory OGSA Enabled File Systems OGSA Enabled Database OGSA Enabled Work-

flow OGSA Enabled Security OGSA Enabled

Web Services OGSI – Open Grid Services Infrastructure OGSA Architected Services

Applications

Modèle du « sablier » Environnements de Grille

Globus-I : pour comprendre la grille

• Services globaux (collectifs)

• Adaptabilité : maintenir les fonctionnalités quand la grille évolue

high level Applications

adaptative

29

• Fonctionnalités locales à chaque ressource avec une interface standard

Ex : authentification sur la ressource locale Ex : authentification sur toute la grille

• Hétérogénéité et pannes possibles low

level modules

level services

Ressources distribuées

• Ensemble (minimal) de fonctionnalités standards sur chaque ressource

Globus-I : pour comprendre la grille

liaison ATM – rapide ($$) Internet – “best effort”

Exemple d’application adaptative (dynamiquement) :

30

Application adaptative

levelLow modules

Highlevel services

Ressources distribuées Measure-performance-comm.

if (Internet-not-loaded) use-Internet

else

use-and-pay-ATM-link

Implantation :

- Utilisation d’un service (haut niveau) disponible - Implantation d’un nouveau service (haut niveau) - Implantation directe dans l’application

(6)

Globus-I : pour comprendre la grille

High level services Applications

adaptative Chaque site et ressource de la grille possède ses outils

d’authentification …

- Un utilisateur s’authentifie une seule fois, grâce à un service de haut niveau (ayant une interface standard) Exemple de relation entre services de haut et de bas niveau :

31

Low level modules Ressources distribuées - Il est automatiquement authentifié auprès des ressources

qu’il utilise, grâce à des modules de bas niveau

Globus-II : décomposition plus fine

Architecture en 4 couches (le sablier s’épaissit) :

•Collective: Coordination des différentes ressources

•Resources: Accès et partage de chaque ressource (indépendamment)

•Connectivity: Communications sécurisées (avec authentification)

•Fabric: Interface avec les module propres aux ressources locales

32

Application Collective Resource Connectivity

Fabric Low level modules

High level services

Modèle sablier de Globus-I

Globus-II : nouvelle décomposition

Architecture en 3 groupes de services thématiquestransversaux :

Basé sur une extension de FTP (GridFTP) Basé sur des

mécanismes d’annuaires

33

Basé sur des échanges de « certificats »

( )

d annuaires (LDAP)

Basé sur des annuaires,

« schedulers », et files d’attente

Globus-II → Globus-III

Globus-IIest opérationnel mais complexe à déployer Chaque « service/module » se programme différemment !

34

Conception d’une nouvelle architecture plus riche et plus homogène

Globus-III et l’architecture OGSA Incluent des concepts provenant des web-services

GLOBUS-III : Architecture OGSA

Software architecture definition Principes de base :

Un nouveau découpage en couches intégrant des « web services »

35

Grid-Service

“template”

Service orientation

Virtualization &

Service composition

Un début de sémantique de grille !

« Tout est service. »

Les services peuvent se composer facilement.

(programmation en WSDL – SOAP – UDDI & XML) Rapprochement

des web-services

Globus-III : Architecture “OGSA”

Services de haut niveau utilisant des services GT3 et autres Ex: gestion des données, user

Un autre découpage en couches …

Applications

WSDL, SOAP, UDDI

36

Services locaux avec interface standard Services de bas niveau Ex: transfert des données, monitoring

g ,

gestion de la charge user

Distributed resources

(7)

Globus-III : Architecture “OGSA”

Grid-Service “template” :

• Un ensemble minimum d’interfaces et de fonctionnalités standards

• Tout service OGSA doit respecter un gabarit standard

37

• Un ensemble minimum d’informations normalisées sur le service (fonctionnalités, nature, …)

• Permet à tout service d’analyser un autre service (de le « découvrir »).

• Permet à deux services de dialoguer plus facilement.

→ début de sémantique de grille !

Globus-III : Architecture “OGSA”

Programmation des services de grille :

• Langages de prog. des “web-services” : WSDL, SOAP, UDDI et XML

• Définition de l’interface (unique) du service

• Programmation (multiple) du corps du service Interface unique Exemple:

38

HTTP:

Protocole pour des opérations distantes

Protocole pour desIPC:

opérations locales Exemple:

choix de la qualité de comm.

Interface unique Protocole sans

détection d’erreur Protocole garantissant une communication exacte recherche dep

l’efficacité optimale

Globus-III → Globus-IV

Globus-III & OGSA : bonnes idées !!

Mais ré-inventent une partie des concepts des web-services

39

Conception d’une nouvelle architecture plus associée aux web-services

Globus-IV et WSRF

Convergence/fusion des web-services et des grid-services

Globus-IV : Architecture initiale

OGSA Architected Services Applications

Grid-services de haut-niveau

Mé i

40 Network

OGSA Enabled

Storage

OGSA Enabled

Servers

OGSA Enabled

Messaging OGSA Enabled Directory OGSA Enabled File Systems OGSA Enabled Database OGSA Enabled Workflow OGSA Enabled Security OGSA Enabled

Web Services OGSI – Open Grid Services Infrastructure

Grid-services de bas-niveau implantés en

technologie web-services Mécanismes spécifiques et web-services

Globus-IV : Web/Grid - services

Convergence des Grid et Web services

Convergence !

Démarrent avec des applications

“Web Services Resource Framework”:

WSRF

41

Les deux « communautés » ont identifié des intérêts communs Futurs Grid et Web services : langages et sémantiques communs

Convergence !

applications et technologies

éloignées

OGSA Architected Services Applications

Globus-IV : architecture finale

Applications

De (nouveaux) web-services implanteront tous les Grid-services de bas niveau :

42

Network OGSA Enabled Storage

OGSA Enabled Servers

OGSA Enabled

Network

OGSA Enabled

Storage

OGSA Enabled

Servers

OGSA Enabled

Web Services OGSA Architected Services

WSRF

(8)

Grid-Computing

3 – Environments de Grille

• Globus

43

Globus

• XtremWeb

• ProActive

• JavaSpaces

EuroGrid-Unicore (2001-2003)

Unicore: un middleware de grille Européen très orienté “sécurité”

EuroGrid: une plate-forme de test Européenne (testbed) Recherche

Testbeds

Développement Applications

• Un projet de Grille complet (comme Globus)

44

Biologie moleculaire

Prédictions météorologiques

CAO/CFAO (EADS)

Calcul intensif Testbeds Applications

• Quatre domaines d’application et d’évaluation :

EuroGrid-Unicore : le middleware

Architecture d’Unicore :

1 -Interface client: fonction de soumission et de

• Architecture classique en 3 parties pour interconnecter des sites de calcul intensif

• Une forte proportion de couches de sécurité

45

3 -Serveur Unicore : schedulinget exécution sur un site de calcul de soumission et de contrôle de tâches

2 -Passerelle : point d’entrée d’un site de calcul intensif

Grid-Computing

3 – Environments de Grille

• Globus

46

Globus

• XtremWeb

• ProActive

• JavaSpaces

XtremWeb : principes de base

Un middleware de grille pour la distribution de calculs indépendants et la récupération de puissances de calcul inutilisées

Cluster de PC (worker)

47

Serveur XtremWeb

Internet

( )

“Desktop PC”

(clientou worker) Applications

“embarrassingly parallel”

(client)

XtremWeb : principes de base

Un serveur de tâches (le « scheduler ») Des serveurs de calcul dédiés

Des « desktop PC » qui peuvent être à tout moment :

• utilisés à d’autres tâches (mode « user »)

• utilisés pour soumettre des tâches à XtremWeb (mode « client »)

• utilisés pour traiter des tâches XtremWeb (mode « worker »)

48

• utilisés pour traiter des tâches XtremWeb (mode « worker »)

Poste « client »

« Worker » : Serveur (de calculs) dédié

Poste « worker »

Serveurs de tâches XtremWeb Poste « user »

Poste « client »

(9)

XtremWeb : communications

Exige “peu” des firewalls des sites clients/workers(stateless firewall):

• Communications initiées par le client

• Données du serveur envoyées en réponse aux requêtes du client

User/Worker Serveur de tâches

Rq : hostRegister Contacte le dernier serveur XtremWeb Devient

inutilisé Enregistre le

nouveau worker

49

contacté ou bien le serveur “root”

Rq : workRequest Envoie ses caractéristiques, et demande une tâche

Rq : workAlive Signale son activité a son serveur de tâche

Rq : workResult Envoie le résultat au serveur désigné et à son serveur de tâche

Attend une tâche

Traite une tâche

Tâche terminée

Retourne une tâche : - code binaire, - données - @ serveur à qui

répondre Re-planifie la tâche si aucun signal d’activité reçu

Grid-Computing

3 – Environments de Grille

• Globus

50

Globus

• XtremWeb

• ProActive

• JavaSpaces

NES : Network Enabled Servers Appel de serveurs et de codes de calculs distants

Principes des “NES”

//GridRPC

51

… grpc_call…

… Allocateur de

ressources et équilibreur de charge (« brooker »

ou « agent »)

Serveurs de puissance de calcul et de codes de calcul (« solvers ») Poste

utilisateur Programme

utilisateur

Interface de programmation standard : GridRPC

Middleware spécifique (NetSolve, Ninf, Diet)

Ressources distribuées

+ +

Principes des “NES”

5 composants conceptuels : Constituants de l’agent ou du «brooker» Client

Data- base

1 3

52

Analyse et ordonnancement sur demande du client

Mesure de performances permanente

Server Server Server

Server Server Server Scheduler

Monitor Monitor Monitor

base 2

4 5

Principes des “NES”

Fonctionnement type du middleware :

1-requête de calcul

Client Agent

3- 1– Le client soumet une requête

à l’agent

2– L’agent retourne une liste de serveurs adéquats

53

Serveur Serveur Serveur info données

4-résultat 2-liste de serveurs q

3– Le client contacte les serveurs indiqués jusqu’à ce que l’un d’eux réponde, puis lui envoie les données et le calcul démarre 4– Le serveur retourne ses résultats

au client

L’utilisateur ne voit qu’un simple RPC

Principes des “NES”

L’agent : un élément critique

• Traite toutesles requêtes client

• Doit connaître les caractéristiques de tous les composants de la grille (solveurs, serveurs et réseau)

Utili d til d t d

54

Les performances de la grille dépendent de celles de l’agent.

L’agent est un point d’engorgement potentiel du NES !!

• Utilise des outils de mesure et de prédiction de performances (temps de calcul, charge des serveurs, trafic réseau)

Agent

EtatCharge Caractéristiques

(10)

NetSolve : une implantation de NES

University of Tennessee University of Tennessee

Netsolve Agent Application:

C, Fortran, Matlab Mathematica

Netsolve Proxy

Netsolve Servers & Solvers:

C, Fortran Netsolve Problem+

Description File

55

• Un bus Corba pour gerer les (objets) solveurs et les communications

• Des « proxy » pour éviter les engorgements sur l’agent

• Des fichiers de description des interfaces et de la complexité des solveurs, pour prédire les temps de calculs

Bus Corba

p

NetSolve : une implantation de NES

Fonctionnement du middleware :

• Un processus séparé appelé « proxy » réside sur chaque poste client

requête Un PC

• Il s’informe de l’état de la grille auprès de l’Agent quand celui-ci est disponible

56

NetSolve Client

NetSolve Proxy

NetSolve Serveur données &

résultats

NetSolve Agent

rq info liste est disponible

• Il traite les requête de son client à la place de l’Agent (« cache »)

→ diminue les engorgements

DIET : une implantation de NES

Distributed Interactive Engineering Toolbox Client

MA MA MA

Master

A t

B u

• Un bus Corba pour gerer les (objets) solveurs et les communications

• Une hiérarchie d’agents pour

57

Local Agents &

Server Daemons:

monitoring MA

MA MA

MA

LA LA LA SeD SeDSeDSeD

LDAP LDAP LDAP Agents:

scheduling

Serveurs de calcul

u s C o r b a

g p

éviterles engorgements

• Des outils de mesure et de prévision des performances

Architecture conçue pour la gestion de grandes grilles (pour le « passage à l’échelle »)

Persistance des données dans les NES

Pb : On réutilise des données dans des séquences d’opérations …

→ Ne router qu’une fois ces données du client vers le serveur

→ Conserver les résultats intermédiaires sur le serveur de calcul

A B A B

R = ((A B) A)

58

client serveur

A,B R₁

client serveur

A,R1

R

client serveur

A,B

client serveur

R R₁= A B

R = R₁ A

Sans persistance Avec persistance

• NetSolve : regroupement des opérations en « séquences »

• DIET : définition de données « persistante » ou « volatile »

Grid-Computing

3 – Environments de Grille

• Globus

59

Globus

• XtremWeb

• ProActive

• JavaSpaces

ProActive

Basé sur des JavaRMI, mais plus simple que les JavaRMI :

• Les « stubs » des objets distants sont masqués à l’utilisateur

• Objets locaux ou distants : identiques

Un environnement de programmation des systèmes distribués pour l’exploitation de clusters, de Grilles ou de systèmes P2P.

60

j q

Composition :

• Un ensemble de classes Java

• Des fichiers XML de définition du système distribué Applications :

• Clients/serveurs et Parallélisme sur cluster, Grille ou système P2P

(11)

ProActive

Concept d’Objets Actifs

• Simples à créer

• Permettent du parallélisme sur des clusters ou à travers Internet

61

• Appels d’objets actifs : toujours asynchrones

• Pas de partage des objets passifs (entre objets actifs)

• Objets passifs passés par valeur (par recopie) aux objets actifs Concept de variables futures

• synchronisation « par nécessité » • Tous les appels d’O. actifs

Grid-Computing

3 – Environments de Grille

• Globus

62

Globus

• XtremWeb

• ProActive

• JavaSpaces

JavaSpaces/Jini

Le modèle JavaSpaces

• Une mémoire partagée virtuelle entre processus distribués

• Les processus n’interagissent pas directement

• Les processus interagissent par le biais d’un ou plusieurs JavaSpaces

D’après des documents de Robert Gérin-Lajoie, CIRANO63

JavaSpaces/Jini

Composants d’un JavaSpaces

Services Jini supportant un JavaSpace : _Tolérance

aux pannes

64

Peuvent être lancé en mode :

• « persistant » : objets stockés dans le JavaSpaceet sur disque

• « activable » : services redémarrés automatiquement en cas de panne du service.

Tolérance aux pannes

JavaSpaces/Jini

Qu’est-ce qu’un JavaSpaces

• Un très petit nombre d’opérations sont définies sur un Space – Lire

– Prendre – Écrire

– ReadIfExists() // Lire sans bloquer – TakeIfExists() // Prendre sans bloquer

65

+ un mécanisme de notification d’évènements à travers le réseau

JavaSpaces/Jini

Qu’est-ce qu’un JavaSpaces

• Les objets déposés (les « Entry ») sont des objets typés qui peuvent contenir du code exécutable.

• La lecture et récupération d’objets se fait par appariement (pattern- matching) avec des patrons d’objets :

– Les champs non assignés sont des « jokers »

66

– Basé sur les «tuple-spaces» (voir David Gelernter’s avec le système Linda)

• Les opérations sont transactionnelles si souhaité (contribue à la résistance aux pannes)

• Les clients peuvent s’enregistrer sur les opérations d’écriture avec la méthode «notify»

(12)

JavaSpaces/Jini

Bilan des JavaSpaces

Points forts :

• Simple d’utilisation (peu de primitives)

• Plusieurs implantation Open-Source et Industrielles existent

• Traitent beaucoup de problèmes (outil générique)

67

p p ( g q )

• Possèdent un mode transactionnel (op réversibles jusqu’au commit) : aide à la tolérance aux pannes.

• Les implantations à stockage réparti ont de grandes capacités d’extension (passage à l’échelle). Ex :

• Un point clé de leur réalisation est l’indexeur des données

Grid-Computing

4 – Une expérience de Grille

68

mondiale pour le CERN

Expérience de Grille mondiale pour le CERN

DATA-Grid pour le LEP

“Next generation of scientific exploration, with intensive computing and analysis of shared large scale datasets, across widely distributed scientific communities”

Projet Européen (FP5 - 2001-2003) :

• 15 pays – 21 institutions – 200 personnes

•100 TBytes – 1 PBytes

69

• Physique, Biologie, Environnement

• Basé sur Globus-II

DATA-Grid pour le LEP

Extension de l’architecture de Globus-II :

Besoin d’un transfert automatique de fichiers

Output files Input files

PC local Ressource

distante

70

• Modèle en sablier de Globus-II

•Ajout de 16 nouveaux services

• Utilisation de OpenLDAP

High level Grid middleware (high level Grid services)

OS & Net services Application layer VO common application layer

Basic services (Globus-II toolkit)

Le «replica manager» et le «replica catalogue service» gèrent

DATA-Grid pour le LEP

Exemple de nouveau service de gestion de données :

Les gros fichiers accédés depuis de nombreux points de la grille sont « répliqués » par morceaux, pour éviter un engorgement et utiliser au mieux la bande passante du réseau.

71

la création des réplicas et leur accès automatique.

logical file name

physical file name

physical file physical name

file name

replicas replica

catalogue service

replica manager

DATA-Grid pour le LEP

Exemple de constitution et de publication d’un annuaire global :

• Chaque ressource lance un service “Globus GRIS” (local monitoring) et publie les résultats dans un annuaire local (LDAP).

• Certaines ressources lancent des services « Globus GIIS » qui collectent les résultats et les re-publient dans de nouveaux annuaires.

U hié hi d GIIS t éé t i l b l t blié

72

• Une hiérarchie de « GIIS » est créée et un annuaire global est publié.

new LDAP

ResourceGRIS local info local LDAP

GIIS Global LDAP

GIIS GIIS GIIS GIIS GIIS GIIS

(13)

Data & Computing Grid pour le LHC

•15 PetaOctets/an

•Enormément de calculs

Une grille de calcul

&

Du calcul volontaire (réaliste ?)

73

LHC@home LCG : LHC

Computing Grid

?

Data & Computing Grid pour le LHC

LCG : the LHC Computing Grid

• Une grille de grilles

avec plusieurs environnements interconnectés

• Des Virtual Organizations

74

selon les thématiques de travail

Data & Computing Grid pour le LHC

LCG : the LHC Computing Grid Un système hiérarchique de nœuds T-tiers

pour produire, stocker, cacher et calculer, inspiré de l’expérience DATA-GRID LEP

75

Nœuds T-0 : CERN production de données Nœuds T-1 : Sites de stockage dans le monde

Nœuds T2 : nœuds de stockage partiel dans le monde (cache de BdD) Nœuds T3 : nœuds de calcul (ex : clusters)

Grid-Computing

5 – Bilan des Grilles

76

Bilan des Grilles

Bilan de l’architecture logicielle

rsrc rsrc rsrc rsrc

Infrastructure réseau Routage, contrôle, supervision réseau

Middleware de Grille Application distribuée Environnement de développement

77

Env. de dev.

Middleware générique

de Grille Globus

MPI-G Env. de dev.

Middleware générique

Corba + VPN GridRPC Middleware

spécifique ProActive

JavaRMI + JVM

DIET middl.

ProActive middl.

Deux stratégies :

• ambitieux middleware générique de Grille (ex : Globus)

• middleware générique traditionnel + complément spécifique

Bilan des Grilles

Bilan de l’architecture logicielle

rsrc rsrc rsrc rsrc

Infrastructure réseau Routage, contrôle, supervision réseau

Middleware de Grille Application distribuée Environnement de développement

78

Différents objectifs :

• des langages de programmation de bas niveau - pour les clients/serveurs : GridRPC - pour le parallélisme : MPI

• des langages de plus haut niveau - générique : ProActive

- pour l’exploration multi-paramètres : XtremWeb

ProActive XtremWeb MPI GridRPC

(14)

Grid-Computing

6 – Autres exemples de Grilles

79

Projets génériques internationaux

EGEE

• 70 participants

80

p p

• 27 pays (en augmentation)

« Une Grille de productionpour la recherche scientifique (e-science Grid) »

Basé sur un middleware de grille conçu pour la grille EGEE (Open-Source) The Enabling Grids for E-sciencE (EGEE) project is funded by the European Commission and aims to build on recent advances in grid technology and develop a service grid infrastructure which is available to scientists 24 hours-a-day

EGEE

Utilisateurs en 2008 :

81 LHC ?

EGEE

Bilan en 2008 :

• 259 sites connectés, provenant de 52 pays

• CPUs utilisables 24/7 : 72000

• Espace disque : 20 PetaOctets

• VO : 150 à 200

82

• Users : 7500 à 14000

• Nombre de jobs : 150000/jour

• Projet « Egee actuel » : 9Durée : 2 ans

9Budget : 47MEuros (dont Commission Européenne : 32MEuros) + 50MEuros de matériel apporté par les membres.

Une grille de production scientifique bien utilisée!

DEISA

83

« Une grille de production ou un ensemble (?) de supercalculateurs, pour la recherche scientifique » S’appuie sur des technologies propriétaires.

DEISA

•The fundamental integration conceptin this area is transparent access to remote data files via a global distributed file system.

• Processes can be executed on any node

( )

Global Parallel File System(technologie IBM) :

84

(they can access their data).

(15)

Projet Français actuel

Grid’5000

15 clusters sur 9 sites Réseau privé RENATER : 2,5 Gbit/s à 10 Gbit/s Processeurs AMD Opteron d 2 Gh à 2 4 Gh

85

de 2 Ghz à 2,4 Ghz Environ 5000 coeurs en 2009

Point fort : déploiement d’ OS à la demande!

Grid’5000 est une grille d’expérimentation.

Grid-Computing

7 - Acteurs industriels

86

Produits industriels

Acteurs industriels

Développeurs de produits:

IBM Oracle

Sun Microsystems Amazon

D S

Utilisateurs de « clouds » ou

« d’enterprise Grid »:

87

Data Synapse Platform Computing

…

Vendeurs de ressources:

Amazon Salesforce.com Google

…

« d enterprise Grid »:

BNP-Paribas Société Générale PSA

…

Introduction au Grid computing FIN

88