Working Page

Pre References

Here some more details conerning Xrootd in general and how to integrate this with D-Cache are described

Access via a XrootD Proxy host

There is a proxy that speaks (gsi-enabled) xrootd to the outside world. Towards the local resources it connects to a (non-gsi-enabled) D-Cache door. All traffic is routed through this box.

The proxy runs on one CMS VOBOX and connects to the European redirector @ INFN. The configuration /etc/xrootd/xrootd.cf looks like this:

# Port specifications; only the redirector needs to use a well-known port
# "any" will cause rooted to bind to any available port.  Change as needed for firewalls.
xrd.port 1094

# The roles this server will play.
all.role server
all.role manager if xrootd.ba.infn.it
# The known managers
all.manager all xrootd-cms.infn.it+ 1213
# Allow any path to be exported; this is further refined in the authfile.
all.export / r

# Hosts allowed to use this xrootd cluster
cms.allow host *

### Standard directives
# Simple sites probably don't need to touch these.
# Logging verbosity
xrootd.trace emsg login stall redirect
ofs.trace none
xrd.trace conn
cms.trace all

# Integrate with CMS TFC, placed in /etc/storage.xml
pss.namelib /usr/lib64/libXrdCmsTfc.so file:/etc/xrootd/storage.xml?protocol=direct

# Turn on authorization
ofs.authorize 1
acc.authdb /etc/xrootd/Authfile
acc.audit deny grant

# Security configuration
sec.protocol /usr/lib64 gsi -certdir:/etc/grid-security/certificates -cert:/etc/grid-security/xrd/xrdcert.pem -key:/etc/grid-security/xrd/xrdkey.pem -crl:3

# The following is the suggestion configuration if you use SCAS/GUMS; you will need the xrootd-lcmaps RPM
# sec.protocol /usr/lib64 gsi -certdir:/etc/grid-security/certificates -cert:/etc/grid-security/xrd/xrdcert.pem -key:/etc/grid-security/xrd/xrdkey.pem -crl:3 -authzfun:libXrdLcmaps.so -authzfunparms:--osg,--lcmapscfg,/etc/xrootd/lcmaps.cfg,--loglevel,0|useglobals --gmapopt:2 --gmapto:0

xrootd.seclib /usr/lib64/libXrdSec.so
xrootd.fslib /usr/lib64/libXrdOfs.so
ofs.osslib /usr/lib64/libXrdPss.so
all.adminpath /var/run/xrootd
all.pidpath /var/run/xrootd

cms.delay startup 10
cms.fxhold 60s
cms.perf int 30s pgm /usr/share/xrootd/scripts/XrdOlbMonPerf 30

if exec xrootd
  xrd.report xrootd.unl.edu:3333 every 300s all
  xrootd.monitor all flush 5s mbuff 1k window 1s dest files io info user xrootd.t2.ucsd.edu:9930
fi

# Replace with the IP address of the xrootd dCache door.  Workaround for a segfault bug.
#pss.origin dcache-cms-xrootd.desy.de:1094
# dcache-cms-xrootd.desy.de
pss.origin 131.169.98.165:1094
# dcache-vdoor-cms50
#pss.origin 131.169.98.166:1094

# After doing tests, set this back to 0; very noisy
pss.setopt DebugLevel 1
# Default cache size is 512MB per file; prune
pss.setopt ReadAheadSize 16384
pss.setopt ReadCacheSize 8388608
pss.setopt ReadAheadStrategy 0
pss.setopt ReadTrimBlockSize 16384
# dCache xrootd door has a big perf hit for async.
xrootd.async off
# Default workers setting thread contention on load.
pss.config workers 32

The TFC plugin translates all LFNs to PFNs. It is configured in /etc/xrootd/storage.xml. It needs to be adapted to the needs of each site. The storage.xml from the local Phedex configuration is a good starting point.

 <storage-mapping>
<lfn-to-pfn protocol="direct" destination-match=".*"
      path-match="/+(.*)"
      result="/pnfs/desy.de/cms/tier2/$1"/>
</storage-mapping>

Redirecting to D-Cache door

Instead of channeling all traffic through a proxy, one can redirect all connections to a D-Cache xrootd door immediately. One needs a host that runs the cmsd and the native xrootd with a config (/etc/xrootd/xrootd.cf) like this:

# Port specifications; only the redirector needs to use a well-known port
# "any" will cause rooted to bind to any available port.  Change as needed for firewalls.
xrd.port 1094

# The roles this server will play.
all.role server
all.role manager if xrootd.ba.infn.it
# The known managers
#all.manager xrootd.ba.infn.it:1213
# Test redirector by Giacinto
all.manager all xrootd-cms.infn.it+ 1213
# Allow any path to be exported; this is further refined in the authfile.
all.export / r

# Hosts allowed to use this xrootd cluster
cms.allow host *

### Standard directives
# Simple sites probably don't need to touch these.
# Logging verbosity
xrootd.trace emsg login stall redirect
ofs.trace none
xrd.trace conn
cms.trace all

# Turn on authorization
ofs.authorize 1
acc.authdb /etc/xrootd/Authfile
acc.audit deny grant

# Security configuration
#sec.protocol /usr/lib64 gsi -certdir:/etc/grid-security/certificates -cert:/etc/grid-security/xrd/xrdcert.pem -key:/etc/grid-security/xrd/xrdkey.pem -crl:3

# The following is the suggestion configuration if you use SCAS/GUMS; you will need the xrootd-lcmaps RPM
# sec.protocol /usr/lib64 gsi -certdir:/etc/grid-security/certificates -cert:/etc/grid-security/xrd/xrdcert.pem -key:/etc/grid-security/xrd/xrdkey.pem -crl:3 -authzfun:libXrdLcmaps.so -authzfunparms:--osg,--lcmapscfg,/etc/xrootd/lcmaps.cfg,--loglevel,0|useglobals --gmapopt:2 --gmapto:0

xrootd.fslib /usr/lib64/libXrdOfs.so
# Works if CMS LFNs 'map' to PFN from a certain point in the directory tree
oss.localroot /pnfs/desy.de/cms/tier2
# Note that the redirect line doesn't match the documentation!
xrootd.redirect dcache-vdoor-cms50.desy.de:1094 /
# Note: this works so far only, if the door is not GSI enabled.


all.adminpath /var/run/xrootd
all.pidpath /var/run/xrootd

cms.delay startup 10
cms.fxhold 60s

-- ChristophWissing - 18-Aug-2011

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2014-04-14 - TommasoBoccali
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback