topic Re: Invalid data for cluster lock LUN configuration in Operating System - Linux

Invalid data for cluster lock LUN configuration

pbraun — Thu, 28 May 2009 16:04:38 GMT

http://forums.itrc.hp.com/

Invalid data for cluster lock LUN configuration

Hi, I'm installing MC/Serviceguard 11.18 on two RHEL5.3 nodes. When trying to validate the configuration before making the binaries, I get,
...
/dev/sdb1 is not a valid device. Validation failed.
Invalid data for cluster lock LUN configuration
...

The configuration on both nodes,
...
CLUSTER_LOCK_LUN /dev/sdb1
...

"sdb" is a shared disk through iSCSI. It's viewed on both nodes and I created the 1-cylinder wide partition (must be at least 100k) with type 83.

Disk /dev/sdb: 62.2 GB, 62277025280 bytes
64 heads, 32 sectors/track, 59391 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 1 2 2032 83 Linux

It's loaded by the "iscsi" service (from the iscsi-initiator-utils rpm). Here's the dmesg,

May 28 18:35:10 sg1 kernel: Loading iSCSI transport class v2.0-724.
May 28 18:35:11 sg1 kernel: iscsi: registered transport (tcp)
May 28 18:35:11 sg1 kernel: iscsi: registered transport (iser)
May 28 18:35:11 sg1 iscsid: iSCSI logger with pid=6278 started!
May 28 18:35:11 sg1 kernel: scsi16 : iSCSI Initiator over TCP/IP
May 28 18:35:11 sg1 kernel: Vendor: NetBSD Model: NetBSD iSCSI Rev: 0
May 28 18:35:11 sg1 kernel: Type: Direct-Access ANSI SCSI revision: 03
May 28 18:35:11 sg1 kernel: SCSI device sdb: 121634815 512-byte hdwr sectors (62277 MB)
May 28 18:35:11 sg1 kernel: sdb: Write Protect is off
May 28 18:35:11 sg1 kernel: sdb: Mode Sense: 0e 00 00 08
May 28 18:35:11 sg1 kernel: sdb: got wrong page
May 28 18:35:11 sg1 kernel: sdb: assuming drive cache: write through
May 28 18:35:11 sg1 kernel: SCSI device sdb: 121634815 512-byte hdwr sectors (62277 MB)
May 28 18:35:11 sg1 kernel: sdb: Write Protect is off
May 28 18:35:11 sg1 kernel: sdb: Mode Sense: 0e 00 00 08
May 28 18:35:11 sg1 kernel: sdb: got wrong page
May 28 18:35:11 sg1 kernel: sdb: assuming drive cache: write through
May 28 18:35:11 sg1 kernel: sdb: sdb1
May 28 18:35:11 sg1 kernel: sd 16:0:0:0: Attached scsi disk sdb
May 28 18:35:11 sg1 kernel: sd 16:0:0:0: Attached scsi generic sg1 type 0
May 28 18:35:12 sg1 iscsid: transport class version 2.0-724. iscsid version 2.0-868
May 28 18:35:12 sg1 iscsid: iSCSI daemon with pid=6279 started!
May 28 18:35:12 sg1 iscsid: received iferror -38
May 28 18:35:12 sg1 last message repeated 2 times
May 28 18:35:12 sg1 iscsid: connection1:0 is operational now

I'm able to read and write to the disk from both nodes (e.g. dd to /dev/null). What's wrong with that lock LUN ? Even setting the lock data manually (with cmdisklock) works but cmcheckconf still fails. What's wrong with my Lock LUN ?

Note. Eventhough iscsi storage may not be supported by MC/Serviceguard, I would like to troubbleshoot the issue and have the technical details : what's so different between my iscsi disk and an fibre channel disk ?

The iscsi target server is also an RHEL5.3. I tryed IET targets with Type=blockio (no cache) and Type=fileio (with cache). I also tryed netbsd-iscsi (with cache) from EPEL. All give the same result.

target config with IET,
Target iqn.2001-04.com.nethence:iscsi.lun0
Lun 0 Path=/dev/sdb,Type=fileio
MaxConnections 9
InitialR2T No
ImmediateData Yes

target config with netbsd-iscsi,
extent0 /dev/sdb 0 62277025791
target0 rw extent0 10.1.1.0/24

default initiators config on both nodes,
node.startup = automatic
node.session.timeo.replacement_timeout = 120
node.conn[0].timeo.login_timeout = 15
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5
node.session.initial_login_retry_max = 4
node.session.cmds_max = 128
node.session.queue_depth = 32
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072
discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 32768

Thanks

Re: Invalid data for cluster lock LUN configuration

Serviceguard for Linux — Fri, 29 May 2009 01:32:36 GMT

11.18 has no iSCSI support

Even if you are experimenting, it would matter which iSCSI target you are using. An iSCSI target hosted by another server probably doesn't support the type of access that LockLUN requires (it has stricter requirements than a standard shared LUN.

If the iSCSI is hosted by another server, you should run the QS on that server.

Re: Invalid data for cluster lock LUN configuration

Jozef_Novak — Fri, 29 May 2009 06:04:53 GMT

Hello,

as already stated, iSCSI is not a supported shared storage interface in Serviceguard. The only two options you have are Fibre Channel and MSA2000 family.

J.

Re: Invalid data for cluster lock LUN configuration

pbraun — Fri, 29 May 2009 08:01:19 GMT

I guess it's the same for 11.19. Yes it's for experimenting/modelling. Could you give me more details on the stricter requirements ? e.g. lun reset support ?

Thanks

Re: Invalid data for cluster lock LUN configuration

Serviceguard for Linux — Fri, 29 May 2009 13:14:01 GMT

The device needs to support "true multi-initiator". That means the device needs to manage accesses from multiple hosts that are reading/writing at the "same time". This needs to happen without a clustered file system.

I hope that's clear.

BTW - this may be somewhat high level. There may be more subtle requirements that I'm not aware of. But since this is not supported anyway, then this should be enough of an explanation.

Re: Invalid data for cluster lock LUN configuration

Colin Topliss — Sat, 30 May 2009 21:19:27 GMT

Hi,

We've had all sorts of problems with lock LUNs - they are a real pain. If I were you, I'd go with a quorum server (I went through a programme of changing a large number of our clusters, both HP and Linux, from lock LUNs to quorum server).

BTW - HP are dropping ServiceGuard for Linux anyway (we found out last week). Now might be a time to go look for a different product....

http://h18026.www1.hp.com/solutions/enterprise/highavailability/linux/serviceguard/discontinuance.html

Regards

Colin.

Re: Invalid data for cluster lock LUN configuration

pbraun — Fri, 26 Jun 2009 09:14:23 GMT

ok iSCSI not supported in 11.18