In a business continuity cluster, you should have only one NSS pool for each LUN that can be failed over to another cluster. This is necessary because in a business continuity cluster, entire LUNs fail over to other peer clusters. A pool is the entity that fails over to other nodes in a given cluster.
Multiple LUNs can be used as segments in a pool if the storage systems used in the clusters can fail over groups of LUNs, sometimes called consistency groups. In this case, a given LUN can contribute space to only one pool.
A cluster-enabled NSS pool must contain at least one volume before its cluster resource can be enabled for business continuity. You get an error message if you attempt to enable the resource for business continuity if its NSS pool does not contain a volume.
Also, if you have encrypted NSS volumes in your BCC, then all clusters in that BCC must be in the same eDirectory tree. The clusters in the other eDirectory tree cannot decrypt the NSS volumes.
See Table 12-1 for resources that explain how to create shared disk cluster resources on Novell Open Enterprise Server 2 Linux servers:
Table 12-1 Shared Disk Cluster Resources on OES 2 Linux Servers
|
Shared Disk Cluster Resources |
Procedure |
|---|---|
|
Dynamic Storage Technology shadow volume pairs |
|
|
Linux POSIX file systems |
|
|
NCP (NetWare Core Protocol) volumes |
|
|
Novell Storage Services (NSS) pools and volumes |
|
For information about creating cluster resources for OES 2 Linux services, see the OES 2 High-Availability documentation Web site.