冗長性を計画する (Search Server 2008)

  • [アーティクル]

更新日: 2008年7月

適用対象: Microsoft Search Server 2008

 

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

この記事の内容 :

  • 冗長性について

  • サーバーの冗長要件を定義する

  • 最低レベルのサーバー冗長性を計画する

  • ベースライン サーバー ファーム トポロジを選択する

  • クエリ サーバーの冗長性を計画する

  • データベース サーバーの冗長性を計画する

  • サーバーの障害のリスクを評価する

ここでは、Microsoft Search Server 2008 ファームに含まれる冗長サーバーの役割をスケール アウトするためのオプションについて説明します。この記事を読めば、環境に適した冗長オプションを判断して記録できるようになります。

このトピックを読む前に、以下のトピックをお読みください。

Search Server 2008 および Search Server 2008 Express は、通常はコンテンツをホストしないことに注意してください。これらは主として、Search サービスのホスト、Windows SharePoint Services および Microsoft Office SharePoint Server のファーム上または他のリモート コンテンツ ソース上のコンテンツのクロール、およびクエリへの応答に使用されます。環境によっては、Search Server 2008 および Search Server 2008 Express を使用してコンテンツをホストできます。コンテンツをホストするために Search Server 2008 または Search Server 2008 Express を使用する場合は、「パフォーマンスおよび容量を計画する (Windows SharePoint Services)」の記事を読み、コンテンツのホストと Search Server 2008 または Search Server 2008 Express の実行を同じファームで行うための要件を確認してください。

冗長性について

冗長性という語は、可用性と同義に誤って解釈されることが少なくありません。これらの概念には関連性がありますが、まったく同じものではありません。冗長性とは、ファームのパフォーマンスを向上させたり、追加ユーザーに適応させるためにスケール アウトを行ったり、可用性を向上させるなど、何かを目的として負荷分散環境で複数のサーバーを使用することを意味します。

可用性とは、接続を受け入れ、ファームの 1 つ以上のサーバーが稼動しなくなっても通常通り動作するために設計された複数サーバー環境を意味します。したがって、可用性は冗長性を表すと同時に、フェールオーバー メカニズムやその他の考え得る特性をも表します。ただし、冗長性を持つシステムは、必ずしも高可用性を持つとは限りません。

可用性の詳細については、「可用性の計画 (Search Server 2008)」を参照してください。

ここでは、Search Server 2008 ファームで冗長サーバーを実装する方法について説明します。

サーバーの冗長性の要件を定義する

Search Server 2008 は、容量、パフォーマンス、および可用性のための拡張可能なサーバー ファームをサポートします。一般に、容量は、使用するサーバー コンピュータの台数を決定するときの最初の考慮事項です。パフォーマンスの要件を分析した後は、可用性もサーバー ファーム内のサーバー コンピュータの台数と規模または容量を決定するうえで重要です。

このセクションを読むと、冗長サーバーを展開して、サーバー展開トポロジに拡張可能な容量を組み込む必要があるかどうかを判断できます。または、冗長サーバーのない限定されたサーバー展開を計画することが組織にとって適切であるかどうかを判断できます。

最低レベルのサーバー冗長性を計画する

冗長性ソリューションを展開するには、サーバー ファームを展開する必要があります。

ベースラインとして使用できるサーバー トポロジには、いくつか種類があります。いずれのトポロジにも、ある程度のサーバー冗長性が組み込まれています。ここでは、サーバー ファームの概要を示します。

注意

以下の説明では、インデックスの役割がインストールされたサーバーをインデックス サーバーと呼び、クエリの役割がインストールされたサーバーをクエリ サーバーと呼びます。

冗長トポロジ

ここでは、冗長トポロジの例を示します。

5 台以上のサーバー ファーム

最適な冗長サーバー ファームのトポロジとは、インデックス サーバーを別に用意し、クラスタ構成になった 2 台以上のデータベース サーバー コンピュータと、2 台以上のクエリ サーバー コンピュータからなる、全部で 5 台以上のサーバー コンピュータによる構成です。

