LHCb (Aresh) ----- LHCb week: 2-3 presentations sur le changement du computing model + cloud. http://lgm.cern.ch/?r=week&cs=&ce=&c=CLOUD.IN2P3.fr&h=&tab=m&vn=&hide-hf=false&stack=&show_dhosts= Fin mars Andrew McNab a mis en place vcycle (VM pilotes avec serveur au cern) au CC. Une dizaine de VM accordees pour ce tenant, chacune d'elle tourne 1 job pilote qui execute un job MC ; la VM est tuee a la fin et recreee. Ces jobs font partie de la production de LHCb, et ca marche bien. Ce sont 10 jobs sur ~2000 jobs LHCb Au CERN, il y a 500 VM (scalable). Au RAL: ~20 VM LHCb a l'intention de basculer une partie des pledges sur la partie cloud. Catherine: est-ce que les ressources de LHCb sont utilisees de maniere efficace dans la VM ? On ne sait pas, ca depend de la VO, de la machine virtuelle. La VO ne sait pas le type d'hyperviseur. Vcycle permet de comparer ressources utilisees avec pledges. Au CERN, meme tenant LHCb+CMS+ATLAS(?) et ca permet a vcycle de mieux gerer les ressources et les contraintes. Catherine: pourquoi ne pas faire tourner notre vcycle ici ? Mattieu: pourquoi pas -> avoir vue sur ce qui se passe au niveau de la tenancy et le fairshare comme on veut. Le machine/job features est une piste pour une meilleure utilisation des ressources et utile pour l'extinction des VM par le provider. Les prospectives multicore sont interessantes, vcycle permet le regroupement des VM de facon a optimiser utilisation multicore, regroupement par duree de vie etc. ATLAS (Emmanouil) ------ Au niveau d'ATLAS, pas de plan autre que l'usage opportuniste. Au CC: 500 jobs (32 VM avec 16), c'est un share pas negligeable (10% extra sur les pledges). Efficacite badjob/total 80% On observe en moyenne 9% difference wallclock time avec l'utilisation d'une VM vs hyperviseur (?) Et <5% avec optimisation noyau Les jobs partagent 8 coeurs sur VM Catherine: avec atlas, les VM ont une longue duree de vie, contrairement a LHCb. Rolf: comment ca se passe? Emmanouil: pilotes crees par condor, puis autre condor soumet VM lorsu'il voir les pilotes en queue PEM: ---- Questions d'aujourd'hui addresses aux journees prospectives & colloque calcul. Pas de sentiment fort que le cloud doive etre integre dans la grille, car pas de besoin ressenti, ni manpower important. Un travail important, celui de l'accounting et autorisation d'acces par les cloud admins sera a effectuer de toute facon. Une reunion sur les questions du cloud@CC ont eu lieu recemment, Mattieu doit envoyer les conclusions. Contexte international : * federation EGI (petite utilisation par wlcg avec vcycle) * indigo data cloud: panoplie de composants logiciel pour faire tourner de l'IAAS (le CC participe avec 1/JSAGA et 2/evaluation techologies et testbed). Projet de 30 mois, le CNRS n'a pas (encore) signe. * HNSci : - Cadre H2020 fait pour financer achat cloud public pour computing pour etre en mesure d'acheter des ressources en debordement ou remplacement de capacite compatible avec l'infra WLCG. - HNSci regroupe des acheteurs infn, in2p3, kit, etc., il y aura un appel d'offre, pour au final 1 prestataire pour les end users (cas in2p3: uniquement pour WLCG). - Ces ressources compteront un peu dans les pledges. Si ca marche bien, on pourrait passer en phase plus industrielle avec connexions Geant, accounting etc. - Les agences depensent chacune 100k euro - Il y aura du developpement opensource (par le prestataire?), genre accounting, qui pourra etre reutilise par la suite pour nos besoins. Risque: les ressources (ou une partie) pourraient ne plus etre dans les centres de calcul dedies comme le notre. Le CERN a franchi un pas important avec Wigner. Le stockage partira peut-etre aussi Les approches LSST et Euclid rappellent cette approche. Le cern dit que leur datacenter leur coute aussi cher que chez amazon. Quid du reseau ? stockage ? Atlas et Cms aux USA ont paye des connexions speciales avec amazon. Mattieu: d'apres ses calculs, on reste largement competitifs par rapport a amazon. Catherine n'imagine pas que les VO n'envisagent pas au moins d'avoir les copies primaires des RAW dans nos centres, et le workflow qui va avec. Contexte national: FG et IDGC (le CC n'est pas partie prenant dans ce contexte) Conclusions: role du LHC au cloud@CC ------------------------------------- Priorites : PEM: - assurer run2, priorite essentielle - ne pas etre en dehors des initiatives de developpement - un peu moins attentiste sur les technologies Mattieu: on a ce qui faut pour accueillir LHC, et 3 choses a ameliorer: - accounting: (christelle) - comment eviter de reserver les ressources , mettre en place du fair share et recuperation de ressources (pas du paradgime cloud). Question abordee par INFN, 1 personne la-dessus dans le cadre indigo. - que fait-on de la plateforme materielle actuelle (m610) ? c6100 pas forcement un bon candidat, a suivre. Catherine: quel est le but : se montrer ou faire calculer le LHC ? Benoit: a fait 3 ans qu'on nous dit qu'il faut faire du cloud. Est-ce que l'enjeu n'est pas en fait de la survie ? Rolf: est-on sur le point de devoir investir massivement sur le cloud ? (meme a performances moindres) Mattieu: il faut commencer a se poser a la question du nouveau materiel pour une vraie estimation de performances. Rolf: pour ne pas fausser la comparaison: utiliser le meme materiel cloud et batch. Catherine: quel est interet vs la grille ? Aresh: il y a l'interet du site aussi, plus de flexibilite au niveau operationnel, la VO prend plus de responsabilites, meilleurs facon d'exploiter les ressources. Rolf: en tant que site mutualise on a un probleme, car c'est complique de mutualiser du cloud (ndlr: en l'absence de ressources infinies ;) ) PEM: peut-etre que le cloud permet d'etre plus efficace, moins de tuning a effectuer, pour au final un meilleur service. Mattieu: pleins de gains de virtualisation en tant que site/infrastructure. Ca a du sens de tout virtualiser et tout gerer par une couche cloud. Emmanouil: helixnebula tres politique, le CERN veut etre pour etre big player dans cet environnement Quelle place du cc dans le monde cloud-HTC? Il faut mieux organiser et classifier les besoins des utilisateurs pour un meilleur design interne. Outlook ------ PEM: besoins emergeants en calcul parallele a ne pas negliger du reste. Le besoin est enorme en fait. Catherine: utilisateurs finaux aussi ont besoin de cloud, aussi LHC, analyses RUN2.