https://lcg.in2p3.fr/api.php?action=feedcontributions&feedformat=atom&user=Barbet
lcgwiki - Contributions [en]
2026-06-12T21:32:21Z
Contributions
MediaWiki 1.43.1
https://lcg.in2p3.fr/index.php?title=Alice&diff=8530
Alice
2023-02-02T10:19:55Z
<p>Barbet: /* Bienvenue sur la page Alice LCG-France Welcome to the LCG-France Alice page */</p>
<hr />
<div>== ''Bienvenue sur la page Alice LCG-France <br><br> Welcome to the LCG-France Alice page'' ==<br />
<br />
* Alice computing Representative : Jean-Michel Barbet<br />
* Alice Web site : http://aliceinfo.cern.ch/<br />
* Alice Monitoring : http://alimonitor.cern.ch<br />
* Tier-1 site: CCIN2P3<br />
* Tier-2 sites : Subatech Nantes, IPHC Strasbourg, IJCLab Orsay and IRFU (GRIF), LPC Clermont<br />
<br />
<br />
==== [[Alice:Communication| Alice Communication VO/Sites]] ====<br />
<br />
* VO Alice ID Card : https://cic.gridops.org/index.php?section=vo<br />
* Alice LCG Task Force<br />
* Liste de diffusion : alice-lcg-task-force@cern.ch<br />
* AliEn WiKi : http://alien2.cern.ch<br />
<br />
==== [[Alice:Communication| Alice T1/T2 Workshops]] ====<br />
<br />
* CERN 26-27 Mai 2009 http://indico.cern.ch/event/58444/<br />
* Karlsruhe 24-26 Janvier 2012 https://indico.cern.ch/event/157585/<br />
* Lyon 4-6 Juin 2013 https://indico.in2p3.fr/event/8114/<br />
* Tsukuba 3-8 Mars 2014 https://indico.cern.ch/event/274974/overview<br />
* Torino 23-25 Février 2015 https://indico.cern.ch/event/354209/overview<br />
* Bergen 18-20 Avril 2016 https://indico.cern.ch/event/485835/<br />
* Strasbourg 3-5 Mai 2017 https://indico.cern.ch/event/595536/<br />
* Derby 17-19 Avril 2018 https://indico.cern.ch/event/690294/<br />
* Bucarest 14-16 Mai 2019 https://indico.cern.ch/event/778465/<br />
* Budapest 26-28 Septembre 2022 https://indico.cern.ch/event/877541/<br />
<br />
==== [[Alice:Vobox| Alice Vobox]] ====<br />
Il faut commencer par installer une machine LCG en VOBOX (meta-package YAIM)<br />
et vérifier que sur cette machine on dispose de toutes les fonctionnalités d'une UI<br />
LCG (soumission de jobs).<br />
<br />
Voir cette doc :<br />
http://alien2.cern.ch/index.php?option=com_content&view=article&id=21&Itemid=67<br />
<br />
Il existe un script permettant de tester les fonctions LCG nécessaires<br />
avant d'installer AliEn.<br />
<br />
<strike>Il faut installer un LFC local (sur la VOBOX ou ailleurs).</strike><br />
(màj début 2007 : Ce n'est plus nécessaire d'installer un LFC sur la VOBOX).<br />
<br />
Il faut ensuite installer AliEn. Cela se fait en récupérant un<br />
"installer" : un script shell qui va se charger de récupérer<br />
les packages et les installer<br />
<pre><br />
wget alien.cern.ch/alien-installer<br />
</pre><br />
<br />
Il faut aussi s'enregister auprès de la VO Alice (fournir le DN de son <br />
certificat) et demander le rôle alicesgm :<br />
http://alien.cern.ch/twiki/bin/view/Alice/UserRegistration<br />
<br />
AliEn se compose de plusieurs demons ou "services" :<br />
<br />
- Monitor<br />
- CE<br />
- CMreport<br />
- MonaLisa<br />
<br />
Home WiKi ALiEn :<br />
http://alien2.cern.ch<br />
<br />
Il y a pas mal de trous à faire dans le firewall:<br />
<br />
[https://twiki.cern.ch/twiki/pub/LCG/VoBoxesInfo/VO-Box-security-policy_v05.doc Security Policy]<br />
<br />
<br />
--[[Utilisateur:Barbet|Barbet]] 14 Octobre 2015 à 10:11 (CEST)*</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Tier_2:Subatech&diff=8529
Tier 2:Subatech
2023-02-02T10:15:21Z
<p>Barbet: </p>
<hr />
<div>Laboratoire SUBATECH - UMR<br />
CNRS/IN2P3-Ecole des Mines de Nantes-Université de Nantes<br />
http://www-subatech.in2p3.fr/<br />
<br><br />
[[Tier_2:Subatech |Version Française ]] | [[Tier_2:Subatech_en|English Version ]] <br />
<br />
Le laboratoire SUBATECH s'est engagé à participer en tant que centre de traitement "Tier-2" au stockage et à l'analyse des données issues de l'expérience ALICE au LHC.<br />
<br />
<span style="color:#FF0000;">Note: Le Tier-2 Subatech va être progressivement arrêté courant 2023</span><br />
<br />
===== Ressources dédiées à LCG =====<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Année !! 2005 [1]!! 2006 [1]!! 2007 [1]!! 2008 [2] !! 2009 [2] !! 2010 [3] !! 2011 !! 2012 !! 2013 !! 2014 !! 2015 !! 2016 !! 2017 !! 2018 !! 2019 [4] !! 2020 !! 2021 !! 2022 !! 2023 [6]<br />
|-<br />
! CPU (KSI2K)<br />
| 14 || 56 ||112 || 312 || 373 || - || - || - || - || - || - || - || - || - || - || - || - || - || - <br />
|-<br />
! CPU (SPEC-HEP06)<br />
| - || - || - || - || - || 2400 || 3000 || 3000 || 3000 || 3000 || 3000 || 4500 || 4500 || 4500 || 8500 [4] || 13500 [5] || 13500 || 13500 || 0<br />
|-<br />
! Stockage (To) <br />
| 4,25 || 15,3 || 16 || 43 || 97 || 200 || 270 || 310 || 310 || 310 || 310 || 800 || 1619 || 1619 || 1500 || 1500 || 2500|| 2500 || 0<br />
|-<br />
|}<br />
[1] : sur la base de 1CPU = 1,644 KSI2K <br />
<br />
[2] : en KSI2K CERN conformément à [[http://www.cern.ch/LCG/documents/Processor%20performance%20metrics_26may07.pdf CPU Capacity Metrics for WLCG]]<br />
<br />
[3] : SPEC-HEP06 : Nouvelle métrique <br />
<br />
[4] : Ajout de 400 Coeurs CPU mutualisés dans le centre HPC CCIPL Université de Nantes<br />
<br />
[5] : Ajout de 640 Coeurs CPU mutualisés dans le centre HPC CCIPL Université de Nantes<br />
<br />
[6] : arrêt progressif di site à partir de mai 2023<br />
<br />
Référence : http://gstat-wlcg.cern.ch/apps/pledges/resources/<br />
<br />
===== Personnes et moyens humains =====<br />
Responsable Scientifique : Laurent Aphecetche<br />
<br />
Responsable Technique : Jean-Michel Barbet<br />
<br />
Exploitation : Khalil Chawoshi (Chef du Service Informatique), Jean-Michel Barbet, Pierrick Le Corre, Erwan Macé et Jérome Pinot.<br />
Les moyens humains dédiés à LCG représentent actuellement 1,2 ETP.<br />
<br />
===== Financement et partenaires =====<br />
Les achats ont étés réalisés avec les crédits du laboratoire avec l'aide de la Région des Pays-de-Loire. Depuis Juin 2017, la majorité des ressources CPU sont mutualisées dans un mésocentre HPC de l'Université de Nantes : le CCIPL.<br />
<br />
===== Technologies et savoir-faire =====<br />
Cluster local CentOS7, HT-Condor, Puppet/Foreman (worker nodes, disk servers)<br />
<br />
Stockage : RAID5/6, EOS<br />
<br />
Divers : Surveillance Nagios, Virtualisation: VMware, Elogger.<br />
<br />
===== Liens =====<br />
Site IN2P3-SUBATECH dans la GOCDB [https://goc.egi.eu/portal/index.php?Page_Type=View_Object&object_id=151&grid_id=0] <br />
<br />
Expérience ALICE au LHC [http://aliceinfo.cern.ch/Public]<br />
<br />
Carte AliEn [http://pcalimonitor.cern.ch:8889/show?page=index.html]<br />
<br />
Groupe Plasma à SUBATECH [http://www-subatech.in2p3.fr/%7Eplasma/index_plasma.html]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Tier_2:Subatech_en&diff=8520
Tier 2:Subatech en
2021-09-14T06:46:47Z
<p>Barbet: </p>
<hr />
<div>Laboratoire SUBATECH - UMR<br />
CNRS/IN2P3-IMT-Atlantique-Université de Nantes<br />
http://www-subatech.in2p3.fr/<br />
<br><br />
[[Tier_2:Subatech |Version Française ]] | [[Tier_2:Subatech_en|English Version ]] <br />
<br />
The SUBATECH laboratory commited itself to take part as a "Tier-2" center to the processing and storage of data from the ALICE experiment at the LHC.<br />
===== Resources dedicated to LCG =====<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Année !! 2005 [1]!! 2006 [1]!! 2007 [1]!! 2008 [2] !! 2009 [2] !! 2010 [3] !! 2011 !! 2012 !! 2013 !! 2014 !! 2015 !! 2016 !! 2017 !! 2018 !! 2019 [4] !! 2020 !! 2021 !! 2022 !! 2023<br />
|-<br />
! CPU (KSI2K)<br />
| 14 || 56 ||112 || 312 || 373 || - || - || - || - || - || - || - || - || - || - || - || - || - || - <br />
|-<br />
! CPU (SPEC-HEP06)<br />
| - || - || - || - || - || 2400 || 3000 || 3000 || 3000 || 3000 || 3000 || 4500 || 4500 || 4500 || 8500 [4] || 13500 [5] || 13500 || 13500 || to be defined<br />
|-<br />
! Stockage (To) <br />
| 4,25 || 15,3 || 16 || 43 || 97 || 200 || 270 || 310 || 310 || 310 || 310 || 800 || 1619 || 1619 || 1500 || 1500 || 2500|| 2500 || 1152<br />
|-<br />
|}<br />
<br />
[1] : on the basis of 1CPU = 1,644 KSI2K <br />
<br />
[2] : in KSI2K CERN according to [[http://www.cern.ch/LCG/documents/Processor%20performance%20metrics_26may07.pdf CPU Capacity Metrics for WLCG]]<br />
<br />
[3] : SPEC-HEP06 : new metric<br />
<br />
[4] : Addition of 400 CPU cores in the CCIPL HPC center (University of Nantes)<br />
<br />
[5] : Addition of 640 CPU cores in the CCIPL HPC center (University of Nantes)<br />
<br />
===== People and Human Resources =====<br />
Scientific Manager : Laurent Aphecetche<br />
<br />
Technical Manager : Jean-Michel Barbet<br />
<br />
Exploitation : Khalil Chawoshi (Chef du Service Informatique), Jean-Michel Barbet, Pierrick Le Corre, Jerome Pinot, Erwan Mace.<br />
<br />
Human resources dedicated to LCG currently account for 1,2 FTE.<br />
<br />
===== Funding et partners =====<br />
Hardware have been purchased with funds from IMT-Atlantique and Région des Pays-de-Loire.<br />
<br />
===== Technologies and know-how =====<br />
Local cluster CentOS7, HT-Condor, Puppet/Foreman (worker nodes, disk servers)<br />
<br />
Storage : RAID5/6, EOS<br />
<br />
Misc. : Nagios, Virtualisation: VMware, Elogger.<br />
<br />
===== Links =====<br />
Site IN2P3-SUBATECH in the GOCDB [https://goc.egi.eu/portal/index.php?Page_Type=View_Object&object_id=151&grid_id=0]<br />
<br />
ALICE Experiment at the LHC [http://aliceinfo.cern.ch/Public]<br />
<br />
AliEn Map [http://pcalimonitor.cern.ch:8889/show?page=index.html]<br />
<br />
Plasma Group at SUBATECH [http://www-subatech.in2p3.fr/%7Eplasma/index_plasma.html]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Tier_2:Subatech_en&diff=8519
Tier 2:Subatech en
2021-09-14T06:46:26Z
<p>Barbet: </p>
<hr />
<div>Laboratoire SUBATECH - UMR<br />
CNRS/IN2P3-IMT-Atlantique-Université de Nantes<br />
http://www-subatech.in2p3.fr/<br />
<br><br />
[[Tier_2:Subatech |Version Française ]] | [[Tier_2:Subatech_en|English Version ]] <br />
<br />
The SUBATECH laboratory commited itself to take part as a "Tier-2" center to the processing and storage of data from the ALICE experiment at the LHC.<br />
===== Resources dedicated to LCG =====<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Année !! 2005 [1]!! 2006 [1]!! 2007 [1]!! 2008 [2] !! 2009 [2] !! 2010 [3] !! 2011 !! 2012 !! 2013 !! 2014 !! 2015 !! 2016 !! 2017 !! 2018 !! 2019 [4] !! 2020 !! 2021 !! 2022 !! 2023<br />
|-<br />
! CPU (KSI2K)<br />
| 14 || 56 ||112 || 312 || 373 || - || - || - || - || - || - || - || - || - || - || - || - || - || - <br />
|-<br />
! CPU (SPEC-HEP06)<br />
| - || - || - || - || - || 2400 || 3000 || 3000 || 3000 || 3000 || 3000 || 4500 || 4500 || 4500 || 8500 [4] || 13500 [5] || 13500 || 13500 || à définir<br />
|-<br />
! Stockage (To) <br />
| 4,25 || 15,3 || 16 || 43 || 97 || 200 || 270 || 310 || 310 || 310 || 310 || 800 || 1619 || 1619 || 1500 || 1500 || 2500|| 2500 || 1152<br />
|-<br />
|}<br />
<br />
[1] : on the basis of 1CPU = 1,644 KSI2K <br />
<br />
[2] : in KSI2K CERN according to [[http://www.cern.ch/LCG/documents/Processor%20performance%20metrics_26may07.pdf CPU Capacity Metrics for WLCG]]<br />
<br />
[3] : SPEC-HEP06 : new metric<br />
<br />
[4] : Addition of 400 CPU cores in the CCIPL HPC center (University of Nantes)<br />
<br />
[5] : Addition of 640 CPU cores in the CCIPL HPC center (University of Nantes)<br />
<br />
===== People and Human Resources =====<br />
Scientific Manager : Laurent Aphecetche<br />
<br />
Technical Manager : Jean-Michel Barbet<br />
<br />
Exploitation : Khalil Chawoshi (Chef du Service Informatique), Jean-Michel Barbet, Pierrick Le Corre, Jerome Pinot, Erwan Mace.<br />
<br />
Human resources dedicated to LCG currently account for 1,2 FTE.<br />
<br />
===== Funding et partners =====<br />
Hardware have been purchased with funds from IMT-Atlantique and Région des Pays-de-Loire.<br />
<br />
===== Technologies and know-how =====<br />
Local cluster CentOS7, HT-Condor, Puppet/Foreman (worker nodes, disk servers)<br />
<br />
Storage : RAID5/6, EOS<br />
<br />
Misc. : Nagios, Virtualisation: VMware, Elogger.<br />
<br />
===== Links =====<br />
Site IN2P3-SUBATECH in the GOCDB [https://goc.egi.eu/portal/index.php?Page_Type=View_Object&object_id=151&grid_id=0]<br />
<br />
ALICE Experiment at the LHC [http://aliceinfo.cern.ch/Public]<br />
<br />
AliEn Map [http://pcalimonitor.cern.ch:8889/show?page=index.html]<br />
<br />
Plasma Group at SUBATECH [http://www-subatech.in2p3.fr/%7Eplasma/index_plasma.html]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Tier_2:Subatech&diff=8518
Tier 2:Subatech
2021-09-14T06:36:47Z
<p>Barbet: </p>
<hr />
<div>Laboratoire SUBATECH - UMR<br />
CNRS/IN2P3-Ecole des Mines de Nantes-Université de Nantes<br />
http://www-subatech.in2p3.fr/<br />
<br><br />
[[Tier_2:Subatech |Version Française ]] | [[Tier_2:Subatech_en|English Version ]] <br />
<br />
Le laboratoire SUBATECH s'est engagé à participer en tant que centre de traitement "Tier-2" au stockage et à l'analyse des données issues de l'expérience ALICE au LHC.<br />
===== Ressources dédiées à LCG =====<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Année !! 2005 [1]!! 2006 [1]!! 2007 [1]!! 2008 [2] !! 2009 [2] !! 2010 [3] !! 2011 !! 2012 !! 2013 !! 2014 !! 2015 !! 2016 !! 2017 !! 2018 !! 2019 [4] !! 2020 !! 2021 !! 2022 !! 2023<br />
|-<br />
! CPU (KSI2K)<br />
| 14 || 56 ||112 || 312 || 373 || - || - || - || - || - || - || - || - || - || - || - || - || - || - <br />
|-<br />
! CPU (SPEC-HEP06)<br />
| - || - || - || - || - || 2400 || 3000 || 3000 || 3000 || 3000 || 3000 || 4500 || 4500 || 4500 || 8500 [4] || 13500 [5] || 13500 || 13500 || à définir<br />
|-<br />
! Stockage (To) <br />
| 4,25 || 15,3 || 16 || 43 || 97 || 200 || 270 || 310 || 310 || 310 || 310 || 800 || 1619 || 1619 || 1500 || 1500 || 2500|| 2500 || 1152<br />
|-<br />
|}<br />
[1] : sur la base de 1CPU = 1,644 KSI2K <br />
<br />
[2] : en KSI2K CERN conformément à [[http://www.cern.ch/LCG/documents/Processor%20performance%20metrics_26may07.pdf CPU Capacity Metrics for WLCG]]<br />
<br />
[3] : SPEC-HEP06 : Nouvelle métrique <br />
<br />
[4] : Ajout de 400 Coeurs CPU mutualisés dans le centre HPC CCIPL Université de Nantes<br />
<br />
[5] : Ajout de 640 Coeurs CPU mutualisés dans le centre HPC CCIPL Université de Nantes<br />
<br />
Référence : http://gstat-wlcg.cern.ch/apps/pledges/resources/<br />
<br />
===== Personnes et moyens humains =====<br />
Responsable Scientifique : Laurent Aphecetche<br />
<br />
Responsable Technique : Jean-Michel Barbet<br />
<br />
Exploitation : Khalil Chawoshi (Chef du Service Informatique), Jean-Michel Barbet, Pierrick Le Corre, Erwan Macé et Jérome Pinot.<br />
Les moyens humains dédiés à LCG représentent actuellement 1,2 ETP.<br />
<br />
===== Financement et partenaires =====<br />
Les achats ont étés réalisés avec les crédits du laboratoire avec l'aide de la Région des Pays-de-Loire. Depuis Juin 2017, la majorité des ressources CPU sont mutualisées dans un mésocentre HPC de l'Université de Nantes : le CCIPL.<br />
<br />
===== Technologies et savoir-faire =====<br />
Cluster local CentOS7, HT-Condor, Puppet/Foreman (worker nodes, disk servers)<br />
<br />
Stockage : RAID5/6, EOS<br />
<br />
Divers : Surveillance Nagios, Virtualisation: VMware, Elogger.<br />
<br />
===== Liens =====<br />
Site IN2P3-SUBATECH dans la GOCDB [https://goc.egi.eu/portal/index.php?Page_Type=View_Object&object_id=151&grid_id=0] <br />
<br />
Expérience ALICE au LHC [http://aliceinfo.cern.ch/Public]<br />
<br />
Carte AliEn [http://pcalimonitor.cern.ch:8889/show?page=index.html]<br />
<br />
Groupe Plasma à SUBATECH [http://www-subatech.in2p3.fr/%7Eplasma/index_plasma.html]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Tier_2:Subatech&diff=8517
Tier 2:Subatech
2021-09-14T06:10:04Z
<p>Barbet: /* Ressources dédiées à LCG */</p>
<hr />
<div>Laboratoire SUBATECH - UMR<br />
CNRS/IN2P3-Ecole des Mines de Nantes-Université de Nantes<br />
http://www-subatech.in2p3.fr/<br />
<br><br />
[[Tier_2:Subatech |Version Française ]] | [[Tier_2:Subatech_en|English Version ]] <br />
<br />
Le laboratoire SUBATECH s'est engagé à participer en tant que centre de traitement "Tier-2" au stockage et à l'analyse des données issues de l'expérience ALICE au LHC.<br />
===== Ressources dédiées à LCG =====<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Année !! 2005 [1]!! 2006 [1]!! 2007 [1]!! 2008 [2] !! 2009 [2] !! 2010 [3] !! 2011 !! 2012 !! 2013 !! 2014 !! 2015 !! 2016 !! 2017 !! 2018 !! 2019 [4] !! 2020 !! 2021 !! 2022 !! 2023<br />
|-<br />
! CPU (KSI2K)<br />
| 14 || 56 ||112 || 312 || 373 || - || - || - || - || - || - || - || - || - || - || - || - || - || - <br />
|-<br />
! CPU (SPEC-HEP06)<br />
| - || - || - || - || - || 2400 || 3000 || 3000 || 3000 || 3000 || 3000 || 4500 || 4500 || 4500 || 8500 [4] || 13500 [5] || 13500 || 13500 || à définir<br />
|-<br />
! Stockage (To) <br />
| 4,25 || 15,3 || 16 || 43 || 97 || 200 || 270 || 310 || 310 || 310 || 310 || 800 || 1619 || 1619 || 1500 || 1500 || 2500|| 2500 || 1152<br />
|-<br />
|}<br />
[1] : sur la base de 1CPU = 1,644 KSI2K <br />
<br />
[2] : en KSI2K CERN conformément à [[http://www.cern.ch/LCG/documents/Processor%20performance%20metrics_26may07.pdf CPU Capacity Metrics for WLCG]]<br />
<br />
[3] : SPEC-HEP06 : Nouvelle métrique <br />
<br />
[4] : Ajout de 400 Coeurs CPU mutualisés dans le centre HPC CCIPL Université de Nantes<br />
<br />
[5] : Ajout de 640 Coeurs CPU mutualisés dans le centre HPC CCIPL Université de Nantes<br />
<br />
Référence : http://gstat-wlcg.cern.ch/apps/pledges/resources/<br />
<br />
===== Personnes et moyens humains =====<br />
Responsable Scientifique : Laurent Aphecetche<br />
<br />
Responsable Technique : Jean-Michel Barbet<br />
<br />
Exploitation : Khalil Chawoshi (Chef du Service Informatique), Jean-Michel Barbet, Pierrick Le Corre, Erwan Macé et Jérome Pinot.<br />
Les moyens humains dédiés à LCG représentent actuellement 1,2 ETP.<br />
<br />
===== Financement et partenaires =====<br />
Les achats ont étés réalisés avec les crédits du laboratoire avec l'aide de la Région des Pays-de-Loire. Depuis Juin 2017, la moitié des ressources CPU proviennent d'un mésocentre HPC de l'Université de Nantes : le CCIPL.<br />
<br />
===== Technologies et savoir-faire =====<br />
Cluster local Scientific-Linux 6, OpenPBS. Quattor (worker nodes, disk servers), Puppet, YAIM (service nodes)<br />
<br />
Stockage : SAN, RAID5/6, xrootd, EOS<br />
<br />
Divers : Surveillance Nagios, Support: Request-Tracker (RT), Virtualisation: VMware, Elogger.<br />
<br />
===== Liens =====<br />
Site IN2P3-SUBATECH dans la GOCDB [https://goc.egi.eu/portal/index.php?Page_Type=View_Object&object_id=151&grid_id=0] <br />
<br />
Expérience ALICE au LHC [http://aliceinfo.cern.ch/Public]<br />
<br />
Carte AliEn [http://pcalimonitor.cern.ch:8889/show?page=index.html]<br />
<br />
Groupe Plasma à SUBATECH [http://www-subatech.in2p3.fr/%7Eplasma/index_plasma.html]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Tier_2:Subatech&diff=8516
Tier 2:Subatech
2021-09-14T06:09:42Z
<p>Barbet: /* Ressources dédiées à LCG */</p>
<hr />
<div>Laboratoire SUBATECH - UMR<br />
CNRS/IN2P3-Ecole des Mines de Nantes-Université de Nantes<br />
http://www-subatech.in2p3.fr/<br />
<br><br />
[[Tier_2:Subatech |Version Française ]] | [[Tier_2:Subatech_en|English Version ]] <br />
<br />
Le laboratoire SUBATECH s'est engagé à participer en tant que centre de traitement "Tier-2" au stockage et à l'analyse des données issues de l'expérience ALICE au LHC.<br />
===== Ressources dédiées à LCG =====<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Année !! 2005 [1]!! 2006 [1]!! 2007 [1]!! 2008 [2] !! 2009 [2] !! 2010 [3] !! 2011 !! 2012 !! 2013 !! 2014 !! 2015 !! 2016 !! 2017 !! 2018 !! 2019 [4] !! 2020 !! 2021 !! 2022 !! 2023<br />
|-<br />
! CPU (KSI2K)<br />
| 14 || 56 ||112 || 312 || 373 || - || - || - || - || - || - || - || - || - || 800 [4] || - || - || - || - <br />
|-<br />
! CPU (SPEC-HEP06)<br />
| - || - || - || - || - || 2400 || 3000 || 3000 || 3000 || 3000 || 3000 || 4500 || 4500 || 4500 || 8500 [4] || 13500 [5] || 13500 || 13500 || à définir<br />
|-<br />
! Stockage (To) <br />
| 4,25 || 15,3 || 16 || 43 || 97 || 200 || 270 || 310 || 310 || 310 || 310 || 800 || 1619 || 1619 || 1500 || 1500 || 2500|| 2500 || 1152<br />
|-<br />
|}<br />
[1] : sur la base de 1CPU = 1,644 KSI2K <br />
<br />
[2] : en KSI2K CERN conformément à [[http://www.cern.ch/LCG/documents/Processor%20performance%20metrics_26may07.pdf CPU Capacity Metrics for WLCG]]<br />
<br />
[3] : SPEC-HEP06 : Nouvelle métrique <br />
<br />
[4] : Ajout de 400 Coeurs CPU mutualisés dans le centre HPC CCIPL Université de Nantes<br />
<br />
[5] : Ajout de 640 Coeurs CPU mutualisés dans le centre HPC CCIPL Université de Nantes<br />
<br />
Référence : http://gstat-wlcg.cern.ch/apps/pledges/resources/<br />
<br />
===== Personnes et moyens humains =====<br />
Responsable Scientifique : Laurent Aphecetche<br />
<br />
Responsable Technique : Jean-Michel Barbet<br />
<br />
Exploitation : Khalil Chawoshi (Chef du Service Informatique), Jean-Michel Barbet, Pierrick Le Corre, Erwan Macé et Jérome Pinot.<br />
Les moyens humains dédiés à LCG représentent actuellement 1,2 ETP.<br />
<br />
===== Financement et partenaires =====<br />
Les achats ont étés réalisés avec les crédits du laboratoire avec l'aide de la Région des Pays-de-Loire. Depuis Juin 2017, la moitié des ressources CPU proviennent d'un mésocentre HPC de l'Université de Nantes : le CCIPL.<br />
<br />
===== Technologies et savoir-faire =====<br />
Cluster local Scientific-Linux 6, OpenPBS. Quattor (worker nodes, disk servers), Puppet, YAIM (service nodes)<br />
<br />
Stockage : SAN, RAID5/6, xrootd, EOS<br />
<br />
Divers : Surveillance Nagios, Support: Request-Tracker (RT), Virtualisation: VMware, Elogger.<br />
<br />
===== Liens =====<br />
Site IN2P3-SUBATECH dans la GOCDB [https://goc.egi.eu/portal/index.php?Page_Type=View_Object&object_id=151&grid_id=0] <br />
<br />
Expérience ALICE au LHC [http://aliceinfo.cern.ch/Public]<br />
<br />
Carte AliEn [http://pcalimonitor.cern.ch:8889/show?page=index.html]<br />
<br />
Groupe Plasma à SUBATECH [http://www-subatech.in2p3.fr/%7Eplasma/index_plasma.html]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Tier_2:Subatech&diff=8515
Tier 2:Subatech
2021-09-14T05:57:13Z
<p>Barbet: /* Ressources dédiées à LCG */</p>
<hr />
<div>Laboratoire SUBATECH - UMR<br />
CNRS/IN2P3-Ecole des Mines de Nantes-Université de Nantes<br />
http://www-subatech.in2p3.fr/<br />
<br><br />
[[Tier_2:Subatech |Version Française ]] | [[Tier_2:Subatech_en|English Version ]] <br />
<br />
Le laboratoire SUBATECH s'est engagé à participer en tant que centre de traitement "Tier-2" au stockage et à l'analyse des données issues de l'expérience ALICE au LHC.<br />
===== Ressources dédiées à LCG =====<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Année !! 2005 [1]!! 2006 [1]!! 2007 [1]!! 2008 [2] !! 2009 [2] !! 2010 [3] !! 2011 [3] !! 2012 [3] !! 2013 [3] !! 2014 [3] !! 2015 [3] !! 2016 [3] !! 2017 [3] !! 2018 !! 2019 [4] !! 2020 !! 2021 !! 2022 !! 2023<br />
|-<br />
! CPU (KSI2K)<br />
| 14 || 56 ||112 || 312 || 373 || - || - || - || - || - || - || - || - || - || 800 [4] || - || - || - || - || -<br />
|-<br />
! CPU (SPEC-HEP06)<br />
| - || - || - || - || - || 2400 || 3000 || 3000 || 3000 || 3000 || 3000 || 4500 || 4500 || 4500 || 8500 [4] || 13500 [5] || 13500 || 13500 || à définir<br />
|-<br />
! Stockage (To) <br />
| 4,25 || 15,3 || 16 || 43 || 97 || 200 || 270 || 310 || 310 || 310 || 310 || 800 || 1619 || 1619 || 1500 || 1500 || 2500|| 2500 || à définir<br />
|-<br />
|}<br />
[1] : sur la base de 1CPU = 1,644 KSI2K <br />
<br />
[2] : en KSI2K CERN conformément à [[http://www.cern.ch/LCG/documents/Processor%20performance%20metrics_26may07.pdf CPU Capacity Metrics for WLCG]]<br />
<br />
[3] : SPEC-HEP06 : Nouvelle métrique <br />
<br />
[4] : Ajout de 400 Coeurs CPU mutualisés dans le centre HPC CCIPL Université de Nantes<br />
<br />
[5] : Ajout de 640 Coeurs CPU mutualisés dans le centre HPC CCIPL Université de Nantes<br />
<br />
Référence : http://gstat-wlcg.cern.ch/apps/pledges/resources/<br />
<br />
===== Personnes et moyens humains =====<br />
Responsable Scientifique : Laurent Aphecetche<br />
<br />
Responsable Technique : Jean-Michel Barbet<br />
<br />
Exploitation : Khalil Chawoshi (Chef du Service Informatique), Jean-Michel Barbet, Pierrick Le Corre, Erwan Macé et Jérome Pinot.<br />
Les moyens humains dédiés à LCG représentent actuellement 1,2 ETP.<br />
<br />
===== Financement et partenaires =====<br />
Les achats ont étés réalisés avec les crédits du laboratoire avec l'aide de la Région des Pays-de-Loire. Depuis Juin 2017, la moitié des ressources CPU proviennent d'un mésocentre HPC de l'Université de Nantes : le CCIPL.<br />
<br />
===== Technologies et savoir-faire =====<br />
Cluster local Scientific-Linux 6, OpenPBS. Quattor (worker nodes, disk servers), Puppet, YAIM (service nodes)<br />
<br />
Stockage : SAN, RAID5/6, xrootd, EOS<br />
<br />
Divers : Surveillance Nagios, Support: Request-Tracker (RT), Virtualisation: VMware, Elogger.<br />
<br />
===== Liens =====<br />
Site IN2P3-SUBATECH dans la GOCDB [https://goc.egi.eu/portal/index.php?Page_Type=View_Object&object_id=151&grid_id=0] <br />
<br />
Expérience ALICE au LHC [http://aliceinfo.cern.ch/Public]<br />
<br />
Carte AliEn [http://pcalimonitor.cern.ch:8889/show?page=index.html]<br />
<br />
Groupe Plasma à SUBATECH [http://www-subatech.in2p3.fr/%7Eplasma/index_plasma.html]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=WLCGBenchmarkingGroup&diff=8500
WLCGBenchmarkingGroup
2020-10-19T09:06:16Z
<p>Barbet: /* Events/Presentations */</p>
<hr />
<div>== Home page ==<br />
<br />
https://twiki.cern.ch/twiki/bin/view/HEPIX/CpuBenchmark<br />
<br />
== Meetings ==<br />
<br />
https://indico.cern.ch/category/1806/<br />
<br />
== Gitlab: HEP-workloads ==<br />
* [https://gitlab.cern.ch/hep-benchmarks/hep-workloads Gitlab HEP-score]<br />
* [https://gitlab.cern.ch/hep-benchmarks/hep-score Benchmarking suite]<br />
* [https://bmkwg.web.cern.ch/bmkwg/ Gitlab : HEP benchmarking Suite]<br />
* [https://gitlab.cern.ch/hep-benchmarks/hep-workloads/container_registry Docker containers of WL-benchmarks]<br />
* [https://es-bmkwg7.cern.ch/kibana/ Kibana Dashboard of Elastic-Search Data repository]<br />
<br />
== Events/Presentations ==<br />
<br />
* [https://indico.jinr.ru/event/738/session/2/contribution/164 conférence NEC'2019 Andrea Vallasi]<br />
* [https://indico.cern.ch/event/739897/ Pre-GDB CERN 8/10/2019]<br />
* [https://indico.cern.ch/event/739883/ GDB CERN 9/10/2019]<br />
* [https://indico.cern.ch/event/773049/contributions/3473809/attachments/1931931/3200035/20191104-CHEP2019-BMK-AV-v005.pdf CHEP 2019 : Benchmarking WLCG resources using HEP experiment workloads]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=WLCGBenchmarkingGroup&diff=8499
WLCGBenchmarkingGroup
2020-10-19T09:01:56Z
<p>Barbet: /* Home page */</p>
<hr />
<div>== Home page ==<br />
<br />
https://twiki.cern.ch/twiki/bin/view/HEPIX/CpuBenchmark<br />
<br />
== Meetings ==<br />
<br />
https://indico.cern.ch/category/1806/<br />
<br />
== Gitlab: HEP-workloads ==<br />
* [https://gitlab.cern.ch/hep-benchmarks/hep-workloads Gitlab HEP-score]<br />
* [https://gitlab.cern.ch/hep-benchmarks/hep-score Benchmarking suite]<br />
* [https://bmkwg.web.cern.ch/bmkwg/ Gitlab : HEP benchmarking Suite]<br />
* [https://gitlab.cern.ch/hep-benchmarks/hep-workloads/container_registry Docker containers of WL-benchmarks]<br />
* [https://es-bmkwg7.cern.ch/kibana/ Kibana Dashboard of Elastic-Search Data repository]<br />
<br />
== Events/Presentations ==<br />
<br />
* conférence NEC'2019 Andrea Vallasi(slides 16 et 21)<br />
* Pre-GDB CERN 8/10/2019<br />
* GDB CERN 9/10/2019<br />
* CHEP 2019</div>
Barbet
https://lcg.in2p3.fr/index.php?title=WLCGBenchmarkingGroup&diff=8498
WLCGBenchmarkingGroup
2020-10-19T09:01:09Z
<p>Barbet: /* Meetings */</p>
<hr />
<div>== Home page ==<br />
<br />
https://twiki.cern.ch/twiki/bin/view/HEPIX/CpuBenchmark<br />
<br />
== Gitlab: HEP-workloads ==<br />
* [https://gitlab.cern.ch/hep-benchmarks/hep-workloads Gitlab HEP-score]<br />
* [https://gitlab.cern.ch/hep-benchmarks/hep-score Benchmarking suite]<br />
* [https://bmkwg.web.cern.ch/bmkwg/ Gitlab : HEP benchmarking Suite]<br />
* [https://gitlab.cern.ch/hep-benchmarks/hep-workloads/container_registry Docker containers of WL-benchmarks]<br />
* [https://es-bmkwg7.cern.ch/kibana/ Kibana Dashboard of Elastic-Search Data repository]<br />
<br />
== Events/Presentations ==<br />
<br />
* conférence NEC'2019 Andrea Vallasi(slides 16 et 21)<br />
* Pre-GDB CERN 8/10/2019<br />
* GDB CERN 9/10/2019<br />
* CHEP 2019</div>
Barbet
https://lcg.in2p3.fr/index.php?title=WLCGBenchmarkingGroup&diff=8497
WLCGBenchmarkingGroup
2020-10-19T09:00:26Z
<p>Barbet: /* Meetings */</p>
<hr />
<div>== Home page ==<br />
<br />
https://twiki.cern.ch/twiki/bin/view/HEPIX/CpuBenchmark<br />
<br />
== Meetings ==<br />
<br />
* Gitlab: HEP-workloads<br />
* [https://gitlab.cern.ch/hep-benchmarks/hep-workloads Gitlab HEP-score]<br />
* [https://gitlab.cern.ch/hep-benchmarks/hep-score Benchmarking suite]<br />
* [https://bmkwg.web.cern.ch/bmkwg/ Gitlab : HEP benchmarking Suite]<br />
* [https://gitlab.cern.ch/hep-benchmarks/hep-workloads/container_registry Docker containers of WL-benchmarks]<br />
* [https://es-bmkwg7.cern.ch/kibana/ Kibana Dashboard of Elastic-Search Data repository]<br />
<br />
== Events/Presentations ==<br />
<br />
* conférence NEC'2019 Andrea Vallasi(slides 16 et 21)<br />
* Pre-GDB CERN 8/10/2019<br />
* GDB CERN 9/10/2019<br />
* CHEP 2019</div>
Barbet
https://lcg.in2p3.fr/index.php?title=WLCGBenchmarkingGroup&diff=8496
WLCGBenchmarkingGroup
2020-10-19T08:59:43Z
<p>Barbet: /* Meetings */</p>
<hr />
<div>== Home page ==<br />
<br />
https://twiki.cern.ch/twiki/bin/view/HEPIX/CpuBenchmark<br />
<br />
== Meetings ==<br />
<br />
* Gitlab: HEP-workloads<br />
* [https://gitlab.cern.ch/hep-benchmarks/hep-workloads Gitlab : HEP-score]<br />
* [https://gitlab.cern.ch/hep-benchmarks/hep-score Benchmarking suite]<br />
* [https://bmkwg.web.cern.ch/bmkwg/ Gitlab : HEP benchmarking Suite]<br />
* [https://gitlab.cern.ch/hep-benchmarks/hep-workloads/container_registry Docker containers of WL-benchmarks]<br />
* [https://es-bmkwg7.cern.ch/kibana/ Kibana Dashboard of Elastic-Search Data repository]<br />
<br />
== Events/Presentations ==<br />
<br />
* conférence NEC'2019 Andrea Vallasi(slides 16 et 21)<br />
* Pre-GDB CERN 8/10/2019<br />
* GDB CERN 9/10/2019<br />
* CHEP 2019</div>
Barbet
https://lcg.in2p3.fr/index.php?title=WLCGBenchmarkingGroup&diff=8495
WLCGBenchmarkingGroup
2020-10-19T08:57:26Z
<p>Barbet: /* Events/Presentations */</p>
<hr />
<div>== Home page ==<br />
<br />
https://twiki.cern.ch/twiki/bin/view/HEPIX/CpuBenchmark<br />
<br />
== Meetings ==<br />
<br />
* Gitlab: HEP-workloads<br />
* Gitlab : HEP-score<br />
* Benchmarking suite<br />
* Gitlab : HEP benchmarking Suite<br />
* Docker containers of WL-benchmarks<br />
* Kibana Dashboard of Elastic-Search Data repository<br />
* Gitlab: private-tools<br />
<br />
== Events/Presentations ==<br />
<br />
* conférence NEC'2019 Andrea Vallasi(slides 16 et 21)<br />
* Pre-GDB CERN 8/10/2019<br />
* GDB CERN 9/10/2019<br />
* CHEP 2019</div>
Barbet
https://lcg.in2p3.fr/index.php?title=WLCGBenchmarkingGroup&diff=8494
WLCGBenchmarkingGroup
2020-10-19T08:57:06Z
<p>Barbet: /* Meetings */</p>
<hr />
<div>== Home page ==<br />
<br />
https://twiki.cern.ch/twiki/bin/view/HEPIX/CpuBenchmark<br />
<br />
== Meetings ==<br />
<br />
* Gitlab: HEP-workloads<br />
* Gitlab : HEP-score<br />
* Benchmarking suite<br />
* Gitlab : HEP benchmarking Suite<br />
* Docker containers of WL-benchmarks<br />
* Kibana Dashboard of Elastic-Search Data repository<br />
* Gitlab: private-tools<br />
<br />
== Events/Presentations ==<br />
<br />
* conférence NEC'2019 Andrea Vallasi(slides 16 et 21)<br />
* Pre-GDB CERN 8/10/2019<br />
* GDB CERN 9/10/2019<br />
* CHEP 2019</div>
Barbet
https://lcg.in2p3.fr/index.php?title=WLCGBenchmarkingGroup&diff=8493
WLCGBenchmarkingGroup
2020-10-19T08:56:43Z
<p>Barbet: Created page with "== Home page == https://twiki.cern.ch/twiki/bin/view/HEPIX/CpuBenchmark == Meetings == * Gitlab: HEP-workloads * Gitlab : HEP-score * Benchmarking suite..."</p>
<hr />
<div>== Home page ==<br />
<br />
https://twiki.cern.ch/twiki/bin/view/HEPIX/CpuBenchmark<br />
<br />
== Meetings ==<br />
<br />
* Gitlab: HEP-workloads<br />
* Gitlab : HEP-score<br />
* Benchmarking suite<br />
* Gitlab : HEP benchmarking Suite<br />
* Docker containers of WL-benchmarks<br />
* Kibana Dashboard of Elastic-Search Data repository<br />
* Gitlab: private-tools<br />
<br />
== Events/Presentations ==<br />
<br />
* conférence NEC'2019 Andrea Vallasi(slides 16 et 21)<br />
* Pre-GDB CERN 8/10/2019<br />
* GDB CERN 9/10/2019<br />
* CHEP 2019</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Tier_2:Subatech&diff=8489
Tier 2:Subatech
2019-11-04T15:59:28Z
<p>Barbet: </p>
<hr />
<div>Laboratoire SUBATECH - UMR<br />
CNRS/IN2P3-Ecole des Mines de Nantes-Université de Nantes<br />
http://www-subatech.in2p3.fr/<br />
<br><br />
[[Tier_2:Subatech |Version Française ]] | [[Tier_2:Subatech_en|English Version ]] <br />
<br />
Le laboratoire SUBATECH s'est engagé à participer en tant que centre de traitement "Tier-2" au stockage et à l'analyse des données issues de l'expérience ALICE au LHC.<br />
===== Ressources dédiées à LCG =====<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Année !! 2005 [1]!! 2006 [1]!! 2007 [1]!! 2008 [2] !! 2009 [2] !! 2010 [3] !! 2011 [3] !! 2012 [3] !! 2013 [3] !! 2014 [3] !! 2015 [3] !! 2016 [3] !! 2017 [3] !! 2018 !! 2019 [4] !! au-delà<br />
|-<br />
! CPU (KSI2K)<br />
| 14 || 56 ||112 || 312 || 373 || - || - || - || - || - || - || - || - || - || 800 [4] || à définir<br />
|-<br />
! CPU (SPEC-HEP06)<br />
| - || - || - || - || - || 2400 || 3000 || 3000 || 3000 || 3000 || 3000 || 4500 || 4500 || 4500 || 8500 [4] || à définir<br />
|-<br />
! Stockage (To) <br />
| 4,25 || 15,3 || 16 || 43 || 97 || 200 || 270 || 310 || 310 || 310 || 310 || 800 || 1619 || 1619 || 1500 ||à définir<br />
|-<br />
|}<br />
[1] : sur la base de 1CPU = 1,644 KSI2K <br />
<br />
[2] : en KSI2K CERN conformément à [[http://www.cern.ch/LCG/documents/Processor%20performance%20metrics_26may07.pdf CPU Capacity Metrics for WLCG]]<br />
<br />
[3] : SPEC-HEP06 : Nouvelle métrique <br />
<br />
[4] : Ajout de 400 Coeurs CPU mutualisés dans le centre HPC CCIPL Université de Nantes<br />
<br />
Référence : http://gstat-wlcg.cern.ch/apps/pledges/resources/<br />
<br />
===== Personnes et moyens humains =====<br />
Responsable Scientifique : Laurent Aphecetche<br />
<br />
Responsable Technique : Jean-Michel Barbet<br />
<br />
Exploitation : Khalil Chawoshi (Chef du Service Informatique), Jean-Michel Barbet, Pierrick Le Corre, Erwan Macé et Jérome Pinot.<br />
Les moyens humains dédiés à LCG représentent actuellement 1,2 ETP.<br />
<br />
===== Financement et partenaires =====<br />
Les achats ont étés réalisés avec les crédits du laboratoire avec l'aide de la Région des Pays-de-Loire. Depuis Juin 2017, la moitié des ressources CPU proviennent d'un mésocentre HPC de l'Université de Nantes : le CCIPL.<br />
<br />
===== Technologies et savoir-faire =====<br />
Cluster local Scientific-Linux 6, OpenPBS. Quattor (worker nodes, disk servers), Puppet, YAIM (service nodes)<br />
<br />
Stockage : SAN, RAID5/6, xrootd, EOS<br />
<br />
Divers : Surveillance Nagios, Support: Request-Tracker (RT), Virtualisation: VMware, Elogger.<br />
<br />
===== Liens =====<br />
Site IN2P3-SUBATECH dans la GOCDB [https://goc.egi.eu/portal/index.php?Page_Type=View_Object&object_id=151&grid_id=0] <br />
<br />
Expérience ALICE au LHC [http://aliceinfo.cern.ch/Public]<br />
<br />
Carte AliEn [http://pcalimonitor.cern.ch:8889/show?page=index.html]<br />
<br />
Groupe Plasma à SUBATECH [http://www-subatech.in2p3.fr/%7Eplasma/index_plasma.html]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=HT-Condor&diff=8442
HT-Condor
2018-11-15T09:18:51Z
<p>Barbet: </p>
<hr />
<div>Démarrer avec HT-Condor<br />
=== Démarrer avec HT-Condor ===<br />
<br />
[Page en cours de création]<br />
<br />
==== Documentation et références ====<br />
<br />
Site de référence : http://research.cs.wisc.edu/htcondor/<br />
<br />
Wiki : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki<br />
<br />
Recettes Administrateur : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToAdminRecipes<br />
<br />
Manuel (version stable 8.2) : http://research.cs.wisc.edu/htcondor/manual/v8.2/index.html<br />
<br />
European HTCondor Site Admins Meeting 2014 : http://indico.cern.ch/event/272794/<br />
<br />
Workshop HT-Condor / ARC-CE, Cerdanyola-del-Vallès, 2016 : https://indico.cern.ch/event/467075/<br />
<br />
==== Repositories et installation ====<br />
<br />
http://research.cs.wisc.edu/htcondor/yum/<br />
<br />
<tt><br />
cd /etc/yum.repos.d/<br />
wget http://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel6.repo<br />
yum install condor<br />
</tt><br />
<br />
Attention: condor est aussi distribué via les repositories UMD, il peut être nécessaire de désactiver ces repositories ou bien d'utiliser les priorités avec YUM.<br />
<br />
==== Installation personnelle : configuration et premiers tests ====<br />
<br />
La configuration par défaut après l'installation du RPM permet de tester le produit sur une seule machine. Dans ce cas, sur la même machine, on trouve les trois types de noeuds : <i>submit node</i>, <i>master node</i> et <i>worker node</i>.<br />
<br />
Démarrer les demons :<br />
<br />
<tt><br />
service condor start<br />
Starting up Condor... done.<br />
<br />
service condor status<br />
Condor is running (pid 22310)<br />
</tt><br />
Les processus suivants sont lancés :<br />
<tt><br />
ps -ef | grep condor<br />
condor 22310 1 0 09:52 ? 00:00:00 /usr/sbin/condor_master -pidfile /var/run/condor/condor.pid<br />
root 22311 22310 0 09:52 ? 00:00:00 condor_procd -A /var/run/condor/procd_pipe -L /var/log/condor/ProcLog -R 1000000 -S 60 -C 493<br />
condor 22312 22310 0 09:52 ? 00:00:00 condor_collector -f<br />
condor 22314 22310 0 09:52 ? 00:00:00 condor_negotiator -f<br />
condor 22315 22310 0 09:52 ? 00:00:00 condor_schedd -f<br />
condor 22316 22310 0 09:52 ? 00:00:00 condor_startd -f<br />
condor 22359 22316 93 09:53 ? 00:00:11 mips<br />
</tt><br />
<br />
En ce qui concerne le demon qui gère un worker node (condor_startd), les processeurs disponibles sue la machine locale sont bien reconnus :<br />
<br />
<tt><br />
condor_status<br />
Name OpSys Arch State Activity LoadAv Mem ActvtyTime<br />
<br />
slot1@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:30:11<br />
slot2@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.030 1949 0+00:50:05<br />
slot3@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:06<br />
slot4@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:07<br />
Total Owner Claimed Unclaimed Matched Preempting Backfill<br />
<br />
X86_64/LINUX 4 0 0 4 0 0 0<br />
<br />
Total 4 0 0 4 0 0 0<br />
</tt><br />
<br />
Créer un programme de test (un script shell lançant des exécutables) :<br />
<br />
<tt><br />
more HT-Condor/testprog01.sh<br />
#! /bin/sh<br />
echo "HT-condor testprog01"<br />
echo "I'm process id $$ on" `hostname`<br />
echo "This is sent to standard error" 1>&2<br />
date<br />
echo "Running as binary $0" "$@"<br />
echo "My name (argument 1) is $1"<br />
echo "My sleep duration (argument 2) is $2"<br />
sleep $2<br />
echo "Sleep of $2 seconds finished. Exiting"<br />
exit 0<br />
</tt><br />
<br />
Créer la description du travail :<br />
<br />
<tt><br />
executable=testprog01.sh<br />
universe=vanilla<br />
arguments=Example.$(Cluster).$(Process) 100<br />
output=results.output.$(Process)<br />
error=results.error.$(Process)<br />
log=results.log<br />
notification=never<br />
should_transfer_files=YES<br />
when_to_transfer_output = ON_EXIT<br />
queue<br />
</tt><br />
<br />
Lancer le job :<br />
<br />
<tt><br />
condor_submit testprog01.submit <br />
Submitting job(s).<br />
1 job(s) submitted to cluster 1.<br />
</tt><br />
<br />
En surveiller l'exécution :<br />
<br />
<tt><br />
condor_q<br />
<br />
-- Submitter: nanpc117.in2p3.fr : <134.158.25.117:39976> : nanpc117.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
1.0 untel 8/4 09:57 0+00:00:05 R 0 0.0 testprog01.sh Exam<br />
<br />
1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended<br />
</tt><br />
<br />
Fin du job : les fichiers demandés sont là :<br />
<br />
<tt><br />
ls<br />
results.error.0 results.output.0 testprog01.submit<br />
results.log testprog01.sh<br />
</tt><br />
<br />
==== Installation type cluster local ====<br />
<br />
Le cluster de compose de : <br />
<br />
* une machine qui joue le rôle de serveur de batch (demons : condor_master, condor_collector, condor_negotiator)<br />
* une ou plusieurs machines pouvant soumettre des travaux (demon : condor_shedd) <br />
* les machines devant exécuter les travaux (worker nodes) (demons : )<br />
<br />
On installe le même RPM partout (comme ci-dessus) et c'est via les fichiers de configuration dans le répertoire /etc/condor que les machines vont jouer un rôle différent.<br />
Il est recommandé de ne jamais modifier le fichier /etc/condor/condor_config mais de surcharger la config par un fichier /etc/condor/condor_config.local ou mieux : un ensemble de fichiers dans /etc/condor/config.d<br />
Le fichier peut être le même pour toutes les machines et les différences exprimées avec des fichiers dans /etc/condor/config.d.<br />
<br />
Exemple de fichier global /etc/condor/condor_config.local :<br />
<br />
<tt><br />
# 0-General-Settings-and-Macros<br />
<br />
UID_DOMAIN = htcondor-grid@subatech.in2p3.fr<br />
CENTRAL_MANAGER1 = nanpbs3.in2p3.fr<br />
COLLECTOR_HOST = $(CENTRAL_MANAGER1)<br />
CONDOR_HOST=$(CENTRAL_MANAGER1)<br />
<br />
EVENT_LOG = EventLog<br />
<br />
# 1-Use-Security<br />
<br />
# 2-Policies<br />
<br />
SEC_DEFAULT_AUTHENTICATION = REQUIRED<br />
<br />
# 3-Authorizations<br />
<br />
ALLOW_WRITE = <br />
ALLOW_READ = */*.in2p3.fr<br />
ALLOW_DAEMON = *.in2p3.fr<br />
ALLOW_ADMINISTRATOR = root@$(CONDOR_HOST)<br />
ALLOW_CONFIG = root@$(FULL_HOSTNAME)<br />
<br />
# 4-Authentication<br />
SEC_PASSWORD_FILE = /etc/condor/pool_password<br />
SEC_READ_AUTHENTICATION = OPTIONAL<br />
SEC_CLIENT_AUTHENTICATION = REQUIRED<br />
SEC_DEFAULT_AUTHENTICATION_METHODS = PASSWORD,FS<br />
SCHEDD.SEC_WRITE_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SCHEDD.SEC_DAEMON_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SEC_CLIENT_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
SEC_READ_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
</tt><br />
<br />
Le modèle de sécurité choisi ici repose sur le partage d'une clé commune entre les différentes machines (submitter,master,workers). Cette clé /etc/condor/pool_password est crée par la commande suivante et distribuée sur les machines :<br />
<br />
<tt><br />
condor_store_cred -f /etc/condor/pool_password<br />
Enter password: xxxxxx<br />
</tt><br />
<br />
Ce modèle est assez simple et n'apporte que l'authentification entre demons, pas le chiffrement et le contrôle de l'intégrité des communications.<br />
<br />
<br />
===== Configuration du serveur de batch (nanpbs3.in2p3.fr) =====<br />
<br />
Dans cet exemple, le serveur de batch est aussi machine de soumission (il dispose des mêmes comptes que sur les worker nodes)<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/20-master.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = COLLECTOR, MASTER, NEGOTIATOR, SCHEDD<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
</tt><br />
<br />
===== Configuration d'un worker node (nanwn58.in2p3.fr) =====<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/10-workernode.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = MASTER, STARTD<br />
TRUST_UID_DOMAIN=TRUE<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
DaemonMaster None nanwn58.in2p3.fr <br />
Machine Job slot1@nanwn58.in2p3.fr <br />
Machine Job slot2@nanwn58.in2p3.fr <br />
Machine Job slot3@nanwn58.in2p3.fr <br />
Machine Job slot4@nanwn58.in2p3.fr <br />
Machine Job slot5@nanwn58.in2p3.fr <br />
Machine Job slot6@nanwn58.in2p3.fr <br />
Machine Job slot7@nanwn58.in2p3.fr <br />
Machine Job slot8@nanwn58.in2p3.fr <br />
</tt><br />
<br />
Examen de la queue depuis le server et submitter :<br />
<tt><br />
[root@nanpbs3 ~]# condor_q<br />
<br />
<br />
-- Submitter: nanpbs3.in2p3.fr : <193.48.101.50:58431> : nanpbs3.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
<br />
0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended<br />
</tt><br />
<br />
===== Réseaux privés, ports de communication, Pares-Feu =====<br />
<br />
Lorsque HTCondor est réparti sur plusieurs machines, rien de spécial n'est à faire si toutes sont situées dans le même réseau.<br />
Par contre, dans le cas ou elles sont isolées par des pares-feu ou autres, il faut faire ouvrir les ports utilisés par Condor. Dans le cas d'un tout petit cluster (1 CM avec Collecteur , Negotiateur et Scheduleur et 2 workers), il suffit d'autoriser l'écriture, d'ouvrir un intervalle de ports et les définir dans le fichier de configuration de condor (condor_config.local par exemple).<br />
<br />
<tt><br />
# To expand your condor pool beyond a single host, set ALLOW_WRITE to match all of the hosts (last one is ccgr2 Mac)<br />
ALLOW_WRITE = $(ALLOW_WRITE) ,$(CONDOR_HOST) , worker1, worker2, ......<br />
Define the ports used by condor<br />
#NEGOTIATOR_SOCKET_CACHE_SIZE = 16<br />
LOWPORT = 9600<br />
HIGHPORT= 9625 <br />
</tt><br />
En fait, le nombre de ports à ouvrir est de 21 au minimum (5 pour la communication avec les daemons et 16 pour le "negotiator_socket_cache_size" mais il doit augmenter avec la taille du cluster.Pour ce qui est d'une information plus détaillée sur les différents ports utilisés par Condor et réseaux: http://www.wolftech.ncsu.edu/support/support/Condor/Firewall<br />
<br />
Un exemple d'ouverture de ports entre ma VM qui est le CM et mon MAC qui est un de mes worker-nodes:<br />
<tt><br />
- en entree vers mon mac :<br />
permit tcp host 172.xxx host 134.yyy range 9600 9625<br />
permit udp host 172.xxxx host 134.yyy range 9600 9625<br />
-en entree vers le serveur condor :<br />
permit tcp host 134.yyy host 172.xxx range 9600 9625<br />
permit udp host 134.yyy host 172.xxx range 9600 9625<br />
</tt><br />
<br />
===== Gestion des ressources, priorités et comptabilité (accounting) =====<br />
<br />
Dans le cadre d'un cluster local, c'est l'utilisateur qui définit lui-même le groupe auxquel il appartient via une instruction de type ClassAd dans son fichier .submit. Exemple :<br />
<tt><br />
# accounting group<br />
accounting_group = group_info<br />
</tt><br />
<br />
==== Utilisation en contexte grille ====<br />
<br />
Sauf en cas de soumission directe au système de batch local, il faudra installer un Computing-Element (CE). Les CE disponibles actuellement et capables de soumettre à un pool HT-Condor sont :<br />
<br />
* CREAM-CE<br />
* ARC-CE<br />
* HT-Condor-CE<br />
<br />
===== Configuration HT-Condor et ARC-CE =====<br />
<br />
==== Tips and tricks ====<br />
<br />
<br />
<br />
==== Sécurité ====</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Alice&diff=8244
Alice
2018-01-25T07:18:28Z
<p>Barbet: /* Alice T1/T2 Workshops */</p>
<hr />
<div>== ''Bienvenue sur la page Alice LCG-France <br><br> Welcome to the LCG-France Alice page'' ==<br />
<br />
* Alice computing Representative : Renaud Vernet<br />
* Alice Web site : http://aliceinfo.cern.ch/<br />
* Alice Monitoring : http://alimonitor.cern.ch<br />
* Tier-1 site: CCIN2P3<br />
* Tier-2 sites : Subatech Nantes, IPHC Strasbourg, IPN Orsay and IRFU (GRIF), LPC Clermont, CCIN2P3, LPSC Grenoble<br />
* Tier-3 sites : IPN Lyon<br />
<br />
<br />
==== [[Alice:Communication| Alice Communication VO/Sites]] ====<br />
<br />
* VO Alice ID Card : https://cic.gridops.org/index.php?section=vo<br />
* Alice LCG Task Force<br />
* Liste de diffusion : alice-lcg-task-force@cern.ch<br />
* AliEn WiKi : http://alien2.cern.ch<br />
<br />
==== [[Alice:Communication| Alice T1/T2 Workshops]] ====<br />
<br />
* CERN 26-27 Mai 2009 http://indico.cern.ch/event/58444/<br />
* Karlsruhe 24-26 Janvier 2012 https://indico.cern.ch/event/157585/<br />
* Lyon 4-6 Juin 2013 https://indico.in2p3.fr/event/8114/<br />
* Tsukuba 3-8 Mars 2014 https://indico.cern.ch/event/274974/overview<br />
* Torino 23-25 Février 2015 https://indico.cern.ch/event/354209/overview<br />
* Bergen 18-20 Avril 2016 https://indico.cern.ch/event/485835/<br />
* Strasbourg 3-5 Mai 2017 https://indico.cern.ch/event/595536/<br />
* Derby 17-19 Avril 2018 https://indico.cern.ch/event/690294/<br />
<br />
==== [[Alice:Vobox| Alice Vobox]] ====<br />
Il faut commencer par installer une machine LCG en VOBOX (meta-package YAIM)<br />
et vérifier que sur cette machine on dispose de toutes les fonctionnalités d'une UI<br />
LCG (soumission de jobs).<br />
<br />
Voir cette doc :<br />
http://alien2.cern.ch/index.php?option=com_content&view=article&id=21&Itemid=67<br />
<br />
Il existe un script permettant de tester les fonctions LCG nécessaires<br />
avant d'installer AliEn.<br />
<br />
<strike>Il faut installer un LFC local (sur la VOBOX ou ailleurs).</strike><br />
(màj début 2007 : Ce n'est plus nécessaire d'installer un LFC sur la VOBOX).<br />
<br />
Il faut ensuite installer AliEn. Cela se fait en récupérant un<br />
"installer" : un script shell qui va se charger de récupérer<br />
les packages et les installer<br />
<pre><br />
wget alien.cern.ch/alien-installer<br />
</pre><br />
<br />
Il faut aussi s'enregister auprès de la VO Alice (fournir le DN de son <br />
certificat) et demander le rôle alicesgm :<br />
http://alien.cern.ch/twiki/bin/view/Alice/UserRegistration<br />
<br />
AliEn se compose de plusieurs demons ou "services" :<br />
<br />
- Monitor<br />
- CE<br />
- CMreport<br />
- MonaLisa<br />
<br />
Home WiKi ALiEn :<br />
http://alien2.cern.ch<br />
<br />
Il y a pas mal de trous à faire dans le firewall:<br />
<br />
[https://twiki.cern.ch/twiki/pub/LCG/VoBoxesInfo/VO-Box-security-policy_v05.doc Security Policy]<br />
<br />
<br />
--[[Utilisateur:Barbet|Barbet]] 14 Octobre 2015 à 10:11 (CEST)*</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Tier_2:Subatech&diff=8220
Tier 2:Subatech
2017-12-13T10:38:36Z
<p>Barbet: </p>
<hr />
<div>Laboratoire SUBATECH - UMR<br />
CNRS/IN2P3-Ecole des Mines de Nantes-Université de Nantes<br />
http://www-subatech.in2p3.fr/<br />
<br><br />
[[Tier_2:Subatech |Version Française ]] | [[Tier_2:Subatech_en|English Version ]] <br />
<br />
Le laboratoire SUBATECH s'est engagé à participer en tant que centre de traitement "Tier-2" au stockage et à l'analyse des données issues de l'expérience ALICE au LHC.<br />
===== Ressources dédiées à LCG =====<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Année !! 2005 [1]!! 2006 [1]!! 2007 [1]!! 2008 [2] !! 2009 [2] !! 2010 [3] !! 2011 [3] !! 2012 [3] !! 2013 [3] !! 2014 [3] !! 2015 [3] !! 2016 [3] !! 2017 [3] !! au-delà<br />
|-<br />
! CPU (KSI2K)<br />
| 14 || 56 ||112 || 312 || 373 || - || - || - || - || - || - || - || - || à définir<br />
|-<br />
! CPU (SPEC-HEP06)<br />
| - || - || - || - || - || 2400 || 3000 || 3000 || 3000 || 3000 || 3000 || 4500 || 4500 || à définir<br />
|-<br />
! Stockage (To) <br />
| 4,25 || 15,3 || 16 || 43 || 97 || 200 || 270 || 310 || 310 || 310 || 310 || 800 || 1619 ||à définir<br />
|-<br />
|}<br />
[1] : sur la base de 1CPU = 1,644 KSI2K <br />
<br />
[2] : en KSI2K CERN conformément à [[http://www.cern.ch/LCG/documents/Processor%20performance%20metrics_26may07.pdf CPU Capacity Metrics for WLCG]]<br />
<br />
[3] : SPEC-HEP06 : Nouvelle métrique <br />
<br />
Référence : http://gstat-wlcg.cern.ch/apps/pledges/resources/<br />
<br />
===== Personnes et moyens humains =====<br />
Responsable Scientifique : Laurent Aphecetche<br />
<br />
Responsable Technique : Jean-Michel Barbet<br />
<br />
Exploitation : Khalil Chawoshi (Chef du Service Informatique), Jean-Michel Barbet, Pierrick Le Corre, Erwan Macé et Jérome Pinot.<br />
Les moyens humains dédiés à LCG représentent actuellement 1,2 ETP.<br />
<br />
===== Financement et partenaires =====<br />
Les achats ont étés réalisés avec les crédits du laboratoire avec l'aide de la Région des Pays-de-Loire. Depuis Juin 2017, la moitié des ressources CPU proviennent d'un mésocentre HPC de l'Université de Nantes : le CCIPL.<br />
<br />
===== Technologies et savoir-faire =====<br />
Cluster local Scientific-Linux 6, OpenPBS. Quattor (worker nodes, disk servers), Puppet, YAIM (service nodes)<br />
<br />
Stockage : SAN, RAID5/6, xrootd, EOS<br />
<br />
Divers : Surveillance Nagios, Support: Request-Tracker (RT), Virtualisation: VMware, Elogger.<br />
<br />
===== Liens =====<br />
Site IN2P3-SUBATECH dans la GOCDB [https://goc.egi.eu/portal/index.php?Page_Type=View_Object&object_id=151&grid_id=0] <br />
<br />
Expérience ALICE au LHC [http://aliceinfo.cern.ch/Public]<br />
<br />
Carte AliEn [http://pcalimonitor.cern.ch:8889/show?page=index.html]<br />
<br />
Groupe Plasma à SUBATECH [http://www-subatech.in2p3.fr/%7Eplasma/index_plasma.html]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Tier_2:Subatech&diff=8214
Tier 2:Subatech
2017-12-13T10:37:57Z
<p>Barbet: </p>
<hr />
<div>Laboratoire SUBATECH - UMR<br />
CNRS/IN2P3-Ecole des Mines de Nantes-Université de Nantes<br />
http://www-subatech.in2p3.fr/<br />
<br><br />
[[Tier_2:Subatech |Version Française ]] | [[Tier_2:Subatech_en|English Version ]] <br />
<br />
Le laboratoire SUBATECH s'est engagé à participer en tant que centre de traitement "Tier-2" au stockage et à l'analyse des données issues de l'expérience ALICE au LHC.<br />
===== Ressources dédiées à LCG =====<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Année !! 2005 [1]!! 2006 [1]!! 2007 [1]!! 2008 [2] !! 2009 [2] !! 2010 [3] !! 2011 [3] !! 2012 [3] !! 2013 [3] !! 2014 [3] !! 2015 [3] !! 2016 [3] !! 2017 [3] !! au-delà<br />
|-<br />
! CPU (KSI2K)<br />
| 14 || 56 ||112 || 312 || 373 || - || - || - || - || - || - || - || - || à définir<br />
|-<br />
! CPU (SPEC-HEP06)<br />
| - || - || - || - || - || 2400 || 3000 || 3000 || 3000 || 3000 || 3000 || 4500 || 4500 || à définir<br />
|-<br />
! Stockage (To) <br />
| 4,25 || 15,3 || 16 || 43 || 97 || 200 || 270 || 310 || 310 || 310 || 310 || 800 || 1619 ||à définir<br />
|-<br />
|}<br />
[1] : sur la base de 1CPU = 1,644 KSI2K <br />
<br />
[2] : en KSI2K CERN conformément à [[http://www.cern.ch/LCG/documents/Processor%20performance%20metrics_26may07.pdf CPU Capacity Metrics for WLCG]]<br />
<br />
[3] : SPEC-HEP06 : Nouvelle métrique <br />
<br />
Référence : http://gstat-wlcg.cern.ch/apps/pledges/resources/<br />
<br />
===== Personnes et moyens humains =====<br />
Responsable Scientifique : Laurent Aphecetche<br />
<br />
Responsable Technique : Jean-Michel Barbet<br />
<br />
Exploitation : Khalil Chawoshi (Chef du Service Informatique), Jean-Michel Barbet, Pierrick Le Corre, Jean Andrianavaly et Jérome Pinot.<br />
Les moyens humains dédiés à LCG représentent actuellement 1,2 ETP.<br />
<br />
===== Financement et partenaires =====<br />
Les achats ont étés réalisés avec les crédits du laboratoire avec l'aide de la Région des Pays-de-Loire. Depuis Juin 2017, la moitié des ressources CPU proviennent d'un mésocentre HPC de l'Université de Nantes : le CCIPL.<br />
<br />
===== Technologies et savoir-faire =====<br />
Cluster local Scientific-Linux 6, OpenPBS. Quattor (worker nodes, disk servers), Puppet, YAIM (service nodes)<br />
<br />
Stockage : SAN, RAID5/6, xrootd, EOS<br />
<br />
Divers : Surveillance Nagios, Support: Request-Tracker (RT), Virtualisation: VMware, Elogger.<br />
<br />
===== Liens =====<br />
Site IN2P3-SUBATECH dans la GOCDB [https://goc.egi.eu/portal/index.php?Page_Type=View_Object&object_id=151&grid_id=0] <br />
<br />
Expérience ALICE au LHC [http://aliceinfo.cern.ch/Public]<br />
<br />
Carte AliEn [http://pcalimonitor.cern.ch:8889/show?page=index.html]<br />
<br />
Groupe Plasma à SUBATECH [http://www-subatech.in2p3.fr/%7Eplasma/index_plasma.html]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=ARC-CE&diff=8179
ARC-CE
2017-10-18T07:24:19Z
<p>Barbet: /* Testing the Information service */</p>
<hr />
<div>ARC-CE/HT-Condor : Installation, Configuration Recipes<br />
<br />
== Installation ==<br />
<br />
=== Requirements ===<br />
* NTP<br />
* Local accounts or NIS (ypbind)<br />
* Host certificate for the ARC-CE<br />
<br />
=== HT-Condor ===<br />
* Install HT-Condor and configure the ARC-CE as a HT-Condor ''submitter''<br />
* Add firewall rule to allow condor communications<br />
firewall-cmd --permanent --zone=public --add-port=9618/tcp<br />
<br />
* Test HT-Condor submitter<br />
<br />
=== ARC-CE ===<br />
* Configure repositories<br />
* Install ARC-CE<br />
* Add firewall rules for ARC-CE<br />
<br />
== Configuration ==<br />
<br />
=== ARC-CE configuration file ===<br />
<br />
=== Configuration LCMAPS/LCAS (mapping) ===<br />
<br />
== Start(Stop) ARC-CE services ==<br />
<br />
=== Start the gridftp service ===<br />
<br />
systemctl start gridftpd.service<br />
<br />
=== Start ARC-CE service (a-rex) ===<br />
<br />
systemctl start a-rex<br />
<br />
=== Start Information service (BDII/LDAP) ===<br />
<br />
systemctl restart nordugrid-arc-ldap-infosys.service<br />
<br />
== Test ==<br />
<br />
=== Testing the Information service ===<br />
<br />
UI>arcinfo -c nanlcg08.in2p3.fr<br />
Computing service: MINIMAL Computing Element (production)<br />
Information endpoint: ldap://nanlcg08.in2p3.fr:2135/Mds-Vo-Name=local,o=grid<br />
Information endpoint: ldap://nanlcg08.in2p3.fr:2135/o=glue<br />
Submission endpoint: gsiftp://nanlcg08.in2p3.fr:2811/jobs (status: ok, interface: org.nordugrid.gridftpjob)<br />
<br />
UI>ldapsearch -x -H ldap://nanlcg08.in2p3.fr:2135 -b mds-vo-name=local,o=grid<br />
# extended LDIF<br />
#<br />
# LDAPv3<br />
# base <mds-vo-name=local,o=grid> with scope subtree<br />
# filter: (objectclass=*)<br />
# requesting: ALL<br />
#<br />
# local, grid<br />
dn: Mds-Vo-name=local,o=grid<br />
objectClass: Mds<br />
Mds-Vo-name: local<br />
Mds-validfrom: 20171018071546Z<br />
Mds-validto: 20171018081546Z<br />
# nanlcg08.in2p3.fr, local, grid<br />
dn: nordugrid-cluster-name=nanlcg08.in2p3.fr,Mds-Vo-name=local,o=grid<br />
nordugrid-cluster-totalcpus: 8<br />
[...]<br />
<br />
ldapsearch -x -H ldap://nanlcg08.in2p3.fr:2135 -b o=glue<br />
# extended LDIF<br />
#<br />
# LDAPv3<br />
# base <o=glue> with scope subtree<br />
# filter: (objectclass=*)<br />
# requesting: ALL<br />
#<br />
# glue<br />
dn: o=glue<br />
objectClass: organization<br />
o: glue<br />
# services, glue<br />
dn: GLUE2GroupID=services,o=glue<br />
objectClass: GLUE2Group<br />
GLUE2GroupID: services<br />
[...]<br />
<br />
== ARC-CE/HT-Condor for HPC ==<br />
<br />
== External links ==<br />
* [http://www.nordugrid.org/arc/ce/ ARC-CE home page]<br />
* [https://www.gridpp.ac.uk/wiki/Example_Build_of_an_ARC/Condor_Cluster GridPP Example Build of an ARC/Condor Cluster]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=ARC-CE&diff=8176
ARC-CE
2017-10-18T07:23:45Z
<p>Barbet: /* Testing the Information service */</p>
<hr />
<div>ARC-CE/HT-Condor : Installation, Configuration Recipes<br />
<br />
== Installation ==<br />
<br />
=== Requirements ===<br />
* NTP<br />
* Local accounts or NIS (ypbind)<br />
* Host certificate for the ARC-CE<br />
<br />
=== HT-Condor ===<br />
* Install HT-Condor and configure the ARC-CE as a HT-Condor ''submitter''<br />
* Add firewall rule to allow condor communications<br />
firewall-cmd --permanent --zone=public --add-port=9618/tcp<br />
<br />
* Test HT-Condor submitter<br />
<br />
=== ARC-CE ===<br />
* Configure repositories<br />
* Install ARC-CE<br />
* Add firewall rules for ARC-CE<br />
<br />
== Configuration ==<br />
<br />
=== ARC-CE configuration file ===<br />
<br />
=== Configuration LCMAPS/LCAS (mapping) ===<br />
<br />
== Start(Stop) ARC-CE services ==<br />
<br />
=== Start the gridftp service ===<br />
<br />
systemctl start gridftpd.service<br />
<br />
=== Start ARC-CE service (a-rex) ===<br />
<br />
systemctl start a-rex<br />
<br />
=== Start Information service (BDII/LDAP) ===<br />
<br />
systemctl restart nordugrid-arc-ldap-infosys.service<br />
<br />
== Test ==<br />
<br />
=== Testing the Information service ===<br />
<br />
UI>arcinfo -c nanlcg08.in2p3.fr<br />
Computing service: MINIMAL Computing Element (production)<br />
Information endpoint: ldap://nanlcg08.in2p3.fr:2135/Mds-Vo-Name=local,o=grid<br />
Information endpoint: ldap://nanlcg08.in2p3.fr:2135/o=glue<br />
Submission endpoint: gsiftp://nanlcg08.in2p3.fr:2811/jobs (status: ok, interface: org.nordugrid.gridftpjob)<br />
<br />
UI>ldapsearch -x -H ldap://nanlcg08.in2p3.fr:2135 -b mds-vo-name=local,o=grid<br />
# extended LDIF<br />
#<br />
# LDAPv3<br />
# base <mds-vo-name=local,o=grid> with scope subtree<br />
# filter: (objectclass=*)<br />
# requesting: ALL<br />
#<br />
# local, grid<br />
dn: Mds-Vo-name=local,o=grid<br />
objectClass: Mds<br />
Mds-Vo-name: local<br />
Mds-validfrom: 20171018071546Z<br />
Mds-validto: 20171018081546Z<br />
# nanlcg08.in2p3.fr, local, grid<br />
dn: nordugrid-cluster-name=nanlcg08.in2p3.fr,Mds-Vo-name=local,o=grid<br />
nordugrid-cluster-totalcpus: 8<br />
[...]<br />
<br />
ldapsearch -x -H ldap://nanlcg08.in2p3.fr:2135 -b o=glue<br />
# extended LDIF<br />
#<br />
# LDAPv3<br />
# base <o=glue> with scope subtree<br />
# filter: (objectclass=*)<br />
# requesting: ALL<br />
#<br />
# glue<br />
dn: o=glue<br />
objectClass: organization<br />
o: glue<br />
# services, glue<br />
dn: GLUE2GroupID=services,o=glue<br />
objectClass: GLUE2Group<br />
GLUE2GroupID: services<br />
[...]<br />
<br />
== ARC-CE/HT-Condor for HPC ==<br />
<br />
== External links ==<br />
* [http://www.nordugrid.org/arc/ce/ ARC-CE home page]<br />
* [https://www.gridpp.ac.uk/wiki/Example_Build_of_an_ARC/Condor_Cluster GridPP Example Build of an ARC/Condor Cluster]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=ARC-CE&diff=8170
ARC-CE
2017-10-18T07:19:45Z
<p>Barbet: /* Test */</p>
<hr />
<div>ARC-CE/HT-Condor : Installation, Configuration Recipes<br />
<br />
== Installation ==<br />
<br />
=== Requirements ===<br />
* NTP<br />
* Local accounts or NIS (ypbind)<br />
* Host certificate for the ARC-CE<br />
<br />
=== HT-Condor ===<br />
* Install HT-Condor and configure the ARC-CE as a HT-Condor ''submitter''<br />
* Add firewall rule to allow condor communications<br />
firewall-cmd --permanent --zone=public --add-port=9618/tcp<br />
<br />
* Test HT-Condor submitter<br />
<br />
=== ARC-CE ===<br />
* Configure repositories<br />
* Install ARC-CE<br />
* Add firewall rules for ARC-CE<br />
<br />
== Configuration ==<br />
<br />
=== ARC-CE configuration file ===<br />
<br />
=== Configuration LCMAPS/LCAS (mapping) ===<br />
<br />
== Start(Stop) ARC-CE services ==<br />
<br />
=== Start the gridftp service ===<br />
<br />
systemctl start gridftpd.service<br />
<br />
=== Start ARC-CE service (a-rex) ===<br />
<br />
systemctl start a-rex<br />
<br />
=== Start Information service (BDII/LDAP) ===<br />
<br />
systemctl restart nordugrid-arc-ldap-infosys.service<br />
<br />
== Test ==<br />
<br />
=== Testing the Information service ===<br />
<br />
UI>arcinfo -c nanlcg08.in2p3.fr<br />
Computing service: MINIMAL Computing Element (production)<br />
Information endpoint: ldap://nanlcg08.in2p3.fr:2135/Mds-Vo-Name=local,o=grid<br />
Information endpoint: ldap://nanlcg08.in2p3.fr:2135/o=glue<br />
Submission endpoint: gsiftp://nanlcg08.in2p3.fr:2811/jobs (status: ok, interface: org.nordugrid.gridftpjob)<br />
<br />
UI>ldapsearch -x -H ldap://nanlcg08.in2p3.fr:2135 -b mds-vo-name=local,o=grid<br />
# extended LDIF<br />
#<br />
# LDAPv3<br />
# base <mds-vo-name=local,o=grid> with scope subtree<br />
# filter: (objectclass=*)<br />
# requesting: ALL<br />
#<br />
# local, grid<br />
dn: Mds-Vo-name=local,o=grid<br />
objectClass: Mds<br />
Mds-Vo-name: local<br />
Mds-validfrom: 20171018071546Z<br />
Mds-validto: 20171018081546Z<br />
# nanlcg08.in2p3.fr, local, grid<br />
dn: nordugrid-cluster-name=nanlcg08.in2p3.fr,Mds-Vo-name=local,o=grid<br />
nordugrid-cluster-totalcpus: 8<br />
[...]<br />
<br />
ldapsearch -x -H ldap://nanlcg08.in2p3.fr:2135 -b o=glue<br />
# extended LDIF<br />
#<br />
# LDAPv3<br />
# base <o=glue> with scope subtree<br />
# filter: (objectclass=*)<br />
# requesting: ALL<br />
#<br />
# glue<br />
dn: o=glue<br />
objectClass: organization<br />
o: glue<br />
# services, glue<br />
dn: GLUE2GroupID=services,o=glue<br />
objectClass: GLUE2Group<br />
GLUE2GroupID: services<br />
[...]<br />
<br />
== ARC-CE/HT-Condor for HPC ==<br />
<br />
== External links ==<br />
* [http://www.nordugrid.org/arc/ce/ ARC-CE home page]<br />
* [https://www.gridpp.ac.uk/wiki/Example_Build_of_an_ARC/Condor_Cluster GridPP Example Build of an ARC/Condor Cluster]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=ARC-CE&diff=8164
ARC-CE
2017-10-18T07:11:43Z
<p>Barbet: /* Start(Stop) ARC-CE services */</p>
<hr />
<div>ARC-CE/HT-Condor : Installation, Configuration Recipes<br />
<br />
== Installation ==<br />
<br />
=== Requirements ===<br />
* NTP<br />
* Local accounts or NIS (ypbind)<br />
* Host certificate for the ARC-CE<br />
<br />
=== HT-Condor ===<br />
* Install HT-Condor and configure the ARC-CE as a HT-Condor ''submitter''<br />
* Add firewall rule to allow condor communications<br />
firewall-cmd --permanent --zone=public --add-port=9618/tcp<br />
<br />
* Test HT-Condor submitter<br />
<br />
=== ARC-CE ===<br />
* Configure repositories<br />
* Install ARC-CE<br />
* Add firewall rules for ARC-CE<br />
<br />
== Configuration ==<br />
<br />
=== ARC-CE configuration file ===<br />
<br />
=== Configuration LCMAPS/LCAS (mapping) ===<br />
<br />
== Start(Stop) ARC-CE services ==<br />
<br />
=== Start the gridftp service ===<br />
<br />
systemctl start gridftpd.service<br />
<br />
=== Start ARC-CE service (a-rex) ===<br />
<br />
systemctl start a-rex<br />
<br />
=== Start Information service (BDII/LDAP) ===<br />
<br />
systemctl restart nordugrid-arc-ldap-infosys.service<br />
<br />
== Test ==<br />
<br />
== ARC-CE/HT-Condor for HPC ==<br />
<br />
== External links ==<br />
* [http://www.nordugrid.org/arc/ce/ ARC-CE home page]<br />
* [https://www.gridpp.ac.uk/wiki/Example_Build_of_an_ARC/Condor_Cluster GridPP Example Build of an ARC/Condor Cluster]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=ARC-CE&diff=8158
ARC-CE
2017-10-11T12:24:53Z
<p>Barbet: </p>
<hr />
<div>ARC-CE/HT-Condor : Installation, Configuration Recipes<br />
<br />
== Installation ==<br />
<br />
=== Requirements ===<br />
* NTP<br />
* Local accounts or NIS (ypbind)<br />
* Host certificate for the ARC-CE<br />
<br />
=== HT-Condor ===<br />
* Install HT-Condor and configure the ARC-CE as a HT-Condor ''submitter''<br />
* Add firewall rule to allow condor communications<br />
firewall-cmd --permanent --zone=public --add-port=9618/tcp<br />
<br />
* Test HT-Condor submitter<br />
<br />
=== ARC-CE ===<br />
* Configure repositories<br />
* Install ARC-CE<br />
* Add firewall rules for ARC-CE<br />
<br />
== Configuration ==<br />
<br />
=== ARC-CE configuration file ===<br />
<br />
=== Configuration LCMAPS/LCAS (mapping) ===<br />
<br />
== Start(Stop) ARC-CE services ==<br />
<br />
== Test ==<br />
<br />
== ARC-CE/HT-Condor for HPC ==<br />
<br />
== External links ==<br />
* [http://www.nordugrid.org/arc/ce/ ARC-CE home page]<br />
* [https://www.gridpp.ac.uk/wiki/Example_Build_of_an_ARC/Condor_Cluster GridPP Example Build of an ARC/Condor Cluster]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=ARC-CE&diff=8152
ARC-CE
2017-10-11T12:18:29Z
<p>Barbet: </p>
<hr />
<div>ARC-CE/HT-Condor : Installation, Configuration Recipes<br />
<br />
== Installation ==<br />
<br />
=== Requirements ===<br />
* NTP<br />
* Local accounts or NIS (ypbind)<br />
* Host certificate for the ARC-CE<br />
<br />
=== HT-Condor ===<br />
* Install HT-Condor and configure the ARC-CE as a ''submitter''<br />
* Add firewall rule to allow condor communications<br />
* Test HT-Condor submitter<br />
<br />
=== ARC-CE ===<br />
* Configure repositories<br />
* Install ARC-CE<br />
* Add firewall rules for ARC-CE<br />
<br />
== Configuration ==<br />
<br />
=== ARC-CE configuration file ===<br />
<br />
=== Configuration LCMAPS/LCAS (mapping) ===<br />
<br />
== Start(Stop) ARC-CE services ==<br />
<br />
== Test ==<br />
<br />
== ARC-CE/HT-Condor for HPC ==<br />
<br />
== External links ==<br />
* [http://www.nordugrid.org/arc/ce/ ARC-CE home page]<br />
* [https://www.gridpp.ac.uk/wiki/Example_Build_of_an_ARC/Condor_Cluster GridPP Example Build of an ARC/Condor Cluster]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=ARC-CE&diff=8149
ARC-CE
2017-10-11T12:16:58Z
<p>Barbet: </p>
<hr />
<div>ARC-CE/HT-Condor : Installation, Configuration Recipes<br />
<br />
== Installation ==<br />
<br />
=== Requirements ===<br />
* NTP<br />
* Local accounts or NIS (ypbind)<br />
* Host certificate for the ARC-CE<br />
<br />
=== HT-Condor ===<br />
* Install HT-Condor and configure the ARC-CE as a ''submitter''<br />
* Add firewall rule to allow condor communications<br />
* Test HT-Condor submitter<br />
<br />
=== ARC-CE ===<br />
* Configure repositories<br />
* Install ARC-CE<br />
* Add firewall rules for ARC-CE<br />
<br />
== Configuration ==<br />
<br />
=== ARC-CE configuration file ===<br />
<br />
=== Configuration LCMAPS/LCAS (mapping) ===<br />
<br />
== Start ARC-CE services<br />
<br />
== Test ==<br />
<br />
== ARC-CE/HT-Condor for HPC ==<br />
<br />
== External links ==<br />
* [http://www.nordugrid.org/arc/ce/ ARC-CE home page]<br />
* [https://www.gridpp.ac.uk/wiki/Example_Build_of_an_ARC/Condor_Cluster GridPP Example Build of an ARC/Condor Cluster]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=ARC-CE&diff=8143
ARC-CE
2017-10-10T13:29:01Z
<p>Barbet: </p>
<hr />
<div>Installation, Configuration Recipes<br />
<br />
<br />
<br />
== External links ==<br />
* [http://www.nordugrid.org/arc/ce/ ARC-CE home page]<br />
* [https://www.gridpp.ac.uk/wiki/Example_Build_of_an_ARC/Condor_Cluster GridPP Example Build of an ARC/Condor Cluster]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=ARC-CE&diff=8140
ARC-CE
2017-10-10T13:28:20Z
<p>Barbet: LCG-FR Tech ARC-CE Installation/Configuration recipes</p>
<hr />
<div>Installation, Configuration Recipes<br />
<br />
<br />
<br />
== External links ==<br />
[http://www.nordugrid.org/arc/ce/ ARC-CE home page]<br />
[https://www.gridpp.ac.uk/wiki/Example_Build_of_an_ARC/Condor_Cluster GridPP Example Build of an ARC/Condor Cluster]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=CPU-Benches&diff=8043
CPU-Benches
2017-01-09T13:01:51Z
<p>Barbet: /* Tests réalisés par Jean-Michel : */</p>
<hr />
<div>'''Transition vers les nouvelles unités specs HEP-SPEC06'''<br />
--MàJ --[[User:Chollet|Chollet]] 09:37, 11 septembre 2009 (CEST)--<br />
<br />
=== Page HEPiX de référence === <br />
* https://hepix.caspur.it/benchmarks<br />
<br />
* <br />
=== One major rule of HS06 benchmarking is to run the benchmark in exactly the same system configuration which is also used for production ===<br />
* If a site runs WNs with hyperthreading disabled, they must run the benchmark on a system under test with HT<br />
disabled, and vice versa.<br />
* The number of HS06 benchmark copies should be set to the same number of job slots like the WNs are configured.'''<br />
<br />
=== Stratégie LCG ===<br />
* LCG Overview Board - Change of CPU accounting unit (I.Bird):<br />
''The working group on benchmarking has now concluded, both on the new benchmark and on the transition process from SI2K. A new benchmark, based on the SPEC 2006 suite has been agreed upon. This uses a combination of the SPEC2006 FP and INT benchmarks, and has been shown to scale well with the experiments’ applications. This benchmark, labelled HEP-SPEC06, will be used in future to specify requirements and resources. '''There is an agreement to use a simple conversion factor of 4 representing the benchmarks ratio HEP-SPEC06/kSI2K'''. Sites will be requested to benchmark their existing resources, and the results will be published on a web site. Future procurements should require the vendor to run the benchmark – provided as a simple script. Planning for changing the reporting in the accounting system is under way. The new unit will be used in the April RRB.''<br />
* LCG Management Board : [https://twiki.cern.ch/twiki/pub/LCG/MbMeetingsMinutes/LCG_Management_Board_2009_01_27.htm Décision du MB du 27 janvier 2009] s'appuyant sur la [http://indico.cern.ch/materialDisplay.py?contribId=3&sessionId=0&materialId=0&confId=49388 proposition du groupe technique (G.Merino)] <br />
* Pledges WLCG en HEP-SPEC06 : http://lcg.web.cern.ch/LCG/resources.htm<br />
<br />
=== HEP-SPEC06 Benchmark ===<br />
*Le script dispo à https://twiki.cern.ch/twiki/bin/view/FIOgroup/TsiBenchHEPSPEC (Voir les attachements en bas de page tar.gz)<br />
<br />
* La distribution de la suite SPEC CPU2006 version 1.1 est disponible (sous AFS au CC).<br />
Pour plus d'infos contacter F.Chollet ou Pierre Larrieu<br />
<br />
=== Conversion des kSI2k ===<br />
* Facteur de conversion HEP-SPEC06/kSI2k : 4<br />
* 1 kSI2k = 4 HEP-SPEC06<br />
<br />
=== Publication des capacités CPU ===<br />
* Document de référence pour la publication dans le contexte actuel (Glue schema 1.3): <br />
https://twiki.cern.ch/twiki/pub/LCG/WLCGCommonComputingReadinessChallenges/WLCG_GlueSchemaUsage-1.8.pdf <br><br />
<br />
Tentative de synthèse --[[User:Chollet|Chollet]] 09:46, 11 septembre 2009 (CEST)<br />
** PhysicalCPUs = processeurs c.a.d chipset<br />
Un subcluster de 113 machines bi processeurs quadricoeurs = 226 CPUs physiques<br />
** LogicalCPUs = processeurs logiques ou vus de l'OS correspond au nombre de cœurs pour <br />
autant que l'hyperthreading ne soit pas activé (incluant les machines offline ou arrêtées)<br />
Un subcluster de 113 machines bi processeurs quadricoeurs = 904 CPUs logiques<br />
Le nombre de cœurs par CPU physique (par chipset) étant de 4 <br />
A publier via l'attribut ''GlueSubClusterLogicalCPUs''<br />
** A noter : Un SubCluster est a priori défini comme un ensemble homogène de workers mais <br />
il est "admis que dans la pratique" cela ne soit pas le cas. Dans ce cas, les sites sont<br />
sensés publier des spécifications moyennes pour certains attributs.<br />
<br />
* Consignes pour les sites / Advices for sites (Juin 2009):<br />
[http://indico.cern.ch/getFile.py/access?sessionId=2&resId=1&materialId=0&confId=63028 Présentation J.Gordon]<br />
<br />
Tentative de synthèse --[[User:Chollet|Chollet]] 17:50, 10 septembre 2009 (CEST)<br />
MàJ --[[User:Chollet|Chollet]] 17:01, 2 décembre 2009 (CET)<br />
- Effectuer la mesure de la '''capacité CPU de la machine''' à partir du benchmark HEP-SPEC06<br />
en utilisant le script mis à disposition ci-dessous. '''ATTENTION''' le bench fournit <br />
un score par machine et la publication se fait par cœur<br />
- Publier la '''capacité par cœur''' en HEP-SPEC06 via <br />
''GlueHostProcessorOtherDescription: Benchmark=<value>-HEP-SPEC06''<br />
Cet attribut est également utilisé pour publier le nombre moyen de cœurs par processeur<br />
(ou chipset)<br />
''GlueHostProcessorOtherDescription: Cores=<typical number of cores per CPU>, Benchmark=<br />
<value>-HEP-SPEC06'' <br />
- Convertir la capacité CPU par coeur en SI2K en mulipliant par 250<br />
- Mettre à jour l'attribut ''GlueHostBenchmarkSI00'' <br />
<br />
Les sites qui n'ont pas passé le benchmark HEP-SPEC06 doivent publier une valeur moyenne en SpecInt200 <br />
par LogicalCPU via l'attribut ''GlueHostBenchmarkSI00'' <br />
<br />
En cas de clusteur ou sous-clusteur hétérogène, GlueHostBenchmarkSI00 étant défini comme "Average SpecInt2000 rating per logical CPU" c.a.d par coeur pourvu que l'hyperthreading soit désactivé, vous êtes invités à publier une valeur moyenne pondérée. Voir le document<br />
de référence page 5 (dernière ligne)<br />
<br />
<br />
-----<br />
<br />
=== Résultats des benchs effectués par les sites ===<br />
SPEC CPU2000 <br />
Des tests de puissance des CPU ont été réalisés au LAPP (Eric Fede) et à Subatech (Jean-Michel Barbet) avecla suite SPEC CPU2000 suivant la méthodologie recommandée : http://hepix.caspur.it/processors/<br />
Ajout des tests au CPPM (Edith Knoops)<br />
<br />
HEP-SPEC06<br />
Des mesures avec le benchmark suite HEP-SPEC06 sont également disponibles ( fond bleu des tableaux)<br />
<br />
<br />
==== Tests réalisés par Jean-Michel :====<br />
<br />
A noter que les tests ont été réalisés sur des machines en configuration opérationnelles pour la grille (avec tous les daemons).<br />
<br />
'''Scientific-Linux V4.3 i386, gcc v3.4.5'''<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core [1] !! FZK SI2K/core [3] !! CERN SI2K/core corrigé [2] !! '''HEP-SPEC06 32bits/machine [4]''' !! '''SPEC HEP 64bits/machine [5]''' <br />
|-<br />
| Dell PE1955 || Woodcrest 5160 3.00GHz || 4 || 8Go || 1409 || 1830 || 2113 || bgcolor="#0066FF" | 39.48 || bgcolor="#0066FF" | -<br />
|-<br />
| IBM || Clovertown 2.33GHz || 8 || 16Go || 979 || 1875 || 1468 || bgcolor="#0066FF" | 53.12 || bgcolor="#0066FF" | -<br />
|-<br />
|}<br />
<br />
'''Scientific Linux SL release 4.5 (Beryllium) x86_64, gcc v3.4.6'''<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core [1] !! FZK SI2K/core [3] !! CERN SI2K/core corrigé [2] !! '''HEP-SPEC06 32bits/machine [4]''' !! '''SPEC HEP 64bits/machine [5]''' <br />
|-<br />
| Dell P21950 || Clovertown E5420 2.50GHz || 8 || 16Go || - || - || - || bgcolor="#0066FF" | 63.18 || bgcolor="#0066FF" | 57.63<br />
|-<br />
|}<br />
<br />
'''Scientific Linux SL release 5.3 (Boron) x86_64 gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)'''<br />
<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core [1] !! FZK SI2K/core [3] !! CERN SI2K/core corrigé [2] !! '''HEP-SPEC06 32bits/machine [4]''' !! '''SPEC HEP 64bits/machine [5]''' <br />
|-<br />
| Dell P21950 || Clovertown E5420 2.50GHz || 8 || 16Go || - || - || - || bgcolor="#0066FF" | [6] || bgcolor="#0066FF" | [6]<br />
|-<br />
| Dell R410 || Nehalem E5520 2.26GHz || 8 || 16Go || - || - || - || bgcolor="#0066FF" | 94.38 || bgcolor="#0066FF" | -<br />
|-<br />
| Dell R410 || Nehalem E5520 2.26GHz || 16 [7] || 16Go || - || - || - || bgcolor="#0066FF" | 114.36 [7] || bgcolor="#0066FF" | -<br />
|-<br />
|}<br />
<br />
<br />
'''[Août 2013] Scientific Linux SL release 6.3 (Carbon) x86_64 gcc version 4.4.6 20120305 (Red Hat 4.4.6-4)'''<br />
<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core [1] !! FZK SI2K/core [3] !! CERN SI2K/core corrigé [2] !! '''HEP-SPEC06 32bits/machine [4]''' !! '''SPEC HEP 64bits/machine [5]''' <br />
|-<br />
| Dell P21950 || Clovertown E5420 2.50GHz || 8 || 16Go || - || - || - || bgcolor="#0066FF" | 71.24 || bgcolor="#0066FF" | -<br />
|-<br />
| Dell R410 || Nehalem E5520 2.26GHz || 8 || 16Go || - || - || - || bgcolor="#0066FF" | 96.36 || bgcolor="#0066FF" | -<br />
|-<br />
| Dell R410 || Nehalem E5620 2.40GHz || 8 || 16Go || - || - || - || bgcolor="#0066FF" | 102.13 || bgcolor="#0066FF" | -<br />
|-<br />
|}<br />
<br />
<br />
'''[Novembre 2013] Scientific Linux SL release 6.3 (Carbon) x86_64 gcc version 4.4.6 20120305 (Red Hat 4.4.6-4)'''<br />
<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core [1] !! FZK SI2K/core [3] !! CERN SI2K/core corrigé [2] !! '''HEP-SPEC06 32bits/machine [4]''' !! '''SPEC HEP 64bits/machine [5]''' <br />
|-<br />
| Dell R420 || Intel(R) Xeon(R) CPU E5-2407 0 @ 2.20GHz || 8 || 32Go || - || - || - || bgcolor="#0066FF" | 100.79 || bgcolor="#0066FF" | -<br />
|-<br />
|}<br />
<br />
'''[Décembre 2016] Scientific Linux SL release 6.5 (Carbon) x86_64 gcc version 4.4.7 20120313 (Red Hat 4.4.7-4)'''<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core [1] !! FZK SI2K/core [3] !! CERN SI2K/core corrigé [2] !! '''HEP-SPEC06 32bits/machine [8]''' !! '''SPEC HEP 64bits/machine [5]''' <br />
|-<br />
| Dell R420 || Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz || 16 || 32Go || - || - || - || bgcolor="#0066FF" | 252.31 || bgcolor="#0066FF" | -<br />
|-<br />
|}<br />
<br />
'''Fiches SPEC des machines :'''<br />
<br />
Dell PowerEdge 1955 Woodcrest 5160 : http://www.spec.org/osg/cpu2000/results/res2006q3/cpu2000-20060626-06298.html<br />
<br />
Dell PowerEdge 1950 Clovertown E5420 2.33GHz : <br />
<br />
Dell PowerEdge 1950 E5420 2.50GHz : <br />
<br />
IBM 3550 Woodcrest 5160 : http://www.spec.org/osg/cpu2000/results/res2006q3/cpu2000-20060623-06219.html<br />
<br />
IBM 3350 Clovertown E5345 : http://www.spec.org/osg/cpu2000/results/res2006q4/cpu2000-20061113-07918.html<br />
<br />
'''Notes :'''<br />
<br />
[1] : Moyenne de 3 exécutions successives avec les optimisations CERN, chaque exécution démarrant un benchmark CPU2000 par CPU core. <br />
<br />
[2] : Correction : La valeur moyenne ci-dessus + 50%. C'est la valeur à publier via le système d'information de la grille.<br />
<br />
[3] : Une exécution unique avec les optimisations FZK à titre indicatif.<br />
<br />
[4] : Benchmark suite HEP SPEC, en suivant les recommandations : https://twiki.cern.ch/twiki/bin/view/FIOgroup//TsiBenchHEPSPEC <br />
<br />
[5] : A titre indicatif : résultats avec les binaires 64bits (HEP-SEPC06 n'est défini que pour des binaires 32bits)<br />
<br />
[6] : Ce test est suspendu car je suis tombé sur le problème suivant : <br />
https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0909&L=LCG-ROLLOUT&P=R3371<br />
<br />
[7] : En activant l'hyperthreading, les benches tournent en 16 exemplaires. A titre indicatif (une seule mesure).<br />
<br />
[8] : Benchmark suite HEP SPEC avec la suite SPEC-CPU2006v12 en suivant les recommandations :http://w3.hepix.org/benchmarks/doku.php?id=bench:howto <br />
<br />
----<br />
<br />
==== Tests réalisés au LAPP (eric) : ====<br />
<br />
Scientific-Linux V3.08 i386, gcc v3.4.3<br />
<br />
A noter que les tests ont été réalisés sur des machines dont tous les services non nécéssaires étaient desactivés<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core [1] !! FZK SI2K/core [3]!! CERN SI2K/core corrigé [2] <br />
|-<br />
| HP BL 460c || Woodcrest 2.66GHz || 4 || 8Go || 1367 || 1665 || 2050 <br />
|-<br />
|}<br />
<br />
<br />
Scientific-Linux V4.5 x86_64, gcc v3.4<br />
<br />
A noter que les tests ont été réalisés sur des machines dont tous les services non nécéssaires étaient desactivés. Un tuning "simple" au niveau du bios donne des disparités dans les résultats des bench qui depassent les 10 %.<br />
<br />
On est toujours dans le cas où l'hyperthreading est désactivé : nb de cores logiques = nb de cores physiques = nombre de thread<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core [1] !! FZK SI2K/core [3]!! CERN SI2K/core corrigé [2] !! '''HEP-SPEC06 32bits [4] per machin''' !! '''HEP-SPEC06 64bits [4] per machin''' <br />
|-<br />
| HP BL 460c || Woodcrest 2.66GHz || 4 || 8Go || 1485 || 1592 || 2227 || bgcolor="#0066FF" | 36.58 || bgcolor="#0066FF" | 34.6 <br />
|-<br />
| HP BL 460c || Clovertown 2.33GHz || 8 || 16Go || 1225 || x || 1837 || bgcolor="#0066FF" | 56.04 || bgcolor="#0066FF" | 51.18<br />
|-<br />
| DELL 1950 || Intel 5335 2GHz || 8 || 8Go || 1060 || 1139 || 1590 || bgcolor="#0066FF" | x || bgcolor="#0066FF" | x<br />
|-<br />
| HP BL 460c || Harpertown 3GHz || 8 || 16Go || 1620 || 1715 || 2430 || bgcolor="#0066FF" | 70.83 || bgcolor="#0066FF" | 63.99<br />
|-<br />
| DELL M600 || Harpertown 2.66GHz || 8 || 32Go || 1481 || 1588 || 2221 || bgcolor="#0066FF" | x || bgcolor="#0066FF" | x<br />
|-<br />
| HP BL 2x220G6 || Nehalem L5520 2.27GHz || 8 || 16Go || x || x || x || bgcolor="#0066FF" | 95.35 || bgcolor="#0066FF" | x<br />
|}<br />
<br />
<br />
[1] : Moyenne de 3 exécutions successives avec les optimisations CERN, chaque exécution démarrant un benchmark CPU2000 par CPU core. <br />
<br />
[2] : Correction : La valeur moyenne ci-dessus + 50%. C'est la valeur à publier via le système d'information de la grille.<br />
<br />
[3] : Une exécution unique avec les optimisations FZK à titre indicatif.<br />
<br />
[4] : Benchmark suite HEP SPEC, en suivant les recommandations : https://twiki.cern.ch/twiki/bin/view/FIOgroup//TsiBenchHEPSPEC <br />
<br />
<br />
<br />
<br />
<span style="color:#0066FF">Scientific-Linux V5.5 x86_64, </span> <span style="color:#00FF00">Scientific-Linux V6.3 x86_64 : GCC 4.4.6-4, </span> <span style="color:#CC3333">Scientific-Linux V6.5 x86_64 : GCC 4.4.7-11, </span><br />
<br />
Hyperthreading toujours actif, c'est la version 32 bits du bench qui doit être publiée (COULEUR INTENSE)<br />
La version 64 bits du bench est donnée à titre indicative ( COULEUR PASTEL) <br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Machine !! CPU !! Nb cores !! Mémoire RAM !! Nb de Threads !! '''HEP-SPEC06 32bits per machin''' !! '''HEP-SPEC06 64bits per machin''' !! '''HEP-SPEC06 32bits per machin''' !! '''HEP-SPEC06 64bits per machin''' <br />
|-<br />
| HP BL 460c || Woodcrest 2.66GHz || 4 || 8Go || 4 || bgcolor="#0066FF" | 36.58 || bgcolor="#A0C2F6" | x || bgcolor="#00FF00" | 44.15 || bgcolor="#C5F6A0" | x<br />
|-<br />
| HP BL 460c || Harpertown 3GHz || 8 || 16Go || 8 || bgcolor="#0066FF" | 70.83 || bgcolor="#A0C2F6" | x || bgcolor="#00FF00" | 75.47 || bgcolor="#C5F6A0" | x<br />
|-<br />
| HP BL 280c || Intel E5630 2.53GHz || 8 + 8(HT) || 32Go || 8 || bgcolor="#0066FF" | 103.60 || bgcolor="#A0C2F6" | 119.36 || bgcolor="#00FF00" | 117.07 || bgcolor="#C5F6A0" | x<br />
|-<br />
| HP BL 280c || Intel E5630 2.53GHz || 8 + 8(HT) || 32Go || 12 || bgcolor="#0066FF" | 122.31 || bgcolor="#A0C2F6" | 137.36 || bgcolor="#00FF00" |126.71 || bgcolor="#C5F6A0" |x<br />
|-<br />
| HP BL 280c || Intel E5630 2.53GHz || 8 + 8(HT) || 32Go || 16 || bgcolor="#0066FF" | 128.04 || bgcolor="#A0C2F6" | 140.42 || bgcolor="#00FF00" | 138.20 || bgcolor="#C5F6A0" | x<br />
|-<br />
| HP BL 280c || Intel E5645 2.40GHz || 12 + 12(HT) || 48Go || 16 || bgcolor="#0066FF" | 165.5 || bgcolor="#A0C2F6" | x || bgcolor="#00FF00" | 171.28 || bgcolor="#C5F6A0" | 191.62<br />
|-<br />
| HP BL 280c || Intel E5645 2.40GHz || 12 + 12(HT) || 48Go || 18 || bgcolor="#0066FF" | 170.8 || bgcolor="#A0C2F6" | x ||bgcolor="#00FF00" |175.47 || bgcolor="#C5F6A0" | 199.31 <br />
|-<br />
| HP BL 280c || Intel E5645 2.40GHz || 12 + 12(HT) || 48Go || 20 || bgcolor="#0066FF" | 175.2 || bgcolor="#A0C2F6" | x ||bgcolor="#00FF00" | 178.62 || bgcolor="#C5F6A0" | 199.93 <br />
|-<br />
| Fujitsu BX924 S4 || INTEL E5-2630L v2 2.40GHz || 12 + 12(HT) || 64Go || 16 || bgcolor="#0066FF" | x || bgcolor="#A0C2F6" | x ||bgcolor="#00FF00" | 200.62 || bgcolor="#C5F6A0" | 237.63<br />
|-<br />
| Fujitsu BX924 S4 || INTEL E5-2630L v2 2.40GHz || 12 + 12(HT) || 64Go || 18 || bgcolor="#0066FF" | x || bgcolor="#A0C2F6" | x ||bgcolor="#00FF00" | 209.39 || bgcolor="#C5F6A0" | 244.46<br />
|-<br />
| Fujitsu BX924 S4 || INTEL E5-2630L v2 2.40GHz || 12 + 12(HT) || 64Go || 20 || bgcolor="#0066FF" | x || bgcolor="#A0C2F6" | x ||bgcolor="#00FF00" | 216.47 || bgcolor="#C5F6A0" | 250.21<br />
|- <br />
| Fujitsu BX924 S4 || INTEL E5-2630L v2 2.40GHz || 12 + 12(HT) || 64Go || 24 || bgcolor="#0066FF" | x || bgcolor="#A0C2F6" | x ||bgcolor="#00FF00" | 224.71 || bgcolor="#C5F6A0" | x<br />
|-<br />
| Fujitsu BX2560 || INTEL E5-2620 v3 2.40GHz || 12 + 12(HT) || 64Go || 18 || bgcolor="#0066FF" | x || bgcolor="#A0C2F6" | x ||bgcolor="#CC3333" | 232.06 || bgcolor="#FF0099" | x<br />
|-<br />
| Fujitsu BX2560 || INTEL E5-2620 v3 2.40GHz || 12 + 12(HT) || 64Go || 20 || bgcolor="#0066FF" | x || bgcolor="#A0C2F6" | x ||bgcolor="#CC3333" | 240.51 || bgcolor="#FF0099" | x<br />
|-<br />
| Fujitsu BX2560 || INTEL E5-2620 v3 2.40GHz || 12 + 12(HT) || 64Go || 24 || bgcolor="#0066FF" | x || bgcolor="#A0C2F6" | x ||bgcolor="#CC3333" | 252.46 || bgcolor="#FF0099" | x<br />
|-<br />
|}<br />
<br />
<br />
<br />
----<br />
<br />
==== Tests réalisés au CPPM (Edith/Carlos) : ====<br />
<br />
Scientific-Linux 4.6 x86_64, gcc v3.4.6<br />
<br />
Scientific-Linux 5.3 x86_64, gcc 4.1.2 <br />
<br />
A noter que les tests ont été réalisés sur des machines dont tous les services non nécéssaires étaient desactivés<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core !! FZK SI2K/core !! CERN32 SI2K/core || CERN SI2K/core corrigé !! '''HEP-SPEC06 32bits (SL4)''' || '''HEP-SPEC06 32bits (SL5.3)''' || '''HEP-SPEC06 64bits (SL5.3)'''<br />
|-<br />
| HP DL145 || Opteron 250 2.4Ghz || 2 || 4Go || 1149 || 1278 || 972 || 1725 || 15.14 || bgcolor="#0066FF" | 16.16 || <br />
|-<br />
| SUN || Opteron 250 2.4Ghz || 2 || 4Go || 1173 || 1298 || 988 || 1760 || || ||<br />
|-<br />
| HP DL145G2 || Opteron 275 2.2 Ghz || 4 ||6Go || 981 || 1087 || 857 || 1471 || 26.52 || bgcolor="#0066FF" | 27.41 ||<br />
|-<br />
| DELL || Opteron 2218 2.6 Ghz || 4 || 8Go || 1199 || 1073 ||1045 || 1798 || 32.24 || bgcolor="#0066FF" | 31.68 ||<br />
|-<br />
| DELL || Xeon E5420 2.5Ghz || 8 || 16 Go || 1418 ||1528 || x ||2128 || 63.12 || bgcolor="#0066FF" | 68.64 ||<br />
|-<br />
|DELL || Xeon X5550 2.67GHz || 8 || 24 Go || || || || || || bgcolor="#0066FF" | 116 ||<br />
|-<br />
|DELL || Xeon X5550 2.67GHz || 16 [1] || 24 Go || || || || || || bgcolor="#0066FF" | 145.82 ||<br />
|- <br />
|DELL R410 || Xeon X5650 2.67GHz || 24 [2] || 48 Go || || || || || || || bgcolor="#0066FF" | 199.34 <br />
|- <br />
|DELL C6100 || Xeon X5650 2.67GHz || 24 [2] || 48 Go || || || || || || || bgcolor="#0066FF" | 231.40 <br />
<br />
|}<br />
<br />
<br />
[1] 8 cores / 16 virtual cpu<br />
<br />
[2] 12 cores / 24 virtual cpu<br />
<br />
----<br />
<br />
==== Tests réalisés à l'IPHC (Jérôme) : ====<br />
<br />
Scientific-Linux 5.3 x86_64, gcc v4.1.2<br />
<br />
Pour la réalisation de ces tests, seuls les services indispensables étaient activés. Pour chaque système, le résultat indiqué est une moyenne de quatre tests. Compte tenu de la variation des résultats, une seule décimale est affichée.<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core !! FZK SI2K/core !! CERN SI2K/core corrigé !! '''HEP-SPEC06 32bits per machin'''<br />
|-<br />
| DELL M600 || Xeon E5410 2.33Ghz || 8 || 16 Go || N/A || N/A || N/A || bgcolor="#0066FF" | 61.1<br />
|-<br />
| DELL M600 || Xeon L5420 2.50Ghz || 8 || 16 Go || N/A || N/A || N/A || bgcolor="#0066FF" | 65.4<br />
|-<br />
| DELL M610 || Xeon E5530 2.40Ghz || 8 || 24 Go || N/A || N/A || N/A || bgcolor="#0066FF" | 100,6<br />
|-<br />
| DELL M610 [1] || Xeon E5530 2.40Ghz || 8 + 8 || 24 Go || N/A || N/A || N/A || bgcolor="#0066FF" | 127,0<br />
|-<br />
| DELL M610 || Xeon L5640 2.26Ghz || 12 || 48 Go || N/A || N/A || N/A || bgcolor="#0066FF" | 142,1<br />
|-<br />
| DELL M610 [1] || Xeon L5640 2.26Ghz || 12 + 12 || 48 Go || N/A || N/A || N/A || bgcolor="#0066FF" | 171,6<br />
|-<br />
| HP SL390s || Xeon E5649 2.53Ghz || 12 || 48 Go || N/A || N/A || N/A || bgcolor="#0066FF" | 146,7<br />
|-<br />
| HP SL390s [1] || Xeon E5649 2.53Ghz || 12 + 12 || 48 Go || N/A || N/A || N/A || bgcolor="#0066FF" | 179,6<br />
|-<br />
| HP SL250 [1] || Xeon E5-2670 2.60Ghz || 16 + 16 || 64 Go || N/A || N/A || N/A || bgcolor="#0066FF" | 338,5<br />
|}<br />
<br />
<br />
[1] Option "Virtual CPU" activée.<br />
<br />
----<br />
<br />
==== Tests réalisés au LPC (Jean-Claude) : ====<br />
<br />
Scientific-Linux 4.6 x86_64, gcc v3.4.6<br />
<br />
Pour la réalisation de ces tests, seuls les services indispensables étaient activés.<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core !! FZK SI2K/core !! CERN SI2K/core corrigé !! '''HEP-SPEC06 32bits [1] per machin'''<br />
|-<br />
| IBM Blade || Xeon E5345 2.33Ghz || 8 || 16Go || N/A || N/A || N/A || bgcolor="#0066FF" | 57.41<br />
|}<br />
<br />
[1] Moyenne des résultats obtenus sur trois tests.<br />
<br />
<br />
Scientific-Linux 5.3 x86_64, gcc v4.1.2<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Machine !! CPU !! Nb cores !! Mémoire RAM !! CERN SI2K/core !! FZK SI2K/core !! CERN SI2K/core corrigé !! '''HEP-SPEC06 32bits [2] per machin'''<br />
|-<br />
| IBM Blade || Xeon E5430 2.66Ghz || 8 || 12Go || N/A || N/A || N/A || bgcolor="#0066FF" | 70.64<br />
|}<br />
<br />
[2] Moyenne des résultats obtenus sur quatre tests.<br />
<br />
<br />
----<br />
<br />
==== Tests réalisés au LLR (pascale): ====<br />
<br />
Scientific-Linux 5.3 x86_64, gcc v4.1.2<br />
<br />
les machines ont ete installees comme les WN standard de la grille<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Machine !! CPU !! Nb cores !! Mémoire RAM !! Virtual CPU enabled !! '''HEP-SPEC06 32bits per machin''' !! HEP-SPEC06 64bits [1] per machin''' <br />
|-<br />
| DELL R410 || E 5520 || 16[1] || 24Go || YES || 118.57 || 143.44<br />
|-<br />
| || E 5540 || 16[1] || 24Go || YES || 128.38 || 151.03<br />
|-<br />
| DELL R410 || E 5520 || 8 || 24Go || NO || 96.51 || 113.35<br />
|-<br />
| || E 5540 || 8 || 24Go || NO || 103.41|| 121.47<br />
|-<br />
| DELL R410 || E 5520 || 16[1] || 16Go || YES || Pas fait || Pas fait<br />
|-<br />
| || E 5540 || 16[1] || 16Go || YES || Pas fait || 148.64<br />
|-<br />
| DELL R410 || E 5520 || 8 || 16Go || NO || 94.97 || 109.42<br />
|-<br />
| || E 5540 || 8 || 16Go || NO || 102.41|| 117.5<br />
<br />
<br />
<br />
|}<br />
<br />
<br />
[1] Sur les serveurs il y a réellement 8 cores en tout. A cause de l'activation du "Virtual CPU" , le systeme d'exploitation pense qu'il y a 16 procs : la commande /proc/cpuinfo donne 16 coeurs. D'après les tests il est interessant d'activer le "Virtual CPU". Mais, combien de jobs faut-il activer en parallele? Et comment allons-nous les déclarer dans la grille?<br />
Voici les résultats des tests avec 8, 10, 12, 14 et 16 jobs lancés en parallèle pour la <br />
configuration suivante : R410, 16g ram, Virtual CPU activé.<br />
<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Nb jobs !! HEP-SPEC06 64bits [1] per machin''' <br />
|-<br />
| 8 jobs || 115.66 <br />
|-<br />
| 10 jobs || 130.66 <br />
|-<br />
| 12 jobs || 139.29 <br />
|-<br />
| 14 jobs || 144.38 <br />
|-<br />
| 16 jobs || 148.64<br />
<br />
|}<br />
<br />
----<br />
==== Tests réalisés à l'IRFU (Christine): ====<br />
Scientific Linux SL release 5.3 (Boron)<br />
<br />
2.6.18-164.6.1.el5 #1 SMP Tue Nov 3 23:02:51 EST 2009 x86_64 x86_64 x86_64 GNU/Linux<br />
<br />
version gcc 4.1.2 20080704 (Red Hat 4.1.2-44)<br />
<br />
<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Machine !! CPU !! Nb cores !! Virtual CPU enabled !! Nbre de thread !! Mémoire RAM !! HEP-SPEC06 64bits per machin [1]''' <br />
|-<br />
| Bull R422 || E 5520 || 16 Virtual CPU / 8 physical CPU || YES || 16 || 24Go || 142.26<br />
|- <br />
| Bull R422 || E 5520 || 16 Virtual CPU / 8 physical CPU || YES || 12 || 24Go || 136.69<br />
|- <br />
| Bull R422 || E 5520 || 16 Virtual CPU / 8 physical CPU || YES || 8 || 24Go || 114.67<br />
|- <br />
| Bull R422 || E 5520 || 8 || NO || 8 || 24Go || 114.01<br />
|- <br />
| Bull R422 || E 5520 || 8 || NO || 12 || 24Go || 121.39<br />
|- <br />
| Fujitsu PRIMERGY RX200 || Intel(R) Xeon(R) CPU L5420 @ 2.50GHz || 8 || _ || 8 || 16Go || 71.26<br />
|- <br />
|}<br />
<br />
<br />
[1] Moyenne des résultats obtenus sur deux tests<br />
<br />
----<br />
==== Tests réalisés à l'IPNL (Denis) : ====<br />
<br />
Scientific Linux SL release 5.4 (Boron)<br />
<br />
2.6.18-274.18.1.el5 #1 SMP Thu Feb 9 12:20:03 EST 2012 x86_64 x86_64 x86_64 GNU/Linux<br />
<br />
version gcc 4.1.2 20080704 (Red Hat 4.1.2-50)<br />
<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | System !! Processor !! Frequency !! L2 Cache !! CPU nb !! Nb cores / CPU !! Virtual CPU enabled !! Thread nb !! RAM !! HEP-SPEC06 32bits per System !! HEP-SPEC06 64bits per System ''' <br />
|-<br />
| Dell C6100 || E 5645 || 2.40 Ghz || 12 Mo || 2 CPU || 6 c || YES || 24 [1] || 48Go || bgcolor="#0066FF" | 181.13 || bgcolor="#0066FF" | 199.64<br />
|- <br />
|}<br />
<br />
<br />
[1] Nous avons configuré 20 job slots pour 24 coeurs virtuels<br />
----<br />
<br />
==== Benchs réalisés au CC-IN2P3 : ====<br />
<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | System !! Processor !! Frequency !! CPU nb !! Nb cores / CPU !! Virtual CPU enabled !! Thread nb !! RAM !! HEP-SPEC06 32bits per System !! Comment ''' <br />
|-<br />
| Dell C6220 || Intel Xeon E5-2680v2 || 2.8 Ghz || 2 CPU || 10 c || YES || 40 (HT ON) || 128 Go || bgcolor="#0066FF" | 454 || HS06 measured with 40 vcpus HT ON<br />
|- <br />
|}<br />
<br />
<br />
----<br />
<br />
=== Résultats des benchs GRIDPP (UK) === <br />
* http://www.gridpp.ac.uk/wiki/HEPSPEC06</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Storage-Benches&diff=8026
Storage-Benches
2016-09-22T06:11:55Z
<p>Barbet: /* Procedures */</p>
<hr />
<div>Storage benchmarking and [[TCP-Tuning|tuning]] depends upon several parameters like file systems, kernel parameters, RAID configuration, network parameters, etc. This page aims to provide benchmarking tools and procedures for LCG Storage Element, as well as some results for particular hardware solutions.<br />
<br />
= Tools =<br />
<br />
The XIO software developed at CC-IN2P3 have been used to bench the storage. A presentation of this tool has been given in [https://indico.in2p3.fr/event/4340/session/2/contribution/3/material/slides/0.pdf this talk]. Now it is advised to move to [http://git.kernel.dk/cgit/fio/tree/README FIO] with a set of agreed parameters (work in progress).<br />
<br />
= Procedures =<br />
<br />
* Describe the hardware<br />
* Indicate filesystem options (at filesystem creation and mount options)<br />
* Indicate System parameters regarding I/O<br />
* Execute each test 3 times, report the average and standard deviation<br />
* For each test report FIO parameters<br />
* Publish your result (format to be defined) with date and person to contact<br />
<br />
= Results =<br />
<br />
* [https://indico.in2p3.fr/event/11617/session/5/contribution/30/material/slides/0.pdf DELL R730xd with 6TB disks] with XIO<br />
* [https://indico.in2p3.fr/event/11973/session/10/contribution/27/material/slides/0.pdf DELL R730xd with 8TB disks] with XIO<br />
<br />
= External links =<br />
<br />
[http://git.kernel.dk/cgit/fio/tree/README FIO]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Storage-Benches&diff=8025
Storage-Benches
2016-09-22T06:07:21Z
<p>Barbet: /* External links */</p>
<hr />
<div>Storage benchmarking and [[TCP-Tuning|tuning]] depends upon several parameters like file systems, kernel parameters, RAID configuration, network parameters, etc. This page aims to provide benchmarking tools and procedures for LCG Storage Element, as well as some results for particular hardware solutions.<br />
<br />
= Tools =<br />
<br />
The XIO software developed at CC-IN2P3 have been used to bench the storage. A presentation of this tool has been given in [https://indico.in2p3.fr/event/4340/session/2/contribution/3/material/slides/0.pdf this talk]. Now it is advised to move to [http://git.kernel.dk/cgit/fio/tree/README FIO] with a set of agreed parameters (work in progress).<br />
<br />
= Procedures =<br />
<br />
= Results =<br />
<br />
* [https://indico.in2p3.fr/event/11617/session/5/contribution/30/material/slides/0.pdf DELL R730xd with 6TB disks] with XIO<br />
* [https://indico.in2p3.fr/event/11973/session/10/contribution/27/material/slides/0.pdf DELL R730xd with 8TB disks] with XIO<br />
<br />
= External links =<br />
<br />
[http://git.kernel.dk/cgit/fio/tree/README FIO]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Storage-Benches&diff=8024
Storage-Benches
2016-09-22T06:06:37Z
<p>Barbet: /* Results */</p>
<hr />
<div>Storage benchmarking and [[TCP-Tuning|tuning]] depends upon several parameters like file systems, kernel parameters, RAID configuration, network parameters, etc. This page aims to provide benchmarking tools and procedures for LCG Storage Element, as well as some results for particular hardware solutions.<br />
<br />
= Tools =<br />
<br />
The XIO software developed at CC-IN2P3 have been used to bench the storage. A presentation of this tool has been given in [https://indico.in2p3.fr/event/4340/session/2/contribution/3/material/slides/0.pdf this talk]. Now it is advised to move to [http://git.kernel.dk/cgit/fio/tree/README FIO] with a set of agreed parameters (work in progress).<br />
<br />
= Procedures =<br />
<br />
= Results =<br />
<br />
* [https://indico.in2p3.fr/event/11617/session/5/contribution/30/material/slides/0.pdf DELL R730xd with 6TB disks] with XIO<br />
* [https://indico.in2p3.fr/event/11973/session/10/contribution/27/material/slides/0.pdf DELL R730xd with 8TB disks] with XIO<br />
<br />
= External links =</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Storage-Benches&diff=8023
Storage-Benches
2016-09-22T06:05:56Z
<p>Barbet: /* Tools */</p>
<hr />
<div>Storage benchmarking and [[TCP-Tuning|tuning]] depends upon several parameters like file systems, kernel parameters, RAID configuration, network parameters, etc. This page aims to provide benchmarking tools and procedures for LCG Storage Element, as well as some results for particular hardware solutions.<br />
<br />
= Tools =<br />
<br />
The XIO software developed at CC-IN2P3 have been used to bench the storage. A presentation of this tool has been given in [https://indico.in2p3.fr/event/4340/session/2/contribution/3/material/slides/0.pdf this talk]. Now it is advised to move to [http://git.kernel.dk/cgit/fio/tree/README FIO] with a set of agreed parameters (work in progress).<br />
<br />
= Procedures =<br />
<br />
= Results =<br />
<br />
* [https://indico.in2p3.fr/event/11617/session/5/contribution/30/material/slides/0.pdf DELL R730xd with 6TB disks]<br />
* [https://indico.in2p3.fr/event/11973/session/10/contribution/27/material/slides/0.pdf DELL R730xd with 8TB disks]<br />
<br />
= External links =</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Alice&diff=7902
Alice
2016-04-27T06:17:39Z
<p>Barbet: /* Alice T1/T2 Workshops */</p>
<hr />
<div>== ''Bienvenue sur la page Alice LCG-France <br><br> Welcome to the LCG-France Alice page'' ==<br />
<br />
* Alice computing Representative : Renaud Vernet<br />
* Alice Web site : http://aliceinfo.cern.ch/<br />
* Alice Monitoring : http://alimonitor.cern.ch<br />
* Tier-1 site: CCIN2P3<br />
* Tier-2 sites : Subatech Nantes, IPHC Strasbourg, IPN Orsay and IRFU (GRIF), LPC Clermont, CCIN2P3, LPSC Grenoble<br />
* Tier-3 sites : IPN Lyon<br />
<br />
<br />
==== [[Alice:Communication| Alice Communication VO/Sites]] ====<br />
<br />
* VO Alice ID Card : https://cic.gridops.org/index.php?section=vo<br />
* Alice LCG Task Force<br />
* Liste de diffusion : alice-lcg-task-force@cern.ch<br />
* AliEn WiKi : http://alien2.cern.ch<br />
<br />
==== [[Alice:Communication| Alice T1/T2 Workshops]] ====<br />
<br />
* CERN 26-27 Mai 2009 http://indico.cern.ch/event/58444/<br />
* Karlsruhe 24-26 Janvier 2012 https://indico.cern.ch/event/157585/<br />
* Lyon 4-6 Juin 2013 https://indico.in2p3.fr/event/8114/<br />
* Tsukuba 3-8 Mars 2014 https://indico.cern.ch/event/274974/overview<br />
* Torino 23-25 Février 2015 https://indico.cern.ch/event/354209/overview<br />
* Bergen 18-20 Avril 2016 https://indico.cern.ch/event/485835/<br />
<br />
==== [[Alice:Vobox| Alice Vobox]] ====<br />
Il faut commencer par installer une machine LCG en VOBOX (meta-package YAIM)<br />
et vérifier que sur cette machine on dispose de toutes les fonctionnalités d'une UI<br />
LCG (soumission de jobs).<br />
<br />
Voir cette doc :<br />
http://alien2.cern.ch/index.php?option=com_content&view=article&id=21&Itemid=67<br />
<br />
Il existe un script permettant de tester les fonctions LCG nécessaires<br />
avant d'installer AliEn.<br />
<br />
<strike>Il faut installer un LFC local (sur la VOBOX ou ailleurs).</strike><br />
(màj début 2007 : Ce n'est plus nécessaire d'installer un LFC sur la VOBOX).<br />
<br />
Il faut ensuite installer AliEn. Cela se fait en récupérant un<br />
"installer" : un script shell qui va se charger de récupérer<br />
les packages et les installer<br />
<pre><br />
wget alien.cern.ch/alien-installer<br />
</pre><br />
<br />
Il faut aussi s'enregister auprès de la VO Alice (fournir le DN de son <br />
certificat) et demander le rôle alicesgm :<br />
http://alien.cern.ch/twiki/bin/view/Alice/UserRegistration<br />
<br />
AliEn se compose de plusieurs demons ou "services" :<br />
<br />
- Monitor<br />
- CE<br />
- CMreport<br />
- MonaLisa<br />
<br />
Home WiKi ALiEn :<br />
http://alien2.cern.ch<br />
<br />
Il y a pas mal de trous à faire dans le firewall:<br />
<br />
[https://twiki.cern.ch/twiki/pub/LCG/VoBoxesInfo/VO-Box-security-policy_v05.doc Security Policy]<br />
<br />
<br />
--[[Utilisateur:Barbet|Barbet]] 14 Octobre 2015 à 10:11 (CEST)*</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Alice&diff=7844
Alice
2016-04-05T06:07:00Z
<p>Barbet: /* Bienvenue sur la page Alice LCG-France Welcome to the LCG-France Alice page */</p>
<hr />
<div>== ''Bienvenue sur la page Alice LCG-France <br><br> Welcome to the LCG-France Alice page'' ==<br />
<br />
* Alice computing Representative : Renaud Vernet<br />
* Alice Web site : http://aliceinfo.cern.ch/<br />
* Alice Monitoring : http://alimonitor.cern.ch<br />
* Tier-1 site: CCIN2P3<br />
* Tier-2 sites : Subatech Nantes, IPHC Strasbourg, IPN Orsay and IRFU (GRIF), LPC Clermont, CCIN2P3, LPSC Grenoble<br />
* Tier-3 sites : IPN Lyon<br />
<br />
<br />
==== [[Alice:Communication| Alice Communication VO/Sites]] ====<br />
<br />
* VO Alice ID Card : https://cic.gridops.org/index.php?section=vo<br />
* Alice LCG Task Force<br />
* Liste de diffusion : alice-lcg-task-force@cern.ch<br />
* AliEn WiKi : http://alien2.cern.ch<br />
<br />
==== [[Alice:Communication| Alice T1/T2 Workshops]] ====<br />
<br />
* CERN 26-27 Mai 2009 http://indico.cern.ch/event/58444/<br />
* Karlsruhe 24-26 Janvier 2012 https://indico.cern.ch/event/157585/<br />
* Lyon 4-6 Juin 2013 https://indico.in2p3.fr/event/8114/<br />
* Tsukuba 3-8 Mars 2014 https://indico.cern.ch/event/274974/overview<br />
* Torino 23-25 Février 2015 https://indico.cern.ch/event/354209/overview<br />
<br />
==== [[Alice:Vobox| Alice Vobox]] ====<br />
Il faut commencer par installer une machine LCG en VOBOX (meta-package YAIM)<br />
et vérifier que sur cette machine on dispose de toutes les fonctionnalités d'une UI<br />
LCG (soumission de jobs).<br />
<br />
Voir cette doc :<br />
http://alien2.cern.ch/index.php?option=com_content&view=article&id=21&Itemid=67<br />
<br />
Il existe un script permettant de tester les fonctions LCG nécessaires<br />
avant d'installer AliEn.<br />
<br />
<strike>Il faut installer un LFC local (sur la VOBOX ou ailleurs).</strike><br />
(màj début 2007 : Ce n'est plus nécessaire d'installer un LFC sur la VOBOX).<br />
<br />
Il faut ensuite installer AliEn. Cela se fait en récupérant un<br />
"installer" : un script shell qui va se charger de récupérer<br />
les packages et les installer<br />
<pre><br />
wget alien.cern.ch/alien-installer<br />
</pre><br />
<br />
Il faut aussi s'enregister auprès de la VO Alice (fournir le DN de son <br />
certificat) et demander le rôle alicesgm :<br />
http://alien.cern.ch/twiki/bin/view/Alice/UserRegistration<br />
<br />
AliEn se compose de plusieurs demons ou "services" :<br />
<br />
- Monitor<br />
- CE<br />
- CMreport<br />
- MonaLisa<br />
<br />
Home WiKi ALiEn :<br />
http://alien2.cern.ch<br />
<br />
Il y a pas mal de trous à faire dans le firewall:<br />
<br />
[https://twiki.cern.ch/twiki/pub/LCG/VoBoxesInfo/VO-Box-security-policy_v05.doc Security Policy]<br />
<br />
<br />
--[[Utilisateur:Barbet|Barbet]] 14 Octobre 2015 à 10:11 (CEST)*</div>
Barbet
https://lcg.in2p3.fr/index.php?title=HT-Condor&diff=7737
HT-Condor
2016-03-16T09:15:52Z
<p>Barbet: /* Utilisation en contexte grille */</p>
<hr />
<div>Démarrer avec HT-Condor<br />
=== Démarrer avec HT-Condor ===<br />
<br />
[Page en cours de création]<br />
<br />
==== Documentation et références ====<br />
<br />
Site de référence : http://research.cs.wisc.edu/htcondor/<br />
<br />
Wiki : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki<br />
<br />
Recettes Administrateur : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToAdminRecipes<br />
<br />
Manuel (version stable 8.2) : http://research.cs.wisc.edu/htcondor/manual/v8.2/index.html<br />
<br />
European HTCondor Site Admins Meeting 2014 : http://indico.cern.ch/event/272794/<br />
<br />
Workshop HT-Condor / ARC-CE, Cerdanyola-del-Vallès, 2016 : https://indico.cern.ch/event/467075/<br />
<br />
==== Repositories et installation ====<br />
<br />
http://research.cs.wisc.edu/htcondor/yum/<br />
<br />
<tt><br />
cd /etc/yum.repos.d/<br />
wget http://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel6.repo<br />
yum install condor<br />
</tt><br />
<br />
Attention: condor est aussi distribué via les repositories UMD, il peut être nécessaire de désactiver ces repositories ou bien d'utiliser les priorités avec YUM.<br />
<br />
==== Installation personnelle : configuration et premiers tests ====<br />
<br />
La configuration par défaut après l'installation du RPM permet de tester le produit sur une seule machine. Dans ce cas, sur la même machine, on trouve les trois types de noeuds : <i>submit node</i>, <i>master node</i> et <i>worker node</i>.<br />
<br />
Démarrer les demons :<br />
<br />
<tt><br />
service condor start<br />
Starting up Condor... done.<br />
<br />
service condor status<br />
Condor is running (pid 22310)<br />
</tt><br />
Les processus suivants sont lancés :<br />
<tt><br />
ps -ef | grep condor<br />
condor 22310 1 0 09:52 ? 00:00:00 /usr/sbin/condor_master -pidfile /var/run/condor/condor.pid<br />
root 22311 22310 0 09:52 ? 00:00:00 condor_procd -A /var/run/condor/procd_pipe -L /var/log/condor/ProcLog -R 1000000 -S 60 -C 493<br />
condor 22312 22310 0 09:52 ? 00:00:00 condor_collector -f<br />
condor 22314 22310 0 09:52 ? 00:00:00 condor_negotiator -f<br />
condor 22315 22310 0 09:52 ? 00:00:00 condor_schedd -f<br />
condor 22316 22310 0 09:52 ? 00:00:00 condor_startd -f<br />
condor 22359 22316 93 09:53 ? 00:00:11 mips<br />
</tt><br />
<br />
En ce qui concerne le demon qui gère un worker node (condor_startd), les processeurs disponibles sue la machine locale sont bien reconnus :<br />
<br />
<tt><br />
condor_status<br />
Name OpSys Arch State Activity LoadAv Mem ActvtyTime<br />
<br />
slot1@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:30:11<br />
slot2@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.030 1949 0+00:50:05<br />
slot3@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:06<br />
slot4@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:07<br />
Total Owner Claimed Unclaimed Matched Preempting Backfill<br />
<br />
X86_64/LINUX 4 0 0 4 0 0 0<br />
<br />
Total 4 0 0 4 0 0 0<br />
</tt><br />
<br />
Créer un programme de test (un script shell lançant des exécutables) :<br />
<br />
<tt><br />
more HT-Condor/testprog01.sh<br />
#! /bin/sh<br />
echo "HT-condor testprog01"<br />
echo "I'm process id $$ on" `hostname`<br />
echo "This is sent to standard error" 1>&2<br />
date<br />
echo "Running as binary $0" "$@"<br />
echo "My name (argument 1) is $1"<br />
echo "My sleep duration (argument 2) is $2"<br />
sleep $2<br />
echo "Sleep of $2 seconds finished. Exiting"<br />
exit 0<br />
</tt><br />
<br />
Créer la description du travail :<br />
<br />
<tt><br />
executable=testprog01.sh<br />
universe=vanilla<br />
arguments=Example.$(Cluster).$(Process) 100<br />
output=results.output.$(Process)<br />
error=results.error.$(Process)<br />
log=results.log<br />
notification=never<br />
should_transfer_files=YES<br />
when_to_transfer_output = ON_EXIT<br />
queue<br />
</tt><br />
<br />
Lancer le job :<br />
<br />
<tt><br />
condor_submit testprog01.submit <br />
Submitting job(s).<br />
1 job(s) submitted to cluster 1.<br />
</tt><br />
<br />
En surveiller l'exécution :<br />
<br />
<tt><br />
condor_q<br />
<br />
-- Submitter: nanpc117.in2p3.fr : <134.158.25.117:39976> : nanpc117.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
1.0 untel 8/4 09:57 0+00:00:05 R 0 0.0 testprog01.sh Exam<br />
<br />
1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended<br />
</tt><br />
<br />
Fin du job : les fichiers demandés sont là :<br />
<br />
<tt><br />
ls<br />
results.error.0 results.output.0 testprog01.submit<br />
results.log testprog01.sh<br />
</tt><br />
<br />
==== Installation type cluster local ====<br />
<br />
Le cluster de compose de : <br />
<br />
* une machine qui joue le rôle de serveur de batch (demons : condor_master, condor_collector, condor_negotiator)<br />
* une ou plusieurs machines pouvant soumettre des travaux (demon : condor_shedd) <br />
* les machines devant exécuter les travaux (worker nodes) (demons : )<br />
<br />
On installe le même RPM partout (comme ci-dessus) et c'est via les fichiers de configuration dans le répertoire /etc/condor que les machines vont jouer un rôle différent.<br />
Il est recommandé de ne jamais modifier le fichier /etc/condor/condor_config mais de surcharger la config par un fichier /etc/condor/condor_config.local ou mieux : un ensemble de fichiers dans /etc/condor/config.d<br />
Le fichier peut être le même pour toutes les machines et les différences exprimées avec des fichiers dans /etc/condor/config.d.<br />
<br />
Exemple de fichier global /etc/condor/condor_config.local :<br />
<br />
<tt><br />
# 0-General-Settings-and-Macros<br />
<br />
UID_DOMAIN = htcondor-grid@subatech.in2p3.fr<br />
CENTRAL_MANAGER1 = nanpbs3.in2p3.fr<br />
COLLECTOR_HOST = $(CENTRAL_MANAGER1)<br />
CONDOR_HOST=$(CENTRAL_MANAGER1)<br />
<br />
EVENT_LOG = EventLog<br />
<br />
# 1-Use-Security<br />
<br />
# 2-Policies<br />
<br />
SEC_DEFAULT_AUTHENTICATION = REQUIRED<br />
<br />
# 3-Authorizations<br />
<br />
ALLOW_WRITE = <br />
ALLOW_READ = */*.in2p3.fr<br />
ALLOW_DAEMON = *.in2p3.fr<br />
ALLOW_ADMINISTRATOR = root@$(CONDOR_HOST)<br />
ALLOW_CONFIG = root@$(FULL_HOSTNAME)<br />
<br />
# 4-Authentication<br />
SEC_PASSWORD_FILE = /etc/condor/pool_password<br />
SEC_READ_AUTHENTICATION = OPTIONAL<br />
SEC_CLIENT_AUTHENTICATION = REQUIRED<br />
SEC_DEFAULT_AUTHENTICATION_METHODS = PASSWORD,FS<br />
SCHEDD.SEC_WRITE_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SCHEDD.SEC_DAEMON_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SEC_CLIENT_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
SEC_READ_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
</tt><br />
<br />
Le modèle de sécurité choisi ici repose sur le partage d'une clé commune entre les différentes machines (submitter,master,workers). Cette clé /etc/condor/pool_password est crée par la commande suivante et distribuée sur les machines :<br />
<br />
<tt><br />
condor_store_cred -f /etc/condor/pool_password<br />
Enter password: xxxxxx<br />
</tt><br />
<br />
Ce modèle est assez simple et n'apporte que l'authentification entre demons, pas le chiffrement et le contrôle de l'intégrité des communications.<br />
<br />
<br />
===== Configuration du serveur de batch (nanpbs3.in2p3.fr) =====<br />
<br />
Dans cet exemple, le serveur de batch est aussi machine de soumission (il dispose des mêmes comptes que sur les worker nodes)<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/20-master.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = COLLECTOR, MASTER, NEGOTIATOR, SCHEDD<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
</tt><br />
<br />
===== Configuration d'un worker node (nanwn58.in2p3.fr) =====<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/10-workernode.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = MASTER, STARTD<br />
TRUST_UID_DOMAIN=TRUE<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
DaemonMaster None nanwn58.in2p3.fr <br />
Machine Job slot1@nanwn58.in2p3.fr <br />
Machine Job slot2@nanwn58.in2p3.fr <br />
Machine Job slot3@nanwn58.in2p3.fr <br />
Machine Job slot4@nanwn58.in2p3.fr <br />
Machine Job slot5@nanwn58.in2p3.fr <br />
Machine Job slot6@nanwn58.in2p3.fr <br />
Machine Job slot7@nanwn58.in2p3.fr <br />
Machine Job slot8@nanwn58.in2p3.fr <br />
</tt><br />
<br />
Examen de la queue depuis le server et submitter :<br />
<tt><br />
[root@nanpbs3 ~]# condor_q<br />
<br />
<br />
-- Submitter: nanpbs3.in2p3.fr : <193.48.101.50:58431> : nanpbs3.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
<br />
0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended<br />
</tt><br />
<br />
===== Réseaux privés, ports de communication, Pares-Feu =====<br />
<br />
Lorsque HTCondor est réparti sur plusieurs machines, rien de spécial n'est à faire si toutes sont situées dans le même réseau.<br />
Par contre, dans le cas ou elles sont isolées par des pares-feu ou autres, il faut faire ouvrir les ports utilisés par Condor. Dans le cas d'un tout petit cluster (1 CM avec Collecteur , Negotiateur et Scheduleur et 2 workers), il suffit d'autoriser l'écriture, d'ouvrir un intervalle de ports et les définir dans le fichier de configuration de condor (condor_config.local par exemple).<br />
<br />
<tt><br />
# To expand your condor pool beyond a single host, set ALLOW_WRITE to match all of the hosts (last one is ccgr2 Mac)<br />
ALLOW_WRITE = $(ALLOW_WRITE) ,$(CONDOR_HOST) , worker1, worker2, ......<br />
Define the ports used by condor<br />
#NEGOTIATOR_SOCKET_CACHE_SIZE = 16<br />
LOWPORT = 9600<br />
HIGHPORT= 9625 <br />
</tt><br />
En fait, le nombre de ports à ouvrir est de 21 au minimum (5 pour la communication avec les daemons et 16 pour le "negotiator_socket_cache_size" mais il doit augmenter avec la taille du cluster.Pour ce qui est d'une information plus détaillée sur les différents ports utilisés par Condor et réseaux: http://www.wolftech.ncsu.edu/support/support/Condor/Firewall<br />
<br />
Un exemple d'ouverture de ports entre ma VM qui est le CM et mon MAC qui est un de mes worker-nodes:<br />
<tt><br />
- en entree vers mon mac :<br />
permit tcp host 172.xxx host 134.yyy range 9600 9625<br />
permit udp host 172.xxxx host 134.yyy range 9600 9625<br />
-en entree vers le serveur condor :<br />
permit tcp host 134.yyy host 172.xxx range 9600 9625<br />
permit udp host 134.yyy host 172.xxx range 9600 9625<br />
</tt><br />
<br />
===== Gestion des ressources, priorités et comptabilité (accounting) =====<br />
<br />
Dans le cadre d'un cluster local, c'est l'utilisateur qui définit lui-même le groupe auxquel il appartient via une instruction de type ClassAd dans son fichier .submit. Exemple :<br />
<tt><br />
# accounting group<br />
accounting_group = group_info<br />
</tt><br />
<br />
... A développer ...<br />
<br />
==== Utilisation en contexte grille ====<br />
<br />
Sauf en cas de soumission directe au système de batch local, il faudra installer un Computing-Element (CE). Les CE disponibles actuellement et capables de soumettre à un pool HT-Condor sont :<br />
<br />
* CREAM-CE<br />
* ARC-CE<br />
* HT-Condor-CE<br />
<br />
==== Sécurité ====</div>
Barbet
https://lcg.in2p3.fr/index.php?title=HT-Condor&diff=7736
HT-Condor
2016-03-16T09:11:14Z
<p>Barbet: /* Documentation et références */</p>
<hr />
<div>Démarrer avec HT-Condor<br />
=== Démarrer avec HT-Condor ===<br />
<br />
[Page en cours de création]<br />
<br />
==== Documentation et références ====<br />
<br />
Site de référence : http://research.cs.wisc.edu/htcondor/<br />
<br />
Wiki : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki<br />
<br />
Recettes Administrateur : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToAdminRecipes<br />
<br />
Manuel (version stable 8.2) : http://research.cs.wisc.edu/htcondor/manual/v8.2/index.html<br />
<br />
European HTCondor Site Admins Meeting 2014 : http://indico.cern.ch/event/272794/<br />
<br />
Workshop HT-Condor / ARC-CE, Cerdanyola-del-Vallès, 2016 : https://indico.cern.ch/event/467075/<br />
<br />
==== Repositories et installation ====<br />
<br />
http://research.cs.wisc.edu/htcondor/yum/<br />
<br />
<tt><br />
cd /etc/yum.repos.d/<br />
wget http://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel6.repo<br />
yum install condor<br />
</tt><br />
<br />
Attention: condor est aussi distribué via les repositories UMD, il peut être nécessaire de désactiver ces repositories ou bien d'utiliser les priorités avec YUM.<br />
<br />
==== Installation personnelle : configuration et premiers tests ====<br />
<br />
La configuration par défaut après l'installation du RPM permet de tester le produit sur une seule machine. Dans ce cas, sur la même machine, on trouve les trois types de noeuds : <i>submit node</i>, <i>master node</i> et <i>worker node</i>.<br />
<br />
Démarrer les demons :<br />
<br />
<tt><br />
service condor start<br />
Starting up Condor... done.<br />
<br />
service condor status<br />
Condor is running (pid 22310)<br />
</tt><br />
Les processus suivants sont lancés :<br />
<tt><br />
ps -ef | grep condor<br />
condor 22310 1 0 09:52 ? 00:00:00 /usr/sbin/condor_master -pidfile /var/run/condor/condor.pid<br />
root 22311 22310 0 09:52 ? 00:00:00 condor_procd -A /var/run/condor/procd_pipe -L /var/log/condor/ProcLog -R 1000000 -S 60 -C 493<br />
condor 22312 22310 0 09:52 ? 00:00:00 condor_collector -f<br />
condor 22314 22310 0 09:52 ? 00:00:00 condor_negotiator -f<br />
condor 22315 22310 0 09:52 ? 00:00:00 condor_schedd -f<br />
condor 22316 22310 0 09:52 ? 00:00:00 condor_startd -f<br />
condor 22359 22316 93 09:53 ? 00:00:11 mips<br />
</tt><br />
<br />
En ce qui concerne le demon qui gère un worker node (condor_startd), les processeurs disponibles sue la machine locale sont bien reconnus :<br />
<br />
<tt><br />
condor_status<br />
Name OpSys Arch State Activity LoadAv Mem ActvtyTime<br />
<br />
slot1@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:30:11<br />
slot2@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.030 1949 0+00:50:05<br />
slot3@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:06<br />
slot4@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:07<br />
Total Owner Claimed Unclaimed Matched Preempting Backfill<br />
<br />
X86_64/LINUX 4 0 0 4 0 0 0<br />
<br />
Total 4 0 0 4 0 0 0<br />
</tt><br />
<br />
Créer un programme de test (un script shell lançant des exécutables) :<br />
<br />
<tt><br />
more HT-Condor/testprog01.sh<br />
#! /bin/sh<br />
echo "HT-condor testprog01"<br />
echo "I'm process id $$ on" `hostname`<br />
echo "This is sent to standard error" 1>&2<br />
date<br />
echo "Running as binary $0" "$@"<br />
echo "My name (argument 1) is $1"<br />
echo "My sleep duration (argument 2) is $2"<br />
sleep $2<br />
echo "Sleep of $2 seconds finished. Exiting"<br />
exit 0<br />
</tt><br />
<br />
Créer la description du travail :<br />
<br />
<tt><br />
executable=testprog01.sh<br />
universe=vanilla<br />
arguments=Example.$(Cluster).$(Process) 100<br />
output=results.output.$(Process)<br />
error=results.error.$(Process)<br />
log=results.log<br />
notification=never<br />
should_transfer_files=YES<br />
when_to_transfer_output = ON_EXIT<br />
queue<br />
</tt><br />
<br />
Lancer le job :<br />
<br />
<tt><br />
condor_submit testprog01.submit <br />
Submitting job(s).<br />
1 job(s) submitted to cluster 1.<br />
</tt><br />
<br />
En surveiller l'exécution :<br />
<br />
<tt><br />
condor_q<br />
<br />
-- Submitter: nanpc117.in2p3.fr : <134.158.25.117:39976> : nanpc117.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
1.0 untel 8/4 09:57 0+00:00:05 R 0 0.0 testprog01.sh Exam<br />
<br />
1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended<br />
</tt><br />
<br />
Fin du job : les fichiers demandés sont là :<br />
<br />
<tt><br />
ls<br />
results.error.0 results.output.0 testprog01.submit<br />
results.log testprog01.sh<br />
</tt><br />
<br />
==== Installation type cluster local ====<br />
<br />
Le cluster de compose de : <br />
<br />
* une machine qui joue le rôle de serveur de batch (demons : condor_master, condor_collector, condor_negotiator)<br />
* une ou plusieurs machines pouvant soumettre des travaux (demon : condor_shedd) <br />
* les machines devant exécuter les travaux (worker nodes) (demons : )<br />
<br />
On installe le même RPM partout (comme ci-dessus) et c'est via les fichiers de configuration dans le répertoire /etc/condor que les machines vont jouer un rôle différent.<br />
Il est recommandé de ne jamais modifier le fichier /etc/condor/condor_config mais de surcharger la config par un fichier /etc/condor/condor_config.local ou mieux : un ensemble de fichiers dans /etc/condor/config.d<br />
Le fichier peut être le même pour toutes les machines et les différences exprimées avec des fichiers dans /etc/condor/config.d.<br />
<br />
Exemple de fichier global /etc/condor/condor_config.local :<br />
<br />
<tt><br />
# 0-General-Settings-and-Macros<br />
<br />
UID_DOMAIN = htcondor-grid@subatech.in2p3.fr<br />
CENTRAL_MANAGER1 = nanpbs3.in2p3.fr<br />
COLLECTOR_HOST = $(CENTRAL_MANAGER1)<br />
CONDOR_HOST=$(CENTRAL_MANAGER1)<br />
<br />
EVENT_LOG = EventLog<br />
<br />
# 1-Use-Security<br />
<br />
# 2-Policies<br />
<br />
SEC_DEFAULT_AUTHENTICATION = REQUIRED<br />
<br />
# 3-Authorizations<br />
<br />
ALLOW_WRITE = <br />
ALLOW_READ = */*.in2p3.fr<br />
ALLOW_DAEMON = *.in2p3.fr<br />
ALLOW_ADMINISTRATOR = root@$(CONDOR_HOST)<br />
ALLOW_CONFIG = root@$(FULL_HOSTNAME)<br />
<br />
# 4-Authentication<br />
SEC_PASSWORD_FILE = /etc/condor/pool_password<br />
SEC_READ_AUTHENTICATION = OPTIONAL<br />
SEC_CLIENT_AUTHENTICATION = REQUIRED<br />
SEC_DEFAULT_AUTHENTICATION_METHODS = PASSWORD,FS<br />
SCHEDD.SEC_WRITE_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SCHEDD.SEC_DAEMON_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SEC_CLIENT_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
SEC_READ_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
</tt><br />
<br />
Le modèle de sécurité choisi ici repose sur le partage d'une clé commune entre les différentes machines (submitter,master,workers). Cette clé /etc/condor/pool_password est crée par la commande suivante et distribuée sur les machines :<br />
<br />
<tt><br />
condor_store_cred -f /etc/condor/pool_password<br />
Enter password: xxxxxx<br />
</tt><br />
<br />
Ce modèle est assez simple et n'apporte que l'authentification entre demons, pas le chiffrement et le contrôle de l'intégrité des communications.<br />
<br />
<br />
===== Configuration du serveur de batch (nanpbs3.in2p3.fr) =====<br />
<br />
Dans cet exemple, le serveur de batch est aussi machine de soumission (il dispose des mêmes comptes que sur les worker nodes)<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/20-master.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = COLLECTOR, MASTER, NEGOTIATOR, SCHEDD<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
</tt><br />
<br />
===== Configuration d'un worker node (nanwn58.in2p3.fr) =====<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/10-workernode.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = MASTER, STARTD<br />
TRUST_UID_DOMAIN=TRUE<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
DaemonMaster None nanwn58.in2p3.fr <br />
Machine Job slot1@nanwn58.in2p3.fr <br />
Machine Job slot2@nanwn58.in2p3.fr <br />
Machine Job slot3@nanwn58.in2p3.fr <br />
Machine Job slot4@nanwn58.in2p3.fr <br />
Machine Job slot5@nanwn58.in2p3.fr <br />
Machine Job slot6@nanwn58.in2p3.fr <br />
Machine Job slot7@nanwn58.in2p3.fr <br />
Machine Job slot8@nanwn58.in2p3.fr <br />
</tt><br />
<br />
Examen de la queue depuis le server et submitter :<br />
<tt><br />
[root@nanpbs3 ~]# condor_q<br />
<br />
<br />
-- Submitter: nanpbs3.in2p3.fr : <193.48.101.50:58431> : nanpbs3.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
<br />
0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended<br />
</tt><br />
<br />
===== Réseaux privés, ports de communication, Pares-Feu =====<br />
<br />
Lorsque HTCondor est réparti sur plusieurs machines, rien de spécial n'est à faire si toutes sont situées dans le même réseau.<br />
Par contre, dans le cas ou elles sont isolées par des pares-feu ou autres, il faut faire ouvrir les ports utilisés par Condor. Dans le cas d'un tout petit cluster (1 CM avec Collecteur , Negotiateur et Scheduleur et 2 workers), il suffit d'autoriser l'écriture, d'ouvrir un intervalle de ports et les définir dans le fichier de configuration de condor (condor_config.local par exemple).<br />
<br />
<tt><br />
# To expand your condor pool beyond a single host, set ALLOW_WRITE to match all of the hosts (last one is ccgr2 Mac)<br />
ALLOW_WRITE = $(ALLOW_WRITE) ,$(CONDOR_HOST) , worker1, worker2, ......<br />
Define the ports used by condor<br />
#NEGOTIATOR_SOCKET_CACHE_SIZE = 16<br />
LOWPORT = 9600<br />
HIGHPORT= 9625 <br />
</tt><br />
En fait, le nombre de ports à ouvrir est de 21 au minimum (5 pour la communication avec les daemons et 16 pour le "negotiator_socket_cache_size" mais il doit augmenter avec la taille du cluster.Pour ce qui est d'une information plus détaillée sur les différents ports utilisés par Condor et réseaux: http://www.wolftech.ncsu.edu/support/support/Condor/Firewall<br />
<br />
Un exemple d'ouverture de ports entre ma VM qui est le CM et mon MAC qui est un de mes worker-nodes:<br />
<tt><br />
- en entree vers mon mac :<br />
permit tcp host 172.xxx host 134.yyy range 9600 9625<br />
permit udp host 172.xxxx host 134.yyy range 9600 9625<br />
-en entree vers le serveur condor :<br />
permit tcp host 134.yyy host 172.xxx range 9600 9625<br />
permit udp host 134.yyy host 172.xxx range 9600 9625<br />
</tt><br />
<br />
===== Gestion des ressources, priorités et comptabilité (accounting) =====<br />
<br />
Dans le cadre d'un cluster local, c'est l'utilisateur qui définit lui-même le groupe auxquel il appartient via une instruction de type ClassAd dans son fichier .submit. Exemple :<br />
<tt><br />
# accounting group<br />
accounting_group = group_info<br />
</tt><br />
<br />
... A développer ...<br />
<br />
==== Utilisation en contexte grille ====<br />
<br />
==== Sécurité ====</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Tier_2:Subatech&diff=7731
Tier 2:Subatech
2016-02-26T13:15:20Z
<p>Barbet: /* Ressources dédiées à LCG */</p>
<hr />
<div>Laboratoire SUBATECH - UMR<br />
CNRS/IN2P3-Ecole des Mines de Nantes-Université de Nantes<br />
http://www-subatech.in2p3.fr/<br />
<br><br />
[[Tier_2:Subatech |Version Française ]] | [[Tier_2:Subatech_en|English Version ]] <br />
<br />
Le laboratoire SUBATECH s'est engagé à participer en tant que centre de traitement "Tier-2" au stockage et à l'analyse des données issues de l'expérience ALICE au LHC.<br />
===== Ressources dédiées à LCG =====<br />
{| class="wikitable" style="text-align:center" border="1" cellpadding="5" cellspacing="0"<br />
|+<br />
|-<br />
! style="background:#efefef;" | Année !! 2005 [1]!! 2006 [1]!! 2007 [1]!! 2008 [2] !! 2009 [2] !! 2010 [3] !! 2011 [3] !! 2012 [3] !! 2013 [3] !! 2014 [3] !! 2015 [3] !! 2016 [3] !! au-delà<br />
|-<br />
! CPU (KSI2K)<br />
| 14 || 56 ||112 || 312 || 373 || - || - || - || - || - || - || - || à définir<br />
|-<br />
! CPU (SPEC-HEP06)<br />
| - || - || - || - || - || 2400 || 3000 || 3000 || 3000 || 3000 || 3000 || 4500 || à définir<br />
|-<br />
! Stockage (To) <br />
| 4,25 || 15,3 || 16 || 43 || 97 || 200 || 270 || 310 || 310 || 310 || 310 || 800 || à définir<br />
|-<br />
|}<br />
[1] : sur la base de 1CPU = 1,644 KSI2K <br />
<br />
[2] : en KSI2K CERN conformément à [[http://www.cern.ch/LCG/documents/Processor%20performance%20metrics_26may07.pdf CPU Capacity Metrics for WLCG]]<br />
<br />
[3] : SPEC-HEP06 : Nouvelle métrique <br />
<br />
Référence : http://gstat-wlcg.cern.ch/apps/pledges/resources/<br />
<br />
===== Personnes et moyens humains =====<br />
Responsable Scientifique : Laurent Aphecetche<br />
<br />
Responsable Technique : Jean-Michel Barbet<br />
<br />
Exploitation : Khalil Chawoshi (Chef du Service Informatique), Jean-Michel Barbet, Pierrick Le Corre, Jean Andrianavaly et Jérome Pinot.<br />
Les moyens humains dédiés à LCG représentent actuellement 1,2 ETP.<br />
<br />
===== Financement et partenaires =====<br />
Les achats ont étés réalisés avec les crédits du laboratoire avec l'aide de la Région des Pays-de-Loire.<br />
<br />
===== Technologies et savoir-faire =====<br />
Cluster local Scientific-Linux 6, OpenPBS. Quattor (worker nodes, disk servers), Puppet, YAIM (service nodes)<br />
<br />
Stockage : SAN, RAID5/6, xrootd, EOS<br />
<br />
Divers : Surveillance Nagios, Support: Request-Tracker (RT), Virtualisation: VMware, Elogger.<br />
<br />
===== Liens =====<br />
Site IN2P3-SUBATECH dans la GOCDB [https://goc.egi.eu/portal/index.php?Page_Type=View_Object&object_id=151&grid_id=0] <br />
<br />
Expérience ALICE au LHC [http://aliceinfo.cern.ch/Public]<br />
<br />
Carte AliEn [http://pcalimonitor.cern.ch:8889/show?page=index.html]<br />
<br />
Groupe Plasma à SUBATECH [http://www-subatech.in2p3.fr/%7Eplasma/index_plasma.html]</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Alice&diff=7517
Alice
2015-10-14T08:17:04Z
<p>Barbet: /* Bienvenue sur la page Alice LCG-France Welcome to the LCG-France Alice page */</p>
<hr />
<div>== ''Bienvenue sur la page Alice LCG-France <br><br> Welcome to the LCG-France Alice page'' ==<br />
<br />
* Alice computing Representative : Yves Schutz <br />
* Alice Web site : http://aliceinfo.cern.ch/<br />
* Alice Monitoring : http://pcalimonitor.cern.ch:8889/<br />
* Tier-1 site: CCIN2P3<br />
* Tier-2 sites : Subatech Nantes, IPHC Strasbourg, IPN Orsay and IRFU (GRIF), LPC Clermont, CCIN2P3, LPSC Grenoble<br />
* Tier-3 sites : IPN Lyon<br />
* Représentant de la Fédération des Tiers-2 auprès d'Alice : Laurent Aphecetche<br />
<br />
<br />
==== [[Alice:Communication| Alice Communication VO/Sites]] ====<br />
<br />
* VO Alice ID Card : https://cic.gridops.org/index.php?section=vo<br />
* Alice LCG Task Force<br />
* Liste de diffusion : alice-lcg-task-force@cern.ch<br />
* AliEn WiKi : http://alien.cern.ch/twiki/bin/view/AliEn/Home<br />
<br />
==== [[Alice:Communication| Alice T1/T2 Workshops]] ====<br />
<br />
* CERN 26-27 Mai 2009 http://indico.cern.ch/event/58444/<br />
* Karlsruhe 24-26 Janvier 2012 https://indico.cern.ch/event/157585/<br />
* Lyon 4-6 Juin 2013 https://indico.in2p3.fr/event/8114/<br />
* Tsukuba 3-8 Mars 2014 https://indico.cern.ch/event/274974/overview<br />
* Torino 23-25 Février 2015 https://indico.cern.ch/event/354209/overview<br />
<br />
==== [[Alice:Vobox| Alice Vobox]] ====<br />
Il faut commencer par installer une machine LCG en VOBOX (meta-package YAIM)<br />
et vérifier que sur cette machine on dispose de toutes les fonctionnalités d'une UI<br />
LCG (soumission de jobs).<br />
<br />
Voir cette doc :<br />
http://alien.cern.ch/twiki/bin/view/AliEn/HowToInstallLcgVoBox<br />
<br />
Il existe un script permettant de tester les fonctions LCG nécessaires<br />
avant d'installer AliEn.<br />
<br />
<strike>Il faut installer un LFC local (sur la VOBOX ou ailleurs).</strike><br />
(màj début 2007 : Ce n'est plus nécessaire d'installer un LFC sur la VOBOX).<br />
<br />
Il faut ensuite installer AliEn. Cela se fait en récupérant un<br />
"installer" : un script shell qui va se charger de récupérer<br />
les packages et les installer.<br />
<br />
Il faut aussi s'enregister auprès de la VO Alice (fournir le DN de son <br />
certificat) et demander le rôle alicesgm :<br />
http://alien.cern.ch/twiki/bin/view/Alice/UserRegistration<br />
<br />
AliEn se compose de plusieurs demons ou "services" :<br />
<br />
- Monitor<br />
- CE<br />
- CMreport<br />
- MonaLisa<br />
<br />
Home WiKi ALiEn :<br />
http://alien.cern.ch/twiki/bin/view/AliEn/Home<br />
<br />
Il y a pas mal de trous à faire dans le firewall:<br />
<br />
[https://twiki.cern.ch/twiki/pub/LCG/VoBoxesInfo/VO-Box-security-policy_v05.doc Security Policy]<br />
<br />
<br />
--[[Utilisateur:Barbet|Barbet]] 14 Octobre 2015 à 10:11 (CEST)*</div>
Barbet
https://lcg.in2p3.fr/index.php?title=Alice&diff=7516
Alice
2015-10-14T08:10:52Z
<p>Barbet: /* Bienvenue sur la page Alice LCG-France Welcome to the LCG-France Alice page */</p>
<hr />
<div>== ''Bienvenue sur la page Alice LCG-France <br><br> Welcome to the LCG-France Alice page'' ==<br />
<br />
* Alice computing Representative : Yves Schutz <br />
* Alice Web site : http://aliceinfo.cern.ch/<br />
* Alice Monitoring : http://pcalimonitor.cern.ch:8889/<br />
* Tier-1 site: CCIN2P3<br />
* Tier-2 sites : Subatech Nantes, IPHC Strasbourg, IPN Orsay and IRFU (GRIF), LPC Clermont, CCIN2P3, LPSC Grenoble<br />
* Tier-3 sites : IPN Lyon<br />
* Représentant de la Fédération des Tiers-2 auprès d'Alice : Laurent Aphecetche<br />
<br />
<br />
==== [[Alice:Communication| Alice Communication VO/Sites]] ====<br />
<br />
* VO Alice ID Card : https://cic.gridops.org/index.php?section=vo<br />
* Alice LCG Task Force<br />
* Réunions hebdomadaires le jeudi 14:00 : http://indico.cern.ch/categoryDisplay.py?categId=3l151<br />
* Liste de diffusion : alice-lcg-task-force@cern.ch<br />
* AliEn WiKi : http://alien.cern.ch/twiki/bin/view/AliEn/Home<br />
<br />
<br />
==== [[Alice:Vobox| Alice Vobox]] ====<br />
Il faut commencer par installer une machine LCG en VOBOX (meta-package YAIM)<br />
et vérifier que sur cette machine on dispose de toutes les fonctionnalités d'une UI<br />
LCG (soumission de jobs).<br />
<br />
Voir cette doc :<br />
http://alien.cern.ch/twiki/bin/view/AliEn/HowToInstallLcgVoBox<br />
<br />
Il existe un script permettant de tester les fonctions LCG nécessaires<br />
avant d'installer AliEn.<br />
<br />
<strike>Il faut installer un LFC local (sur la VOBOX ou ailleurs).</strike><br />
(màj début 2007 : Ce n'est plus nécessaire d'installer un LFC sur la VOBOX).<br />
<br />
Il faut ensuite installer AliEn. Cela se fait en récupérant un<br />
"installer" : un script shell qui va se charger de récupérer<br />
les packages et les installer.<br />
<br />
Il faut aussi s'enregister auprès de la VO Alice (fournir le DN de son <br />
certificat) et demander le rôle alicesgm :<br />
http://alien.cern.ch/twiki/bin/view/Alice/UserRegistration<br />
<br />
AliEn se compose de plusieurs demons ou "services" :<br />
<br />
- ClusterMonitor<br />
- CE<br />
- SE<br />
- FTS<br />
- Packman<br />
- MonaLisa<br />
<br />
Home WiKi ALiEn :<br />
http://alien.cern.ch/twiki/bin/view/AliEn/Home<br />
<br />
Il y a pas mal de trous à faire dans le firewall:<br />
<br />
[https://twiki.cern.ch/twiki/pub/LCG/VoBoxesInfo/VO-Box-security-policy_v05.doc Security Policy]<br />
<br />
<br />
--[[Utilisateur:Barbet|Barbet]] 19 juin 2006 à 17:26 (CEST)*</div>
Barbet
https://lcg.in2p3.fr/index.php?title=HT-Condor&diff=7509
HT-Condor
2015-09-22T14:38:06Z
<p>Barbet: /* Gestion des ressources, priorités et comptabilité (accounting) */</p>
<hr />
<div>Démarrer avec HT-Condor<br />
=== Démarrer avec HT-Condor ===<br />
<br />
[Page en cours de création]<br />
<br />
==== Documentation et références ====<br />
<br />
Site de référence : http://research.cs.wisc.edu/htcondor/<br />
<br />
Wiki : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki<br />
<br />
Recettes Administrateur : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToAdminRecipes<br />
<br />
Manuel (version stable 8.2) : http://research.cs.wisc.edu/htcondor/manual/v8.2/index.html<br />
<br />
European HTCondor Site Admins Meeting 2014 : http://indico.cern.ch/event/272794/<br />
<br />
==== Repositories et installation ====<br />
<br />
http://research.cs.wisc.edu/htcondor/yum/<br />
<br />
<tt><br />
cd /etc/yum.repos.d/<br />
wget http://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel6.repo<br />
yum install condor<br />
</tt><br />
<br />
Attention: condor est aussi distribué via les repositories UMD, il peut être nécessaire de désactiver ces repositories ou bien d'utiliser les priorités avec YUM.<br />
<br />
==== Installation personnelle : configuration et premiers tests ====<br />
<br />
La configuration par défaut après l'installation du RPM permet de tester le produit sur une seule machine. Dans ce cas, sur la même machine, on trouve les trois types de noeuds : <i>submit node</i>, <i>master node</i> et <i>worker node</i>.<br />
<br />
Démarrer les demons :<br />
<br />
<tt><br />
service condor start<br />
Starting up Condor... done.<br />
<br />
service condor status<br />
Condor is running (pid 22310)<br />
</tt><br />
Les processus suivants sont lancés :<br />
<tt><br />
ps -ef | grep condor<br />
condor 22310 1 0 09:52 ? 00:00:00 /usr/sbin/condor_master -pidfile /var/run/condor/condor.pid<br />
root 22311 22310 0 09:52 ? 00:00:00 condor_procd -A /var/run/condor/procd_pipe -L /var/log/condor/ProcLog -R 1000000 -S 60 -C 493<br />
condor 22312 22310 0 09:52 ? 00:00:00 condor_collector -f<br />
condor 22314 22310 0 09:52 ? 00:00:00 condor_negotiator -f<br />
condor 22315 22310 0 09:52 ? 00:00:00 condor_schedd -f<br />
condor 22316 22310 0 09:52 ? 00:00:00 condor_startd -f<br />
condor 22359 22316 93 09:53 ? 00:00:11 mips<br />
</tt><br />
<br />
En ce qui concerne le demon qui gère un worker node (condor_startd), les processeurs disponibles sue la machine locale sont bien reconnus :<br />
<br />
<tt><br />
condor_status<br />
Name OpSys Arch State Activity LoadAv Mem ActvtyTime<br />
<br />
slot1@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:30:11<br />
slot2@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.030 1949 0+00:50:05<br />
slot3@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:06<br />
slot4@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:07<br />
Total Owner Claimed Unclaimed Matched Preempting Backfill<br />
<br />
X86_64/LINUX 4 0 0 4 0 0 0<br />
<br />
Total 4 0 0 4 0 0 0<br />
</tt><br />
<br />
Créer un programme de test (un script shell lançant des exécutables) :<br />
<br />
<tt><br />
more HT-Condor/testprog01.sh<br />
#! /bin/sh<br />
echo "HT-condor testprog01"<br />
echo "I'm process id $$ on" `hostname`<br />
echo "This is sent to standard error" 1>&2<br />
date<br />
echo "Running as binary $0" "$@"<br />
echo "My name (argument 1) is $1"<br />
echo "My sleep duration (argument 2) is $2"<br />
sleep $2<br />
echo "Sleep of $2 seconds finished. Exiting"<br />
exit 0<br />
</tt><br />
<br />
Créer la description du travail :<br />
<br />
<tt><br />
executable=testprog01.sh<br />
universe=vanilla<br />
arguments=Example.$(Cluster).$(Process) 100<br />
output=results.output.$(Process)<br />
error=results.error.$(Process)<br />
log=results.log<br />
notification=never<br />
should_transfer_files=YES<br />
when_to_transfer_output = ON_EXIT<br />
queue<br />
</tt><br />
<br />
Lancer le job :<br />
<br />
<tt><br />
condor_submit testprog01.submit <br />
Submitting job(s).<br />
1 job(s) submitted to cluster 1.<br />
</tt><br />
<br />
En surveiller l'exécution :<br />
<br />
<tt><br />
condor_q<br />
<br />
-- Submitter: nanpc117.in2p3.fr : <134.158.25.117:39976> : nanpc117.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
1.0 untel 8/4 09:57 0+00:00:05 R 0 0.0 testprog01.sh Exam<br />
<br />
1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended<br />
</tt><br />
<br />
Fin du job : les fichiers demandés sont là :<br />
<br />
<tt><br />
ls<br />
results.error.0 results.output.0 testprog01.submit<br />
results.log testprog01.sh<br />
</tt><br />
<br />
==== Installation type cluster local ====<br />
<br />
Le cluster de compose de : <br />
<br />
* une machine qui joue le rôle de serveur de batch (demons : condor_master, condor_collector, condor_negotiator)<br />
* une ou plusieurs machines pouvant soumettre des travaux (demon : condor_shedd) <br />
* les machines devant exécuter les travaux (worker nodes) (demons : )<br />
<br />
On installe le même RPM partout (comme ci-dessus) et c'est via les fichiers de configuration dans le répertoire /etc/condor que les machines vont jouer un rôle différent.<br />
Il est recommandé de ne jamais modifier le fichier /etc/condor/condor_config mais de surcharger la config par un fichier /etc/condor/condor_config.local ou mieux : un ensemble de fichiers dans /etc/condor/config.d<br />
Le fichier peut être le même pour toutes les machines et les différences exprimées avec des fichiers dans /etc/condor/config.d.<br />
<br />
Exemple de fichier global /etc/condor/condor_config.local :<br />
<br />
<tt><br />
# 0-General-Settings-and-Macros<br />
<br />
UID_DOMAIN = htcondor-grid@subatech.in2p3.fr<br />
CENTRAL_MANAGER1 = nanpbs3.in2p3.fr<br />
COLLECTOR_HOST = $(CENTRAL_MANAGER1)<br />
CONDOR_HOST=$(CENTRAL_MANAGER1)<br />
<br />
EVENT_LOG = EventLog<br />
<br />
# 1-Use-Security<br />
<br />
# 2-Policies<br />
<br />
SEC_DEFAULT_AUTHENTICATION = REQUIRED<br />
<br />
# 3-Authorizations<br />
<br />
ALLOW_WRITE = <br />
ALLOW_READ = */*.in2p3.fr<br />
ALLOW_DAEMON = *.in2p3.fr<br />
ALLOW_ADMINISTRATOR = root@$(CONDOR_HOST)<br />
ALLOW_CONFIG = root@$(FULL_HOSTNAME)<br />
<br />
# 4-Authentication<br />
SEC_PASSWORD_FILE = /etc/condor/pool_password<br />
SEC_READ_AUTHENTICATION = OPTIONAL<br />
SEC_CLIENT_AUTHENTICATION = REQUIRED<br />
SEC_DEFAULT_AUTHENTICATION_METHODS = PASSWORD,FS<br />
SCHEDD.SEC_WRITE_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SCHEDD.SEC_DAEMON_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SEC_CLIENT_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
SEC_READ_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
</tt><br />
<br />
Le modèle de sécurité choisi ici repose sur le partage d'une clé commune entre les différentes machines (submitter,master,workers). Cette clé /etc/condor/pool_password est crée par la commande suivante et distribuée sur les machines :<br />
<br />
<tt><br />
condor_store_cred -f /etc/condor/pool_password<br />
Enter password: xxxxxx<br />
</tt><br />
<br />
Ce modèle est assez simple et n'apporte que l'authentification entre demons, pas le chiffrement et le contrôle de l'intégrité des communications.<br />
<br />
<br />
===== Configuration du serveur de batch (nanpbs3.in2p3.fr) =====<br />
<br />
Dans cet exemple, le serveur de batch est aussi machine de soumission (il dispose des mêmes comptes que sur les worker nodes)<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/20-master.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = COLLECTOR, MASTER, NEGOTIATOR, SCHEDD<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
</tt><br />
<br />
===== Configuration d'un worker node (nanwn58.in2p3.fr) =====<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/10-workernode.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = MASTER, STARTD<br />
TRUST_UID_DOMAIN=TRUE<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
DaemonMaster None nanwn58.in2p3.fr <br />
Machine Job slot1@nanwn58.in2p3.fr <br />
Machine Job slot2@nanwn58.in2p3.fr <br />
Machine Job slot3@nanwn58.in2p3.fr <br />
Machine Job slot4@nanwn58.in2p3.fr <br />
Machine Job slot5@nanwn58.in2p3.fr <br />
Machine Job slot6@nanwn58.in2p3.fr <br />
Machine Job slot7@nanwn58.in2p3.fr <br />
Machine Job slot8@nanwn58.in2p3.fr <br />
</tt><br />
<br />
Examen de la queue depuis le server et submitter :<br />
<tt><br />
[root@nanpbs3 ~]# condor_q<br />
<br />
<br />
-- Submitter: nanpbs3.in2p3.fr : <193.48.101.50:58431> : nanpbs3.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
<br />
0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended<br />
</tt><br />
<br />
<br />
===== Gestion des ressources, priorités et comptabilité (accounting) =====<br />
<br />
Dans le cadre d'un cluster local, c'est l'utilisateur qui définit lui-même le groupe auxquel il appartient via une instruction de type ClassAd dans son fichier .submit. Exemple :<br />
<tt><br />
# accounting group<br />
accounting_group = group_info<br />
</tt><br />
<br />
... A développer ...<br />
<br />
==== Utilisation en contexte grille ====<br />
<br />
==== Sécurité ====</div>
Barbet
https://lcg.in2p3.fr/index.php?title=HT-Condor&diff=7508
HT-Condor
2015-09-22T14:37:34Z
<p>Barbet: /* Installation type cluster local */</p>
<hr />
<div>Démarrer avec HT-Condor<br />
=== Démarrer avec HT-Condor ===<br />
<br />
[Page en cours de création]<br />
<br />
==== Documentation et références ====<br />
<br />
Site de référence : http://research.cs.wisc.edu/htcondor/<br />
<br />
Wiki : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki<br />
<br />
Recettes Administrateur : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToAdminRecipes<br />
<br />
Manuel (version stable 8.2) : http://research.cs.wisc.edu/htcondor/manual/v8.2/index.html<br />
<br />
European HTCondor Site Admins Meeting 2014 : http://indico.cern.ch/event/272794/<br />
<br />
==== Repositories et installation ====<br />
<br />
http://research.cs.wisc.edu/htcondor/yum/<br />
<br />
<tt><br />
cd /etc/yum.repos.d/<br />
wget http://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel6.repo<br />
yum install condor<br />
</tt><br />
<br />
Attention: condor est aussi distribué via les repositories UMD, il peut être nécessaire de désactiver ces repositories ou bien d'utiliser les priorités avec YUM.<br />
<br />
==== Installation personnelle : configuration et premiers tests ====<br />
<br />
La configuration par défaut après l'installation du RPM permet de tester le produit sur une seule machine. Dans ce cas, sur la même machine, on trouve les trois types de noeuds : <i>submit node</i>, <i>master node</i> et <i>worker node</i>.<br />
<br />
Démarrer les demons :<br />
<br />
<tt><br />
service condor start<br />
Starting up Condor... done.<br />
<br />
service condor status<br />
Condor is running (pid 22310)<br />
</tt><br />
Les processus suivants sont lancés :<br />
<tt><br />
ps -ef | grep condor<br />
condor 22310 1 0 09:52 ? 00:00:00 /usr/sbin/condor_master -pidfile /var/run/condor/condor.pid<br />
root 22311 22310 0 09:52 ? 00:00:00 condor_procd -A /var/run/condor/procd_pipe -L /var/log/condor/ProcLog -R 1000000 -S 60 -C 493<br />
condor 22312 22310 0 09:52 ? 00:00:00 condor_collector -f<br />
condor 22314 22310 0 09:52 ? 00:00:00 condor_negotiator -f<br />
condor 22315 22310 0 09:52 ? 00:00:00 condor_schedd -f<br />
condor 22316 22310 0 09:52 ? 00:00:00 condor_startd -f<br />
condor 22359 22316 93 09:53 ? 00:00:11 mips<br />
</tt><br />
<br />
En ce qui concerne le demon qui gère un worker node (condor_startd), les processeurs disponibles sue la machine locale sont bien reconnus :<br />
<br />
<tt><br />
condor_status<br />
Name OpSys Arch State Activity LoadAv Mem ActvtyTime<br />
<br />
slot1@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:30:11<br />
slot2@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.030 1949 0+00:50:05<br />
slot3@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:06<br />
slot4@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:07<br />
Total Owner Claimed Unclaimed Matched Preempting Backfill<br />
<br />
X86_64/LINUX 4 0 0 4 0 0 0<br />
<br />
Total 4 0 0 4 0 0 0<br />
</tt><br />
<br />
Créer un programme de test (un script shell lançant des exécutables) :<br />
<br />
<tt><br />
more HT-Condor/testprog01.sh<br />
#! /bin/sh<br />
echo "HT-condor testprog01"<br />
echo "I'm process id $$ on" `hostname`<br />
echo "This is sent to standard error" 1>&2<br />
date<br />
echo "Running as binary $0" "$@"<br />
echo "My name (argument 1) is $1"<br />
echo "My sleep duration (argument 2) is $2"<br />
sleep $2<br />
echo "Sleep of $2 seconds finished. Exiting"<br />
exit 0<br />
</tt><br />
<br />
Créer la description du travail :<br />
<br />
<tt><br />
executable=testprog01.sh<br />
universe=vanilla<br />
arguments=Example.$(Cluster).$(Process) 100<br />
output=results.output.$(Process)<br />
error=results.error.$(Process)<br />
log=results.log<br />
notification=never<br />
should_transfer_files=YES<br />
when_to_transfer_output = ON_EXIT<br />
queue<br />
</tt><br />
<br />
Lancer le job :<br />
<br />
<tt><br />
condor_submit testprog01.submit <br />
Submitting job(s).<br />
1 job(s) submitted to cluster 1.<br />
</tt><br />
<br />
En surveiller l'exécution :<br />
<br />
<tt><br />
condor_q<br />
<br />
-- Submitter: nanpc117.in2p3.fr : <134.158.25.117:39976> : nanpc117.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
1.0 untel 8/4 09:57 0+00:00:05 R 0 0.0 testprog01.sh Exam<br />
<br />
1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended<br />
</tt><br />
<br />
Fin du job : les fichiers demandés sont là :<br />
<br />
<tt><br />
ls<br />
results.error.0 results.output.0 testprog01.submit<br />
results.log testprog01.sh<br />
</tt><br />
<br />
==== Installation type cluster local ====<br />
<br />
Le cluster de compose de : <br />
<br />
* une machine qui joue le rôle de serveur de batch (demons : condor_master, condor_collector, condor_negotiator)<br />
* une ou plusieurs machines pouvant soumettre des travaux (demon : condor_shedd) <br />
* les machines devant exécuter les travaux (worker nodes) (demons : )<br />
<br />
On installe le même RPM partout (comme ci-dessus) et c'est via les fichiers de configuration dans le répertoire /etc/condor que les machines vont jouer un rôle différent.<br />
Il est recommandé de ne jamais modifier le fichier /etc/condor/condor_config mais de surcharger la config par un fichier /etc/condor/condor_config.local ou mieux : un ensemble de fichiers dans /etc/condor/config.d<br />
Le fichier peut être le même pour toutes les machines et les différences exprimées avec des fichiers dans /etc/condor/config.d.<br />
<br />
Exemple de fichier global /etc/condor/condor_config.local :<br />
<br />
<tt><br />
# 0-General-Settings-and-Macros<br />
<br />
UID_DOMAIN = htcondor-grid@subatech.in2p3.fr<br />
CENTRAL_MANAGER1 = nanpbs3.in2p3.fr<br />
COLLECTOR_HOST = $(CENTRAL_MANAGER1)<br />
CONDOR_HOST=$(CENTRAL_MANAGER1)<br />
<br />
EVENT_LOG = EventLog<br />
<br />
# 1-Use-Security<br />
<br />
# 2-Policies<br />
<br />
SEC_DEFAULT_AUTHENTICATION = REQUIRED<br />
<br />
# 3-Authorizations<br />
<br />
ALLOW_WRITE = <br />
ALLOW_READ = */*.in2p3.fr<br />
ALLOW_DAEMON = *.in2p3.fr<br />
ALLOW_ADMINISTRATOR = root@$(CONDOR_HOST)<br />
ALLOW_CONFIG = root@$(FULL_HOSTNAME)<br />
<br />
# 4-Authentication<br />
SEC_PASSWORD_FILE = /etc/condor/pool_password<br />
SEC_READ_AUTHENTICATION = OPTIONAL<br />
SEC_CLIENT_AUTHENTICATION = REQUIRED<br />
SEC_DEFAULT_AUTHENTICATION_METHODS = PASSWORD,FS<br />
SCHEDD.SEC_WRITE_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SCHEDD.SEC_DAEMON_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SEC_CLIENT_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
SEC_READ_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
</tt><br />
<br />
Le modèle de sécurité choisi ici repose sur le partage d'une clé commune entre les différentes machines (submitter,master,workers). Cette clé /etc/condor/pool_password est crée par la commande suivante et distribuée sur les machines :<br />
<br />
<tt><br />
condor_store_cred -f /etc/condor/pool_password<br />
Enter password: xxxxxx<br />
</tt><br />
<br />
Ce modèle est assez simple et n'apporte que l'authentification entre demons, pas le chiffrement et le contrôle de l'intégrité des communications.<br />
<br />
<br />
===== Configuration du serveur de batch (nanpbs3.in2p3.fr) =====<br />
<br />
Dans cet exemple, le serveur de batch est aussi machine de soumission (il dispose des mêmes comptes que sur les worker nodes)<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/20-master.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = COLLECTOR, MASTER, NEGOTIATOR, SCHEDD<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
</tt><br />
<br />
===== Configuration d'un worker node (nanwn58.in2p3.fr) =====<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/10-workernode.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = MASTER, STARTD<br />
TRUST_UID_DOMAIN=TRUE<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
DaemonMaster None nanwn58.in2p3.fr <br />
Machine Job slot1@nanwn58.in2p3.fr <br />
Machine Job slot2@nanwn58.in2p3.fr <br />
Machine Job slot3@nanwn58.in2p3.fr <br />
Machine Job slot4@nanwn58.in2p3.fr <br />
Machine Job slot5@nanwn58.in2p3.fr <br />
Machine Job slot6@nanwn58.in2p3.fr <br />
Machine Job slot7@nanwn58.in2p3.fr <br />
Machine Job slot8@nanwn58.in2p3.fr <br />
</tt><br />
<br />
Examen de la queue depuis le server et submitter :<br />
<tt><br />
[root@nanpbs3 ~]# condor_q<br />
<br />
<br />
-- Submitter: nanpbs3.in2p3.fr : <193.48.101.50:58431> : nanpbs3.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
<br />
0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended<br />
</tt><br />
<br />
<br />
===== Gestion des ressources, priorités et comptabilité (accounting) =====<br />
<br />
Dans le cadre d'un cluster local, c'est l'utilisateur qui définit lui-même le groupe auxquel il appartient via une instruction de type ClassAd dans son fichier .submit. Exemple :<br />
<tt><br />
# accounting group<br />
accounting_group = group_info<br />
</tt><br />
<br />
... A développer ...<br />
<br />
==== Utilisation en contexte grille ====<br />
<br />
==== Sécurité ====</div>
Barbet
https://lcg.in2p3.fr/index.php?title=HT-Condor&diff=7507
HT-Condor
2015-09-22T14:32:40Z
<p>Barbet: /* Documentation et références */</p>
<hr />
<div>Démarrer avec HT-Condor<br />
=== Démarrer avec HT-Condor ===<br />
<br />
[Page en cours de création]<br />
<br />
==== Documentation et références ====<br />
<br />
Site de référence : http://research.cs.wisc.edu/htcondor/<br />
<br />
Wiki : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki<br />
<br />
Recettes Administrateur : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToAdminRecipes<br />
<br />
Manuel (version stable 8.2) : http://research.cs.wisc.edu/htcondor/manual/v8.2/index.html<br />
<br />
European HTCondor Site Admins Meeting 2014 : http://indico.cern.ch/event/272794/<br />
<br />
==== Repositories et installation ====<br />
<br />
http://research.cs.wisc.edu/htcondor/yum/<br />
<br />
<tt><br />
cd /etc/yum.repos.d/<br />
wget http://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel6.repo<br />
yum install condor<br />
</tt><br />
<br />
Attention: condor est aussi distribué via les repositories UMD, il peut être nécessaire de désactiver ces repositories ou bien d'utiliser les priorités avec YUM.<br />
<br />
==== Installation personnelle : configuration et premiers tests ====<br />
<br />
La configuration par défaut après l'installation du RPM permet de tester le produit sur une seule machine. Dans ce cas, sur la même machine, on trouve les trois types de noeuds : <i>submit node</i>, <i>master node</i> et <i>worker node</i>.<br />
<br />
Démarrer les demons :<br />
<br />
<tt><br />
service condor start<br />
Starting up Condor... done.<br />
<br />
service condor status<br />
Condor is running (pid 22310)<br />
</tt><br />
Les processus suivants sont lancés :<br />
<tt><br />
ps -ef | grep condor<br />
condor 22310 1 0 09:52 ? 00:00:00 /usr/sbin/condor_master -pidfile /var/run/condor/condor.pid<br />
root 22311 22310 0 09:52 ? 00:00:00 condor_procd -A /var/run/condor/procd_pipe -L /var/log/condor/ProcLog -R 1000000 -S 60 -C 493<br />
condor 22312 22310 0 09:52 ? 00:00:00 condor_collector -f<br />
condor 22314 22310 0 09:52 ? 00:00:00 condor_negotiator -f<br />
condor 22315 22310 0 09:52 ? 00:00:00 condor_schedd -f<br />
condor 22316 22310 0 09:52 ? 00:00:00 condor_startd -f<br />
condor 22359 22316 93 09:53 ? 00:00:11 mips<br />
</tt><br />
<br />
En ce qui concerne le demon qui gère un worker node (condor_startd), les processeurs disponibles sue la machine locale sont bien reconnus :<br />
<br />
<tt><br />
condor_status<br />
Name OpSys Arch State Activity LoadAv Mem ActvtyTime<br />
<br />
slot1@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:30:11<br />
slot2@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.030 1949 0+00:50:05<br />
slot3@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:06<br />
slot4@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:07<br />
Total Owner Claimed Unclaimed Matched Preempting Backfill<br />
<br />
X86_64/LINUX 4 0 0 4 0 0 0<br />
<br />
Total 4 0 0 4 0 0 0<br />
</tt><br />
<br />
Créer un programme de test (un script shell lançant des exécutables) :<br />
<br />
<tt><br />
more HT-Condor/testprog01.sh<br />
#! /bin/sh<br />
echo "HT-condor testprog01"<br />
echo "I'm process id $$ on" `hostname`<br />
echo "This is sent to standard error" 1>&2<br />
date<br />
echo "Running as binary $0" "$@"<br />
echo "My name (argument 1) is $1"<br />
echo "My sleep duration (argument 2) is $2"<br />
sleep $2<br />
echo "Sleep of $2 seconds finished. Exiting"<br />
exit 0<br />
</tt><br />
<br />
Créer la description du travail :<br />
<br />
<tt><br />
executable=testprog01.sh<br />
universe=vanilla<br />
arguments=Example.$(Cluster).$(Process) 100<br />
output=results.output.$(Process)<br />
error=results.error.$(Process)<br />
log=results.log<br />
notification=never<br />
should_transfer_files=YES<br />
when_to_transfer_output = ON_EXIT<br />
queue<br />
</tt><br />
<br />
Lancer le job :<br />
<br />
<tt><br />
condor_submit testprog01.submit <br />
Submitting job(s).<br />
1 job(s) submitted to cluster 1.<br />
</tt><br />
<br />
En surveiller l'exécution :<br />
<br />
<tt><br />
condor_q<br />
<br />
-- Submitter: nanpc117.in2p3.fr : <134.158.25.117:39976> : nanpc117.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
1.0 untel 8/4 09:57 0+00:00:05 R 0 0.0 testprog01.sh Exam<br />
<br />
1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended<br />
</tt><br />
<br />
Fin du job : les fichiers demandés sont là :<br />
<br />
<tt><br />
ls<br />
results.error.0 results.output.0 testprog01.submit<br />
results.log testprog01.sh<br />
</tt><br />
<br />
==== Installation type cluster local ====<br />
<br />
Le cluster de compose de : <br />
<br />
* une machine qui joue le rôle de serveur de batch (demons : condor_master, condor_collector, condor_negotiator)<br />
* une ou plusieurs machines pouvant soumettre des travaux (demon : condor_shedd) <br />
* les machines devant exécuter les travaux (worker nodes) (demons : )<br />
<br />
On installe le même RPM partout (comme ci-dessus) et c'est via les fichiers de configuration dans le répertoire /etc/condor que les machines vont jouer un rôle différent.<br />
Il est recommandé de ne jamais modifier le fichier /etc/condor/condor_config mais de surcharger la config par un fichier /etc/condor/condor_config.local ou mieux : un ensemble de fichiers dans /etc/condor/config.d<br />
Le fichier peut être le même pour toutes les machines et les différences exprimées avec des fichiers dans /etc/condor/config.d.<br />
<br />
Exemple de fichier global /etc/condor/condor_config.local :<br />
<br />
<tt><br />
# 0-General-Settings-and-Macros<br />
<br />
UID_DOMAIN = htcondor-grid@subatech.in2p3.fr<br />
CENTRAL_MANAGER1 = nanpbs3.in2p3.fr<br />
COLLECTOR_HOST = $(CENTRAL_MANAGER1)<br />
CONDOR_HOST=$(CENTRAL_MANAGER1)<br />
<br />
EVENT_LOG = EventLog<br />
<br />
# 1-Use-Security<br />
<br />
# 2-Policies<br />
<br />
SEC_DEFAULT_AUTHENTICATION = REQUIRED<br />
<br />
# 3-Authorizations<br />
<br />
ALLOW_WRITE = <br />
ALLOW_READ = */*.in2p3.fr<br />
ALLOW_DAEMON = *.in2p3.fr<br />
ALLOW_ADMINISTRATOR = root@$(CONDOR_HOST)<br />
ALLOW_CONFIG = root@$(FULL_HOSTNAME)<br />
<br />
# 4-Authentication<br />
SEC_PASSWORD_FILE = /etc/condor/pool_password<br />
SEC_READ_AUTHENTICATION = OPTIONAL<br />
SEC_CLIENT_AUTHENTICATION = REQUIRED<br />
SEC_DEFAULT_AUTHENTICATION_METHODS = PASSWORD,FS<br />
SCHEDD.SEC_WRITE_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SCHEDD.SEC_DAEMON_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SEC_CLIENT_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
SEC_READ_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
</tt><br />
<br />
Le modèle de sécurité choisi ici repose sur le partage d'une clé commune entre les différentes machines (submitter,master,workers). Cette clé /etc/condor/pool_password est crée par la commande suivante et distribuée sur les machines :<br />
<br />
<tt><br />
condor_store_cred -f /etc/condor/pool_password<br />
Enter password: xxxxxx<br />
</tt><br />
<br />
Ce modèle est assez simple et n'apporte que l'authentification entre demons, pas le chiffrement et le contrôle de l'intégrité des communications.<br />
<br />
<br />
===== Configuration du serveur de batch (nanpbs3.in2p3.fr) =====<br />
<br />
Dans cet exemple, le serveur de batch est aussi machine de soumission (il dispose des mêmes comptes que sur les worker nodes)<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/20-master.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = COLLECTOR, MASTER, NEGOTIATOR, SCHEDD<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
</tt><br />
<br />
===== Configuration d'un worker node (nanwn58.in2p3.fr) =====<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/10-workernode.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = MASTER, STARTD<br />
TRUST_UID_DOMAIN=TRUE<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
DaemonMaster None nanwn58.in2p3.fr <br />
Machine Job slot1@nanwn58.in2p3.fr <br />
Machine Job slot2@nanwn58.in2p3.fr <br />
Machine Job slot3@nanwn58.in2p3.fr <br />
Machine Job slot4@nanwn58.in2p3.fr <br />
Machine Job slot5@nanwn58.in2p3.fr <br />
Machine Job slot6@nanwn58.in2p3.fr <br />
Machine Job slot7@nanwn58.in2p3.fr <br />
Machine Job slot8@nanwn58.in2p3.fr <br />
</tt><br />
<br />
Examen de la queue depuis le server et submitter :<br />
<tt><br />
[root@nanpbs3 ~]# condor_q<br />
<br />
<br />
-- Submitter: nanpbs3.in2p3.fr : <193.48.101.50:58431> : nanpbs3.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
<br />
0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended<br />
</tt><br />
<br />
==== Utilisation en contexte grille ====<br />
<br />
==== Sécurité ====</div>
Barbet
https://lcg.in2p3.fr/index.php?title=HT-Condor&diff=7497
HT-Condor
2015-08-12T09:11:42Z
<p>Barbet: /* Installation type cluster local */</p>
<hr />
<div>Démarrer avec HT-Condor<br />
=== Démarrer avec HT-Condor ===<br />
<br />
[Page en cours de création]<br />
<br />
==== Documentation et références ====<br />
<br />
Site de référence : http://research.cs.wisc.edu/htcondor/<br />
<br />
Wiki : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki<br />
<br />
Recettes Administrateur : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToAdminRecipes<br />
<br />
Manuel (version stable 8.2) : http://research.cs.wisc.edu/htcondor/manual/v8.2/index.html<br />
<br />
==== Repositories et installation ====<br />
<br />
http://research.cs.wisc.edu/htcondor/yum/<br />
<br />
<tt><br />
cd /etc/yum.repos.d/<br />
wget http://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel6.repo<br />
yum install condor<br />
</tt><br />
<br />
Attention: condor est aussi distribué via les repositories UMD, il peut être nécessaire de désactiver ces repositories ou bien d'utiliser les priorités avec YUM.<br />
<br />
==== Installation personnelle : configuration et premiers tests ====<br />
<br />
La configuration par défaut après l'installation du RPM permet de tester le produit sur une seule machine. Dans ce cas, sur la même machine, on trouve les trois types de noeuds : <i>submit node</i>, <i>master node</i> et <i>worker node</i>.<br />
<br />
Démarrer les demons :<br />
<br />
<tt><br />
service condor start<br />
Starting up Condor... done.<br />
<br />
service condor status<br />
Condor is running (pid 22310)<br />
</tt><br />
Les processus suivants sont lancés :<br />
<tt><br />
ps -ef | grep condor<br />
condor 22310 1 0 09:52 ? 00:00:00 /usr/sbin/condor_master -pidfile /var/run/condor/condor.pid<br />
root 22311 22310 0 09:52 ? 00:00:00 condor_procd -A /var/run/condor/procd_pipe -L /var/log/condor/ProcLog -R 1000000 -S 60 -C 493<br />
condor 22312 22310 0 09:52 ? 00:00:00 condor_collector -f<br />
condor 22314 22310 0 09:52 ? 00:00:00 condor_negotiator -f<br />
condor 22315 22310 0 09:52 ? 00:00:00 condor_schedd -f<br />
condor 22316 22310 0 09:52 ? 00:00:00 condor_startd -f<br />
condor 22359 22316 93 09:53 ? 00:00:11 mips<br />
</tt><br />
<br />
En ce qui concerne le demon qui gère un worker node (condor_startd), les processeurs disponibles sue la machine locale sont bien reconnus :<br />
<br />
<tt><br />
condor_status<br />
Name OpSys Arch State Activity LoadAv Mem ActvtyTime<br />
<br />
slot1@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:30:11<br />
slot2@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.030 1949 0+00:50:05<br />
slot3@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:06<br />
slot4@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:07<br />
Total Owner Claimed Unclaimed Matched Preempting Backfill<br />
<br />
X86_64/LINUX 4 0 0 4 0 0 0<br />
<br />
Total 4 0 0 4 0 0 0<br />
</tt><br />
<br />
Créer un programme de test (un script shell lançant des exécutables) :<br />
<br />
<tt><br />
more HT-Condor/testprog01.sh<br />
#! /bin/sh<br />
echo "HT-condor testprog01"<br />
echo "I'm process id $$ on" `hostname`<br />
echo "This is sent to standard error" 1>&2<br />
date<br />
echo "Running as binary $0" "$@"<br />
echo "My name (argument 1) is $1"<br />
echo "My sleep duration (argument 2) is $2"<br />
sleep $2<br />
echo "Sleep of $2 seconds finished. Exiting"<br />
exit 0<br />
</tt><br />
<br />
Créer la description du travail :<br />
<br />
<tt><br />
executable=testprog01.sh<br />
universe=vanilla<br />
arguments=Example.$(Cluster).$(Process) 100<br />
output=results.output.$(Process)<br />
error=results.error.$(Process)<br />
log=results.log<br />
notification=never<br />
should_transfer_files=YES<br />
when_to_transfer_output = ON_EXIT<br />
queue<br />
</tt><br />
<br />
Lancer le job :<br />
<br />
<tt><br />
condor_submit testprog01.submit <br />
Submitting job(s).<br />
1 job(s) submitted to cluster 1.<br />
</tt><br />
<br />
En surveiller l'exécution :<br />
<br />
<tt><br />
condor_q<br />
<br />
-- Submitter: nanpc117.in2p3.fr : <134.158.25.117:39976> : nanpc117.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
1.0 untel 8/4 09:57 0+00:00:05 R 0 0.0 testprog01.sh Exam<br />
<br />
1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended<br />
</tt><br />
<br />
Fin du job : les fichiers demandés sont là :<br />
<br />
<tt><br />
ls<br />
results.error.0 results.output.0 testprog01.submit<br />
results.log testprog01.sh<br />
</tt><br />
<br />
==== Installation type cluster local ====<br />
<br />
Le cluster de compose de : <br />
<br />
* une machine qui joue le rôle de serveur de batch (demons : condor_master, condor_collector, condor_negotiator)<br />
* une ou plusieurs machines pouvant soumettre des travaux (demon : condor_shedd) <br />
* les machines devant exécuter les travaux (worker nodes) (demons : )<br />
<br />
On installe le même RPM partout (comme ci-dessus) et c'est via les fichiers de configuration dans le répertoire /etc/condor que les machines vont jouer un rôle différent.<br />
Il est recommandé de ne jamais modifier le fichier /etc/condor/condor_config mais de surcharger la config par un fichier /etc/condor/condor_config.local ou mieux : un ensemble de fichiers dans /etc/condor/config.d<br />
Le fichier peut être le même pour toutes les machines et les différences exprimées avec des fichiers dans /etc/condor/config.d.<br />
<br />
Exemple de fichier global /etc/condor/condor_config.local :<br />
<br />
<tt><br />
# 0-General-Settings-and-Macros<br />
<br />
UID_DOMAIN = htcondor-grid@subatech.in2p3.fr<br />
CENTRAL_MANAGER1 = nanpbs3.in2p3.fr<br />
COLLECTOR_HOST = $(CENTRAL_MANAGER1)<br />
CONDOR_HOST=$(CENTRAL_MANAGER1)<br />
<br />
EVENT_LOG = EventLog<br />
<br />
# 1-Use-Security<br />
<br />
# 2-Policies<br />
<br />
SEC_DEFAULT_AUTHENTICATION = REQUIRED<br />
<br />
# 3-Authorizations<br />
<br />
ALLOW_WRITE = <br />
ALLOW_READ = */*.in2p3.fr<br />
ALLOW_DAEMON = *.in2p3.fr<br />
ALLOW_ADMINISTRATOR = root@$(CONDOR_HOST)<br />
ALLOW_CONFIG = root@$(FULL_HOSTNAME)<br />
<br />
# 4-Authentication<br />
SEC_PASSWORD_FILE = /etc/condor/pool_password<br />
SEC_READ_AUTHENTICATION = OPTIONAL<br />
SEC_CLIENT_AUTHENTICATION = REQUIRED<br />
SEC_DEFAULT_AUTHENTICATION_METHODS = PASSWORD,FS<br />
SCHEDD.SEC_WRITE_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SCHEDD.SEC_DAEMON_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SEC_CLIENT_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
SEC_READ_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
</tt><br />
<br />
Le modèle de sécurité choisi ici repose sur le partage d'une clé commune entre les différentes machines (submitter,master,workers). Cette clé /etc/condor/pool_password est crée par la commande suivante et distribuée sur les machines :<br />
<br />
<tt><br />
condor_store_cred -f /etc/condor/pool_password<br />
Enter password: xxxxxx<br />
</tt><br />
<br />
Ce modèle est assez simple et n'apporte que l'authentification entre demons, pas le chiffrement et le contrôle de l'intégrité des communications.<br />
<br />
<br />
===== Configuration du serveur de batch (nanpbs3.in2p3.fr) =====<br />
<br />
Dans cet exemple, le serveur de batch est aussi machine de soumission (il dispose des mêmes comptes que sur les worker nodes)<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/20-master.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = COLLECTOR, MASTER, NEGOTIATOR, SCHEDD<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
</tt><br />
<br />
===== Configuration d'un worker node (nanwn58.in2p3.fr) =====<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/10-workernode.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = MASTER, STARTD<br />
TRUST_UID_DOMAIN=TRUE<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
DaemonMaster None nanwn58.in2p3.fr <br />
Machine Job slot1@nanwn58.in2p3.fr <br />
Machine Job slot2@nanwn58.in2p3.fr <br />
Machine Job slot3@nanwn58.in2p3.fr <br />
Machine Job slot4@nanwn58.in2p3.fr <br />
Machine Job slot5@nanwn58.in2p3.fr <br />
Machine Job slot6@nanwn58.in2p3.fr <br />
Machine Job slot7@nanwn58.in2p3.fr <br />
Machine Job slot8@nanwn58.in2p3.fr <br />
</tt><br />
<br />
Examen de la queue depuis le server et submitter :<br />
<tt><br />
[root@nanpbs3 ~]# condor_q<br />
<br />
<br />
-- Submitter: nanpbs3.in2p3.fr : <193.48.101.50:58431> : nanpbs3.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
<br />
0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended<br />
</tt><br />
<br />
==== Utilisation en contexte grille ====<br />
<br />
==== Sécurité ====</div>
Barbet
https://lcg.in2p3.fr/index.php?title=HT-Condor&diff=7496
HT-Condor
2015-08-12T09:10:55Z
<p>Barbet: /* Installation type cluster local */</p>
<hr />
<div>Démarrer avec HT-Condor<br />
=== Démarrer avec HT-Condor ===<br />
<br />
[Page en cours de création]<br />
<br />
==== Documentation et références ====<br />
<br />
Site de référence : http://research.cs.wisc.edu/htcondor/<br />
<br />
Wiki : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki<br />
<br />
Recettes Administrateur : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToAdminRecipes<br />
<br />
Manuel (version stable 8.2) : http://research.cs.wisc.edu/htcondor/manual/v8.2/index.html<br />
<br />
==== Repositories et installation ====<br />
<br />
http://research.cs.wisc.edu/htcondor/yum/<br />
<br />
<tt><br />
cd /etc/yum.repos.d/<br />
wget http://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel6.repo<br />
yum install condor<br />
</tt><br />
<br />
Attention: condor est aussi distribué via les repositories UMD, il peut être nécessaire de désactiver ces repositories ou bien d'utiliser les priorités avec YUM.<br />
<br />
==== Installation personnelle : configuration et premiers tests ====<br />
<br />
La configuration par défaut après l'installation du RPM permet de tester le produit sur une seule machine. Dans ce cas, sur la même machine, on trouve les trois types de noeuds : <i>submit node</i>, <i>master node</i> et <i>worker node</i>.<br />
<br />
Démarrer les demons :<br />
<br />
<tt><br />
service condor start<br />
Starting up Condor... done.<br />
<br />
service condor status<br />
Condor is running (pid 22310)<br />
</tt><br />
Les processus suivants sont lancés :<br />
<tt><br />
ps -ef | grep condor<br />
condor 22310 1 0 09:52 ? 00:00:00 /usr/sbin/condor_master -pidfile /var/run/condor/condor.pid<br />
root 22311 22310 0 09:52 ? 00:00:00 condor_procd -A /var/run/condor/procd_pipe -L /var/log/condor/ProcLog -R 1000000 -S 60 -C 493<br />
condor 22312 22310 0 09:52 ? 00:00:00 condor_collector -f<br />
condor 22314 22310 0 09:52 ? 00:00:00 condor_negotiator -f<br />
condor 22315 22310 0 09:52 ? 00:00:00 condor_schedd -f<br />
condor 22316 22310 0 09:52 ? 00:00:00 condor_startd -f<br />
condor 22359 22316 93 09:53 ? 00:00:11 mips<br />
</tt><br />
<br />
En ce qui concerne le demon qui gère un worker node (condor_startd), les processeurs disponibles sue la machine locale sont bien reconnus :<br />
<br />
<tt><br />
condor_status<br />
Name OpSys Arch State Activity LoadAv Mem ActvtyTime<br />
<br />
slot1@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:30:11<br />
slot2@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.030 1949 0+00:50:05<br />
slot3@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:06<br />
slot4@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:07<br />
Total Owner Claimed Unclaimed Matched Preempting Backfill<br />
<br />
X86_64/LINUX 4 0 0 4 0 0 0<br />
<br />
Total 4 0 0 4 0 0 0<br />
</tt><br />
<br />
Créer un programme de test (un script shell lançant des exécutables) :<br />
<br />
<tt><br />
more HT-Condor/testprog01.sh<br />
#! /bin/sh<br />
echo "HT-condor testprog01"<br />
echo "I'm process id $$ on" `hostname`<br />
echo "This is sent to standard error" 1>&2<br />
date<br />
echo "Running as binary $0" "$@"<br />
echo "My name (argument 1) is $1"<br />
echo "My sleep duration (argument 2) is $2"<br />
sleep $2<br />
echo "Sleep of $2 seconds finished. Exiting"<br />
exit 0<br />
</tt><br />
<br />
Créer la description du travail :<br />
<br />
<tt><br />
executable=testprog01.sh<br />
universe=vanilla<br />
arguments=Example.$(Cluster).$(Process) 100<br />
output=results.output.$(Process)<br />
error=results.error.$(Process)<br />
log=results.log<br />
notification=never<br />
should_transfer_files=YES<br />
when_to_transfer_output = ON_EXIT<br />
queue<br />
</tt><br />
<br />
Lancer le job :<br />
<br />
<tt><br />
condor_submit testprog01.submit <br />
Submitting job(s).<br />
1 job(s) submitted to cluster 1.<br />
</tt><br />
<br />
En surveiller l'exécution :<br />
<br />
<tt><br />
condor_q<br />
<br />
-- Submitter: nanpc117.in2p3.fr : <134.158.25.117:39976> : nanpc117.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
1.0 untel 8/4 09:57 0+00:00:05 R 0 0.0 testprog01.sh Exam<br />
<br />
1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended<br />
</tt><br />
<br />
Fin du job : les fichiers demandés sont là :<br />
<br />
<tt><br />
ls<br />
results.error.0 results.output.0 testprog01.submit<br />
results.log testprog01.sh<br />
</tt><br />
<br />
==== Installation type cluster local ====<br />
<br />
Le cluster de compose de : <br />
<br />
* une machine qui joue le rôle de serveur de batch (demons : condor_master, condor_collector, condor_negotiator)<br />
* une ou plusieurs machines pouvant soumettre des travaux (demon : condor_shedd) <br />
* les machines devant exécuter les travaux (worker nodes) (demons : )<br />
<br />
On installe le même RPM partout (comme ci-dessus) et c'est via les fichiers de configuration dans le répertoire /etc/condor que les machines vont jouer un rôle différent.<br />
Il est recommandé de ne jamais modifier le fichier /etc/condor/condor_config mais de surcharger la config par un fichier /etc/condor/condor_config.local ou mieux : un ensemble de fichiers dans /etc/condor/config.d<br />
Le fichier peut être le même pour toutes les machines et les différences exprimées avec des fichiers dans /etc/condor/config.d.<br />
<br />
Exemple de fichier global /etc/condor/condor_config.local :<br />
<br />
<tt><br />
# 0-General-Settings-and-Macros<br />
<br />
UID_DOMAIN = htcondor-grid@subatech.in2p3.fr<br />
CENTRAL_MANAGER1 = nanpbs3.in2p3.fr<br />
COLLECTOR_HOST = $(CENTRAL_MANAGER1)<br />
CONDOR_HOST=$(CENTRAL_MANAGER1)<br />
<br />
EVENT_LOG = EventLog<br />
<br />
# 1-Use-Security<br />
<br />
# 2-Policies<br />
<br />
SEC_DEFAULT_AUTHENTICATION = REQUIRED<br />
<br />
# 3-Authorizations<br />
<br />
ALLOW_WRITE = <br />
ALLOW_READ = */*.in2p3.fr<br />
ALLOW_DAEMON = *.in2p3.fr<br />
ALLOW_ADMINISTRATOR = root@$(CONDOR_HOST)<br />
ALLOW_CONFIG = root@$(FULL_HOSTNAME)<br />
<br />
# 4-Authentication<br />
SEC_PASSWORD_FILE = /etc/condor/pool_password<br />
SEC_READ_AUTHENTICATION = OPTIONAL<br />
SEC_CLIENT_AUTHENTICATION = REQUIRED<br />
SEC_DEFAULT_AUTHENTICATION_METHODS = PASSWORD,FS<br />
SCHEDD.SEC_WRITE_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SCHEDD.SEC_DAEMON_AUTHENTICATION_METHODS = FS,PASSWORD<br />
SEC_CLIENT_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
SEC_READ_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE<br />
</tt><br />
<br />
Le modèle de sécurité choisi ici repose sur le partage d'une clé commune entre les différentes machines (submitter,master,workers). Cette clé /etc/condor/pool_password est crée par la commande suivante et distribuée sur les machines :<br />
<br />
<tt><br />
condor_store_cred -f /etc/condor/pool_password<br />
Enter password: xxxxxx<br />
</tt><br />
<br />
Ce modèle est assez simple et n'apporte que l'authentification entre demons, pas le chiffrement et le contrôle de l'intégrité des communications.<br />
<br />
<br />
===== Configuration du serveur de batch (nanpbs3.in2p3.fr) =====<br />
<br />
Dans cet exemple, le serveur de batch est aussi machine de soumission (il dispose des mêmes comptes que sur les worker nodes)<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/20-master.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = COLLECTOR, MASTER, NEGOTIATOR, SCHEDD<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
</tt><br />
<br />
===== Configuration d'un worker node (nanwn58.in2p3.fr) =====<br />
<br />
Creation d'un fichier supplémentaire /etc/condor/config.d/10-workernode.conf :<br />
<br />
<tt> <br />
DAEMON_LIST = MASTER, STARTD<br />
TRUST_UID_DOMAIN=TRUE<br />
</tt><br />
<br />
Redémarrage avec la nouvelle config :<br />
<br />
<tt><br />
service condor restart<br />
</tt><br />
<br />
<tt><br />
condor_status -any<br />
MyType TargetType Name <br />
<br />
Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.<br />
Scheduler None nanpbs3.in2p3.fr <br />
DaemonMaster None nanpbs3.in2p3.fr <br />
Negotiator None nanpbs3.in2p3.fr <br />
DaemonMaster None nanwn58.in2p3.fr <br />
Machine Job slot1@nanwn58.in2p3.fr <br />
Machine Job slot2@nanwn58.in2p3.fr <br />
Machine Job slot3@nanwn58.in2p3.fr <br />
Machine Job slot4@nanwn58.in2p3.fr <br />
Machine Job slot5@nanwn58.in2p3.fr <br />
Machine Job slot6@nanwn58.in2p3.fr <br />
Machine Job slot7@nanwn58.in2p3.fr <br />
Machine Job slot8@nanwn58.in2p3.fr <br />
</tt><br />
<br />
Examen de la queue depuis le server et submitter :<br />
<tt><br />
[root@nanpbs3 ~]# condor_q<br />
<br />
<br />
-- Submitter: nanpbs3.in2p3.fr : <193.48.101.50:58431> : nanpbs3.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
<br />
0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended<br />
</tt><br />
<br />
==== Utilisation en contexte grille ====<br />
<br />
==== Sécurité ====</div>
Barbet
https://lcg.in2p3.fr/index.php?title=HT-Condor&diff=7495
HT-Condor
2015-08-10T13:35:32Z
<p>Barbet: /* Installation personnelle : configuration et premiers tests */</p>
<hr />
<div>Démarrer avec HT-Condor<br />
=== Démarrer avec HT-Condor ===<br />
<br />
[Page en cours de création]<br />
<br />
==== Documentation et références ====<br />
<br />
Site de référence : http://research.cs.wisc.edu/htcondor/<br />
<br />
Wiki : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki<br />
<br />
Recettes Administrateur : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToAdminRecipes<br />
<br />
Manuel (version stable 8.2) : http://research.cs.wisc.edu/htcondor/manual/v8.2/index.html<br />
<br />
==== Repositories et installation ====<br />
<br />
http://research.cs.wisc.edu/htcondor/yum/<br />
<br />
<tt><br />
cd /etc/yum.repos.d/<br />
wget http://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel6.repo<br />
yum install condor<br />
</tt><br />
<br />
Attention: condor est aussi distribué via les repositories UMD, il peut être nécessaire de désactiver ces repositories ou bien d'utiliser les priorités avec YUM.<br />
<br />
==== Installation personnelle : configuration et premiers tests ====<br />
<br />
La configuration par défaut après l'installation du RPM permet de tester le produit sur une seule machine. Dans ce cas, sur la même machine, on trouve les trois types de noeuds : <i>submit node</i>, <i>master node</i> et <i>worker node</i>.<br />
<br />
Démarrer les demons :<br />
<br />
<tt><br />
service condor start<br />
Starting up Condor... done.<br />
<br />
service condor status<br />
Condor is running (pid 22310)<br />
</tt><br />
Les processus suivants sont lancés :<br />
<tt><br />
ps -ef | grep condor<br />
condor 22310 1 0 09:52 ? 00:00:00 /usr/sbin/condor_master -pidfile /var/run/condor/condor.pid<br />
root 22311 22310 0 09:52 ? 00:00:00 condor_procd -A /var/run/condor/procd_pipe -L /var/log/condor/ProcLog -R 1000000 -S 60 -C 493<br />
condor 22312 22310 0 09:52 ? 00:00:00 condor_collector -f<br />
condor 22314 22310 0 09:52 ? 00:00:00 condor_negotiator -f<br />
condor 22315 22310 0 09:52 ? 00:00:00 condor_schedd -f<br />
condor 22316 22310 0 09:52 ? 00:00:00 condor_startd -f<br />
condor 22359 22316 93 09:53 ? 00:00:11 mips<br />
</tt><br />
<br />
En ce qui concerne le demon qui gère un worker node (condor_startd), les processeurs disponibles sue la machine locale sont bien reconnus :<br />
<br />
<tt><br />
condor_status<br />
Name OpSys Arch State Activity LoadAv Mem ActvtyTime<br />
<br />
slot1@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:30:11<br />
slot2@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.030 1949 0+00:50:05<br />
slot3@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:06<br />
slot4@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:07<br />
Total Owner Claimed Unclaimed Matched Preempting Backfill<br />
<br />
X86_64/LINUX 4 0 0 4 0 0 0<br />
<br />
Total 4 0 0 4 0 0 0<br />
</tt><br />
<br />
Créer un programme de test (un script shell lançant des exécutables) :<br />
<br />
<tt><br />
more HT-Condor/testprog01.sh<br />
#! /bin/sh<br />
echo "HT-condor testprog01"<br />
echo "I'm process id $$ on" `hostname`<br />
echo "This is sent to standard error" 1>&2<br />
date<br />
echo "Running as binary $0" "$@"<br />
echo "My name (argument 1) is $1"<br />
echo "My sleep duration (argument 2) is $2"<br />
sleep $2<br />
echo "Sleep of $2 seconds finished. Exiting"<br />
exit 0<br />
</tt><br />
<br />
Créer la description du travail :<br />
<br />
<tt><br />
executable=testprog01.sh<br />
universe=vanilla<br />
arguments=Example.$(Cluster).$(Process) 100<br />
output=results.output.$(Process)<br />
error=results.error.$(Process)<br />
log=results.log<br />
notification=never<br />
should_transfer_files=YES<br />
when_to_transfer_output = ON_EXIT<br />
queue<br />
</tt><br />
<br />
Lancer le job :<br />
<br />
<tt><br />
condor_submit testprog01.submit <br />
Submitting job(s).<br />
1 job(s) submitted to cluster 1.<br />
</tt><br />
<br />
En surveiller l'exécution :<br />
<br />
<tt><br />
condor_q<br />
<br />
-- Submitter: nanpc117.in2p3.fr : <134.158.25.117:39976> : nanpc117.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
1.0 untel 8/4 09:57 0+00:00:05 R 0 0.0 testprog01.sh Exam<br />
<br />
1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended<br />
</tt><br />
<br />
Fin du job : les fichiers demandés sont là :<br />
<br />
<tt><br />
ls<br />
results.error.0 results.output.0 testprog01.submit<br />
results.log testprog01.sh<br />
</tt><br />
<br />
==== Installation type cluster local ====<br />
<br />
==== Utilisation en contexte grille ====<br />
<br />
==== Sécurité ====</div>
Barbet
https://lcg.in2p3.fr/index.php?title=HT-Condor&diff=7494
HT-Condor
2015-08-10T13:35:02Z
<p>Barbet: /* Installation personnelle : configuration et premiers tests */</p>
<hr />
<div>Démarrer avec HT-Condor<br />
=== Démarrer avec HT-Condor ===<br />
<br />
[Page en cours de création]<br />
<br />
==== Documentation et références ====<br />
<br />
Site de référence : http://research.cs.wisc.edu/htcondor/<br />
<br />
Wiki : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki<br />
<br />
Recettes Administrateur : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToAdminRecipes<br />
<br />
Manuel (version stable 8.2) : http://research.cs.wisc.edu/htcondor/manual/v8.2/index.html<br />
<br />
==== Repositories et installation ====<br />
<br />
http://research.cs.wisc.edu/htcondor/yum/<br />
<br />
<tt><br />
cd /etc/yum.repos.d/<br />
wget http://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel6.repo<br />
yum install condor<br />
</tt><br />
<br />
Attention: condor est aussi distribué via les repositories UMD, il peut être nécessaire de désactiver ces repositories ou bien d'utiliser les priorités avec YUM.<br />
<br />
==== Installation personnelle : configuration et premiers tests ====<br />
<br />
La configuration par défaut après l'installation du RPM permet de tester le produit sur une seule machine. Dans ce cas, sur la même machine, on trouve les trois types de noeuds : <i>submit node</i>, <i>master node</i> et <i>worker node</i>.<br />
<br />
Démarrer les demons :<br />
<br />
<tt><br />
service condor start<br />
Starting up Condor... done.<br />
<br />
service condor status<br />
Condor is running (pid 22310)<br />
</tt><br />
Les processus suivants sont lancés :<br />
<tt><br />
ps -ef | grep condor<br />
condor 22310 1 0 09:52 ? 00:00:00 /usr/sbin/condor_master -pidfile /var/run/condor/condor.pid<br />
root 22311 22310 0 09:52 ? 00:00:00 condor_procd -A /var/run/condor/procd_pipe -L /var/log/condor/ProcLog -R 1000000 -S 60 -C 493<br />
condor 22312 22310 0 09:52 ? 00:00:00 condor_collector -f<br />
condor 22314 22310 0 09:52 ? 00:00:00 condor_negotiator -f<br />
condor 22315 22310 0 09:52 ? 00:00:00 condor_schedd -f<br />
condor 22316 22310 0 09:52 ? 00:00:00 condor_startd -f<br />
condor 22359 22316 93 09:53 ? 00:00:11 mips<br />
</tt><br />
<br />
En ce qui concerne le demon qui gère un worker node (condor_startd), les processeurs disponibles sue la machine locale sont bien reconnus :<br />
<br />
<tt><br />
condor_status<br />
Name OpSys Arch State Activity LoadAv Mem ActvtyTime<br />
<br />
slot1@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:30:11<br />
slot2@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.030 1949 0+00:50:05<br />
slot3@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:06<br />
slot4@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:07<br />
Total Owner Claimed Unclaimed Matched Preempting Backfill<br />
<br />
X86_64/LINUX 4 0 0 4 0 0 0<br />
<br />
Total 4 0 0 4 0 0 0<br />
</tt><br />
<br />
Créer un programme de test (un script shell lançant des exécutables) :<br />
<br />
<tt><br />
more HT-Condor/testprog01.sh<br />
#! /bin/sh<br />
echo "HT-condor testprog01"<br />
echo "I'm process id $$ on" `hostname`<br />
echo "This is sent to standard error" 1>&2<br />
date<br />
echo "Running as binary $0" "$@"<br />
echo "My name (argument 1) is $1"<br />
echo "My sleep duration (argument 2) is $2"<br />
sleep $2<br />
echo "Sleep of $2 seconds finished. Exiting"<br />
exit 0<br />
</tt><br />
<br />
Créer la description du travail :<br />
<br />
<tt><br />
executable=testprog01.sh<br />
universe=vanilla<br />
arguments=Example.$(Cluster).$(Process) 100<br />
output=results.output.$(Process)<br />
error=results.error.$(Process)<br />
log=results.log<br />
notification=never<br />
should_transfer_files=YES<br />
when_to_transfer_output = ON_EXIT<br />
queue<br />
</tt><br />
<br />
Lancer le job :<br />
<br />
<tt><br />
condor_submit testprog01.submit <br />
Submitting job(s).<br />
1 job(s) submitted to cluster 1.<br />
</tt><br />
<br />
En surveiller l'exécution :<br />
<br />
<tt><br />
condor_q<br />
<br />
<br />
-- Submitter: nanpc117.in2p3.fr : <134.158.25.117:39976> : nanpc117.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
1.0 untel 8/4 09:57 0+00:00:05 R 0 0.0 testprog01.sh Exam<br />
<br />
1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended<br />
</tt><br />
<br />
Fin du job : les fichiers demandés sont là :<br />
<br />
<tt><br />
ls<br />
results.error.0 results.output.0 testprog01.submit<br />
results.log testprog01.sh<br />
</tt><br />
<br />
==== Installation type cluster local ====<br />
<br />
==== Utilisation en contexte grille ====<br />
<br />
==== Sécurité ====</div>
Barbet
https://lcg.in2p3.fr/index.php?title=HT-Condor&diff=7493
HT-Condor
2015-08-10T13:34:36Z
<p>Barbet: /* Installation personnelle : configuration et premiers tests */</p>
<hr />
<div>Démarrer avec HT-Condor<br />
=== Démarrer avec HT-Condor ===<br />
<br />
[Page en cours de création]<br />
<br />
==== Documentation et références ====<br />
<br />
Site de référence : http://research.cs.wisc.edu/htcondor/<br />
<br />
Wiki : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki<br />
<br />
Recettes Administrateur : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToAdminRecipes<br />
<br />
Manuel (version stable 8.2) : http://research.cs.wisc.edu/htcondor/manual/v8.2/index.html<br />
<br />
==== Repositories et installation ====<br />
<br />
http://research.cs.wisc.edu/htcondor/yum/<br />
<br />
<tt><br />
cd /etc/yum.repos.d/<br />
wget http://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel6.repo<br />
yum install condor<br />
</tt><br />
<br />
Attention: condor est aussi distribué via les repositories UMD, il peut être nécessaire de désactiver ces repositories ou bien d'utiliser les priorités avec YUM.<br />
<br />
==== Installation personnelle : configuration et premiers tests ====<br />
<br />
La configuration par défaut après l'installation du RPM permet de tester le produit sur une seule machine. Dans ce cas, sur la même machine, on trouve les trois types de noeuds : <i>submit node</i>, <i>master node</i> et <i>worker node</i>.<br />
<br />
Démarrer les demons :<br />
<br />
<tt><br />
service condor start<br />
Starting up Condor... done.<br />
<br />
service condor status<br />
Condor is running (pid 22310)<br />
</tt><br />
Les processus suivants sont lancés :<br />
<tt><br />
ps -ef | grep condor<br />
condor 22310 1 0 09:52 ? 00:00:00 /usr/sbin/condor_master -pidfile /var/run/condor/condor.pid<br />
root 22311 22310 0 09:52 ? 00:00:00 condor_procd -A /var/run/condor/procd_pipe -L /var/log/condor/ProcLog -R 1000000 -S 60 -C 493<br />
condor 22312 22310 0 09:52 ? 00:00:00 condor_collector -f<br />
condor 22314 22310 0 09:52 ? 00:00:00 condor_negotiator -f<br />
condor 22315 22310 0 09:52 ? 00:00:00 condor_schedd -f<br />
condor 22316 22310 0 09:52 ? 00:00:00 condor_startd -f<br />
condor 22359 22316 93 09:53 ? 00:00:11 mips<br />
</tt><br />
<br />
En ce qui concerne le demon qui gère un worker node (condor_startd), les processeurs disponibles sue la machine locale sont bien reconnus :<br />
<br />
<tt><br />
condor_status<br />
Name OpSys Arch State Activity LoadAv Mem ActvtyTime<br />
<br />
slot1@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:30:11<br />
slot2@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.030 1949 0+00:50:05<br />
slot3@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:06<br />
slot4@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:07<br />
Total Owner Claimed Unclaimed Matched Preempting Backfill<br />
<br />
X86_64/LINUX 4 0 0 4 0 0 0<br />
<br />
Total 4 0 0 4 0 0 0<br />
</tt><br />
<br />
Créer un programme de test (un script shell lançant des exécutables) :<br />
<br />
<tt><br />
more HT-Condor/testprog01.sh<br />
#! /bin/sh<br />
echo "HT-condor testprog01"<br />
echo "I'm process id $$ on" `hostname`<br />
echo "This is sent to standard error" 1>&2<br />
date<br />
echo "Running as binary $0" "$@"<br />
echo "My name (argument 1) is $1"<br />
echo "My sleep duration (argument 2) is $2"<br />
sleep $2<br />
echo "Sleep of $2 seconds finished. Exiting"<br />
exit 0<br />
</tt><br />
<br />
Créer la description du travail :<br />
<br />
<tt><br />
executable=testprog01.sh<br />
universe=vanilla<br />
arguments=Example.$(Cluster).$(Process) 100<br />
output=results.output.$(Process)<br />
error=results.error.$(Process)<br />
log=results.log<br />
notification=never<br />
should_transfer_files=YES<br />
when_to_transfer_output = ON_EXIT<br />
queue<br />
</tt><br />
<br />
Lancer le job :<br />
<br />
<tt><br />
condor_submit testprog01.submit <br />
Submitting job(s).<br />
1 job(s) submitted to cluster 1.<br />
</tt><br />
<br />
En surveiller l'exécution :<br />
<br />
<tt><br />
condor_q<br />
<br />
<br />
-- Submitter: nanpc117.in2p3.fr : <134.158.25.117:39976> : nanpc117.in2p3.fr<br />
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD <br />
1.0 untel 8/4 09:57 0+00:00:05 R 0 0.0 testprog01.sh Exam<br />
<br />
1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended<br />
</tt><br />
<br />
Fin du job : les fichiers demandés sont là :<br />
<br />
<tt><br />
ls<br />
results.error.0 results.output.0 testprog01.submit<br />
results.log testprog01.sh<br />
</tt><br />
<br />
==== Installation type cluster local ====<br />
<br />
==== Utilisation en contexte grille ====<br />
<br />
==== Sécurité ====</div>
Barbet