冗長性を計画する (Office SharePoint Server)

この記事の内容 :

• 冗長性について

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

• 限定的なサーバー展開を計画する

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

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

• Web サーバーの冗長性を計画する

• アプリケーション サーバーの冗長性を計画する

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

• アプリケーション サーバーの障害のリスクを評価する

• ベースライン トポロジを選択する

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

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

冗長性について

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

可用性は、特に、ファーム内の 1 つ以上のサーバーが使用できないときでも通常どおりに接続および運用できるように設計された、複数のサーバーから成る環境を表現するための概念です。したがって、可用性は冗長性の概念を含んでいるほか、フェールオーバー メカニズムの概念を含んでおり、さらにその他のいくつかの機能を持つことがあります。冗長システムであっても、可用性が高いとは限りません。

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

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

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

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

限定的なサーバー展開を計画する

サーバー展開に容量やパフォーマンスの拡張性を組み込む必要がない場合、サーバー トポロジの開始点は 1 台または 2 台のサーバーです。使用目的が限られている場合は、1 台のサーバーを展開すれば十分です。

限定的な使用を目的とする例を以下に示します。

• 評価のために Office SharePoint Server 2007 をインストールする。

• Windows SharePoint Services 3.0 のみを展開する。

• Office SharePoint Server 2007 の機能のサブセットを展開する。

• 限られた目的 (単一の部門など) または少数のユーザーのために Office SharePoint Server 2007 を展開する。

通常、初期の Office SharePoint Server 2007 の展開では、少なくとも次の 2 台のサーバー コンピュータによる構成が推奨されています。

• サーバー 1 : フロントエンド Web サーバーおよびアプリケーション サーバーのコンピュータ

• サーバー 2 : SQL Server 専用のコンピュータ

  

環境にサーバー冗長性が必要ないと判断した場合は、「パフォーマンスと容量を計画する (Office SharePoint Server)」記事に進んで、次の計画手順を完了します。この計画手順を完了すると、サーバー展開計画でのサーバーの推奨合計台数が決まります。この記事の残りを読む必要はありません。

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

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

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

3 台のサーバー ファーム

冗長性を実現しながら、展開するサーバー数を少なくするために、もう 1 つの方法があります。3 台のサーバー ファームでは、Web サーバー ロールとデータベース サーバー ロールのどちらを冗長にするかを選択する必要があります。

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

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

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

4 台のサーバー ファーム

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

• サーバー 1 と 2 : 両方のコンピュータに Web サーバーとクエリの役割をインストール。Excel Calculation Services などの他のアプリケーション サーバー ロールを、一方または両方のサーバーにインストールできます。

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

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

Excel Calculation Services などの他のアプリケーション サーバー ロールを、パフォーマンスと可用性の要件に応じて、一方または両方の Web サーバーにインストールできます。前の図では、追加のアプリケーション ロールが、オプション A とオプション B の両方で 1 台のサーバーにのみ展開されています。オプション A のパフォーマンスは、インデックスの役割とクエリの役割の両方をホストしていない Web サーバーが他のアプリケーション ロールをホストする場合に最適化されます。オプション B のトポロジは、ユーザーの要求とクエリのために最適化されます。他の Web サーバーのインデックス作成ジョブをオフピーク時にスケジュールするようにパフォーマンスを管理すれば、業務のピーク時の他のアプリケーション サーバー ロールのパフォーマンスがさらに向上します。

5 台のサーバー ファーム

最も一般的な冗長サーバー ファーム トポロジは、中間層を導入した 5 台のサーバー コンピュータで構成されます。

このトポロジを使用すると、すべてのアプリケーション サーバー ロールを専用のアプリケーション サーバーにインストールできます。この設計では、1 つ以上のアプリケーション サーバー ロールを中間層に移すことができるので、フロントエンド Web サーバー コンピュータのパフォーマンスを最適化できます。

このトポロジで最も重要な計画に関する決定事項は、アプリケーション サーバー ロールをインストールする場所です。インデックス サーバー ロールは、専用のアプリケーション サーバーに残す必要があります。ただし、追加のアプリケーション サーバー ロールをインストールする場所の決定は、サーバー ファームを最適化する対象が容量かパフォーマンスかに依存します。アプリケーション サーバー ロールの冗長性が優先される場合は、冗長性用に設計されたアプリケーション サーバー ロール (Excel Calculation Services、検索クエリ、および Microsoft Office Project Server 2007) を、2 台の Web サーバーにインストールできます。パフォーマンスを最適化するには、最初に Excel Services の役割をアプリケーション サーバーに移動することを検討し、次にクエリの役割について検討します。

クエリの役割を Web サーバーに展開するように構成することで、一般的に、この役割の冗長性を実現でき、さらにサーバー ファーム全体のパフォーマンスも最適化できます。後の「アプリケーション サーバーの可用性を計画する」を読んだ後で行う計画の選択により、どちらのオプションが環境にとって最適かが決まります。

