Technologies pour le Metacomputing Thierry Priol IRISA/INRIA.

Technologies pour le Metacomputing

Thierry Priol

IRISA/INRIA

Métacomputing

Introduction, définition et applications

Technologies pour le Metacomputing

Cobra: un environnement fondé sur CORBA Un exécutif pour des grappes de PC Concept d’objet CORBA parallèle

Quelques applications en cours de réalisation Traitement du signal Réalité virtuelle

Introduction, définitions

Metacomputer (métacalculateur) Collection de calculateurs/supercalculateurs Dispersion géographique des calculateurs/supercalculateurs Connexion par un réseau à très haut-débit

Vision logique d’une seule machine: le métacalculateur

Il y a 15 ans, cela s’appelait tout simplement un système distribué !

Metacomputing (métacalcul) Programmation des métacalculateurs

(systèmes, éxécutifs, langages, outils, applications)

Meta application

Une application qui ne peut s’exécuter sur une seule machine limitation des ressources (puissance des processeurs, mémoire, disque) absence de certains types de ressources (visualisation, …)

Une application qui est une collection de modules relativement indépendants pouvant s’exécuter de façon asynchrone

Le parallélisme est présent à l’intérieur d’un module

Exemple d’une méta application: conception d’un satellite Analyse de structure, dynamique, thermique, optique, ...

Métacomputing: vers l’informatique de demain ?

Un accroissement sensible de la demande en ressources de calculs Généralisation des outils de simulation à tous les niveaux de l’industrie

(Petites, Moyennes et Grandes Entreprises)

Calculateurs de plus en plus complexes à utiliser

Calculateurs de plus en plus chers à maintenir

Un regard sur le passé Analogie avec l’énergie électrique...

Energie

Informatique

Applications du Métacomputing

Visualisation à distance Systèmes de réalité virtuelle (CAVE, …)

Simulation distribuée (ou Problem Solving Environment) La puissance de calcul disponible sur un simple PC permet d’envisager le

couplage de codes de simulation

Travail coopératif Faire travailler plusieurs experts simultanément sur les résultats d’une

simulation

Problèmes liés au Metacomputing

Metacomputer : une collection de machine environnement logiciel hétérogène (système d’exploitation, exécutif) pas de partage de fichiers possible règles de sécurité différentes dans chaque site

Les problèmes à résoudre Allocation de ressources Communication Gestion des données distribuées Sécurité Tolérance aux défaillances

Allocation de ressources: problèmes

Autonomie des sites participants différentes organisations avec leurs propres règles (allocation, sécurité, …)

Gestionnaire de ressources hétérogènes Condor, NQE, CODINE, EASY, LSF, PBS, LoadLeveler,…

Extensibilité ajout de nouvelles ressources, impact sur les autres sites ?

Allocation simultanée des ressources distribuées Certaines applications nécessitent une co-allocation (allocation simultanée

de ressources sur plusieurs sites)

Communication

Contraintes

Technologies réseaux variées (ATM, HIPPI, Gigabit, …) Performance (TCP/IP ?) Interopérabilité

Différentes approches:

Echange de message (PVM, MPI) RPC (DCE, …) Objet distribué (CORBA, …)

Gestion de données distribuées: problèmes

La distribution d’une application, sous forme de composants, pose le problème de l’accès aux données Chaque composant consomme et produit des données (fichiers) Echange de données (transfert de fichiers entre machines)

Mécanismes de mouvement et d’accès aux données Limitation des solutions existantes (NFS, MPI-IO, WWW, …) Contraintes de conception:

• Doit nécessiter peu de modifications dans les applications

• Ne doit pas imposer de fortes contraintes à l’installation

• Doit pouvoir exploiter le maximum de performance offerte par le réseau

Sécurité

Utilisation de plusieurs machines avec ses propres règles de sécurité Impossible de transférer des fichiers de façon transparente (mot de passe!)

