Distributed Analysis Tools Panda Ganga Tadashi Maeno

Distributed Analysis Tools Panda & Ganga Tadashi Maeno (Brookhaven National Laboratory)

Distributed Analysis on Grid (script, exe) Local analysis Grid A framework to utilize large-scale and geographically distributed resources Limited resources Ø 1~4 CPUs Ø~1 TB of disk 2

Distributed Analysis on Grid Local analysis 3

Distributed Analysis on Grid Ø Run own analysis on distributed resources – Parallelization for fast turnaround • 1 CPU× 800 hours 800 CPUs× 1 hour – Unavoidably distributed data • 10 T 1 computing center for ATLAS, but no T 1 can host all data 4

Traditional Procedure of DA Grid brokerage ü Site selection Gate Keeper = Computing Element Local analysis ü File upload ü Authentication CPUs = Worker Nodes ü Job execution Storage ü Input/Output data 5

Traditional Procedure of DA brokerage Grid ü Site selection Gate Keeper = Computing Element Different among Local analysis grid-flavors = grid-middleware 　　　　dependent ü File upload ü Authentication CPUs = Worker Nodes local batch-system condor, LSF, PBS, … ü Job execution local storage for EGEE/OSG Storage dcap, dpm, xrootd, castor remote storage for NDGF 6 ü Input/Output data

Three middleware e. g. , upload a file using different protocol EGEE Grid = EGEE backend OSG backend NDGF backend Not entirely true ! Just for intuitive understanding 7

Simple Implementation of Common User I/F for Various Backends def upload (file, backend. Type): if backend. Type==EGEE: egee. Module. upload(file) elif backend. Type==OSG: osg. Module. upload(file) elif backend. Type==NDGF: ndgf. Module. upload(file) Ø Prepare a plug-in module for each backend Ø Implementation of GANGA to support multiple backends Ø Easily extended for other backends 8

Simple Implementation of Common User I/F for Various Backends Ø Ultimately users have to understand each backend – e. g. , connection failure each backend uses a different port check each port Ø 3 backends expertise and support/development work are 3 times more – Limited manpower Ø Capability for easy extension is useful in R&D phase but is redundant in production phase 9

Common I/F using pilot (PANDA System) Panda server NDGF pilot arc pull a. CT https analysis job OSG pilot job https submit EGEE End-user pilot Pilot factory 10

Common I/F using pilot (PANDA System) Panda server NDGF pilot Users access a common server using a single protocol pull arc a. CT https analysis job OSG pilot Interaction with backends jobis done centrally https submit EGEE End-user pilot Pilot factory 11

Operation/Service Model of PANDA Ø End-users are insulated from GRID – Communicate with the Panda (HTTP) server – Lower threshold especially for physicists Ø Pilot factory sends pilots using GRID middleware – Only the operator of the scheduler needs to have enough expertise on GRID Ø Production and Analysis run on the same infrastructure – Production should suffer from the same problem as analysis – Once production team (one shift crew) fix the problem for official production, analysis get cured automatically no additional manpower is needed for analysis 12

Panda Ø PANDA = Production ANd Distributed Analysis system – Designed for analysis as well as production – Project started Aug 2005, prototype Sep 2005, production Dec 2005 – The backend for all ATLAS production jobs – The primary backend for all ATLAS anaysis jobs Ø A single task queue and pilots – Apache-based Central Server – Pilots retrieve jobs from the server as soon as CPU is available low latency Ø Highly automated, has an integrated monitoring system, and requires low operation manpower Ø Integrated with ATLAS Distributed Data Management (DDM) system 13

Panda System Overview Prod. DB prod job bamboo DQ 2 Panda server LFC logger pull NDGF https analysis job pilot OSG job https submit a. CT EGEE End-user submit arc pilot submit condor-g autopyfactory Worker Nodes 14

Ownership Issue Ø GK maps each job to individual UNIX ID – In traditional model, each user sends job to GK possible to know who runs a process – In pilot models, pilot factory sends pilots to GK impossible to distinguish processes using UID. Note that each role is mapped to a different UID and thus it is possible to distinguish role-ed users from end-users Ø Separation between physical/logical layers is popular – Virtualization (e. g. , cloud, LVM, …) – But conflicts with a “policy” Ø WLCG is going to introduce glexec which changes UID on WN – Each site admin will be able to see who runs a process without peeking logical layer – File ownership is unrelated to UID since SRM itself sets owner using proxy – Only proxy delegation is required (glexec requires proxy delegation) 15

panda-client Ø Tools to submit or manage analysis jobs on Panda Ø Five tools – pathena • Athena jobs – prun • General jobs (ROOT, python, sh, exe, …) – pbook • Bookkeeping – psequencer • Analysis chain (e. g. , submit job + download output) – puserinfo • Access control 16

pathena (1/2) Ø To submit Athena jobs to Panda Ø A simple command line tool, but contains advanced capabilities for more complex needs Ø Provides a consistent interface to users who are familiar with Athena $ athena job. O. py $ pathena job. O. py -–in. DS input. Dataset. Name -–out. DS output. Dataset. Name 17

pathena (2/2) Ø What pathena does 1. Extract job configuration by running Athena with fake application manager 2. Collect source/job. O files in local working area 3. Assign the job to a site where ü Athena version is available ü Input datasets is available ü CPUs are free 4. Prepare one build. Job to compile source files, and one or many run. Athena jobs to run Athena 5. Send them to Panda 18

What happens when job is submitted (1/2) Local pathena submit Remote sources dq 2 download build. Job x 1 Single Job = run. Athena x N compile build. Job trigger binaries Storage binaries outputs run. Athena inputs output dataset Automatically split input dataset 19

What happens when job is submitted (2/2) Ø Why build. Job is required? – Platform (OS, CPU-architecture) may be different between local and remote • Sl 5/64 bit binaries cannot run on SL 4/32 bit – Athena creates some absolute links in Install. Area, i. e. , generally not relocatable – The total time of (build. Job + N x run. Athena) is shorter than N x (build. Job+run. Athena) • Use CPUs more efficiently – build. Job can be skipped using an option if you know the step is not required 20

prun Ø To submit General jobs to Panda – ROOT (ARA), Python, shell script, exe … Ø Two-staged Analysis Model of ATLAS – Run Athena on AOD/ESD to produce DPD pathena – Run ROOT or something on DPD to produce final plots prun Ø In principle you can do anything, but please avoid careless network operations unless you know well about scalability of those operations – svn co, wget, lcg-cp … – A single job is split to many sub-jobs running in parallel which can easily break remote servers 21

pbook Ø Bookkeeping of Panda jobs – Browsing – Kill – Retry Ø Make local sqlite 3 repository to keep personal job information – IMAP like sync-diff mechanism – Not scanning global Panda repository quick response Ø Dual user interface – Command-line – Graphical 22

Ganga. Panda Ø Plug-in to access PANDA def upload (file, backend. Type): if backend. Type==EGEE: egee. Module. upload(file) elif backend. Type==OSG: osg. Module. upload(file) elif backend. Type==NDGF: ndgf. Module. upload(file) elif backend. Type==PANDA panda. Module. upload(file) Ø All ATLAS backends will be consolidated to PANDA Ø Other backends are still maintained for some reason 23

Links Ø User support hn-atlas-dist-analysis-help@cern. ch Ø Bug report Savannah Ø Documentations panda-client package pathena prun Pbook ganga 24