In general, a virtual tape library (VTL) is a component that emulates physical tape drives, libraries, and volumes, and that utilizes disk as the underlying storage hardware. Because VTLs emulate all the SCSI capabilities of tape hardware, VTL usage is not apparent to Tivoli Storage Manager servers, regardless of the server level or platform.
Because the underlying disk storage hardware is disk and because "drives" and "volumes" in a VTL environment are logical entities that are modified for particular environments, the differences between VTLs and physical tape libraries has significant side-effects for Tivoli Storage Manager servers in the following key areas:
Because the underlying disk storage hardware is disk and because "drives" and "volumes" in a VTL environment are logical entities that are modified for particular environments, the differences between VTLs and physical tape libraries has significant side-effects for Tivoli Storage Manager servers in the following key areas:
VTL Library Capacity:
The concept of "capacity" in VTLs is different than "capacity" in physical tape libraries. In a physical tape library, each volume has a defined capacity, and the library's capacity is defined in terms of the total number of volumes residing in the library. The capacity of a VTL, alternatively, is defined in terms of total available disk space. Furthermore, the number and size of volumes on disk can be increased or decreased by the user.
This variability affects what it means to "run out of space" in a VTL. For example, a volume in a VTL can run out of space before reaching its assigned capacity if the total underlying disk runs out of space. In this situation, the server can receive an abrupt end-of-volume message without any warning, resulting in backup failures.
Also Read: Limitations of using TSM Tape Drive Encryption
Also Read: Limitations of using TSM Tape Drive Encryption
When out-of-space errors and backup failures occur; however, there is usually disk space available in the VTL. It is "hidden" in volumes that are not currently in use. For example, volumes that are logically deleted or returned to scratch in the Tivoli Storage Manager server are only deleted in the server database. The VTL is not notified, and the VTL maintains the full size of the volume as allocated in its capacity considerations.
To help prevent out-of-space errors, you can use the RELABELSCRATCH parameter on the DEFINE LIBRARY and UPDATE LIBRARY commands. The RELABELSCRATCH option enables the server to overwrite the label for any volume that is deleted and to return the volume to scratch status in the library. During this operation, volumes are checked out of the library and then checked back in with an immediate LABEL LIBVOLUME command. As part of this command, OVERWRITE=YES is specified for the volume that was deleted and returned to scratch.
The RELABELSCRATCH option was introduced in V5.5.1. Later fixes enhanced the original functionality. To take full advantage of this option, use the following server levels:
V6.1.0.0 and later, includes all fixes
V6.2.0.0 and later, includes all fixes
V6.3.0.0 and later, includes all fixes
Storage pool selection:
The number of user-defined volumes in a VTL tends to be very large compared to the number of volumes in physical tape libraries. Furthermore, the capacity of VTL volumes is often logically modified to be smaller than the capacity of physical tape volumes. These characteristics do not cause any general backup or restore problems. However, they can create some undesired side effects for performance in environments that combine VTL storage pools and physical tape storage pools.
Also Read: TSM Storage Pool Concepts (V7 Revised)
Also Read: TSM Storage Pool Concepts (V7 Revised)
To force the server to ignore the number of volumes when selecting a storage pool to restore or to retrieve data, use the IGNORENUMVOLSCHECK option .
The IGNORENUMVOLSCHECK option is available with the following server levels:
V5.5.4.2 and later
V6.2.0.0 and later
V6.3.0.0 and later
Drive selection performance:
Drive configuration in a VTL, like volume configuration in a VTL, is variable. Most VTL environments attempt to utilize as many drives as possible to maximize the number of concurrent tape operations. A single tape mount in a VTL environment is typically significantly faster than a physical tape mount. However, using a large number of drives increases the amount of time that Tivoli Storage Manager servers require to select a drive for the requested mount operation. The selection process takes longer as the number of drives defined in a single library object in the Tivoli Storage Manager server increases. Virtual tape mounts can take as long or longer than physical tape mounts depending on the number of drives in the VTL.
APAR IC66116 improved server drive-selection performance by roughly doubling the optimal number of drives in a VTL. Prior to IC66116, the general recommendation was to create libraries with about 80 - 120 drives. Some environments required more drives, but this tended to increase the overhead involved in server drive selection. If more drives were required, the recommendation was to logically partition the VTL into multiple libraries and assign each library 80 - 120 drives.
With APAR IC66116, the recommended maximum number of drives is 150 - 250 for each library. This recommendation is based on benchmark testing at V6.1 and V6.2. The changes from this APAR apply to the V5.5.5.0, V6.1.4.0, and V6.2.1.0 servers.
The V6.3 Tivoli Storage Manager server introduced a new library type, called VTL, that increases mount performance with large numbers of drives. When using this library type, there can be no mixed media within the library and a path must be defined for all the drives to all of the servers or storage agents that use the library. Given these two assumptions, the server can dramatically improve drive selection performance, such that the recommended maximum number of drives would be 300 - 500 drives per library. If the assumptions made for VTL libraries are not true, the drive selection performance will degrade to the levels of a SCSI library type as stated in the previous paragraph (128 - 256 drives). For example, a mixture of different drive types (3592 + LTO) or drive generations (LTO2 + LTO3) within the same VTL library would degrade performance. Likewise, if paths are not defined between all drives and a storage agent that used the library, drive selection performance would also degrade. For more information on the new VTL library type see Managing virtual tape libraries in the V6.3 Tivoli Storage Manager Information Center.
Server version 6 and later benefit more from the changes in APAR IC66116 than server version 5 because some of the changes in the APAR relate specifically to DB2 performance.
The drive recommendations above are highly dependent on the environment. For example, a large number of drives can overload the bandwidth capabilities of the fibre cards in the VTL or the HBA on the host. Environmental constraints can reduce the effective number of drives that should be defined within a single library to a lower value than the recommended maximums.
0 Comment to "Limitations of using Virtual Tape Library (VTL) in TSM environment"
Post a Comment