17
Vladimir Litvin, Harvey Newman Caltech CMS Scott Koranda, Bruce Loftis, John Towns NCSA Miron Livny, Peter Couvares, Todd Tannenbaum, Jamie Frey Wisconsin Condor Grid Infrastructure for Caltech CMS Production on Alliance Resources

Vladimir Litvin, Harvey Newman Caltech CMS Scott Koranda, Bruce Loftis, John Towns NCSA Miron Livny, Peter Couvares, Todd Tannenbaum, Jamie Frey Wisconsin

Embed Size (px)

Citation preview

Vladimir Litvin, Harvey Newman

Caltech CMS

Scott Koranda, Bruce Loftis, John Towns

NCSA

Miron Livny, Peter Couvares, Todd Tannenbaum, Jamie Frey

Wisconsin Condor

Grid Infrastructure for Caltech CMS Production on Alliance Resources

CMS Physics

The CMS detector at the LHC will probe fundamental forces in our Universe and search for the yet undetected Higgs Boson

Detector expected to come online 2006

CMS Physics

ENORMOUS Data Challenges

• One sec of CMS running will equal data volume equivalent to 10,000 Encyclopaedia Britannica

• Data rate handled by the CMS event builder (~500 Gbit/s) will be equivalent to amount of data currently exchanged by the world's telecom networks

• Number of processors in the CMS event filter will equal number of workstations at CERN today (~4000)

Leveraging Alliance Grid Resources

• The Caltech CMS group is using Alliance Grid resources today for detector simulation and data processing prototyping

• Even during this simulation and prototyping phase the computational and data challenges are substantial

Challenges of a CMS Run

• CMS run naturally divided into two phases

– Monte Carlo detector response simulation

– 100’s of jobs per run– each generating ~ 1 GB– all data passed to next

phase and archived

– reconstruct physics from simulated data

– 100’s of jobs per run– jobs coupled via

Objectivity database access

– ~100 GB data archived

• Specific challenges

– each run generates ~100 GB of data to be moved and archived

– many, many runs necessary

– simulation & reconstruction jobs at different sites

– large human effort starting & monitoring jobs, moving data

Meeting Challenge With Globus and Condor

Globus

• middleware deployed across entire Alliance Grid

• remote access to computational resources

• dependable, robust, automated data transfer

Condor• strong fault tolerance

including checkpointing and migration

• job scheduling across multiple resources

• layered over Globus as “personal batch system” for the Grid

CMS Run on the Alliance Grid

• Caltech CMS staff prepares input files on local workstation

• Pushes “one button” to launch master Condor job

• Input files transferred by master Condor job to Wisconsin Condor pool (~700 CPUs) using Globus GASS file transfer

Master Condor job running at

Caltech

Caltech workstation

Input files via Globus GASS

WI Condor pool

CMS Run on the Alliance Grid

• Master Condor job at Caltech launches secondary Condor job on Wisconsin pool

• Secondary Condor job launches 100 Monte Carlo jobs on Wisconsin pool

– each runs 12~24 hours– each generates ~1GB

data– Condor handles

checkpointing & migration

– no staff intervention

Master Condor job running at

Caltech

Secondary Condor job on WI pool

100 Monte Carlo jobs on Wisconsin Condor pool

CMS Run on the Alliance Grid

• When each Monte Carlo job completes data automatically transferred to UniTree at NCSA

– each file ~ 1 GB– transferred using

Globus-enabled FTP client “gsiftp”

– NCSA UniTree runs Globus-enabled FTP server

– authentication to FTP server on user’s behalf using digital certificate

100 Monte Carlo jobs on Wisconsin Condor pool

NCSA UniTree with

Globus-enabled FTP server

100 data files transferred via gsiftp, ~ 1 GB each

CMS Run on the Alliance Grid

• When all Monte Carlo jobs complete Secondary Condor reports to Master Condor at Caltech

• Master Condor at Caltech launches job to stage data from NCSA UniTree to NCSA Linux cluster– job launched via Globus

jobmanager on cluster– data transferred using

Globus-enabled FTP– authentication on user’s

behalf using digital certificate

Master starts job via Globus jobmanager on cluster to stage data

Secondary Condor job on WI pool

NCSA Linux cluster

Secondary reports complete to master

Master Condor job running at

Caltech

gsiftp fetches data from UniTree

CMS Run on the Alliance Grid

• Master Condor at Caltech launches physics reconstruction jobs on NCSA Linux cluster– job launched via Globus

jobmanager on cluster– Master Condor continually

monitors job and logs progress locally at Caltech

– no user intervention required– authentication on user’s

behalf using digital certificate

Master Condor job running at

Caltech

Master starts reconstruction jobs via Globus jobmanager on cluster

NCSA Linux cluster

CMS Run on the Alliance Grid

• When reconstruction jobs complete data automatically archived to NCSA UniTree– data transferred using

Globus-enabled FTP

• After data transferred run is complete and Master Condor at Caltech emails notification to staff

NCSA Linux cluster

data files transferred via gsiftp to UniTree for archiving

Production Data

• 7 Signal Data Sets 50000 events each have been simulated and reconstructed without pileup

• Large QCD background Data Set (1M of events) has been simulated through this system

• Data has been stored both NCSA UniTree and Caltech HPSS

Condor Details for Experts

• Use CondorG– Condor + Globus– allows Condor to submit

jobs to remote host via a Globus jobmanager

– any Globus-enabled host reachable (with authorization)

– Condor jobs run in the “Globus” universe

– use familiar Condor classads for submitting jobs

universe = globusglobusscheduler = beak.cs.wisc.edu/jobmanager- condor-INTEL-LINUXenvironment = CONDOR_UNIVERSE=scheduler

executable = CMS/condor_dagman_runarguments = -f -t -l . -Lockfile cms.lock -Condorlog cms.log -Dag cms.dag -Rescue cms.rescueinput = CMS/hg_90.tar.gzremote_initialdir = Prod2001

output = CMS/hg_90.outerror = CMS/hg_90.errlog = CMS/condor.log

notification = alwaysqueue

Condor Details for Experts

• Exploit Condor DAGman– DAG=directed acyclic graph– submission of Condor jobs

based on dependencies– job B runs only after job A

completes, job D runs only after job C completes, job E only after A,B,C & D complete…

– includes both pre- and post-job script execution for data-staging, cleanup, or the like

Job jobA_632 Prod2000/hg_90_gen_632.cdrJob jobB_632 Prod2000/hg_90_sim_632.cdrScript pre jobA_632 Prod2000/pre_632.cshScript post jobB_632 Prod2000/post_632.cshPARENT jobA_632 CHILD jobB_632

Job jobA_633 Prod2000/hg_90_gen_633.cdrJob jobB_633 Prod2000/hg_90_sim_633.cdrScript pre jobA_633 Prod2000/pre_633.cshScript post jobB_633 Prod2000/post_633.cshPARENT jobA_633 CHILD jobB_633

Future Directions

• Include Alliance LosLobos Linux cluster at AHPCC in two ways– Add path so that physics

reconstruction jobs may run on Alliance LosLobos Linux cluster at AHPCC in addition to NCSA cluster

– Allow Monte Carlo jobs at Wisconsin to “glide-into” LosLobos

– Add pileup datasets

Master Condor job running at

Caltech

Secondary Condor job on WI pool

75 Monte Carlo jobs on Wisconsin Condor pool

25 Monte Carlo jobs on LosLobos via Condor glide-in