 |
 |
Hi Tommaso & Marian, I apologize that we didn't get a prompt response back. Somehow this slipped through the cracks. So, let me intersperse my answers in the text below. On Thu, 27 Mar 2014, Tommaso Boccali wrote: > ok, but what happens if a site restarts its cmsd when the redirector points > just to one redirector (because the other is off)? > when the second redirector comes back in the DNS list, will the site pick > it up or not? When a site restarts it's cmsd when one of the redirectors is off. When all is used, all traffic marked to go to the one that is offline is shifted to a particular redirector that is still working. When that redirector comes back online the traffic is shifted back as it would have been had the redirector been online at the time of restart. When any is used, all traffic marked to go to that redirector, if any, is shifted to another working redirector. When that redirector comes back online the traffic is normally shifted back to that redirector if it was the redirector of choice (i.e. the one originally chosen to receive all of the traffic). > On Thu, Mar 27, 2014 at 4:08 PM, Marian Zvada <[log in to unmask]> wrote: > >> we have very same setup for CMS T2 and currently in commissioning process. >> We have DNS round-robin alias between FNAL and UNL and use the following in >> the config: >> all.manager meta all cmsxrootd.fnal.gov+ 1213 >> (xrootd1.fnal.gov and xrootd.unl.edu behind that) Yes, this is the correct way of doing this. XRootD will take over the parcelling out of traffic as DNS round-robbin is (and always has been) problematic for the way XRootD needs to load balance requests. >> => I think this should be adapted also for your setup as well I believe, >> though pointing to different aliased host. Yes. >> For the question of "all" as parameter I was already asking in developers >> list what's beneficial, all || any, but didn't get response so far. Here >> it's documented but I didn't get full understanding what's recommended from >> operation point of view while using DNS-RR setup: >> http://xrootd.org/doc/prod/cms_config.htm#_Toc339484334 Indeed, we should have had a better explanation. Could either of you post a problem ticket that requests that the documentation discuss why you would choose one over the other so it doesn't fall through the cracks? In absence of that let me explain. Choosing any is suitable when your interaction rate with xrootd is not overtaxing the system. You may be overtaxing the system if the CPU usage of the cmsd is getting high or it's memory starts getting out of hand (sort of c,sd using more than 10% of the CPU or sitting on more than 2GB of memory -- though we haven' really benchmarked that). With all, all traffic goes to a single cmsd and the other redirectors listed are merely used as a fallback if the primary cmsd fails. Choosing all is suitable when you interaction rate with xrootd is very high and you wish to distribute that load across all of the cmsd's that are available. This is suitable when all of the cmsd's are roughly of the same power (if not you will get rather odd skew effects in responsiveness). Here, requests are parcelled out using a determinstic algorithm so that each request relative to a particular file always goes to the same cmsd, thus maximizing the use of the routing cache. >> However, we stick so far with: >> all.manager meta all cmsxrootd.fnal.gov+ 1213 >> >> Also, currently each of top redirectors in the DNS-RR alias subscribes to >> global redirector: >> all.manager meta any cms-xrd-global.cern.ch+ 1098 >> (see 'any' in this case) Yes, I see that. So is there any reason why you used any here while you used all elsewhere? Not that it likely matters but I am curious why the difference. Andy ######################################################################## 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