topic Re: Service Guard Linux Lock Disk issue in Operating System - Linux

Service Guard Linux Lock Disk issue

Andrew Young_2 — Wed, 09 Dec 2009 07:47:07 GMT

Hi.

An administrator at a client has added another LUN to their SAN (a Clarion I think) and presented it to their Service Guard Linux hosts. Having rebooted the one node the disk lettering has changed so the lock disk - and just about every other disk - is now different on this node. They are getting a "Cannot reach lock device" errors on that node.

I'm sure the solution is pretty obvious, maybe I'm a few cups of coffee short of a good morning, but I can't figure it out.

Some help would be appreciated. Also any ideas on preventing this in future.

The techie stuff:
SGLX A.11.18
Redhat 4u7
HP P Series blades

Thanks in advance.

Andrew Y

Re: Service Guard Linux Lock Disk issue

Sameer_Nirmal — Wed, 09 Dec 2009 08:24:51 GMT

You may need to export the VGs and import them thereafter.

To prevent this problem in future, you may want to refer this

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&taskId=120&prodSeriesId=376220&prodTypeId=15351&objectID=c01538162

Re: Service Guard Linux Lock Disk issue

Matti_Kurkela — Wed, 09 Dec 2009 10:47:20 GMT

Yes, this is a fact of life in Linux SAN configurations. The /dev/sd* names are not persistent and you should assume that they *will* be changing at some point.

In Linux, it is not necessary to export & import VGs - simply running "vgscan" will re-detect the VGs.

You should use something that provides persistent names for your disk devices. There are many alternatives for that: if you use LVM, it handles this automatically. But for the lock disk, you may need a different solution.

If you don't use LVM but have multiple paths to your SAN disks, some multipath solutions will also provide persistent naming (dm-multipath certainly does it).

If you use plain /dev/sd* devices, you should write some udev rules to assign persistent names for your devices.

Please see this document about using udev with Serviceguard for Linux:
http://docs.hp.com/en/8859/udev_sglinuxconfig.pdf

MK

Re: Service Guard Linux Lock Disk issue

melvyn burnard — Wed, 09 Dec 2009 17:43:43 GMT

Chaps, I think you are missing something here. A Lock Lun is NOT part of a VG, so there is nothing to do with VG that may cause this issue. It is purely down th enon-persistance of devices in Linux.

Re: Service Guard Linux Lock Disk issue

melvyn burnard — Wed, 09 Dec 2009 17:52:19 GMT

Perhaps this might help?
http://docs.hp.com/en/8859/udev_sglinuxconfig.pdf

Re: Service Guard Linux Lock Disk issue

Serviceguard for Linux — Thu, 10 Dec 2009 04:42:50 GMT

Melvyn has one good point.

I don't remember the exact functions of the drivers with different versions of the FC drivers, but both have had persistent naming as a function (side effect) of their multipath. So if you are using multipath (and you should) then there may be a driver configuration problem.

Re: Service Guard Linux Lock Disk issue

Andrew Young_2 — Thu, 17 Dec 2009 10:36:43 GMT

Hi All

Thanks for the advice.

I have tried to do as suggested but with no luck.

The /sbin/scsi_id command fails with errors when querying the disk. I suspect this is because the EMC DMX disk array is blacklisted by the scsi_id system as default. However if I run the scsi_id command with the -g -s options to get the ID I get the following:

SEMC SYMMETRIX 751545487000

I am open to suggestions on what to do.

Regards

Andrew Y