RE: Multimaster question

["Clowser, Jeff" <jeff_clowser@fanniemae.com>]

> > I want to set up a cluster of ldap servers.  In that 
> cluster, I want:
> >
> > - One primary supplier server
> > - One hot standby supplier server
> > - N read only consumer replicas.
> > - a load balancer that directs all writes to the primary 
> master if it's
> > up,
> >   or the standby if it's down.
> >
> > However, I want operational attributes like password policy 
> attributes
> > to be replicated across the cluster.  My understanding is that if I
> > set up two suppliers and N consumers, operational attribute changes 
> > (such as password policy attrs) on the consumers will not replicate 
> > across the cluster.
> 
> Where did you find such information?

There was a post about this about a month ago, talking about this as a
problem and using chaining to solve it, but I'm thinking the chaining
idea didn't solve all the problems...

> in order to syhnchronise all user attributes and operational
> attributes just use *,+ as attribute list, as lined out in man
> slapd.conf(5) 
> 
> -Dieter

My understanding is that if I have a master/slave config with a
typical syncrepl setup, and have password policy turned on in the 
consumer, password policy operational attributes are maintained 
locally, and are not replicated back to the master/supplier, but 
operational attributes on a master/supplier will be replicated to a 
consumer.  Given that most clients will talk to a consumer server, 
that would mean password policy op attrs are not replicated to other 
consumers.  Is that correct?  If they are in fact replicated, how 
does the consumer have permission to write back to the master/supplier, 
so it can replicate to other consumers?

I want to find a way to preserve the idea of directory consistency by
writing to a single server from an external client POV, while 
propogating operational knowledge like password failures across the 
cluster.

I'm thinking there are 2 options (in theory - I don't know if these 
actually work - at this point, I'm looking for advice on the best 
direction to go for this in my testing.  Hoping to brainstorm 
possibilities first to limit the number of test cases/situations I 
have to try before I get something workable):

Option 1
Use the chain overlay to forward write operations on a consumer back
to the supplier.  I think I would have to have different aci's on the 
consumer (only non-write aci's) so that a client could not write to 
the consumer and have it chained to the master(?)  I.e. to an external 
client, I still want this to "appear" as a typical single master (well,
single master with a hot standby which is hidden by a load balancer),
multiple 
read-only consumers setup.  I don't really care if the consumer returns 
a referral on a write attempt or an error, since most of my clients
don't 
follow referrals anyway. I definitely don't want all my consumers to 
allow writes directly (I'd actually prefer to firewall my suppliers off 
so only select apps can even get to them to write, while most apps only 
have access to a read-only consumer.) But... I think I saw something 
previously on the list about these operational attributes being written 
directly to the db, so might not follow a chain rule to write it to the 
supplier(?)  Also, creates a single point of failure (well, not single, 
but as many suppliers as you have) in that everything has to be
channeled 
through the master server(s).

Option 2
Everything is a master/supplier, but aci's on designated "masters" allow
read/write operations, while designated "consumers" have aci's that only
allow non-write access.  I believe this would replicate the operational
attributes in a way that chaining may not(?), eliminates single point
of failure, since every server can pass its op changes on to every other
server(?).  Effectively, from an external client, this is a typical one
master, many consumer setup, but internally, operational data is shared
across the entire cluster (assuming it all works like I think it does).

Option 2 has the added benefit that I can promote one of these
"consumers" to be a master in a disaster recovery situation very easily 
by just replacing the aci's.  Option 1 would require me to undo all the
chaining config, and update all my consumers to point to the "new" 
supplier (I suppose DNS tricks could be used to resolve some of that, 
but either way it's more complicated).


So.. Am I on the right track?  Anything I say completely wrong?  Is
there
another, better option to do what I want?