3A-IIC - Parallélisme & Grid GRID : Middleware

3A-IIC - Parallélisme & Grid GRID : Middleware Stéphane Vialle Stephane.Vialle@supelec.fr http://www.metz.supelec.fr/~vialle Grid : Middleware 1. Globus 2. UniGrids 3. NES 4. XtremWeb 5. JavaSpaces/Jini 6. ProActive 7. Bilan et perspectives GLOBUS A la base, Globus était un projet complet incluant la conception d un middleware de Grille : Resource discovery & management Data management & Transfer Authentication & Security Gusto Research Testbeds Data-Grid National Fusion Collaboratory Software Tools Applications Globus-I, -II, -III, -IV: Low-level Meta- Computing toolkit Distributed supercomputing Desktop supercomputing Teleimmersion High-level Grid services 1

GLOBUS Evolution de l architecture de Globus : 1997-98 2000-01 2002-03 Virtual Organization & Grid Architecture Application Collective Resource Connectivity Fabric Open Grid Services Architecture Application GLOBUS Evolution de l architecture de Globus : 2002-03 2004-05 Open Grid Services Architecture Application OGSA and Web-services Applications OGSA Architected Services Messaging Directory Workflow Security Servers OGSI Open Grid Services Infrastructure Web Services File Database Systems Storage Meta-Computing Toolkit Hourglass model Application Globus services: Other Adaptive Wide Area Ser- Resource Environment vices Globus toolkit modules: Comms, Resource (al)location Authentication, Data access, Information service, Network GLOBUS-I Architecture et principes de Globus-I (1998): Applications adaptatives : Doivent maintenir leurs fonctionnalités quand les ressources évoluent : «adaptation dynamique» Services de haut niveau : Services dépendant des applications Services globaux ou «collectifs» Modules de bas niveau : Ensemble (minimal) de fonctionnalités standard Fonctionnalités dépendant des ressources Ressources distribuées : Hétérogènes Pannes/disparitions possibles «Sablier» Adaptive applications High level services Low level modules Heterogeneous resources 2

GLOBUS-I La machine virtuelle de metacomputing de Globus-I : Fonctionnalités : Resource location and allocation Communications Resource information Authentication Process creation Data access Adaptive applications High level services Metacomputing virtual machine Low level modules Heterogeneous resources Principe : Un ensemble minimal de services de bas-niveau standard supportant un large éventail de services de haut-niveau. GLOBUS-I Exemple de service (collectif) de haut niveau : Service d authentification global - Une grille est composée de machines d institutions différentes avec des politiques de sécurité différentes. - Mais un utilisateur ne doit s authentifier qu une fois! Besoin d un service collectif d authentification. Adaptive applications High level services Low level modules Heterogeneous resources GLOBUS-I Exemple d application adaptative : Choix dynamique du support de comm. Lien internet (TCP/IP) : bon marché & best-effort. Lien ATM : cher et QoS garantie measure comm performances if (Internet not loaded) use Internet else use (and pay for) ATM link Adaptive applications High level services Low level modules Heterogeneous Implantation possibles : resources Récupération d un service existant, Définition d un nouveau service de haut niveau, Implantation directement dans l application (adaptative). 3

De GLOBUS-I à GLOBUS-II Globus-I a une décomposition en sablier (haut niveau machine virtuelle bas niveau) est trop grossière Besoin de décomposer plus finement le sablier et sa machine virtuelle Globus-II propose une architecture plus complète et plus fine GLOBUS-II Architecture de Globus-II : décomposition plus fine du sablier Machine virtuelle de metacomputing en 4 couches : Fabric: Interface avec les ressources locales et leurs services Connectivity: Communications sécurisées et simples Resources: Gestion partagée de chaque ressource séparément Collective: Gestion coordonnée de l ensemble des ressources Séparation moins nette des services de bas et haut niveaux. High level services Low level modules Application Collective Resource Connectivity Fabric Globus-I hourglass model GLOBUS-II Architecture de Globus-II : décomposition plus fine du sablier 4 Services de grille de haut niveau (slide suivante). Application Collective Resource Connectivity Fabric 3 Trois modules devenus standard : GRIP : Grid Resource Information Protocol GRAM : Grid Resource Access and Management protocol GridFTP : Grid Management protocol for Data Access 2 Protocoles et mécanismes de communication. Protocoles et mécanismes d authentification. 1 Découverte et analyse des ressources. Contrôle des ressources. 4

