Speaker
Conclusions
The FTS team is evaluating a redesign of the service to meet the future needs of the infrastructure.
Impact
A generic file transfer service would support the new data movement patterns now seen on the grid by offering asynchronous transfers with scheduling and contention management to a far wider spectrum of use cases than is presently the case. This would contribute to the goal of more efficient use of bandwidth and storage on the grid at a time when demand for both is expected to increase in the near future.
Description of the work
The main change affecting FTS architecture is that experiments want to leave the channel model that is in the core of FTS. The channel model was built for Tier0-Tier1 sites, its point-to-point approach is not scalable in Tier2 region. In addition, FTS configuration is a complex task. T2 sites use LCG Util that has similar functionalities in terms of transferring data but it lacks scheduling and resource management capabilities. To address those problems, we propose redesigning FTS based on standard building blocks: the two main points are using messaging (to address channel-less operations) and supporting database backends other than Oracle (for T2 configurations). We also plan supporting more transfer protocols in addition to grifdtp: HTTP, potentially peer-to-peer systems, etc. FTS command line interface and LCG Util would also be merged to provide a consistent, selectable sync/async ways of data transfer: transfer scheduling and FTS services will be available for standard users as well. In order to provide better resource management, we propose that individual storage elements publish information about their internal load and network status as well.
Overview
We propose a new gLite file transfer service that implements the latest requirements of experiments and serves the needs of smaller (Tier2) sites as well.
