17.1 Planning for DST in a Cluster

Ensure that each node in the cluster is running the same release version of OES.

When you use clustered DST volumes, special steps are needed when you upgrade the cluster from OES 2 SP3 to OES 2015 or later. For information, see Section 17.11, Upgrading a Cluster with DST Resources from OES 2 SP3 to OES 2015 or Later.

The NCP (NetWare Core Protocol) Server and the Dynamic Storage Technology software are not cluster aware. They must be installed on every node in the cluster where you plan to migrate or fail over the cluster resource that contains shadow volumes. You do not cluster NCP Server or DST services. You can cluster the DST shadow volume pair by creating a DST pool cluster resource that manages the primary and secondary disks, pools, and volumes.

Dynamic Storage Technology supports shadow volumes created with pairs of shared OES Storage Services (NSS) volumes. Install NSS on each node in the cluster. For information, see the OES 2018 SP3: NSS File System Administration Guide for Linux.

You must create the two NSS pools and volumes on separate shared disks before you create the shadow volume relationship for the two volumes. The primary pool must be cluster-enabled. The secondary pool must be shared. You can alternatively cluster-enable the secondary pool, but its Cluster objects and IP address are not used by the secondary cluster resource while the two NSS volumes are in the shadow relationship.

You do not use the Dynamic Storage Technology Options page in OES Remote Manager to create a clustered DST shadow volume pair. The ncpcon mount command in the load script creates the DST shadow volume pair on the node where the resource is brought online.

When you use OES Remote Manager for Linux to manage policies for the shadow volume, you typically connect to the IP address of the DST pair cluster resource. You can also connect to the IP address of the server node where the cluster resource is currently mounted.

NCP Server allows NCP users to access a merged view of the clustered DST volume pair when the cluster resource is online. As with any clustered volume, the files are not available when the cluster resource is offline.

OES CIFS supports the Dynamic Storage Technology merged view of DST volume pairs composed of two NSS volumes. eDirectory and Active Directory users can access a merged view of the clustered DST volume pair when the cluster resource is online. As with any clustered volume, the files are not available when the cluster resource is offline. OES CIFS does not require users to be Linux enabled with Linux User Management (LUM).

You must install and configure OES CIFS on every node in the cluster where you plan to give users CIFS access to the shared cluster resource. For information, see OES 2018 SP3: OES CIFS for Linux Administration Guide.

You want OES CIFS to be available on the node where the DST shadow volumes is active. To do this, you add OES CIFS as an advertising protocol for the primary NSS pool resource as you cluster-enable it. You do not enable OES CIFS shares for the secondary NSS volume, because users access data via the merged view and do not directly access data on the secondary volume.

In the primary NSS pool cluster resource load script, the following command binds OES CIFS to provide access to the shared resource through the virtual server IP address when the resource is mounted on a node.

exit_on_error novcifs --add --vserver=virtualserverFDN --ip-addr=virtualserverip

In the primary NSS pool cluster resource unload script, the following command unbinds OES CIFS from the DST pool cluster resource when the resource is failed over or cluster migrated to another node in the cluster.

ignore_error novcifs --remove --vserver=virtualserverFDN --ip-addr=virtualserverip 

In the primary NSS pool cluster resource monitor script, the CIFS monitor command helps to keep CIFS up and running.

exit_on_error rcnovell-cifs monitor

In addition, the following CIFS attributes are automatically added to the NCS:NCP Server object for the virtual server on the primary pool cluster resource:

For information, see Configuring CIFS with Cluster Services for an NSS File System in the OES 2018 SP3: OES CIFS for Linux Administration Guide.

ShadowFS and FUSE (File System in Userspace) can be used with Novell Samba to allow SMB/CIFS users to access a merged view of the clustered DST volume pair. Novell Samba is an alternative to OES CIFS; they cannot be used together on the same server. Novell Samba requires users to be Linux enabled with LUM.

You do not enable Novell Samba shares for the secondary NSS volume, because users access data via the merged view and do not directly access data on the secondary volume.

You must install and configure Novell Samba and ShadowFS for each node in the cluster. For information about setting up SMB/CIFS access on each node, see Section 13.0, Using ShadowFS to Provide a Merged View for Novell Samba Users.

Additional commands for managing FUSE for the resource must be added manually in the cluster load/unload scripts of the primary pool cluster resource You must also add the following lines in the load script of the primary NSS pool cluster resource to allow time for ShadowFS to start:

# If shadowfs is used, wait for shadowfs to start
for (( c=1; c<=10; c++ )) do
if [ ! -d /media/shadowfs/VOLUME/._NETWARE ]; then sleep 5; fi
done 

You must add the following line to the unload script of the primary NSS pool cluster resource to unload the volume in FUSE:

#unload the volume in FUSE
ignore_error fusermount -u /media/shadowfs/VOLUME

OES AFP does not support a merged view of files on the DST volume pair. AFP users see only the files on the primary volume. Do not give AFP users direct access to the secondary volume.