200 likes | 236 Views
Explore XRootD architecture, proxies, security transformations, and clustering for scalable data storage systems. Learn about authentication, firewall configurations, and extending access with practical examples. Discover how security transforms ensure a secure data environment across servers and clients.
E N D
xrootd Proxies Andrew Hanushevsky (SLAC) • Middleware Security Group Meeting • 5-6 June 2006 • http://xrootd.slac.stanford.edu • xrootd is largely funded by the US Department of Energy • Contract DE-AC02-76SF00515 with Stanford University
Outline • xrootd Architecture Overview • Terms and Concepts • Clustering • Proxies • Single and double firewalls • Proxy clusters for scalability • Security transformations • Conclusions & Acknowledgements 2: http://xrootd.slac.stanford.edu
Performance authentication (gsi, krb5, etc) lfn2pfn prefix encoding authorization (name based) Protocol (1 of n) (xrootd) File System (ofs, sfs, alice, etc) Storage System (oss, drm/srm, etc) Scaling Clustering (olbd) xrootd Plugin Architecture Protocol Driver (XRD) 3: http://xrootd.slac.stanford.edu
Acronyms, Entities & Relationships xrootd Data Network (redirectors steer clients to data Data servers provide data) olbd Control Network Managers, Supervisors & Servers (resource info, file location) Redirectors olbd M ctl xrootd olbd S Data Clients data xrootd Data Servers 4: http://xrootd.slac.stanford.edu
Cluster Architecture A manager is an optionally replicated xrootd/olbd pair functioning as a root node Up to 64 servers or cells can connect to a manager Server A server is an xrootd/olbd pair leaf node that delivers data A cell is 1-to-64 entities (servers or cells) clustered around a cell manager called a supervisor 5: http://xrootd.slac.stanford.edu
Single Level Switch A open file X Redirectors Cache file location go to C 2nd open X Who has file X? B go to C I have open file X C Redirector (Head Node) Client Data Servers Cluster Client sees all servers as xrootd data servers 6: http://xrootd.slac.stanford.edu
Two Level Switch Client A Who has file X? Data Servers open file X B D go to C Who has file X? I have open file X I have C E go to F I have Supervisor (sub-redirector) Redirector (Head Node) F open file X Cluster Client sees all servers as xrootd data servers 7: http://xrootd.slac.stanford.edu
SLAC Configuration kan01 kan02 kan03 kan04 kanxx kanolb-a bbr-olb03 bbr-olb04 client machines 8: http://xrootd.slac.stanford.edu
Extending Access • Easy clustered local access • Everyone sees everyone • Simple configuration • Low human overhead to maintain • Remote access • Difficult because of connection constraints • Want to make it humanly administrable • Critical to minimize cross-domain knowledge • Utilize the peer-to-peer nature of xrootd 9: http://xrootd.slac.stanford.edu
Proxies I (single firewall) data01 data02 data03 data04 IN2P3 olbd 3 2 Firewall proxy xrootd INDRA 1 client machines 10: http://xrootd.slac.stanford.edu
Scaling Proxies • Need to provide more than one proxy • Selection criteria for proxies? • Utilize natural rooted clustering • Create proxy clusters • Automatically load balance • No practical limit on number 11: http://xrootd.slac.stanford.edu
Proxy Clusters (single firewall) data01 data02 data03 data04 olbd olbd 5 2 4 proxy manager xrootd proxy server xrootd Firewall 1 3 client machines 12: http://xrootd.slac.stanford.edu
Dealing With Lockdowns • Double Firewalls • Reality sets in. • Incoming and outgoing traffic limited • Utilize peer-to-peer nature of rooted • Maintains practical simplicity • Alternative not particularly appealing • Application controlled firewall • LBL and ANL models for gridFTP. • Could use xrootd’s for this as well, though. 13: http://xrootd.slac.stanford.edu
Proxies II (double firewall, simplified) data01 data02 data03 data04 4 olbd 3 remote proxy xrootd Firewalls 2 local proxy xrootd 1 client machines 14: http://xrootd.slac.stanford.edu
N-to-M Authentication issues • Clusters of proxies on each side • Random server-server connections • Authentication key management issues • Complex because of size and interactions • Would like to simplify key distribution • Use a security transformation • GSI to global session key 15: http://xrootd.slac.stanford.edu
2 3 2 1 Scalable Proxy Security SLAC PROXY RAL PROXY Data Servers Data Servers Firewall 1 Authenticate & develop session key 2 Distribute session key to authenticated subscribers 3 Servers can log into each other using session key 16: http://xrootd.slac.stanford.edu
Extending Security Transforms • xrootd protocol allows security transforms • Redirect can pass along a CGI string • Anyone can redirect! • No practical redirect limit. • Allows security framework substitutions • Minimizes GSI intra-cluster overhead 17: http://xrootd.slac.stanford.edu
Security Transforms data01 data02 data03 data04 olbd 4 3 GSI “proxy” xrootd x-auth xrootd 1 2 client machines 18: http://xrootd.slac.stanford.edu
Conclusion • xrootd has a security enabling architecture • Protocol was designed with security in mind • Accommodates security transforms • Server-to-server • Client-server • Very easy to administer • Critical for maintaining security 19: http://xrootd.slac.stanford.edu
Acknowledgements • Software collaborators • INFN/Padova: Fabrizio Furano, Alvise Dorigao • Root: Fons Rademakers, Gerri Ganis • Alice: Derek Feichtinger, Guenter Kickinger, Andreas Peters • Cornell: Gregory Sharp • SLAC: Jacek Becla, Tofigh Azemoon, Wilko Kroeger, Bill Weeks • Princeton: Pete Elmer • Operational collaborators • BNL, CNAF, FZK, INFN, IN2P3, RAL, SLAC 20: http://xrootd.slac.stanford.edu