GLOBUS-II Architecture de Globus-II : services de haut niveau classiques Application Collective Resource Connectivity Fabric 4 - Directory services LDAP - Software discovery services - Monitoring and diagnostics services - Scheduling services - Workload management systems - Grid-enabled programming systems - Community authorization servers - Community accounting and payment services - Collaborative services - Meta directory services - Data replication services - Replica management services - Credential repository services GLOBUS-II Autre architecture de Globus-II : L architecture en sablier ne matérialise pas les principaux problèmes. Nouvelle architecture en groupes de services thématiques transversaux. Basé sur des mécanismes d annuaires (LDAP) Basé sur une extension de FTP (GridFTP) Basé sur des annuaires (de rsrc), des schedulers collectifs, et des files d attente Basé sur des échanges de «certificats» De GLOBUS-II à GLOBUS-III Globus-II est opérationnel mais complexe à déployer Chaque «service/module» se programme différemment! Conception d une nouvelle architecture plus riche et plus homogène Globus-III et l architecture OGSA Incluent des concepts provenant des web-services (standard) 5

GLOBUS-III : Architecture OGSA Principes de base de Globus-III: Un nouveau découpage en couches intégrant des «web services» Software architecture definition «Tout est service.» Service orientation Grid-Service template Un début de sémantique de grille! Virtualization & Service composition Rapprochement des web-services Les services peuvent se composer facilement. (programmation en WSDL SOAP UDDI & XML) Globus-III : Architecture OGSA Un autre découpage en couches user user Services de haut niveau utilisant des services GT3 et autres Ex: gestion des données, gestion de la charge Services de bas niveau Ex: transfert des données, monitoring WSDL, SOAP, UDDI Applications Services locaux avec interface standard Distributed resources Globus-III : Architecture OGSA Grid-Service template : Tout service OGSA doit respecter un gabarit standard Un ensemble minimum d interfaces et de fonctionnalités standards 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! 6

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 Exemple: recherche de l efficacité optimale HTTP: Protocole pour des opérations distantes Interface unique IPC: Protocole pour des opérations locales Exemple: choix de la qualité de comm. Protocole sans détection d erreur Interface unique Protocole garantissant une communication exacte Globus-III Globus-IV Globus-III & OGSA : bonnes idées!! Mais ré-inventent une partie des concepts des web-services 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 de Globus-IV : Applications Grid-services de haut-niveau OGSA Architected Services Mécanismes spécifiques et web-services Grid-services de bas-niveau implantés en technologie web-services OGSI Open Grid Services Infrastructure Web Services Security Workflow Database File Systems Directory Messaging Servers Storage Network 7

Globus-IV Convergence des Grid et Web services : Grid Démarrent avec des applications et technologies éloignées Web GT1 GT2 Convergence! HTTP WSDL, WS-* OGSI WSDL 2, WSDM Web Services Resource Framework : WSRF Les deux «communautés» ont identifié des intérêts communs Futurs Grid et Web services : langages et sémantiques communs Globus-IV De (nouveaux) web-services implanteront tous les Grid-services de bas niveau : Applications OGSA Architected Services Applications OGSI Open Grid Services Infrastructure OGSA Architected Services Web Services Security Workflow Database File Systems Directory Messaging OGSI Open Grid Services Infrastructure Web Services Servers Storage Network Web Services Grid Security Workflow Database File Systems Directory Messaging Web WSRF Servers Storage Network Grid : Middleware 1. Globus 2. UniGrids 3. NES 4. XtremWeb 5. JavaSpaces/Jini 6. ProActive 7. Bilan et perspectives 8

UniGrids Prologue : L Europe a développé un middleware de Grille : Unicore, destiné à interconnecter des centres de calculs sécurisés. Grille de centre de calculs sécurisés 1 - Clients: Définition, soumission et contrôle de tâches. 2 - Gateways: points d entrée de centres de calcul sécurisés (point fort d Unicore). 3 - Serveurs: ordonnancent et exécutent de (grosses) tâches de calcul. UniGrids UniGrids est un projet Européen développant l interopérabilité entre des (middlewares de) grilles basés sur l architecture OGSA. Grille de grilles de centre de calculs. Concept de services atomiques appelé par les clients et assurés par les divers middleware de grille orienté OGSA. Couches logicielles d adaptation au niveau des serveurs de calculs et des clients. Forte participation aux instances mondiales de standardisation. UniGrids Objectif des «services atomiques»: Tout client peut appelé un service de n importe quelle grille Toute grille peut appeler un service d une autre grille GridBean GridBean GridBean Expert Client GridBean Application Client GridBean GridBean GridBean Portal Client Atomic Service Client API Atomic Services UNICORE/GS Globus Toolkit 4 China Grid Support Package Other OGSAcompliant Grid servers 9

