Pinned topic Redhat 6.2 and LNXALUA
Is there any additional configuration needed with multipath? Out of the box (and what is documented in the install guide), multipath is using the scsi_dh_rdac handler. Should it instead be using the scsi_dh_alua handler?
Right now, this seems to just work -- unless I pull a cable to simulate a path failure. A couple of systems with a forgotten link failed to find any LUNs on the associated DS3500 when it booted; I would have thought ALUA would allow the host to find everything through the existing link... I'll be trying identify all the failure modes, but first I thought I'd check if my configuration sounds sane.
(In the past I've used the RDAC drivers, but I'd like to avoid a solution that requires kernel modules to be compiled everytime I update the kernel -- although I'll need to do a little bit for GPFS.)
Thanks for the help.
sles 2700045NSV15 Posts
Re: Redhat 6.2 and LNXALUA2013-11-07T08:44:27ZThis is the accepted answer. This is the accepted answer.
Have the same issue:
Nov 07 12:38:24 | sdh: alua not supported
Nov 07 12:38:24 | sdg: alua not supported
on ubuntu 13.04
although host type is LNXALUA...
77.84Updated on 2013-11-07T08:47:18Z at 2013-11-07T08:47:18Z by sles
db808 270002HU3E1 Post
Re: Redhat 6.2 and LNXALUA2014-06-16T21:33:29ZThis is the accepted answer. This is the accepted answer.
- sles 2700045NSV
To my knowledge, the "ALUA" feature supported in the DS35xx and DCS3700, is "ALUA" by name only. It provides ALUA-like functionality but uses proprietary command-and-control signaling (the "rdac" command set) to identify the topology and switch paths. It is the scsi_dh_rdac module that is updated for RHEL 6.x to now include proprietary-ALUA functionality.
So to get proprietary-ALUA functionality with the DC35xx and DCS3700, you use the same scsi_dh_rdac module (that should be preloaded in grub.conf, and your multipath.conf entry is the same as your active/passive multipath.conf entry for RHEL 6.x. You change the "host type" parameter on the LUN on the storage array side to "LNXALUA", where the host type setting "LINUX" is used for the active/passive mode of operation. You must be running RHEL 6.x or newer for proper proprietary-ALUA support for the DC35xx and DCS3700.
The scsi_dh_alua driver is for storage that implements industry-standard ALUA, using the T10 standard-defined signaling to identify the topology and switch paths. For standards-based ALUA storage, the multipath.conf "path checker" is usually "TUR" (test-unit-ready), which is the standards-based signaling to test for path availability.
Other storage vendors that offer proprietary-ALUA, may or may not require that their respective scsi_dh_xxxx module be used ... it depends if they can function properly using the standards-based ALUA signaling ONLY. In some cases, the vendor-proprietary-ALUA mode may offer additional capabilities beyond the standards-based signaling.
I find it more understandable to use the term "proprietary-ALUA" when discussing non-standards-compliant ALUA functionality. Such proprietary-ALUA functionality still require the proprietary scsi_dh_xxxx modules.
So ultimately ... you need to check with the storage vendor and use the multipath and device handler modules recommended by the vendor.Updated on 2014-06-16T21:37:01Z at 2014-06-16T21:37:01Z by db808