テスト結果: 大規模展開シナリオ (FAST Search Server 2010 for SharePoint)

適用先: FAST Search Server 2010

トピックの最終更新日: 2015-03-09

Microsoft FAST Search Server 2010 for SharePoint の大規模展開テスト シナリオの対象は大きなテスト コーパスでした。このシナリオでは、情報を最新の状態に保つために、営業時間に増分クロールが実行される可能性がありました。また、コンテンツの量は最大 1 億アイテムでした。

親 Microsoft SharePoint Server 2010 ファームは 2 台のフロントエンド Web サーバー、2 台のアプリケーション サーバー、および 1 台のデータベース サーバーでセットアップし、次のように配置しました。

• コンテンツのクロールには、SharePoint Server 2010 クローラー、インデックス コネクタ フレームワーク、および FAST Content Search Service Application (Content SSA) を使用しました。また、テスト セットアップの I/O 制限 (1 Gbit/ネットワーク) に対応するために、Content SSA の 2 個のクロール コンポーネントを 2 台のアプリケーション サーバーに分散しました。単一ネットワーク アダプターではボトルネックになる可能性があったからです。

• アプリケーション サーバーの 1 台でも、ファームのサーバーの全体管理をホストしました。

• データベース サーバーはクロール データベース、FAST Search Server 2010 for SharePoint 管理データベース、およびその他の SharePoint Server 2010 データベースをホストしました。

アプリケーション サーバーおよびフロントエンド Web サーバーに必要なのはオペレーティング システム、アプリケーション バイナリ、およびログ ファイルの容量だけなので、別のデータ ストレージは使用しませんでした。

この記事の内容

• テストの展開

• テストの特性

• テスト結果

テストの展開

大規模展開シナリオで、以下の FAST Search Server 2010 for SharePoint 展開をテストしました。

テストの特性

このセクションでは、テスト環境のハードウェア、ソフトウェア、トポロジ、および構成の詳細について説明します。

ハードウェア/ソフトウェア

次のハードウェアおよびソフトウェアを使用して、指定された展開をテストしました。

FAST Search Server 2010 for SharePoint サーバー

• Windows Server 2008 R2 x64 Enterprise Edition

• ハイパースレッディングおよび Turbo Boost が有効の 2 台の Intel L5520 CPU

• 24 GB のメモリ

• 1 Gbit/秒のネットワーク カード

• ストレージ サブシステム:

  • OS: 2 個の 146 GB 10k RPM SAS ディスク (RAID 1)

  • アプリケーション: 12 個の 146 GB 10k RPM SAS ディスク (RAID50) (それぞれに 6 ドライブのパリティ グループが 2 つ)。フォーマット容量合計は 2 TB

  • ディスク コントローラー: HP Smart Array P410、ファームウェア 3.30

  • ディスク: HP DG0146FARVU、ファームウェア HPD6

SharePoint Server 2010 サーバー

• Windows Server 2008 R2 x64 Enterprise Edition

• 2 台の Intel L5420 CPU

• 16 GB のメモリ

• 1 Gbit/秒のネットワーク カード

• OS/プログラム用のストレージ サブシステム: 2 個の 146GB 10k RPM SAS ディスク (RAID1)

SQL サーバー

SharePoint Server 2010 サーバーと同じ仕様ですが、6 個の 146GB 10k RPM SAS ディスク (RAID5) を持つ SQL データ用追加ディスク RAID を備えています。

トポロジ

このセクションでは、テスト展開のトポロジについて説明します。

L1

L1 は、単一行、6 列展開で、追加の管理ノードを備えています。L1 のセットアップには次の deployment.xml ファイルを使用しました。

<?xml version="1.0" encoding="utf-8" ?> 

