8.1 Understanding the BCC Drivers

Business Continuity Clustering provides two templates that are used with the eDirectory driver in Identity Manager to create the BCC drivers:

Both the Cluster Resource Synchronization driver and the User Object Synchronization driver can be added to the same driver set. The driver set can also contain multiple instances of a given driver. For example, you have an 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 and between any two trees. The default port in the Cluster Resource Synchronization template is 2002. The default port in the User Object Synchronization template is 2001. You can use any ports that are unique for each instance of a driver, and that are not otherwise allocated. Make sure the ports are not blocked by the firewall. Examples of port assignments are shown in the tables below.

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.

For example, 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 8-1.

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

If the clusters are in different trees, or if the User objects are in a separate eDirectory partition than Cluster objects, you also need to install an instance of the User Object Synchronization driver on a different port, as shown in Table 8-3 and Table 8-4.

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 8-5 and Table 8-6.

If one of the clusters is in a different tree, or if the User objects are in a separate eDirectory partition, you also need to install an instance of the User Object Synchronization driver on a different port for the two nodes that communicate across the tree (or across the partitions). Table 8-7 shows Cluster One and Cluster Two in Tree A (or User_PartitionA) and Cluster Three in Tree B (or User_PartitionB). The User Object Synchronization driver has been set up for Cluster One and Cluster Three to communicate across the trees (or across the partitions).

You install the drivers on each cluster, with multiple instances needed only where the master cluster talks to multiple clusters and across trees, as shown in Table 8-8.

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 8-9.

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 8-10.

In the four-cluster business continuity cluster, you can set up the fourth node to talk to any one of the other three, making sure to avoid a configuration that results in a synchronization loop. This might be desirable if Cluster One and Cluster Two are in one tree (or user object partition), and Cluster Three and Cluster Four are in a second tree (or user object partition). In this case, you could set up channels for the Cluster Resource Synchronization driver between Cluster One and Cluster Two, between Cluster One and Cluster Three, and between Cluster Three and Cluster Four. You must assign a separate port for each of these channels, as shown in Table 8-11. You also need to install an instance of the User Object Synchronization driver on a different port between the two clusters that communicate across the two trees (or across the two User object partitions).

You install the drivers on each cluster, with multiple instances needed only where the master cluster talks to multiple clusters and across trees, as shown in Table 8-12.