lcgwiki - Contributions [en]

HT-Condor

2015-10-08T13:10:31Z

Ghita: /* Réseaux privés, ports de communication, Pares-Feu */

Démarrer avec HT-Condor
=== Démarrer avec HT-Condor ===

[Page en cours de création]

==== Documentation et références ====

Site de référence : http://research.cs.wisc.edu/htcondor/

Wiki : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki

Recettes Administrateur : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToAdminRecipes

Manuel (version stable 8.2) : http://research.cs.wisc.edu/htcondor/manual/v8.2/index.html

European HTCondor Site Admins Meeting 2014 : http://indico.cern.ch/event/272794/

==== Repositories et installation ====

http://research.cs.wisc.edu/htcondor/yum/

<tt>
cd /etc/yum.repos.d/
wget http://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel6.repo
yum install condor
</tt>

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.

==== Installation personnelle : configuration et premiers tests ====

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 : submit node, master node et worker node.

Démarrer les demons :

<tt>
service condor start
Starting up Condor... done.

service condor status
Condor is running (pid 22310)
</tt>
Les processus suivants sont lancés :
<tt>
ps -ef | grep condor
condor 22310 1 0 09:52 ? 00:00:00 /usr/sbin/condor_master -pidfile /var/run/condor/condor.pid
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
condor 22312 22310 0 09:52 ? 00:00:00 condor_collector -f
condor 22314 22310 0 09:52 ? 00:00:00 condor_negotiator -f
condor 22315 22310 0 09:52 ? 00:00:00 condor_schedd -f
condor 22316 22310 0 09:52 ? 00:00:00 condor_startd -f
condor 22359 22316 93 09:53 ? 00:00:11 mips
</tt>

En ce qui concerne le demon qui gère un worker node (condor_startd), les processeurs disponibles sue la machine locale sont bien reconnus :

<tt>
condor_status
Name OpSys Arch State Activity LoadAv Mem ActvtyTime

slot1@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:30:11
slot2@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.030 1949 0+00:50:05
slot3@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:06
slot4@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:07
Total Owner Claimed Unclaimed Matched Preempting Backfill

X86_64/LINUX 4 0 0 4 0 0 0

Total 4 0 0 4 0 0 0
</tt>

Créer un programme de test (un script shell lançant des exécutables) :

<tt>
more HT-Condor/testprog01.sh
#! /bin/sh
echo "HT-condor testprog01"
echo "I'm process id $$ on" `hostname`
echo "This is sent to standard error" 1>&2
date
echo "Running as binary $0" "$@"
echo "My name (argument 1) is $1"
echo "My sleep duration (argument 2) is $2"
sleep $2
echo "Sleep of $2 seconds finished. Exiting"
exit 0
</tt>

Créer la description du travail :

<tt>
executable=testprog01.sh
universe=vanilla
arguments=Example.$(Cluster).$(Process) 100
output=results.output.$(Process)
error=results.error.$(Process)
log=results.log
notification=never
should_transfer_files=YES
when_to_transfer_output = ON_EXIT
queue
</tt>

Lancer le job :

<tt>
condor_submit testprog01.submit
Submitting job(s).
1 job(s) submitted to cluster 1.
</tt>

En surveiller l'exécution :

<tt>
condor_q

-- Submitter: nanpc117.in2p3.fr : <134.158.25.117:39976> : nanpc117.in2p3.fr
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD
1.0 untel 8/4 09:57 0+00:00:05 R 0 0.0 testprog01.sh Exam

1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended
</tt>

Fin du job : les fichiers demandés sont là :

<tt>
ls
results.error.0 results.output.0 testprog01.submit
results.log testprog01.sh
</tt>

==== Installation type cluster local ====

Le cluster de compose de :

* une machine qui joue le rôle de serveur de batch (demons : condor_master, condor_collector, condor_negotiator)
* une ou plusieurs machines pouvant soumettre des travaux (demon : condor_shedd)
* les machines devant exécuter les travaux (worker nodes) (demons : )

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

