From nakai.norihisa ＠ yes.nttcom.ne.jp Thu Aug 28 13:30:37 2008 From: nakai.norihisa ＠ yes.nttcom.ne.jp (=?ISO-2022-JP?B?GyRCQ2Y1bzd7NVcbKEI=?=) Date: Thu, 28 Aug 2008 13:30:37 +0900 Subject: [Ultramonkey-l7-develop 194] Re: =?iso-2022-jp?b?UW9TGyRCJTMhPCVJJE49JEA1JCokaCRTREkyQxsoQiAt?= =?iso-2022-jp?b?IDI=?= In-Reply-To: References: <20080825130608.F17C.TANUMA.KOUHEI@nttcom.co.jp> <20080826020423.e4ca6044.n.nakai@sdy.co.jp> <20080826103837.3a07ae0e.n.nakai@sdy.co.jp> Message-ID: <48B629ED.30808@yes.nttcom.ne.jp> 中居＠幕張です。 お疲れ様です。 #なぜか自社メールに流れてきていなかったので。 > ○ URL モジュールの場合 > index.html に適合するルールが無い場合は，接続拒否． > 動作は現在の実装と変わらない． この部分ですが、error.htmlが別サーバに設定している場合は 挙動が異なりませんか? URLですとurlごとにサーバ振り先が異なりますよね? cookie-insertはコネクションごとに変わると思うので問題はないと思います。 あと、現状まだ実装されていませんがurlaも対応できないと思われますが。 (これは中身を全部走査しますので、先頭だけを渡すのは難しいと思います) よって、urlaモジュールに当てはまる場合は全部渡す… と、なると今度はQoSに制限が出るような気がします。 > 先頭から L7VS_CONN_READ_BUFSIZE 分だけ読み込んだバッファを， > サービス判定のフローに丸投げすることで回避できそうです． > プロトコルモジュールに新しくサービス判定用のインタフェイスを作ったりして， > 各プロトコルに応じた判定処理をすれば問題ないと思います． サービス判定用IFが一番スマートのような気がしますね。 ただ、現状のMonkeyのつくりではprotocolmodule側がサービスを確定するという つくりが足を引っ張っているような気がしないでもないです。 長期的にはこの部分をもう少し考慮する必要があるかもしれません。 From takebayashi.shinya ＠ oss.ntt.co.jp Thu Aug 28 14:14:18 2008 From: takebayashi.shinya ＠ oss.ntt.co.jp (Shinya TAKEBAYASHI) Date: Thu, 28 Aug 2008 14:14:18 +0900 Subject: [Ultramonkey-l7-develop 195] Re: =?iso-2022-jp?b?UW9TGyRCJTMhPCVJJE49JEA1JCokaCRTREkyQxsoQiAt?= =?iso-2022-jp?b?IDI=?= In-Reply-To: <48B629ED.30808@yes.nttcom.ne.jp> References: <20080825130608.F17C.TANUMA.KOUHEI@nttcom.co.jp> <20080826020423.e4ca6044.n.nakai@sdy.co.jp> <20080826103837.3a07ae0e.n.nakai@sdy.co.jp> <48B629ED.30808@yes.nttcom.ne.jp> Message-ID: 中居 様 竹林です． お疲れ様です． > この部分ですが、error.htmlが別サーバに設定している場合は > 挙動が異なりませんか? > URLですとurlごとにサーバ振り先が異なりますよね? 現在の実装でも，Keepalive 無効の場合は URL ごとに振り分け先を分ける事が できますが，Keepalive が有効な場合は，URL ごとに振り分け先は変えられません． 実機で今の実装を確認してみました． ○ 条件 UM-L7 バージョン： 2.0.0-1 試験用ファイル ： 192.168.0.104 には index.html のみ 192.168.0.202 には error.html のみ l7directord.cf ： virtual=192.168.0.251:8080 real=192.168.0.104:80 masq module=url --pattern-match 'index.html' ・・・・ virtual=192.168.0.251:8080 real=192.168.0.202:80 masq module=url --pattern-match 'error.html' ・・・・ Apache の設定 ： Keepalive On Firefox の設定 ： Keepalive 有効 ○ 試験パターン（矢印以下は，期待する動作） 1. index.html を取得 → 正常に取得できる 2. index.html を取得 → error.html を取得 → error.html 取得時に HTTP 404 発生 Keepalive 無効時は，error.html も取得可能 3. error.html を取得 → 正常に取得できる 4. error.html を取得 → index.html を取得 → index.html 取得時に HTTP 404 発生 Keepalive 無効時は，index.html も取得可能 5. index.html を取得 → 202 を落とす → error.html を取得 → error.html 取得時に HTTP 404 発生 Keepalive 無効時は，error.html 取得時に Connection 切断 6. error.html を取得 → 104 を落とす → index.html を取得 → error.html 取得時に HTTP 404 発生 Keepalive 無効時は，index.html 取得時に Connection 切断 ※ それぞれの試験の前に，Firefox は再起動します ○ 結果 1. 期待通り 2. 期待通り（HTTP 404 発生） 3. 期待通り 4. 期待通り（HTTP 404 発生） 5. 期待通り（HTTP 404 発生） 6. 期待通り（HTTP 404 発生） サービス決定後は，コネクションが維持されている限りリアルサーバは固定されるので URL パーシスタンスは機能しません． > あと、現状まだ実装されていませんがurlaも対応できないと思われますが。 確かにそうですね． 考えないといけません． ----------------------------------------------------------- Shinya TAKEBAYASHI E-mail: takebayashi.shinya ＠ oss.ntt.co.jp GPG ID: 395EFCE8 GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 ----------------------------------------------------------- 中居憲久 wrote in message <48B629ED.30808 ＠ yes.nttcom.ne.jp > *** Subject: Re: [Ultramonkey-l7-develop 192] Re: QoSコードの修正および追加 - 2 *** Date: 2008/08/28 13:30:37 > 中居＠幕張です。 > お疲れ様です。 > > #なぜか自社メールに流れてきていなかったので。 > > > ○ URL モジュールの場合 > > index.html に適合するルールが無い場合は，接続拒否． > > 動作は現在の実装と変わらない． > > この部分ですが、error.htmlが別サーバに設定している場合は > 挙動が異なりませんか? > URLですとurlごとにサーバ振り先が異なりますよね? > cookie-insertはコネクションごとに変わると思うので問題はないと思います。 > あと、現状まだ実装されていませんがurlaも対応できないと思われますが。 > (これは中身を全部走査しますので、先頭だけを渡すのは難しいと思います) > よって、urlaモジュールに当てはまる場合は全部渡す… > と、なると今度はQoSに制限が出るような気がします。 > > > 先頭から L7VS_CONN_READ_BUFSIZE 分だけ読み込んだバッファを， > > サービス判定のフローに丸投げすることで回避できそうです． > > プロトコルモジュールに新しくサービス判定用のインタフェイスを作ったりして， > > 各プロトコルに応じた判定処理をすれば問題ないと思います． > > > サービス判定用IFが一番スマートのような気がしますね。 > ただ、現状のMonkeyのつくりではprotocolmodule側がサービスを確定するという > つくりが足を引っ張っているような気がしないでもないです。 > > 長期的にはこの部分をもう少し考慮する必要があるかもしれません。 > > > > From tanuma.kouhei ＠ nttcom.co.jp Thu Aug 28 22:28:43 2008 From: tanuma.kouhei ＠ nttcom.co.jp (Kouhei TANUMA) Date: Thu, 28 Aug 2008 22:28:43 +0900 Subject: [Ultramonkey-l7-develop 196] Re: =?iso-2022-jp?b?UW9TGyRCJTMhPCVJJE49JEA1JCokaCRTREkyQxsoQiAt?= =?iso-2022-jp?b?IDI=?= In-Reply-To: References: <48B629ED.30808@yes.nttcom.ne.jp> Message-ID: <20080828155112.B40D.TANUMA.KOUHEI@nttcom.co.jp> 皆様 田沼です。 メールが大変長くなってしまい申し訳ございません。 既存の実装と案ベースのものの差異は、最初の 1 回の読み込みで モジュールの処理（サービス決定とか）をするという部分だけですので、 それ以外の部分は既存と挙動は同じはずです。 そのため、竹林さんが調査したとおり > サービス決定後は，コネクションが維持されている限りリアルサーバは固定されるので > URL パーシスタンスは機能しません． 言い換えると 「1 コネクションに対して 1 度しかパーシステンス確認をしない」 これは正しく、既存からの仕様であると思ってます。 また、URL モジュールだけではなく、Cookie や 他の全てのモジュールも同じ動作になります。 ちなみに、2ch 情報ですが、Foundry のアプライアンス等も、 このような動作をするようです。 BIG-IP でも URL モジュールのような設定を iRule で行い KeepAlive で確認しましたが(*1)、こちらは問題なく、 クライアント - BIG-IP 間のコネクションが保たれたまま、 2 つのプールからの応答が返ってきます。 とりあえずこの点については、現状のままにしておき 次のリリース以後に検討してはどうでしょうか。 次に、どれだけ読み込んでモジュール処理（match_cldata, analyze_rsdata） するかについてですが、既存との比較をします。 ■ 既存 ・方式 ・読めるだけ読み込んで判定 ・問題点 (1)クライアントの通信が遅い場合、クライアントが期待する 全通信内容を読み込んでるとは限らない(*2) (2)上り QoS が Keep-Alive のようなサービス決定後に再度通信が 行われる場合にしか利かない (3)通信全てを溜め込む (4)QoS が LB の受信時に行われるため、全て溜め込むまでの過程が 制限されてゆっくりになり、溜め終わるまで対向へパケットは 一切流れない。さらに、モジュール処理後の溜めたデータの送信は 制限なしのフルスピードとなる。 ■ 修正 ・方式 ・最初の 1 回だけ読み込んで判定 ・既存と同じ問題点 (1)クライアントの通信が遅い場合、クライアントが期待する 通信内容を読み込んでるとは限らない(*2) ・新しい問題点 (5)最初の 1 回の読み込みだけでモジュール処理が正常にできるとは 限らない ・修正される問題点 (2)上り QoS が 2 回以上読む必要がある通信に対して全て利く (3)最初の 1 回分だけ溜め込む (4)QoS が LB の受信時に行われるが、1 回受信後、すぐ送信するため 理想どおりちょろちょろ流れる ということで、新しい問題点の(5)を検討すればいいように思えます。 モジュール処理は上り通信時の match_cldata と 下り通信時の analyze_rsdata があります。 1 回の読み込みを現在の実装どおり 20KB とし、 まず、現在実装済みのモジュールで考えます。 ■ match_cldata ・cinsert ・Cookie フィールドを解析している ・HTTP リクエストヘッダが 20KB 以内であれば問題なし （20KB 以上になる可能性はほとんどない） ・url ・リクエスト URI と Host フィールドを解析している ・HTTP リクエストヘッダが 20KB 以内であれば問題なし （20KB 以上になる可能性はほとんどない） （URI には長さに関する制限はない - RFC2616 s3.2.1） ・sslid ・SSLv3/TLSv1 の session-id を解析している ・問題なし（76バイトあれば判断可能） ・sessionless ・何もしない ・問題なし（パケット不要） ■ analyze_rsdata ・cinsert ・Cookie を挿入している ・HTTP レスポンスヘッダのステータスコード行（最初の1行目）が 20KB 以内であれば問題なし （20KB 以上になる可能性はほぼない） （ステータスコードの説明句（Not Foundなど）は拡張可能で 長さは無制限 - RFC2616 s6.1.1） ・url ・何もしない ・問題なし（パケット不要） ・sslid ・SSLv3/TLSv1 の session-id を解析している ・問題なし（76バイトあれば判断可能） ・sessionless ・何もしない ・問題なし（パケット不要） 上記のとおり、ほとんど問題はないはずです。 次に新しいモジュールを実装した際についてですが、 これは確かに問題になります。 例として昔あった urla を考えます。 ■ match_cldata ・HTTP リクエストから sessionid っぽい文字列を解析 ・HTTP リクエストヘッダが 20KB 以内であれば問題なし （20KB 以上になる可能性はほとんどない） ■ analyze_rsdata ・HTTP レスポンスボディから sessionid っぽい文字列を解析 ★sessionid の位置が 20KB いないであればいいが、 そうでない場合もありえる 以上のように、レスポンスの解析で問題が置きえます。 あとは、この問題点と、先に挙げた修正点について比較判断すれば よいでしょうか。 私は、現在の QoS の問題は結構大きいと個人的に思います。 また、urla のようなレスポンスやリクエストの後方部分で パーシステンス処理するようなことは他にまずないと思いますが、 どうでしょうか。 （普通はヘッダでパーシステンス処理すると思います…） あと、これまでとは関係ない話で、ソースを読んでいて知ったのですが、 クライアントと対向の RealServer が決定した後は、リレー処理されると 思っていたのですが、下りの analyze_rsdata は、RealServer から応答が 来るたびに呼ばれるようです。 これは意図的にこのようになっているのでしょうか？ （大した処理はしていないので、呼んでも問題はないようですが…） 以上、宜しくお願い致します。 (*1) - 設定した iRule when HTTP_REQUEST { if { [HTTP::uri] contains "image" } { pool web01 } else { pool web02 } } - 送信したリクエスト GET / HTTP/1.1 Host: bigip Connection: keep-alive GET /image/ HTTP/1.1 Host: bigip Connection: keep-alive (*2) - 例（telnet で cinsert を使った HTTP の仮想サービスに接続） | % telnet vip 80 1| GET / HTTP/1.0[CRLN] 2| Cookie: CookieName=xxxxx[CRLN] 3| [CRLN] telnet の場合、改行のたびに通信が行われるため、 1 の GET 文だけが match_cldata に渡り、 2 の Cookie 文でのパーシステンス処理が行われず、 Cookie なしとして RealServer が決定し、1 の文が送られる。 その後、RealServer に 2 の Cookie 文、3 の空行が送られ、 レスポンスが返ってくる。 On Thu, 28 Aug 2008 14:14:18 +0900 Shinya TAKEBAYASHI wrote: > 中居 様 > > > 竹林です． > お疲れ様です． > > > この部分ですが、error.htmlが別サーバに設定している場合は > > 挙動が異なりませんか? > > URLですとurlごとにサーバ振り先が異なりますよね? > > 現在の実装でも，Keepalive 無効の場合は URL ごとに振り分け先を分ける事が > できますが，Keepalive が有効な場合は，URL ごとに振り分け先は変えられません． > > 実機で今の実装を確認してみました． > > ○ 条件 > UM-L7 バージョン： 2.0.0-1 > 試験用ファイル ： 192.168.0.104 には index.html のみ > 192.168.0.202 には error.html のみ > l7directord.cf ： > virtual=192.168.0.251:8080 > real=192.168.0.104:80 masq > module=url --pattern-match 'index.html' > ・・・・ > > virtual=192.168.0.251:8080 > real=192.168.0.202:80 masq > module=url --pattern-match 'error.html' > ・・・・ > Apache の設定 ： Keepalive On > Firefox の設定 ： Keepalive 有効 > > > ○ 試験パターン（矢印以下は，期待する動作） > > 1. index.html を取得 > → 正常に取得できる > > 2. index.html を取得 → error.html を取得 > → error.html 取得時に HTTP 404 発生 > Keepalive 無効時は，error.html も取得可能 > > 3. error.html を取得 > → 正常に取得できる > > 4. error.html を取得 → index.html を取得 > → index.html 取得時に HTTP 404 発生 > Keepalive 無効時は，index.html も取得可能 > > 5. index.html を取得 → 202 を落とす → error.html を取得 > → error.html 取得時に HTTP 404 発生 > Keepalive 無効時は，error.html 取得時に Connection 切断 > > 6. error.html を取得 → 104 を落とす → index.html を取得 > → error.html 取得時に HTTP 404 発生 > Keepalive 無効時は，index.html 取得時に Connection 切断 > > ※ それぞれの試験の前に，Firefox は再起動します > > ○ 結果 > 1. 期待通り > 2. 期待通り（HTTP 404 発生） > 3. 期待通り > 4. 期待通り（HTTP 404 発生） > 5. 期待通り（HTTP 404 発生） > 6. 期待通り（HTTP 404 発生） > > > サービス決定後は，コネクションが維持されている限りリアルサーバは固定されるので > URL パーシスタンスは機能しません． > > > > あと、現状まだ実装されていませんがurlaも対応できないと思われますが。 > > 確かにそうですね． > 考えないといけません． > > ----------------------------------------------------------- > Shinya TAKEBAYASHI > > E-mail: takebayashi.shinya ＠ oss.ntt.co.jp > GPG ID: 395EFCE8 > GPG FP: 58B2 B5D0 A692 1BD8 328B E31E E027 AC35 395E FCE8 > ----------------------------------------------------------- > > > 中居憲久 wrote in message <48B629ED.30808 ＠ yes.nttcom.ne.jp > > > *** Subject: Re: [Ultramonkey-l7-develop 192] Re: QoSコードの修正および追加 - 2 > *** Date: 2008/08/28 13:30:37 > > 中居＠幕張です。 > > お疲れ様です。 > > > > #なぜか自社メールに流れてきていなかったので。 > > > > > ○ URL モジュールの場合 > > > index.html に適合するルールが無い場合は，接続拒否． > > > 動作は現在の実装と変わらない． > > > > この部分ですが、error.htmlが別サーバに設定している場合は > > 挙動が異なりませんか? > > URLですとurlごとにサーバ振り先が異なりますよね? > > cookie-insertはコネクションごとに変わると思うので問題はないと思います。 > > あと、現状まだ実装されていませんがurlaも対応できないと思われますが。 > > (これは中身を全部走査しますので、先頭だけを渡すのは難しいと思います) > > よって、urlaモジュールに当てはまる場合は全部渡す… > > と、なると今度はQoSに制限が出るような気がします。 > > > > > 先頭から L7VS_CONN_READ_BUFSIZE 分だけ読み込んだバッファを， > > > サービス判定のフローに丸投げすることで回避できそうです． > > > プロトコルモジュールに新しくサービス判定用のインタフェイスを作ったりして， > > > 各プロトコルに応じた判定処理をすれば問題ないと思います． > > > > > > サービス判定用IFが一番スマートのような気がしますね。 > > ただ、現状のMonkeyのつくりではprotocolmodule側がサービスを確定するという > > つくりが足を引っ張っているような気がしないでもないです。 > > > > 長期的にはこの部分をもう少し考慮する必要があるかもしれません。 > > > > > > > > > > _______________________________________________ > Ultramonkey-l7-develop mailing list > Ultramonkey-l7-develop ＠ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-develop > -- 田沼 航平 NTTコムウェア株式会社 基盤技術本部 OSS推進部 TEL:043-211-2266(#383-8017)