<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Sam Tran wrote: <blockquote cite="midcee681b0050708105952609643@mail.gmail.com" type="cite"> <pre wrap="">On 7/8/05, Kevin Myer <a class="moz-txt-link-rfc2396E" href="mailto:kevin_myer@iu13.org"><kevin_myer@iu13.org></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Quoting Sam Tran <a class="moz-txt-link-rfc2396E" href="mailto:stlist@gmail.com"><stlist@gmail.com></a>: </pre> <blockquote type="cite"> <pre wrap="">I was wondering how FDS compares with OpenLDAP in terms of performance. </pre> </blockquote> <pre wrap="">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 :) </pre> <blockquote type="cite"> <pre wrap="">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? </pre> </blockquote> <pre wrap="">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. </pre> <blockquote type="cite"> <pre wrap="">I would appreciate your input. </pre> </blockquote> <pre wrap="">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 <a class="moz-txt-link-freetext" href="http://www.iu13.org">http://www.iu13.org</a> -- Fedora-directory-users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Fedora-directory-users@redhat.com">Fedora-directory-users@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/fedora-directory-users">https://www.redhat.com/mailman/listinfo/fedora-directory-users</a> </pre> </blockquote> <pre wrap=""> 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: <a class="moz-txt-link-freetext" href="http://www.watersprings.org/pub/id/draft-zeilenga-ldup-harmful-02.txt">http://www.watersprings.org/pub/id/draft-zeilenga-ldup-harmful-02.txt</a> What do you think? </pre> </blockquote> 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 - <a class="moz-txt-link-freetext" href="http://www2.parc.com/csl/projects/bayou/pubs/uist-97/Bayou.pdf">http://www2.parc.com/csl/projects/bayou/pubs/uist-97/Bayou.pdf</a> 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: <blockquote type="cite"> <pre>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. </pre> </blockquote> 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. <blockquote cite="midcee681b0050708105952609643@mail.gmail.com" type="cite"> <pre wrap=""> Thanks. Sam -- Fedora-directory-users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Fedora-directory-users@redhat.com">Fedora-directory-users@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/fedora-directory-users">https://www.redhat.com/mailman/listinfo/fedora-directory-users</a> </pre> </blockquote> </body> </html>