Utilisateurs de la Grille et Applications

1
Utilisateurs de la Grille et Applications

• Michel Jouvin
• LAL, Orsay
• jouvin_at_lal.in2p3.fr
• http//grif.fr
• M3PEC-Mésocentre, Bordeaux
• 24 Juin 2008

2
Agenda

• Le contexte de la grille et ses spécificités
• Organiser les utilisateurs
• Porter des applications
• Les spécificités des logiciels commerciaux
• Conclusions

3
Les Grilles Pourquoi ?

• Partage transparent de lutilisation de
  ressources massivement distribuées par des
  utilisateurs de différentes disciplines
• A computational grid is a hardware and software
  infrastructure that provides dependable,
  consistent, pervasive, and inexpensive access to
  high computational capabilities. (The Grid, I.
  Foster, C. Kesselman, 1998)
• pour permettre une mutualisation des coûts
• Donner accès à une très grande quantité de
  ressources par lagrégation de ressources
  existantes
• Optimiser lutilisation dinfrastructure coûteuse
• Permettre un accès occasionnel à de grosses
  ressources
• Permettre à des communautés à faible moyen
  daccéder à des ressources significatives

4
Composants de la Grille

• Les ressources
• Apportées et mises en oeuvre par certains groupes
  dutilisateurs
• Partagées (ou partageables) entre tous les
  groupes
• Middleware (intergiciel) services standards
  permettant 1 accès virtualisé aux ressources
• Sécurité (authentification / autorisation)
• Soumission de jobs
• Accès aux données, gestion de méta données
• Les applications
• Ne font pas partie de la grille mais lutilisent
• Mise en oeuvre par une communauté dutilisateur
• Peuvent nécessiter une adaptation pour utiliser
  les services du middleware

5
Avantages Techniques

• Mutualisation des développements et de la gestion
  des ressources entre communautés dutilisateurs
• Beaucoup de problèmes communs
• Services standardisés de haut niveau évitent la
  duplication des solutions
• Y compris des frameworks de gestion de workflow
• Des utilisateurs concentrés sur leurs métiers
  plutôt que sur les outils
• Particulièrement important pour les  petites 
  communautés
• Des ressources adaptées à la croissance des
  besoins
• Possibilité de démarrer sans mettre en uvre de
  ressources
• Possibilité daccès transparent à plus de
  ressources pour la production, éventuellement par
  la mise en uvre de ressources
• Les APIs de grille facilitent lidentification et
  laccès transparent à de nouvelles ressources
• Accès aux données
• Un grand volume disponible et universellement
  accessible
• Facilité de localisation et de partage contrôlé

6
Les Différents Acteurs

• Utilisateurs
• Scientifiques ou personnes souhaitant exécuter
  des jobs
• Organisations Virtuelles (VO)
• Personnes partageant un même but
• Communauté délimitée se dotant de moyen de
  certifier ladhésion dun membre
• Possibilités de sous groupe ou statuts différents
• Sites et administrateurs
• Ressources dans un domaine dadministration
  unique
• Responsable de la gestion cohérente et efficace
  des ressources
• Organisations réelles souvent les financeurs
• Instituts, agences de financement,
  gouvernement...
• Forums et institutions de standardisation
• OASIS, GGF, W3C, IETF, ...
• Pas daccord bi-latéraux (requis) entre ces
  entités

7
EGEE La Réalité

• Size of the infrastructure today
• 250 sites in 50 countries
• 70 000 CPU
• 20 PB disk tape MSS

• Sustained load
• 300 Kjobs/day
• Data Transfer gt 2 GB/s

http//gridportal.hep.ph.ic.ac.uk/rtm/
8
Ressources fournis

• Les sites décident qui peut utiliser leur
  ressources.
• Autorisation par VO
• Les sites du EGEE supportent des disciplines
  variées
• Les sites peuvent déployer plus dun CE ou SE.
• Nombre et pas taille des ressources!

9
Croissance de lUtilisation

• Nombre dheures délivrés en 1 an x2
• 30000 curs dernière génération utilisés en
  permanence
• 1/3 hors LCG

10
VOs Actives

• Nombre des VOs  actives  augmente ainsi que les
  ressources consommées par VO
• Nombre de VO multiplié par 2 en 2 ans
• Total VOs 104 enregistrées, 258 visibles
• La croissance concerne surtout les VOs consommant
  beaucoup de ressources

11
Type dApplications

• EGEE support simultané de différents types
  dapplication sur la même infrastructure
• Différence avec les desktop grids
• Pas de réservation
• Simulation batch, pas de gestion de donnée
• CPU intensif, jobs  longs 
• Pas (peu) de données en entrée, gros fichiers de
  sortie
• Beaucoup de job indépendants, peu dutilisateurs
• Sappuie sur des gestionnaires de jobs tels GANGA
  ou DIANE
• Analyse de données batch gestion de données
• Beaucoup de données distribuées en entrée, gros
  fichiers en sortie
• Requirements de la simulation outils
  sophistiqués de transferts de données (ex FTS)
• Peut nécessiter aussi une gestion de meta-données
  (AMGA) ou lintégration avec des bases de données

12
Type dApplications

• Pseudo-interactif temps de réponse court
• Application hors grille qui soumet un grand
  nombre de jobs courts et consolide les résultats
• Généralement GUI ou portail Web
• Peu de données en entrée et en sortie
• Besoin dun scheduling immédiat des jobs
• Problématique de standing reservation,
  préemption
• Workflow enchainement de tâches complexes
• Même problématique que lanalyse de données mais
  avec des tâches complexes et interdépendantes
• Utilisation de plusieurs infrastructures
  super-calculateurs, grille
