Deploy VMware Identity Manager in a secondary data center to provide failover capabilities if the primary VMware Identity Manager data center becomes unavailable.

Beginning with version 2.1.1, two options to provide failover capabilities to a secondary data center are available. The existing method of active - hot standby allows continuity of the entire VMware Identity Manager service with minimal downtime as the secondary data center is made primary. The method available beginning with version 2.1.1 enables a secondary data center to be powered on and active with read-only access, which eliminates any downtime during the fail-over. The read-only capability allows end users to view and launch their applications. This section documents how to set up a secondary data center in read-only mode.

Note

If your enterprise environment requires second data center failover with full read/write capability, other deployment options are also available. See KB 2094258, Using embedded vPostgres database for VMware Workspace Portal 2.1.

VMware Identity Manager Data Center Diagram

The scenario for Figure 1 is as follows:

The primary data center includes WS1 as the master VMware Identity Manager server configured with an internal database. WS2 is cloned from WS1 and the database is configured as a slave to the master database in WS1.

The secondary data center is a manual replication of the primary data center. The master VMware Identity Manager (WS1) configuration is imported to WS3 and WS4. The database is configured as slaves of WS1, with read-only access.

Each data center is configured with a load balancer.

The View Pods and Citrix-based Xen App Farm resources in the primary data center are setup in the secondary data center to mirror the configuration in the primary data center. When XenApp applications are configured, set up two Integration Brokers, one in each datacenter. Use a load balancer or a DNS record to control traffic flow to either the primary data center or to secondary data centers when the primary data center becomes unavailable. The ThinApp repository is set up in a Distributed File System (DFS) for high availability.

The VMware Identity Manager FQDN should be served by a load balancer or a DNS entry which forwards all the traffic either to the load balancer in the primary data center or to the load balancer in the secondary data center.