WebSphere Portal Server V6.0.x introduced support for multiple LDAP directory servers with respect to new multi-realm capabilities. Not surprisingly, this has lead to some confusion when deploying multiple LDAP directory servers in response to the requirements of high-availability. As such, when multiple LDAP directory servers are deployed in support of a multi-realm deployment, often used in conjuction with Virtual Portals, these LDAP directory servers need to be highly available in their own right.
For Tivoli Directory Server based implementations, high availability is achieveable through the deployment of two directory servers that operate in a master peer-to-peer topology. However, in a slight deviation from the standard peer-to-peer practice, which works on a concept that there are multiple master peers in an environment each being capable of processing read and write requests, the recommend solution is to utilize a load balancer to preference one master peer as the active member for all read and write requests. The reason for this decision is to eliminate any potential conflicts that would otherwise result from two-way replication.
As such, the load balancer should be configured to always route read and write requests to the nominated master peer during normal operation. However, should the load balancer detect a failure of the master peer, the load balancer will re-route all requests to the alternate master peer. During write requests, there will be replication from 'node 1' to 'node 2', not the other way round, as there should not be any write requests being distributed across both LDAP servers or peers. It follows that read only requests can be evenly distributed to both peer LDAP servers. This can be achieved by configuring a second load balancer cluster group, with a different virtual host name to make a distinction from the first load balancer cluster group and virtual host name.
Important Note When using LDAP over SSL (LDAPS), care should be taken when utilizing a load balancer as described above. LDAPS not only establishes a JNDI context against the target server, but also implements SSL handshaking between the client and target server (including key
negotiation). Whether the load balancer simply just redirects the SSL connection to the target directory server or whether the SSL connection is terminated at the load balancer, with the load balancer re-negotiating a secondary SSL connection to the target directory server, needs to be decided.
great note, thanks!
ReplyDelete