From n.nakai @ sdy.co.jp Thu Oct 22 00:04:37 2009 From: n.nakai @ sdy.co.jp (=?ISO-2022-JP?B?GyRCQ2Y1bzd7NVcbKEI=?=) Date: Thu, 22 Oct 2009 00:04:37 +0900 Subject: [Ultramonkey-l7-develop 560] Re: =?iso-2022-jp?b?VWx0cmFNbm9rZXktTDcbJEIkTjUhRz1ESTJDJEsbKEI=?= =?iso-2022-jp?b?GyRCJEQkJCRGGyhC?= In-Reply-To: <4ADE745F.9080703@nttcom.co.jp> References: <4ADC20B8.2040702@nttcom.co.jp> <20091019.184614.1098872335252737965.tateishi.katsuyuki@oss.ntt.co.jp> <4ADC3A12.1070001@nttcom.co.jp> <20091019.193716.321689434267588422.tateishi.katsuyuki@oss.ntt.co.jp> <4ADC450A.2040609@nttcom.co.jp> <4ADE745F.9080703@nttcom.co.jp> Message-ID: <4ADF2305.2080300@sdy.co.jp> 中居です。 お疲れ様です。 インラインコメントで失礼いたします。 > 1.マルチスレッド対応 > UltraMnokey-L7をマルチスレッド化し、処理性能の向上を図る。 thread内部での処理内容に比例すると思いますがMultiThreadのオーバーヘッド を考慮する必要があります。 1)pthread_create(2)はthread一つ一つにくくりつけられたスタック領域を確保 します。これはプロセスのスタックサイズのソフトリミットと同じサイズですか ら、結構大きなサイズになります。 これが馬鹿にならないぐらい重たく、単純に接続が現れた場合にthreadを起こす というモデルではepollより速度低下すると思われます。 #memory allocateはserializeされるため、multicpuも意味がない Javaのapplicationserver等はthread poolなどで対応していますので、 この対応が必要かと思います。 2)別に進めているMultiQueueとの整合性がとれると幸いかとおもいます。 本日22日にOSSCのフェルナンドさんの誘導でネットワークメンテナのDavidさん と、またMultiQueueのメンテナになったXuさんと会合を持ちます。 ただ、現在判明している点はFlowDirectorやDirectedAcceptを導入するに当たっ ては実行時に自らAPIをたたいて…と云う処理にはならない見通しです。 逆に、APIのフォーマットに関係なく上記機能が動きやすいThread構成にしてお く必要があるかと思います。 > 2.IPv6対応 > IPv6ネットワーク上でも動作するようにする。 IPv6のサポートはどのあたりのターゲットを目指していますか? Mobile IPv4/IPv6や、windowsXPのIPv6実装(特定範囲で一定時間にIPが循環す る)も含めて、ターゲットを決める必要があるかと思います。 逆に、フルでのIPv6のサポートはLinux自体が出来ていませんから、 どこまで線を引くのかと云う問題になるかと思いますが。 > 3.IPモジュールの追加 > ソースIPアドレスによるパーシステンスを行うProtocolModule。 これは単純にSourceIPのみでパーシステンスですから、 monkey-v4相当と考えてよいのでしょうか?? また、 > 4.SSLProxyのUltraMnokey-L7への組込み > マルチスレッド化したUltraMnokey-L7への組込みによる > 処理性能の向上と、プロセス統合によるユーザビリティ > (仕様の統一化、設定の簡易化など)の向上を図る。 > > 5.アクセスログの出力 > UltraMnokey-L7へのアクセスログを記録できるようにする。 > > 上記の機能追加では、実装的な構造変更により、仕様の変更 > なども、起きる可能性がありますので、皆様のご意見など > いただけたらと思っています。 > どうぞよろしくお願いいたします。 このあたりはプロトコルモジュールでのSSL実装、 MultiLog出力対応と考えてよろしいでしょうかね? -- _____________________________________________ 中居 憲久[Norihisa NAKAI] n.nakai @ sdy.co.jp 株式会社SDY tel:047-401-7210/fax:047-401-7207 From morisita.tooru @ nttcom.co.jp Thu Oct 22 14:10:20 2009 From: morisita.tooru @ nttcom.co.jp (=?ISO-2022-JP?B?GyRCPzkyPEUwGyhC?=) Date: Thu, 22 Oct 2009 14:10:20 +0900 Subject: [Ultramonkey-l7-develop 561] Re: =?iso-2022-jp?b?VWx0cmFNbm9rZXktTDcbJEIkTjUhRz1ESTJDJEsbKEI=?= =?iso-2022-jp?b?GyRCJEQkJCRGGyhC?= In-Reply-To: References: <4ADC20B8.2040702@nttcom.co.jp> <20091019.184614.1098872335252737965.tateishi.katsuyuki@oss.ntt.co.jp> <4ADC3A12.1070001@nttcom.co.jp> <20091019.193716.321689434267588422.tateishi.katsuyuki@oss.ntt.co.jp> <4ADC450A.2040609@nttcom.co.jp> <4ADE745F.9080703@nttcom.co.jp> Message-ID: <4ADFE93C.6060108@nttcom.co.jp> 竹林様、立石様、中居様 森下です。 コメント、ご要望ありがとうございます。 回答が遅くなり、申し訳ありません。 以下、失礼ながらまとめてインラインにて、 (長文になり、失礼いたします) >> 1.マルチスレッド対応 >> UltraMnokey-L7をマルチスレッド化し、処理性能の向上を図る。 竹林様: > 現在進めている MQ 関係の調整と旨く絡められると > なお良いかと思いますが,まだカーネル側からユーザ空間に抵抗される > インタフェイスが確立していないので,今回は見送りでしょうか. 立石様: > (コメント) > 「マルチスレッド化は必須」とか、要件を限定できればいいのです > が・・・難しいんですよね? 中居様: > thread内部での処理内容に比例すると思いますがMultiThreadのオーバーヘッド > を考慮する必要があります。 > > 1)pthread_create(2)はthread一つ一つにくくりつけられたスタック領域を確保 > します。これはプロセスのスタックサイズのソフトリミットと同じサイズですか > ら、結構大きなサイズになります。 > これが馬鹿にならないぐらい重たく、単純に接続が現れた場合にthreadを起こす > というモデルではepollより速度低下すると思われます。 > #memory allocateはserializeされるため、multicpuも意味がない > > Javaのapplicationserver等はthread poolなどで対応していますので、 > この対応が必要かと思います。 > > 2)別に進めているMultiQueueとの整合性がとれると幸いかとおもいます。 > 本日22日にOSSCのフェルナンドさんの誘導でネットワークメンテナのDavidさん > と、またMultiQueueのメンテナになったXuさんと会合を持ちます。 > ただ、現在判明している点はFlowDirectorやDirectedAcceptを導入するに当たっ > ては実行時に自らAPIをたたいて…と云う処理にはならない見通しです。 > 逆に、APIのフォーマットに関係なく上記機能が動きやすいThread構成にしてお > く必要があるかと思います。 回答: マルチスレッド化については、竹林様にOpenSourceWorld 2009で 発表していただいた資料にあるとおり、 http://sourceforge.jp/projects/ultramonkey-l7/docs/osw2009slide/ja/1/osw2009slide.pdf マルチコア、マルチCPUの環境での性能改善を図るために 今年度取り組むこととしていますので、「必須」と思っています。 ご指摘のMultiQueueへの対応ですが、竹林様の指摘どおり インタフェース等が固まっていないこともあり、 Thread構成の検討なども含めて、次回開発以降で改めて検討する ことになりそうです。 ThreadPoolについてはご指摘どおりですので、採用する方向で 検討したいと思います。 >> 2.IPv6対応 >> IPv6ネットワーク上でも動作するようにする。 竹林様: > こちらは特に考慮していただきたい項目はありません. > 実装をよろしくお願いいたします. 立石様: > (要望) > 世の中の多くのIPv6対応デーモンがそうであるように、デュアルス > タックで待ち受け動作できるようにしたいです。 > > 言い換えると getaddrinfo(2) の第3引数のai_flags にAI_PASSIVE > をセットし、第1引数にNULLを渡す方法を提供する必要があるという > 意味です。例えば l7directord.cf で「virtual = *:80」としたら > そうなるとか。 中居様: > IPv6のサポートはどのあたりのターゲットを目指していますか? > Mobile IPv4/IPv6や、windowsXPのIPv6実装(特定範囲で一定時間にIPが循環す > る)も含めて、ターゲットを決める必要があるかと思います。 > 逆に、フルでのIPv6のサポートはLinux自体が出来ていませんから、 > どこまで線を引くのかと云う問題になるかと思いますが。 回答: ご指摘どおり、デュアルスタックでの待ち受けについて、検討 したいと思います。 また、ターゲットについては、まだ明確に線引きができておりません ので、検討し、明確にしていきたいと思います。 >> 3.IPモジュールの追加 >> ソースIPアドレスによるパーシステンスを行うProtocolModule。 竹林様: > 既存にも IP アドレスベースのパーシステンスをする ip モジュールが > 実装されていますが,今度は特定の IP アドレスと特定のリアルサーバを > 括り付ける機能とするのでしょうか. 中居様: > これは単純にSourceIPのみでパーシステンスですから、 > monkey-v4相当と考えてよいのでしょうか?? 回答: ご指摘どおり既存のソースIPパーシステンスのProtocolModuleのことです。 新たな機能追加ではありません。失礼しました。 なのでmonkey-V4(L4ですよね?)のIPパーシステンスと同等と 考えています。 >> 4.SSLProxyのUltraMnokey-L7への組込み >> マルチスレッド化したUltraMnokey-L7への組込みによる >> 処理性能の向上と、プロセス統合によるユーザビリティ >> (仕様の統一化、設定の簡易化など)の向上を図る。 竹林様: > 既存では HTTPS のみの対応としていますが,今回の機能改善で > SSL を使用した IMAPS などへの対応はどうしましょうか. > > また,組み込むと一言で言っても, > > ○ プロトコルモジュールとして組み込む > ○ l7vsd に組み込む(今で言う conn.c 相当に組み込む) > > など,方式は様々考えられます. > > どのような方式とするのか,具体的な案があれば教えてください. 立石様: > (要望) > ロードバランサでSSLデコードしたいという動機は、「デコードした > 結果(L7の情報)に従って何か(主にパーシステンス)したい」という > ところにあると思っていますので、考慮をお願いします。 > # SSLデコードだけしてリアルサーバへの振り分けはラウンドロビ > # ンオンリーというのでは、SSLをデコードする意味がないですよ > # ね?(ラウンドロビンはSSLをデコードしなくてもできている) 中居様: > このあたりはプロトコルモジュールでのSSL実装、 > MultiLog出力対応と考えてよろしいでしょうかね? 回答: 今回は現SSLProxyの機能をそのまま組み込むことを考えており、 HTTPSのみの対応で考えています。 組み込む方法は、「l7vsd に組み込む」方法を考えており、 VirtualServiceにSSLを扱う、扱わないの属性を付与し、 SSL/非SSLの接続、通信処理を共存させて処理することを イメージしております。 (プロトコルモジュールのイメージではありません) 組み込まれたSSL機能は、デコード後のデータを各Protocolモジュールに 渡してこれまでどおりの処理を行うことを考えていますので、 SSLでもパーシステンス等の処理ができるよう考えています。 ラウンドロビンしかできないということはない考えです。 >> 5.アクセスログの出力 >> UltraMnokey-L7へのアクセスログを記録できるようにする。 竹林様: > ログの出力については,Apache の Customlog のように > ユーザが自由に書式を設定できるようにすると良いかと思います. 中居様: > このあたりはプロトコルモジュールでのSSL実装、 > MultiLog出力対応と考えてよろしいでしょうかね? 回答: ご指摘の、ログ出力書式のカスタマイズについて、検討 したいと思います。 アクセスログはApacheで出力しているaccess_logのようなもの をイメージしています。中居様ご指摘のMultiLogとは、どのような ことを指しているのでしょうか? その他コメント 竹林様: > 全体的に,どのようなスケジュールで進めるのかが固まっていれば, > そちらも教えていただけると助かります. > > また,すべての機能を盛り込んだソース一式がいきなり出てきてしまうと > 見る方も見られなくなってしまいますので,たとえば機能ごとなどに > 細分化した形で,ソースを頂ければと思います. 立石様: > (コメント) > 理想的には、意味のある変更ごとにリポジトリにコミットしてもら > うのがいいと思っています。意図としては「すべてがごっちゃになっ > た変更として出されても誰もレビューできない」ということで、竹 > 林さんのコメントと同様ですが、粒度を小さくして欲しいなと。 > # 「理想的には」です。 > ## が、なんらかのリビジョン管理をしていれば、もともと細かいチェ > ## ンジセットで変更が管理されているはずで、楽勝だと思いますが。 > > ちなみに ultramonkey-l7-v3 のリポジトリもありますが、開店休業 > 状態なので、一度ワイプして ultramonkey-l7-v2 のリポジトリを > clone してスタートしてもらうのが一番いいですかね・・・ 回答: スケジュールについては、2010年1月末をめどとした計画ですすめよう としています。 開発中のコード公開については、コムウェア社内での整理が付き次第、 本MLにて周知、順次公開していけるようにしたいと思いますので よろしくお願いいたします。 リポジトリについても別途相談させていただきたいと思います。 以上、よろしくお願いいたします。