Novell Cluster Services must already be installed and configured on the server. Table 8-1 provides references for cluster-related tasks for NSS.
Table 8-1 Clustering Guidelines for NSS
|
NSS Feature |
Description |
Reference |
|---|---|---|
|
Shared device |
Enable the Shareable for Clustering parameter to support high-availability server clusters with Novell 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.12, Preventing Pools from Activating on Multiple Servers |
|
Pool snapshot |
On NetWare, when you take a snapshot of a shared pool, the stored-on location for the snapshot must be the same shared pool. Snapshots of unshared pools can be stored only on unshared pools. The technologies used for pool snapshots are different for NetWare and Linux. Pool snapshots taken on Linux do not work on NetWare, and vice versa. 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. 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. You can add volumes to the pool later by cluster migrating the pool cluster resource back to the original server node in the cluster where the pool was created. Otherwise, you get an eDirectory error because the tools only look for the Pool object under its current server node, and not under the original node where it it was created. To create or modify home directories, Distributed File Services junctions, or any other elements that are managed using eDirectory objects, you must cluster migrate the pool resource back to the node where it was created before you perform those management tasks. This restriction also applies to management tasks like renaming a pool or volume that changes information in the eDirectory objects for the shared pool or volume. |
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. |
Sharing Encrypted NSS Volumes in a Cluster |
|
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 Linux. |