5 台のサーバー ファーム

このようなトポロジにすると、インデックス サーバー ロールを専用のアプリケーション サーバーにインストールできます。この設計では、インデックス処理を中間層に移すことができるので、クエリ サーバー コンピュータのパフォーマンスを最適化できます。

このトポロジには、手動フェールオーバーを提供する SQL Server のクラスタ構成が示されていることに注意してください。自動フェールオーバー用に SQL Server クラスタを構成する方法の詳細については、使用している SQL Server のバージョンに応じて、「SQL Server 2005 Failover Clustering White Paper (英語)」または「SQL Server 2008 フェールオーバー クラスタのインストール」を参照してください。

4 台のサーバー ファーム

冗長性を組み込む最小のサーバー ファームは、4 台のサーバーで構成されます。

  • サーバー 1 と 2 : 両方のコンピュータにクエリの役割をインストールします。

  • サーバー 3 と 4 : データベース サーバーをクラスタ化またはミラー化します。

4 台のサーバー ファーム

サーバー 4 台のファームを使用するときは、インデックス サーバー ロールを展開する場所を注意して決定する必要があります。クエリの役割をファーム内のインデックス サーバーともう 1 つのサーバーにインストールしても、冗長性は実現できません。これは、インデックスの役割をクエリの役割と同じサーバー コンピュータにインストールすると、インデックスの役割はコンテンツのインデックスを他のクエリ サーバーに伝達しなくなるためです。したがって、インデックス サーバー ロールをどちらかの Web サーバーにインストールした場合、両方の Web サーバー上でクエリの役割をホストできなくなります。インデックスの役割をデータベース サーバーにインストールすると、クエリの役割の冗長性を Web サーバー上で実現できます。ただし、データベース サーバーのパフォーマンスが低下します。特に、コンテンツがクロールされるときに大きな影響があります。

3 台のサーバー ファーム

展開するサーバーがさらに少ないときは、別の方法で冗長性を実現できます。3 台のサーバー ファームを使用するときは、Web サーバー ロールとデータベース サーバー ロールのどちらを冗長にするかを決定する必要があります。

3 台目のサーバーを Web サーバー層に追加すると、Web サーバー ロールの冗長性が実現されます。クエリの役割とインデックスの役割は、同じ Web サーバーにインストールすること (このセクションのオプション A を参照) も、異なる Web サーバーにインストールすること (このセクションのオプション B を参照) もできます。

冗長 Web サーバーを使用した 3 台のサーバー ファーム

このトポロジでは、クエリの役割を両方の Web サーバーに展開して冗長性を実現することはできません。これは、クエリ サーバーの役割をインデックス サーバーと同じサーバーにインストールすると、インデックス サーバーから他のクエリ サーバーにインデックスが伝達されなくなるためです。インデックスの役割は、データベース サーバーにインストールできます。このようにすると、クエリの役割を両方の Web サーバーに展開できます。ただし、データベース サーバーのパフォーマンスは低下します。

可用性は制限されますが、2 台のサーバーを Web サーバー ロールに割り当てることで、小規模なファームでの全体的なパフォーマンスが向上します。データの冗長性よりパフォーマンスの方が重要な場合は、このトポロジを使用します。

非冗長トポロジ

冗長ではないトポロジにも複数のサーバーが含まれる場合がありますが、各サーバーの役割は 1 台のサーバーにのみ存在するので冗長ではありません。たとえば、1 台のクエリ サーバー、1 台のインデックス サーバー、そして 1 台のデータベース サーバーで構成されるファームは、冗長ではありません。

サーバーの展開に余分な容量やパフォーマンスが必要ない場合、最初に考えるサーバー トポロジは 1 台または 2 台のサーバーです。使用目的が限られている場合は、単一の Search Server 2008 サーバーまたは Microsoft Search Server 2008 Express を展開でき、設計上、それは単一のアプリケーション サーバーに制限されます。

