Storage Resource Managers - Cern

rangesatanskingdomSoftware and s/w Development

Dec 2, 2013 (3 years and 8 months ago)

312 views




Stefano Occhetti


S
TORAGE
R
ESOURCE
M
ANAGERS











February,
18
, 2003





i


Table of contents

1 STORAGE RESOURCE M
ANAGERS

................................
.................

1

1.1

I
NTRODUCTION

................................
................................
.................

2

1.2

S
TORAGE
R
ESOURCE
M
ANAGERS AND
D
ATA
G
RID ARCHITECTURE

..

3

1.2.1 Purpose and goals

................................
................................
................................
....

5

1.2.2 Storage Resource Managers

................................
................................
....................

6

1.2.3 Previous work on SRMs

................................
................................
.........................

7

1.2.4 A typical scenario

................................
................................
................................
.....

9

1.2.5 Advantages of the use of an SRM

................................
................................
.......

11

1.2.6 Replica types

................................
................................
................................
...........

13

1.2.7 “
Pinning” and “two
-
phase pinning”

................................
................................
..

14

1.2.8 Why is “pinning” useful?

................................
................................
......................

14

1.2.9 Pinning strategies

................................
................................
................................
...

15

1.2.10 Summing up

................................
................................
................................
..........

16

1.3

SRM

1.0

FUNCTION
AL DESIGN

................................
..........................

18

1.3.1 Basic requirements

................................
................................
................................
.

18

1.3.1.1 SRMs access generality

................................
................................
...............

18

1.3.1.2 SRMs should get files when they are not in local disk

................................

18

1.3.1.3 SRMs should support a “push” mode for writes

................................
..........

18

1.3.1.4 SRM APIs should be uniform for DRMs and HRMs

................................
..

19

1.3.1.5 SRMs should support pinning of files
................................
..........................

19

1.3.2 Fun
ctionality

................................
................................
................................
...........

20

1.3.2.1 Read functionality

................................
................................
........................

20

1.3.2.2 Write functionality

................................
................................
.......................

21

1.4

SRM

1.0

INTERFACE SPECIFICAT
ION

................................
...............

23

1.4.1 Protocols

................................
................................
................................
.................

24

1.4.2 Some guiding principles

................................
................................
........................

24

1.4.3 File Naming and URLs

................................
................................
.........................

25

1.4.4 Asynchronous Operations

................................
................................
....................

26

1.4.5 requestStatus

................................
................................
................................
...........

26

1.4.6 File Status

................................
................................
................................
................

27

1.4.7 SRM Methods

................................
................................
................................
.........

28

1.4.8 SRM Use Cases

................................
................................
................................
......

32

1.4.9 Future Work

................................
................................
................................
...........

33

1.4.10 The SRM as a Web Service

................................
................................
................

33

1.5

SRM

2.0

JOINT FUNCTIONAL DES
IGN

................................
..............

34

1.5.1 Issues and Recommendations

................................
................................
..............

34

1.5.2 Summary of methods and concepts

................................
................................
....

48

1.5.2.1 Summary of methods and their funct
ionality

................................
...............

48

1.5.2.2 Summary of srmGet, srmPut, and srmCopy differences

..............................

51

1.5.2.3 Summary of SRM’s actions based on file
-
status

................................
.........

52

1.5.2.4 Summary of the source and targ
et sites for srmGet, srmPut, srmCopy

.......

52

1.6

SRM

2.0

INTERFACE SPECIFICAT
ION

................................
...............

54

1.6.1 Description of methods

................................
................................
........................

55



ii


2 A BRIEF INTRODUCTI
ON TO WEB SERVICES

.........................

60

2.1

I
NTRODUCTION

................................
................................
................

61

2.1.1 A Simple Example Searching for Information
................................
..................

62

2.1.2 The Next Generation of the Web

................................
................................
.......

63

2.1.3 Web Service Architecture

................................
................................
.....................

63

2.1.3.1 Web Service Roles

................................
................................
.......................

63

2.1.3.2 Web Service Protocol Stack
................................
................................
.........

64

2.1.4 An example: The IBM Web Services Browser

................................
..................

65

2.1.5 Interacting with Web Servic
es

................................
................................
.............

68

2.1.5.1 RPC
-
Oriented Interactions

................................
................................
...........

68

2.1.5.2 Document
-
Oriented interactions

................................
................................
..

68

2.1.5.3 Usage Example

................................
................................
............................

69

2.2

XML

................................
................................
................................
.

71

2.2.1.1 Example

................................
................................
................................
.......

73

2.2.2 XML Namespace

................................
................................
................................
...

73

2.2.3 XML Schema

................................
................................
................................
..........

75

2.2.3.1 Example: a simple type

................................
................................
................

76

2.2.3.2 Example: a complex type

................................
................................
.............

77

2.3

SOAP

................................
................................
...............................

78

2.3.1 SOAP messages

................................
................................
................................
......

79

2.3.1.1 Envelope

................................
................................
................................
......

80

2.3.1.2 Header

................................
................................
................................
..........

80

2.3.1.3 Body
................................
................................
................................
.............

80

2.3.1.4 Fault

................................
................................
................................
.............

80

2.3.2 SOAP encoding

................................
................................
................................
......

81

2.3.3 Using SOAP for RPC
-
Style Web Services

................................
.........................

82

2.3.3.1 Invoking Methods

................................
................................
........................

82

2.3.3.2 Returning

Responses
................................
................................
....................

82

2.4

WSDL

................................
................................
..............................

84

2.4.1 Anatomy of a WSDL Document

................................
................................
........

84

2.4.1.1 definitions

................................
................................
................................
....

85

2.4.1.2 types

................................
................................
................................
.............

85

2.4.1.3 m
essage

................................
................................
................................
........

85

2.4.1.4 portType

................................
................................
................................
.......

85

2.4.1.5 binding

................................
................................
................................
.........

85

2.4.1.6 service

................................
................................
................................
..........

85

2.4.1.7 documentation

................................
................................
..............................

86

2.4.1.8 import

................................
................................
................................
...........

86

2.4.2 Example

................................
................................
................................
...................

86

2.4.2.1 Echo.wsdl

................................
................................
................................
....

87

2.4.2.2 definitions

................................
................................
................................
....

87

2.4.2.3 message

................................
................................
................................
........

88

2.4.2.4 portType

................................
................................
................................
.......

88

2.4.2.5 binding

................................
................................
................................
.........

88

2.4.2.6 service

................................
................................
................................
..........

89

3 POSSIBLE IMPLEMENT
ATIONS FOR THE GRID
SIDE

...........

90

3.1

I
NTRODUCTION

................................
................................
................

91



iii


3.2

P
OSSIBLE SOL
UTIONS

................................
................................
......

92

3.2.1 Solution 1

................................
................................
................................
................

92

3.2.1.1 Description

................................
................................
................................
...

92

3.2.1.2 Configuration

................................
................................
...............................

93

3.2.2 Solution 2

................................
................................
................................
................

93

3.2.2.1 Descr
iption

................................
................................
................................
...

93

3.2.2.2 Configuration

................................
................................
...............................

94

3.2.3 Solution 3

................................
................................
................................
................

95

3.2.3.1 Description

................................
................................
................................
...

95

3.2.3.2 Configuration

................................
................................
...............................

96

3.2.4 So
lution 4

................................
................................
................................
................

97

3.2.4.1 Description

................................
................................
................................
...

97

3.2.4.2 Configuration

................................
................................
...............................

98

3.3

D
EVELOPING
,

TESTING AND DEBUGGIN
G

................................
.......

99

3.4

T
OWARD IMPLEMENTATION

................................
...........................

100

3.4.1 [Solution 1] and
[
Solution 2
]

implementation

................................
.................

102

3.4.1.1 Description

................................
................................
................................
.

102

3.4.1.2 Running and testing

................................
................................
...................

102

3.4.2 [Solution 3] implementation

................................
................................
...............

103

3.4.2.1 Description

................................
................................
................................
.

103

3.4.2.2 Running and testing

................................
................................
...................

107

3.4.3 [Solution 4] implementation

................................
................................
...............

108

3.4.3.1 Description

................................
................................
................................
.

108

3.4.3.2 Running and testing

................................
................................
...................

108

3.5

C
OMPATIBILITY ISSUES

................................
................................
...

109

3.5.1 Solving the problem

................................
................................
............................

110

3.6

C
ONCLUSIONS

................................
................................
................

111

4 POSSIBLE IMPLEMENT
A
TION FOR THE CASTOR
SIDE

......

112

4.1

I
NTRODUCTION

................................
................................
..............

113

4.2

P
ERL IMPLEMENTATION O
F
SRM

DATA STRUCTURES AND
OBJECTS

................................
................................
................................
.............

114

4.3

SRM

SPECIFICS AND
CASTOR

................................
.......................

120

4.3.1 No notion of SRM Request_ID (nor of request status) in CASTOR

.........

120

4.3.2 User and group IDs not specified in SRM specifics

................................
......

122

4.3.3 No methods are specified to get the SRM version

................................
.........

122

4.3.4 Error messages: data type and handling

................................
...........................

122

4.3.5 File size data type

................................
................................
................................
.

123

4.3.6 No notion of SRM file status in CASTOR

................................
......................

123

4.3.7 Impossib
ility to predict the time needed to serve a request

..........................

125

4.3.8 Pinning mechanism

................................
................................
.............................

125

4.3.9 Retention period on disk

................................
................................
....................

126

4.3.10 Tests for embedded APIs

................................
................................
.................

126

4.4

T
WO POSSIBLE IMPLEMEN
TATIONS

................................
................

127



iv


4.5

S
OLUTION
1

................................
................................
....................

128

4.5.1 description

................................
................................
................................
.............

128

4.6

S
OLUTION
2

................................
................................
....................

130

4.6.1 description

................................
................................
................................
.............

130

4.6.2 C data structures and CASTOR’s APIs

................................
............................

131

4.6.2.1 APIs to be used

................................
................................
..........................

131

4.6.2.2 GetProtocols

................................
................................
..............................

132

4.6.2.3 Get

................................
................................
................................
.............

132

4.6
.2.4 Put

................................
................................
................................
..............

132

4.6.2.5 getEstGetTime , getEstPutTime

................................
................................
.

133

4.6.2.6 getFileMetaData

................................
................................
........................

133

4.6.2.7 getRequestStatus

................................
................................
........................

133

4.6.2.8 MkPermanent, Advisor
yDelete
................................
................................
..

133

4.6.2.9 Pin, UnPin, setFileStatus

................................
................................
...........

134

4.6.3 Providing specific functions

................................
................................
...............

134

4.6.4 Gluing C to Perl: the Xs code

................................
................................
............

134

4.6.5 Writi
ng tests

................................
................................
................................
..........

136

4.6.6 Assembling the pieces

................................
................................
.........................

136

4.6.7 Compatibility with CASTOR version 1.5.1.3

................................
..................

138

4.7

A
DDING THE
SSL

LAYER

................................
................................

140

5 STANDARDIZAT
ION AND COMPATIBILIT
Y WITH OTHER
SYSTEMS

................................
................................
..............................

142

5.1

S
TANDARDIZATION AND C
OMPATIBILITY WITH OT
HER SYSTEMS

...

143

5.1.1 Checking types

................................
................................
................................
......

143

5.1.1.1 Boolean

................................
................................
................................
......

143

5.1.1.2 Date and time

................................
................................
.............................

144

5.1.1.3 Long

................................
................................
................................
...........

144

5.1.2 Semantics of URLs

................................
................................
..............................

145

5.1.3 XMLSPY

................................
................................
................................
...............

145

5.1.4 Looking at the WSDL

................................
................................
.........................

152

5.1.5 WSDL, not WSDL

................................
................................
..............................

154

5.1.6 The poor man’s client

................................
................................
.........................

155

5.1.7 Running [
FNAL
]’s client

................................
................................
....................

160

5.2

S
UMMING UP

................................
................................
...................

163

5.2.1 Changi
ng server architecture

................................
................................
..............

163

5.2.1.1 Stand
-
alone HTTP single
-
process daemon:

................................
...............

164

5.2.1.2 Stand
-
alone HTTP multi
-
process daemon with prefork:

...........................

164

5.2.1.3 Stand
-
alone HTTPS
multi
-
process daemon with prefork:

.........................

164

5.2.1.4 CGI:

................................
................................
................................
...........

164

5.2.1.5 mod_perl

................................
................................
................................
....

165

5.2.2 Logical scheme

................................
................................
................................
.....

