[gin-data] Re: Start implementing the plan

Reagan Moore moore at sdsc.edu
Sat Feb 25 12:00:32 CST 2006


Charlie:
The ability for SRB servers to access data in another independent 
data grid is supported through several mechanisms:

- peer-to-peer SRB servers.  All SRB servers can forward information 
to the appropriate server for resolution.  From a SRB client in 
Europe, a user can access any SRB collection by knowing the 
collection identity (port number and host).  They can then read 
public data or data for which they have read permission.  The SRB can 
use GSI authentication, but not all SRB collections use the GSI 
authentication scheme.  The SRB has been ported onto GSI versions 2, 
3, 4, and Java.

- GridFTP access.  If a grid has installed the GridFTP interface to 
the SRB, the access can be done through GridFTP, given the SRB URL 
pointing to the file in a SRB collection.  This assumes GSI version 4.

- True federation.  The SRB uses the "Shibboleth authentication 
model" for interoperability between data grids.  Each user is 
identified by their home data grid.  When a user accesses another 
data grid, the second data grid checks that it has already 
established a trust relationship with the first data grid, and sends 
a request to the first data grid to authenticate the user.  The 
access controls are applied by the second data grid.

The SRB provides mechanisms to cross-register name spaces between 
data grids.  Thus users in the first data grid can have their 
identity registered into the second data grid.  Similarly logical 
resource names can be cross-registered.  Synchronization routines can 
replicate both data and metadata from the first data grid into the 
second data grid.

Depending upon which name spaces are shared, it is possible to create 
hierarchical relationships between the data grids.  Examples are:
-  NOAO, created 5 data grids that pull data from a remote data grid 
into the local data grid.  One of the data grids is used as a 
preservation environment.  Data is pulled from Chile to the US.
- WUNgrid, federated 5 data grids in a peer-to-peer federation.  Each 
data grid sees the files in the other data grids.
- BaBar, uses two data grids to move data from SLAC to Lyon, France
- KEK Belle project, uses 7 data grids to distribute high-energy 
physics data around the world
- NARA persistent archive, uses 3 data grids to build a preservation 
environment.

Reagan




>Hi Reagan-
>
>This is a good conversation to have, thanks for taking the 
>initiative.  At a very basic level, what we want is for a user of 
>Grid X to be able to get data from an SRB infrastructure that is 
>part of Grid Y.  For example, a DEISA user would be able to use an 
>SRB client on a DEISA machine in Europe (I've  cc'd Stefan Heinzel 
>who is one of the DEISA technical leaders) to find and access data 
>in a TeraGrid SRB server.  That user might wish to move that data 
>using GridFTP as well.
>
>I'm sure this has implications for authentication and authorization, 
>which is the focus Dane (also cc'd) is leading.
>
>CeC
>
>On Feb 24, 2006, at 12:53 PM, Reagan Moore wrote:
>
>>Charlie:
>>I would like to track what is needed for the "SRB Island".  There 
>>are multiple SRB data grids running on the Teragrid at the moment, 
>>including installations at SDSC, Purdue, ORNL, NCSA.
>>
>>Is the "SRB Island" a test environment or a production system?
>>
>>What interoperability components should be included in the "SRB 
>>Island"?  Possibilities include:
>>- SRB MCAT catalog
>>- SRB servers for storage access
>>- SRB data grid federation (linking two independent data grids)
>>- GSI authentication (which version -  2, 3, 4, Java?)
>>- GridFTP
>>- SRM interface (we support SRM version 1 drivers to talk to storage)
>>- GMCat interface to Replica Location Servers (Simon Metson - UK)
>>- DSpace and Fedora digital libraries
>>
>>Reagan
>>
>>
>>>TeraGrid will help to build  the SRB island.
>>>
>>>We also want to work with DEISA (and others) on getting striped 
>>>GridFTP working reliably and with reasonable performance between 
>>>sites on our Grids.
>>>
>>>To make this happen Dane or I will make sure to assign the right 
>>>technical person, being just paper pushers ourselves!
>>>
>>>CeC
>>>
>>>On Feb 24, 2006, at 11:05 AM, Erwin Laure wrote:
>>>
>>>>Dear GINers,
>>>>
>>>>As you've pledged to contribute effort to GIN in last week's GGF 
>>>>meeting, I'd like to come back to you to start implementing the 
>>>>data management plan.
>>>>
>>>>(I'm not sure I covered really all the projects that pledged 
>>>>effort and I'm also missing the email addresses from H. Jin 
>>>>(China Grid), R. Davis (APAC), and R. Lee (Korean National Grid) 
>>>>- could people having their email addresses please forward this?)
>>>>
>>>>An updated version of the original data mgmt document was already 
>>>>distributed and can be found in gridforge. I suggest we keep 
>>>>expanding that as the working document.
>>>>
>>>>As a first action we need to identify the Grid infrastructures 
>>>>that will collaborate in building the two island (SRM-island and 
>>>>SRB-island). Could you please let me know by the end of next week 
>>>>to which island your Grid would contribute? OSG and EGEE will be 
>>>>part of the SRM island but I'd need a firm answer from the other 
>>>>Grids on where they will be.
>>>>
>>>>From the Grids that take part in the SRB island I'd like to have 
>>>>a person responsible driving the intra-island interoperability 
>>>>work.
>>>>
>>>>For the Grids in the SRM island the next step will be the 
>>>>identification of the resources, the publishing of the SRM 
>>>>versions, implementations, and endpoints, as well as the 
>>>>publishing of the gridFTP versions, implementations, and 
>>>>endpoints. These sites will also have to put the security 
>>>>infrastructure in place, as discussed in the auth group.
>>>>
>>>>Please also make your people subscribe to the gin-data at ggf.org mailinglist!
>>>>
>>>>If we want to show first results by GGF17 this work really has to 
>>>>start now!
>>>>
>>>>Best regards,
>>>>
>>>>-- Erwin





More information about the gin-data mailing list