Exchange コンテンツ インデックスの再構築のベースラインを確立する – パート 1

原文の記事の投稿日: 2012 年 6 月 26 日 (火曜日)

 

トラブルシューティングにより Exchange Content Indexing に関する問題が疑われる場合、通常、大部分の Exchange 管理者が最初にとる措置は、問題を起こしているメールボックス データベースのコンテンツ インデックス ファイルを (手動、または \Exchange Server\Scripts ディレクトリにある ResetSearchIndex.ps1 スクリプトを使用して) 再構築することでしょう。また、私が長年一緒に仕事をしてきた Exchange 管理者の中には、積極的に検索インデックスの再構築を選択する人が数多くいました。それを行うのは、1 年の中のさまざまな時点、または、プロジェクトの中のさまざまなマイルストーンに達したとき (たとえば、移行プロジェクトが 1 例) です。

インデックスをリセットする理由にかかわらず、大部分の管理者は、このプロセスを始めてから終わるまでどのくらい時間がかかるかと尋ねられても、現実的な見積もりができないものです。この時間が正確に見積もれないために望ましくない事態も発生しますが、その内容は組織によってさまざまです。IT 部門では、エンドユーザーの生産性が低下することや、ヘルプ デスクに届く問題が拡大し増加することを挙げ、営業日の間、サーバー側のインデックスをユーザーが利用できないという事態を避けることがあります。運用上の観点からすると、再構築の時間が予測できないために、再構築プロセス自体に発生する可能性のある問題について Exchange 管理者が警戒することもできません。理由が何であれ、プロセスにかかる時間をしっかりと理解することが大切です。

確かに、Exchange コンテンツ インデックスの再構築にかかる時間 (または、さらに良いのは、かかるはずの時間) に関する情報は、現在ほとんど入手できません。これは、実際に再構築にかかる時間が常に変化するから、というのが表向きの理由です。再構築の速度と完了までの時間に影響する要因は多数あります。特に影響が大きいのは次の要因です。

• Exchange メールボックス データベースを "ホーム" とするエンドユーザーのメールボックスの総数の変化
• Exchange メールボックス データベースに含まれるメールボックスのサイズの変化
• Exchange メールボックス データベースをホームとするユーザーのメールボックス間のアイテム数のばらつき
• 複数の Exchange メールボックス データベース間のアイテム数のばらつき (同時に再構築を実行している場合)
• Exchange メールボックス データベース内にあるアイテムのサイズの変化
• Exchange メールボックス データベース内にあるメールの添付ファイルの数とサイズの変化
• Exchange メールボックス サーバー上で有効化されている IFilter の種類と数 (さまざまなファイル形式のインデックス付けが可能)
• クロールを実行しているメールボックス サーバーの全体的なシステム リソース使用量 (Throttling など)
• その他多数

マイクロソフトでは (当社内の実装でも、さまざまな Office 365 の提供においても)、 検索再構築フレームワーク を利用しています。これは、同僚の Anatoly Girko と私が開発したものです。このフレームワークは、元々、社内の運用スタッフがコンテンツ インデックスの再構築を実行するときに、包括的な検証ステップと進行状況のインジケーターを利用できるように設計しました。これらの手段を、再構築プロセス全体の中の種々の主要なマイルストーンで使用して、プロセスが確実に正常終了するようにしています。

このフレームワークが進化する中で、すべての再構築処理に対するスループットのメトリックを履歴として追跡および保存できるような付加機能を追加することにしました。このようにして収集したデータが増加し、その後データの傾向が明らかになると、指定された再構築処理にかかる時間について、以前よりもずっと情報に基づいた正確な見積もりができることに気づきました。次に、運用チームとしては、これを利用することにより再構築のスケジュールをより良く決定し、エンド ユーザーである顧客ベースに与える混乱を最小限に抑えることができました。当初から、このフレームワークは、サポートするさまざまな環境の中で数千のコンテンツ インデックスに対する再構築処理を監視するために利用されてきたのです。

一連の記事では、この " 再構築フレームワーク " について説明しますので、興味のある方は、必要があれば、自身の環境に同様の方法を適用できます。このプロセスを補助するために作成したさまざまなツールセットに関する説明を含め、フレームワークの各段階を詳しく説明します。このシリーズの最後には、観測したコンテンツ インデックスの再構築の統計量を示すグラフと表、および現在までのまとめを載せます。これまでにこの分野で統計量を調査したことがないお客様にとって、このシリーズが参考としてお役に立てば幸いです。おそらく、このシリーズによって、お客様も、ご自身の環境における Exchange コンテンツ インデックスの再構築時間に関して、今までより情報に基づいた見積もりができるようになります。Exchange 環境はすべて、それぞれに独特なものなので、お使いの環境における再構築のメトリックは、当社が観測し、ここに発表している速度とは全く異なる場合がありますので、ご注意ください。

