Sistema de producción de datos de ATLAS

Sistema de producción de datos de ATLAS

Julio Lozano BahiloUniversidad de Granada

Introducción

1/13Julio Lozano Bahilo

Objetivo :Automatización de las tareas necesarias para efectuar la generación, simulación y reconstrucción masiva de datos de ATLAS (DC2) empleando los recursos disponibles gracias a la tecnología GRID

Optimización del uso de las CPUs y elementos de almacenamiento

Estudio exhaustivo en condiciones extremas del middleware y del hardware: estabilidad del sistema, capacidad de almacenamiento, ancho de banda, etc …

Arquitectura :Sistema modular lo más simple y flexible posible:

1. Repositorio con trabajos a ejecutar y todo tipo de información acerca de los ficheros de entrada, de salida y de su estado de ejecución

Introducción


2. Agente que se comunica con dicho repositorio, extrayendo la información precisa para crear los trabajos (jobs) y actualiza la información presente en él

3. Agente que intercambia información con el agente previo y envia los trabajos al GRID; por ello depende del “sabor” GRID

4. Sistema de acceso uniforme a los datos empleado por el agente que gestiona la ejecución de los trabajos. Transfiere los ficheros de entrada necesarios y copia los archivos producidos a un elemento de almacenamiento

Esquema de producción


LCG NG Grid3 LSF

LCGexe

LCGexe

NGexe

G3exe

LSFexe

prodDB DMS

super super super super super

RLS RLS RLS

jabber jabber jabber jabber jabber

LexorDulcinea

Capone

Don Quijote

Windmill

Legacy

Base de datos


ProdDBServidor Oracle en el CERN : comunicación via queries SQLConsta de diferentes tablas :

TASK

JOBTRANS LOGICALFILEJOBDEFINITION

Colección de trabajos asociados a una misma transformación

Transformación :•versión del software •generación/simulación/

reconstrucción•tipo de datos

Definición abstracta del trabajo, incluyendo todos los parámetros necesarios para su ejecución : transformación, ficheros de entrada y salida, etc …

Información sobre los ficheros generados : LFN y GUID de los ficheros de datos y el log

Estado de cada intento de ejecución del trabajo e información adicional : supervisor, ejecutor, CE, mensaje de error en caso de fallo

JOBEXECUTION

Supervisor


WindmillTanto el supervisor como el ejecutor son paquetes escritos en Python y corren en un UI ( User Interface )Funcionalidad del supervisor :• Gestionar los trabajos residentes en la base de datos :

1. Extraer su definición y traspasarla al ejecutor en formato XML ( tabla jobdefinition )

2. Obtener información acerca del estado de los trabajos enviados a GRID a través del ejecutor y actualizar la base de datos ( tablas jobexecution y jobdefinition )

• Verificar la correcta finalización de los trabajos accediendo a través de Don Quijote al RLSUn fichero de configuración determina diversos parámetros de operación del supervisor. Alguno de ellos está relacionado con las máquinas empleadas:

Supervisor


• servidor jabber Y otros con el tiempo de espera para que el supervisor realice las operaciones pertinentes:• petición de nuevos trabajos• información de tabajos en espera• estado actual de procesos en ejecución• información de trabajos finalizados

tiempos a optimizar

Supervisor


WindmillnumJobsWantedexecuteJobsgetExecutorDatagetStatuskillJob

Via de comunicación

jabber ejecutores

Don Quijote(gestión de datos) Centros

GRID

1. lexor2. dulcinea3. capone4. legacy5. rocinante

supervisores

Centros GRID

Base de datosde producción

Supervisor


WindmillLa comunicación con el ejecutor se hace en base a 5 mensajes

codificados en XML a través de un servidor jabber :i. numJobsWanted

el supervisor pide al ejecutor que haga una estimación del numero de CPUs disponibles en maquinas que cumplen los requisitos apropiados ( versión del software, CPU MHzs, memoria RAM )

ii. executeJobstransmite la definición del trabajo al ejecutor para su posterior envío a un CE

iii. getExecutorDataobtiene el identificador único de los trabajos enviados a GRID

