05 March 2007 - 13:22Sun 6.0: Multi Master Thoughts
Neil Wilson on Sun's new 6.0 release. Clever title. Thought-provoking piece. I'll let the smart ones in the group play with the potential flaws in this logic.
We've been waiting for the rumored 6.0 and congratulate them for getting it out. Now we'll all be able to see what's been behind the curtain and factor any innovations into our collective thinking.
Maybe Symas Labs, our vast research center in a secret location in the southern hemisphere so secret we don't even know where it is or how to contact it will send us some good benchmark data on all this.
four comments:
The reasons that SunDS has needed multiple servers are not the same reasons why we recommend multiple servers. I.e., the performance of a single SunDS server has been slower than OpenLDAP’s since OpenLDAP 2.1. (Our experience at Stanford indicated the difference was more than a factor of 20:1 for their workload…) Where they need multiple servers to handle a given workload, we can do the same job with one. So the only real concern for us is with high availability and eliminating single-point-of-failure concerns. And our track record in heavy use deployments is that the OpenLDAP server is never the reason for any downtime – it’s either hardware failure or unrelated software upgrades. Yes, you have to cover all your bases to eliminate single-point-of-failure, but unlike other products, it’s not because our software is unreliable.
Binary copy to duplicate a server is pretty inelegant to begin with, and given the multiple architectures that are prevalent in most deployments, they’re a non-starter. OpenLDAP Syncrepl lets you duplicate servers entirely through LDAP, which means the duplication is inherently architecture-independent. True, we still rely on architecture-dependent executables, but that can be managed as well.
Password policy – this has been and remains a thorny issue, with or without multimaster replication. Neil’s post is still written from the LDAP perspective of a directory being a single contiguous, homogeneous namespace. This misses the reality that X.500 more adequately addresses – in an information system that is widely distributed, not all of the data is relevant to all points of the system, and not all of it is owned by a single administrative entity. Depending on a site policy, login failures may be a distributed concern but they are more commonly a node-specific issue. The real issues are pretty complex and are still unresolved in the Password Policy draft. The simple ability to replicate password policy state is not a silver bullet.
re: clients modifying read-only replicas – this hasn’t been a concern for years, since we can configure replicas to chain modifications to the master transparently. There is still the question of clients trying to immediately read back what they wrote, but that’s why we support the PostRead control. Also it strikes me that any client that needs to do this is ill-conceived to begin with, but we support it nonetheless.
re: write performance – nonsense. It is possible that if you have many servers and only a single writing client, that spreading its writes across multiple servers will be faster. Of course if the writes are serially dependent then you can’t do that anyway. But when the number of writers is greater than or equal to the number of servers, the aggregate throughput stops increasing. Since it’s very rare for a multi-server deployment to have only a single writer active, you’re still better off to have a single write-optimized server that distributes updates to other read-optimized servers.
read vs write latency – yes, even with write chaining the write latency will include an extra network hop. That’s a fair point. Any time you have to talk to multiple servers in order to service a request, you’re going to pay a latency cost. (Which is one reason that giant monolithic servers are still preferable to distributed clustering approaches for very large directories…) But given the speed of networks vs disk I/O, it’s still likely that chaining to a write-optimized master will be faster than writing locally. It all depends on how many indices need to be updated along with the main write operation.
re: logging – since the OpenLDAP accesslog writes to any LDAP database, you can keep logs resident on the server or direct them to a remote server, or both, or whatever combination you desire. No big deal.
At this point we have N-way multimaster support already, so it’s now just a question of choosing the setup that makes sense for a given deployment. Read-only servers are still the sensible solution for public-facing, sanitized data. Etc…
See, I told you the smart ones would speak up!
Multi-master deployments are superior to master-slaves. Multi-master implementations can scale vertically and horizontally to a far greater extent that single-master. Oh, and of course all multi-master implementations are not created equal.
Also, how do you replace the single-master’s hardware with NO DOWNTIME?
On performance, it has been my experience that almost every server implementation is able to beat someone other server implementation at some specific query or function. The reality is that most modern LDAP servers are fast enough for most LDAP operations; certainly the in the smaller entry counts.
-jim
@Jim Willeke:
Jim, you raise points that deserve some responsible comment. I am particularly interested in addressing the point about how you replace the single-master’s hardware with NO DOWNTIME! We agree that most modern LDAP servers are fast enough for the smaller entry counts, by the way, which makes most of this discussion interesting only to the top few percent of LDAP directory users … but what the heck, it’s our little corner of the world and our couple of percent 
... marty
No trackbacks: