Dela via

SharePoint 2010 における検索サーバーの冗長構成について：前編

  • Artikel
<関連記事> SharePoint 2010 における検索サーバーの冗長構成について：前編 SharePoint 2010 における検索サーバーの冗長構成について：後編

 

 

皆さんこんにちは。

SharePoint サポートチームの荒川です。

 

今回は SharePoint 2010 における検索サーバーの冗長構成について、前半と後半の 2 回に分けてお話ししたいと思います。

 

SharePoint 2010 では従来のバージョンと比較して、より柔軟性に富んだ検索トポロジを設計できるようになりました。

 

従来のようなインデックスサーバー、クエリ サーバーという概念は無くなり、各役割はコンポーネント化され、検索サーバー上で柔軟なトポロジ構成を取れるようになりました。

クロール コンポーネントが実行される検索サーバー (従来でいうところのインデックスサーバー) で作成された一時検索インデックス ファイルは、クエリ コンポーネントが実行される検索サーバー (従来でいうところのクエリ サーバー) にコピーされた後に適宜削除され、クロール コンポーネント上には検索インデックスを蓄積しません。このため、クロールコンポーネントは純粋にコンテンツをクロールする目的にのみ利用されるようになり、従来のようにインデックス サーバーが単一の障害ポイントになることは無くなりました。

 

この変更により、検索インデックスファイルは、クエリ コンポーネント側で保持されることになります。もちろん、クエリ コンポーネントの検索インデックスの完全なコピーを複数のクエリ コンポーネントで保持することができ (ミラー化) いずれか 1 台のクエリ コンポーネントがダウンした場合であっても、既存の検索インデックスが完全に失われることを防止できます。さらに、検索インデックスの持ち方についても柔軟性に富んだ構成をとることが可能で、例えばクエリコンポーネントに格納される検索インデックスを複数のパーティションに分割し、1台のクエリ サーバーにすべてのインデックスを保持するのではなく、複数のクエリサーバーに分散して保持させることも可能です。(この辺りはまた別の機会に詳しく解説したいと思います。)

 

 

このようなトポロジモデルの変更により、複数のインデックス サーバーを用いてクロールを実行するなど、従来は行えなかった柔軟な運用管理が行えるようになりました。このあたりの詳しい解説は、以下の検索アーキテクチャモデルに関する資料に記載がありますので、ご参考いただけると幸いです。

 

タイトル： SharePoint Server 2010 の検索アーキテクチャ: モデル URL ： https://technet.microsoft.com/ja-jp/library/gg602074 タイトル：検索トポロジを管理する URL ： https://technet.microsoft.com/ja-jp/library/ee805956

 

さて、トポロジの設計および設定自体は管理 UI から比較的簡単に行えますが、実際に障害が発生した際には管理者側で行わなければならないいくつかのタスクがあります。このあたりは、まだ詳しく書かれた資料が少ないように思いますので、今回はこの部分にフォーカスした話を展開していきたいと思います。

 

 

■運用中にクエリコンポーネントで障害が発生したシナリオを考える

実際に運用中にクエリコンポーネントで障害が発生した場合どのような動作が生じるのでしょうか。

 

ユーザーの検索クエリへの影響

ファームに複数台存在するクエリコンポーネントのいずれか 1 台がダウンした場合、ユーザーが検索を実行するタイミングによって、検索クエリ要求がダウンしたクエリ コンポーネントに送信される可能性があります。この場合、ユーザーには「内部サーバーエラー」が返され検索に失敗します。

 

 

検索に一度失敗すると、失敗したクエリコンポーネントはバッド リスト (Load Balancer サービスのキャッシュ) に登録され、以後のクエリには使用されなくなります。このため、エラーが恒久的に続くことはありませんが、バッドリスト キャッシュの有効期限は既定で 10 分なので、10 分経過後には再び検索クエリ要求がダウンしたクエリコンポーネントに送信される可能性があります。再び検索に失敗すると、再度バッド リストに 10 分間エントリが登録される仕組みです。

この動作はダウンしたクエリコンポーネントが復旧されるか、検索トポロジからクエリ コンポーネントが削除されるまで続きます。

したがって、ユーザー側には、概ね検索は成功するが、ごく稀に検索時に「内部サーバーエラー」が返される状況が、クエリサーバーが復旧されるまで続くことになります。

 

失敗したクエリサーバーはバッド リストに保持される期間は、BadListPeriod パラメータにより変更できます。

 

<設定方法> ファームのいずれか 1 台の SharePoint サーバーで SharePoint 2010 管理シェルを開き、以下のように設定します。   $topo=Get-SPTopologyServiceApplicationProxy Set-SPTopologyServiceApplicationProxy -Identity $topo -BadListPeriod "任意の数字 (秒)" (例:3600 など)   補足：最大 480 分 (28800 秒) まで指定が可能ですが、長くした場合にはクエリ サーバーの復旧後に負荷分散が正しく機能するまでに時間がかかる可能性がありますので注意が必要です。

 

 

