Invalid data for cluster lock LUN configuration

[pbraun]

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

[Serviceguard for Linux]

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.

[Jozef_Novak]

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.

[pbraun]

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

[Serviceguard for Linux]

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.

[Colin Topliss]

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.

[pbraun]

ok iSCSI not supported in 11.18