DFSMShsm enhancements for Transparent Cloud Tiering
In this appendix, we provide methods to improve the DFSMShsm Transparent Cloud Tiering (TCT) migration to cloud experience. Before implementing any of the changes that are documented in this appendix, ensure that the latest TCT maintenance level is installed. You find the maintenance level by going to New Function For Transparent Cloud Tiering and searching for the following FIXCAT categories:
•IBM.Function.DFSMSCloudStorage
•DFSMSCS/K
|
Note: Thanks to Jeannie Vangsness and Glenn Wilcock for their contribution to this appendix.
|
This appendix includes the following topics:
Large number of data sets
With APAR OA58915, you can increase the maximum number of large data sets that can be migrated to the cloud concurrently. The feature is available in base z/OS V2R5. PTFs for OA58915 are available for V2R4 and V2R3.
•A limited number of large data sets can be migrated to the cloud concurrently.
If this number is exceeded, large data sets are skipped. These large data sets are revisited later when the large data sets in the process complete. When only large data sets remain to process, DFSMShsm waits a defined interval before the next scan.
The following PATCH command can be used to change this interval:
PATCH .MGCB.+152 X'nnnn'
nnnn is the time in seconds.
The default value is X'001E' (30 seconds).
•Set the interval for issuing the Disk controller busy, ARC1587I message.
An ARC1587I message indicates that all disk controller cloud data movement threads are busy for a specified number of seconds. The following PATCH command can be used to change the interval in which the message is issued:
PATCH .MGCB.+164 X'nnnn'
nnnn is the time in seconds.
If this value is set to X'7FFF', no interval checking is done, and no ARC1587 messages are issued. The default value is X'7FFF'.
•Setting the maximum wait time in seconds to get a disk controller for moving data to the cloud.
You can set the maximum wait time that Hierarchical Storage Manager (HSM) waits to get a disk controller cloud data movement thread lock. HSM Space Management for a volume terminates when a disk controller cannot be reserved within this time. When the wait time is exceeded, a ARC0535I message is issued, and volume processing is terminated.
The following PATCH command can be used to tune the wait time:
PATCH .MGCB.+9A X'nnnn'
nnnn is the time in seconds.
If this value is set to X'7FFF', no interval checking is done, and Space Management of a volume is not terminated. The default value is X'7FFF'.
•Setting the minimum size of a large data set.
A data set is considered “large” when it is larger than this value in the management communication vector table (MCVT). The following PATCH command can be used to tune this value:
PATCH .MCVT.+5AC X'nnnnnnnn'
nnnnnnnn is a data set size in tracks.
The default value is X'000186A0' (100.000) tracks.
•Setting the minimum number of small data set threads for moving data to the cloud.
There is a limited number of DS8000 threads for data movement. By default, DFSMShsm reserves one thread per DS8000 internal server to process small data sets to avoid the situation where large data sets processing consumes all available threads and no small data sets are migrated.
If you know that only large data sets will be processed, you can make this reserved thread available for processing large data sets too. You can use the following PATCH command to tune the number of threads that are reserved for small data sets:
PATCH .MCVT.+3CE X'nnnn'
nnnn is the number of threads that is reserved for small data sets.
The default value is X'0001'.
A large data set is one that exceeds the default value of 100,000 tracks or the customer-defined value in the MCVT+5AC. A PATCH value of '0' enables DFSMShsm to use all DS8000 threads for processing large data sets without concern for blocking out small data set processing.
•Allowing DFSMShsm to trace threads checking and reserving during migration to cloud storage.
By default, threads checking and reserving traces are not written during migration to cloud storage. To enable this option, run the following PATCH command:
PATCH .MCVT.+24F BITS(...1....)
This processing can be reversed or disabled by running the following PATCH command:
PATCH .MCVT.+24F BITS(...0....)
•Defining the MIGRATE STORAGEGROUP command behavior.
The MIGRATE STORAGEGROUP command migrates the eligible data sets on the volumes in one or more storage groups. When the MIGRATE STORAGEGROUP command is issued, DFSMShsm reads the SMS storage group definition and determines the list of volumes that are defined by this storage group. Next, the data sets on these volumes are processed in a similar way to automatic migration processing.
By default, the main differences are as follows:
– Volumes can be processed several times a day.
– In a multi-host environment, the command can go into a wait state for up to 5 minutes if the volume that is required for processing is reserved by another host.
The following PATCH command can be applied to provide MIGRATE STORAGEGROUP command behavior that is fully consistent with automatic migration:
PATCH .MGCB.+113 BITS(..1.....)
This processing can be reversed or disabled by issuing the following PATCH command:
PATCH .MGCB.+113 BITS(..0.....)
•Allowing DFSMShsm automatic functions or the MIGRATE STORAGEGROUP command to process volumes more than once per day.
If the MIGRATE STORAGEGROUP command behavior is fully consistent with automatic migration (the PATCH command above is applied) and the DAYS(0) or MOVE parameter is not specified, the volumes can be processed only once every 14 hours. In this case, the tuning of the MIGRATE STORAGEGROUP command processing is the same as automatic primary space management of SMS volumes.
MIGRATE STORAGEGROUP with thee DAYS(0) or MOVE parameter can process the volumes once every 3 hours and 59 minutes. You can change this limit by using the following PATCH command:
PATCH .MCVT.+5B0 X'nnnnnnnn'
nnnnnnnn is the minimum time in seconds between MIGRATE STORAGEGROUP commands with the DAYS(0) or MOVE parameter.
•Setting the wait Interval before the next Secure Sockets Layer (SSL) check is run during migration to cloud storage when multiple migration subtasks are enabled.
The following PATCH command can be used to change the interval in seconds before the next migration subtask starts to migrate the first data set to cloud storage:
PATCH .MGCB.+166 X'nnnn'
nnnn is the time in seconds.
If this value is set to X'0000', the next migration subtask does not wait before data set processing. The default value is X'0000'.
If for example, you set this value to 60 seconds, Subtask1 starts immediately, Subtask2 starts 60 seconds after the first, Subtask3 starts 120 seconds after the first, Subtask4 starts 180 seconds after the first, and so on.
Performance improvements
This section describes the following topics:
Asynchronous object deletion
With APAR OA59765, DFSMShsm is enhanced to modify automatic migration functions to delete old migration copies from cloud storage asynchronously. This new function reduces the time that it takes to migrate data sets to the cloud storage.
To enable this option, apply the following PATCH command:
PATCH .MGCB.+113 BITS(...1....)
This processing can be reversed or disabled by issuing the following PATCH command:
PATCH .MGCB.+113 BITS(...0....)
The APAR is available in base z/OS V2R5. PTFs are available for V2R4 and V2R3.
Additional performance improvements
To improve DSFShsm performance with TCT, consider the following measures:
•Enable migration subtasking by running the following SETSYS command:
SETSYS MIGRATIONSUBTASKS(YES)
•With DS8880 8.5 or higher or DS8900, increase the number of concurrent DS8000 cloud movement threads per DS8000 internal server from 6 to 12 with the following PATCH command:
PATCH .MCVT.+494 X'000C'
•Change the container creation cycle to 92 days if it is still set to 7 in your environment. Run the following PATCH command:
PATCH .ARCCVT.+50F X’5C’
The default was changed from 7 to 92 with APAR OA60278.
•Set a unique plex name per HSMplex with the following SETSYS command:
SETSYS PLEXNAME(plexname)
•Separate cloud work with the following SETSYS command:
SETSYS MIGRATIONAUTOCLOUD(NOCLOUD | CLOUDONLY)
•Testing migration to cloud
The MIGRATE DSN command is a single threaded command. It is not a proficient way of testing migration to cloud. Instead, use the MIGRATE STORAGEGROUP DAYS(0) or MOVE parameter so that the volumes are distributed equally across the DS8000 internal servers (central processor complexes (CPCs)).
Other considerations
When you migrate data sets to the cloud, consider the following items:
•Large data sets take a long time to go to the cloud. Be patient.
•Be sure to know your average throughput going to your cloud provider.
•If DFSMShsm seems stalled or not progressing, make sure that you set the ENABLE(AOM496I) parameter in the DEVSUPXX parmlib member set. The AOM496I status message goes to the console for TCT operations. It is disabled by default. For more information, see z/OS MVS Initialization and Tuning Reference.
•When a user cancels a “stalled” HSM task, this action cancels the task in the z/OS host, but it does not cancel the DS8000 thread moving the data set to the cloud.
•The new patches are documented in “Tuning patches supported by DFSMShsm”
in z/OS 2.5 DFSMShsm Implementation and Customization Guide.
in z/OS 2.5 DFSMShsm Implementation and Customization Guide.
•Always run with the latest maintenance levels, which can be found by going to New Function For Transparent Cloud Tiering and searching for the following FIXCAT categories:
– IBM.Function.DFSMSCloudStorage
– DFSMSCS/K
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.