Administrator's Guide


The Storage Pool Hierarchy

Consider using multiple levels of primary storage pools to form a storage hierarchy. For example, your fastest devices are disks, but suppose you do not have enough space on these devices to store all data that needs to be backed up. You have tape drives, which are slower to access, but have much greater capacity. You can define a hierarchy so that files are initially stored on the fast disk volumes in one storage pool. This provides clients with quick response to backup requests and recall requests. Then, as the disk storage pool becomes full, the server migrates, or moves, data to volumes in the tape storage pool. Migrating files to sequential storage pool volumes is particularly useful because TSM migrates all the files for a single node together. This is especially helpful if you have not enabled collocation.

When you define or update a storage pool, you establish a hierarchy by identifying the next storage pool, sometimes called the subordinate storage pool. The server migrates, or moves, data to the next storage pool if the original storage pool is full or unavailable.

Restrictions:

  1. You cannot establish a chain of storage pools that leads to an endless loop. For example, you cannot define StorageB as the next storage pool for StorageA, and then define StorageA as the next storage pool for StorageB.

  2. The storage pool hierarchy includes only primary storage pools, not copy storage pools.

How the Server Stores Files in a Storage Pool Hierarchy

Understanding how the server selects and accesses a primary storage pool can help you estimate the amount of space required for each storage pool in the hierarchy.

When a user backs up or archives files from a client node, the server may group multiple client files into an aggregate (a single physical file). The size of the aggregate depends on the sizes of the client files being stored, and the number of bytes and files allowed for a single transaction. Two options, one in the server options file and one in the client options file, affect the number of bytes and files allowed for a single transaction:

Together these options allow you to control the size of aggregate files stored by the server. For more information on using options to tune performance, see the performance tuning guide on the Web page ( http://www.tivoli.com/tsm ).

When an HSM client migrates files (space-managed files), the files are not grouped into an aggregate.

Where the Files Are Stored

When a user backs up, archives, or migrates a file from a client node, the server looks at the management class that is bound to the file. The management class specifies the destination, the storage pool in which to store the file. The server then checks that storage pool to determine the following:

Using these factors, the server determines if the file can be written to that storage pool or the next storage pool in the hierarchy.

An Example

As an example, assume a company has a storage pool hierarchy as shown in Figure 17.

Figure 17. Storage Hierarchy, Read/Write Access, and Maximum File Size

Storage Hierarchy, Read/Write Access, and Maximum File Size

The storage pool hierarchy consists of two storage pools:

DISKPOOL
The top of the storage hierarchy. It contains fast disk volumes for storing data.

TAPEPOOL
The next storage pool in the hierarchy. It contains tape volumes accessed by high-performance tape drives.

Assume a user wants to archive a 5MB file that is named FileX. FileX is bound to a management class that contains an archive copy group whose storage destination is DISKPOOL, see Figure 17.

When the user archives the file, the server determines where to store the file based on the following process:

  1. The server selects DISKPOOL because it is the storage destination specified in the archive copy group.

  2. Because the access mode for DISKPOOL is read/write, the server checks the maximum file size allowed in the storage pool.

    The maximum file size applies to the physical file being stored, which may be a single client file or an aggregate file. The maximum file size allowed in DISKPOOL is 3MB. FileX is a 5MB file and therefore cannot be stored in DISKPOOL.

  3. The server searches for the next storage pool in the storage hierarchy.

    If the DISKPOOL storage pool has no maximum file size specified, the server checks for enough space in the pool to store the physical file. If there is not enough space for the physical file, the server uses the next storage pool in the storage hierarchy to store the file.

  4. The server checks the access mode of TAPEPOOL, which is the next storage pool in the storage hierarchy. The access mode for TAPEPOOL is read/write.

  5. The server then checks the maximum file size allowed in the TAPEPOOL storage pool. Because TAPEPOOL is the last storage pool in the storage hierarchy, no maximum file size is specified. Therefore, if there is available space in TAPEPOOL, FileX can be stored in it.

Using Copy Storage Pools to Back Up a Storage Hierarchy

It is strongly recommended that all primary storage pools that are linked to form a storage hierarchy use the same copy storage pool for backup. If you do this, then a file that is copied to a copy storage pool does not need to be recopied when the file migrates from its original primary storage pool.

In most cases, a single copy storage pool can be used for backup of all primary storage pools. The number of copy storage pools you need depends on whether you have more than one primary storage pool hierarchy and on what type of disaster recovery protection you want to implement.

Multiple copy storage pools may be needed to handle particular situations, including:

Using the Hierarchy to Stage Client Data from Disk to Tape

A common way to use the storage hierarchy is to initially store client data on disk, then let the server migrate the data to tape. A guideline for how much primary disk storage should be dedicated to this staging of client data is enough storage to handle one night's worth of the clients' incremental backups. While not always possible, this guideline proves valuable when considering storage pool backups.

For example, if you have enough disk space for nightly incremental backups for clients and have tape devices, you can set up the following pools:

You can then schedule the following steps every night:

  1. Perform an incremental backup of the clients to the disk storage pool.

  2. After clients complete their backups, back up the disk primary storage pool (now containing the incremental backups) to the copy storage pool.

    Backing up disk storage pools before migration processing allows you to copy as many files as possible while they are still on disk. This saves mount requests while performing your storage pool backups.

  3. Start the migration of the files in the disk primary storage pool to the tape primary storage pool (the next pool in the hierarchy) by lowering the high migration threshold. For example, lower the threshold to 40%.

    When this migration completes, raise the high migration threshold back to 100%.

  4. Back up the tape primary storage pool to the copy storage pool to ensure that all files have been backed up.

    The tape primary storage pool must still be backed up to catch any files that might have been missed in the backup of the disk storage pools (for example, large files that went directly to sequential media).

See Estimating Space Needs for Storage Pools for more information about storage pool space.


[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]