Difference between revisions of "HT-Condor"

Un article de lcgwiki.
Jump to: navigation, search
(→‎Installation personnelle : configuration et premiers tests)
(→‎Installation type cluster local)
Ligne 129: Ligne 129:
  
 
==== Installation type cluster local ====
 
==== 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>
  
 
==== Utilisation en contexte grille ====
 
==== Utilisation en contexte grille ====
  
 
==== Sécurité ====
 
==== Sécurité ====

Version du 10:10, 12 août 2015

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

Repositories et installation

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

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

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 : 

service condor start
Starting up Condor...    done.

service condor status
Condor is running (pid 22310)

Les processus suivants sont lancés : 

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

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

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

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

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

Créer la description du travail : 

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

Lancer le job : 

condor_submit testprog01.submit 
Submitting job(s).
1 job(s) submitted to cluster 1.

En surveiller l'exécution : 

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

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

ls
results.error.0  results.output.0  testprog01.submit
results.log      testprog01.sh

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 : 

# 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

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 : 

condor_store_cred -f /etc/condor/pool_password
Enter password: xxxxxx

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 : 

DAEMON_LIST = COLLECTOR, MASTER, NEGOTIATOR, SCHEDD

Redémarrage avec la nouvelle config : 

service condor restart


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

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

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

DAEMON_LIST = MASTER, STARTD
TRUST_UID_DOMAIN=TRUE

Redémarrage avec la nouvelle config : 

service condor restart


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

Examen de la queue depuis le server et submitter : 

[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

Utilisation en contexte grille

Sécurité

Récupérée de « http://lcg.in2p3.fr/wiki/index.php?title=HT-Condor&oldid=7496 »