Nombre de job slot par machine Server_priv/node. Node1 np=2 Règle de 1 core = 1 job slot = 2 Go. Sur un bi-processeur bi-core on annonce alors np=4 Pas toujours respectée. –Pour faire tourner X jobs sur Y cores. –Pour avoir des job slots supplémentaires qui permettrons d’y faire tourner des jobs aux caractéristiques particulières (standing reservation) CPPM, GRIF 2 x plus de job slot que de core LAPP 1,25 x plus de job slot que de core La surcharge de job slot est elle une bonne chose ? Oui mais ca dépend du pourquoi faire

Nombre de job slot publiés dans le SI de EGEE Les scripts remontant les infos par queues se basent sur le job manager ldapsearch -x -H ldap://lapp-ce01.in2p3.fr:2135 -b mds-vo-name=local,o=grid | grep GlueCEStateRunningJobs GlueCEStateRunningJobs: 102 ldapsearch -x -H ldap://lapp-ce01.in2p3.fr:2135 -b mds-vo-name=local,o=grid | grep GlueCEStateWaitin GlueCEStateWaitingJobs: 34 N’IMPORTE OU lapp-ce01.in2p3.fr :> qstat atlas |grep R | wc -l 102 lapp-ce01.in2p3.fr :> qstat atlas |grep Q |wc -l 34 SUR LE CE Problème : Torque n’est pas au courant des standing reservation –Donc on publie tous les job slots –Ou on modifie les scripts afin de récupérer les informations auprès de MAUI et non plus torque : solution GRIF

Publication d’infos Ressources du CE publiées –Attention aux différentes infos publiées dans le système de la grille GlueCEUniqueID –GlueCEStateRunningJobs: –GlueCEStateWaitingJobs: –GlueCEStateTotalJobs: Basé les queues GlueVOViewLocalID –GlueCEStateRunningJobs: –GlueCEStateWaitingJobs: –GlueCEStateTotalJobs: Basé sur les VO (mapping entre group unix et VO) Queues de type 1Queues de type 2

Publication d’infos Doit-on publier les queues locales (si on en a) ? –Non, si pas connues, pas utilisées Doit on les protéger ? –Oui, pas accessibles depuis un job grille set queue local queue_type = Execution set queue local max_queuable = 800 set queue local acl_host_enable = True set queue local acl_hosts = lappsl07.in2p3.fr set queue local acl_hosts += lappsl06.in2p3.fr set queue lhcb queue_type = Execution set queue lhcb max_queuable = 400 set queue lhcb acl_host_enable = True set queue lhcb acl_hosts = lapp-ce01.in2p3.fr Les machines lappsl07 et lappsl06 peuvent faire qsub sur la queue local Le CE peut faire un qsub la queue lapp (qui est une queue de grille)

Standing reservation L’intérêt est de réserver une ressource à un type de jobs. –Parce qu’il y a un critère physique qui justifie cela ( type de processeur, interconnect,…) –Parce qu’on veux « garder » cette ressource pour un type de job particulier. Jobs prioritaires –Utilisateur, groupe, queue, …. particulier Faibles latences –Ne pas attendre en queue …

Standing reservation Exemple : –SRCFG[reserv_overload] HOSTLIST=lapp-wn00[1-9],lapp-wn01[0-9],lapp-wn02[0- 9],lapp-wn03[0-2] –SRCFG[reserv_overload] PERIOD=INFINITY –SRCFG[reserv_overload] ACCESS=DEDICATED –SRCFG[reserv_overload] TASKCOUNT=1 –SRCFG[reserv_overload] RESOURCES=PROCS:1 –SRCFG[reserv_overload] GROUPLIST=dteam,ops –SRCFG[reserv_overload] CLASSLIST=flash –SRCFG[reserv_overload] USERLIST=atlass,lhcbs –Cette réservation s’applique aux machines HOSTLIST –Elle n’est pas limitée dans le temps –Elle concerne 1 processeur(core) –En benéficient : les groupes unix dteam et ops, la queue flash, et les utilisateurs atlass et lhcbs Pour une machine ayant 4 cores si on a défini 5 jobs slots dans le job-manager on a ainsi: 4 job slots « normaux » + 1 réservé à la standing réservation : reserv_overload

Priorité MAUI Les priorités pouvant être appliquées à chacun des attributs des jobs. –USER : L’identité de l’utilisateur –Utilisateur au sens UNIX. Correspondant à des utilisateurs génériques dans le cadre des jobs grille. –GROUP : Le groupe de l’émetteur du job. –Groupe au sens unix. –CLASS : Notion liée aux queues du job-manager. –C’est le nom de la queue : atlas, lhcb, short, long,…. –ACCOUNT :Non officiellement utilisée par la grille. –QOS : Notion construite en fonction des besoins et permettant de caractériser un ensemble de jobs.

Priorité MAUI Au sein d’une VO –USER : Dépend du mapping du VOMS attribut Intéressant pour définir les priorités entre rôle d’une VO. Si on a X mapping entre VO et user doit on maintenir X règles de priorité ??? –GROUP : Si unique par VO, permet de définir des priorités entre groupe (donc VO) Si plusieurs groupe pour une VO plus difficile. Or VO –CLASS : Intéressant pour définir des règles de priorité entre des queues grilles et des queues locales. –ACCOUNT :Peut être utilisé pour définir son propre critère sur lequel sera appliqué des règles de priorité. Utilisation du submit_script

Accounting L’accounting des queues de grille est remonté par apel mais quid des queues locales. –Nécessite un outil local pour monitorer toutes les queues –Permet notamment de vérifier que les infos remontées dans appel correspondent a celles remontées par l’outils local

Nettoyage du CE –??

Comment partager les infos Un wiki –Pour y mettre les astuces et recettes de chaque site ? –Un wiki de plus –Nécessite une certaine discipline pour l’alimenter régulièrement AOB