multipath-tools support for SGI TP9700...

multipath-tools support for SGI TP9700...

[Kevin M Lange]

[-- Attachment #1.1: Type: text/plain, Size: 716 bytes --]

Salut,

Our organization is currently prototyping a database host which is running 
RHEL5 with SGI InfiniteStorage TP9700 Storage System.  Red Hat support has 
effectively told us that the device-mapper-multipath software does not 
support our TP9700 storage.  Does the multipath-tools v0.4.8 support SGI 
TP9700?  We are interested in contributing our hardware configuration for 
test of multipath-tools, but are unable to contribute programming 
resources at this time.

- Kevin


Kevin M Lange 
Principal Information Systems Technologist, NASA EMD Program
EMD UNIX IT Support 
Raytheon Information Solutions 

301.851.8450 office
301.928.2492 cell
klange@raytheon.com
5700 Rivertech Court
Riverdale, MD 20737-1250

[-- Attachment #1.2: Type: text/html, Size: 1130 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: multipath-tools support for SGI TP9700...

[Christophe Varoqui]

Le jeudi 12 juin 2008 à 00:51 -0400, Kevin M Lange a écrit :
> 
> Salut, 
> 
> Our organization is currently prototyping a database host which is
> running RHEL5 with SGI InfiniteStorage TP9700 Storage System.  Red Hat
> support has effectively told us that the device-mapper-multipath
> software does not support our TP9700 storage.  Does the
> multipath-tools v0.4.8 support SGI TP9700?  We are interested in
> contributing our hardware configuration for test of multipath-tools,
> but are unable to contribute programming resources at this time. 
> 
TP9700 seems to look like TP9500, which has configuration defaults set.
You should try and report using the TP9500 config for 9700 in
your /etc/multipath.conf:

devices {
        device {
                vendor "SGI"
                product "TP9[457]00"
                path_grouping_policy group_by_prio
                path_checker rdac
                checker rdac
                hardware_handler "1 rdac"
                prio rdac
                failback immediate
                no_path_retry queue
        }
}

Regards,
cvaroqui

Re: multipath-tools support for SGI TP9700...

[Kevin M Lange]

[-- Attachment #1.1.1: Type: text/plain, Size: 3502 bytes --]

Christophe,
Unfortunately it does not appear that the TP9700 is working using the 
multipath device settings you provided. 

Our configuration is such where the host (a Sun X4600 running RHEL 5.2) is 
connected to the TP9700 using two Fibrechannel connections:



No FC switches are used, just simple direct HBA to SP connectivity with 
two HBAs and two Storage Processors.  LUNs on the RAID are distributed to 
be owned by either SPA or SPB to distribute the workload between the SPs 
and the fibrechannel connections.

The TP9700 can be configured to present the storage to a host by setting 
the "Storage Array Host Type" (Linux, SGIRDAC, SGIAVT, Windows, etc).  For 
my tests, I've been experimenting with Linux and SGIRDAC.  I have been 
unsuccessful in determining what the storage array host type "Linux"s 
failover method is, but I thought I had come across an article that said 
the Linux type is basic AVT.  I could be mistaken.

Setting the TP9700 Host Type to "Linux" , I then setup /etc/multipath.conf 
to mimic the defaults for the TP9500:

       device {
               vendor                  "SGI"
               product                 "TP9[457]00"
               getuid_callout          "/sbin/scsi_id -g -u -s /block/%n"
               prio_callout            "/sbin/mpath_prio_tpc /dev/%n"
               features                "0"
               hardware_handler        "0"
               path_grouping_policy    group_by_prio
               failback                immediate
               rr_weight               uniform
               rr_min_io               1000
               path_checker            tur
       }

This configuration ran OK for a while, then began to log multipath 
failures, and eventually I/O buffer errors.  All LUNs on one SP trespassed 
to the other SP, and I had to manually place each trespassed LUN back to 
its primary path.

Changing the TP9700 host type to SGIRDAC, then trying the configuration 
you provided me caused the host to not see the ghost path.  Effectively I 
ended up with a single path.  Disconnecting a FC connection resulted in 
the inability to see any of the LUNs assigned to the associated SP.

I modified the multipath.conf a little:
        device {
                vendor "SGI"
                product "TP9700"
                path_grouping_policy failover
                getuid_callout          "/sbin/scsi_id -g -u -s /block/%n"
                features "1 queue_if_no_path"
                path_checker rdac
                prio_callout            "/sbin/mpath_prio_tpc /dev/%n"
                hardware_handler "1 rdac"
                prio rdac
                failback immediate
        }
This worked ok, but I see lots of scsi sense key errors:

Jun 23 12:16:42 p4dbl03 kernel: sdbk: Current: sense key: Recovered Error
Jun 23 12:16:42 p4dbl03 kernel:     <<vendor>> ASC=0x95 ASCQ=0x1ASC=0x95 
ASCQ=0x1
Jun 23 12:16:42 p4dbl03 kernel:

I see those error regardless of how I configured the RAID and 
multipath.conf, which is worrisome.
I especially see those errors if I run 'fdisk -l'. 

Disconnecting a FC cable on one HBA caused the associated volumes to 
trespass to the other SP, however, during this process, I noticed buffer 
I/O errors.  Also, I noticed that the trespassed LUNs did not failback to 
their original SP when the FC cable was reconnected.  Am I to assume that 
RDAC or other multipath software will not tell the storage to failback 
trepassed LUNs?

Your assistance is appreciated,

- Kevin




[-- Attachment #1.1.2: Type: text/html, Size: 7386 bytes --]

[-- Attachment #1.2: Type: image/jpeg, Size: 14003 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Re: multipath-tools support for SGI TP9700...

[Konrad Rzeszutek]

> their original SP when the FC cable was reconnected.  Am I to assume that 
> RDAC or other multipath software will not tell the storage to failback 
> trepassed LUNs?

It will if the priority received from the prio_callout (or in more recent
version prio) is greater for the set of the trespassed LUNs and you are using
the right prio group policy. Try having this value in the new configuration
for the RDAC setup:

               path_grouping_policy    group_by_prio