If your environment is SSO I will give you 2 tips.
Wait for the completion of all backups and then run make_scsi_dev. Then
configure all Linux drives.
After that comment (#) the make_scsi_dev line at the NetBackup startup
script.
And do not reboot the system. If you do it you must run the make_scsi_dev
before netbackup start (and all drives must be idle)
I have install several linux systems and all working fine.
smpt
_____
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Daniel Cox
Sent: Tuesday, August 15, 2006 7:32 PM
To: veritas-bu at mailman.eng.auburn.edu
Subject: [Veritas-bu] make_scsi_dev woes under Linux
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/20060816/ba85a47e/attachment-0001.html
|
