Virtual volume planning

A TS7700 supports a maximum of four million virtual volumes. To determine the number of virtual volumes that are required to accommodate your workload consider:

• The size of your virtual volumes
• The number of scratch volumes needed per day
• The time required for return-to-scratch processing
• How often scratch processing is performed

Size of virtual volumes

Depending on the virtual volume sizes that you choose, the number of volumes that are required to store your data can change depending on the media size from which you are converting. If you currently store your data on native 3490 cartridges, the number of virtual volumes that are needed likely remains the same, except multi-volume data sets. If you migrate a multi-volume data set that uses native 3490 Enhanced Capacity cartridges (800 MiB) and your target virtual volume size is 4000 MiB, then approximately five of the original volumes of a multi-volume data set can fit on one virtual volume. In this scenario, the number of virtual volumes that are needed is reduced. If your data sets currently fill native 3590 volumes you would need many more virtual volumes to store your data (as multi-volume sets), even using 4000 MiB virtual volumes.

A virtual volume's size can be set by VOLSER and can change dynamically using the DFSMS (data facility system managed storage) Data Class storage construct. You can specify 400 MiB CST (cartridge stored tape)-emulated cartridges or 800 MiB with ECCST (extended capacity cartridge storage tape)-emulated cartridges when adding volumes to the TS7700. You can use these sizes without modification or use policy management to override those sizes to provide for the 400, 800, 1000, 2000, 4000, and 6000, and 25000 MiB sizes.

The amount of data that is copied to the stacked cartridge is only the amount of data that has been written to a virtual volume. The choice between all available virtual volume sizes does not affect the real space used in either the TS7700 Cache or the stacked volume. In general, unless you have a special need for CST emulation (400 MiB), specify the ECCST media type when inserting volumes in the TS7700.

Number of scratch volumes needed per day

As you run your daily production workload, plan for enough virtual volumes in scratch status to support the data that is written to the TS7700. This could be hundreds or thousands of volumes, depending on your workload. More than a single day's worth of scratch volumes should be available at any point in time.

Time required for return-to-scratch processing

Return-to-scratch processing involves running a set of tape management tools that identifies the virtual volumes that no longer contain active data and then communicating with the TS7700 to change the status of those volumes from private to scratch. The amount of time the process takes depends on the type of tape management system being employed and how busy the TS7700 is when it is processing the volume status change requests and whether a grid configuration is being used. You should expect that when a TS7700 is not handling a daily workload peak that up to 5000 virtual volumes per hour can be returned to scratch for a single cluster and up to 2500 virtual volumes per hour can be returned to scratch in a two-cluster grid configuration.

To modify according to preferred configuration, refer to Define virtual volume expiration time and to the description of Set Expire Hold in Categories.

How often return-to-scratch processing is performed

If the number of virtual volumes that are used daily is small (less than a few thousand), you can choose to perform return-to-scratch processing only every few days. A good rule of thumb is to plan for no more than a four-hour time period to run return to scratch. By ensuring a nominal run time of four hours, enough time exists during first shift to run the process twice should problems be encountered during the first attempt. For example, assume that you use 2000 scratch volumes per night on a two-cluster grid configuration. A four-hour return-to-scratch period returns up to 10000 virtual volumes to scratch status. Running return-to-scratch processing every five days would keep up with the rate at which the scratch virtual volumes are being used. Therefore, running return-to-scratch every three or four days would provide some buffer in the number of available scratch virtual volumes.

In planning for the number of virtual volumes that are needed, first determine the number of private volumes that make up the current workload being migrated. One way to do this is by looking at the amount of data on your current volumes and then matching that to the supported virtual volume sizes. You would match the volume sizes taking into account the compressibility of your data. If you do not know what the average ratio is, a conservative value of 2:1 may be used.

If you define more volumes than you need, at a later time you can delete the additional volumes; unused virtual volumes do not consume space. Refer to the topic Physical volumes linked from the Related information section for implications of a large number of previously used, but now scratch, virtual volumes.

Preferred migration of scratch volumes

TS7700 Tape Attach Clusters operating at microcode level 8.21.0.xx or later use the preferred migration of scratch volumes enhancement, which migrates scratch volumes before migrating non-scratch volumes. This enhancement modifies the least recently used (LRU) algorithm to ensure that more critical data remains in cache for a longer period of time.