Exchange、スタブ、およびデータベース領域回復
原文の記事の投稿日: 2012 年 8 月 28 日 (火曜日)
Exchange 2010 SP2 RU1 には、データベース領域回復に関する問題点の修正が含まれます。この問題点については誤解があるようですので、問題が何か、修正方法は何かについて説明します。また、データベース内でアイテムをスタブするときにサード パーティー製品を使用する場合についても説明します (スタブとは、メッセージがポインター オブジェクトで置き換えられ、元のバージョンが外部リポジトリに保存される過程です)。
バグと修正
Exchange 2010 で、アイテムが物理的に削除された (アイテムがストアから削除された) いくつかのシナリオで、データベース領域が回復されていなかったことが分かりました。これには、アイテムが日付に基づいて一括削除されるアーカイブ シナリオ、添付ファイルが削除されるスタブ シナリオ、およびジャーナル メールボックスとパブリック フォルダー レプリケーションのようなその他のシナリオがあります。この問題点はさまざまな顧客に影響しており、原因はアイテム削除の方法でした。
Exchange 2010 は、通常、アイテムが物理的に削除された後の 2、3 分以内に、削除されたアイテムの行のクリーンアップを試行します。しかし、何かがアイテムに対して開いたままの参照を持っている場合、クリーンアップは失敗します。たとえば、クリーンアップが失敗するシナリオは以下のとおりです。コンテンツのインデックス作成がメッセージのインデックスを作成している、個別のクライアントがメッセージを読み取っているなど。何かが開いたままの参照を持っている場合、クリーンアップは失敗します。この修正以前は、クリーンアップがこの時点で失敗した場合、そのスペースは実質的にリークされ、メールボックスを移動せずに復旧することはできませんでした。
削済みメッセージの未処理の参照は、ジャーナリング メールボックスで、またはサード パーティーのアーカイブ ソフトウェアが使用されたときに、特に一般的であるということが分かりました。このバグが発生した顧客の圧倒的多数は、これらの 2 つのシナリオのどちらかでした。しかし、理論上は、すべてのクライアントが、開いた参照を保留し、アイテムがクリーンアップされることを妨げることができます。
SP2 RU1 に含まれる修正は、クリーンアップ再試行メカニズムを追加することにより、この問題を修正します。何かが開いたままの参照を持っていることによりクリーンアップが失敗した場合、ストアは、成功するまで定期的にクリーンアップを再試行します。
これはスタブ処理を "修正する" のか
スタブ処理とは、サード パーティーのアーカイブ製品が、大きなメッセージを、小さなアイテム、つまりスタブに変換する過程を指します。一般的には、添付ファイルを削除し、メッセージ本文をより小さく変更することにより行います。
スタブ処理が添付ファイルを削除するという範囲では、このバグによって影響を受ける可能性があります。それらの削除された添付ファイルは、開いた参照によりクリーンアップを失敗させる可能性があるからです。しかし、それ以外の点について、このバグの原因は、直接、スタブ処理とは関係ありません。
予想よりもスタブ処理による領域の解放が少ない場合
Exchange Information Store は、長年にわたって、大きく変更されてきました。しかし Exchange 2003 や 2007 でも、スタブ処理をした後で、メールボックスのサイズを合計すると、データベースは予測より大きくなっていました。これは、主に 2 種類のオーバーヘッドが原因です。
第 1 の種類のオーバーヘッドは、単純にメッセージのサイズに含まれないプロパティです。Outlook で表示されるメッセージのサイズは、そのメッセージについて Exchange が保存したすべてのデータの合計のサイズではありません。ユーザーに対しては示されず、メッセージのサイズには反映されない特定のプロパティが保存されています。これらには、PR_URL_NAME のような、公開で文書化されたプロパティや、クライアントがアクセスできないその他の内部プロパティがあります。
第 2 の種類のオーバーヘッドは、ページ断片化です。データベースのページ サイズは、バージョンに応じて変更されてきました。Exchange 2003 では 4 KB、Exchange 2007 では 8 KB、Exchange 2010 では 32 KB となっています。データベース内の各レコードはこれらのページに配置する必要があります。それをどれだけ効率的できるかによって、ページに一部の領域が残ります。これが、ページ断片化です。これにより、データベース保守では回復できない空き領域が発生します。Exchange の最近のバージョンでは、ページ サイズがより大きくなっていることにより、複数の小さいアイテムを単一のページに配置しやすくなっています。これにより、断片化は減ってはいますが、ある程度の断片化は避けられません。
通常、オーバーヘッドの量は、メッセージごとに大きく変わりません。小さいメッセージでも、大きいメッセージと同じぐらいのオーバーヘッドがあります。これが原因で、小さいアイテムがデータベースに多数あると、オーバーヘッドはより目立つようになります。
たとえば、サイズがすべて 1 MB のアイテムでデータベースがいっぱいになったシナリオを想定します。これらのアイテムは、すべて 1 KB のオーバーヘッドを持っています。これは、データベースに約 0.09% のオーバーヘッドがあることを意味します。次に、データベースですべてのアイテムをスタブして、サイズを 4 KB に減らすとします。この場合、データベースの 25% が 1 KB のオーバーヘッドで占められ、はるかに目立つことになります。私は以前、個人的に、ごく小さいアイテムばかりでデータベースをいっぱいにした後で全体をスタブ処理することにより、70% がオーバーヘッドの Exchange 2003 データベースを生成したことがあります。
Exchange Server 2010 の場合
Exchange 2010 では、スタブ処理による領域回復に影響する、別の要因があります。これはデータベースの設計の変更によるものです。
Exchange 2010 は、データベース IOPS を減らすことにおいて、大きく進歩しました。主な点は、古いオンライン最適化プロセスを取り除いたことによるものです。このプロセスは、毎晩、データベースを激しくかき回し、アイテムをあちこちに移動して領域を最適化していました。Exchange 2010 では、使われていない領域が残ったとしても、IO を減らせるように、連続的なページにメールボックスの内容を保存することに重点を置きました。言い換えれば、Exchange 2010 は、メッセージが縮小されるたびに、単純に領域を回復するようには設計されていません。IO を向上する目的で、新しいアーキテクチャでは、このようなシナリオは最小限にされました。保守に関する変更の詳細については、「Database Maintenance in Exchange 2010」を参照してください。
これはスタブ処理では領域は節約できないということでしょうか。そうとは限りません。スタブ処理をすると、一般的には添付ファイルが削除されることから、領域が解放されると予測できます。また、そのように設計されているわけではありませんが、添付ファイルがないアイテムがスタブされたときでも、Exchange 2010 が一部の領域を解放することが確認されています。
しかし、これは Exchange 2010 の設計にはないことであり、スタブ アーカイブを使用してどれだけの領域が解放されるかは予測できません。これのついての予想は、ご自身でテストされるか、アーカイブ ソフトウェア ベンダーで提供するデータから予測する必要があります。
言いかえれば、アイテムがより小さくなるよう変更されたときの領域の回復については、コメントできません。アイテムが小さくなるように変更して、まったく領域が解放されなくても、それは Exchange 2010 の仕様となります。データベース領域の問題のサポート調査は、サード パーティー製品を使用するときのその他の場合と同様に、Exchange の仕様内の動作であれば、その特定のサード パーティーにサポートしていただくことになることがあります。
まとめ
Exchange 2010 SP2 RU1 には、スタブ処理かどうかにかかわらず、すべての種類のアーカイブについて、顧客を支援する修正が含まれています。これは、物理的に削除されたアイテムのクリーンアップを、より確実に機能させることによります。しかし、スタブ処理自体からのディスク領域節約は、アーカイブ ソフトウェア ベンダーによって検証される必要があります。記憶域を準備するときには、Exchange データ用に十分な領域が確保できるように、当社により発行されたガイダンスとツールを使用することを推奨します。ガイダンスには、サード パーティー アーカイブ ソリューションに依存する必要がなくなる、大きなメールボックスを使用することが含まれます。
Bill Long
これはローカライズされたブログ投稿です。原文の記事は「Exchange, Stubbing, and Database Space Reclamation」をご覧ください。