SCSI PATH Changing on fibre attached tape Librarys !!!

[Ross Humphryes]

Hi folks

We are having a problem with our fibre attached tape Libraries OR should I say we are having a problem with the order in which the Libraries are being recognised by our servers.

HP ProLiant DL380 with Windows server 2003/2000
HP EVA3000
HP 2Gbit Brocade 32port switches
HP KGPSA HBAs (with latest drivers)
MSL5026SL with NS E1200/E1200-160

We use Legato NetWorker 7.1.3 to backup our fibre attached servers which have Dynamic Drive Sharing enabled.

The servers recognise the NSRs, Librarys, and tape drives in the numeric order of the device path (command control port). The device path basically comprises of the SCSI bus, the SCSI target ID and the SCSI LUN on that target, in the following format:
"scsidev@scsi_bus.scsi_target_id.scsi_lun"

Here's an example:
scsidev@12.2.0:COMPAQ MSL5000 Series 0423|Autochanger (Jukebox), \\.\Changer2

scsidev@12.3.0:COMPAQ MSL5000 Series 0423|Autochanger (Jukebox), \\.\Changer1

The problem we have is that we are getting I/O errors in our backups and under investigation we are finding that the device path has altered (sometimes during backup), specifically the SCSI_TARGET_ID is changing.

Does anybody know what could possibly be altering the SCSI_TARGET_ID of our NSR/Library/Drive ???

Aditionally, is there any way we can manipulay the SCSI_TARGET_ID ???


Thanks very much

Regards
Ross

[Ross Humphryes]

BTW
Each server has a matching pair of FC HBAs. One connected to Switch1 and one connected to Switch2.

Library1 is connected to Switch1 Port0
Library2 is connected to Switch2 Port30
Library3 is connected to Switch2 Port31

We have SecurePath installed but we have ZONES setup on our switches to present the Librarys to all servers.

[Marino Meloni_1]

see my answer: http://forums1.itrc.hp.com/service/forums/bizsupport/questionanswer.do?threadId=956746

[Urban Petry]

I strongly recommend using persistent binding as well. This should be done on both the NSR (create a manually configured device map for each used fibre port on the NSR) also on the Windows servers (for Emulex HBAs use lputilnt.exe, don't know the equivalent for QLogic). This makes your system immune to intermittent device failures and/or removals, if - and only if - your backup application really directly takes to the SCSI addresses! Are you 100% sure that it is not using the shown windows devices names ("\\.\Changer1")? Because those names still can change depending on what devices are available upon system startup or device rescanning ...

Urban

[Ross Humphryes]

Thanks for your feedback.

Sounds like "Persistent Bindings" is the direction to go for.

Legato NetWorker (as far as I understand it) is dependant on the OS to present the tape devices. However, NetWorker provides its own Library device driver, the RSM is disabled. The thing is, if tape devices disappear from the OS and then come back the quite often tape drive device paths are on another Library. We have three Library's and five tape devices. Changer0 (tape0 & tape1) seem to be consistent BUT Changer1 (tape2 & tape3) and Changer2 (tape4) get confused and reordered because the OS seems to assign the device path based on the SCSI_TARGET_ID.

My goal is:
1. To ensure that the device path says
constant (does not change).
2. Devices stop disappearing.


It seems that I need to get a better grip of what exactly "Persistent Bindings" is and how I can check for it and implement it correctly on our HBAs.

The driver versions on our Compaq KGPSA-xx FC HBAs is: 5.4.82.16
Firmware: 3.821a

I have noticed that when I run the LPUTILNT.EXE utility and change the category to "Persistent Bindings" I see that are 3 defined but there seems to be also some unbound targets so I need to understand what exactly I need to do before I can put a plan in for change control.

Does anybody have any URLs for any How-To type documents for these Emulex/Compaq FC HBAs ?

Cheers for now!
Ross

[Urban Petry]

I don't think that the SCSI ID of the devices change, but only which Windows Tape Device (\\.\TapeX) is associated with which physical tape drive (in terms of port:id:lun). This is done by Windows and depends on numerous factors: are you running SP4 on your W2K machines? If yes are you also using Plug&Play-aware tape device drivers and can Legato cope with dynamic device addition/removal?

After you configured persistent binding (a document is attached) intermittent device disappearance should have less impact. But I would also track down what's causing those removals since this should not happen at all during normal operation ...

Urban

[Stuart Whitby]

There is no spoon.

SCSI ID means nothing to fibre. The Device ID of the tape drives may change each time the fabric is initialised. This means that the devices will get presented to the SCSI layer in a different order, and assigned arbitrary IDs of (let's say) 0-3. It's not the SCSI ID of the *device* which changes, but the way the drive is presented to the host OS. It ends up showing up as a new drive with the old one now missing, but if the old device entries are still there (Unix) it will create new device entries, or if they're gone (Windows) it may create the //./Tape entries in a different order.

NetWorker gets configured using these device names, and these names need to be set up in the same order that the jukebox sees them. So if everything's configured correctly to start with in order rmt1, rmt2, rmt3, rmt4 and then you reboot, you now get the jukebox to load a tape into drive 1 and try to read from an rmt1 device which no longer exists. Or with Windows, you load tape X into drive 1, read from //./Tape1, fail, load tape Y into drive 2, read from //./Tape2 *and find tape X*, then ..... it starts getting really messy. The jukebox doesn't get automatically reconfigured, NW will just figure that the tape was labelled incorrectly and change the tape label to match the wrong barcode. Yuck.

What persistent bindings does is to set up a constant order in which the devices are presented to and addressed in the host OS, configured by node name or port number. Here's a link from google. Might answer your question about setting this up: http://www.emulex.com/ts/docfc/utilities/lputil/15a0/persistent_pci.htm

[CARTON]

There is an other solution from Networker point of view in this case:
you can update the library adress without restarting the Networker service:
Edit Autochanger resource/"Control Port" field.
You can even do that with a nsradmin script.

The adress of the Tapes is not important (because Networker uses the windows device). The only thing you have to check is the number of tapes: if a Tape is missing you have to reconfigure the Autochanger.
But this is just a temporary solution, the good solution is static adress.