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

Multi-Master, referrals, and chaining

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.