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 8-1 for information about how to create shared disk cluster resources for OES 2018 SP8 clusters.
Table 8-1 Clustering Shared Disk Cluster Resources with Novell Cluster Services
|
Shared Disk Cluster Resources |
Procedure |
|---|---|
|
Dynamic Storage Technology shadow volume pairs |
|
|
Linux LVM volume groups and logical volumes |
|
|
NCP (NetWare Core Protocol) volumes |
Configuring NCP Volumes with OES Cluster Services in the OES 2018 SP3: NCP Server for Linux Administration Guide |
|
Novell Storage Services (NSS) pools and volumes |
|
|
Legacy CSM cluster resources from OES 2 SP3 clusters (managing only) |
|
|
Xen virtual machines |
|
See Table 8-2 for information about how to create cluster resources for OES 2018 SP3 services.
Table 8-2 Clustering OES 2018 SP3 Services with Novell Cluster Services