いきなり本題に入る前に、このシリーズはトラブルシューティングのガイドとして書かれたものではないことも述べておきます。ここでは、お客様自身のトラブルシューティングによって、問題への対処として、または、先々のための測定として、再構築を実行することを決定した場合を想定しています。このシリーズの中で示している例はすべて、Exchange 2007 を念頭に置いています。2010 と比較すると、2007 のインデックスを再構築する方がはるかに可能性が高いため、この投稿では 2007 に集中することに決めました (2007 と異なり、2010 には正常な重複ソースからコンテンツ インデックスを再建する機能があるので、マルチコピー アーキテクチャではインデックス再構築の完全実行が必要になることはほとんどありません)。Anatoly と私は、Exchange 2010 バージョンの コンテンツ インデックス再構築アナライザー のスクリプトの使用例を蓄積し、後日、そのスクリプト参照を提供する追加投稿を行うつもりです。

インデックス再構築アナライザーのスクリプト

マイクロソフト 社内で、コンテンツ インデックスを再構築するときに活用する主なツールセットは、IndexRebuildAnalyzer スクリプトです。このスクリプトは、特にコンテンツ インデックス再構築の基準を確立するために、Anatoly と私が作成したものです。既に述べたように、このスクリプトには、Exchange 2007 バージョンと Exchange 2010 バージョンの 2 バージョンがあります。統計量を正しく計算するためには、インデックスを再構築する Exchange メールボックス データベースのバージョンに対応したスクリプトを必ず使用します。IndexRebuildAnalyzer スクリプトは、オペレーターが渡す処理モードによって 2 種類のメトリックを生成します。社内ではこの 2 つのモードを "再構築前のメトリック" および "再構築後のメトリック" と呼んでいます (すべてのプロパティが、以下のスクリプト参照のセクションに記載されています)。

このスクリプトは本来、コンテンツ インデックスの再構築処理を追跡するために活用していますが、Exchange 管理者 がこのスクリプトを " 再構築前モード " で使用し、メールボックスを中心としたさまざまな目的のために、 特定の時点 の統計量を取得することもできます (例: 組織全体の "メールボックス数"、"データベース内のアイテム数"、"メッセージの平均サイズ" など)。たとえば、ビジネス要件やニーズに応じてこのツールを定期的に利用すれば、ユーザーの傾向を調べる付加的な計測器や機能としてもご利用いただけます。

E2K7_IndexRebuildAnalyzer.ps1 スクリプト (英語) のパラメーターと使用方法の例を取得するには、スクリプトを実行する前に PowerShell セッションで -Help パラメーターを渡します。

次の表は、各パラメーターの概要を示しています。

パラメーター	必須かどうか	説明
-CMS </クラスター 1,クラスター 2>	必須	-CMS パラメーターを使用すると、Exchange メールボックス サーバーまたは Exchange クラスター化メールボックス サーバーのすべてのデータベースに対する統計量が計算されます。複数のスタンドアロンのメールボックス サーバーまたはクラスター化メールボックス サーバーにわたるデータベースの統計量を計算するには、サーバー名をコンマで区切ります。
-Database <データベース名,データベース名>	必須	-Databaseパラメーターを使用すると、指定したメールボックス データベースの統計量を計算できます。このパラメーターを使用する場合、次の形式でデータベース名を渡します。 "メールボックス サーバー名\ストレージ グループ名\データベース名" 複数のデータベースの統計量を計算する場合は、データベース名をコンマで区切ります。 アクティブなユーザーのメールボックスをまったく含まないデータベースは処理されません。
-All	オプション	-All スイッチを使用すると、Exchange 組織内のすべての Exchange メールボックス データベースの統計量を計算します。
-CSVFile	オプション	-CSVFile パラメーターを使用すると、すべてのメトリックを CSV ファイルに出力します。
-PostRebuild	オプション	-PostRebuild スイッチは、スクリプトの実行モードを識別するのに使用します。具体的には、 -PostRebuild が指定されると、スクリプトはアプリケーション イベント ログを解析し、インデックス再構築処理のパフォーマンス メトリックの計算を試みます。
-Help	オプション	スクリプトのヘルプを表示します。

データベース メトリックのヘッダー

再構築前

上記で定義したように、スクリプトの "処理モード" は -PostRebuild スイッチがあるか否かで決定します。再構築前のメトリックを取得するには、 -PostRebuild スイッチを使用しません。再構築前モードでスクリプトをインスタンス化すると、次のようなヘッダーが対応するメトリックに表示されます。