Exemple de fichier global /etc/condor/condor_config.local :

<tt>
# 0-General-Settings-and-Macros

UID_DOMAIN = htcondor-grid@subatech.in2p3.fr
CENTRAL_MANAGER1 = nanpbs3.in2p3.fr
COLLECTOR_HOST = $(CENTRAL_MANAGER1)
CONDOR_HOST=$(CENTRAL_MANAGER1)

EVENT_LOG = EventLog

# 1-Use-Security

# 2-Policies

SEC_DEFAULT_AUTHENTICATION = REQUIRED

# 3-Authorizations

ALLOW_WRITE =
ALLOW_READ = */*.in2p3.fr
ALLOW_DAEMON = *.in2p3.fr
ALLOW_ADMINISTRATOR = root@$(CONDOR_HOST)
ALLOW_CONFIG = root@$(FULL_HOSTNAME)

# 4-Authentication
SEC_PASSWORD_FILE = /etc/condor/pool_password
SEC_READ_AUTHENTICATION = OPTIONAL
SEC_CLIENT_AUTHENTICATION = REQUIRED
SEC_DEFAULT_AUTHENTICATION_METHODS = PASSWORD,FS
SCHEDD.SEC_WRITE_AUTHENTICATION_METHODS = FS,PASSWORD
SCHEDD.SEC_DAEMON_AUTHENTICATION_METHODS = FS,PASSWORD
SEC_CLIENT_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE
SEC_READ_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE
</tt>

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 :

<tt>
condor_store_cred -f /etc/condor/pool_password
Enter password: xxxxxx
</tt>

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.

===== Configuration du serveur de batch (nanpbs3.in2p3.fr) =====

Dans cet exemple, le serveur de batch est aussi machine de soumission (il dispose des mêmes comptes que sur les worker nodes)

Creation d'un fichier supplémentaire /etc/condor/config.d/20-master.conf :

<tt>
DAEMON_LIST = COLLECTOR, MASTER, NEGOTIATOR, SCHEDD
</tt>

Redémarrage avec la nouvelle config :

<tt>
service condor restart
</tt>

<tt>
condor_status -any
MyType TargetType Name

Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.
Scheduler None nanpbs3.in2p3.fr
DaemonMaster None nanpbs3.in2p3.fr
Negotiator None nanpbs3.in2p3.fr
</tt>

===== Configuration d'un worker node (nanwn58.in2p3.fr) =====

Creation d'un fichier supplémentaire /etc/condor/config.d/10-workernode.conf :

<tt>
DAEMON_LIST = MASTER, STARTD
TRUST_UID_DOMAIN=TRUE
</tt>

Redémarrage avec la nouvelle config :

<tt>
service condor restart
</tt>

<tt>
condor_status -any
MyType TargetType Name

Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.
Scheduler None nanpbs3.in2p3.fr
DaemonMaster None nanpbs3.in2p3.fr
Negotiator None nanpbs3.in2p3.fr
DaemonMaster None nanwn58.in2p3.fr
Machine Job slot1@nanwn58.in2p3.fr
Machine Job slot2@nanwn58.in2p3.fr
Machine Job slot3@nanwn58.in2p3.fr
Machine Job slot4@nanwn58.in2p3.fr
Machine Job slot5@nanwn58.in2p3.fr
Machine Job slot6@nanwn58.in2p3.fr
Machine Job slot7@nanwn58.in2p3.fr
Machine Job slot8@nanwn58.in2p3.fr
</tt>

Examen de la queue depuis le server et submitter :
<tt>
[root@nanpbs3 ~]# condor_q

-- Submitter: nanpbs3.in2p3.fr : <193.48.101.50:58431> : nanpbs3.in2p3.fr
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD

0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended
</tt>

===== Réseaux privés, ports de communication, Pares-Feu =====

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

<tt>
# To expand your condor pool beyond a single host, set ALLOW_WRITE to match all of the hosts (last one is ccgr2 Mac)
ALLOW_WRITE = $(ALLOW_WRITE) ,$(CONDOR_HOST) , worker1, worker2, ......
Define the ports used by condor
#NEGOTIATOR_SOCKET_CACHE_SIZE = 16
LOWPORT = 9600
HIGHPORT= 9625
</tt>
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

Un exemple d'ouverture de ports entre ma VM qui est le CM et mon MAC qui est un de mes worker-nodes:
<tt>
- en entree vers mon mac :
permit tcp host 172.xxx host 134.yyy range 9600 9625
permit udp host 172.xxxx host 134.yyy range 9600 9625
-en entree vers le serveur condor :
permit tcp host 134.yyy host 172.xxx range 9600 9625
permit udp host 134.yyy host 172.xxx range 9600 9625
</tt>

===== Gestion des ressources, priorités et comptabilité (accounting) =====

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 :
<tt>
# accounting group
accounting_group = group_info
</tt>

... A développer ...

==== Utilisation en contexte grille ====

==== Sécurité ====

HT-Condor

2015-10-08T13:02:34Z

Ghita: /* Réseaux privés, ports de communication, Pares-Feu */

Démarrer avec HT-Condor
=== Démarrer avec HT-Condor ===

[Page en cours de création]

==== Documentation et références ====

Site de référence : http://research.cs.wisc.edu/htcondor/

Wiki : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki

Recettes Administrateur : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToAdminRecipes

Manuel (version stable 8.2) : http://research.cs.wisc.edu/htcondor/manual/v8.2/index.html

European HTCondor Site Admins Meeting 2014 : http://indico.cern.ch/event/272794/

==== Repositories et installation ====

http://research.cs.wisc.edu/htcondor/yum/

<tt>
cd /etc/yum.repos.d/
wget http://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel6.repo
yum install condor
</tt>

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.

==== Installation personnelle : configuration et premiers tests ====

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 : submit node, master node et worker node.

Démarrer les demons :

<tt>
service condor start
Starting up Condor... done.

service condor status
Condor is running (pid 22310)
</tt>
Les processus suivants sont lancés :
<tt>
ps -ef | grep condor
condor 22310 1 0 09:52 ? 00:00:00 /usr/sbin/condor_master -pidfile /var/run/condor/condor.pid
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
condor 22312 22310 0 09:52 ? 00:00:00 condor_collector -f
condor 22314 22310 0 09:52 ? 00:00:00 condor_negotiator -f
condor 22315 22310 0 09:52 ? 00:00:00 condor_schedd -f
condor 22316 22310 0 09:52 ? 00:00:00 condor_startd -f
condor 22359 22316 93 09:53 ? 00:00:11 mips
</tt>

En ce qui concerne le demon qui gère un worker node (condor_startd), les processeurs disponibles sue la machine locale sont bien reconnus :

<tt>
condor_status
Name OpSys Arch State Activity LoadAv Mem ActvtyTime

slot1@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:30:11
slot2@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.030 1949 0+00:50:05
slot3@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:06
slot4@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:07
Total Owner Claimed Unclaimed Matched Preempting Backfill

X86_64/LINUX 4 0 0 4 0 0 0

Total 4 0 0 4 0 0 0
</tt>

Créer un programme de test (un script shell lançant des exécutables) :

<tt>
more HT-Condor/testprog01.sh
#! /bin/sh
echo "HT-condor testprog01"
echo "I'm process id $$ on" `hostname`
echo "This is sent to standard error" 1>&2
date
echo "Running as binary $0" "$@"
echo "My name (argument 1) is $1"
echo "My sleep duration (argument 2) is $2"
sleep $2
echo "Sleep of $2 seconds finished. Exiting"
exit 0
</tt>

Créer la description du travail :

<tt>
executable=testprog01.sh
universe=vanilla
arguments=Example.$(Cluster).$(Process) 100
output=results.output.$(Process)
error=results.error.$(Process)
log=results.log
notification=never
should_transfer_files=YES
when_to_transfer_output = ON_EXIT
queue
</tt>

