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
>>> SBach AT MGE DOT COM 15/10/2004 2:33:11 >>>
Currently preparing changes to our tape hardware in the Data Center.
Current TSM Server is Version 5, Release 1, Level 7.0 on OS390 2.10 MVS
Mainframe. We are moving to ZOS sometime before
January. The change at this time is our tape environment. Will probably
give too much detail here but I need to completely understand the
implications of the changes. If anyone can think of something I may have
missed in my implementation plan I sure would appreciate a response.
Currently we have two ATL'S,
1. A Sutmyn 5600 Memorex ATL, has 3490 drives and uses 3490
cartridges with 800 MB's
(Currently 98% of this ATL is used just for TSM Archives)
2. An IBM Magstar 3494, has 3590B drives and uses 3590J
cartridges (about 12 GB each) all tape racks are full inside this ATL.
3. TSM backup nightly incremental process,
a. The nightly incremental backups go to a DASD
primary diskpool.
b. The data is copied to an Offsite copypool (Magstar
3590J) to go offsite.
c. Before the next nightly incremental backup the
DASD primary diskpool data is migrated to a primary sequential
stgpool on the
Magstar (3590J) carts.
d. Backupset's are sent directly to the Magstar
(3590J), ejected but kept onsite.
e. All the weekly, monthly, and yearly Archives go
directly to tape on the Memorex (3490 carts) and are kept onsite.
The following are the new hardware changes that will have an effect on our TSM
archive environment,
1. The Sutmyn 5600 Memorex ATL is getting replaced with an
IBM Virtual Tape Server 3494-B18 VTS with 432 GB of cache. It will
have four 3590E control units each with 16 drives, for a total of 64. It will
connect to an IBM 3494 D12 with four 3590E drives for the
VTS. The virtual tape volumes in cache will be defined
exactly as the Memorex tape volumes, 3490 cartridge with 800
MB's. All data currently going to the Memorex that does not go offsite
will be diverted to VTS cache, this includes all the TSM Archives.
Eventually, the data in the VTL cache will migrate to the 3494
D12. They will be 3590E drives and using 3590K cartridges, which should
hold between 40-50 GB's each.
a. Supposedly, TSM will not know the difference
between the Memorex cartridge volumes and the VTL volumes because as they will
be defined the same. As a result of this, my plan for the TSM
archives configuration is as follows.
i. Create a new primary sequential storage pool
example- ARCHCART02
ii. Keep collocation ON to reduce the number of VTS
volumes required for a full retrieve if it was ever requested. Collocation with
the VTS will not minimize the physical tapes used but will minimize the
logical volumes used.
iii. The TSM archives will be diverted to the new
ARCHCART02 stgpool through an MVS system change, TSM should never know the
difference. After archives start going to ARCHCART02, start moving the
data from the old ARCHCART to ARCHCART02.
iv. Currently reclamation for archives is done once a week,
I should only need to do this once a month during non-peak hours
now.
v. I can set a much higher MOUNTLIMIT with defining
the device class as there will now be 64 virtual drives available.
MOUNTRETENTION can now be set to zero.
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,
a. The nightly incremental backups will still go to
DASD.
b. The OFFSITE sequential copy pool will stay in the
current Magstar along with any other data cartridges that need to go
offsite or be ejected for some reason.
c. The TSM data on DASD will now migrate to the new
ATL with the 3590 E drives. Because the current Magstar tape racks are
completely full, we have to eject between 100-200 carts each week make it
through the lights-out weekend. Reclamation during the
weekdays of both the primary BACKCART01 and OFFSITE copy pool call most of
those tapes to be put back in.
d. Although the cartridge sizes are the same, the
tape drives are different. My plan for the TSM incremental backup
configuration is as follows.
i. Define a new sequential primary storage pool for
the new ATL example-BACKCART02
ii. Turn collocation on for faster restores.
iii. The TSM incremental backups will then be migrated to
the new BACKCART02 stgpool. After the backup data starts going to
BACKCART02, I will set reclamation on the old BACKCART01 to point to
BACKCART02.
iv. Because the cartridges in BACKCART02 will hold
more than those already created in BACKCART01, we will not put these carts into
the new ATL. They can be read but not written to until the data is
expired and the tape is scratched. I will move the
data from BACKCART01 to BACKCART02 a little bit everyday until done.
Can anyone see a problem with these plans that hasn't occurred to me?
Anything I should take into consideration or improve upon? I am open to
all ideas & suggestions. I'm hoping to get this all finished before we
move to ZOS, at which time we will upgrade our TSM server version to 5.2.
Thank you for your time,
Shannon
Operations Analyst
Madison Gas & Electric Co.oe. As a result of this, my plan for
Data Center Services
Information Management Services
***********************************************************************************
This email, including any attachments sent with it, is confidential and for the
sole use of the intended recipient(s). This confidentiality is not waived or
lost, if you receive it and you are not the intended recipient(s), or if it is
transmitted/received in error.
Any unauthorised use, alteration, disclosure, distribution or review of this
email is prohibited. It may be subject to a statutory duty of confidentiality
if it relates to health service matters.
If you are not the intended recipient(s), or if you have received this email in
error, you are asked to immediately notify the sender by telephone or by return
email. You should also delete this email and destroy any hard copies produced.
***********************************************************************************
|
