Data Management Expert Panel

RLS

Globus-EDG Replica Location Service

Joint Design in the form of the ‘Giggle’ architecture

Reference Implementation by Globus Team within GT2 Focus on performance and features

Implementation by EDG team in a Web Services Framework Focus on manageability and robustness

No interoperability due to differences in communication protocols and language bindings

EDG implementation chosen to build grid catalog for POOL – January 2003

RLS then (Jan 2003) : EDG & Globus Impl.

Globus RLS

C-based daemon-style technology

C-language binding, java through JNI

MySQL-only backend implementation

Supports LRCs and RLIs.

Uses proprietary Globus Toolkit 2 (GT2) protocols for network communications

N:M logical to physical filename mapping

Schema is not designed to support GUIDs and aliasing

Evolution is very hard due to hardcoded schema and SQL, code change required

WP2 RLS

Java-based technology

Native C, C++, Java, Perl, Python bindings

MySQL and Oracle support, easy to extend to more DBMS

LRC only at the moment. Support planned for RLIs.

Uses Web Service protocols for network communication Small client, no dependencies (on GT2 or others)

N:1:M logical to physical file mapping

Schema has natural support for GUIDs and alias-aliasing

Evolution is easier, no code change necessary. and SQL, SQL is in configuration file.

RLS now (June 2002) : EDG & Globus Impl.

Globus RLS

C-based daemon-style technology

Native C and java bindings

MySQL and Postgres backend implementation

Supports LRCs and RLIs.

Uses proprietary Globus Toolkit 2 (GT2) protocols for network communications

N:M logical to physical filename mapping

Schema is not designed to support GUIDs and aliasing

Evolution is very hard due to hardcoded schema and SQL, code change required

WP2 RLS

Java-based technology

Native C, C++, Java, Perl, Python bindings

MySQL and Oracle support, easy to extend to more DBMS

Supports LRCs and RLIs.

Uses Web Service protocols for network communication Small client, no dependencies (on GT2 or others)

N:1:M logical to physical file mapping

Schema has natural support for GUIDs and alias-aliasing

Evolution is easier, no code change necessary. and SQL, SQL is in configuration file.

RLS : Which one for which user?

Differences between functionality growing smaller Commitment on both sides to implement new functionality in a

interoperable way e.g. bulk upload, new query mechanisms

WP2 / CERN IT-DB not able to support external (non-EDG / LCG) customers

Deployment model still different Major outstanding technical difference, which will be resolved with GT3

Choice probably comes down to what components you already use

Interoperability

Had meeting with Globus after CHEP Agreed to do it now would require lots of extra work – wrapper code to

hide differences in network protocols

GT3, and GGF standards will make this easier

Second meeting scheduled mid July 2003

Interoperability a strategic goal

Aim for full interoperability within the context of OGSA

WP2 Work Schedule

EDG WP2 Work Schedule (1/3)

April 2003 : EDG 2.0 - First release of new data management framework

Services Deployed Replica Location Service (Local Replica Catalog)

Replica Metadata Catalog

Replica Optimisation Service

Replica Manager

Issues: No security integration (authentication + authorization)

Single Local Replica Catalog/ Replica Metadata Catalog per VO

EDG WP2 Work Schedule (2/3)

July 2003 : EDG 2.1 – Focus on missing functionality from EDG 2.0

July 11 – Replica Location Indices LRC pushes updates to registered RLIs

EDG Replica Manager supports multiple LRCs and RLIs

July 22 – Security Integrate VOMS

Deployment of EDG Trust Manager into tomcat – authentication available for all java based services. R-GMA, SE also using this.

Deployment of EDG Authorization Manager to allow services to make course grained authorization decisions

EDG WP2 Work Schedule (3/3)

October 2003

RLS Service Proxy - Hide the interaction with RLI and remote LRCs

Information service

Removes complexity and duplicated code from EDG Replica Manager

POOL

Grid File Access Library

The Grid look like two “Local” Replica Catalog One is LRC for local site

One acts as a proxy for all other LRCs in the grid

Problems in current architecture (1/2)

RLS complexity The RLS will have a large set of LRCs, RLIs running across many sites Currently the client (e.g. EDG Replica Manager or POOL) will need to

manage these interactions

Client failures All failures are managed at the client side if the client itself fails, there is no means of recovery - no state can be

read back

Scalability of transfer If each client is allowed to issue GridFTP requests in a fabric, the

network will be saturated Currently no way to find out whether a given file is already being

replicated

Future Work

Problems in current architecture (2/2)

Outbound connectivity The worker nodes need to have direct outbound connectivity for the

Replica Manager to work.

This is not a given in all fabrics

Failure upon unreachable remote service (RMC) The RMC will be deployed only at one site

This means jobs can fail if network between site and RMC breaks

Possible Solutions (1/2)

RLS complexity Service for RLS which acts as a proxy to RLI and all remote LRCs

Client failures Better client side libraries which handle network retries

Hide/manage the network and service related exceptions

Scalability of transfer Single service at each site could schedule replications, and block

requests for that file until it arrives

Possible Solutions (2/2)

Outbound connectivity SOAP proxy solves problem for all services

Data transfer (gridftp) still a problem

Failure upon unreachable remove service (RMC) WAN-Distributed database

Distributed messaging system to store actions at worker node site and handle retries

Use vendor supplied solutions rather than re-invent

Outstanding Components

Collection management Confined Collections

Limited to PFNs all stored on the same LRC Could be considered as ‘directories’ Allows a user to replicate a set of PFNs from one site to another

Free Collections PFNs which could be stored on any site Are these needed? Use cases not clear

Replica Subscription Service Provides functionality of GDMP from EDG Release 1

Allows background third party replication between SRMs

GFAL

Grid File Access Library

A solution to the “Grid Open” problem

POSIX API for opening a file in the Grid

Hides the complexity of Replica Metadata Catalog

Replica Location Service

Storage Resource Manager

MSS backends

File access Protocols file, rfio, dcap, root,

GFAL Overview

Physics Application

Replica Catalog

Client

SRM Client

LocalFile I/O

rfio I/O

dCap I/O

Grid File Access Library (GFAL)

SRMService

dCapService

rfioService

RCServices

MSSService Local Disk

POSIX I/O

Wide AreaAccess

VFS

root I/O

GFAL example (open)