SharePoint Server 2010 での容量管理と規模設定の概要
更新日: 2012年6月
適用先: SharePoint Server 2010
トピックの最終更新日: 2016-11-30
この記事は、効果的に Microsoft SharePoint Server 2010 環境の容量を計画して、管理する方法の概要を示します。また、この記事はパフォーマンスおよびボリューム データの分析により、展開での容量要件および機能を把握する方法について説明します。また、コンテンツの特性および利用状況を含め、容量に対する主要なアプリケーションからの影響を確認します。
実装はコンテンツと利用状況に対して静的なままであることはないので、容量管理は、常に進行中の過程です。SharePoint Server 2010 に基づく環境が効率的なビジネス ソリューションを安定して提供できるように、成長と変更をふまえて計画する必要があります。
容量計画は、容量管理サイクルの一部に過ぎません。設計アーキテクトは、初期アーキテクチャが SharePoint Server 2010 展開で最適に機能するかを、一連の初期アクティビティで判断します。容量管理モデルには、初期アーキテクチャを検証し、調整する際に役立つ追加の手順が含まれ、ハードウェア、トポロジ、および構成の最適な選択を含め、設計目的を実現できるまで、再計画と運用環境を最適化するフィードバック ループを提供します。
この記事の内容
用語集
容量管理についての記事の対象読者
パフォーマンスの 4 つの基本
容量管理と容量計画の比較
規模過大と規模過小の比較
ソフトウェアの制限および境界
主な相違点: SharePoint Server 2010 と Office SharePoint Server 2007 の比較
SharePoint Server 2010 の展開での主な差別化要因
基準となるアーキテクチャ
用語集
以下の専門用語が SharePoint Server 2010 の容量管理についての文書で使用されます。
RPS 秒あたりの要求。1 秒間にファームまたはサーバーが受信した要求の数。これはサーバーとファームの負荷の一般的な計測方法です。ファームで処理される要求の数は、ページ読み込みとエンド ユーザーの操作の回数より大きくなります。これは、各ページに複数のコンポーネントが含まれ、それらが、ページが読み込まれるときに 1 つまたは複数の要求を作成するからです。いくつかの要求は、トランザクション コストに関して、その他の要求より軽くなります。ラボ テストとケース スタディ文書では、ファーム リソースへの影響がほとんどないことから、RPS を計算する際の要求から 401 要求および応答 (認証ハンドシェイク) を除外しています。
ピーク時間 ファームでの負荷が最大となる時間。
ピーク負荷 RPS で測定された、ファームでの日単位での最高負荷の平均。
負荷スパイク 通常のピーク時間外に発生する、一時的な負荷のピーク。これは、ユーザー トラフィックの予定外の増加、管理操作によるファーム スループットの減少、またはこのような要因の組み合わせによって発生することがあります。
スケール アップ スケール アップとは、サーバーにプロセッサまたはメモリのようなリソースを追加することを意味します。
スケール アウト スケール アウトとは、ファームにより多くのサーバーを追加することを意味します。
容量管理についての記事の対象読者
このコンテンツを読む必要があるかどうかについては、以下の質問を考慮してください。
SharePoint Server 2010 の評価
IT 担当者またはビジネス意思決定者で、特定のビジネス問題のソリューションを探しています。SharePoint Server 2010 は、私が検討している展開の選択肢の 1 つです。これは、特定の要件を満たす機能とスケーラビリティを実現できるでしょうか。
SharePoint Server 2010 が特定のソリューションの要求に対してどのように規模的に対応するかの情報について、また、要件を満たすのに必要なハードウェアをどのように決定するかについては、この記事で後述する以下のセクションを参照してください。
主な相違点: SharePoint Server 2010 と Office SharePoint Server 2007 の比較
ソフトウェアの制限および境界
特定のビジネス要件に対して SharePoint Server 2010 を評価する方法についての情報は、以下の記事を参照してください。
Office SharePoint Server 2007 からのアップグレード
現在、Office SharePoint Server 2007 を使用しています。SharePoint Server 2010 では何が変更され、アップグレードする際には何を考慮する必要があるでしょうか。アップグレードは、トポロジのパフォーマンスと規模にどのように影響するでしょうか。
Office SharePoint Server 2007 と SharePoint Server 2010 でパフォーマンスと容量要因がどのように異なるかについては、この記事で後述する以下のセクションを参照してください。
- 主な相違点: SharePoint Server 2010 と Office SharePoint Server 2007 の比較
Office SharePoint Server 2007 からのアップグレードを計画し実行するうえでの、より一般的なアップグレードの注意事項とガイダンスについては、以下の記事を参照してください。
ライブの SharePoint ベース環境の調整と最適化
SharePoint Server 2010 を展開しましたが、適切なハードウェアとトポロジが配置されていることを確認する必要があります。アーキテクチャを検証して、適切に管理するにはどうすればいいでしょうか。
Microsoft SharePoint Server 2010 ファームの監視とパフォーマンス カウンターについては、以下の記事を参照してください。
サーバーの全体管理インターフェイスに組み込まれた正常性監視ツールを使用する方法については、以下の記事を参照してください。
SharePoint Server 2010 を展開した後で、パフォーマンスの問題が発生しています。環境をトラブルシューティングして、最適化するにはどうすればいいでしょうか。
Microsoft SharePoint Server 2010 ファームの監視とパフォーマンス カウンターについては、以下の記事を参照してください。
サーバーの全体管理インターフェイスに組み込まれた正常性監視ツールを使用したトラブルシューティングについては、以下の記事を参照してください。
多くの特定の SharePoint Server 2010 のサービスおよび機能の容量管理に関する記事のリストについては、以下の記事を参照してください (記事は入手可能になりしだい、追加されます)。
データベースの規模設定およびパフォーマンスの情報については、以下の記事を参照してください。
リモート BLOB ストレージ (RBS) の情報については、以下の記事を参照してください。
最初から最後まで
SharePoint Server 2010 の容量管理のすべてについて知る必要があります。どこから始めたらいいでしょうか。
容量管理の一般的な概念の情報と、追加の文書とリソースへのリンクについては、以下の記事を参照してください。
容量管理の追加情報については、この概要記事に関連する以下の記事を参照してください。
これらの記事で、概念については十分に理解できるはずです。SharePoint Server 2010 の制限と境界については、以下の記事を参照してください。
SharePoint Server 2010 ベースの環境での開始点トポロジを識別する準備ができたら、自分の要件に最も一致する要件がないか、入手可能なテクニカル ケース スタディのライブラリを調べることができます。ケース スタディのリストについては、以下の記事を参照してください (今後、ケース スタディは、順次、追加されます)。
多くの特定の SharePoint Server 2010 のサービスおよび機能の容量管理に関する記事のリストについては、以下の記事を参照してください (記事は入手可能になりしだい、追加されます)。
データベースの規模設定およびパフォーマンスの情報については、以下の記事を参照してください。
リモート BLOB ストレージ (RBS) の情報については、以下の記事を参照してください。
サーバーの全体管理インターフェイスに組み込まれた正常性監視ツールを使用した正常性監視およびトラブルシューティングについては、以下の記事を参照してください。
一般的なパフォーマンス調整ガイドラインと、さまざまな特定のパフォーマンスと容量に関する事項については、以下の記事を参照してください (記事は入手可能になりしだい、追加されます)。
SharePoint Server 2010 ベースのサーバーを仮想化する方法の詳細については、以下の記事を参照してください。
パフォーマンスの 4 つの基本
容量管理は、ソリューションの規模設定での以下の 4 つの主な側面に重点を置いています。
待機時間 容量管理の目的からは、待機時間とは、ユーザーが、ハイパーリンクのクリックのようなアクションを開始してから、最後のバイトがクライアント アプリケーションまたは Web ブラウザーに送信されるまでの継続時間と定義されます。
スループット スループットとは、サーバーまたはサーバーファームが同時に処理できる要求の数と定義されます。
データ規模 データ規模とは、システムがホストすることができるコンテンツ サイズとデータ コーパスと定義されます。コンテンツ データベースの構造と配置は、システムが要求を処理するまでにかかる時間 (待機時間) と、同時に扱える要求の数 (スループット) に重大な影響を及ぼします。
信頼性 信頼性とは、一定時間の待機時間とスループットについて設定された目標を、システムがどれだけ達成できますかという能力の計測です。
環境の容量を管理する主な目的は、組織で目標とされる待機時間、スループット、データ規模、および信頼性に適合するシステムを設定し、管理することです。
待機時間
待機時間は、エンド ユーザー認知待機時間とも呼ばれ、主に 3 つの要素から構成されます。
サーバーが要求を受信して、処理する際に要する時間。
ネットワーク経由で要求とサーバー対応が転送される際に要する時間。
応答がクライアント アプリケーションでレンダリングされる際に要する時間。
異なる組織では、ビジネス要件とユーザーの期待に基づいて、異なる待機時間目標が定義されます。一部の組織では数秒の待機時間を許すことができますが、その他の組織では非常に迅速なトランザクションを必要とします。非常に迅速なトランザクションに最適化するには、通常、よりコストがかかり、より強力なクライアントとサーバー、最新のブラウザーとクライアント アプリケーション、高帯域幅ネットワーク ソリューション、および、おそらく開発投資とページ調整が必要とされます。
エンド ユーザー認知待機時間が長くなる主な要因と、いくつかの一般的な問題の例は、以下のリストで示されます。これらの要因は、クライアントがサーバー ファームから地理的に遠いシナリオ、または低帯域幅のネットワーク接続でファームにアクセスしているシナリオでは、特に重要です。
最適化されていない機能、サービス、または構成パラメーターは、要求の処理を遅らせ、リモートおよびローカル クライアントの両方の待機時間に影響することがあります。詳細については、この記事で後述する「スループット」と「信頼性」を参照してください。
必要なデータとリソースをダウンロードする際、サーバーに不必要な要求を生成する Web ページ。最適化には、ページを描画する目的で最小数のリソースをダウンロードすること、画像のサイズを減らすこと、匿名のアクセスを有効にするフォルダーに静的なリソースを保存すること、要求をクラスター化し、リソースがサーバーから非同期的にダウンロードされる間に、ページ対話型操作を有効にすることが含まれます。これらの最適化は、初回の参照エクスペリエンスを許容範囲内にする目的で重要です。
ネットワーク経由で送信される過剰な量のデータは、待機時間を増やし、スループットを低下させます。たとえば、ページ上の画像とその他のバイナリ オブジェクトは、可能な限り、ビットマップではなく .png または .jpg のような圧縮形式を使用する必要があります。
2 回目のアクセスのページ読み込みに最適化されない Web ページ。一部のページ リソースがクライアントでキャッシュされ、ブラウザーはキャッシュされていない動的コンテンツのみをダウンロードすることにより、2 回目のアクセスのページ読み込みでのページ読み込み時間 (PLT) は減少します。2 回目のアクセスのページ負荷待機時間が増加するのは、多くの場合、正しくないバイナリ ラージ オブジェクト (BLOB) キャッシュ構成か、クライアント コンピューターでローカル ブラウザー キャッシュが無効になっていることが原因です。最適化には、クライアントでのリソースの適切なキャッシュが含まれます。
最適化されていないカスタムの JavaScript コードを含む Web ページ。これにより、クライアントでページのレンダリングが遅くなる可能性があります。最適化では残りのページが読み込まれるまで、クライアントでの JavaScript の処理を遅らせ、理想的には、JavaScript をインラインで追加する代わりにスクリプトを呼び出します。
スループット
スループットは、サーバー ファームが一定時間で処理できる要求の数で示され、組織の規模とその利用状況の特性に基づき、システムが維持することを期待される操作の規模を評価する目的でしばしば使用されます。すべての操作は、サーバー ファーム リソースで特定のコストを必要とします。需要を理解し、一貫して需要を満足させることができるファーム アーキテクチャを展開するには、同時実行が頻繁で、システムにストレスがかかっているとき、その待機時間が目標以下にならないように検証する目的で、予想負荷を予測し、負荷をかけてアーキテクチャをテストすることが必要です。
スループットを低下させる一般的な条件には、以下のような例があります。
不十分なハードウェア リソース ファームが同時に処理できる以上の要求を受信すると、一部の要求がキューに入れられます。この場合、需要が十分に減ってキューがなくなるまで、それ以降の要求の処理は累積的に遅れます。より高いスループットを維持できるように、ファームを最適化する例には以下のものが含まれます。
ファーム サーバーのプロセッサが過度に使用されないようにします。たとえば、ピーク時間または負荷スパイク時の CPU 利用状況が継続的に 80 パーセントを超えている場合は、より多くのサーバーを追加するか、その他のファーム サーバーにサービスを再分配します。
アプリケーション サーバーと Web サーバーに、キャッシュ全体を含められるだけの十分なメモリがあるようにします。これにより、キャッシュされていないコンテンツの要求に応答する目的で、データベースに呼び出しをせずに済むようになります。
データベース サーバーにボトルネックが発生しないようにします。全体的に使用可能なディスク IOPS がピーク需要に対して不十分な場合、より多くのディスクを追加して、または十分利用されていないディスクにデータベースを再分配します。詳細については、「SharePoint Server 2010 製品とテクノロジの監視および管理」の記事の「ボトルネックをなくす」のセクションを参照してください。
既存のコンピューターにリソースを追加してもスループットの問題が十分に解決されない場合は、サーバーを追加し、影響を受けている機能およびサービスをその新しいサーバーに再分配します。
最適化されていないカスタム Web ページ 運用環境で頻繁に使用するページにカスタム コードを追加することは、スループットの問題のよくある原因です。カスタム コードを追加すると、サービスのデータ要求に対し、データベース サーバーまたは Web サービスに追加のラウンド トリップが生成される可能性があります。あまり使用しないページのカスタマイズは、スループットに大きな影響を与えないことがあります。しかし、適切に最適化されたコードであっても、1 日に何千回も要求された場合は、ファーム スループットを減らすことがあります。SharePoint Server 管理者は、開発者ダッシュボードを有効にして、最適化を必要とするカスタム コードを識別できます。以下は、カスタム コードの最適化のいくつかの例です。
Web サービス要求と SQL クエリの数を最小限にします。
データベース サーバーへの各呼び出しで、必要なラウンド トリップの数を最小限にし、必要な最小限のデータを取得します。
頻繁に使用するページには、カスタム コードを追加しないようにします。
フィルター処理されたデータを取得するとき、インデックスを使用します。
信頼されていないソリューション bin フォルダーにカスタム コードを展開すると、サーバーのパフォーマンスを低下させることがあります。信頼されていないコードを含むページが要求されるたびに、ページを読み込む前に、SharePoint Server 2010 はセキュリティ チェックを実行する必要があります。信頼されていないコードを展開する特定の理由がない限り、不必要なセキュリティ チェックを避けられるように、カスタム アセンブリを GAC にインストールする必要があります。
データ規模
データ規模とは、待機時間とスループットの目標を達成した上で、サーバーまたはサーバーファームが保存することができるデータのボリュームです。一般的には、ファームのデータ ボリュームが大きいほど、全体的なスループットおよびユーザー エクスペリエンスへの影響が増加します。ディスクとデータベース サーバー間でデータを分散する方法は、また、ファームの待機時間およびスループットに影響することがあります。
データベース規模設定、データ アーキテクチャ、および十分なデータベース サーバーのハードウェアはすべて、最適なデータベース ソリューションにとって非常に重要です。理想的な展開では、コンテンツ データベースは制限ガイダンスに従って規模設定され、物理ディスク間で分散されます。これにより、ディスク過大使用により要求がキューに入れられないようになります。また、データベース サーバーは、リソース利用率しきい値を超えずに、ピーク負荷と予想外のスパイクに対応することができるようになります。
また、特定の操作は、操作中に特定のテーブルをロックすることがあります。この例としては、大規模なサイトの削除があります。この場合、削除操作が完了するまで、サイトが存在するコンテンツ データベース内の関連するテーブルがロックされることがあります。
データおよび記憶域パフォーマンスに関してのファームの最適化の例には、以下のものがあります。
データベースが、データベース サーバー間で適切に分散されるようにします。また、データのボリュームおよび分散に対応できるように、データベース サーバーのリソースが十分であるようにします。
一意の物理ディスク スピンドルから構成される、一意の論理ユニット (LUN) にデータベース ボリュームを分割します。データベース サーバーの記憶域での需要を満たせるように、短いシーク時間と適切な RAID 構成を持つ複数のディスクを使用します。
コーパスが多くのバイナリ ラージ オブジェクト (BLOB) を含む場合は、リモート BLOB ストレージ (RBS) を使用することができます。RBS には次のメリットがあります。
単純なストレージを処理するように構成された低コストのストレージ デバイスに BLOB データを格納できます。
BLOB データに特化して設計されたシステムによって BLOB ストレージが管理されます。
データベース サーバーのリソースがデータベース操作用に解放されます。
これらの利点には、代償が発生します。RBS を SharePoint Server 2010 に実装する前に、これらの利点が、RBS を実装して維持するコストや制約に見合うものか評価してください。
詳細については、「RBS を計画する (SharePoint Server 2010)」を参照してください。
データ規模を計画する方法の詳細については、「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」を参照してください。
信頼性
信頼性とは、サーバー ファームの容量が、一定時間内に、設定した待機時間、スループット、およびデータ容量の目標を満たすかどうかの、総計の計測です。信頼性が高いファームでは、稼働時間、反応性、障害発生率、および待機時間スパイクの頻度と振幅が、設定した目標および運用上の要件を満たしています。信頼性が高いファームは、また、ピーク負荷とピーク時間中、またはクロールや毎日のバックアップのようなシステム操作が発生するときに、待機時間およびスループット目標を一貫して達成することができます。
持続的な信頼性の重要な要因は、パフォーマンス目標への一般的な管理操作の影響です。データベース インデックスの再構築、保守タイマー ジョブ、または大量のコンテンツを持つ複数のサイトの削除のような特定の処理中に、システムは、ユーザー要求をすばやく処理できないことがあります。この場合、エンド ユーザー要求の待機時間およびスループットの両方が低下することがあります。ファームへの影響は、このようなそれほど一般的でない操作の頻度とトランザクション コスト、そしてそれらが通常の運用時間中に実行されるかどうかに依存します。
より信頼性が高いシステムを維持する方法の例としては以下のものがあります。
リソースに負担をかけるタイマー ジョブと管理タスクを、オフピーク時間中にスケジュール設定します。
既存のファーム サーバーのハードウェアをスケール アップするか、Web サーバー、アプリケーション サーバー、またはデータベース サーバーを追加することでスケール アウトします。
リソースに負担をかけるサービスおよび機能を専用のサーバーに配分します。またハードウェアのロード バランサーを使用して、特定の機能またはサービス専用の Web サーバーに、機能固有のトラフィックを向けることができます。
容量管理と容量計画の比較
容量管理は、容量計画の概念を拡張して循環的な方法を表したものであり、変化する条件と要件に対応するために SharePoint Server 2010 展開の容量を継続的に監視して最適化します。
SharePoint Server 2010 では柔軟性が向上しており、多様な規模ポイントでの利用状況シナリオを実現するよう構成することができます。単一の展開アーキテクチャというものはありません。つまり、システムのデザイナーおよび管理者は、固有の環境の要件を理解する必要があります。
SharePoint Server 2010 容量管理モデル
.gif "SharePoint キャパシティ管理モデル")
手順 1. モデル モデリングとは、環境がサポートする必要のある、キー ソリューションを決定する過程で、すべての重要な測定基準とパラメーターを確立します。モデリングの結果は、使用中の環境を設計する際に必要なすべての主要なデータのリストとなります。
予想される負荷とデータセットを理解します。
ファームのパフォーマンスおよび信頼性の目標を設定します。
SharePoint Server 2010 IIS ログを解析します。
手順 2. 設計 手順 1. でデータを収集した後、ファームを設計することができます。出力は、詳細なデータ アーキテクチャと、物理および論理トポロジです。
出発点となるアーキテクチャを決定します。
ハードウェアを選択します。
手順 3. パイロット、テスト、および最適化 新しい展開を設計したとき、負荷および予想される利用状況特性をテストするパイロット環境を展開する必要があります。既存のファームで、インフラストラクチャに大きな変更が行われた場合、テストが推奨されますが、パフォーマンス目標を維持できるよう監視結果に基づく通常の最適化が必要になる可能性があります。この段階での出力とは、目標に対してのテスト結果の分析と、設定したパフォーマンスと容量目標を維持できる最適化されたアーキテクチャのことです。
パイロット パイロット環境を展開します。
テスト 待機時間およびスループットについて目標をテストします。
最適化 テスト結果を集めて、ファーム リソースとトポロジに必要な変更を行います。
手順 4. 展開 この手順では、ファームの実装、または既存のファームに変更を展開することについて説明します。新しい設計の場合の出力は、すべてのコンテンツおよびユーザー移行を含め、ライブ運用環境への展開を完了することです。既存のファームの出力は、ファーム マップの改訂と、保守計画の更新です。
手順 5. 監視と管理 この手順では、監視をセットアップする方法と、ボトルネックを予測、識別して、通常の保守とボトルネック緩和アクティビティを実行する方法について説明します。
規模過大と規模過小の比較
規模過大とは、ハードウェアの上限まで利用されることなく目標が到達され、SharePoint Server ファームのリソースが一貫してあまり利用されていないファーム設計の手法を指します。規模過大の展開では、メモリ、CPU、およびファームのリソースのその他の指標は、より少ないリソースでも、適切に需要に応えることができることを示します。規模過大の欠点は、ハードウェアと保守の出費が増え、必要となる電源と設置場所も増えることです。
規模過小とは、SharePoint Server ファームでハードウェア リソースが使用され過ぎていることにより、パフォーマンスと容量の目標が達成できないファーム設計の手法を指します。ファームを規模過小にすることは、ハードウェアのコストを減らす目的で行われることがあります。しかし、一般的には、待機時間が長くなることで、ユーザー エクスペリエンスの質と満足度を下げ、エスカレーションが頻繁になり、サポートのコストが上がり、環境のトラブルシューティングおよび調整の目的で不必要な出費が発生します。
ファームを設計するとき、通常のピーク負荷と予想外のスパイクの両方について、設定したパフォーマンスおよび容量目標をファームが満たすことができることを確認してください。設計、テスト、および最適化により、ファームが適切なハードウェアを備えていることを確認できます。
パフォーマンス目標を維持して、成長に対応するために、目標を満たす最小限より多くのリソースを持つことが常に理想的です。ハードウェアへの過大投資のコストは、通常、規模過小による問題のトラブルシューティングに関連する累積的な出費と比較して非常に少なくなります。
ピーク需要は、さまざまな時間での特定のサービスにおいて異なることがあるので、十分に対応できるようシステムを規模設定しておく必要があります。効果的に容量要件を見積もるには、すべてのリソースについて最悪の場合の需要期間を識別する必要があります。始業時または昼食後のような、1 日の特定の時間で、さまざまな機能およびサービスで負荷が増大することがあります。
また、ファームは、組織全体への告知がされている場合や、異常に多数のユーザーがサイトに同時にアクセスするときのような、予定外のピークに対応できる必要があります。このような高需要の期間中に、ファームで増大した負荷に対応できる十分なファーム リソースが利用できない場合は、ユーザーに長時間の待機時間が発生したり、または、ファームからまったく応答が得られなくなったりすることがあります。
企業でユーザーが追加されたときも、ファーム容量を再考する必要があります。合併や買収のような状況では、ファームにアクセスする新しい社員やメンバーが増え、事前に計画し予測しておかないと、パフォーマンスに悪影響を与えることがあります。
動作状態: グリーン ゾーンとレッド ゾーン
運用システムの負荷を示すとき、主な動作状態が 2 つあります。"グリーン ゾーン" 状態では、システムが通常の、予想された負荷の範囲内で動作しています。"レッド ゾーン" 状態は、ファームに一時的に非常に高いリソース需要が発生している状態で、障害、他のパフォーマンス、信頼性の問題が発生するまでの限られた期間のみ持続されます。
グリーン ゾーン これは、サーバーまたはファームが、予想される日ごとのピーク負荷の範囲内の、通常の負荷条件の下で動作している状態です。この範囲内で動作上のファームは、応答時間と待機時間を許容範囲のパラメーター内に維持することができます。
レッド ゾーン 負荷が通常のピーク負荷より大きくなっていますが、一定期間は要求に応答できる動作範囲です。この状態では、システム ボトルネックの飽和により、通常より長い待機時間と障害の可能性があります。
ファーム設計の最終目的は、サービス障害を起こさず、許容範囲の待機時間およびスループット目標内で、レッド ゾーン負荷に一貫して対応できる環境を展開することです。
ソフトウェアの制限および境界
SharePoint Server 2010 には、仕様によって固定されている超過不可能な制限と、ファーム管理者が既定値を変更できる制限があります。また、Web アプリケーションごとのサイト コレクション数のように、構成可能な値では示されない制限もあります。
境界とは、仕様によって固定されている超過不可能な絶対制限値です。これらの制限を把握し、ファーム設計時に正確でない想定を行わないようにすることが重要です。
たとえば、2 GB のドキュメント サイズ制限も境界の 1 つです。2 GB より大きなドキュメントを保存するように SharePoint Server 2010 を構成することはできません。これは組み込みの固定値であり、仕様によって超過不可能になっています。
しきい値とは、既定値のある制限で、値を変更しない限り、超過できません。しきい値は、状況に応じて、ファームの設計に適合させるために超過できますが、既定値を超えるとファームのパフォーマンスやその他の制限の有効値に影響することがあるので、それについて理解することが重要です。
一部のしきい値では、既定値の超過は絶対最大値までに制限されます。ドキュメント サイズ制限もその 1 つです。既定では、ドキュメント サイズの限界は 50 MB に設定されていますが、この限界を最大値 2 GB までの範囲で変更できます。
サポートされる制限は、パラメーターごとのテスト済み値を定義します。このような制限の既定値は、テスト結果に基づいて定義されており、製品の既知の制限を示します。サポートされる制限を超えると、予期しない結果、パフォーマンスの著しい低下のように、悪影響が発生する可能性があります。
サポートされる制限には、既定で推奨値に設定される構成可能なパラメーターになっているものと、構成可能な値では示されないパラメーターに関連するものがあります。
たとえば、Web アプリケーションごとのサイト コレクション数もサポートされる制限の 1 つです。この場合のサポートされる制限は 500,000 個であり、この数は、テスト時にパフォーマンス ベンチマークに適合した、Web アプリケーションごとのサイト コレクションの最大数です。
このドキュメントで示す制限値の多くは、リソース負荷の増加とそれに伴うパフォーマンス低下を示す曲線の 1 点を表しています。したがって、Web アプリケーションごとのサイト コレクション数のように、ある特定の制限値を超過しても、ファームのパフォーマンスは少ししか低下しない場合もあります。ただし、ほとんどの場合、示された制限値やその値近辺まで使用することはお勧めしません。制限値の適切なバランスを保つようにファームを設計した場合に、許容範囲のパフォーマンスと信頼性の目標を最大限に実現できます。
しきい値とサポートされる制限のガイドラインは、パフォーマンスに基づいて確認されています。つまり、既定の制限値より大きくすることはできますが、制限値を大きくするとファームのパフォーマンスやその他の制限の有効値に影響することがあります。SharePoint Server 2010 の制限値の多くは変更できますが、制限の変更によるファームの他の部分への影響を把握しておくことが重要です。
「ハードウェア要件およびソフトウェア要件 (SharePoint Server 2010)」で説明されている、最小ハードウェア仕様を満たしていない運用システムに関して Microsoft テクニカル サポートに問い合わせても、システムをアップグレードして最小要件を満たすまで、受けられるサポートは限定的です。
制限値の確認方法
SharePoint Server 2010 では、ファームのサービスと操作が有効な操作性限度に達するまで負荷を増加させ、ファームの動作をテストおよび観測することによって、しきい値とサポートされる制限が確認されています。ファームのサービスとコンポーネントには、他のサービスやコンポーネントより高い負荷をサポートできるものもあります。このことから、場合によっては、複数の要素の平均値に基づいて制限値を割り当てる必要があります。
たとえば、サイト コレクションを追加して負荷に対するファームの動作を観察すると、許容範囲外の長い待機時間を示す機能と、許容可能なパラメーター範囲内で動作する機能があります。したがって、サイト コレクション数として割り当てる最大値は絶対ではなく、大部分の状況において指定の制限値でファームの全体的なパフォーマンスが許容範囲になると想定される使用特性一式に基づいて算出されます。
制限値のテストに使用したパラメーターより大きい値のパラメーターでサービスを使用する場合には、一部のサービスの有効な制限値は当然低下します。したがって、使用する環境における有効な制限値を取得するには、固有の展開において厳密な容量管理およびスケール テストを実施することが重要です。
境界および制限と、容量管理過程にどのように影響するかの詳細については、「SharePoint Server 2010 容量管理ソフトウェアの境界と制限」を参照してください。
主な相違点: SharePoint Server 2010 と Office SharePoint Server 2007 の比較
SharePoint Server 2010 では、以前のバージョンと比較して、より多くの機能を持ち、より柔軟なトポロジ モデルを使用できます。ユーザーにより高機能な機能を提供できるよう、このより複雑なアーキテクチャを使用する前に、ファームの容量とパフォーマンスにどのような影響があるか慎重に検討する必要があります。
Office SharePoint Server 2007 では、SSP (共有サービス プロバイダー) で有効にできる主なサービスが 4 つありました。つまり、Search Service、Excel Calculation Service、User Profile Service、および Business Data Catalog Service です。さらに、Office SharePoint Server 2007 と直接接続できる、比較的少数のクライアントがありました。
SharePoint Server 2010 では、SSA (SharePoint Service アプリケーション) と呼ばれる、より多くのサービスが使用できます。また、SharePoint Server 2010 では、ファームと連携できるクライアント アプリケーションが大幅に増えています。これらには、いくつかの新しい Office アプリケーション、モバイル デバイス、デザイナー ツール、およびブラウザーが含まれます。拡張されたクライアントとのいくつかの相互作用では、以下のような、容量に関する考慮事項に影響を与えるものがあります。
SharePoint Server 2010 には、Outlook と統合されるソーシャル アプリケーションが含まれます。これにより、Outlook 2013 クライアントは、電子メールメッセージが Outlook クライアントで表示されるとき、SharePoint Server ファームから取得した電子メール受信者の情報を表示できるようになります。これにより、考慮する必要がある、新しい一連のトラフィック パターンおよびサーバー負荷が発生するようになります。
いくつかの新しい Microsoft Office 2010 クライアント機能では、クライアント アプリケーションが実行しており、活発に使用されていないときでも、SharePoint Server ファームに対して、自動的にデータを更新します。SharePoint Workspace と OneNote のようなクライアントでも、考慮する必要があるいくつかの新しいトラフィック パターンおよびサーバー負荷が発生するようになります。
ブラウザーから直接 Office ファイルを編集できるようにする、Office Web Apps のような、SharePoint Server 2010 の新しい Web 対話型操作機能は、考慮する必要があるいくつかの新しいトラフィック パターンおよびサーバー負荷を発生させる、AJAX 呼び出しを使用します。
Office SharePoint Server 2007 では、サーバーを操作する主なクライアントは Web ブラウザーでした。SharePoint Server 2010 でのより豊富な機能セットにより、全体的な 1 秒あたりの要求 (RPS) は増加すると予想されます。さらに、ブラウザーから来る要求の割合は Office SharePoint Server 2007 より小さくなると予想されます。これにより、組織全体で広く使用されている、他のクライアントから来る新しく増加したトラフィックの余地が生まれます。
さらに、SharePoint Server 2010 では、ファームの負荷を増やす、ネイティブの埋め込みビデオ サポートのような新しい機能が導入されています。また、いくつかの機能は、以前のバージョンより大きな規模をサポートするよう拡張されています。
以下のセクションでは、ソリューションを設計するときに検討する必要がある、これらのクライアントの相互作用、サービスおよび機能、そして、システムの全体的なパフォーマンスおよび容量への影響について説明します。
SharePoint Server 2010 へのアップグレード方法の詳細については、「SharePoint Server 2010 にアップグレードする」を参照してください。
サービスと機能
以下の表は、各層で異なるサービスのリソース要件について、単純化された高レベルの説明を示します。空白セルは、そのサービスがその層で実行できないか、影響を与えないことを示します。
X - リソースに、最小限、またはごく限定的なコストを要することを示します。サービスは、その他のサービスとこのリソースを共有することができます。
XX - リソースに、中程度のコストを要することを示します。サービスは、その他のサービスとこのリソースを共有することができ、その際、限定的な影響があります。
XXX - リソースに、大きなコストを要することを示します。サービスは、一般的には、その他のサービスとこのリソースを共有すべきではありません。
SQL Server データベースの計画方法の詳細については、「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」を参照してください。
多くの特定の SharePoint Server 2010 のサービスおよび機能の容量管理に関する記事のリストについては、「パフォーマンスと容量のテスト結果と推奨事項 (SharePoint Server 2010)」を参照してください (記事は入手可能になりしだい、追加されます)。
| サービス アプリケーション | Web サーバー CPU | Web サーバー RAM | アプリケーション サーバー CPU | アプリケーション サーバー RAM | SQL Server CPU | SQL Server IOPS | SQL Server 記憶域 | |
|---|---|---|---|---|---|---|---|---|
SharePoint Foundation Service |
XXX |
XXX |
XX |
XXX |
XXX |
|||
サーバーの全体管理サービス |
XX |
XX |
X |
X |
X |
|||
ログ サービス * |
XX |
XX |
XX |
XXX |
XXX |
|||
SharePoint Search Service |
XXX |
XXX |
XXX |
XXX |
XXX |
XXX |
XXX |
|
Word Viewing Service アプリケーション * |
X |
X |
XXX |
XX |
||||
PowerPoint Service * |
XX |
XX |
XXX |
XX |
||||
Excel Calculation Service |
XX |
X |
XX |
XXX |
||||
Visio Service * |
X |
X |
XXX |
XXX |
X |
X |
X |
|
Access Service * |
X |
X |
XXX |
XX |
X |
X |
X |
|
User Profile Service |
X |
XX |
XX |
XX |
XXX |
XXX |
XX |
|
Managed Metadata Service * |
X |
XX |
XX |
XX |
X |
X |
XX |
|
Web Analytics Service * |
X |
X |
XXX |
XXX |
XXX |
|||
Business Connection Service * |
XX |
XX |
XXX |
XXX |
||||
InfoPath Forms Service |
XX |
XX |
XX |
XX |
X |
X |
X |
|
Word Conversion Service |
X |
X |
XXX |
XX |
X |
X |
X |
|
PerformancePoint Service アプリケーション * |
XX |
XX |
XXX |
XXX |
X |
X |
X |
|
Project Service * |
X |
X |
X |
X |
XXX |
XXX |
XX |
|
サンドボックス ソリューション * |
X |
X |
XXX |
XXX |
||||
ワークフロー機能 * |
XXX |
XXX |
||||||
Timer Service |
XX |
XX |
XX |
XX |
||||
PowerPivot * |
X |
X |
XXX |
XXX |
XX |
XX |
XXX |
注意
アスタリスク (*) は、SharePoint Server 2010 で導入された新しいサービスを示します。
SharePoint Foundation Service コンテンツ共同作業で使用する中核的な SharePoint サービス。大規模な SharePoint Server 展開では、予想されるトラフィック負荷に基づいて冗長な Web サーバーを割り当て、コンテンツ データベースにサービスを提供する SQL Server ベースのコンピューターを適切に規模設定し、ファームの規模に基づいて適切に記憶域を割り当てることを推奨します。
サーバーの全体管理サービス 管理サービスです。このサービスは、比較的、小さな容量要件しか必要としません。冗長性を確保できるように、複数のファーム サーバーでこのサービスを有効にすることを推奨します。
ログ サービス 監視の目的で、利用状況および正常性の指標を記録するサービス。これは書き込みの負担をかけるサービスで、指標の数と記録する頻度によって、比較的、大量のディスク領域を必要とすることがあります。大規模な SharePoint Server 2010 展開では、コンテンツ データベースとは別の SQL Server ベースのコンピューターに、利用状況データベースを分離することを推奨します。
SharePoint Search Service アプリケーション インデックス作成とクエリ機能を提供する共有サービス アプリケーション。このサービスは、非常に大規模なコンテンツ展開でサービスを提供するように規模調整されることがあり、通常、比較的リソースに負担をかけます。エンタープライズ検索が非常に重要な大規模な SharePoint Server 展開では、クロールとクエリに許容範囲内のスループットを保証できるように、検索サービス アプリケーションをホストし、専用のデータベース リソースを持つ個別の "サービス ファーム" を使用すること、特定の検索機能 (クロールまたはクエリ) にサービスを提供する複数のアプリケーション サーバーとコンテンツ ファーム専用のターゲット Web サーバーを使用することを推奨します。また、FAST Service アプリケーションを Search Service アプリケーションとして有効にすることができます。FAST Search Server 2010 for SharePoint でコンテンツをインデックス作成する目的で、1 つまたは複数の FAST Search コネクタを作成します。さらに、FAST Search コネクタによってクロールされるコンテンツにクエリを実行する目的で、別の FAST Search クエリ (SSA) を作成します。
Word Viewing Service アプリケーション このサービスを有効にすると、ブラウザーから、直接、Word ドキュメントを表示できます。このサービスは、SharePoint Server 2010 に加えて Office Web Apps をインストールしたときに追加されます。このサービスでは、ブラウザーで表示できるよう、アプリケーション サーバーが元のファイルを用意する必要があります。大規模な SharePoint Server 展開では、冗長性とスループットを確保できるよう、複数のアプリケーション サーバーにサービスをスケール アウトすることを推奨します。
注意
SharePoint Server 2010 ファームに Office Web Apps をインストールしたとき、Word と OneNote でのブラウザー編集は有効です。しかし、この機能はファーム Web サーバーで実行され、サービス アプリケーションを使用しません。
PowerPoint Service アプリケーション このサービスは、PowerPoint ファイルをブラウザーに表示し、ユーザーが、直接、編集できるようにします。また、ライブ PowerPoint プレゼンテーションをブロードキャストし、共有できるようにします。このサービスは、SharePoint Server 2010 に Office Web Apps をインストールしたときに追加されます。このサービスでは、ブラウザーで表示できるよう、アプリケーション サーバーが元のファイルを用意する必要があります。この機能が頻繁に使用される大規模な SharePoint Server 展開では、冗長性とスループットが許容範囲内となるように複数のアプリケーション サーバーを展開すること、また、PowerPoint ブロードキャストが頻繁に使用される場合は、より多くの Web サーバーを追加することを推奨します。
Excel Calculation Service アプリケーション このサービスは、ブラウザーに直接 Excel ワークシートを表示し、また、サーバーで Excel の計算を実行します。また、SharePoint Server 2010 に Office Web Apps をインストールしたときは、ブラウザーから、直接、ワークシートを編集することができます。この機能が頻繁に使用される大規模な SharePoint Server 展開では、許容範囲のパフォーマンスとスループットが得られるように、十分な RAM を持つアプリケーション サーバーを適切な数だけ割り当てることを推奨します。
PowerPivot for SharePoint PowerPivot が有効な Excel ワークシートを、ブラウザーで、直接、表示するサービスです。この機能が頻繁に使用される大規模な SharePoint Server 展開では、許容範囲のパフォーマンスとスループットが得られるように、十分な RAM と CPU 能力を持つアプリケーション サーバーを適切な数だけ割り当てることを推奨します。詳細については、「ハードウェアとソフトウェアの要件 (PowerPivot for SharePoint)」を参照してください。
Visio Service アプリケーション ブラウザーに、直接、動的 Visio 図を表示するサービスです。このサービスは、比較的、小規模の SQL Server データベースを必要とする、Session State Service アプリケーションに対する依存関係を持っています。Visio サービスでは、ブラウザーで表示できるよう、アプリケーション サーバーが元の Visio ファイルを用意する必要があります。この機能が頻繁に使用される大規模な SharePoint Server 展開では、許容範囲のパフォーマンスとスループットが得られるように、十分な CPU 能力と RAM を持つ複数のアプリケーション サーバーでサービスをスケール アウトすることを推奨します。
Access Service アプリケーション SharePoint Server 2010 内に Access ソリューションをホストするサービスです。この機能が頻繁に使用される大規模な SharePoint Server 展開では、許容範囲のパフォーマンスとスループットが得られるように、十分な RAM を持つ複数のアプリケーション サーバーでスケール アウトすることを推奨します。Access サービスは、その他のデータベースで同じ場所に配置できる SQL Server データベースを必要とする、SQL Reporting Services を使用します。
User Profile Service アプリケーション SharePoint Server 2010 でのソーシャル シナリオを支えて、個人用サイト、タグ付け、メモ、ディレクトリとその他のソーシャル機能でのプロファイル同期を可能にするサービスです。プロファイル サービスは、同期、プロファイル、およびソーシャル タグ付けデータベースの、比較的、リソースに負担をかける 3 つのデータベースを必要とします。このサービスは Managed Metadata Service アプリケーションに依存しています。大規模な SharePoint Server 展開では、一般的なトランザクションおよびディレクトリ同期ジョブで許容範囲内のパフォーマンスが得られるように、共有サービスファームにこのサービスを配分することを考慮し、データベース サーバー層を適切に規模設定する必要があります。
Managed Metadata Service アプリケーション 中央メタデータ ストアを支え、企業全体でコンテンツ タイプのシンジケートができるようにするサービスです。このサービスは、専用のサービス ファームでフェデレーション対象とすることができます。その他のデータベースと同じ場所に配置できるデータベースを必要とします。
Web Analytics Service アプリケーション ファームの利用状況特性の統計を収集して、保存するサービス。このサービスは、SQL Server リソースおよび記憶域について、比較的、高い需要を持っています。このサービスは、専用のサービス ファームでフェデレーション対象とすることができます。大規模な SharePoint Server 展開では、異なるデータベース サーバーでホストすることにより、その他の非常に重要、またはリソースに負担をかけるデータベースから Web Analytics データベースを分離することを推奨します。
Business Connection Service アプリケーション SharePoint Server 2010 で、組織のさまざまな基幹業務アプリケーションの統合を可能にするサービス。このサービスでは、アプリケーション サービスが外部のリソースへのデータ接続を管理する必要があります。この機能が頻繁に使用される大規模な SharePoint Server 展開では、許容範囲のパフォーマンスが得られるように、十分な RAM を持つアプリケーション サーバーを適切な数だけ割り当てることを推奨します。
InfoPath Forms Service SharePoint Server 2010 でのブラウザーベースのフォームと、フォーム作成の目的での InfoPath クライアント アプリケーションとの統合を可能にするサービス。このサービスは、アプリケーション サーバーを必要とし、比較的、小規模のデータベースを必要とする Session State Service アプリケーションに対する依存関係を持っています。このサービスはその他のサービスと同じ場所に配置することができ、比較的、小さい容量要件を持っていますが、この機能の使用頻度によっては要件は大きくなることがあります。
Word Automation Service アプリケーション .doc のような特定の形式から, .docx または .pdf のような別の形式に Word ファイルを変換できるようにするサービス。このサービスはアプリケーション サーバーを必要とします。この機能が頻繁に使用される大規模な SharePoint Server 展開では、許容範囲の変換スループットが得られるように、十分な CPU リソースを持つ複数のアプリケーション サーバーでサービスをスケール アウトすることを推奨します。また、このサービスは、変換ジョブのキューを管理する、比較的、小規模のデータベースを必要とします。
PerformancePoint Service アプリケーション SharePoint Server 2010 の PerformancePoint BI 機能を有効にして、分析的な視覚化を作成できるようにするサービス。このサービスはアプリケーション サーバーとデータベースを必要とします。この機能が頻繁に使用される大規模な SharePoint Server 展開では、許容範囲のパフォーマンスとスループットが得られるように、アプリケーション サーバーに十分な RAM を割り当てることを推奨します。
Project Service アプリケーション SharePoint Server 2010 に加えて、すべての Microsoft Project Server 2010 計画および進捗管理機能を有効にするサービス。このサービスは、アプリケーション サーバーと、比較的、リソースの負担に耐えられるデータベースを必要とします。この機能が頻繁に使用される大規模な SharePoint Server 展開では、Project Server データベースに専用のデータベース サーバーを割り当てる必要があり、Project Server 管理ソリューション専用の SharePoint Server ファームも検討する必要があります。
Timer Service ファームの異なるサーバーで、さまざまにスケジュール設定されたタスクを実行するプロセス。システムではさまざまなタイマー ジョブが実行されます。いくつかはすべてのファーム サーバーで実行され、いくつかはサーバーの役割に基づいて特定のサーバーのみで実行されます。これらのタイマー ジョブの一部は、リソースに負担をかけます。そのアクティビティと操作対象のコンテンツの量に基づいて、ローカル サーバーとデータベース サーバーの両方に負荷をかけることがあります。タイマー ジョブがエンド ユーザーの待機時間に影響を与えることがある大規模な SharePoint Server 展開では、よりリソースに負担をかけるジョブの実行を分離する目的で、専用のサーバーを割り当てることを推奨します。
ワークフロー SharePoint Server 2010 に統合されたワークフローを有効にして、Web サーバーでワークフローを実行する機能。リソース利用率は、ワークフローの複雑さと処理するイベントの合計数に依存します。この機能が頻繁に使用される大規模な SharePoint Server 展開では、エンド ユーザートラフィックが影響を受けないように、また、ワークフロー操作が遅れないように、Web サーバーを追加するか、ワークフロー タイマー サービスのみを処理するサーバーを分離することを検討する必要があります。
サンドボックス ソリューション 専用のファーム リソースにカスタム コードを隔離するサービス。この機能が頻繁に使用される大規模な SharePoint Server 展開では、カスタム コードがサーバーのパフォーマンスに影響し始めた場合に、追加の専用 Web サーバーを割り当てること検討する必要があります。
SharePoint Server 2010 での新しいクライアント アプリケーションの相互作用
このセクションでは、SharePoint Server 2010 がサポートするいくつかの新しいクライアント/サーバー間の相互作用と、その容量計画への影響について説明します。
以下の表は、これらの新しい機能がシステムにかける一般的な負荷について、単純化された高レベルな説明を示します。
X - システムのリソースに、最小限、またはごく限定的な負荷をかけることを示します。
XX - システムのリソースに、中程度の負荷をかけることを示します。
XXX - システムのリソースに、高い負荷をかけることを示します。
| クライアント | トラフィック | ペイロード |
|---|---|---|
Office Web Apps |
XXX |
XX |
PowerPoint ブロードキャスト |
XXX |
X |
Word および PowerPoint 2010 クライアント アプリケーション |
XX |
X |
OneNote クライアント アプリケーション |
XXX |
XXX |
Outlook Social Connector |
XX |
XX |
SharePoint Workspace |
XXX |
XX |
Office Web Apps Word、PowerPoint、Excel、および OneNote ファイルの Web 表示と編集は、各トラフィック特性がわずかに異なる、ブラウザー要求のサブセットです。この種の相互作用は、共同編集のような機能を可能にするのに必要な、比較的、高負荷のトラフィックを発生させます。これらの機能が有効にされた大規模な SharePoint Server 展開では、Web サーバーに追加の負荷がかかることを予期する必要があります。
PowerPoint ブロードキャスト Web ブラウザーでのライブ PowerPoint プレゼンテーションの表示に関連する一連の要求は、ブラウザー要求のもう 1 つのサブセットです。ライブ PowerPoint ブロードキャスト セッション中に、参加しているクライアントはサービスから変更を要求します。この機能が頻繁に使用される大規模な SharePoint Server 展開では、Web サーバーに追加の負荷がかかることを予期する必要があります。
Word および PowerPoint 2010 クライアント アプリケーション Word および PowerPoint 2013 クライアントは、SharePoint Server ファームを活用する新機能を持っています。1 つの例は、ドキュメント共同編集で、共同編集セッションに参加しているすべてのクライアント アプリケーションは、サーバーと頻繁に更新箇所のアップロードとダウンロードを繰り返します。この機能が頻繁に使用される大規模な SharePoint Server 展開では、Web サーバーに追加の負荷がかかることを予期する必要があります。
OneNote 2010 クライアント アプリケーション OneNote 2013 クライアントは、以前の OneNote バージョンと同様の方法で SharePoint Server ファームと相互作用し、SharePoint Server 2010 を使用して OneNote ノートブックの共有と共同編集ができるようにします。クライアントが実行しており、活発に使用されていないときでも、このシナリオは SharePoint Server 2010 に負荷を発生させます。この機能が頻繁に使用される大規模な SharePoint Server 展開では、Web サーバーに追加の負荷がかかることを予期する必要があります。
Outlook 2010 クライアント アプリケーション Outlook 2013 には、SharePoint Server ファームを活用する新機能、Outlook Social Connector があります (このコンポーネントは以前のバージョンの Outlook に追加することもできます)。この機能は、SharePoint Server ファームから要求されたソーシャル アクティビティを、直接、電子メールで表示できるようにします。この機能が有効にされた大規模な SharePoint Server 展開では、Web サーバーに追加の負荷がかかることを予期する必要があります。
SharePoint Workspace SharePoint Workspace 2013 クライアントは SharePoint Server ファームを活用する新機能を持っており、クライアントと Web サイト、リスト、およびドキュメント ライブラリを同期してオフラインで使用できるようにします。SharePoint Workspace 2013 は、クライアントが実行されたとき、活発に使用されているかにかかわらず、添付されたサーバー オブジェクトを定期的に同期させます。この機能が頻繁に使用される大規模な SharePoint Server 展開では、Web サーバーに追加の負荷がかかることを予期する必要があります。
SharePoint Server 2010 の展開での主な差別化要因
各 SharePoint Server 2010 展開では、一意的で、その他のファームとは異なる、一連の重要な特性を持っています。これらの主な差別化要因は、以下の 4 つの主なカテゴリで示されます。
仕様 ファームのハードウェアと、ファーム トポロジおよび構成を示します。
負荷 ユーザーの数と利用状況特性を含む、ファームの需要を示します。
データセット コンテンツのサイズおよび配分を示します。
正常性とパフォーマンス 待機時間およびスループットの目標に関して、ファームのパフォーマンスを示します。
仕様
ハードウェア
ハードウェアとは、プロセッサ、メモリ、およびハード ディスクのような、コンピューターの物理的なリソースです。ハードウェアには、NIC (ネットワーク インターフェイス カード)、ケーブル、スイッチ、ルーター、およびハードウェア ロード バランサーのような物理的なネットワーク コンポーネントも含まれます。パフォーマンスと容量に関する多くの問題は、適切なハードウェアを使用することで解決できます。逆に、サーバーでのメモリ不足のような、ハードウェア リソースの 1 つの誤用が、ファーム全体のパフォーマンスに影響することがあります。
トポロジ
トポロジとは、ファームのハードウェアおよびコンポーネントの配分と相互関係のことです。次の 2 種類のトポロジがあります。
論理トポロジ ファームのサービスおよび機能のような、ソフトウェア コンポーネントのマップ。
物理トポロジ サーバーおよび物理リソースのマップ。
一般的には、ユーザーの数と利用状況特性が、ファームの物理トポロジを決定し、特定の機能で予期される負荷をサポートする必要性のようなビジネス要件が、論理トポロジを決定します。
構成
構成とは、ソフトウェア設定とパラメーターが設定される方法を示す用語構成です。また、構成とは、キャッシュ、RBS、構成可能な制限が設定される方法や、特定の要件を満たすように変更または設定されることがあるソフトウェア環境のあらゆる部分を示します。
負荷
負荷は、ユーザー ベース、同時実行、使用されている機能、ファームに接続するために使用されるユーザー エージェントまたはクライアント アプリケーションを含む、ファームの重要な運用上の特性を定義します。
各 SharePoint Server 機能は、ファームのリソースで独自の関連するコストを持っています。よりコストを必要とする機能が頻繁に利用されると、パフォーマンスとシステムの正常性に大きく影響を与えることがあります。予想された需要と利用状況特性を把握することで、実装を適切に規模設定し、常に不安定な条件でシステムを実行するリスクを減らせます。
ユーザー ベース
SharePoint Server ベースのアプリケーションのユーザー ベースとは、ユーザーの合計数と、ユーザーが地理的にどのように分散しているかを組み合わせた情報です。また、ユーザー ベースの合計内で、その他のグループよりも頻繁に、特定の機能またはサービスを使用するユーザーのサブグループがある場合があります。ユーザーの同時実行とは、特定の時間でのシステムを活発に使用しているユーザーの合計の割合と定義されます。ユーザー ベースを定義する指標には、一意のユーザーの合計数と同時ユーザーの数が含まれます。
利用状況特性
ファームのパフォーマンスはシステムを操作しているユーザーの数だけではなく、利用状況特性によって影響を受けることがあります。同じユーザー数の 2 つの組織は、ユーザーがファーム リソースにアクセスする頻度と、リソースに負担をかける機能およびサービスがファームで有効にされているかどうかによって、大きく異なる要件を持つことがあります。利用状況特性を示す指標には、一意的な操作の頻度、全体的な処理の混合 (読み取りおよび書き込み操作と、管理操作の比率)、利用状況パターン、およびファームで有効にされた新機能に対する負荷 (たとえば、個人用サイト、検索、ワークフロー、および Office Web Apps) が含まれます。
データセット
システムに保存されたコンテンツのボリュームと、それが保存されたアーキテクチャの特性は、システムの全体的な正常性とパフォーマンスに重大な影響を及ぼすことがあります。データのサイズ、アクセス頻度、および配分を把握することで、システムの記憶域を適切に規模設定でき、ファーム サービスへのユーザーの操作の速度を遅くし、エンド ユーザー エクスペリエンスに影響を与えてしまうボトルネックを防ぐことができます。
SharePoint Server ベースのソリューションの記憶域アーキテクチャを適切に予測して設計するには、システムに保存されることになるデータのボリュームと、さまざまなデータ ソースからデータを要求るユーザーの数を把握する必要があります。コンテンツのボリュームは、その他の機能のパフォーマンスと、ネットワーク待機時間と利用可能な帯域幅に影響する可能性があることから、ディスク容量を規模設定する際の重要な要素となります。データセットを定義する指標には、コンテンツの合計サイズ、ドキュメントの合計数、サイト コレクションの合計数、およびサイト コレクションの平均および最大サイズが含まれます。
正常性とパフォーマンス
SharePoint Server ファームの正常性とは、基本的には、システムの信頼性、安定性、およびパフォーマンスを反映する単純化された計測値またはスコアです。ファームが目標に対して、どの程度、適切に機能しているかは、最初の 3 つの差別化要因に依存しています。正常性およびパフォーマンスのスコアは、一連の指標の集約により、追跡管理し、記述することができます。詳細については、「SharePoint Server 2010 の監視と保守」を参照してください。これらの指標には、システムの稼働時間、エンド ユーザー認知待機時間、ページ障害の割合、およびリソース利用率指標 (CPU、RAM) が含まれます。
ハードウェア、トポロジ、構成、負荷、またはデータセットへの大きな変更は、システムの信頼性と反応性を大きく変えることがあります。正常性スコアは、一定期間にわたってパフォーマンスを追跡管理して、運用条件の変化またはシステム変更がファームの信頼性にどのように影響するかを評価する目的で使用することができます。
基準となるアーキテクチャ
SharePoint Server 2010 は複雑かつ高機能な製品であることから、1 つのアーキテクチャ ソリューションだけであらゆる状態に対応できるわけではありません。SharePoint Server 展開は 1 つ 1 つ固有で、その利用状況およびデータの特性によって定義されます。組織の需要を最適に満たす、適切に規模設定されたソリューションをカスタマイズするには、どの組織も徹底的な容量管理過程を実行し、SharePoint Server 2010 システムの柔軟性を効果的に活用する必要があります。
基準となるアーキテクチャの概念は、SharePoint Server 展開のさまざまな主要カテゴリを示して説明することを意図しており、アーキテクトが自身のソリューションを設計する際にそのまま使用するものではありません。このセクションでは、SharePoint Server 展開が一般的に規模調整される方向性を示すことに重点を置いています。
ここで示すアーキテクチャは、これらの汎用カテゴリ間の一般的な差別化要因を把握し、一般的なコスト要因と労力の規模で区別する際に役立つ方法として提供されます。
単一サーバー展開
単一サーバー展開のアーキテクチャは、SharePoint Server 2010 と、サポートされるバージョンの SQL Server を実行中の 1 台のサーバーから構成されます。このアーキテクチャは、評価目的、開発者向け、または少数のユーザーしかおらずミッション クリティカルでない、独立した部門での実装に適しています。しかし、運用環境で使用することは推奨されません。
.gif "単一サーバー展開モデル")
小規模ファーム展開
小規模ファーム展開は、単一のデータベース サーバーまたはクラスターと、1 台または 2 台の SharePoint Server 2010 ベースのコンピューターから構成されます。このアーキテクチャの主な特性は、限定的な冗長性およびフェールオーバーを持ち、最小限の SharePoint Server の機能が有効にされていることです。
小規模ファームは、最小限のサービス アプリケーションが有効にされた、比較的、小規模のユーザー ベース、比較的、低い利用状況負荷 (毎分数回の要求か毎秒数回の要求)、比較的、小規模のボリュームのデータ (10 ギガバイト程度)のような限定的な展開だけで役立ちます。
.gif "小規模ファーム展開モデル")
中規模ファーム展開
このアーキテクチャでは、専用の Web サーバー、専用のアプリケーション サーバー、および 1 つまたは複数のデータベース サーバーあるいはクラスターから構成される、3 層のトポロジを持っています。アプリケーション サーバー層からフロントエンド サーバー層を分離することで、サービス隔離の柔軟性を増し、システム全体の負荷の分散に役立ちます。
これは最も一般的なアーキテクチャで、多様なサービス トポロジとファーム規模が含まれます。中規模ファーム展開は、以下の条件を持つ環境へのサービス提供に役立ちます。
複数のサーバー間に配分された、いくつかのサービス アプリケーション。一般的な機能としては、Office Web Apps Service、User Profile Service、Managed Metadata Service、および Excel Calculation Service が含まれます。
数万ユーザーのユーザー ベースと、1 秒あたり 10 から 50 回の要求の負荷。
1 または 2 テラバイトのデータ ストア。
.gif "キャパシティ - 中規模ファーム展開モデル")
大規模ファーム展開
大規模ファーム展開では、単一ファームの層をさらにスケール アウトする、複数のファームにわたるサービスおよびソリューションの分類があります。いくつかの SharePoint Server サービスが、複数の使用側ファームからの要求に応える専用のサービス ファームで展開されることがあります。これらの大規模なアーキテクチャでは、一般的に、ローカル (非共有) サービスの各利用状況特性に基づいて、Web サーバー、複数のアプリケーション サーバーがあります。また、コンテンツのサイズと、ファームで有効なアプリケーション サービス データベースに基づいて、複数の SQL Server ベースのサーバーまたは SQL Server クラスターがあります。大規模ファーム アーキテクチャは、以下の条件を持つ展開にサービス提供することが予測されます。
一般的には、User Profile Service、Search、Managed Metadata Service、および Web Analytics のような、専用のサービス ファームでフェデレーション対象となり、使用されるいくつかのサービス アプリケーション。
ほとんどのその他のサービス アプリケーションはローカルで有効にされます。
数十万ユーザーの範囲のユーザー ベース。
1 秒あたりの要求が数百回の範囲の利用負荷。
10 テラバイト以上の範囲のデータセット。
.gif "キャパシティ - 大規模ファーム展開モデル")
See Also
Concepts
SharePoint Server 2010 の容量計画
SharePoint Server 2010 のパフォーマンス テスト
SharePoint Server 2010 の監視と保守
SharePoint Server 2010 容量管理ソフトウェアの境界と制限
パフォーマンスと容量のテスト結果と推奨事項 (SharePoint Server 2010)
パフォーマンスと容量に関する技術的なケース スタディ (SharePoint Server 2010)
ハードウェア要件およびソフトウェア要件 (SharePoint Server 2010)