Understanding the Identity Manager High-Availability Feature Set

Identity Manager is designed to leverage HA infrastructure if it is available. For example, Identity Manager does not require an application server cluster to achieve high availability, but it can utilize a cluster if it exists.

The following diagram shows the major Identity Manager components deployed in a non-redundant architecture. The sections that follow will describe how the Identity Manager repository, application server, and gateway can be made highly-available.

Figure 3–1 Identity Manager Standard System Architecture

See Understanding the System Separation and Physical Proximity Guidelines for information on which components should be physically sited near one another in order to minimize performance issues that could arise due to latency and network congestion.

Making the Repository Highly-Available

Identity Manager stores all of its provisioning and state information in the Identity Manager repository.

The availability of the database instance storing the Identity Manager repository is the most critical piece to achieving a highly available Identity Manager deployment. The repository is the representation of the entire Identity Manager installation and the data within it must be protected as with other important database applications. At minimum, regular backups must be performed.

Do not host the Identity Manager repository on a virtual platform such as a VMware virtual machine because performance (transactions per second) will be hindered significantly.

There can only be one image of the repository. It is not possible to have two separate databases for Identity Manager and attempt to synchronize them nightly. Sun recommends using your database's clustering or mirroring capabilities to provide fault tolerance.

Making the Application Server Highly Available

Identity Manager can run within an application server cluster and take advantage of the added availability and load balancing that a cluster provides. Identity Manager does not use any J2EE features that require clustering, however.

Identity Manager uses the HTTP Session object that is available through the Servlet API. This session object tracks a user's visit as the user logs in and performs actions. In a cluster, you can optionally have multiple nodes handle a user's requests during a given session. This is usually not recommended, however, and most installations are configured to send a user's entire request for a given session to the same server.

It is possible to add additional availability and capacity to the application server running Identity Manager even if you do not set up a cluster. This is achieved by installing multiple application servers with Identity Manager, connecting them to the same repository, and putting a load balancer with session affinity in front of all the application servers.

For more information on session affinity, see Frequently Asked Questions Regarding Session Affinity and Session Persistence.

Identity Manager runs certain tasks in the background—for example, scheduled reconciliation tasks. These tasks are stored in the database and can be picked up by any Identity Manager server to run. Identity Manager uses the database to ensure that these tasks are always run to completion, even if it has to fail over to another node.

Configuring Active Sync Clustering on Application Server Nodes

The sources.hosts setting in the Waveset.properties file controls which hosts in a multi instance environment are used for executing Active Sync requests. This setting provides a list of hosts that source adapters can run on. Setting this to localhost or null will allow source adapters to execute on any host in the web farm. (This is the default behavior.) By listing one or more hosts, you can restrict execution to that list. If you have inbound updates from another system that go to a particular host, use the sources.hosts setting to record the host names.

In addition, you can define a property named sources.resourceName.hosts, which controls where the resource's Active Sync task will run. Replace resourceName with the name of the resource object you wish to specify.

Making the Gateway Highly Available

Identity Manager requires a lightweight gateway to manage resources that cannot be directly accessed from the server. These include systems that require client-side API calls that are platform specific. For example, if Identity Manager is running on a UNIX-based application server, the ability to make NTLM or ADSI calls to managed NT or Active Directory domains is not possible. Because Identity Manager requires a gateway to manage these resources, it is important to ensure that the Identity Manager Gateway is made highly available.

To prevent the Gateway from becoming a single point of failure, Sun recommends having multiple machines running a Gateway instance. A network routing device should be configured to provide failover if the main Gateway instance dies. The failover device should be setup for sticky sessions and use a simple round robin scheme. Do not place the Gateways behind a device that load balances! This is not a supported configuration and will cause certain Identity Manager functions to fail.

All Windows domains managed by a Gateway must be part of the same forest. Managing domains across forest boundaries is unsupported. If you have multiple forests, install at least one Gateway in each forest.

Win32 monitoring tools can be configured to watch the gateway.exe process on the Win32 host. In the event that gateway.exe fails, the process can be automatically restarted.