Service Manager のパフォーマンス

公開日: 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 のパフォーマンスの善し悪しが最も顕著に表れるのは、次の 3 つの部分です。

• Service Manager コンソールの応答速度。 これは、コンソールで操作を行ったときに、その処理が完了するまでにかかる時間です。

• コネクタのデータ挿入時間。 これは、コネクタが同期しているときに Service Manager でデータをインポートするのにかかる時間です。

• ワークフローの所要時間。 これは、ワークフローが自動的にアクションを適用するのにかかる時間です。

コネクタの初期同期には、かなり長い時間がかかります。たとえば、System Center Configuration Manager との大規模な初期同期には、8 ～ 12 時間ほど必要です。 コネクタの初期同期中は、すべての Service Manager サーバー ロールとプロセスのパフォーマンスが低下する可能性があります。 これは、Microsoft SQL Server データベースである Service Manager データベースにデータが順番に挿入されるためです。 コネクタの初期同期プロセスを速めることはできませんが、初期同期を計画して、Service Manager の運用が開始される前に同期プロセスが完了するようにすることはできます。

初期同期が完了した後も Service Manager は同期を続けますが、変更箇所だけの同期であるため、パフォーマンスに大きな影響はありません。

ワークフローは自動的に発生するプロセスで、 電子メールによる通知、変更要求をアクティブ化した後の処理、テンプレートの自動適用などがあります。

次に、ワークフローのパフォーマンスに関する注意事項を示します。

• 通常、ワークフローの開始から終了までにかかる時間は 1 分ですが、Service Manager サーバー ロールに大きな負荷がかかっているときは、この時間では完了しません。

• また、新しい通知サブスクリプションなどの新しいワークフローを作成する場合は、さらにシステムに負荷がかかります。 新しく作成するワークフローの数が増えるほど、各ワークフローの実行にかかる時間も長くなります。

大量の新規インシデントを作成し、各インシデントで多数のワークフローを作成するなど、システムに大きな負荷がかかる場合は、パフォーマンスが低下することがあります。

System Center 2012 – Service Manager のパフォーマンスが System Center Service Manager 2010 に比べ改善されました。これは、ワークフロー プロセスの応答速度をアップできる新しい ManagmentHostKeepAlive 管理パックによるもので、ほぼすべてのワークフロー プロセスが 1 分以内で完了します。

グループとユーザー ロールの計画は早い段階に行ってください。 グループは少なめに作成し、なるべく小さい単位で作成します。 また、グループを作成する前に、Active Directory ドメイン サービス (AD DS)、System Center Configuration Manager、System Center Operations Manager のデータをデータベースに取り込んでおきます。

ユーザーのアクセスを特定のグループだけに制限するために、グループを作成することがよくあります。 たとえば、人事担当者によって使用されるコンピューターに影響するインシデントなど、インシデントのサブセットを作成する場合を考えます。 ここでは、極秘情報を取り扱う人事部サーバーのグループを表示または変更できるユーザーを特定の担当者だけに制限します。 このためには、まず、すべてのユーザー用のグループ ("すべてのユーザー") と、人事部のコンピューター用のグループ ("人事部サーバー") を作成してから、セキュリティ ロールが両方のグループにアクセスできるように設定する必要があります。 すべてのユーザーを含むグループを作成したことで、Service Manager はこのグループが変更されたかどうかを頻繁にチェックしなければならなくなり、パフォーマンスへの影響は避けられません。 既定では、このチェックは 30 秒おきに実行されます。 非常に大きなグループの場合は、変更のチェックによりシステムに多大な負荷がかかり、応答速度が著しく低下することがあります。

対処法 1:レジストリを変更して、Service Manager によるグループの変更チェック間隔を手動で指定します。 たとえば、グループの変更チェック間隔を 30 秒から 10 分に変更すると、パフォーマンスが大幅に向上します。 ただし、キューとサービス レベル目標は特別な種類のグループであり、同じグループ計算ポーリング間隔を使用します。 そのため、ポーリング間隔の値を大きくすると、キューおよびサービス レベル目標の計算に要する時間が長くなります。

