2010年1月5日火曜日

FIM2010のパフォーマンス その3

前回からしばらく間があいてしまいましたが、紹介した環境下でのFIMの各構成要素毎のパフォーマンス測定結果およびボトルネックの考慮に関する情報です。
また、後半ではFIMのサイジングに関する考慮点を紹介します。

参考情報
・各サービスのリソース使用状況
http://blogs.msdn.com/darrylru/archive/2009/10/09/fim-2010-performance-testing-hardware.aspx
・FIMのサイジング
http://blogs.msdn.com/darrylru/archive/2009/10/22/fim-2010-performance-testing-scale-load.aspx

■各構成要素毎のパフォーマンス測定結果
◆Synchronization Service
・概要
 基本的にディスクの性能がすべてです。

・Synchronization Serviceによるリソース使用状況
 Synchronization Serviceが動く際のリソースの使用状況のカウンタです。Fドライブ(SQL Serverのデータ領域)へのアクセスが際立ちます。一部振りきってしまっている部分もあるので、結果的にこの部分がボトルネックになるということだと思います。













◆FIM Service
・概要
 やはりこちらもSQL Serverがキーポイントになりますが、こちらは主にSQLのクエリ処理が中心となるのでディスクに加えてメモリサイズやCPU性能が効いてきます。(都度SQL Serverに問い合わせに行くので大量のSQLトランザクションが発生しているはず)

・FIM Serviceによるリソース使用状況
 FIM Serviceが動く際のリソースの使用状況のカウンタです。メモリおよびFドライブ(SQL Serverのデータ領域)へのアクセスが際立ちます。一部振りきってしまっている部分もあるので、結果的にこの部分がボトルネックになるということだと思います。














 更に、このケースではFIM ServiceとSQL Serverの同居構成なので各サービス毎のCPUの使用状況を深堀りしてみます。















黒色でハイライトされているのがSQL ServerによるCPUの使用なので、このグラフからも主にSQL Serverに対して多くのリソースの割り当てを行うことが重要だということが読みれます。


■サイジングに関する考察
どのくらいのユーザ数ならこんなトポロジやこの程度のマシン性能、といったバシっとした情報が紹介されているわけではありませんが、FIMを導入するうえで規模(スケール)と負荷(ロード)について考慮すべきポイントが紹介されています。

◆規模(スケール)
 FIMを含め基本的に各IdM製品について言えることですが、どれだけのオブジェクトをハンドリングする必要があるのか?が最大のポイントになります。ということで、FIMでは何をするとオブジェクトの数が変動するのか?についての考察が重要になります。

 まず、ポータルの導入によるエンドユーザに対するオブジェクト管理権限の委譲が最大のポイントとなります。委譲する範囲によっては実際の人事上の従業員や組織数を大幅に上回る数のオブジェクトを管理する結果となることも考えられます。実際マイクロソフトにおいては150,000以上のユーザと400,000以上のグループを使用しているそうです。まだ同時にこの問題はIdMだけでなくレポジトリ(Active DirectoryやLDAPなど)のサイジングにも影響を及ぼす問題なので十分に考慮が必要ということが出来ます。

 次に、これはグループオブジェクト(およびメンバシップ)とFIMが内部で管理するSETオブジェクトの数に関連する問題ですが、例えばユーザの属性値を基準としたダイナミックなグルーピングを行うかどうか、行うとしたらどのような種類および数になるのか、について十分な検討が必要となります。

 また、コンピュータオブジェクトなどのカスタムオブジェクトの管理の有無についてもオブジェクト数の算出に大きく影響を与えます。

 最後にFIMが内部で使用するポリシーオブジェクト(MPRやActionFlow)についても考慮が必要です。コードレスプロビジョニングを使うことによりそれ自体がFIM上のオブジェクトである(つまり、ILMSDBとの同期対象となる)ERE(Expected Rules Entry)やDRE(Detected Rules Entry)が作成されるので、それらのオブジェクトをハンドリングするオーバーヘッドについても考慮が必要となります。

 まとめると、以下の点について事前に十分考慮し、実際に管理する対象オブジェクトの数を算出することが必要となります。
 ・エンドユーザへの権限委譲
 ・ダイナミックグルーピング
 ・カスタムオブジェクト
 ・ポリシーオブジェクト


◆負荷(ロード)
 IdMシステムの規模感が判明した後は各コンポーネントに対してどの程度の負荷がかかるのかの算定が必要になります。負荷は発生しえるトランザクションの種類と数から算出することになりますので、ここではFIMに対してどのようなトランザクションが発生しえるのか?について確認して行きます。

 具体的には下記の種類のトランザクション(オペレーション)の数を定義することが必要であると記載されています。
・グループへの参加登録や登録解除リクエスト
・スタティックもしくはダイナミックグループの作成リクエスト
・セキュリティグループと配布グループの内訳
・パスワードリセットのための事前登録やパスワードリセットのリクエスト
・FIMクライアントがインストールされているコンピュータの数(クライアントは定期的にログオン時に登録が必要かどうかをチェックするため)
・ユーザがグループ管理を行う際に主としてポータルを使うか、Outlookを使うか?(Outlookを使う場合メールを経由するため、Exchangeサーバへのポーリングを行うメールリスナーへの負荷を考慮する必要があるため)
・企業内の利用パターン(ログインのピーク時間帯とピーク時の集中率)

 これらの事項について確認し、VSTSなどを使って負荷試験をして実際に使用する各ハードウェアのスペックなどを決定していく、ということになります。

2 件のコメント:

  1. お世話になっております。ういこうです。ご指摘のとおり、FIM に限らず、ILM もまさにボトルネックになるのは Disk IO です。ILM と SQL を同じマシンに構築する際、RAID などにしていても、同じ物理ドライブであり、かつ IO 処理速度が遅いデバイスであればデッドロックが発生します。この点は非常に注意が必要です。(実際にそうした事例があります…。)しかしいつもすばらしい記事をありがとうございます。もう私たちが書くネタがないくらいです!今後ともよろしく願いします!

    返信削除
  2. ういこさん
    コメント&情報ありがとうございます。
    今後も頑張っていきますので、よろしくお願いします!

    返信削除