Affinity Load Balancing behind an AWS Network Load Balancer

Tagged: , ,

This topic has 1 reply, 1 voice, and was last updated 4 years, 6 months ago by bmccraw.

  • Author
  • #20689

    Hi 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.


    Finally found confirmation that affinity routing isn’t supported on the userstore backend. Looks like it’s being worked on though.

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?