UniGrids Les interfaces de «services atomiques» définissent un ensemble de fonctionnalités que chaque grille doit offrir. Les implantations peuvent différer selon la grille sous-jacente. Add a new target system to the Grid Manage target system Manage jobs on target system Manage files on storage Manage imports to storage Manage exports from storage Target System Factory (TSF) Target System Service (TSS) Job Management Service (JMS) Storage Management Service (SMS) File Import Service (FIS) File Export Service (FES) Implementation Implementation Implementation Implementation Implementation Implementation Atomic Services Commence à être opérationnel en 2005. À suivre. Grid : Middleware 1. Globus 2. UniGrids 3. NES 4. XtremWeb 5. JavaSpaces/Jini 6. ProActive 7. Bilan et perspectives NES : Network Enabled Servers Principe : Appel de codes de calculs distants sur des serveurs de calcul (extension du RPC ou du RMI) //GridRPC grpc_call Programme utilisateur Poste utilisateur Interface de programmation standard : GridRPC Allocateur de ressources et équilibreur de charge («brooker» ou «agent») Middleware spécifique + + (NetSolve, Ninf, Diet) Serveurs de puissance de calcul et de codes de calcul («solvers») Ressources distribuées 10

NES : Network Enabled Servers Cinq composants conceptuels : Analyse et ordonnancement sur demande du client («on demand») 1 Client Scheduler 2 Database Monitor Monitor Monitor 5 Server Server Server Server Server Server Server Server Server 4 3 Constituants de l agent ou du «brooker» Mesure de performances permanente et archivage NES : Network Enabled Servers Fonctionnement type : 1 Le client soumet une requête à l agent 2 L agent retourne une liste de serveurs adéquats 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 3- données Client 1-requête de calcul 2-liste de serveurs 4- résultat Agent info Serveur Serveur Serveur L utilisateur ne voit qu un simple RPC NES : Network Enabled Servers Pb 1 : l agent est un élément critique Traite toutes les requêtes client Doit connaître les caractéristiques de tous les composants de la grille Utilise des outils de mesure et de prédiction de performances Les performances de la grille dépendent de celles de l agent. Agent Etat Charge Caractéristiques Objectifs : Eviter l engorgement de l agent. Etre tolérant aux pannes. Solutions classiques : Utilisation de proxies. Déploiement d un ensembles d agents. 11

NES : Network Enabled Servers Pb 2 : la réutilisation des données dans les enchaînements d op. Objectifs : ne router qu une fois ces données du client vers le serveur, conserver les résultats intermédiaires sur le serveur de calcul. R = ((A B) A) client A,B R 1 serveur R 1 = AB client A,B serveur client A,R 1 R serveur R = R 1 A client R serveur Démarche de base Démarche efficace Solutions classiques : regroupement des opérations en «séquences» définition de données «persistantes» ou «volatiles» NES : Network Enabled Servers Trois principaux NES : NetSolve Ninf DIET Corba (RPC mechanism) Global Grid Forum GridRPC Des middleware différents Une API standard Systèmes opérationnels, mais le modèle de programmation (RPC) reste de (trop?) bas niveau! NES : Network Enabled Servers NetSolve University of Tennessee 12

NES : solution «NetSolve» Application: C, Fortran, Matlab Mathematica Netsolve Proxy Netsolve Agent Netsolve Servers & Solvers: C, Fortran + Netsolve Problem Description File Bus Corba Un bus Corba pour gérer les (objets) solveurs et les communications Des«proxies» 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 NES : solution «NetSolve» Fonctionnement de NetSolve: Un processus séparé appelé «proxy» réside sur chaque poste client Il s informe de l état de la grille auprès de l Agent quand celui-ci est disponible Il traite les requête de son client à la place de l Agent («cache») Diminue les engorgements. Tolère des pannes courtes. Chaque serveur contacte périodiquement l agent pour signaler qu il est en vie. Un PC NetSolve Client données & résultats NetSolve Serveur requête liste info NetSolve Proxy NetSolve Agent rq Les proxies augmentent la modularité : - Les évolutions de NetSolve n affectent que les proxies et pas les clients - Différents proxies permettent d accéder à différentes grilles. Utilise NWS pour monitorer la grille NES : solution «NetSolve» Utilise les services de Kerberos et des listes de contrôle d accès aux serveurs de calculs La sécurité n est pas gérée par l agent mais par les serveurs 13

