6.1 Understanding the BCC Drivers

Multiple instances of the Cluster Resource Synchronization drivers can be added to the same driver set. For example, the driver set has a driver instance for each Identity Manager connection that a given cluster has with another peer cluster.

The BCC drivers are installed and configured on the Identity Manager node in each of the peer clusters in the business continuity cluster. Each of the driver connections has a Publisher channel (sending) and a Subscriber channel (listening) for sharing information between any two peer clusters. The two nodes are not directly connected; they communicate individually with the Identity Manager vault on a port that is assigned for that instance of the driver.

You must assign a unique port for communications between any two peer clusters. The default port in the Cluster Resource Synchronization template is 2002. For each instance of a driver, you can use any ports that are unique and not otherwise allocated. Ensure that the ports are not blocked by the firewall. Examples of port assignments are described elsewhere in this section.

You must specify the same port number for the same driver instance on both cluster nodes. For example, if you specify 2003 as the port number for the Cluster Resource Synchronization driver on one cluster, you must specify 2003 as the port number for the same Cluster Resource Synchronization driver instance on the peer cluster.

The driver needs to have sufficient eDirectory rights in the Cluster context to create, modify, and delete objects related to BCC-enabled cluster resources. This is achieved by making the Driver object security equivalent to the BCC Admin user.

If you have three or more clusters in your business continuity cluster, you should set up synchronization for the Cluster Resource objects in a manner that prevents Identity Manager synchronization loops. Identity Manager synchronization loops can cause excessive network traffic and slow server communication and performance.

For example, in a three-cluster business continuity cluster, an Identity Manager synchronization loop occurs when Cluster One is configured to synchronize with Cluster Two, Cluster Two is configured to synchronize with Cluster Three, and Cluster Three is configured to synchronize back to Cluster One. This is illustrated in Figure 6-1 below.

Figure 6-1 Three-Cluster Identity Manager Synchronization Loop

A preferred method is to make Cluster One an Identity Manager synchronization master. Cluster One synchronizes with Cluster Two. Cluster Two and Cluster Three both synchronize with Cluster One. This is illustrated in Figure 6-2 below.

Figure 6-2 Three-Cluster Identity Manager Synchronization Master

You could also have Cluster One synchronize with Cluster Two, Cluster Two synchronize with Cluster Three, and Cluster Three synchronize back to Cluster Two, as illustrated in Figure 6-3.

Figure 6-3 Alternate Three-Cluster Identity Manager Synchronization Scenario

In a single-tree scenario with a four-cluster business continuity cluster, Cluster One is an Identity Manager synchronization master in which Cluster One synchronizes data with each of the peer clusters, as illustrated in Figure 6-4.

Figure 6-4 Single-Tree, Four-Cluster Identity Manager Synchronization Scenario

Let’s consider a two-cluster business continuity cluster. The Cluster Resource Synchronization driver’s Publisher channel in Cluster One communicates with the driver’s Subscriber channel in Cluster Two. Conversely, the driver’s Publisher channel in Cluster Two communicates with the driver’s Subscriber channel in Cluster One. The two clusters send and listen to each other on the same port via the Identity Manager vault, as shown in Table 6-1.

You install the Cluster Resource Synchronization driver once on Cluster One and once on Cluster Two, as shown in Table 6-2.

If you have more than two clusters in your business continuity cluster, you should set up communications for the drivers in a manner that prevents Identity Manager synchronization loops. Identity Manager synchronization loops can cause excessive network traffic and slow server communication and performance. You can achieve this by picking one of the servers to be the master for the group. Each of the peer clusters’ drivers communicates to this node.

For example, let’s consider a three-cluster business continuity cluster. You can set up a communications channel for the Cluster Resource Synchronization driver between Cluster One and Cluster Two, and another channel between Cluster One and Cluster Three. Cluster Two does not talk to Cluster Three, and vice versa. You must assign a separate port for each of these communications channels, as shown in Table 6-3 and Table 6-4.

When you extend the single-tree example for a four-cluster business continuity cluster, you can set up similar communications channels for the Cluster Resource Synchronization driver between Cluster One and Cluster Two, between Cluster One and Cluster Three, and between Cluster One and Cluster Four. You must assign a separate port for each of these channels, as shown in Table 6-5.

You install the drivers on each cluster, with multiple instances in the driver set on Cluster One, but only a single instance in the peer clusters, as shown in Table 6-6.