冗長性を計画する (Windows SharePoint Services)
この記事の内容 :
冗長性について
サーバーの冗長要件を定義する
限定されたサーバー展開を計画する
最低レベルのサーバー冗長性を計画する
ベースライン サーバー ファーム トポロジを選択する
Web サーバーの冗長性を計画する
検索サーバーの冗長性を計画する
データベース サーバーの冗長性を計画する
ベースライン トポロジを選択する
ここでは、Windows SharePoint Services 3.0 ファームに含まれる冗長サーバー ロールをスケール アウトするためのオプションについて説明します。この記事を読むと、組織の環境にとって適切な冗長性オプションを判断および記録できるようになります。
可用性の詳細については、可用性を計画する (Windows SharePoint Services)を参照してください。
冗長性について
冗長性という語は、可用性と同義に誤って解釈されることが少なくありません。これらの概念には関連性がありますが、まったく同じものではありません。冗長性とは、ファーム パフォーマンスを向上したり、追加ユーザーに適応させるためにスケール アウトを行ったり、可用性を向上させるなど、何らかの目的で負荷分散環境で複数のサーバーを使用することを意味します。
可用性とは、接続を受け入れ、ファームの 1 つ以上のサーバーが稼動しなくなっても通常通り動作するために設計された複数サーバー環境を意味します。したがって、可用性は冗長性を表すと同時に、フェールオーバー メカニズムやその他の考え得る特性をも表します。ただし、冗長性を持つシステムは、必ずしも高可用性を持つとは限りません。
ここでは、Windows SharePoint Services 3.0 ファームに冗長性サーバーを実装する方法について説明します。
サーバーの冗長要件を定義する
Windows SharePoint Services 3.0 は、容量、パフォーマンス、可用性のための拡張可能なサーバー ファームをサポートします。一般に、容量は、使用するサーバー コンピュータの台数を決定するときの最初の考慮事項です。パフォーマンスを分析した後は、パフォーマンスと容量を計画することも、サーバー ファーム内のサーバー コンピュータの台数と規模または容量を決定するうえで重要です。
このセクションを読むと、冗長サーバー (3 台以上のサーバー) を展開して、サーバー展開トポロジに拡張可能な容量を組み込む必要があるかどうかを決定できます。または、冗長サーバーのない限定されたサーバー展開を計画することが組織にとって適切であるかどうかを判断できます。
限定的なサーバー展開を計画する
サーバー展開に追加の容量とパフォーマンスを組み込む必要がない場合、サーバー トポロジの開始点は 1 台または 2 台のサーバーです。使用目的が限られている場合は、1 台のサーバーを展開すれば十分です。
.gif "単一サーバー")
限定的な使用を目的とする例を以下に示します。
評価目的での Windows SharePoint Services 3.0 のインストール
限られた目的 (単一の部門など) または少数のユーザーのために Windows SharePoint Services 3.0 を展開する。
通常、初期の Windows SharePoint Services 3.0 の展開では、少なくとも次の 2 台のサーバー コンピュータによる構成が推奨されています。
サーバー 1 : フロントエンド Web サーバーおよび検索サーバー コンピュータ
サーバー 2 : SQL Server 専用のコンピュータ
.gif "2 台のサーバー ファーム")
環境にサーバーの冗長性が必要ないと判断した場合、「パフォーマンスおよび容量を計画する (Windows SharePoint Services)」に進んで次の計画ステップを完了します。この計画手順を完了すると、組織のサーバー展開計画で推奨されるサーバーの合計台数が決まります。この記事の残りを読む必要はありません。
最低レベルのサーバー冗長性を計画する
冗長性ソリューションを展開するには、サーバー ファームを展開する必要があります。サーバー ファームを使用すると、予期しないダウンタイムや、オペレーティング システムの更新などのメンテナンス時のダウンタイムの影響を軽減します。
ベースラインとして使用できるサーバー トポロジには、いくつか種類があります。いずれのトポロジにも、ある程度のサーバー冗長性が組み込まれています。ここでは、サーバー ファームの概要を示します。
4 台のサーバー ファーム
冗長性を組み込む最小のサーバー ファームは、4 台のサーバーで構成されます。
サーバー 1 と 2 : Web サーバー。このどちらかの Web サーバーに検索サーバーがインストールされます。
サーバー 3 と 4 : クラスタ化またはミラー化データベース サーバー。
.gif "4 台のサーバー ファーム")
5 台のサーバー ファーム
最も一般的な冗長性サーバー ファーム トポロジは、中間層を導入した 5 台のサーバー コンピュータで構成されます。
サーバー 1 と 2 : Web サーバー。
サーバー 3 : 検索サーバー。
サーバー 4 と 5 : クラスタ化またはミラー化データベース サーバー
.gif "5 台のサーバー ファーム")
このトポロジでは、検索機能を専用のサーバー コンピュータに割り当てることにより、フロントエンド Web サーバー コンピュータのパフォーマンスを最適化します。
3 台のサーバー ファーム
さらに少ないサーバーを展開するもう 1 つの方法があります。3 台のサーバー ファームでは、Web サーバー ロールとデータベース サーバー ロールのどちらを冗長にするのかを選択する必要があります。
3 台目のサーバーを Web 層に加えると、Web サーバー ロールの冗長が実現されます。検索サーバー ロールはいずれかの Web サーバーにインストールできます。
このトポロジでは、可用性が制限されるものの、小規模ファーム全体のパフォーマンスが向上します。データの冗長性よりパフォーマンスの方が重要な場合は、このトポロジを使用します。
.gif "3 台のサーバー ファーム用フロントエンド サーバー")
3 台目のサーバーをデータベース層に加えると、重要データの可用性を確保できます。データの可用性が不可欠で、ユーザー アクセスの一時的な中断を許容できる場合は、この小規模トポロジを使用することを計画します。
.gif "3 台のサーバー ファーム用データベース")
ベースライン サーバー ファーム トポロジを選択する
これまでに説明した各サーバー ファーム トポロジは、展開を設計するためのベースラインとなる初期状態を表しています。組織にとって最適な開始点は、冗長が必要なサーバー ロールによって異なります。
この記事の後半では、各サーバー ロールの冗長オプションについて説明します。この記事を最後まで読むと、組織に必要な冗長性を提供するベースライン トポロジを特定できるようになります。このトポロジは、容量とパフォーマンスの計画を開始するときのベースラインとして使用します。
フロントエンド Web サーバーの冗長性を計画する
ここでは、以下の作業を行います。
組織で Web 層に冗長性を組み込む必要があるかどうかを判断します。
Web サーバーでどのような負荷分散技術を実装するのかを計画します。
ほとんどの組織では、Web 層の冗長性が必要になります。Web サーバー ロールを 1 台のサーバーで実行する 3 台のサーバー ファームが有効なシナリオがいくつかあります。
次の手順では、実装する負荷分散技術を計画します。Windows SharePoint Services 3.0 は、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 サーバー リソース上のリソースには影響を与えません。Windows SharePoint Services 3.0 は、任意の負荷分散ハードウェアと組み合わせて使用できます。
可用性を向上させるために、負荷分散のアフィニティを [なし] に設定することをお勧めします。カスタムのトポロジ要件がある場合は、別の関係性を構成することもできます。
推奨はできませんが、負荷分散にはもう 1 つの方法があります。それは、ドメイン ネーム システム (DNS) のラウンドロビン負荷分散です。ラウンドロビン DNS 負荷分散は、フロントエンド Web サーバーのリソースを大量に使用する可能性があり、負荷分散ソフトウェアまたはハードウェアよりも処理速度が下がります。Windows SharePoint Services 3.0 と組み合わせて使用することはお勧めしません。また、ラウンドロビン DNS 負荷分散は、ユーザーをサーバーにルーティングするときにセッションの負荷を考慮しないため、サーバーが過負荷になる可能性があります。
検索サーバーの冗長性を計画する
Windows SharePoint Services 3.0 には、検索というアプリケーション サーバー ロールが 1 つあります。Windows SharePoint Services 3.0 検索アプリケーション ロールには、検索コンポーネントとインデックス コンポーネントの両方が含まれます。これらのコンポーネントは分割できません。検索ロールは、Web サーバーまたは専用のアプリケーション サーバーにインストールできます。Windows SharePoint Services 3.0 をスタンドアロンのコンピュータに展開する場合を除いて、データベースと同じコンピュータに検索ロールをインストールすることはお勧めしません。
Windows SharePoint Services 3.0 の検索をホストするサーバーでエラーが発生した場合、検索は利用できません。検索機能を復元するために必要な時間の長さは、既存のコンテンツ インデックスを復元できるかどうか、またはコンテンツを再クロールして新しいインデックスを生成する必要があるかどうかによって異なります。
Windows SharePoint Services 3.0 は、容量上の理由で複数のサーバーに展開できます。ただし、それら複数のサーバーは冗長ではありません。このシナリオでは、各検索サーバーが異なるコンテンツ データベース セットをクロールするように構成されます。複数の検索サーバーを展開する第一の理由は、容量またはパフォーマンスのスケーラビリティを実現することなので、この後に続く計画関連の記事では、組織のサーバー展開で複数のサーバーを使用することが推奨されるかどうかを判断するうえで役に立つ情報を紹介します。詳細については、「パフォーマンスおよび容量を計画する (Windows SharePoint Services)」を参照してください。
データベース サーバーの冗長性を計画する
このセクションを読み、データベース サーバー ロールの冗長がソリューションにとって必要かどうかを判断するうえで役立ててください。この後に続く計画関連のトピックでは、組織の環境にとって最も適切なデータベース冗長性技術を判断するうえで役に立つ情報を紹介します。
データベース サーバー ロールは、ソリューションの可用性に対して他の役割より大きい影響を与えます。Web サーバーまたはアプリケーション サーバー ロールは、エラーが生じてもすぐに復元または再展開できます。一方、データベース サーバーで障害が発生した場合、ソリューションはデータベース サーバーの復元に依存します。データベース サーバーを再構築し、バックアップ メディアからデータを復元することも 1 つの方法です。この場合、SQL Server 2005 の構成方法によっては、最後のバックアップ ジョブ以降の新しいデータまたは変更されたデータが失われる可能性があります。さらに、データベース サーバー ロールを復元するまでの間、ソリューションは完全に利用できません。
ベースライン トポロジを選択する
個々のサーバー ロールの冗長要件を特定したら、ベースライン サーバーのトポロジを確認し、環境にとって最も適切なトポロジを選択します。
このドキュメントをダウンロードする
このトピックは、簡単に読んだり印刷したりできるように、次のダウンロード可能なドキュメントに収められています。
入手可能なドキュメントの詳細な一覧については、「Windows SharePoint Services 3.0 テクニカル ライブラリ」を参照してください。