LDAP server pool

[cxj]

It is common to have more than one LDAP server, with all servers providing the same data. For example, there may be more than one LDAP server to provide fail-over or backup. Or maybe there are multiple LDAP servers for load balancing or better network latency for an organization which has multiple geographic locations.

In my use of SlapOM, we may have several LDAP servers configured -- a pool of LDAP servers. I could subclass the SlapOM\Connection class, and override the __construct() and connect() methods to enable multiple servers, I think.

But would it make sense to instead include the multiple LDAP server pool capability right in SlapOM? If that seems reasonable, I will create the code and provide Pull Requests for that feature.

Thanks!

[chanmix51]

It would be nice but I have no idea on how to test such feature.

[cxj]

Yes, testing may not be easy. Usually mock objects are used in place of servers for testing. But SlapOM is already the abstraction for the server. I will think about it some more, and do some research to see might help with testing multiple LDAP servers.

[cxj]

I have discovered that the PHP ldap_connect() call can take a space-delimited list of hosts or URLs for LDAP servers to connect to. This is because PHP's ldap_connect() call uses the OpenLDAP C library; see http://linux.die.net/man/3/ldap_open for the C library documentation, and also the user-contributed note by Alexandros Vellis at http://php.net/ldap_connect.

So I think the SlapOM class can work as-is for the simple case of providing more than one hostname. It would be nicer to make the host "pool" feature more obvious. It might also be useful to provide a hook to select a load-balancing or fail-over search order. Perhaps a SlapOM method which provided a default algorithm, which could then be overridden by a user-supplied method would be a good way to allow user-specified search order for multiple LDAP servers.

One simple way to partially test multiple LDAP servers would be to specify the same functioning hostname multiple times, and possibly mix in a completely false server.

$allGoodHosts = "ldap.mydomain.com ldap.mydomain.com ldap.mydomain.com";
$oneBadHost =   "ldap.mydomain.com bad.example.com   ldap.mydomain.com";

[chanmix51]

It is not as trivial as it seems because

Be careful when doing LDAP writes; be sure to always connect to your master host 
when you are about to modify the database, so that the replicates will get the 
changes as expected.

This means we must distinct masters from slaves and be able to select maybe a different server to read and to write.

[cxj]

Yes, I see. That is very important. Testing reads will be simple, but not writes. I was thinking wrongly because in my situation, we only do reads from LDAP using PHP. I will continue to think about how it can be done.