Distributed analysis challenge test: en el Tier2 Español de ATLAS S. González de la Hoz IFIC – Institut de Física Corpuscular de València VI Reunión presencial del Tier2 Español Distribuido de ATLAS Barcelona, 27-Noviembre-2008

Santiago González de la Hoz, VI Reunión presencial del Tier2, Barcelona 27-Noviembre Resumen reunión de análisis 20-Nov por EVO (asistentes Pablo, Jordi, Santi)  Índice: Objetivos Herramientas usadas en los test y resultados de dichos test Expansión a otras “clouds”

Santiago González de la Hoz, VI Reunión presencial del Tier2, Barcelona 27-Noviembre Objetivos  Validación de los centros y de la “cloud” a la hora de hacer análisis de datos Los trabajos de Monte Carlo son diferentes a los de análisis.  Un sitio puede estar funcionando bastante bien con los trabajos de MC pero podría tener un rendimiento pobre para los de análisis  Identificar los puntos conflictivos y los cuellos de botellas en el centro y/o “cloud”.

Santiago González de la Hoz, VI Reunión presencial del Tier2, Barcelona 27-Noviembre Herramientas utilizadas  Utilizan Ganga Enviar trabajos a los diferentes centros Monitorizar el estado de dichos trabajos permitiéndoles hacer un informe cuando ellos acaben  Código real de análisis utilizados por los físicos Primeras semanas mismos trabajos a todo el mundo  Munon Analysis algorithm y mismos Datasets  Ganga LCG backend WMS (CE)  Poxis I/O y “Copy” mode

Santiago González de la Hoz, VI Reunión presencial del Tier2, Barcelona 27-Noviembre Los tests  Identificación de la aplicación(es) para correr los tests Primer test con un algoritmo de análisis común (muones)  Futuros tests con algoritmos de análisis usados por los físicos de los centros Replicar los datasets en la “cloud” Preparar los trabajos de análisis y hacer pequeños tests de validación Enviar los trabajos al WMS  Decidir colas donde correrán los trabajos y prioridades No tenemos colas dedicadas exclusivamente al análisis. ¿Y si están llenas las colas? Actualmente los trabajos se envían al Ganga LCG backend (en el futuro funcionará corriendo sobre Panda ANALY_*queues)  Los trabajos de Ganga recogen estadística El output de los trabajos (correrán con el rol de usuario, caso real ) se copiarán en el ATLASUSERDISK spacetoken???

Santiago González de la Hoz, VI Reunión presencial del Tier2, Barcelona 27-Noviembre Resultados de los tests  Empezaron a correr estos tests en las clouds IT y DE hace un mes  2-5 usuarios enviaron un análisis de muones sobre AODs tanto a la nube IT como DE. 200 trabajos enviados por usuario, en total 1000 por centro Los trabajos leían directamente los datos del SE usando poxis I/0  Ellos produjeron una serie de métricas: De rendimiento:  Éxito/fallo rate, CPU/Walltime, Sucesos por segundo Clasificación de errores  Diferentes errores I/O

Santiago González de la Hoz, VI Reunión presencial del Tier2, Barcelona 27-Noviembre Resultado de los tests:  Los Tier2 saturaron su network a 1Gb. Si asumimos 0.2 MB por suceso, a 1 Gb de conexión se puede sacar “stream” a 640 HZ. Con 200 CPUs, se observó y se esperaba ~3Hz. 15 HZ hubiera sido lo deseado En el IFIC, nuestros dos servidores de disco cada uno a 1 Gb y nuestros trabajadores cada uno también a 1 Gb. (Switch cisco4500)  Descubrieron en un Tier2 y switch que funcionaba mal  Encontraron un fallo en athena Twiki:

Santiago González de la Hoz, VI Reunión presencial del Tier2, Barcelona 27-Noviembre Expansión a otras “clouds”  Participación activa de la gente en la “cloud” Contacto de la Cloud  Les dice a Johannes y Danniel los centros listos para testear  Coordinación de los centros antes y después de los tests. Contactos de los centros  Los tests y los plots se producen de forma centralizada pero para ello, para digerir toda la información se necesitan expertos en cada centro, sobre todo para entender posibles errores. Estar en el TierofATLAS (ganga utiliza este fichero al igual que dq2) Espacio en disco algunos GB Objetivos  Inicialmente una eficiencia del 80% con una media de 15 Hz por trabajo  Ideal: 95% con una media de 20 Hz

