次の方法で共有

SharePoint Server 2013 の容量計画

  • [アーティクル]

適用対象:yes-img-13 2013no-img-162016 no-img-192019 no-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

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

この記事を読む前に、「Capacity management and sizing overview for SharePoint Server 2013」を読む必要があります。

重要

この記事の一部の情報と値は、テスト結果と SharePoint 2010 製品 に関連するその他の情報に基づくもので、SharePoint Server 2013 での最終的な値を示すものではありません。

この記事では、環境に合わせた効率的な容量管理を実現するために実行すべき手順について説明します。 各ステップには、実行を成功させるために特定の情報が必要であり、後続の手順で使用する成果物のセットがあります。 手順ごとの要件と成果物を表にまとめました。

ステップ 1: モデル化

SharePoint Server 2013 ベースの環境をモデル化するには、まず、既存のソリューションを分析し、セットアップを計画しているデプロイの予想される需要とターゲットを見積もります。 まずは、ユーザー基盤、データ要件、および遅延とスループットの目標を収集して、展開する SharePoint Server 2013 の機能を文書化します。 このセクションは、収集すべきデータ、その方法、および以降の手順での用途を理解するために使用してください。

予想されるワークロードとデータセットを理解する

SharePoint Server 2013 実装を正しくサイジングするためには、ソリューションが処理を期待されている需要特性を調査して理解する必要があります。 需要を理解するには、ユーザー数や最も頻繁に使用される操作などのワークロード特性と、コンテンツ サイズやコンテンツ配布などのデータセット特性の両方を記述できる必要があります。

このセクションは、収集すべき特定の測定基準およびパラメーターとそれらを収集可能なメカニズムの理解に役立ちます。

ワークロード

ワークロードは、システムが維持する必要のある需要、ユーザー基盤、および使用状況特性を意味します。 下の表に、ワークロードの決定に役立つ主な測定基準を示します。 この表は、これらの測定基準を収集して記録するために使用できます。

ワークロード特性 値
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 秒間に処理された要求数で表現されるサーバー ファーム上の需要を説明するためによく使用される指標ですが、要求の種類や規模は区別されません。 組織のユーザー ベースに応じ、組織固有の使用状況特性に応じて、異なるペースでシステム負荷が生成されます。 詳細については、「 用語集」を参照してください。

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

  • 1 日あたりのユーザー総数 - ユーザー総数は、システムが処理する必要のある全体負荷のもう 1 つの重要な指標です。 この測定値は、24 時間の一意のユーザーの実際の数であり、organizationの従業員の総数ではありません。

    注:

    1 日あたりのユーザー総数は、ファーム上の負荷の潜在的な増加を示すことができます。 たとえば、潜在的ユーザーとして 10 万人の従業員がいて、1 日あたりのユーザー数が 1 万 5,000 人の場合は、時間とともにユーザー導入が増えるため、負荷が大幅に増加する可能性があります。

  • ワークロードの分散 - ファームと対話しているクライアントのアプリケーションに基づいて要求の分散を理解すると、SharePoint Server 2013 に移行した後の予想される傾向と負荷の変化を予測するのに役立ちます。 ユーザーが Office 2013 などの最新のクライアント バージョンに移行し、新しい機能の使用を開始すると、新しい読み込みパターン、RPS、および合計要求の増加が予想されます。 クライアントごとに、1 日の時間枠で使用する個別のユーザーの数と、クライアントまたは機能がサーバーで生成する要求の合計数を記述できます。

    たとえば、下のチャートは、標準的なソーシャル ソリューションを提供している社内の Microsoft 環境のスナップショットを示しています。 この例では、ほとんどの負荷が検索クローラーと一般的なエンド ユーザー Web 閲覧によって生成されることがわかります。 また、Outlook ソーシャル コネクタ機能 (要求の 6.2%) によって大幅な負荷が発生していることも確認できます。

    日常の要求負荷の一般的な分布

実稼働ワークロードの見積もり

ファームで維持できるようにしなければならない必要なスループットの見積もりでは、ファーム内で使用されるさまざまなトランザクションを予測することから始めます。 システムが提供する最も頻繁に使用されるトランザクションの分析に焦点を当て、使用される頻度とユーザーの数を把握します。 この理解は、ファームが運用前テストでこのような負荷を維持できるかどうかを後で検証するときに役立ちます。

下の図は、システム上のワークロードと負荷の関係を示しています。

キャパシティ - ワークロードの図

