From toreno4257 ＠ nifty.com Fri Feb 8 01:23:23 2008 From: toreno4257 ＠ nifty.com (Hideaki Kondo) Date: Fri, 8 Feb 2008 01:23:23 +0900 Subject: [Ultramonkey-l7-develop 142] Re: =?iso-2022-jp?b?bDdndWkbJEIkTjR7QjhJdEosJEgkThsoQklG?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= References: <20080206143908.73ad3a92.takebayashi.shinya@nttcom.co.jp><47A95199.2040807@yes.nttcom.ne.jp><20080206153846.D4A6.KONDO.HIDEAKI@oss.ntt.co.jp> <47AAC2EE.70706@yes.nttcom.ne.jp> Message-ID: <002601c869a5$c32ff700$5701a8c0@PCGTR1B> 中居様 (Cc:UM-L7開発MLの皆様) 近藤です。 お疲れ様です。 ご回答いただき有り難うございます。 本件につきまして、了解しました。 また、実装方式と課題管理等考慮いただき 有り難うございました。 ----- Original Message ----- From: "nakai norihisa" To: "Hideaki Kondo" Cc: "Shinya TAKEBAYASHI" ; "ultramonkey-l7-develop" Sent: Thursday, February 07, 2008 5:35 PM Subject: [Ultramonkey-l7-develop 141] Re: l7guiの既存部分とのIFについて > TO:近藤様 > CC:MLの皆様 > > お疲れ様です。 > > 処理コストを定量化できればOKなのですが、 > ちょっと今現在コストを定量化する余裕がありません(^^;;;; > > これは当初fork()で実装をすすめ、再度 > JNIでの実装を検討するというステータスで > 課題管理にしたほうが良い感じがしますね。 > > 多分、これに付随してwatchdog processの話も絡んでくるでしょうから、 > この部分はsfjの課題管理に移行しておきます。 > > どうぞよろしくお願いいたします。 > > >> 中居様 >> (Cc:竹林様、関係各位) >> >> 近藤です。 >> お疲れ様です。 >> >> 標記の件に関連して、内容を十分に確認しきれていないので >> 少しズレているかも知れませんが、forkの処理コストを考慮して >> JNIでl7guiとl7vsadm,l7vsd,Heartbeat2等とのインタフェースを >> 取ることを考えつつあるように思いますが、そもそもUM-L7の >> 運用始めた後でfork処理コストが負荷分散処理に影響を与えるほど >> GUIから（定期的な発行はあるにしても）呼び出して使うことが >> あるのかが疑問です。 >> >> Heartbeatは複数プロセスで構成されていますが、JNIで簡単に >> インタフェースがとれるかどうかも懸念されますし、 >> 他クラスタソフトとの連携においても、コマンドベースでの >> インタフェースに比べて差し替えが容易な構造を維持できるかも >> （クラスの作り方でカプセル化はできると思いますが）心配です。 >> また、連携される側のソフト(Heartbeat等)が何も意識しないで >> インタフェースをとれるのかも気になります。 >> >> 個人的にはコマンドベースのインタフェースで統一してもらった方が >> 構造としてもシンプルでわかり易いですし、差替えも容易と考えられる >> ので、forkの処理コストのみを心配して、JNIで処理する構造とする >> 方針には、（十分に理解できていないので）賛同しかねている状況です。 >> >> JNIを利用することのメリットだけでなく、デメリット面もあるよう >> でしたら、その点をご教授いただく必要があると思います。 >> >> >> On Wed, 06 Feb 2008 15:20:09 +0900 >> nakai norihisa wrote: >> >>> 中居です。 >>> >>> >>>> ポイント 1 とポイント 2，ポイント 2 とポイント 4は矛盾の関係にあるので， >>>> 何かしら措置を執る必要があります． >>>> 一番簡単な解決策は中居さんの案の「2」にあたる部分を >>>> 両パッケージに入れる方法ですが，アトミック性が低下するためボツです． >>>> かといって，l7vsd の中に admjni.c を入れた場合は，l7gui を使うためにも >>>> l7vsd のソースコード一式が必要になります． >>>> 加えて，l7vsd を rpm パッケージでインストールした場合の対処なども >>>> 未検討のような気がします． >>> 依存関係にかんしてはおおむね同意です。 >>> これはl7vsd側が口を持つべきだと思います。 >>> (ただ、l7guiを使うには必ずl7vsdが必要ですので、l7vsdをrpm install時に >>> admjndi.soをinstallするように考慮すればよい気がします) >>> >>> >>>> ○ l7vsd との通信を行う関数をまとめた共有オブジェクト >>>> （admjni.so と仮定）を作成 >>>> ○ l7vsadm は admjni.so を通して l7vsd と通信する >>>> ○ l7gui は，admjni.so を通して l7vsd と通信する >>>> ○ admjni.so のソースである admjni.c を l7vsd のパッケージに入れる >>>> （rpm 化した場合でも，l7vsd のパッケージに admjni.so が入るので >>>> l7gui をインストールする場合でも再コンパイルの必要がない） >>>> とすることで，「保守性」「アトミック性」の保障ができると考えています． >>> ただ、l7vsadmがadmjni.soを使う必要性はありませんね。 >>> l7vsadm自体はそのままsocketを利用する仕様でよいと思います。 >>> admjni.soのコードをl7vsd側のパッケージに入れる部分でアトミック性は確保できるでしょう。 >>> >>> したがって、l7vsd側のパッケージにjni用の.soを追加するというのがベターな気がします。 >>> >>> と、ここまで書いて思ったのですがやはりl7vsd側に入れるのは問題が発生しそうです。 >>> 現状Cluster側の表示を行う部分でもjni用soが必要なのですが、 >>> l7vsd自体どのクラスタソフトを使用するかと言うのは固定できないと思います。 >>> lifekeeperかも知れませんし、HB2かもしれません。 >>> 現状その部分についてはJNDIでの名前解決で差し替え可能に設計を進めていますが、 >>> ここもjniを利用したIFの口を持つ必要があります。 >>> >>> すると、上記パッケージの場所はどこにするのがベターなのかと言う問題にぶち当たります。 >>> l7vsdの中にhb2jni.soが入るのはなしですよね? >>> >>> 別途、独立してかつ、各l7vsdやHB2にあわせたjniのパッケージを用意するのが >>> ベターのようが気がしてきました。 >>> >>> ただ、この問題はもう少し掘り下げて考えなくてはならないと思いますので、 >>> 何か良い案がありましたらご意見いただけますと幸いです。 >>> >>> どうぞよろしくお願いいたします。 >>> 以上よろしくお願いします。 -- Hideaki Kondo (近藤 秀明)