Fedora directory users - Jul 2005 - Advantages of using FDS vs OpenLDAP?

This question is probably completely obvious to those more versed in  
LDAP, which I am not.  And since I couldn''t find an answer to this in  
the Wiki, I thought that it didn''t hurt to ask.

So what are the advantages of using a "specialized" LDAP server,  
whether Fedora/Red Hat Directory Server, Apache Directory, Open  
Directory, etc., versus using just OpenLDAP?  Increased  
functionality?  Heightened and more security measures?

Bryan wrote:
> This question is probably completely obvious to those more versed in  
> LDAP, which I am not.  And since I couldn''t find an answer to this
in
> the Wiki, I thought that it didn''t hurt to ask.
>
> So what are the advantages of using a "specialized" LDAP server,
> whether Fedora/Red Hat Directory Server, Apache Directory, Open  
> Directory, etc., versus using just OpenLDAP?
I''m not sure what you mean by "specialized" here.  Could you
explain
further?  If you mean "OS or NOS specific", then FDS is not
specialized
- it is used on a wide variety of OS for different purposes other than 
just NOS user/group management.  If you mean "small or used for a 
specific purpose", then FDS is not specialized - it is used in very 
large deployments, is highly scalable, even in WAN environments, and is 
used for a variety of purposes.
> Increased  functionality?
Yes.  It seems one feature of OpenLDAP that many people want (or at 
least ask for a lot) is multi-master replication, to eliminate a single 
point of write failure or load balance among writable servers.  FDS 
supports 4 masters (meaning we''ve exhaustively tested it with 4
masters)
but can theoretically support many more, depending on your replication 
topology.

Another feature of FDS is the GUI management console which many people 
prefer to a command line interface.  Sure, there are tools that allow 
you to do user/group management using a GUI, but the console provides 
that and much, much more - backups, restores, import, export, indexing, 
schema, logs, full on-line server configuration, monitoring, metrics, etc.

Many of the features of OpenLDAP 2.3 which make management easier, such 
as on-line configuration, on-line schema updates, in tree ACIs, auto 
database recovery, and more, have been in FDS for years and are fully 
tested, stable, and mature.  It remains to be seen how stable the 
corresponding features in OpenLDAP are.  I''m not saying they
aren''t
stable in OpenLDAP, but I''m just saying that FDS has had these features
for years and they have been tested in very demanding production 
environments.
> Heightened and more security measures?
We''ve done a lot of static analysis using tools like rats and 
flawfinder, and dynamic analysis using tools like valgrind and purify.  
We did quite a bit of "hardening" prior to open sourcing the code. 
But
I''m sure the OpenLDAP team can boast similar measures.

The crypto engine is NSS which we feel is more secure than OpenSSL 
(although I suppose that''s a matter of debate).  But NSS 3.9.3 is FIPS 
140 certified (OpenSSL is not, although I think certification is 
underway).  NSS supports any crypto device that conforms to the PKCS11 
standard - OpenSSL usually supports these devices through vendor 
proprietary interfaces.   NSS was and still is developed by many of the 
same folks who worked on the initial Netscape SSL implementation - some 
of whom are our co-workers at Red Hat.  NSS is the same crypto engine 
that''s in Mozilla/Firefox, Evolution, OpenOffice, Netscape/Sun/iPlanet 
server products, and many others.
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

If I can piggyback off of this question and ask another: advantages of using
RedHat Directory Server vs. Fedora Directory Server?

The only thing I can see we get with RedHat Directory server is 
official support
(and at the prices I was quoted per year, for two servers, I could hire half a
person, although academic pricing wasn''t available at the time :)

The situation I''m in is one where I have an aging directory
infrastructure,
going all the way back to the days when the Directory Server was branded with
the Netscape brand :)  Its been on my TODO list to upgrade to something, for
the past two years, but I never got around to migrating to OpenLDAP, for a
number of reasons.  With the release of RedHat/Fedora Directory Server, it was
a matter of installing it, adding a few schema modifications, exporting data
from the old server, and importing into the new.  Simple as pie.  I''ve
been
running with that in a test environment for a month, no problems.  And
I''m
ready to plan out a full scale conversion and setup multimaster replication.

So am I missing anything obvious, beside official support, for what I 
would pay
for Red Hat Directory Server?

Kevin

-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org

