SharePoint Server 2013 の容量計画Capacity planning for SharePoint Server 2013

適用対象:はい2013 No2016 no2019 (SharePoint Online なし)APPLIES TO: yes2013 no2016 no2019 noSharePoint Online

この記事では、SharePoint Server 2013 ファームの容量を計画する方法について説明します。容量計画および管理に精通している場合は、その知識をシステム サイジングに活用することができます。サイジングは、ソリューション プラットフォームに適切なデータ アーキテクチャ、論理トポロジと物理トポロジ、およびハードウェアの選択および構成について説明する場合に使用される用語です。最適なハードウェアと構成オプションの選択方法に影響を与えるさまざまな容量管理と用途に関する考慮事項があります。This article describes how to plan the capacity of a SharePoint Server 2013 farm. When you have a good appreciation and understanding of capacity planning and management, you can apply your knowledge to system sizing. Sizing is the term used to describe the selection and configuration of appropriate data architecture, logical and physical topology, and hardware for a solution platform. There is a range of capacity management and usage considerations that affect how you should determine the most appropriate hardware and configuration options.

この記事を読む前に、「Capacity management and sizing overview for SharePoint Server 2013」をお読みください。Before you read this article, you should read Capacity management and sizing overview for SharePoint Server 2013.

重要

この記事の一部の情報と値は、テスト結果と SharePoint 2010 製品 に関連するその他の情報に基づくもので、SharePoint Server 2013 での最終的な値を示すものではありません。Some information and values in this article are based on test results and other information related to SharePoint 2010 Products and may not represent the final values for SharePoint Server 2013.

この記事では、環境に合わせた効率的な容量管理を実現するために実行すべき手順について説明します。手順ごとに、正しく実行するための特定の情報が必要であり、それ以降の手順で使用する一連の成果物が生成されます。手順ごとの要件と成果物を表にまとめました。In this article, we describe the steps you should take to undertake effective capacity management for your environment. Each step requires certain information for successful execution, and has a set of deliverables that you will use in the subsequent step. For each step, these requirements and deliverables are outlined in tables.

ステップ 1: モデル化Step 1: Model

SharePoint Server 2013 ベースの環境のモデリングは、既存のソリューションの分析と、セットアップを計画している展開の予想需要と目標の評価から始まります。まずは、ユーザー基盤、データ要件、および遅延とスループットの目標を収集して、展開する SharePoint Server 2013 の機能を文書化します。このセクションは、収集すべきデータ、その方法、および以降の手順での用途を理解するために使用してください。Modeling your SharePoint Server 2013-based environment begins with analyzing your existing solutions and estimating the expected demand and targets for the deployment you are planning to set up. You start by gathering information about your user base, data requirements, latency and throughput targets, and document the SharePoint Server 2013 features you want to deploy. Use this section to understand what data you should collect, how to collect it, and how it can be used in subsequent steps.

予想されるワークロードとデータセットを理解するUnderstand your expected workload and dataset

SharePoint Server 2013 実装を正しくサイジングするためには、ソリューションが処理を期待されている需要特性を調査して理解する必要があります。需要を理解するためには、ユーザー数やよく使用される操作などのワークロード特性と、コンテンツ サイズやコンテンツ配信などのデータセット特性の両方を表現できる必要があります。Proper sizing of a SharePoint Server 2013 implementation requires that you study and understand the demand characteristics that your solution is expected to handle. Understanding the demand requires that you be able to describe both the workload characteristics such as number of users and the most frequently used operations, and dataset characteristics such as content size and content distribution.

このセクションは、収集すべき特定の測定基準およびパラメーターとそれらを収集可能なメカニズムの理解に役立ちます。This section can help you understand some specific metrics and parameters you should collect and mechanisms by which they can be collected.

ワークロードWorkload

ワークロードは、システムが維持する必要のある需要、ユーザー基盤、および使用状況特性を意味します。下の表に、ワークロードの決定に役立つ主な測定基準を示します。この表は、これらの測定基準を収集して記録するために使用できます。Workload describes the demand that the system will need to sustain, the user base and usage characteristics. The following table provides some key metrics that are helpful in determining your workload. You can use this table to record these metrics as you collect them.

ワークロード特性Workload Characteristics Value
1 日あたりの平均 RPSAverage daily RPS
平均ピーク時 RPSAverage RPS at peak time
1 日あたりの一意のユーザー総数Total number of unique users per day
1 日あたりの平均同時ユーザー数Average daily concurrent users
ピーク時同時ユーザー数Peak concurrent users at peak time
1 日あたりの要求総数Total number of requests per day
予想ワークロード配分Expected workload distribution
1 日あたりの要求数No. of Requests per day
%
Web ブラウザー - 検索クロールWeb Browser - Search Crawl
Web ブラウザー - 一般的グループ作業相互作用Web Browser - General Collaboration Interaction
Web ブラウザー - ソーシャル相互作用Web Browser - Social Interaction
Web ブラウザー - 一般的相互作用Web Browser - General Interaction
Web ブラウザー - Office Web AppsWeb Browser - Office Web Apps
Office クライアントOffice Clients
OneNote クライアントOneNote Client
SharePoint WorkspaceSharePoint Workspace
Outlook RSS 同期Outlook RSS Sync
Outlook Social ConnectorOutlook Social Connector
その他の相互作用 (カスタム アプリケーション/Web サービス)Other interactions(Custom Applications/Web services)
  • 同時ユーザー数 - 一定期間に要求を発行した一意のユーザー数としてサーバー ファーム上で実行された処理の同時並行性を評価するのが最も一般的です。主な測定単位は、1 日あたりの平均同時ユーザー数とピーク負荷時の同時ユーザー数です。Concurrent users - It is most common to measure the concurrency of operations executed on the server farm as the number of distinct users generating requests in a given time frame. The key metrics are the daily average and the concurrent users at peak load.

  • 1 秒あたりの要求数 (RPS) - RPS は、ファームで 1 秒間に処理された要求数で表現されるサーバー ファーム上の需要を説明するためによく使用される指標ですが、要求の種類や規模は区別されません。組織のユーザー ベースに応じ、組織固有の使用状況特性に応じて、異なるペースでシステム負荷が生成されます。この用語の詳細については、「 Capacity management and sizing overview for SharePoint Server 2013」の「 用語集」セクションを参照してください。Requests per second (RPS) - RPS is a commonly used indicator used to describe the demand on the server farm expressed in the number of requests processed by the farm per second, but with no differentiation between the type or size of requests. Every organization's user base generates system load at a rate that is dependent on the organization's unique usage characteristics. See the Glossary section in Capacity management and sizing overview for SharePoint Server 2013 for more information on this term.

  • 1 日あたりの要求総数 - 1 日あたりの要求総数は、システムが処理する必要のある全体負荷の適切な指標です。24 時間にわたる、認証Iハンドシェイク要求 (HTTP ステータス 401) を除くすべての要求を評価するのが最も一般的です。Total daily requests - Total daily requests is a good indicator of the overall load the system will need to handle. It is most common to measure all requests except authentication handshake requests (HTTP status 401) over a 24 hour period.

  • 1 日あたりのユーザー総数 - ユーザー総数は、システムが処理する必要のある全体負荷のもう 1 つの重要な指標です。 この測定結果は、24 時間にわたる実際の一意のユーザー数であって、組織内の従業員の総数ではありません。Total daily users - Total users is another key indicator of the overall load the system will need to handle. This measurement is the actual number of unique users in a 24 hour period, not the total number of employees in the organization.

    注意

    1 日あたりのユーザー総数は、ファーム上の負荷の潜在的な増加を示すことができます。たとえば、潜在的ユーザーとして 10 万人の従業員がいて、1 日あたりのユーザー数が 1 万 5,000 人の場合は、時間とともにユーザー導入が増えるため、負荷が大幅に増加する可能性があります。The number of total daily users can indicate the growth potential of the load on the farm. For example, if the number of potential users is 100k employees, 15k daily users indicates that the load may significantly grow over time as user adoption increases.

  • ワークロード配分 - ファームと通信しているクライアント アプリケーションに基づく要求の配分を理解することによって、SharePoint Server 2013 への移行後に予想される傾向と負荷の変化の予測が可能になります。ユーザーが Office 2013 などのより新しいクライアント バージョンに移行して、新しい機能を使用し始めると、新しい負荷パターン、RPS、および要求総数が増加することが予想されます。クライアントごとに、1 日の特定の時間帯にそれを使用している一意のユーザー数と、クライアントまたは機能がサーバー上で生成する要求総数を表現できます。Workload Distribution - Understanding the distribution of the requests based on the clients applications that are interacting with the farm can help predict the expected trend and load changes after migrating to SharePoint Server 2013. As users transition to more recent client versions such as Office 2013, and start using the new capabilities new load patterns, RPS and total requests are expected to grow. For each client we can describe the number of distinct users using it in a time frame of a day, and the amount of total requests that the client or feature generates on the server.

    たとえば、下のチャートは、標準的なソーシャル ソリューションを提供している社内の Microsoft 環境のスナップショットを示しています。この例では、大部分の負荷が検索クローラと標準的なエンド ユーザーの Web 閲覧によって生成されていることがわかります。Outlook Social Connector 機能によって大量の負荷が導入されていることもわかります (要求の 6.2 %)。For example, the chart below shows a snapshot of a live internal Microsoft environment serving a typical social solution. In this example, you can see that the majority of the load is generated by the search crawler and typical end user web browsing. You can also observe that there is significant load introduced by the Outlook Social Connector feature (6.2 percent of the requests).

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

実稼働ワークロードの見積もりEstimating your production workload

ファームで維持できるようにしなければならない必要なスループットの見積もりでは、ファーム内で使用されるさまざまなトランザクションを予測することから始めます。システムで処理される頻繁に使用されるトランザクションの分析と、それらの使用頻度とユーザー数の理解に焦点を当てます。これにより、後の実稼働前テストで、ファームがそのような負荷を維持できるかどうかを検証しやすくなります。In estimating the required throughput your farm needs to be able to sustain, begin with estimating the mix of transactions that will be used in your farm. Focus on analyzing the most frequently used transactions the system will serve, understanding how frequently they will be used and by how many users. That will help you validate later whether the farm can sustain such load in pre-production testing.

下の図は、システム上のワークロードと負荷の関係を示しています。The following diagram describes the relationship of the workload and load on the system:

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

予想ワークロードを見積もるために、以下の情報を収集します。To estimate your expected workload, collect the following information:

  • 標準的な Web ページの閲覧、ファイルのダウンロードとアップロード、ブラウザーでの Office Web アプリケーションの表示と編集、共同編集相互作用、SharePoint Workspace サイトの同期、Outlook ソーシャル接続、 RSS 同期 (Outlook またはその他のビューアー)、PowerPoint ブロードキャスト、OneNote 共有ノートブック、Excel Service 共有ブック、Access Service 共有アプリケーションなどのユーザー操作を特定します。詳細については、記事「Capacity management and sizing overview for SharePoint Server 2013」の「 サービスと機能」セクションを参照してください。展開に固有の相互作用の特定に焦点を当て、そのような負荷の予想される影響を評価します。たとえば、InfoPath フォーム、Excel Service 計算、または同様の専用ソリューションを大量に使用した場合です。Identify user interactions such as typical web page browses, file downloads and uploads, Office Web Application views and edits in the browser, co-authoring interactions, SharePoint Workspace site syncs, Outlook Social Connections, RSS sync (in Outlook or other viewers), PowerPoint Broadcasts, OneNote shared notebooks, Excel Service shared workbooks, Access Service shared applications and others. See the Services and Features section of the article Capacity management and sizing overview for SharePoint Server 2013 for more information. Focus on the identifying the interactions that may be unique to your deployment, and recognize the expected impact of such load, examples can be significant use of InfoPath Forms, Excel Service Calculations and similar dedicated solutions.

  • 検索インクリメンタル クロール、日次バックアップ、プロファイル同期タイマー ジョブ、Web 分析処理、ログ タイマー ジョブなどのシステム処理を特定します。Identify system operations such as Search incremental crawls, daily backups, profile sync timer jobs, web analytics processing, logging timer jobs and others.

  • 各機能の使用が予想される 1 日あたりのユーザー総数を見積もり、1 秒あたりの予想同時ユーザー数と高レベル要求数を抽出し、現在の同時並行性や機能によって異なる同時ユーザーあたりの RPS の係数などを前提として、前述したワークロード表を見積もりに利用する必要があります。平均スループットではなく、ピーク時間に焦点を当てることが重要です。ピーク活動を計画すれば、SharePoint Server 2013 ベースのソリューションを正確にサイジングすることができます。Estimate the total number of users per day that are expected to utilize each capability, derive the estimated concurrent users and high level Requests per second, there are some assumptions you will be making such as present concurrency and the factor of RPS per concurrent users that is different across capabilities, you should use the workload table earlier in this section for your estimates. It is important to focus on peak hours, rather than average throughput. Planning for peak activity, you are able to proper size your SharePoint Server 2013-based solution.

既存の Office SharePoint Server 2007 ソリューションがある場合は、IIS ログ ファイルを調べたり、その他の Web 監視ツールを試してみたりして、既存のソリューションから予想される動作の一部をより良く理解することも、次のセクションで手順の詳細を確認することもできます。既存のソリューションから移行しない場合は、大まかな見積もりによって表を埋める必要があります。後の手順で、前提を検証し、システムを調整する必要があります。If you have an existing Office SharePoint Server 2007 solution, you can mine the IIS log files or look to other Web monitoring tools you have to better understand some of the expected behaviors from the existing solution or see the instructions in the section below for more details. If you are not migrating from an existing solution, you should fill out the table using rough estimates. In later steps you will need to validate your assumptions and tune the system.

SharePoint Server 2013 IIS ログの分析Analyzing your SharePoint Server 2013 IIS Logs

