High availability architecture for Identity Manager

This article contains information for WAR file deployment.

Smart ID Identity Manager can be configured as a High Availability (HA) solution in different ways and different scenarios:

Active-passive failover cluster
Active-active load balancer setup
Mix of both

Identity Manager HA setup is mainly used for runtime environment: Identity Manager Operator and Smart ID Self-Service. HA is possible for all clients (for example, Identity Manager Admin and Identity Manager Tenant), but typically for these applications, an HA environment is not necessary. It is assumed (and highly recommended) that the database that Identity Manager connects via JDBC is also HA. How the database HA-setup can look like depends on the corresponding database product in the customer’s environment.

Supported platforms for WAR file deployment installations

For WAR file deployment installations, HA is available on the following OS Platforms:

Windows Server
Linux (setup and available capabilities might differ between the different distributions)

Software Components:

Apache Tomcat 8/9
Apache HTTP Server 2.4 with MOD_JK 1.2, AJP 1.3 for Load balancing

Active-passive failover cluster

The easiest HA setup for Identity Manager is a failover cluster with one active Tomcat and one hot-standby. There are different cluster failover tools available (also for Linux) on the market that works with Identity Manager. The tested, and from Nexus recommended, setup for failover cluster is “Windows Failover Cluster”.

Active-active load balancer setup

In an environment with high workload or huge user volumes, one application server (Tomcat) might be insufficient and potentially would cause system overload or bad reaction times. Therefore the load is distributed on multiple Tomcats via load balancing.

Identity Manager supports load balancing on multiple Tomcats with an Apache HTTP server in front. There are a number of different possible setups for Identity Manager load balancing. It depends on the customers’ requirements and the expected system load on the application which setup is the best.

Examples of some typical scenarios:

Standard load balancer setup

The simplest load balancer setup is shown below.

There are two identical Tomcats for the whole runtime system (Operator and Self-Service).
The Tomcats are load balanced via the Apache HTTP server.
Both Tomcats need to connect via the same JDBC connection to a HA database instance, for example, MS SQL Cluster. It is up to the customer to provide the HA database environment.
Optional add on-modules, for example, PKI connectors, also must be deployed on each Tomcat node and would connect to a (HA) PKI environment from each Tomcat node.

Separated Smart ID Self-Service load balancer setup

The expected system load can be different between Identity Manager Operator and Smart ID Self-Service. Therefore, it could make sense to have these systems separated and also have separate load balancing for Identity Manager Operator and Smart ID Self-Service:

Separate IDM Self-Service load balancer setup

Load balancing with failover cluster

In all load balancing scenarios, as described in Active-active load balancer setup, the Apache HTTP server is a potential single point of failure. Therefore, it is necessary to think about, how this component is also HA. In some scenarios, it could be sufficient to have HA on OS layer, for example, in a clustered VM environment. Another scenario can be to combine failover cluster and load balancer. One approach is to setup a clustered Apache HTTP server, for example, in a Windows failover cluster.

As the following graphic shows, there are two Apache HTTP servers connecting to the same Tomcats. One HTTP server is active, and distributes the request to Tomcat 1 and Tomcat 2, the other one is in hot-standby. As soon as the active HTTP server fails, the second one takes over and goes on serving the two Tomcats with requests.

Additional information

Useful links