CONDOR

INDICE:

             Introduzione
             Condor Pool
             Come si "prepara" un job per Condor
             Submit di job
             Alcuni comandi utili

INTRODUZIONE

Condor e` un sistema software che realizza un High Throughput Computing (HTC) environment, utilizzando workstation Unix (e` previsto per il futuro il supporto anche per sistemi Windows NT). L'utente, anziche` sottomettere i propri job sulla "propria" workstation, puo` utilizzare Condor, al fine di massimizzare il throughput.
Per ogni job sottomesso, Condor "individua" una macchina libera in grado di elaborarlo, e inizia ad eseguire il relativo programma su tale computer. Se ad un certo punto il calcolatore non e` piu` disponibile (ad esempio perche` il corrispondente owner inizia ad usarlo), Condor effettua un checkpoint del job, che viene "migrato" su un altro computer disponibile: l'esecuzione riprende esattamente dal punto in cui era stata interrotta.

Non e` necessario che ci sia un file system comune tra le workstation del Condor pool, e non e` nemmeno necessario che gli utenti di Condor abbiano un account su tutti questi calcolatori.

Il servizio di resource management implementato in Condor prende il nome di ClassAds. Sostanzialmente ogni workstation del pool indica quali sono le sue risorse disponibili (tipo di CPU e relative prestazioni, RAM, load, ecc...). L'utente che sottomette un job indica quali sono le risorse necessarie per la relativa esecuzione (requirement) e quelle "desiderabili" (rank). Analogamente per ogni workstation si possono definire requirement e rank. Condor controlla le risorse (richieste e desiderabili) dei job sottomessi, e sceglie le workstation per l'esecuzione in base alle risorse offerte, e in base ai relativi requirement e rank.

CONDOR POOL

E` stato implementato un condor pool esteso in wide area a tutto l'INFN. Sulla pagina Condor on the INFN Wan potete vedere quali sono le workstation che sono state inserite. Le macchine di Padova che fanno parte del pool le potete trovare nella pagina Workstation di Padova nel Condor INFN pool.
Le nostre workstation sono state configurate in workgroup (i workgroup attualmente definiti sono AlicePd, CmsPd, DelphiPd, G3Pd, NomadPd), che permettono di definire diversi livelli di priorita`.

Fra tutti gli utenti Condor, nell'utilizzo di una certa workstation valgono le seguenti priorita`:

hanno piu` alta priorita` i job degli utenti che appartengono allo stesso workgroup di cui fa parte la workstation (quindi, ad esempio, un utente del workgroup NomadPd ha piu` alta priorita` nell'utilizzo delle sue workstation);
se non ci sono job di utenti di questo workgroup, hanno piu` alta priorita` i job sottomessi dagli altri utenti di Padova;
solo se non ci sono job di utenti di Padova, la workstation puo` essere usata da utenti "esterni" (di altre sezioni).

Vale comunque sempre il principio per cui una workstation viene utilizzata da Condor solo se e` in quel momento inutilizzata.

COME SI "PREPARA" UN JOB PER CONDOR

Non e` necessario modificare i file sorgenti per l'utilizzo di Condor: e` sufficiente il "relink" con particolari librerie che permettono la realizzazione del checkpointing, e che gestiscono il fatto che submitting machine e executing machine non hanno necessariamente un file system comune.

Il comando condor_compile gestisce automaticamente questo "relink": e` sufficiente premettere condor_compile al comando che si utilizza per la compilazione/link (cc, CC, gcc, f77, g++, ld, make, ecc...).

Qualche esempio:

condor_compile cc -O -o myprogram.condor file1.c file2.c ...

condor_compile make

condor_compile f77 -O mysolver.f

Ci sono delle limitazioni per i programmi che possono essere usati con Condor:

sono supportati solo job a singolo processo (non sono ammesse system call quali fork, exec, ecc...);
non si possono gestire all'interno dell'applicazione i signal SIGUSR2 e SIGTSTP;
molte system call per l'interprocess communication (IPC) non sono supportate (es. socket, send, recv);
se su un file si effettuano operazioni solo di lettura o solo di scrittura non ci sono problemi; i programmi che invece effettuano contemporanamente letture e scritture su uno stesso file potrebbero non funzionare.

SUBMIT DI JOB

Per sottomettere job a Condor, si utilizza il comando condor_submit:

condor_submit CondorSubmitFile

Il CondorSubmitFile indica qual e` l'eseguibile, quali sono i file di input e di output, quali sono i requirement e i rank, ecc...

Qualche esempio di CondorSubmitFile:

Esempio 1:

               Executable = sim.exe
                input = title
                output = out.fz
                error = sim.err
                Initialdir = /home/sgaravat
                Queue

Si specifica che deve essere eseguito sim.exe (che deve essere stato generato attraverso condor_compile), usando il file di input title, e producendo il file di output out.fz (cioe` sim.exe < title > out.fz). Gli eventuali errori vengono riportati nel file sim.err. Il job deve essere eseguito a partire dalla directory /home/sgaravat. Poiche` non e` stata indicata l'architettura su cui il job deve essere eseguito, si sottointende che la executing machine deve essere della stessa piattaforma della submitting machine.

Esempio 2:

               Executable = prog.exe
                Requirements = Memory >= 64
                Rank = Memory >= 128
                Input = in.$(Process)
                Output = out.$(Process)
                Error = err.$(Process)
                Log = log.$(Process)
                Queue 100

Si specifica che il programma prog.exe deve essere eseguito 100 volte. Nel primo run il file di input e` in.0, quello di output out.0, quello di log log.0, quello di errori err.0; per l'ultimo run (il centesimo) il file di input e` in.99, quello di output out.99, quello di log log.99, quello di errori err.99. Si potranno utilizzare solo workstation con almeno 64 MB di RAM e, se disponibili, si utilizzeranno computer con almeno 128 MB di memoria.

Esempio 3:

Ecco un esempio concreto: come ho utilizzato Condor per l'esecuzione di cmsim su alpha station.
Dopo aver creato con condor_compile l'eseguibile (cms112.exe) ho creato il seguente script:

           #!/bin/csh
            source script.csh
            source /afs/cern.ch/cms/utils/cms112
            setenv SCRATCH /delphi/sgaravat/cms/du
            condor_submit cmsim.cmd

Nello script vengono "richiamati" altri script (che definiscono alcuni nomi logici, necessari per l'esecuzione di cmsim), e alla fine si invoca il comando condor_submit, specificando come condor submit file il file cmsim.cmd.

Questo e` il contenuto del file cmsim.cmd:

          executable = cms112.exe
            input            = title.$(Process)
            output         = out.$(Process)
            error            = err.$(Process)
            log               = log.$(Process)
            rank = (CkptServer =?= LastCkptServer) *100 + CkptBW +
                        SUBMIT_UID_DOMAIN == "pd.infn.it" +
                        SUBMIT_GROUP_ID == "DelphiPd"
            getenv         = True
            image_size = 75000
            queue 10

getenv = True indica che il job deve "conoscere" le variabili di environment definite al momento del submit.

La parte del rank:

SUBMIT_UID_DOMAIN == "pd.infn.it" + SUBMIT_GROUP_ID == "DelphiPd"

serve per definire le priorita` prima descritte: il job deve avere la massima priorita` sulle workstation del workgroup indicato (DelphiPd, in questo caso), e poi sulle altre workstation di Padova.

La rimanente parte del rank:

(CkptServer =?= LastCkptServer) *100 + CkptBW

indica cosa fare per il checkpointing:

si seleziona l'executing machine tra quelle con piu` alta banda verso il suo checkpoint server;
quando un job "riparte" dopo un checkpoint, sceglie, se disponibile, una executing machine che utilizza lo stesso checkpoint server, preferendo sempre quella con piu` alta banda;
se nessuna macchina del dominio di checkpoint (cioe` che utilizza lo stesso checkpoint server) e` disponibile, se ne sceglie una esterna (se disponibile).

ALCUNI COMANDI UTILI

Con il comando:

condor_status

si puo` verificare lo stato del Condor pool.

Il comando:

condor_status -l hostname

permette di visualizzare lo stato della workstation hostname.

Si possono verificare quali sono gli utenti che hanno job sottomessi al pool con il comando:

condor_status -submitter

Una volta sottomesso uno o piu` job, si puo` verificarne lo stato con il comando:

condor_q

In particolare per ogni job viene visualizzato un identificatore (ID) e lo stato (ST). Se lo stato e` pari a R, il job e` in esecuzione; se e` pari a I e` in attesa che si "liberi" un computer per l'esecuzione.
Se si vuole verificare perche` un certo job non viene mai eseguito (lo stato e` sempre pari a I), si puo` dare il comando:

condor_q id -analyze

Per rimuovere un job prima sottomesso, il comando da dare e`:

condor_rm id

Nel file di log specificato nel condor submit file, si puo` vedere la "storia" del job sottomesso (su che workstation e` stato eseguito, se e` stato "checkpointato", ecc...).

Massimo Sgaravatto

(Modificato il 21 Aprile 1999)