6.1 Understanding the BCC Drivers

Business Continuity Clustering provides a Cluster Resource Synchronization template that is used with the eDirectory driver in Identity Manager to create the BCC drivers. It is a set of policies, filters, and objects that synchronize cluster resource information between any two of the peer clusters. This template is always used to create drivers for synchronizing information, and must be configured after installing BCC software.

6.1.1 IDM Driver Set and Driver Guidelines

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.

6.1.2 Preventing Synchronization Loops for Identity Manager Drivers

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

6.1.3 Example 1: Two Peer Clusters

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.

Table 6-1 Two-Cluster Driver Set Example

Cluster Resource

Subscriber Node

Publisher Node

Cluster One

Cluster Two

Cluster One

Not applicable

CR, port 2002

Cluster Two

CR, port 2002

Not applicable

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

Table 6-2 Driver Set Summary for a Two-Cluster Business Continuity Cluster

Driver Instance

Driver Set for Cluster One

Driver Set for Cluster Two

Cluster Resource

C1 to C2, port 2002

C2 to C1, port 2002

6.1.4 Example 2: Three Peer Clusters

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.

Table 6-3 Three-Cluster Driver Set Example

Cluster Resource

Subscriber Node

Publisher Node

Cluster One

Cluster Two

Cluster Three

Cluster One

(master node)

Not applicable

CR, port 2002

CR, port 2003

Cluster Two

CR, port 2002

Not applicable

No channel

Cluster Three

CR, port 2003

No channel

Not applicable

Table 6-4 Driver Set Summary for a Three-Cluster Business Continuity Cluster

Driver Instance

Driver Set for Cluster One

Driver Set for Cluster Two

Driver Set for Cluster Three

Cluster Resource

C1 to C2, port 2002

C2 to C1, port 2002

C3 to C1, port 2003

Cluster Resource

C1 to C3, port 2003

 

 

6.1.5 Example 3: Four Peer Clusters

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.

Table 6-5 Four-Cluster Driver Set Example

Cluster Resource

Subscriber Node

Publisher Node

Cluster One

Cluster Two

Cluster Three

Cluster Four

Cluster One

(master node)

Not applicable

CR, port 2002

CR, port 2003

CR, port 2004

Cluster Two

CR, port 2002

Not applicable

No channel

No channel

Cluster Three

CR, port 2003

No channel

Not applicable

No channel

Cluster Four

CR, port 2004

No channel

No channel

Not applicable

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.

Table 6-6 Driver Set Summary for a Four-Cluster Business Continuity Cluster

Driver Instance

Driver Set for Cluster One

Driver Set for Cluster Two

Driver Set for Cluster Three

Driver Set for Cluster Four

Cluster Resource

C1 to C2, port 2002

C2 to C1, port 2002

C3 to C1, port 2003

C4 to C1, port 2004

Cluster Resource

C1 to C3, port 2003

 

 

 

Cluster Resource

C1 to C4, port 2004