3.6 eDirectory Design Guidelines

Your eDirectory solution for each of the peer clusters in the business continuity cluster must consider the following configuration elements. Ensure that your approach is consistent across all peer clusters.

3.6.1 Naming Conventions for BCC-Enabled Resources

Develop a cluster-independent naming convention for BCC-enabled cluster resources. It can become confusing if the names of objects belonging to a BCC enabled cluster resource refer to one peer cluster but the resource is active on another peer cluster.

You can use a naming convention for resources in your BCC as you create those resources. Changing existing names of cluster resources is less straightforward and can be error prone.

When you cluster-enable NSS pools, these are the default names used by NCS:

  • Cluster Resource: poolname_SERVER
  • Cluster-Enabled Pool: clustername_poolname_POOL
  • Cluster-Enabled Volume: clustername_volumename
  • Virtual Server: clustername-poolname-SERVER

Instead, use names that are independent of the clusters and that are unique across all peer clusters. For example, replace the clustername with something static, such as BCC.

NOTE:The pool and volume objects will need to be renamed before a resource is BCC enabled.

NCP servers cannot be renamed. The proper name must be specified when cluster enabling the pool.

  • Cluster Resource: poolname_SERVER
  • Cluster-Enabled Pool: BCC_poolname_POOL
  • Cluster-Enabled Volume: BCC_volumename
  • Virtual Server: BCC-poolname-SERVER

3.6.2 Object Location

Cluster nodes and Cluster objects can exist anywhere in the eDirectory tree. The virtual server object, cluster pool object, and cluster volume object are automatically created in the eDirectory context of the server where the cluster resource is created and cluster-enabled.

3.6.3 Cluster Context

Place each cluster in a separate Organizational Unit (OU). All objects belonging to the cluster nodes and the cluster object for a given cluster should be in the same OU.

Figure 3-1 Cluster Resources in Separate OUs

3.6.4 Partitioning and Replication

Partition each cluster OU and replicate it to dedicated eDirectory servers holding a replica of the parent partition and to all cluster nodes. This helps prevent resources from being stuck in an NDS Sync state when a cluster resource’s configuration is modified.

  • The cluster node that hosts the Identity Manager driver should have a full read/write eDirectory replica with the following containers in the replica:

    • Driver set container

    • Cluster object

    • (Parent) container where the servers reside

    • Landing zone container

  • Ensure that you have full read/write replicas of the entire tree at each data center.

3.6.5 Objects Created by the BCC Drivers for Identity Manager

When a resource is BCC-enabled, its configuration is automatically synchronized with every peer cluster in the business continuity cluster by using customized Identity Manager drivers. The following eDirectory objects are created in each peer cluster:

  • Cluster Resource object

  • NCP Server object for the virtual server

  • Cluster Pool object

  • Cluster Volume object(s)

The Cluster Resource object is always placed in the Cluster object of the assigned peer clusters where the resource did not exist initially. Any OU can be defined as the BCC landing zone. The NCP Server object for the virtual Server, Cluster Pool, and Cluster Volume objects are stored in the landing zone.

Resources have an identity in each peer cluster, and the names are the same in each peer cluster. Figure 3-2 shows the cluster resource identity in each of two peer clusters.

Figure 3-2 Cluster Resource Identity in Two Clusters