Lancer le job :

<tt>
condor_submit testprog01.submit
Submitting job(s).
1 job(s) submitted to cluster 1.
</tt>

En surveiller l'exécution :

<tt>
condor_q

-- Submitter: nanpc117.in2p3.fr : <134.158.25.117:39976> : nanpc117.in2p3.fr
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD
1.0 untel 8/4 09:57 0+00:00:05 R 0 0.0 testprog01.sh Exam

1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended
</tt>

Fin du job : les fichiers demandés sont là :

<tt>
ls
results.error.0 results.output.0 testprog01.submit
results.log testprog01.sh
</tt>

==== Installation type cluster local ====

Le cluster de compose de :

* une machine qui joue le rôle de serveur de batch (demons : condor_master, condor_collector, condor_negotiator)
* une ou plusieurs machines pouvant soumettre des travaux (demon : condor_shedd)
* les machines devant exécuter les travaux (worker nodes) (demons : )

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

Exemple de fichier global /etc/condor/condor_config.local :

<tt>
# 0-General-Settings-and-Macros

UID_DOMAIN = htcondor-grid@subatech.in2p3.fr
CENTRAL_MANAGER1 = nanpbs3.in2p3.fr
COLLECTOR_HOST = $(CENTRAL_MANAGER1)
CONDOR_HOST=$(CENTRAL_MANAGER1)

EVENT_LOG = EventLog

# 1-Use-Security

# 2-Policies

SEC_DEFAULT_AUTHENTICATION = REQUIRED

# 3-Authorizations

