Exchange コンテンツ インデックスの再構築のベースラインを確立する – パート 2
原文の記事の投稿日: 2012 年 6 月 27 日 (水曜日)
このシリーズのパート 1 では、E2K7_IndexRebuildAnalyzer.ps1 スクリプト (英語)について説明しました。この記事では、Anatoly Girko と私が開発した検索再構築フレームワークについて説明します。もともとこのフレームワークは、社内の運用スタッフがコンテンツ インデックスを再構築するときに利用できる包括的な検証ステップと進行状況のインジケーターのセットとして用意したものです。
ステージ 1: 再構築前の統計情報の収集
マイクロソフト社内の環境で Exchange メールボックス データベースのコンテンツ インデックス ファイルを再構築すると決定した場合、まずオペレーターは影響を受けるストアに対して再構築前の統計情報を計算します。これらの統計情報は、記録を残しておくために必ず CSV に書き込まれて、最終的にはマイクロソフトの履歴データ コレクション セットに挿入されます。ただし、既に説明したように、 -CSVFile パラメーターは省略できます。-CSVFile パラメーターを指定しない場合は、対応する出力がシェル コンソール ウィンドウに表示されます。読みやすいように、コンソールの [画面バッファーのサイズ] の [幅] 、および [ウィンドウのサイズ] の [幅] の両方を調整して、出力されるさまざまなヘッダーおよびメトリックがすべて適切に表示されるようにします。このように調整すると、コンソール セッションで値を読みやすくなります。通常、この出力を、 -AutoSize (-a) パラメーターを指定した Format-Table (ft) にパイプで渡します。
例
コンソールの例 :
.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 | ft -a
出力 :
CSV の例:
.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 -CSVFile c:\ericnor\NA-1ERICNOR-1_PreRebuild.csv
出力 :
次に、再構築前のメトリックを履歴データ コレクションと比較して、再構築を完了するまでの平均時間の推定値を導出します。メールボックス データベースおよび対応するエンド ユーザー メールボックスの地理的な場所も考慮します。ストアの地理的な場所および完了するまでの推定時間に基づいて、そのストアでのユーザーのアクティビティが最も少ない日時に再構築作業をスケジュールします。
ステージ 2: 影響を受けるメールボックス データベースのコンテンツ インデックスのリセット
次に、マイクロソフト社内の環境で作業するオペレーターは、「フルテキスト インデックス カタログを再構築する方法 」に説明されているどちらかの方法を使用して、メールボックス データベースのコンテンツ インデックスをリセットします。
次に示す例では、環境内の 2 つのメールボックス データベースの コンテンツ インデックス ファイルをリセットします。これら 2 つのストアは、NA1-ERICNOR-1 クラスター化メールボックス サーバー上で最大のメールボックス数、EDB ファイル サイズ、およびデータベース合計アイテム数を持っています。
コンテンツ インデックス ファイルのリセット:
ステージ 3: フル クロールが必要であると Search Indexer によって判断されたかどうかの確認
ファイル システムから既存のコンテンツ インデックス ファイルを削除し、続いて Microsoft Exchange Search Indexer サービスを再起動した後、MonitorAndUpdateMDBList スレッドによって、メールボックス サーバー上でコンテンツのインデックス作成が有効化されているすべてのメールボックス データベースのコンテンツ インデックスの現在の状態が特定されます。MonitorAndUpdateMDBList スレッドによって各メールボックス データベースの コンテンツ インデックスの正常性状態 が特定された後、各メールボックス データベースの正常性状態の値がメモリに格納されます。コンテンツ インデックスの正常性状態の値が " 新規 " の場合、コンテンツ インデックス ファイルを正常な状態に移行するには完全な フル クロール が必要であると Microsoft Search Indexer サービス によって判断されています ("正常" な状態とは、ストア通知によってインデックスが最新の状態に維持されていることを指します)。この時点で、Exchange Search Indexer サービスによって、影響を受けるメールボックス データベースに対して フル クロール 操作が開始されます。
フル クロール 操作が実際に開始される時刻は、アプリケーション イベント ログに イベント ID 109 で示されます。
作業を実行するオペレーターは、システム上ですべての フル クロール 操作が開始されたことを確認するために、 ステージ 2 でコンテンツ インデックスをリセットした各メールボックス データベースに対して イベント ID 109 が存在するかどうかを確認します。
例
前の例で説明したように、ResetSearchIndex スクリプトを使用して、NA1-ERICNOR-1-DB1 および NA1-ERICNOR-1-DB18 のコンテンツ インデックス ファイルがリセットされました。Microsoft Exchange Search Indexer サービスによってフル クロール操作が開始されたことを確認するには、メールボックス サーバー上の各メールボックス データベースに対して一意の イベント ID 109 が存在している必要があります。実際に、これらのイベントが存在しています。
イベントの種類: 情報
イベントのソース: MSExchange Search Indexer
イベントのカテゴリ: 全般
イベント ID: 109
日付: 2012/05/10
時刻: 14:22:19
コンピューター: NA1-ERICNOR-1-A
説明: Exchange Search Indexer は、メールボックス データベース NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129) の新しい検索インデックスを作成しました。このメールボックス データベースのフル クロールが実行されます。
イベントの種類: 情報
イベントのソース: MSExchange Search Indexer
イベントのカテゴリ: 全般
イベント ID: 109
日付: 2012/05/10
時刻: 14:22:20
コンピューター: NA1-ERICNOR-1-A
Description: Exchange Search Indexer は、メールボックス データベース NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16) の新しい検索インデックスを作成しました。このメールボックス データベースのフル クロールが実行されます。
メモ : イベント ログを画面で確認する以外に、Get-EventLog コマンドレットを使用して開始イベントを CSV に書き込むこともできます。次に例を示します。
Get-EventLog "Application" | Where-Object {$_.EventID -eq 109} | Select-Object EventID,TimeGenerated,Message | Export-CSV -NoTypeInformation -Path c:\Search_StartEvents.csv
ステージ 4: Search Indexer の進行状況および完了の確認
オペレーターは、 イベント ID 109 の存在によって フル クロール 操作が開始されたことを確認した後、 システム モニター を使用して全体的な再構築の進行状況を監視します。具体的には、次のオブジェクトおよびカウンターを監視します。
- MSExchange Search Indexer\Number of Databases Being Crawled
- MSExchange Search Indexer\Number of Indexed Databases Being Kept Up-to-Date by Notifications
- MSExchange Search Indices\<クロール中の DB インスタンス>\Full Crawl Mode Status
- MSExchange Search Indices\<クロール中の DB インスタンス>\Document Indexing Rate
- MSExchange Search Indices\<クロール中の DB インスタンス>\Number of Mailboxes Left to Crawl
- MSExchange Search Indices\<クロール中の DB インスタンス>\Number of Recently Moved Mailboxes Being Crawled
- MSExchange Search Indices\<クロール中の DB インスタンス>\Number of Outstanding Batches
- MSExchange Search Indices\<クロール中の DB インスタンス>\Throttling Delay Value
オペレーターは、MSExchangeSearchIndexer オブジェクトを確認することによって、サーバー上の最新のコンテンツ インデックスの数および現在クロール中のコンテンツ インデックスの数を簡単に確認できます。メールボックス サーバーが完全に最新の状態になっている場合、"Number of Databases Being Crawled" カウンターの値は常に 0 になり、"Number of Indexed Databases Being Kept Up-to-Date by Notifications" カウンターの値はサーバー上でコンテンツのインデックス作成が有効化されているメールボックス データベースの数と等しくなります。
今回の例では、メール サーバー上に合計で 18 のメールボックス データベースがあり、現在これらのデータベースのうちの 2 つが フル クロール 中です。したがって、"Number of Databases Being Crawled" の値は 2 に、"Number of Indexed Databases Being Kept Up-to-Date by Notifications" の値は 16 になっています。
個々のメールボックス データベースで フル クロール が完了すると、システム モニターのさまざまなオブジェクト カウンターの値に特定の変化が見られます。
MSExchange Search Indexer のレベル:
- "Number of Databases Being Crawled" カウンターが 1 つ減少します。
- "Number of Indexed Databases Being Kept Up-to-Date by Notification" が 1 つ増加します。
メールボックス データベースのインデックスのレベル:
- 個々のデータベースの "Full Crawl Mode Status" の値が 0 に減少します (MonitorAndUpdateMDBList モニター スレッドによって特定された コンテンツ インデックスの正常性 状態の新しい値を反映しています)。
- "Number of Mailboxes Left to Crawl" の値が 0になります。
- フル クロール による再構築操作そのものには関連しませんが、"Number of Recently Moved Mailboxes Being Crawled" カウンターも各インデックスに対して 0 である必要があります。Exchange メールボックス データベース間で Exchange メールボックスが正常に移動された場合、移動先でコンテンツのインデックス作成が有効化されているときは、移動先データベースの検索通知が一時的に中断されます。これは、Exchange Search Indexer サービス が最近移動されたメールボックスの 1 回限りのクロールを実行して、マスター インデックスを完全に最新の状態にするためです。1 回限りのクロールが完了したら、ストア通知が再開されます。ここでのポイントは、技術的には フル クロール は完了しているが、コンテンツ インデックスの再構築と同時にメールボックスの移動が行われている場合は、1 回限りのクロールが実行される可能性がある点です。このカウンターが 0 の場合は、メールボックス データベースで実行されるすべてのクロール アクティビティが確実に完了しています。そのため、このカウンターが 0 であることを確認する必要があります。
すべてのコンテンツ インデックスが完全に最新の状態である Exchange サーバーでは、次の値になります。
- "MSExchange Search Indexer\Number of Databases Being Crawled" は 0です。
- "MSExchange Search Indexer\Number of Indexed Databases Being Kept Up-to-Date by Notifications" は、メールボックス サーバー上でインデックス作成が有効化されているメールボックス データベースの数です。
- メールボックス サーバー上の各 Exchange メールボックス データベース インスタンスの "Full Crawl Mode Status" は 0です。
- メールボックス サーバー上の各 Exchange メールボックス データベース インスタンスの "Number of Mailboxes Left to Crawl" は 0です。
- メールボックス サーバー上の各 Exchange メールボックス データベース インスタンスの "Number of Recently Moved Mailboxes Being Crawled" は 0 です。
今回の例では、これらすべての値が上記の条件にあてはまるので、インデックスが正常に再構築され、コンテンツ インデックスの観点からサーバーが完全に 正常 であると推定できます。
作業を実行するオペレーターは、すべてのコンテンツ インデックスが最新であることをシステム モニターで確認したら、アプリケーション イベント ログで、Microsoft Exchange Search Indexer の フル クロール 完了イベントである イベント ID 110 が存在するかどうかを確認します。イベント ID 109 と同様に、 フル クロール が完了した各メールボックス データベースに対して 110 イベントの一意のエントリが存在します。
イベントの種類: 情報
イベントのソース: MSExchange Search Indexer
イベントのカテゴリ: 全般
イベント ID: 110
日付: 2012/05/10
時刻: 17:39:47
コンピューター: NA1-ERICNOR-1-A
説明: Exchange Search Indexer は、メールボックス データベース NA1-ERICNOR-1\NA1-ERICNOR-1-SG1\NA1-ERICNOR-1-DB1 (GUID = 5a1122be-b9bb-4d5b-853a-e689b1ea1129) のフル クロール (インデックス処理) を完了しました。
イベントの種類: 情報
イベントのソース: MSExchange Search Indexer
イベントのカテゴリ: 全般
イベント ID: 110
日付: 2012/05/10
時刻: 17:11:47
コンピューター: NA1-ERICNOR-1-A
説明: Exchange Search Indexer は、メールボックス データベース NA1-ERICNOR-1\NA1-ERICNOR-1-SG18\NA1-ERICNOR-1-DB18 (GUID = 2faba54d-1699-441e-8ac8-1a136d0b7b16) のフル クロール (インデックス処理) を完了しました。
メモ : イベント ログを画面で確認する以外に、Get-EventLog コマンドレットを使用して完了イベントを CSV に書き込むこともできます。次に例を示します。
Get-EventLog "Application" | Where-Object {$_.EventID -eq 110} | Select-Object EventID,TimeGenerated,Message | Export-CSV -NoTypeInformation -Path c:\Search_CompletionEvents.csv
ステージ 5: 再構築後のメトリックの収集
ステージ 5 では、オペレーターが各メールボックス データベースに対して フル クロール の完了を確認していることを前提とします。オペレーターは、このステージで 再構築後 のメトリックを収集して、クロールが実行された各メールボックス データベースのスループット特性を特定します。
これらのメトリックを収集するには、 -PostRebuild スイッチを指定して E2K7_IndexRebuildAnalyzer スクリプトを使用します。
既に説明したように、 -PostRebuild スイッチを指定すると、アプリケーション イベント ログが解析されて、 イベント ID 109 および イベント ID 110 の両方が存在するかどうかが確認されます。 クラスター連続レプリケーション の場合は、CCR クラスターの各ノードのアプリケーション イベント ログが評価されます。スクリプトでこれらのイベント ID が検出されると、各メールボックス データベースに対して フル クロール を完了するのに必要な合計時間が (さまざまな時間単位で) 計算されます。その後、オペレーターに対して、それぞれの再構築操作のスループット特性が返されます。
すべてのメールボックス データベースで検索インデックスが再構築されたかどうかに関係なく、メールボックス サーバー上のすべてのメールボックス データベースが評価されることに注意してください。また、 -CSVFile オプションを指定しないでインスタンス化された場合、結果セットはコンソール ウィンドウに出力されます。Excel を使用するとレポート作成、並べ替え、フィルター、ピボットを簡単に行うことができるため、再構築後の統計情報を計算する場合は -CSVFile を指定することを強くお勧めします。
例
.\E2K7_IndexRebuildAnalyzer.ps1 -CMS NA1-ERICNOR-1 -PostRebuild -CSVFile c:\ericnor\NA1-ERICNOR-1_PostRebuild.csv
E2K7_IndexRebuildAnalyzer の実行が完了した後、CSV ファイルを検査できます。CSV を確認すると、メールボックス サーバー上のすべての Exchange メールボックス データベースが処理されたことがわかります。Search Indexer のイベント ID のペアが見つからないため、多くの Exchange メールボックス データベースに対して "NoEventsFound" という文字列が返されています。今回の例では、16 のメールボックス データベースで "NoEventsFound" とレポートされ、2 つのメールボックス データベースで有効な再構築後のメトリックがレポートされています。
Excel 内で簡単なテキスト ベースのフィルターを適用して、この結果セットをさらに絞り込むことができます。任意の再構築後のメトリックの列ヘッダーに対してフィルターを適用し、"NoEventFound" の文字列のチェック ボックスをオフにすることによって、有効な再構築後のメトリックを持つデータベースのみが表示されます。
例の結果セットにこのフィルターを適用すると、NA1-ERICNOR-1-DB1 および NA1-ERICNOR-1-DB18 (コンテンツ インデックスがリセットされたメールボックス データベース) のみが表示されます。また、さまざまな再構築後のメトリックのヘッダーに対して有効な値が表示されており、再構築後のメトリックが正常に確定されたことがわかります。
文字列フィルターの適用後:
ステージ 6: Test-ExchangeSearch による検証
再構築フレームワークの ステージ 6 では、コンテンツ インデックスがリセットされたメールボックス データベースに所属するすべてのメールボックスが有効な検索応答を返すことができることを確認します。Test-ExchangeSearch コマンドレットに含まれているコア機能を利用してこの目的を達成できます。このコマンドレットに対してすべてのメールボックスが True の応答を返すと、最終的な検証が完了します。
例:
Get-Mailbox -Database NA1-ERICNOR-1\ NA1-ERICNOR-1-SG1\ NA1-ERICNOR-1-DB1 | Test-ExchangeSearch | ft -a
Get-Mailbox -Database NA1-ERICNOR-1\ NA1-ERICNOR-1-SG18\ NA1-ERICNOR-1-DB18 | Test-ExchangeSearch | ft -a
データベースに含まれているメールボックスの数に応じて、このプロセスが完了するまでに長い時間がかかることがあります。また、Test-ExchangeSearch を使用して一括操作を実行する場合、結果が True であるか False であるかにかかわらず、ResultFound プロパティおよび SearchTime プロパティはすべてのメールボックスが処理された後にコンソール ウィンドウに表示されます。記録を残しておくためにすべての結果を CSV に格納することもできます。
Test-ExchangeSearch テストに False をレポートしたすべてのエンド ユーザー メールボックスは、一時的に問題が発生していると見なされて、適宜修復されます。
ステージ 7: 再構築後のメトリックの分析
読みやすいように、Excel の列に表示された状態ではなく、表形式でさまざまなメトリックを示します。既に説明したように、NA1-ERICNOR-1 クラスター化メールボックス サーバーには、コンテンツ インデックスが再構築された NA1-ERICNOR-1-DB1 および NA1-ERICNOR-1-DB18 という 2 つの Exchange メールボックス データベースがありました。
再構築後のメールボックスのメトリック:
メールボックス データベース再構築のメトリック:
さまざまな再構築メトリックおよび再構築前のメトリックは、今後再構築を行う場合に平均時間の履歴として使用できるように、履歴データ コレクション セットに追加されます。
まとめ
このシリーズのパート 2 では、検索再構築フレームワークの各ステージについて説明しました。次の最後の記事では、マイクロソフト社内の展開における実際の平均値について説明します。
Eric Norberg
サービス エンジニア
Office 365 専任
これはローカライズされたブログ投稿です。原文の記事は、「Establishing Exchange Content Index Rebuild Baselines – Part 2」をご覧ください。