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
|