165

5.2.3 Set up

................................
................................
................................
.....................

165

5.2.3.1 Requirements

................................
................................
.............................

165

5.2.3.2 Installation

................................
................................
................................
.

166

6 THE FUTURE OF SRMS

................................
................................
..

168

6.1

SRM

2.1

F
UNCTIONALITY
A
ND
I
NTERFACE
D
ESIGN

......................

169



v


6.1.1
Details of issues and recommendations

................................
...........................

169

6.1.2 SUMMARY

................................
................................
................................
..........

178

6.1.2.1 Main functionality to be added to the SRM interface

................................

178

6.1.2.2 Other issues

................................
................................
................................

178

6.1.3 minimal common functionality

................................
................................
..........

179

6.2

T
HE
S
TORAGE
R
ESOURCE
M
ANAGER
2.1

I
NTERFACE
S
PECIFICATION

................................
................................
................................
.............

181

6.2.1 Defined Structures

................................
................................
...............................

181

6.2.2 Function specificatio
n

................................
................................
.........................

185

6.2.2.1 Space Management Functions

................................
................................
...

185

6.2.2.2 Directory Functions:

................................
................................
..................

188

6.2.2.3 Data Transfer Functions

................................
................................
.............

1
92

6.2.3 StatusCode specifica
tion

................................
................................
.....................

198

7 APPENDIX A

................................
................................
.....................

203

7.1

R
ESOURCES FOR CHAPTER

3

................................
...........................

204

7.1.1 Sketches of data structures

................................
................................
.................

204

7.1.2 Solution 1 and 2
-

source code

................................
................................
..........

208

7.1.2.1 SRMService.pm

................................
................................
.........................

208

7.1.2.2 SRM.pl

................................
................................
................................
.......

210

7.1.2.3 SRMd.pl

................................
................................
................................
.....

211

7.1.3 Running the Perl implementation

................................
................................
.....

212

7.1.3.1

Screen output 1

................................
................................
..........................

212

7.1.4 XML messages 1

................................
................................
................................
..

214

7.1.4.1 Perl Client’s request

................................
................................
...................

214

7.1.4.2 Perl Server’s reply

................................
................................
.....................

215

7.1.5 Deployment descriptor

................................
................................
.......................

217

7.1.5.1 DeploymentDescriptor.xml (extract)

................................
.........................

217

7.1.6 Testing SRM Service on Tomcat

................................
................................
.......

218

7.1.6.1 testit.cmd

................................
................................
................................
....

218

7.1.7 XML messages 2

................................
................................
................................
..

220

7.1.7.1 Java Client’s request

................................
................................
..................

220

7.1.7.2 Java Server’s reply

................................
................................
.....................

221

7.1.8 Solution 4


Source code

................................
................................
....................

223

7.1.8.1 SRM2d.pl

................................
................................
................................
...

223

7.1.9 A solution for the compatibility problem

................................
........................

224

7.1.9.1 RequestStatus.pm

................................
................................
.......................

224

7.1.9.2 SRM.pl

................................
................................
................................
.......

224

7.1.9.3 SRMd.pl

................................
................................
................................
.....

225

7.1.9.4 SRM
Service.pm

................................
................................
.........................

225

7.1.10 XML messages 3

................................
................................
................................

227

7.1.10.1 Server’s reply (Wrong)

................................
................................
............

227

7.1.10.2 Server’s reply (Correct)

................................
................................
...........

228

7.2

R
ESOURCES FOR CHAPTER

4

................................
...........................

229

7.2.1 Data structures: the natural way

................................
................................
........

229

7.2.1.1 RequestFileStatus.pm


The natural way (sketch)

................................
.....

229

7.2.2 Data structures implementation

................................
................................
........

230

7.2.2.1 GenericClass.pm

................................
................................
........................

230

7.2.2.2 FileMetaData.pm

................................
................................
.......................

232

7.2.2.3 RequestFileStatus.pm

................................
................................
................

232

7.2.3 User and Group IDs

................................
................................
...........................

233



vi


7.2.3.1 A P
erl Routine to change Group and User IDs

................................
..........

233

7.2.4 CASTOR’s commands examples

................................
................................
......

233

7.2.4.1 stagein syntax
................................
................................
.............................

233

7.2.4.2 stagein example

................................
................................
.........................

233

7.2
.4.3 stageqry syntax

................................
................................
..........................

234

7.2.4.4 stageqry example

................................
................................
.......................

234

7.2.4.5 nsls syntax

................................
................................
................................
..

235

7.2.4.6 nsls example
................................
................................
...............................

236

7.2.5 Solution 1


source code

................................
................................
.....................

236

7.2.5.1 A Perl routine to parse stageqry’s output

................................
...................

236

7.2.6 C data structures

................................
................................
................................
...

238

7.2.6.1 struct stgcat_entry

................................
................................
......................

238

7.2.6.2 struct Cns_filestat

................................
................................
......................

239

7.2.7 Tests for future versions

................................
................................
.....................

240

7.2.7.1 Test for stage_out_hsm

................................
................................
..............

240

7.2.8 Bugs

................................
................................
................................
........................

241

7.2.8.1 stcp_output in stage_in_hsm

................................
................................
......

241

7.2.8.2 STAGE_SILENT in stage_in_hsm

................................
............................

241

7.2.9 C specific functions

................................
................................
.............................

242

7.2.9.1 lib.h

................................
................................
................................
............

242

7.2.9.2 lib.c (excerpt)

................................
................................
.............................

243

7.2
.10 External subs (XS glue code)

................................
................................
...........

245

7.2.10.1 CASTOR.xs (excerpt)

................................
................................
..............

245

7.2.11 Testing the extension

................................
................................
........................

248

7.2.11.1 Test.pl

................................
................................
................................
......

248

7.2.12 Embedding

C into Perl

................................
................................
.....................

249

7.2.12.1 CASTOR/lib/Makefile.pl

................................
................................
.........

249

7.2.12.2 CASTOR/Makefile.pl

................................
................................
..............

249

7.2.12.3 MANIFEST

................................
................................
.............................

250

7.3

R
ESOURCES ABOUT CHAPT
ER
5

................................
.......................

251

7.3.1 FNAL sample client

................................
................................
............................

251

7.3.1.1 FileMetaData.java (excerpt)

................................
................................
......

251

