IDR with round robin?

[JOHNMILLER2]

Hi,

When deploying 2 or more IDRs in a cluster without a load balancer, can DNS round robin be used to direct users to the SSO agent?  Will the keychain be replicated? Also, will this work for SAML SPs to contact an IDR?

I understand that RR can be used by AM to connect to an IDR by using the host file.

I'm just wondering how much redundancy can be obtained without a load balancer.

Thanks.

[LyndalK · Accepted solution]

Hi John,

  great question!  DNS round robin is not supported, because IDRs have specific Load Balancer Requirements, that DNS round robin does not satisfy.

Examples of some DNS round robin drawbacks are:

• client-side address cache-ing is unknown by the DNS and unpredictable, so DNS round robin cannot properly balance loads.
• From an IDR standpoint, session persistence cannot be guaranteed if a client re-issues a DNS query before the authentication session has expired.  The "session" in "session persistence" refers to a user's authentication session which is independent of any underlying network connection.  Authentication session lifetime is typically much longer than a "network" connection (e.g. a TCP or TLS session) and an authentication session may incorporate multiple concurrent network connections.
• the standard DNS protocol does not check for server outages, so DNS round robin itself cannot ensure IDR high availability.   There are some DNS servers that have additional functionality outside of the DNS protocol to improve high availability, e.g.  poll IPs in a round robin list and temporarily remove those that don't respond from the list.  That would help with HA to a certain extent, but DNS round robin still would not meet all load balancing requirements.

regards

Lyndal

[JOHNMILLER2]

Thank you Lyndal.

[JOHNMILLER2]

Hi, Thanks for the reply. 

I want to make sure I'm clear, I'm trying to make sense out of this article:

Clusters 

From what I understand I would NEVER deploy more than one IDR in a Cluster without a Load Balancer. Is this correct? 

Therefore:

No supported load balancer = single IDR deployment, single point of failure for Enterprise connector and SSO Agent?

Thank you.

[LyndalK]

Hi John,

  With no load balancer, you can still avoid single point of failure by configuring two IDRs in a DR architecture as follows:

• IDR1 would be your usual production/active IDR and all applications would be directed to it only, via DNS.
• IDR2 would be a standby.  If IDR1 fails, IDR2 takes over when DNS is altered to direct requests to IDR2 instead of IDR1.  Your DNS may have the feature to do this automatically when IDR1 stops responding.

You would typically place each IDR in its own cluster (e.g. IDR1 in an active cluster and IDR2 in a standby/DR cluster) although that is not mandatory.  It is useful to have separate clusters if you think you may add additional IDRs and a load balancer later  - see section "SSO Agent Multicluster Deployments" at the bottom of the Clusters page for the options.

Notes:

• One IDR must be able to handle the peak production loads
• For faster failover, it is best to keep the standby IDR running as a "hot" standby, so it will automatically always be up-to-date with configuration changes and software updates.  Software updates should be done in a timely manner, to avoid issues and possibly the need to reinstall an IDR if it gets too out of date (only the current and 1 previous version of IDRs are supported).
• If you use HTTP Federation and are planning to have multiple IDRs in a cluster, you need to be aware of the quorum rule.  Information about quorum is on the Clusters page you were reading (section "Cluster Status in SSO Agent Deployments"). This means that with 2 IDRs arranged in the above DR architecture, the active and standby IDRs should each be in their own cluster.
• Deploying IDRs in separate clusters is very straightforward.  It is just a matter of defining the additional cluster(s) in the Cloud Administration Console, and when you add an IDR, specifying which cluster it should belong to.
• Deployment and user performance factors should be considered as well when choosing an architecture.  These are explained in more detail in the RSA SecurID Access SSO Agent Performance and Scalability Guide. 

To discuss the best architecture, taking into consideration your organization's specific needs, we recommend having a discussion with RSA Sales.  To get in touch with an RSA Sales SecurID Access specialist, you can use this form .