This topic has 1 reply, 1 voice, and was last updated 4 years, 6 months ago by bmccraw.
-
AuthorPosts
-
January 26, 2018 at 11:05 pm #20689
bmccraw
ParticipantHi everyone,
I’m looking for some help understanding an architectural assumption. We setup OpenAM (v5.5) to communicate with an OpenDS (v5.5) proxy using the affinity load balancing algorithm through an AWS Network Load Balancer (NLB). Behind the OpenDS-Proxy are separate servers for both user and CTS storage on separate baseDNs. The assumption was that no matter how the NLB balanced AM request to the DS-Proxy, as long as the proxy layer contained the same list of backend directory servers hosting the corresponding baseDN, the affinity routing should route all request for the same DN to the same user or CTS storage server.
In practice, we’ve seen issues where OpenAM issues a CREATE for a new user which is followed quickly by a READ for that user which returns a 404 from OpenAM.
We’ve also seen issues where a session has been confirmed deleted, but if an application attempts to re-validate a session token, it’s still active.
Replication is in sync and running quickly (5ms or less), so I do not think this is a replication issue.
The External CTS configuration does have Affinity routing enabled in the OpenAM configuration.If affinity routing was properly routing the DN, then the CREATE and READ commands should be routed to the same backend user store.
Any advice is welcome. Thank you.
February 5, 2018 at 8:38 pm #20810bmccraw
ParticipantFinally found confirmation that affinity routing isn’t supported on the userstore backend. Looks like it’s being worked on though. https://bugster.forgerock.org/jira/browse/OPENAM-12184
-
AuthorPosts
You must be logged in to reply to this topic.