0

最低限の数のサーバーで冗長性を最大にするには、中間層にアプリケーション サーバーを追加して展開し、冗長性のために設計されているアプリケーション サーバー ロールの負荷を分散させます。このサーバー ファーム トポロジは、6 台のサーバーで構成されます。冗長性を実現するため、クエリの役割はフロントエンド Web サーバーにインストールします。

Excel Calculation Services アプリケーション サーバー ロールまたは Office Project Server 2007 アプリケーションの役割をファームに展開することを計画し、これらのサービスの冗長性が優先される場合は、このトポロジが推奨初期状態です。このトポロジでは、これらのサーバー ロールにユーザーが直接接続することがなくなり、これより小さいファームと比較してファーム全体のパフォーマンスが最適化されます。

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

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

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

フロントエンド Web サーバーの冗長性を計画する

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

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

• Web サーバーでどのような負荷分散技術を実装するのかを計画します。

ほとんどの組織では、Web 層の冗長性が必要になります。Web サーバー ロールを 1 台のサーバーで実行する 3 台のサーバー ファームが有効なシナリオがいくつかあります。

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

• Microsoft Windows Server 2003 オペレーティング システムに組み込まれているネットワーク負荷分散 (NLB) サービスなどのソフトウェア。NLB はフロントエンド Web サーバー上で動作し、TCP/IP を使用して要求をルーティングします。NLB (および他のソフトウェア負荷分散ソリューション) は、フロントエンドの Web サーバーで動作して、フロントエンド Web システムのリソースを使用するので、Web ページの提供に使用できるリソースが減少します。一方、システム リソースに対する影響は大きくなく、ソフトウェア ソリューションは最高で 32 台のフロントエンド Web サーバーを処理できます。Windows Server 2003 での NLB サービスの詳細については、「ネットワーク負荷分散クラスタ」(https://technet.microsoft.com/ja-jp/library/cc759510.aspx) を参照してください。Windows Server 2008 での NLB サービスの詳細については、「Network Load Balancing (英語) (https://technet.microsoft.com/ja-jp/library/cc732855.aspx) を参照してください。

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

  可用性を向上させるために、負荷分散のアフィニティを [なし] に設定することをお勧めします。カスタムのトポロジ要件がある場合は、別の関係性を構成することもできます。

推奨はできませんが、負荷分散の第 3 の方法として、ドメイン ネーム システム (DNS) によるラウンドロビン負荷分散があります。ラウンドロビン DNS による負荷分散は、フロントエンド Web サーバーのリソースを大量に使用する場合があり、負荷分散用のソフトウェアやハードウェアよりも処理が遅いので、Office SharePoint Server 2007 での使用はお勧めできません。また、ラウンドロビン DNS 負荷分散では、ユーザーをサーバーにルーティングするときにセッションの負荷を考慮しないので、サーバーが過負荷になる可能性があります。

アプリケーション サーバーの冗長性を計画する

どのベースライン サーバー トポロジを選択するかは、アプリケーション サーバー ロールの冗長性に対する要件に依存します。この節では、アプリケーション サーバー ロールの冗長性オプションについて説明します。

Office SharePoint Server 2007 に対するアプリケーション サーバー ロールは、2 つのカテゴリに分かれます。

• 冗長にできるロール

• 冗長にできないロール

冗長にできるロール

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

以下のアプリケーション サーバー ロールは、冗長に展開できます。

• クエリ。クエリの役割は、任意の数のアプリケーション サーバー コンピュータに展開できます。または、複数の Web サーバーに展開することもできます。ただし、制限が 1 つあります。クエリの役割を、インデックスの役割もホストしているサーバーに展開する場合は、他のサーバー コンピュータにクエリの役割を展開しないようにしてください。これは、インデックスの役割はクエリの役割が同じサーバー上に存在することを認識すると、インデックスを伝達しようとしないためです。シナリオによっては、専用のアプリケーション サーバー用に中間層を導入した場合であっても、クエリの役割を複数の Web サーバーに展開することで、サーバー ファームのスループットを最適化できます。たとえば、サーバー ファームが受け取るコンテンツ要求の 50% 以上が静的コンテンツに対する要求である場合は、クエリの役割を Web サーバーでホストすることにより、パフォーマンスを最適化できる可能性があります。これは、クエリの役割は提供するコンテンツをキャッシュしているので、以降の要求ではコンテンツが簡単に利用できるためです。クエリの役割は、この意味では固有です。

• Excel Calculation Services。Excel Calculation Services の役割は、コンテンツ データベースに格納されている Excel ブックの Excel 計算を実行することです。このアプリケーション サーバー ロールが他の役割と異なるのは、ユーザー セッションの期間を通じてセッション状態の情報を保管していることです。ユーザーがブックを開くと、Web サーバー ロールは、ブックが閉じられてユーザーがセッションを終了するまで、ユーザーの要求を継続して同じ Excel Calculation Services アプリケーション サーバーにルーティングします。Excel Calculation Services の役割はリソースを多く使用する場合があります。シナリオによっては、この役割をすべての Web サーバーに展開することで、ファームのパフォーマンスを最適化できます。

• Office Project Server 2007。Office Project Server 2007 は Office SharePoint Server 2007 には含まれていませんが、Windows SharePoint Services 3.0 プラットフォームに組み込まれており、Windows SharePoint Services 3.0 ファームまたは Office SharePoint Server 2007 ファームに展開できます。Office Project Server 2007 アプリケーションの役割は、Office Project Server 2007 サービスに対する要求および Microsoft Office Project Web Access サーバーに対するデータを処理します。

冗長にできないロール

冗長にできないアプリケーション サーバー ロールには、インデックスと Windows SharePoint Services 3.0 検索があります。これらのアプリケーション サーバー ロールは複数のサーバーに展開できますが、複数のサーバーは冗長ではありません。これらのサーバー ロールは、コンテンツをクロールし、コンテンツのインデックスを生成するために構成されます。これらの役割を複数のサーバーに展開すると、サーバーごとに異なるコンテンツをクロールします。

• Windows SharePoint Services 3.0   Windows SharePoint Services 3.0 検索のアプリケーションの役割は、Office SharePoint Server 2007 のクエリとインデックスを使用していない場合のオプションです。Windows SharePoint Services 3.0 検索のアプリケーションの役割には、検索コンポーネントとインデックス コンポーネントの両方が含まれます。これらのコンポーネントは分割できません。さらに、ヘルプの全文検索を提供するには、Windows SharePoint Services 3.0 の検索が必要です。したがって、この機能を実現するには、Office SharePoint Server 2007 の検索が展開されている場合であっても、Office SharePoint Server 2007 ファームにこのアプリケーション サーバー ロールを展開することを検討してかまいません。

• Office SharePoint Server 2007   Office SharePoint Server 2007 では、インデックス ロールは共有サービス プロバイダ (SSP) と関連付けられています。インデックス ロールは、SSP ごとに 1 つのインデックスを作成します。1 つのインデックス サーバーを、複数の SSP と関連付けることができます。ただし、複数の SSP 間でインデックスを結合することはできません。複数のインデックス サーバーを展開することで能力を向上させることができます。この場合、各インデックス サーバーは、異なる SSP と関連付けられます。Windows SharePoint Services 3.0 検索ロールとは異なり、Office SharePoint Server 2007 インデックス ロールによって生成されるコンテンツ インデックスは、ファーム内でクエリ ロールをホストしているすべてのサーバーに継続して伝達されます。したがって、Office SharePoint Server 2007 インデックス サーバー ロールの出力 (つまりインデックス) は、クエリ ロールが複数のサーバー コンピュータに展開されている場合には、冗長性を備えていると考えられます。

Office SharePoint Server 2007 ファームを展開する場合は、Office SharePoint Server 2007 のクエリ サーバーとインデックス サーバー ロールを使用することをお勧めします。これにより、クエリ コンポーネントを拡張でき、コンテンツ インデックスの冗長性を実現できます。複数の Office SharePoint Server 2007 インデックス サーバーまたは Windows SharePoint Services 3.0 検索サーバーを展開する最大の理由は、容量またはパフォーマンスに合わせて拡張するためなので、この後の計画に関する記事を参考にして、実際の展開に複数のサーバーが推奨されるかどうかを判断してください。

次の表は、冗長性を持たせて展開できるアプリケーション サーバー ロールと、複数のサーバーに展開できるが冗長性はないアプリケーション サーバー ロールを示しています。

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

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

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

アプリケーション サーバーの障害のリスクを評価する

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

冗長性に関する一般的な推奨事項は、次の場合には、少なくとも 2 台のアプリケーション サーバー コンピュータにアプリケーション サーバー ロールをインストールすることを計画する、というものです。

• ソリューションが、主としてアプリケーション サーバーによって提供される機能に基づいている。

• サーバー ロールによって提供される機能に対する可用性要件が、99% 以上である。

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

ベースライン トポロジを選択する

個々のサーバー ロールの冗長要件を特定したら、ベースライン サーバーのトポロジを確認し、環境にとって最も適切なトポロジを選択します。

このブックをダウンロードする

このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なブックに収められています。

• Office SharePoint Server 2007 の計画とアーキテクチャ、パート 2

• Windows SharePoint Services のエクストラネット環境を計画する

入手できるすべてのブックの一覧については、「Office SharePoint Server 2007 のダウンロード可能なブック」を参照してください。