Re: Multi-Master, referrals, and chaining

[Ryan Steele <ryans@aweber.com>]

Hey Darryl,

I decided to use a mixture of MMR and slaves.  Specifically, I'll have two masters doing MMR with a proxy (well, a
floating IP/hostname that achieves the same thing, anyways) in front to direct traffic to the 'active' master, with the
high-availability services being provided by Pacemaker, which will swap resources if the active master dies or becomes
unresponsive).  Additionally, I'll now have four slaves, each of which will happily perform reads and use an updateref
to send writes to the active master.  Along with that, I'll use chaining to have the slaves automatically chase the
referrals for the clients, so it seems transparent from their end.  With this model, I can still guarantee the
consistency of my data, distribute whatever reads don't hit the local caches more evenly among the cluster for better
performance, and still have a redundant set of masters to preserve continuity.  The nice thing is that altering my
current six-node MMR setup to fit this new architecture is pretty simple, requiring only a few changes to the newly
demoted slaves (such as disabling MirrorMode and simplifying some of the ACLs).  Thanks for the suggestion, though!

Price, Darryl wrote:
> Ryan,
> 
> In order to do what you're suggesting,  you'd probably need an intermediate layer ... a proxy server that routes write requests to a specific server.   I know Sun's LDAP Proxy that ships with DSEE 6.x can do that and I'm sure there are others as well.  I suppose you could also do this with MirrorMode replication rather than the multi-master model.  See http://www.openldap.org/doc/admin24/replication.html#MirrorMode%20replication
> 
> --Darryl
> 
> -----Original Message-----
> From: openldap-software-bounces+ldappro=gmail.com@OpenLDAP.org
> [mailto:openldap-software-bounces+ldappro=gmail.com@OpenLDAP.org]On
> Behalf Of Ryan Steele
> Sent: Wednesday, March 24, 2010 12:38 PM
> To: openldap-software@openldap.org
> Subject: 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
>>
> The information contained in this message and any attachment may be
> proprietary, confidential, and privileged or subject to the work
> product doctrine and thus protected from disclosure.  If the reader
> of this message is not the intended recipient, or an employee or
> agent responsible for delivering this message to the intended
> recipient, you are hereby notified that any dissemination,
> distribution or copying of this communication is strictly prohibited.
> If you have received this communication in error, please notify me
> immediately by replying to this message and deleting it and all
> copies and backups thereof.  Thank you.
> 
>