any concern on persistent search through a load balancer?
We have access manager 7 installed which make use of persistent search. My understanding is that persistent search required to maintain a connection so that the server can refresh/update the client whenever entry in the result set changed. If we configure the system to connect to ldap through load balancer, will that cause any problem? What will happen if the load balancer refresh connection after a period of time? Or , if the original ldap server failed and the load balancer try load balance the client to another ldap server, will the persistent search still works?
Also, if the ldap server that the persistent search initially established connection with crashed, will the client get error message and in that case, is it the client's responsibility to re-run/retry the persistent search with other failover ldap server?
Thanks,
[856 byte] By [
612158a] at [2007-11-27 7:38:32]
# 1
If a persistent search goes through a load balancer, it is very likely that the connection will be cut by the LB. AM will re-establish the persistent connection, but overall it does create a waste of resources.
If an LDAP server goes down, the connection and Psearch need to be redone. It cannot just be resumed from another server.
Persistent searches can have an option to first return entries that matches the filter, and then return entries that are being changed.
A client application using persistent search can be smart enough to remember the last modification time stamp of the last entry received, and use it to resume a persistent search to the same or another server.
Regards,
Ludovic.
# 2
Given the waste of resources due to re-establish of persistent connection, is it recommended / good practice to have AM access ldap thru' LB?
When AM re-establish the connection, does it redo the whole psearch as it is doing it the first time or it is doing it the smart way as you described?
Thanks again
# 4
Your best bet, even when using a hardware load balancer, is to front your DS instances with a pair of load-balanced Directory Proxy Servers. This way, you have physical redundancy at the load balancer level, and intelligent LDAP-aware load balancing at the proxy server level. DPS 6 is very nice in that you can split binds, searches, and updates amongst several backend DS instances, and the connection state is maintained by the proxy, not the DS instance (i.e. if an instance fails, you really shouldn't be forced to rebind, the proxy fails-over to another DS for searching).
We have our Directory Servers on a pair of Solaris 10 systems, each with a zone for a replicated Master DS, and another zone each for a DPS instance. The DPS instances are configured to round-robin binds/searches/updates/etc. among the DS master zones. This works out very well for us.
