30 September 2006 - 13:18Rant Number 2
I want to think better of Linux Journal but when they publish paid commercial announcements like this as technical content, I have to think less of them.
Sigh, well, I didn't get the original fact-checked the way I should have. Shame on me. Thanks, and apologies to our friends quick to call my hand.
The happy sounding endorsement of the Data Integrity Hole (Defect) challenge lurking in Fedora Directory Server's Multi-Master mode Replication is a dead giveaway that the writer has no appreciation of the requirements of Enterprise Software in mission critical data environments. From the Red Hat Directory Server (RHDS) Administration Guide for RHDS 7.1:
Multi-master replication uses a loose consistency replication model. This means that the same entries can be changed on different servers. When replication occurs between the two servers, the conflicting changes need to be resolved. Mostly, resolution occurs automatically, based on the timestamp associated with the change on each server. The most recent change takes precedence.
However, there are some cases where change conflicts require manual intervention in order to reach a resolution.
In other words, updates are left in this "conflicted" incorrect state and administrators have to run queries, analyze the output, and try to figure out what the correct data. We suspect that the relational database vendors (Oracle, IBM, MySQL) wouldn't get away with that. They would be villified, dragged to the stocks and set up for public ridicule. That simply isn't acceptable for an Enterprise database used for mission critical applications. But in RHDS-land (or Sun JSDS-land), it's a feature and people like this, obviously naively unaware because they've never read the funny manual. Hmmm. so does that mean that our friends are sitting there running queries and reading outputs like hourly?
Multi-master updating without locking and the devastating impact on performance, can not be made Enterprise robust. OpenLDAP has chosen not to introduce such a tempting and dangerous defect feature into its code. Data integrity is a core competency of Database products like OpenLDAP. By choice, it has NOT been a core competency of RHDS or JSDS. It will be interesting, as they attract Open Source developers, to see if Sun's OpenDS elects to introduct the defect.
OpenLDAP addressed the reliability and most of the performance advantages of Multi-master mode. Mirrormode (designed, developed, and contributed by Howard Chu, Chief Architect of Symas) offers hot fail-over capability for the Master Directory Server, the one that's doing all the database modifications (add, update, delete). Working with appropriate LDAP load balancers and system heart-beat monitors, mirromode offers excellent hot standby capabilities for the Enterprise. And mirrormode has NONE of the data corruption replication conflict exposures of RHDS or JSDS. OpenLDAP implemented code in addition to the Berkeley DB transactional integrity support to protect against LDAP data corruption. It simply doesn't get corrupted the way the others still apparently do, according to users who contact us looking for a solution to that problem.
Oh, and OpenLDAP completed a recent monster benchmark running the workload of the optimistic future on a single active Master with a mirrormode Replica. The numbers were stellar. There was headroom available on the platform for bigger faster servers and this was for one of those Enterprise Customers who was quite impressed.
Enough of that rant.
It's clear that RHDS still has a dependence on its administration server (the Directory Server Console), a separate related server. We've seen the emails about the fragility of the administration server and how that's a reliability problem for the Directory Server. OpenLDAP chose to do a lot different, on reflection, when implementing its dynamic configuration engine.
Microsoft Active Directory synchronizaton has been done for OpenLDAP several times. PADL's XAD, rumored to have been purchased by Novell, was one of the more robust approaches. Symas has one, not so nice but effective, if you need it.
So what do we end up with. OpenLDAP is 20% to 50% faster (or more), provably more stable and less expensive, even with Symas's inexpensive support subscriptions. And HP has been kind enough to offer global 9x5 and 24x7 support options for CDS as well. Of course, Symas support (and HP support) provides access to active, full-time directory developers. It's all we do. So, why did Linux World go ga-ga over FDS?
Beats us. ... marty
four comments:
>It’s all part of adopting Berkeley DB which OpenLDAP did
>years earlier than RHDS and JSDS. Ho Hum.
Ho Utter Nonsense !
Berkeley DB (the modern Sleepycat version which we’re discussing here)
was _written_for_ the Netscape Directory Server.
I wrote the code in Netscape Directory Server that talks to
BDB. It used the first private alpha of BDB to be released
outside Sleepycat. OL didn’t use BDB until much later (did
OL even exist in 1996??).
The first rule of ranting is to rant with facts that are actually true.
MMR does not corrupt data and was in fact written as a result of fortune 500 customer requests and has been not only “acceptable” but also required for many many major deployments; I don’t know what you mean by flaky but FDS doesn’t need the admin server to start – it adds a capability to centralize configuration among other things; back-ends – hey it’s true we haven’t added a lot of backends but that doesn’t mean it isn’t possible (in general customers didn’t want it) – the ldif backend you mention is one of them (take a look at how configuration is stored) and I remember fixing bugs in that circa 1997; no restart for configuration changes (or new indexes, schema changes and a host of other things), configuration over LDAP, and Sleepycat BerkleyDB support have a similar story of being long time features which have many years of deployment grade stability. Frankly it does not reflect well that you continue to proclaim the greatness of your solution at the expense of FDS based on features that have long been part of FDS and have only recently shown up in OL.
Well, that was embarassing. Thanks for calling me on that. I learned a bunch of things I probably should have known before I opened my (figurative) mouth. Hopefully the updated post is less hopelessly erroneous.
BTW, mirror mode breaks ACID too, it’s just that it doesn’t even attempt to regain consistency. In other words, it has far less of the functionality of MMR and and doesn’t do as much as MMR in the functionality area it does offer.
No trackbacks: