EDG WP5

WP5 Developments: 

WP5 Developments John Gordon, Jens Jensen GridPP Middleware Workshop February 2003

Summary: 

Summary Overview External Interfaces Internal Structure Details of specific issues Roadmap John Gordon John Gordon John Gordon Jens Jensen John Gordon

The StorageElement: 

The StorageElement The StorageElement provides a grid-aware interface to Mass Storage Systems)MSS) For this first release the three interfaces to the outside world are: Data, gridftp will be used to transfer files over the WAN and the files will optionally be available to local nodes by NFS. Information, Existing MDS information providers will be extended to provide the extra information in the GLUE storage schema. Control, functions such as reservation, pinning, deletion, and transfer time estimation. TB2.0 will see the first production release of the SE control system And a native gridftp service on Castor at CERN We demonstrated data transfer between MSS at RAL and CERN over the wide area network at the recent EU review of EDG.

Who uses it, and how: 

Who uses it, and how User can access files in SE directly RLS points to files in SE Fully distributed RLS can have a catalogue/SE edg-replica-manager pushs/pulls files to/from SE Optor can decide to create new replica Reserve/copy/commit Pin/copy/release

Data Flow in Demo Operations: 

demoUI Disk Disk HSM Data HSM Data Flow in Demo Operations

Collaborations: 

Collaborations WP2 getSECosts for use by Optor edg-trust-manager – secure web service StorageElement java class – used by ERM SRM API for remote access to MSS Collaboration of most big HEP labs (LBNL, FNAL, JLAB, CERN, RAL) Common WSDL => interworking at SOAP level Not really a grid project (predates PPDG but adding grid)

SE functionality: 

SE functionality List internal catalogue Make directory Reserve for writing Release reservation Commit write Pin for reading Release pin Set/get ACL

External Interfaces: 

External Interfaces Command Line C API Java API As web service

Slide9: 

Client App API SE HTTP library SSL socket library Apache RMANMAN SE core SE Java Client The design of the SE follows a layered model with a central core handling all paths between client and MSS. Core is flexible and extensible making it easy to support new protocols, features and MSS Java Client API C Client

Slide10: 

SE Web Service Interface Web Service Implementation Java2WSDL WSDL WSDL2Java Client Stubs Java Client API Server Stubs Apache AXIS Development Process Request / Response Flow

SE Java Client API: 

SE Java Client API We provide Java Client API to access SE Web Service Hides client applications from complexities of SOAP and dynamic method invocation in XML-RPC AXIS WSDL2Java tool makes this easy WSDL2Java generates Server-side and Client-side stubs to access Web Service Client-side stubs are tweaked to provide further abstraction  SE Java Client API

Internals of SE: 

Internals of SE

XML for file metadata: 

XML for file metadata + Easy to create + Extensible – Hard to find tools in C or C++ to manipulate XML  we mostly store static data in XML We use expat and libxml for parsing, libxml for manipulation and Sablotron for XSL processing Static file metadata Creator, creation time VO Size, checksum Dynamic file metadata Access latency Access & modification time Physical location Pins

XML for command processing: 

XML for command processing The request contains the sequence of names of handlers As each handler processes the request, it calls a library that moves the name to an audit section The library allows easy access to global data Handlers may also have handler-specific data in the XML Storing the XML output from each handler as the request gets processed makes it easy to debug the SE sequence audit XML

Security: client/server: 

Security: client/server “Home-made” protocol (instead of SOAP) Server: Apache+modssl currently using a GSI patch (to accept proxies) but the patch needs to be updated/rewritten because it assumes root CA has a version 1 certificate Client uses simple SSL socket library No Globus libraries Web service (SOAP) Server: Tomcat Uses WP2’s TrustManager connector Client: uses standard Java HTTPS libraries

Security: authorisation: 

Security: authorisation Access Control Lists: We use Andrew McNab’s GACL library An ACL per file, but ACLs can be shared between files Some limitations at the moment – we can’t change ACLs via the API yet Question: what is the default ACL for a VO? Future: VOMS Membership server provides credentials with groups and roles Once LCAS and LCMAPS libraries are mature, we can start customising them (probably need to write a plugin) Compatible with CAS?

Reservation: 

Reservation SE can check amount of space available, but can provide no guarantees Accessing files on disk via NFS or files on tape directly in the MSS makes it impossible to guarantee SRM calls this “best effort, volatile” In the future we will support SRM v2 reservations: Some or all of: Volatile, Durable, Permanent Semantics is non-trivial Provides interoperability Will be much easier if/when all file access goes through the SE

Other (mostly future) issues: 

Other (mostly future) issues Need to maintain several physical copies of the file internally In the simplest case, one on disk (cached), one on tape In the future, we can mirror file to several servers (“distributed” SE) for load balancing Disk cache management Easy to build a simple one, but cache management is non-trivial Optimisations At the moment everything is stored in files to provide maximal robustness – switch to Berkeley DB? Have persistent handlers rather than start one for each request?

Roadmap: 

Roadmap What we have done TB2.0 v1.0 Reserve new files Pin existing files Commit new files to MSS Cache existing MSS files to disk CLI/Java API/(C API) What we will do very soon V1.1 Registration of existing MSS files GACL interface StorageElement java class for WP2 NFS access Direct TURL to MSS Local Posix i/o via RFIO RGMA showSignOfLife

Roadmap: 

Roadmap What comes next? v2.0 (end of May?) Rewrite, of course. (request queuing, persistent handlers) Use SRM v2.1 WSDL for bits we have implemented SRM v1 WSDL??? Act on VOMS proxies http data access … other protocols? V3.0 (end of August?) Fuller SRM functionality Posix I/O