Data placement/managment g S Jézéquel

Data placement/managment g S Jézéquel

S. Jézéquel

Atl k (O t b 2009)

Atlas week (October 2009)

Introduction

Presentation of the policy on data management for 2009 on Grid sites

at CERN for non Grid (can/should be followed up by other sites) at CERN for non Grid (can/should be followed up by other sites)

Based on the available management tools (Grid and infrastructure)

Evolutions regularly discussed within relevant meetings (ADC,CREM,TOB) P li t b i d d 2009 f ll i

Policy to be reviewed end 2009 following:

Feedback from 2009 experience during/after data-taking Improvement on Grid/infrastructure management tools

M i f ti f it i

More informations from monitoring

Outline

Introduction

Orders of magnitude

St t f G id t l f d t t

Status of Grid tools for data management ATLAS replication policy

O i ti f d t ithi it

Organisation of data within a site

Current implementation of central replication policy E tra replication of data on demand

Extra replication of data on demand Replication of user dataset

R li ti t l l

Replication to local area Read/write access to storage C t l d l ti li

Central deletion policy Monitoring tools

Di k it

Disk occupancy per site

Orders of magnitude

According to information filled in According to information filled in Data Distribution Management (DDM)

(V. Garonne)

X10

Tools for data management on Grid

Grid tools are efficient to replicate data between distant sites Even now used for migrations within site (DISK <-> TAPE)

Implemented in 2008: Classify data per activity type Implemented in 2008: Classify data per activity type

and define quotas (->space token)

z

Reserve disk space per activity

z

Better understanding of disk usage between activities

z

Cross-check with DDM information (‘useless files hunting’)

z

Cross check with DDM information ( useless files hunting )

z

Enforce matching between space token and path on storage

ATLAS Data Organisation

token name used for @T2@ @T1@ @T0@

ATLASDATATAPE RAW data,

ESD, AOD from re-proc

X X

ATLASDATADISK ESD AOD from data X X X

ATLASDATADISK ESD, AOD from data X X X

ATLASMCTAPE HITS from G4,

AOD from ATLFAST

X

ATLASMCDISK AOD from MC X X X

ATLASPRODDISK buffer for in-and export X

ATLASGROUPDISK DPD X X X

ATLASGROUPDISK DPD X X X

ATLASUSERDISK Temp. User Data X X *) X

ATLASLOCALGROUPDISK Local User Data @T3 X

ATLASLOCALGROUPDISK Local User Data @T3 X

Central operation management Central operation management Phys/Perf group data

User data

Central replication policy

Management of datasets produced centrally Management of datasets produced centrally Based on the ATLAS Computing Model

Real data (first processing):

RAW : 2 copies: CERN (TAPE) Tier 1 (TAPE) RAW : 2 copies: CERN (TAPE), Tier 1 (TAPE) ESD : 2 copies: CERN (TAPE), T1 (DISK)

AOD/DPD : at least one copy on disk per cloud + CERN (DISK) Simulated data:

EVNT replicated to 5 T1s

HITS kept on both DISK and TAPE at T1 HITS kept on both DISK and TAPE at T1 ESD kept at T1 (DISK)

AOD/DPD : at least one copy per cloud + CERN (DISK)

DPD placement: To be exercised when number of files and TB known

Central replication policy within cloud

Example: FDR2

Replication policy defined within cloud

Example: FDR2

Replication policy defined within cloud (A. Klimentov)

50 % f t B t AOD

5 % of all AOD

50 % of stream Beauty AOD

Share of real data to be defined in:

http://atladcops.cern.ch:8000/drmon/crmon_TiersInfo.html

Extra DDM transfer request

Submit a request for dataset transfer with DDM:

Submit a request for dataset transfer with DDM:

-To be validated by cloud responsible according to:

according to:

zCoherence with ATLAS/cloud policy

Di k il bilit t t t

zDisk space availability at target

zCompetition with predefined transfers Also provided for transfers:

Also provided for transfers:

z user dataset

z TAPE->DISK Castor >Castor

z Castor->Castor

-http://panda.atlascomp.org/?mode=reqsubs0

(M. Titov)

Also accessible from AMI page

DDM replication of group/user datasets

Replication of phys/perf group datasets (already 19 groups) Under deployment

Replication of user datasets: under evaluation Replication of user datasets: under evaluation

Check that it does not affect significantly central replication Competition for transfer slots

Competition for transfer slots

Need to have consolidated dataset (No retrial over problematic files)

Replication to local area

d 2 d

dq2-get,… commands

Based on interactive replication command

