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 はハングした I/O を 60 秒間報告せず、I/O を 8 分間再試行しません。ハングした I/O を再試行するまでに 8 分もかかるのは長すぎるので、マイクロソフトでは新しいガイダンスをリリースし、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 の Extensible Storage Engine によるハングした I/O の復旧
Exchange Server 2010 SP1 では、ハングした I/O に対処するしくみが大幅に強化されています。強化された機能については、TechNet の記事 https://technet.microsoft.com/ja-jp/library/ff625233.aspx で次のように詳細に解説されています。
"Exchange 2010 SP1 には、特定の状況が発生したとき、具体的にはハングした I/O が発生したときに組み込みの Windows バグチェックの動作を活用する新しい復旧ロジックが備わっています。SP1 では、ハングした I/O を検知し、サーバーを自動的に復旧するための是正措置を講じるように Extensible Storage Engine (ESE) が更新されています。ESE は、特定の時間 I/O が未処理になっていることを検知する I/O ウォッチドッグ スレッドを保持しています。既定では、データベースの I/O が 1 分を超えて未処理になっていると、ESE がイベントをログに記録します。データベースの I/O が 4 分を超えて未処理になっていると、ESE は (可能であれば) 特定の失敗イベントをログに記録します。ハングした I/O の性質に応じて、ESE イベント 507、508、509、または 510 がログに記録される場合とされない場合があります。問題の性質が、OS ボリュームが影響を受けていたり、イベント ログへの書き込みが影響を受けていたりするたぐいのものであれば、イベントはログに記録されません。イベントがログに記録されると、Microsoft Exchange Replication サービス (MSExchangeRepl.exe) がその状況を検知し、wininit.exe プロセスを終了して意図的に Windows のバグチェックが実行されるようにします。"
つまり、これはどういうことでしょうか。多少の議論 (および ESE コードの検索) を経て、この動作をわかりやすくまとめたのが次の表です (参考のために以前のバージョンの Exchange も含めています)。
注意: ここで Exchange チームの ESE 開発者である Alexandre Costa と Brett Shirley の両名に深い感謝の意を表します。2 人がいなければ、この情報をまとめることはできませんでした。
|
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 が完了して初めて報告されていたことに注意してください。
この新しい動作が意に沿わない場合の対処方法
多くの事柄と同様に、非常に明確でやむを得ない理由がない限り、この新しい動作を変更することはお勧めできません。それでも、新しい Extensible Storage Engine によるハングした I/O の復旧動作をどうしても変更する必要がある場合は、いくつかのレジストリ キーと Active Directory 属性を操作して変更できます。詳細については、ここを参照してください。
まとめ
この記事を書き始めたそもそもの理由は、Exchange DAG サーバー ノードの Windows ディスク TimeOutVale を、ここ (英語)で推奨されているように短かくすべきかどうかを判断するためでした。
Exchange チームの Matt Gossage (Matt は Exchange と I/O のことを何でも知っています) に相談したところ、ディスク タイムアウトの働きの 1 つは、バス リセットのストームからホストを保護することだと説明してくれました。I/O が Windows ディスク TimeOutValue に達したときの興味深い副作用の 1 つは、disk.sys ドライバーがバス リセットを発行し、このリセットによって、応答していない LUN だけでなくサーバー上のすべての LUN が影響を受けるということです。
この現象が生じる最も一般的なシナリオが、Exchange 2010 と JBOD ストレージの組み合わせです。RAID ソリューションが展開されている場合、ディスク コントローラーはデータを別のディスクから読み取るか、パリティからデータを再計算することによって不良ブロックの読み取りに対処できます。この場合 I/O は遅延しますが、大幅な遅延ではありません。JBOD では、データ ブロックのコピーが 1 つしかないので、ディスクがデータを読み取ろうとするのを待つ間に、不良ブロックが原因でハングした I/O が発生する可能性があります。要するに、JBOD 展開ではディスク TimeOutValue を短かくすることは望ましくなく、JBOD ディスクのスピンドルの 1 枚で障害が起き始めている場合は、むしろ値を増やしてバス リセットのストームの影響を減らすことが必要になる場合もあるということです。
次の表は、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」をご覧ください。