SharePoint Server 2010 の容量計画

 

適用先: SharePoint Server 2010

トピックの最終更新日: 2016-11-30

この記事では、Microsoft SharePoint Server 2010 ファームの容量を計画する方法について説明します。容量の計画と管理について正しく理解すると、その知識をシステムのサイジングに適用できます。サイジングとは、適切なデータ アーキテクチャ、論理トポロジと物理トポロジ、およびソリューション プラットフォームのハードウェアを選択し、構成することを説明する用語です。容量の管理と使用には、最も適切なハードウェアと構成オプションを決定する方法に影響する広範な検討事項があります。

この記事を読む前に、「SharePoint Server 2010 での容量管理と規模設定の概要」を読む必要があります。

この記事では、使用する環境に対して効果的な容量管理を実施する上で実行する必要のある手順について説明します。各手順では、実行を成功するための特定の情報が要求されます。また、各手順には、その後の手順で使用する一連の成果物が生成されます。各手順において、この要件と成果物を表に示します。

この記事の内容

• 手順 1. モデル作成

• 手順 2. 設計

• 手順 3. パイロット、テスト、および最適化

• 手順 4. 展開

• 手順 5: 監視と維持

手順 1. モデル作成

SharePoint Server 2010 ベースの環境のモデルを作成するには、既存のソリューションを分析し、セットアップする予定の展開で予想される要求と目標を見積もることから始めます。まず、ユーザー ベース、データ要件、遅延とスループットの目標に関する情報を収集し、展開する SharePoint Server 機能を文書化します。このセクションを使用して、収集する必要のあるデータ、そのデータを収集する方法、以降の手順でそのデータをどのように使用できるかについて理解します。

予想される負荷とデータセットを把握する

SharePoint Server 2010 実装の適切なサイジングには、ソリューションで処理することが予想される要求特性の調査と理解が必要です。要求を理解するには、負荷特性 (ユーザー数、使用頻度の最も多い操作など) とデータセット特性 (コンテンツのサイズ、コンテンツの配布など) を明確に示すことができる必要があります。

このセクションは、収集する必要のあるいくつかの特定の測定基準とパラメーター、およびそれらの収集メカニズムを理解するのに役立つ可能性があります。

負荷

負荷は、システムが持続するために必要な要求、ユーザー ベース、および使用特性を表します。次の表に、負荷の決定に役立ついくつかの主な測定基準を示します。この表を使用して、これらの測定基準を収集し、記録できます。

負荷特性	値
1 日の平均 RPS
ピーク時の平均 RPS
1 日あたりの一意のユーザーの合計数
1 日の平均同時ユーザー数
ピーク時のピーク同時ユーザー数
1 日あたりの要求の合計数
予想される負荷の分散	1 日あたりの要求数
Web ブラウザー - 検索クロール
Web ブラウザー - 一般的なグループ作業のやりとり
Web ブラウザー - 社会的なやり取り
Web ブラウザー - 一般的なやりとり
Web ブラウザー - Office Web Apps
Office クライアント
OneNote クライアント
SharePoint Workspace
Outlook RSS 同期
Outlook Social Connector
その他のやり取り (カスタム アプリケーション/Web サービス)

• 同時ユーザー数 – サーバー ファームで実行される操作の同時実行性を、特定の期間に要求を生成する重複しないユーザーの数として測定する最も一般的な指標です。主な測定基準は、1 日の平均同時ユーザー数と、ピーク負荷時の同時ユーザー数です。

• 1 秒あたりの要求数 (RPS) – RPS は、サーバー ファーム上の要求を説明するために一般的に使用される指標であり、1 秒あたりにファームで処理される要求数で表現されます。ただし、要求の種類やサイズは区別されません。すべての組織のユーザー ベースはシステム負荷を生成しますが、その割合は組織固有の使用特性に依存します。この用語の詳細については、「SharePoint Server 2010 での容量管理と規模設定の概要」の「Glossary」を参照してください。

• 1 日の合計要求数 – 1 日の合計要求数は、システムで処理する必要のある負荷全体を表す適切な指標です。これは、認証ハンドシェイク要求 (HTTP ステータス 401) を除くすべての要求数を 24 時間にわたって測定する最も一般的な指標です。

