Aggiornamento sull’attività del progetto ‘Condor on WAN’ dall’ultima riunione di settembre 98.

Segue la lista delle action decisa nella riunione.

1. Ottimizzare e distribuire gli strumenti di monitoraggio del traffico di Condor e dell’attività del checkpoint server (C.Vistoli, T.Ferrari)
2. Sperimentazione di AFS sotto Condor (R.Gomezel, F.Prelz, P.Mazzanti, E.Fasanelli)
3. Poichè le valutazioni sui dati di utilizzo della CPU del pool e del traffico indotto sulla rete da parte dei job di simulazione dei prog. di simulazione dei nuovi exp., con un I/O compreso in un certo range, sono state positive, si è presa la decisione di aprire il pool a tutti i tipi di JOB delle sezioni (tutti).
4. CMSIM : è necessario aggiungere altri HP nel pool e misurare il traffico di I/O (PD)
5. Interesse sull’uso del pool da parte del gruppo degli astrofisici teorici di Roma1 con un programma (OG14) che gira su piattaforma Digital Unix e Linux.
6. Ottimizzazione delle configurazioni delle execution machine e dei parametri dei submit file per dare priorità ai JOB locali sulle execution machine locali (Bortolotti, Ferrari, Gomezel, Parlati, Prelz)

 

Argomenti da approfondire con M.Livny:

7. Checkpointing distributo e dinamico
8. Tecniche di caching per job con alto rate di I/O
9. Supporto al flocking da parte del Condor-team

15-16 ottobre, seminario di M.Livny e discussione sui punti elencati sopra

Il seminario era focalizzato sulle novità in corso di implementazione per aumentare il ‘goodput’.

(Le trasparenze sono reperibili nel web www.mi.infn.it/condor)

Vengono illustrati i vari stati del funzionamento di Condor per individuare i punti che possono essere migliorati al fine di aumentare sia il throughput sia il goodput.

Fra i vari meccanismi individuati per questo improvement c’è anche il caching per migliorare il ‘remote I/Ò e alcune novità sul checkpointing. Si rimanda alla lettura delle trasparenze per approfondire questi punti.

Contributi della discussione con Miron in merito alle action.

• Action 2: AFS per migliorare l’I/O: è già stato preso in considerazione dal Condor-team e ritenuto non adatto allo scopo. ML ritiene che il problema del miglioramento del throughput per i job I/O intensive vada affrontato non basandosi sui file system tradizionali ma con meccanismi propri, analogamente al checkpointing. E’ interessante approfondire quanto indicato nella presentazione di Miron su questo argomento. A proposito di questa action, è stato fatto qualche test? Sempre a proposito dei Job I/O bound si veda l’utilizzo di NFS nel documento allegato.

• Action 7: Checkpointing distribuito e dinamico: è stato concordata una soluzione descritta nel documento che verrà messo nel web al più presto. Questa soluzione è fondamentalmente basata su alcune ipotesi e obiettivi:
• Ipotesi sulla distribuzione dei checkpoint server:
• Ciascuna sezione può costituire di fatto un ‘sub-pool’ (in assenza del flock) e quindi dotato di un checkpoint server.
• Le collaborazioni possono voler costituire dei ‘sub-pool’ locali e geografici dedicati al calcolo del loro esperimento dotati quindi di ckpt server dedicati.
• CKPT server geografici localizzati in siti ben connessi alla rete.

• Obiettivi
• Adottare meccanismi di checkpointing che soddisfino le policy descritte sopra.
• Fare in modo che il checkpointing di file di grosse dimensioni non causi ritardi nell’accesso alla macchina da parte dell’utente.
• Avere la possibilità di scegliere il ckpt server sulla base del traffico di rete.
• Per la descrizione della proposta si rimanda al documento. Si fa notare che questa versione non prende in considerazione per il momento la scelta del ckpt server sulla base del traffico di rete misurato in tempo reale. La proposta include anche i tool di misura del traffico di Condor che si stanno sviluppando al cnaf.

La task force INFN per la definizione e l’implementazione del checkponting distribuito e dinamico è attualmente costituita da Ferrari, Ghiselli, Mazzanti, Semeria e Vistoli.

• Action 3 ; CMSIM . Sgaravatto sottometterà i job a breve e sta predisponendo con Vistoli i tool di monitoraggio del traffico di I/O dei JOB.
• Action 5; configurazione dei ‘sub-pool’ locali o domini. Il file con tutte le istruzioni è allegato, quindi si sollecita tutti coloro che hanno dei Condor pool a trasformarli in sub-pool. Tutte quelle sezioni che hanno un numero sufficiente di macchine e richieste di calcolo da parte di utenti locali potranno definire i sub-pool.
• Action 5’; Si sta studiando un’interfaccia web per l’utente che faciliti la sottomissione dei job nel dominio richiesto.
• Action 4 ; i job stanno utilizzando il Condor pool con ottimi risultati. Sarebbe opportuno fare un report sull’attività di questo Job …….

Commissione Calcolo del 28 settembre scorso.

L’attività di Condor è stata presentata nell’ultima Commissione Calcolo (la presentazione è disponibile su web) e sono stati finaziati 10Mlire su budget 98 per trasferte a Madison per il problema del checkpointing distribuito. Come sapete l’obiettivo principale per la Comm.Calcolo è la messa in funzione del pool geografico per tutta l’utenza INFN, dove il ckpt distribuito è uno strumento indispensabile. Entro fine anno va definita la proposta (layout, policy, gestione….) ed entro primavera dell’anno prossimo va completata l’implementazione.

Come abbiamo già discusso una prima implementazione è costituita dai sub-pool e dobbiamo formalizzare al più presto il gruppo infn di condor-admin.

La Comm.Calcolo ha raccomandato di inserire da subito nel pool più macchine possibile e ha nominato 2 referee per il progetto: Pollarolo e Merola.

CNTC del 30 settembre scorso

È stato fatto un aggiornamento del progetto nell’ultima riunione di CNTC dove è stata ribadita la necessità di avere al più presto il sistema Condor geografico in produzione con un management ben definito e di configurare le evoluzioni come progetti distinti con la partecipazione INFN e del Condor-team di Madison.

Possiamo quindi definire "Condor on WAN" , cosi’ come è descritto nel documento memorizzato nella pagina web degli esperimenti dell’INFN, (www.infn.it/condor/) un "framework" a cui afferiscono diversi progetti. Attualmente possiamo identificarne 3, corrispondenti agli obiettivi descritti nel documento medesimo:

• Condor on WAN come sistema di calcolo dell’INFN
• Checkpoint distribuito e dinamico
• Condor e ODBMS

di cui i primi due sono già definiti.

Abbiamo ritenuto opportuno questo aggiornamento via e.mail anche per verificare se è necessaria la riunione prevista per il 12 novembre prossimo. Il motivo è anche logistico e legato a sopraggiunte difficoltà a partecipare alla riunione per i bolognesi della sezione.

Noi riteniamo che la discussione sui punti descritti sopra possa svolgersi per e.mail e non sia necessaria una riunione a breve, ma se non siete dello stesso parere fatecelo sapere.

La riunione potrebbe essere rimandata a gennaio, dopo la trasferta a Madison, per discutere:

• proposta di configurazione del pool geografico per la produzione
• monitoraggio dell’intero pool
• management del pool