Pool Condor

From Atlmiwiki

Il sito INFN-MILANO-ATLASC ospita due batch systems Condor nella sala C, PBS nella sala N. L'architettura prevede:

   * t2-ce-02: CE, con configurazione aggiornata e resistente agli aggiornamenti via YAIM (sempre con SCHEDD attivo).
   * t2cmcondor-125: CentralManager, coi sottosistemi COLLECTOR (per la gestione del pool) e NEGOTIATOR (per il matching job/workernode) attivi
   * wn-b1-XX: Pool di macchine di calcolo col sottosistema STARTD (esecuzione jobs) attivo 

il software condor si installa a partire da un package standard su ogni tipo di macchina, scaricato dal sito ufficiale

Contents

Configurazione CE 'nuovo' (t2-ce-02)

  • Il nodo e' installato innanzitutto come CE 'infn-grid' seguendo le istruzioni per il profilo 'ig_CE' qui: [1]
 NOTA: Sono state configurate due interfacce di rete, una (eth0) sulla rete pubblica (192.135.14.X) con MTU 1500 e una sulle reti private
 (192.168.125/127) con MTU 9000. Come per ogni configurazione dove piu' di una interfaccia e' collegata allo stesso segmento di rete,
 e' stato settato in sysctl (e /etc/sysctl.conf):
 net.ipv4.conf.all.arp_filter = 1
 
  • E' stato installato l'RPM di Condor, scaricato dal sito ufficiale indicato sopra:
 rpm -ihv condor-7.4.1-linux-x86-rhel3-dynamic-1.i386.rpm
  • E' stato creato questo symlink alla versione corrente di Condor:
 ln -s /opt/condor-7.4.1/ /opt/condor
  • e questo symlink nella locazione di 'default' della configurazione, che rende i comandi interattivi meno dipendenti dall'environment:
 mkdir /etc/condor
 ln -s /opt/condor/etc/condor_config /etc/condor
  • E' stato installato questo modulo di configurazione delle 'pseudocode' di Condor: /opt/glite/bin/pseudoqueue_config.pl ed e' stato creato un symlink per poterlo utilizzare come info provider:
 ln -s /opt/glite/bin/pseudoqueue_config.pl /opt/glite/libexec/glite-info-dynamic-condor

Questo modulo utilizza un file di configurazione (/opt/glite/etc/pseudoqueue_config.conf) che ha la sola funzione di permettere di sovrascrivere il valore di alcuni attributi:

 > cat /opt/glite/etc/pseudoqueue_config.conf   
 #
 # Configuration file for /opt/glite/bin/pseudoqueue_config.pl
 # Each line specifies a key=value pair. The corresponding attribute
 # is set for *all* LDIF objects found by pseudoqueue_config.pl
 # and takes precedence over any finding of the script
 #
 #GlueCEStateStatus = Draining
  • Sono stati creati gli account e l'area di esecuzione per Condor:
  groupadd -g 999 condor
  useradd -g 999 -u 9991 condor
  mkdir /var/condor
  chown condor.condor /var/condor
  mkdir /var/condor/log
  mkdir /var/condor/spool
  mkdir /var/condor/execute
  chown condor.condor /var/condor/log
  chown condor.condor /var/condor/spool
  chown condor.condor /var/condor/execute
  chmod 777 /var/condor/execute
  chmod o+t /var/condor/execute
  • E' stato modificato il setting di LOCAL_CONFIG_FILE in /opt/condor/etc/condor_config:
 LOCAL_CONFIG_FILE = /opt/glite/bin/pseudoqueue_config.pl -c /opt/condor/local.t2-ce-02/condor_config.local|
  • E' stato fatto partire Condor:
  /etc/init.d/condor start
  • E' stata applicata una ulteriore patch a /usr/opt/glite/yaim/functions/local/config_dgas_ce per rendere alcuni parametri configurabili [2] - Nota: questa patch deve essere ancora segnalata a INFN-GRID.
  • E' stata applicata una patch a /opt/glite/sbin/glite-urcollector.pl per impedire al ciclo di lettura di condor_history di arrestarsi in corrispondenza ai job cancellati [3]. Patch segnalata agli sviluppatori di DGAS.
  • E' stata applicata una patch a /usr/opt/globus/setup/globus/lcgcondor.in [4]. La prima parte della patch (collocazione dell'area per gli userlog Condor) e' stata segnalata nel baco di Savannah #56783. Non si sa cosa ne succedera'. La seconda parte e' relativa alla gestione locale delle quote e delle 'pseudocode'.
  • E' stato installato questo RPM (proveniente da questo sito):
 rpm -ihv glite-apel-condor-2.0.6-2.noarch.rpm
  CE_condor_FUNCTIONS="${CE_FUNCTIONS}
  config_apel_condor
  config_gip_sched_plugin_condor
  "
  • E' stata installata la configurazione di site di YAIM in /root/siteinfo (come in questo tarfile).
  • E' stato infine (...) fatto girare yaim:
  /opt/glite/yaim/bin/ig_yaim -c -s /root/siteinfo/ig-site-info.def -n ig_CE_condor
  • L'installazione e' stata quindi verificata con globusrun.

Configurazione CE 'vecchio' (ce-b1-1)

  • Controllare sul CE la presenza del comando:

