管理エージェント（MA）っていくつまで作っちゃえる？
皆さんこんばんは。今東京は夜の 23 時です。
あと 30 分で US と EMEA (ヨーロッパ)、India とのテレカンが始まります。
私は日本語の言霊をこよなく愛していますので、英語のテレカンと思うと脳みそが鼻から出てきそうになるほど緊張します。
なので、気持ちを落ち着かせつつこのブログを書いております。
なぜか「ノーマネーでフィニッシュです (※ 最近、私たち ILM チームで流行り始めた言葉です…) 」という言葉が頭をぐるぐる回っていますがどうしたらいいでしょう。
きっとこれは誕生日の日に虫歯でもないのに勝手に前歯の神経が死んで、すごい痛くてしょうがないから現実逃避をしてるんでしょうね。
さて、今日の話題ですが、まだ GALSYNC についての内容は確認を進めているので、ブログに紹介させていただくのはもう少し先になりそうです。
やはり、ILM に限らず、サーバプロダクトはお客様それぞれのニーズによって、システム設計が大きく異なります。これはすなわち、最大公約数的な情報が少ないということにもつながります。幾つか私たちもこれまでお客様から頂いた事例ベースでテストパターンを試しているのですが、GALSYNC、奥が深いです…。
というわけで今日は軽めに、「管理エージェント（Management Agent = MA）っていくつまで作っちゃえるワケ？！ 」という話題からいかせて頂こうと思います。
これも先日、社内の ILM のディスカッション トピックに出ていた内容です。
たとえば激しく MA を作ったとします。さて、ILM 君はいくつまで MA をサポートしてるのでしょう？
答えは以下の通りです。
ILM 2007 FP1 … 1023
ILM 2 … 1023
はい、ILM2 になっても変わりません。**上限は 1023 個**です。
でも、これは理論値であり、実際には各 MA の設定に必要な情報なども加算しますと、各 MA オブジェクトごとにメモリの使用状況が変わりますし、OS にはメモリだけではなく、リソースという概念もありますので、この観点からいえば、恐らく 1023 になる前にリソース不足が通知される可能性が高いでしょう。
また、Import – Provisioning などの整合性などを考えると、MA の数を 100 個も作るのは安定した運用とはいえません。
何か恐ろしいことが発生するかもしれないというリスクが高くなると思います。
では、MA のメタボ状態をどうにかしたい場合どうすればいいか。
たとえばMA を大量に作らなくてはいけないという問題に対する解決策が複数の ILM サーバーを使用することだった場合を考えて見ましょう ( ※) 。
でもこれは余り言い解決策ではありません。なぜなら、集中化された ID データストアを持たない、つまりそれぞれのアプリケーション サイトのインスタンスで独自の ID データ ストアを使用するアプリケーションが大量に存在することになるからです。
これでは、アプリケーション数にアプリケーションのインスタンス数をかけた場合、管理エージェント数は軽く 1000 を超えてしまいます。
やはり各 ILM サーバー上の管理エージェント数を減らすための解決策としては、ILM サーバーを層状にスタックし、複数の管理エージェントを、ID 情報をすぐ上のレベルの ILM サーバーから取得する状態にした複数のサーバーをまたがる形でアプリケーション レベルで配布するといった対処がよいでしょう。
ただこれもベストではありません。
同期対象として、再設計など大幅な見直しも行うことも大切です。
なぜなら、問題が発生してからでは遅いからです。
サーバ製品でお問い合わせを頂いていると非常に多いパターンとしては、設計としてはまずいとわかっていながらも運用を続けた結果、取り返しのつかないことになるというものです。
結果的にこれは、高い高いツケを払うことになりかねません。
確かに見直し、設計変更などはコストがあるように見えるかもしれませんが、年末が見えてきた今のうちにシステム設計を振り返られることも良いかもしれません。
( ※) ILM を冗長構成にしたとしても、SQL Server データベースは 1台もしくはクラスタ構成で事実上 1 つに見える形で対応する必要があります。これはつまり、メタバース（情報を溜め込んで、インポート対象とするデータを集積するリポジトリみたいなもの）が複数あるということは、一括管理できず、不整合が発生する恐れがあるからです。
SQL Server 単体製品としてみた場合、SQL Server 自体の冗長構成は可能ですが、ILM2007 を使用する際は 1 つで運用を行う必要があります。
-- ういこ --