次に示す図表は、冗長ではないトポロジの例です。

シングル サーバー展開 2 台のサーバー ファーム

ベースライン サーバー ファーム トポロジを選択する

これまでに説明した各サーバー ファーム トポロジは、展開を設計するためのベースラインとなる初期状態を表しています。組織にとって最適な開始点は、冗長が必要なサーバーの役割によって異なります。

この記事の後半では、各サーバーの役割の冗長オプションについて説明します。この記事を最後まで読むと、組織に必要な冗長性を提供するベースライン トポロジを特定できるようになります。このトポロジを、容量とパフォーマンスを計画するときのベースラインとして使用します。

クエリ サーバーの冗長性を計画する

ここでは、以下の作業を行います。

  • 組織で Web 層に冗長性を組み込む必要があるかどうかを判断します。

  • クエリ サーバーで実装する負荷分散技術を計画します。

クエリ サーバーの役割は、複数のサーバーに展開できます。各サーバーに展開されるコードはまったく同じで、クエリ サーバーはデータを格納しません。つまり、クエリ サーバーの役割の各インスタンスは、まったく同じ状態を保ちます。いずれかのサーバー コンピュータが故障しても、保存されているデータは失われません。クエリ サーバーは、これらのサーバーの役割に対する要求を、利用できるサーバー コンピュータ間に、自動的に負荷分散します。

クエリの役割は、任意の数の Web サーバーに展開できます。ただし、制限が 1 つあります。クエリの役割をインデックスの役割もホストしているサーバーに展開する場合は、他のサーバー コンピュータにクエリの役割を展開することはできません。これは、インデックスの役割は、クエリの役割が同じサーバー上に存在することを認識するためです。したがって、インデックスの役割はインデックスを伝達しようとしません。

Search Server 2008 内でインデックス アプリケーション サーバー ロールを冗長にすることはできません。Search Server 2008 では、インデックスの役割は共有サービス プロバイダ (SSP) に関連付けられます。インデックスの役割は、SSP ごとに 1 つのインデックスを作成します。複数のインデックス サーバーを展開して処理能力を向上させることはできません。インデックス サーバーは 1 つの SSP と関連付けられ、Search Server 2008 では、使用できる SSP は 1 つだけです。

次の手順では、実装する負荷分散技術を計画します。Search Server 2008 は、2 種類の負荷分散をサポートします。

  • Windows Server 2003 オペレーティング システムに組み込まれているネットワーク負荷分散 (NLB) サービスなどのソフトウェア。NLB はクエリ サーバー上で動作し、TCP/IP を使用して要求をルーティングします。NLB および他のソフトウェア負荷分散ソリューションはクエリ サーバー上で動作するので、クエリ サーバーのシステム リソースを使用します。そのため、クエリの提供に使用できるリソースが減ります。ただし、システム リソースに対する影響は大きくなく、ソフトウェア ソリューションは最高で 32 台のクエリ サーバーを処理できます。

  • ルーター、スイッチ ボックスなどのハードウェア。負荷分散ハードウェアは、ネットワークを使用して、クエリ サーバー間のクエリ トラフィックをルーティングします。負荷分散ハードウェアは、ソフトウェアよりセットアップに費用がかかります。ただし、クエリ サーバーでのリソースの使用には影響を与えません。Search Server 2008 は、任意の負荷分散ハードウェアと組み合わせて使用できます。

推奨はできませんが、負荷分散にはもう 1 つの方法があります。それは、ドメイン ネーム システム (DNS) のラウンドロビン負荷分散です。ラウンドロビン DNS 負荷分散は、クエリ サーバーのリソースを大量に使用する可能性があり、負荷分散ソフトウェアまたはハードウェアほど処理速度が速くありません。Search Server 2008 と組み合わせて使用することはお勧めしません。また、ラウンドロビン DNS 負荷分散は、ユーザーをサーバーにルーティングするときにセッションの負荷を考慮しないため、サーバーが過負荷になる可能性があります。

