Add or Delete a Cluster

[#1]

You can group multiple identity routers into clusters to enable high availability features, such as session replication, load balancing, and keychain synchronization.

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. The following features are also managed within clusters:

• Built-in RADIUS server to enable RSA SecurID Access authentication for users who access protected networks through RADIUS-capable devices.

• SSO Agent to enable RSA SecurID Access as your company's single sign-on (SSO) service.

Note:  Cluster features related to high availability and SSO are not supported for identity routers that are embedded in RSA Authentication Manager. These identity routers are also not included in quorum calculations.

For more information, see:

• Cluster Overview

• Add a Cluster

• Delete a Cluster

​Cluster Overview

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. For more information, see:

• Cluster Status in SSO Agent Deployments

• SSO Agent High Availability Features

• SSO Agent Keychain Synchronization

• SSO Agent Intracluster Session Replication

• SSO Agent Multicluster Deployments

​Cluster Status in SSO Agent Deployments

In an SSO Agent deployment, clusters automatically transition between two operational states, quorum and read-only, depending on how many identity routers in the cluster are fully functioning.

Cluster Status	Description
Quorum	A cluster is in quorum when more than 50% of its identity routers can communicate with each other. Users can authenticate through the cluster. Users who authenticate to HTTP Federation applications can create or modify user profile data (application sign-in credentials).
Read-only	A cluster is read-only when 50% or more of its identity routers do not allow users who access HTTP Federation applications to create or change user profile data. These users receive an error message if they try to set application-specific sign-in credentials. Users can still authenticate to all identity routers in the cluster and access HTTP Federation applications. Note:  Read-only status does not affect your ability to administer the cluster or make configuration changes. You can still use the Cloud Administration Console to update your deployment when a cluster is read-only.

The following example illustrates how quorums are calculated.

Total Identity Routers in Cluster	Identity Routers Down	Cluster Status
2	0	Quorum (fully operational)
2	1	Read-Only
2	2	Unavailable (offline)
3	0	Quorum (fully operational)
3	1	Quorum (fully operational)
3	2	Read-Only
3	3	Unavailable (offline)

You can configure a third-party monitoring service to query any identity router in the cluster using the status servlet running on https://<identityroutermanagementIP><:port>/status/v2, where:

• <identityroutermanagementIP> is the identity router management IP address

• <:port> is :9876 for identity routers in the Amazon cloud and not required for on-premises identity routers.

The status servlet reports ClusterStatus.readOnly=false for quorum, and ClusterStatus.readOnly=true for read-only.

Note:  Alternatively, you can use http://<identityroutermanagementIP>:8080/status/v2. 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.

If High Availability is enabled for the cluster, you can also access the status servlet through the portal interface using the following URLs:

Portal Interface URL	Returns
https://<portal hostname>/status/v2/lbstatus	OK
https://<portal hostname>/status/v2	Full component-level status

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

For details on the servlet status report, see Identity Router Status Servlet Report.

​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 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, see Configure High Availability for Cloud Administration Console Deployments

You can add a cluster without enabling high availability, but the capabilities of the cluster will be severely restricted. If a cluster contains only one identity router, it is not necessary to enable high availability, because a single identity router cannot support high availability features.

Note:  You must enable high availability if you deploy FIDO authenticators and the cluster contains more than one identity router.

​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 for the cluster, and each time changes are published within 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.

​Add a Cluster

Procedure 

1. In the Cloud Administration Console, click Platform > Clusters.
2. Click Add a Cluster.
3. In the Name field, enter a name to identify the cluster.
4. (Optional) To enable RADIUS, select the Enable the RADIUS service on all identity routers in this cluster checkbox.

   

Note:  Enabling RADIUS for a cluster automatically opens RADIUS UDP port 1812 in the firewall settings for all identity routers in the cluster.

5. (Optional) If you are using RSA SecurID Access for SSO, select the Enable the SSO Agent on all identity routers in the cluster checkbox.

   

   If you are using a third-party SSO service or are not using SSO, ensure that the checkbox is cleared.

   Note:  Enabling the SSO Agent automatically opens the TCP ports 80 and 443 on the identity router. For on-premises identity routers, these ports are opened on the portal interface. If you used the SSO Agent and then clear this checkbox, these ports are disabled along with other ports on the identity router that were enabled when you added applications for SSO.

6. (Optional) To enable high availability features for the SSO Agent, do the following:
   1. In the High Availability section, click Enabled.
   2. (Optional) Select Intracluster Session Replication to enable replication of user sign-in sessions among identity routers in the cluster.

   3. In the Load Balancer DNS Name field, enter the Load Balancer DNS Name value specified for this cluster in your Quick Setup Guide.

      Note:   If your deployment uses FIDO authenticators, you must use the same Load Balancer DNS Name for all clusters.

7. Click Save and Finish.
8. (Optional) Click Publish Changes in the top menu bar if you want to activate the changes immediately. Otherwise, changes accumulate and are published during the next publish operation.

After you finish 

• Assign identity routers to the cluster by selecting the cluster name when adding or editing identity routers.
• (Optional) To populate the identity routers in the new cluster with user profiles and keychains, restore a backup from an existing cluster to the new cluster. For more information, see Back Up Now for a Single Cluster and Restore a Backup for a Cluster.

​Delete a Cluster

You can delete a cluster to remove it from your deployment. Delete clusters using the Cloud Administration Console.

When you delete a cluster, all features and functions provided by that cluster become unavailable. If your deployment requires load balancing between identity routers, session replication, keychain synchronization, or other cluster functionality, you must configure other clusters to provide the necessary capabilities.

Before you begin

The cluster you delete must not be associated with any identity routers. Delete the associated identity routers, or edit them to assign them to other clusters using the Identity Routers page of the Cloud Administration Console.

Procedure 

1. In the Cloud Administration Console, click Platform > Clusters.
2. From the drop-down menu to the right of the cluster you want to delete, select Delete Cluster.
3. Click Delete.
4. Click Publish Changes to apply the configured settings.

Previous Topic:Manage Access Policies

Next Topic:Cluster Relationships

You are here

Table of Contents > Clusters, High Availability, and Backups > Clusters