Kevin Myer wrote:
> If I can piggyback off of this question and ask another: advantages of 
> using
> RedHat Directory Server vs. Fedora Directory Server?
>
> The only thing I can see we get with RedHat Directory server is 
> official support
> (and at the prices I was quoted per year, for two servers, I could 
> hire half a
> person, although academic pricing wasn''t available at the time :)
Sure.  I was told by the Marketing director that there would be academic 
pricing for RHDS.  For what it''s worth, Red Hat marketing has decided
to
target the whales first - large enterprises and govt. organizations with 
deep pockets that would find our pricing much more attractive than our 
competitors in that space.
>
> The situation I''m in is one where I have an aging directory 
> infrastructure,
> going all the way back to the days when the Directory Server was 
> branded with
> the Netscape brand :)  Its been on my TODO list to upgrade to 
> something, for
> the past two years, but I never got around to migrating to OpenLDAP, 
> for a
> number of reasons.  With the release of RedHat/Fedora Directory 
> Server, it was
> a matter of installing it, adding a few schema modifications, 
> exporting data
> from the old server, and importing into the new.  Simple as pie. 
I''ve
> been
> running with that in a test environment for a month, no problems.  And 
> I''m
> ready to plan out a full scale conversion and setup multimaster 
> replication.
>
> So am I missing anything obvious, beside official support, for what I 
> would pay
> for Red Hat Directory Server?
Official support, upgrades, patches.  Easily installable/upgradeable 
binaries rather than build from source code.  If there is a patch for 
FDS, it is unlikely that the patch will be made readily available as a 
binary (although we will try).
>
> Kevin
>

On 7/8/05, Kevin Myer <kevin_myer@iu13.org> wrote:
> If I can piggyback off of this question and ask another: advantages of
using
> RedHat Directory Server vs. Fedora Directory Server?
> 
> The only thing I can see we get with RedHat Directory server is
> official support
> (and at the prices I was quoted per year, for two servers, I could hire
half a
> person, although academic pricing wasn''t available at the time :)
> 
> The situation I''m in is one where I have an aging directory
infrastructure,
> going all the way back to the days when the Directory Server was branded
with
> the Netscape brand :)  Its been on my TODO list to upgrade to something,
for
> the past two years, but I never got around to migrating to OpenLDAP, for a
> number of reasons.  With the release of RedHat/Fedora Directory Server, it
was
> a matter of installing it, adding a few schema modifications, exporting
data
> from the old server, and importing into the new.  Simple as pie. 
I''ve been
> running with that in a test environment for a month, no problems.  And
I''m
> ready to plan out a full scale conversion and setup multimaster
replication.
> 
Hi Kevin,

I am using OpenLDAP in our environment. I''ve been thinking to migrate
FDS.

I was wondering how FDS compares with OpenLDAP in terms of performance.

If you don''t mind me asking how big is your current LDAP
infrastructure in terms of entries and number of connections/sec.? How
well your test FDS performs compare to your current LDAP server?

I would appreciate your input.

Thanks.
Sam

Sam Tran wrote:
>On 7/8/05, Kevin Myer <kevin_myer@iu13.org> wrote:
>  
>
>>If I can piggyback off of this question and ask another: advantages of
using
>>RedHat Directory Server vs. Fedora Directory Server?
>>
>>The only thing I can see we get with RedHat Directory server is
>>official support
>>(and at the prices I was quoted per year, for two servers, I could hire
half a
>>person, although academic pricing wasn''t available at the time
:)
>>
>>The situation I''m in is one where I have an aging directory
infrastructure,
>>going all the way back to the days when the Directory Server was branded
with
>>the Netscape brand :)  Its been on my TODO list to upgrade to something,
for
>>the past two years, but I never got around to migrating to OpenLDAP, for
a
>>number of reasons.  With the release of RedHat/Fedora Directory Server,
it was
>>a matter of installing it, adding a few schema modifications, exporting
data
>>from the old server, and importing into the new.  Simple as pie. 
I''ve been
>>running with that in a test environment for a month, no problems.  And
I''m
>>ready to plan out a full scale conversion and setup multimaster
replication.
>>
>>    
>>
>
>Hi Kevin,
>
>I am using OpenLDAP in our environment. I''ve been thinking to
migrate FDS.
>
>I was wondering how FDS compares with OpenLDAP in terms of performance.
>  
>
They are similar, especially when using recent versions of OL (2.2.24 or 
later) with the back-bdb (BDB 4.2.52 + patches).  It seems that the 
default configuration (and auto-configuration functions) with FDS make 
it easier to get good performance "out of the box".  OpenLDAP requires
a
bit more digging and tweaking.  I would say that there is no reason to 
choose one over the other strictly on performance alone - both servers 
are "fast enough" for almost any application.
>If you don''t mind me asking how big is your current LDAP
>infrastructure in terms of entries and number of connections/sec.? How
>well your test FDS performs compare to your current LDAP server?
>
>I would appreciate your input.
>
>Thanks.
>Sam
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users@redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  
>

