Why would ctdb need to be in no-lmaster or no-recmaster modes?

ronnie sahlberg ronniesahlberg at gmail.com
Thu Nov 20 17:14:46 MST 2014


On Thu, Nov 20, 2014 at 1:40 PM, Martin Schwenke <martin at meltin.net> wrote:
> Hi Richard,
>
> On Thu, 20 Nov 2014 09:47:18 -0800, Richard Sharpe
> <realrichardsharpe at gmail.com> wrote:
>
>> I am trying to understand ctdb more and wonder why we need those two
>> flags/capabilities in ctdb.
>
> From ctdb(7):
>
>        The RECMASTER and LMASTER capabilities can be disabled when CTDB
>        is used to create a cluster spanning across WAN links. In this
>        case CTDB acts as a WAN accelerator.
>
> That was written by Ronnie so he may be able to explain what he had in
> mind.
>
> My understanding is that nodes without these capabilities can still be
> DMASTER for records, so can still have Samba running on them. However,
> to find the who is DMASTER the "remote" nodes will still need to go to
> the LMASTER.  I've never understood the term "accelerator" in this
> context...

Accelerator in the sense that the remote office/node would only take
the latency hit to walk across the WAN link and request a dmaster
migration on first access to the record and then any successive access
to the records would be fast since the record would be held locally.

The rationale for "remote-node can not be LMASTER" was:
For the rest of the cluster, the non-remote part of the cluster which
we assume is the important part of prod, those nodes should never have
to go across a WAN link to find the LMASTER for a record.
So this was a way to try to guarantee that for the core part of the
cluster, you would always be able to resolve the LMASTER to a nearby
local node.

The remote node however would always have to go across the WAN link
any time it would need to find the LMASTER, but that seemed
reasonable.

Similarly for RECMASTER. Do not allow RECMASTER role to be held by the
single node that is far away and has high latency to talk to every
other node.


I think Andreas S<something> did a few tests for this with very
promising results.


regards
ronnie sahlberg


More information about the samba-technical mailing list