ADSM-L

Re: [ADSM-L] Replacing tape drives (or "there has to be a better way")

2009-07-09 19:38:47
Subject: Re: [ADSM-L] Replacing tape drives (or "there has to be a better way")
From: "Costa, Justino" <justino.costa AT LOGICA DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 10 Jul 2009 00:37:02 +0100
There must be a reason why sandiscovery defaults to off on non-windows
platforms.

Anyway, I think you're right and that *should* be the correct behavior
of SANDISCOVERY=ON.

However, I prefer to stick with persistent binding and tight control on
SAN changes. This way, I can at least avoid spending time on false
positives like this one described here
http://www-01.ibm.com/support/docview.wss?uid=swg1IC59807, even for the
latest 5.5.x and 6.1.x versions.

jmC


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Wanda Prather
Sent: quinta-feira, 9 de Julho de 2009 18:11
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Replacing tape drives (or "there has to be a
better way")

I've been following this thread and have a question about AUTODETECT:

I've seen this message:
ANR8955I Drive drive name in library library name with serial number
serial number is updated with the newly discovered serial number serial
number .

as a result of having the drives defined with AUTODETECT=YES and also
SANDISCOVERY ON with the appropriate HBA library installed.

Can anyone expand on why this does or doesn't always work when changing
a drive serial #?  Or does it only work when the device number changes?

W


On Thu, Jul 9, 2009 at 12:12 PM, Costa, Justino
<justino.costa AT logica DOT com>wrote:

>
>
> 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.
>


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.

<Prev in Thread] Current Thread [Next in Thread>