One of my customers encountered policy evaluation failure last week due to a fault with one of their OpenDJ servers.
The Policy Configuration (Access Control ++ / (Top Level Realm) ++ Services ++ Policy Configuration) is seldom in use, unless a LDAP Filter condition is configured in Policies (Access Control ++ / (Top Level Realm) ++ Policies)
I'm trying my luck again today to find out a good HA solution for Policy Configuration.
1) The following instructs all OpenAM nodes to communicate with a single OpenDJ server. This is not ideal.
2) The following will not work.
OpenAM debug log will complain with failed to get LDAP server name. If you enter more than one server name in the policy config service's Primary LDAP Server field, please make sure the ldap server name is preceded with the local server name".
3) For multi OpenAM servers, it is better to distribute the load equally to different OpenDJ servers in the backend. However, of course, this doesn't solve the original high-availability/failover issue.
I'm thinking of having 2 entries of the same local server name, each append with a different OpenDJ server. No luck!
Tested. OpenAM only takes the last entry if multiple identical local server name appear. In the above case, only "am2.cdemo.sg:3389" is mapped to "am2.cdemo.sg" (local server name).
The underlying code is such that a local server name can only return a LDAP SERVER entry.
com.sun.identity.policy.PolicyConfig
com.sun.identity.shared.datastruct.CollectionHelper
Why isn't there a Secondary LDAP Server configuration?
For now, no choice, I think we need a LB in front of the OpenDJ servers.
.
No comments:
Post a Comment