• 1 日の合計ユーザー数 - 合計ユーザー数は、システムで処理する必要のある負荷全体を表すもう 1 つの主な指標です。この測定値は、24 時間における実際の一意のユーザー数であり、組織の合計従業員数ではありません。

  注意

  1 日の合計ユーザー数は、ファームの負荷の拡大の可能性を示すことがあります。たとえば、潜在的なユーザー (従業員) 数が 10 万で、1 日のユーザー数が 15,000 の場合、時間の経過と共にユーザーの導入が進むにつれて負荷が大幅に増加する可能性があることが示されます。

• 負荷の分散 – ファームとやりとりを行うクライアント アプリケーションに基づいて要求の分散を把握しておくと、SharePoint Server 2010 への移行後に予想される傾向と負荷の変化を容易に予測できます。ユーザーが、Office 2010 など、最新のクライアント バージョンに移行し、新しい機能の使用を始めると、新しい負荷パターン、RPS、および合計要求数は増加することが予想されます。クライアントごとに、1 日の特定の期間におけるそのクライアントを使用する重複しないユーザーの数、およびクライアントまたは機能によってサーバーで生成される要求の合計数を示すことができます。

  たとえば、以下の図は、標準的な社会的ソリューションを提供する Microsoft の実際の内部環境のスナップショットを示しています。この例では、負荷のほとんどが検索クローラーおよびエンド ユーザーの標準的な Web 閲覧によって生成されていることがわかります。また、新しい Outlook Social Connector 機能によって大量の負荷 (要求の 6.2 パーセント) が発生していることも確認できます。

  

運用負荷の見積もり

ファームで持続可能にする必要のあるスループットを見積もるには、まず、ファームで使用されるトランザクションの組合せを見積もります。システムが提供するトランザクションのうち最もよく使用されるトランザクションを分析し、それらのトランザクションの使用頻度と使用ユーザー数を把握することに重点的に取り組みます。これにより、以後の運用前テストで、ファームでこのような負荷を持続できるかどうかを検証できます。

次の図は、負荷とシステムの負荷との関係を示しています。

予想される負荷を見積もるには、次の情報を収集します。

• ユーザーのやりとりを特定します。たとえば、Web ページの標準的な閲覧、ファイルのダウンロードとアップロード、ブラウザーでの Office Web Application の表示と編集、共同編集のやりとり、SharePoint Workspace サイトの同期、Outlook Social Connections、RSS 同期 (Outlook または他のビューアー内)、PowerPoint ブロードキャスト、OneNote 共有ノートブック、Excel Services 共有ブック、Access Services 共有アプリケーションがあります。詳細については、記事「SharePoint Server 2010 での容量管理と規模設定の概要」の「Services and Features」を参照してください。展開固有のやりとりとなる可能性のあるやりとりを特定することに重点的に取り組んで、予想されるその負荷の影響を把握します。たとえば、InfoPath Forms、Excel Service Calculations、および同様の専用ソリューションの多用が考えられます。

• 検索の増分クロール、毎日のバックアップ、プロファイル同期のタイマー ジョブ、Web 分析処理、ログ記録のタイマー ジョブなど、システム操作を特定します。

• 各機能を利用することが予想される 1 日あたりのユーザーの合計数を見積もり、1 秒あたりの同時ユーザー数と高レベルの要求数を推定します。ただし、いくつかの前提条件があります。たとえば、現在の同時実行数や、機能によって異なる、1 同時ユーザーあたりの RPS の要因です。したがって、前述の負荷の表を使用して独自の推定を行う必要があります。平均スループットよりも、ピーク時間に焦点を当てることが重要です。ピーク動作に応じた計画を作成することで、SharePoint Server 2010 ベース ソリューションの適切なサイジングを行うことができます。

既存の Office SharePoint Server 2007 ソリューションがある場合、IIS ログ ファイルを調査するか、他の Web 監視ツールを確認できます。既存のソリューションからいくつかの予想される動作をより深く理解する必要があります。または、以下のセクションの手順を参照して詳細を確認してください。既存のソリューションからの移行を行わない場合は、大まかな推定値を使用して表に記入する必要があります。後の手順で、この仮定を検証し、システムを調整する必要があります。

SharePoint Server 2010 IIS ログの分析