記事「Windows Server 2003 でネットワーク負荷分散パラメータを構成する方法」(https://support.microsoft.com/kb/323437?amp;clcid=0x411) では、NLB の構成方法が説明されています。異なる負荷分散技術を実装する場合は、プロセスの計画および展開でこれを考慮してください。

データベース サーバーの冗長性を計画する

このセクションを読み、データベース サーバー ロールの冗長性がソリューションにとって必要かどうかを判断するうえで役立ててください。この後に続く計画関連のトピックでは、組織の環境にとって最も適切なデータベース冗長性技術を判断するうえで役に立つ情報を紹介します。詳細については、「データベースの記憶域と管理を計画および設計する」を参照してください。

データベース サーバー ロールは、ソリューションの可用性に対して他の役割より大きい影響を与えます。クエリ サーバーまたはインデックス サーバーの役割は、エラーが生じてもすぐに復元または再展開できます。一方、データベース サーバーで障害が発生した場合、ソリューションはデータベース サーバーの復元に依存します。データベース サーバーを再構築し、バックアップ メディアからデータを復元することも 1 つの方法です。この場合、SQL Server 2005 の構成方法によっては、最後のバックアップ ジョブ以降の新しいデータまたは変更されたデータが失われる可能性があります。さらに、データベース サーバー ロールを復元するまでの間、ソリューションは完全に利用できません。

サーバーの障害のリスクを評価する

ここでは、単一のクエリ サーバーまたはインデックス サーバーが故障した場合に予想される影響をまとめます。つまり、クエリ サーバーの役割を 1 つのサーバーだけに展開し、そのサーバーで障害が発生した場合、どのような結果になる可能性があるかということです。可能性のある結果を理解することは、ファームでのサーバーの割り当ての優先順位を決めるのに役に立ちます。次の表は、アプリケーション サーバー ロールと、それぞれが停止したときの影響をまとめたものです。

サーバーの役割 停止したときの影響

クエリ

ユーザーは、全文クエリを発行できません。サイトを閲覧し、サイトを介して公開されているコンテンツにアクセスすることはできます。ユーザーまたは顧客が検索を実行してコンテンツを発見できることにアプリケーションが依存している場合は、クエリ サーバーの役割を複数のサーバーに展開することを計画します。5 台のサーバー ファームでは、クエリの役割を 2 台の Web サーバー コンピュータに展開することで簡単に実現できます。

インデックス

インデックス サービスが回復して新しいインデックスまたは更新されたインデックスが生成されるまで、クエリ サーバーは既存のコンテンツ インデックスを引き続き使用します。したがって、インデックスの役割が利用できない間、検索結果には新しいコンテンツや変更されたコンテンツは含まれません。

データベース

ユーザーはファームにアクセスできません。ファーム内のページを表示しようとすると、エラー メッセージが発生します。ユーザーまたは顧客が検索を実行してコンテンツを発見できることにアプリケーションが依存している場合は、データベース サーバーをクラスタ構成にすることを計画します。

冗長性に関する一般的な推奨事項として、クエリ サーバーの役割の可用性要件が 99% 以上の場合は、少なくとも 2 台のサーバー コンピュータにクエリ サーバーの役割をインストールするように計画します。

IT チームがアプリケーション サーバー ロールを別のサーバーに展開するまで、または既存のサーバーにサービスを復元するまでの間、一時的な機能の喪失に耐えられる場合は、単一のアプリケーション サーバーに役割を展開することを検討します。

関連項目

概念

可用性の計画 (Search Server 2008)

その他のリソース

データベースの記憶域と管理を計画および設計する
Windows Server 2003 でネットワーク負荷分散パラメータを構成する方法
SQL Server 2005 Failover Clustering White Paper (英語)
SQL Server 2008 フェールオーバー クラスタのインストール