Difference between revisions of "HT-Condor"

Un article de lcgwiki.
Jump to: navigation, search
(→‎Documentation et références)
 
(One intermediate revision by the same user not shown)
Ligne 295: Ligne 295:
 
</tt>
 
</tt>
  
−
... A développer ...
+
==== Utilisation en contexte grille ====
 +
 
 +
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 :
 +
 
 +
* CREAM-CE
 +
* ARC-CE
 +
* HT-Condor-CE
 +
 
 +
===== Configuration HT-Condor et ARC-CE =====
 +
 
 +
==== Tips and tricks ====
 +
 
  
−
==== Utilisation en contexte grille ====
 
  
 
==== Sécurité ====
 
==== Sécurité ====

Latest revision as of 10:18, 15 novembre 2018

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/

Workshop HT-Condor / ARC-CE, Cerdanyola-del-Vallès, 2016 : https://indico.cern.ch/event/467075/

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

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

#  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

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: 

- 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

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 : 

# accounting group
accounting_group = group_info

Utilisation en contexte grille

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 :

  • CREAM-CE
  • ARC-CE
  • HT-Condor-CE
Configuration HT-Condor et ARC-CE

Tips and tricks

Sécurité

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