アクティブなユーザー数、アクティブなユーザーがシステムを使用する頻度、受信される要求の種類、要求の送信元のクライアントの種類など、既存の SharePoint Server 2010 展開に関する主な測定基準を検出するには、データを ULS および IIS ログから抽出する必要があります。このデータを取得する最も簡単な方法の 1 つは、Microsoft から無償でダウンロードできる強力なツールのログ パーサーを使用することです。ログ パーサーでは、すべての IIS 形式を含め、多くのテキストおよびバイナリ形式の読み込みと書き込みができます。

ログ パーサーを使用して SharePoint Server 2010 の使用状況を分析する方法については、「Analyzing Microsoft SharePoint Products and Technologies Usage (英語)」(https://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e\&displaylang=en) を参照してください。

ログ パーサー 2.2 は、https://www.microsoft.com/downloads/details.aspx?familyid=890cd06b-abf8-4c25-91b2-f8d975cf8c07&displaylang=ja でダウンロードできます。

データセット

データセットは、システムに格納されているコンテンツの量と、そのコンテンツをデータ ストアにどのように分散できるかを示します。次の表に、データセットの決定に役立ついくつかの主な測定基準を示します。この表を使用して、これらの測定基準を収集し、記録できます。

オブジェクト	値
DB サイズ (GB)
コンテンツ DB の数
サイト コレクションの数
Web アプリケーションの数
サイトの数
検索インデックスのサイズ (サイト数)
ドキュメントの数
リストの数
サイトの平均サイズ
最大のサイト サイズ
ユーザー プロファイルの数

• コンテンツ サイズ – SharePoint Server 2010 システムに格納することが予想されるコンテンツのサイズを把握することは、システム ストレージの計画と設計を行う上で重要です。また、このコンテンツをクロールしてインデックスを作成する検索ソリューションを適切にサイジングする上でも重要になります。コンテンツ サイズは合計ディスク容量に示されます。コンテンツを既存の展開から移行する場合、移動する合計サイズは簡単に特定できます。ただし、計画時に、予測される傾向に基づいて十分な空き容量を確保し、今後の拡大に備える必要があります。

• ドキュメントの合計数 – データ コーパスのサイズを除いて、アイテムの全体数を追跡することが重要です。100 GB のデータが、各 2 GB の 50 個のファイルで構成されている場合と、各 1 KB の 100,000 個のファイルで構成されている場合では、システムの反応が異なります。大規模展開では、1 つのアイテム、ドキュメント、またはドキュメント領域にかかる負荷が低いと、パフォーマンスは向上します。多くのサイトおよびサイト コレクションに分散する複数の小さいファイルなど、広範囲に分散するコンテンツは、非常に大きいファイルが含まれる 1 つの大きいドキュメント ライブラリよりも提供が容易になります。

• 最大サイト コレクション サイズ – SharePoint Server 2010 に格納するコンテンツの最大単位を特定することが重要です。ただし、通常、そのコンテンツ単位の分割を妨げるものは、組織のニーズです。すべてのサイト コレクションの平均サイズとサイト コレクションの推定合計数は、必要なデータ アーキテクチャの特定に役立つもう 1 つの指標です。

• サービス アプリケーションのデータ特性 – コンテンツ ストアのストレージのニーズを分析することに加えて、次のような他の SharePoint Server 2010 ストアのサイズを分析して見積もる必要があります。

• 検索インデックスの合計サイズ

• プロファイル ストア内のユーザー数に基づいた、プロファイル データベースの合計サイズ

• タグ、仕事仲間、および活動の推定数に基づいた、ソーシャル データベースの合計サイズ

• メタデータ ストアのサイズ

• 利用状況データベースのサイズ

• Web Analytics データベースのサイズ

データベース サイズを見積もる方法については、「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」を参照してください。

ファームのパフォーマンスと信頼性の目標の設定

「手順 1. モデル作成」の成果物の 1 つは、組織のニーズを最適に満たす、パフォーマンスと信頼性の目標について十分理解することです。適切に設計された SharePoint Server ソリューションでは、"フォー ナイン" (99.99%) のアップタイムと 1 秒未満のサーバー応答を達成できます。

ファームのパフォーマンスと信頼性を示すために使用する指標として、次の項目を使用できます。

• サーバーの可用性 – 通常、システムの総アップタイムとの割合によって示されます。予期しないあらゆるダウンタイムを追跡し、全体の可用性を、設定した組織の目標と比較する必要があります。通常、目標は 9 の数字を使って示されます (99%、99.9%、99.99% など)。

• サーバー応答 – ファームが要求を処理するためにかかる時間は、ファームの正常性を追跡する指標として優れています。この指標は、通常、サーバー側の遅延と呼ばれます。また、一般的に、1 日に処理される要求の平均または中央 (50 パーセンタイル) の遅延が使用されます。目標は、通常、1 秒未満または数秒で示されます。組織が SharePoint Server 2010 からページを 2 秒未満で提供することを目標とする場合、サーバー側の目標は 1 秒未満とする必要があります。これにより、ページがネットワーク経由でクライアントに到達するまでの時間と、ページがブラウザーでレンダリングされる時間が確保されます。また、通常、長いサーバー応答時間は、ファームが正常でないことを示します。これは、通常、スループットに影響するため、ほとんどの要求に対してサーバーでの処理時間が 1 秒を超える場合、RPS をほとんど維持できません。

• サーバーでスパイクがよく発生する状態 – すべての要求のうち最も遅い 5% の要求の動作は、サーバー側の遅延を示す、追跡する価値のあるもう 1 つの優れた指標です。通常、遅い要求は、高負荷の状態で要求がシステムにヒットしたときに発生します。また、遅い要求がさらによく発生する状況として、ユーザーがシステムを操作している間に発生頻度の低いアクティビティによって要求が影響された場合があります。ただし、正常なシステムとは、最も遅い要求も制御できるシステムです。ここでの目標は、「サーバ応答」と似ていますが、不安定なサーバーで 1 秒未満の応答を達成するには、多くの予備リソースを備えたシステムを構築し、負荷のスパイクを処理する必要があります。

• システム リソースの使用率 – システムの正常性を追跡するために使用するその他の一般的な指標は、ファーム トポロジ内の各サーバーの正常性を示すシステム カウンターのコレクションです。追跡するために最もよく使用する指標は、CPU 使用率と使用可能なメモリです。ただし、正常でないシステムを特定するのに役立つ可能性のあるその他のカウンターもいくつかあります。詳細については、「手順 5: 維持」を参照してください。

手順 2. 設計

配布する必要のあるソリューションに関するいくつかの事実および推定情報の収集が終了しました。次の手順に進み、予想される要求を持続できることが予測される、提案されるアーキテクチャを設計します。

この手順を終了すると、物理トポロジの設計と論理トポロジのレイアウトが得られます。したがって、必要な発注処理に進めます。

配置するハードウェアの仕様とマシンの数は緊密に関連します。特定の負荷を処理するには、いくつかのソリューションを選択して展開できます。一般的には、小数の強力なマシンを使用する (スケール アップ) か、多数の小型マシンを使用します (スケール アウト)。容量、冗長性、能力、費用、場所、その他の検討事項に関して、各ソリューションに利点と欠点があります。

この手順では、まず、アーキテクチャとトポロジを決定することをお勧めします。さまざまなファームと、各ファーム内のさまざまなサービスの配置をどのように計画するかを定義した後、設計内の個々のサーバーごとにハードウェア仕様を選択します。また、この処理を行う方法として、展開が予想されるハードウェア仕様を特定した後 (多くの組織が特定の企業標準に制約されます) に、アーキテクチャとトポロジを定義することもできます。

次の表を使用して設計パラメーターを記録します。含まれているデータはサンプル データです。このデータを使用してファームのサイズを設定しないでください。ユーザー独自のデータに対して、この表をどのように使用するかを示すことを目的とします。

役割	種類 (標準または仮想)	マシン数	プロセッサ	RAM	IOPS ニーズ	ディスク サイズ	データ ドライブ
Web サーバー	仮想	4	4 コア	8	指定しない	400 GB	指定しない
コンテンツ データベース サーバー	標準	1 クラスター	4 クアッド コア、2.33 GHz	48	2k	400 GB	20 ディスク、300GB @ 15K RPM
アプリケーション サーバー	仮想	4	4 コア	16	指定しない	400 GB	指定しない
検索クロール ターゲット Web サーバー	仮想	1	4 コア	8	指定しない	400 GB	指定しない
検索クエリ サーバー	標準	2	2 クアッド コア、2.33 GHz	32	指定しない	400 GB	500 GB
検索クローラー サーバー	標準	2	2 クアッド コア、2.33 GHz	16	400	400 GB	指定しない
検索クロール データベース サーバー	標準	1 クラスター	4 クアッド コア、2.33 GHz	48	4k (読み取りに応じて調整)	100 GB	16 ディスク、150GB、@ 15K RPM
検索プロパティ ストア データベース + 管理データベース サーバー	標準	1 クラスター	4 クアッド コア、2.33 GHz	48	2k (書き込みに応じて調整)	100 GB	16 ディスク、150GB、@ 15K RPM

開始点のアーキテクチャを決定する

このセクションでは、開始点のアーキテクチャを選択する方法について説明します。

SharePoint Server 2010 を展開する場合、さまざまなトポロジから選択してソリューションを実装できます。SharePoint Server ファームには、単一のサーバーを展開するか、多数のサーバーをスケール アウトできます。スケール アウトされたファームには、クラスター化またはミラー化されたデータベース サーバーと、さまざまなサービス用の離散したアプリケーション サーバーが含まれます。後で、各役割の要件、および容量、可用性、冗長性のニーズに基づいて、ハードウェア構成を選択します。

まず、基準となるさまざまなアーキテクチャをレビューしてファームの構造を見つけ出し、ソリューションを複数のファームに分割する必要があるか、またはいくつかのサービス (検索など) を専用ファームに統合する必要があるかどうかを決定します。詳細については、「SharePoint Server 2010 での容量管理と規模設定の概要」の、基準となるアーキテクチャに関するセクションを参照してください。

SharePoint Server 2010 の技術的ケース スタディ

SharePoint Server 2010 の容量管理ガイダンスには、既存の運用環境の技術的なケース スタディが多く含まれます。これらのケース スタディでは、SharePoint Server ベースの既存の運用環境が詳細に説明されています。その他の技術的なケース スタディも少しずつ公開される予定です。これらのケース スタディは、特定の目的に応じて SharePoint Server ベースの環境をどのように設計するかについての基準として使用できます。

SharePoint Server ソリューションのアーキテクチャを設計するときに、これらのケース スタディを基準として使用できます。特に、これらの展開に固有の主な差別化要因の説明が、設計しているソリューションの要求と目標に似ていることを発見した場合、そのケース スタディを基準として使用できます。

これらのドキュメントでは、示された各ケース スタディに対して以下の情報が示されます。

• 仕様。ハードウェア、ファーム トポロジ、構成など

• 負荷。ユーザー ベースおよび使用特性を含む

• データセット。コンテンツ サイズ、コンテンツ特性、およびコンテンツの配布を含む

• 正常性とパフォーマンス。ファームの信頼性とパフォーマンス特性を示す、一連の記録された指標を含む

詳細については、「パフォーマンスと容量に関する技術的なケース スタディ 」ページ (https://technet.microsoft.com/ja-jp/library/cc261716.aspx) で関連するドキュメントをダウンロードしてください。

ハードウェアを選択する

ファーム内のマシンに適した仕様を選択することは、展開に対する適切な信頼性とパフォーマンスを確保する上で重要な作業です。注意する必要のある重要な考え方の 1 つは、ピーク負荷とピーク時間に応じて計画を作成する必要があるということです。つまり、平均以下の負荷条件でファームが運用されている場合、使用可能な十分なリソースが残されているため、遅延とスループットの目標を達成したまま予想される最大の要求を処理できます。

サーバーの容量とパフォーマンスに関する、中心となるハードウェア機能は、システムの処理能力、ディスク パフォーマンス、ネットワーク容量、およびメモリ容量の 4 つの主なカテゴリを反映します。

もう 1 つの検討事項として、仮想マシンの使用があります。SharePoint Server ファームは、仮想マシンを使用して展開できます。これにより、パフォーマンス上の利点が得られることは確認されていませんが、管理上の利点が得られます。一般的に、SQL Server サーバーベースのコンピューターを仮想化することは、推奨されませんが、Web サーバーとアプリケーション サーバーの層を仮想化することで特定の利点が得られる場合があります。詳細については、「仮想化の計画 (SharePoint Server 2010)」(https://technet.microsoft.com/ja-jp/library/ff607968.aspx) を参照してください。

ハードウェア選択のガイドライン

プロセッサを選択する

SharePoint Server 2010 は、64 ビット プロセッサでのみ使用できます。一般的に、プロセッサの数が多いほど、高い要求を処理できます。

SharePoint Server 2010 では、個々の Web サーバーは、コアを追加することで拡大します (24 コアまでテスト済み)。サーバーのコアが多くなると、サーバーはより高い負荷を持続できます。その逆も同じです。SharePoint Server の大規模展開では、複数の 4 コア Web サーバー (仮想化可能) またはそれより少ない強力な Web サーバー (8, 16, または 24 コア) を割り当てることをお勧めします。

アプリケーション サーバーのプロセッサ容量の要件は、サーバーの役割およびサーバーで実行するサービスによって異なります。SharePoint Server の機能によっては、他の機能よりも強力な処理能力が要求される場合があります。たとえば、SharePoint Search Service は、アプリケーション サーバーの処理能力に大きく依存します。SharePoint Server の機能とサービスに関するリソース要件については、「SharePoint Server 2010 での容量管理と規模設定の概要」の「サービスと機能」セクションを参照してください。

SQL Server のプロセッサ容量の要件も、SQL Server ベースのコンピューターでホストされるサービス データベースに依存します。各データベースの通常の動作と要件の詳細については、「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」を参照してください。

メモリの選択

サーバーで必要とされるメモリ容量は、サーバーの機能と役割によって異なります。たとえば、検索クロール コンポーネントを実行するサーバーに大量のメモリが搭載されていると、データ処理が高速になります。ドキュメントがメモリに読み込まれて処理されるためです。SharePoint Server 2010 の多くのキャッシュ機能を利用する Web サーバーでも、多くのメモリが必要とされる場合があります。

一般に、Web サーバーのメモリ要件は、ファームで有効にされているアプリケーション プールの数、および提供される同時要求数に大きく依存します。SharePoint Server のほとんどの運用展開において、各 Web サーバーに 8 GB RAM 以上を割り当てて、高いトラフィックのサーバーには 16 GB を割り当てるか、分離するようにセットアップされた複数のアプリケーション プールを使用して展開することをお勧めします。

アプリケーション サーバーのメモリ要件も同様に異なります。SharePoint Server 機能によっては、アプリケーション層でのメモリ要件が他の機能よりも高くなる場合があります。SharePoint Server のほとんどの運用展開において、各アプリケーションサーバーに 8 GB RAM 以上を割り当てることをお勧めします。同じサーバーで多くのアプリケーション サービスが有効にされている場合、または Excel Calculation Service、SharePoint Server Search Service など、メモリに大きく依存するサービスが有効にされている場合は、16 GB、32 GB、および 64 GB のアプリケーション サーバーが一般的です。

データベース サーバーのメモリ要件は、データベース サイズに密接に依存します。SQL Server ベースのコンピューターのメモリを選択する方法については、「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」を参照してください。

ネットワークの選択

クライアントがネットワーク経由で高速データ アクセスできる場合、ユーザーに利点がもたらされますが、それに加えて、分散されたファームでもサーバー間通信で高速アクセスを使用する必要があります。サービスを複数のサーバーに分散する場合や、いくつかのサービスを他のファームに統合する場合は、これが特に当てはまります。ファームでは、Web サーバー層、アプリケーション サーバー層、およびデータベース サーバー層間で膨大なトラフィックが発生するため、大容量ファイルの処理、非常に高い負荷など、特定の条件化で、ネットワークは簡単にボトルネックになる可能性があります。

Web サーバーとアプリケーション サーバーは、2 個以上のネットワーク インターフェイス カード (NIC) を使用して構成する必要があります。1 つの NIC でエンド ユーザーのトラフィックを処理し、もう 1 つの NIC でサーバー間通信を処理します。サーバー間のネットワークの遅延は、パフォーマンスに大きな影響を与える可能性があります。したがって、Web サーバーと、コンテンツ データベースをホストする SQL Server ベース コンピューター間のネットワーク遅延については、1 ミリ秒未満を維持することが重要です。また、各サービス アプリケーションのデータベースをホストする SQL Server ベースのコンピューターは、可能な限り、使用側アプリケーション サーバーに近づける必要もあります。ファーム サーバー間のネットワークの帯域幅は 1 Gbps 以上とする必要があります。

ディスクとストレージの選択

ディスク管理は、単に、適切なデータ領域を提供するだけの機能ではありません。現在の要求と拡大状況を評価し、ストレージ アーキテクチャによってシステムのパフォーマンスが低下していないことを確認する必要があります。各ディスクに、データ要件の最高の推定値に加えて、30% 以上の容量が常に確保されていることを確認し、将来の拡大のために余地を残しておく必要があります。また、ほとんどの運用環境において、サーバーのストレージ要求を満たすだけの十分なスループットを提供するディスク速度 (IOps) が重要になります。展開内の主なデータベースで必要とされるトラフィックの量 (IOps) を見積もり、そのトラフィックに対応する十分なディスクを割り当てる必要があります。

データベース サーバーのディスクを選択する方法については、「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」を参照してください。

Web サーバーとアプリケーション サーバーにもストレージ要件があります。ほとんどの運用環境において、OS と TEMP (一時領域) 用に 200 GB 以上のディスク領域、ログ用に 150 GB 以上のディスク領域を割り当てることをお勧めします。

手順 3. パイロット、テスト、および最適化

テストと最適化の段階は、効果的な容量管理の重要な要素です。新しいアーキテクチャは、運用環境に展開する前にテストする必要があります。また、受け入れテストを、以下の監視のベスト プラクティスと共に実施し、設計したアーキテクチャがパフォーマンスと容量の目標を達成することを確認する必要があります。これにより、実際の展開でユーザーが潜在的なボトルネックの影響を受ける前に、そのボトルネックを特定して最適化できます。Office SharePoint Server 2007 環境からアップグレードするときにアーキテクチャの変更を計画している場合や、SharePoint Server の新しい機能のユーザー負荷を見積もる場合、新しい SharePoint Server ベースの環境がパフォーマンスと容量の目標を満たすことを確認するためのテストが特に重要です。

環境のテストが完了すると、テスト結果を分析し、「手順 1. モデル作成」で確立したパフォーマンスと容量の目標を達成するために加える必要のある変更を確認できます。

以下の手順は、運用前に実行する必要のある推奨補助手順です。

• 「手順 2. 設計」で設計した初期のアーキテクチャを模倣するテスト環境を作成します。

• 「手順 1. モデル作成」で特定したデータセットまたはデータセットの一部をストレージに格納します。

• 「手順 1. モデル作成」で特定した負荷を表す人工的負荷をシステムにかけます。

• テストを実行し、結果を分析して、アーキテクチャを最適化します。

• 最適化したアーキテクチャをデータ センターで展開し、小さいユーザー セットを使用してパイロットをロールアウトします。

• パイロットの結果を分析し、潜在的なボトルネックを特定して、アーキテクチャを最適化します。必要に応じて、再テストを実行します。

• 運用環境に展開します。

テスト

テストは、負荷と使用特性をサポートするシステム設計の能力を確立する上で重要な要素です。SharePoint Server 2010 展開のテストの詳細については、「SharePoint Server 2010 のパフォーマンス テスト」を参照してください。

• テスト計画を作成する

• テスト環境を作成する

• テストとツールを作成する

パイロット環境を展開する

SharePoint Server 2010 を運用環境に展開する前に、まず、パイロット環境を展開し、ファームを十分にテストして、予想されるピーク負荷に対する容量とパフォーマンスの目標がパイロットで満たされることを確認することが重要です。特に大規模展開では、まず、人工的な負荷を使用してパイロット環境をテストした後に、小規模セットの実際のユーザーとコンテンツによってパイロット環境に負荷をかけることをお勧めします。小規模セットの実際のユーザーを使用してパイロット環境を分析することの利点は、運用環境に完全に移行する前に、使用特性とコンテンツの拡大に関するいくつかの前提条件を検証できることです。

最適化

ファームのハードウェアを拡大したり、トポロジに変更を加えたりしても、容量とパフォーマンスの目標を満たすことができない場合、ソリューションの改訂を検討する必要が生じる場合があります。たとえば、初期の要件がグループ作業 (検索と交流) 用の単一ファームを対象としていた場合、検索など、いくつかのサービスを専用のサービス ファームに統合したり、負荷をより多くのファームで分割したりする必要が生じる場合があります。1 つの代替方法として、交流用に専用ファームを展開し、チームのグループ作業用にもう 1 つのファームを展開します。

手順 4. 展開

テストの最終段階の実行が完了し、「手順 1. モデル作成」で確立したパフォーマンスと容量の目標が、選択したアーキテクチャによって達成されることを確認すると、SharePoint Server 2010 ベースの環境を運用環境に展開できます。

適切なロール アウト戦略は、環境と状況によって異なります。全般的に、SharePoint Server の展開はこのドキュメントの範囲外ですが、容量計画作業で実行できる特定の推奨活動があります。以下にいくつかの例を示します。

• 新しい SharePoint Server ファームの展開: 容量計画作業では、SharePoint Server 2010 の設計と展開についての計画を誘導して、確認する必要がありました。この場合、ロールアウトが、最初の広範な SharePoint Server 2010 の展開になります。容量計画作業中に使用したサーバーとサービスは、運用環境に移動して再構築する必要があります。これは、既存のファームをアップグレードしたり変更したりする必要がないため、最も簡単なシナリオです。

• SharePoint Server 2010 への Office SharePoint Server 2007 ファームのアップグレード: 容量計画作業では、ファームの設計が既存の要求を満たすこと、およびファームの設計をスケール アップして SharePoint Server 2010 ファームの増加する要求および使用状況を満たすことができることを確認する必要がありました。容量計画作業の一環としてテスト移行を含めて、アップグレード プロセスにかかる時間、変更または置き換えの必要があるカスタム コードがあるかどうか、更新が必要なサードパーティ ツールがあるかどうかなどを検証する必要がありました。容量計画の終わりに、設計の検証を完了し、アップグレードにかかる時間を把握し、アップグレード プロセスにおける最適な作業計画 (一括アップグレード、新しいファームへのコンテンツ データベースの移行など) を完了している必要がありました。一括アップグレードを行う場合、容量計画中に、追加またはアップグレードするハードウェアが必要なことや、ダウンタイムの検討事項を確認した可能性があります。計画作業からの出力には、必要なハードウェアの変更に関するリスト、およびハードウェアの変更をファームに最初に展開するための詳細な計画を含める必要があります。容量計画時に検証したハードウェア プラットフォームの配置が完了すると、SharePoint Server 2010 へのアップグレード プロセスに進むことができます。

• 既存の SharePoint Server 2010 ファームのパフォーマンスの向上: 容量計画作業によって、現在の実装に含まれるボトルネックの特定、そのボトルネックを削減または除外する方法の考案、SharePoint Server サービスのビジネス要件を満たす向上した実装の検証を行うことができました。パフォーマンスの問題を解決した可能性があるさまざまな方法があります。それは簡単な方法です。既存のハードウェア間でサービスの再割り当てを行うか、既存のハードウェアをアップグレードするか、ハードウェアを追加してそれにサービスを追加することです。各方法は容量計画作業中にテストして検証する必要があります。その後、テスト結果に応じて展開計画を策定します。

手順 5: 監視と維持

システム パフォーマンスを維持するには、サーバーを監視して潜在的なボトルネックを特定する必要があります。監視を効果的に行うには、ファームの特定の部分に注意が必要な場合にそれを伝える重要な指標、およびその指標を解釈するためのノウハウを理解しておく必要があります。定義した目標の範囲外でファームが運用されていることを確認した場合、ハードウェア リソースの追加や削除、トポロジの変更、またはデータの格納方法の変更を行ってファームを調整できます。

「SharePoint Server 2010 の監視と保守」には、設定の一覧が含まれます。これらの設定を変更し、初期の段階の環境を監視できます。これにより、必要な変更があるかどうかを確認できます。監視機能を増強すると、使用状況データベースで必要とされるディスク領域の量が影響を受けます。環境が安定し、この詳細監視の必要がなくなった場合、設定を既定に戻すことをお勧めします。

SharePoint Server サーバーの全体管理インターフェイスに組み込まれた正常性監視ツールを使用して、正常性監視とトラブル シューティングを行う方法については、以下のドキュメントを参照してください。

正常性の監視 (SharePoint Server 2010)

問題の解決とトラブルシューティング (SharePoint Server 2010) (https://technet.microsoft.com/ja-jp/library/ee748639.aspx)

See Also

Concepts

SharePoint Server 2010 での容量管理と規模設定の概要
SharePoint Server 2010 のパフォーマンス テスト
SharePoint Server 2010 の監視と保守
正常性の監視 (SharePoint Server 2010)
ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)