XRootD Refresher History, Concepts & Architecture
Description: XRootD Refresher History, Concepts Architecture XRootD Workshop Tokyo November 9, 2016 Andrew Hanushevsky, SLAC http:xrootd.org Basic XRootD Concept A system for scalable cluster data access Not a file system Not just for file systems
Related Topics
Download Presentation
"XRootD Refresher History, Concepts & Architecture" is the property of its rightful owner. Permission is granted to download and print the materials on this website for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Presentation Transcript
slide1. XRootD Refresher History, Concepts & Architecture XRootD Workshop
Tokyo
November 9, 2016
Andrew Hanushevsky, SLAC
http://xrootd.org<br>
slide2. Basic XRootD Concept A system for scalable cluster data access
Not a file system
Not just for file systems
If you can write a plug-in you can cluster it<br>
slide3. Brief History of XRootD 1997 – Objectivity, Inc. collaboration
Design & Development to scale Objectivity/DB
First attempt to use commercial DB for Physics data
Successful but problematical
2001 – BaBar decides to use root framework vs Objectivity
Collaboration with INFN, Padova & SLAC created
Design & develop high performance data access system
Work based on what we learned with Objectivity
2003 – First deployment of XRootD system at SLAC
2015 – Wide deployment with several implementations
ALICE, ATLAS, CMS, EXO, Fermi, LSST; among others
Protocol available in dCache, DPM, and EOS<br>
slide4. Only One Shot To Succeed! A lot of negativity floating around
Objectivity deemed a failure why not this?
So, we focused on the specific problem
The High Energy Physics analysis regime
Write once read many times access mode
Thousands of parallel batch jobs
Small block sparse random I/O
Not enough money for hardware
This explains XRootD fundamental features
Why the name?<br>
slide5. Why the Name XRootD? Spurred by the pre-packaged rootd daemon
ROOT team planned to upgrade it
We wanted to avoid duplication
Easier to get people to use a familiar name
We tried rebranding in 2008
Structured Cluster Architecture for Low Latency Access (SCALLA)
Total failure!<br>
slide6. Solution: Over-Engineer It! 6 Minimize latency Minimize hardware requirements Minimize human cost Maximize scaling The synergistic approach made
XRootD one of the fastest cost-effective
systems even to this day<br>
slide7. XRootD Plug-in Architecture 7 Protocol Driver
Any n protocols 7 Allowed code reuse – faster development
In retrospect, gave it incredible longevity<br>
slide8. Super Scaling Using B64 Trees 8 Manager
(Root Node) Data Server
(Leaf Nodes) Supervisors
(Interior Nodes) How does a client get to a leaf?<br>
slide9. Routing Client To The Data 641 = 64 642 = 4096 Handles massive number of files
without using any database
and is naturally self-healing<br>
slide10. Conclusion XRootD is simple, flexible, and effective
Numerous plug-ins developed
Latest ones: Ceph, CASTOR, and mySQL
Others: File and block caching, Mass Storage, multiple file system (e.g. HDFS, DPM, etc)
Scaling and latency are ideal for HPC’s
Though that path is not obvious
We’ll explore this with BNL in 2017<br>
Tokyo
November 9, 2016
Andrew Hanushevsky, SLAC
http://xrootd.org<br>
slide2. Basic XRootD Concept A system for scalable cluster data access
Not a file system
Not just for file systems
If you can write a plug-in you can cluster it<br>
slide3. Brief History of XRootD 1997 – Objectivity, Inc. collaboration
Design & Development to scale Objectivity/DB
First attempt to use commercial DB for Physics data
Successful but problematical
2001 – BaBar decides to use root framework vs Objectivity
Collaboration with INFN, Padova & SLAC created
Design & develop high performance data access system
Work based on what we learned with Objectivity
2003 – First deployment of XRootD system at SLAC
2015 – Wide deployment with several implementations
ALICE, ATLAS, CMS, EXO, Fermi, LSST; among others
Protocol available in dCache, DPM, and EOS<br>
slide4. Only One Shot To Succeed! A lot of negativity floating around
Objectivity deemed a failure why not this?
So, we focused on the specific problem
The High Energy Physics analysis regime
Write once read many times access mode
Thousands of parallel batch jobs
Small block sparse random I/O
Not enough money for hardware
This explains XRootD fundamental features
Why the name?<br>
slide5. Why the Name XRootD? Spurred by the pre-packaged rootd daemon
ROOT team planned to upgrade it
We wanted to avoid duplication
Easier to get people to use a familiar name
We tried rebranding in 2008
Structured Cluster Architecture for Low Latency Access (SCALLA)
Total failure!<br>
slide6. Solution: Over-Engineer It! 6 Minimize latency Minimize hardware requirements Minimize human cost Maximize scaling The synergistic approach made
XRootD one of the fastest cost-effective
systems even to this day<br>
slide7. XRootD Plug-in Architecture 7 Protocol Driver
Any n protocols 7 Allowed code reuse – faster development
In retrospect, gave it incredible longevity<br>
slide8. Super Scaling Using B64 Trees 8 Manager
(Root Node) Data Server
(Leaf Nodes) Supervisors
(Interior Nodes) How does a client get to a leaf?<br>
slide9. Routing Client To The Data 641 = 64 642 = 4096 Handles massive number of files
without using any database
and is naturally self-healing<br>
slide10. Conclusion XRootD is simple, flexible, and effective
Numerous plug-ins developed
Latest ones: Ceph, CASTOR, and mySQL
Others: File and block caching, Mass Storage, multiple file system (e.g. HDFS, DPM, etc)
Scaling and latency are ideal for HPC’s
Though that path is not obvious
We’ll explore this with BNL in 2017<br>