3.6 eDirectory Design Guidelines

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. You should create cluster resources on the master node of the cluster.

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

Figure 3-1 Cluster Resources in Separate OUs

Partition the 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.

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:

The Cluster Resource object is placed in the Cluster object of the peer clusters where the resource did not exist initially. The Virtual Server, Cluster Pool, and Cluster Volume objects are stored in the landing zone. Search-and-replace transform rules define cluster-specific modifications such as the IP address.

Any OU can be defined as the BCC landing zone. Use a separate OU for the landing zone than you use for a cluster OU. The cluster OU for one peer cluster can be the landing zone OU for a different peer cluster.

Develop a cluster-independent naming convention for BCC-enabled cluster resources. It can become confusing if the cluster resource name refers to one cluster and is failed over to a 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.

For example, when you cluster-enable NSS pools, these are the default naming conventions used by NSS:

• 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.

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

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

Figure 3-2 Cluster Resource Identity in Two Clusters