Just saw your comment on Evan's blog about his QCon presentation and agree. Lots of people are overlooking LDAP and throwing away the excellent implementations out there that are designed for large workloads with powerful replication tools.
Having recently deployed OpenDS for a new service, I noticed an O'Reilly LDAP book on a shelf while visiting a customer. The customer saw this and his immediate response was to ask why we'd consider using such an old standard for our new offering!
We've had a very positive experience with our LDAP deployment after uncertain beginnings. I hope it's served to improve LDAP's reputation internally at least to make it a part of future projects.
lucasrockwell
· 9 months ago
Thanks for the comment. Yes, LDAP is old, and still an amazing technology. Telcos don't use LDAP because they are "legacy" companies, they use it because it is fast and scales wonderfully.
I wish you the best of luck with your current and future LDAP projects!
Jauder Ho
· 8 months ago
What kind of traffic are you seeing on your DS?
I've been a longtime fan of LDAP and have done several deployments. It is interesting to me that none of the web20 companies have used LDAP (that I know of) as part of their architecture.
Imagine, sharding information could easily be kept in the DS (amongst other things) and on a well tested infrastructure.
lucasrockwell
· 8 months ago
We have a 3 node (multi master) + 2 proxy setup that barely gets exercised (like in the high teens requests/second). This is with Sun's DS and proxy 5.2 series.
The real fun I am having right now is working on using OpenDS as a ticket cache (TicketRegistry) for CAS (the JA-SIG single sign on server). My testing today used two OpenDS servers doing an average of 216 write/read/delete operations per second (72 tickets per second going through this 3-stage process). One server would do the initial write, and then replicate the info to the other server where it was read and then deleted. So, it was replicating 72 tickets/second over the network. I actually think it can do a lot more than that.
On Monday I am going to do this for 1M tickets to see how it goes. I will be putting together a paper on it when I am done. I'll post a link to all of that info on this blog once it's ready.
lucasrockwell
· 8 months ago
Yea, it is sad how the web 2.0 crowd doesn't consider LDAP. I downloaded Laconica and took a look at the SQL and it just boggles my mind how they think something like that can scale. I guess when your tool of choice is a RDBMS, every problem starts looking like a SQL query.
The ROFLR
· 6 months ago
lolololololol
The ROFLR
· 6 months ago
But seriously, LDAP's scalability is *not* performance scalability. In a modern key-value store, being unable to handle tens of thousands of operations per second per node would be completely unacceptable.
lucasrockwell
· 6 months ago
I am not sure what you are suggesting... Are you suggesting that LDAP can not handle tens of thousands of operations per second?
On my MacBook, I can get OpenDS 1.3RC6 to do around 7000 requests/second (and this is a Java app). Sun's c-based DS is much faster.
The ROFLR
· 6 months ago
It's not a problem with LDAP itself, but whether or not it can scale out. The cost you end up paying in a distributed LDAP server is for consistency, since LDAP is designed with strong consistency in mind, it would likely need to be (a) completely replicated and (b) require some strong ordering mechanism (like Paxos). It's not a problem of scaling up, it's a problem of scaling out. If you have an example of a scaled OUT LDAP system, I'd be interested in seeing it.
lucasrockwell
· 6 months ago
In my current work we use Sun's LDAP proxy server which allows you to very easily scale out LDAP. For instance, if you have 100M users, you could easily split them up into n clusters (at least 2 LDAP servers -- each a multi-master -- in a cluster) of people (maybe 2-10M per cluster), and then the proxy server (based on the DN) would know where the user is located. Of course, if you didn't know where someone was (because you were not doing a base search using an exact DN) then there is more work involved in finding the person.
All Comments
Having recently deployed OpenDS for a new service, I noticed an O'Reilly LDAP book on a shelf while visiting a customer. The customer saw this and his immediate response was to ask why we'd consider using such an old standard for our new offering!
We've had a very positive experience with our LDAP deployment after uncertain beginnings. I hope it's served to improve LDAP's reputation internally at least to make it a part of future projects.
I wish you the best of luck with your current and future LDAP projects!
I've been a longtime fan of LDAP and have done several deployments. It is interesting to me that none of the web20 companies have used LDAP (that I know of) as part of their architecture.
Imagine, sharding information could easily be kept in the DS (amongst other things) and on a well tested infrastructure.
The real fun I am having right now is working on using OpenDS as a ticket cache (TicketRegistry) for CAS (the JA-SIG single sign on server). My testing today used two OpenDS servers doing an average of 216 write/read/delete operations per second (72 tickets per second going through this 3-stage process). One server would do the initial write, and then replicate the info to the other server where it was read and then deleted. So, it was replicating 72 tickets/second over the network. I actually think it can do a lot more than that.
On Monday I am going to do this for 1M tickets to see how it goes. I will be putting together a paper on it when I am done. I'll post a link to all of that info on this blog once it's ready.
http://blogs.sun.com/directoryservices/entry/45...
or
http://blogs.sun.com/directoryservices/entry/op...
On my MacBook, I can get OpenDS 1.3RC6 to do around 7000 requests/second (and this is a Java app). Sun's c-based DS is much faster.