powerpath多路径切换疑问

我有一台服务器：

RHEL5.4环境下，内核自带驱动，以下这个参数是不是判断loop down的timeout设置？

[root@pcfaildb-5 /root]

# cat /sys/module/qla2xxx/parameters/ql2xlogintimeout

20

有次由于HBA1至交换机链路问题，出现这个报错，注意到timeout out command, waited 30s，这个30s又是哪里来的呢？

Jun 16 16:49:56 pcfaildb-5 kernel: qla2xxx 0000:0b:00.0: scsi(1:2:1): Abort command issued -- 1 f6fb4ff 2002.

Jun 16 16:49:56 pcfaildb-5 kernel: sd 1:0:2:1: timing out command, waited 30s

Jun 16 16:49:56 pcfaildb-5 kernel: Error:Mpx:Path Bus 1 Tgt 2 Lun 1 to CK200071300285 is dead.

Jun 16 16:49:56 pcfaildb-5 kernel: Error:Mpx:Killing bus 1 to Clariion   CK200071300285 port SP B1.

正如你提到的，HBA卡驱动判断loop down的timeout设置决定了failover的时间。如果主机连接的是磁盘设备的话，Timeout参数一般设置在30秒-1分钟。如果连接的是磁带设备的话，这个参数就要相应调长。

Powerpath上没有timeout相关的设置，事实上，Powerpath正是在HBA驱动timeout之后才确定某个Path断掉的。希望这个回答对你有帮助：）

推荐 最好使用emulex或是qlogic网站上, 指定存储厂家匹配的HBA卡firmware和驱动. 并根据存储厂家的配置文档的说明,修改HBA卡的配置参数, 这样可以使得HBA卡以最好的状态来工作.

powerpath链路切换的原理就是在发现了某条链路有响应失败的时候, 标记该链路故障, 而把IO重定向到工作正常的链路上去. 并且每5分钟对失败的链路检查一下是不是恢复正常了. 检测到链路恢复后, 就恢复对该链路的IO传送.

Logintimeout是HBA端口的Login超时设置，我觉得Loop Down的timeout设置很大程度上取决于主机多久能探测端口Down（参数为Port Down Retry Count) 和在发现端口Down之后多久能确定Path Dead（参数为Link Down Timeout）。

Log里的Waited 30s是Link Down Timeout时间，即在主机已经探测到端口Down后，会再等待一段时间(例如30s)才断定路径Path Dead并且停止发送IO。在某些情况下链路若只是短暂的抖动很快恢复，这个机制可以避免不必要的trespass。可以修改这个参数qllink_down_timeout调整Link Down Timeout设置 。

EMC推荐的Qlogic HBA的配置参数如下:

更多信息建议参考文档EMC Host Connectivity with QLogic Fibre Channel and iSCSI Host Bus Adapters(HBAs)。从Powerlink下载路径为

Home > Support > Technical Documentation and Advisories > Host Connectivity/HBAs > Installation/Configuration

qllink_down_timeout这个参数哪里可以看到，是怎样设置的呢？

powerpath内部的failover有没有时间的限制，比如最少需要多少多少秒的？

上面表格里提到的参数Port Down Retry Count和Link Down Timeout都可以用SANsurfer CLI在NVRAM里编辑修改。

Main Menu

1: General Information

2: HBA Information

3: HBA Parameters

4: Target/LUN List

5: Boot Device

6: Utilities

7: Beacon

8: Diagnostics

9: FCoE

10: Help

11: Exit

选择1可以查看上面表格中的参数值，选择3可以修改这些参数。详细步骤请参考Qlogic 关于SANsurfer CLI的官方文档http://filedownloads.qlogic.com/files/Manual/72911/Users_Guide_-_SANsurfer_FC_HBA_CLI_%5BK%5D.pdf

Powerpath的failover没有时间限制的，Powerpath何时标记链路故障并重定向IO，完全取决于HBA的驱动返回的结果。

Powerpath工作在HBA以及SCSI驱动的上层，由于下层的驱动通常都有重试和超时机制，Powerpath本身在遇到I/O错误的情况下，就会尝试使用不同的通道发送I/O，而不再重试。

当然Powerpath对于通道状态以及I/O请求的完成结果，仍然来源于下层驱动的返回。因此直到HBA驱动判定一个I/O请求超时之前，Powerpath都不会进行转发。

Powerpath本身也有路径检测机制，每个一段时间会根据自身的逻辑检测部分io通道，这样即使在应用发送I/O请求之前就可能提前发现通道故障，避免浪费一个超时的时间。

非常感谢，慢慢有眉目了。

之前您有一段话没有明白：

Loop Down的timeout设置很大程度上取决于主机多久能探测端口Down（参数为Port Down Retry Count) 和在发现端口Down之后多久能确定Path Dead（参数为Link Down Timeout）。

