Zlatko,
I don't thing there is a performance issue writing TSM data to a VTS. The
reasons you
probably would avoid sending TSM data to a VTS are:
1. With a VTS, you get your biggest "bang for the buck" with applications
that typically
do not fill an entire tape. Many mainframe applications typically do not
create individual
files that fill entire tapes. That means with a VTS, the physical space
occupied by each
logical volume is only as big as the individual dataset. Sure some jobs
stack one file
after another to fill a tape but many jobs usually do not. Applications
like DFHSM and
TSM will keep appending to a tape until it is completely full. If they can
fill a high
capacity tape, like a Magstar tape, then why not create them on a "native"
3590
versus in the VTS? The main idea behind the VTS is to fill tapes for
applications
that are not designed to do it on their own or to basically fill your high
capacity
tapes as much as possible.
2. Since virtual volumes are removed from the VTS disk cache on a first in
first out
basis, depending the average disk cache life of your virtual volumes, many
of your
TSM tape mounts could result in "backend" physical tape mounts to recall
the logical
volume back to disk so TSM could append more data to the tape. Generally
workload
that generates lots of VTS backend tape mounts might not be best for the
VTS and
can lead to a condition IBM calls thrashing.
It can depend on things like your workload, number of backend drives, etc.
3. The VTS performs reclamation in the similar manner to TSM. Over time,
as logical
volumes expire, when a stacked(physical 3590 VTS tape) has only a few
"good" logical
volumes left, those logical volumes are eligible to be moved to another
stacked volume
to be sure the 3590 tapes are filled to capacity. You set a reclamation
threshold just
like in TSM. Now imagine a scenario where stacked volume 999999 has two
logical
volumes left on it, 100000 and 100001, and 999999 is now eligible for
reclaim. Logical
volumes 100000 and 100001 are moved to stacked volume 999990 and 999999
is now a scratch volume for the VTS. This operation required two of your
VTS backend
drives to move the logical volumes from one stacked volume to another. Now
say
10 minutes later, logical volume 100000 happens to be a TSM volume and it
only
has 20% valid data left. Volume 100000 is now eligible for reclaim so TSM
asks
for the volume and it is now recalled to the VTS disk cache so it can be
used. The
data is move from logical volume 100000 to 100002. Now TSM marks 100000 as
scratch and now the space on stacked volume 999990 is free space. So
basically
what just happened is. The VTS moved a volume from one physical tape to
another. Then TSM comes along shortly after and scratches one of the
volumes we
just moved. As you can see, a whole lot of physical mounts and recalls can
result by
putting TSM on the VTS.
4. Another thing to consider is, say you are doing a bare metal recovery
of a large
client and nearly all the VTS tape volumes are no longer in the VTS cache.
Your
restore would have to wait for each tape to be recalled from the stacked
physical
tape to the VTS cache before TSM could use the tape in the restore. This
could
theoretically increase your restore elapsed time.
Hope this helps,
Jeff Connor
Niagara Mohawk Power Corp
Zlatko Krastev/ACIT <acit AT ATTGLOBAL DOT NET>@VM.MARIST.EDU> on 12/06/2001
09:53:28 AM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: TSM and VTS - virtual volumes
If VTS is artifically configured TSM server backend this leads to another
question - virtual volumes performance.
We read recently on the list that TSM using VTS is having not so good
performance. Is this true or not I cannot prove and cannot have clear
opinion.
But virtual volumes are by definition TSM server backing up to TSM server.
And if TSM-TSM performance is good why not TSM-VTS (i.e. TSM) performance
be good? And how we can define "good" or "better" or "average"? If TSM-VTS
is performing "not so good" is TSM-TSM having similar performance (measured
in GB/hour or something similar)? If both perform at comparable speeds can
we say both are "not so good" or TSM-TSM performs better?
Sorry for asking so many questions. I have no mainframe (and VTS) to answer
them by myself.
Zlatko Krastev
IT Consultant
Michael Bartl <michael.bartl AT CW DOT COM> on 03.12.2001 10:48:11
Please respond to michael.bartl AT de.cw DOT com
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: TSM and VTS
I remember from an IBM presentation a few years ago that the technology
behind VTS is TSM. So using a VTS library on a TSM server means stacking
the same intelligent tape management technology for two instances. This
can eliminate some of the benefits.
On one hand, when collocation is "inactivated" by VTS, access
performance to your data may drop. On the other hand, VTS uses quite a
lot of disk caching to improve performance. It depends on the structure
of a TSM servers data, whether the gain or loss in performance will be
stronger.
Best regards,
Michael
--
Michael Bartl mailto:michael.bartl AT cw DOT com
Michael Bartl mailto:michael.bartl AT cw DOT com
Office of Technology, IT Germany/Austria Tel: +49-89-92699-806
Cable & Wireless Deutschland GmbH. Fax: +49-89-92699-302
Landsberger Str. 155, D-80687 Muenchen http://www.cw.com/de
Bill Mansfield wrote:
>
> The fact is that TSM does not always write tapes 'til they are full. If
> you have a bunch of small nodes using collocation or backupsets, you can
> wind up with a lot of expensive tape with little content. Using the VTS
> would allow you to stack these nearly empty tapes onto one tape. I'm not
> sure whether this defeats the purpose of collocation, since I'm not sure
> that the virtual tapes will stay collocated inside the VTS, though.
>
> _____________________________
> William Mansfield
> Senior Consultant
> Solution Technology, Inc
>
|
