Tutorial HTCondor - Gli 'universe' di sottomissione.

Una introduzione sistematica.

Francesco Prelz

INFN, sezione di Milano
Per conto del gruppo di lavoro Condor

Sommario

• Panorama sugli universe di sottomissione dei job, con qualche dettaglio pratico:
  1. vanilla
  2. standard
  3. local/scheduler
  4. vm
  5. 'docker'
  6. java
  7. grid
  8. mpi/parallel

Vanilla Universe

• Universo di default
• Singolo eseguibile, con i suoi sottoprocessi (flusso di esecuzione seriale)
• Deve essere in grado di girare in background:
  • Nessun input interattivo.
  • Nessuna finestra/GUI.
  • stdin, stdout e stderr sono rediretti a file.
• Se interrotto, ricomincia da capo.
• Trasferimento automatico dei file in input e output.

Trasferimento File

• ShouldTransferFiles = YES:
  Trasferisci sempre i file da e per il sito di esecuzione.
• ShouldTransferFiles = NO:
  Supponi sempre l'esistenza di un filesystem condiviso.
• ShouldTransferFiles = IF_NEEDED:
  Trasferisci automaticamente i file solo se le macchine di sottomissione ed esecuzione non appartengono allo stesso FileSystemDomain (default)
• Transfer_input_files = x, y
  Elenca i file di input da trasferire, oltre all'eseguibile e al suo standard input.
• Transfer_output_files = x, y
  Elenca i file di output da trasferire. Se non è specificato sono tutti i file presenti nella directory di esecuzione.
• Transfer_output_remaps = " name1 = newname1 ; name2 = newname2 ... "
  Rinomina i file di output, se necessario.
• when_to_transfer_output = < ON_EXIT | ON_EXIT_OR_EVICT >
  Determina se l'output dei job deve essere trasferito quando il job chiama spontaneamente exit() oppure in qualunque modo termini (per job fault tolerant).

Standard Universe

• Era una volta l'universo di default
• Remote I/O (via condor_shadow) e checkpoint/resume automatici.
• L'immagine di checkpoint (registri di CPU, memory image, I/O) è specifica per Condor.
• Richiede un relink degli eseguibili (condor_compile).
• Richiede di mantenere una versione con patch della glibc, Linux-only.
• Il codice coinvolto è in molte parti specializzato, diverso da quello usato per gli altri universi.
• Gli sviluppatori non vedono l'ora di sbarazzarsene, ma criu.org non è ancora così in userspace come potrebbe essere.

Limiti al checkpointing

1. Non applicabile a job multi-processo, che usano le syscall fork(), exec() e system().
2. Non è permessa la comunicazione interprocesso: pipes, semaphore, shared memory.
3. Le comunicazioni di rete devono restare brevi. Si può usare socket(), ma le connessioni che rimangono aperte ritardano checkpoint e migrazione.
4. Non è permesso utilizzare i segnali SIGUSR2 o SIGTSTP, che sono riservati a HTCondor per il controllo della sospensione e di checkpoint e migrazione dei job.
5. Non si possono usare alarm e timer (alarm(), getitimer(), sleep()).
6. Non si possono usare thread gestite dal kernel. Si possono usare a user level.
7. Non è permesso l'accesso memory-mapped ai file (mmap(), munmap()).
8. Gli eseguibili devono essere linkati staticamente (se ne occupa condor_compile).
9. E' permesso utilizzare i file lock, che però vengono persi dopo un checkpoint.
10. Tutti i file devono essere aperti in sola lettura o sola scrittura. Viene generato un warning on caso di apertura R/W perchè lo stato del file non può essere inq uel caso ricostruito se si torna ad un checkpoint precedente.
11. L'accesso a file di dimensione >2GB è possibile solo se l'eseguibile e il condor_shadow della macchina di sottomissione sono entrambi a 64 bit.
12. Deve essere disponibile sufficiente spazio disco per salvare le immagini di checkpoint (eventualmente su un checkpoint server esterno).

Local/Scheduler Universe

• I job sottomessi al local universe girano sulla macchina di sottomissione.
• Una specie di cron/at, che funziona anche dove non c'è cron.
• Applicazione banale della cura 'paterna' di HTCondor per tutti i processi figli.
• Lo Scheduler Universe è una versione limitata del Local Universe: di questi job non si prende cura un condor_starter e il match viene fatto con il classad dello schedd. Ideato per meta-scheduler come DAGman. Potrebbe (assai ragionevolmente) sparire.

VM Universe (1)

• La soluzione estrema per fare checkpoint and migration.
  • vm_checkpoint = true nel submit file.
  • Ma non vengono gestiti i checkpoint periodici come nello standard universe.
  • E non viene utilizzato il checkpoint server, se configurato
• Il job 'è' l'immagine della VM.
• L'output del job 'è' l'immagine modificata della VM.
• Supporto per VMWare, Xen, KVM (o quanto syupportato da libvirt/libvirtd).
• condor_starter interagisce con gli hypervisor attraverso un VM GAHP.
• I job nel VM universe terminano quando viene fatto lo shutdown della macchina.

