s.maru885
s.mar****@gmail*****
2013年 3月 28日 (木) 02:48:04 JST
中野様、雲雀様 お世話になっております。 丸水です。 御回答有り難うございます。 > maxconn=3 > sorryserver=127.0.0.1:55555 <=ダミー（接続できないサーバを指定） > > sorryserverがつながる状態になければ、HTTPだろうが > HTTPSだろうが、即座に切断することになるので、 > 期待する動作を満たせるかと思います。 上記設定でテストしたところ、 最大同時接続数を超えた後のアクセスで即時エラーが返ってくることを 確認致しました。 > UltraMonkey-L7がキューイング(非同期処理)をやっているというのも > ありますが、TCPネットワークの仕様として、「パケット応答がない > 場合はパケットを再送する」という原則があります。 > 再送間隔と再送し続ける期間は可変ですが、かなり長いです > > この場合、以下のようなシーケンスだと思います。 > > 1. 超えたときに送ったパケットはUltraMonkeyでHTTPヘッダが解釈できず、 > 無応答となる。 > 2. 応答がないので、クライアントは該当セッションのパケットを送り続ける。 > 3. maxconnを下回ったとき、UltraMonkeyはsorryserver接続ではなく通常 > リアルサーバへの振り分けをする。 > 4. その時送った再送パケットはリアルサーバに到達し、応答が返る。 なるほど、UltraMonkeyでHTTPヘッダを解釈しようとした結果、 無応答となっているのですね。 上記動作について承知致しました。 この度は、早々のご回答、誠に有難うございました。 お陰様で問題を解決することができました。 今後とも宜しくお願い致します。 以上 2013年3月26日 13:23 中野 宏朗 <nakan****@nttco*****>: > 中野@幕張です。 > こんにちは。 > > UltraMonkey-L7の設定としては、雲雀さんの回答どおりです。 > maxconnを越えた時はsorryserverに接続にいくフラグを立てるように > なっているので、maxconnのみだとうまく動かないですね。 > > (2013/03/26 6:29), s.maru885 wrote: >> お世話になっております。 >> 丸水です。 >> >> 本件に関連して質問させて頂きます。 >> >> 現在、HTTPSにて最大同時接続数(接続数の上限値)を設定し、 >> 以下の様な動作をさせたいと考えております。 >> >> (1)最大同時接続数の制限 >> (2)最大同時接続数を超えた状態でアクセスした場合、 >> 即時エラー(またはSorry)を返す >> >> HTTPS通信時に上記の動作を実現することは可能でしょうか。 >> >> HTTPであれば、maxconn、sorryserverを設定することで >> 上記動作は可能かと思いますが、 >> HTTPSですと、sorryserverが対応していないとのことで、 >> 想定通りに動作しなかったため、質問させて頂きました。 >> >> 以下にこちらで検証した内容とそのときの設定(一部抜粋)を記載します。 >> >> ■maxconn、sorryserverを設定 >> 設定： >> l7vs.cf >> session_thread_pool_size=100 >> l7directord.cf >> maxconn=3 >> sorryserver=172.16.210.128:443 >> 動作： >> (1)は満たすが、(2)が動作しない >> UltraMonkeyでキューイングしているような動作をしており、 >> 最大同時接続数を超えている場合、応答待ちとなり、 >> 最大同時接続数を下回った後にリアルサーバに振り分けて >> 応答を返す。 > > UltraMonkey-L7がキューイング(非同期処理)をやっているというのも > ありますが、TCPネットワークの仕様として、「パケット応答がない > 場合はパケットを再送する」という原則があります。 > 再送間隔と再送し続ける期間は可変ですが、かなり長いです。 > > この場合、以下のようなシーケンスだと思います。 > > 1. 超えたときに送ったパケットはUltraMonkeyでHTTPヘッダが解釈できず、 > 無応答となる。 > 2. 応答がないので、クライアントは該当セッションのパケットを送り続ける。 > 3. maxconnを下回ったとき、UltraMonkeyはsorryserver接続ではなく通常 > リアルサーバへの振り分けをする。 > 4. その時送った再送パケットはリアルサーバに到達し、応答が返る。 > >> ■maxconnのみを設定 >> 設定： >> l7vs.cf >> session_thread_pool_size=100 >> l7directord.cf >> maxconn=3 >> #sorryserver=172.16.210.128:443 >> 動作： >> UltraMonkeyを起動してもmaxconnの設定が反映されず、 >> maxconnは0のまま >> →sorryserverを設定しないとmaxconnは有効にならない。 > > これは最初にいったとおりで、雲雀さんの設定で逃げるしかないです。 > >> ■session_thread_pool_sizeで制限 >> 設定： >> l7vs.cf >> session_thread_pool_size=3 >> l7directord.cf >> #maxconn=3 >> #sorryserver=172.16.210.128:443 >> 動作： >> (1)は満たすが、(2)が動作しない >> UltraMonkeyでキューイングしているような動作をしており、 >> 最大同時接続数を超えている場合、応答待ちとなり、 >> 最大同時接続数を下回った後にリアルサーバに振り分けて >> 応答を返す。 >> 備考： >> 通常、session_thread_pool_sizeで最大同時接続数を >> 制限するようなことはしないかと思いますが、試しに確認しました。 > > この場合も、最初と同じですね。 > session_thread_pool_size以上の接続が同時に来ると、listenしている > ソケットの数が足りないのでTCPレベルで無応答になります。 > 空きソケットが出来るまで、再送を繰り返すことになります。 > これはTCPの仕様どおりですね。 > >> 似たような問題が発生した方、解決方法をご存じの方がいらっしゃいましたら、 >> ご教示頂けると幸いです。 > > UltraMonkeyでFIN返すか、HTTPなどのアプリケーション層エラー組み立てて返す機能を > 追加するくらいしかないです。 > つまり、今現在はその機能はありません。sorryサーバにすべてを任せるように > なっています。 > が、なぜかsorryサーバ転送前にHTTPヘッダを解釈しようとするという・・・ > > # 任せるなら余計なことせずに丸投げすればいいのに。 > > 機能追加はリリースタイミング的にかなり後になりそうなので、いまは > 存在しないsorryサーバの設定で回避してみてください。 > >> 2013年3月7日 22:21 s.maru885 <s.mar****@gmail*****>: >>> 中野様、雲雀様 >>> >>> お世話になっております。 >>> 丸水です。 >>> >>>> Sorryサーバですが、現在HTTPのみの対応となっております。 >>>> HTTPSを利用される際には、fallback機能を利用されることをお勧めします。 >>> HTTPのみの対応であること承知いたしました。 >>> 通信の種類に合わせてSorryとfallbackを使い分けていきたいと思います。 >>> >>>> sslconfigfile設定時の動作としては、UM-L7でSSL通信を終端させるため、 >>>> UltraMonkey-リアルサーバ間はhttp通信となります。 >>> UltraMonkey-リアルサーバ間がhttp通信になること承知致しました。 >>> >>> >>> この度は、早々のご回答、誠に有難うございました。 >>> お陰様で不明な点を解消することができました。 >>> 厚く御礼申し上げます。 >>> >>> >>> それでは、今後とも宜しくお願い致します。 >>> >>> 2013年3月7日 10:35 Hibari Michiro <hibar****@lab*****>: >>>> >>>> 丸水様 >>>> >>>> 初めまして。雲雀と申します。 >>>> >>>>> ■質問内容 >>>>> 1) https通信時のSorryサーバへの振り分けについて >>>>> httpsで通信する場合、仮想サービスがSorry状態となった際に >>>>> Sorryサーバに振り分けられますでしょうか。 >>>> Sorryサーバですが、現在HTTPのみの対応となっております。 >>>> >>>> おそらくですが、Sorryサーバ機能では、Sorryサーバ接続時に >>>> URLを加工する処理等が含まれているので、暗号化通信だと >>>> 上手くいかないようです。 >>>> >>>> HTTPSを利用される際には、fallback機能を利用されることをお勧めします。 >>>> >>>>> >>>>> 2) sslconfigfile設定時の動作について >>>>> sslconfigfile設定時の動作についてご教示頂けますでしょうか。 >>>>> (1)UltraMonkey-リアルサーバ：http通信 >>>>> →リアルサーバへの振り分けは正常に行われる。 >>>>> (2)UltraMonkey-リアルサーバ：https通信 >>>>> →リアルサーバからHTTPステータスレコード『400 Bad Request』が返ってくる。 >>>>> (2)の動作が仕様として、正しい動作なのかご教示頂けますでしょうか。 >>>> (2)は仕様通りの動作となります。 >>>> sslconfigfile設定時の動作としては、UM-L7でSSL通信を終端させるため、 >>>> UltraMonkey-リアルサーバ間はhttp通信となります。 >>>> >>>> 以上、宜しくお願いいたします。 >>>> >>>> (2013/03/07 4:36), s.maru885 wrote: >>>>> はじめまして、丸水と申します。 >>>>> >>>>> 長文にて失礼致します。 >>>>> 現在、下記の構成にて、UltraMonkey-l7を使用したLBサーバの設定を行なっております。 >>>>> https通信時の設定、動作について2点解らない箇所がございましたので、 >>>>> 質問させて頂きます。 >>>>> >>>>> ■環境構成 >>>>> LB(UltraMonkey)×1 >>>>> OS：CentOS 6.3 x86_64 >>>>> カーネル：2.6.32-279.el6.x86_64 >>>>> UltraMonkey：ultramonkeyl7-3.0.4-3.el6.x86_64 >>>>> APサーバ×3(リアルサーバ)、Sorryサーバ×1 >>>>> OS：CentOS 6.3 x86_64 >>>>> カーネル：2.6.32-279.el6.x86_64 >>>>> Web：httpd-2.2.15-15.el6.centos.1.x86_64 >>>>> mod_ssl-2.2.15-15.el6.centos.1.x86_64 >>>>> openssl-1.0.0-20.el6_2.5.x86_64 >>>>> 接続クライアント×1 >>>>> OS：CentOS 6.3 x86_64 >>>>> カーネル：2.6.32-279.el6.x86_64 >>>>> ブラウザ等：Mozilla Firefox 10.0.5、curl 7.19.7 >>>>> >>>>> ■質問内容 >>>>> 1) https通信時のSorryサーバへの振り分けについて >>>>> httpsで通信する場合、仮想サービスがSorry状態となった際に >>>>> Sorryサーバに振り分けられますでしょうか。 >>>>> 仮想サービス、各リアルサーバ、Sorryサーバのポート番号を443に設定し、 >>>>> Sorry状態(リアルサーバダウン)で仮想サービスにhttpsでアクセスすると >>>>> Sorryサーバに振り分けられ、クライアントに応答が返るものと >>>>> 想定しておりましたが、想定した動作とならなかったため、質問させて頂きました。 >>>>> ※設定については【検証】(1)を参照 >>>>> >>>>> 以下にこちらで検証した内容とそのときの設定(一部抜粋)を記載します。 >>>>> 設定不備等ございましたら、ご指摘頂ければと存じます。 >>>>> 【検証】 >>>>> (1)仮想サービス、各リアルサーバ、Sorryサーバのポートを443に設定し、 >>>>> https通信を振り分けられるか確認 >>>>> →リアルサーバへの振り分けは正常に行われたが、 >>>>> リアルサーバ全ダウン時のSorryサーバへの振り分けは失敗。 >>>>> 172.16.210.125:443 <http://172.16.210.125:443> 振り分けOK >>>>> 172.16.210.126:443 <http://172.16.210.126:443> 振り分けOK >>>>> 172.16.210.127:443 <http://172.16.210.127:443> 振り分けOK >>>>> >>>>> 172.16.210.128:443 <http://172.16.210.128:443> リアルサーバ全ダウン時、振り分けNG >>>>> 設定： >>>>> virtual = 172.16.210.105:443 <http://172.16.210.105:443> >>>>> real = 172.16.210.125:443 <http://172.16.210.125:443> masq 1 >>>>> real = 172.16.210.126:443 <http://172.16.210.126:443> masq 1 >>>>> real = 172.16.210.127:443 <http://172.16.210.127:443> masq 1 >>>>> module = sessionless >>>>> scheduler = rr >>>>> sorryserver = 172.16.210.128:443 <http://172.16.210.128:443> >>>>> テスト時の接続URL： >>>>> https://172.16.210.105/ >>>>> 備考： >>>>> 下記の設定のようにリアルサーバ1台(172.16.210.125)と >>>>> Sorryサーバ(172.16.210.128)を設定上入れ替えて動作を確認しましたが、 >>>>> リアルサーバへの振り分けは172.16.210.128も含め、正常に行われ、 >>>>> リアルサーバ全ダウン時のSorryサーバ(172.16.210.125)への >>>>> 振り分けは失敗しました。 >>>>> virtual = 172.16.210.105:443 <http://172.16.210.105:443> >>>>> real = 172.16.210.126:443 <http://172.16.210.126:443> masq 1 >>>>> real = 172.16.210.127:443 <http://172.16.210.127:443> masq 1 >>>>> real = 172.16.210.128:443 <http://172.16.210.128:443> masq 1 #元々はSorryサーバ >>>>> module = sessionless >>>>> scheduler = rr >>>>> sorryserver = 172.16.210.125:443 <http://172.16.210.125:443> #元々はリアルサーバ >>>>> テスト時の接続URL： >>>>> https://172.16.210.105/ >>>>> >>>>> (2)https通信以外の動作を確認するため、 >>>>> 仮想サービス、各リアルサーバ、Sorryサーバのポートを80に設定し、 >>>>> http通信を振り分けられるか確認 >>>>> →リアルサーバへの振り分けは正常に行われ、 >>>>> リアルサーバ全ダウン時のSorryサーバへの振り分けも正常に行われた。 >>>>> 172.16.210.125:80 <http://172.16.210.125:80> 振り分けOK >>>>> 172.16.210.126:80 <http://172.16.210.126:80> 振り分けOK >>>>> 172.16.210.127:80 <http://172.16.210.127:80> 振り分けOK >>>>> >>>>> 172.16.210.128:80 <http://172.16.210.128:80> リアルサーバ全ダウン時、振り分けOK >>>>> 設定： >>>>> virtual = 172.16.210.105:80 <http://172.16.210.105:80> >>>>> real = 172.16.210.125:80 <http://172.16.210.125:80> masq 1 >>>>> real = 172.16.210.126:80 <http://172.16.210.126:80> masq 1 >>>>> real = 172.16.210.127:80 <http://172.16.210.127:80> masq 1 >>>>> module = sessionless >>>>> scheduler = rr >>>>> sorryserver = 172.16.210.128:80 <http://172.16.210.128:80> >>>>> テスト時の接続URL： >>>>> http://172.16.210.105/ >>>>> >>>>> (3)仮想サービス、各リアルサーバのポートを443、 >>>>> Sorryサーバのポートを80に設定し、https通信を振り分けられるか確認 >>>>> →リアルサーバへの振り分けは正常に行われたが、 >>>>> リアルサーバ全ダウン時のSorryサーバへの振り分けは失敗。 >>>>> ただし、http://172.16.210.105:443/(http <http://172.16.210.105:443/%28http>通 信)でアクセスしたところ、 >>>>> Sorryサーバへの振り分けは正常に行われた。 >>>>> 172.16.210.125:443 <http://172.16.210.125:443> 振り分けOK >>>>> 172.16.210.126:443 <http://172.16.210.126:443> 振り分けOK >>>>> 172.16.210.127:443 <http://172.16.210.127:443> 振り分けOK >>>>> >>>>> 172.16.210.128:80 <http://172.16.210.128:80> リアルサーバ全ダウン時、振り分けNG >>>>> (https://172.16.210.105/) >>>>> 172.16.210.128:80 <http://172.16.210.128:80> リアルサーバ全ダウン時、振り分けNG >>>>> (http://172.16.210.105:443/) >>>>> 設定： >>>>> virtual = 172.16.210.105:443 <http://172.16.210.105:443> >>>>> real = 172.16.210.125:443 <http://172.16.210.125:443> masq 1 >>>>> real = 172.16.210.126:443 <http://172.16.210.126:443> masq 1 >>>>> real = 172.16.210.127:443 <http://172.16.210.127:443> masq 1 >>>>> module = sessionless >>>>> scheduler = rr >>>>> sorryserver = 172.16.210.128:80 <http://172.16.210.128:80> >>>>> テスト時の接続URL： >>>>> https://172.16.210.105/ >>>>> >>>>> >>>>> 2) sslconfigfile設定時の動作について >>>>> sslconfigfile設定時の動作についてご教示頂けますでしょうか。 >>>>> UltraMonkey-L7 管理者マニュアル v3.2を確認しましたところ、 >>>>> sslconfigfileについて以下の様な記載がございました。 >>>>> 『VirtualService が Clientとの通信の際に SSL 通信を行う場合、 >>>>> SSL設定ファイルのパスを指定する。』 >>>>> 上記を踏まえ、 >>>>> クライアント-UltraMonkey間の通信はhttps >>>>> UltraMonkey-リアルサーバ間の通信はhttp,httpsの2パターンで試しましたところ、 >>>>> 以下の様な動作となりました。 >>>>> (1)UltraMonkey-リアルサーバ：http通信 >>>>> →リアルサーバへの振り分けは正常に行われる。 >>>>> (2)UltraMonkey-リアルサーバ：https通信 >>>>> →リアルサーバからHTTPステータスレコード『400 Bad Request』が返ってくる。 >>>>> (2)の動作が仕様として、正しい動作なのかご教示頂けますでしょうか。 >>>>> 外部(クライアント-UltraMonkey)はセキュリティの高いhttps、 >>>>> 内部(UltraMonkey-APサーバ)は負荷が低い速度の速いhttp >>>>> と考えると正しい動作なのではないかと考えております。 >>>>> >>>>> 以下にこちらで検証した内容とそのときの設定(一部抜粋)を記載します。 >>>>> 設定不備等ございましたら、ご指摘頂ければと存じます。 >>>>> 【設定】 >>>>> (1)UltraMonkey-リアルサーバ：http通信 >>>>> virtual = 172.16.210.105:443 <http://172.16.210.105:443> >>>>> real = 172.16.210.125:80 <http://172.16.210.125:80> masq 1 >>>>> real = 172.16.210.126:80 <http://172.16.210.126:80> masq 1 >>>>> real = 172.16.210.127:80 <http://172.16.210.127:80> masq 1 >>>>> module = sessionless >>>>> scheduler = rr >>>>> sorryserver = 172.16.210.128:80 <http://172.16.210.128:80> >>>>> テスト時の接続URL： >>>>> https://172.16.210.105/ >>>>> (2)UltraMonkey-リアルサーバ：https通信 >>>>> virtual = 172.16.210.105:443 <http://172.16.210.105:443> >>>>> real = 172.16.210.125:443 <http://172.16.210.125:443> masq 1 >>>>> real = 172.16.210.126:443 <http://172.16.210.126:443> masq 1 >>>>> real = 172.16.210.127:443 <http://172.16.210.127:443> masq 1 >>>>> module = sessionless >>>>> scheduler = rr >>>>> sorryserver = 172.16.210.128:443 <http://172.16.210.128:443> >>>>> テスト時の接続URL： >>>>> https://172.16.210.105/ >>>>> >>>>> 似たような問題が発生した方、解決方法をご存じの方がいらっしゃいましたら、 >>>>> ご教示頂けると幸いです。 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ultramonkey-l7-users mailing list >>>>> Ultra****@lists***** >>>>> http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users >>>> >>>> >>>> -- >>>> 雲雀 路朗 (Michiro Hibari) >>>> MAIL: hibar****@lab***** >>>> 所属: NTT OSSセンタ 基盤技術ユニット 高信頼担当 >>>> TEL : 03-5860-5135 / FAX: 03-5463-5490 >>>> >>>> _______________________________________________ >>>> Ultramonkey-l7-users mailing list >>>> Ultra****@lists***** >>>> http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users >> >> _______________________________________________ >> Ultramonkey-l7-users mailing list >> Ultra****@lists***** >> http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users >> >> >> > > -- > 中野 宏朗 (NAKANO Hiroaki) > > _______________________________________________ > Ultramonkey-l7-users mailing list > Ultra****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users
UltraMonkey-L7
Fork