Networker

Re: [Networker] [I] Re: [Networker] Adding a dedicated storage node in v7.3.2

2006-11-30 07:37:41
Subject: Re: [Networker] [I] Re: [Networker] Adding a dedicated storage node in v7.3.2
From: "King, David" <dking AT EASTMAN DOT COM>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Date: Thu, 30 Nov 2006 07:20:04 -0500
The drive logical name reshuffling is a Windows 'feature', due to the
Windows SCSI scans assigning the logical name ( i.e. \\.\Tape0) to the
first drive it finds, etc.

We use QLOGIC cards and have enabled the persistent binding on them.
This has GREATLY reduced the reshuffling.  You may see some reshuffling
after the binding, but if you check 'inquire', you will probably see
some logical names missing, or some missing drives due to the drive
going offline.   Check your Device Manager and see if there are some
tape drive drivers missing. Reinstall the missing drivers and do another
inquire, and they should show up again. However, when you do this, the
drives may reshuffle again.  Reboot your server (I sometimes have to
reboot three times) to get everything back to the way it was before.

Also, if the first drive (lowest WWN) changes, your library will
probably change SCSI address.  You have to edit the Autochanger in
Networker if so.


David L. King


-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of Matthew Robert
Sent: Wednesday, November 29, 2006 5:32 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: [I] Re: [Networker] Adding a dedicated storage node in v7.3.2

This email is to be read subject to the disclaimer below.

Hi Jerome,

I admin a medium sized Legato installation run on Widnows 2k3. To
prevent the drives from changing ID's upon reboots you need to enable
persistant binding in your HBA management utility - HBAnyware from
Emulex is good if you use Emulex cards. Basically Windows is handing out
any old SCSI ID to the drives as it detects them. Persistant binding
will ensure that you get the same ID on each device.

I have seen the ame inventory behavior as what you are experiencing, but
I cant for the life of me remember what we did to fix it - if I remember
I will let you know,

Cheers,
Matt






"Landwehr, Jerome" <jlandweh AT HARRIS DOT COM> Sent by: EMC NetWorker
discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>
30/11/2006 12:58 AM
Please respond to
EMC NetWorker discussion <NETWORKER AT LISTSERV.TEMPLE DOT EDU>; Please respond
to "Landwehr, Jerome" <jlandweh AT HARRIS DOT COM> All email is logged and may
be reviewed - Refer policy FP206

To
NETWORKER AT LISTSERV.TEMPLE DOT EDU
cc

Subject
Re: [Networker] Adding a dedicated storage node in v7.3.2






Firstly - use 'jbedit' rather than jbconfig - you enter most of the info
on the command line, repeating for each device

Yes - deleting a jukebox removes any association of what tapes it was
holding - as one would expect

I'm not personally a NT admin, but from what I remember RSM is the
culprit in the drive mis-ordering - not that it is ever completely fixed
in my experience

HTH
Jerry

-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of Andy Garman
Sent: Wednesday, November 29, 2006 6:33 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: [Networker] Adding a dedicated storage node in v7.3.2

Hello,

    Our v7.3.2 backup server has licences for up to 100 clients, 5
shared (FC LTO3) drives and 17 dedicated storage nodes. When configuring
new storage nodes, we have been unable to follow the suggested and
logical procedure in the JVM gui as we are requested for storage node
licenses which we do not have - we have dedicated storage node licenses
only. Our workaround has been to use jbconfig, assigning multiple remote
paths for each physical drive, which causes dedicated storage node
licenses to be allocated automatically.

    However, this process involves deleting and recreating the jukebox
every time a new storage node is needed or an existing jukebox changes
its device paths. This was inconvenient enough under v7.3, but since the
upgrade to v7.3.2, when the jukebox is recreated, the tape labels are no
longer read in
- we have to reinventory 400 slots each time, taking 3-4 hours).

    So I have 3 questions which some helpful people might have useful
suggestions to:

- has anyone got the standard procedure for adding new storage nodes to

work? Or just a better workaround?

- has anyone else observed/solved the same jukebox problem we have seen
of tapes needing re-inventoried after jukebox recreation? I've checked
obvious things like barcode scanner enabled and labels to match, but
might have missed something else?

- the two problems above are exacerbated by the tendency for windows
servers to change their device pathnames on reboot. Do any windows
admins have any tips for this unix admin to pass on to his windows admin
colleagues to ensure device persistence across system restarts?

Many thanks in advance,


Andy Garman
Computing Services
University of Edinburgh
Scotland UK.

To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or via RSS at
http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or via RSS at
http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER





--------------------
NOTICE - This communication contains information which is confidential
and the copyright of Ernst & Young or a third party. 

If you are not the intended recipient of this communication please
delete and destroy all copies and telephone Ernst & Young on 1800 655
717 immediately. If you are the intended recipient of this communication
you should not copy, disclose  or distribute this communication without
the authority of Ernst & Young.

Any views expressed in this Communication are those of the individual
sender, except where the sender specifically states them to be the views
of Ernst & Young.

Except as required at law, Ernst & Young does not represent, warrant
and/or guarantee that the integrity of this communication has been
maintained nor that the communication is free of errors, virus,
interception or interference.

Liability limited by a scheme approved under Professional Standards
Legislation.
--------------------


If this communication is a "commercial electronic message" (as defined
in the Spam Act 2003) and you do not wish to receive communications such
as this, please forward this communication to unsubscribe AT au.ey DOT com

To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or via RSS at
http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER

To sign off this list, send email to listserv AT listserv.temple DOT edu and 
type "signoff networker" in the body of the email. Please write to 
networker-request AT listserv.temple DOT edu if you have any problems with this 
list. You can access the archives at 
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER