• [アーティクル]

Project Server 2010 でハードウェア アーキテクチャを計画する

 

適用先: Project Server 2010

トピックの最終更新日: 2015-03-09

Microsoft Project Server 2010 では、スループットに大きな影響を及ぼす要因が数多くあります。この要因には、ユーザー数、ユーザー操作の種類、複雑さ、および頻度、操作内のポストバックの数、データ接続のパフォーマンスがあります。ハードウェア アーキテクチャを計画する場合は、ここで説明する要因について慎重に検討する必要があります。Project Server はさまざまな方法で展開および構成できます。そのため、特定のサーバー数でサポートできるユーザー数を簡単に見積もる方法はありません。したがって、Project Server 2010 を運用環境に展開する前に必ず独自の環境でテストを実施してください。

この記事では、Microsoft Project Server 2010 のパフォーマンスと容量に関するテスト済みの制限について説明し、テスト環境とテスト結果に関する情報を提供し、許容範囲のパフォーマンスに関するガイドラインを示します。この記事の情報を使用して、Project Server のスループットの目標を見積もります。

Microsoft Project Server 2010 の容量計画を行う場合は、Project Server 展開のパフォーマンスに影響を及ぼす可能性がある可変要素に留意してください。

Project Server には多くの機能があるため、ハイレベルでは同じように見える展開でも、実際のパフォーマンス特性は大きく異なる場合があります。システム内で予定しているプロジェクト数やユーザー数だけで要求を特徴付けるのでは、十分ではありません。Project Server 展開のパフォーマンスについて検討するには、よりきめ細やかで全体的な方法が必要です。たとえば、ワークロードやその後のハードウェア ニーズは、次の可変要素に関連して異なります。

要因 特性

プロジェクト

  • プロジェクトの数

  • タスクに関する一般的なプロジェクト サイズ

  • プロジェクト レベルのユーザー設定フィールド数

  • タスク間のリンク (依存関係) のレベル

ユーザー

  • ユーザーの同時実行。システムに同時にアクセスするユーザー数、平均負荷、トラフィックの急増。

  • ユーザーのセキュリティのアクセス許可。これは、サーバーがある時点でユーザーに提供する必要があるデータ量と、サーバーが実行する必要があるセキュリティ チェックの複雑さの両方に影響します。

  • ユーザーの地理的分布。ユーザーが地理的に広範な領域に分散している場合、ネットワーク待ち時間が原因で、パフォーマンスが低下する可能性があります。これは使用パターンにも影響し、一日のうちのさまざまな時間帯にサーバーがアクセスされる場合、バックアップ、レポート、Active Directory の同期など、メンテナンス タスクを実行する低トラフィックの時間帯を見つけるのが困難です。

使用パターン

  • ワークロード条件。一般的に使用される機能セット。たとえば、タイムシートを頻繁に使用する展開の特性は、タイムシートを使用しない展開とは異なります。

  • ページ要求間の平均時間。

  • 平均セッション時間。

  • ページのペイロード。 特定のページ上の Web パーツの数、含まれているデータの量。

それぞれの環境のパフォーマンスに影響する可変要素はこの他にも多数あり、各可変要素によって影響を受けるパフォーマンスの分野はさまざまに異なります。この記事で示すテスト結果と推奨事項には、関連する機能やユーザー操作が使用環境に存在せず、使用するソリューションに適用されないものもあります。独自の環境に応じた正確なデータを取得するには、詳細なテストが必要です。

考慮が必要な他の可変要素


  • ユーザーの同時実行: ユーザーの同時実行による負荷は、多くの場合、容量要件を設定する上での重要な要因です。システム内のユーザー数が少ない場合でも、"ピーク" トラフィック時間帯にすべてのユーザーがサーバーに同時にアクセスすることがあります。たとえば、すべてのユーザーが毎週同じ時間にステータス/タイムシートの更新を送信する組織では、その時間帯のパフォーマンスが大幅に低下する可能性があります。ピーク時の使用率が非常に高い場合、データセットに対して推奨されているトポロジにリソースを追加することを計画します。


  • ユーザー ロールの分割: ユーザーを管理者、ポートフォリオ管理者、プロジェクト マネージャー、およびチーム メンバーに割り振ると、各種類のユーザーが多様なデータにアクセスするという点で、展開のパフォーマンスに影響を及ぼします。異なるセキュリティ カテゴリに属するユーザーは、表示できるプロジェクトとリソースの数に関してそれぞれ異なる可能性があります。たとえば、管理者は、プロジェクト センターの読み込み時にサーバー上のすべてのプロジェクトを表示し、リソース センターの読み込み時にはすべてのリソースを表示できます。これに対して、プロジェクト マネージャーが表示できるのは、自身のプロジェクトのみです。この結果、ユーザーはパフォーマンスの低下を感じます。可能であれば、[サーバー設定] > [ビューの管理] で定義するビュー内で適切なフィルターを定義することにより、特定のビューに表示されるプロジェクト、タスク、またはリソースの数を制限することをお勧めします。


  • ユーザーのグローバルな分布


  • 懸案事項、リスク、および成果物: これらのエンティティが多数あると、SQL Server に追加の負荷がかかる場合があります。特に、Project サイトでこれらのエンティティを表示したり操作したりすると、追加の負荷が発生する可能性があります。これらの機能を頻繁に使用する場合は、追加のリソースを SQL Server の展開に割り当てることで、高レベルのパフォーマンスを維持できます。これらの成果物と Project サイト機能が SharePoint のサイトおよびリストの場合、SharePoint のサイトおよびリストの拡張に関するドキュメントを参照してください。


  • カレンダー: プロジェクト、タスク、およびリソースに対してユーザー設定カレンダーを定義できます。これはスケジューリング エンジンに大きな影響を及ぼし、アプリケーション サーバーとデータベース サーバーで大量の CPU を使用します。

一般的なデータセット

このセクションで説明するデータセットは、次の表に示されている可変要素数で特徴付けられます。これらの可変要素で、Project Server のパフォーマンスに影響するすべての要因が表されるとは限りません (たとえば、展開内で使用する傾向がある、機能の混在は表されません)。しかし、適切な容量を判断する上で重要な情報の大部分は表されます。

エンティティ 説明/メモ 小 中 大

1

プロジェクト

100

5000

20000

1

タスク

17125

856250

3425000

1

プロジェクトあたりの平均タスク数

171.25

171.25

171.25

2

タスク トランザクション履歴

特定のタスクに対してステータスが送信および承認される回数

10

100

1000

1

割り当て

22263

1113125

4500000

1

タスクあたりの平均割り当て数

1.3

1.3

1.3

2/3

承認

マネージャーあたりの保留中の更新

50

600

3000

ユーザー

1000

10000

50000

ユーザー設定フィールド

プロジェクト (数式)

3

20

25

ユーザー設定フィールド

プロジェクト (手動)

2

40

50

ユーザー設定フィールド

タスク (数式)

タスク数式フィールドは、タスクごとに計算する必要があるため、パフォーマンスに最も負担をかける傾向があります。

6

12

15

ユーザー設定フィールド

タスク (手動)

4

8

10

ユーザー設定フィールド

割り当ての細分化

50%

50%

50%

ユーザー設定フィールド

リソース

10

20

25

ユーザー設定フィールド

参照テーブルのユーザー設定フィールド

2

15

100

1

タイムシート (年間)

タイムシートを使用するほど、SQL Server で多くのリソースが必要です。

52000

780000

8,320,000

1

タイムシート行

5

10

10

ハードウェアに関する推奨事項

ここでは、パフォーマンスおよび容量に関する全般的な推奨事項を説明します。これらの推奨事項から、各自の要件に適した開始トポロジを特定し、開始トポロジのスケール アウトとスケール アップのどちらが必要かを判断できます。

この記事には、Web フロント エンド サーバー ロール、アプリケーション サーバー ロール、およびデータベース (SQL) サーバー ロールという、Windows Server でセットアップする 3 種類のロールが出てきます。これらはすべて、完全な Project Server 2010 展開のコンポーネントです。Web フロント エンド サーバーは、Project Server にアクセスするユーザーとのインターフェイスとして動作します。アプリケーション サーバーは、Project Server のデータ層への要求を処理し、Project Server 2010 のビジネス ロジックを実装します。最後に、データベース層はデータ ソースであり、Project Server 2010 データベースが格納されています。小規模展開の場合、Web フロント エンド サーバー、アプリケーション サーバー、およびデータベース サーバーの各ロールは、同じ物理コンピューター上にまとめられることがあります。大規模展開の場合は、これらのロールを個別のコンピューターに分ける必要があり、複数の物理コンピューターが同じロールを実行することもあります。

小規模データセットの推奨ハードウェア