7.3.1.2 FileMetaData.java (excerpt)

................................
................................
......

251

7.3.1.3 RequestStatus.java (ex
cerpt)

................................
................................
......

251

7.3.2 Overriding properties accessors

................................
................................
........

252

7.3.2.1 RequestStatus.pm

................................
................................
.......................

252

7.3.2.2 FileMetaData.pm

................................
................................
.......................

253

7.3.3 Encoding date and time

................................
................................
......................

254

7.3.3.1 A Perl routine to get the system date and time, and format them according to
ISO 8601

................................
................................
................................
................

254

7.3.4 Exchanging SOAP messages

................................
................................
.............

255

7.3.4.1 srm
-
get.pl (excerpt of sa
mple client)

................................
.........................

255

7.3.4.2 srmSd.pl (sample server)

................................
................................
...........

256

7.3.4.3 SRMService.pm (excerpt of sample Get method handler)

........................

257

7.3.4.4 Get request

................................
................................
................................
.

258

7.3.4.5 Get response
................................
................................
...............................

259

7.3.5 Mails and discussions

................................
................................
..........................

260

7.3.5.1 Date and time with SOAP::Lite

................................
................................
.

260

7.3.5.2 Wrong namespace using WSDL in SOAP::Lite

................................
........

261

7.3.6 Using WSDL

................................
................................
................................
.........

262

7.3.6.1 managerv1.wsdl

................................
................................
.........................

262

7.3.6.2 Simple_WSDL_client.pl, version 1

................................
...........................

269

7.3.7 Dialog using the WSDL client, version 1

................................
.........................

270

7.3.7.1 Get response using WSDL client, version 1

................................
..............

270

7.3.7.2 Get request using WSDL client, version 1

................................
.................

270



vii


7.3.7.3 Simple_WSDL_client.pl, version 2

................................
...........................

272

7.4

A
TTACHMENTS

................................
................................
...............

273

7.4.1 XML data types

................................
................................
................................
....

273

8 PERSONALITIES

................................
................................
..............

274

8.1

P
ERSONALITIES

................................
................................
..............

275

9 SOFTWARE

................................
................................
........................

278

9.1

S
OFT
WARE

................................
................................
......................

279

9.1.1 XML, SOAP and WSDL

................................
................................
....................

279

9.1.1.1 Information

................................
................................
................................

279

9.1.1.2 Utilities

................................
................................
................................
......

281

9.1.2 Perl specific

................................
................................
................................
...........

281

9.1
.2.1 Set up and documentation

................................
................................
..........

281

9.1.2.2 Modules

................................
................................
................................
.....

283

9.1.2.3 Information

................................
................................
................................

284

9.1.3 Castor specifics

................................
................................
................................
.....

285

9.1.4 SSL and HTTPS related

................................
................................
......................

288

9.1.5 HTTP related

................................
................................
................................
........

288

9.1.5.1 Servers

................................
................................
................................
.......

288

9.1.5.2 Modules for Perl

................................
................................
........................

289

9.1.5.3 Modules for Java

................................
................................
........................

289

9.1.6 Java re
lated

................................
................................
................................
............

290

9.1.7 Python and other script languages

................................
................................
....

291

9.1.8 WWW Specifics

................................
................................
................................
....

291

9.1.8.1 IANA

................................
................................
................................
.........

291

9.1.8.2 IETF

................................
................................
................................
...........

292

9.1.8.3 Internet Society

................................
................................
..........................

292

9.1.8.4 ISO

................................
................................
................................
.............

292

9.1.8.5 W3C

................................
................................
................................
...........

292

9.1.8.6 uddi.org

................................
................................
................................
......

295

9.1.9 Other utilities, help and tutorials

................................
................................
.......

295

9.1.9.1 The SOAP::Lite group

................................
................................
...............

295

9.1.9.2 Utilities

................................
................................
................................
......

296

9.1.10 Unofficials and other references

................................
................................
.....

297

10 REFERENCES

................................
................................
.................

298

10.1

R
EFERENCES

................................
................................
.................

299

10.1.1 Centers, organizations, research groups and experiments

..........................

299

10.1.1.1 SRM official

................................
................................
............................

299

10.1.1.2 Brookhaven National Laboratory (BNL)

................................
.................

299

10.1.1.3 California Institute of Technology (CALTECH)

................................
.....

299

10.1.1.4 European Organization for Nuclear Research (CERN)

...........................

299

10.1.1.5 Fermi National Accelerator Laboratory (FNAL)

................................
.....

301

10.1.1.6 Jefferson Lab (JLAB)

................................
................................
..............

302

10.1.1.7 Lawrence Berkeley National Laboratory (LBNL)

................................
...

302

10.1.1.8 San Diego Supercomputing Center (SDSC)

................................
............

303

10.1.1.9 Standford Linear Accelerator Center (SLAC)

................................
.........

303

10.1.1.10 European DataGrid (EDG)

................................
................................
....

303



viii


10.1.1.11 Oak Ridge National Laboratory (ORNL)

................................
..............

304

10.1.1.12 Deutsches E
lektronen
-
Synchrotron (DESY)
................................
..........

304

10.1.1.13 Wisconsin

................................
................................
..............................

304

10.1.1.14 Other groups and experiments

................................
...............................

304

10.1.2 Articles

................................
................................
................................
.................

305

10.1.3 Books

................................
................................
................................
...................

309

10.1.4 Other references

................................
................................
................................

312

11 INDEXES

................................
................................
..........................

313

11.1

I
NDEX

................................
................................
............................

314

11.2

I
NDEX OF TABLES

................................
................................
..........

315

11.3

I
NDEX OF FIGURES

................................
................................
........

317



ix


Preface

he aim of this paper is to explain in details the work done so far on the
development of Storage Resource Managers (SRMs) at [
CERN
].

Chapter
[
1
]

explains what SRMs are, what t
hey are useful for and what
capabilities they should provide. It
draw
s

the history of SRMs, presenting a

brief

overview
of them,
starting from the beginning,
then reporting in details the
specifics of versions 1.0 and 2.0, which found the bases for the dev
elopment of the
whole work.

Chapter [
2
] offers an introduction of what web services are, focusing, in particular,
on the protocols used by SRMs: [
XML
], [
SOAP
] and [
WSDL
].

C
hapter [
3
] and [
4
] describe in details some different solution
s

