 |
 |
On 6/14/19 10:12 PM, Andrew Hanushevsky wrote: > Hi Afrian, Hi! > Answers withon the email... Thank you for your answers! I will have some more questions below > On Fri, 14 Jun 2019, Adrian Sevcenco wrote: > >> Hi! What would be the recommended settings for an xrootd installation >> that use a distributed file system like gluster? > I can't recommend specific settings but can indicate required directives > to allow the whole thing to correctly function. You need to specify the > cms.dfs directive. > > http://xrootd.org/doc/dev410/cms_config.htm#_Toc8247261 > > This tells the cmsd that you are using a distributed file system. It > needs to know that to change file location to be consistent with DFS > semantics. on the dfs topic with central lookup, how is the redirector aware about the location of the data? i can make sure that the mountpoint is identical over all servers (redirector and xrootd data servers alike) but should i also set up on the redirector things like oss.space and for ALICE case the specific authorization and file name translation (ofs.authorize ofs.authlib oss.namelib) ? >> beside the dfs what other tweaks will make sure that the load is >> equally distributed among the file servers? > You will need to enable load scheduling to get the best effect here. The > default is round-robbin which works in many cases but is far from ideal > when you want to avoid hot spots. Consult the cms.sched and cms.perf > directives: > > http://xrootd.org/doc/dev410/cms_config.htm#_Toc8247267 > http://xrootd.org/doc/dev410/cms_config.htm#_Toc8247264 hmm, while i use cms.sched i did not use cms.perf and i see that cms.perf have no pgm default even if there is a provided script /usr/share/xrootd/utils/XrdOlbMonPerf so, given that cms.perf was not set up should i understand that the specifications of cpu and io in cms.sched are just ignored as there is no facility for load reporting? >> it would seem that the redirector remembers the last data server that >> answered a file query so the same server is used again ...how can this >> be disabled? > No need to disable anything here if you use the cms.dfs directive. ok >> also, given the uniformity of the storage space, is there a need for a >> redirector?(or cmsd)? could a simple xrootd (and with dns aliasing) >> distribute the load equally? > Using DNS will not distribute load equally and will cause severe latency > issues should one or more of the servers become unavailable. While it > may appear to work you will soon find that it works very poorly. ok >> also, for really large installations (and not only) i seen that there >> is a mechanism for keeping a metadata cache of all namespace(s) - XrdCnsd > Yes, we have tried to deprecate that but people come up wanting it from > time to time; so, it still has a life of its own. > >> can this be used to bypass the metadata query of files and reduce the >> load of the actual block device? > No, the XrdCnsd is meant to keep an inventory so that should you loose a > disk array you will know what you lost. It is not a sufficiently > real-time inventory suitable for file lookups. ok, i completely misunderstood the purpose of such facility .. Thank you!! Adrian ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-L list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1