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。等待 8 分鐘才重試無回應的 I/O 實在太久了，因此 Microsoft 發行了一項新指南，建議使用者根據其存放區架構，調整 Windows 的磁碟逾時設定。
對於 Exchange，我的問題很簡單：磁碟逾時行為對於 Exchange DAG 部署有什麼影響？更進一步地說，我應該依照最新建議，減少 Exchange Server 上 Windows 的磁碟逾時時間？還是保留原來的設定呢？
為了得到解答，我詢問了幾位 ESE 開發人員的意見，然後得到下列結論。
- Windows 磁碟逾時值主要用途，在記錄事件及重試 I/O。
- 在 Exchange Server 2010 之前，Exchange 對於反應過慢的 I/O 不會採取任何行動，而只會將其記錄在事件記錄檔中。
- 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 在處理無回應的 I/O 上有著長足的進步。在 https://technet.microsoft.com/zh-tw/library/ff625233.aspx 這篇 TechNet 文章中，詳細說明了改良的內容：
「Exchange 2010 SP1 引進了全新的復原邏輯，其會在發生某些情況時，特別是 IO 無回應時，運用 Windows 的內建錯誤檢查行為。SP1 也更新了可延伸儲存引擎 (ESE)，使之可以偵測無回應的 IO 並加以更正，以自動復原伺服器。ESE 會保留一個 IO 看門狗執行緖，當偵測到有任何 IO 的停止時間已經達到指定的時間之後。根據預設，當資料庫的 IO 停止回應超過一分鐘時，ESE 就會記錄該事件。若資料庫中有任何 IO 的停止回應時間超過四分鐘，ESE 會在可能的情況下，將其記錄成特定的失敗事件。根據無回應 IO 性質的的不同，可能會記錄 ESE 事件 507、508、509 或 510，但也可能不會記錄。若問題的性質是作業系統磁碟區受到影響，或寫入事件記錄檔的能力受到影響，就不會記錄這類事件。在有事件記錄檔的情況下，Microsoft Exchange 複寫服務 (MSExchangeRepl.exe) 會了解相關的狀況，然後藉由終止 wininit.exe 程序而有目的地地引發 Windows 的錯誤檢查。」
這到底是什麼意思呢？經過一番討論後 (以及我們對 ESE 代碼的一番搜尋)，我們整理出了下列表格，方便大家更清楚地認識這項行為 (其中也加入了舊版的 Exchange 供大家參考)。
附註：在這裡我要大大地感謝 Alexandre Costa 和 Brett Shirley 的鼎力相助，他們倆都是 Exchange 小組的 ESE 開發人員，如果沒有他們，大家就看不到這項寶貴的資訊 - 謝啦！
|
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 代表 I/O 速度很慢，以長達 30 秒的時間完成了作業。有一點很重要：在 Exchange Server 2010 之前，並沒有偵測執行中之 I/O 的概念，而只會在 I/O 完成後回報一次。
我不喜歡這個新行為，有其他好的建議嗎？
一如我對於大多數情況的建議，除非您有不得不的理由，否則請勿更動這個新行為，但如果您真的需要修改「處理無回應 IO 的可延伸儲存引擎復原功能」的新行為，確有一些登錄機碼或 Active Directory 屬性可以讓您使用，詳情請參閱此處。
結論
我寫這篇文章的出發點，是想評估我們是否應該依照此處 (可能為英文網頁)的建議，減少 Exchange DAG 伺服器節點的 Windows 磁碟逾時時間。
經過和 Exchange 小組的 Matt Gossage 促膝長談之後 (Matt 對於一切有關 Exchange 和 I/O 的事瞭若指掌)，他解釋說：磁碟逾時的功能之一，是保護主機不會出現巨量的匯流排重設狀況。當 I/O 達到 Windows 磁碟逾時值時，會一項奇怪的副作用，那就是 disk.sys 驅動程式會重設匯流排，並全面影響到伺服器上所有的 LUN，而不光只是無回應的 LUN。
這種狀況最常出現在 Exchange 2010 和 JBOD 儲存裝置。部署 RAID 解決方案的磁碟控制卡，可以藉由讀取另一顆磁碟的資料，或利用同位資料重新計算資料這兩種方式，處理從損毀磁區中讀取的資料；這會稍微拖慢 I/O，但並不嚴重。然而使用 JBOD 時，由於資料磁區只有一個複本，因此當我們等待磁碟嘗試讀取資料時，損毀磁區即有可能會造成 I/O 無回應。我們不會希望部署 JBOD 必須減少磁碟逾時值，甚至於還會需要增加此值，以在任何 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