CTDB IP takeover/failover tunables - do you use them?

[hvjunk]

> On 20 Apr 2017, at 11:50 , Martin Schwenke <martin at meltin.net> wrote:
> 
> On Thu, 20 Apr 2017 09:27:25 +0200, hvjunk <hvjunk at gmail.com> wrote:
> 
>>> On 20 Apr 2017, at 07:16 , Martin Schwenke <martin at meltin.net> wrote:
> 
>>> Right. So, in that case, you just set the public addresses list on
>>> NodeC to be empty.  You can even set
>>> CTDB_PUBLIC_ADDRESSES=/dev/null on NodeC - that's what our test suite
>>> does when it is running against "local daemons”.  
> 
>> Okay… the documentation I’ve read up till now, states something like:
> 
> If you see it wrong anywhere else then please yell and we'll fix
> it.  :-)

Ah, sorry, I confused the public_IPs list file with the NODES list file! 
(Have just a headache after battling SystemD to get the GlusterFS mounting *reliably* )

> The order of the public IPs in the files doesn't matter.  The IP
> takeover process gathers the IPs from all nodes and (effectively) sorts
> them before allocating them.  However, a detail of the implementation
> means that the list ends up *reversed* before the IPs are allocated. So,
> if NodeA is node 0 and NodeB is node 1 with addresses 10.0.1.1 and
> 10.0.2.2 then the allocation should look like:
> 
>  10.0.1.1  1   # NodeB
>  10.0.2.2  0   # NodeA
> 
> It is easy enough to test.  Hopefully you can work with that.
> 
> The IP failover part of CTDB will mostly like undergo some large
> changes before Samba 4.8.  I don't think we'll lose any
> functionality... but we might un-reverse the sort order...  ;-)

okay… 

Thanks for the explanation! 

However, would it be difficult/etc. to have it “preferred” to a specific node? ie, in the  CTDB_PUBLIC_ADDRESSES for a node, have something like:

10.1.1.1/24 eth1 prefer
10.1.2.1/24 eth1

In a case with the cluster “local” I know it’ll not make a difference, but with my “distributed” nodes, the locality would be nice to have it assigned, rather than computed, especially if the algorithm might change during an upgrade.

Anycase, thank you Martin for the help, it helped me a lot!

Hendrik Visage