SE architecture

1
SE architecture

• WP5 Storage Elephant
• Tim EVES, Jens G JENSEN, Owen SYNGE, Regina TAM

2
Talk breakdown

• What is an Storage Element?
• SE in Test bed 1
• SE in release 2
• What we have done

3
What is a Storage Element?

• A consistent interface to MSS.
• MSS
• Castor
• HPSS
• RAID arrays
• SRM
• DMF
• Enstore
• Interfaces
• GridFTP
• GridRFIO
• /grid
• OGSA
• Summary A framework for supporting grid aware
  protocols to data storage.

4
Clients

• Resource Broker Job Submission Service (WP1)
• Replica Manager (WP2)
• replicates files between Storage Elements
• Information services (WP3)
• User Applications
• running on a Computing Element
• command line utilities

5
Interaction with other Work Packages
6
Mass Storage Systems

• All MSS are being used
• Features differ greatly between MSS
• Most support directories (Hierarchical Storage
  Management)
• Most support UID/GID some only UID
• Most dont support certificate based system
• Most dont support Access Control Lists

7
Grid Clients
Other clients
SE
Mass Storage Systems
8
An SE in Testbed1

• A disk server
• running GDMP v2.0 and now v3.0 (Not yet examined
  by WP5)
• Stages files to MSS - Castor/Leon
• running information providers
• running data servers (RFIO, GridFTP)
• optionally NFS mount user data on local CE
• GridRFIO being evaluated.
• Mini Castor being installed for experimental
  access at CERN

9
Release 2 SE

• Will happen in September.
• Will provide a constant interface to MSS
• Large amount of Code still to be written.

10
SE Design

• Abstraction of interfaces
• Supporting changing Grid interfaces
• Abstraction of MSS
• Supporting all major MSS with single system
• Scaleable cluster system
• SOAP based system.

11
SE Requirements

• Accessing Data
• Authorization
• Grid Access control lists
• Authentication
• Resource management
• Meta data catalogue
• Quota Management

12
SE Design Philosophy

• Simplicity
• Multi process model
• Minimum IPC mechanisms
• Flexibility
• XML API model based on SOAP
• Modules can be chained together
• Maintainable
• Self auditing
• Discrete modules

13
Data Transfer

• Uniform method for all interfaces providing a
  series of atomic operations
• Traunch based data transfer
• Data is preceded by XML describing the datas
  destination.
• Collection of connections
• Pipes/Sockets
• Buffered/Queued
• Predictable overload behavior
• Clustering simplified
• File based requests
• Flexible (XML/XSL format)
• Maintainable (No complex API)

14
Data Flow Diagram for SE
Interface Layer
The Core and the Bottom Layer
2
Interface
Queue Manager
Network
3
1
Request Manager
Pipe Manager
4
Disk
Handler
MSM
Pipe Store
Named Pipe
6
Named Pipe
Tape
5
Named Pipe
8
7
Named Pipe
15
Project Divisions

• Made up of 2 parts
• Interface to Common Data Format (XML)
• Tim Eves and Jens Jensen.
• Interface to MSS
• Owen Synge and Regina Tam
• Advantages
• Allows new Interfaces to be added easily
• Keeps the interface implementation out of the MSS
• XML used to link these sections

16
Interfaces

• Receive Network connections
• Support protocols
• Sometimes authenticate the user
• Translate requests to XML format
• Make each request atomic.

17
Interfaces implementation

• All interfaces will connect using a single
  protocol in XML to the backend
• Currently working on GridFTP Server
• WuFTP based server
• lex yacc system
• difficult to maintain/modify
• Intend to use /grid
• coda implementation initiated by Andrew McNabb
• allows us to intercept file requests to call the
  core
• incompatible with RedHat 6.2

18
(No Transcript)
19
Interface Request to SE backend

• Present on all interface calls to core.
• Expresses Request in atomic form.
• Placed in queue to be dealt with by the core.
• Common format to all interfaces.
• Contains authentication information