Local command (rfcp for Castor) if transfer within site Grid command if source is outside the destination https://twiki.cern.ch/twiki/bin/view/Atlas/DQ2Clients

Read/write access policy

DISK access

read : allowed to all ATLAS users/groups read : allowed to all ATLAS users/groups write : restricted depending on space token

TAPE access

Facts: Wild competition between different activities

z Data are not disentangled when writing on tape (size,path,…) Concurrent access to tapes

z Concurrent access to tapes

->read/write access: reserved for few activities from central operation (reprocessing and data export)

(reprocessing and data export) ->Need to replicate data to DISK when many concurrent access

H t b l d i d

Has to be planned in advance

Already setup for muon calibration on T2s

1beam data: Demonstration

Data Exports to T1s Throughput in MB/s

Effect of concurrent data access

from

centralized transfers

and user ti it

Number of errors

activity

(overload of

disk server)

disk server)

Castor CERN default pool

Actual setup for tape access:

Users and groups can read/write on TAPE through ‘default’ pool Target :

Provide pool with very restricted access (T0 activity + data export): done Decommission tape access through ‘default’ pool (beginning 2009)

Decommission tape access through default pool (beginning 2009)

Steps:

Steps:

Provide specific disk space for groups and users Tape access is read only through ‘default’ pool Tape access is read-only through ‘default’ pool

Users/groups have to replicate selected files from TAPE to DISK:

Tool to be provided

Remove read access through ‘default pool’

R k U / d t t i T1/T2

Remark : Users/groups are encouraged to use storage ressources in T1/T2

CERN disk organisation

Many pools (= disk) dedicated to specific data/activity storage (S. Campana)a y poo s ( d s ) ded cated to spec c data/act ty sto age (S Ca pa a)

t0atlas +t0merge(space token: ATLASDATATAPE)

internal to the T0, not even readable for anybody other than T0 managers

t0 tl d f i iti l i d t l f d t t T1’

t0atlas: used for initial processing and export pool for data to T1’s tomerge:for merging RAW files

atldata (ATLASDATADISK)

100% AOD, 100% performance and physics D1PD

Fraction of real data requested for analysis activity (bulk requests centralised by A. Hoecker)

atlprod (ATLASMCDISK)

100% AOD, 100% performance and physics D1PD

On request: fraction of other simulated data requested for analysis activity (ESD, HITS)

atlcal (not Grid accessible)

Calibration and Alignment data for CAF

atlgrp (ATLASGROUPDISK)

Space for all Physics Groups together (quota per phys/perf group): D2PD One/few persons responsible for managing data on this disk

userdisk (ATLASUSERDISK): For temporary analysis job output

CERN data flow : CERN processing

Tape

afs T1T1T1T1

localgroup disk

t0atlas

t0atlas ^t0merge

Atlprod

(MC) _AOD

CPUsCPUs

CPUsCPU ^AOD

end-user analysis ESD

userdisk ^any

(MC)

CPUsCPUsCPUsT0

AOD ESD

tl CPUs

CPU

y

D2PD D1PD

atldata

atldata CPU

calib

atlgrp CPUs

CPUsCPUs

CAF ^AOD

physics group analysis ESD D2PD

atlcal

CPUsCPUs CPUsCAF

Xpress

CPUsCAF

managers space users space

calibration and alignment

users space

CERN data flow : T1 processing

afs

Reprocessing

localgroup disk

T1T1T1T1

Atlprod MC

userdisk CPUs

CPUsCPUsCPU

any

AOD

end-user analysis ESD

AOD ESD

MC D1PD

tl CPUs

CPU

AOD ESD

y

D2PD D1PD

D1PD

atldata atldata

atlgrp CPUs

CPUsCPUs

CAF ^AOD

physics group analysis ESD D2PD

Central deletion policy

Obsolete or ‘archived’ datasets are defined with coordinators:

Ex: B. Kersevan for simulated samples

Deletion on Grid storages

d t t li t ibl i di t l

dataset replicas are not accessible immediately Files on storage are deleted asap

D l ti Deletion

A Di Girolamo A. Di Girolamo

Disk occupancy per site

Central monitoring from Grid information system (F. Barreiro)

Ex:

/

Available disk space Used disk space

DDM estimation

DDM estimation

Global disk occupancy:

Disk space deployed for space tokens

http://atlddm02.cern.ch/dq2/media/presentations/

Conclusion

M f d i d i

Management of data is more dynamic

Different activities are splitted over storages p g Basic storage monitoring tools are available

Organisation of data access on tape is modified for 2009 data taking

Organisation of data access on tape is modified for 2009 data taking

Will be revisited at the end of 2009