[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Multi-Master, referrals, and chaining

I actually realized that my logic was slightly faulty - since each of the six masters is capable of performing the write
operation, the referral will never be chased.  Given that, is it impossible to have an N-Way MultiMaster configuration
in which writes are possible on any node, but the writes at any given time are performed on only one of them to ensure
consistency?  That is, short of doing what I'm doing now (sending ALL traffic to only one master), which doesn't scale
very well.

Ryan Steele wrote:
> Hey folks,
> As it stands, I've got an environment with six slapd servers (2.4.18) in an N-Way Multi-Master configuration.  At any
> given moment, only one of these six nodes is receiving client requests (reads, writes, etc.).  We use Pacemaker to
> provide some basic high-availability services, such that if the current 'master' (a term I'll use in this thread to
> refer to the one node receiving all reads/writes from clients) croaks, a shared IP/hostname resource is migrated to the
> next available server.
> I would like to modify this setup such that ALL of these six nodes can receive client requests, but in the interest of
> preserving data consistency, I'd like to refer writes to just one of them (that one being the current 'master'), such
> that the rest receive the update(s) via syncrepl.  From my own research and reading, it seems as though I'll need a
> combination of referrals (specifically, the 'updateref' directive) and chaining, with the latter being introduced so
> that the job of chasing the referrals is handled server-side instead of being offloaded to the clients.  I have two
> questions about this setup, though:
> 1. In order to prevent an endless loop of referrals, I'm assuming that the terminal node (the 'master') should NOT have
> an updateref option that points to the 'master' shared IP/hostname (i.e., itself), like the rest of the nodes do.  Is
> this correct, or will slapd realize that the referral target is itself, and answer authoritatively?
> 2. If the assumption in #1 is correct, what is the most advisable way to handle referrals in the situation where the
> identity of the terminal node is subject to change?  My thought was to trigger an ldapmodify operation which effectively
> removes the olcUpdateRef option during the failover, but I'm open to better ideas if they exist.
> Thanks!
> -Ryan