C.1 Understanding Remote Volume Support for the Technology Preview

In OES 2 SP3, Dynamic Storage Technology provides a technology preview for using a local primary NSS volume with a remote secondary NSS volume in a DST shadow volume pair. Figure C-1 illustrates the remote setup options. The DST server is an OES 2 SP3 Linux server running DST. The two primary NSS volumes reside on storage devices that are seen as local to the DST server, such as Fibre Channel, iSCSI, or direct-attached storage. The remote NSS volumes can reside on NetWare, OES 1 Linux, or OES 2 Linux servers that are in the same Novell eDirectory tree and partition as the primary NSS volumes. It does not matter if DST is also running on a remote OES 2 Linux server.

Figure C-1 DST Remote Secondary Volume Support in the Technology Preview for OES 2 SP3 Linux

You use the Novell Client 2.3 for Linux (NCL) on the DST server to connect to a remote server. To allow DST to access data on the remote NSS volume, you must log in with the credentials (user name, password, context, and tree) of a user that is a file system trustee with the Supervisor right on the remote NSS volume. We recommend that you create a user identity to use only for this purpose. The full Linux path of the NCL mount point is used as the secondary path when you define the DST shadow volume pair.

NCL automatically mounts the remote volume as a native Linux POSIX file system, not as an NSS file system. This does not allow DST to exchange the full set of NSS file system and NCP (NetWare Control Protocol) access control lists (ACLs) when data is moved between the two volumes as DST does when the secondary NSS volume is local. Instead, NCL exchanges only the metadata that is compatible with the Linux POSIX file system and ACLs.

After you create a DST shadow volume, file system trustees and rights are set by using the merged view of the file trees. If the primary NSS volume contains data at create time, the current trustee and rights settings apply to files and folders in the primary and the secondary volumes. If the remote NSS volume contains data at create time, the settings are not automatically brought across to the primary volume. You must reset the file system trustees and rights from the merged view.

Because DST cannot push the metadata to the remote NSS volume through NCL, the NSS file system trustees and rights settings reside only on the primary volume. If you unlink the shadow volume pair, you must set up the file system trustees and rights for any data that remains on the remote NSS volume.

Both NCP users and Novell CIFS users can see a merged view of the data on the two NSS volumes. They access data via shares created on the primary NSS volume. DST controls access to the remote file system based on the file system rights of each user. It is not necessary to LUM enable the users.

An OES 2 SP3 patch release is planned that will allow DST to see the remote secondary NSS volumes as an NSS volume instead of a Linux POSIX file system. This will allow DST to exchange file system trustees and trustee rights with the remote NSS volumes so that both volumes have a synchronized copy of the settings. Figure C-2 illustrates the final vision for DST remote secondary NSS volume support.

Figure C-2 DST Remote Secondary Volume Support that Allows NSS and NCP Metadata Exchange