Re: Multimaster further work

[Markus Storm <Markus.Storm@mediaWays.net>]

Howard Chu wrote:
> 
> > -----Original Message-----
> > From: owner-openldap-software@OpenLDAP.org
> > [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Derek Simkowiak
> 
> > > In many cases this comes down to directory design.
> 
> >       Well, yes, but then you don't have conflicting entries for the
> > same DN.  You have non-conflicting entries for different DNs,
> > and you're
> > not even in the discussion anymore  :)
> 
> Sometimes the best approach when faced with a hard problem is to take a
> different path and avoid facing it in the first place.

Yes. This is why we built a loadbalancing (failover, merely) system around
servers running slapds with broken indexing code.

> 
> Talk about "5 nines" reliability or somesuch, server up 99.999% of the time.
> This translates to 10 minutes of downtime per week. This in itself is pretty
> generous, to my mind. I have slapd servers providing SSO/authentication, etc.
> to various web sites that have been running for 9-10 months at a time; the
> only reason they restart is for software upgrades. There probably isn't even
> 10 minutes of downtime per *year*. And if it fails, it will assuredly take
> less than 10 minutes for failover to the spare server to occur. As such, the
> spectre of "single point of failure" also isn't very compelling.

I strongly disagree.
Are you telling me OpenLDAP doesn't need to offer multimaster because anyone 
should be able to keep his servers 3 nines up ?
Ever had to deal with a flooding like we just had in Germany ?
Also, it highly depends on the application and environment whether you can
easily switch to a backup system or not.
And given the long history of index bugs ... no bashing intended, but I'm
astonished to hear that you manage 9 months runtime. *We* had to regularly
stop slapd to reinitialize the database.
Luckily, we were able to do without interruption of neither read nor write
access to the slapd servers - thanks to multimaster !

As I mentioned earlier, we've been using it for two years and it *really*
saved my .... err, you know what I mean. More than once.

> 
> The issue of load-balancing is a red herring. If you have a pool of servers
> and you are distributing queries across all of them, the load from write
> operations is the same whether you are using single-master or multi-master
> replication - the update still has to propagate to every other server. As
> such, multi-master replication offers no benefit, while introducing a slew of
> potential problems.

Don't think of loadbalancers as "loadbalancers". Think of them as devices
that *supervise* a bunch of backend servers, recognize broken ones and direct
incoming requests to the remaining working ones.
You then need multimaster to keep the data consistent.

[ I agree with the non-benefit due to multiple-write here.
  Though - just for the sake of discussion - you could solve that as well:
  'Partition' the data onto multiple backends and use a proxy to direct the
  requests to the appropriate backend.
  Some issues need to be addressed then, but the back-meta code already
  implements a major part of this. ]

> 
> >       I strongly disagree.  I think this is an issue that should have
> >strong input from the endusers.  Devel lists are somewhat exclusive to
> >people who are great at writing code, but not necessarily great at
> >identifying endusers' needs.  I think this discussion is best held out "in
> >the open", where real-world users of OpenLDAP can make sure their needs
> >are being taken into account.
> 
> Endusers who have not been around the subject area for a great length of time
> tend to misidentify their needs and desired solutions. In any profession, the
> percentage of people proficient at thinking critically in that field is a
> tiny amount compared to the field as a whole, and as such most enduser input
> is typically no better than random noise. I also think it's naive to believe
> that developers are not also endusers themselves, and fully cognizant of the
> features needed to apply an arbitrary technology to a real world problem.

Hey, we aren't endusers.
We're administrators facing and trying to solve real world problems.

regards,
Markus

-- 
  Markus Storm, mediaWays GmbH, Verl, Germany
  storm @ mediaways.net