Télécharger la présentation
La présentation est en train de télécharger. S'il vous plaît, attendez
Publié parÉmilien Baril Modifié depuis plus de 8 années
1
JRES 20111 Gestion des ressources de calcul : 4 points de vue Recherche Développement Production Romaric David Julien Devemy Philippe Olivero Suzanne Poulat Yannis Georgiou Olivier Richard Bruno Bzeznik
2
JRES 2011 2 Plan de l'exposé ▶ Motivations ▶ Les gestionnaires de ressources : des objets de recherche ▶ Le point de vue des développeurs ► D'un logiciel maison à un standard : l'expérience du CC- IN2P3 ► Retour d'expérience dans le méso-centre de l'UdS ► Conclusion
3
JRES 2011 3 Motivations ▶ Les gestionnaires de ressources sont incontournables dans l'exploitation des centres de calcul : ▶ Pour l'utilisateur, ils constituent la principale interface avec le système ▶ Pour les administrateurs, ils permettent d'offrir un service de qualité via la mise en place de politiques d'ordonnancement ▶ Il existe un grand nombre de gestionnaires de ressources et/ou de batch ▶ La combinaison des fonctionnalités offertes est large
4
JRES 2011 4 Motivations (suite) ▶ Cette présentation vous rapporte une des premières études scientifiques sur les gestionnaires de ressources ▶ Ces mêmes logiciels seront ensuite abordés sous l'angle des développeurs ▶ Enfin deux retours d'expériences de centres de calcul de taille nationale et régionale illustreront le propos ▶ Ce travail est issu d'une coordination entre 3 groupes d'auteurs
5
JRES 2011 5 Plan de l'exposé ▶ Motivations ▶ Les gestionnaires de ressources : des objets de recherche ▶ Le point de vue des développeurs ► D'un logiciel maison à un standard : l'expérience du CC- IN2P3 ► Retour d'expérience dans le méso-centre de l'UdS ► Conclusion
6
JRES 2011 6 Grille d'analyse et comparaison ▶ Peu d'études comparatives ▶ Trop anciennes pour être exploitables ▶ Ici nous dressons la synthèse d'une étude : Yiannis Georgiou, Contributions à la Gestion de Ressources et de Tâches pour le Calcul de Haute Performance. Thèse de doctorat de l'université de Grenoble, 5 novembre 2010.
7
JRES 2011 7 Critères d'évaluation 3 catégories principales ● les fonctions de gestion de ressources ● Par exemple, le placement des jobs en fonction de la topologie du réseau, la gestion de l'énergie,... ● la gestion des tâches ● Par exemple, la gestion des jobs interactifs, des jobs modelables, du signaling,... ● les fonctions d'ordonnancement. ● Par exemple, le partage équitable, la gestion des jetons de licence,...
8
JRES 2011 8 Métrique Nous avons défini une échelle de notation à 4 niveaux de 0 à 3 ▶ 0 : fonctionnalité absente ▶ 1 : support partiel ▶ 2 : support correct ▶ 3 : ayant fait l'objet d'une attention particulière Dans le tableau qui suit, ces notes sont symbolisées respectivement par « NO », « Y », « YY » et « YYY »
9
JRES 2011 9 Exemple de tableau comparatif
10
JRES 2011 10 Synthèse des résultats ▶ 10 systèmes considérés : ▶ SLURM, CONDOR, TORQUE, OAR, SGE, MAUI ▶ MOAB, LSF, PBSPro LoadLeveler. ▶ Notes au dessus de la moyenne : ▶ LSF : 6.4/10 et SLURM : 6.2/10 OAR : 6/10, SGE : 5.9/10, PBSPro : 5.8/10 CONDOR : 5.7/10 ▶ Les autres systèmes sont plus en retrait.
11
JRES 2011 11 Plan de l'exposé ▶ Motivations ▶ Les gestionnaires de ressources : des objets de recherche ▶ Le point de vue des développeurs ► D'un logiciel maison à un standard : l'expérience du CC- IN2P3 ► Retour d'expérience dans le méso-centre de l'UdS ► Conclusion
12
JRES 2011 12 Pourquoi développer OAR ▶ Motivation historique : 2002, PBS devient payant ▶ Besoin d'un système polyvalent (Grid 5000) ▶ Facilement adaptable et extensible ▶ Contraintes topologiques (multi-coeur) ▶ Prise en compte de l'énergie ▶ Pour faire de la recherche dans le domaine de la gestion d'infrastructures de calcul ▶ Domaine nécessitant une très bonne maîtrise de ce type de système
13
JRES 2011 13 Quel effort de développement ? ▶ Beaucoup de programmation système : une affaire de spécialistes ! ▶ Cycle de développement d'une version majeure : au moins 1 an.homme ▶ Développements extérieurs sur les fonctions périphériques, Affichage, Portail de soumission ▶ Gestion de graphe de tâches (IBMP, Strasbourg) ▶ Effort systématique d'intégration dans une plate-forme (UshareSoft, Pipol, Senslab, Grid'5000)
14
JRES 2011 14 Développer son propre gestionnaire : difficultés ▶ Documentation ▶ Tests difficiles compte tenu du caractère distribué et multi- facettes ▶ Packaging et gestion des sources : une tâche qui peut être chronophage ▶ Trouver le bon équilibre entre fonctionnalités et stabilité/performances ▶ Coût humain de l'exploitation et de la maintenance évolutive
15
JRES 2011 15 Plan de l'exposé ▶ Motivations ▶ Les gestionnaires de ressources : des objets de recherche ▶ Le point de vue des développeurs ► D'un logiciel maison à un standard : l'expérience du CC- IN2P3 ► Retour d'expérience dans le méso-centre de l'UdS ► Conclusion
16
JRES 2011 16 CC-IN2P3 ● Centre de calcul national de l'IN2P3 et l'IRFU (CEA) ● Participe à plus de 100 projets internationaux ● T1 pour les grandes expériences LHC, AMS, LSST, etc ● Ouverture pluridisciplinaire (biologie, SHS) ● Quelques chiffres : ● 85 personnes travaillent au CC ● Stockage/archivage : ~10 PO disques, 40 PO de bandes ● Puissance de calcul : ~86 TFlops soit ~ 36 M-SI2K, 17 000 cœurs
17
JRES 2011 17 Gestionnaire initial de Batch : BQS ● Développement maison initié en 1991 ● Bien adapté à nos besoins et à notre capacité : gère 17 000 cœurs, 20 000 jobs en exécution simultanée, 125 000 jobs exécutés par jour ● Main d’œuvre : 3 FTE dont 2.2 FTE pour le développement et le déploiement ● Préconisation de changement de système lors de l'audit de la commission internationale consultative (COS)
18
JRES 2011 18 Changement de gestionnaire de batch Des buts clairs et ambitieux : ● Libérer des FTE ● Passer l’échelle de la croissance prévue ● Faire face à de nouveaux défis (virtualisation, cloud,...) sans développements lourds ● Rompre l'isolement dans ce domaine et participer à une communauté d'utilisateurs
19
JRES 2011 19 Phases de l'étude (1) ● Juillet 2009 : Enquête sur les produits utilisés dans notre communauté (HEP) ● 1er tri sur des critères basiques ● Étude des produits retenus : ● LSF, Torque/Maui, SGE, PBS Pro ● Classement en fonction d'une grille de critères
20
JRES 2011 20 Grille des critères ▶ Scalabilité, robustesse ▶ Système d’ordonnancement ▶ Jobs parallèles, interactifs ▶ Contraintes de mise en œuvre ▶ Système de comptabilité ▶ Gestion des serveurs de calcul ▶ Facilité d’administration et d’exploitation ▶ Support du logiciel ▶ Interfaçage avec les intergiciels fournis pour les grilles de calcul ▶ Support d’AFS
21
JRES 2011 21 Phases de l'étude (2) ● Étude plus approfondie des produits classés en tête : GE, LSF ● Maquettage dans une configuration proche de celle de production ● Tests de charge et estimation des efforts prévisibles pour passage en production ● Choix final de GE (Février 2010) ● Début en version libre, support Oracle fin juin 2011
22
JRES 2011 22 Mise en production ● Contournements techniques légers : ● Support des jetons AFS ● Contrôle de l'espace disque local aux serveurs de calcul ● Adaptation du middleware LCG ● Accounting/monitoring ● Documentation et accompagnement des utilisateurs ● Quelques manques et difficultés comme : ● l'accès aux informations sur les jobs ● La régulation fine pour la mise en exécution des jobs
23
JRES 2011 23 Bilan sur SGE ● Migration en plusieurs phases ● 01/05/2011 - Plateforme de pré-production avec 900 cœurs ● 30/06/2011 - Plateforme de production avec 3 000 cœurs ● 01/09/2011 – 9 000 cœurs soit 58% de la capacité ● 06/12/2011 – fin de la migration ● Bilan ● 1.5 FTE ● Test en cours de virtualisation de serveurs de calcul ● Premiers contacts pour animer une fédération d’utilisateurs
24
JRES 2011 24 Plan de l'exposé ▶ Motivations ▶ Les gestionnaires de ressources : des objets de recherche ▶ Le point de vue des développeurs ► D'un logiciel maison à un standard : l'expérience du CC- IN2P3 ► Retour d'expérience dans le méso-centre de l'UdS ► Conclusion
25
JRES 2011 25 Ressources de calcul du méso-centre : ► 1000 coeurs de calcul achetés par les laboratoires ► Environ 15 TFlops ▶ 100 Serveurs de calcul ▶ Linux Centos 5.3 ▶ Torque / Maui Pôle HPC
26
JRES 2011 26 ▶ 300 k€ HT ▶ 12 partenaires ▶ Une nouvelle salle machine : Hébergement sur le site de l'IUFM d'Alsace à Strasbourg ▶ Merci à l'équipe de proximité l'IUFM (M./ L. Collin, D. Messinger) Réalisations Mutualisation depuis 2008
27
JRES 2011 27 Mutualisation Définition et caractéristiques ● Mise en commun volontaire de serveurs de calcul afin d'en optimiser l'utilisation et de redistribuer à la communauté la puissance de calcul disponible. ● 12 partenaires depuis 2008 ● 100% de la puissance de calcul est d'origine mutualisée ● Nous arrivons à redistribuer 17% des cycles CPU à la communauté des non-mutualiseurs
28
JRES 2011 28 Mutualisation : Offre de services Accès au heures CPU ● 2 classes d'utilisateurs : ● Contributeurs : ayant payé des machines. Accès prioritaire à toutes les machines mutualisées. ● Non contributeurs : bénéficient du temps CPU libre ● Via le système de gestion de ressources ● Accès à autant d'heures CPU que si les machines étaient dédiées ● Accès le plus rapide possible aux processeurs : préemption d'un job de non contributeur par un job de contributeur
29
JRES 2011 29 Mutualisation : Besoins logiciels ● Classes d'utilisateurs : ACL sur les files d'attente et définition de grandeurs avancées ● Accès à autant d'heures CPU que si les machines étaient dédiées ⇒ fairshare sur cible d'heures CPU à atteindre ● Préemption d'un job de non contributeur par un job de contributeur ⇒ 2 besoins en découlent : ● Politique de préemption existante dans l'ordonnanceur ● Capacité à contrôler les processus d'une application, en particulier MPI = couplage fin
30
JRES 2011 30 Choix de la solution ● Le couple Torque/Maui a été choisi en raison de : ● L'intégration fine d'OpenMPI ● Des tests réussis de préemption (ordonnanceur et gestionnaire de ressources) ● L'existence d'un fairshare multi-critères par utilisateur ou groupe. ● Points positifs : ● Nous partageons efficacement les nœuds entre plusieurs jobs ● La solution s'est montrée capable d'obtenir un taux de charge instantané de 100%
31
JRES 2011 31 Limites de la solution ● Exploitation quotidienne ● Remontée des erreurs inexistante. Ce n'est parce qu'un nœud est en panne que le gestionnaire de batch arrête de vouloir l'utiliser (au contraire) ● Tableaux de jobs : parfaitement documenté... parfaitement non- utilisable ● Passage à l'échelle et gestion de l'hétérogénéité ● Nous avons pu contourner l'absence de fairshare hiérarchique ● Prise en compte des GPU difficile (ressources génériques non fonctionnelle)
32
JRES 2011 32 Le Fairshare hiérarchique : pourquoi ● Nous ajoutons des ressources de calcul génération par génération, selon les financements des chercheurs ● Génération 1 = Processeurs Opteron 2384, 8 cœurs par nœud : 30 GFlops ● Génération 2 = Processeurs Nehalem ou Westmere, 8 ou 12 cœurs par nœuds : 50 GFlops ● Cette hétérogénéité est cachée à l'ordonnanceur ● Les groupes de recherche contribuent à un certain pourcentage d'une génération donnée, que nous devons leur permettre d'atteindre
33
JRES 2011 33 Le Fairshare hiérarchique : comment ● Étape 1 : Création de files d'attente (+ACL) spécialisées, une par génération de processeurs (GR) Garantit à un utilisateur de calculer sur un processeur de sa génération ● Étape 2 : Calcul des cibles de Fairshare (au tableur...) : ● Cible = Nombre de cœurs achetés / Nombre total de cœurs ● Étape 3 : Attribution d'une cible de Fairshare fonction de utilisateur, groupe, file (GB) GR : Gestionnaire de ressources, GB : Batch
34
JRES 2011 34 Le Fairshare hiérarchique : Exemple
35
JRES 2011 35 Plan de l'exposé ▶ Motivations ▶ Les gestionnaires de ressources : des objets de recherche ▶ Le point de vue des développeurs ► D'un logiciel maison à un standard : l'expérience du CC- IN2P3 ► Retour d'expérience dans le méso-centre de l'UdS ► Conclusion
36
JRES 2011 36 Conclusion ▶ Les gestionnaires de ressources sont des logiciels complexes ▶ Des critères de choix existent à présent ▶ Les retours d'expériences montrent que le paysage est mouvant : développer, adapter, intégrer ? ▶ N'hésitez pas à remettre des choix précédents sur le tapis
Présentations similaires
© 2024 SlidePlayer.fr Inc.
All rights reserved.