Technologies pour le metacomputing
Download
1 / 59

Technologies pour le Metacomputing - PowerPoint PPT Presentation


  • 102 Views
  • Uploaded on
  • Presentation posted in: General

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha

Download Presentation

Technologies pour le Metacomputing

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


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étacalculateurIl 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


GlobusI. 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)

Accès aux données(GASS)


Accès aux données(GASS)


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: programmation

  • Du 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,LWORK

integer NSINFO

cSolve 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 logiciels

  • Du 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

Server

Ninf

Server

Ninf

Server

NumericalRoutine

NumericalRoutine

NumericalRoutine

NumericalRoutine

NumericalRoutine

NumericalRoutine

NumericalRoutine

NumericalRoutine

NumericalRoutine

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

C Client

Excel

Client

MetaServer

Java

Client

Mathematica

Client


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


A

B

C

D

dmmul

dmmul

E

F

dmmul

G

Ninf: Interface de programmation

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


Ninf: Interface de programmation

  • Callback:

    • notification du client par le serveur

    • exécution d’une fonction du client par le serveur

Client

Serveur

Ninf_call

Void CallbackFunc(…) {

/* corps de la fonction */

}

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

CallbcakFunc


Ninf Executable

Ninf Executable

Ninf Executable

Ninf: Langage de description d’interface

  • Spécifications:

    • Fonctions et arguments (mode)

    • Librairies associées aux fonctions

    • Complexité

    • Spécification du langage d’implémentation

Ninf

Computational

Server

Definedmmul(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^3

Calls “C” dmmul(n,A,B,C);

Stub

Program

Ninf

Procedure

Ninf Stub

Generator

IDL File


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

Directory

Service

Server Side

Server

Proxy

MetaServer

Client Side

Scheduler

Server

Probe

Module

Server

Proxy

Client

Server

Load

query

Schedule

query

Data

Client

Client

Proxy

Server

Proxy

Server

Throughput

Measurement


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

in args

operation()

Implémentation de l’objet

client

out args + return value

Répertoire

d’implémentation

IDL

skeleton

DSI

Répertoire d’interface

IDL

stub

ORB

interface

DII

Adaptateur d’objet

ORB core

GIOP / IIOP / ESIOP


Exemple de spécification IDL

interface MatOps {

typedef long vect[100];

typedef long mat[100][100];

void MatVect( in mat A, in vect B, out vect C );

};

Implémentation

de l’objet

Compilateur

IDL

Serveur

Invocation de

l’objet

Client

IDL skeleton

IDL stub

Object Adapter

Object Request Broker (ORB)

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


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

IDL (du service)

C++ (client)

typedef dsequence <double,1024,

(BLOCK,BLOCK)> diff_array;

interface diff_object {

void diffusion(in long timestep,

inout diff_array darray);

};

diff_object* diff =

diff_object::_spmd_bind(“example”,

HOST1);

diff->diffusion(64, my_diff_array);

spmd_bind

diffusion

spmd_bind

diffusion

spmd_bind

diffusion

Application A

diff_object

Application B


Pardis: les futures

IDL service A

IDL service B

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

};

C++ (client)

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

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 ?

Programme Parallèle

Objet

CORBA

IDL

Programme Parallèle

Extended-IDL

MPI

MPI

obj.

obj.

proc

proc

obj.

proc

proc

MPI

obj.

obj.

Processus SPMD

Objet CORBA parallèle


Implémentation

de l’objet

Implémentation

de l’objet

Squelette

IDL

Squelette

IDL

Adaptateur

d’objet

Adaptateur

d’objet

Concept d’objet CORBA parallèle

Serveur 1

Service parallèle

Serveur n

Process

Objet CORBA parallèle

=

Collection d’objets CORBA

Client

Invocation

objet

...

Talon IDL

Courtier d’objet (ORB)


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


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 [*] MatOps { ... };

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

interface [*] I1 { ... };

interface [4] I2 { ... };

interface [2 .. 4] I3 { ... };

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

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

interface [*] 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 );

Nouveau type

pour les paramètres

distribués

Compilateur

Extended-IDL

void MatVect( const mat A,

const vect B,

vect C );

void MatVect( const darray_mat &A,

const darray_vect &B,

darray_vect &C );

Talon

Squelette


#2

#1

A

A

B

B

C

C

Génération du talon

  • Distribution physique des données (mode in)

  • Construction d’une requête multiple

  • Assemblage des données distribuées (mode out)

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

void MatVect(in dist[BLOCK][*] mat A,

in vect B,

out dist[BLOCK] vect C );

talon

squel.

obj. 1

A

objet

Objet

CORBA

parallèle

Objet

CORBA

B

squel.

obj. 2

C

ORB

Requests

serveur

client


obj. 1

talon

obj. 2

talon

obj. n

talon

Génération du talon

ObjetCORBA

parallèle

  • 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é

Objet

CORBA

squel.

obj.

Objet CORBA

parallèle

squel.

obj. 1

MPI

squel.

obj. p

ORB

client

serveur


Génération du squelette

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

void op1( in vect A,

in dist[BLOCK] vect B );

A

squel.

Objet

1

talon

void op2( in vect C );

B

A

squel.

Objet

Objet

talon

MPI

B

squel.

A

Objet

2

talon

ORB

ORB

B

co->op2( A );

co->op2( B );

pco->op1( A, B );


Interface avec le service de nommage

  • Le service de nommage permet d’associer un nom à un objet

Serveur: objet de la collection

OpMat_Impl* obj = new OpMat_Impl();

NamingService->join_collection("Matrice", obj);

...

NamingService->leave_collection("Matrice", obj);

Client

objs = NamingService->resolve_collection("Matrice", obj);

svr = OperationsMatricielles::_narrow(objs)

/* ... */

svr->multiplication(A,B,C);


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

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

Nœud de calcul

Anneau SCI

(200 MB/s)

Grappe SCI

Comm.

SCI

PC SMP

2 x Pentium Pro/II

128 Mo EDO RAM

2 Go Disk

PCI-SCI Card

Nœud de service


Gestion de ressources

Machine parallèle virtuelle

Région de mémoire partagée

Administration

Configuration

Utilisateurs

Extensibilité

Plusieurs nœuds de service

L’exécutif Cobra


Application de traitement du signal

Modèle réduit sur un socle pivotant

  • 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


IDAHO

IDAHO

Architecture logicielle

Chargement de

l’applet JAVA

du serveur WEB

(1)

Serveur

WEB

Apache

Objet CORBA parallèle

Création de la VPM

(2)

Objets CORBA

...

Services

Cobra

Destruction de la VPM

(6)

Objet CORBA

Applet Java

proxy

IDAHO

Initialisation (3)

Exécution (4)

Visualisation (5)

Station de travail

Nœuds de calcul

Nœuds de service


Applications de réalité virtuelle

Résultats du calcul de radiosité

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


RADIOSITY

RADIOSITY

RADIOSITY

Réalité Virtuelle

Serveur

WEB

Apache

Objet CORBA parallèle

Chargement de

l’applet JAVA

du serveur WEB

(1)

Objets CORBA

...

Services

Cobra

Destruction de la VPM

(6)

Objet CORBA

Création de la VPM

(2)

VRML

proxy

RADIOSITY

Initialisation (3)

Exécution (4)

Visualisation (5)

Applet

Station de travail

Nœud de calcul

Nœud de service


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)


ad
  • Login