Windows 磁盘超时与 Exchange Server 2010
原文发布于 2011 年 11 月 17 日（星期四）
几个月前，Bruce Langworthy 撰写了一篇关于设置 Windows 磁盘超时值的新建议的优秀文章 - https://blogs.msdn.com/b/san/archive/2011/08/15/the-windows-disk-timeout-value-understanding-why-this-should-be-set-to-a-small-value.aspx（该链接可能指向英文页面）。
这篇文章让我开始思考 Exchange 以及我们处理 I/O 问题的方式。如果您尚未阅读 Bruce 的文章，那么让我告诉您，文中谈到，默认的 60 秒的磁盘超时意味着 Windows 在 60 秒内不会报告挂起的 I/O，而且在 8 分钟内不会重试 I/O。在重试挂起的 IO 之前等待 8 分钟过于漫长，因此 Microsoft 发布了新指南，建议将 Windows 磁盘超时设置更改为适合您的存储体系结构的值。
我思考的 Exchange 问题很简单：磁盘超时行为会如何影响 Exchange DAG 部署？ 更具体地说，就是我是应根据新的建议减少 Exchange 服务器上的 Windows 磁盘超时时间还是不管它？
为了回答此问题，我与一些 ESE 开发人员进行了探讨以了解他们的想法…下面是讨论得出的结论…
- Windows 磁盘超时值主要针对事件日志记录和 I/O 重试。
- 在 Exchange Server 2010 之前，对于速度较慢的 I/O，Exchange 除了在事件日志中报告它之外没有采取任何措施。
- Exchange Server 2010 RTM 为受速度较慢的 I/O 影响的页面引入了抢先页面修补技术（干净页面覆盖）。
- Exchange Server 2010 SP1 是第一个包含处理挂起的 I/O 的智能的 Exchange 版本，如果挂起的 I/O 影响了 DAG 节点上的活动数据库，Exchange Server 2010 SP1 将会主动使服务器失败（检测错误）。
我认为，我们必须先了解 Exchange Server 2010 SP1 引入了什么样的智能以及它如何与磁盘超时进行交互，然后才能确定如何处理磁盘超时设置。
针对挂起的 IO 的 Exchange Server 2010 SP1 可扩展存储引擎恢复
Exchange Server 2010 SP1 带来了一些对挂起的 I/O 的处理方式的重大改进。这些改进将在以下的 TechNet 文章 https://technet.microsoft.com/zh-cn/library/ff625233.aspx 中详细讨论：
“Exchange 2010 SP1 包含新的恢复逻辑，该逻辑在出现特定情况时（具体而言是出现挂起的 IO 时）利用内置的 Windows 检测错误行为。在 SP1 中，可扩展存储引擎 (ESE) 已进行更新，可以检测挂起的 IO 并采取纠正措施来自动恢复服务器。ESE 维持了一个 IO 监视程序线程，该线程会检测 IO 在一个特定的时间段内一直处于未完成状态的情况。默认情况下，如果某个数据库的某个 IO 在一分钟以上的时间内一直处于未完成状态，ESE 将记录一个事件。如果某个数据库的某个 IO 在 4 分钟以上的时间内一直处于未完成状态，ESE 将记录一个特定的失败事件（如果可以这样做）。可能会也可能不会记录 ESE 事件 507、508、509 或 510，具体取决于挂起的 IO 的性质。如果问题的性质是诸如操作系统卷受影响或写入事件日志的功能受影响，则不会记录事件。如果已记录事件，Microsoft Exchange 复制服务 (MSExchangeRepl.exe) 将通过终止 wininit.exe 进程来检测该情况并有意引发 Windows 的检测错误。”
那么，这意味着什么呢？在进行一些讨论（和一些 ESE 代码搜索）之后，我们创建了下表使这些行为更易于理解（我包含了之前的 Exchange 版本以供参考）。
说明：在这里我想对 Exchange 团队的 ESE 开发人员 Alexandre Costa 和 Brett Shirley 表示由衷的感谢，没有他们，我就无法获得这些重要的信息 - 谢谢他们！
|
Exchange 版本 |
I/O 类型 |
I/O 时间 |
行为 |
|
Exchange Server 2003 |
已完成 |
>60 秒 |
|
|
Exchange Server 2007 |
已完成 |
>60 秒 |
|
|
Exchange Server 2010 RTM |
已完成 |
>60 秒 |
|
|
Exchange Server 2010 SP1 |
正在进行 |
>60 秒 |
|
|
>4 分钟 |
| ||
|
已完成 |
>30 秒 |
|
说明：正在进行的 I/O 描述的是尚未成功完成的较慢的 I/O 操作。已完成的 I/O 表示用了 30 秒以上的时间才完成的较慢的 I/O。在这里要重点指出，在 Exchange Server 2010 之前没有检测正在进行的较慢的 I/O 的概念，我们只会在 I/O 完成后报告一次。
我不喜欢这个新行为，我能对它做什么？
与大多数事情一样，我建议不要更改新行为，除非您有非常明确且有说服力的理由这样做… 但是，如果您确实需要修改针对挂起的 IO 的可扩展存储引擎恢复的新行为，那么有一些注册表项/Active Directory 属性可以让您这样做，此处对它们进行了说明。
结束语
如果我们重新谈到我开始撰写本文的原因，那么就是评估我们是否应降低 Exchange DAG 服务器节点上的 Windows 磁盘 TimeOutVale，正如此处（该链接可能指向英文页面）所建议的。
我与 Exchange 团队的 Matt Gossage 进行了交谈（Matt 对 Exchange 和 I/O 无所不知），他指出，磁盘超时所做的事情之一就是保护主机免遭总线复位风暴。I/O 达到 Windows 磁盘 TimeOutValue 时的连带副作用之一是 disk.sys 驱动程序将发出总线复位，此复位将影响服务器上的所有 LUN，而不仅仅是影响无法响应的 LUN。
使用 Exchange 2010 和 JBOD 存储时最常出现这种行为。在部署 RAID 解决方案的情况下，磁盘控制器将能够通过从其他磁盘读取数据或借助奇偶校验重新计算数据来处理损坏的数据块读取；这会使 I/O 延迟，但并不明显。在使用 JBOD 时，只有一个数据块副本，因此，损坏的块有可能会在我们等待磁盘尝试和读取数据时导致挂起的 I/O。此处的底线是，在使用 JBOD 部署时，我们不希望减小 TimeOutValue，而事实上，我们可能甚至希望增大它以减轻当某个 JBOD 的磁盘心轴开始发生故障时总线复位风暴的影响。
下表列出了为运行 Exchange Server 2010 邮箱角色的服务器设置 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Disk\TimeOutValue 的建议指南。
| 应用场景 | 建议 |
| 直接附加存储 |
|
| SAN 附加 RAID 存储 |
|
| JBOD 存储 |
|
Neil Johnson
UK MCS 高级顾问
这是一篇本地化的博客文章。请访问 Windows Disk Timeouts and Exchange Server 2010 以查看原文