Quoting Sam Tran <stlist@gmail.com>:
> I was wondering how FDS compares with OpenLDAP in terms of performance.
Well, its faster, in our case (and I say that tongue-in-cheek).  Our current
primary directory server is running on a dual 168Mhz Ultra 2 Sun box.  And our
secondary is a Sparcstation 10, at a whopping 70Mhz :)
> If you don''t mind me asking how big is your current LDAP
> infrastructure in terms of entries and number of connections/sec.? How
> well your test FDS performs compare to your current LDAP server?
Its a small installation, maybe 10,000 entries, but that services our own
organization, as well as 22 school districts, each in separate trees.  But per
above, there''s really no way I can provide an accurate comparison
between the
current and anything else, other than to say its faster.
> I would appreciate your input.
Factors that go into my decision (and I use Fedora loosely, to describe my
experience and observations with Netscape/Sun/iPlanet products generally):

Cost (its a wash between OpenLDAP vs. Fedora DS)
Manageability (hands down Fedora, simply because I''m familar with the
Netscape
management infrastructure)
Scalability (my guess is Fedora, based on the size of installations 
that are out
there)
Availability (Fedora - no proven multimaster support in OpenLDAP)
Ease of migration (Fedora - an upgrade to OpenLDAP meant refactoring 
all ACL''s,
massaging attributes and objectclasses, etc.)

Kevin

-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org

On 7/8/05, Kevin Myer <kevin_myer@iu13.org> wrote:
> Quoting Sam Tran <stlist@gmail.com>:
> > I was wondering how FDS compares with OpenLDAP in terms of
performance.
> 
> Well, its faster, in our case (and I say that tongue-in-cheek).  Our
current
> primary directory server is running on a dual 168Mhz Ultra 2 Sun box.  And
our
> secondary is a Sparcstation 10, at a whopping 70Mhz :)
> 
> > If you don''t mind me asking how big is your current LDAP
> > infrastructure in terms of entries and number of connections/sec.? How
> > well your test FDS performs compare to your current LDAP server?
> 
> Its a small installation, maybe 10,000 entries, but that services our own
> organization, as well as 22 school districts, each in separate trees.  But
per
> above, there''s really no way I can provide an accurate comparison
between the
> current and anything else, other than to say its faster.
> 
> > I would appreciate your input.
> 
> Factors that go into my decision (and I use Fedora loosely, to describe my
> experience and observations with Netscape/Sun/iPlanet products generally):
> 
> Cost (its a wash between OpenLDAP vs. Fedora DS)
> Manageability (hands down Fedora, simply because I''m familar with
the Netscape
> management infrastructure)
> Scalability (my guess is Fedora, based on the size of installations
> that are out
> there)
> Availability (Fedora - no proven multimaster support in OpenLDAP)
> Ease of migration (Fedora - an upgrade to OpenLDAP meant refactoring
> all ACL''s,
> massaging attributes and objectclasses, etc.)
> 
> Kevin
> 
> --
> Kevin M. Myer
> Senior Systems Administrator
> Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org
> 
> 
> --
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> 
Thanks Rich and Kevin for your input.

As far as I am concerned the management console and the multimaster
replication would be the two main advantages of FDS.

However according to that paper multi-master replication could lead to
inconsistencies:
http://www.watersprings.org/pub/id/draft-zeilenga-ldup-harmful-02.txt

What do you think?

Thanks.
Sam