20
Data Flow Diagram for SE (2)
Interface Layer
The Core and the Bottom Layer
2
Interface
Queue Manager
Network
3
1
Request Manager
Pipe Manager
4
Disk
Handler
MSM
Pipe Store
Named Pipe
6
Named Pipe
Tape
5
Named Pipe
8
7
Named Pipe
21
Example Interface to SE backend
ltxml version1.0gt ltrequest_file version1.0gt
ltinterface nameGridFTPgt ltusergtOGrid,
OUKHEP, OUhepgrid.clrc.ac.uk, CNOwen
Syngelt/usergt lt/interfacegt ltrequestgt
ltreadgt ltfilegt ltnamegt/alice/looking_g
lass/red_queenlt/namegt lttranche
offset100000 length400000/gt lt/filegt
ltpipegt ltlocationgt/var/opt/edg/pipestor
e/1234lt/locationgt ltdirectiongtoutboundlt/dir
ectiongt lt/pipegt lt/readgt
lt/requestgt lt/request_filegt
The tags ltrequest_file/gt and ltmetadata/gt have
not been expanded for the sake of brevity. These
additional XML subsections will provide space for
all verification that the correct request is
being handled by the SE internals and that file
metadata can be found also.
22
Internal SE file information

• Based on SOAP
• Easy to support OGSA when Globus release
• Similar to interface to SE file format
• Allows scripting and tracing of systems Behaviour

23
Data Flow Diagram for SE (3 4)
Interface Layer
The Core and the Bottom Layer
2
Interface
Queue Manager
Network
3
1
Request Manager
Pipe Manager
4
Disk
Handler
MSM
Pipe Store
Named Pipe
6
Named Pipe
Tape
5
Named Pipe
8
7
Named Pipe
24
Example internal SE file format
lt?xml version"1.0 ltse version"1"gt
ltrequest_filegt lthandlersgt
lthandlergt ltnamegtedg_se_handler_read_disk
lt/namegt ltreadgt ltfile
scheamer_version"1"gt
ltnamegt/alice/looking_glass/red_queenlt/namegt
lttranche offset"100000"
length"400000"/gt lt/filegt
ltpipegt ltlocationgt/var/opt/edg/pipestor
e/1234lt/locationgt ltdirectiongtoutboundlt
/directiongt lt/pipegt lt/readgt
lt/handlergt lt/handlersgt ltdatagt
ltrequest_file_abstract version"1.0"gt
ltinterface name"GridFTP"gt ltusergtOGrid,
OUKHEP, OUhepgrid.clrc.ac.uk, CNOwen
Syngelt/usergt lt/interfacegt ltrequestgt
ltreadgt ltfilegt
ltnamegt/alice/looking_glass/red_queenlt/namegt
lttranche offset"100000" length"400000"/gt
lt/filegt ltpipegt
ltlocationgt/var/opt/edg/pipestore/1234lt/locationgt
ltdirectiongtoutboundlt/directiongt
lt/pipegt lt/readgt lt/requestgt
lt/request_file_abstractgt lt/datagt ltaudits/gt
lt/request_filegt lt/segt
25
Data Transfer Header

• Present on all out bound data
• Control request contained internally

26
Data Flow Diagram for SE (7)
Interface Layer
The Core and the Bottom Layer
2
Interface
Queue Manager
Network
3
1
Request Manager
Pipe Manager
4
Disk
Handler
MSM
Pipe Store
Named Pipe
6
Named Pipe
Tape
5
Named Pipe
8
7
Named Pipe
27
Example Data Transfer Header
ltxml version1.0gt ltdata_transfer
version1.0gt lthandler_request_file/gt
ltmetadata/gt ltfilegt ltnamegtlocalhost//grid/al
ice/lx123.binlt/namegt lttranche offset100000
length400000/gt lt/filegt lt/data_transfergt
The tags ltrequest_file/gt and ltmetadata/gt have
not been expanded for the sake of brevity. These
additional XML subsections will provide space for
all verification that the correct request is
being handled by the SE internals and that file
metadata can be found also.
28
Data Flow Diagram for SE
Interface Layer
The Core and the Bottom Layer
2
Interface
Queue Manager
Network
3
1
Request Manager
Pipe Manager
4
Disk
Handler
MSM
Pipe Store
Named Pipe
6
Named Pipe
Tape
5
Named Pipe
8
7
Named Pipe