Clusters

Document created by RSA Information Design and Development on Jul 13, 2016Last modified by RSA Information Design and Development on Sep 15, 2017
Version 18Show Document
  • View in full screen mode
  

A cluster is a group of one or more identity routers. In an SSO Agent deployment, you can group multiple identity routers into clusters to enable high availability features, such as session replication, load balancing, keychain synchronization, and backup.

Every identity router must be part of a cluster. If no clusters exist the first time you add an identity router using the Cloud Administration Console, RSA SecurID Access automatically creates a default cluster and adds the identity router to the cluster. You can edit the name and other parameters for the default cluster or any cluster that you add using the Cloud Administration Console. You can add subsequent identity routers to the default cluster, or to another cluster that you added manually.

 

SSO Agent Cluster Operational Modes

In an SSO Agent deployment, clusters automatically transition between two operational modes, depending on the ratio of total identity routers to functional identity routers within the cluster.
  • Quorum mode - When more than half of the identity routers in a cluster are operational, users can authenticate through the cluster and create or modify user profile data.
  • Read-only mode - If half or more of the identity routers in a cluster become disabled for any reason, users can still authenticate through the remaining identity routers in the cluster, but cannot create or modify user profile data. Users receive an error message if they attempt to set application-specific sign-in credentials.

To check the operational mode of a cluster, you can configure a third-party monitoring service to query any identity router in the cluster using the status servlet running on http://<managementIP>:<port>/status/v2/lbstatus, where <managementIP> is the IP address of the identity router management interface, and <port> is either 443 or 8080. The status servlet reports ClusterStatus.readOnly=false for Quorum Mode, and ClusterStatus.readOnly=true for Read-only Mode.

Note:  Traffic to port 8080 is blocked by the default identity router firewall rules. You must configure a custom firewall rule to access the status servlet on port 8080.

You can achieve optimal balance between resource usage and fault tolerance by configuring clusters with odd numbers of identity routers.

 

SSO Agent High Availability Features

In an SSO Agent deployment, the term "high availability" represents a set of features designed to improve performance, reduce downtime, and resist hardware or network failure by enabling identity routers and clusters to share their status, workload, and user information. You can enable or disable high availability functionality when you add or edit each cluster. You can configure clusters to provide the following high availability features.
  • Load balancing
  • Keychain synchronization
  • Intracluster session replication
  • Multicluster deployments
    • Disaster recovery
    • Geographically Distributed High Availability (GDHA)

Load balancing is a high availability feature that improves identity router response time and reliability during periods of heavy network traffic, when large numbers of users attempt authentication simultaneously. A load balancer directs network traffic among multiple identity routers in a cluster. In a load-balanced cluster, user network traffic does not reach the identity routers directly by their individual host names. Instead, the traffic reaches the load balancer by its DNS name. The load balancer forwards the requests based on the available capacity of each identity router. Load balancing is a prerequisite for all other high availability features. For more information on load balancers, see Load Balancer Requirements.

 

SSO Agent Keychain Synchronization

In an SSO Agent deployment, keychain synchronization is a high availability feature that enables sharing of stored application-specific user credentials among the identity routers in a cluster, or from one cluster to another. If an identity router or cluster becomes unavailable for any reason while keychain synchronization is enabled, users can still authenticate using stored credentials on a separate synchronized identity router or cluster. Keychains are synchronized within a cluster automatically when you enable high availability functionality for the cluster. You configure synchronization between clusters manually using cluster relationships.

For more information, see Cluster Relationships.

 

SSO Agent Intracluster Session Replication

In an SSO Agent deployment, intracluster session replication is a high availability feature that enables sharing of user authentication sessions among the identity routers in a cluster. If an identity router becomes unavailable for any reason while session replication is enabled, users who authenticated to that identity router can continue to interact with web applications through other identity routers in the cluster automatically, without authenticating again. Session replication requires frequent communication among identity routers within a cluster, which can reduce performance in high-traffic environments. When session replication is disabled, users are required to re-authenticate in a failover scenario. RSA SecurID Access does not support session replication between clusters.

 

SSO Agent Multicluster Deployments

RSA SecurID Access supports SSO Agent deployments that use multiple clusters to provide the following high availability features.

 
  • Disaster Recovery - An active cluster in a local data center manages authentication under normal circumstances. You can activate a standby cluster in a remote data center if the primary cluster fails.
  • Geographically Distributed High Availability (GDHA) - Multiple clusters in separate geographic locations manage authentication. A Global Server Load Balancer (GSLB) directs user traffic to the appropriate cluster based on availability and proximity.

Note:  In a multicluster deployment, the load balancers for all clusters must use the same DNS name. DNS directs user traffic to the appropriate cluster.

 

 

Next Topic:Manage Clusters
You are here
Table of Contents > Clusters and Backups > Clusters

Attachments

    Outcomes