Consider the guidelines in this section when planning how to provide access to the merged view of data in the DST shadow volume.
Users access the merged view of the data in the DST shadow volume by connecting to the primary volume. Users should not be allowed to connect directly to the secondary volume.
All file access is controlled with the Novell Trustee Model, which requires users to authenticate via Novell eDirectory 8.8.2 or later. You can use the Novell Client or similar NCP client tools to set trustees and file system rights in the merged file view by connecting to the primary volume.
All users (except the root user) of the shadow volume must have User objects defined in eDirectory. For information about configuring eDirectory users, see the Novell eDirectory 8.8 SP7 Administration Guide. The root user of the OES 2 Linux server is the only local user who has direct access to the volumes.
A merged user view of the file system is available for both NCP and CIFS users. The CIFS access can be set up by using either Novell CIFS or Novell Samba; OES does not support using both CIFS user access solutions on the same server. NCP Server is required to be installed and running even if all users access data via Novell CIFS or Novell Samba.
This section describes the requirements and guidelines for file access protocols:
Using DST affects the file access performance, depending on the file access protocol being used, as shown in Table 5-1.
Table 5-1 Performance for File Access Protocols Used with DST Volumes
|
User Access |
Aggregate Performance |
|---|---|
|
Novell Client users |
Performance is reduced by less than 10%. |
|
Novell CIFS users |
Performance is reduced by about 25%. |
|
SMB/CIFS users (requires Novell Samba, FUSE, ShadowFS, and Linux-enabling of users with Linux User Management) |
Performance is reduced by up to 48%. |
When users access the files via multiple protocols, you should enable the NCP Server Cross-Protocol File Locks option to protect against data corruption. For information, see Configuring Cross-Protocol File Locks for NCP Server
in the OES 2 SP3: NCP Server for Linux Administration Guide
The DST Shadow Volumes engine supports file access for NCP users. Users access data via an NCP share on the primary storage location, by using the Novell Client or other NCP clients. For information about configuring NCP Server for the OES 2 Linux server, see the OES 2 SP3: NCP Server for Linux Administration Guide.
Novell Client: See the following resources for the latest release of the Novell Client, which provides NCP access for users on Linux and Windows clients:
Only NCP client versions that are configured to receive broadcast messages are eligible to receive the duplicate file conflict messages. For information, see Section 8.3.3, Enabling or Disabling Broadcast Messages for Duplicate Files Conflicts.
NetStorage: NetStorage for Linux has limited use for accessing files on shadow volumes. NetStorage presents a merged view of the data, and the user can see, read, and write files. However, certain management functions (such as getting file properties, setting trustees, and salvaging files) work only if the files are on the primary volume. The user will find that the commands work for some files but not others because they are not aware of where the file is physically stored. For information about using NetStorage, see OES 2 SP3: NetStorage Administration Guide.
Beginning in OES 2 SP3, Novell CIFS supports using NSS volumes in a DST shadow volume configuration. It supports the following DST features:
Merged View: Novell CIFS works with NCP Server to provide a merged view of the two NSS volumes. CIFS users can access data on both volumes via a Novell CIFS share on the primary NSS volume.
Duplicate Files: CIFS can handle duplicate files, but it does not support the broadcast message notification via NCP. It shows the instance of the file on the primary volume to users. The administrator or user can rename the file so that the secondary instance of the file is again visible. The user can then determine which instance to delete.
If the global policy is set to hide duplicate files, CIFS moves the files on the secondary volume to the /._DUPLICATE_FILES folder where the administrator can access them for recovery, if necessary.
Global DST Policies: When users access or modify files, CIFS honors the global DST policies for moving files from the secondary volume to the primary volume.
Setting up Novell CIFS for use with a DST shadow volume is similar to setting up CIFS for an NSS volume. You create the CIFS share on the primary volume, but not on the secondary volume. Enable the cross-protocol file locking parameter for NCP Server on the DST server.
Novell CIFS features should work as expected, including cross-protocol file locking. The key difference is that users access the merged view of data in both volumes via the CIFS share on the primary NSS volume. The users do not know that the data is stored on two different volumes.
For information, see the following:
Consider the following requirements when configuring Novell CIFS for use with DST volumes:
Novell CIFS supports only NSS volumes on Linux. Thus, Novell CIFS can be used only with DST volumes built on NSS volumes.
CIFS users access a merged view of the DST shadow volume by using a Novell CIFS share on the primary volume. Create a CIFS share on the Primary volume only; delete the share on the secondary (or do not give users rights to access the secondary share).
Novell CIFS users don't see broadcast messages if the Broadcast Messages for Duplicate Files Conflicts feature is enabled for Duplicate Files errors. This DST option works only for Novell Client users as described in Section 8.3.3, Enabling or Disabling Broadcast Messages for Duplicate Files Conflicts. If you have only Novell CIFS users and no NCP users, you might as well disable the broadcasting option.
If you use Novell CIFS with a DST volume in a cluster, you need to add the Novell CIFS lines in the load/unload scripts for the DST cluster resource. The differences are described in Section 13.0, Configuring DST Shadow Volume Pairs with Novell Cluster Services.
You cannot configure Novell CIFS and the SMB/CIFS setup on the same server. This limitation is derived from the requirement that Novell Samba and Novell CIFS cannot be installed on the same server, and is unrelated to DST.
Novell Samba is supported for providing SMB/CIFS user access to shadow volumes. This Samba version is the standard Linux Samba that has been integrated with eDirectory. For information, see the OES2 SP3: Samba Administration Guide.
To provide a merged view for SMB/CIFS users, you must also set up ShadowFS (Shadow File System) and FUSE (Filesystem in Userspace). See Section 12.0, Using ShadowFS to Provide a Merged View for Novell Samba Users for installation and configuration requirements.
SMB/CIFS users must be Linux-enabled users of the OES 2 Linux server. The Linux Samba service must also be LUM enabled. For information, see the OES 2 SP3: Novell Linux User Management Administration Guide.
Enable the cross-protocol file locking parameter for NCP Server. For information, see Configuring Cross-Protocol File Locks for NCP Server
in the OES 2 SP3: NCP Server for Linux Administration Guide.
Novell AFP (Apple Filing Protocol) does not support DST shadow volumes. AFP users are able to see only the data that is on the primary volume. Do not create AFP shares on the primary or secondary volumes that are used in a DST shadow volume.
User access to shadow volumes via other native Linux protocols (such as HTTP, FTP, NFS, and others) is not supported.
The Shadow File System (ShadowFS) is used to provide a merged view of the shadow volume tree when you use Novell Samba for user file access. ShadowFS must be running in order for the SMB/CIFS users to access the data.
When ShadowFS is running, it automatically creates a shadow file system directory for each of the shadow volumes, not just the ones where you plan to allow SMB/CIFS access. SMB/CIFS users see only those volumes where they have file system trustee rights.
ShadowFS requires FUSE (File System in Userspace) to be installed and running. For information, see Section 12.0, Using ShadowFS to Provide a Merged View for Novell Samba Users.