Access Management 7.3.2

Deployment architectures

You can deploy CTS token stores in a number of deployment architectures, depending on your system requirements:

CTS affinity deployment

With affinity load balancing for CTS, AM balances request across available DS servers, always routing LDAP requests for the same CTS token to the same directory server. This prevents AM from reading a token before DS has replicated pending changes. Affinity is well suited for deployments with many AM servers.

Configure AM’s Connection String(s) property using the AM admin UI to use server affinity without a load balancer. For more information on the Connection String(s) property, refer to External store configuration.

Learn more about CTS affinity deployments in the Knowledge Base article Best practice for using Core Token Service (CTS) Affinity based load balancing in PingAM.

The connection strings to the data or identity stores are static and not hot-swappable. This means that, if you expand or contract your DS affinity deployment, AM will not detect the change.

To work around this, either:

  • Manually add or remove the instances from the connection string and restart AM or the container where it runs.

  • Configure a DS proxy in front of the DS instances to distribute data across multiple DS shards, and configure the proxy’s URL in the connection string.

CTS site deployment

CTS supports uninterrupted session availability in deployments with multiple sites when all sites use the same globally replicated CTS store. If an entire site fails or becomes unavailable, AM servers in another site detect the failure of the site’s load balancer and attempt to use sessions from the global Core Token Service.

In the event of a failure, client applications can connect to an AM server in an active data center.

A global Core Token Service replicated across two data centers
Figure 1. Global CTS with affinity

For details on DS replication, refer to Replication in the Directory Services documentation.