iv. getStatusrecibe información acerca del estado del trabajo y si ha acabado, ordena al ejecutor que registre los ficheros de salida

v. killJob

Ejecutor


LexorAl igual que el supervisor, está implementado en Python. Se

ejecuta en un UI.Requiere de una credencial para enviar los trabajos y esa

credencial se debe guardar en un Proxy Server para que la credencial guardada localmente sea renovada antes de que expire ( WN RB PS )

El ejecutor depende del sabor GRID dado que utiliza el middleware asociado a cada proyecto: LCG-2 ( basado en EDG ) en nuestro caso

Funcionalidad del ejecutor :• Suministrar información al supervisor :

1. Numero de CPUs disponibles ( contacta BDII )2. Estado de los trabajos en ejecución3. Estado de los trabajos finalizados

Ejecutor


• Enviar los trabajos a ejecución :1. Traducir la descripción del trabajo de XML a JDL2. Enviar trabajo a RB para ejecución en CE

Un fichero de configuración determina las máquinas a utilizar ( RB, BDII, Proxy Server ), el número máximo de trabajos en ejecución y permite restringir los centros donde corren los trabajos

El script que se ejecuta en un WN ( Worker Node ) realiza los siguientes pasos:

Verifica la instalación del software del experimento Copia el paquete de la transformación a efectuar Copia los ficheros de entrada a través de DQ Ejecuta el programa del experimento para

generar/simular/reconstruir los sucesos Copia los ficheros de salida a un SE mediante DQ

Ejecutor


El ejecutor para la infra-estructura GRID de LCG es Lexor. Intercambia mensajes de tipo XML via jabber con el supervisor y envía los trabajos a ejecución

<jobDef><jobDefID>163334</jobDefID><jobName>dc2.003026.simul.A0_top._02814.job</jobName><transUses>JobTransforms-8.0.5.6 Atlas-8.0.5</transUses><transImplementation>share/dc2.g4sim.trf</transImplementation><transHomePackage>JobTransforms-8.0.5.6</transHomePackage><expectedResources><cpuConsumption><count>25000</count><unit>specint2000hours</unit></cpuConsumption><diskConsumption><count>500</count><unit>MB</unit></diskConsumption><ipConnectivity>yes</ipConnectivity><minimumRAM><count>512</count><unit>MB</unit></minimumRAM></expectedResources><jobInputs><fileInfo><LFN>dc2.003026.evgen.A0_top._00071.pool.root.1</LFN><logCol>/datafiles/dc2/evgen/dc2.003026.evgen.A0_top/</logCol><turlList/></fileInfo></jobInputs><jobOutputs><fileInfo><LFN>dc2.003026.simul.A0_top._02814.pool.root.1</LFN><logCol>/datafiles/dc2/simul/dc2.003026.simul.A0_top/</logCol><dataset><name>dc2.003026.simul.A0_top</name></dataset><SEList><SE>castorgrid.cern.ch</SE></SEList></fileInfo></jobOutputs><jobLogs><fileInfo><LFN>dc2.003026.simul.A0_top._02814.job.log.1</LFN><logCol>/logfiles/dc2/simul/dc2.003026.simul.A0_top/</logCol><dataset><name>dc2.003026.simul.A0_top.log</name></dataset><stream>stdboth</stream><SEList><SE>castorgrid.cern.ch</SE></SEList></fileInfo></jobLogs><jobPars><actualPar><name>inputfile</name><position>1</position><type>LFN</type><metaType>inputLFN</metaType><value>dc2.003026.evgen.A0_top._00071.pool.root</value></actualPar><actualPar><name>outputfile</name><position>2</position><type>LFN</type><metaType>outputLFN</metaType><value>dc2.003026.simul.A0_top._02814.pool.root.1</value></actualPar><actualPar><name>etamin</name><position>3</position><type>float</type><metaType>plain</metaType><value>-6</value></actualPar><actualPar><name>etamax</name><position>4</position><type>float</type><metaType>plain</metaType><value>6</value></actualPar><actualPar><name>total</name><position>5</position><type>natural</type><metaType>plain</metaType><value>100</value></actualPar><actualPar><name>skip</name><position>6</position><type>natural</type><metaType>plain</metaType><value>1300</value></actualPar><actualPar><name>ranseed</name><position>7</position><type>natural</type><metaType>plain</metaType><value>2814</value></actualPar></jobPars></jobDef>

