CA Identity Manager Installation Guide › JBoss Version › Installation on a JBoss Cluster › Sample Installations on a JBoss Cluster

Sample Installations on a JBoss Cluster

The following topics illustrate the JBoss cluster architecture supported by CA Identity Manager 12.6.4:

• CA Identity Manager on a JBoss 5 Cluster
• CA Identity Manager on a JBoss 6.1 Cluster

CA Identity Manager on a JBoss 5 Cluster

In configuring JBoss clustering, you create a master node and it is usually the node that starts first in the cluster. As other nodes start, they receive deployment files from the master node. If the master node fails, another node becomes the new master node.

The following JBoss 5 figure shows the relationship between the nodes and cluster members. Each node contains one cluster member. Each member of the cluster has a unique Server Peer ID. The master node would be cluster member 1, assuming it was created first.

In this figure, the messaging database is a central store for cluster members to share messages and each node contains three components:

CA Identity Manager Server

Provides the core functionality of the product.

JBoss Messaging Engine

Provides messaging functionality for members of the cluster using JMS.

CA Identity Manager on a JBoss 6.1 Cluster

On JBoss Enterprise Application Platform (EAP) 6.1, CA Identity Manager supports clusters that use either the unicast or multicast form of communication between nodes. In either type of cluster, you create a master node and it is usually the node that starts first in the cluster. As other nodes start, they receive deployment files from the master node. If the master node fails, another node becomes the new master node.

For example, consider the situation where you have a cluster of two nodes. The following figure shows the relationship between the nodes and cluster members. Each node contains one cluster member. Each member of the cluster has a unique Server Peer ID. The master node would be cluster member 1, assuming it was created first.

In this figure, the following components exist:

CA Identity Manager Server

Provides the core functionality of the product.

Live and Backup HornetQ Instances

Provides messaging functionality for members of the cluster. On each node, you configure two HornetQ instances, a live instance and a backup.

Journal Files

Persists HornetQ messages using journal files without using a database. You configure each HornetQ instance to store journal files. In this example, all nodes share a set of journal files, which are on a Storage Area Network (SAN) Server. This scenario is referred to as a Shared Store.

In you choose Replication instead of a Shared Store during installation, journal files are stored on each node.