クロールへの影響

クエリ コンポーネントの障害は、検索クエリだけでなく、クロール動作にも影響を及ぼします。

SharePoint 製品とテクノロジの以前のバージョンである MOSS 2007 では、ファームのいずれか 1 台のクエリ サーバーがダウンすると、進行中のクロールは中断され、管理者により明示的にクエリ サーバーが復旧されるまで、クロールが進行しませんでした。これは、インデックスサーバーで作成されたインデックスがファームのすべてのクエリ サーバーに等しく伝達 (プロパゲート) され、整合性を保持して管理される必要があったためです。このため、通常はダウンしたクエリ サーバーをファームから取り除くか、再構成して再度利用できるようにするまで、クロールを再開することができませんでした。

 

 

これに比べて SharePoint 2010 では、事前に管理者により、ファームで最低限稼働する必要があるクエリコンポーネントの数を指定できるようになりました。最低限の数が満たされている限り、クエリ サーバーがダウンした場合でも残りのクエリ サーバーに対してインデックスを伝達できるため、クロール処理そのものが停止することはありません。

 

具体的には、TimeBeforeAbandoningQueryComponent と MinimumReadyQueryComponentsPerPartition の設定値が、この動作に影響します。

 

SharePoint Server 2010 のクロール処理ではクロール コンポーネントにより作成された検索インデックスが、クロール中に継続的にクエリ サーバーに伝達されます。クロール処理が実行されている際にクエリサーバーがダウンしていた場合、伝達処理が失敗し、5 分おきに再試行されます。伝達処理が再試行されている間は、クロール処理が中断されます。伝達処理の再試行は、伝達処理が正常に完了するか、TimeBeforeAbandoningQueryComponent で指定された時間 (既定値は 60 分) が経過して対象のクエリ サーバーが使用不可としてマークされるまで続きます。

 

クエリ サーバーが使用不可としてマークされた後、クロールが再開されるかどうかは、MinimumReadyQueryComponentsPerPartition の設定値により変わります。MinimumReadyQueryComponentsPerPartition は、インデックス パーティションごとに最低限稼働していなければならないクエリ コンポーネントの数が指定されており、使用可能なクエリ サーバーの台数が MinimumReadyQueryComponentsPerPartition で指定された数 (既定値は 2) を満たす場合には使用不可としてマークされたクエリ サーバーは無視してクロールが再開され、使用可能なクエリサーバーの台数が MinimumReadyQueryComponentsPerPartition で指定された数に満たない場合には、管理者によりクエリコンポーネントが復旧されるまでクロールが中断したままとなります。

 

例えば、クエリサーバー 2 台構成の環境においていずれか 1 台のクエリ サーバーがダウンした場合にクロール処理を継続するためには、MinimumReadyQueryComponentsPerPartition の値を 1 に変更する必要があります。TimeBeforeAbandoningQueryComponent の値の変更は必須ではありませんが、クロールの中断時間を短くしたい場合には、15 分程度に設定しても問題ありません。あまりに短い時間を設定するとパフォーマンスに影響する可能性があるので注意が必要です。

 

<設定方法> ファームのいずれか 1 台の SharePoint サーバーで SharePoint 2010 管理シェルを開き、以下のように設定します。   $ssa=Get-SPEnterpriseSearchServiceApplication $ssa.MinimumReadyQueryComponentsPerPartition =1 $ssa.TimeBeforeAbandoningQueryComponent=[timespan]"00:15:00" $ssa.update()

 

 

■運用中にクロールコンポーネントで障害が発生したシナリオを考える

クロール コンポーネントについてはクエリコンポーネントよりも単純です。

クロール コンポーネントが複数のサーバーに割り当てられている場合、サービスアプリケーション内で個々のクロール コンポーネントのステータスが定期的に確認され、"オンライン" の状態のクロールコンポーネントが使用されてクロールが行われます。ファームに複数台存在するクエリ サーバーのいずれか 1 台がダウンした場合、クロールコンポーネントと通信できない状況が一定時間継続すると、使用できないクロール コンポーネントを使用不可とマークし、"応答なし" と設定します。その後、"応答なし" 以外のクロール コンポーネントでクロールが継続されるようになります。

なお、障害が発生したクロールコンポーネントが復旧して通信できるようになった際には、通常は 1、2 分で程度で "オンライン" に変更されます。

 

クロール コンポーネントが使用不可としてマークされるまでの時間は、クロールコンポーネントが動作する各サーバー上のレジストリにて変更できます。ただし、あまりに短い時間を設定するとパフォーマンスに影響する可能性があるので注意が必要です。

 

キー：HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Global\Gathering Manager 名前：DisableInterval   補足：既定値は 60 (分/10進数) です。

 

 

(後編に続く)