XML job

description [

Requirements = ( ( ( ( Member("VO-atlas-lcg-release-0.0.2",other.GlueHostApplicationSoftwareRunTimeEnvironment) ) && \( Member("VO-atlas-release-8.0.5",other.GlueHostApplicationSoftwareRunTimeEnvironment) ) && \( other.GlueCEPolicyMaxCPUTime >= ( Member("LCG-2_1_0",other.GlueHostApplicationSoftwareRunTimeEnvironment) \? ( 90000000 / 60 ) : 90000000 ) / other.GlueHostBenchmarkSI00 ) ) && \( other.GlueHostNetworkAdapterOutboundIP == true ) ) && \( other.GlueHostMainMemoryRAMSize >= 512 );RetryCount = 0;Arguments = "dc2.003026.evgen.A0_top._00071.pool.root dc2.003026.simul.A0_top._02814.pool.root.1 -6 6 100 1300 2814";Environment = {"LEXOR_WRAPPER_LOG=lexor_wrapper.log", "LEXOR_STAGEOUT_MAXATTEMPT=5","LEXOR_STAGEOUT_INTERVAL=60","LEXOR_LCG_GFAL_INFOSYS=lxb2011.cern.ch:2170","LEXOR_T_RELEASE=8.0.5","LEXOR_T_PACKAGE=8.0.5.6/JobTransforms","LEXOR_T_BASEDIR=JobTransforms-08-00-05-06","LEXOR_TRANSFORMATION=share/dc2.g4sim.trf","LEXOR_STAGEIN_LOG=dq_163334_stagein.log","LEXOR_STAGEIN_SCRIPT=dq_163334_stagein.sh","LEXOR_STAGEOUT_LOG=dq_163334_stageout.log","LEXOR_STAGEOUT_SCRI PT=dq_163334_stageout.sh"};MyProxyServer = "lxb0727.cern.ch";Executable = "lexor_wrap.sh";StdOutput = "dc2.003026.simul.A0_top._02814.job.log.1";OutputSandbox = { "metadata.xml","lexor_wrapper.log","dq_163334_stagein.log","dq_163334_stageout.log","dc2.003026.simul.A0_top._02814.job.log.1" };VirtualOrganisation = "atlas";Rank = ( -other.GlueCEStateEstimatedResponseTime );StdError = "dc2.003026.simul.A0_top._02814.job.log.1";InputSandbox = {"lexor/inputsandbox/lexor_wrap.sh","lexor/inputsandbox/dqlcg.py","lexor/inputsandbox/edgrmpi.sh","lexor/inputsandbox/dqrep.pl","lexor/inputsandbox/run_dqlcg.sh","/tmp/lexor/rebatto/dq_163334_stagein.sh","/tmp/lexor/rebatto/dq_163334_stageout.sh"}]

Job Description

Language

Supervisor Lexor

cliente jabber

XML parser

gestor de trabajos

Workload Management SystemAPI

El ejecutor también recupera la información sobre el estado del trabajo y si acaba correctamente registra los ficheros de salida. Transmite la información al ejecutor via XML igualmente

UI UI

jobdefinitionjobexecution

Flujo de tareas


Supervisor EjecutorServ. jabbernumJobsWanted

BDII

executeJobs

RBCE

getExecutorDatagetStatus

SE

RLS DQ

ProdDB

SQL ldap

EDG WMS API

job wrapper

Comentarios


1. Ejemplo de empleo de tecnología GRID aplicada a la producción, procesado y almacenado de datos en AA.EE.

2. Se ha sometido la infraestructura GRID ( tanto middleware como hardware y personal humano ) a un continuo esfuerzo para mejorar las prestaciones del sistema

3. Empleo de diferentes tecnologías para implementar un sistema en cuya base tenemos la tecnología GRID

4. GRID está ‘vivo y coleando’ y va dando frutos visibles

Sistema de producción de datos de ATLAS

Documents

Transcript of Sistema de producción de datos de ATLAS