跳转到主内容

控制 MS iSCSI 如何在不对应用程序造成损害的情况下生存丢失的 TCP 连接的参数是什么?

Views:
4
Visibility:
Public
Votes:
0
Category:
iscsi-initiator-support-kit
Specialty:
san
Last Updated:

可不使用  

适用于

  • SAN
  • SAN 协议
  • FlexPod

解答

在连接瞬时丢失期间、 Microsoft iSCSI 启动程序将尝试重新连接到目标并重新提交未执行的 SCSI 命令,而不是立即报告“ Device not available ”(设备不可用)。

与 MS iSCSI 重试行为相关的注册表值有三个、可在以下路径中找到:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E97B-E325-11CE-BFC1-08002BE10318}\[Instance_Number]\Parameters

注: [instance_number] 可能与系统不同、具体取决于系统上已存在的 SCSI 适配器数量。

三个注册表值为:
  • DelayBetweenReconnect [default: 5 (seconds)]
  • MaxConnectionRetries [default: 0xFFFFFFFF, infinite]
  • MaxRequestHoldTime [default: 60 (seconds)]

说明:
通常不需要修改DelayBetweenReconnectMaxConnectionRetries
MaxRequestHoldTime可能是您唯一需要更改的。它定义了 Microsoft iSCSI 启动程序在通知Device Removal事件的上层之前应保留和重试未执行的命令的时间。此事件通常会导致使用 iSCSI 磁盘的应用程序出现 I/O 故障。MaxRequestHoldTime仅与非 MPIO 环境相关。如果涉及 MPIO 、则会忽略该值。

Device Removal对于正在使用 iSCSI 逻辑单元号( LUN )的应用程序而言、事件可能会很坏、特别是在电缆拔出、文件管理器重新引导、文件管理器集群故障转移等需要MaxRequestHoldTime恢复的时间超过此时间时。 
MaxRequestHoldTime如果选择 iSCSI 协议、 Windows Host Utilities 安装程序将设置为 120 、除非检测到适用于 Windows MPIO 的 Data ONTAP DSM 。

注:
即使Device Removal报告了事件之后、 Microsoft iSCSI 启动程序仍将继续尝试按照前两个注册表值定义重新连接到目标DelayBetweenReconnect、和MaxConnectionRetries

更改注册表值后,必须重新启动 Windows iSCSI 主机。

其他信息

不适用