VM Universe (2)

• Esempio di configurazione di host che offre servizi VM:
  
  
  VM_MEMORY = 256
VM_MAX_NUMBER = 2
VM_NETWORKING = True
VM_NETWORKING_TYPE = nat, bridge
VM_NETWORKING_DEFAULT_TYPE = nat
VM_SOFT_SUSPEND = True
VM_NETWORKING_BRIDGE_INTERFACE = br0

VM 'Inner machine'

• E' possibile avere/sottomettere virtual machine che sono nodi di esecuzione di HTcondor su una macchina host con HTCondor (ad esempio per architetture diverse)
• Configurazione sulla macchina host:
  VMP_VM_LIST = vm1.bar.edu, vm2.bar.edu
HOSTALLOW_WRITE = $(HOSTALLOW_WRITE), $(VMP_VM_LIST)
• Configurazione sulla VM:
  VMP_HOST_MACHINE = foo.bar.edu START = (KeyboardIdle > 150) && (HOST_KeyboardIdle > 150)
• Si può evitare che più condor_startd inizino a 'duellare' per ottenere le risorse della macchina solo da un punto di osservazione esterno.
  • Se si trova nello stesso pool, un eventuale startd sulla macchina host delega tutto alle VM.

'docker' Universe

• Di fatto una applicazione del 'vanilla universe'
• Perché qui, diversamente che nel caso del VM universe, i job sono davvero job.
• Indispensabile che l'utente condor appartenga al gruppo docker:
  useradd -G docker condor
• La disponibilità di Docker su un nodo di esecuzione viene rilevata automaticamente alla partenza/riconfigurazione di Condor
• Ulteriori dettagli in questa presentazione.

Java Universe

• E' più che eseguire java Class.class nel vanilla universe...
• Un eseguibile ('executable' + 'jar_files') Java sottomesso con universe = java esegue su qualunque macchina abbia a disposizione una JVM, la cui presenza viene rilevata da Condor alla partenza.
• Il CLASSPATH viene ridefinito in modo opportuno sulla macchina di esecuzione.
• Vari attributi sono disponibili per il match-making:
  HasJava = true
JavaVendor = "Sun Microsystems Inc."
JavaVersion = "1.6.0_34"
JavaMFlops = 592.55127
JavaSpecificationVersion = "1.6"
  
• Un wrapper specifico raccoglie informazioni sul completamento del processo, non solo l'exitcode della JVM.

Grid Universe (1)

• La stele di Rosetta.Una infinità di dettagli
  si trovano nel relativo capitolo del manuale
• Vengono resi disponibili servizi client-side
  di Condor stesso, Globus (gt2, gt3, gt5),
  CREAM, Nordugrid, Unicore, deltacloud,
  BOINC, Amazon EC2, Google Compute Engine, altri batch system (BLAHP!) sono disponibili in altrettanti processi GAHP.
• E' in generale necessario conoscere al momento della sottomissione i dettagli della risorsa di destinazione, e specificarli nel multiforme attributo grid_resource.
• Si può anche implementare una forma di match-making, (§5.3.11 del manuale) a patto che qualcuno popoli il condor_collector con le necessarie informazioni sulle risorse disponibili.
  Poter fare late binding ha però offerto vari vantaggi in pratica.

Grid Universe (2)

• Esempio di sottomissione verso un altro Condor pool:
  
  # minimal submit description file for an HTCondor-C job
universe = grid
executable = myjob
output = myoutput
error = myerror
log = mylog
grid_resource = condor joe@remotemachine.example.com remotecentralmanager.example.com
+remote_jobuniverse = 5
+remote_requirements = True
+remote_ShouldTransferFiles = "YES"
+remote_WhenToTransferOutput = "ON_EXIT"
queue

Parallel Universe (1)

• Condor è strutturato per ospitare normalmente un numero arbitrario di scheduler indipendenti, ognuno dei quali ottiene risorse attraverso il meccanismo di 'claim' arbitrato dal condor_negotiator.
• Introdurre una possibilità di sincronizzare i claim in questo quadro conduce fatalmente al deadlock.
• I job veramente paralleli ('HTHPC') vengono supportati attraverso un Dedicated Scheduler, che deve essere unico per tutte le risorse che devono essere utilizzate da parallel universe.
• Gli slot allocati per il Dedicated Scheduler rimangono per qualche tempo di suo uso esclusivo.
• Il parallelismo basato su multipli core e offerto dai partitionable slot (vedi talk di David Rebatto) è molto più efficiente ed elastico.
• Applicazioni non nel mainstream, ci possono essere sorprese.

Parallel Universe (2)

• Configurazione su condor_startd:
  DedicatedScheduler = "DedicatedScheduler@schedd_name@schedd_host"
STARTD_ATTRS = $(STARTD_ATTRS), DedicatedScheduler
RANK = Scheduler =?= $(DedicatedScheduler)
PREEMPT = Scheduler =!= $(DedicatedScheduler) && ...
  
• Esisteva una volta un 'MPI' universe (universe=mpi), di applicazione più specifica. E' ora obsoleto, come già prima di lui il 'PVM' universe...