A newly defined Dynamic Storage Technology shadow volume pair consists of two new volumes or of one existing volume and one new volume. For this discussion, an existing volume is one that contains data. When you use an existing volume in a pair, the new volume can act as the primary volume or the secondary volume. Shadowing scenarios for new and old volume combinations are described below.
In general, you should not use two unrelated existing volumes in a shadow volume pair. However, if two volumes are already in a shadow relationship, their content is logically and structurally related. You can temporarily remove a shadow relationship for two volumes, and then re-create the pair. For example, when a shadow volume pair is clustered with OES Cluster Services, the pair is defined when its cluster resource is online, and the pair is undefined when its resource is offline. You also might temporarily remove a shadow relationship to migrate a shadow volume pair between servers as two separate volumes, and then redefine their shadow relationship on the new server. The two volumes should not be independently accessed by users outside their shadow relationship.
The following sections describe shadowing scenarios with one existing volume and one new volume:
Your existing NSS volume currently contains many files that are seldom used and rarely change. You want to free space on the high-performance device for the unstructured files that are critical to your growing business. Backing up the volume takes more time than the window reserved for incremental and weekly backups. You want to move the stagnant files to a location where they can be easily accessed but backed up less frequently. This decreases the time it takes to back up or restore the data you use the most.
You set up iSCSI SAN storage to use for the secondary volume. You create a new NSS volume on the iSCSI disk, then define a shadow volume pair for the existing and new NSS volumes.
You configure a policy that governs what files to move to the secondary storage area. Files are returned to the primary area based on a policy of usage or file type. For example, if the user simply views the data in a file, then the data does not move. If the user modifies the file, then the file is moved back to the primary volume. Users are not aware of where the data are physically stored because they see a merged view of both volumes.
The backup administrator configures different backup schedules for the two volumes. The primary volume is backed up incrementally throughout the week, and fully at the weekends. The secondary volume is backed up less frequently. If a restore is needed, the files on the primary can be restored first and more quickly than was previously possible.
Your existing NSS volume resides on an older storage array in the SAN. You want to migrate the data to new high-performance storage arrays. The files are mission critical and the volume cannot be taken offline for a long period while you migrate the data.
You decide to use Dynamic Storage Technology to gradually and transparently migrate files to the new storage. You create a new NSS volume on a storage device in the high-performance storage array. You define a shadow volume pair that uses the empty volume as the primary area, and the existing volume as the secondary area.
You can configure a policy so that the data moves to the primary volume based upon usage. Data gradually flows to the primary volume as it is used. In this way, there is a natural background migration of data from the existing volume to the new volume. The new volume grows, and contains the files used most recently by the users. You can use policies to move all of the files to the new primary volume, or you can leave the secondary volume in place to store the little used and unchanged files.
For example, suppose you have an existing pool that spans multiple LUNs, and contains multiple volumes. The current best practice is to use a separate LUN for each pool, and a single volume per pool. You create a new pool on a new larger LUN (or fewer larger LUNs), then create a single NSS volume in the pool. You might need to rename the old and new NSS volumes if users need to access the data via known paths, because after the shadow volume is created, users access data via the new volume. Repeat this process so that you have one new empty volume for each of the old volumes on the pool. As the new and old volumes are ready, you create a DST shadow volume with the new volume as the primary storage area and an existing volume from the old pool as the secondary storage area.
To begin de-migrating the data, configure the global policies to shift data from the secondary storage area to the primary storage area whenever they are accessed or modified. You can also configure individual shadow volume policies or use inventory reports to shift data on schedule or on-demand based on age, file names, file types, or file size. De-migration occurs with the storage online and accessible to end users; they are not aware of where the data is actually stored. To ensure that the entire existing directory structure (including empty directories) is replicated on the primary volume, an administrator can enumerate the directory from an NCP client that is mapped to the merged view. After all of the data is moved from the old NSS volume to the new one, you can remove the shadow volume relationship, and delete the old NSS volume from the old pool. Users are not aware that the volume is on a new pool. They see only the volume by its name.
You can apply this process to migrate data from the other volumes in the pool. When all data has been migrated and the old volumes are deleted, you can delete the old pool, which frees that storage for other uses.