Service Manager のハードウェア パフォーマンスを計画する

System Center - Service Manager のパフォーマンスの重要な部分は、組織のニーズを処理するために計画されているハードウェア構成と展開トポロジによって異なります。 次のセクションでは、適切なハードウェア パフォーマンスを計画する際に考慮する一般的なガイドラインを示します。

ハードウェアのパフォーマンス

Service Manager で最も顕著なハードウェアのボトルネックを次に示します。Service Manager データベースのデータの負荷と量は大きくなります。

1. 最も頻繁に見られるボトルネックは、Microsoft SQL Server を実行するコンピューターのメモリと I/O です。 リソースがある場合は、より多くのメモリと高速の I/O サブシステムに投資して SQL Server I/O を改善することで、パフォーマンスが向上します。
2. 管理サーバーに接続するコンソールが多数あると予想される場合は、管理サーバー用の追加の CPU とメモリに投資するか、セカンダリ Service Manager 管理サーバーをインストールすることで、ピーク時の負荷を処理するためのパフォーマンスを向上させることができます。

このマニュアルに記載されている各ロールの推奨最小ハードウェアを目安にしてください。

仮想マシンの役割

多くの組織では、Windows Server アプリケーションのホストに仮想マシンを使用しています。 管理サーバーやデータ ウェアハウス サーバーなどの Service Manager サーバーの役割は例外ありません。 仮想マシンを使ってすべてのサーバー ロールを仮想化する場合もあれば、仮想コンピューターと物理コンピューターを組み合わせる場合もあります。

組織のニーズは本質的に一意であるため、特定の仮想と物理コンピューターの比率はお勧めしません。 ただし、このマニュアルに記載されている各ソフトウェア ロールの最小ハードウェア要件は、物理コンピューター用です。 ソフトウェアの役割を仮想化する場合は、各仮想コンピューターに追加のハードウェア リソースがあることを確認する必要があります。

次の計画ガイダンスに従っていない場合、データベース サーバーは仮想マシンのパフォーマンス低下に対して脆弱です。

• Hyper-V 環境での SQL Server の実行。
• SQL Server をホストする仮想マシンでダイナミック ディスクを使用しないでください。 必ず固定サイズの仮想ハード ドライブまたはパス スルーを使用してください。
• Hyper-V では、ゲストごとに 4 つの仮想 CPU しか使用できないので、コンソールが多数ある場合は Service Manager サーバーが制限される可能性があります。

Service Manager ベースライン テストの結果

Service Manager は、物理コンピューターの形式で推奨されるハードウェアを最小限に抑えたさまざまな展開シナリオを使用して、パフォーマンスとスケーラビリティに関するベースライン テストが行われています。 具体的には、事前に設定されたデータベースと、Service Manager コンソールでインシデントと変更要求をループで作成および更新するシナリオをテストしました。

テストは、次の 2 通りの環境で行いました。

• テスト 1 は、20,000 台のコンピューターと 20,000 人のユーザー、必要な構成アイテム約 250,000 個で構成され、データベースには合計約 250 万行あります。 テスト 1 には、40 個のアクティブな Service Manager コンソールも含まれていました。
• テスト 2 は、50,000 台のコンピューターと 50,000 人のユーザー、必要な構成アイテム約 700,000 個で構成され、データベースには合計約 600 万行あります。 テスト 2 には、80 個のアクティブな Service Manager コンソールも含まれていました。

テストの結果は次のとおりです。

• コンピューター 50,000 台の構成で、目標の応答時間を達成するためには、SQL Server のメモリを 8 ギガバイト (GB) から 32 GB に増やす必要がありました。
• コンピューター 20,000 台の構成では、1 時間に 200 件のインシデントと 50 件の変更要求が、コンピューター 50,000 台の構成では 1 時間に 500 件のインシデントと 125 件の変更要求が生成され、それぞれのインシデントと変更要求で 3 ～ 4 個の通知サブスクリプションとテンプレートが処理されました。
• 通知サブスクリプションの処理やテンプレートの適用などのワークフローは、生成される作業アイテム 1 つにつき、概ね 1 分以内に実行が完了しました。

サポートされているコンピューターとコンソールの数が 20,000 台未満で、ワークフロー数が少ない場合は、Service Manager の一部の役割が仮想コンピューターでホストされている場合でも、Service Manager のパフォーマンスを許容できる必要があります。

ただし、Service Manager データベースにサポートされているコンピューターを追加する予定がある場合は、このドキュメントに記載されている最小要件を超えて、Service Manager データベース サーバーの RAM の量を増やすことを計画する必要があります。 たとえば、ベースライン テストでは、20,000 台のコンピューターのレコードを含む Service Manager データベース サーバーに 8 GB の RAM がインストールされました。 サポートするコンピューターを増やす場合は、10,000 台ごとに 8 GB の RAM を増設する必要があります。 したがって、合計 50,000 台のコンピューターをサポートする場合は、32 GB の RAM が必要になります。 コンピューター 50,000 台の構成で 32 GB の RAM を搭載した SQL Server コンピューターを使用したテストでは、コンピューターを追加する前に比べても劣化が見られない状態にまでパフォーマンスが改善されました。

ネットワーク待ち時間についても、ベースライン テストを行いました。 Service Manager コンソールと Service Manager 管理サーバーの間にネットワーク待機時間が導入されました。

Note

Service Manager データベース サーバーと Service Manager 管理サーバーは、待ち時間の短い LAN 上に存在する必要があります。Service Manager データベース サーバーと Service Manager 管理サーバーの間のネットワーク待ち時間は、Service Manager のパフォーマンスが大幅に低下する可能性があります。

その他のテスト結果は次のとおりです。

• ネットワーク待機時間が 100 ミリ秒 (ミリ秒) 未満であった場合、Service Manager コンソール全体の応答時間は良好でした。

• ネットワーク待機時間が 150 ミリ秒から 200 ミリ秒の場合、パフォーマンスは使用可能と見なされ、一部のシナリオでは応答時間が最大 40% 低下しました。 待機時間が 150 ミリ秒から 200 ミリ秒の間の場合は、組織の主要なシナリオを評価し、リモート デスクトップ接続 (RDC) がより適切なオプションであるかどうかを判断することを計画する必要があります。

  Note

  Service Manager コンソールでサービス マップを拡張すると、待機時間が長くなっていました。

• ネットワーク待ち時間が 200 ミリ秒を超えると、Service Manager コンソール全体の応答時間が低いと観察されました。 待ち時間が 200 msec より長い場合は、通常の業務で RDC 接続または他の同様のリモート アクセス ソリューションを使用することを検討してください。 ただし、管理作業は頻繁に行わないので、管理作業でリモート アクセスを使わなくてもよい場合もあります。

次のステップ

• Service Manager ソフトウェアのパフォーマンスを計画する際に考慮する一般的なガイドラインを読むには、 Service Manager のパフォーマンスを確認してください。