EVA disk presented to 2 servers but seen as different persistent DSF's on each server

[Kevin P Bannister]

We have two nodes mp1 and mp2
On mp2 one lun is seen as /dev/disk/disk25 which is 1Tb.
On mp1 the lun /dev/disk/disk25 is 400Gb
ie two separate disks.

From the Legacy DSF I can see the disks are different using ioscan.

I want to change from Legacy DSF's to persistent DSF's but am concerned about this mixup.

Has anyone had this problem, please help with clear instructions.

Kevin

[singh sanjeev]

ioscan -m dsf
ioscan -m lun

compare the WWN number of the disk..which is made avialable to two server..may be you referring to different disk..

[Kevin P Bannister]

I know they are different disks and discovered this already using ioscan.
We have a 2 node cluster using serviceguard A.11.18.00

My question is -- as I've got two servers with the same persistent DSF (but are diff disks) what can I do.

[VK2COT]

Hello Kevin,

This scenario will be taken care of
soon in ServiceGuard 11.20. New class
of device special files will exist.

In the meantime, use "ioinit -f" to reassign
instances on one host to look like the other.
Refer to ioinit(1M) for more details.

Install the latest 11.31 ioinit and related dependencies firstly. You will be able to
dynamically (without rebooting) change disk
instances. Then, evaluate the DSFs in use and
clean old DSFs that may be stale.

Cheers,

VK2COT

[TTr]

See my reply and the two URLs in this thread.
http://forums13.itrc.hp.com/service/forums/questionanswer.do?threadId=1431739

Not sure how the 11.31 new disk devices relate to ioinit/ioconfig renumbering.

[S. Ney]

I had set up a two node cluster using persistent DSF's on 11.31. When you do your vgexport of the map file from active node to passive node and vgimport on the passive node the VGID contained in the mapfile will enable the passive node to know what disks belong to the volume group.

As long as you keep careful records of what maps to where you should be ok. For example I have a spreadsheet and used xpinfo to get the wwn's and then map the lun's between the 2 servers:
sys1/dev/rdisk/disk133 0x01c9 sys2/dev/rdisk/disk152 0x01c9
sys1/dev/rdisk/disk58 0x0112 sys2/dev/rdisk/disk133 0x0112
then on the shared volume group here is an example of an lvol (disk PE LE PVG lun hw_path)on the active system:
/dev/disk/disk133 6399 6399 pvg_07 64000/0xfa00/0x2b
/dev/disk/disk136 6399 6399 pvg_07 64000/0xfa00/0x2e
/dev/disk/disk137 6399 6399 pvg_07 64000/0xfa00/0x2f
lastly here is the hw path for disk133 on sys1 and disk152 on sys2:
0/7/1/0/4/0.222.42.239.14.T.L
0/7/1/0/4/0.222.42.239.14.T.L

hope that helps

[chris huys_4 · Accepted solution]

Hi Kevin,

The same you would do, when you were still on HP-UX 11.23 and had the same lun presented to 2 nodes of your cluster, and were due to hardware path differences of the nodes, had the lun on node A, ending up, with legacy device file /dev/rdsk/c20t3d0 and the lun on host B, ending up, with legacy device file /dev/rdsk/c23t3d0.

In that case, on HP-UX 11.23, you would just vgimport on host A the volumegroup with vgimport /dev/rdsk/c20t3d0 and on host B, vgimport /dev/rdsk/c23t3d0.

I.e on HP-UX 11.31, first find out what the persistent device files corresponding for a specific lun on the 2 different nodes, is.

On the EVA.
Note down, of the vdisk, that is presented to the 2 nodes, the WWID (or UUID), that can be found from the general tab, and the LUN ID, that can be found, from the presentation tab.

On hostA,
Translate the LUN ID, to a legacy device file.

F.e. if the LUN ID was lun 10, then you should have a eva disk, with a legacy device file, ending with t1(*8)d2=t1d2.

With ioscan -m lun, match that legacy device file to a a /dev/disk persistent devicefile.

Crosscheck with
# scsimgr -D /dev/r?disk/ get_info , if the found persistent devicefile, has indeed the WWID, that you had seen for that vdisk, in the general tab of the eva.

on hostB, repeat the above procedure that was done for hostA, but now you will probably end up with a different persistent devicefile for the same eva lun.

Then import on hostA, the volumegroup, with the persistent device file that you found on hostA .

And on hostB, import the volumegroup with the (different) persistent device file that you found on hostB.

NOTE1: offcourse if the volumegroups are currently imported with legacy device files, vgexport the volumegroups first on both hosts, before doing the above procedure..

NOTE2: also you might need to first vgexport the volumegroups, with the legacy device files, in preview mode, to preserve the mapfile, so that the mapfile can be used when vgimporting, with the persistent device file..

NOTE3: dont do the ioinit thing.. its a bad habit to do this kind of "forcing".. work with the default behavior of how the OS on a particular host, sees a particular lun, instead of trying to "force" the way, you would like the host to "see" a particular lun.. (unless there is a very good, i.e. "life&death" reason, to do just that.. )

Greetz,
Chris

[Mancboy]

hi kevin,
to expand on what chris said (agree totally about not forcing things using ioinit),
1) make one node your master node.
2) put scripts on this node to gather VG info from all nodes talking to the EVA (vgexport -p -s -m vgname.mapfile)
3) put scripts on this node to import the VGs onto each node connected to the EVA (vgimport -N -s -m vgname.mapfile)
4) never stray from this path!

reason I do it this way, is if I know I have one area which is my config control area, I know to just trust that area.

every time I make a change anywhere on the SAN, I make sure I update the config area and then repopulate.

extra hint: watch out for /etc filling up with all the vg.conf and vg.conf.old files building up.

hope that helps

[Kevin P Bannister]

Hi Folks,
Thank you for the feedback.
We use alsmp2 as master.
Here is one of my problem VG ie /dev/vg04

(alsmp2):/:# scsimgr -D /dev/rdisk/disk26 get_info |grep WWID
World Wide Identifier (WWID) = 0x600508b40006a9540000a00001990000
(alsmp1):/:# scsimgr -D /dev/rdisk/disk25 get_info |grep WWID
World Wide Identifier (WWID) = 0x600508b40006a9540000a00001990000
------- Different Persistent DSF but same disk (400Gb).

(alsmp2):/:# ioscan -m dsf /dev/rdisk/disk26
Persistent DSF Legacy DSF(s)
========================================
/dev/rdisk/disk26 /dev/rdsk/c22t0d1
/dev/rdsk/c12t0d1
/dev/rdsk/c18t0d1
/dev/rdsk/c8t0d1

(alsmp1):/:# ioscan -m dsf /dev/rdisk/disk25
Persistent DSF Legacy DSF(s)
========================================
/dev/rdisk/disk25 /dev/rdsk/c22t0d1
/dev/rdsk/c4t0d1
/dev/rdsk/c18t0d1
/dev/rdsk/c16t0d1

My /etc/lvmtab has the Legacy DSF(s) on both servers and are working.
Should I be concerned about making the Persistent DSF the same on both servers.

Is it possible in this case to change both servers to the same Persistent DSF eg /dev/rdisk/disk55
or is it a waste of time.

[Mancboy]

>> or is it a waste of time.

well, we've ignored these for the last 18 months and not really been concerned with them.
Just make sure you always vgimport/export using -s, you should be okay.
also evainfo is a good tool to keep track of which discs are which LUNs