Confidentialité des données Transfert de données confidentielles à l’échelle de l ’Internet Cryptage des données

Tolérance aux défaillances

Meta application: une application distribuée! Que faire si un composant de l’application tombe en panne ?

Techniques Checkpointing

• problème de la définition d’un état cohérent

• nécessite souvent la modification des logiciels (définition d’un état)

• sauvegarde des états

Réplication• impossibilité de répliquer tous les modules

• quel module choisir ?

Quelques exemples d’environnements pour le Metacomputing

Approche par échange de messages Globus

Approche par RPC (Remote Procedure Call) Netsolve Ninf

Approche orientée objet distribué Pardis Cobra

Approche par échange de messages

Globus I. Foster et C. Kesselman

Une boite à outils plutôt qu’un environnement de metacomputing

Un ensemble de services: Allocation de ressources (GRAM) Communication unicast/multicast (Nexus) Gestion de l’information, état du système (MDS) Sécurité (GSI) Monitoring (HBM) Accès aux données à distance (GASS) Gestion des exécutables (GEM)

Architecture de Globus

Allocation de ressource(GRAM)

Concept de gestionnaire local des ressources Offrir une vision homogène de l’allocation des ressources quelque soit le

gestionnaire de ressource utilisé (NQE, LSF, CODINE, …)

Service d’information Disponibilité, caractéristiques, propriétés des ressources

Langage de spécification de ressources (RSL) Langage pour exprimer un besoin particulier en ressources Exemple: &(executable=myprog)

(|(&(count=5)(mempry>=64)) (&(count=10)(memory>=32)))

Courtier de ressources Spécialisation: transformation de requêtes RSL en requêtes plus simples

avec l’ajout d’un nom de machine identifiant le gestionnaire de ressource

Allocation de ressources(GRAM)

Accès aux données(GASS)

GASS: Global Access to Secondary Storage

Un mécanisme de mouvement et d’accès aux données Optimisé pour les patrons d’accès des applications de metacomputing Implémentation de nécessitant pas de services particuliers Contrôle de l’utilisateur pour optimiser les transferts de données

• cache de donnée, filtrage, …

Problèmes à résoudre: Nommage, API, authentification, communication, performance...


Nommage par URL x-gass://host:port/filename ftp://host/filename

Interface de programmation: proche de celle d’UNIX

globus_gass_open() globus_gass_close() globus_gass_cache()

Sémantique copie vers le cache à l’ouverture mise à jour du fichier à la fermeture

si modification

Performance: optimisation pour des patrons d’accès (via un cache)

lecture-seulement (à partir du cache local)

écriture-seulement (vers le cache local)

lecture-écriture (à partir/vers le cache local)

écriture-seulement, ajout (vers le serveur à distance)

Support de GASS dans GRAM &(executable=x-gass://quad:12/file)

(stdin = x-gass://quad:12/myin) (stdout = /home/bester/output) (stderr = x-gass://qd:1/dev/stdout)

Approches par RPC

Netsolve (Univ. Tennessee) H. Casanova & J. Dongarra

Concept de librairie étendu à l’échelle d’Internet ou d’un Intranet

« Librairie virtuelle » Eviter l’installation de logiciels

Concepts de base accès à distance à des ressources de

calcul (client/serveur) Espace de nommage Données du problème sont

transmises à un serveur Interfaces avec C, Fortran, Matlab,

Java, … Equilibrage des charges entre

serveurs

NetSolve: programmationDu coté du client

Transparence de la localisation des serveurs (réseau transparent) Accès à la « librairie virtuelle » par identificateur Appel synchrone/asynchrone

parameter (MAX=100)double precision A(MAX,MAX),B(MAX)integer IPIV(MAX),N,INFO,LWORKinteger NSINFO

c Solve linear equations

call DGESV(N,1,A,MAX,IPIV,B,MAX,INFO)

call NETSL(‘DGESV()’,NSINFO, N,1,1,MAX,IPIV,B,MAX,INFO)

NetSolve: accès aux logicielsDu coté du serveur

Gestion du matériel et du logiciel Interface avec les logiciels scientifiques installés sur le serveur

• BLAS, LAPACK, ItPack, FitPack, FFTPack, NAG Software, …

Outils pour l’installation de nouveaux logiciels (Compilateur NetSolve)

Du coté de l’agent Courtier en ressources Stocke l’information concernant la disponibilité des machines sur le réseau

et des logiciels scientifiques disponibles Equilibrage des charges par prédiction des temps d’exécution

• performance du réseau

• performance du serveur (LINPACK) et de sa charge

• Temps d’exécution du logiciel en fonction de la taille du problème

Ninf (Electronical Lab., Tsukuba)Nakada et al.

Ninf Network Infrastructure for Global

Computing

Accès aux serveurs par RPC protocole dynamique + interopérabilité

Interface de programmation RPC synchrone/asynchrone Transaction Callback

Langage de description d’interface Langage IDL spécifique

Equilibrage dynamique des charges allocation dynamique des ressources

MetaServer

C Client

NumericalRoutineNumericalRoutineNumericalRoutineNumericalRoutine

NumericalRoutineNumericalRoutine

NinfServer

NinfServer



NinfServer

NinfServer



NinfServer

NinfServer

MathematicaClient

JavaClient

ExcelClient

Ninf: Interface de programmation

Caractéristiques: Langage cible: C, C++, Fortran, Java, Lisp …,Mathematica, Excel Nommage des fonctions: ninf://HOST:PORT/ENTRY_NAME

Appel synchrone/asynchrone:

double A[n][n],B[n][n],C[n][n];

/* multiplication de matrice */

Ninf_call(«ninf://etlhpc.etl.go.jp:3000/dmmul»,n,A,B,C);

id = Ninf_call_async(«dmmul»,n,A,B,C);

Ninf_wait(id);


Transaction: exploitation du parallélisme au niveau du réseau analyse de dépendance à l’exécution exécution de type dataflow

double A[n][n],B[n][n],C[n][n];

Ninf_transaction_start();Ninf_call(«dmmul»,n,A,B,E);Ninf_call(«dmmul»,n,C,D,F);Ninf_call(«dmmul»,n,E,F,G);Ninf_transaction_end();

dmmul

dmmul

dmmul

A B C D

E F

G


Callback: notification du client par le serveur exécution d’une fonction du client par le serveur

Void CallbackFunc(…) { /* corps de la fonction */}

Ninf_call(« func », arg, …, CallbackFunc);

Ninf_call

Client Serveur

CallbcakFunc

Ninf: Langage de description d’interface

Define dmmul(long mode_in int n, mode_in double A[n][n], mode_in double B[n][n], mode_out double C[n][n])“ description “Required “libXXX.o”CalcOrder n^3Calls “C” dmmul(n,A,B,C);

Spécifications: Fonctions et arguments (mode) Librairies associées aux fonctions Complexité Spécification du langage d’implémentation

NinfProcedure

IDL FileNinf StubGenerator

StubProgram

NinfComputational

Server

Ninf ExecutableNinf Executable



Ninf: équilibrage des charges

Comment répartir les calculs afin d’exploiter au mieux les ressources de calcul ? Changement dynamique de la charge (réseau, serveurs) Informations distribuées

Informations nécessaires pour une répartition équitable de la charge Caractéristiques des serveurs Etat des serveurs (charge, …) Etat des réseaux (latence, débit) Caractéristiques des applications (complexité, taille du problème, …)

Ninf: équilibrage des charges

Client

Client Side

Server Side

Client

Server

Server

DirectoryService

DirectoryService

SchedulerScheduler

Data

Throughput Measurement

Load query

Schedulequery

ClientProxy

ClientProxy

ServerProxy

ServerProxy

ServerProbe Module

ServerProbe Module

ServerProxy

ServerProxy

ServerProxy

ServerProxy

MetaServer

Approche orientée objet distribué

CORBA et le Metacomputing

CORBA est un standard pour la conception d’applications distribuées proposé par l’OMG (Object Management Group) Orienté objet Mécanisme d’invocation à distance (RPC) Indépendance vis à vis du matériel, des systèmes d’exploitation et des

langages de programmation Indépendance vis à vis des implémentations (interoperabilité) Concept de bus logiciel

Composants principaux: Interface Description Language (IDL) Object Request Broker (ORB): communication entre objets Ensemble de services (nommage, événement, …)

Architecture de CORBA

DII IDLstub

IDLskeleton

DSI

Adaptateur d’objetORB

interface

Implémentation de l’objetImplémentation de l’objetclientclient

ORB core

operation()

in args

out args + return value

GIOP / IIOP / ESIOP

Répertoired’implémentation

Répertoire d’interface

Exemple de spécification IDLinterface MatOps {

typedef long vect[100];typedef long mat[100][100];void MatVect( in mat A, in vect B, out vect C );

};

Object Request Broker (ORB)

IDL skeleton

IDL stub Object Adapter

Implémentationde l’objet

Invocation del’objet

CompilateurIDL

server->MatVect( A, B, C);

Client

Serveur

Pardis (Univ. Indiana) K. Keahey et D. Gannon

Une approche « à la CORBA » reprend les même concepts: ORB + IDL a priori non interopérable avec des implémentations de CORBA

Intégration du parallélisme Concept d’objet SPMD Concept de séquence distribuée

Support de l’asynchronisme grâce au future Associé à l’appel non bloquant d’une opération future = valeur + sémaphore Exemples d’utilisation

• Traitement des résultats intermédiaires (visualisation, mise au point, …)

• Couplage de codes (synchronisation lâche)

Pardis: concept d’objet SPMD

typedef dsequence <double,1024, (BLOCK,BLOCK)> diff_array;interface diff_object {

void diffusion( in long timestep, inout diff_array darray);};

Application A

diff_object

diff_object* diff = diff_object::_spmd_bind(“example”, HOST1);diff->diffusion(64, my_diff_array);

spmd_bind

spmd_bind

spmd_bind

Application B

diffusion

diffusion

diffusion

IDL (du service)C++ (client)

Pardis: les futures

interface direct {void solve(in mat A, in vec B,

out vec X);};

interface iterative {void solve(in double tol, mat A, in vec B,

out vec X);};

IDL service BIDL service A

direct_var = d_solver = direct::_spmd_bind(“direct_solver”, HOST_1);iterative_var = i_solver = iterative::_spmd_bind(“itrt_solver”, HOST_2);...PARDIS::future <vec_var> X1;vec_var X1_real, X2_real;

i_solver->solve_nb(tolerance, A, B, X1);d_solver->solve_nb(A,B,X2_real)

X1_real = X1;double diff = compute_diff(X1_real, X2_real);

C++ (client)

Client A B

Cobra: un environnement fondé sur CORBA

Un environnement à l’échelle d’un Intranet Problem Solving Environment Application de type client/serveur ou serveur/serveur (couplage de codes)

Adoption de standards CORBA: communication entre composants MPI: communication au sein d’un composant

Cobra un gestionnaire de ressources pour un réseau de PC/stations de travail une extension de CORBA pour supporter le parallélisme (SPMD)

CORBA et le parallélisme SPMD

Un programme parallèle SPMD est un ensemble de processus identique

Comment encapsuler un tel programme au sein d’un objet CORBA parallèle ?

procproc

proc

obj.

proc

IDLObjetCORBA

Programme ParallèleExtended-IDL

Objet CORBA parallèle

obj.obj.

obj.obj.

MPI

MPIMPI

Programme Parallèle

Processus SPMD

Concept d’objet CORBA parallèle

Talon IDL

Courtier d’objet (ORB)

Process

Serveur 1 Serveur n

Objet CORBA parallèle=

Collection d’objets CORBA

Service parallèle

...

Client

Invocationobjet


Adaptateurd’objet

SqueletteIDL


Adaptateurd’objet

SqueletteIDL

Objet CORBA parallèle mise en oeuvre

Contraintes Ne pas modifier le courtier d’objets (ORB), rester compatible CORBA

Gestion des données Distribution ou réplication des valeurs de paramètres au sein de la collection

d’objets

Invocation entre objets Objet standard objet parallèle Objet parallèle objet standard Objet parallèle objet parallèle

Interface avec les services CORBA nommage des services parallèles

Compilateur Extended-IDL

Définition de l’interface d’un service parallèle Distinction entre service standard et service parallèle Distribution des valeurs des paramètres lors d’une invocation

Génération du talon Appel simultané de chaque opération sur l’ensemble des objets de la

collection Utilisation d’une librairie de communication (MPI) au sein du talon pour la

distribution ou la redistribution des données

Génération du squelette Stockage de l’information sur la distribution des paramètres

interface [2^n] MatOps { ... };

interface [*] Compute: MatOps { ... };

Spécification du nombre d’objets au sein d’une collection

Plusieurs possibilités offertes un nombre indéterminé Un nombre fixe Une fonction

Problème de l’héritage d’interfaces

interface [*] I1 { ... };interface [4] I2 { ... };interface [2 .. 4] I3 { ... };interface [2^n] I4 { ... };

interface [*] MatOps { ... };

interface [2^n] Compute: MatOps { ... };

Spécification de la distribution des paramètres

Mode de distribution proche de celle d’HPF

void MatVect( in dist[BLOCK][*] mat A, in vect B, out dist[BLOCK] vect C );

void MatVect( const mat A, const vect B, vect C );

void MatVect( const darray_mat &A, const darray_vect &B, darray_vect &C );

CompilateurExtended-IDL

Talon Squelette

Nouveau typepour les paramètresdistribués

A

B

C

#2

A

B

C

#1

Distribution physique des données (mode in) Construction d’une requête multiple Assemblage des données distribuées (mode out)

Requests

A

C

pco->MatVect( A, B, C );

ORB

B

obj. 1

obj. 2

squ

el.

squ

el.

talon

Génération du talon

void MatVect(in dist[BLOCK][*] mat A, in vect B, out dist[BLOCK] vect C );

objetObjet

CORBAparallèle

ObjetCORBA

clientserveur

Génération du talon

Lorsque l’objet appelant est parallèle et l’appelé est séquentiel Election d’un objet pour

l’invocation Assemblage des données

Lorsque à la fois l’objet appelant et l’objet appelé sont parallèles Election d’un sous-ensemble

d’objets pour l ’invocation Redistribution des données en

fonction de la distribution chez l’appelant et celle de l’appelé

ObjetCORBAparallèle

ORB

squ

el.

obj.

ObjetCORBA

squ

el.

obj. 1

obj. p

Objet CORBAparallèle

client serveur

obj. n

talo

n

obj. 2

talo

n

obj. 1

talo

n

squ

el.

MPI

Génération du squelette

Stockage de l’information sur la distribution associée à l’objet (distributed array).

Objet1

Objet2

A

Bsq

uel

.

A

B

squ

el.

talo

n

Objet

A

B

ORB

squ

el.

Objet

ORB

void op1( in vect A, in dist[BLOCK] vect B );

void op2( in vect C );

pco->op1( A, B ); co->op2( A );co->op2( B );

talo

nta

lon

MPI

Interface avec le service de nommageLe service de nommage permet d’associer un nom à un objet

OpMat_Impl* obj = new OpMat_Impl();NamingService->join_collection("Matrice", obj);...NamingService->leave_collection("Matrice", obj);

Serveur: objet de la collection

objs = NamingService->resolve_collection("Matrice", obj);svr = OperationsMatricielles::_narrow(objs)/* ... */svr->multiplication(A,B,C);

Client

Cobra: un éxécutif pour les objets CORBA parallèles

Objectifs Exécution des objets CORBA

parallèles Allocation de ressources aux

utilisateurs Administration de la plate-forme

Contraintes Services accessibles sur le réseau

Exécutif Cobra Un ensemble de services CORBA

pour une grappe de PCs interconnectés par SCI

PC SMP 2 x Pentium Pro/II128 Mo EDO RAM2 Go DiskPCI-SCI Card

Comm.SCI

Grappe SCIAnneau SCI(200 MB/s)

Nœud de calcul

Nœud de service

L’exécutif Cobra

ORB

CORBARmProcess

ORB

ORB

ORB

Nœud de servcice

Au sein de la machine PACHA

Service/Administration NodeNode

Station de travail

ORB

Libre

Nœud de calcul

VPM 1 : 3 nœuds de calcul

ORB

Libre

Nœud de calcul

CORBARmProcess

CORBAAdminProcess

CORBAAPProcess

ORB

Proc.Util.

Comm. UNIX

ORB

Proc.Util.

Comm. UNIX

ORB

Proc.Util.

Comm. Unix

ORB

NodeProcess Obj0

ORB

NodeProcess Obj0

ORB

NodeProcess Obj0

Gestion de ressources Machine parallèle

virtuelle Région de mémoire

partagée

Administration Configuration Utilisateurs

Extensibilité Plusieurs nœuds de

service

Application de traitement du signal

IDAHO: une application de traitement du signal (électromagnétisme)

Un modèle réduit d’avion est illuminé par un faisceau pour chaque angle de (de 0 à 360°) et pour des fréquences variant de 2 à 8 GHz

L’expérience dure 90 heures et génère 1Goctets de données

Chambre

Modèle réduit sur un socle pivotant

Architecture logicielle

ServicesCobra

Objets CORBACréation de

la VPM(2)

proxyIDAHO

Objet CORBA

IDAHO

IDAHO


...

Destruction de la VPM

(6)

Initialisation (3)Exécution (4)

Visualisation (5)

Applet Java

Nœuds de serviceNœuds de calculStation de travail

ServeurWEBApache

Chargement del’applet JAVA

du serveur WEB(1)

RADIOSITE: une étape de prétraitement pour calculer l’échange d’énergie entre objets dans une scène

Le calcul du radiosité est effectué de façon itérative

Plusieurs heures de calcul

Nécessité de visualiser à chaque itération dans le cas d’un processus d’optimisation (placement de sources lumineuses)

Applications de réalité virtuelle

Résultats du calcul de radiosité

Réalité Virtuelle

VRML

Applet

Nœud de calcul

Nœud de service

ServicesCobra

Objets CORBA

Création de la VPM

(2) proxyRADIOSITY

Objet CORBA

RADIOSITY


...Destruction de la VPM

(6)

Initialisation (3)Exécution (4)

Visualisation (5)

ServeurWEBApache

Chargement del’applet JAVA

du serveur WEB(1)

Station de travail

RADIOSITY

RADIOSITY

Conclusion & perspectives

Metacomputing

De nombreux systèmes existent mais ne sont pas interopérables! On réinvente souvent la roue! Réels besoins: à l’échelle de l’INTERNET ou de l’INTRANET ?

Nos travaux actuels et le futur proche Approche: utilisation et extension de standards existants Conception d’un ORB efficace (ESIOP) Système de gestion de données (service CORBA) Langage de coordination pour la conception d’applications Applications via des contrats (Aerospatiale, Esprit Jaco3, Soft-IT)

Technologies pour le Metacomputing Thierry Priol IRISA/INRIA.

Documents

Transcript of Technologies pour le Metacomputing Thierry Priol IRISA/INRIA.