NES : solution «NetSolve» Programmation de solvers : NetSolve client Codes C ou Fortran classiques NetSolve computing server Solvers Scientific Scientific Scientific computing computing computing library library library Problem Description File (PDF) Code PDF : langage de description spécifique ou GUI @OBJECT MATRIX D X Solution X (NxNRHS) @COMPLEXITY 3,3 @CALLINGSEQUENCE @ARG I0 @ARG I1,O0 @ARG ni0,mi0,mi1 NES : solution «NetSolve» Interface avec les environnements de calcul standard : Multiplication de matrices en C : double A[N][N], B[N][N], C[N][N]; int status; status = netsolve( matmult,a,b,c,n,n); Tri de vecteurs depuis Matlab: >> [request1] = netsolve_nb( send, qsort, v) Utiliser un NES (NetSolve) depuis un outil de calcul scientifique est aussi simple qu utiliser une bibliothèque de calcul. Depuis un interpréteur d expressions scientifiques les appels à NetSolve sont asynchrones par défaut. NES : Network Enabled Servers DIET Distributed Interactive Engineering Toolbox 14

NES : solution «DIET» Un bus Corba pour gérer les (objets) solveurs et les comms. Une hiérarchie d agents pour éviter les engorgements et tolérer des pannes. Des outils de mesure et de prévision des performances pour optimiser le choix des solveurs. Pb Bus Corba Architecture conçue pour la gestion de grandes grilles (pour le «passage à l échelle») NES : solution «DIET» Architecture conceptuelle en 5 composants Client Scheduler Database Monitor Monitor Monitor Server Server Server Server Server Server Server Server Server Master Agents: scheduling Local Agents & Server Daemons: monitoring Serveurs de calcul Architecture de DIET MA LA SeD MA Client LA MA LA MA SeD SeD SeD MA LDAP LDAP LDAP B u s C o r b a NES : solution «DIET» Exemple de déploiement de DIET : 1 Master-Agent: Pour gérer les rsrc d un campus. 1 Local-Agent: Pour gérer les rsrc d un labo du campus. 1 child-local-agent: Pour gérer les rsrc d une équipe du labo. MA MA MA MA MA LA LA LA SeD SeD SeD SeD Prévision de performances - Choix d un serveur de calcul : Mesure et BdD des performances des exécutions passées + BdD de benchmarks + Modèles analytiques des serveurs de calcul 15

Grid : Middleware 1. Globus 2. UniGrids 3. NES 4. XtremWeb 5. JavaSpaces/Jini 6. ProActive 7. Bilan et perspectives 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) Applications embarrassingly parallel (client) Serveur XtremWeb Internet Desktop PC (client ou worker) 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») Poste «client» «Worker» : Serveur (de calculs) dédié Serveurs de tâches XtremWeb Poste «user» Poste «worker» Poste «client» 16

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 Rq : hostregister Devient inutilisé Contacte le dernier serveur XtremWeb contacté ou bien le serveur root Attend une tâche Traite une tâche Tâche terminée 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 Serveur de tâches Enregistre le nouveau worker Retourne une tâche : - code binaire, - données - @ serveur à qui répondre Re-planifie la tâche si aucun signal d activité reçu XtremWeb : architecture des workers Mode User : PC User / Worker : Activity monitor Etat d utilisation de la ressource monitoré en permanence Mode Worker : PC ré-utilisé : passe en mode User Control PC inutilisé : passe en mode Worker Computing Alive Activity monitor Quand l utilisateur réutilise son PC : les threads de calcul sont tuées et le PC repasse en mode User immédiatement. XtremWeb : architecture du serveur Serveurs de tâches XtremWeb : Une application est : des binaires pour différentes archis. une description de ses paramètres et de son résultat Une tâche soumise est : une référence d application un ensemble de paramètres Pool of applications Accounting modules Les information stockées servent à : Prédire les performances des tâches Retourner un bilan aux utilisateurs Pool of tasks Web user interface Interface web utilisée pour : Soumettre des tâches Obtenir des statistique Administrer le système 17

