ハードウェアのパフォーマンス
公開日: 2016年7月
対象: System Center 2012 SP1 - Service Manager、System Center 2012 R2 Service Manager、System Center 2012 - Service Manager
System Center 2012 – Service Manager のパフォーマンスで重要な点は、組織の業務を遂行するのに十分なハードウェア構成と展開トポロジを計画することです。 次に、ハードウェアで適切なパフォーマンスを得るための一般的なガイドラインを示します。
ハードウェアのパフォーマンス
Service Managerの次のハードウェア ボトルネックは、 Service Manager データベースの負荷とデータ量が非常に大きな場合に顕著になります。
最も頻繁に見られるボトルネックは、Microsoft SQL Server を実行するコンピューターのメモリと I/O です。 リソースがある場合は、メモリを増設し、高速の IO サブ システムを導入すると、SQL Server の I/O のパフォーマンスが向上します。
1 台の管理サーバーに多数のコンソールを接続する場合は、負荷が最大になったときのパフォーマンスを改善するために、管理サーバーに CPU とメモリを追加するか、2 台目の Service Manager 管理サーバーを設置します。
このマニュアルに記載されている各ロールの推奨最小ハードウェアを目安にしてください。
仮想マシンのロール
多くの組織では、Windows Server アプリケーションのホストに仮想マシンを使用しています。 Service Manager サーバー ロールも例外ではありません。 仮想マシンを使ってすべてのサーバー ロールを仮想化する場合もあれば、仮想コンピューターと物理コンピューターを組み合わせる場合もあります。
組み合わせる場合の仮想コンピューターと物理コンピューターの比率は、組織のニーズによって異なるので、特に決まりはありません。 ただし、このマニュアルに記載されている各ソフトウェア ロールの最小ハードウェア要件は、物理コンピューター用です。 ソフトウェア ロールを仮想化する場合は、各仮想コンピューター用に追加のハードウェア リソースが必要になります。
次の計画ガイドラインに従わないと、仮想マシンのデータベース サーバーのパフォーマンスが著しく低下する可能性があります。
『Running SQL Server 2008 in a Hyper-V Environment (SQL Server 2008 を Hyper-V 環境で実行する) 』 (SQL2008inHyperV2008.docx) を参照してください。
SQL Server をホストする仮想マシンでダイナミック ディスクを使用しないでください。 必ず固定サイズの仮想ハード ドライブまたはパス スルーを使用してください。
Hyper-V では、ゲスト 1 つにつき 4 つの仮想 CPU しか使用できません。そのため、コンソールが多数ある場合は、 Service Manager サーバーの利用が制限されることがあります。
Service Manager のベースライン テスト結果
Service Manager のパフォーマンスとスケーラビリティのベースライン テストは、推奨最小ハードウェア要件を満たす物理コンピューターを使用したさまざまな展開環境で行いました。 予めデータを入力しておいたデータベースを使い、 Service Manager コンソールでインシデントと変更要求を作成、更新する一通りのプロセスを実行しました。
テストは、次の 2 通りの環境で行いました。
テスト 1 は、20,000 台のコンピューターと 20,000 人のユーザー、必要な構成アイテム約 250,000 個で構成され、データベースには合計約 250 万行あります。 また、アクティブな Service Manager コンソールが 40 個あります。
テスト 2 は、50,000 台のコンピューターと 50,000 人のユーザー、必要な構成アイテム約 700,000 個で構成され、データベースには合計約 600 万行あります。 また、アクティブな Service Manager コンソールが 80 個あります。
テストの結果は次のとおりです。
コンピューター 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 管理サーバーの間で発生させました。
[!メモ]
Service Manager データベース サーバーと Service Manager 管理サーバーは、待ち時間の短い LAN に設置する必要があります。 Service Manager データベース サーバーと Service Manager 管理サーバー間のネットワーク待ち時間によって、 Service Manager のパフォーマンスが大幅に低下する可能性があります。
その他のテスト結果は次のとおりです。
ネットワーク待ち時間が 100 ミリ秒未満 (msec) の場合は、全体的に Service Manager コンソール で良好な応答速度が得られました。
ネットワーク待ち時間が 150 ～ 200 msec のときは、環境によって応答速度が最大 40% 劣化しましたが、パフォーマンスは実用に耐え得る範囲でした。 待ち時間が 150 ～ 200 msec の場合は、組織の重要な業務での実用性を評価し、リモート デスクトップ接続 (RDC) を使用するべきかどうかを検討してください。
[!メモ]
Service Manager コンソール でサービス マップを拡張したときは、待ち時間に関係なく応答が遅くなりました。ネットワーク待ち時間が 200 msec を超えると、 Service Manager コンソール の応答時間が長くなりました。 待ち時間が 200 msec より長い場合は、通常の業務で RDC 接続または他の同様のリモート アクセス ソリューションを使用することを検討してください。 ただし、管理作業は頻繁に行わないので、管理作業でリモート アクセスを使わなくてもよい場合もあります。