Port Down Retry Count这个参数怎么理解？

和Link Down Timeout参数有何种关系？

确定port down了再retry？还是retry了以后才确定down了？

retry又是怎么计数的呢？

还有，之前提到的，waited 30s不是port down的设置，我的port down timeout设置为8s。

Jul  6 01:39:57 temdb33 kernel: scsi(1): ABORT status detected 0x5-0x0.

Jul  6 01:39:57 temdb33 kernel: qla2xxx 0000:0b:00.0: scsi(1:7:19): Abort command issued -- 1 4995756 2002.

Jul  6 01:40:07 temdb33 kernel: qla2xxx_eh_abort(1): aborting sp ffff810fb2a46740 from RISC. pid=77158235.

Jul  6 01:40:07 temdb33 kernel: scsi(1): ABORT status detected 0x5-0x0.

Jul  6 01:40:07 temdb33 kernel: qla2xxx 0000:0b:00.0: scsi(1:7:19): Abort command issued -- 1 499575b 2002.

Jul  6 01:40:14 temdb33 kernel: qla2xxx 0000:0b:00.0: scsi(1:6:19): DEVICE RESET ISSUED.

Jul  6 01:40:14 temdb33 kernel: qla2x00_wait_for_hba_online return_status=0

Jul  6 01:40:36 temdb33 kernel: qla2xxx 0000:0b:00.0: scsi(1:6:19): DEVICE RESET SUCCEEDED.

Jul  6 01:40:36 temdb33 kernel: qla2xxx 0000:0b:00.0: scsi(1:7:19): DEVICE RESET ISSUED.

Jul  6 01:40:36 temdb33 kernel: qla2x00_wait_for_hba_online return_status=0

Jul  6 01:40:36 temdb33 kernel: qla2xxx 0000:0b:00.0: scsi(1:7:19): DEVICE RESET SUCCEEDED.

Jul  6 01:40:36 temdb33 kernel: sd 1:0:6:19: timing out command, waited 30s

Jul  6 01:40:36 temdb33 kernel: sd 1:0:7:19: timing out command, waited 30s

Jul  6 01:40:36 temdb33 kernel: sd 1:0:6:19: timing out command, waited 30s

Jul  6 01:40:36 temdb33 kernel: sd 1:0:7:19: timing out command, waited 30s

Jul  6 01:40:36 temdb33 kernel: sd 1:0:7:19: timing out command, waited 30s

一般故障检测机制是发生了timeout以后,去做retry, retry N次之后,标记fail.

发生了timeout就会在底层日志里报错了.

据我自己做的测试，交换机端disable掉主机hba卡连的端口，无论我的port down timeout设置成多少，message日志马上会打印这条日志：

Jul  6 11:10:13 temdb33 kernel: qla2xxx 0000:0e:00.0: LOOP DOWN detected (2 6 0).

然后会做retry：

Jul  6 00:59:20 temdb33 kernel: scsi(0): fcport-4 - port retry count: 15 remaining

Jul  6 00:59:20 temdb33 kernel: scsi(0): fcport-5 - port retry count: 15 remaining

Jul  6 00:59:20 temdb33 kernel: scsi(0): fcport-6 - port retry count: 15 remaining

Jul  6 00:59:20 temdb33 kernel: scsi(0): fcport-7 - port retry count: 15 remaining

每秒一次，retry了Port Down Retry Count这么多次以后，就报path dead。看起来这时候powerpath才做failover。

这样看的话，port down timeout这个参数完全没有任何用处。

看上去这个参数没有生效。

内核模块参数修改之后需要重新加载一下内核，请确认一下是否执行了这步操作。

重启服务器或者

modprobe -r ; modprobe #这个过程会unload驱动，因此必须确保设备不在使用。

我是通过qlogic的SANsurfer CLI工具改的HBA卡参数，改的应该是hba卡的NVRAM里的数据吧？

这个能及时生效吗？

nvram里面的修改应该也不是即时生效的，参数生效是在驱动初始化/内核模块加载的时候。

这个参数的重载级别应该是 用户指定的参数 > 驱动定义的默认参数 > NVRAM配置。

因此我建议修改modprobe.conf，然后重新加载内核模块来尝试一下。

根据楼上的几位讨论，小结一下，欢迎补充：）

下层HBA驱动有重试和超时机制，当HBA确定超时后会返回结果给Powerpath。之后Powerpath标志原路径故障并用不同的路径转发IO。

这样看来Failover的时间取决于HBA重试和超时的机制，其中最重要的参数是Port Retry Count的时间。这个参数在NVRAM配置中为Port Down Retry Count，在内核模块modprobe.conf配置中为ql_port_down_retry。参数的具体配置请参考HBA的厂家解释。

正如Alex所说，Modprobo.conf级别较高会覆盖 NVRAM的配置，建议在Modprobo.conf中改参数配置。