Re: ldap load measuring and reproduction tools

["J.Smith" <temp201@hotmail.com>]

----- Original Message ----- 
From: "Mike Jackson" <mj@sci.fi>
To: "J.Smith" <temp201@hotmail.com>
Cc: <openldap-software@OpenLDAP.org>
Sent: Sunday, March 13, 2005 11:28 AM
Subject: Re: ldap load measuring and reproduction tools
> Depending on the amount of updates, you might hit a limit when replicating
> to more than 6-8 servers.
Yeah, that was what I was thinking as well. However, I currently lack the
'proof' to convince people of this - which is my primary motivation behind
wanting to do the tests. In order to convince people of this I will need
something more tangible than 'I think it will break'.
;)

> I think that if you need 10-20 replicas, then the architecture and design
> of your directory service is less than optimal.
Personally I agree with you, but the Architects at our site seem to
disagree. The argument that the Architects are making, is that they want to
minimize the impact of badly behaving applications (ldap clients). They want
to prevent that a single application that crashes or overloads the ldap
server, will impacting all of the other applications that use the same ldap
server as well. Simply sizing a single server appropriately is not an
option - no matter how big you size a server, if a badly behaving
application decides to do stupid things or go into a loop it will likely
overload or crash the server no matter how much iron you throw at it. Going
for a Highly-Available active/standby or loadbalanced cluster is probably
not going to solve the issue either for similar reasons. If the BadApp
crashes/overloads the first server, causing a failover to the second server,
it will likely just crash the second server as well. So the design decision
that is currently being made is to just provide one or two ldap replica
servers per 'business domain', department, etc. That way, if one BadApp
crashes/overloads the two replica's in that 'business domain', it will only
impact the applications that are located in that same 'business domain' and
not the other applications in the other 'business domains' which are using
their own dedicated ldap replica's. Also, they do not want the
administrative overhead of having to re-create the same user-accounts in all
of these ' business domains' - so giving each of these domains a seperate
master is not an option, it has to be a replica.


> You can increase overall performance in another way with OL by doing
> subtree synchronization with syncrepl. Synchronize portions of the DIT
> with dedicated servers, e.g. accounts branch to the mail server and to the
> web portal, etc. Configure those high-traffic services to use their local
> copy of the data.
Our tree is pretty flat. We have a o=ourcorp,c=ourcountry suffix which
contains all of the user accounts. When we designed the tree, we
purposefully chose to make it as flat as possible. The primary motivation
behind that decision was that if we would make the tree reflect the
organizational structure, we would be forced to change the tree whenever
there was a major re-organization. Re-organizations are pretty common in our
business, so this was not a realistic design for the tree. And now that some
of our applications are expecting a certain tree layout (yes, that's bad
application design - but it happens in practice nonetheless) we cant change
it anymore without re-designing our applications. So effectively, there
arent any 'portions' or subtree's to replicate - we are forced to replicate
the entire tree to all of our replica's.




Sincerely,


John Smith.