ALLOW_WRITE =
ALLOW_READ = */*.in2p3.fr
ALLOW_DAEMON = *.in2p3.fr
ALLOW_ADMINISTRATOR = root@$(CONDOR_HOST)
ALLOW_CONFIG = root@$(FULL_HOSTNAME)

# 4-Authentication
SEC_PASSWORD_FILE = /etc/condor/pool_password
SEC_READ_AUTHENTICATION = OPTIONAL
SEC_CLIENT_AUTHENTICATION = REQUIRED
SEC_DEFAULT_AUTHENTICATION_METHODS = PASSWORD,FS
SCHEDD.SEC_WRITE_AUTHENTICATION_METHODS = FS,PASSWORD
SCHEDD.SEC_DAEMON_AUTHENTICATION_METHODS = FS,PASSWORD
SEC_CLIENT_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE
SEC_READ_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE
</tt>

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 :

<tt>
condor_store_cred -f /etc/condor/pool_password
Enter password: xxxxxx
</tt>

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.

===== Configuration du serveur de batch (nanpbs3.in2p3.fr) =====

Dans cet exemple, le serveur de batch est aussi machine de soumission (il dispose des mêmes comptes que sur les worker nodes)

Creation d'un fichier supplémentaire /etc/condor/config.d/20-master.conf :

<tt>
DAEMON_LIST = COLLECTOR, MASTER, NEGOTIATOR, SCHEDD
</tt>

Redémarrage avec la nouvelle config :

<tt>
service condor restart
</tt>

<tt>
condor_status -any
MyType TargetType Name

Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.
Scheduler None nanpbs3.in2p3.fr
DaemonMaster None nanpbs3.in2p3.fr
Negotiator None nanpbs3.in2p3.fr
</tt>

===== Configuration d'un worker node (nanwn58.in2p3.fr) =====

Creation d'un fichier supplémentaire /etc/condor/config.d/10-workernode.conf :

<tt>
DAEMON_LIST = MASTER, STARTD
TRUST_UID_DOMAIN=TRUE
</tt>

Redémarrage avec la nouvelle config :

<tt>
service condor restart
</tt>

<tt>
condor_status -any
MyType TargetType Name

Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.
Scheduler None nanpbs3.in2p3.fr
DaemonMaster None nanpbs3.in2p3.fr
Negotiator None nanpbs3.in2p3.fr
DaemonMaster None nanwn58.in2p3.fr
Machine Job slot1@nanwn58.in2p3.fr
Machine Job slot2@nanwn58.in2p3.fr
Machine Job slot3@nanwn58.in2p3.fr
Machine Job slot4@nanwn58.in2p3.fr
Machine Job slot5@nanwn58.in2p3.fr
Machine Job slot6@nanwn58.in2p3.fr
Machine Job slot7@nanwn58.in2p3.fr
Machine Job slot8@nanwn58.in2p3.fr
</tt>

Examen de la queue depuis le server et submitter :
<tt>
[root@nanpbs3 ~]# condor_q

-- Submitter: nanpbs3.in2p3.fr : <193.48.101.50:58431> : nanpbs3.in2p3.fr
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD

0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended
</tt>

===== Réseaux privés, ports de communication, Pares-Feu =====

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

<tt>
# To expand your condor pool beyond a single host, set ALLOW_WRITE to match all of the hosts (last one is ccgr2 Mac)
ALLOW_WRITE = $(ALLOW_WRITE) ,$(CONDOR_HOST) , worker1, worker2, ......
Define the ports used by condor
#NEGOTIATOR_SOCKET_CACHE_SIZE = 16
LOWPORT = 9600
HIGHPORT= 9625
</tt>
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 ports utilisés par Condor et réseaux: http://www.wolftech.ncsu.edu/support/support/Condor/Firewall

Un exemple d'ouverture de ports entre ma VM qui est le CM et mon MAC qui est un de mes worker-nodes:
<tt>
- en entree vers mon mac :
permit tcp host 172.xxx host 134.yyy range 9600 9625
permit udp host 172.xxxx host 134.yyy range 9600 9625
-en entree vers le serveur condor :
permit tcp host 134.yyy host 172.xxx range 9600 9625
permit udp host 134.yyy host 172.xxx range 9600 9625
</tt>

===== Gestion des ressources, priorités et comptabilité (accounting) =====

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 :
<tt>
# accounting group
accounting_group = group_info
</tt>

... A développer ...

==== Utilisation en contexte grille ====

==== Sécurité ====

HT-Condor

2015-10-08T12:59:59Z

Ghita:

Démarrer avec HT-Condor
=== Démarrer avec HT-Condor ===

[Page en cours de création]

==== Documentation et références ====

Site de référence : http://research.cs.wisc.edu/htcondor/

Wiki : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki

Recettes Administrateur : https://htcondor-wiki.cs.wisc.edu/index.cgi/wiki?p=HowToAdminRecipes

Manuel (version stable 8.2) : http://research.cs.wisc.edu/htcondor/manual/v8.2/index.html

European HTCondor Site Admins Meeting 2014 : http://indico.cern.ch/event/272794/

==== Repositories et installation ====

http://research.cs.wisc.edu/htcondor/yum/

<tt>
cd /etc/yum.repos.d/
wget http://research.cs.wisc.edu/htcondor/yum/repo.d/htcondor-stable-rhel6.repo
yum install condor
</tt>

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.

==== Installation personnelle : configuration et premiers tests ====

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 : submit node, master node et worker node.

Démarrer les demons :

<tt>
service condor start
Starting up Condor... done.

service condor status
Condor is running (pid 22310)
</tt>
Les processus suivants sont lancés :
<tt>
ps -ef | grep condor
condor 22310 1 0 09:52 ? 00:00:00 /usr/sbin/condor_master -pidfile /var/run/condor/condor.pid
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
condor 22312 22310 0 09:52 ? 00:00:00 condor_collector -f
condor 22314 22310 0 09:52 ? 00:00:00 condor_negotiator -f
condor 22315 22310 0 09:52 ? 00:00:00 condor_schedd -f
condor 22316 22310 0 09:52 ? 00:00:00 condor_startd -f
condor 22359 22316 93 09:53 ? 00:00:11 mips
</tt>

En ce qui concerne le demon qui gère un worker node (condor_startd), les processeurs disponibles sue la machine locale sont bien reconnus :

<tt>
condor_status
Name OpSys Arch State Activity LoadAv Mem ActvtyTime

slot1@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:30:11
slot2@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.030 1949 0+00:50:05
slot3@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:06
slot4@testcondor.in2 LINUX X86_64 Unclaimed Idle 0.000 1949 0+00:50:07
Total Owner Claimed Unclaimed Matched Preempting Backfill

X86_64/LINUX 4 0 0 4 0 0 0

Total 4 0 0 4 0 0 0
</tt>

Créer un programme de test (un script shell lançant des exécutables) :

<tt>
more HT-Condor/testprog01.sh
#! /bin/sh
echo "HT-condor testprog01"
echo "I'm process id $$ on" `hostname`
echo "This is sent to standard error" 1>&2
date
echo "Running as binary $0" "$@"
echo "My name (argument 1) is $1"
echo "My sleep duration (argument 2) is $2"
sleep $2
echo "Sleep of $2 seconds finished. Exiting"
exit 0
</tt>

Créer la description du travail :

<tt>
executable=testprog01.sh
universe=vanilla
arguments=Example.$(Cluster).$(Process) 100
output=results.output.$(Process)
error=results.error.$(Process)
log=results.log
notification=never
should_transfer_files=YES
when_to_transfer_output = ON_EXIT
queue
</tt>

Lancer le job :

<tt>
condor_submit testprog01.submit
Submitting job(s).
1 job(s) submitted to cluster 1.
</tt>

En surveiller l'exécution :

<tt>
condor_q

-- Submitter: nanpc117.in2p3.fr : <134.158.25.117:39976> : nanpc117.in2p3.fr
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD
1.0 untel 8/4 09:57 0+00:00:05 R 0 0.0 testprog01.sh Exam

1 jobs; 0 completed, 0 removed, 0 idle, 1 running, 0 held, 0 suspended
</tt>

Fin du job : les fichiers demandés sont là :

<tt>
ls
results.error.0 results.output.0 testprog01.submit
results.log testprog01.sh
</tt>

==== Installation type cluster local ====

Le cluster de compose de :

* une machine qui joue le rôle de serveur de batch (demons : condor_master, condor_collector, condor_negotiator)
* une ou plusieurs machines pouvant soumettre des travaux (demon : condor_shedd)
* les machines devant exécuter les travaux (worker nodes) (demons : )

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

Exemple de fichier global /etc/condor/condor_config.local :

<tt>
# 0-General-Settings-and-Macros

UID_DOMAIN = htcondor-grid@subatech.in2p3.fr
CENTRAL_MANAGER1 = nanpbs3.in2p3.fr
COLLECTOR_HOST = $(CENTRAL_MANAGER1)
CONDOR_HOST=$(CENTRAL_MANAGER1)

EVENT_LOG = EventLog

# 1-Use-Security

# 2-Policies

SEC_DEFAULT_AUTHENTICATION = REQUIRED

# 3-Authorizations

ALLOW_WRITE =
ALLOW_READ = */*.in2p3.fr
ALLOW_DAEMON = *.in2p3.fr
ALLOW_ADMINISTRATOR = root@$(CONDOR_HOST)
ALLOW_CONFIG = root@$(FULL_HOSTNAME)

# 4-Authentication
SEC_PASSWORD_FILE = /etc/condor/pool_password
SEC_READ_AUTHENTICATION = OPTIONAL
SEC_CLIENT_AUTHENTICATION = REQUIRED
SEC_DEFAULT_AUTHENTICATION_METHODS = PASSWORD,FS
SCHEDD.SEC_WRITE_AUTHENTICATION_METHODS = FS,PASSWORD
SCHEDD.SEC_DAEMON_AUTHENTICATION_METHODS = FS,PASSWORD
SEC_CLIENT_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE
SEC_READ_AUTHENTICATION_METHODS = FS,PASSWORD,CLAIMTOBE
</tt>

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 :

<tt>
condor_store_cred -f /etc/condor/pool_password
Enter password: xxxxxx
</tt>

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.

===== Configuration du serveur de batch (nanpbs3.in2p3.fr) =====

Dans cet exemple, le serveur de batch est aussi machine de soumission (il dispose des mêmes comptes que sur les worker nodes)

Creation d'un fichier supplémentaire /etc/condor/config.d/20-master.conf :

<tt>
DAEMON_LIST = COLLECTOR, MASTER, NEGOTIATOR, SCHEDD
</tt>

Redémarrage avec la nouvelle config :

<tt>
service condor restart
</tt>

