コンテンツのクロール (Search Server 2008)
更新日: 2010年9月
適用対象: Microsoft Search Server 2008
トピックの最終更新日: 2010-09-20
注意
別途記載のない限り、この記事の情報は Microsoft Search Server 2008 と Microsoft Search Server 2008 Express の両方に適用されます。
コンテンツのクロールは、システムがコンテンツとそのプロパティ (メタデータとも呼ばれます) にアクセスして解析し、コンテンツ インデックスを構築するプロセスです。このインデックスは、検索クエリ サービスの実行に使用されます。
コンテンツが正常にクロールされた結果、クエリを検索できるようにする個々のファイルまたはコンテンツが、クローラによってアクセスされて読み取られます。これらのファイルのキーワードとメタデータは、コンテンツ インデックス (単にインデックスとも呼ばれます) に保存されます。インデックスは、インデックス サーバーのファイル システムに保存されるキーワードと、検索データベースに保存されるメタデータで構成されます。キーワード、各コンテンツに関連付けられたメタデータ、およびコンテンツがクロールされたソースの URL について、それらの間のマッピングがシステムにより維持されます。
注意
クローラによって、ホスト サーバー上のファイルが変更されることはありません。ホスト サーバー上のファイルは、アクセスされて読み取られ、インデックスが作成されるインデックス サーバーにそのファイルのテキストとメタデータが送信されます。ただし、クローラによりホスト サーバー上のコンテンツが読み取られるため、特定のコンテンツ ソースをホストするサーバーでは、クロールされたファイルの最終アクセス日時が更新される場合があります。
コンテンツをクロールするタイミングを決定する
サーバー ファームを展開してしばらくの間実行したら、検索サービス管理者は、通常、クロールのスケジュールを変更する必要があります。この処理を行う理由は次のとおりです。
ダウンタイムとピーク使用時間の変化に対応するため。
コンテンツをホストするサーバーでのコンテンツ更新の頻度の変化に対応するため。
以下の目的でクロールをスケジュールするため。
低速のホスト サーバーにホストされているコンテンツを高速のホスト サーバーにホストされているコンテンツとは別にクロールする。
新しいコンテンツ ソースをクロールする。
対象のコンテンツが更新されるたびにクロールを実行します。たとえば、毎日更新されるリポジトリは、毎日クロールし、それほど頻繁に更新されないリポジトリのクロール頻度はそれよりも減らします。
クロールの実行
通常、ほとんどのクロールはスケジュールを作成することで自動化できます。ただし、クロールを手動で開始することが必要になる場合があります。たとえば、クロールおよびインデックス作成を行うコンテンツにクロール ルールなどの管理上の変更を適用したり、クロール ログでのエラーが解決されたかどうかを確認したりするために、クロールを開始するような場合です。
さらに、スケジュールされているか手動で開始されているかにかかわりなく、1 つ以上のクロールを停止または一時停止しなければならない場合もあります。たとえば、クロール対象のコンテンツをホストしているサーバーの管理者から、クロールによってサーバーに過剰な負荷が生じていると知らされる場合があります。あるいは、クロール対象のサーバーが現在オフラインになっていることを通知される場合もあります。どちらの場合でも、クロールの停止または一時停止が必要となります。
フル クロールは増分クロールより多くの時間とサーバー リソースを消費します。フル クロールには、次のような特徴があります。
増分クロールより多くのメモリおよび CPU サイクルをインデックス サーバーで消費します。
サーバー ファームのコンテンツをクロールする場合に、増分クロールより多くのメモリおよび CPU サイクルを Web フロントエンド サーバーで消費します。ただし、この点は、サーバー ファームの外部にあるコンテンツには当てはまりません。
増分クロールより多くのネットワーク帯域幅を使用します。
重要
どの種類のコンテンツ ソースのクロールを停止した場合でも、そのコンテンツ ソースの次回のクロールでは、Microsoft Search Server 2008 によって自動的にフル クロールが実行されます。これは、ユーザーが増分クロールを実行しようとした場合にも当てはまります。したがって、クロールを停止する代わりに、一時停止する必要がないかどうかを十分に検討してください。
また、一時停止されている各コンテンツ ソースがインデックス サーバーでメモリと CPU リソースを消費するため、あまりにも多くのコンテンツ ソースのクロールを同時に一時停止しないよう注意してください。
フル クロールまたは増分クロールの開始、クロールの停止、一時停止、または再開には、次のいずれかを行います。
クロールのスケジュール
以下のセクションでは、スケジュールどおりにコンテンツをクロールするうえでの考慮事項の詳細について説明します。
ダウンタイムと使用がピークとなる時間
クロール対象のコンテンツをホストするサーバーのダウンタイムとピーク使用時間を考慮します。たとえば、サーバー ファームの外部にあり、多数のサーバーでホストされているコンテンツをクロールする場合、サーバーごとのバックアップ スケジュールが異なり、ピーク使用時間もそれぞれ異なることが考えられます。一般に、サーバー ファーム外部のサーバーの管理は制御できません。そのため、クロール対象のコンテンツをホストするサーバーの管理者とクロールについて調整し、ダウンタイムまたはピーク使用時にサーバー上のコンテンツをクロールしないようにする必要があります。
注意
ホスト サーバーのピーク使用時間やダウンタイムの時間は変化するため、新規作成するコンテンツ ソースだけでなく、すべてのコンテンツ ソースのクロール スケジュールを定期的に再評価することをお勧めします。
一般的なシナリオとして、組織の管理下にないコンテンツが、SharePoint サイト上のコンテンツに関連している場合があります。このコンテンツの開始アドレスを既存のコンテンツ ソースに追加することも、外部コンテンツ用の新しいコンテンツ ソースを作成することもできます。外部サイトの可用性には大きな差があるので、外部コンテンツごとに個別のコンテンツ ソースを追加すると便利です。このように、外部コンテンツに対応するコンテンツ ソースは、他のコンテンツ ソースと異なる時間にクロールできます。その後で、各サイトの可用性に沿ったクロール スケジュールで外部コンテンツを更新できます。
頻繁に更新されるコンテンツ
クロール スケジュールを計画する場合は、頻繁に更新されるコンテンツ ソースと、そうでないコンテンツ ソースがあることを考慮します。たとえば、特定のサイト コレクションや外部ソースのコンテンツが金曜日にしか更新されないことがわかっている場合、そのコンテンツを週 2 回以上クロールするとリソースの浪費となります。一方、月曜日から金曜日まで継続的に更新され、土曜日と日曜日には通常更新されないサイト コレクションがサーバー ファームに含まれているとします。この場合は、平日に数回クロールし、週末にはクロールしないようにします。
環境内の複数のサイト コレクションにコンテンツが保存されている場合、各 Web アプリケーション内のサイト コレクションごとに追加のコンテンツ ソースを作成できます。たとえば、1 つのサイト コレクションに保存されているのがアーカイブ済み情報のみの場合、そのコンテンツは、頻繁に更新されるコンテンツを含むサイト コレクションほど頻繁にクロールする必要はありません。この場合、この 2 つのサイト コレクションは、別のスケジュールでクロールできるように異なるコンテンツ ソースを使用してクロールします。
フル クロールと増分クロールのスケジュール
検索サービスの管理者は、コンテンツ ソースごとに個別のクロール スケジュールを構成できます。各コンテンツ ソースで、フル クロールを行う時間と増分クロールを行う時間を別々に指定できます。
注意
増分クロールを実行するには、事前に特定のコンテンツ ソースに対するフル クロールを実行する必要があります。
検索サービスを実行するサーバーおよびクロール対象コンテンツをホストするサーバーの可用性、パフォーマンス、および帯域幅の考慮事項に基づいて、クロール スケジュールを計画することをお勧めします。
クロール スケジュールを計画するときには、次のベスト プラクティスを考慮してください。
コンテンツをホストするサーバーの可用性の類似点および許容される全体的なリソース配分状況に基づいて、コンテンツ ソースの開始アドレスをグループ化します。
コンテンツをホストするサーバーが利用でき、サーバーのリソースに対する需要が低い時間に、各コンテンツ ソースの増分クロールをスケジュールします。1 つ以上のクローラ影響ルールを追加または編集して、クロールするサーバーの負荷を軽減することもできます。クローラ影響ルールの詳細については、「クローラの影響を管理する (Search Server 2008)」を参照してください。
ファーム内のサーバーの負荷が時間的に分散されるようにクロール スケジュールをずらします。
次のセクションで示す理由のために必要な場合にのみ、フル クロールをスケジュールします。フル クロールは増分クロールよりも低い頻度で実行することをお勧めします。
フル クロールが必要になる管理上の変更は、計画されているフル クロールのスケジュールの直前に行われるようにスケジュールします。たとえば、次回に予定されているフル クロールの前にクロール ルールの作成をスケジュールすることをお勧めします。それにより、新たにフル クロールを実行する必要がなくなります。
同時クロールは、クロールを行うインデックス サーバーの容量に基づいて行います。インデックス サーバーが一度に複数のコンテンツ ソースを使用してクロールしないように、クロール スケジュールをずらすことをお勧めします。インデックス サーバーのパフォーマンスとコンテンツをホストするサーバーのパフォーマンスによって、クロールを同時に実行できる範囲が決定します。各コンテンツ ソースの標準的なクロール実行時間を把握するに従って、クロール スケジュールの戦略を改良できます。環境内でのクロールの長さに関する傾向データを記録することをお勧めします。
フル クロールを実行する理由
検索サービス管理者がフル クロールを実行する理由には、次のようなものがあります。
ファーム内のサーバーに 1 つ以上の修正プログラムまたはサービス パックがインストールされたため。詳細については、修正プログラムまたはサービス パックのドキュメントを参照してください。
検索サービス管理者が新規管理プロパティを追加したため。
Windows SharePoint Services 3.0 サイトの ASPX ページのインデックスを再作成するため。
注意
Windows SharePoint Services 3.0 サイトの ASPX ページが変更されると、クローラは発見できなくなります。そのため、個別のリスト アイテムが削除されると、増分クロールではビューやホーム ページのインデックスが再作成されません。ASPX ファイルを含むサイトのフル クロールを定期的に実行することで、ページのインデックスが確実に再作成されるようにすることをお勧めします。
ファイル共有の最後のフル クロールの後にファイル共有に対して行われたセキュリティ変更を検出するため。
増分クロールの連続する障害を解決するため。まれに、リポジトリ内の任意のレベルで増分クロールに 100 回連続で失敗すると、インデックス サーバーにより、影響を受けるコンテンツがインデックスから削除されることがあります。
クロール ルールが追加、削除、または変更されたため。
破損したインデックスを修復する必要がある。
検索サービス管理者が 1 つ以上のサーバー名マッピングを作成した。
既定のコンテンツ アクセス アカウントにアカウントが割り当てられたか、クロール ルールが変更された。
増分クロールが要求された場合でも、次の条件下では、システムによってフル クロールが実行されます。
検索サービス管理者が直前のクロールを停止した。
コンテンツ データベースが復元された。
注意
Microsoft Office サーバー製品インフラストラクチャ更新プログラム を実行している場合は、stsadm コマンドライン ツールの復元操作を使用して、コンテンツ データベースの復元によってフル クロールが行われるかどうかを変更できます。
ファーム管理者がコンテンツ データベースを切断し、再接続した。
サイトのフル クロールが一度も実行されたことがない。
変更ログには、クロール中のアドレスのエントリが含まれません。クロール中のアイテムの変更ログにエントリが含まれていないと、増分クロールは実行されません。
既定のコンテンツ アクセス アカウントにアカウントが割り当てられたか、クロール ルールが変更された。
破損したインデックスを修復する必要がある。
破損の重大度によっては、インデックス内で破損が検出されたときにフル クロールが試行される場合があります。
初期展開の後、ファーム内のサーバー、およびコンテンツをホスティングしているサーバーのパフォーマンスと容量に応じて、スケジュールを調整できます。
関連項目
概念
コンテンツをクロールする方法 (Search Server 2008)
フル クロールをスケジュールする (Search Server 2008)
増分クロールをスケジュールする (Search Server 2008)