Santiago González de la Hoz, VI Reunión presencial del Tier2, Barcelona 27-Noviembre “SWE clouds (coordinado por Xavi)”  Involved sites (responsible) PIC (Xavi), IFAE (Jordi), IFIC (Santi), UAM (Pablo), LIP-LISBON (Mario y Goncalo), LIP-COIMBRA (Helmut y Miguel Oliveira)  Job Brokering WMS, very short term (direct submission to the CEs) Each site send the queue(s) names where to send the jobs (CE ready)  IFIC: ce01.ific.uv.es:2119/jobmanger-pbs-short ce01.ific.uv.es:2119/jobmanager-pbs-atlasL ce01.ific.uv.es:2119/jobmanager-pbs-atlas WMS (wms01.ific.uv.es)  Volver a decir aqui el problema con las prioridad de las colas PanDa, medium term, backend not yet ready in Ganga  Need dedicated queues in PanDa: ANALY_*sitename* that can be associated to a already working queue or a brand new one. Need to know where to point every Panda  queue: f.i. at PIC we have: ANALY_PIC => ce07-long

Santiago González de la Hoz, VI Reunión presencial del Tier2, Barcelona 27-Noviembre “SWE clouds (coordinado por Xavi)”  Job Submission Job Submitters (Correct SW releases installed)  Jobs sent centrally with Daniel's or Johannes certificate during the very first phase (Análisis de muones).  Later phase (TBC) jobs sent by our physicists running user analysis rather than AOD muon analysis that will be used as common job for DA-FT. Jobs sent without production Role (correct use case) while using WMS.  ¿Insisto, se copian ATLASUSERDISK spacetoken el output? When changing to Panda this should be revised and tuned.  I'd like to push for sending jobs in a daily basis rather than weekly. Free resources could swallow the jobs in a single day, hence not testing the sites for the rest of the week (this is happening for MC-FT right now)

Santiago González de la Hoz, VI Reunión presencial del Tier2, Barcelona 27-Noviembre “SWE clouds (coordinado por Xavi)”  Data Access protocols: Ganga uses by default Posix I/O to access the input files, this means (Srmv2 + ST ready):  'dcap://...' is used for dCache,  'rfio://...' is used for Castor or DPM  'file://...' is used for Storm SEs to directly read the files on the WN from the SE.  IFIC: utilizamos Lustre y Ganga puede averiguar donde está físicamente el fichero en nuestro SE: “ file:// “ para poder leer directamente los input datafile:// “ para "copy mode", this uses dq2-get from the local SE to the WN, to be tested after the posix I/O tests. Notice that *there's no need to mount the FS in the WN*

Santiago González de la Hoz, VI Reunión presencial del Tier2, Barcelona 27-Noviembre “SWE clouds (coordinado por Xavi)”  Monitoring They will centrally record job metrics such as walltime, cpu utilization, and number of events/files. But also a "digested" report per site/cloud could provide relevant info when relevant:  Bandwidth WN-SE  CPU/Walltime efficiency  Loads on the srm/pnfs/  EN EL IFIC utilizaremos nuestras herramientas de monitorización para poder evaluar estas métricas y dar el report. Perhaps we could work out a dashboard where to plot the relevant information for all sites? Requirements and roadmap (need to be confirmed per site)

Santiago González de la Hoz, VI Reunión presencial del Tier2, Barcelona 27-Noviembre “ES cloud test on 26th to 27th November”  Daniel has scheduled a test on 26 November morning at 10AM: Test #37:  Start Time: :00:00  End Time: :00:00  Max Jobs Per Site (depends on dataset availability): job per dataset available  Input Type: DQ2_LOCAL  Sites: PIC_MCDISK, IFIC-LCG2_MCDISK, IFAE_MCDISK_UAM-LCG2_MCDISK, LIP- LISBON_MCDISK  Input DS Patterns: mc08.*Wmunu*.recon.AOD.e*_s*_r5*tid* mc08.*Zprime_mumu*.recon.AOD.e*_s*_r5*tid* mc08.*Zmumu*.recon.AOD.e*_s*_r5*tid* mc08.*T1_McAtNlo*.recon.AOD.e*_s*_r5*tid* mc08.*H*zz4l*.recon.AOD.e*_s*_r5*tid* mc08.*.recon.AOD.e*_s*_r5*tid*  We can watch the test progress here: Podemos ver los plots y dicustir los resultados  Nuevo Test # November from 12:00 to 16:00 in order to solve problems with LIP (not dataset and dq2 incompatibilities, version to be used ) Problemas con la release de atlas en la UAM (required athena )