Sam Tran wrote:
>On 7/8/05, Kevin Myer <kevin_myer@iu13.org> wrote:
>  
>
>>Quoting Sam Tran <stlist@gmail.com>:
>>    
>>
>>>I was wondering how FDS compares with OpenLDAP in terms of
performance.
>>>      
>>>
>>Well, its faster, in our case (and I say that tongue-in-cheek).  Our
current
>>primary directory server is running on a dual 168Mhz Ultra 2 Sun box. 
And our
>>secondary is a Sparcstation 10, at a whopping 70Mhz :)
>>
>>    
>>
>>>If you don''t mind me asking how big is your current LDAP
>>>infrastructure in terms of entries and number of connections/sec.?
How
>>>well your test FDS performs compare to your current LDAP server?
>>>      
>>>
>>Its a small installation, maybe 10,000 entries, but that services our
own
>>organization, as well as 22 school districts, each in separate trees. 
But per
>>above, there''s really no way I can provide an accurate
comparison between the
>>current and anything else, other than to say its faster.
>>
>>    
>>
>>>I would appreciate your input.
>>>      
>>>
>>Factors that go into my decision (and I use Fedora loosely, to describe
my
>>experience and observations with Netscape/Sun/iPlanet products
generally):
>>
>>Cost (its a wash between OpenLDAP vs. Fedora DS)
>>Manageability (hands down Fedora, simply because I''m familar
with the Netscape
>>management infrastructure)
>>Scalability (my guess is Fedora, based on the size of installations
>>that are out
>>there)
>>Availability (Fedora - no proven multimaster support in OpenLDAP)
>>Ease of migration (Fedora - an upgrade to OpenLDAP meant refactoring
>>all ACL''s,
>>massaging attributes and objectclasses, etc.)
>>
>>Kevin
>>
>>--
>>Kevin M. Myer
>>Senior Systems Administrator
>>Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org
>>
>>
>>--
>>Fedora-directory-users mailing list
>>Fedora-directory-users@redhat.com
>>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>
>>    
>>
>
>Thanks Rich and Kevin for your input.
>
>As far as I am concerned the management console and the multimaster
>replication would be the two main advantages of FDS.
>
>However according to that paper multi-master replication could lead to
>inconsistencies:
>http://www.watersprings.org/pub/id/draft-zeilenga-ldup-harmful-02.txt
>
>What do you think?
>  
>
I think Kurt Z. is correct.  Any loosely consistent replication model 
can lead to inconsistencies - including OpenLDAP single master 
replication.  I won''t go into too many details, but if you really want 
to know about different replication consistency models, read this - 
http://www2.parc.com/csl/projects/bayou/pubs/uist-97/Bayou.pdf

In general, the only way to ensure absolute consistency is to use 
something like two phase commit, used by some RDBMS products.  In this 
case, your write operation does not return a response until that write 
operation has been successfully propagated to all systems in the 
replication topology (or rolled back from all in the case of failure).

There is no way for any LDAP loosely coupled replication to guarantee 
"read your writes" consistency.  As an example, consider a single
master
case with one or more read only replicas.  End user clients will 
typically be pointed to one or more read only replicas to use for 
searches for load balancing or fail over purposes.  If the client makes 
a write request, it will typically be sent a referral to the master, 
where the write operation will be performed.  The write operation will 
return immediately to the client, without waiting for that write 
operation to be propagated to the replicas.  If the client immediately 
performs a search request on a replica (which it has been configured to 
do so), that data may or may not be available, depending on the 
replication schedule, speed of the master, write performance of the 
replica, etc., etc.

Any kind of loosely coupled replication breaks ACID:
Consistency - the "view" of the data is different depending on which 
server you talk to
Isolation - the update is visible on the master before it is visible on 
a consumer
Durability - it''s possible that the change could be lost or refused due
to an error condition on a replica

However, Kurt''s document states the following:
>It is noted that X.500 replication (shadowing) model allows for
>  transient inconsistencies to exist between the master and shadow
>  copies of directory information.  As applications which update
>  information operate upon the master copy, any inconsistencies in
>  shadow copies are not evident to these applications.
>  
>
The problem is that no one deploying LDAP follows this model.  As I 
said, people use replicas for load balancing, failover, and data 
locality (e.g. putting a copy of the corporate data in a remote 
office).  Therefore, in almost every LDAP deployment, clients _use_ the 
"shadow copies" directly.  In almost every case, load balancing, 
failover, data locality, "no single point of failure" are the most 
salient concerns of network architects, and absolute data consistency is 
secondary.

Kurt then goes on to give specific examples of where multi master can 
lead to inconsistencies.  In almost every case, the MMR protocol can 
handle the inconsistency in a logical manner, or flag the inconsistency 
for operator intervention (with the operational attribute 
nsds5ReplConflict).

