We've got a few media servers running NetBackup 5.1 MP5 under Linux
(RedHat AS4) and we're having no end of problems with FC attached tape
drive device mappings. I see when NB starts it runs make_scsi_dev, which
creates the following devices:
[ROOT at arcachnbmm03] ~ # ls -l /dev/st
total 0
lrwxrwxrwx 1 root root 8 2006-08-15 12:28 h0c0t0l0 -> /dev/st5
lrwxrwxrwx 1 root root 8 2006-08-15 12:28 h0c0t1l0 -> /dev/st4
lrwxrwxrwx 1 root root 8 2006-08-15 12:28 h0c0t2l0 -> /dev/st3
lrwxrwxrwx 1 root root 8 2006-08-15 12:28 h1c0t0l0 -> /dev/st1
lrwxrwxrwx 1 root root 8 2006-08-15 12:28 h1c0t1l0 -> /dev/st0
lrwxrwxrwx 1 root root 8 2006-08-15 12:28 h1c0t2l0 -> /dev/st2
lrwxrwxrwx 1 root root 9 2006-08-15 12:28 nh0c0t0l0 -> /dev/nst5
lrwxrwxrwx 1 root root 9 2006-08-15 12:28 nh0c0t1l0 -> /dev/nst4
lrwxrwxrwx 1 root root 9 2006-08-15 12:28 nh0c0t2l0 -> /dev/nst3
lrwxrwxrwx 1 root root 9 2006-08-15 12:28 nh1c0t0l0 -> /dev/nst1
lrwxrwxrwx 1 root root 9 2006-08-15 12:28 nh1c0t1l0 -> /dev/nst0
lrwxrwxrwx 1 root root 9 2006-08-15 12:28 nh1c0t2l0 -> /dev/nst2
There seems to be 2 big problems with this. The devices as created by
the OS (st*, nst*) can change due to HBA driver upgrades, PCI bus
detection order changes, somebody moving an HBA around on the system or
somebody moving a drive around in the SAN for various reasons (port
based zoning). Another problem is if any of the previous scenarios occur
then NB creates entirely different /dev/st/*, /dev/sg/* entries to
represent the new host/controller/target/lun detection order. Naturally
either of these scenarios results in drive and robotic library id
mismatches and either netbackup refusing to start or drives going into
perm DOWN state.
We can use 2.6 kernel udev rules to map WWNs to OS devices and always
have consistent /dev/st*, /dev/sg* device names to get around the first
problem; however the NB auto-created devices can still change so we are
stuck with things occasionally breaking and then we waste a fare amount
of time putting it all back together again.
Is there some better way of handling this?
Dan-
*****************************************************************************
Note: The information contained in this message and any attachment to it is
privileged, confidential and protected from disclosure. If the reader of this
message is not the intended recipient, or an employee or agent responsible for
delivering this message to the intended recipient, you are hereby notified that
any dissemination, distribution or copying of this communication is strictly
prohibited. If you have received this communication in error, please notify
the sender immediately by replying to the message, and please delete it from
your system. Thank you. NYSE Group.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20060815/1030126c/attachment.html
|
