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

重要

このバージョンのService Managerはサポート終了に達しました。 Service Manager 2022 にアップグレードすることをお勧めします。

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

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

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

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

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

仮想マシンの役割

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

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

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

• 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 分以内に実行が完了しました。

organizationでサポートされるコンピューターとコンソールの数が 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管理サーバーの間にネットワーク待機時間が導入されました。

注意

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

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

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

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

  注意

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

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

次の手順

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