この間、自分のコンピュータに取り込まれたWindows Mediaのライブラリを見ていたら、
90年代ミュージックしか入っていないことに気がつきました。
21世紀のWindowsを使っているのに、ライブラリは20世紀のまま!!
もしかしたら、「懐かしのメロディー集」とかいうタイトルで、スーパーの2Fとかで売れそうな感じです。
(もちろん、ライブラリに入っている曲は個人の範囲で楽しませていただいております)
今日は、FIM2010のサーバー構成について考えてみたいと思います。
以前、FIMのコンポーネント紹介をさせていただきました(FIM2010のインストール(2)参照)。
そのときには、
■ ILM Synchronization Service
■ ILM Service
■ ILM Portal
■ ILM Certificate Management Service
の4種類のコンポーネントがあると紹介しましたね。
実際にインストールするときには、
■ ILM "2" Synchronization ServiceをインストールすることでILM Synchronization Service
■ ILM"2" ServerをインストールすることでILM ServiceとILM Portal
がそれぞれ実装されます。
(ILM"2"Certificate Management Service Server and CA Modulesをインストールすることで
ILM Certificate Management Serviceが実装されますが、ここでは話題にしません)
そのため、FIM2010を実装するときには、
・すべての役割を1台のサーバーにまとめてインストールする
・ILM Synchronization Serviceと、ILM Service / ILM Portalを別々のサーバーにインストールする
という選択肢があります。
ILM Synchronization ServiceはIDの同期、ILM Service / ILM PortalはWebサービスと
役割が異なるため、サーバーに求められる特性も異なります。
そのため、実際の運用では別々のサーバーに実装することが一般的になると思います。
ちなみに、両者を別々のサーバーに配置するときには、Active Directoryにサービスの委任を
設定しておく必要があります。具体的にはsetspnコマンドを使うのですが、
これについてはマイクロソフトTechNetサイトの「Installing the ILM Service and ILM Portal on separate servers」
の項目を参照してください。
そのため、ILM Service / ILM Portalのサーバーは、ネットワーク負荷分散(NLB)を使えば
ポータルアクセスの負荷分散と共に可用性を高める構成もできますね。
一方、ILM Server / ILM PortalとILM Synchronization Serviceは共にSQL Serverにデータベースを持ちます。
そのため、可用性を高める構成を考えるのであれば、SQL Serverのクラスタ化も考えておく必要があります。
こうなると、ILM Synchronization Serviceについても可用性を高める構成が必要なのではないか？と考えるでしょう。
私もそう思います。
しかし、この部分についてはまだ見えてこない、というのが正直なところです。
あるカンファレンスでは、ILM Synchronization Serviceそのものを二重化するのではなく、
サービス的には何の連携もない、全く別個のスタンバイサーバーを 用意しておいて、
障害時には自分で切り替えるような方法を紹介していました。
しかし、具体的にどのように配置するべきなのか、などのベストプラクティスはこれから考えられていくのではないかと思います。
(私も少し考えてみましたが、あっという間に眠くなってしまいました…)
何かわかりましたら、またご紹介します。
コメント
MIIS/ILM2007のころからのテーマですね。プロビジョニング製品の特性としてどうしてもバッチ処理中心となるので即時切替の必要性は薄いと考えられます。特にMIIS/ILMは中小規模ユーザへの導入が中心となるでしょうから、これまであまり冗長性に関する考慮がなされて来なかったといえると思います。他の大規模向け製品での実装では同期先毎にサーバを分割したり、負荷分散装置でバランシングして結果として冗長性を確保することが多いように感じます。これはどちらかというと耐障害性というよりも性能確保、という意味合いが強いのですが、そうでもしないと多数のオブジェクトの同期が一回の夜間バッチで完了しない、という大規模ユーザ特有の課題を解決するためのものです。現在のILMの実装だとキーファイルがネックになり同様の実装は難しそうですが、今後大規模ユーザへ対応して行く中で対策がなされるのかも、と期待したりしています。
確かに、プロビジョニングの処理はバッチ処理中心になりますね。そう考えると冗長性のことよりも、時間内に処理を終了させるために必要な構成としてNLBを利用するというケースが現実的ですね。私もまだわかりませんが、セキュリティ製品(Forefornt)としての位置づけになると、冗長構成が必要になってくるシナリオも出てくるかもしれないと考えています。ただ、現時点では、おっしゃるとおり実装は難しそうな気がします。