From tadashi.1027 ＠ gmail.com Wed Feb 3 11:20:51 2010 From: tadashi.1027 ＠ gmail.com (=?ISO-2022-JP?B?GyRCMHAzQBsoQg==?=) Date: Wed, 03 Feb 2010 11:20:51 +0900 Subject: [Ultramonkey-l7-users 300] Re: =?iso-2022-jp?b?ZmFsbGJhY2sbJEJAX0RqJEskRCQkJEYbKEI=?= In-Reply-To: <4B67BCE9.6060301@nttcom.co.jp> References: <4B6784C9.1050200@gmail.com> <4B679088.2000904@nttcom.co.jp> <4B679420.2090407@gmail.com> <4B679689.5000301@nttcom.co.jp> <4B6799AC.3080608@gmail.com> <4B67BCE9.6060301@nttcom.co.jp> Message-ID: <4B68DD83.2000200@gmail.com> 田沼様 お世話になります。 稲垣です。 /etc/ha.d/ldirectord.cfに127.0.0.1:80を追加しましたが、 fallbackの設定が追加されなくなりました。 # ipvsadm -l IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 172.31.208.181:https rr -> 192.168.1.1:https Masq 1 0 0 -> 192.168.1.2:https Masq 1 0 0 TCP 172.31.208.181:http rr -> 192.168.1.2:http Masq 1 0 1 -> 192.168.1.1:http Masq 1 0 1 なんででしょうか？ 以上、宜しくお願い致します。 Kohei TANUMA さんは書きました: > 稲垣さま > > 田沼です。 > > LVS の理解が不足してるので間違っているかもしれませんが > 私なりにわかったところまで回答します。 > 先に結論として、127.0.0.1 を real や fallback に指定する場合は > バーチャルサービスと同一のポートで動かす必要があるのではないかと > 思います。（つまり fallback 81 番ポートは無理） > そのため、先程の私の masq を指定するというのは間違いのようです。 > > 127.0.0.1 への振り分けはダイレクトにパケットが配送される > ようで、バーチャルサービス宛(172.31.207.10:80宛) のパケットが > 127.0.0.1:81 の Apache に飛ぶのでコネクションがリセットされて > いるように見えます。 > 試しに、iptables で 80 宛を 81 宛に無理やり書き換えると、 > Apache で正常に処理することができました。 > > iptables -t nat -A PREROUTING -i eth0 -p tcp -d 172.31.207.10 --dport 80 > -j DNAT --to 172.31.207.10:81 > > ただし、これだと通常の real が使い物にならなくなるので却下…。 > （上記 iptables の -A を -D で削除） > > 以下の設定で動作確認できました。 > > ■ ldirectord > fallback = 127.0.0.1:80 > virtual = 172.31.207.10:80 > real = 172.31.206.1:80 masq 1 > real = 172.31.206.2:80 masq 1 > checktype = negotiate > service = http > request = "index.html" > receive = "test" > scheduler = rr > protocol = tcp > > ■ 172.31.207.10 の Apache > ... > Listen 80 > ... > > ■ ipvsadm -ln (real が正常な場合) > IP Virtual Server version 1.2.1 (size=4096) > Prot LocalAddress:Port Scheduler Flags > -> RemoteAddress:Port Forward Weight ActiveConn InActConn > TCP 172.31.207.10:80 rr > -> 172.31.206.1:80 Masq 1 0 0 > -> 172.31.206.2:80 Masq 1 0 0 > > ■ ipvsadm -ln (real 全てが異常な場合 - index.html の test 文字を消す) > IP Virtual Server version 1.2.1 (size=4096) > Prot LocalAddress:Port Scheduler Flags > -> RemoteAddress:Port Forward Weight ActiveConn InActConn > TCP 172.31.207.10:80 rr > -> 127.0.0.1:80 Local 1 0 0 > -> 172.31.206.1:80 Masq 0 0 0 > -> 172.31.206.2:80 Masq 0 0 0 > > とりあえず上記で fallback の Apache のページが表示されました。 > > 稲垣さんの設定の場合だと fallback のポートを 80 に設定し > （masq も消して）172.31.207.10 のサーバで HTTPd を 80 ポートで > 動かすように修正する必要があると思います。 > > ただし、間違いがあるかもしれませんので、他の識者の方々つっこみ > お願いします。 > > 以上です。 > > > 2010/02/02 12:19, 稲垣 wrote: > >> 田沼様 >> >> お世話になっております。 >> 稲垣です。 >> >> コマンド結果は以下の通りです。 >> # ipvsadm -ln >> IP Virtual Server version 1.2.1 (size=4096) >> Prot LocalAddress:Port Scheduler Flags >> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >> TCP 172.31.207.10:80 rr >> -> 127.0.0.1:81 Local 1 0 1 >> >> 以上宜しくお願いします。 >> >> Kohei TANUMA さんは書きました: >> >>> 稲垣さま >>> >>> 田沼です。 >>> >>> 表示されないというのはページが表示されないという意味でしょうか？ >>> 先のメールの ipvsadm の結果では以下のように fallback サーバの >>> ポートを 81 に設定しているにもかかわらずポートが 80 で >>> 追加されているのが問題と考えました。 >>> >>> >>> >>>>>> TCP 172.31.207.10:http rr >>>>>> -> LB01:http Local 1 0 0 >>>>>> >>>>>> >>> masq を追加した後の ipvsadm -ln の結果を >>> 確認させていただけますでしょうか。 >>> >>> >>> 2010/02/02 11:55, 稲垣 wrote: >>> >>> >>>> 田沼様 >>>> >>>> お世話になっております。 >>>> 稲垣です。 >>>> >>>> >>>> >>>>> fallback=127.0.0.1:81 masq >>>>> >>>>> >>>>> >>>> ご指摘の通りに設定しましたが、表示されません。 >>>> >>>> 以上、宜しくお願い致します。 >>>> >>>> >>>> Kohei TANUMA さんは書きました: >>>> >>>> >>>>> 稲垣さま >>>>> >>>>> 田沼と申します。 >>>>> >>>>> LVS についてはあまりわからないのですが、 >>>>> ldirectord の動作を確認したところ fallback 行で >>>>> forward 設定を省略すると gate として設定されるようです。 >>>>> ldirectord.cf の fallback を以下のように変更してみてください。 >>>>> >>>>> fallback=127.0.0.1:81 masq >>>>> >>>>> 以上です。 >>>>> >>>>> >>>>> 2010/02/02 10:50, 稲垣 wrote: >>>>> >>>>> >>>>> >>>>>> お世話になっております。 >>>>>> 稲垣です。 >>>>>> >>>>>> ipvsadmコマンドで全リアルサーバ(HTTP)をメンテナンス状態にし、 >>>>>> fallbackサーバを表示させたいのですが、 >>>>>> /etc/ha.d/ldirectord.cfに記載したfallbackサーバが表示されません。 >>>>>> >>>>>> ipvsadm -lの状態はfallbackサーバを表示しております。 >>>>>> >>>>>> /etc/ha.d/ldirectord.cfの設定はHTTPのリアル設定をコメントしております。 >>>>>> /etc/httpd/conf/httpd.confのListenは81になっており、直にたたくと問題なく >>>>>> 表示されます。 >>>>>> >>>>>> >>>>>> # ipvsadm -l >>>>>> IP Virtual Server version 1.2.1 (size=4096) >>>>>> Prot LocalAddress:Port Scheduler Flags >>>>>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>>>>> TCP 172.31.207.10:http rr >>>>>> -> LB01:http Local 1 0 0 >>>>>> >>>>>> # cat /etc/ha.d/ldirectord.cf >>>>>> >>>>>> # Global Directives >>>>>> checktimeout=3 >>>>>> checkinterval=1 >>>>>> fallback=127.0.0.1:81 >>>>>> autoreload=no >>>>>> logfile="/var/log/ldirectord.log" >>>>>> #logfile="local0" >>>>>> #emailalert="admin ＠ x.y.z" >>>>>> #emailalertfreq=3600 >>>>>> #emailalertstatus=all >>>>>> quiescent=no >>>>>> >>>>>> # Sample for an http virtual service >>>>>> virtual=172.31.207.10:80 >>>>>> # real=172.31.206.1:80 masq 1 >>>>>> # real=172.31.206.2:80 masq 1 >>>>>> service=http >>>>>> request="index.html" >>>>>> # receive="Test Page" >>>>>> scheduler=rr >>>>>> # persistent=600 >>>>>> # netmask=255.255.255.255 >>>>>> # protocol=tcp >>>>>> checktype=negotiate >>>>>> >>>>>> 何か設定不備等ありますか？ >>>>>> 以上、ご教授の程宜しくお願いします。 >>>>>> >>>>>> > > From tadashi.1027 ＠ gmail.com Wed Feb 3 11:45:33 2010 From: tadashi.1027 ＠ gmail.com (=?ISO-2022-JP?B?GyRCMHAzQBsoQg==?=) Date: Wed, 03 Feb 2010 11:45:33 +0900 Subject: [Ultramonkey-l7-users 301] Re: =?iso-2022-jp?b?VWx0cmFNb25rZXkbJEIkRyROGyhCSVAbJEJGKTJhGyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <20100126.184909.756168950323994513.tateishi.katsuyuki@oss.ntt.co.jp> References: <4B5E8A0E.6010700@gmail.com> <4B5E96A1.3050101@gmail.com> <20100126.184909.756168950323994513.tateishi.katsuyuki@oss.ntt.co.jp> Message-ID: <4B68E34D.2090406@gmail.com> お世話になります。 稲垣です。 UltraMonkey-L4でNATモード、ワンアームで IPエイリアスを使って仮想的にツーアームに見せ掛け 成功した事例はありますか？ 以上、宜しくお願い致します。 TATEISHI Katsuyuki さんは書きました: > 稲垣さま、 > 立石です。こんばんは。 > > 稲垣 -san wrote: > > >> 送信元IPを透過したいとき、 >> NATモードを使う場合はツーアーム構成で、 >> DSRモードを使う場合はワンアーム構成ということですね。 >> >> > (略) > >>> ワンアーム構成（同一セグメント）での NAT 設定では，ソース IP アドレスを >>> 残すことはできません． >>> これは TCP/IP の通信方式に起因する制約です． >>> UltraMonkey-L7 を使用した場合と同じです． >>> > > 試していないので、動くかどうかわからないのですが、ワンアーム > 構成（同一セグメント）の場合には、リアルサーバのデフォルトルー > タとして LB サーバ を設定することで NAT 設定でも動作するかも > しれません。 > > ●同一セグメントでNAT構成が動かない理由(想像) > > リアルサーバがそのセグメントの本当のルータ(router)をデフォル > トルータとしている場合(いわゆる普通の設定です)、NAT構成では > > client -> router -> lb -> real > > # router の左右でネットワークセグメントが分かれていると思って > # 下さい > > 上記のように届くパケットの送信元が client のものであり、real > サーバは返信パケットを > > client <- router <- real > > のように投げてしまうのでlb サーバが書き換えできず、返信パケッ > トの送信元が real サーバの IP アドレスのままになってしまい、 > クライアントは身に覚えのないパケットとして捨ててしまうはずで > す。これがワンアーム構成（同一セグメント）で NAT 設定が動かな > い理由だと思います。 > > > ●同一セグメントでNAT構成を動かせるかもしれない方法 > > そこで real サーバのデフォルトルータとして router ではなく、 > lb を指定してやることで、返信パケットが > > client <- router <- lb <- real > > のように通るようになります。 > > 本来のルータが見えているのに他のマシンをデフォルトルータに設 > 定するのはかなり異質な感じがしますが、これで lb で返信パケッ > トの送信元IPアドレスをlbサーバのものに書き換えできるのではな > いかなと想像しています。 > > ただし、この場合も同一セグメントに client がある場合は動作し > ないはずです(real は client が自分と同じネットワークにいるこ > とがわかるのでデフォゲ(lb)に投げません)。 > > ●その他 > > lb サーバに NIC は2枚あるけどネットワークを分けたくないだけ、 > ということであれば lb サーバをブリッジとして設定したうえで、 > real サーバをルータから見て lb サーバの向こう側に接続してやれ > ばデフォルトルータをいじらなくても動くかもしれません(こちらも > 想像です) > > > 以上、手元に環境がないので試せていませんが参考になれば・・・ > > -- > TATEISHI Katsuyuki > > >>> >>> ワンアーム構成でソース IP アドレスを残したい場合は， >>> DSR モードを使用する必要があります． >>> >>> BIG-IP と同様に，ワンアーム構成の NAT モードでは LB サーバに >>> SNAT の設定を行う必要があるのですが，SNAT を実施した時点で TCP ヘッダ上の >>> ソース IP アドレスが LB サーバのものとなるため，リアルサーバにパケットが >>> 到着した段階でクライアントのソース IP アドレスは失われた状態となります． >>> >>> ツーアーム（別セグメント）構成では，リアルサーバ側とクライアント側の >>> ネットワークを物理・論理的に分割しリアルサーバのデフォルトゲートウェイを >>> LB サーバに設定することで，通常のルーティングのような見せ方を >>> することができるため，ソース IP アドレスを残すことができるのです． >>> >>> ----------------------------------------------------------- >>> Shinya TAKEBAYASHI >>> >>> E-mail: takebayashi.shinya ＠ oss.ntt.co.jp >>> GPG ID: E2695938 >>> GPG FP: 0412 40A9 B385 17EB 1E49 D2D2 DECA 8DE1 E269 5938 >>> ----------------------------------------------------------- >>> >>> >> _______________________________________________ >> Ultramonkey-l7-users mailing list >> Ultramonkey-l7-users ＠ lists.sourceforge.jp >> http://lists.sourceforge.jp/mailman/listinfo/ultramonkey-l7-users >> From tanuma.kouhei ＠ nttcom.co.jp Wed Feb 3 13:43:35 2010 From: tanuma.kouhei ＠ nttcom.co.jp (Kohei TANUMA) Date: Wed, 03 Feb 2010 13:43:35 +0900 Subject: [Ultramonkey-l7-users 302] Re: =?iso-2022-jp?b?ZmFsbGJhY2sbJEJAX0RqJEskRCQkJEYbKEI=?= In-Reply-To: <4B68DD83.2000200@gmail.com> References: <4B6784C9.1050200@gmail.com> <4B679088.2000904@nttcom.co.jp> <4B679420.2090407@gmail.com> <4B679689.5000301@nttcom.co.jp> <4B6799AC.3080608@gmail.com> <4B67BCE9.6060301@nttcom.co.jp> <4B68DD83.2000200@gmail.com> Message-ID: <4B68FEF7.3040901@nttcom.co.jp> 稲垣さま 田沼です。 fallback は実際のリアルサーバが全て異常と判断された際の 代替サーバになりますので、リアルサーバが正常な場合は 追加されない仕様のはずです。 リアルサーバの監視は ldirectord の checktype や service 設定に 従いますので、例えば、checktype = negotiate, service = http の 場合は、192.168.1.1, 192.168.1.2 の Apache 等を停止した際に fallback 設定の 127.0.0.1:80 が自動的に追加されるはずです。 checktype = ping の場合は、ケーブルを抜く、インタフェースを down させるなどして ping がリアルサーバに届かない状態にして みてください。 checktype = on の場合は、常にリアルサーバが正常と判断されるため fallback は追加されないと思います。 以上、宜しくお願い致します。 2010/02/03 11:20, 稲垣 wrote: > 田沼様 > > お世話になります。 > 稲垣です。 > > /etc/ha.d/ldirectord.cfに127.0.0.1:80を追加しましたが、 > fallbackの設定が追加されなくなりました。 > > # ipvsadm -l > IP Virtual Server version 1.2.1 (size=4096) > Prot LocalAddress:Port Scheduler Flags > -> RemoteAddress:Port Forward Weight ActiveConn InActConn > TCP 172.31.208.181:https rr > -> 192.168.1.1:https Masq 1 0 0 > -> 192.168.1.2:https Masq 1 0 0 > TCP 172.31.208.181:http rr > -> 192.168.1.2:http Masq 1 0 1 > -> 192.168.1.1:http Masq 1 0 1 > > なんででしょうか？ > > 以上、宜しくお願い致します。 > > > Kohei TANUMA さんは書きました: >> 稲垣さま >> >> 田沼です。 >> >> LVS の理解が不足してるので間違っているかもしれませんが >> 私なりにわかったところまで回答します。 >> 先に結論として、127.0.0.1 を real や fallback に指定する場合は >> バーチャルサービスと同一のポートで動かす必要があるのではないかと >> 思います。（つまり fallback 81 番ポートは無理） >> そのため、先程の私の masq を指定するというのは間違いのようです。 >> >> 127.0.0.1 への振り分けはダイレクトにパケットが配送される >> ようで、バーチャルサービス宛(172.31.207.10:80宛) のパケットが >> 127.0.0.1:81 の Apache に飛ぶのでコネクションがリセットされて >> いるように見えます。 >> 試しに、iptables で 80 宛を 81 宛に無理やり書き換えると、 >> Apache で正常に処理することができました。 >> >> iptables -t nat -A PREROUTING -i eth0 -p tcp -d 172.31.207.10 --dport 80 >> -j DNAT --to 172.31.207.10:81 >> >> ただし、これだと通常の real が使い物にならなくなるので却下…。 >> （上記 iptables の -A を -D で削除） >> >> 以下の設定で動作確認できました。 >> >> ■ ldirectord >> fallback = 127.0.0.1:80 >> virtual = 172.31.207.10:80 >> real = 172.31.206.1:80 masq 1 >> real = 172.31.206.2:80 masq 1 >> checktype = negotiate >> service = http >> request = "index.html" >> receive = "test" >> scheduler = rr >> protocol = tcp >> >> ■ 172.31.207.10 の Apache >> ... >> Listen 80 >> ... >> >> ■ ipvsadm -ln (real が正常な場合) >> IP Virtual Server version 1.2.1 (size=4096) >> Prot LocalAddress:Port Scheduler Flags >> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >> TCP 172.31.207.10:80 rr >> -> 172.31.206.1:80 Masq 1 0 0 >> -> 172.31.206.2:80 Masq 1 0 0 >> >> ■ ipvsadm -ln (real 全てが異常な場合 - index.html の test 文字を消す) >> IP Virtual Server version 1.2.1 (size=4096) >> Prot LocalAddress:Port Scheduler Flags >> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >> TCP 172.31.207.10:80 rr >> -> 127.0.0.1:80 Local 1 0 0 >> -> 172.31.206.1:80 Masq 0 0 0 >> -> 172.31.206.2:80 Masq 0 0 0 >> >> とりあえず上記で fallback の Apache のページが表示されました。 >> >> 稲垣さんの設定の場合だと fallback のポートを 80 に設定し >> （masq も消して）172.31.207.10 のサーバで HTTPd を 80 ポートで >> 動かすように修正する必要があると思います。 >> >> ただし、間違いがあるかもしれませんので、他の識者の方々つっこみ >> お願いします。 >> >> 以上です。 >> >> >> 2010/02/02 12:19, 稲垣 wrote: >> >>> 田沼様 >>> >>> お世話になっております。 >>> 稲垣です。 >>> >>> コマンド結果は以下の通りです。 >>> # ipvsadm -ln >>> IP Virtual Server version 1.2.1 (size=4096) >>> Prot LocalAddress:Port Scheduler Flags >>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>> TCP 172.31.207.10:80 rr >>> -> 127.0.0.1:81 Local 1 0 1 >>> >>> 以上宜しくお願いします。 >>> >>> Kohei TANUMA さんは書きました: >>> >>>> 稲垣さま >>>> >>>> 田沼です。 >>>> >>>> 表示されないというのはページが表示されないという意味でしょうか？ >>>> 先のメールの ipvsadm の結果では以下のように fallback サーバの >>>> ポートを 81 に設定しているにもかかわらずポートが 80 で >>>> 追加されているのが問題と考えました。 >>>> >>>> >>>> >>>>>>> TCP 172.31.207.10:http rr >>>>>>> -> LB01:http Local 1 0 0 >>>>>>> >>>>>>> >>>> masq を追加した後の ipvsadm -ln の結果を >>>> 確認させていただけますでしょうか。 >>>> >>>> >>>> 2010/02/02 11:55, 稲垣 wrote: >>>> >>>> >>>>> 田沼様 >>>>> >>>>> お世話になっております。 >>>>> 稲垣です。 >>>>> >>>>> >>>>> >>>>>> fallback=127.0.0.1:81 masq >>>>>> >>>>>> >>>>>> >>>>> ご指摘の通りに設定しましたが、表示されません。 >>>>> >>>>> 以上、宜しくお願い致します。 >>>>> >>>>> >>>>> Kohei TANUMA さんは書きました: >>>>> >>>>> >>>>>> 稲垣さま >>>>>> >>>>>> 田沼と申します。 >>>>>> >>>>>> LVS についてはあまりわからないのですが、 >>>>>> ldirectord の動作を確認したところ fallback 行で >>>>>> forward 設定を省略すると gate として設定されるようです。 >>>>>> ldirectord.cf の fallback を以下のように変更してみてください。 >>>>>> >>>>>> fallback=127.0.0.1:81 masq >>>>>> >>>>>> 以上です。 >>>>>> >>>>>> >>>>>> 2010/02/02 10:50, 稲垣 wrote: >>>>>> >>>>>> >>>>>> >>>>>>> お世話になっております。 >>>>>>> 稲垣です。 >>>>>>> >>>>>>> ipvsadmコマンドで全リアルサーバ(HTTP)をメンテナンス状態にし、 >>>>>>> fallbackサーバを表示させたいのですが、 >>>>>>> /etc/ha.d/ldirectord.cfに記載したfallbackサーバが表示されません。 >>>>>>> >>>>>>> ipvsadm -lの状態はfallbackサーバを表示しております。 >>>>>>> >>>>>>> /etc/ha.d/ldirectord.cfの設定はHTTPのリアル設定をコメントしております。 >>>>>>> /etc/httpd/conf/httpd.confのListenは81になっており、直にたたくと問題なく >>>>>>> 表示されます。 >>>>>>> >>>>>>> >>>>>>> # ipvsadm -l >>>>>>> IP Virtual Server version 1.2.1 (size=4096) >>>>>>> Prot LocalAddress:Port Scheduler Flags >>>>>>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>>>>>> TCP 172.31.207.10:http rr >>>>>>> -> LB01:http Local 1 0 0 >>>>>>> >>>>>>> # cat /etc/ha.d/ldirectord.cf >>>>>>> >>>>>>> # Global Directives >>>>>>> checktimeout=3 >>>>>>> checkinterval=1 >>>>>>> fallback=127.0.0.1:81 >>>>>>> autoreload=no >>>>>>> logfile="/var/log/ldirectord.log" >>>>>>> #logfile="local0" >>>>>>> #emailalert="admin ＠ x.y.z" >>>>>>> #emailalertfreq=3600 >>>>>>> #emailalertstatus=all >>>>>>> quiescent=no >>>>>>> >>>>>>> # Sample for an http virtual service >>>>>>> virtual=172.31.207.10:80 >>>>>>> # real=172.31.206.1:80 masq 1 >>>>>>> # real=172.31.206.2:80 masq 1 >>>>>>> service=http >>>>>>> request="index.html" >>>>>>> # receive="Test Page" >>>>>>> scheduler=rr >>>>>>> # persistent=600 >>>>>>> # netmask=255.255.255.255 >>>>>>> # protocol=tcp >>>>>>> checktype=negotiate >>>>>>> >>>>>>> 何か設定不備等ありますか？ >>>>>>> 以上、ご教授の程宜しくお願いします。 From tanuma.kouhei ＠ nttcom.co.jp Wed Feb 3 13:45:58 2010 From: tanuma.kouhei ＠ nttcom.co.jp (Kohei TANUMA) Date: Wed, 03 Feb 2010 13:45:58 +0900 Subject: [Ultramonkey-l7-users 303] Re: =?iso-2022-jp?b?aXB2c2FkbRskQiUzJV4lcyVJJE4xP01RJEskRCQkGyhC?= =?iso-2022-jp?b?GyRCJEYbKEI=?= In-Reply-To: <4B679ADF.6040903@gmail.com> References: <4B67869C.4040809@gmail.com> <4B67957E.5020000@nttcom.co.jp> <4B679ADF.6040903@gmail.com> Message-ID: <4B68FF86.9020906@nttcom.co.jp> 稲垣さま 田沼です。 バーチャルサービスを無効化する場合は ご想像のとおり紐づいているリアルサーバの weight を全て 0 にすればいいと考えます。 以上です。 2010/02/02 12:24, 稲垣 wrote: > 田沼様 > > ご回答どうもありがとうございます。 > > weightを0にするやり方がよさそうですね。 > つまり、バーチャルサービス丸ごと無効化したい場合は、 > それに紐づく全てのリアルサービスのweightを0にしてやればよいということで > しょうか？ > > 以上、宜しくお願い致します。 > > > Kohei TANUMA さんは書きました: >> 稲垣さま >> >> 田沼です。 >> >> こちらについては要件にもよるかと思います。 >> 削除と無効化ではサービス停止には変わりはないですが、 >> 既存の接続をどのように扱うかが異なります。 >> >> バーチャルサービスやリアルサーバを削除した場合、 >> その際に接続しているクライアントが全て切断されますが、 >> リアルサーバを無効化した場合は、新規のクライアントのみが >> 接続できなくなり、無効化した際に接続しているクライアントは >> そのまま維持されます。 >> （接続したままのクライアント数は ipvsadm の ActiveConn の >> 数や ipvsadm -lc で確認できると思います） >> メンテナンス時など、とりあえず新規コネクションは止めて >> 既存コネクションがはけてからメンテナンスを行うなどの場合は >> 無効にする方法が有効かと思います。 >> >> 無効化は以下のコマンドでリアルサーバの weight を 0 にする >> ことで実現されます。 >> >> ■ real が gate 設定の場合 >> ipvsadm -e -t VIRTUAL:PORT -r REAL:PORT -g -w 0 >> >> ■ real が masq 設定の場合 >> ipvsadm -e -t VIRTUAL:PORT -r REAL:PORT -m -w 0 >> >> 詳細は man ipvsadm (-w, --weight のところ) をご確認ください。 >> >> 以上です。 >> >> >> >> 2010/02/02 10:57, 稲垣 wrote: >> >>> お世話になっております。 >>> 稲垣です。 >>> >>> /etc/ha.d/ldirecotord.cfファイルの設定をいじらずに >>> ipvsadmコマンドでバーチャルサービス、リアルサービスの >>> 有効無効を制御したいと考えております。 >>> >>> そういった場合は、バーチャルサービス、リアルサービスを >>> 削除する方法がいいのでしょうか？ >>> >>> それとも、バーチャルサービス、リアルサービスを残したまま >>> 文字通り「有効・無効」に切り替えることはできるでしょうか？ >>> >>> 以上、宜しくお願い致します。 From tateishi.katsuyuki ＠ oss.ntt.co.jp Wed Feb 3 13:51:11 2010 From: tateishi.katsuyuki ＠ oss.ntt.co.jp (TATEISHI Katsuyuki) Date: Wed, 03 Feb 2010 13:51:11 +0900 (JST) Subject: [Ultramonkey-l7-users 304] Re: =?iso-2022-jp?b?VWx0cmFNb25rZXkbJEIkRyROGyhCSVAbJEJGKTJhGyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4B68E34D.2090406@gmail.com> References: <4B5E96A1.3050101@gmail.com> <20100126.184909.756168950323994513.tateishi.katsuyuki@oss.ntt.co.jp> <4B68E34D.2090406@gmail.com> Message-ID: <20100203.135111.580906918135309375.tateishi.katsuyuki@oss.ntt.co.jp> 立石です。こんにちは。 稲垣 -san wrote: > UltraMonkey-L4でNATモード、ワンアームで > IPエイリアスを使って仮想的にツーアームに見せ掛け > 成功した事例はありますか？ どのような環境を想定されているのか、ちょっとよくつかめまない ので、具体的におねがいします。 例えば以下のような、一つのEthernetセグメントに対して異な るネットワークを二つ載せるような構成でしょうか？ # 等幅フォントで表示しないとズレると思います。 +--------+ | client | +---+----+ | +---+----+ | router | +---+----+ IP address: 192.168.1.1/24 | +-------+ | | | +---+----+ IPaddr: 192.168.1.2/24, alias 192.168.254.2/24 | | UM | | +--------+ | +-------+ | | | +---+----+ IPaddr: 192.168.254.10/24 | | Web0 | | +--------+ | +-------+ | +---+----+ IPaddr: 192.168.254.11/24 | Web1 | +--------+ (router が 192.168.1.0/24 だと思っているネットワークに実は 192.168.254.0/24 のパケットも流れているような構成) リアルサーバ(Web0, Web1)におけるデフォルトルータがUMの 192.168.254.2 を向いていれば動作すると思いますが、試したこと はないです。事例についても不明です。 最終的にやりたいことは、どんなことでしょう？ -- TATEISHI Katsuyuki From tadashi.1027 ＠ gmail.com Wed Feb 3 13:58:01 2010 From: tadashi.1027 ＠ gmail.com (=?ISO-2022-JP?B?GyRCMHAzQBsoQg==?=) Date: Wed, 03 Feb 2010 13:58:01 +0900 Subject: [Ultramonkey-l7-users 305] Re: =?iso-2022-jp?b?ZmFsbGJhY2sbJEJAX0RqJEskRCQkJEYbKEI=?= In-Reply-To: <4B68FEF7.3040901@nttcom.co.jp> References: <4B6784C9.1050200@gmail.com> <4B679088.2000904@nttcom.co.jp> <4B679420.2090407@gmail.com> <4B679689.5000301@nttcom.co.jp> <4B6799AC.3080608@gmail.com> <4B67BCE9.6060301@nttcom.co.jp> <4B68DD83.2000200@gmail.com> <4B68FEF7.3040901@nttcom.co.jp> Message-ID: <4B690259.7090601@gmail.com> 田沼様 お世話になります。 稲垣です。 リアルサーバのhttpdを停止したらfallbackのあて先が表示されました。 ただ、httpsの方がfallbackに同じ宛先を指定しているのですが表示されません。 「プロキシサーバへの接続を拒否されました。」 がブラウザに表示されます。 以上、宜しくお願いします。 Kohei TANUMA さんは書きました: > 稲垣さま > > 田沼です。 > > fallback は実際のリアルサーバが全て異常と判断された際の > 代替サーバになりますので、リアルサーバが正常な場合は > 追加されない仕様のはずです。 > > リアルサーバの監視は ldirectord の checktype や service 設定に > 従いますので、例えば、checktype = negotiate, service = http の > 場合は、192.168.1.1, 192.168.1.2 の Apache 等を停止した際に > fallback 設定の 127.0.0.1:80 が自動的に追加されるはずです。 > checktype = ping の場合は、ケーブルを抜く、インタフェースを > down させるなどして ping がリアルサーバに届かない状態にして > みてください。 > checktype = on の場合は、常にリアルサーバが正常と判断されるため > fallback は追加されないと思います。 > > 以上、宜しくお願い致します。 > > > 2010/02/03 11:20, 稲垣 wrote: > >> 田沼様 >> >> お世話になります。 >> 稲垣です。 >> >> /etc/ha.d/ldirectord.cfに127.0.0.1:80を追加しましたが、 >> fallbackの設定が追加されなくなりました。 >> >> # ipvsadm -l >> IP Virtual Server version 1.2.1 (size=4096) >> Prot LocalAddress:Port Scheduler Flags >> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >> TCP 172.31.208.181:https rr >> -> 192.168.1.1:https Masq 1 0 0 >> -> 192.168.1.2:https Masq 1 0 0 >> TCP 172.31.208.181:http rr >> -> 192.168.1.2:http Masq 1 0 1 >> -> 192.168.1.1:http Masq 1 0 1 >> >> なんででしょうか？ >> >> 以上、宜しくお願い致します。 >> >> >> Kohei TANUMA さんは書きました: >> >>> 稲垣さま >>> >>> 田沼です。 >>> >>> LVS の理解が不足してるので間違っているかもしれませんが >>> 私なりにわかったところまで回答します。 >>> 先に結論として、127.0.0.1 を real や fallback に指定する場合は >>> バーチャルサービスと同一のポートで動かす必要があるのではないかと >>> 思います。（つまり fallback 81 番ポートは無理） >>> そのため、先程の私の masq を指定するというのは間違いのようです。 >>> >>> 127.0.0.1 への振り分けはダイレクトにパケットが配送される >>> ようで、バーチャルサービス宛(172.31.207.10:80宛) のパケットが >>> 127.0.0.1:81 の Apache に飛ぶのでコネクションがリセットされて >>> いるように見えます。 >>> 試しに、iptables で 80 宛を 81 宛に無理やり書き換えると、 >>> Apache で正常に処理することができました。 >>> >>> iptables -t nat -A PREROUTING -i eth0 -p tcp -d 172.31.207.10 --dport 80 >>> -j DNAT --to 172.31.207.10:81 >>> >>> ただし、これだと通常の real が使い物にならなくなるので却下…。 >>> （上記 iptables の -A を -D で削除） >>> >>> 以下の設定で動作確認できました。 >>> >>> ■ ldirectord >>> fallback = 127.0.0.1:80 >>> virtual = 172.31.207.10:80 >>> real = 172.31.206.1:80 masq 1 >>> real = 172.31.206.2:80 masq 1 >>> checktype = negotiate >>> service = http >>> request = "index.html" >>> receive = "test" >>> scheduler = rr >>> protocol = tcp >>> >>> ■ 172.31.207.10 の Apache >>> ... >>> Listen 80 >>> ... >>> >>> ■ ipvsadm -ln (real が正常な場合) >>> IP Virtual Server version 1.2.1 (size=4096) >>> Prot LocalAddress:Port Scheduler Flags >>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>> TCP 172.31.207.10:80 rr >>> -> 172.31.206.1:80 Masq 1 0 0 >>> -> 172.31.206.2:80 Masq 1 0 0 >>> >>> ■ ipvsadm -ln (real 全てが異常な場合 - index.html の test 文字を消す) >>> IP Virtual Server version 1.2.1 (size=4096) >>> Prot LocalAddress:Port Scheduler Flags >>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>> TCP 172.31.207.10:80 rr >>> -> 127.0.0.1:80 Local 1 0 0 >>> -> 172.31.206.1:80 Masq 0 0 0 >>> -> 172.31.206.2:80 Masq 0 0 0 >>> >>> とりあえず上記で fallback の Apache のページが表示されました。 >>> >>> 稲垣さんの設定の場合だと fallback のポートを 80 に設定し >>> （masq も消して）172.31.207.10 のサーバで HTTPd を 80 ポートで >>> 動かすように修正する必要があると思います。 >>> >>> ただし、間違いがあるかもしれませんので、他の識者の方々つっこみ >>> お願いします。 >>> >>> 以上です。 >>> >>> >>> 2010/02/02 12:19, 稲垣 wrote: >>> >>> >>>> 田沼様 >>>> >>>> お世話になっております。 >>>> 稲垣です。 >>>> >>>> コマンド結果は以下の通りです。 >>>> # ipvsadm -ln >>>> IP Virtual Server version 1.2.1 (size=4096) >>>> Prot LocalAddress:Port Scheduler Flags >>>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>>> TCP 172.31.207.10:80 rr >>>> -> 127.0.0.1:81 Local 1 0 1 >>>> >>>> 以上宜しくお願いします。 >>>> >>>> Kohei TANUMA さんは書きました: >>>> >>>> >>>>> 稲垣さま >>>>> >>>>> 田沼です。 >>>>> >>>>> 表示されないというのはページが表示されないという意味でしょうか？ >>>>> 先のメールの ipvsadm の結果では以下のように fallback サーバの >>>>> ポートを 81 に設定しているにもかかわらずポートが 80 で >>>>> 追加されているのが問題と考えました。 >>>>> >>>>> >>>>> >>>>> >>>>>>>> TCP 172.31.207.10:http rr >>>>>>>> -> LB01:http Local 1 0 0 >>>>>>>> >>>>>>>> >>>>>>>> >>>>> masq を追加した後の ipvsadm -ln の結果を >>>>> 確認させていただけますでしょうか。 >>>>> >>>>> >>>>> 2010/02/02 11:55, 稲垣 wrote: >>>>> >>>>> >>>>> >>>>>> 田沼様 >>>>>> >>>>>> お世話になっております。 >>>>>> 稲垣です。 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> fallback=127.0.0.1:81 masq >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> ご指摘の通りに設定しましたが、表示されません。 >>>>>> >>>>>> 以上、宜しくお願い致します。 >>>>>> >>>>>> >>>>>> Kohei TANUMA さんは書きました: >>>>>> >>>>>> >>>>>> >>>>>>> 稲垣さま >>>>>>> >>>>>>> 田沼と申します。 >>>>>>> >>>>>>> LVS についてはあまりわからないのですが、 >>>>>>> ldirectord の動作を確認したところ fallback 行で >>>>>>> forward 設定を省略すると gate として設定されるようです。 >>>>>>> ldirectord.cf の fallback を以下のように変更してみてください。 >>>>>>> >>>>>>> fallback=127.0.0.1:81 masq >>>>>>> >>>>>>> 以上です。 >>>>>>> >>>>>>> >>>>>>> 2010/02/02 10:50, 稲垣 wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> お世話になっております。 >>>>>>>> 稲垣です。 >>>>>>>> >>>>>>>> ipvsadmコマンドで全リアルサーバ(HTTP)をメンテナンス状態にし、 >>>>>>>> fallbackサーバを表示させたいのですが、 >>>>>>>> /etc/ha.d/ldirectord.cfに記載したfallbackサーバが表示されません。 >>>>>>>> >>>>>>>> ipvsadm -lの状態はfallbackサーバを表示しております。 >>>>>>>> >>>>>>>> /etc/ha.d/ldirectord.cfの設定はHTTPのリアル設定をコメントしております。 >>>>>>>> /etc/httpd/conf/httpd.confのListenは81になっており、直にたたくと問題なく >>>>>>>> 表示されます。 >>>>>>>> >>>>>>>> >>>>>>>> # ipvsadm -l >>>>>>>> IP Virtual Server version 1.2.1 (size=4096) >>>>>>>> Prot LocalAddress:Port Scheduler Flags >>>>>>>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>>>>>>> TCP 172.31.207.10:http rr >>>>>>>> -> LB01:http Local 1 0 0 >>>>>>>> >>>>>>>> # cat /etc/ha.d/ldirectord.cf >>>>>>>> >>>>>>>> # Global Directives >>>>>>>> checktimeout=3 >>>>>>>> checkinterval=1 >>>>>>>> fallback=127.0.0.1:81 >>>>>>>> autoreload=no >>>>>>>> logfile="/var/log/ldirectord.log" >>>>>>>> #logfile="local0" >>>>>>>> #emailalert="admin ＠ x.y.z" >>>>>>>> #emailalertfreq=3600 >>>>>>>> #emailalertstatus=all >>>>>>>> quiescent=no >>>>>>>> >>>>>>>> # Sample for an http virtual service >>>>>>>> virtual=172.31.207.10:80 >>>>>>>> # real=172.31.206.1:80 masq 1 >>>>>>>> # real=172.31.206.2:80 masq 1 >>>>>>>> service=http >>>>>>>> request="index.html" >>>>>>>> # receive="Test Page" >>>>>>>> scheduler=rr >>>>>>>> # persistent=600 >>>>>>>> # netmask=255.255.255.255 >>>>>>>> # protocol=tcp >>>>>>>> checktype=negotiate >>>>>>>> >>>>>>>> 何か設定不備等ありますか？ >>>>>>>> 以上、ご教授の程宜しくお願いします。 >>>>>>>> > > From tadashi.1027 ＠ gmail.com Wed Feb 3 14:09:03 2010 From: tadashi.1027 ＠ gmail.com (=?ISO-2022-JP?B?GyRCMHAzQBsoQg==?=) Date: Wed, 03 Feb 2010 14:09:03 +0900 Subject: [Ultramonkey-l7-users 306] Re: =?iso-2022-jp?b?VWx0cmFNb25rZXkbJEIkRyROGyhCSVAbJEJGKTJhGyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <20100203.135111.580906918135309375.tateishi.katsuyuki@oss.ntt.co.jp> References: <4B5E96A1.3050101@gmail.com> <20100126.184909.756168950323994513.tateishi.katsuyuki@oss.ntt.co.jp> <4B68E34D.2090406@gmail.com> <20100203.135111.580906918135309375.tateishi.katsuyuki@oss.ntt.co.jp> Message-ID: <4B6904EF.3040808@gmail.com> 立石様 お世話になります。 稲垣です。 まさにご提示頂いた構成です。 リアルサーバのGWはUMのIPエイリアスになっております。 ただ現在検証している最中ですが、動作が不安定です。 ブラウザからインターネット経由でアクセス確認しましたが、 １号機、2号機に振り分けられた後、504エラーを返してしまいます。 以上、宜しくお願いします。 TATEISHI Katsuyuki さんは書きました: > 立石です。こんにちは。 > > 稲垣 -san wrote: > > >> UltraMonkey-L4でNATモード、ワンアームで >> IPエイリアスを使って仮想的にツーアームに見せ掛け >> 成功した事例はありますか？ >> > > どのような環境を想定されているのか、ちょっとよくつかめまない > ので、具体的におねがいします。 > > 例えば以下のような、一つのEthernetセグメントに対して異な > るネットワークを二つ載せるような構成でしょうか？ > # 等幅フォントで表示しないとズレると思います。 > > +--------+ > | client | > +---+----+ > | > +---+----+ > | router | > +---+----+ IP address: 192.168.1.1/24 > | > +-------+ > | | > | +---+----+ IPaddr: 192.168.1.2/24, alias 192.168.254.2/24 > | | UM | > | +--------+ > | > +-------+ > | | > | +---+----+ IPaddr: 192.168.254.10/24 > | | Web0 | > | +--------+ > | > +-------+ > | > +---+----+ IPaddr: 192.168.254.11/24 > | Web1 | > +--------+ > > (router が 192.168.1.0/24 だと思っているネットワークに実は > 192.168.254.0/24 のパケットも流れているような構成) > > リアルサーバ(Web0, Web1)におけるデフォルトルータがUMの > 192.168.254.2 を向いていれば動作すると思いますが、試したこと > はないです。事例についても不明です。 > > 最終的にやりたいことは、どんなことでしょう？ > > -- > TATEISHI Katsuyuki > > From tadashi.1027 ＠ gmail.com Wed Feb 3 14:10:34 2010 From: tadashi.1027 ＠ gmail.com (=?ISO-2022-JP?B?GyRCMHAzQBsoQg==?=) Date: Wed, 03 Feb 2010 14:10:34 +0900 Subject: [Ultramonkey-l7-users 307] Re: =?iso-2022-jp?b?aXB2c2FkbRskQiUzJV4lcyVJJE4xP01RJEskRCQkGyhC?= =?iso-2022-jp?b?GyRCJEYbKEI=?= In-Reply-To: <4B68FF86.9020906@nttcom.co.jp> References: <4B67869C.4040809@gmail.com> <4B67957E.5020000@nttcom.co.jp> <4B679ADF.6040903@gmail.com> <4B68FF86.9020906@nttcom.co.jp> Message-ID: <4B69054A.6030300@gmail.com> 田沼様 お世話になります。 稲垣です。 了解致しました。 どうもありがとうございました。 Kohei TANUMA さんは書きました: > 稲垣さま > > 田沼です。 > > バーチャルサービスを無効化する場合は > ご想像のとおり紐づいているリアルサーバの > weight を全て 0 にすればいいと考えます。 > > 以上です。 > > > 2010/02/02 12:24, 稲垣 wrote: > >> 田沼様 >> >> ご回答どうもありがとうございます。 >> >> weightを0にするやり方がよさそうですね。 >> つまり、バーチャルサービス丸ごと無効化したい場合は、 >> それに紐づく全てのリアルサービスのweightを0にしてやればよいということで >> しょうか？ >> >> 以上、宜しくお願い致します。 >> >> >> Kohei TANUMA さんは書きました: >> >>> 稲垣さま >>> >>> 田沼です。 >>> >>> こちらについては要件にもよるかと思います。 >>> 削除と無効化ではサービス停止には変わりはないですが、 >>> 既存の接続をどのように扱うかが異なります。 >>> >>> バーチャルサービスやリアルサーバを削除した場合、 >>> その際に接続しているクライアントが全て切断されますが、 >>> リアルサーバを無効化した場合は、新規のクライアントのみが >>> 接続できなくなり、無効化した際に接続しているクライアントは >>> そのまま維持されます。 >>> （接続したままのクライアント数は ipvsadm の ActiveConn の >>> 数や ipvsadm -lc で確認できると思います） >>> メンテナンス時など、とりあえず新規コネクションは止めて >>> 既存コネクションがはけてからメンテナンスを行うなどの場合は >>> 無効にする方法が有効かと思います。 >>> >>> 無効化は以下のコマンドでリアルサーバの weight を 0 にする >>> ことで実現されます。 >>> >>> ■ real が gate 設定の場合 >>> ipvsadm -e -t VIRTUAL:PORT -r REAL:PORT -g -w 0 >>> >>> ■ real が masq 設定の場合 >>> ipvsadm -e -t VIRTUAL:PORT -r REAL:PORT -m -w 0 >>> >>> 詳細は man ipvsadm (-w, --weight のところ) をご確認ください。 >>> >>> 以上です。 >>> >>> >>> >>> 2010/02/02 10:57, 稲垣 wrote: >>> >>> >>>> お世話になっております。 >>>> 稲垣です。 >>>> >>>> /etc/ha.d/ldirecotord.cfファイルの設定をいじらずに >>>> ipvsadmコマンドでバーチャルサービス、リアルサービスの >>>> 有効無効を制御したいと考えております。 >>>> >>>> そういった場合は、バーチャルサービス、リアルサービスを >>>> 削除する方法がいいのでしょうか？ >>>> >>>> それとも、バーチャルサービス、リアルサービスを残したまま >>>> 文字通り「有効・無効」に切り替えることはできるでしょうか？ >>>> >>>> 以上、宜しくお願い致します。 >>>> > > From tanuma.kouhei ＠ nttcom.co.jp Wed Feb 3 14:39:07 2010 From: tanuma.kouhei ＠ nttcom.co.jp (Kohei TANUMA) Date: Wed, 03 Feb 2010 14:39:07 +0900 Subject: [Ultramonkey-l7-users 308] Re: =?iso-2022-jp?b?ZmFsbGJhY2sbJEJAX0RqJEskRCQkJEYbKEI=?= In-Reply-To: <4B690259.7090601@gmail.com> References: <4B6784C9.1050200@gmail.com> <4B679088.2000904@nttcom.co.jp> <4B679420.2090407@gmail.com> <4B679689.5000301@nttcom.co.jp> <4B6799AC.3080608@gmail.com> <4B67BCE9.6060301@nttcom.co.jp> <4B68DD83.2000200@gmail.com> <4B68FEF7.3040901@nttcom.co.jp> <4B690259.7090601@gmail.com> Message-ID: <4B690BFB.7060005@nttcom.co.jp> 稲垣さま 田沼です。 こちらでは正常な動作を確認できました。 以下についてご確認ください。 ・LB サーバ（172.31.208.181）に mod_ssl 等の HTTPS を処理する モジュールがインストールされているか ・HTTPS で使うサーバ証明書が LB サーバとリアルサーバで同じものを 使っているか（ブラウザによってエラーになります） 2010/02/03 13:58, 稲垣 wrote: > 田沼様 > > お世話になります。 > 稲垣です。 > > リアルサーバのhttpdを停止したらfallbackのあて先が表示されました。 > ただ、httpsの方がfallbackに同じ宛先を指定しているのですが表示されません。 > > 「プロキシサーバへの接続を拒否されました。」 > がブラウザに表示されます。 > > 以上、宜しくお願いします。 > > Kohei TANUMA さんは書きました: >> 稲垣さま >> >> 田沼です。 >> >> fallback は実際のリアルサーバが全て異常と判断された際の >> 代替サーバになりますので、リアルサーバが正常な場合は >> 追加されない仕様のはずです。 >> >> リアルサーバの監視は ldirectord の checktype や service 設定に >> 従いますので、例えば、checktype = negotiate, service = http の >> 場合は、192.168.1.1, 192.168.1.2 の Apache 等を停止した際に >> fallback 設定の 127.0.0.1:80 が自動的に追加されるはずです。 >> checktype = ping の場合は、ケーブルを抜く、インタフェースを >> down させるなどして ping がリアルサーバに届かない状態にして >> みてください。 >> checktype = on の場合は、常にリアルサーバが正常と判断されるため >> fallback は追加されないと思います。 >> >> 以上、宜しくお願い致します。 >> >> >> 2010/02/03 11:20, 稲垣 wrote: >> >>> 田沼様 >>> >>> お世話になります。 >>> 稲垣です。 >>> >>> /etc/ha.d/ldirectord.cfに127.0.0.1:80を追加しましたが、 >>> fallbackの設定が追加されなくなりました。 >>> >>> # ipvsadm -l >>> IP Virtual Server version 1.2.1 (size=4096) >>> Prot LocalAddress:Port Scheduler Flags >>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>> TCP 172.31.208.181:https rr >>> -> 192.168.1.1:https Masq 1 0 0 >>> -> 192.168.1.2:https Masq 1 0 0 >>> TCP 172.31.208.181:http rr >>> -> 192.168.1.2:http Masq 1 0 1 >>> -> 192.168.1.1:http Masq 1 0 1 >>> >>> なんででしょうか？ >>> >>> 以上、宜しくお願い致します。 >>> >>> >>> Kohei TANUMA さんは書きました: >>> >>>> 稲垣さま >>>> >>>> 田沼です。 >>>> >>>> LVS の理解が不足してるので間違っているかもしれませんが >>>> 私なりにわかったところまで回答します。 >>>> 先に結論として、127.0.0.1 を real や fallback に指定する場合は >>>> バーチャルサービスと同一のポートで動かす必要があるのではないかと >>>> 思います。（つまり fallback 81 番ポートは無理） >>>> そのため、先程の私の masq を指定するというのは間違いのようです。 >>>> >>>> 127.0.0.1 への振り分けはダイレクトにパケットが配送される >>>> ようで、バーチャルサービス宛(172.31.207.10:80宛) のパケットが >>>> 127.0.0.1:81 の Apache に飛ぶのでコネクションがリセットされて >>>> いるように見えます。 >>>> 試しに、iptables で 80 宛を 81 宛に無理やり書き換えると、 >>>> Apache で正常に処理することができました。 >>>> >>>> iptables -t nat -A PREROUTING -i eth0 -p tcp -d 172.31.207.10 --dport 80 >>>> -j DNAT --to 172.31.207.10:81 >>>> >>>> ただし、これだと通常の real が使い物にならなくなるので却下…。 >>>> （上記 iptables の -A を -D で削除） >>>> >>>> 以下の設定で動作確認できました。 >>>> >>>> ■ ldirectord >>>> fallback = 127.0.0.1:80 >>>> virtual = 172.31.207.10:80 >>>> real = 172.31.206.1:80 masq 1 >>>> real = 172.31.206.2:80 masq 1 >>>> checktype = negotiate >>>> service = http >>>> request = "index.html" >>>> receive = "test" >>>> scheduler = rr >>>> protocol = tcp >>>> >>>> ■ 172.31.207.10 の Apache >>>> ... >>>> Listen 80 >>>> ... >>>> >>>> ■ ipvsadm -ln (real が正常な場合) >>>> IP Virtual Server version 1.2.1 (size=4096) >>>> Prot LocalAddress:Port Scheduler Flags >>>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>>> TCP 172.31.207.10:80 rr >>>> -> 172.31.206.1:80 Masq 1 0 0 >>>> -> 172.31.206.2:80 Masq 1 0 0 >>>> >>>> ■ ipvsadm -ln (real 全てが異常な場合 - index.html の test 文字を消す) >>>> IP Virtual Server version 1.2.1 (size=4096) >>>> Prot LocalAddress:Port Scheduler Flags >>>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>>> TCP 172.31.207.10:80 rr >>>> -> 127.0.0.1:80 Local 1 0 0 >>>> -> 172.31.206.1:80 Masq 0 0 0 >>>> -> 172.31.206.2:80 Masq 0 0 0 >>>> >>>> とりあえず上記で fallback の Apache のページが表示されました。 >>>> >>>> 稲垣さんの設定の場合だと fallback のポートを 80 に設定し >>>> （masq も消して）172.31.207.10 のサーバで HTTPd を 80 ポートで >>>> 動かすように修正する必要があると思います。 >>>> >>>> ただし、間違いがあるかもしれませんので、他の識者の方々つっこみ >>>> お願いします。 >>>> >>>> 以上です。 >>>> >>>> >>>> 2010/02/02 12:19, 稲垣 wrote: >>>> >>>> >>>>> 田沼様 >>>>> >>>>> お世話になっております。 >>>>> 稲垣です。 >>>>> >>>>> コマンド結果は以下の通りです。 >>>>> # ipvsadm -ln >>>>> IP Virtual Server version 1.2.1 (size=4096) >>>>> Prot LocalAddress:Port Scheduler Flags >>>>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>>>> TCP 172.31.207.10:80 rr >>>>> -> 127.0.0.1:81 Local 1 0 1 >>>>> >>>>> 以上宜しくお願いします。 >>>>> >>>>> Kohei TANUMA さんは書きました: >>>>> >>>>> >>>>>> 稲垣さま >>>>>> >>>>>> 田沼です。 >>>>>> >>>>>> 表示されないというのはページが表示されないという意味でしょうか？ >>>>>> 先のメールの ipvsadm の結果では以下のように fallback サーバの >>>>>> ポートを 81 に設定しているにもかかわらずポートが 80 で >>>>>> 追加されているのが問題と考えました。 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>>> TCP 172.31.207.10:http rr >>>>>>>>> -> LB01:http Local 1 0 0 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> masq を追加した後の ipvsadm -ln の結果を >>>>>> 確認させていただけますでしょうか。 >>>>>> >>>>>> >>>>>> 2010/02/02 11:55, 稲垣 wrote: >>>>>> >>>>>> >>>>>> >>>>>>> 田沼様 >>>>>>> >>>>>>> お世話になっております。 >>>>>>> 稲垣です。 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> fallback=127.0.0.1:81 masq >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> ご指摘の通りに設定しましたが、表示されません。 >>>>>>> >>>>>>> 以上、宜しくお願い致します。 >>>>>>> >>>>>>> >>>>>>> Kohei TANUMA さんは書きました: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 稲垣さま >>>>>>>> >>>>>>>> 田沼と申します。 >>>>>>>> >>>>>>>> LVS についてはあまりわからないのですが、 >>>>>>>> ldirectord の動作を確認したところ fallback 行で >>>>>>>> forward 設定を省略すると gate として設定されるようです。 >>>>>>>> ldirectord.cf の fallback を以下のように変更してみてください。 >>>>>>>> >>>>>>>> fallback=127.0.0.1:81 masq >>>>>>>> >>>>>>>> 以上です。 >>>>>>>> >>>>>>>> >>>>>>>> 2010/02/02 10:50, 稲垣 wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> お世話になっております。 >>>>>>>>> 稲垣です。 >>>>>>>>> >>>>>>>>> ipvsadmコマンドで全リアルサーバ(HTTP)をメンテナンス状態にし、 >>>>>>>>> fallbackサーバを表示させたいのですが、 >>>>>>>>> /etc/ha.d/ldirectord.cfに記載したfallbackサーバが表示されません。 >>>>>>>>> >>>>>>>>> ipvsadm -lの状態はfallbackサーバを表示しております。 >>>>>>>>> >>>>>>>>> /etc/ha.d/ldirectord.cfの設定はHTTPのリアル設定をコメントしております。 >>>>>>>>> /etc/httpd/conf/httpd.confのListenは81になっており、直にたたくと問題なく >>>>>>>>> 表示されます。 >>>>>>>>> >>>>>>>>> >>>>>>>>> # ipvsadm -l >>>>>>>>> IP Virtual Server version 1.2.1 (size=4096) >>>>>>>>> Prot LocalAddress:Port Scheduler Flags >>>>>>>>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>>>>>>>> TCP 172.31.207.10:http rr >>>>>>>>> -> LB01:http Local 1 0 0 >>>>>>>>> >>>>>>>>> # cat /etc/ha.d/ldirectord.cf >>>>>>>>> >>>>>>>>> # Global Directives >>>>>>>>> checktimeout=3 >>>>>>>>> checkinterval=1 >>>>>>>>> fallback=127.0.0.1:81 >>>>>>>>> autoreload=no >>>>>>>>> logfile="/var/log/ldirectord.log" >>>>>>>>> #logfile="local0" >>>>>>>>> #emailalert="admin ＠ x.y.z" >>>>>>>>> #emailalertfreq=3600 >>>>>>>>> #emailalertstatus=all >>>>>>>>> quiescent=no >>>>>>>>> >>>>>>>>> # Sample for an http virtual service >>>>>>>>> virtual=172.31.207.10:80 >>>>>>>>> # real=172.31.206.1:80 masq 1 >>>>>>>>> # real=172.31.206.2:80 masq 1 >>>>>>>>> service=http >>>>>>>>> request="index.html" >>>>>>>>> # receive="Test Page" >>>>>>>>> scheduler=rr >>>>>>>>> # persistent=600 >>>>>>>>> # netmask=255.255.255.255 >>>>>>>>> # protocol=tcp >>>>>>>>> checktype=negotiate >>>>>>>>> >>>>>>>>> 何か設定不備等ありますか？ >>>>>>>>> 以上、ご教授の程宜しくお願いします。 >>>>>>>>> From tateishi.katsuyuki ＠ oss.ntt.co.jp Wed Feb 3 14:43:33 2010 From: tateishi.katsuyuki ＠ oss.ntt.co.jp (TATEISHI Katsuyuki) Date: Wed, 03 Feb 2010 14:43:33 +0900 (JST) Subject: [Ultramonkey-l7-users 309] Re: =?iso-2022-jp?b?VWx0cmFNb25rZXkbJEIkRyROGyhCSVAbJEJGKTJhGyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4B6904EF.3040808@gmail.com> References: <4B68E34D.2090406@gmail.com> <20100203.135111.580906918135309375.tateishi.katsuyuki@oss.ntt.co.jp> <4B6904EF.3040808@gmail.com> Message-ID: <20100203.144333.455691525214985478.tateishi.katsuyuki@oss.ntt.co.jp> 立石です。 稲垣 -san wrote: > まさにご提示頂いた構成です。 > リアルサーバのGWはUMのIPエイリアスになっております。 > ただ現在検証している最中ですが、動作が不安定です。 以前提示したような、フラットなセグメントでリアルサーバのデフォ ルトルータを変えるだけのほうがいいかもしれませんね。(または DSR構成にする) # 下の例でいえば 192.168.1.0/24 に統一し、192.168.254.0/24 の # アドレスは撤廃。Web0, Web1 のデフォルトルータは # 192.168.1.2に設定する 同じEthernetセグメントに異なるネットワークがかぶさっていると (まさに体験されているように)トラブったときの切り分けが難しい ですし・・・ 現在の構成にこだわるなら、という前提で以下続きです。 > ブラウザからインターネット経由でアクセス確認しましたが、 > １号機、2号機に振り分けられた後、504エラーを返してしまいます。 504 ということは HTTP まで理解する何らかの中継サービス(Proxy とか)がエラーを返しているってことですかね。 Proxy経由はもちろんですが、そもそもインターネット経由だとどこ が悪いのかポイントを絞りにくいので、まずは、UM-router間のネッ トワークに属しているクライアントからアクセスできるか確認して みてはいかがでしょうか？ 下の例でいえば、192.168.1.3/24 (なクライアントをつないで)から アクセスしてみるとか。 # もちろんそれ以前の問題として 192.168.254.0/24 なクライアン # トからはアクセスできてますよね？ってのはありますが。 >> +--------+ >> | client | >> +---+----+ >> | >> +---+----+ >> | router | >> +---+----+ IP address: 192.168.1.1/24 >> | >> +-------+ >> | | >> | +---+----+ IPaddr: 192.168.1.2/24, alias 192.168.254.2/24 >> | | UM | >> | +--------+ >> | >> +-------+ >> | | >> | +---+----+ IPaddr: 192.168.254.10/24 >> | | Web0 | >> | +--------+ >> | >> +-------+ >> | >> +---+----+ IPaddr: 192.168.254.11/24 >> | Web1 | >> +--------+ -- TATEISHI Katsuyuki From tadashi.1027 ＠ gmail.com Wed Feb 3 14:46:35 2010 From: tadashi.1027 ＠ gmail.com (=?ISO-2022-JP?B?GyRCMHAzQBsoQg==?=) Date: Wed, 03 Feb 2010 14:46:35 +0900 Subject: [Ultramonkey-l7-users 310] Re: =?iso-2022-jp?b?ZmFsbGJhY2sbJEJAX0RqJEskRCQkJEYbKEI=?= In-Reply-To: <4B690BFB.7060005@nttcom.co.jp> References: <4B6784C9.1050200@gmail.com> <4B679088.2000904@nttcom.co.jp> <4B679420.2090407@gmail.com> <4B679689.5000301@nttcom.co.jp> <4B6799AC.3080608@gmail.com> <4B67BCE9.6060301@nttcom.co.jp> <4B68DD83.2000200@gmail.com> <4B68FEF7.3040901@nttcom.co.jp> <4B690259.7090601@gmail.com> <4B690BFB.7060005@nttcom.co.jp> Message-ID: <4B690DBB.20106@gmail.com> 田沼様 お世話になっております。 稲垣です。 > ・LB サーバ（172.31.208.181）に mod_ssl 等の HTTPS を処理する > モジュールがインストールされているか > ・HTTPS で使うサーバ証明書が LB サーバとリアルサーバで同じものを > 使っているか（ブラウザによってエラーになります） > インストールされてませんでした。。。 すみません。 mod_sslをインストールし、リアルと同じ証明書で動作確認できました。 どうもありがとうございました。 Kohei TANUMA さんは書きました: > 稲垣さま > > 田沼です。 > > こちらでは正常な動作を確認できました。 > 以下についてご確認ください。 > > ・LB サーバ（172.31.208.181）に mod_ssl 等の HTTPS を処理する > モジュールがインストールされているか > ・HTTPS で使うサーバ証明書が LB サーバとリアルサーバで同じものを > 使っているか（ブラウザによってエラーになります） > > > 2010/02/03 13:58, 稲垣 wrote: > >> 田沼様 >> >> お世話になります。 >> 稲垣です。 >> >> リアルサーバのhttpdを停止したらfallbackのあて先が表示されました。 >> ただ、httpsの方がfallbackに同じ宛先を指定しているのですが表示されません。 >> >> 「プロキシサーバへの接続を拒否されました。」 >> がブラウザに表示されます。 >> >> 以上、宜しくお願いします。 >> >> Kohei TANUMA さんは書きました: >> >>> 稲垣さま >>> >>> 田沼です。 >>> >>> fallback は実際のリアルサーバが全て異常と判断された際の >>> 代替サーバになりますので、リアルサーバが正常な場合は >>> 追加されない仕様のはずです。 >>> >>> リアルサーバの監視は ldirectord の checktype や service 設定に >>> 従いますので、例えば、checktype = negotiate, service = http の >>> 場合は、192.168.1.1, 192.168.1.2 の Apache 等を停止した際に >>> fallback 設定の 127.0.0.1:80 が自動的に追加されるはずです。 >>> checktype = ping の場合は、ケーブルを抜く、インタフェースを >>> down させるなどして ping がリアルサーバに届かない状態にして >>> みてください。 >>> checktype = on の場合は、常にリアルサーバが正常と判断されるため >>> fallback は追加されないと思います。 >>> >>> 以上、宜しくお願い致します。 >>> >>> >>> 2010/02/03 11:20, 稲垣 wrote: >>> >>> >>>> 田沼様 >>>> >>>> お世話になります。 >>>> 稲垣です。 >>>> >>>> /etc/ha.d/ldirectord.cfに127.0.0.1:80を追加しましたが、 >>>> fallbackの設定が追加されなくなりました。 >>>> >>>> # ipvsadm -l >>>> IP Virtual Server version 1.2.1 (size=4096) >>>> Prot LocalAddress:Port Scheduler Flags >>>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>>> TCP 172.31.208.181:https rr >>>> -> 192.168.1.1:https Masq 1 0 0 >>>> -> 192.168.1.2:https Masq 1 0 0 >>>> TCP 172.31.208.181:http rr >>>> -> 192.168.1.2:http Masq 1 0 1 >>>> -> 192.168.1.1:http Masq 1 0 1 >>>> >>>> なんででしょうか？ >>>> >>>> 以上、宜しくお願い致します。 >>>> >>>> >>>> Kohei TANUMA さんは書きました: >>>> >>>> >>>>> 稲垣さま >>>>> >>>>> 田沼です。 >>>>> >>>>> LVS の理解が不足してるので間違っているかもしれませんが >>>>> 私なりにわかったところまで回答します。 >>>>> 先に結論として、127.0.0.1 を real や fallback に指定する場合は >>>>> バーチャルサービスと同一のポートで動かす必要があるのではないかと >>>>> 思います。（つまり fallback 81 番ポートは無理） >>>>> そのため、先程の私の masq を指定するというのは間違いのようです。 >>>>> >>>>> 127.0.0.1 への振り分けはダイレクトにパケットが配送される >>>>> ようで、バーチャルサービス宛(172.31.207.10:80宛) のパケットが >>>>> 127.0.0.1:81 の Apache に飛ぶのでコネクションがリセットされて >>>>> いるように見えます。 >>>>> 試しに、iptables で 80 宛を 81 宛に無理やり書き換えると、 >>>>> Apache で正常に処理することができました。 >>>>> >>>>> iptables -t nat -A PREROUTING -i eth0 -p tcp -d 172.31.207.10 --dport 80 >>>>> -j DNAT --to 172.31.207.10:81 >>>>> >>>>> ただし、これだと通常の real が使い物にならなくなるので却下…。 >>>>> （上記 iptables の -A を -D で削除） >>>>> >>>>> 以下の設定で動作確認できました。 >>>>> >>>>> ■ ldirectord >>>>> fallback = 127.0.0.1:80 >>>>> virtual = 172.31.207.10:80 >>>>> real = 172.31.206.1:80 masq 1 >>>>> real = 172.31.206.2:80 masq 1 >>>>> checktype = negotiate >>>>> service = http >>>>> request = "index.html" >>>>> receive = "test" >>>>> scheduler = rr >>>>> protocol = tcp >>>>> >>>>> ■ 172.31.207.10 の Apache >>>>> ... >>>>> Listen 80 >>>>> ... >>>>> >>>>> ■ ipvsadm -ln (real が正常な場合) >>>>> IP Virtual Server version 1.2.1 (size=4096) >>>>> Prot LocalAddress:Port Scheduler Flags >>>>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>>>> TCP 172.31.207.10:80 rr >>>>> -> 172.31.206.1:80 Masq 1 0 0 >>>>> -> 172.31.206.2:80 Masq 1 0 0 >>>>> >>>>> ■ ipvsadm -ln (real 全てが異常な場合 - index.html の test 文字を消す) >>>>> IP Virtual Server version 1.2.1 (size=4096) >>>>> Prot LocalAddress:Port Scheduler Flags >>>>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>>>> TCP 172.31.207.10:80 rr >>>>> -> 127.0.0.1:80 Local 1 0 0 >>>>> -> 172.31.206.1:80 Masq 0 0 0 >>>>> -> 172.31.206.2:80 Masq 0 0 0 >>>>> >>>>> とりあえず上記で fallback の Apache のページが表示されました。 >>>>> >>>>> 稲垣さんの設定の場合だと fallback のポートを 80 に設定し >>>>> （masq も消して）172.31.207.10 のサーバで HTTPd を 80 ポートで >>>>> 動かすように修正する必要があると思います。 >>>>> >>>>> ただし、間違いがあるかもしれませんので、他の識者の方々つっこみ >>>>> お願いします。 >>>>> >>>>> 以上です。 >>>>> >>>>> >>>>> 2010/02/02 12:19, 稲垣 wrote: >>>>> >>>>> >>>>> >>>>>> 田沼様 >>>>>> >>>>>> お世話になっております。 >>>>>> 稲垣です。 >>>>>> >>>>>> コマンド結果は以下の通りです。 >>>>>> # ipvsadm -ln >>>>>> IP Virtual Server version 1.2.1 (size=4096) >>>>>> Prot LocalAddress:Port Scheduler Flags >>>>>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>>>>> TCP 172.31.207.10:80 rr >>>>>> -> 127.0.0.1:81 Local 1 0 1 >>>>>> >>>>>> 以上宜しくお願いします。 >>>>>> >>>>>> Kohei TANUMA さんは書きました: >>>>>> >>>>>> >>>>>> >>>>>>> 稲垣さま >>>>>>> >>>>>>> 田沼です。 >>>>>>> >>>>>>> 表示されないというのはページが表示されないという意味でしょうか？ >>>>>>> 先のメールの ipvsadm の結果では以下のように fallback サーバの >>>>>>> ポートを 81 に設定しているにもかかわらずポートが 80 で >>>>>>> 追加されているのが問題と考えました。 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>> TCP 172.31.207.10:http rr >>>>>>>>>> -> LB01:http Local 1 0 0 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>> masq を追加した後の ipvsadm -ln の結果を >>>>>>> 確認させていただけますでしょうか。 >>>>>>> >>>>>>> >>>>>>> 2010/02/02 11:55, 稲垣 wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> 田沼様 >>>>>>>> >>>>>>>> お世話になっております。 >>>>>>>> 稲垣です。 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> fallback=127.0.0.1:81 masq >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> ご指摘の通りに設定しましたが、表示されません。 >>>>>>>> >>>>>>>> 以上、宜しくお願い致します。 >>>>>>>> >>>>>>>> >>>>>>>> Kohei TANUMA さんは書きました: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> 稲垣さま >>>>>>>>> >>>>>>>>> 田沼と申します。 >>>>>>>>> >>>>>>>>> LVS についてはあまりわからないのですが、 >>>>>>>>> ldirectord の動作を確認したところ fallback 行で >>>>>>>>> forward 設定を省略すると gate として設定されるようです。 >>>>>>>>> ldirectord.cf の fallback を以下のように変更してみてください。 >>>>>>>>> >>>>>>>>> fallback=127.0.0.1:81 masq >>>>>>>>> >>>>>>>>> 以上です。 >>>>>>>>> >>>>>>>>> >>>>>>>>> 2010/02/02 10:50, 稲垣 wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> お世話になっております。 >>>>>>>>>> 稲垣です。 >>>>>>>>>> >>>>>>>>>> ipvsadmコマンドで全リアルサーバ(HTTP)をメンテナンス状態にし、 >>>>>>>>>> fallbackサーバを表示させたいのですが、 >>>>>>>>>> /etc/ha.d/ldirectord.cfに記載したfallbackサーバが表示されません。 >>>>>>>>>> >>>>>>>>>> ipvsadm -lの状態はfallbackサーバを表示しております。 >>>>>>>>>> >>>>>>>>>> /etc/ha.d/ldirectord.cfの設定はHTTPのリアル設定をコメントしております。 >>>>>>>>>> /etc/httpd/conf/httpd.confのListenは81になっており、直にたたくと問題なく >>>>>>>>>> 表示されます。 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> # ipvsadm -l >>>>>>>>>> IP Virtual Server version 1.2.1 (size=4096) >>>>>>>>>> Prot LocalAddress:Port Scheduler Flags >>>>>>>>>> -> RemoteAddress:Port Forward Weight ActiveConn InActConn >>>>>>>>>> TCP 172.31.207.10:http rr >>>>>>>>>> -> LB01:http Local 1 0 0 >>>>>>>>>> >>>>>>>>>> # cat /etc/ha.d/ldirectord.cf >>>>>>>>>> >>>>>>>>>> # Global Directives >>>>>>>>>> checktimeout=3 >>>>>>>>>> checkinterval=1 >>>>>>>>>> fallback=127.0.0.1:81 >>>>>>>>>> autoreload=no >>>>>>>>>> logfile="/var/log/ldirectord.log" >>>>>>>>>> #logfile="local0" >>>>>>>>>> #emailalert="admin ＠ x.y.z" >>>>>>>>>> #emailalertfreq=3600 >>>>>>>>>> #emailalertstatus=all >>>>>>>>>> quiescent=no >>>>>>>>>> >>>>>>>>>> # Sample for an http virtual service >>>>>>>>>> virtual=172.31.207.10:80 >>>>>>>>>> # real=172.31.206.1:80 masq 1 >>>>>>>>>> # real=172.31.206.2:80 masq 1 >>>>>>>>>> service=http >>>>>>>>>> request="index.html" >>>>>>>>>> # receive="Test Page" >>>>>>>>>> scheduler=rr >>>>>>>>>> # persistent=600 >>>>>>>>>> # netmask=255.255.255.255 >>>>>>>>>> # protocol=tcp >>>>>>>>>> checktype=negotiate >>>>>>>>>> >>>>>>>>>> 何か設定不備等ありますか？ >>>>>>>>>> 以上、ご教授の程宜しくお願いします。 >>>>>>>>>> >>>>>>>>>> > > > From tadashi.1027 ＠ gmail.com Wed Feb 3 15:29:46 2010 From: tadashi.1027 ＠ gmail.com (=?ISO-2022-JP?B?GyRCMHAzQBsoQg==?=) Date: Wed, 03 Feb 2010 15:29:46 +0900 Subject: [Ultramonkey-l7-users 311] Re: =?iso-2022-jp?b?VWx0cmFNb25rZXkbJEIkRyROGyhCSVAbJEJGKTJhGyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <20100203.144333.455691525214985478.tateishi.katsuyuki@oss.ntt.co.jp> References: <4B68E34D.2090406@gmail.com> <20100203.135111.580906918135309375.tateishi.katsuyuki@oss.ntt.co.jp> <4B6904EF.3040808@gmail.com> <20100203.144333.455691525214985478.tateishi.katsuyuki@oss.ntt.co.jp> Message-ID: <4B6917DA.7030604@gmail.com> 立石様 お世話になります。 稲垣です。 > # 下の例でいえば 192.168.1.0/24 に統一し、192.168.254.0/24 の > # アドレスは撤廃。Web0, Web1 のデフォルトルータは > # 192.168.1.2に設定する > この構成で検証しましたが、こちらは504エラーはでないですが Webページが表示されるまでにかなりの時間がかかります。 また、UM、リアルでtcpdumpをとってみましが、 一回のコネクションごとに送信元IPからのパケットが1号機、2号機に 流れているようですが正しい動きでしょうか？ 以上、宜しくお願いします。 TATEISHI Katsuyuki さんは書きました: > 立石です。 > > 稲垣 -san wrote: > > >> まさにご提示頂いた構成です。 >> リアルサーバのGWはUMのIPエイリアスになっております。 >> ただ現在検証している最中ですが、動作が不安定です。 >> > > 以前提示したような、フラットなセグメントでリアルサーバのデフォ > ルトルータを変えるだけのほうがいいかもしれませんね。(または > DSR構成にする) > > # 下の例でいえば 192.168.1.0/24 に統一し、192.168.254.0/24 の > # アドレスは撤廃。Web0, Web1 のデフォルトルータは > # 192.168.1.2に設定する > > 同じEthernetセグメントに異なるネットワークがかぶさっていると > (まさに体験されているように)トラブったときの切り分けが難しい > ですし・・・ > > > 現在の構成にこだわるなら、という前提で以下続きです。 > > >> ブラウザからインターネット経由でアクセス確認しましたが、 >> １号機、2号機に振り分けられた後、504エラーを返してしまいます。 >> > > 504 ということは HTTP まで理解する何らかの中継サービス(Proxy > とか)がエラーを返しているってことですかね。 > > Proxy経由はもちろんですが、そもそもインターネット経由だとどこ > が悪いのかポイントを絞りにくいので、まずは、UM-router間のネッ > トワークに属しているクライアントからアクセスできるか確認して > みてはいかがでしょうか？ > > 下の例でいえば、192.168.1.3/24 (なクライアントをつないで)から > アクセスしてみるとか。 > > # もちろんそれ以前の問題として 192.168.254.0/24 なクライアン > # トからはアクセスできてますよね？ってのはありますが。 > > > >>> +--------+ >>> | client | >>> +---+----+ >>> | >>> +---+----+ >>> | router | >>> +---+----+ IP address: 192.168.1.1/24 >>> | >>> +-------+ >>> | | >>> | +---+----+ IPaddr: 192.168.1.2/24, alias 192.168.254.2/24 >>> | | UM | >>> | +--------+ >>> | >>> +-------+ >>> | | >>> | +---+----+ IPaddr: 192.168.254.10/24 >>> | | Web0 | >>> | +--------+ >>> | >>> +-------+ >>> | >>> +---+----+ IPaddr: 192.168.254.11/24 >>> | Web1 | >>> +--------+ >>> > > -- > TATEISHI Katsuyuki > From tadashi.1027 ＠ gmail.com Wed Feb 3 15:56:39 2010 From: tadashi.1027 ＠ gmail.com (=?ISO-2022-JP?B?GyRCMHAzQBsoQg==?=) Date: Wed, 03 Feb 2010 15:56:39 +0900 Subject: [Ultramonkey-l7-users 312] Re: =?iso-2022-jp?b?VWx0cmFNb25rZXkbJEIkRyROGyhCSVAbJEJGKTJhGyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4B6917DA.7030604@gmail.com> References: <4B68E34D.2090406@gmail.com> <20100203.135111.580906918135309375.tateishi.katsuyuki@oss.ntt.co.jp> <4B6904EF.3040808@gmail.com> <20100203.144333.455691525214985478.tateishi.katsuyuki@oss.ntt.co.jp> <4B6917DA.7030604@gmail.com> Message-ID: <4B691E27.6040608@gmail.com> 立石様 お世話になります。 稲垣です。 正しい動きではないですね。 構成をNAT、ツーアームにするとキレイにラウンドロビンされます。 tcpdumpで見ると1コネクションは必ずどちらかのリアルに振られる感じです。 以上になります。 稲垣 さんは書きました: > 立石様 > > お世話になります。 > 稲垣です。 > > >> # 下の例でいえば 192.168.1.0/24 に統一し、192.168.254.0/24 の >> # アドレスは撤廃。Web0, Web1 のデフォルトルータは >> # 192.168.1.2に設定する >> >> > この構成で検証しましたが、こちらは504エラーはでないですが > Webページが表示されるまでにかなりの時間がかかります。 > > また、UM、リアルでtcpdumpをとってみましが、 > 一回のコネクションごとに送信元IPからのパケットが1号機、2号機に > 流れているようですが正しい動きでしょうか？ > > 以上、宜しくお願いします。 > > > TATEISHI Katsuyuki さんは書きました: > >> 立石です。 >> >> 稲垣 -san wrote: >> >> >> >>> まさにご提示頂いた構成です。 >>> リアルサーバのGWはUMのIPエイリアスになっております。 >>> ただ現在検証している最中ですが、動作が不安定です。 >>> >>> >> 以前提示したような、フラットなセグメントでリアルサーバのデフォ >> ルトルータを変えるだけのほうがいいかもしれませんね。(または >> DSR構成にする) >> >> # 下の例でいえば 192.168.1.0/24 に統一し、192.168.254.0/24 の >> # アドレスは撤廃。Web0, Web1 のデフォルトルータは >> # 192.168.1.2に設定する >> >> 同じEthernetセグメントに異なるネットワークがかぶさっていると >> (まさに体験されているように)トラブったときの切り分けが難しい >> ですし・・・ >> >> >> 現在の構成にこだわるなら、という前提で以下続きです。 >> >> >> >>> ブラウザからインターネット経由でアクセス確認しましたが、 >>> １号機、2号機に振り分けられた後、504エラーを返してしまいます。 >>> >>> >> 504 ということは HTTP まで理解する何らかの中継サービス(Proxy >> とか)がエラーを返しているってことですかね。 >> >> Proxy経由はもちろんですが、そもそもインターネット経由だとどこ >> が悪いのかポイントを絞りにくいので、まずは、UM-router間のネッ >> トワークに属しているクライアントからアクセスできるか確認して >> みてはいかがでしょうか？ >> >> 下の例でいえば、192.168.1.3/24 (なクライアントをつないで)から >> アクセスしてみるとか。 >> >> # もちろんそれ以前の問題として 192.168.254.0/24 なクライアン >> # トからはアクセスできてますよね？ってのはありますが。 >> >> >> >> >>>> +--------+ >>>> | client | >>>> +---+----+ >>>> | >>>> +---+----+ >>>> | router | >>>> +---+----+ IP address: 192.168.1.1/24 >>>> | >>>> +-------+ >>>> | | >>>> | +---+----+ IPaddr: 192.168.1.2/24, alias 192.168.254.2/24 >>>> | | UM | >>>> | +--------+ >>>> | >>>> +-------+ >>>> | | >>>> | +---+----+ IPaddr: 192.168.254.10/24 >>>> | | Web0 | >>>> | +--------+ >>>> | >>>> +-------+ >>>> | >>>> +---+----+ IPaddr: 192.168.254.11/24 >>>> | Web1 | >>>> +--------+ >>>> >>>> >> -- >> TATEISHI Katsuyuki >> >> > > From tateishi.katsuyuki ＠ oss.ntt.co.jp Wed Feb 3 16:07:10 2010 From: tateishi.katsuyuki ＠ oss.ntt.co.jp (TATEISHI Katsuyuki) Date: Wed, 03 Feb 2010 16:07:10 +0900 (JST) Subject: [Ultramonkey-l7-users 313] Re: =?iso-2022-jp?b?VWx0cmFNb25rZXkbJEIkRyROGyhCSVAbJEJGKTJhGyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4B6917DA.7030604@gmail.com> References: <4B6904EF.3040808@gmail.com> <20100203.144333.455691525214985478.tateishi.katsuyuki@oss.ntt.co.jp> <4B6917DA.7030604@gmail.com> Message-ID: <20100203.160710.67235356703661032.tateishi.katsuyuki@oss.ntt.co.jp> 立石です。 稲垣 -san wrote: >> # 下の例でいえば 192.168.1.0/24 に統一し、192.168.254.0/24 の >> # アドレスは撤廃。Web0, Web1 のデフォルトルータは >> # 192.168.1.2に設定する >> > この構成で検証しましたが、こちらは504エラーはでないですが > Webページが表示されるまでにかなりの時間がかかります。 Proxyの諦めが良い場合は504を返すこともありそうですね。 「結果として正常だけど異常なほど時間がかかる」という場合は DNSがらみであることが多いように思います。 リアルサーバから何らかのDNSの逆引きなどで時間がかかっているとか。 例えばリアルサーバの web サーバが Apache だとしたら、 httpd.conf のなかの Deny from ... のようなアクセス制限におい て IP アドレス表現ではなく、ドメイン名で制限をかけているとか、 アクセスログに IP アドレスではなくてホスト名を出すようにして いる・・・などの設定をしていると、クライアントのIPアドレスを 逆引きしようとして、DNSに問い合わせを出すはずです。 このとき DNS サーバは設定(/etc/resolv.conf等)されているけど実 際には DNS サーバに到達できないような状況だったりすると、名前 解決に死ぬほど時間がかかってもおかしくない気がします。 Web0, Web1からDNSとのやりとりを確認してみてはいかがでしょう か？またはリアルサーバの /etc/nsswitch.conf (OSによって違いま すが) 等の名前解決手段の設定で dns を無効にしてしまうとか。 > また、UM、リアルでtcpdumpをとってみましが、 > 一回のコネクションごとに送信元IPからのパケットが1号機、2号機に > 流れているようですが正しい動きでしょうか？ これだけではなんとも・・・ 「一回のコネクション」の「コネクション」が何をさしているのか、 (TCPコネクションですか?でもそれだと宛先IPアドレス、ポート番号 とかも同一でないとそもそも1回のコネクションと判断できません し・・・) とか「1号機、2号機に流れているよう」と判断した根拠 となる情報を示していただかないと答えるのは難しいです。 例えば「コネクション」が単に「一般的なWebブラウザから1回アク セスした」のことだとすると、 * リアルサーバのwebサーバで (HTTPの) KeepAlive off、つまり http リクエスト一回毎に 1 tcp コネクションがはられる状態で、 * ipvs(UM) でpersistent は設定しておらず、 * クライアントがアクセスするページには など のブラウザが自動的に複数回アクセスするようなタグが書いて あり、 * 普通のブラウザでアクセスした とか言う状況であれば、1回ブラウザで表示しただけでも複数リクエ ストが発生していてそれぞれ別のリアルサーバに振られることもあ るでしょうから、「送信元IPからのパケット」が両方のリアルサー バに届いていてもおかしくはない気がしますし。 -- TATEISHI Katsuyuki From tateishi.katsuyuki ＠ oss.ntt.co.jp Wed Feb 3 16:08:42 2010 From: tateishi.katsuyuki ＠ oss.ntt.co.jp (TATEISHI Katsuyuki) Date: Wed, 03 Feb 2010 16:08:42 +0900 (JST) Subject: [Ultramonkey-l7-users 314] Re: =?iso-2022-jp?b?VWx0cmFNb25rZXkbJEIkRyROGyhCSVAbJEJGKTJhGyhC?= =?iso-2022-jp?b?GyRCJEskRCQkJEYbKEI=?= In-Reply-To: <4B691E27.6040608@gmail.com> References: <20100203.144333.455691525214985478.tateishi.katsuyuki@oss.ntt.co.jp> <4B6917DA.7030604@gmail.com> <4B691E27.6040608@gmail.com> Message-ID: <20100203.160842.543408123292428404.tateishi.katsuyuki@oss.ntt.co.jp> 立石です。 稲垣 -san wrote: > 正しい動きではないですね。 > 構成をNAT、ツーアームにするとキレイにラウンドロビンされます。 ではその構成でよいのでは・・・というのはナシですか？ # 最終目的は何でしょうか？ -- TATEISHI Katsuyuki From kamijotakashi ＠ gmail.com Wed Feb 3 17:49:27 2010 From: kamijotakashi ＠ gmail.com (Takashi Kamijo) Date: Wed, 3 Feb 2010 17:49:27 +0900 Subject: [Ultramonkey-l7-users 315] =?iso-2022-jp?b?VWx0cmFNb25rZXktTDcbJEJNUSVqJT0hPCU5JSghPCU4GyhC?= =?iso-2022-jp?b?GyRCJSclcyVIJEskRCQkJEYbKEI=?= Message-ID: 初めて投稿させていただきます。 上條と申します。 よろしくお願いいたします。 CentOS5.2に「Heartbeat2環境インストールマニュアル（2.0.0-0対応版）」のとおりに環境を構築しました。 heartbeat-2.1.3-3.el5.centos ultramonkey-l7-2.1.3-0 この状態でheartbeat を起動して、 安定したところで、 # crm_mon 上記コマンドで確認すると ・ ・ ・ Resource Group: grpUltraMonkey prmVIPcheck (heartbeat::ocf:VIPcheck): Started hoge1.com prmL7vsd (heartbeat::ocf:L7vsd): Started hoge1.com prmVIP (heartbeat::ocf:IPaddr): Started hoge1.com prmL7directord (heartbeat::ocf:L7directord): Stopped と、最後の行にあるL7directordだけが起動されません。 リソースエージェントのソース 「/usr/lib/ocf/resource.d/heartbeat/L7directord」の99行目あたり ############################### # Resource Running Check Method ############################### isRunning(){ RET=0 RET=`ps -ef | grep l7directord | grep -v grep | grep -v less | grep -v vi | wc -l` return $RET } の$RETの値を標準出力させてもう一度heartbeatを起動し、観察したのですが、 $RETの値が 「0→2」 と変化することがわかりました。 ちなみに「wc -l」を除いて表示させると # ps -ef | grep l7directord | grep -v grep | grep -v less | grep -vi root 30181 1 0 16:58 ? 00:00:00 /usr/sbin/l7directord start root 30215 30181 0 16:58 ? 00:00:00 l7directord: http:172.16.40.52:80:UP 以上の結果をふまえると、 「/usr/lib/ocf/resource.d/heartbeat/L7directord」の 130行目あたりにある条件式 if [ $RET -eq 1 ]; then これだと$RETの値が"1"でなければうまく動作しないので、 → if [ $RET -ge 1 ]; then と変更してみました。 同様に、 169行目あたりにある条件式も if [ $RET -eq 1 ]; then → if [ $RET -ge 1 ]; then と変更してみました。 この状態でようやくHeartbeatからL7directordを起動することができました。 今のところ、これで上手く動いているようですが、 他に事例がなかったので、MLに投稿させていただきました。 皆様はこんなことしなくても正常に動作されてますでしょうか？ 以上、ご教授の程宜しくお願い致します。 From kt ＠ wheel.jp Wed Feb 3 18:26:59 2010 From: kt ＠ wheel.jp (TATEISHI Katsuyuki) Date: Wed, 03 Feb 2010 18:26:59 +0900 (JST) Subject: [Ultramonkey-l7-users 316] Re: =?iso-2022-jp?b?VWx0cmFNb25rZXktTDcbJEJNUSVqJT0hPCU5JSgbKEI=?= =?iso-2022-jp?b?GyRCITwlOCUnJXMlSCRLJEQkJCRGGyhC?= In-Reply-To: References: Message-ID: <20100203.182659.737004071327906687.kt@wheel.jp> 立石と申します。こんばんは。 おそらくポイントが2ヶ所あります。 From: Takashi Kamijo Subject: [Ultramonkey-l7-users 315] UltraMonkey-L7用リソースエージェントについて Date: Wed, 3 Feb 2010 17:49:27 +0900 > CentOS5.2に「Heartbeat2環境インストールマニュアル（2.0.0-0対応版）」のとおりに環境を構築しました。 > > heartbeat-2.1.3-3.el5.centos > ultramonkey-l7-2.1.3-0 * ポイント1. 参照するマニュアルについて ultramonkey-l7-2.1.3-0 で Heartbeat を使った冗長構成を組むの であれば、 http://sourceforge.jp/projects/ultramonkey-l7/docs/UltraMonkey-L7_HBv2_install_manual_v1.3/ja/5/UltraMonkey-L7_HBv2_install_manual_v1.3.txt の「UltraMonkey-L7　Heartbeat v2環境インストールマニュアル　v1.3」 を参照してください。(手順的にはそんなに違わないと思いますの で、次のポイント2のほうが直接的な原因だと思います) * ポイント2. リソースエージェント(RA)について たぶんこちらが直接の原因です。 heartbeat用RAは ultramonkey-l7-2.1.3-0 の RPM でプログラム 本体と一緒にインストールされるものが最新ですので、そちらを 使ってみてください。 # ちなみにこのRAは heartbeat-2.1.4系 で動作確認しています。 RAはRPMだと /usr/share/doc/ultramonkey-l7-2.1.3-0/heartbeat-ra 配下あたり にインストールされます。 正確には rpm -ql ultramonkey-l7 |grep doc とかで探せると思います。 (ultramonkey-l7-hbra_hb2.1.4.tar.gzは若干古いです。上記の新し い手順書でも ultramonkey-l7-hbra_hb2.1.4.tar.gz を使えって書 いてありますね・・・すみません。) > リソースエージェントのソース > 「/usr/lib/ocf/resource.d/heartbeat/L7directord」の99行目あたり > > ############################### > # Resource Running Check Method > ############################### > isRunning(){ > RET=0 > RET=`ps -ef | grep l7directord | grep -v grep | grep -v less | > grep -v vi | wc -l` > return $RET > } 該当の行付近が ultramonkey-l7-2.1.3-0 に含まれる RA だと、 ============================================================ 107 ############################### 108 # Resource Running Check Method 109 ############################### 110 isRunning(){ 111 RET=0 112 RET=`ps -ef | grep "/usr/sbin/l7directord start" | grep -v grep | wc -l` 113 return $RET 114 } ============================================================ となってますので、正しく動くと思います。(start の行しか含ま れないので) 大雑把な回答ですみませんが、以上です。 -- TATEISHI Katsuyuki