ADSM-L

Re: [ADSM-L] Tape library possible replacement - push/pull

2013-02-14 13:56:03
Subject: Re: [ADSM-L] Tape library possible replacement - push/pull
From: "Prather, Wanda" <Wanda.Prather AT ICFI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 14 Feb 2013 18:02:32 +0000
Hi Zoltan,

What is your plan if you have to do this for a DR drill?  Shouldn't be any 
different.

Use a select or a Q LIBV to get a list of all the tapes that are checked in 
with their "owner" attribute.
Move all the tapes to the new library, close the doors and let the library scan.

Then take your list and turn it into CHECKIN VOL xxxxxx status=private 
owner=blah
That puts your library inventory right back the way it was, yes?

Wanda


---Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Zoltan Forray
Sent: Thursday, February 14, 2013 11:23 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Tape library possible replacement - push/pull

Well, it looks like this is going to happen and yes it will be a 
pull-out-3494-push-install-3584/TS3500.

We are trying to make this transition as easy as possible so I have some 
questions about prepping for this.

One issue is we have 2-library manager TSM servers.  This was done primarily 
for redundancy in case there were major problems with a sole-LM there was a 
backup we could switch to (our disk pools fill up all the time).

Our current plan is to manually/physically unload the tapes (1400+) from the 
3494, the day before the deinstall starts (8-hours for dis-assembly and 
removal).  Since there are 2-LM, we would need to somehow keep them separated 
since they would have to be reloaded into the 3584 in a similar fashion.  Since 
I can't think of how we could logically separate them while physically removing 
them, my thought/question is, would it be simply to move to a single LM server, 
right now while still using the 3494.

Anybody else perform a tape library transition between like-models/drives?
 All war stories are welcome.

On Mon, Feb 4, 2013 at 2:43 PM, Remco Post <r.post AT plcs DOT nl> wrote:

> On 4 feb. 2013, at 20:32, Zoltan Forray <zforray AT VCU DOT EDU> wrote:
>
> > Thanks for the "explanations" but I still don't understand.  Does 
> > the
> fibre
> > channel connection replace the 3494 IP link?  I think read that you 
> > still need IP for CLI?
> >
>
> yes, there is an IP interface (or usually even multiple for GUI and 'CLI'
> access as well as SNMP.
>
> > Are the drives still separate when it comes to paths (other than 
> > being defined as part of a library)?  Is the fibre connection to the 
> > library
> the
> > way the library communicates with the drives (like the old RS422 in 
> > the 3494)?  or how the TSM library manager server communicates with 
> > the library/TS3500?
> >
>
> there is some communications between the drives and the library, but 
> as to which protocol is used... I don't know (nor do I care)
>
> > With the 3494, you used a driver called ibmatl which used
> /etc/ibmatl.conf
> > (this is RedHat Linux) to define the IP/host connection to the library.
> > How do you configure a TS3500?
>
> place a control path on one or more drives, do your thing to detect 
> scsi devices (autoconf) and off you go... the atl is lung on the drives 
> where you defined the control path (as is customary for scsi libraries).
>
> >
> > On Mon, Feb 4, 2013 at 2:06 PM, Remco Post <r.post AT plcs DOT nl> wrote:
> >
> >> On 4 feb. 2013, at 19:43, Zoltan Forray <zforray AT VCU DOT EDU> wrote:
> >>
> >>> As this project moves forward, I am doing more and more research 
> >>> since
> I
> >> am
> >>> unfamiliar with this beast (3494 has been my baby since it was
> installed
> >> in
> >>> 1995).
> >>>
> >>> The book talks about "*to communicate with a server, the IBM 
> >>> System
> >> Storage
> >>> TS3500 Tape Library uses a Fibre Channel interface (also called a
> >> port).*"
> >>>
> >>> Why?  What is this "fibre channel interface" used for?   The 3494 use
> IP
> >> to
> >>> communicate/manage the library and the drives inside the library 
> >>> used
> >> fibre
> >>> plus an RS422 connection to the library manager.
> >>
> >> Because that is the way a 3584 works.... 'in band'. leftovers from 
> >> when
> the
> >> 3584 was still midrange and midrange libraries are controlled in band.
> BTW,
> >> with modern ts3500's features like control path failover are 
> >> inclusive
> and
> >> losing one tape drive does not mean that the library is uncontrollable.
> >>
> >>
> >>> --
> >>> *Zoltan Forray*
> >>> TSM Software & Hardware Administrator Virginia Commonwealth 
> >>> University UCC/Office of Technology Services zforray AT vcu DOT edu - 
> >>> 804-828-4807 Don't be a phishing victim - VCU and other reputable 
> >>> organizations will never use email to request that you reply with 
> >>> your password, social security number or confidential personal 
> >>> information. For more details visit 
> >>> http://infosecurity.vcu.edu/phishing.html
> >>
> >> --
> >>
> >> Met vriendelijke groeten/Kind regards,
> >>
> >> Remco Post
> >> r.post AT plcs DOT nl
> >> +31 6 24821622
> >>
> >
> >
> >
> > --
> > *Zoltan Forray*
> > TSM Software & Hardware Administrator Virginia Commonwealth 
> > University UCC/Office of Technology Services zforray AT vcu DOT edu - 
> > 804-828-4807 Don't be a phishing victim - VCU and other reputable 
> > organizations will never use email to request that you reply with 
> > your password, social security number or confidential personal 
> > information. For more details visit 
> > http://infosecurity.vcu.edu/phishing.html
>
> --
>
> Met vriendelijke groeten/Kind regards,
>
> Remco Post
> r.post AT plcs DOT nl
> +31 6 24821622
>



--
*Zoltan Forray*
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will never 
use email to request that you reply with your password, social security number 
or confidential personal information. For more details visit 
http://infosecurity.vcu.edu/phishing.html