予想ワークロードを見積もるために、以下の情報を収集します。

  • ユーザーの操作を識別します。 以下に例を示します。

    • Web ページが参照されます。
    • ファイルのダウンロードとアップロード。
    • Office Web アプリケーションは、ブラウザーで表示および編集を行います。
    • 共同編集の相互作用。
    • SharePoint ワークスペース サイトの同期。
    • Outlook Social Connections。
    • RSS 同期 (Outlook やその他の閲覧者)。
    • PowerPointブロードキャスト。
    • OneNote 共有ノートブック。
    • Excel Service 共有ブック。
    • サービス共有アプリケーションにアクセスする

    詳細については、「 サービスと機能」を参照してください。 デプロイに固有の相互作用の特定に焦点を当てます。 このような負荷の予想される影響を認識します。 たとえば、InfoPath Forms、Excel サービス計算、および同様の専用ソリューションを大幅に使用します。

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

  • 次の項目を見積もる:

    • 各機能を利用することが予想される 1 日あたりのユーザーの合計数。
    • 推定同時実行ユーザーと 1 秒あたりの高レベル要求を派生させます。

    いくつかの前提を立てることになります。 以下に例を示します。

    • コンカレンシーを提示します。
    • 機能間で異なる同時ユーザーあたりの RPS の係数

    見積もりについては、このセクションの前半のワークロード テーブルを使用してください。 平均スループットではなく、ピーク時に焦点を当てることが重要です。 ピーク アクティビティの計画では、SharePoint Server 2013 ベースのソリューションのサイズを適切に設定できます。

既存の Office SharePoint Server 2007 ソリューションがある場合は、IIS ログ ファイルをマイニングするか、他の Web 監視ツールを参照して、既存のソリューションから予想される動作のいくつかを理解する必要があります。 それ以外の場合は、以下のセクションの手順を参照してください。 既存のソリューションから移行していない場合は、大まかな見積もりを使用して表に記入する必要があります。 後の手順では、前提条件を検証し、システムを調整する必要があります。

SharePoint Server 2013 IIS ログの分析

既存の SharePoint Server 2013 展開に関する主要なメトリックを検出するには、ULS ログと IIS ログからデータを抽出する必要があります。 以下に例を示します。

  • アクティブなユーザーの数。
  • システムを使用している頻度。
  • どのような種類の要求が入ってくるか。
  • 要求の発信元のクライアントの種類。

このデータを見つける最も簡単な方法の 1 つは、Microsoft から無料でダウンロードできる強力なツールである Log Parser を使用することです。 ログ パーサーは、すべての IIS 形式を含む多くのテキスト形式とバイナリ形式に対して読み取りと書き込みを行うことができます。