このセクションでは、「一般的なデータセット」で示された小規模、中規模、および大規模なデータセット サイズごとに、推奨トポロジを提案します。各データセットの推奨トポロジは、そのデータセット サイズのほとんどの使用パターンで、妥当なパフォーマンスを十分に示すことができます。ただし、この記事の後半に記載されている特定の推奨事項を考慮に入れて、近似のデータセットに対して推奨されたトポロジを、さらに拡張する必要があるかどうかを判断してください。通常、トポロジのパフォーマンス指標を監視し、パフォーマンス特性に満足できない場合は、それに応じて拡張します。

Project Server 2010 は SharePoint Server 2010 と共存するため、追加のリソース (プロセッサ、RAM、ハード ディスク) を使用します。SharePoint Server 2010 のガイドライン要件は、小規模データセットで低頻度に使用する Project Server 2010 のインストールにも当てはまります。しかし、より大きなデータセットと使用パターンの場合は、追加のハードウェア リソースが必要になります。小規模データセットを使用した、スタンドアロン コンピューターでの展開の場合、高レベルのパフォーマンスを実現するには、16 GB の RAM が適切です。さらに、可能であれば、SQL Server を実行している専用のコンピューターにデータベースを配置することによって、データベース サーバーをアプリケーション層および Web フロント エンド層と分けることをお勧めします。

以下の表は、組み込みデータベースを備えた単一サーバー インストールと、ファーム内に 1 つまたは複数のサーバーを含むサーバー ファーム インストールの仕様を示しています。

フロントエンド Web/アプリケーション サーバー

コンポーネント 推奨

プロセッサ

64 ビット、4 コア、各コア最小 2.5 GHz

RAM

開発用または評価用に 4 GB、単一サーバーおよび複数サーバーの運用ファームに 8 GB

ハード ディスク

80 GB

SQL Server

コンポーネント 推奨

プロセッサ

64 ビット、4 コア、各コア最小 2.5 GHz (データセットのサイズが中規模より大幅に大きい場合は 8 コアを推奨します)

RAM

開発用または評価用に 4 GB、単一サーバーおよび複数サーバーの運用ファームに 8 GB

ハード ディスク

80 GB

中規模データセットの推奨ハードウェア

中規模データセットの最小要件は、スケールアウトおよびスケールアップして、追加の負荷に対処できます。スケールアップおよびスケールアウトされたトポロジでは、増加したユーザー負荷およびデータ負荷の対処方法を検討します。

一般的には、十分な数のコンピューターを用意して Web フロント エンド サーバーおよびアプリケーション サーバーをトポロジに追加することで、追加のユーザー負荷およびデータ負荷の対処に備えることができます。Web フロント エンド サーバーおよびアプリケーション サーバーのハードウェア仕様は、ほとんど変わりません。中規模のデータセットおよび使用パターンのニーズに対処するには、4 x 2 x 1 トポロジで十分です。アプリケーション サーバーと Web フロント エンド サーバーをスケールアウトすると SQL Server に追加の負荷がかかるため、メモリと CPU リソースを追加することで補う必要があります。次の SQL Server 仕様で、ほとんどの中規模データセットのパフォーマンス ニーズに対処できます。設計したトポロジがパフォーマンス ニーズを満たすかどうかを判断するには、ステージング環境をセットアップしてトポロジをテストし、パフォーマンス特性を監視する方法が適しています。

フロントエンド Web サーバー

コンポーネント 推奨

プロセッサ

64 ビット、4 コア、各コア最小 2.5 GHz

RAM

開発用または評価用に 4 GB、単一サーバーおよび複数サーバーの運用ファームに 8 GB

ハード ディスク

80 GB

アプリケーション サーバー

コンポーネント 推奨

プロセッサ

64 ビット、4 コア、各コア最小 2.5 GHz

RAM

開発用または評価用に 4 GB、単一サーバーおよび複数サーバーの運用ファームに 8 GB

ハード ディスク

80 GB

SQL Server

コンポーネント 推奨

プロセッサ

64 ビット、8 コア、各コア最小 2.5 GHz (データセットのサイズが中規模より大幅に大きい場合は 8 コアを推奨します)

RAM

32 GB

ハード ディスク

160 GB

大規模データセットの推奨ハードウェア

大規模なデータセットの場合、データ負荷が最も大きなパフォーマンス ボトルネックになります。

通常、大規模なデータセットの場合は、最小でも 4 x 2 x 1 トポロジが必要です。Web フロント エンド サーバーおよびアプリケーション サーバーのハードウェア特性は、通常、小規模データセットおよび中規模データセットで推奨される特性と変わりません。しかし、SQL Server インストールがボトルネックの場合、追加の Web フロント エンド サーバーおよびアプリケーション サーバーへのスケールアウトが制約されることがあります。データ負荷がボトルネックの場合は、Web フロント エンド サーバーおよびアプリケーション サーバーを追加しても、スループットが向上しない可能性があります。

