Tutorial HTCondor

Breve introduzione generale.

Francesco Prelz

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

Quiz

Sommario

• HTCondor ("HT is mute") sta trovando nuovi e qualche volta rinnovati spazi di applicazione nel vecchio continente.
  • 2 anni fa: European HTCondor Site Admins Meeting @ CERN.
  • Febbraio 2016: HTCondor workshop @ ALBA Synchrotron (Barcellona).
• Qui cerchiamo di essere un po' più hands-on che in quelle occasione: il nostro obiettivo è arrivare a condividere le risorse di tutti i laptop in questa stanza, possibilmente con altre risorse (pool nazionale, risorse cloud), così che qualche user payload (compresi DAG e job MPI) possa venire eseguito.
• Si raccolgono scommesse sulla percentuale di successo da qui a domani sera...
• Ora, prima di user e administrator tutorial, pochi concetti introduttivi (perlopiù provenienti, with permission, da una presentazione di Greg Thain, che ora ben conosciamo).

HTC, HPC e HTHPC (1)

high-throughput	high-performance

HTC, HPC e HTHPC (2)

high-throughput	high-performance

HTC, HPC e HTHPC (3)

high-throughput	high-performance
FLOPY	FLOPS

Sette princípi

1. HTCondor gestisce i job
2. HTCondor gestisce le macchine di esecuzione
3. HTCondor gestisce i dati (per i job)
4. HTCondor è scalabile e sicuro
5. HTCondor utilizza la rete disponibile
6. HTCondor gestisce workflow
7. HTCondor può essere controllato ('monitored')

HTCondor gestisce i job

• A job is like money in the bank (TM).
• Lo stato dei job è salvato come in un database.
• In modo che sopravviva a crash e interruzioni di rete.
• Gli eventi della sua esecuzione sono salvati in un log.
• Ha una propria policy.
• Esistono vari tipi di job.

HTCondor gestisce le macchine

Il proprietario della macchina è sovrano (imperatore?). Le policy del proprietario prevalgono su tutte le altre. Il proprietario potrebbe non essere chi siede alla tastiera. Al termine di ogni job ne viene cancellata ogni traccia. Condor non deve essere in grado di abbattere la macchina. Condor indaga e conosce le risorse della macchina.

HTCondor gestisce i dati

Non è obbligatorio avere un filesystem condiviso. Le 'sandbox' dei job vengono trasferite. I trasferimenti vengono gestiti ed accodati. Condor conosce la dimensione delle 'sandbox'. Sono possibili trasferimenti '3rd party'.

HTCondor è scalabile e sicuro

Il Central Manager è stateless e ragionevolmente leggero. Lo stato viene conservato sempre alle estremità di ogni relazione. Fatto scalare fino a 200000 job contemporaneamente in esecuzione. Con supporto per: SSL, Kerberos, GSI, NTSPI, Host-based, password, CLAIMTOBE.... Utilizza le librerie locali a disposizione. Sicurezza applicata alla singola sessione.

HTCondor utilizza la rete disponibile

• Può aggirare i firewall: Condor Connection Broker (CCB).
• Può utilizzare una singola porta in ingresso: shared_port.
• Le macchine di esecuzione possono avere soltanto connettività in uscita.
• Il Condor Collector può comunicare via UDP o TCP.
• Supporto di IPv6 in dual-stack.
• Può essere installato senza la collaborazione dell'amministratore di rete...

HTCondor inoltre...

• Supporta veri workflow, non solo bags of tasks (dagman).
• Permette il controllo del suo utilizzo e funzionamento:
  • Statistiche interne.
  • Condorview.
  • Ganglia.
  • Log utente.

Grazie per l'attenzione.