中野 宏朗
nakan****@nttco*****
2013年 3月 26日 (火) 13:23:07 JST
中野@幕張です。 こんにちは。 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
Fork