to implement SRMs
on
top of the

[
CERN
]

Advanced Storage manager”,
[
CASTOR
],
analyzing the
interf
ace toward the Grid and to the internal system, respectively.

Chapter [
5
] describes a follow up of the work treated in all the previous chapters.
After having implemented SRMs, it is shown the process of making them
compliant to

standard and of testing compatibility toward other systems.

Finally, chapter [
6
] presents some ideas and considerations for a new version of
SRMs, 2.1, depicting the directions toward new generations of SRMs are evolving.

N
OTAT
ION

Text in
Hyperlink style

is an hyperlink to other resources, either local to this
document, like the
cfr

directory
, or to other web sites.

[te
xt in square brackets
]

reminds to references or paragraphs, contributors,
personalities, s
oftware, documentation in this document. These references can be
found in chapters [
7
], [
8
], [
9
], and [
10
].



T


1

C
HAPTER
1

1

1

S
TORAGE
R
ESOURCE
M
ANA
GERS

In which a complete review of all the available literature
about Storage Resource Managers is collected
, until version
2.0
.

This
chapter

is intended to summarize all the work done about Storage
Resource Manager
s,
depicting the situation as it was

at the beginning of
this work
.


This chapter refers to a set of articles, mainly by [
Shoshani
], that were reviewed
and adapted. Details about the source references are reported in the text.

Thanks t
o
[
Baud
] for
correcting and
supervising.

STEFANO OCCHETTI



S T O R A G E R E S O U R C E M A N
A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S

I
N T R O D U C T I O N



2


1.1

Introduction

he aim of this
chapter

is to gather all the available literature about Storage
Resource Managers in a unique, complete document, comprehensive of the
whole work developed so far about

the subject. To fulfill this purpose, all
the available articles, drafts and notes have been collected, reviewed, ordered and,
finally, assembled. Lot of effort is done to follow the chronological evolution of the
topic, in order to explain the reasons th
at brought to the whole development
process, and to make the causes of each functional choice as clear as possible. This
work is not only intended to describe the progress of the work, from the beginning
to the present time, but also to depict an overview
of the current situation about
the subject.

First, Storage Resource Managers are presented through a quite informal definition
and a general idea is provided in order to explain both their utility in scientific
experiments, and the role they accomplish in
grid
-
computing context. A general
functional schema is also sketched, together with a description of some previous
works, as example.

In the second part, the beginning functional design considerations are drawn,
describing the basic requirements SRM should

comply to, and the functionalities
they should provide. These design guidelines lead to the drawing up of the specifics
for Storage Resource Managers version 1.0, described in detail in the third part.

Next, details are given about the “SRM joint function
al design”, as it represents a
result of further discussions about the work in progress after the SRM version 1.0
specification. Here, a list of issues is studied and discussed, in order to provide, for
each of them, a recommendation for newer specifics. A
lso, some concepts not well
specified before, are rigorously defined. A summary of new methods carrying the
ideas just discussed is then provided: these constitute the basis for the Storage
Resource Managers Interface Specification version 2.0, presented i
n the last part of
this work.

T

STEFANO OCCHETTI



S T O R A G E R E S O U R C E M A N
A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S A N D
D
A T A
G
R I D A R C H I T E C T U R E



3


1.2

Storage Resource Managers

and Data
Grid architecture
1

he amount of scientific data generated by simulations or collected from
large scale experiments have r
eached levels that cannot be stored in the
researcher’s workstation or even in his/her local computer center. Such
data are vital to large scientific collaborations dispersed over wide
-
area networks. In
the past, the concept of a Grid infrastructure mainly

emphasized the computational
aspect of supporting large distributed computational tasks, and optimizing the use
of the network by using bandwidth reservation techniques (called “quality of
service”; see [
Foster et al., The Grid…, 1998
]). The Storage Resource Managers
(SRMs) a
re

components that complement this with the support for the storage
management of large distributed datasets. The access to data is becoming the main
bottleneck in such “data intensive” applications because the dat
a cannot be
replicated in all sites. SRMs can be used to dynamically optimize the use of storage
resource to help unclog this bottleneck.

High Energy Physics (HEP) and Climate Modeling and Prediction (CMP) are two
scientific application areas that illustra
te the need to manage storage resources
2
.

In HEP experiments, elementary particles are accelerated to nearly the speed of
light and made to collide. These collisions generate a large number of additional
particles. For each
collision, called an “event”, about 1
-
10 MBs of raw data are
collected
, after filtering
. The rate of these collisions is 1
-
10 per second,
corresponding to 30
-
300 million events per year. Thus, the total amount of raw
data collected in a year amounts to 100
s of terabytes to several petabytes. After the
raw data are collected they undergo a “reconstruction” phase, where each event is
analyzed to determine the particles it produced and to extract its summary
properties (such as the total energy of the event, m
omentum, and number of
particles of each type). The volume of data generated after the reconstruction phase
ranges from a tenth of the raw data to about the same volume. Most of the time
only the reconstructed data are needed for analysis, but the raw data

must still be
available. Another activity that produces similar amounts of data is the simulation
of event data, and their reconstruction. Most of the data reside on tertiary storage
(robotic tape systems), managed by a mass storage system
3
. The next phas
e of the
scientific investigation is the analysis of the data, where 100s


1000s of scientists all
over the globe need to access subsets of the data. The access of data out of tape for
analysis is usually the main bottleneck, and therefore repeated readin
g of the same
files from tape should be avoided. The simulation and reconstruction phases are
obviously compute intensive, but they also produce huge amounts of data that
have to be moved to archives. Data Grids are necessary not only to distribute the
com
putation to various sites, but also to move the data to archives. The output of



1

See [
EDG
].

2

See [
Shoshani et al., SRM for DG…
].

3

S
uch as HPSS; see [
HPSS
].

T

C O N C E P T S

Several branches of the
scientific world, such as
High Energy Physics, or
Climate Modeling and
Prediction,

need new grid
infrastructure to handle
the amount of data they
deal with.

Storage resource
manage
ment plays an
important role to improve
access to the data through
grids

STEFANO OCCHETTI



S T O R A G E R E S O U R C E M A N
A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S A N D
D
A T A
G
R I D A R C H I T E C T U R E



4


computations require temporary disk storage before the data can be moved to tape.
This is where dynamic storage reservation management is needed. Storage
management is even mor
e critical in the analysis phase. While it is possible to
predict the storage needs in the simulation and reconstruction phases, the analysis
phase is more ad
-
hoc. Files have to move to multiple sites where the analysis takes
place based on what the physic
ists want to examine. This ad
-
hoc process requires
storage management to avoid unnecessary duplication of data in storage devices, as
well as reading the same files repeatedly out of tape.

A similar situation exists in CMP. Climate simulation programs gene
rate very large
datasets depending on the resolution of the grid meshes being simulated. The size
of such a simulation is already measured in terabytes. This data generation rate is
expected to increase as more ambitious models are simulated with finer res
olution,
better physics, and a more accurate representation of the land/ocean boundaries.
The data is generated and stored in time order. Given a time point, the simulation
programs generate some 30
-
40 measures, called “variables” (such as temperature or
w
ind velocity) for each spatial point on the mesh. In the analysis phase, scientists
wish to access subsets of the data, consisting of a selection over the time, space,
and variables. This requires reading of many files form tape to extract a relatively
muc
h smaller amount of data. Here again, avoiding repeated reading of files from
tape is crucial. Similarly, the sharing of files by multiple scientists requires storage
management and coordination that is based on the access patterns of the data.
Since scien
tists analyzing the simulation data are in multiple physical sites, grid
-
based storage management is an integral part of the analysis process.

In the past, storage management issues were avoided by pre
-
allocation of space, a
great deal of data replication,

and pre
-
partitioning of the data. For example, HEP
data was pre
-
selected into subsets (referred to as “micro
-
DSTs” or “streams”), and
those were stored in pre
-
selected sites where the scientists interested in this subset
perform the analysis. Because the
data are stored according to the access patterns
anticipated when the experiment was implemented, analysis requiring new access
patterns is made more difficult, since the time to get events other than the subset at
hand was prohibitively long. This mode of

operation is not preferred since
scientists accessing the data can be in multiple remote institutions, and the amount
of data is expected to grow. To improve access to the data in this mode, data grids
are now being developed, and storage resource managem
ent is a needed integral
part of the middleware of data grids. Examples of such grid middleware being
developed are [
Globus
], and [
SRB
]. The proposal to manage storage resources
complements the other services provi
ded by these projects, especially grid security,
efficient file transfer, and replica catalogs
4
. Examples of HEP data systems that
would benefit from this research are [
FNAL
]’s [
Run II
] experiments and their
enabling mi
ddleware [
SAM
]; and, at [
CERN
], all the major experiments related to
[
LHC
]: [
CMS
], [
ALICE
], [
Atlas
], [
LHCb
].and [
TOTEM
].




4

[
OED
] reports, as official spellin
g, “catalogue”, but in this document we will maintain the
spelling “catalog”, as used in the SRMs’ litterature.

STEFANO OCCHETTI



S T O R A G E R E S O U R C E M A N
A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S A N D
D
A T A
G
R I D A R C H I T E C T U R E



5


1.2.1

P
URPOSE AND GOALS

It is necessary to have Storage Resource Managers (SRMs) associated with each
storage resource on the grid in order to achieve the coordinated and optimized
usage of these resources. The goal is to use shared reso
urces on the grid to
minimize data staging from tape systems, as well as to minimize the amount of data
transferred over the network. The main advantages

of developing SRMs as part of
the grid architecture are:



Support for local policy. Each storage resource can be managed
independently of other storage resources. Thus, each site can have its own
policy on which files to keep in its resource and for how long.



Temporary locking. Files re
siding in one storage system can be temporarily
locked before being transferred to another system that needs them. This
provides the flexibility to read frequently accessed files from disk caches on
the grid, rather than reading files repeatedly from the a
rchival tape system.



Advance reservations. SRMs are the components that
dynamically
manage
the storage. Therefore, they can be used to plan the storage system usage
by making advanced reservations.



Dynamic space management. It is essential to have SRMs in
order to
provide the dynamic management of replicas according to the locations
they are needed the most (based on access patterns).



Estimates for planning. SRMs are essential for planning the execution of a
request. They can provide estimates on space avai
lability and the time till a
file will be accessed. These estimates are essential for planning, and for
providing dynamic status information on the progress of multi
-
file
requests.

STEFANO OCCHETTI



S T O R A G E R E S O U R C E M A N
A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S A N D
D
A T A
G
R I D A R C H I T E C T U R E



6


1.2.2

S
TORAGE
R
ESOURCE
M
ANAGERS
5

The term “storage resource” refers to any storage system that can be shared by
multiple clients
6
. Storage Resource Managers (SRMs) are middelware software
modules whose purpose is t
o manage in a dynamic fashion what should reside on
the storage resource at any one time. There are several types of SRMs
7
: Disk
Resource Managers (DRMs), Tape Resource Managers (TRMs), and Hierarchical
Resource Managers (HRMs).

A Disk Resource Manager (DR
M)

manages a single shared disk cache. This disk
cache can be a single disk, a collection of disks, or a RAID system. The assumption
we make here is that the disk cache is made available to the client through some
operat
ing system that provides a file system view of the disk cache, with the usual
capability to create directories, open, read, write, and close files. The function of a
DRM is to manage this cache using some policy that can be set by the
administrator of the
disk cache. The policy may restrict the number of
simultaneous requests by users, or may give preferential access to clients based on
their assigned priority. In addition, a DRM may perform operations to get files
from other SRMs on the grid. This capabili
ty will become clear later
8
.

A Tape Resource Manager (TRM)

is a middleware layer in front of a robotic tape
system. Such tape systems are accessible to a client through fairly sophisticated
Mass Storage Systems (MSSs)
9
.
Such systems usually have some disk cache that is
used to stage files temporarily before transferring them to clients. MSSs typically
provide a client with a file system view and a directory structure, but do not
usually
allow dynamic open, read, write, an
d close to files. Instead they provide some way
to transfer files to the client space, using transfer protocols such as FTP, and
various variants of FTP (e.g. Parallel FTP, called PFTP, in [
HPSS
]). The TRM’s
function is to accept requests
for file transfers from clients, queue such requests in
case the MSS is busy or temporarily down, and apply a policy on the use of MSS
resource. As in the case of a DRM, the policy may restrict the number of
simultaneous requests by users, or may give pref
erential access to clients based on
their assigned priority.

