>>" the same thing that happened to the 3466 (i.e. Tivoli does not
recognize it or support it as a true TSM platform) IS GOING to happen to the
3494 system, since it is also somewhat based on the same concept and that if
we implement this, we were almost sure to lose support from Tivoli in the
near future. "
That is a VERY weird statement to make. There are a LOT of 3494
installations out there - lots more than there ever were for the 3466, which
is a "package" of existing hardware & software. And it's the larger
installations (read, those with MONEY) that are using the 3494/3590
technology. It's IBM's premier tape techology, and not likely to go away
any time soon. I would be more inclined to think the reason for the
statement is that the Tivoli person you spoke to is clueless about IBM
hardware (no big surprise).
But that aside, performance IS an issue with a VTS & TSM. It depends on
your load, mostly, and your time constraints. It can work well, depending
on your environment; but you should be VERY CAREFUL about your requirements
planning before you do this.
TSM is a worst-case application for a VTS. Not because TSM is doing
anything wrong, but because ANY application that writes single-file tape
images that FILL THE TAPE VOLUME is non-optimal for a VTS. This applies to
DFHSM or DFDSS tapes on OS/390 (mainframe) as well.
The whole intent of the VTS design was to accept small files that were
originally directed to older, small-capacity tapes, store them on disk as
"virtual" tape images, then let the virtual tape images get migrated off and
stacked together on new large-capacity tapes. When you want to access
something on a "Virtual" tape volume again, the VTS has to stage the data
from the tape back to the disk before you can use it.
If you are talking small application files, the VTS works wonderfully. But
because TSM (and any similar application) writes ONE large file that fills
the "virtual" tape, the WHOLE TSM "volume" gets written to disk, then staged
out to tape. So far so good. But when you want to do a restore of a
particular file, the WHOLE TSM volume gets staged back in, not just the
piece you want.
So it's a performance issue. I know people who use a VTS with TSM and are
happy with it. Should work just fine if you have a light load.
I also know someone who backs up many GB of data a night with TSM that gets
sent to a VTS, then migrated out to tape. Then when they want to copy those
"virtual" tapes to create their offsite copy pool ---- takes a lifetime,
because each volume has to be staged back to disk first, just to do the
copy. They have great difficulty meeting their time windows becuase of the
staging time required, and they are less than 100% happy with the results.
So THINK TWICE about your requirements before making TSM (or DFHSM, or
anything that writes single-file tapes) depend on a VTS. Make sure you
understand the performance issues, and that the performance limitations will
be acceptable in your environment.
Talk to someone on the OS390 support staff about the VTS that exists; how
new it is; whether they have sufficient drives and cache capacity to deal
with the load you intend to add. You can improve the performance of the VTS
in cases like yours by adding more disk cache. Just do your homework ahead
of time...
My opinions and nobody else's,
Wanda Prather
|
