Migration Process in TSM Overview
Automatic data movement between storage pools balances the performance and cost of different storage devices while ensuring adequate free space to meet new space allocations. This process is known as migration.
For each storage pool, you define low and high migration thresholds. Migration thresholds are based on a percentage of the storage pool’s total data capacity. The low threshold identifies the amount of free space needed to meet the daily processing requirements of your business. The high threshold triggers migration and ensures that enough free space is available while migration occurs. The difference between the high and low thresholds indicates the approximate amount of data that is migrated.
Image Source: IBM
Ensure that the amount of data that is migrated from a disk storage pool is a multiple of the capacity of a tape volume in the next storage pool. This policy helps reduce tape mounts and uses the space on tape volumes effectively.
Also Read: How TSM Server determines the eligibility of files during different types of backup ?
Also Read: How TSM Server determines the eligibility of files during different types of backup ?
Storage pools are chained to form a storage hierarchy. The data flows to the next designated storage pool in the chain. When the high threshold is reached, files migrate to the specified next-in- chain storage pool. Migration ends when the amount of occupied space in the storage pool declines to the low migration threshold. Migration does not occur if there is no next storage pool.
How Migration process works ?
1) Tivoli Storage Manager first identifies the client node that has backed up or migrated the largest single file space or has archived files that occupy the most space. When the server identifies that client node, the server migrates all files from every file space belonging to that client. The migration applies to those files if the number of days in the storage pool exceeds the value that the MIGDELAY parameter specifies.
2) After the files for the first client node migrate to the next storage pool, the server checks the low migration threshold for the storage pool to determine if the migration process should stop. If the amount of space that the storage pool uses is now below the low migration threshold, migration ends. If not, using the same criteria, Tivoli Storage Manager chooses another client node, and the migration process continues.
3) If the value for the MIGCONTINUE parameter is set to YES, Tivoli Storage Manager continues the migration process based on how long the files are in the storage pool. The oldest files are migrated first until the low migration threshold is reached. If the value for the MIGCONTINUE parameter is set to NO, the migration process ends, and the administrator receives a warning message.
4) If multiple migration processes are running, controlled by the MIGPROCESS parameter of the define stgpool command, the files for more than one node might be chosen for migration at the same time.
5) If the cache option is enabled, files that are migrated remain on disk storage, that is, the files are cached, until space is needed for new files. You can enable caching by specifying CACHE=YES when you define or update a disk storage pool. When caching is enabled, the migration process leaves behind duplicate copies of files on disk after the server migrates these files to subordinate storage pools in the storage hierarchy. The copies remain in the disk storage pool, but in a cached state, so that subsequent retrieval requests are satisfied quickly. However, if space is needed to store new data in the disk storage pool, cached files are erased, and the space reused for the new data.
Also Read: DISK vs FILE device classes performance
Also Read: DISK vs FILE device classes performance
The reason to use a cache for a disk storage pool is that caching shortens some file retrieval times for the server. When you use a cache, a copy of the file remains on fast disk storage after the server migrates the primary file to another storage pool. You might want to consider using a disk storage pool with caching enabled to store space-managed files that clients frequently access. Using a cache can result in the following conditions
- Increase the time for client backup operations to complete.
- Require more space for the Tivoli Storage Manager database.
6) You can use the MIGRATE STGPOOL command to run migration manually for a random access or sequential access primary storage pool.
migrate storagepool diskpool lo=0
The MIGRATE STGPOOL command also uses the following extra parameters
- DUration: Specifies the maximum number of minutes the migration runs before being automatically canceled. You can specify a value from 1 to 9999. If not specified, the server stops only after the low migration threshold is reached.
- LOwmig: For random-access and sequential-access disk storage pools, specifies that the server stops migration when the amount of data in the pool is at or below this percentage of the pool’s estimated capacity. This parameter is optional. You can specify a number from 0 to 99. The default value is the LOWMIG attribute of the storage pool definition.
- REClaim: Specifies whether to attempt reclamation for the storage pool before performing the migration. You can specify this parameter only for a sequential-access storage pool. This parameter is optional. The default is No.
Yes: Specifies that the server attempts reclamation before starting the migration.
- Wait: Specifies whether to wait for the server to complete processing this command in the foreground. This parameter is optional. The default is No.
No: Specifies that the server processes this command in the background.
Yes: Specifies that the server processes this command in the foreground.
PREVIOUS: 4.3 TSM V7 Device Class Introduction
0 Comment to "5.1 How to monitor and manage TSM migration process ?"
Post a Comment