ADSM-L

Re: Changes to Tape Management hardware in Data Center

2004-10-15 16:18:05
Subject: Re: Changes to Tape Management hardware in Data Center
From: "Gee, Norman" <Norman.Gee AT LC.CA DOT GOV>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 15 Oct 2004 13:14:49 -0700
Shannon,

I have a fairly small shop.  I currently have about 5 TB of managed data on
primary tape pool and about 250 GB nightly backups and about 70 servers.  I
moved away from the VTS long before I got to this size

When I did restores from the VTS, it took many hours.  Many of the files
being restored span multiple 3490 virtual volumes.  With the additional
staging time required, this easily double or triple the expected restore
time. This was for my primary backup pool. I always sent my archives to
native 3590 H drive K length tapes.

On my disk migrates to VTS, somehow I always ended up staging in my filling
backup pool volumes.  This is a factor on how much disk cache you have.
After you append to a volume, the VTS will write to the 3590 and invalidate
the original location.

On my reclamation, I had many tapes that appears almost empty, but had one
file that span multiple tapes.  When these tapes are reclaim, TSM will stage
in and reclaim every tape that file span.  Sometimes I thought I only had
one tape to reclaim, but that one tape brought in 5 others.  After TSM has
finished its reclamation, then the VTS will start reclaiming its native 3590
tapes.  The VTS has some of the same intelligence as TSM.  TSM reclamation
will leave lots of free space on the VTS physical tape store and then the
VTS will need to be reclaim.  I was reclaiming daily to keep up.

With 3590 H extended length cartridges holding about 60 GB native, I reclaim
once a week on cartridges half empty.  A half empty cartridge will take
about one hour to reclaim.

You mention you wanted to turn collocation on the VTS.  What happens if the
volumes TSM wants to mount for you archives is not in disk cache, then all
these volumes must be staged back in.   Depending on how many archives, this
could take some time. VTS is best for volumes that will never be appended
to. This is the same reason not to use the VTS for your DFHSM ML2 migrate.

Imagine a single retrieve of 50 virtual volumes, that could be an extra 4
hours of staging time.

A normal stage in process will take 4 to 6 minutes and the average native
tape mount is about 90 seconds.

If you have enough native drives or can get them, I would always go native.
Leave the VTS for what it was design for, stacking lots of small tape data
sets to large tapes.  TSM will monitor your tape usage, and will fill your
3590s to max capacity with little wastes.

Norman Gee



Thanks for the responses!  Here is the paragraph from IBM Redbook #
SG24-2229-03 that I based my plan for sending TSM Archives to the VTS.

Recommendations for VTS usage
Use VTS for Tivoli Storage Manager archiving: Use VTS for archiving and back
up of large
files or data bases for which you don't have a high performance requirement
during back up
and restore. VTS is ideal for Tivoli Storage Manager archive or long term
storage because
archive data is not frequently retrieved. Archives and restores for large
files should see less
impact from the staging overhead. Small files, such as individual files on
file servers, can see
performance impacts from the VTS staging. (If a volume is not in cache the
entire volume
must be staged before any restore can be done).

Norman, how much data were you talking about in your Primary pool on the
VTS?  And how many nodes were you backing up? I may have to re-think this if
reclamation is going to be a problem. I have reclamation going all day on
weekdays, to keep up with all the storage pools, and the Archcart stgpool
only takes about 4 hours a week to complete, it's our easiest one!



I at one time had my primary backup pool go into a VTS.  Mine is a 3494-B18,
older model.   TSM likes to append to tape volumes until they are full. The
recall process to stage a virtual volume from tape back to disk cache will
take from 4 to 6 minutes and then TSM will start appending the tape and then
it is written back to tape back end.  When you start tape reclamation, it
will take 4 to 6 minutes to load each 800 MB volume that needs to be
reclaim.  Tape reclamation is a real pain,  at one time I was reclaiming 50
volume daily.  I had 1200 virtual volumes before I decided to convert it all
to native 3590 cartridges.

I backup my database to VTS, but my offsite I take a DB SNAPSHOT to a 3590
cartridge.

-----Original Message-----
From: Steve Harris [mailto:Steve_Harris AT HEALTH.QLD.GOV DOT AU]
Sent: Thursday, October 14, 2004 4:38 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Changes to Tape Management hardware in Data Center

Shannon,

What was the reason for purchasing the VTL?  I'd surmise it is probably to
do tape consolidation on your mainframe operations.

*caveat! I have not actually used a 3494 VTL*

Past posts here have indicated that TSM is not a good fit for the VTL
because of the overhead of staging data that will only be used once and then
destaged.

I'd have to question why there is a perceived need to keep the archives in
3480 format.  I can think of no reason to when native 3590s are available,
other than a larger number of available drives.  Sure, copy them over that
way at conversion time if there is a co-existence issue with the new and old
libraries, but new ones, nah.

I understand that the VTL can be logically split into a native library and a
VTL.  I'd suggest for TSM that you use the native library. See the other
posts earlier today about how to migrate to the new media.

Regards

Steve

Steve Harris
AIX and TSM Admin - ex mainframer 1980-1997
Queensland Health, Brisbane Australia


I do have a question here about backing up the TSM database. Will it be
possible to do some kind of DB Backup to the VTS and still keep my DB
Series that is going offsite?

       2.      In addition to the VTS and our current Magstar, we are
adding a 3494 -D14 and a 3494 -D12, that have a total of (6) 3590E drives.
As with the Magstar, it will use the 3590J cartridges but will they should
hold more data because of               the difference between the Magstar
3590B drives vs. the 3590E drives on the new ATL.  The following is the
how             this hardware change will have an effect on our TSM backup
environment,