	A	B	C	D	E	F	G	H	I	J	K
1	39	BA - CMS	CT - ALICE	LNF - ATLAS	LNL - CMS	MI - ATLAS	NA - ATLAS	PI - CMS	RM - ATLAS	RM - CMS	TO - ALICE
2
3	*1 ) Sistema di code usato*	Torque/MAUI	LSF 6.1 HPC	PBS	LSF	TORQUE/PBS 2.1.6	PBS/Torque 2.X	LSF	LSF	LSF v 6.1	PBS (torque-2 + maui)
4	*1a) Da quando e' in produzione?*	PBS e' in produzione dal 2003. Torque/MAUI dal 2005.	Marzo 2005	2004	Dal 2001	2 mesi (precendemente TORQUE/PBS 1.x)	circa 2 anni	2 mesi; precedentemente PBS 1.x	Ottobre 2006	meta' settembre 2006, prima PBS	Dall'inizio...
5	*2a) Code per esperimento o code per lunghezza dei jobs?*	Code specifiche per esperimento solo quando strettamente richiesto (ALICE, test). Per tutti gli altri code condivise fra esperimenti e organizzate per durata.	Entrambe	per esperimento	Per esperimento	code per esperimento + 1 coda short	code per esperimento. Per Atlas 2 code in base alla lunghezza dei job.	per esperimento	atlasgcert (Grid, dteam/infngrid (certification), 1440.0 min); atlasglong (Grid, ATLAS, 4320.0 min); atlaslong (Local, local users, 4320.0 min); atlascalib (Local, calibration, 4320.0 min); cdfglong (Grid, CDF, 4320.0 min)	code per lunghezza job divise per esperimento	~per VO
6	*2b) Numero totale di code*	7	17	3	8	7	7	7	5	5	11
7	*2c) Macchina su cui gira lo scheduler (es, CE, nodo a parte ...)*	CE	CE	CE	Master LSF su un nodo a parte	CE	CE	master LSF, nodo a parte	Server LSF separato	Master LSF dedicato, nodo a parte	CE
8	*2d) Quali VO supportate?*	Tutte quelle EGEE e INFN-GRID	Tutte quelle mostrate nella pagina: http://grid.ct.infn.it/monit/daily.php	Atlas, Dteam, Infngrid, Gridit	I quattro esperimenti LHC piu' cdf ed euindiagrid	alice, atlas, cms, lhcb, dteam,infngrid,ops	atlas alice lhcb cms dteam ops infngrid gridit virgo babar cdf argo pamela (esp. HEP + esp. presenti in sezione)	tutte quelle di LCG/INFNGrid	ATLAS, CDF, DTEAM, INFNGRID	CMS, Grid Cert	atlas alice lhcb cms dteam infngrid babar zeus na48 ops biomed
9	*3 ) Sistema di code prettamente utilizzato via GRID o anche uso locale*	Prevalentemente via Grid. La coda locale e' ormai dismessa.	Sia uso via GRID che locale	solo via grid	Solo via grid (coda locale usato solo da admin, per test e poco altro)	solo via GRID	via grid	anche uso locale	LSF	anche uso locale	Esclusivamente via GRID
10	*4 ) Sistema di prioritizzazione scheduler (FIFO, FairShare, Priority based...)*	Il sistema di prioritizzazione tiene in considerazione molti parametri per coprire al meglio le richieste di una farm multi-VO. Vengono dati dei pesi sia alla priorita' statica di una VO o di un utente, sia al fair-share, sia al tempo trascorso in coda; sono anche possibili pre-allocazioni di risorse.	Priorita' + Pre-emption	Priority based	FairShare, con Host Partitions per dare piu' priorita' ad alice sulle macchine da loro comprate	Priority based e FairShare con vari pesi	priority	FairShare	FairShare	cross queue FairShare	Priority + FairShare
11	*5 ) Macchine da cui e' possibile sottomettere jobs locali*	3 diversi CE e una UI (in dismissione)	2 o 3 macchine	cluster lxcalc	Master LSF	solo CE	al momento nessuna	qualunque CE/WN	Tutte le UI del sito (correntemente 3 UI su macchine virtuali)	UI dedicata	NESSUNA
12	*6 ) Account esistenti sul manager, utilizzabili per mandare jobs*	Solo account grid.	Diversi	solo account grid	account grid	account Grid + ~10 account locali	al momento nessuno	account grid, in via di installazione su tutti i nodi Grid tutti gli account AFS di sezione	80 account locali	account grid, account locali T2 (numero limitato)	NESSUNA
13	*7 ) Dimensioni medie del cluster (slot utilizzabili, jobs running, jobs in coda)*	90 slot, 90 job running , anche fino a 2000-3000 job in coda.	Guarda la pagina: http://grid.ct.infn.it/monit/queues.php	30 slot, 30 job running, ~ 400 job in coda	200 / 0-200 / 0-Nmila	65 / 60 / da 0 fino a 2000 jobs in coda	34 slot (altre 28 entro pochi giorni); 34 job running, job in code dell'ordine delle centinaia.	600 / 400 / mediamente zero, con punte > 3000	56 slot, 56 jobs running, >100 jobs pending	42/ 40 (togliendo 2 job cert) / 400 jobs in coda	146 + 2 (riservate per job di test/certificazione), 146 job running, ~50 in coda
14	*8 ) Scalabilita' del sistema: fino a che livello e' stato testato*	fino a 150 slot e 4000 job in coda	Da quando e' stato installato LSF il job count e' a poco meno di 1 milione di job	30 slot, 30 job running, ~ 1500 job in coda	75 host, 200 slot, ~5000 job in coda	26 hosts/ 70 slots /2000 jobs in coda	il sistema lavora al 100% per la maggior parte del tempo	170 hosts / 600 Slots / 3500 jobs in coda	fino a 56 nodi a Roma1, ma LSF supporta migliaia di nodi (testato sia al CNAF che al CERN)	vedi punto 7	148 job running, 500 in coda
15	*9 ) Carico medio del GridManager in condizioni di massimo utilizza*	LoadAverage intorno a 4-5 ma dovuto al middleware di grid.	Se intendi il CE, mai piu' del 50-60% di CPU (e' un dual dual-core con 4 GB di RAM)	1	Non mi e' chiaro cosa si intende con 'GridManager', il CE ha sempre un load elevato (in genere da 2 a 10), mentre sul master LSF il load e' trascurabile (~0.1)	loadaverage sul CE ~5 ; pbs_server %MEM 7.0 %CPU 0-6 ; maui %MEM 4.5 %CPU 0-3	CPU Load del CE-pbs server < 40% (era questo che volevate sapere?)	lsf manager carico sempre < 1	Load >= 2.0	domanda non chiara	3-4
16	*10 ) Problemi riscontrati nel sistema per massimo utilizzo*	Il middleware di grid satura la macchina -> Necessario avere piu' CE installati per suddividere il carico.	Nessuno	-	Nessun problema specifico di LSF	con la versione 2 nessun problema	Nessuno	carico eccessivo sul CE (~20), non LSF specific	Blocco del sistema per utilizzo eccessivo di memoria o intensivo di servizi	hang del CE, risolto con sostituzione del CE con macchina piu' performante	Il sistema di code intrinsecamente non ha problemi riscontrabili anche a pieno carico. I job wrapper del middleware lasciano spesso parecchi processi defunct, e la versione di globus-url-copy usata per il trasferimento da/verso il WMS soffre spesso di bug di comunicazione che bloccano di fatto la prosecuzione del job. (Questi pero' non sono problemi del sistema di code)
17	*11a) Possibilita' di spostare risorse fra code diverse senza fermare tutto*	E' possibile ma non viene usato, perche' maui consente una gestione piu' fine per ottenere lo stesso risultato	SI	semplice reconfig dinamico	SI	SI	Non abbiamo l'associazione risorse-code	semplice reconfig, dinamico	Supportata e testata	conf dinamica	Tutte le code vedono le medesime CPU
18	*11b) Possibilita' di riorganizzare a runtime priorita' dei jobs*	Si, in diversi modi: facile.	SI	abbastanza facile usando comandi qorder, ecc...	SI	SI	Si, molto semplice	molto facile	Supportata e testata, anche advanced reservation	SI	i nodi sono job-exclusive
19	*11c) Strumenti di debug/logging dei jobs (per es per trovare "buchi neri")*	Il logging e' presente, non ci sono strumenti gia' forniti, se ne possono sviluppare diversi in modo semplice.	SI	ok, guardando i log	SI	SI (checkjob, tracejob, diagnose)	Non immediato, attraverso i log files.	ok, anche per i jobs finiti da tempo	Attualmente in fase di implementazione nel sistema locale di monitoring	con un po' di lavoro	Strumento di monitoraggio impiegati: nagios + mrtg oltre a naturalmente grep nei file di log
20	*11d) Possibilita' di partizionare la farm (cioe' di legare WN a code)*	SI	SI	si e' possibile	SI	SI	Possibilita' non utilizzata.	SI	Supportata e implementata per i job di certificazione e le code locali o di calibrazione	SI	non utilizzato:Tutte le code vedono le medesime CPU. Inoltre molte delle feature del LRMS non sono utilizzabili dal wrapping grid
21	*12 ) Sviluppi previsti come # di Slots nella coda*	Gli sviluppi dipenderanno dai finanziamenti ricevuti	Siamo un T-2 per ALICE quindi diverse centinaia di core nei prossimi anni	non sono previsti sviluppi al momento	?	~20 nuovi nei prossimi mesi	aggiunta entro pochi giorni di 28 nuove slot (7 biprocessori dual core)	circa costante	Inclusione dei nuovi nodi Intel Woodcrest (8 nodi x 4 CPU = 32 slot)	dipende dai referee	no nel 2007
22	*13 ) Prevedete un cambiamento di gestore di code nel prossimo futuro?*	Solo se le condizioni di utilizzo evidenziassero evidenti problemi di scalabilita'	NO	no	NO	Si se le condizioni di utilizzo evidenziano problemi di scalabilita'	si, verso LSF, in un tempo non ancora definito.	NO	NO	NO	NO
23	*14 ) Costo del gestore di code / provenienza licenze*	Torque/MAUI, entrambi open source.	Licenze CNAF via server FlexLM	OPENPBS e' gratuito	Licenze acquistate negli anni 2001-2004. Dal 2005 (o 2006?) non paghiamo piu' la manutenziona, a carico del contratto LSF-INF del CNAF	TORQUE/MAUI sono opensource e free	free	demo accademic licenses	Licenze CNAF	licenze centralizzate al T1	Licenza LGPL, progetto mantenuto da cluster resources (http://www.clusterresources.com/) come versione opensource del sistema commerciale MOAB
24	*15 ) Gestore di code unico per tutta la sezione o specifico per il T2?*	Torque/MAUI usati in piu' cluster, ma con installazioni separate	T2 + farm di CMS + farm di Gruppo IV. La farm di Gruppo III usa OpenPBS	unico per tutta la sezione	Al momento il T2 e la farm dei Laboratori hanno ancora 2 istanze separate di LSF, ma stiamo lavorando per unificarli e avere un gestore unico	specifico per il T2	specifico per il T2	LSF per 13 cluster (compreso T2). 2 cluster con SunGridEngine SGE	Specifico per i Tier2, ma utilizzato anche per i siti INFN-ROMA1-CMS e INFN-ROMA1-VIRGO	specifico T2 Atlas/CMS	assoluta anarchia
25	*16 ) Altre particolarita' del vostro sistema?*	Lo stesso batch server e' usato da piu' CE appartenenti a test-bed diversi che pero' condividono i WN.	- Controllo automatico del numero di job pending e messa automatica del sito in "draining mode" quando il numero di job pending supera 750. - Integrazione di MPICH-2 con gLite. - Supporto per WN con SLC 4.4 a 64 bit nativi	nessuna	-	tutti i WN son sotto rete privata	-	nessuna	Gestione congiunta per i tre sisti ospitati dalla sezione di ROMA1	nessuna	I nodi di calcolo non hanno indirizzi pubblici.
26	*17 ) Esperienza nella installazione (problemi / meraviglie) e nella gestione*	Instazione e management molto semplici. Necessita' di usare l'ultima versione per ottenere la scalabilita' necessaria.	Ottima	nessuna	-	installazione e management semplici, problemi di scalabilita' con torque 1.x	Installazione ed aggiornamenti con il resto del mw infn-grid, nessun problema	installazione LSF completamente automatizzata e integrata nel tool di installazione di una nuova farm. Software e le configurazioni distribuite centralmente via AFS	-	inst di LSF sui WN inserita nel kickstart	nulla di particolare
27	*18a) Problemi nella presente configurazione*	Nessuno legato al Batch System, pero' necessario prevedere lo splitting dei servizi Grid per aumentare la scalabilita' (Il CE puo' andare sovraccarico quando ci sono molti job)	Nessuno	nessuno	Nessuno specifico di LSF	NO	Nessuno in particolare, dobbiamo implementare il fair share per migliorare la condivisione delle risorse.	nessuno	-	nessuno	apparentemente nessuno
28	*18b) Pensate che il vs sistema possa scalare nei prossimi anni fino a coprire un T2?*	Dal comportamento visto fin'ora sembrerebbe di si. Ma siamo disponibili a cambiare sistema se mostrasse problemi.	CERTAMENTE	si	Si'	Si, ma possibile passaggio a LSF	per questo pensiamo ad un passaggio a LSF.	SI	SI	SI	adeguando opportunamente l'hardware
29	*18c) Grado di soddisfazione nell'utilizzo giornaliero*	Ottimo	PIENA	ottimo	Alto (e' forse l'unica cosa che non da' mai problemi)	Buono con l'ultima versione	buono	ottimo	Alto	buono.. nessuna lamentela al momento	-
30	*18d) Tempo necessario per il mantenimento giornaliero del gestore di code*	0, interventi solo in caso di cambiamento della configurazione di scheduling	MINIMO	circa il 5% della giornata lavorativa di un FTE	Solo quando serve modificare priorita', share, ecc.	Intervento solo in caso di cambiamneto parametri di scheduling (maui.cfg)	minimo	0	Mediamente pochi minuti al giorno	dipende, ancora in fase di tuning per avere una conf ottimale	Il gestore di code presenta problemi con una frequenza di diversi ordini di grandezza inferiore rispetto al resto del middleware.
31	*19 ) Avete provato/valutato altri sistemi di batch queuing?*	Si, condor	Si, prima usavano OpenPBS e poi Torque/MAUI	no	No, partiti fin dall'inizio con LSF	LSF	NO	PBS, SGE	Si: DQS, PBS, Torque/MAUI	PBS	LSF e' stato preso in considerazione.
32	*19a) Accennare a pro e contro riscontrati*	Difficolta' di configurare la parte grid, impossibilita' di gestire le code, in modo semplice.	LSF non ha mostrato finora dei "contro".	-	-	contro: difficolta' di configurazione, mancanza di documentazione e supporto open	-	PBS (scarsa scalabilita', poco stabile, CE spesso sovraccarico); SGE (solo in cluster locali)	Pro: semplicita' di configurazione; Contro: impossibilita' di FairShare adeguato e limitazioni sulla scalabilita'	non scalabile, meno flessibile, meno configurabile	LSF e' sistema proprietario e a licenza commerciale con caratteristiche analoghe. La scelta del sistema di code è fortemente limitato dalle poche funzionalità che vengono realmente sfruttate dal middleware grid.
33	*20 ) Esperienza col supporto tecnico*	Ottima.	OTTIMA	ottima	Buono	Il supporto per TORQUE/MAUI viene dalla comunity degli utenti, ottima documentazione e supporto open	nessuna interazione col supporto di PBS/Torque, buon supporto da parte del ROC.	LSF buono	Buona, attraverso i canali preferenziali dell'INFN	LSF buono	google funziona egregiamente