From makoto ＠ kanon-net.jp Mon Aug 13 02:20:07 2007 From: makoto ＠ kanon-net.jp (Shinya TAKEBAYASHI) Date: Mon, 13 Aug 2007 02:20:07 +0900 Subject: [Ultramonkey-l7-develop 47] Re: =?iso-2022-jp?b?VWx0cmFNb25rZXktTDcbJEIkTiVYJUMlQEosM2QbKEI=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <46A5D884.4010504@yes.nttcom.ne.jp> References: <469F3634.9050107@yes.nttcom.ne.jp> <46A015F5.4070108@yes.nttcom.ne.jp> <46A05D63.3020702@yes.nttcom.ne.jp> <46A069DA.30002@yes.nttcom.ne.jp> <46A5D884.4010504@yes.nttcom.ne.jp> Message-ID: 中居 様 竹林です． お疲れ様です． 詳細な説明をしていただきまして，ありがとうございます． 確かにセッション同期（sync_session）処理で CPU 時間が取られて いそうな感じはしています． 性能に与える影響の理由として納得しましたが，sync_session を 取り除く事によって，冗長化構成（ACT-STANDBY）を組んだ場合の セッションのレプリケートが出来なくなくなります． フェイルオーバ時のセッション救済について，代替案をお持ちでしょうか． ＃ chash くらいしかレプリケートの必要な機能はない・・・とか・・・． ＃＃ 世間一般では cinsert が多いのかな・・・とも思いますが． それともう一点． 今回投げていただいたパッチによってセッション同期が無効になりますが， 中居さんのメール中では「検討している」となっているので，今後も永続的に セッション同期をなくすつもりはない，つまり，今回で沈めるという訳ではない と考えて良いですか． 以上，よろしくご確認願います． ------------------------------------------------------------- Shinya TAKEBAYASHI E-mail(Office) ： takebayashi.shinya ＠ nttcom.co.jp E-mail(private)： makoto ＠ kanon-net.jp GPG ID： FFD20D1F GPG FP： 7B5B E0FC B785 7457 683C 47D6 5564 DDDD FFD2 0D1F ------------------------------------------------------------- From makoto ＠ kanon-net.jp Mon Aug 13 02:21:55 2007 From: makoto ＠ kanon-net.jp (Shinya TAKEBAYASHI) Date: Mon, 13 Aug 2007 02:21:55 +0900 Subject: [Ultramonkey-l7-develop 48] Re: =?iso-2022-jp?b?bDdkaXJlY3RvcmQbJEIkSyQqJDEkayVdITwlSDRGGyhC?= =?iso-2022-jp?b?GyRCO2tJVDZxOWdCUD1oJVElQyVBO3ZBMD5IMnEbKEI=?= In-Reply-To: <20070802184227.E0F4.KONDO.HIDEAKI@oss.ntt.co.jp> References: <20070802184227.E0F4.KONDO.HIDEAKI@oss.ntt.co.jp> Message-ID: 近藤 様 竹林です． お疲れ様です． l7directord の件ですが，8 月 13 日（金）にパッチを当てたバージョンを リリースしました． https://sourceforge.jp/projects/ultramonkey-l7/files/?release_id=26644#26644 ご確認をお願い致します． ------------------------------------------------------------- Shinya TAKEBAYASHI E-mail(Office) ： takebayashi.shinya ＠ nttcom.co.jp E-mail(private)： makoto ＠ kanon-net.jp GPG ID： FFD20D1F GPG FP： 7B5B E0FC B785 7457 683C 47D6 5564 DDDD FFD2 0D1F ------------------------------------------------------------- *** Hideaki Kondo wrote in message <20070802184227.E0F4.KONDO.HIDEAKI ＠ oss.ntt.co.jp > *** Subject: [Ultramonkey-l7-develop 43] l7directordにおけるポート監視不 具合対処パッチ事前照会 *** Date: Thu, 02 Aug 2007 18:53:26 +0900 > > UM-L7開発MLの皆様 > > 近藤と申します。 > お世話になっております。 > > 本家UltraMonkeyプロジェクトのサイトにおきまして > UltraMonkey(L4)のldirectordにおいてポート監視 > (checktype=connect)に不具合があり、その対処が > なされた旨のアナウンスが以下の通りありました。 > http://www.ultramonkey.org/news_archive.shtml > > これに伴いまして、現在公開中のl7directord-0.5.0-1 > につきましてもUM-L4のldirectordソースコードを > ベースとしていることから、同様な不具合対処を行なう > 必要があり、本件対処パッチを作成しましたので > 事前照会させていただきます。 > > 1〜2週間程度待って特に問題等報告されなければ > このパッチを反映し、l7directord-0.5.0-2として > リリースしたいと考えておりますので、ご確認の程 > よろしくお願い致します。 > > ＃UM-L7公式サイトへのリリースにつきましては > ＃竹林さんが対応される予定です。 > > 以上よろしくお願いします。 > -- > Hideaki Kondo > > From makoto ＠ kanon-net.jp Mon Aug 13 02:38:12 2007 From: makoto ＠ kanon-net.jp (Shinya TAKEBAYASHI) Date: Mon, 13 Aug 2007 02:38:12 +0900 Subject: [Ultramonkey-l7-develop 49] =?iso-2022-jp?b?V2VpZ2h0ZWQgUm91bmRSb2JpbiAbJEIlYiU4JWUhPCVrGyhC?= =?iso-2022-jp?b?GyRCJEckLSReJDckPxsoQg==?= Message-ID: 関係各位 竹林です． お疲れ様です． sched_wrr ができました． 以前黒澤さんにアドバイスを頂いた GCD を用いた方法で 重みを考慮したラウンドロビンを行います． ただ，やはりサービスを意識する必要があると考えると， l7vs_service 構造体にメンバ（handle）を追加する必要がありそうです． 仮想サービス関連のコードを見た限りでは，l7vs_service 構造体の サイズを決め打ちしているところは見あたらなかったので， 今回のパッチでメンバをひとつ増やしても影響は無いと思います． ＃ 全体の再コンパイルが必要ですが・・・ ・l7vs-0.6.0-0-wrr.patch sfj 上の l7vs-0.6.0-0 に当てるパッチです． l7vs.h に handle を追加，Makefile.am に sched_wrr.so の分を追加， l7vsadm.c のヘルプの修正，sched_wrr.c を新規作成するものです． ・l7directord-0.5.0-2-wrr.patch sfj 上の l7directord-0.5.0-2 に当てるパッチです． /usr/sbin/l7directord 内でコメントアウトされている weight に関する部分を有効にするものです． 上記ふたつのパッチは，patch -p1 で当ててください． なお，weight の指定の仕方ですが，/etc/ha.d/conf/l7directord.cf に real=192.168.0.12:80 masq 5 real=192.168.0.11:80 masq 1 のように masq の後に weight 値を入れてあげてください． 以上，よろしくご確認願います． ------------------------------------------------------------- Shinya TAKEBAYASHI E-mail(Office) ： takebayashi.shinya ＠ nttcom.co.jp E-mail(private)： makoto ＠ kanon-net.jp GPG ID： FFD20D1F GPG FP： 7B5B E0FC B785 7457 683C 47D6 5564 DDDD FFD2 0D1F ------------------------------------------------------------- -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: l7vs-0.6.0-0-wrr.patch 型: application/octet-stream サイズ: 8322 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/ultramonkey-l7-develop/attachments/20070813/cea94dfd/attachment.obj -------------- next part -------------- テキスト形式以外の添付ファイルを保管しました... ファイル名: l7directord-0.5.0-2-wrr.patch 型: application/octet-stream サイズ: 7039 バイト 説明: 無し URL: http://lists.sourceforge.jp/mailman/archives/ultramonkey-l7-develop/attachments/20070813/cea94dfd/attachment-0001.obj From nakai.norihisa ＠ yes.nttcom.ne.jp Mon Aug 13 18:05:38 2007 From: nakai.norihisa ＠ yes.nttcom.ne.jp (nakai norihisa) Date: Mon, 13 Aug 2007 18:05:38 +0900 Subject: [Ultramonkey-l7-develop 50] Re: =?iso-2022-jp?b?VWx0cmFNb25rZXktTDcbJEIkTiVYJUMlQEosM2QbKEI=?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: References: <469F3634.9050107@yes.nttcom.ne.jp> <46A015F5.4070108@yes.nttcom.ne.jp> <46A05D63.3020702@yes.nttcom.ne.jp> <46A069DA.30002@yes.nttcom.ne.jp> <46A5D884.4010504@yes.nttcom.ne.jp> Message-ID: <46C01EE2.3000007@yes.nttcom.ne.jp> 竹林様 中居です。 お世話になっております。 > 性能に与える影響の理由として納得しましたが，sync_session を > 取り除く事によって，冗長化構成（ACT-STANDBY）を組んだ場合の > セッションのレプリケートが出来なくなくなります． > フェイルオーバ時のセッション救済について，代替案をお持ちでしょうか． > ＃ chash くらいしかレプリケートの必要な機能はない・・・とか・・・． > ＃＃ 世間一般では cinsert が多いのかな・・・とも思いますが． ACT-SBY構成時の同期機能の代替案を用意しております。 > それともう一点． > 今回投げていただいたパッチによってセッション同期が無効になりますが， > 中居さんのメール中では「検討している」となっているので，今後も永続的に > セッション同期をなくすつもりはない，つまり，今回で沈めるという訳ではない > と考えて良いですか． 上記のように今回は無効になりますが、永続的になくすわけではありません。 基本的に0.6.0で入っている機能につきましてはすべて実装すべきと考えており ます。 現在syncの方式変更については資料としてまとめていますが、 ポイントを抜き出しますと 1) 現状ではプロトコルモジュールとl7syncでsync機能を構成しているが、 同期 機構と言う性格上プロトコルモジュールが直接l7syncdとやり取りするのではな く、l7vsdのフレームワークが提供すべき機能と思われる。 2)UDPパケットを利用してデータの同期を行っているが、パケットサイズと同期 すべきデータ量が同期しているように見えない。計算上、chashで同期すべき データ量は最低MTU以上になり、最低MTU以上になった場合にはパケット分割が発 生する。この場合に順序性やパケットロストが発生するが、パケットロスト及び パケット整列の機能はモジュール別ではなく、フレームワークとして提供すべき である。 上記ポイントを抜き出した方式を次回のメールて説明させていただきます。 どうぞよろしくお願いいたします。