ヘッダー	説明
サーバー	処理されるデータベースに関連するメールボックス サーバーの ID。
データベース	処理される Exchange メールボックス データベースの表示名。
EDB サイズ (GB)	対応するデータベース ファイルのディスク上のサイズ (ギガバイト単位)。
EDB サイズ (MB)	対応するデータベース ファイルのディスク上のサイズ (メガバイト単位)。
メールボックス数	処理されるデータベースにおいてアクティブな Exchange メールボックスの数。切断されているメールボックスは処理されません。
データベース: アイテムの総数	Exchange メールボックス データベースに存在するメール アイテムの総数。
データベース: アイテムの合計サイズ (MB)	処理されるメールボックス データベースに存在するすべてのメール アイテムの合計サイズ (メガバイト単位)。
データベース: メッセージの平均サイズ (MB)	処理されるデータベースに存在するすべてのメール アイテムのメッセージの平均サイズ。
1 ユーザーあたりのメールボックスの平均サイズ (MB)	処理されるデータベースに存在するアクティブなメールボックスの平均メールボックス サイズ。
1 ユーザーあたりの平均アイテム数	処理されるデータベースに存在するアクティブなメールボックスの平均メール アイテム数。

再構築後 ( -PostRebuild パラメーターを使用)

-PostRebuild スイッチを使用すると、IndexRebuildAnalyzer は、コンテンツ インデックス再構築処理のスループット メトリックの計算を試みます。この計算を行うために、 アプリケーション イベント ログ を解析し、メールボックス サーバー上の各メールボックス データベースについて、( イベント ID 109 で示される) 再構築の開始時間と ( イベント ID 110 で示される) 完了時間の両方を取得します。再構築後のメトリックを正しく計算するには、対応するコンテンツ インデックスをリセットした各メールボックス データベースの イベント ビューアー に、イベント ID のペアが揃って存在している必要があります。イベント ID のペアが利用できない状況では、スクリプトによる統計量の計算はできません。このような場合、"NoEventsFound" という文字列が戻ります。この文字列が戻される理由として多いのは、次のような場合です。

• 指定したデータベースまたはデータベースのセットに対するコンテンツ インデックス再構築処理が完了していない場合。
• アプリケーション イベント ログ が上書きされたか、またはクリアされた場合 (ベスト プラクティスは、最大ログ サイズの値を維持できる最大値に設定することです)。
• "NoEventsFound" が通知されるメールボックス データベースでは、最近コンテンツ インデックスをリセットしていなかった場合 (そのため、イベント ID のペアがイベント ログに存在しません)。 -CSVFile オプションおよび Excel を利用することにより、この文字列を結果セットから簡単にフィルター処理できます。フィルター処理については、フレームワークの ステップ 5 で説明し、例を示します。

スクリプトの実行時に -PostRebuild スイッチを渡した場合は常に、"再構築前" のヘッダーおよびメトリックもすべて計算されます。 -PostRebuild スイッチを使用すると、次のヘッダーおよびメトリックも追加されます。

ヘッダー	説明
コンテンツ インデックス再構築開始時間	Search Indexer サービスによって、メールボックス データベースの フル クロール が開始されたときを示す開始時間。
コンテンツ インデックス再構築終了時間	Search Indexer サービスによって、メールボックス データベースの フル クロール が完了したときを示す完了時間。
再構築の総所要時間: 時:分:秒	Search Indexer サービスによって、メールボックス データベースの フル クロール が完了するまでの総所要時間 ( 時:分:秒 の形式)。
再構築の総所要時間: 分単位の合計	Search Indexer サービスによって フル クロール が完了するまでの総所要時間 ( 分 単位)。
再構築の総所要時間: 秒単位の合計	Search Indexer サービスによって フル クロール が完了するまでの総所要時間 ( 秒 単位)。
再構築: 1 メールボックスあたりの平均: 秒	1 メールボックスあたりの フル クロール の平均完了時間 ( 秒 単位)。
再構築: MB/秒	Search Indexer の フル クロール の平均スループット (MB/秒 単位)。
再構築: アイテム/秒	Search Indexer の フル クロール のスループット ( メール アイテム/秒 単位)。

まとめ

Exchange 2007 のインデックス再構築アナライザーのスクリプトはここから (英語) ダウンロードできます。

このシリーズのパート 2 では検索再構築フレームワークについて説明し、このシリーズのパート 3 では、現在までにマイクロソフト内で経験したことについて議論します。

Eric Norberg
サービス エンジニア
Office 365 専任

これはローカライズされたブログ投稿です。原文の記事は、「Establishing Exchange Content Index Rebuild Baselines ? Part 1」をご覧ください。