Difference between revisions of "HT-Condor"
(→Réseaux privés, ports de communication, Pares-Feu) |
(→Documentation et références) |
||
| Ligne 15: | Ligne 15: | ||
European HTCondor Site Admins Meeting 2014 : http://indico.cern.ch/event/272794/ | 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 ==== | ==== Repositories et installation ==== | ||
Version du 10:11, 16 mars 2016
Démarrer avec HT-Condor
Sommaire
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
... A développer ...