Grid : Middleware 1. Globus 2. UniGrids 3. NES 4. XtremWeb 5. JavaSpaces/Jini 6. ProActive 7. Bilan et perspectives 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, CIRANO JavaSpaces/Jini Qu est-ce qu un JavaSpaces Un service Jini Jini permet d implanter la mémoire partagée virtuelle. Un système de mémoire distribué : Un dépôt d objets persistants Accessible au travers du réseau Transactionnel si souhaité (résistant aux pannes) Peut contenir du contenu exécutable (on stocke des objets) Les communications des programmes sont découplées du temps et de l espace : Des programmes exécutés sur des machines différentes à des moments différents peuvent communiquer 18

JavaSpaces/Jini Qu est-ce qu un JavaSpaces Un très petit nombre d opérations sont définies sur un Espace Lire Prendre Écrire ReadIfExists() // Lire sans bloquer TakeIfExists() // Prendre sans bloquer + un mécanisme de notification d évènements à travers le réseau Les objets déposés (les «Entry») sont des objets typés 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» Basé sur les «tuple-spaces» (voir David Gelernter s avec le système Linda ) JavaSpaces/Jini Modification des «Entry» Une Entry dans un espace ne peut pas être modifiée Elle doit être prise, puis modifiée, puis écrite JavaSpaces/Jini Ecriture des «Entry» Écrire une «Entry» dans un Espace 19

JavaSpaces/Jini Lecture des «Entry» Lit une Entrée d un Espace Une copie de l objet est retournée L original reste dans l Espace JavaSpaces/Jini Retrait d une «Entry» Prends une Entrée d un Espace Une Entrée conforme est retirée de l espace JavaSpaces/Jini Notification d évènement distant Un JavaSpaces implémente le patron Jini des événements distants Les clients peuvent s enregistrer sur les opérations d écriture avec la méthode «notify» L Auditeur («Listener») doit implémenter «RemoteEventListener» pour se faire appeler L Auditeur doit être accessible par réseau car l Espace doit pouvoir l appeler par la suite. 20

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) Possèdent un mode transactionnel (op réversibles jusqu au commit) : aide à la tolérance aux pannes. Questions pour l avenir : Efficacité sur de grands systèmes : les JavaSpaces passent-ils à l échelle? Grid : Middleware 1. Globus 2. UniGrids 3. NES 4. XtremWeb 5. JavaSpaces/Jini 6. ProActive 7. Bilan et perspectives ProActive Objets Java actifs et distribués Un environnement de programmation des systèmes distribués pour l exploitation de clusters, de Grilles ou de systèmes P2P. 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 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 21

ProActive Objets Java actifs et distribués Concept d Objets Actifs Simples à créer Permettent du parallélisme sur des clusters ou à travers Internet Appels d objets actifs : synchrone ou asynchrones Objets passifs non partagés et passés par valeur (par recopie) Concept de variables futures synchronisation «par nécessité» Communications et opérations sur des groupes d objets actifs Grid : Middleware 1. Globus 2. UniGrids 3. NES 4. XtremWeb 5. JavaSpaces/Jini 6. ProActive 7. Bilan et perspectives Bilan des middleware de Grille Des middleware génériques et ambitieux Ex: Globus, Unicore, Glite Des middleware associés à des environnements de développement Ex: NetSolve, DIET, Jini/JavaSpace, ProActive Un standard d architecture de Grille : OGSA Des middleware propriétaires moins ambitieux et plus opérationnels Ex : SUN Grid Engine, DataSynapse, Platform Des progrès rapides, des systèmes de plus en plus robustes Des déploiements industriels de plus en plus nombreux 22

Perspectives Des tentatives d interopérabilité de middleware de Grille Ex : UniGrids, GridSolve (interrompu) Volonté d étendre la Grille hors de la communauté de calcul intensif Grille d information Grille accessible par terminaux mobiles Grille accessible depuis des outils standards Ex : Mathematica, Excel Besoin d étendre (encore) les middleware de Grille Besoin d interopérabilité entre middleware de Grille Pour une adoption industrielle plus large : Besoin de plus de tolérance aux pannes Besoin de respects des contraintes de temps GRID : Middleware FIN 23