セキュリティ クロールについて
みなさんこんにちは。
SharePoint サポート チームのあらかわです。
今回は SharePoint の 「セキュリティ クロール」 について解説したいと思います。
[事例]
SharePoint の増分クロールを 30 分毎に 1 回の頻度で実施しています。普段は、長くても数十分程度でクロールが終わるのですが、たまに 4 時間以上かかることがあり、更新されているコンテンツの数は普段とそれほど変わりないはずなのに、何かおかしいのでないかと心配しています。
長い時間かかっているときの特徴は次のとおりです。
・検索管理画面から見たとき、クロールのステータスが「増分クロール中」となっている。
・mssearch.exe プロセスを見る限り、CPU 使用率は変動しているのでどうやら動作しているように見える。
・クロール ログを見ても殆ど何も更新されていないように見える。
最終的にずっと待っていればクロールのステータスは「アイドル」に変わるので、クロール自体は正常に完了しているものと考えていますが、処理時間の違いの原因として何が考えられるでしょうか。
[解説]
上記の情報をもとに推測するに、処理時間の違いは SharePoint の「セキュリティ クロール」に依存して発生している可能性が考えられます。
セキュリティ クロールについて
SharePoint ではユーザーのアクセス権に対応した検索結果を表示するために、検索インデックスにコンテンツのアクセス権 (ACL) の情報も一緒に格納しています。このため、例えばあるサイトの配下に親から権限を継承するリストやライブラリが存在した場合、親サイトの権限が変更されると、その配下のすべてのコンテンツのアクセス権も同時に変更されることになります。この結果、増分クロールの際にはサイト配下のすべてのコンテンツのアクセス権の変更をインデックスに反映するためにアクセス権だけのクロールが行われる動作となります。このアクセス権だけのクロールを我々は、セキュリティ クロール (Security Only Crawl) と呼んでいます。
図１：アクセス権の継承
図２：クロールの動作
セキュリティ クロールの特徴は次の通りです。
・セキュリティ クロールは増分クロール時にのみ実施される。 (フル クロール時にはセキュリティとコンテンツ内容の両方がクロールされるためセキュリティのみのクロールは発生しない。)
・クロールは内部的に行われるため実コンテンツへのアクセスは発生しない。従って 、IIS ログにはコンテンツに対するクローラーのアクセス ログは残らない。
・Gatherer は SQL Server との通信により検索インデックスへのセキュリティの変更を完了させる。(検索インデックスのアクセス権は検索データベースで管理される。)
・セキュリティ クロールはコンテンツ数に比例してその処理時間が増加する傾向となる。
・実ファイルに対するクロール処理 (フィルタ処理) が発生しないため、クロール ログが記録されない。
セキュリティ クロールの識別方法
上記のとおり、セキュリティ クロールはクロール ログに残りませんので、クロール ログからは識別することができません。
SharePoint 2010 の場合には、以下の UI から、セキュリティ クロールされたコンテンツの数が確認できます。
1) Search サービス アプリケーションの管理サイトにアクセスします。
2) [クロール ログ] をクリックしてクロール ログを表示します。
3) [クロール履歴] をクリックして [セキュリティの更新] を確認します。
残念ながら、MOSS 2007 では上記の UI はありませんので、別の方法でセキュリティ クロールの判断をすることになります。
もちろん、管理者側でアクセス権の変更に心当たりがあれば、恐らくはセキュリティ クロールであろうと推測できますが、特に心当たりがない場合や、ハングやタイムアウトなどのトラブルと切り分けたい場合には、以下の方法で識別することが可能です。
MOSS 2007 におけるセキュリティ クロールの判断方法としては、主に次の3種類の方法があります。
1. パフォーマンス カウンタ
セキュリティ クロールが行われている場合はクロール ログにはエントリが追加されませんが、パフォーマンス カウンタを確認することでクロールの進行状況を確認することが可能です。
クロールの進行状況を確認するには、Office Server Search Gatherer オブジェクトの Document Entries カウンタおよび Documents Successfully Filtered カウンタを確認します。
・Document Entries カウンタ … 現在メモリにあるドキュメント エントリの数です。0 はインデックス作成が行われていないことを示します。
・Documents Successfully Filtered カウンタ … 正常にフィルタ処理されたドキュメントの数です。
具体例として、私の検証環境に50KBのテキストドキュメントを2000個アップロードして、サイトの権限を変更した後に増分クロールを行った際に取得したパフォーマンス カウンタの画面ショットを添付しました。(参考まで、この環境ではコンテンツのフル クロールに7分54秒、セキュリティ クロールには2分11秒かかりました。)
上記の例ではパフォーマンス ログを仕掛ける前に Office SharePoint Server Search サービスを再起動していますので、取得開始時点の Documents Successfully Filtered の値は0になっています。その後、増分クロールを開始して、Documents Successfully Filtered の値と Document Entries の値が増加していきます。このとき、クローラーはサイトのルート パスにある SiteData Web サービス (sitedata.asmx) と通信して、GetChanges メソッドを実行し、クロール対象の URL の一覧を取得しています。内部的にはコンテンツ データベースの変更ログ (EventCache テーブル) が参照され、セキュリティの変更が検出されたサイト配下のコンテンツの URL 一覧が返されることになります。取得された URL の一覧はクロール キューに登録され、Document Entries の値に反映されます。
Document Entries がある程度増加してからは、キューの中のアイテムが消化されていきますので、Document Entries は少しずつ減少していきます。このとき、Documents Successfully Filtered が正常に増加していくようであれば、クロール処理は正常に行われていると判断できますので、クロール ログが更新されていないのであればセキュリティ クロールが行われているであろうと判断できます。
2. 診断ログ
セキュリティ クロールが動作した場合、クロール ログにはアイテムのエントリが登録されませんが、診断ログには、以下のように GathererSql のカテゴリで、Gatherer トランザクションがコミットしたことを示すエントリが記録されます。ログに記録される内部 ID は、コンテンツ データベースのテーブルで持っているコンテンツの内部 ID と一致しますので、データベースを調べることでコンテンツの特定も可能です。
この方法は最も確実な方法となりますが、既定では以下のログは出力されないため、サーバーの全体管理の診断ログの設定において「MS Search 詳細トレース」のトレース ログのレベルを「中」に変更する必要があります。クロールされるコンテンツの数が多い場合には、この設定により診断ログのサイズが非常に大きくなる可能性がありますので、この設定は慎重に行うことをお勧めします。
--- 診断ログの例 ---
04:21.0 mssearch.exe (0x092C) 0x09A8 Search Server Common GathererSql 0 Medium CGatherer::CommitTransaction succeeded, URL sts3://site/siteurl=/siteid={ee7f629c-a36c-4327-b5f1-0652878fa4a3}/weburl=docs/webid={ba2b56ba-27d1-4cfb-90b4-e638d3f3b0ed}/listid={4d587236-3886-440f-a0d7-0d33622724cd}/folderurl=/itemid=27, CrawlID 51, SourceDocID 229 - File:d:\office\source\search\search\gather\server\gatherobj.cxx Line:9449
------
3. 変更ログ
コンテンツ データベースに保存されている変更ログのエントリを解析することで、増分クロールの対象となった変更ログの中にアクセス権に関わる変更があったかを確認することが可能です。この方法は直接データベースに対するクエリを実行するものですので、運用環境で実施される際は少し心配になるかもしれませんが、私の経験上、単純に SQL に対して SELECT クエリを発行するだけであれば、それほど大きな影響は無いと思います。もちろん、慎重に実施いただくに越したことはありません。
具体的な方法については以下のブログで Russ さんが解説してくれてますので、こちらを参考にしてみてください。
タイトル：Troubleshooting Security Only Crawl
URL：https://blogs.msdn.com/b/russmax/archive/2009/02/09/troubleshooting-security-only-crawl.aspx
まとめ
色々とお話ししましたが、結論として、増分クロールの時に予想外に時間がかかった場合は、まずタスクマネージャで mssearch.exe プロセスの CPU 使用率を確認していただき、ハングしていないようであればセキュリティ クロールの可能性がありますので、セキュリティ変更などのオペレーションを確認していただくとよいと思います。必要に応じてパフォーマンス カウンタの確認をすることでコンテンツのクロールが停滞していないか確認できますので、上述の確認方法を参考にしていただければと思います。