1 / 59

Technologies pour le Metacomputing

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

khalil
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Technologies pour le Metacomputing Thierry Priol IRISA/INRIA

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

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

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

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

  6. Energie

  7. Informatique

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

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

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

  11. 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, …)

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

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

  14. 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 ?

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

  16. Approche par échange de messages

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

  18. Architecture de Globus

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

  20. Allocation de ressources(GRAM)

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

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

  23. Accès aux données(GASS)

  24. Approches par RPC

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

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

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

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

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

  30. 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();

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

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

  33. 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, …)

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

  35. Approche orientée objet distribué

  36. 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, …)

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

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

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

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

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

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

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

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

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

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

  47. 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 { ... };

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

  49. #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

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

More Related