So, knowing that, you have to make your own trade-off between 
convenience and absolute consistency.  MMR gives you the ability to have 
data locality with writes and no single point of write failure, at the 
cost of extra administrative overhead - monitoring, looking for 
conflicts (e.g. search for nsds5ReplConflict=*), and manually resolving 
them.  MMR has been deployed for years (starting in 3/2001 with iPlanet 
DS 5.0), and in the vast majority of cases, data inconsistency just 
doesn''t happen.
>Thanks.
>Sam
>
>--
>Fedora-directory-users mailing list
>Fedora-directory-users@redhat.com
>https://www.redhat.com/mailman/listinfo/fedora-directory-users
>  
>

>However according to that paper multi-master replication could lead to
>inconsistencies:
>http://www.watersprings.org/pub/id/draft-zeilenga-ldup-harmful-02.txt
>
>What do you think?
>  
>
<sigh> Kurt''s views do not represent the majority of the
Directory
Server vendor
community (actually quite the reverse : you will see MMR in products 
from Microsoft,
Novell, IBM and many others).

> -----Original Message-----
> From: fedora-directory-users-bounces@redhat.com 
> [mailto:fedora-directory-users-bounces@redhat.com] On Behalf 
> Of Sam Tran
> Sent: Friday, July 08, 2005 10:59 AM
> To: General discussion list for the Fedora Directory server project.
> Subject: Re: [Fedora-directory-users] Advantages of using FDS 
> vs OpenLDAP?
> However according to that paper multi-master replication could lead to
> inconsistencies:
> http://www.watersprings.org/pub/id/draft-zeilenga-ldup-harmful-02.txt
> 
> What do you think?
Well, the paper is not wrong - MMR is not an atomic write model (everything
in that draft stems from this fact), rather it is a loosley consistent one.
However that doesn''t mean that MMR is not right for your deployment. 
You
must consider how likely those problems are to turn up in your deployment,
how much that will matter, and how easily and quickly you can recover from
them - only you can answer that.

Balance the issues raised in that draft versus having only one master, which
means a single point of write failure without any write load balancing.  In
many (most?) larger deployments (and even small distributed ones) these
advantages far outweigh any issues that arise from lack of MMR lack of
atomicity.

To address some of those points directly:

4.2 allocation serial numbers

True the delete/add value trick to ensure atomicity of serial numbers does
fall down.  But nobody says you have to keep the entry in the replicated
portion of the dit (or in other words, the same entry), with just a little
admin overhead it should be simple enough to manually partition the
uidNumber space between servers - 4 billion possible values ought to provide
enough partition space such that it can be done once and forgotten about.

4.3 Allocation of single-valued authority information

A rehash of 4.2 but an example where the work around for 4.2 won''t
work.  I
wonder how many real world applications really do this though.

4.4  Entry resurrection

Actually I agree with this.  It has been something I have argued vigourously
against (and failed) in the past.  MMR still obeys the order of events of
operations (eventually) just like a single server for all operations EXCEPT
for delete which it will _reverse_, all other operations if replayed on a
single server will result in the entry ending up the same.  I called them
the undead entries.  Though Kurt does not raise the issue, I consider this a
security risk too.  Imagine a deployment where employees can update certain
attributes of their entry.  A simple script could keep a fired employee
entry from getting deleted (though _I hope_ that deployments use the account
inactivation features in such situations - you see my point.)

Bryan wrote:
> This question is probably completely obvious to those more versed in  
> LDAP, which I am not.  And since I couldn''t find an answer to this
in
> the Wiki, I thought that it didn''t hurt to ask.
> 
> So what are the advantages of using a "specialized" LDAP server,
> whether Fedora/Red Hat Directory Server, Apache Directory, Open  
> Directory, etc., versus using just OpenLDAP?  Increased  functionality?  
> Heightened and more security measures?

Fedora Directory Server was called Netscape Directory Server until just 
recently. It was the first LDAPv3 server in the world, afaik. The code 
was commercially developed and tested for ~8 years and has been in use 
in large scale deployments all over the world for a long time. It has 
contained features for many years which OpenLDAP project is just now 
considering, e.g. multi-master replication, ability to alter the 
configuration of the running server via LDAP, in-tree access control, etc.

Fedora is not what I would call a "specialized" LDAP server,
it''s just a
full-featured, standards based, general purpose, high quality LDAP 
server. OpenLDAP is, in contrast, very specialized, having a lot of 
different types of backends in the recent versions. You can do some 
really tricky stuff with OpenLDAP that you can''t do with Fedora, if you
need that sort of tricky stuff in your architecture.

And the main difference for a new person like yourself is the amount of 
available documentation. Fedora is professionally and extensively 
documented, whereas OpenLDAP documentation is very scarce and terse.


Mike