A Hierarchical Storage Manager (HRM)

can be thought, at a simple level, a
s a TRM
that has a staging disk cache for its use. It can use the disk cache fo
r pre
-
staging
files for clients, and for sharing files between clients. This functionality can be very
useful in a data grid, since a request from a client may be for multiple files. Even if
the client can only process one file at a time, the HRM can use i
ts cache to pre
-



5

See [
Shoshani, S
RM why
…, 2001
].

6

The
term “client” here to refer
s

to a user or a software program that run on behalf
of a
user.

7

Further considerations about these different kinds are also explained in [
Issue 1:

and
Recommendation 1:
, page
34
].

8

See [
1.2.4
].

9

Such as HPSS (see [
HPSS
]), Enstore (see [
Enstore
]), etc.

A C R O N Y M S

SRM



Storage Resource
Manager

DRM



Di
sk Resource
Manager

TRM



Tape Resource
Manager

HRM



HSM Resource
Manager

STEFANO OCCHETTI



S T O R A G E R E S O U R C E M A N
A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S A N D
D
A T A
G
R I D A R C H
I T E C T U R E



7


stage the next files. Furthermore, the transfer of large files on a shared wide area
network may be sufficiently slow, that while a file is being transferred, another can
be staged from tape. Because robotic tape systems are mechanical in n
ature, they
have a latency of mounting a tape and seeking to the location of a file. Pre
-
staging
can help eliminate this latency. Another advantage of using a staging disk in an
HRM is that it can be used for file sharing. Given that multiple clients can m
ake a
request for multiple files to an HRM, the HRM can choose to leave a file longer in
cache so that it can be shared with other client based on use history or anticipated
requests. As an example, consider [
CASTOR
], the HSM used at [
CERN
].

1.2.3

P
REVIOUS WORK ON
SRM
S

The general approach is to make Storage Resource Managers (SRMs) as part of the
grid middleware architecture. Each SRM is responsible for the management and
policy enforcement of a Storage Resource (such as a s
hared disk cache, or a shared
robotic tape system). The applications or program invoked by applications make
requests to such SRMs for space reservations, for temporary locking of files, and
for file transfer requests. Consequently, the applications need o
nly express
application
-
specific logical file requests, and the Grid infrastructure can take care of
interacting with the necessary SRMs to get the data the application needs in the
most efficient way. See [
Shoshani et al., SRM for DG…
].

So far SRMs have been experienced managing large datasets for High Energy
Physics applications and Climate simulation applications. In these fields early
versions of SRMs in the [
NGI
] related projects have
been
developed and
deployed
10
.

Belo
w, the work performed so far at the [
LB
N
L
] in the development of
prototypes of an [
HPSS
]
-
HRM, and an early version of a DRM are described.

Specifically, the development work of SRMs is based on experience with a system
desi
gned to support multiple High Energy Physics applications sharing data that is
stored on a tertiary storage system. The system, called STACS (for STorage Access
Coordination System
11
), was developed under the Grand Challenge program and is
now deployed and
used by the STAR project
12
. One of the components developed
under this program was the Storage Manager, which is responsible for queuing
requests and file transfer monitoring from tape to disk (requesting file transfers
from [
HPSS
])
13
. Also
this component, called the HRM, was developed so that it
can be applied to a grid architecture under the [
NGI
] program. It accepts URLs of
the files requested, accessing HPSS to stage the files to its local disk, and calling



10

See [
Shoshani et al., SRM for DG…
].

11

See [
Shoshani et al., New Capabilities…, 2001
], [
Shoshani et al., Experience…,
2001
], [
Shoshani et al., Coordinating…, 2000
], [
Shoshani et al., Access…, 2000
] and
[
Shoshani et al., Storage Access…, 1999
].

12

See [
Shoshani et al., Multidimensional…, 1999
].

13

See [
Shoshani et al., Access…, 2000
].

STEFANO OCCHETTI



S T O R A G E R E S O U R C E M A N
A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S A N D
D
A T A
G
R I D A R C H I T E C T U R E



8


back the reques
ting component when a file is staged. In addition to pre
-
staging and
call back capabilities, HRM provides the client with status capability estimating the
time till staging will be done.

In collaboration [
FNAL
], a common interface to that
system was developed. This
common interface was used by
[
FNAL
]

to link to their
[
SAM
]

data access and
[
dCache
]

([
Enstore
]’s DRM)
network attached storage system. The same interface
was

used for the HRM to interface to [
HPSS
] in Particle Physics Data Grid (see
[
PPDG
]) experiments. Thus, the feasibility of having a single interface to
completely different systems was demonstrated. This is often the case i
n large
collaborations. In addition to its use in [
PPDG
], the same HRM to the Earth
System Grid (see [
ESG
]) was applied, demonstrating its usefulness across multiple
application areas. The HRM was part of the [
ESG
] prototype demonstrated at the
SC 2000 conference (it received the “hottest infrastructure award”).

The [
HPSS
]
-
HRM was enhanced recently to provide a more general grid interface.
The capabilities of the [
HPSS
]
-
HRM w
ere also enhanced for its use in the CMS
HEP project (see [
CMS
]and [
CALTECHCMS
]). Specifically, in the past HRM
relied on a “file catalog” that contained information about the tape ID that [
HPSS
]
assigned to a file as well as the file size. The new enhancements now use a newly
developed [
HPSS
] access module called HSI [
CSM

-

HSI
] to extract this
information dynamically for requested files. This made HRM more gene
ral and
applicable to multiple experiments that use [
HPSS
].

A version of an “on
-
demand” DRM was developed as part of the STACS system
mentioned above. From this experience it was gained insight on the caching
policies required to manage th
e cache. An algorithm was developed for deciding
what should be removed from the disk cache when space is needed, based on the
anticipated needs of the requests made to the system. This algorithm also managed
coordinated access to multiple files that are n
eeded at the same time by the client.
These were referred to as “file bundles”. This algorithm was published in
[
Shoshani et al., Coordinating…, 2000
]. However, this cache management was
not developed as a separate module, but ra
ther it was developed as an integral part
of the job scheduler. Recently, the functionality and the interfaces to an
independent DRM as part of the current [
PPDG
] project
was

designed. An early
version of this DRM has been developed.

