SRM SRB interoperability

Storage Interoperability

GridPP runs various SRM implementations, and NGS mainly runs the Storage Resource Broker from SDSC.

SRM and SRB Interoperability

SRM and SRB are traditionally the two separate "storage islands" in Grid storage, each providing interoperability within its own island (hopefully), but not between the islands.

Well, not any more - now we can transfer data between SRM and SRBs using advanced gLite data management tools. For example, this enables us to publish an SRB as a Storage Element to a gLite-based Grid. With some help from STFC's SRB folks (specifically, Roger Downing at DL), we have managed to transfer files between the Tier1 dCache SRM and a test SRB instance using FTS.

This work was kindly demonstrated by Alex Sim for us at SC2007.

The magic is to pretend that SRB is a Classic SE and equip it with a GridFTP server.

GridFTP

The simplest way to transfer files is to just use GridFTP directly between the two (still assuming the SRB is equipped with a GridFTP server), but then you need to know in advance which pool node with a GridFTP door you need to write the file to. There is no need as such (at least with dCache) to "create" the file via SRM. If you try this, note you have to switch off "data channel authentication" (the -nodcau switch for globus-url-copy) or it won't work.

FTS

Since FTS still supports Classic SEs, and does not directly depend on the information system, it can transfer files between the two.

SRB

Roger downing 11:13, 17 Dec 2007 (GMT)

Apart from the GridFTP server, you also need the right account mappings set up in the SRB. The GridFTP server sees your DN, whereas SRB wants to see a username. When passed a DN string, the SRB server must map it to an SRB username so that access control lists can be consulted etc. There is a many to one mapping between DNs and usernames, such that one username may have multiple DNs referring to it, but a DN may only refer to a single username. DNs and usernames must be unique throughout the SRB system. The grid-mapfile for the GridFTP server needs to be modified slightly to provide the necessary information for SRB login. The SRB domain for that user must be added, for example:

"/C=UK/O=eScience/OU=CLRC/L=DL/CN=roger downing" roger@tahds

The quotes were found to be necessary or the GridFTP server choked on the grid-mapfile.

SRB uses the concept of resources to signify an area of storage such as a directory in an ext3 filesystem, an FTP server, a GridFTP server, or a tape robot. When a client writes data to SRB, a target resource must be specified in some fashion (either implicit in the client environment or explicit in the write request). Since in this scenario the GridFTP server is acting as an SRB client, it must have a resource specified. Per instance of the server only one resource may be configured (which is done via the GLOBUS_SRB_DEFAULT_RESOURCE environment variable). This means that a given server may only be used to write to one resource. Reading from SRB is unrestricted however as (access control notwithstanding) all resources are available to the clients for read access.

The enabling of GridFTP access to SRB was relatively simple. The source code for the SRB DSI was downloaded from the SRB webpage and the brief but accurate instructions were followed to compile the code. Once it was found that a given server could only support a single resource for writing it became clear that scripts would be required to setup the correct environment for each invocation of the server. These scripts all follow the same pattern:

export GLOBUS_LOCATION=/usr/local/globus-4.0.5
export GLOBUS_SRB_HOSTNAME=kisumu.esc.rl.ac.uk:7670
export GLOBUS_SRB_DN="/C=UK/O=eScience/OU=CLRC/L=DL/CN=kisumu.esc.rl.ac.uk/emailAddress=r.downing@dl.ac.uk"
export GLOBUS_SRB_DEFAULT_RESOURCE=tahds-vault
export GRIDMAP=/etc/grid-security/grid-mapfile-tahds

$GLOBUS_LOCATION/sbin/globus-gridftp-server -p 2811 -dsi srb -auth-level 4

Here the port has been defined as 2811, the standard GridFTP port, since it was discovered that some of the other tools being tested made the assumption that that was the port to use.

lcg-utils

As the next, higher level, step we set up a Classic SE GRIS by adding an information system to the GridFTP server, to see if it can be used with lcg-utils and GFAL. It worked! We got lcg-cr, lcg-cp, and lcg-del to work; they could access files, transfer files to/from SRB, and delete files.

These tools also use the catalogues where the file is registered under the gsiftp "SURL".