英文原文已於 2011 年 11 月 17 日星期四發佈

幾個月前 Bruce Langworthy 寫了一篇很棒的文章,講到一些有關設定 Windows 磁碟逾時值的新建議 - http://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 上有著長足的進步。在 http://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 秒

  • 寫入事件記錄檔
  • ESE 針對受到過慢 I/O 影響的頁面執行空白頁面覆寫

Exchange Server 2010 SP1

執行中

>60 秒

  • 寫入事件記錄檔

>4 分鐘

  • 終止 wininit.exe 程序,然後對伺服器主行錯誤檢查

已完成

>30 秒

  • 寫入事件記錄檔
  • ESE 針對受到過慢 I/O 影響的頁面執行空白頁面覆寫

附註:執行中的 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

配置 建議
直接附加儲存裝置
  • 將 Windows 磁碟逾時值減少20 秒
  • 參閱硬體製造商的指示
  • 發生衝突時,以硬體製造商的指示為優先
附加 SAN 的 RAID 儲存裝置
  • 將 Windows 磁碟逾時值減少20 秒
  • 參閱硬體製造商的指示
  • 發生衝突時,以硬體製造商的指示為優先
JBOD 儲存裝置
  • 將 Windows 磁碟逾時值增加180 秒
  • 參閱硬體製造商的指示
  • 發生衝突時,以硬體製造商的指示為優先

Neil Johnson
UK MCS 資深顧問

這是翻譯後的部落格文章。英文原文請參閱 Windows Disk Timeouts and Exchange Server 2010