<tt>
condor_status -any
MyType TargetType Name

Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.
Scheduler None nanpbs3.in2p3.fr
DaemonMaster None nanpbs3.in2p3.fr
Negotiator None nanpbs3.in2p3.fr
</tt>

===== Configuration d'un worker node (nanwn58.in2p3.fr) =====

Creation d'un fichier supplémentaire /etc/condor/config.d/10-workernode.conf :

<tt>
DAEMON_LIST = MASTER, STARTD
TRUST_UID_DOMAIN=TRUE
</tt>

Redémarrage avec la nouvelle config :

<tt>
service condor restart
</tt>

<tt>
condor_status -any
MyType TargetType Name

Collector None My Pool - nanpbs3.in2p3.fr@nanpbs3.in2p3.
Scheduler None nanpbs3.in2p3.fr
DaemonMaster None nanpbs3.in2p3.fr
Negotiator None nanpbs3.in2p3.fr
DaemonMaster None nanwn58.in2p3.fr
Machine Job slot1@nanwn58.in2p3.fr
Machine Job slot2@nanwn58.in2p3.fr
Machine Job slot3@nanwn58.in2p3.fr
Machine Job slot4@nanwn58.in2p3.fr
Machine Job slot5@nanwn58.in2p3.fr
Machine Job slot6@nanwn58.in2p3.fr
Machine Job slot7@nanwn58.in2p3.fr
Machine Job slot8@nanwn58.in2p3.fr
</tt>

Examen de la queue depuis le server et submitter :
<tt>
[root@nanpbs3 ~]# condor_q

-- Submitter: nanpbs3.in2p3.fr : <193.48.101.50:58431> : nanpbs3.in2p3.fr
ID OWNER SUBMITTED RUN_TIME ST PRI SIZE CMD

0 jobs; 0 completed, 0 removed, 0 idle, 0 running, 0 held, 0 suspended
</tt>

===== Réseaux privés, ports de communication, Pares-Feu =====

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

<tt>
# To expand your condor pool beyond a single host, set ALLOW_WRITE to match all of the hosts (last one is ccgr2 Mac)
ALLOW_WRITE = $(ALLOW_WRITE) ,$(CONDOR_HOST) , worker1, worker2, ......

Define the ports used by condor
#NEGOTIATOR_SOCKET_CACHE_SIZE = 16
LOWPORT = 9600
HIGHPORT= 9625
</tt>
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 ports utilisés par Condor et réseaux: http://www.wolftech.ncsu.edu/support/support/Condor/Firewall

Un exemple d'ouverture de ports entre ma VM qui est le CM et mon MAC qui est un de mes worker-nodes:
<tt>
- en entree vers mon mac :
permit tcp host 172.xxx host 134.yyy range 9600 9625
permit udp host 172.xxxx host 134.yyy range 9600 9625
-en entree vers le serveur condor :
permit tcp host 134.yyy host 172.xxx range 9600 9625
permit udp host 134.yyy host 172.xxx range 9600 9625
</tt>

===== Gestion des ressources, priorités et comptabilité (accounting) =====

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 :
<tt>
# accounting group
accounting_group = group_info
</tt>

... A développer ...

==== Utilisation en contexte grille ====

==== Sécurité ====