大規模なデータセットで、Project Server 2010 と共存している SharePoint Server 2010 インスタンスも頻繁に使用される場合 (つまり、SharePoint Server 2010 展開を Project Server 2010 機能専用で使用しているわけではない場合)、4 つの Project Server 2010 データベースを SharePoint Server 2010 コンテンツ データベースから切り離して、専用の SQL Server のインスタンスに配置することをお勧めします。

データ スループットがボトルネックの場合は、トポロジの SQL Server 層で追加のリソースが必要です。RAM、CPU、およびハード ディスクの各リソースを追加することで、SQL Server を "スケールアップ" できます。大規模データセット トポロジの SQL Server 層の最小仕様および推奨仕様を、次に示します。

SQL Server の最小要件

コンポーネント 推奨

プロセッサ

64 ビット、8 コア、各コア最小 2.5 GHz (データセットのサイズが中規模より大幅に大きい場合は 8 コアを推奨します)

RAM

32 GB

ハード ディスク

250 GB

SQL Server の推奨要件

コンポーネント 推奨

プロセッサ

64 ビット、8 コア、各コア最小 2.5 GHz (データセットのサイズが中規模より大幅に大きい場合は 8 コアを推奨します)

RAM

64 GB

ハード ディスク

300 GB 以上。レポート データベースを別のデータベース サーバーに切り離します。データをディスクに分割し、優先順位を付けるのが理想です。データ ファイルと SQL Server 2008 トランザクション ログは、別々の物理ハード ディスクに配置します。RAID 5 は、信頼性とスループットのバランスが優れています。

仮想化に関する推奨事項

Project Server 2010 は、仮想マシン上での実行をサポートしています。SharePoint Server 2010 の仮想化に関する推奨事項の大部分は、Project Server 2010 にも当てはまります。SharePoint Server 2010 の仮想化については、「仮想化の計画 (SharePoint Server 2010)」を参照してください。仮想化と Project Server 2010 の詳細については、その内容の大部分が引き続き適用できるため、Project Server 2007 の仮想化ガイドも参考になります。ただし、仮想化が適用される状況では、同じ物理インスタンス上で実行される仮想マシン間での、物理コンピューターのリソースの競合について考慮することが重要です。

注意

仮想マシン上では SQL Server を実行しないでください。仮想マシン上でのリソースの競合は、サーバーのパフォーマンスを大きく低下させることがあります。仮想環境で SQL Server を実行する必要がある場合は、次の設定を使用することをお勧めします。

  1. ネットワーク アダプター:

    • Hyper-V 仮想化を使用している場合は、従来のネットワーク アダプターではなく、仮想ネットワーク アダプターを使用してください。

  2. 仮想ディスク:

    • SQL Server が実行されている仮想マシンでは、ディスクの種類として "パススルー" オプション (動的や固定ではない) を選択することをお勧めします。このオプションを選択できない場合は、動的にサイズ変更される仮想ディスクではなく、固定ディスク サイズを使用してください。

    • ブート ドライブには SCSI ではなく IDE を選択することをお勧めします。

    • データセットの予測される最大サイズと ULS ログ要求に対処するために、十分なハード ディスク容量を割り当てます。

  3. メモリ:

    • SQL Server が実行されている仮想マシンに、割り当てが可能なだけのメモリを割り当てる必要があります。これは、同じ機能を実行している物理サーバーで必要または推奨されるメモリ量と同程度です。

    • ホスト オペレーティング システム用に、少なくとも 2 GB のメモリを確保します。

仮想環境で Web フロント エンド サーバーまたはアプリケーション サーバーを実行しても、仮想環境内での SQL Server の実行のパフォーマンスが低下することはありません。

ネットワークの要件

大部分の Project Server 展開では、ネットワーク帯域幅がパフォーマンスのボトルネックになることはありません。次の表は、ネットワーク コンポーネントの推奨仕様を示しています。一般的な目標として、アプリケーション層と SQL Server 層の間の待機時間が短くなることを目指します。

コンポーネント 小規模/中規模データセット 大規模データセット

NIC の数

1

2

#NIC の速度 (ネットワーク)

100 mbps を超える速度で十分

1 Gb/秒

ロード バランサーの種類

NLB またはハードウェア (両方可)

NLB またはハードウェア (両方可)