アクティブなユーザー数、彼らのシステム利用度、発行された要求の種類、それらを発行したクライアントの種類などの既存の SharePoint Server 2013 展開に関する主要な測定基準を特定するには、ULS ログと IIS ログからデータを抽出する必要があります。このデータを取得する最も簡単な方法の 1 つが Microsoft から無料でダウンロード可能な強力なツールである Log Parser を使用することです。Log Parser は、すべての IIS 形式を含む、さまざまなテキスト形式とバイナリ形式を読み書きできます。To discover key metrics about an existing SharePoint Server 2013 deployment, such as how many users are active, how heavily they are using the system, what kind of requests are coming in, and from what kind of clients they originate, it is necessary to extract data from ULS and IIS logs. One of the easiest ways to acquire this data is to use Log Parser, a powerful tool available free for download from Microsoft. Log Parser can read and write to a number of textual and binary formats, including all the IIS formats.

Log Parser を使用した SharePoint Server 2013 の使用状況の分析方法については、「Microsoft SharePoint 製品および技術の使用状況分析 (http://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e&displaylang=en&tm)」を参照してください。For detailed information about how to analyze SharePoint Server 2013 usage using Log Parser, read Analyzing Microsoft SharePoint Products and Technologies Usage (http://www.microsoft.com/downloads/details.aspx?familyid=f159af68-c3a3-413c-a3f7-2e0be6d5532e&displaylang=en&tm).

Log Parser 2.2 を http://www.microsoft.com/downloads/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07&displaylang=en からダウンロードすることができます。You can download Log Parser 2.2 at http://www.microsoft.com/downloads/details.aspx?FamilyID=890CD06B-ABF8-4C25-91B2-F8D975CF8C07&displaylang=en.

データセットDataset

データセットは、システムに保存されたコンテンツの量とデータ ストア内でのその配分方法を示します。下の表に、データセットの決定に役立つ主な測定基準を示します。この表は、収集した測定基準を記録するために使用できます。Dataset describes the volume of content stored in the system and how it can be distributed in the data store. The following table provides some key metrics that are helpful in determining your dataset. You can use this table to record these metrics as you collect them.

オブジェクトObject Value
DB サイズ (GB 単位)DB size (in GB)
コンテンツ DB 数Number of Content DBs
サイト コレクション数Number of site collections
Web アプリケーション数Number of web apps
サイト数Number of sites
検索インデックス サイズ (項目数)Search index size (# of items)
ドキュメント数Number of docs
リスト数Number of lists
平均サイト サイズAverage size of sites
最大サイト サイズLargest site size
ユーザー プロファイル数Number of user profiles
  • コンテンツ サイズ - SharePoint Server 2013 システムで保存するコンテンツのサイズを理解することは、システム ストレージを計画して設計するためだけでなく、そのコンテンツをクロールして索引付けする検索ソリューションを正確にサイジングするためにも重要です。コンテンツ サイズは全ディスク領域で表現されます。コンテンツを既存の展開から移行する場合は、移動する全体サイズを比較的容易に特定できることがありますが、計画段階では、予想される傾向に基づいて時間に伴う増加分の余地を残しておく必要があります。Content size - Understanding the size of the content that you expect to store in the SharePoint Server 2013 system is important for planning and architecting the system storage, and also for properly sizing the Search solution that will crawl and index this content. The content size is described in total disk space. If you are migrating content from an existing deployment you might find it simple to identify the total size that you will move; while planning you should leave room for growth over time based on the predicted trend.

  • ドキュメント総数 - データ コーパス サイズを除いて、項目総数を追跡することが重要です。100 GB のデータを 2 GB ずつの 50 ファイルに分けるのと、1 KB ずつの 100,000 ファイルに分けるのとでは、システムの反応が異なります。大規模展開では、単一項目、単一ドキュメント、またはドキュメント領域に対するストレスが少ないほど、パフォーマンスが向上します。多数のサイトとサイト コレクションに保存された複数の小さなファイルのように広く分散されたコンテンツは、非常に大きなファイルを含む単一の大きなドキュメント ライブラリよりも処理が簡単です。Total number of documents - Other than the data corpus size, it is important to track the overall number of items. The system reacts differently if 100 GB of data is composed of 50 files of 2 GB each versus 100,000 files of 1 KB each. In large deployments, the less stress there is on a single item, document or area of documents, the better performance will be. Widely distributed content like multiple smaller files across many sites and site collection is easier to serve then a single large document library with very large files.

  • 最大サイト コレクション サイズ - SharePoint Server 2013 に保存するコンテンツの最大単位を特定することが重要です。このコンテンツ単位の分割を妨げている原因の多くは組織的ニーズです。すべてのサイト コレクションの平均サイズとサイト コレクションの予想総数は、望ましいデータ アーキテクチャの特定に役立つ追加の指標です。Maximum site collection size - It is important to identify what is the biggest unit of content that you will store in SharePoint Server 2013; usually it is an organizational need that prevents you from splitting that unit of content. Average size of all site collections and the estimated total number of site collections are additional indicators that will help you identify your preferred data architecture.

  • サービス アプリケーション データの特性 - コンテンツ ストアの保存ニーズの分析に加えて、以下を含む、その他の SharePoint Server 2013 ストアのサイズを分析して見積もる必要があります。Service applications data characteristics - In addition to analysing the storage needs for the content store, you should analyse and estimate the sizes of other SharePoint Server 2013 stores, including:

  • 検索インデックスの総サイズTotal size of the Search index

  • プロファイル ストア内のユーザー数に基づくプロファイル データベースの総サイズThe profile database total size based on the number of user in the profile store

  • タグ、同僚、および活動の予想数に基づくソーシャル データベースの総サイズThe social database total size based on the expected number of tags, colleagues and activities

  • メタデータ ストア サイズThe metadata store size

  • 使用状況データベースのサイズThe size of the usage database

  • Web Analytics データベースのサイズThe size of the Web Analytics data base

ファームのパフォーマンスと信頼性の目標設定Setting Farm Performance and Reliability Targets

ステップ 1: モデル化の成果物の 1 つは組織のニーズに最適なパフォーマンスと信頼性の目標の正確な把握です。正しく設計された SharePoint Server 2013 ソリューションは、ミリ秒単位のサーバー応答性による「フォー ナイン」 (99.99%) の稼働率を達成できるはずです。One of the deliverables of Step 1: Model is a good understanding of the performance and reliability targets that best fit the needs of your organization. A properly designed SharePoint Server 2013 solution should be able to achieve "four nines" (99.99%) of uptime with sub-second server responsiveness.

ファームのパフォーマンスと信頼性を表現するための指標には以下が含まれます。The indicators used to describe the performance and reliability of the farm can include:

  • サーバー可用性 - 通常は、システム全体のアップタイムの割合 (%) で表現されます。予定外のダウンタイムを追跡して、設定した組織の目標と全体の可用性を照らし合わせる必要があります。一般的に、目標は 9 の数 (99%、99.9%、99.99% など) で表現されます。Server availability - Usually described by the percent of overall uptime of the system. You should track any unexpected downtime and compare the overall availability to the organizational target you set. The targets are commonly described by a number of nines (i.e. 99%, 99.9%, 99.99%)

  • サーバー応答性 - ファームが要求を処理する時間はファームの正常性を追跡する良い指標になります。この指標は、サーバー側遅延と呼ばれることが多く、処理される 1 日あたりの要求数の平均または中間 (50 番目のパーセンタイル値) 遅延を使用するのが一般的です。通常、目標は、ミリ秒単位または秒単位で表現されます。SharePoint Server 2013 から 2 秒以内にページを処理することが組織の目標の場合は、サーバー側の目標をミリ秒単位にしてページがネットワーク経由でクライアントに到達する時間とブラウザーで描画される時間を残す必要があります。また、一般的に、サーバーの応答時間が長い場合は、サーバーが正常でないことを示しており、スループットに対する影響が出ます。ほとんどの要求に対してサーバーの処理が 1 秒以上かかる場合は、RPS をほとんど維持できません。Server responsiveness - The time it takes the farm to serve requests is a good indicator to track the health of the farm. This indicator is usually named server side latency, and it is common to use the average or median (the 50th percentile) latency of the daily requests being served. The targets are commonly described in sub seconds or seconds. Note that if your organization has a target to serve pages from SharePoint Server 2013 in less than two seconds, then the server side goal needs to be sub seconds to leave time for the page to reach the client over the network and time to render in the browser. Also in general longer server response times are an indication of an unhealthy farm, as this usually as an impact on throughput and rarely can RPS keep up if you spend more than a second on the server on most requests

  • サーバー スパイクネス - 追跡すべきもう 1 つの良好なサーバー側遅延指標は、すべての要求の中で最も遅い 5% の振る舞いです。遅い要求とは、一般的には、負荷が高いときにシステムに出される要求であり、さらに一般的には、ユーザーがシステムと対話している間に発生する頻度の低い活動の影響を受ける要求のことです。健全なシステムとは、最も遅い要求も制御できるシステムのことです。ここでの目標はサーバー応答性に似ていますが、サーバー スパイクネスに対してミリ秒単位の応答を達成するには、負荷のスパイクに対処するための大量の予備リソースを組み込んでシステムを構築する必要があります。Server spikiness - Another good server side latency indicator worth tracking is the behaviour of the slowest 5% of all requests. Slower requests are usually the requests that hit the system when it is under higher load or even more commonly, requests that are impacted by less frequent activity that occur while users interact with the system; a healthy system is one that has the slowest requests under control as well. The target here is similar to Server Responsiveness, but to achieve sub-second response on server spikiness, you will need to build the system with a lot of spare resources to handle the spikes in load.

  • システム リソース使用率 - システムの正常性の追跡に使用されるその他の一般的指標は、ファーム トポロジ内の各サーバーの正常性を示すシステム カウンターのコレクションです。追跡によく使用される指標は CPU 使用率とメモリ空き容量ですが、その他にも、不健全なシステムの特定に役立つカウンターがあります。詳細は、「 ステップ 5: 監視と維持」を参照してください。System resource utilization - Other common indicators used to track the health of the system are a collection of system counters that indicate the health of each server in the farm topology. The most frequently used indicators to track are % CPU utilization and Available Memory; however, there are several additional counters that can help identify a non-healthy system; more details can be found in Step 5: Monitor and Maintain.

ステップ 2: 設計Step 2: Design

これで、配信する必要のあるソリューションに関するいくつかの事実または見積もりの収集が終わって、予想需要を維持可能な提案アーキテクチャを設計する次のステップの準備が整いました。Now that you have finished collecting some facts or estimates on the solution you need to deliver, you are ready to start the next step of designing a proposed architecture that you predict will be able to sustain the expected demand.

このステップが終わるまでに、物理トポロジの設計と論理トポロジのレイアウトが完成しているはずで、発注に進むことができるはずです。By the end of this step you should have a design for your physical topology and a layout for your logical topology, so you should be able to go ahead with any necessary purchase orders.

レイアウトするハードウェアの仕様とマシンの台数には密接な関係があり、特定の負荷を処理するために、展開可能ないくつかの解決策があります。強力なマシンの少量セットを使用する (スケール アップ) か、小型のマシンの大量セットを使用する (スケール ダウン) のが一般的です。どちらの解決策も容量、冗長性、電力、コスト、スペース、およびその他の考慮事項に関してメリットとデメリットがあります。The hardware specifications and the number of machines you layout are tightly related, to handle a specific load there are several solutions you can choose to deploy. It is common to either use a small set of strong machines (scale up) or a larger set of smaller machines (scale out); each solution has its advantages and disadvantages when it comes to capacity, redundancy, power, cost, space, and other considerations.

このステップに着手する前に、アーキテクチャとトポロジを決定することをお勧めします。さまざまなファームとファームごとに異なるサービスのレイアウトの計画方法を定義してから、設計に含まれるサーバーごとのハードウェア仕様を選択します。展開を予定しているハードウェア仕様 (多くの組織が特定の社内基準の制約を受けている) を特定することによってこのプロセスを実行してから、アーキテクチャとトポロジを定義することもできます。We recommend that you begin this step by determining your architecture and topology. Define how you plan to layout the different farms and the different services in each farm, and then pick the hardware specifications for each of the individual servers in your design. You can also execute this process by identifying the hardware specifications you are expected to deploy (many organizations are constrained to a certain company standard) and then define your architecture and topology.

下の表は、設計パラメーターを記録するために使用します。含まれるデータはサンプル データであり、ファームのサイジングには使用しないでください。これは、この表をどのように独自のデータに利用するかを示すためのものです。Use the following table to record your design parameters. The data included is sample data, and should not be used to size your farm. It is intended to demonstrate how to use this table for your own data.

役割Role 種類 (標準または仮想)Type (Standard or virtual) マシンの台数# of machines プロセッサProcs RAMRAM 必要な IOPSIOPS need ディスク サイズ (OS + ログ)Disk size OS+Log データ ドライブData drive
Web サーバーWeb servers
仮想Virtual
2/44
4 コア4 cores
8 8
N/AN/A
400 GB400 GB
N/AN/A
コンテンツ データベース サーバーContent database server
標準Standard
1 クラスター1 cluster
4 クアッド コア 2.33 (GHz)4 quad-core 2.33 (GHz)
4848
2k2k
400 GB400 GB
20 ディスク (300 GB)20 disks of 300GB
@ 15K RPM@ 15K RPM
アプリケーション サーバーApplication servers
仮想Virtual
2/44
4 コア4 cores
1616
N/AN/A
400 GB400 GB
N/AN/A
検索クロール ターゲット Web サーバーSearch Crawl Target Web server
仮想Virtual
1-d1
4 コア4 cores
8 8
N/AN/A
400 GB400 GB
N/AN/A
検索クエリ サーバーSearch Query server
標準Standard
pbm-22
2 クアッド コア 2.33 (GHz)2 quad-core 2.33 (GHz)
3232
N/AN/A
400 GB400 GB
500 GB500 GB
検索クロール サーバーSearch Crawler server
標準Standard
pbm-22
2 クアッド コア 2.33 (GHz)2 quad-core 2.33 (GHz)
1616
400400
400 GB400 GB
N/AN/A
検索クロール データベース サーバーSearch Crawl database server
標準Standard
1 クラスター1 cluster
4 クアッド コア 2.33 (GHz)4 quad-core 2.33 (GHz)
4848
4k (読み取り専用)4k (tuned for read)
100 GB100 GB
16 ディスク (150 GB @ 15K RPM)16 disks of 150GB @ 15K RPM
検索プロパティ ストア データベース + 管理データベース サーバーSearch Property Store database + Administration database server
標準Standard
1 クラスター1 cluster
4 クアッド コア 2.33 (GHz)4 quad-core 2.33 (GHz)
4848
2k (書き込み専用)2k (tuned for write)
100 GB100 GB
16 ディスク (150 GB @ 15K RPM)16 disks of 150GB @ 15K RPM

開始点アーキテクチャを決定するDetermine your starting point architecture

このセクションでは、開始点アーキテクチャの選択方法について説明します。This section describes how to select a starting point architecture.

SharePoint Server 2013 を展開するときに、ソリューションを実装するトポロジを複数の中から選択できます。さまざまなサービス用のクラスター化またはミラー化されたデータベース サーバーと個別のアプリケーション サーバーからなる SharePoint Server 2013 ファームに単一のサーバーを展開することも、複数のサーバーをスケール アウトすることもできます。後で、容量、可用性、および冗長性のニーズに基づいて、役割ごとの要件に応じたハードウェア構成を選択することになります。When you deploy SharePoint Server 2013, you can choose from a range of topologies to implement your solution; you may deploy a single server or scale out many servers to a SharePoint Server 2013 farm with clustered or mirrored database servers and discreet application servers for various services. Later you will select the hardware configurations based on the requirements of each of the roles, based on your capacity, availability, and redundancy needs.

さまざまな参照アーキテクチャを調査することから始めて、ファーム構造を明確にし、ソリューションを複数のファームに分散させるのか、検索などの一部のサービスを 1 つの専用ファームに集めるのかを決定します。詳細については、「Capacity management and sizing overview for SharePoint Server 2013」の「 参照アーキテクチャ」セクションを参照してください。Start by reviewing the different reference architectures and figure out your farm structure, decide if you should split your solution across multiple farms, or federate some services, such as search, on a dedicated farm. See the Reference Architectures section in Capacity management and sizing overview for SharePoint Server 2013 for more information.

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

SharePoint Server 2013 に関する容量管理ガイダンスには、既存の SharePoint Server 2013 ベースの実稼働環境に関する詳細な説明を提供するさまざまなテクニカル ケース スタディが含まれています。SharePoint Server 2013 に固有のテクニカル ケース スタディは、入手可能になった段階で公開されます。既存の SharePoint Server 2010 ケース スタディは、特定の目的のために SharePoint Server 2013 ベースの環境を設計する方法に関する参考資料として機能します。Capacity management guidance for SharePoint Server 2013 includes a number of technical case studies of existing production environments that present a detailed description of existing SharePoint Server 2013-based production environments. Technical case studies specific to SharePoint Server 2013 will be published as they become available; the existing SharePoint Server 2010 case studies can serve as a reference on how to design a SharePoint Server 2013-based environment for specific purposes.

これらのケース スタディは、特に、設計中のソリューションの需要と目標に近い展開固有の重要な差別化要因の記述を見つけた場合は、SharePoint Server 2013 ソリューションのアーキテクチャ設計の参考用として使用できます。You can use these case studies as a reference while designing the architecture of your SharePoint Server 2013 solutions especially if you find the description of these deployment specific key differentiators similar to the demands and targets of the solution you are architecting.

これらのドキュメントには、それぞれのケース スタディに関する以下の情報が記載されています。These documents describe the following information for each documented case study:

  • ハードウェア、ファーム トポロジ、構成などの 仕様Specifications, such as hardware, farm topology and configuration;

  • ユーザー基盤と使用状況特性を含む ワークロードWorkload including the user base, and the usage characteristics;

  • コンテンツ サイズ、コンテンツ特性、およびコンテンツ分散を含む データセットDataset, including contents sizes, content characteristics and content distribution

  • ファームの信頼性やパフォーマンスの特徴を示す一連の記録された指標を含む 正常性とパフォーマンスHealth and performance including a set of recorded indicators describing the farm's reliability and performance characteristics

詳細については、「パフォーマンスと容量に関する技術的なケース スタディ (SharePoint Server 2010)」ページから関連ドキュメントをダウンロードしてください。For more information, download relevant documents from the Performance and capacity technical case studies (SharePoint Server 2010) page.

ハードウェアを選択するSelect your hardware

ファーム内のマシンの正しい仕様を選択することは、展開の適切な信頼性とパフォーマンスを保証するために不可欠なステップであり、覚えておくべき重要な概念の 1 つはピーク負荷とピーク時間を計画すべきということです。つまり、ファームが平均的な負荷状態で動作している場合は、予想最大需要に対処できるだけの十分なリソースを確保しながら、遅延とスループットの目標を達成する必要があります。Selecting the right specifications for the machines in your farm is a crucial step to ensure proper reliability and performance of your deployment, one key concept to keep in mind is that you should plan for peak load and peak hours; in other words, when your farm is operating under average load conditions, there should be enough resources available to handle the greatest expected demand while still hitting latency and throughput targets.

サーバーの容量およびパフォーマンスに関するコアなハードウェア機能は、システムの処理能力、ディスク パフォーマンス、ネットワーク容量、およびメモリ機能という 4 つの主要カテゴリに左右されます。The core capacity and performance hardware features of servers reflect four main categories: processing power, disk performance, network capacity, and memory capabilities of a system.

加えて、仮想マシンの使用も考慮すべきです。Another thing to consider is using virtualized machines. SharePoint Server 2013 ファームは、仮想マシンを使用して展開できます。A SharePoint Server 2013 farm can be deployed using virtual machines. 仮想化によってパフォーマンスのメリットが増加するわけではありませんが、管理容易性のメリットが得られます。Although virtualization has not been found to add any performance benefits, it does provide manageability benefits. 一般的に、SQL Server ベースのコンピューターの仮想化は推奨されませんが、Web サーバー層とアプリケーション サーバー層の仮想化には一定のメリットがあります。Virtualizing SQL Server-based computers is generally not recommended, but there may be certain benefits to virtualizing the Web server and application server tiers. 詳細については、「仮想化の計画(/previous-versions/office/sharepoint-server-2010/ff607968 (v = office)」を参照してください。For more information, see Virtualization planning (/previous-versions/office/sharepoint-server-2010/ff607968(v=office.14)).

ハードウェア要件の詳細については、「SharePoint Server 2016 のハードウェア要件およびソフトウェア要件」を参照してください。For more information about hardware requirements, see Hardware and software requirements for SharePoint Server 2016.

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

プロセッサの選択Choosing Processors

SharePoint Server 2013 は、64 ビットのプロセッサでのみ使用できます。一般的に、プロセッサが多いほどより高い需要を処理できます。SharePoint Server 2013 is available only for 64-bit processors. In general, more processors will enable you to serve greater demand.

SharePoint Server 2013 では、コアの増加に伴って、個々の Web サーバーがスケールアップします。他が同じ場合は、サーバーのコアが多いほど、維持可能な負荷が増えます。大規模な SharePoint Server 2013 展開では、複数の 4 コア Web サーバー (仮想化が可能) を割り当てるか、少数だが強力な (8/16/24 コア) Web サーバーを割り当てるかのどちらかをお勧めします。In SharePoint Server 2013, individual web servers will scale up as you add more cores. The more cores the server has the more load it can sustain, all else being equal. In large SharePoint Server 2013 deployments, we recommend that you allocate either multiple 4-core web servers (which can be virtualized), or fewer stronger (8-/16-/24-cores) web servers.

アプリケーション サーバーのプロセッサ容量要件は、サーバーの役割とサーバーが実行するサービスによって異なります。SharePoint Server 2013 の機能によっては、他よりも高い処理能力が必要な場合があります。たとえば、SharePoint Search Service は、アプリケーション サーバーの処理能力に大きく依存します。Application servers' processor capacity requirements differ depending on the role of the server and the services it is running. Some SharePoint Server 2013 features demand greater processing power than others. For example, the SharePoint Search Service is highly dependent on the processing power of the application server.

SQL Server のプロセッサ容量要件は、SQL Server ベースのコンピューターがホストしているサービス データベースによっても異なります。The processor capacity requirements for SQL Server also depend on the service databases that a SQL Server-based computer is hosting.

メモリの選択Choosing Memory

サーバーに必要なメモリ量は、そのサーバーの機能と役割によってさまざまです。たとえば、検索クロール コンポーネントを実行しているサーバーは、大量のメモリを搭載していれば、ドキュメントをメモリに読み込んで処理できるため、データを短時間で処理します。SharePoint Server 2013 のさまざまなキャッシング機能を利用する Web サーバーもより多くのメモリを必要とします。Your servers will require varying amounts of memory, depending on server function and role. For example, servers that run Search crawl components will process data more quickly if they have a large amount of memory because documents are read into memory for processing. Web servers that take advantage of many of the caching features of SharePoint Server 2013 may require more memory as well.

一般的に、Web サーバーのメモリ要件は、ファーム内で有効になっているアプリケーション プールの数と処理する同時要求の数に大きく依存します。ほとんどの実稼働 SharePoint Server 2013 展開において、Web サーバーごとに 8 GB 以上の RAM を割り当てることをお勧めします。よりトラフィックの高いサーバーや隔離用に複数のアプリケーション プールをセットアップした展開の場合は 16 GB の RAM をお勧めします。In general, web server memory requirements are highly dependent on the number of application pools enabled in the farm and the number of concurrent requests being served. In most production SharePoint Server 2013 deployments, we recommend that you allocate at least 8 GB RAM on each web server, with 16 GB recommended for servers that have greater traffic or deployments with multiple application pools set up for isolation.

アプリケーション サーバーのメモり要件も異なります。SharePoint Server 2013 の機能によっては、他よりもアプリケーション層に関するメモリ要件がより厳しい場合があります。ほとんどの実稼働 SharePoint Server 2013 展開において、アプリケーション サーバーごとに 8 GB 以上の RAM を割り当てることをお勧めします。1 つのサーバー上で多数のアプリケーション サービスが有効になっている場合、または、Excel Calculation Service や SharePoint Server 2013 Search Service などのメモリ依存度の高いサービスが有効になっている場合は、16 GB、32 GB、および 64 GB のアプリケーション サーバーが一般的です。Application servers' memory requirements differ also; some SharePoint Server 2013 features have greater memory requirements on the application tier than others. In most production SharePoint Server 2013 deployments we recommend that you allocate at least 8 GB RAM on each application server; 16 GB, 32 GB and 64 GB application servers are common when many application services are enabled on the same server, or when services that are highly dependent on memory, such as the Excel Calculation Service and SharePoint Server 2013 Search Service, are enabled.

データベース サーバーのメモリ要件は、データベース サイズに大きく依存します。SQL Server ベースのコンピューターのメモリ選択方法については、「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server)」を参照してください。The memory requirements of database servers are tightly dependent on the database sizes. For more information about choosing memory for your SQL Server-based computers, see Storage and SQL Server capacity planning and configuration (SharePoint Server).

ネットワークの選択Choosing Networks

クライアントがネットワーク経由で高速データ アクセスが可能な場合にユーザーに提供されるメリットに加えて、分散ファームがサーバー間通信用の高速アクセスを備えている必要があります。このことは、特に、サービスを複数のサーバーで分担したり、いくつかのサービスを別のファームに集めたりしている場合に当てはまります。ファーム内の Web サーバー層、アプリケーション サーバー層、およびデータベース サーバー層で大量のトラフィックが発生し、非常に大きなファイルや非常に高い負荷の処理などの特定の条件下でネットワークが簡単にボトルネックになる可能性があります。In addition to the benefit offered to users if clients have fast data access through the network, a distributed farm must have fast access for inter-server communication. This is especially true when you distribute services across multiple servers or federate some services to other farms. There is significant traffic in a farm across the web server tier, the application server tier, and the database server tier, and network can easily become a bottleneck under certain conditions like dealing with very large files or very high loads.

Web サーバーとアプリケーション サーバーは、2 枚以上のネットワーク インターフェイス カード (NIC) を使用するように構成する必要があります。1 枚はエンド ユーザー トラフィックを処理し、もう 1 枚はサーバー間通信を処理します。サーバー間のネットワーク遅延は、パフォーマンスに大きな影響を及ぼす可能性があります。そのため、Web サーバーと、コンテンツ データベースをホストしている SQL Server ベースのコンピューター間のネットワーク遅延を 1 ミリ秒未満に抑えることが重要です。各サービス アプリケーション データベースをホストする SQL Server ベースのコンピューターは、消費するアプリケーション サーバーのできるだけ近くに配置する必要もあります。ファーム サーバー間のネットワークは 1 Gbps 以上の帯域幅にする必要があります。Web servers and application servers should be configured to use at least two network interface cards (NICs): one NIC to handle end-user traffic and the other to handle the inter-server communication. Network latency between servers can have a significant effect on performance. Therefore, it is important to maintain less than 1 millisecond of network latency between the web server and the SQL Server-based computers hosting the content databases. The SQL Server-based computers that host each service application database should be as close as possible to the consuming application server also. The network between farm servers should have at least 1 Gbps of bandwidth.

ディスクとストレージの選択Choosing Disks and Storage

ディスク管理は、データ用の十分な領域を確保する機能だけではありません。需要と増加を継続的に評価して、ストレージ アーキテクチャがシステムを低速化させていないことを確認する必要があります。また、必ず、各ディスク上に最も高いデータ要件見積もりを 30% 以上上回る容量を確保して、将来の増加の余地を残しておく必要があります。加えて、ほとんどの実稼働環境において、サーバーのストレージ需要を満たすのに十分なスループットが提供されるディスク速度 (IOps) が不可欠です。展開内の主要なデータベースに必要なトラフィック量 (IOps) を見積もって、そのトラフィックを満たすのに十分なディスクを割り当てる必要があります。Disk management is not simply a function of providing sufficient space for your data. You must assess the on-going demand and growth, and make sure that that the storage architecture is not slowing the system down. You should always make sure that that you have at least 30 percent additional capacity on each disk, above your highest data requirement estimate, to leave room for future growth. Additionally, in most production environments, disk speed (IOps) is crucial to providing sufficient throughput to satisfy the servers' storage demands. You must estimate the amount of traffic (IOps) the major databases will require in your deployment and allocate enough disks to satisfy that traffic.

データベース サーバーのディスクの選択方法については、「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server)」を参照してください。For more information about how to choose disks for database servers, see Storage and SQL Server capacity planning and configuration (SharePoint Server).

Web サーバーとアプリケーション サーバーにはストレージ要件もあります。ほとんどの実稼働環境において、OS と一時ファイル用の 200 GB 以上のディスク容量とログ用の 150 GB のディスク容量を割り当てることをお勧めします。The web and application servers have storage requirements also. In most production environments, we recommend that you allocate at least 200 GB disk space for OS and temp and 150 GB of disk space for logs.

ステップ 3: パイロット、テスト、および最適化Step 3: Pilot, Test and Optimize

テストおよび最適化ステージは、効率的な容量管理にとって非常に需要な構成要素です。新しいアーキテクチャは実稼働環境に展開する前にテストする必要があり、以下のモニタリング ベスト プラクティスと一緒に受け入れテストを実施して、設計したアーキテクチャがパフォーマンスと容量の目標を達成していることを保証する必要があります。これにより、潜在的なボトルネックが実展開でユーザーに影響を与える前にそれらを特定して最適化できます。Office SharePoint Server 2007 環境からアップグレードしており、アーキテクチャを変更する予定の場合、または、新しい SharePoint Server 2013 機能のユーザー負荷を見積もっている場合は、新しい SharePoint Server 2013 ベースの環境がパフォーマンスと容量の目標を満たすことを確認するためのテストが特に重要です。The testing and optimization stage is an extremely important component of effective capacity management. You should test new architectures before you deploy them to production and you should conduct acceptance testing together with following monitoring best practices in order to ensure the architectures you design achieve the performance and capacity targets. This allows you to identify and optimize potential bottlenecks before they affect users in a live deployment. If you are upgrading from an Office SharePoint Server 2007 environment and plan to make architectural changes, or are estimating user load of the new SharePoint Server 2013 features, then testing particularly important to make sure that your new SharePoint Server 2013-based environment will meet performance and capacity targets.

環境のテストが終了したら、テスト結果を分析して、ステップ 1: モデル化で設定したパフォーマンスと容量の目標を達成するために変更すべき場所を特定できます。Once you have tested your environment, you can analyze the test results to determine what changes must be made in order to achieve the performance and capacity targets you established in Step 1: Model.

実稼働前の環境で従うべきサブ ステップとして推奨されている手順を以下に示します。These are the recommended sub steps that you should follow for pre-production:

  • ステップ 2: 設計で設計した初期アーキテクチャを試すテスト環境を構築します。Create the test environment that mimics the initial architecture you designed in Step 2: Design.

  • ステップ 1: モデル化で特定したデータセットまたはデータセットの一部でストレージを構成します。Populate the storage with the dataset or part of the dataset that you've identified in Step 1: Model.

  • ステップ 1: モデル化で特定したワークロードに相当する合成負荷をシステムに加えます。Stress the system with synthetic load that represents the workload you've identified in Step 1: Model.

  • テストを実施して、結果を分析し、アーキテクチャを最適化します。Run tests, analyze results, and optimize your architecture.

  • 最適化したアーキテクチャをデータ センターで展開し、小さいユーザー セットを使用してパイロットをロールアウトします。Deploy your optimized architecture in your data center, and roll out a pilot with a smaller set of users.

  • パイロットの結果を分析して、潜在的なボトルネックを特定し、アーキテクチャを最適化します。必要に応じて、再テストします。Analyze the pilot results, identify potential bottlenecks, and optimize the architecture. Retest if it is required.

  • 運用環境に展開します。Deploy to the production environment.

テストTest

テストは、ワークロードと使用状況特性をサポートするためのシステム設計能力を確立するために不可欠な要素です。SharePoint Server 2013 展開のテスト方法については、「SharePoint Server 2013 のパフォーマンス テスト」を参照してください。Testing is a critial factor in establishing the ability of your system design to support your workload and usage characteristics. See Performance testing for SharePoint Server 2013 for detailed information about how to test your SharePoint Server 2013 deployment.

  • テスト計画を作成するCreate a test plan

  • テスト環境を構築するCreate the test environment

  • テストとツールを作成するCreate Tests and Tools

パイロット環境を展開するDeploy the pilot environment

SharePoint Server 2013 を実稼働環境に展開する前に、パイロット環境を展開して、ファームを徹底的にテストし、ファームが予想ピーク負荷に関する容量とパフォーマンスの目標を満たすことができることを確認する必要があります。特に、大規模展開の場合は、先に、合成負荷でパイロット環境をテストしてから、少数の実ユーザーと実コンテンツでストレスを加えることをお勧めします。少数の実ユーザーを使ってパイロット環境を分析するメリットは、完全に実稼働に移行する前に、使用状況特性とコンテンツの増加に関して立てた前提を検証する機会が得られることですBefore you deploy SharePoint Server 2013 to a production environment, it is important that you first deploy a pilot environment and thoroughly test the farm to make sure that that it can meet capacity and performance targets for your expected peak load. We recommend that the pilot environment is first tested with synthetic load especially for large deployments, and then stressed by a small set of live users and live content. The benefit of analyzing a pilot environment by using a small set of live users is the opportunity to validate some assumptions you made about the usage characteristics and the content growth before you go fully into production.

最適化Optimize

ファーム ハードウェアのスケーリングやトポロジの変更では容量とパフォーマンスの目標を満たすことができない場合は、ソリューションの見直しを検討する必要があります。たとえば、初期要件がグループ作業、検索、およびソーシャル用の単一ファームに関するものだった場合は、検索などの一部のサービスを専用サービス ファームにまとめるか、より多くのファームでワークロードを分散させる必要があります。ソーシャル専用のファームとグループ作業専用のファームを展開するという方法もあります。If you cannot meet your capacity and performance targets by scaling your farm hardware or making changes to the topology, you may have to consider revising your solution. For example, if your initial requirements were for a single farm for collaboration, Search and Social, you may have to federate some services such as search to a dedicated services farm, or split the workload across more farms. One alternative is to deploy a dedicated farm for social and another for team collaboration.

ステップ 4: 展開Step 4: Deploy

テストの最終ラウンドを実施して、選択したアーキテクチャがステップ 1: モデル化で設定したパフォーマンスと容量の目標を達成できることを確認したら、SharePoint Server 2013 ベースの環境を実稼働環境に展開できます。Once you have executed your final round of tests and confirmed that the architecture you have selected can achieve the performance and capacity targets you established in Step 1: Model, you can deploy your SharePoint Server 2013-based environment to production.

適切なロールアウト戦略は、環境と状況によって異なります。SharePoint Server 2013 展開は本書の範囲を超えていますが、容量計画演習から提案されている活動があります。ここで、いくつかの例を示します。The appropriate rollout strategy will vary depending on the environment and situation. While SharePoint Server 2013 deployment generally is outside the scope of this document, there are certain suggested activities that may come out of the capacity planning exercise. Here are some examples:

  • 新しい SharePoint Server 2013 ファームの展開: 容量計画演習では SharePoint Server 2016 の設計と展開に関する計画を実行して確認したはずです。この場合は、ロールアウトが SharePoint Server 2013 の最初の広範な展開になります。容量計画演習で使用されたサーバーとサービスを実稼働環境に移動したり、再構築したりする必要があります。これは、既存のファームに対するアップグレードや変更が必要ないため、最も単純なシナリオです。Deploying a new SharePoint Server 2013 farm: The capacity planning exercise should have guided and confirmed plans for a design and deployment of SharePoint Server 2016. In this case, the rollout will be the first broad deployment of SharePoint Server 2013. It will require moving or rebuilding the servers and services that were used during the capacity planning exercises into production. This is the most straight-forward scenario because there are not any upgrades or modifications needed to an existing farm.

  • Office SharePoint Server 2007 ファームの SharePoint Server 2013 へのアップグレード: 容量計画演習では、既存の需要を満たし、SharePoint Server 2013 ファームの増加した需要と使用量を満たすようにスケール アップ可能なファームの設計を検証したはずです。容量計画演習の一部に、アップグレード プロセスに要する時間、カスタム コードを修正または交換する必要があるどうか、サード パーティ ツールを更新する必要があるかどうかなどを検証するためのテスト移行が含まれていたはずです。容量計画の最終段階で、検証済みの設計、アップグレードに要する時間の理解、およびアップグレード プロセスに最適な作業 (インプレース アップグレードやコンテンツ データベースの新しいファームへの移行など) の計画が得られたはずです。インプレース アップグレードを実施する場合は、容量計画中に、追加のハードウェアまたはアップグレードしたハードウェアが必要なこととダウンタイムに関する考慮事項が判明する可能性があります。計画演習の出力として、必要なハードウェア変更のリストとハードウェアの変更を先にファームに展開するための詳細な計画が含まれていたはずです。容量計画中に検証したハードウェア プラットフォームを稼働させれば、SharePoint Server 2013 へのアップグレード プロセスに進むことができます。Upgrading an Office SharePoint Server 2007 farm to SharePoint Server 2013: The capacity planning exercise should have validated the design for a farm that can meet existing demands and scale up to meet increased demand and usage of a SharePoint Server 2013 farm. Part of the capacity planning exercise should have included test migrations to validate how long the upgrade process will take, whether any custom code must be modified or replaced, whether any third-party tools have to be updated, and so on At the conclusion of capacity planning you should have a validated design, and understanding of how much time that it will take to upgrade, and a plan for how best to work through the upgrade process - for example, an in-place upgrade, or migrating content databases into a new farm. If you're doing an in-place upgrade then during capacity planning you may have found that additional or upgraded hardware will be needed, and considerations for downtime. Part of the output from the planning exercise should be a list of the hardware changes that are needed and a detailed plan to deploy the hardware changes to the farm first. Once the hardware platform that was validated during capacity planning is in place, you can move forward with the process of upgrading to SharePoint Server 2013.

  • 既存の SharePoint Server 2013 ファームのパフォーマンスの向上: 容量計画演習では、現行実装内のボトルネックの特定、そのようなボトルネックの削減または排除方法の計画、および SharePoint Server 2013 サービスのビジネス要件を満たすために改善された実装の検証が支援されたはずです。パフォーマンスの問題を解決する方法には、既存のハードウェア全体でのサービスの再配置のような簡単なものから、既存のハードウェアのアップグレードや新しいハードウェアとサービスの追加まで、さまざまなものがあります。容量計画演習中にさまざまなアプローチをテストして検証し、テスト結果に応じて展開計画を設計したはずです。Improving the performance of an existing SharePoint Server 2013 farm: The capacity planning exercise should have helped you to identify the bottlenecks in your current implementation, plan ways to reduce or eliminate those bottlenecks, and validate an improved implementation that meets your business requirements for SharePoint Server 2013 services. There are different ways in which performance issues could have been resolved, from something as easy as reallocating services across existing hardware, upgrading existing hardware, or adding additional hardware and adding additional services to it. The different approaches should be tested and validated during the capacity planning exercise, and then a deployment plan designed depending on the results of that testing.

ステップ 5: 監視と維持Step 5: Monitor and Maintain

システムのパフォーマンスを維持するには、サーバーを監視して潜在的なボトルネックを特定する必要があります。効率的に監視するためには、ファームの特定の部分に注意を向ける必要があるかどうかを示す需要な指標を理解し、それらの指標の解釈方法を把握しておく必要があります。ファームのパフォーマンスが定義した目標に達していないことが判明した場合は、ハードウェア リソースの追加または削除、トポロジの変更、あるいはデータの保存方法の変更によってファームを調整できます。To maintain system performance, you must monitor your server to identify potential bottlenecks. Before you can monitor effectively, you must understand the key indicators that will tell you if a specific part of your farm requires attention, and know how to interpret these indicators. If you find that your farm is operating outside the targets you have defined, you can adjust your farm by adding or removing hardware resources, changing your topology, or changing how data is stored.

初期段階で環境を監視するように変更可能な設定のリストについては、「SharePoint Server 2013 の監視とメンテナンス」を参照してください。変更が必要かどうかの判断に役立ちます。モニタリング機能を増やすと、使用状況データベースに必要なディスク容量に影響することを覚えておいてください。環境が安定して、この詳細なモニタリングの必要がなくなったら、次の設定を既定の設定値に戻すことができます。See Monitoring and maintaining SharePoint Server 2013 for a list of the settings that you can change to monitor your environment in its early stages, which will help you determine whether any changes are needed. Keep in mind that increasing your monitoring capabilities will affect how much disk space that your usage database will require. Once the environment is stable and this detailed monitoring is no longer required, you may want to reverse the settings below to their default settings.

SharePoint Server 2013 Central Admin インターフェイスに組み込まれた正常性監視ツールを使用した正常性監視とトラブルシューティングの詳細については、以下の資料を参照してください。For more information about health monitoring and troubleshooting using the health monitoring tools built into the SharePoint Server 2013 Central Admin interface, read the following:

SharePoint Server 2016 の監視とレポートMonitoring and Reporting in SharePoint Server

問題の解決とトラブルシューティング(/previous-versions/office/sharepoint-server-2010/ee748639 (v = office))Solving problems and troubleshooting (/previous-versions/office/sharepoint-server-2010/ee748639(v=office.14))

関連項目See also

概念Concepts

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

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

ソフトウェアの境界と制限 (SharePoint Server 2016)Software boundaries and limits for SharePoint Server 2016

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

その他のリソースOther Resources

Capacity management and sizing overview for SharePoint Server 2013Capacity management and sizing overview for SharePoint Server 2013

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