From s.maru885 @ gmail.com Tue Mar 26 06:29:55 2013 From: s.maru885 @ gmail.com (s.maru885) Date: Tue, 26 Mar 2013 06:29:55 +0900 Subject: [Ultramonkey-l7-users 545] Re: =?iso-2022-jp?b?aHR0cHMbJEJETD8uO34kTkBfRGohIkYwOm4kSyREGyhC?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: References: <5137EEE8.5040308@lab.ntt.co.jp> Message-ID: お世話になっております。 丸水です。 本件に関連して質問させて頂きます。 現在、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でキューイングしているような動作をしており、 最大同時接続数を超えている場合、応答待ちとなり、 最大同時接続数を下回った後にリアルサーバに振り分けて 応答を返す。 ■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で最大同時接続数を 制限するようなことはしないかと思いますが、試しに確認しました。 似たような問題が発生した方、解決方法をご存じの方がいらっしゃいましたら、 ご教示頂けると幸いです。 2013年3月7日 22:21 s.maru885 : > 中野様、雲雀様 > > お世話になっております。 > 丸水です。 > >> Sorryサーバですが、現在HTTPのみの対応となっております。 >> HTTPSを利用される際には、fallback機能を利用されることをお勧めします。 > HTTPのみの対応であること承知いたしました。 > 通信の種類に合わせてSorryとfallbackを使い分けていきたいと思います。 > >> sslconfigfile設定時の動作としては、UM-L7でSSL通信を終端させるため、 >> UltraMonkey-リアルサーバ間はhttp通信となります。 > UltraMonkey-リアルサーバ間がhttp通信になること承知致しました。 > > > この度は、早々のご回答、誠に有難うございました。 > お陰様で不明な点を解消することができました。 > 厚く御礼申し上げます。 > > > それでは、今後とも宜しくお願い致します。 > > 2013年3月7日 10:35 Hibari Michiro : >> >> 丸水様 >> >> 初めまして。雲雀と申します。 >> >> > ■質問内容 >> > 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 振り分けOK >> > 172.16.210.126:443 振り分けOK >> > 172.16.210.127:443 振り分けOK >> > >> > 172.16.210.128:443 リアルサーバ全ダウン時、振り分けNG >> > 設定: >> > virtual = 172.16.210.105:443 >> > real = 172.16.210.125:443 masq 1 >> > real = 172.16.210.126:443 masq 1 >> > real = 172.16.210.127:443 masq 1 >> > module = sessionless >> > scheduler = rr >> > sorryserver = 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 >> > real = 172.16.210.126:443 masq 1 >> > real = 172.16.210.127:443 masq 1 >> > real = 172.16.210.128:443 masq 1 #元々はSorryサーバ >> > module = sessionless >> > scheduler = rr >> > sorryserver = 172.16.210.125:443 #元々はリアルサーバ >> > テスト時の接続URL: >> > https://172.16.210.105/ >> > >> > (2)https通信以外の動作を確認するため、 >> > 仮想サービス、各リアルサーバ、Sorryサーバのポートを80に設定し、 >> > http通信を振り分けられるか確認 >> > →リアルサーバへの振り分けは正常に行われ、 >> > リアルサーバ全ダウン時のSorryサーバへの振り分けも正常に行われた。 >> > 172.16.210.125:80 振り分けOK >> > 172.16.210.126:80 振り分けOK >> > 172.16.210.127:80 振り分けOK >> > >> > 172.16.210.128:80 リアルサーバ全ダウン時、振り分けOK >> > 設定: >> > virtual = 172.16.210.105:80 >> > real = 172.16.210.125:80 masq 1 >> > real = 172.16.210.126:80 masq 1 >> > real = 172.16.210.127:80 masq 1 >> > module = sessionless >> > scheduler = rr >> > sorryserver = 172.16.210.128:80 >> > テスト時の接続URL: >> > http://172.16.210.105/ >> > >> > (3)仮想サービス、各リアルサーバのポートを443、 >> > Sorryサーバのポートを80に設定し、https通信を振り分けられるか確認 >> > →リアルサーバへの振り分けは正常に行われたが、 >> > リアルサーバ全ダウン時のSorryサーバへの振り分けは失敗。 >> > ただし、http://172.16.210.105:443/(http 通 信)でアクセスしたところ、 >> > Sorryサーバへの振り分けは正常に行われた。 >> > 172.16.210.125:443 振り分けOK >> > 172.16.210.126:443 振り分けOK >> > 172.16.210.127:443 振り分けOK >> > >> > 172.16.210.128:80 リアルサーバ全ダウン時、振り分けNG >> > (https://172.16.210.105/) >> > 172.16.210.128:80 リアルサーバ全ダウン時、振り分けNG >> > (http://172.16.210.105:443/) >> > 設定: >> > virtual = 172.16.210.105:443 >> > real = 172.16.210.125:443 masq 1 >> > real = 172.16.210.126:443 masq 1 >> > real = 172.16.210.127:443 masq 1 >> > module = sessionless >> > scheduler = rr >> > sorryserver = 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 >> > real = 172.16.210.125:80 masq 1 >> > real = 172.16.210.126:80 masq 1 >> > real = 172.16.210.127:80 masq 1 >> > module = sessionless >> > scheduler = rr >> > sorryserver = 172.16.210.128:80 >> > テスト時の接続URL: >> > https://172.16.210.105/ >> > (2)UltraMonkey-リアルサーバ:https通信 >> > virtual = 172.16.210.105:443 >> > real = 172.16.210.125:443 masq 1 >> > real = 172.16.210.126:443 masq 1 >> > real = 172.16.210.127:443 masq 1 >> > module = sessionless >> > scheduler = rr >> > sorryserver = 172.16.210.128:443 >> > テスト時の接続URL: >> > https://172.16.210.105/ >> > >> > 似たような問題が発生した方、解決方法をご存じの方がいらっしゃいましたら、 >> > ご教示頂けると幸いです。 >> > >> > >> > _______________________________________________ >> > Ultramonkey-l7-users mailing list >> > Ultramonkey-l7-users @ lists.sourceforge.jp >> > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users >> >> >> -- >> 雲雀 路朗 (Michiro Hibari) >> MAIL: hibari.michiro @ lab.ntt.co.jp >> 所属: NTT OSSセンタ 基盤技術ユニット 高信頼担当 >> TEL : 03-5860-5135 / FAX: 03-5463-5490 >> >> _______________________________________________ >> Ultramonkey-l7-users mailing list >> Ultramonkey-l7-users @ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users From hibari.michiro @ lab.ntt.co.jp Tue Mar 26 09:32:58 2013 From: hibari.michiro @ lab.ntt.co.jp (Hibari Michiro) Date: Tue, 26 Mar 2013 09:32:58 +0900 Subject: [Ultramonkey-l7-users 546] Re: =?iso-2022-jp?b?aHR0cHMbJEJETD8uO34kTkBfRGohIkYwOm4kSyREGyhC?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: References: <5137EEE8.5040308@lab.ntt.co.jp> Message-ID: <5150ECBA.8090200@lab.ntt.co.jp> 丸水様 雲雀です。 お世話になっております。 > (1)最大同時接続数の制限 > (2)最大同時接続数を超えた状態でアクセスした場合、 > 即時エラー(またはSorry)を返す 最大同時接続数を超えた場合、即時エラーを 返す動作であれば、以下の設定で実現可能です。 maxconn=3 sorryserver=127.0.0.1:55555 <=ダミー(接続できないサーバを指定) sorryserverがつながる状態になければ、HTTPだろうが HTTPSだろうが、即座に切断することになるので、 期待する動作を満たせるかと思います。 #ちょっと裏技的な設定ですけれども。 SorryServer機能がHTTPSにも対応していればSorryコンテンツを 返すこともできるのですが・・・(いずれ改善したいと思っています) 参考までに、 > 備考: > 通常、session_thread_pool_sizeで最大同時接続数を > 制限するようなことはしないかと思いますが、試しに確認しました。 session_thread_pool_size は、今のところ全仮想サービス共通の設定です。 仮想サービスが1つなら上記手段も悪くないと思いますが、 複数の仮想サービスがある場合、他の仮想サービスまで最大同時接続数に 制限がかかってしまうので、あまり現実的でないですね。 次のバージョンでは、session_thread_pool_sizeを仮想サービス毎に 設定できるようになる予定です。 そうなれば、session_thread_pool_sizeを最大同時接続数の制限としても 使うことができると思います。 以上、宜しくお願いいたします。 (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でキューイングしているような動作をしており、 > 最大同時接続数を超えている場合、応答待ちとなり、 > 最大同時接続数を下回った後にリアルサーバに振り分けて > 応答を返す。 > > ■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で最大同時接続数を > 制限するようなことはしないかと思いますが、試しに確認しました。 > > > 似たような問題が発生した方、解決方法をご存じの方がいらっしゃいましたら、 > ご教示頂けると幸いです。 > > > -- 雲雀 路朗 (Michiro Hibari) MAIL: hibari.michiro @ lab.ntt.co.jp 所属: NTT OSSセンタ 基盤技術ユニット 高信頼担当 TEL : 03-5860-5135 / FAX: 03-5463-5490 From nakano.hiroaki @ nttcom.co.jp Tue Mar 26 13:23:07 2013 From: nakano.hiroaki @ nttcom.co.jp (=?ISO-2022-JP?B?GyRCQ2ZMbiEhOShPLxsoQg==?=) Date: Tue, 26 Mar 2013 13:23:07 +0900 Subject: [Ultramonkey-l7-users 547] Re: =?iso-2022-jp?b?aHR0cHMbJEJETD8uO34kTkBfRGohIkYwOm4kSyREGyhC?= =?iso-2022-jp?b?GyRCJCQkRhsoQg==?= In-Reply-To: References: <5137EEE8.5040308@lab.ntt.co.jp> Message-ID: <515122AB.2040403@nttcom.co.jp> 中野@幕張です。 こんにちは。 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 : >> 中野様、雲雀様 >> >> お世話になっております。 >> 丸水です。 >> >>> Sorryサーバですが、現在HTTPのみの対応となっております。 >>> HTTPSを利用される際には、fallback機能を利用されることをお勧めします。 >> HTTPのみの対応であること承知いたしました。 >> 通信の種類に合わせてSorryとfallbackを使い分けていきたいと思います。 >> >>> sslconfigfile設定時の動作としては、UM-L7でSSL通信を終端させるため、 >>> UltraMonkey-リアルサーバ間はhttp通信となります。 >> UltraMonkey-リアルサーバ間がhttp通信になること承知致しました。 >> >> >> この度は、早々のご回答、誠に有難うございました。 >> お陰様で不明な点を解消することができました。 >> 厚く御礼申し上げます。 >> >> >> それでは、今後とも宜しくお願い致します。 >> >> 2013年3月7日 10:35 Hibari Michiro : >>> >>> 丸水様 >>> >>> 初めまして。雲雀と申します。 >>> >>>> ■質問内容 >>>> 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 振り分けOK >>>> 172.16.210.126:443 振り分けOK >>>> 172.16.210.127:443 振り分けOK >>>> >>>> 172.16.210.128:443 リアルサーバ全ダウン時、振り分けNG >>>> 設定: >>>> virtual = 172.16.210.105:443 >>>> real = 172.16.210.125:443 masq 1 >>>> real = 172.16.210.126:443 masq 1 >>>> real = 172.16.210.127:443 masq 1 >>>> module = sessionless >>>> scheduler = rr >>>> sorryserver = 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 >>>> real = 172.16.210.126:443 masq 1 >>>> real = 172.16.210.127:443 masq 1 >>>> real = 172.16.210.128:443 masq 1 #元々はSorryサーバ >>>> module = sessionless >>>> scheduler = rr >>>> sorryserver = 172.16.210.125:443 #元々はリアルサーバ >>>> テスト時の接続URL: >>>> https://172.16.210.105/ >>>> >>>> (2)https通信以外の動作を確認するため、 >>>> 仮想サービス、各リアルサーバ、Sorryサーバのポートを80に設定し、 >>>> http通信を振り分けられるか確認 >>>> →リアルサーバへの振り分けは正常に行われ、 >>>> リアルサーバ全ダウン時のSorryサーバへの振り分けも正常に行われた。 >>>> 172.16.210.125:80 振り分けOK >>>> 172.16.210.126:80 振り分けOK >>>> 172.16.210.127:80 振り分けOK >>>> >>>> 172.16.210.128:80 リアルサーバ全ダウン時、振り分けOK >>>> 設定: >>>> virtual = 172.16.210.105:80 >>>> real = 172.16.210.125:80 masq 1 >>>> real = 172.16.210.126:80 masq 1 >>>> real = 172.16.210.127:80 masq 1 >>>> module = sessionless >>>> scheduler = rr >>>> sorryserver = 172.16.210.128:80 >>>> テスト時の接続URL: >>>> http://172.16.210.105/ >>>> >>>> (3)仮想サービス、各リアルサーバのポートを443、 >>>> Sorryサーバのポートを80に設定し、https通信を振り分けられるか確認 >>>> →リアルサーバへの振り分けは正常に行われたが、 >>>> リアルサーバ全ダウン時のSorryサーバへの振り分けは失敗。 >>>> ただし、http://172.16.210.105:443/(http 通 信)でアクセスしたところ、 >>>> Sorryサーバへの振り分けは正常に行われた。 >>>> 172.16.210.125:443 振り分けOK >>>> 172.16.210.126:443 振り分けOK >>>> 172.16.210.127:443 振り分けOK >>>> >>>> 172.16.210.128:80 リアルサーバ全ダウン時、振り分けNG >>>> (https://172.16.210.105/) >>>> 172.16.210.128:80 リアルサーバ全ダウン時、振り分けNG >>>> (http://172.16.210.105:443/) >>>> 設定: >>>> virtual = 172.16.210.105:443 >>>> real = 172.16.210.125:443 masq 1 >>>> real = 172.16.210.126:443 masq 1 >>>> real = 172.16.210.127:443 masq 1 >>>> module = sessionless >>>> scheduler = rr >>>> sorryserver = 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 >>>> real = 172.16.210.125:80 masq 1 >>>> real = 172.16.210.126:80 masq 1 >>>> real = 172.16.210.127:80 masq 1 >>>> module = sessionless >>>> scheduler = rr >>>> sorryserver = 172.16.210.128:80 >>>> テスト時の接続URL: >>>> https://172.16.210.105/ >>>> (2)UltraMonkey-リアルサーバ:https通信 >>>> virtual = 172.16.210.105:443 >>>> real = 172.16.210.125:443 masq 1 >>>> real = 172.16.210.126:443 masq 1 >>>> real = 172.16.210.127:443 masq 1 >>>> module = sessionless >>>> scheduler = rr >>>> sorryserver = 172.16.210.128:443 >>>> テスト時の接続URL: >>>> https://172.16.210.105/ >>>> >>>> 似たような問題が発生した方、解決方法をご存じの方がいらっしゃいましたら、 >>>> ご教示頂けると幸いです。 >>>> >>>> >>>> _______________________________________________ >>>> Ultramonkey-l7-users mailing list >>>> Ultramonkey-l7-users @ lists.sourceforge.jp >>>> http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users >>> >>> >>> -- >>> 雲雀 路朗 (Michiro Hibari) >>> MAIL: hibari.michiro @ lab.ntt.co.jp >>> 所属: NTT OSSセンタ 基盤技術ユニット 高信頼担当 >>> TEL : 03-5860-5135 / FAX: 03-5463-5490 >>> >>> _______________________________________________ >>> Ultramonkey-l7-users mailing list >>> Ultramonkey-l7-users @ lists.sourceforge.jp >>> http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users > > _______________________________________________ > Ultramonkey-l7-users mailing list > Ultramonkey-l7-users @ lists.sourceforge.jp > http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users > > > -- 中野 宏朗 (NAKANO Hiroaki)