OES Cluster Services must already be installed and configured on the server. Table 9-1 provides references for cluster-related tasks for NSS.
Table 9-1 Clustering Guidelines for NSS
|
NSS Feature |
Description |
Reference |
|---|---|---|
|
Shared device |
Enable the Shareable for Clustering parameter to support high-availability server clusters with OES Cluster Services. |
|
|
Shared pools |
Enable the pool for clustering when you create the pool. Devices contributing space to the pool must already be marked as shareable in order to be able to create a shared pool. Unshared pools can be created on shared devices. Pools created on NetWare can fail over to a Linux node in a mixed-node cluster, but only pools that were originally created on NetWare can fail back from Linux to NetWare. |
|
|
Multiple Server Activation Prevention (MSAP) for pools |
MSAP prevents some accidental activations of a pool on more than one server at a time. MSAP is enabled by default. |
Section 16.14, Preventing Pools from Activating on Multiple Servers |
|
Pool snapshot |
On Linux, NSS does not support using pool snapshots for clustered pools. You must remove any existing pool snapshots for a clustered pool on NetWare before you cluster migrate the pool cluster resource from a NetWare server to a Linux server during a rolling cluster conversion. WARNING:You might not be able to open the original pool on Linux if you do not delete the snapshots before you attempt to cluster migrate the pool cluster resource from NetWare to Linux. |
|
|
Shared volumes |
You must create at least one shared volume in a cluster-enabled pool. We recommend using only one volume per pool in a cluster. Typically, all volumes are created when you initially set up the cluster resource and before you need to cluster migrate or fail over the resource to other servers in the cluster. The Server, Pool, Volume, Cluster Resource, and Cluster objects are recommended to be in the same context (such as ou=ncs,o=microfocus). If the objects are in different contexts, you might receive an eDirectory error when you attempt to modify the pool, create or modify the volumes, home directories, Distributed File Services junctions, or any other elements that are managed using eDirectory objects. To resolve the problem, you must cluster migrate the pool cluster resource back to the node where the pool was created in order to perform those management tasks. |
Section 19.2.4, Guidelines for NSS Volumes in a Mixed-Node Cluster |
|
Shared encrypted volume |
When shared pools contain encrypted volumes, you must provide the encryption password the first time that a volume is mounted after a reboot. Thereafter, the nodes in the cluster share the key. |
|
|
Shadow volume pair using Dynamic Storage Technology |
When a shared pool contains a volume that is part of a shadow volume pair, the other volume in the shadow pair can reside on the same pool or in a different pool on the same server. If it is on a different pool, both pools must be managed by the same cluster resource. In a cluster, shadow volumes can reside on and fail over only to nodes running OES 2 or later servers. |
Before you attempt to cluster-enable an existing pool and its volumes, the pool should be deactivated and its volumes should be dismounted.
Comment out (or remove) the volume’s entry in the /etc/fstab file. The load and unload scripts that are created when you cluster-enable the pool will be responsible for mounting and dismounting the volume after the pool is cluster enabled. If you leave /etc/fstab as-is, the server will continue to try and mount the NSS volume on reboot, but it will not succeed. For information about cluster-enabling an existing pool and its volumes, see Cluster-Enabling an Existing NSS Pool and Its Volumes
in the OES Cluster Services for Linux Administration Guide.