rename drive instances presented from LUNs on SAN

[Robert Mantel]

I need to settle an argument I'm having with a collegue. My system is an HPUX 11.00 HA cluster connected to a SAN which has several LUNs presented to the cluster nodes. Because of a botched SAN move (not my doing I'm proud to say) and fibres on the fc switch getting reversed, once the cluster was brought back up again it detected the new hardware paths and created new device files as it should. This of course caused problems with the LVM configuration and the system did not mount the targets, because the LVM scripts were looking for the old targets. These have since been corrected by adjusting the LVM configuration and not the device files.

I have inherited this situation and an application upgrade provides an opportunity to correct this asymetry between the nodes in the cluster. We would like to correct this situation as there is a danger that the system could be brought down if an unknowing support person performed a cluster sync and copied the LVM config from one node to the other.

The two solutions that we're arguing about are as follows: My collegue wants to reload the OS from scratch and I simply want to remove all past and present SAN device file targets with rmsf and then perform an insf to re-discover the LUN's on both nodes, and they should now be symmetric, with primary and alternate paths reflected accurately on both nodes.

The position of my collegue is that it is far more dangerous to rename the targets than to re-install the OS completely. I see the risk as being equal, but with my solution being less time consuming and hence less downtime for my customer, which we all know is something that you always try to minimize.

Because we are talking about very sensitive information, is there any possible risk to the data on the SAN if I rename the targets on both nodes so that they are identical? Obviously the cluster would be halted when this action is performed and the LUN dismounted. I see very little risk whatsoever with my solution, but would like comments from the group.

Sorry for the long question, but any input would be much appreciated.

[Patrick Wallek · Accepted solution]

There is actually a third way to go about this that should be cleaner and more certain of success than either proposal so far.

Check out the following document from the Technical Knowledge Base: Doc ID KBAN00000795 - How Does One Change An Instance Number -
http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000067424466

Now the problem with the other proposals is that there is no guarantee they will work. Reinstalling the OS will not guarantee that your instance numbers will be the same as they were before. You may have added some cards to the system since the original install and that would change things.

The problem with removing device files is that they will still exist in ioconfig and you could wind up the same as you are now.

My preference over all of the above would be option 4 - Don't worry about it!!!!

We've got an SG cluster where the device files are different on each node. It doesn't bother me at all.

The ONLY LVM information that should EVER be copied between SG nodes is vgexport map files. If you vgexport and vgimport correctly you will NEVER have any trouble with different device file names.

[Robert Mantel]

Patrick, thanks for your rapid reply. I know I didn't mention it but leaving it as is was definately one of the options I supported, but my college is worried about the confcl command that could be executed by a support person who is not intimately familiar with our system. My argument against that is that all the people directly involved in this system are aware of this mismatch and I would hope would not blindly go ahead and sync the lvm configs between the cluster nodes.

Just for the sake of my own knowledge, by just removing the /dev/rdsk(dsk)/cxtxdx targets that map to the SAN LUNs, will they not also be removed from the kernel io_map and hence be gone from the system completely? Then a subsequent ioinit say on boot discovers the LUNS again and for the sake of argument in our system if the the first four card instances are taken by internal drives, then would it not take up c4txdx for the primary paths and c6txdx for the alternates? I suppose my real question is how does the kernel assign card instances? Why is it that the original targets were c4 and c6 and not something else?

Thanks for the link and I'll award you points.