Final
ly, in order to demonstrate the generality of SRMs, the HRM was interfaced to
the Storage Resource Broker (see [
SRB
]), so that it can be accessed through an
[
SRB
] client. Developed at the San Diego Supercomputing Center (see

[
SDSC
]),
the [
SRB
] is client
-
server middleware that provides a uniform interface for
connecting to heterogeneous data resources over a network and accessing
replicated data sets. The use of the HRM with [
SRB
] has been demonstrated in a
prototype system. An interface was developed from the [
SRB
] server to the HRM
system to perform file staging requests. When a file is cached by the HRM, the
[
SRB
] server is notified, and it take
s care of transferring the file to its destination
upon the client’s request. Consequently, two new functions were added to [
SRB
], a
“stage” call, and a “status” call. The “stage” call allows the user to request pre
-
STEFANO OCCHETTI



S T O R A G E R E S O U R C E M A N
A G E R S

S
T O R A G E
R
E S O U
R C E
M
A N A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S A N D
D
A T A
G
R I D A R C H I T E C T U R E



9


staging of files from [
HPSS
] tape to the HRM disk, and requesting the file at a later
time. The “status” call is used to return to the [
SRB
] user the information provided
by HRM on the status of the file, such as the time to completion of the stag
ing
request. The combined system was tested with the [
SRB
] client at the University of
Wisconsin, and the [
SRB
]
-
HRM server at [
LB
N
L
]. This experience helped in
generalizing the functionality of the HRM.

1.2.4

A

TYP
ICAL SCENARIO
14

Suppose that a client runs at some site and wishes to analyze data located on
various files on the grid. First, the client must have some way of determining which
files it needs to access. Checking a file catalog, using some index, or even u
sing a
database system can accomplish this step. We will refer to this step as “request
interpretation”. The information used in this step is commonly referred to as
metadata, since the result of this step will be a set of logical file names that need to
b
e accessed. The second step is to find out for each logical file where it physically
resides. Note that a single logical file can be replicated in multiple sites. Files can be
either pre
-
replicated in multiple sites based on expected use by a system
admini
strator or replicated dynamically because they were accessed by clients at
these sites. In a grid environment, the information on the locations of replicated
files exists in a “replica catalog”, a catalog that maps a single logical file name to
multiple ph
ysical files names located in various sites. The physical file name
includes a name of the site, the directory path on that system, and the file name
15
.

In a recent paper (see [
Foster et al., The Anatomy…, 2001
]), the authors describ
e
5 layers needed to support grid applications: fabric, connectivity, resource,
collective, and application layers. The purpose of this layered approach is that
services in each layer can rely on services in layers below it. The fabric layer consists
of co
mputational resources, storage resources, network resources, catalogs, code
repositories, etc. The connectivity layer consists of communication, authentication,
delegation, etc. The resource layer consists of components (and protocols) for
managing various

resources: computing, storage, network, catalog, inquiry, etc. We
see SRMs as belonging to the “resource layer”. The collective layer consists of
services such as replica catalog, replica selection, request planning, and request
execution. Request managem
ent is a generic term that uses any of the services in
that layer, as well as services below it. The application layer consists of application
specific services. The “request interpretation” we mentioned above belongs to this
layer, since finding which log
ical files are needed by an application is specific to that
application.

In many grid environments today, the burden for the above work is being thrust
up

the clients. Therefore, it is now recognized that such tasks can be delegated to



14

See
[
Shoshani et al., SRM Middleware…, 20
02
] for a detailed example showing the
demo during the Supercomputing 2001 conference.

15

Fil
e naming is discussed in further detail in [
1.4.3
].

STEFANO OCCHETTI



S T O R A G E R E S O U R C E M A N
A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S A N D
D
A T A
G
R I D A R C H I T E C T U R E



10


middleware component
s to provide such services. A “request manager” is the term
used to refer to such services. The request manager performs “request planning”
based on some strategy, and then a “request execution” of the plan. This
terminology is used by several grid project
s, notably [
PPDG
], [
GRIPHYN
], and
[
ESG
].

There are three options to consider for request planning: either move the client’s
program to the site that has the file, move the file to the client’s site, or
move both
the program and the data to another site for processing. All three possibilities are
valid, and much of the middleware development addresses this issue. In all these
cases, SRMs play an important role. In the case that the program moves to the si
te
where the file exists, it is necessary to “pin” the file in that site; that is, to request
that the file remains in that site, so that when the program is executed the file is
found in the cache. When the program completes, the file can be “released”. I
n the
case that the file needs to be transferred from a source site to target site (either to
the client’s site, or to another site), it is necessary to “pin” the file in the source site,
to reserve the space in the target site, and maintain this state til
l the transfer to the
target site is complete. Then the “pin” can be released. Here, the SRM at the source
site has the role of managing the “pinning”, and the SRM at the target site has the
role of allocating space (i.e. making space by removing other fil
es if necessary), and
reserving the space till the transfer completes. SRMs need to deal also with various
failures, so that space reservations do not persist forever, and “pins” do not persist
in case that a “release” is not performed. The concept of “pin
ning a file” is central
to SRMs and will be discussed further [
later in this document
].

For the sake of continuing with the scenario, suppose that the choice is made that
all files needed by the client mov
e to the client’s site, site A. Suppose further that
some of the requested files are located on its site’s shared local disk, and the rest are
in other sites. The request manager can then contact its local DRM at site A for all
the files it needs. The DRM,

in turn, will immediately pin all files it has in its cache,
and let the request manager know that these files are in local cache. For the remote
files, the DRM will first allocate space on its disk cache, and then contact remote
SRMs and request pinning
of files. It is not necessary for the DRM to get all the
files at once. To get a file from a remote site the DRM will initiate the contact with
the remote site. For example, suppose the client is at site A, and it needs file X
which is managed by some HRM
at site B. The DRM at site A first allocates space
on its disk cache, and then contact the HRM at site B asking to pin file X. If the
HRM has that file in its disk cache, it will pin it and notify the DRM at site A that
the file is now available for transf
er. If the file is not in the HRM’s disk cache, it will
stage it from tape to its disk cache and then notify the DRM at site A that the file is
now available for transfer.

STEFANO OCCHETTI



S T O R A G E R E S O U R C E M A N
A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S

S
T O R A G E
R
E S O U R C E
M
A N A G E R S A N D
D
A T A
G
R I D A R C H I T E C T U R E



11


Then the DRM can call a file transfer service to move the file