Andy, Booker and Wei had a meeting today about the two options to
transfer data in and out of a xrootd cluster. We all agree that gsiftp
is the way to go.
1) A gsiftp gateway is potentially much simpler to implement comparing
to a SRM. It may still involve some hard work though.
2) Gsiftp interacts better with glite FTS. Neither FTS and SRM are quite
mature.
3) A gsiftp gateway solution will allow all xrootd nodes to remain
within IFZ.
4) We can work about SRM interface later, should it ever become necessary.
The disadvantage of a gateway solution is the potential point of failure
/bottleneck. If the goal is to transfer 1TB/day (or 100Mbit/sec), the
gateway will likely not a bottleneck.
Booker will look at the implementation. I attached a note from Booker
before the meeting.
Wei Yang | [log in to unmask] | 650-926-3338(O)
Stephen J. Gowdy wrote:
> ATLAS SCCS Planning 10Jan2007
> -----------------------------
> 3. HPSS/gsiftp/xrootd
>
> Want to allow xrootd to be used locally (and eventually over the
> WAN) for data access while also fitting in the ATLAS model for data
> import and export.
>
> Booker should talk to AndyH about what is needed to help make this
> happen. There is a pluggable system of deciding what backend store
> you want to use for SRM, might be a way forward. Need to understand
> how easy/hard that is to do. This would be a stop-gap measure and
> not a complete solution.
>
> Another option is that there is a plug-in module for gsiftp to talk
> to the backend storage. It is available for Unix file system, HPSS
> and some other systems but not xrootd. xrootd has a posix interface
> so perhaps we can make it talk to xrootd via the unix file
> system.
>
> There should be a meeting, hopefully tomorrow afternoon, to talk
> about this to see what would work. Will draft options at the
> meeting for circulation.
|