export GLOBUS_SPOOL_DIR=/opt/globus/tmp/gram_job_state nel file /etc/sysconfig/globus diversamente il polling della coda jobs non funzionerà
Attualmente è stato reso immutabile, per evitare improvvisi malfunzionamenti

  • Lo stesso file di configurazione deve essere letto dal servizio globus-gma /etc/init.d/globus-gma

altrimenti il polling legge i files di log relativi ai jobs da una location sbagliata,
provocando il blocco dei jobs in attesa nella coda

  • pubblicazione dati sul BDII
  • customizzare il jobmanager di globus per condor, in allegato
  • sostituire i moduli dgas per l'accounting in /opt/glite/sbin/glite-urcollector.pl e /opt/glite/sbin/glite-dgas-pushd.pl. Controllare che nel file di configurazione dgas_gianduia.conf vi siano impostate le variabili
    • lrmsType = "condor"
    • condorHistoryCommand="/usr/opt/condor-<version>/bin/condor_history"
  • inserire un source /etc/profile.d/condor.sh in testa al file /etc/init.d/glite-dgas-urcollector. Diversamente mancheranno al collector le variabili d'ambiente per eseguire il condorHistoryCommand
  • Log globus-gatekeeper. Il file /var/log/globus-gatekeeper contiene i log dell'omonimo server, di lcas e di lcmaps. La verbosità può essere controllata settando le variabili d'ambiente:
       LCMAPS_DEBUG_LEVEL
       LCMAPS_LOG_LEVEL
       LCAS_DEBUG_LEVEL
       LCAS_LOG_LEVEL

i cui valori possono variare da 0 a 5, sempre dentro il file /etc/sysconfig/globus.
Questo è stato protetto da scrittura, diversamente ogni configurazione via yaim lo ripristinerà alle condizioni iniziali

File condor_config.local del CE:

sul CE è installato anche il servizio grid ig_CE, che deve essere configurato con yaim usando questo file di configurazione:


Configurazione CM

File condor_config.local del central manager:

Le customizzazioni per le priorità, gruppi e quote macchina si trovano sul central manager (t2cmcondor-125)

Il CM dispone di un'area GPFS condivisa usata per l'autenticazione fra le macchine del pool Condor /gpfs/storage_1/condor_auth

Configurazione dei worker nodes

Self-check e sospensione manuale

  • Aggiunto il file wn_check in /etc/condor/config.d
ENABLE_PERSISTENT_CONFIG = TRUE
PERSISTENT_CONFIG_DIR = /etc/condor/tier2
STARTD_ATTRS = $(STARTD_ATTRS) StartJobs, T2NodeOnline
STARTD.SETTABLE_ATTRS_ADMINISTRATOR = StartJobs
StartJobs = False
T2NodeOnline = False

START = ( $(START) && StartJobs && T2NodeOnline )

STARTD_CRON_CONFIG_VAL = $(RELEASE_DIR)/bin/condor_config_val

STARTD_CRON_JOBLIST = TESTNODE
STARTD_CRON_TESTNODE_MODE = Periodic
STARTD_CRON_TESTNODE_EXECUTABLE = /usr/local/libexec/testnodeWrapper.sh
STARTD_CRON_TESTNODE_PERIOD = 300s

# Make sure values get over
STARTD_CRON_AUTOPUBLISH = If_Changed
  • Aggiunto il file testnodeWrapper.sh in /usr/local/libexec
  • Creata la directory /etc/condor/tier2
mkdir /etc/condor/tier2
chown condor.condor /etc/condor/tier2

Configurazione di rete per i server gridftp

Per evitare che il traffico da e verso i server gridftp passi attraverso il NAT (t2gate), sono state aggiunte queste due righe in /etc/hosts:

192.168.127.28 gridftp-a1-1.mi.infn.it
192.168.127.8  gridftp-b1-1.mi.infn.it

Purtroppo non è sufficiente, perché i server gridftp rispondono al comando PASSV con l'interfaccia pubblica anche quando contattati sull'indirizzo privato (bug?). Sui server quindi gira un secondo demone gridftp su una porta differente (2812) e con una configurazione differente (-data-interface <indirizzo_in_127>).
Affinché i WN usino il secondo demone sono state aggiunte queste due regole alla nat table di iptables:

-A OUTPUT -d 192.168.127.28/32 -p tcp -m tcp --dport 2811 -j DNAT --to-destination 192.168.127.28:2812 
-A OUTPUT -d 192.168.127.8/32 -p tcp -m tcp --dport 2811 -j DNAT --to-destination 192.168.127.8:2812 

rese persistenti col file /etc/sysconfig/iptables


Obsoleted

Su tutti i wn sono montate delle aree GPFS.
Si presti particolare attenzione, la mancanza delle aree condivise può portare al fallimento permanente di tutti i jobs assegnati al sito

I files .conf sono i seguenti:

Questo wn a 32bit opera con utenti sgm, ops, dteam, infngrid. Dei 4 slots, uno lavora solo con sgm e, in presenza di un suo job, sospende gli altri slot. Non accetta code short

Questi wn standard a 32bit operano con tutte le utenze, eccetto le precedenti, stabilite in base alla variabile SlotID.

Versione 7.2.1 installata su un wn a 64bit.

Sui worker nodes è installato anche il servizio ig_WN_noafs, da configurare con yaim, usando i files in calce

Configurazioni Yaim 'infn-grid' per i worker node