ログ パーサー 2.2 は (https://www.microsoft.com/downloads/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07) からダウンロードできます。

データセット

データセットは、システムに保存されたコンテンツの量とデータ ストア内でのその配分方法を示します。 下の表に、データセットの決定に役立つ主な測定基準を示します。 この表は、収集した測定基準を記録するために使用できます。

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

  • コンテンツ サイズ - SharePoint Server 2013 システムで保存するコンテンツのサイズを理解することは、システム ストレージを計画して設計するためだけでなく、そのコンテンツをクロールして索引付けする検索ソリューションを正確にサイジングするためにも重要です。 コンテンツ サイズは全ディスク領域で表現されます。 既存のデプロイからコンテンツを移行する場合は、移動するコンテンツの合計サイズを簡単に特定できます。 計画中は、時間に応じて成長の余地を残す必要があります。

  • ドキュメントの合計数 - データ コーパスサイズ以外に、アイテムの総数を追跡することが重要です。 100 GB のデータを 2 GB ずつの 50 ファイルに分けるのと、1 KB ずつの 100,000 ファイルに分けるのとでは、システムの反応が異なります。 大規模なデプロイでは、1 つのアイテム、ドキュメント、またはドキュメントの領域に対する負荷が少ないほど、パフォーマンスが向上します。 多数のサイトやサイト コレクションに複数の小さなファイルのような広く配布されたコンテンツは、大きなファイルを含む 1 つの大きなドキュメント ライブラリよりも簡単に提供できます。

  • サイト コレクションの最大サイズ - SharePoint Server 2013 に格納するコンテンツの最大の単位を特定することが重要です。通常は、コンテンツの単位を分割できない組織のニーズです。 すべてのサイト コレクションの平均サイズと推定されるサイト コレクションの合計数は、お好みのデータ アーキテクチャを識別するのに役立つその他のインジケーターです。

  • サービス アプリケーションのデータ特性 - コンテンツ ストアのストレージ ニーズを分析するだけでなく、次のような他の SharePoint Server 2013 ストアのサイズを分析して見積もる必要があります。

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

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

  • タグ、同僚、アクティビティの予想数に基づくソーシャル データベースの合計サイズ

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

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

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

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

ステップ 1: モデル化の成果物の 1 つは組織のニーズに最適なパフォーマンスと信頼性の目標の正確な把握です。 適切に設計された SharePoint Server 2013 ソリューションでは、サブ秒サーバーの応答性を備えた "4 つのナイン" (99.99%) のアップタイムを実現できる必要があります。

ファームのパフォーマンスと信頼性を表現するための指標には以下が含まれます。

  • サーバーの可用性: システムの全体的なアップタイムの割合で説明します。 予定外のダウンタイムを追跡して、設定した組織の目標と全体の可用性を照らし合わせる必要があります。 ターゲットは一般的に 9 の数で記述されます (つまり、99%、99.9%、99.99%)

  • サーバーの応答性: ファームが要求を処理するのにかかる時間は、ファームの正常性を追跡するための適切なインジケーターです。 このインジケーターは、 サーバー側の待機時間という名前です。 Tt の一般的な使用は、1 日の要求の平均または中央値 (50 パーセンタイル) の待機時間です。 ターゲットは、通常、秒または秒の分数で記述されます。 target が 2 秒未満でページを提供する場合、サーバー側の目標は 1 秒未満にする必要があります。 このパフォーマンスの向上により、ページがクライアントに到達し、ブラウザーでレンダリングされる時間が得られます。 また、サーバーの応答時間が長いほど、通常は異常なファームを示します。 ほとんどの要求に対してサーバーに 1 秒以上費やした場合、RPS が追いつくことはめったにありません。

  • サーバーのスパイキネス: 追跡する価値があるもう 1 つの優れたサーバー側待機時間インジケーターは、すべての要求の中で最も遅い 5% の動作です。 要求が遅くなるのは、通常、負荷が高い場合にシステムにヒットする要求、またはより一般的な要求であり、ユーザーがシステムとやり取りしている間に発生するアクティビティの頻度が低くなることによって影響を受けます。正常なシステムは、制御下にある要求が最も遅いシステムです。 ここでのターゲットはサーバーの応答性に似ていますが、サーバーのスパイキネスで 2 秒未満の応答を実現するには、負荷の急増を処理するために、多数の予備リソースを使用してシステムを構築する必要があります。

  • システム リソース使用率: システムの正常性を追跡するために使用されるその他の一般的なインジケーターは、ファーム トポロジ内の各サーバーの正常性を示すシステム カウンターのコレクションです。 追跡する最も頻繁に使用されるインジケーターは、CPU 使用率と使用可能なメモリの割合です。ただし、異常なシステムを識別するのに役立つカウンターがいくつかあります。詳細については、「 手順 5: 監視と保守」を参照してください。

ステップ 2: 設計

提供する必要があるソリューションに関するいくつかの事実または見積もりの収集が完了したら、予想される需要を維持できると予測する提案されたアーキテクチャを設計する次の手順を開始する準備ができました。

このステップが終わるまでに、物理トポロジの設計と論理トポロジのレイアウトが完成しているはずで、発注に進むことができるはずです。

特定の負荷を処理するために、ハードウェア仕様とレイアウトするマシンの数が密接に関連しており、デプロイを選択できるソリューションがいくつかあります。 一般的に、小規模な一連の強力なマシン (スケールアップ) または大規模な一連の小規模なマシン (スケールアウト) を使用します。各ソリューションには、容量、冗長性、電源、コスト、スペース、その他の考慮事項に関する利点と欠点があります。

このステップに着手する前に、アーキテクチャとトポロジを決定することをお勧めします。 ファームごとに異なるファームと異なるサービスをレイアウトする方法を定義し、設計内の個々のサーバーごとにハードウェア仕様を選択します。 また、このプロセスを実行するには、展開する必要があるハードウェア仕様を特定し (多くの組織が特定の企業標準に制約されています)、アーキテクチャとトポロジを定義します。

下の表は、設計パラメーターを記録するために使用します。 含まれるデータはサンプル データであり、ファームのサイズ設定には使用しません。 このテーブルを独自のデータに使用する方法を示すことを目的としています。

役割 種類 (標準または仮想) マシンの台数 プロセッサ RAM 必要な IOPS ディスク サイズ (OS + ログ) データ ドライブ
Web サーバー 仮想 4 4 コア 8 N/A 400 GB N/A
コンテンツ データベース サーバー 標準 1 クラスター 4 クアッド コア 2.33 (GHz) 48 2k 400 GB 300 GB の 20 ディスク
@ 15K RPM
アプリケーション サーバー 仮想 4 4 コア 16 N/A 400 GB N/A
検索クロール ターゲット Web サーバー 仮想 1 4 コア 8 N/A 400 GB N/A
検索クエリ サーバー 標準 2 2 クアッド コア 2.33 (GHz) 32 N/A 400 GB 500 GB
検索クロール サーバー 標準 2 2 クアッド コア 2.33 (GHz) 16 400 400 GB N/A
検索クロール データベース サーバー 標準 1 クラスター 4 クアッド コア 2.33 (GHz) 48 4k (読み取り専用) 100 GB 150 GB @ 15K RPM の 16 個のディスク
検索プロパティ ストア データベース + 管理データベース サーバー 標準 1 クラスター 4 クアッド コア 2.33 (GHz) 48 2k (書き込み専用) 100 GB 150 GB @ 15K RPM の 16 個のディスク

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

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

SharePoint Server 2013 を展開する場合は、さまざまなトポロジから選択してソリューションを実装できます。1 つのサーバーを展開したり、クラスター化されたデータベース サーバーまたはミラー化されたデータベース サーバーを備えた SharePoint Server 2013 ファームに多数のサーバーをスケールアウトしたり、さまざまなサービス用の控えめなアプリケーション サーバーを使用したりできます。 後で、容量、可用性、冗長性のニーズに基づいて、各ロールの要件に基づいてハードウェア構成を選択します。

さまざまな参照アーキテクチャを調査することから始めて、ファーム構造を明確にし、ソリューションを複数のファームに分散させるのか、検索などの一部のサービスを 1 つの専用ファームに集めるのかを決定します。 詳細については、「 リファレンス アーキテクチャ」を参照してください。

SharePoint Server 2010 テクニカル ケース スタディ

SharePoint Server 2013 の容量管理ガイダンスには、既存の SharePoint Server 2013 ベースの運用環境の詳細な説明を示す、既存の運用環境に関する多くの技術的なケース スタディが含まれています。 SharePoint Server 2013 に固有の技術的なケース スタディは、利用可能になると公開されます。既存の SharePoint Server 2010 ケース スタディは、特定の目的で SharePoint Server 2013 ベースの環境を設計する方法のリファレンスとして役立ちます。

これらのケース スタディは、SharePoint Server 2013 ソリューションのアーキテクチャを設計するときに参考として使用できます。特に、設計するソリューションの需要とターゲットと同様に、これらの展開固有の主要な差別化要因の説明が見つかる場合です。

これらのドキュメントには、それぞれのケース スタディに関する以下の情報が記載されています。

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

  • ユーザー基盤と使用状況特性を含む ワークロード

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

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

詳細については、「パフォーマンスと容量に関する技術的なケース スタディ (SharePoint Server 2010)」ページから関連ドキュメントをダウンロードしてください。

ハードウェアを選択する

ファーム内のマシンの正しい仕様を選択することは、展開の適切な信頼性とパフォーマンスを保証するために不可欠なステップであり、覚えておくべき重要な概念の 1 つはピーク負荷とピーク時間を計画すべきということです。つまり、ファームが平均的な負荷状態で動作している場合は、予想最大需要に対処できるだけの十分なリソースを確保しながら、遅延とスループットの目標を達成する必要があります。

サーバーの容量およびパフォーマンスに関するコアなハードウェア機能は、システムの処理能力、ディスク パフォーマンス、ネットワーク容量、およびメモリ機能という 4 つの主要カテゴリに左右されます。

加えて、仮想マシンの使用も考慮すべきです。 SharePoint Server 2013 ファームは、仮想マシンを使用して展開できます。 パフォーマンス上の利点を追加するための仮想化は見つかりませんでしたが、管理容易性の利点を提供します。 SQL Server ベースのコンピューターの仮想化はお勧めしませんが、Web サーバーとアプリケーション サーバー層を仮想化することには特定の利点がある場合があります。 詳細については、「 仮想化の計画 (/previous-versions/office/sharepoint-server-2010/ff607968(v=office.14)」を参照してください。

ハードウェア要件の詳細については、「SharePoint Server 2016 のハードウェア要件およびソフトウェア要件」を参照してください。

ハードウェア選定ガイドライン

プロセッサの選択

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

SharePoint Server 2013 では、コアの増加に伴って、個々の Web サーバーがスケールアップします。 他が同じ場合は、サーバーのコアが多いほど、維持可能な負荷が増えます。 大規模な SharePoint Server 2013 展開では、複数の 4 コア Web サーバー (仮想化が可能) を割り当てるか、少数だが強力な (8/16/24 コア) Web サーバーを割り当てるかのどちらかをお勧めします。

アプリケーション サーバーのプロセッサ容量要件は、サーバーの役割と実行されているサービスによって異なります。 SharePoint Server 2013 の機能によっては、他よりも高い処理能力が必要な場合があります。 たとえば、SharePoint Search Service は、アプリケーション サーバーの処理能力に大きく依存します。

SQL Server のプロセッサ容量要件は、SQL Server ベースのコンピューターがホストしているサービス データベースによっても異なります。

メモリの選択

サーバーに必要なメモリ量は、そのサーバーの機能と役割によってさまざまです。 たとえば、検索クロール コンポーネントを実行しているサーバーは、大量のメモリを搭載していれば、ドキュメントをメモリに読み込んで処理できるため、データを短時間で処理します。 SharePoint Server 2013 のさまざまなキャッシング機能を利用する Web サーバーもより多くのメモリを必要とします。

一般に、Web サーバーのメモリ要件は、ファームで有効になっているアプリケーション プールの数と、同時に処理される要求の数によって大きく異なります。 ほとんどの運用環境の SharePoint Server 2013 展開では、各 Web サーバーに少なくとも 8 GB の RAM を割り当てることをお勧めします。分離のために複数のアプリケーション プールが設定されたトラフィックまたは展開が多いサーバーには 16 GB を推奨します。

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

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

ネットワークの選択

ユーザーに提供される利点に加えて、クライアントがネットワーク経由で高速データ アクセスを使用する場合、分散ファームはサーバー間通信に高速アクセスできる必要があります。 このことは、特に、サービスを複数のサーバーで分担したり、いくつかのサービスを別のファームに集めたりしている場合に当てはまります。 ファーム内には、Web サーバー層、アプリケーション サーバー層、データベース サーバー層の間で大量のトラフィックが存在し、大きなファイルの処理や負荷の高い特定の条件下では、ネットワークがボトルネックになる可能性があります。

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

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

ディスク管理は、単にデータに十分な領域を提供する機能ではありません。 継続的な需要と成長を評価し、ストレージ アーキテクチャによってシステムの速度が低下していないことを確認する必要があります。 今後の成長に備えて、データ要件の見積もりを超えて、各ディスクに少なくとも 30% の追加容量があることを常に確認する必要があります。 加えて、ほとんどの実稼働環境において、サーバーのストレージ需要を満たすのに十分なスループットが提供されるディスク速度 (IOps) が不可欠です。 展開内の主要なデータベースに必要なトラフィック量 (IOps) を見積もって、そのトラフィックを満たすのに十分なディスクを割り当てる必要があります。

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

Web サーバーとアプリケーション サーバーにはストレージ要件もあります。 ほとんどの実稼働環境において、OS と一時ファイル用の 200 GB 以上のディスク容量とログ用の 150 GB のディスク容量を割り当てることをお勧めします。

手順 3: パイロット、テスト、最適化

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

環境のテストが終了したら、テスト結果を分析して、ステップ 1: モデル化で設定したパフォーマンスと容量の目標を達成するために変更すべき場所を特定できます。

運用前のサブ手順を次に示します。

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

  • ステップ 1: モデル化で特定したデータセットまたはデータセットの一部でストレージを構成します。

  • ステップ 1: モデル化で特定したワークロードに相当する合成負荷をシステムに加えます。

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

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

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

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

テスト

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

  • テスト計画を作成する

  • テスト環境を構築する

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

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

SharePoint Server 2013 を運用環境に展開する前に、最初にパイロット環境を展開し、ファームを徹底的にテストして、予想されるピーク負荷の容量とパフォーマンスの目標を満たすことができることを確認することが重要です。 パイロット環境では、特に大規模なデプロイに対して合成負荷でテストした後、小規模なライブ ユーザーとライブ コンテンツによってストレスを受け取ることをお勧めします。 少数の実ユーザーを使ってパイロット環境を分析するメリットは、完全に実稼働に移行する前に、使用状況特性とコンテンツの増加に関して立てた前提を検証する機会が得られることです

最適化

ファーム ハードウェアをスケーリングしたり、トポロジを変更したりして、容量とパフォーマンスの目標を達成できない場合は、ソリューションの変更を検討する必要があります。 たとえば、初期要件がグループ作業、検索、およびソーシャル用の単一ファームに関するものだった場合は、検索などの一部のサービスを専用サービス ファームにまとめるか、より多くのファームでワークロードを分散させる必要があります。 ソーシャル専用のファームとグループ作業専用のファームを展開するという方法もあります。

ステップ 4: 展開

テストの最終ラウンドを実行し、アーキテクチャを確認したら、「 手順 1: モデル」で確立したパフォーマンスと容量の目標を達成できることを選択したら、SharePoint Server 2013 ベースの環境を運用環境にデプロイできます。

適切なロールアウト戦略は、環境と状況によって異なります。 SharePoint Server 2013 展開は本書の範囲を超えていますが、容量計画演習から提案されている活動があります。 ここで、いくつかの例を示します。

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

  • Office SharePoint Server 2007 ファームを SharePoint Server 2013 にアップグレード する:容量計画の演習では、既存の需要を満たし、SharePoint Server 2013 ファームの需要と使用量の増加に合わせてスケールアップできるファームの設計を検証する必要があります。 容量計画演習の一部には、アップグレード プロセスにかかる時間、カスタム コードを変更または置き換える必要があるかどうか、サード パーティ製ツールを更新する必要があるかどうかなどを検証するためのテスト移行が含まれている必要があります。 容量計画の最後には、検証済みの設計と、アップグレードにかかる時間と、アップグレード プロセスを実行するのに最適な方法 (インプレース アップグレード、コンテンツ データベースの新しいファームへの移行など) の計画が必要です。 インプレース アップグレードを行っている場合は、容量計画中に、追加またはアップグレードされたハードウェアが必要になることと、ダウンタイムに関する考慮事項が見つかった可能性があります。 計画演習の出力の一部は、必要なハードウェアの変更の一覧と、最初にファームにハードウェアの変更を展開するための詳細な計画である必要があります。 容量計画中に検証されたハードウェア プラットフォームが整ったら、SharePoint Server 2013 にアップグレードするプロセスを進めることができます。

  • 既存の SharePoint Server 2013 ファームのパフォーマンスの向上: 容量計画演習では、現行実装内のボトルネックの特定、そのようなボトルネックの削減または排除方法の計画、および SharePoint Server 2013 サービスのビジネス要件を満たすために改善された実装の検証が支援されたはずです。 パフォーマンスの問題は、既存のハードウェア間でのサービスの再割り当て、既存のハードウェアのアップグレード、ハードウェアの追加、サービスの追加など、さまざまな方法で解決できます。 容量計画演習中にさまざまなアプローチをテストして検証し、テスト結果に応じて展開計画を設計したはずです。

ステップ 5: 監視と維持

システムのパフォーマンスを維持するには、サーバーを監視して潜在的なボトルネックを特定する必要があります。 効率的に監視するためには、ファームの特定の部分に注意を向ける必要があるかどうかを示す需要な指標を理解し、それらの指標の解釈方法を把握しておく必要があります。 ファームのパフォーマンスが定義した目標に達していないことが判明した場合は、ハードウェア リソースの追加または削除、トポロジの変更、あるいはデータの保存方法の変更によってファームを調整できます。

初期の段階で環境を監視するために変更できる設定の一覧については、「 SharePoint Server 2013 の監視と管理 」を参照してください。これは、変更が必要かどうかを判断するのに役立ちます。 監視機能を増やすと、使用データベースに必要なディスク領域に影響を与える点に注意してください。 環境が安定し、この詳細な監視が不要になったら、以下の設定を既定の設定に戻します。

SharePoint Server 2013 Central 管理 インターフェイスに組み込まれている正常性監視ツールを使用した正常性監視とトラブルシューティングの詳細については、次を参照してください。

SharePoint Server 2016 の監視とレポート

問題の解決とトラブルシューティング

関連項目

概念

SharePoint Server 2013 のパフォーマンス テスト

SharePoint Server 2013 の監視とメンテナンス

ソフトウェアの境界と制限 (SharePoint Server 2016)

パフォーマンスと容量テストの結果および推奨事項 (SharePoint Server 2013)

その他のリソース

Capacity management and sizing overview for SharePoint Server 2013

パフォーマンスと容量に関する技術的なケース スタディ (SharePoint Server 2010)