JRES 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

JRES 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

JRES 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

JRES 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

JRES 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

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

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

JRES 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 »

JRES Exemple de tableau comparatif

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

JRES 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

JRES 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

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

JRES 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

JRES 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

JRES 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, cœurs

JRES Gestionnaire initial de Batch : BQS ● Développement maison initié en 1991 ● Bien adapté à nos besoins et à notre capacité : gère cœurs, jobs en exécution simultanée, 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)

JRES 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

JRES 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

JRES 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

JRES 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

JRES 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

JRES Bilan sur SGE ● Migration en plusieurs phases ● 01/05/ Plateforme de pré-production avec 900 cœurs ● 30/06/ Plateforme de production avec cœurs ● 01/09/2011 – 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

JRES 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

JRES 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

JRES ▶ 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

JRES 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

JRES 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

JRES 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

JRES 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%

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

JRES 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

JRES 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

JRES Le Fairshare hiérarchique : Exemple

JRES 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

JRES 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