1. CASTOR: possible evolution into the LHC era
Data and storage mgmt workshop
17/3/2003
Olof Bärring, CERN IT-ADC

2. CASTOR: possible evolution into the LHC era
Outline
CASTOR today
LHC requirements
Some basic requirements
Hardware dependency
Security
“Gridification”
Evolving CASTOR to LHC era
Some design ideas
Conclusions
17/3/2003
CASTOR: possible evolution into the LHC era

3. CASTOR: possible evolution into the LHC era
CASTOR today
Strong points
Solid code base: modular & portable
Scalable performance for most modules, in particular the tape mover (RTCOPY)
Storage resource management optimization strategies built on long experience from production and data challenges
Weak points
Security
Legacy code and dependencies from SHIFT
RFIO and stage have grown from code written more than 10 years ago and have become difficult to maintain
Information overlap between databases
Too many independent user interfaces
Problem tracing difficult due to high independence between modules (e.g. no unique request Id)
17/3/2003
CASTOR: possible evolution into the LHC era

4. LHC requirements Some basic requirements
Scalability
Managed disk storage: ~10PB
Data accumulation: 5-8PB/year
Sustained recording rates: 0.1 – 1GB/s
Performance
Streaming and random access performance limited by hardware
Operation
Performance and exception monitoring
Fault tolerance
Allow for fair-share, request prioritization and storage resource optimization (e.g. load-balancing)
17/3/2003
CASTOR: possible evolution into the LHC era

5. LHC requirements Hardware dependency
Two types of hardware dependency
Support for new hardware devices
A wide range of tape devices and robotics already supported. Relatively easy to add support for new devices.
SCSI and FC attached tape drives supported
Support for new hardware architectures
Server attached storage (current model)
New distributed filesystem technologies
SAN, iSCSI, fiber channel fabrics, ...
Try to keep software design independent of the underlying hardware
17/3/2003
CASTOR: possible evolution into the LHC era

6. LHC requirements Security
Currently model
Trusted hosts with shared or mapped uid/gid (similar to NFS exports)
Physical files owned by users
Would need to support
Authorization to top-level user services based on some standard authentication mechanisms (GSI, Kerberos, ...)
Internal service communication
Host key authentication or trusted networks?
Physical file ownership
Logical files are owned by real owner
Physical files are owned by root or some generic user
17/3/2003
CASTOR: possible evolution into the LHC era

7. LHC requirements “Gridification”
Grid services on top of CASTOR
Data transfer/access: GridFTP
Storage resource management: SRM (Storage Resource Management) interface
Space reservations
File “pinning”
Issue
Logical file ownership for grid users without local logins
17/3/2003
CASTOR: possible evolution into the LHC era

8. Evolving CASTOR to LHC era Some design ideas (1)
Service hierarchy
Authorize
Select pool
Super stager
Select server
Disk pool mgr
Disk pool mgr
Disk pool mgr
Select disk
Local request broker
Disk server
Local request broker
Disk server
Local request broker
Disk server
Local request broker
Disk server
Local request broker
Distributed FS
17/3/2003
CASTOR: possible evolution into the LHC era

9. Evolving CASTOR to LHC era Some design ideas (2)
Disk pool defines the basic storage characteristics, e.g.
User group (or virtual organization)
Some tape migration attributes
Access type policies (streaming, random, ...)
Fair-share policies
Disk servers
Sea of shared resource just like tape servers are nowadays
Request pull rather than push
Responsible for applying the policies associated with the disk pools
Distributed files systems: DMAPI?
17/3/2003
CASTOR: possible evolution into the LHC era

10. Evolving CASTOR to LHC era Some design ideas (3)
Disk server
Monitoring data
CPU load
Disk activity
Tape queues
Group accounting
...
Local Request Broker
Request scheduler
Migrator
Local
LFN – PFN
mapping
Recaller
Scheduling policy plug-in
Scheduling policy plug-in
Scheduling policy plug-in
DiskToDisk GC
LFN – Logical File Name (/castor/...)
PFN – Physical File Name
rfiod
LFN
req.
17/3/2003
CASTOR: possible evolution into the LHC era

11. Evolving CASTOR to LHC era Some design ideas (4)
Other possible improvements
Support data access type hints in RFIO
Sequential access
Streaming sequential (e.g. tape mover)
Random access
“Predictable” random access (ROOT I/O?)
Stream prioritization in RFIO
CDR streams
Tape streams
Normal user streams
Tape mover (RTCOPY) extensions
Multiple clients for same tape mount
Dynamic backfill of incoming requests for mounted tapes
17/3/2003
CASTOR: possible evolution into the LHC era

12. CASTOR: possible evolution into the LHC era
Conclusions
CASTOR has proven good performance and scalability in production and recent data challenges. In particular the tape mover (RTCOPY) has proven to scale well with the hardware.
Yet some parts of CASTOR, in particular stage/RFIO, need to be modified/rewritten to better meet LHC requirements.
Current hardware architecture and the final choice for LHC may have an influence on the software design. High software modularity can partly isolate us from this problem.
17/3/2003
CASTOR: possible evolution into the LHC era