<deployment version="14" modifiedBy="contoso\user" 

   modifiedTime="2009-03-14T14:39:17+01:00" comment="L1" 
   xmlns="https://www.microsoft.com/enterprisesearch" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:schemaLocation="https://www.microsoft.com/enterprisesearch deployment.xsd"> 

   <instanceid>L1</instanceid> 

   <connector-databaseconnectionstring> 
      [<![CDATA[jdbc:sqlserver://sqlbox.contoso.com\sql:1433;DatabaseName=L1.jdbc]]> 
   </connector-databaseconnectionstring> 

   <host name="fs4sp1.contoso.com"> 
      <admin /> 
      <query /> 
      <webanalyzer server="true" link-processing="true" lookup-db="true" max-targets="4"/> 
      <document-processor processes="12" /> 
   </host> 

   <host name="fs4sp2.contoso.com"> 
      <query /> 
      <searchengine row="0" column="0" /> 
      <document-processor processes="12" /> 
   </host> 

   <host name="fs4sp3.contoso.com"> 
      <content-distributor /> 
      <searchengine row="0" column="1" /> 
      <document-processor processes="12" /> 
   </host> 

   <host name="fs4sp4.contoso.com"> 
      <content-distributor /> 
      <searchengine row="0" column="2" /> 
      <document-processor processes="12" /> 
   </host> 

   <host name="fs4sp5.contoso.com"> 
      <content-distributor /> 
      <searchengine row="0" column="3" /> 
      <document-processor processes="12" /> 
   </host> 

   <host name="fs4sp6.contoso.com"> 
      <indexing-dispatcher /> 
      <searchengine row="0" column="4" /> 
      <document-processor processes="12" /> 
   </host> 

   <host name="fs4sp7.contoso.com"> 
      <indexing-dispatcher /> 
      <searchengine row="0" column="5" /> 
      <document-processor processes="12" /> 
   </host> 

   <searchcluster> 
      <row id="0" index="primary" search="true" /> 
   </searchcluster> 

</deployment> 

L2

L2 の構成は L1 と同じで、その他に専用検索行があります。

検索行によりクエリ スループット容量が追加され、クエリ冗長性が実現したほか、クエリを切り離しやすくなり、コンテンツ処理の読み込みも軽減されました。また、専用検索行で実行されていたサーバーのうち 3 台にクエリ処理コンポーネントが含まれ (query)、さらに、その展開では管理サーバーにもクエリ処理コンポーネントが含まれていました (fs4sp1.contoso.com)。Query SSA は、通常の運用では後者のクエリ処理コンポーネントを使用しませんが、メンテナンスのために検索行全体を停止する場合は、クエリを提供できるようにフォールバックとしてそのコンポーネントを使用する場合があります。

L2 のセットアップには次の deployment.xml ファイルを使用しました。

<?xml version="1.0" encoding="utf-8" ?> 

<deployment version="14" modifiedBy="contoso\user" 

   modifiedTime="2009-03-14T14:39:17+01:00" comment="L2" 
   xmlns="https://www.microsoft.com/enterprisesearch" 
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   xsi:schemaLocation="https://www.microsoft.com/enterprisesearch deployment.xsd"> 

   <instanceid>L2</instanceid> 

   <connector-databaseconnectionstring> 
      [<![CDATA[jdbc:sqlserver://sqlbox.contoso.com\sql:1433;DatabaseName=L2.jdbc]]> 
   </connector-databaseconnectionstring> 

   <host name="fs4sp1.contoso.com"> 
      <admin /> 
      <query /> 
      <webanalyzer server="true" link-processing="true" lookup-db="true" max-targets="4"/> 
      <document-processor processes="12" /> 
   </host> 

   <host name="fs4sp2.contoso.com"> 
      <searchengine row="0" column="0" /> 
      <document-processor processes="12" /> 
   </host> 

   <host name="fs4sp3.contoso.com"> 
      <content-distributor /> 
      <searchengine row="0" column="1" /> 
      <document-processor processes="12" /> 
   </host> 

   <host name="fs4sp4.contoso.com"> 
      <content-distributor /> 
      <searchengine row="0" column="2" /> 
      <document-processor processes="12" /> 
   </host> 

   <host name="fs4sp5.contoso.com"> 
      <content-distributor /> 
      <searchengine row="0" column="3" /> 
      <document-processor processes="12" /> 
   </host> 

   <host name="fs4sp6.contoso.com"> 
      <indexing-dispatcher /> 
      <searchengine row="0" column="4" /> 
      <document-processor processes="12" /> 
   </host> 

   <host name="fs4sp7.contoso.com"> 
      <indexing-dispatcher /> 
      <searchengine row="0" column="5" /> 
      <document-processor processes="12" /> 
   </host> 

   <host name=" fs4sp8.contoso.com "> 
      <query /> 
      <searchengine row="1" column="0" />  
   </host> 

   <host name="fs4sp9.contoso.com "> 
      <query /> 
      <searchengine row="1" column="1" /> 
   </host> 
   
   <host name="fs4sp10.contoso.com "> 
      <query /> 
      <searchengine row="1" column="2" /> 
   </host> 

   <host name="fs4sp11.contoso.com "> 
      <searchengine row="1" column="3" /> 
   </host> 

   <host name="fs4sp12.contoso.com"> 
      <searchengine row="1" column="4" /> 
   </host> 

   <host name="fs4sp13.contoso.com" 
      <searchengine row="1" column="5" /> 
   </host> 

   <searchcluster> 
      <row id="0" index="primary" search="true" /> 
      <row id="1" index="none" search="true" /> 
   </searchcluster> 

</deployment>

L3

L3 の構成は L2 と同じですが、検索行では追加のバックアップ インデクサーが有効になっています。バックアップ インデクサーを展開するために、L2 の deployment .xml ファイルを次にように変更しました。

... 
<searchcluster> 
   <row id="0" index="primary" search="true" /> 
   <row id="1" index="secondary" search="true" /> 
</searchcluster> 
... 

データセット

このセクションでは、テスト用ファームのデータセット (データベースのコンテンツとサイズ、検索インデックス、外部データ ソース) について説明します。

次の表は、全体的な測定基準を示しています。

次の表は、インデックスの構築に使用したコンテンツ ソースの種類を示しています。この表で示す数値には、ソースあたりのアイテムの合計数が反映されています。これには複製されたコピーも含まれます。アイテムの合計数とインデックス サイズが違う理由は 2 つあります。

• アイテムがコンテンツ ソースのインデックスで無効になっている場合がある。

• ドキュメント形式の種類にインデックスを作成できなかった。

SharePoint ソースについては、SQL の各コンテンツ データベースのサイズが未加工データのサイズを表します。

大規模展開テスト シナリオの十分なコンテンツ ボリュームに達するように、データ ソースの複製を追加しました。各ドキュメントの各コピーがインデックスで一意のアイテムとして表示されますが、重複のトリミング機能では重複として処理されます。クエリ照合の観点から見ると、読み込みは、一意のドキュメントすべてにインデックスが作成されている場合とそれほど変わりません。しかし、これらのソースの結果は重複検出を起動し、検索結果に折りこまれます。

テスト結果

このセクションでは、読み込みをかけたときにさまざまな展開がどのように動作するか、具体的にはクロールとインデックス付けのパフォーマンス、クエリ パフォーマンス、およびディスクの使用量を表すデータを示します。

クロールとインデックス付けのパフォーマンス

すべての大規模展開シナリオがコンテンツ ソースの帯域幅によって制限され、L1 から L3 のすべてのクロール レートは 1 秒あたり約 200 アイテムでした。

クエリ パフォーマンス

大規模展開 L1、L2、および L3 は、中規模展開テスト シナリオの M1、M4、および M6 の規模を大きくしたものです (詳細については、「展開オプション (FAST Search Server 2010 for SharePoint)」を参照)。つまり、大規模展開では、中規模展開に列を追加し、クエリ パフォーマンスを維持しながらより多くのコンテンツにインデックスを作成できるようにしました。次の図は、進行中のクロールがある場合とない場合の L1 から L3 のクエリの遅延時間を QPS の関数として示しています。

L2 と L3 のパフォーマンスはほぼ同じでした。また、対応するより小さな規模の M4 および M6 と似ていました。

L1 のパフォーマンスは、M1 とは少しパターンが異なっていました。最大許容遅延時間が 1 秒だとすると、M1 の QPS はクロールが行われてないときは 27 QPS、クロール中は 16 QPS でした。同じ条件での L1 の結果はそれぞれ 18 QPS と 9 QPS でした。M1 と比べ、L1 には列が追加されていることから、より多くのサーバーがかかわることが推測できます。あるクエリがあるタイミングで最も遅いサーバーで処理されていると、これがクエリ遅延の要因になります。この現象は L2 や L3 の展開ではあまり目立ちませんでした。この展開には専用検索行があり、リソースをめぐって競い合う他のコンポーネントがサーバーになかったからです。

ディスク使用量

次の表は、L1 展開のすべてのサーバーのディスク使用量を合わせたものです。L2 および L3 は、2 行目の FiXML およびインデックス ファイルの複製用の追加ディスク容量を使用しました。

See Also

Concepts

パフォーマンスと容量の計画 (FAST Search Server 2010 for SharePoint)
コンテンツ容量の拡張について (FAST Search Server 2010 for SharePoint)
展開オプション (FAST Search Server 2010 for SharePoint)