Topic
  • 4 replies
  • Latest Post - ‏2014-06-17T11:44:07Z by sles
rltodd
rltodd
7 Posts

Pinned topic Redhat 6.2 and LNXALUA

‏2012-07-06T15:11:20Z |
Folks: I am setting up a storage system on several hosts, some connected to DS3512's, others to DCS3700's. The hosts are running SL 6.2 (Redhat clone), and all the storage controllers have been flashed to the 10.83 storage controller firmware. The storage arrays are each connected to a pair of hosts using 6Gb SAS, and there are dual links (so each host has a link to each controller of the array). I am using native dm-multipath on the hosts, as the documentation seems to suggest this is preferred over the RDAC drivers moving forward. The host mappings are made with the LNXALUA host type.

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.
Updated on 2012-07-25T17:03:11Z at 2012-07-25T17:03:11Z by eraserhead
  • eraserhead
    eraserhead
    1 Post

    Re: Redhat 6.2 and LNXALUA

    ‏2012-07-25T17:03:11Z  
    I have the same issue on RHEL 6.3. Can't seem to find an answer anywhere.
  • sles
    sles
    15 Posts

    Re: Redhat 6.2 and LNXALUA

    ‏2013-11-07T08:44:27Z  

    Hello!

     

    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.84

     

    Updated on 2013-11-07T08:47:18Z at 2013-11-07T08:47:18Z by sles
  • db808
    db808
    1 Post

    Re: Redhat 6.2 and LNXALUA

    ‏2014-06-16T21:33:29Z  
    • sles
    • ‏2013-11-07T08:44:27Z

    Hello!

     

    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.84

     

    Hi,

    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
  • sles
    sles
    15 Posts

    Re: Redhat 6.2 and LNXALUA

    ‏2014-06-17T11:44:07Z  
    • db808
    • ‏2014-06-16T21:33:29Z

    Hi,

    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.

     

    Thank you!

    May be I'll try it on rhel :-)