Business Continuity Clustering supports eDirectory 9.2.8 with the latest patches applied. See the eDirectory 9.2.8 documentation for information about using and managing eDirectory.
Each cluster that you want to add to a business continuity cluster should reside in its own OU level container.
As a best practice for each peer cluster, put its Server objects, Cluster object, Driver objects, and Landing Zone in the same eDirectory container. See Table 4-2 for an example.
Table 4-2 Sample eDirectory Containers for three Peer Clusters
|
ou=cluster1 |
ou=cluster2 |
ou=cluster3 |
|---|---|---|
|
You can use the cluster OU as the landing zone. Optionally, you can create an OU in the cluster OU for the landing zone. ou=cluster1LandingZone |
You can use the cluster OU as the landing zone. Optionally, you can create an OU in the cluster OU for the landing zone. ou=cluster2LandingZone |
You can use the cluster OU as the landing zone. Optionally, you can create an OU in the cluster OU for the landing zone. ou=cluster3LandingZone |
|
cn=cluster1 |
cn=cluster2 |
cn=cluster3 |
|
c1_node1 (IDM node with read/write replica of ou=cluster1) c1_node2 c1_node3 |
c2_node1 (IDM node with read/write replica of ou=cluster2) c2_node2 c3_node3 |
c3_node1 (IDM node with read/write replica of ou=cluster3) c3_node2 c3_node3 |
|
cluster1BCCDriverSet
|
cluster2BCCDriverSet
|
cluster3BCCDriverSet
|
The node where the Identity Manager engine and the eDirectory driver are installed must have a read-write replica of the cluster container. If the driverset and the landing zone should not be sub-ordinate to the cluster container writable replicas of both objects are also required.
For all other nodes it is very strongly recommended to hold such a replica.
The first time that you install the Business Continuity Clustering software in an eDirectory tree, the eDirectory schema is automatically extended with BCC auxiliary object classed and attributes.
IMPORTANT:The user that installs BCC must have the eDirectory credentials necessary to extend the schema.
If the eDirectory administrator user name or password contains special characters (such as $, #, and so on), you might need to escape each special character by preceding it with a backslash (\) when you enter credentials for some interfaces.
The BCC Administrator user should have at least Read and Write rights to the All Attribute Rights property on the Cluster object of each peer cluster. Before you install BCC, create the BCC Administrator user and group identities in eDirectory to use when you manage the BCC.
The following trustee settings are recommended for the BCC Administrator user on the Cluster object of each peer cluster:
|
Property Name |
Assigned Rights |
Inherit |
Description |
|---|---|---|---|
|
ACL |
None |
No |
Explicitly removing the rights for the ACL property ensures that no rights flow from eDirectory to the file system. |
|
[All Attributes Rights] |
Compare, Read, Write |
Yes |
Read and Write are required. |
|
[Entry Rights] |
Create, Delete |
Yes |
The Create right allows the trustee to create new objects below the container and also includes the Browse right. The Delete right allows the trustee to delete the target from the directory. |
For information, see Section 5.3, Configuring a BCC Administrator User and Group.
The BCC Administrator user is not automatically assigned the rights necessary to manage all aspects of each peer cluster. When you manage individual clusters, you must log in as the Cluster Administrator user, or as administrator-equivalent to this user. You can manually assign the Cluster Administrator rights to the BCC Administrator user for each of the peer clusters if you want the BCC Administrator user to have all rights.
You can assign the BCC Administrator user as an administrator-equivalent account for each peer cluster by configuring the following for the user account:
Give the user the Supervisor right to the Server object of each server in the cluster.
Linux-enable the user account with Linux User Management (LUM).
Make the user a member of a LUM-enabled administrator group that is associated with the servers in the cluster.
For information about configuring permissions for cluster administrator-equivalent users, see Configuring Additional Administrators
in the OES 23.4: OES Cluster Services for Linux Administration Guide.
Each Identity Manager Driver object must have sufficient rights to any object it reads or writes in the following containers:
The Identity Manager driver set container.
The container where the Cluster object resides.
The container where the Server objects reside.
If Server objects reside in multiple containers, this must be a container high enough in the tree to be above all containers that contain Server objects.
The best practice is to have all Server objects in one container.
The container where the cluster Pool objects and Volume objects are placed when they are synchronized to this cluster. This container is referred to as the landing zone. The NCP Server objects for the virtual server of a BCC-enabled resource are also placed in the landing zone.
You can do this by making the Identity Manager Driver object the security equivalent to the BCC Administrator User object after you create the driver.
The node where Identity Manager is installed must have an eDirectory full replica with at least Read/Write access to all eDirectory objects that will be synchronized between clusters.
IMPORTANT:Full eDirectory replicas are required. Filtered eDirectory replicas are not supported.