注意
レジストリを間違って編集すると、システムが壊れる可能性があります。 レジストリを変更する前に、コンピューターにある重要なデータをバックアップしてください。

グループの変更のチェック間隔を手動で指定するには

1. Regedit を実行して、HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2012\Common\ に移動します。

2. 「GroupCalcPollingIntervalMilliseconds」という名前の DWORD 値を作成します。

3. この値として、チェック間隔をミリ秒単位で指定します。 入力した値が 6 倍されます。 たとえば、間隔を 10 分に指定する場合は、「600000」と入力します。

4. System Center Management Service を再開します。

   [!メモ]

   
   System Center 2012 R2 Service Manager では、System Center Management サービスが Microsoft Monitoring Agent という名前に変わりました。

対処法 2:Windows PowerShell スクリプトを使って、ユーザー ロールに "ユーザー" などの種類のオブジェクトを追加します。 基本的に、このロールでログオンするアナリストは、"ユーザー" と同じ種類のすべてのオブジェクトにアクセスできます。 この方法を使用すると、大きなグループ ("すべてのユーザー") も、Service Manager に大きな負荷のかかる、このグループのメンバー シップのチェックも必要ありません。 "ユーザー" という種類を "RoleName" ロールに追加するには、Service Manager 管理サーバーで次の Windows PowerShell スクリプトを実行します。 このサンプル スクリプトは、実際の環境に合わせて変更してください。

Windows PowerShell スクリプトを実行して、オブジェクトをユーザー ロールに追加するには

• 次のスクリプトを適宜変更してから、実行します。

# Insert a \"type\" scope in a role  
# Syntax:  
#   AddTypeToRoleScope -server \"put_server_name_here\" -RoleName \"put display name of the role here\" -TypeToAdd \"put display name of the type to add to scope here\"  
# Note:  This is a simple demonstration script without error checking.   
  
# set script parameter defaults  
param ([String]$Server = "localhost", [String]$RoleName="My Analyst Role", [String]$TypeToAdd="User")  
  
