1.1 Understanding Dynamic Storage Technology

Dynamic Storage Technology presents the file system directory trees on each volume in a merged view for users. The primary file tree and secondary file tree have the same directory structure, so that each directory has an instance in both locations. Each file has a single instance that resides on only one volume at a time. When accessing files through the merged view, users are not aware of the actual physical location of the files.

An example of the merged view of the shadow volume is shown in Figure 1-1. When an NCP client lists files for Subdirectory-1, the user sees File-1, File-2, and File-3. File-1 and File-3 are stored in the primary file tree. File-2 is stored in the shadow file tree.

Figure 1-1 User View of the File System Directory

In general, transactions are executed wherever the file resides. Any file that requires a normal user-level action (copy, delete, and so on) is moved back to the primary for the action to take place, which simplifies the auditing requirements. Some transactions, such as a directory rename, occur in both file trees in order to keep the paths synchronized.

When a client creates new files, the files are automatically stored in the primary file tree. When files in the shadow file tree are modified, a configurable option allows the files to be moved to the primary file tree (default), or left in the shadow file tree. Which method you choose depends upon your storage goals.

For example, if your goal is to place newer files in the primary file tree and to place older files in the shadow file tree, you want an older file in the secondary file tree to move to primary file tree if the file’s content is modified. On the other hand, if your goal is to place files of one type (such as .doc and .ppt) in the primary area and files of a different type (such as.mp3 and .jpg) in the secondary area, you want files to stay where they are whenever they are viewed or modified.

When a new directory is created, it is created in the primary file tree. A configurable option allows the necessary branches of the tree to be created in the shadow file tree in one of two ways:

Performance is better when the directory branches are created only as needed.

When a directory is deleted, it is deleted in both areas. When a directory is renamed, it is renamed in both areas. The coordination of the file and directory management happens automatically so that the areas remain synchronized and have the same directory structure.

The primary volume and secondary volume must use the same type of file system. Only the NSS file system is supported at this time.

Dynamic Storage Technology supports mount points for volumes anywhere in the logical Linux directory tree that is available to the server. This allows you to use DST even for NSS volumes that use non-standard mount points. The primary volume and secondary volume must not use the same mount point.

The primary volume and secondary volume can be located on devices that appear as local devices to the server, including local SCSI devices, Fibre Channel SAN devices, and iSCSI SAN devices, in any combination. The device types and performance can differ between the primary and secondary devices, with the secondary volume typically being on the device with lower performance.

Clustering of a shadow volume pair is supported with OES Cluster Services. For information, see Section 16.0, Configuring DST Shadow Volume Pairs with OES Cluster Services.

Dynamic Storage Technology works closely with NCP Server to provide the merged view for users. eDirectory users and Active Directory users can see the merged view when they access the primary volume with a supported file access protocol.

Dynamic Storage Technology can be accessed by eDirectory users and Active Directory users. Although DST accommodates transactions across both volumes, the file access for a shadow volume pair is ultimately controlled by the same security features that apply for non-shadowed NSS volumes.

Dynamic Storage Technology supports the OES Trustee Model to provide secure file access for eDirectory users. An administrator accesses the shadow volume pair via an NCP client’s merged view, and sets trustees and trustee rights on directories and files in the merged file tree. NCP saves the settings to the trustee database file on the primary NSS volume, and copies the updated trustee database file to the secondary NSS volume. This ensures that the trustee and trustee rights settings are consistent across the two volumes. Trustees and trustee rights are enforced by the same NCP rights management features that apply for non-shadowed NSS volumes.

Authorized users perform directory and file operations (such as read, write, rename, delete, and so on) from a merged view. DST transparently executes directory operations on the directory’s instance on the primary volume and its instance on the secondary volume. DST transparently executes a file transaction on the volume where the file resides. The user is not aware of whether the file is on the primary volume or the secondary volume. As the operation is executed, the directory and file attributes are enforced by the same NSS file system management features used by non-shadowed NSS volumes.

NCP Server and OES CIFS automatically provide a merged view of shadow volume pairs built with NSS volumes. The NCP clients and CIFS users access files normally via this merged view.

A merged view of a shadow volume pair is not available in a native Linux file browser. The primary file tree and the shadow file tree are separate and independent directories. The NSS file system allows the root user to view files on these paths, but this access is unrelated to DST. Root user file access rights are required to back up the two locations as described in Section 1.1.5, Local File Access for Backup and Archive.

Backup administrators and system administrators with root user privileges on the server can see the primary file tree and the shadow file tree as separate and independent directories. Thus, backup tools can apply one backup policy to the primary volume’s Linux path and apply a different backup policy to the secondary volume’s Linux path.

While it is in a shadow relationship, the secondary volume is mounted in Linux, but it is not mounted in NCP. eDirectory users do not access its files directly. The NSS file system allows the root user to view files on these paths, but this access is unrelated to DST. The only operations that are intended to take place directly on the secondary volume are backup, or “remove and archive.”