Hi,

Won't the client try other IPs if the first one fails?

I'd also recommend not to mess with DNS ... changes can take a really long time to propagate ... probably longer than it takes to fix the problem :) Or you want to mess with local DNS at each cluster?

In short, I'd expect that one RR-DNS entry will work ok for both cases:
- jobs falling back to xrootd;
- managers connecting to meta managers.

Matevz

On 03/28/14 13:20, Andrew Hanushevsky wrote:

Hi Tommaso,

Indeed, if this is what you plan to implement then you would need one entry that
is stable and another that is not. While I don't quite understand what you are
trying to accomplish I can say that anything that relies on the presence or
absence of an entry in DNS will likely not work. Why? Because imagine that there
are jobs running between the time a server dies and the time then dead server is
removed from DNS, which could be a substantial delay in the eyes of the jobs.
What happens to those jobs? Likely they will fail because they rely on the DNS
entries to be correct. So, any scheme to avoid dead servers really has to be
handled by the application not some external agent.

Andy

On Fri, 28 Mar 2014, Tommaso Boccali wrote:

ciao andrew, understood & it makes sense, thanks.
But then. I need a different solution for stageout.
As you explained to me here,

all.manager meta all xrootd.infn.it+ 1213  (probably wrong since gmail is
playing with the text, but nevermind ... it is what you wrote ;)

needs xrootd.infn.it to be the list of all possible redirectors, regardless
of their state. Fine.

On the other hand, for CMSSW fallback I need to specify something like

if file /store/file.root not locally available --> try root://
xrootd.infn.it//store/file.root

in this case, instead, I want xrootd.infn.it to resolve only to those
redirectors which are _currently_ ok, right?

then I am afraid I need 2 DNS aliases

- xrootd-fulllist.infn.it : the machines which are installed as redirector,
from which nagios never removes anything
- xrootd.infn.it : the subset of the previous with only currently working
redirectors, to be used in the fallback statement.

Is this correct?

thanks again!

tom



On Fri, Mar 28, 2014 at 8:41 PM, Andrew Hanushevsky
<[log in to unmask]>wrote:

Hi Tommaso,

See below...


On Fri, 28 Mar 2014, Tommaso Boccali wrote:

 Let's say we prepare 2 regional redirectors, 1.1.1.1 and 2.2.2.2, and we

punt them in the DNS as xrootd.infn.it (no round robin: "host
xrootd.infn.it"
will return 2 IP addresses).
Since we want to use xrootd.infn.it as fallback, we plan to have a nagios
test which checks 1.1.1.1 and 2.2.2.2 periodically, and in case one is NOT
ok, it is removed from the DNS.

You shuld never remove anuthing from DNS, it will break all the
recoverability aspects of xrootd. Even if it's broken it should remian in
DNS. Hence, you don't need anything special. Just leave both servers in DNS
all teh time.

> So, question was:

let's say that site ABCD needs to restart the xrootd local servers, which
are configured as

all.manager meta all *xrootd.infn.it <http://xrootd.infn.it>*+ 1213

Uhm, tyhe above won't work/ Perhaps you really wanted to say


all.manager meta all xrootd.infn.it+ 1213

what happens if AT THE RESTART MOMENT xrootd.infn.it only resolves  to
1.1.1.1 (since eventually 2.2.2.2 is broken)? And even more, what if 2
hours later 2.2.2.2 enters again the DNS resolution for

It won't re-resolve. That's why you always leave both addresses in DNS.

Andy

--
Tommaso Boccali
INFN Pisa

########################################################################
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