• Sappuie sur des moteurs de workflow hors grille
• e.g. TAVERNA, MOTEUR, Ganga
• Applications parallèles MPI
• Actuellement 1 job confiné dans 1 site (idem
  DEISA)
• Utilisation croissante dapplications
  commerciales
• Problématique du licensing (ex WISDOM, EGEODE,
  MatLab)

13
Organiser les Utilisateurs

• Appartenance à 1 VO est un pré-requis pour
  accéder à la grille
• Pas de relation directe entre un site et un/des
  utilisateurs
• 1 VO contracte avec des sites qui lui ouvrent des
  ressources (CPU, disque)
• Pré-requis un certificat GRID-FR pour chaque
  utilisateur
• 1 VO peut être thématique, géographique,
  organisationnelle
• Un utilisateur peut appartenir à plusieurs VOs
• Interagit en tant que membre d1 VO à moment
  donné
• Grid proxy, équivalent du login dans une
  ressource  classique 
• De nombreuses VOs thématiques existent déjà et
  sont ouvertes à de nouveaux utilisateurs
• Pas nécessairement utile de créer une nouvelle VO
• Listes des VOs http//cic.gridops.org/index.php?
  sectionhomepagevolist

14
Accèder à la Grille UI

• Accès aux ressources grilles se fait à travers
  des outils (commandes) spécifiques
• Ensemble des outils appelés UI (User Interface)
• UI nest pas une application unique
• UI installable sur la plupart des distributions
  Linux
• RPM pour RHEL/CentOS/SL (v4 actuellement)
• Tar file utilisable pour les autres distributions
• Existe aussi un UI intégré à Eclipse (gEclipse)
  déployable dans tous les environnements
• Plusieurs stratégies de déploiement de lUI
• Déploiement sur une machine spécifique
  (passerelle)
• 1 UI  publique  opérée par GRIF
  grid11.lal.in2p3.fr
• Déploiement de lUI sur les machines interactives
  des utilisateurs serveurs ou desktops (Linux)

15
Formation des Utilisateurs

• Possibilité dorganiser des tutoriaux EGEE à la
  demande
• Exemple du tutorial LLR début juin 2008
  http//indico.lal.in2p3.fr/conferenceDisplay.py?co
  nfId463
• Forte composante travaux pratiques
• 1 moyen important de créer le noyau dune
  communauté dutilisateurs et de lancer une
  dynamique
• Tutorial en ligne (et en français !) maintenu par
  GRIF
• https//trac.lal.in2p3.fr/GridSupport/wiki/Tutoria
  l
• Maintenu à jour très régulièrement
• Base des TPs du tutorial EGEE

16
Porter des Applications

• Besoin dadaptation dune application très
  dépendante de sa complexité
• 1 code séquentiel nutilisant pas les services de
  données de la grille ne nécessite pas de
  modification
• Possibilité de préinstaller une application et
  son environnement sur la grille
• VO software area
• Plusieurs stratégies daccès aux services de
  données
• Traitement externe à lapplication (stage
  in/stage out avec un SE) via les commandes lcg
  utils ou équivalentes
• Intégration à lapplication via lAPI Posix-like
  GFAL
• C/C et Python
• MPI supporté sans modification
• Plusieurs variantes de MPI supportées
• Quelques particularités pour initialiser le job
• Prendre en compte labsence de HW spécifique
  (Infiniband)

17
Porter des Applications

• Gestion de production rapidement une nécessité
• Grille est un environnement avec des probabilités
  de  fautes  forte distribution,  faible 
  coordination
• Bookeeping  manuel  dun grand nombre de job
  nest pas viable
• Production souvent associé à une dépendance aux
  données
• Quelques outils  génériques , par exemple Ganga
• Framework extensible écrit en Python
• http//cern.ch/ganga
• Gestion de workflow support de job collections
  et DAG jobs peuvent offrir une aide
• Utilisation encore à ses débuts mais croissante
  astro-physique, biomed (Bioemergences)
• Permet le support de processus complexes et longs
  découpés en tâches élémentaires  gridifiables 

18
Les Logiciels Commerciaux

• Plusieurs communautés dépendantes de logiciels
  commerciaux
• MatLab, EGEODE (earth sciences), docking
  moléculaire, GAUSSIAN
• Plusieurs problématiques différentes
• Donner accès à 1 logiciel installé sur 1 site à
  un grand nombre dutilisateurs
• Exemple EGEODE (CGG)
• Rendre 1 logiciel utilisable sur plusieurs sites
  pour augmenter les ressources utilisables
• Exemple collaboration EGEE/MathWorks autour de
  MatLab
• Accès sans restriction mais limité dans le temps
  à 1 logiciel
• Exemple docking moléculaire
• Principale contrainte disposer dune
  distribution compatible avec lenvironnement des
  WNs (RHEL4)
• Très dépendant des possibilités de collaboration
  avec les éditeurs EGEE NA4 peut offrir un
  support

19
Conclusions

• Un grille multidisciplinaire fonctionne et est la
  principale voie pour offrir laccès à de très
  grandes ressources
• Lutilisation de la grille ne suppose pas la mise
  en uvre de ressources
• Séparation des responsabilités
• Peut permettre un démarrage progressif
• Succès de nombreux modèles applicatifs, même si
  la production de jobs séquentiels restent
  lutilisation dominante
• Expertise existe dans le cadre de EGEE et en
  France pour la formation des utilisateurs, laide
  au portage dapplications et la négociation avec
  des éditeurs de logiciels
• France a une forte responsabilité dans EGEE NA4
  (applications)
• Cal Loomis (LAL) chairman NA4, Fred Schaer
  (IRFU) VO coordinator