I don't care if the serial number changes.
In one of the sites I manage, I have 47 drives in use by 1 library
manager, sharing them with 4 servers and 60 storage agents. This results
on more than 1400 paths defined on the library manager.
As each path must match the machine device, manually redefining a drive
and it's paths (due to serial number change) it's an headache and, most
importantly, a very time consuming task.
So, I manage this with a script that reads a config file, with server,
sta, libs and drive's characteristics and it outputs all the define,
delete, update drive and update path commands (among others).
As such, when I need to replace a drive or update the device special
file of a drive instance, I simply run the script, grep the output and
pipe it directly to another script.
Replacing a drive in this way turns out to be as simple and as fast as
(for example):
If I need to replace drive 23, the procedure is more or less like this:
Remove drive:
1) run the script greping for "delete" path of drive 23 => seconds
2) run the script greping for "delete" drive drive 23 => seconds
3) prepare acsls for drive change => couple of minutes
Change HW:
4) Do the manual work of replacing the failed drive for a new one
=> support task, don't care how long it takes (sort of ;-)
5) Update operating systems device drivers if needed => It depends...
Add drive:
6) update acsls config for the new drive => couple of minutes
7) run the script greping for "define" drive 23 but leave it offline =>
seconds
8) run the script greping for "define" path for drive 23 => seconds
9) put drive nline and audit the library when possible (no activity on
the other drives) => a couple of minutes
Total time spent = minutes !
jmC
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Roger Deschner
Sent: quinta-feira, 9 de Julho de 2009 16:07
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Replacing tape drives (or "there has to be a
better way")
NOW you tell me. I just went through a terrible time replacing a HP
LTO-4 drive in a library. After futzing around for several hours, I
wound up bouncing the TSM server. Other vendors (Sun/STC, HP...) aren't
sympathetic to requests to change the drive serial number.
I don't think serial number changing is a realistic solution to this
issue. It kinda takes away the whole point of serial numbers in the
first place. Perhaps I should APAR the failure of DEFINE PATH, DEFINE
DRIVE, etc to deal with a drive swap and serial number change. (AIX
5.5.1 TSM server)
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
Academic Computing & Communications Center
On Wed, 8 Jul 2009, Len Boyle wrote:
>In fact we found out that for lto-3 and lto-4 tape drives in an IBM
3584 library, it is required that they change the serial number to
match the old tape drive. Because IBM tracks the drives by serial number
for maint contracts. This we found when the serial numbers that we send
in for a maint contract renewal were kicked out as field engineering
had not been updating the serial numbers. But not for lto-2 tape drives.
>
>len
>
>-----Original Message-----
>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
>Of Sean English
>Sent: Wednesday, July 08, 2009 11:47 AM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: [ADSM-L] Replacing tape drives (or "there has to be a
>better way")
>
>Zoltan,
>
>The majority of our TSM servers are AIX and we do have a setup where we
>share multiple library clients with one library. When we have IBM CEs
>come out and replace drives, they just change the serial number on the
>new drive to match the old drive they are replacing. Apparently there
>is a way to do that on the drive itself.
>
>Thanks,
>Sean
>
>
>
>
>
>
>Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
>Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>07/08/2009 11:30 AM
>Please respond to
>"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
>To
>ADSM-L AT VM.MARIST DOT EDU
>cc
>
>Subject
>[ADSM-L] Replacing tape drives (or "there has to be a better way")
>
>
>
>
>
>
>I need thoughts/suggestions/help on how to deal with SAN attached tape
>drive replacements when a library is shared amongst 5-servers.
>
>We just has a drive replaced, therefore giving us a new serial number
>(3494ATL - TS1130). All servers that use these drives/libraries are
>RedHat Linux and use very current lin_tape drivers.
>
>Currently, the method we use is to bounce each server so the system
>rescans the SAN and gets the new serial number.
>
>In the past, just stopping the TSM server and then restarting the
>lin_tape driver would often be enough. Now with the latest lin_tape
>drivers, I don't see the lin_taped daemon running any more.
>
>Yes, I have tried updating the paths on the library manager server and
>telling it to autodetect but that didn't help.
>
>There has to be a better way! If you have a similar configuration, how
>do you handle this scenario?
>
Please help Logica to respect the environment by not printing this email /
Pour contribuer comme Logica au respect de l'environnement, merci de ne pas
imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie
so Logica dabei die Umwelt zu schuetzen / Por favor ajude a Logica a
respeitar o ambiente nao imprimindo este correio electronico.
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege. It should not be copied,
disclosed to, retained or used by, any other party. If you are not an intended
recipient then please promptly delete this e-mail and any attachment and all
copies and inform the sender. Thank you.
|
