s.maru885
s.mar****@gmail*****
2013年 3月 7日 (木) 04:36:14 JST
UltraMonkey-L7
Forkはじめまして、丸水と申します。
長文にて失礼致します。
現在、下記の構成にて、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/
似たような問題が発生した方、解決方法をご存じの方がいらっしゃいましたら、
ご教示頂けると幸いです。
-------------- next part --------------
HTMLの添付ファイルを保管しました...
다운로드