You're using SAN attachment though correct? (So it should work for us too.)
But, what does it buy you? (TSM will now notice when the paths are stewed?
Can storage agent detect this problem as well?)
I need to re-grab the docs on Atape. I heard something about it supporting
dynamic updates to the rmt numbers. (on AIX)
Maybe someday we'll get PCM (as in SDD for MPIO) like functionality for
tape.
Thanks, [RC]
"Ben Bullock"
<bbullock AT MICRON DOT COM> To: ADSM-L AT
VM.MARIST DOT EDU
Sent by: "ADSM: Dist cc:
Stor Manager" Subject: Re: Tape Drive
Serial #'s (WAS: Adding 3592's to a 3494)
<ADSM-L AT VM.MARIST DOT EDU
>
10/27/2004 03:13 PM
Please respond to
"ADSM: Dist Stor
Manager"
|-------------------|
| [ ] Secure E-mail |
|-------------------|
Wanda has it correct. In our little exercise, we deleted the
path and drives and then re-defined them. Indeed the new serial number
was discovered and displayed.
Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Prather, Wanda
Sent: Wednesday, October 27, 2004 3:57 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Tape Drive Serial #'s (WAS: Adding 3592's to a 3494)
Yes, for SCSI libraries, TSM now records the serial # of the tape
drives.
If you have a SCSI library, look at your devconfig file. (EVERYBODY:
You DO know where your devconfig file is, yes?) If not, run q opt to
find the location.
In your devconfig, you will see the DEFINE DRIVE and DEFINE PATH
statements that were logged when you originally set up your TSM drives,
BUT you will see that TSM has added the SN# and WWN for the drives
(assuming the drives are a type that can send that info back in response
to a TSM query).
TSM started doing this in 5.1, and it is not just a 359x issue.
The caveat is just what Ben pointed out: if you swap out a drive, the
SN# and the WWN no longer match what TSM has recorded in the DEFINE
DRIVE, and TSM won't talk to the new drive until you redefine it.
If your CE replaces a drive:
1) copy your devconfig to a safe place under another name.
2) Use the TSM admin GUI to delete the path for the removed drive
3) Use the TSM admin GUI to delete the drive
4) COPY the original DEFINE DRIVE command from the devconfig copy, MINUS
the WWN and SN#, and paste it back into a command window.
5) COPY the original DEFINE PATH command form the devconfig copy, and
paste it back into a command window.
That will recreate your drive definition without having to think too
much about it! TSM will go out and pick up the replacement SN# and WWN
on its own.
There is also a SERIAL# and WWN parm on the UPDATE DRIVE command, but I
haven't played with those.
People with Windows TSM servers don't even have to do either, you can
delete the path and drive, then use the device configuration wizard to
add it back.
Wanda Prather
"I/O, I/O, It's all about I/O" -(me)
.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Robert Clark
Sent: Wednesday, October 27, 2004 5:22 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Adding 3592's to a 3494
We're running a similar config, so I'm curious about the list response
on this one as well.
One additional question: I think I saw a message about TSM being able to
keep track of tape drives by their serial numbers. Anyone have a pointer
to docs on how this feature works, and what the caveats are, if any?
Thanks, [RC]
"Ben Bullock"
<bbullock AT MICRON DOT COM> To:
ADSM-L AT VM.MARIST DOT EDU
Sent by: "ADSM: Dist cc:
Stor Manager" Subject: Re:
Adding 3592's to a 3494
<ADSM-L AT VM.MARIST DOT EDU
>
10/27/2004 01:55 PM
Please respond to
"ADSM: Dist Stor
Manager"
|-------------------|
| [ ] Secure E-mail |
|-------------------|
Matthew (and others in the group),
Just this week we put in our 2 test 3592 drives and started
playing with them. These are sweet. So far they are running a little
over 2X the speed of the 3590E drives, and we have yet to test the
capacity.
We've been able to test out the alternate pathing, dynamic load
balancing, etc.. It's all through a SAN, so we have tested the zoning,
etc. Failovers work as expected with no interruption to the TSM server
at all. Very nice.
AIX 5.2, TSM 5.2.1.3, Atape 9.0.7.0, atldd 5.5.1.0, 3592 drives,
3490 library.
All has gone smoothly until we went to simulate a failed drive
where we would swap it out for a new one. It didn't go well, with TSM or
the OS not able to see the new drive correctly. When I tried to 'cfgmgr'
it back in, it gave me these errors:
root:># cfgmgr
Method error (/usr/lib/methods/cfgppa_isa -l ppa0 ):
0514-038 Error loading kernel extension.
Method error (/etc/methods/cfgtsmdd -l mt0 ):
0514-051 Device to be configured does not match the physical
device at the specified connection location. Method
error (/etc/methods/cfgtsmdd -l mt1 ):
0514-051 Device to be configured does not match the physical
device at the specified connection location.
I had to remove these 2 "mt" devices to get it to stop erroring.
That's a new one to me...
I have 2 questions:
1: During the installation of the tape drives the IBM CE asked
if we wanted "hard" or "soft" addressing. His instructions say to do
HARD, but then his support folks said "soft", what should it be? I'll be
calling this in to IBM, but was curious if anybody here had an answer.
2: On our switch we are zoning the drives and FC adapters by
WWN. Doing it this way, am I going to have to totally remove and
recreate a drive when I swap it out? (i.e. remove from TSM, the OS,
unzone the switch. Replace drive, re-configure it all back in.).
Thanks,
Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Matthew Glanville
Sent: Thursday, September 30, 2004 11:34 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Adding 3592's to a 3494
When we upgraded we needed a new library defined in TSM to use the
3592's with different private/scratch categories, and device class's,
drives, etc.. Not a different 'logical' library defined on the 3494
library manager. That may have worked too, but it depends on how
particular you want to be as to which drives/slots are available to each
host connected to the library.
3592's have been good. So far after 9 months use of 500 tapes and 6
drives.
2 tapes had I/O problems, no serious problem in data lost, TSM's
'restore volume' cleaned it up in minutes. some drives have just needed
code upgrades to remove minor problems. One had 'clean me' displayed
permanantly, it went way after that. One was replaced, but it was bad
from the factory on initial installation.
Try to do the code upgrades for the drives from the Host's fiber/scsi.
When the IBM SE pushed it via the Library manager it took hours instead
of minutes.
The web interface on the upgraded library manager is great!
No longer do you have to login to the library manager console to find
out why 'operator intervention' is required... You can check it from
your desk and decide to call in IBM to fix the problem or just unload
the tapes that wanted to come out of the I/O slots.
My biggest issue is that the server we have connected to those 6 drives
can't push data fast enough to them, they can go much faster!
Matthew Glanville
Eastman Kodak
========================================================================
======
IMPORTANT NOTICE: This communication, including any attachment, contains
information that may be confidential or privileged, and is intended
solely for the entity or individual to whom it is addressed. If you are
not the intended recipient, you should delete this message and are
hereby notified that any disclosure, copying, or distribution of this
message is strictly prohibited. Nothing in this email, including any
attachment, is intended to be a legally binding signature.
========================================================================
======
==============================================================================
IMPORTANT NOTICE: This communication, including any attachment, contains
information that may be confidential or privileged, and is intended solely for
the entity or individual to whom it is addressed. If you are not the intended
recipient, you should delete this message and are hereby notified that any
disclosure, copying, or distribution of this message is strictly prohibited.
Nothing in this email, including any attachment, is intended to be a legally
binding signature.
==============================================================================
|
