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

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

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

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

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

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

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

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

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

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

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

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