-- 
LDAP Directory Consulting - http://www.netauth.com

Pete Rowley wrote:
>Balance the issues raised in that draft versus having only one master, which
>means a single point of write failure without any write load balancing.
>  
>
Just curious: I see this "write load balaincing" issue coming up all 
times; if I have, say, 2 MMasters, does it mean that each one gets 
(roughly) half the write operations?  What about the other half to get 
in sync within each other?

p.


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497

Pierangelo Masarati wrote:
> Pete Rowley wrote:
> 
>> Balance the issues raised in that draft versus having only one master, 
>> which
>> means a single point of write failure without any write load balancing.
>>  
>>
> 
> Just curious: I see this "write load balaincing" issue coming up
all
> times; if I have, say, 2 MMasters, does it mean that each one gets 
> (roughly) half the write operations?  What about the other half to get 
> in sync within each other?
Hi Pierangelo,
  The fact that LDAP directory servers are not intended to support a 
high frequency of write operations means that the term "write load 
balancer" is not the correct term to use when describing the benefits of 
multi-master versus single-master replication - unless you are arguing 
how to support systems architects who intentionally (or perhaps out of 
ignorance) use LDAP technology in an incorrect manner in their designs. 
The correct term to use in this context, IMO, is "highly available write 
operations".

  If you want to balance operations, then of course you need to use a 
load balancer. When you use single-master replication, it means that 
even if you use a load balancer, write operations are still not highly 
available, e.g. they can not be performed if the master is down.

  The key benefit of multi-master replication is that _all_ of the LDAP 
operations _can_ be made highly available, and that applications which 
need to write something ASAP (think disabling a user''s account) should 
never fail or be postponed as long as there is either a front-end load 
balancer, or clients which can use a failover list of LDAP server names.

  The key failure of the single-master replication model is that it 
(currently) does not stand up in a highly available system design. If 
there were some sort of automatic promotion of replica to master feature 
that worked well, then it would certainly be a viable alternative to 
using MM replication within a single geographical location / directory 
partition.

  IMO, the usage of MM replication is most suited for DIT designs which 
span across wide area networks with subtree replication across a set of 
"international masters", where it unfortunately has not worked very
well
at all due to it''s design. The recent version of FDS/RHDS is supposed
to
address this issue via the use of a "sliding window algorithm", and 
subtree replication support was included already in NDS 6.21.

  So, how about implementing automatic promotion of slaves to master 
status, so that single-master environments can be made highly available? 
This is a generic problem, and applies to both FDS and OL. Do you think 
it''s a good idea or not?

Mike

--

LDAP Directory Consulting - http://www.netauth.com

> So, how about implementing automatic promotion of slaves to master 
> status, so that single-master environments can be made highly 
> available? This is a generic problem, and applies to both FDS and OL. 
> Do you think it''s a good idea or not?
I say bad idea. Implementing a promotion mechanism that can be relied upon
turns out to be hard, possibly as hard or harder than MMR. And you
end up with all the consistency issues of MMR anyway. Best to bite
the bullet and implement MMR. Thankfully this was done many years
ago and we can reap the rewards today.

If the goal is to acheive tight consistency then simply do not use
a Directory Service : use a RDBMS or some other thing that
is designed to deliver it.

Quoting Mike Jackson <mj@sci.fi>:
> Hi Pierangelo,
>  The fact that LDAP directory servers are not intended to support a 
> high frequency of write operations means that the term "write load 
> balancer" is not the correct term to use when describing the benefits 
> of multi-master versus single-master replication - unless you are 
> arguing how to support systems architects who intentionally (or 
> perhaps out of ignorance) use LDAP technology in an incorrect manner 
> in their designs. The correct term to use in this context, IMO, is 
> "highly available write operations".
I thought that more accurately describes it as well.  And my approach would be
to have a "primary" master and a "secondary" master.  Throw
all your writes at
your primary master and if they all go through there, no need to worry about
consistency.  In the event of a disaster, the secondary master is quite 
capable
of taking the writes as well and keeping things running.  This is almost akin
to your master/promotable slave concept, except the promotable slave is not
really a slave but a standby master.  If you''re concerned about load,
throw in
a bunch of slaves that are read-only and point your read-only lookups at the
slaves, reserving your masters for applications that need write access.

End result - highly available write operations, that minimize consistency
issues.  Highly available read operations.  It requires intelligent 
design of a
directory infrastructure, as you note - sometimes I think we expect 
software to
design that too :)

Kevin

-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org