Zlatko,
The design of the VTS was to allow a bunch of (relatively) small files to be
written to the VTS cache (a bunch of disk) as "virtual" volumes, then
"stacked" together on one of the new big tapes.
Consider if you had a lot of old round tapes; they only held about 200 MB.
And in most people's tape libraries, all the tapes aren't full, anyway, so
each tape represents considerably less than 200 MB. If you try to convert
these round tapes to 3590 tapes (which these days can hold 40 GB, before
compression), you waste a LOT of expensive 3590 tapes. If you take the
round tapes and move them into the VTS, they go into the disk cache as
"virtual" volumes, then migrate out to the 3590 tapes "stacked" together so
you make good use of the 3590 tapes.
Now TSM does not put each file it backs up on a tape as a separate file. It
glops them altogether in one BIG FILE file that grows until it fills the
entire tape. If you send the TSM tapes to a VTS, it writes until the
"virtual" volume is full. The max size of a "virtual" volume is set by the
person who configures the VTS. Let's assume for argument that you set the
max virtual volume size to 2 GB.
So in a VTS, TSM writes backup data into one big file that can grow to 2 GB.
That usually works pretty well for people during backups. Virtual volumes
go out to the VTS cache (disk pool), and then migrate out to a 3590 tape.
The trick is that the entire 2 GB "virtual volume" migrates as a unit.
The performance problem usually hits when you want to do a restore. You may
want to restore one TSM file that is only 1 MB; but when you tell TSM to do
the restore, it tries to "mount" the virtual volume, which means it has to
go to the 3590 tape, and destage the WHOLE 2 GB "virtual volume" back to
the disk cache before it can start reading.
So (1) the destaging of the whole 2 GB virtual volume takes time, and (2) it
"pollutes", or uses up, your disk cache, which then affects performance for
the next request.
Consider what a problem that can cause, if you try to create your COPY POOL
tapes AFTER the "virtual volumes" have migrated out to the 3590's - EACH
VOLUME has to be "destaged" back to the disk cache before it can be read by
TSM. That causes a whole lot of thrashing and slows things down.
So the design of a VTS is optimal for SMALL files on tape, not for
applications like TSM or DFHSM that, by design, write to tape until a whole
tape is full.
The VTS can still work nicely for TSM, IF you have a lot of disk cache space
(the bigger the cache in the VTS, the more it costs), and IF you have a low
level of destaging activity.
Hope that helps..
************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu
"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************
|