$a = [reflection.assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.Core")  
  
$m = new-object Microsoft.EnterpriseManagement.EnterpriseManagementGroup $Server   
  
# Get Type object  
#   Note:  If you need to get a list of all available classes related to (for example) “User”,   use this command:  
#               $m.EntityTypes.GetClasses() | ?{ $_.Name -like '*user*'} | %{ $_.Name}  
$type = $m.EntityTypes.GetClasses() | ?{ $_.DisplayName -eq $TypeToAdd}  
  
# Get role object, and insert the type GUID into scope  
$role = $m.Security.GetUserRoles()  | ?{ $_.DisplayName -eq $RoleName}  
$role.Scope.Objects.Add($type.Id)     
$role.Update()  
  
# Get the value from the database again and validate it is there  
if ( $role.scope.objects.Contains($type.Id) ) {  
    write-host *** Successfully set the scope for role `" $role.DisplayName`" and it now contains all instances of $type.DisplayName `( $type.Name `)  
} else {  
    write-host "There was an error trying to insert the scope into the role."  
}  
  

ビューを作成するときは、可能な限りシステムの "標準" クラスを使用するようにしてください。 インシデント管理など、ほとんどのオブジェクト クラスは、"標準" と "詳細" の 2 種類あります。 標準型のオブジェクトには、アイテムに関連するデータの小さなサブセットへの単純な参照が含まれています。 詳細型のオブジェクトには、アイテムに関連するデータへの複雑な参照が含まれています。 標準型は単純なプロジェクションであり、詳細型は複雑なプロジェクションです。 詳細型のオブジェクトの多くは、通常ビューに表示されないフォーム内の各フィールドを埋めるために使用します。 詳細型のオブジェクトに基づいてビューを作成すると、ビューを開くときに、Service Manager によってデータベースが照会され、大量のデータが読み取られます。 しかし、読み取られたデータのうち、実際に表示または使用されるデータはごくわずかです。

定義したビューでパフォーマンスの問題が発生し、そのビューで詳細型のオブジェクトを使用している場合は、標準型に切り替えてください。 または、ビューで使用する特定のデータだけを含む独自のプロジェクション型を作成します。 詳細については、「関連するプロパティ条件を使用するビューの作成 (型プロジェクション): ソフトウェア ビューの例」ブログ エントリ (SCSM エンジニアリング チーム ブログ) を参照してください。

Service Manager データベースのパフォーマンスは、さまざまな要素の影響を直接受けます。たとえば、Service Manager コンソールによるデータの同時読み取りまたは書き込み数、グループの変更のチェック間隔、コネクタによって挿入されるデータなどに左右されます。 詳細はこのドキュメントで説明しています。 次に、その要点を示します。

• 標準の展開環境で十分な応答速度を得るためには、Service Manager データベースをホストする管理サーバーに最低 8 ギガバイト (GB) の RAM が必要です。

• Service Manager データベースをホストするコンピューターには、少なくとも 8 つの CPU コアが必要です。

• ログ ファイルとデータ ファイルを別の物理ディスクに隔離すると、パフォーマンスが向上します。 また、tempdb を Service Manager データベースとは別の物理 RAID ドライブに移動すると、さらにパフォーマンスを改善できます。 可能な場合は、Service Manager データベースのホストに RAID 1+0 ディスク システムを使用してください。

• 小さいサイズの Service Manager データベースを作成して、自動拡張の増大幅を特に小さく設定すると、パフォーマンスが低下する場合があります。

Service Manager ジョブ エイド ドキュメント セット (SM_job_aids.zip) に含まれている Service Manager サイズ測定ヘルパー ツールを参照してデータベースのサイズを見積もり、最終的なサイズに最も近いサイズでデータベースを作成します。 これにより、データベースの自動拡張にかかる時間を短縮してパフォーマンスの低下を防ぐことができます。

同様に、データベースのパフォーマンスを向上させる他のベスト プラクティスもすべて活用できます。 たとえば、高性能のディスク サブ システムを使うことで、テーブルのグループを該当するファイルグループに分割して、別の物理ドライブに移動できます。

Service Manager 管理サーバーのパフォーマンスは主に同時使用するアクティブな Service Manager コンソール の数に左右されます。Service Manager のすべてのロールが管理サーバーと通信するので、同時使用するコンソールを多数展開する場合は、管理サーバーを追加することを検討してください。 管理サーバーには 8 GB の RAM が必要です。 1 つの CPU コアで 10 ～ 12 のアクティブ コンソールをサポートすると想定した場合、1 つの管理サーバーに少なくとも 4 つの CPU コアが必要です。

Service Manager コンソールのパフォーマンスは、主にアナリストが通常開いているフォームの数と、ビューで取得されるデータの量の影響を受けます。Service Manager コンソールをインストールするコンピューターには 4 GB の RAM が必要です。 大量のデータを取得するビューがある場合は、RAM を追加する必要があります。Service Manager コンソールをインストールするコンピューターには、少なくとも 4 コアの CPU が必要です。Service Manager コンソールはエンド ユーザー アプリケーションなので、大量のリソースを消費していると思われる場合は再起動することをお勧めします。Service Manager コンソールで、メモリに大量の情報がキャッシュされ、全体的なメモリの消費量に影響することがあります。

データ ウェアハウスのパフォーマンスは、データを同時に送信している Service Manager 管理サーバーの数、保存されるデータの量やデータの保管期間、データの変更率、ETL (抽出、変換、読み込み) の頻度など、さまざまな要素に直接影響されます。 データ ウェアハウスに保存されるデータの量は、時間の経過と共に増大します。 そのため、不必要になったデータは必ずアーカイブしてください。 また、ETL プロセスの BatchSize 設定もデータ ウェアハウスのパフォーマンスに影響します。

ログ ファイルとデータ ファイルを別の物理ディスクに隔離すると、パフォーマンスを向上できます。 ただし、1 つのディスクに複数のログ ファイルを配置しないでください。 同様に、tempdb を他のデータベースとは別の物理ディスクに配置すると、より高いスループットが得られます。 また、異なるデータベースをそれぞれ別々の物理ディスクに配置すると、パフォーマンスを改善できます。 可能な場合は、データ ウェアハウスのホストに RAID 1+0 ディスク システムを使用してください。 データ ウェアハウス データベースをインストールするコンピューターには、最低 8 GB の RAM が必要です。 Operations Manager または Configuration Manager からもデータ ウェアハウスのデータ ソースを収集する場合は、データベース用の RAM をさらに増やす必要があります。 データ ウェアハウスをホストする SQL Server により大きいメモリを搭載し、データマート データベースとリポジトリ データベースを同じコンピューターに配置すれば、さらに高いパフォーマンスが得られます。 ただし、展開トポロジ内のコンピューターが 4,000 台以下の場合は、4 GB で十分です。 データ ウェアハウス データベースをインストールするコンピューターには、少なくとも 8 つの CPU コアが必要です。 さらにコアを増やせば、ETL とレポートの両方のパフォーマンスが向上します。

システム内のすべてのデータベースを小さなサイズで作成し、自動拡張の増大幅を特に小さく設定すると、パフォーマンスが低下する場合があります。Service Manager ジョブ エイド ドキュメント セット (SM_job_aids.zip) に含まれている Service Manager サイズ測定ヘルパー ツールを参照してデータベースのサイズを見積もり、最終的なサイズに最も近いサイズでデータベースを作成します。データベースを自動増加する回数を減らすことでパフォーマンスが改善されます。

Service Manager には、ファイルグループのサポート機能が組み込まれています。 別々のハード ドライブにファイル グループを配置すると、このサポート機能の効果が大きくなります。の詳細については ファイル グループのベスト プラクティスについては、SQL Server のマニュアルを参照してください。

データ ウェアハウス サーバーのパフォーマンスは、データ ウェアハウスに登録されている Service Manager 管理サーバーの数と展開規模、データ ソースの数に影響されます。 データ ウェアハウス サーバーには通常 8 GB 以上の RAM が必要ですが、 複数の Service Manager 管理サーバーがデータ ウェアハウスにデータを挿入する高度な展開環境の場合は、さらに RAM を増設すると高いパフォーマンスが得られます。 すべての要件を満たすことが不可能な場合は、SQL Server を実行しているコンピューターのメモリを最優先させてください。 パフォーマンスの問題を未然に防ぐには、少なくとも 8 つの CPU コアが必要です。

セルフサービス ポータルは、インシデントやサービス要求の登録を簡単にするように設計されています。 何千人ものユーザーが同時に使用することは想定していません。

セルフサービス ポータルのパフォーマンス テストは、標準的な "月曜日の朝" を想定した環境で行われました。特に、月曜日の朝に数百人のユーザーが 5 ～ 10 分の間にログインでき、許容できる範囲の応答速度 (4 ～ 5 秒未満) でインシデントを開けることを目標にしました。 この目標は、このドキュメントで推奨されている最小ハードウェア要件で達成することができました。

Service Manager で対応できるサービス レベル目標の数は、特に決まっていません。 たとえば、組織内で発生するインシデントの標準的な数が数件の場合は、通常よりも多い数のサービス レベル目標に対応できます。 しかし、大量のインシデントを処理する場合は、サービス レベル目標を減らすか、必要に応じてハードウェアとソフトウェアを追加する必要があります。 コンピューターが 50,000 台の標準的な Service Manager 構成の場合は、サービス レベル目標を 5 つ以上作成しないよう心がけてください。 これ以上のサービス レベル目標を作成することも可能かもしれませんが、 状況は組織ごとに違うため、絶対に超えてはならないサービス レベル目標の数を具体的に示すことはできません。 サービス レベル目標の数によってパフォーマンスが低下する場合は、このガイドの「展開環境の構成」にあるとおり、1 つ上の規模の展開構成を採用することをお勧めします。