- PR -

LVS + keepalived でロードバランス SMTP編

1
投稿者投稿内容
Jumpin'' Jack Flash
大ベテラン
会議室デビュー日: 2006/01/24
投稿数: 198
投稿日時: 2007-04-26 00:11
LVS + keepalived でメールサーバーをロードバランスしようとしています。

とりあえず、SMTPだけやってみました。

■/etc/keepalived/keepalived.conf
----
virtual_server 192.168.1.12 25 {
delay_loop 30
lb_algo rr
lb_kind DR
protocol TCP

real_server 192.168.1.2 25 {
weight 1
SMTP_CHECK {
connect_timeout 10
retry 2
delay_before_retry 5
helo_name "mail.nadai.jp"
}
}

real_server 192.168.1.3 25 {
weight 1
SMTP_CHECK {
connect_timeout 10
retry 2
delay_before_retry 5
helo_name "mail.nadai.jp"
}
}
}
----

送信はできるのですが、ロードバランスされているように見えません。
/var/log/maillog を見ると 192.168.1.2 しか使っていないようです。

# ipvsadm -L -n
----
IP Virtual Server version 1.2.0 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.12:25 rr
-> 192.168.1.3:25 Route 1 0 0
-> 192.168.1.2:25 Route 1 0 0
----

転送レートを見ても、全て0です。

# ipvsadm -L -n --rate
----
IP Virtual Server version 1.2.0 (size=4096)
Prot LocalAddress:Port CPS InPPS OutPPS InBPS OutBPS
-> RemoteAddress:Port
TCP 192.168.1.12:25 0 0 0 0 0
-> 192.168.1.3:25 0 0 0 0 0
-> 192.168.1.2:25 0 0 0 0 0
----

ロードバランスされない原因について見当がつけば、教えてください。

よろしくお願いいたします。
たらお
大ベテラン
会議室デビュー日: 2006/12/25
投稿数: 206
お住まい・勤務地: 東京・永代通り
投稿日時: 2007-04-26 05:44
引用:

# ipvsadm -L -n
----
IP Virtual Server version 1.2.0 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.1.12:25 rr
-> 192.168.1.3:25 Route 1 0 0
-> 192.168.1.2:25 Route 1 0 0


Connectionがカウントされてないので、バランスしてないというよりは、
どちらのサーバーも使われてないように見えます。
SMTP_CHECK でサーバーダウンと判断されているのかも？
リアルサーバーでSMTPのプロセスは動いていますか？

ちょっと甘くなりますが、SMTP_CHECKを

TCP_CHECK {
connect_port 25

に変えてみるのも良いかと。切り分けとしては、sorry_serverも欲しいですね。


_________________
＿福田太郎＿
Jumpin'' Jack Flash
大ベテラン
会議室デビュー日: 2006/01/24
投稿数: 198
投稿日時: 2007-04-26 09:35
コメントありがとうございます。

早速、SMTP_CHECKを
TCP_CHECK {
connect_port 25
}
に変更し、
sorry_server 192.168.1.3 25
としましたが、状況は変わらず、
全て、192.168.1.2 で処理されます。

tcpdumpしてみました。
# tcpdump -n host 192.168.1.12 and port 25
メールを送信しても何も表示されません。

# tcpdump -n port 25
----
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
09:13:23.274782 IP 192.168.1.11.40231 > 72.14.253.27.smtp: S 1297458975:1297458975(0) win 5840 <mss 1460,sackOK,timestamp 344682669 0,nop,wscale 2>
09:13:23.388919 IP 72.14.253.27.smtp > 192.168.1.11.40231: S 660604228:660604228(0) ack 1297458976 win 8190 <mss 1412>
09:13:23.389007 IP 192.168.1.11.40231 > 72.14.253.27.smtp: . ack 1 win 5840
09:13:23.510108 IP 72.14.253.27.smtp > 192.168.1.11.40231: P 1:41(40) ack 1 win 5720
09:13:23.510197 IP 192.168.1.11.40231 > 72.14.253.27.smtp: . ack 41 win 5840
09:13:23.510300 IP 192.168.1.11.40231 > 72.14.253.27.smtp: P 1:21(20) ack 41 win 5840
09:13:23.621919 IP 72.14.253.27.smtp > 192.168.1.11.40231: . ack 21 win 5720
09:13:23.624273 IP 72.14.253.27.smtp > 192.168.1.11.40231: P 41:153(112) ack 21 win 5720
09:13:23.624431 IP 192.168.1.11.40231 > 72.14.253.27.smtp: P 21:57(36) ack 153 win 5840
09:13:23.782754 IP 72.14.253.27.smtp > 192.168.1.11.40231: . ack 57 win 5720
09:13:23.874898 IP 72.14.253.27.smtp > 192.168.1.11.40231: P 153:167(14) ack 57 win 5720
09:13:23.875021 IP 192.168.1.11.40231 > 72.14.253.27.smtp: P 57:86(29) ack 167 win 5840
09:13:23.992579 IP 72.14.253.27.smtp > 192.168.1.11.40231: . ack 86 win 5720
09:13:24.237805 IP 72.14.253.27.smtp > 192.168.1.11.40231: P 167:181(14) ack 86 win 5720
09:13:24.237931 IP 192.168.1.11.40231 > 72.14.253.27.smtp: P 86:92(6) ack 181 win 5840
09:13:24.350620 IP 72.14.253.27.smtp > 192.168.1.11.40231: . ack 92 win 5720
09:13:24.351971 IP 72.14.253.27.smtp > 192.168.1.11.40231: P 181:195(14) ack 92 win 5720
09:13:24.352202 IP 192.168.1.11.40231 > 72.14.253.27.smtp: P 92:816(724) ack 195 win 5840
09:13:24.506601 IP 72.14.253.27.smtp > 192.168.1.11.40231: . ack 816 win 6516
09:13:24.724539 IP 72.14.253.27.smtp > 192.168.1.11.40231: P 195:235(40) ack 816 win 6516
09:13:24.724784 IP 192.168.1.11.40231 > 72.14.253.27.smtp: P 816:822(6) ack 235 win 5840
09:13:24.724824 IP 192.168.1.11.40231 > 72.14.253.27.smtp: F 822:822(0) ack 235 win 5840
09:13:24.840758 IP 72.14.253.27.smtp > 192.168.1.11.40231: . ack 822 win 6516
09:13:24.840813 IP 72.14.253.27.smtp > 192.168.1.11.40231: P 235:294(59) ack 822 win 6516
09:13:24.840927 IP 192.168.1.11.40231 > 72.14.253.27.smtp: R 1297459797:1297459797(0) win 0
09:13:24.842045 IP 72.14.253.27.smtp > 192.168.1.11.40231: F 294:294(0) ack 822 win 6516
09:13:24.842096 IP 72.14.253.27.smtp > 192.168.1.11.40231: . ack 823 win 6516
09:13:24.842140 IP 192.168.1.11.40231 > 72.14.253.27.smtp: R 1297459797:1297459797(0) win 0
09:13:24.842189 IP 192.168.1.11.40231 > 72.14.253.27.smtp: R 1297459798:1297459798(0) win 0
----
なぜか192.168.1.11で処理されています。72.14.253.27はGmailのメールサーバー
みたいです。
192.168.1.11は、OpenVPNのサーバーアドレスで、
確かに今、OpenVPNで接続して仮想ローカル環境でテストしています。
そして、192.168.1.11 = 192.168.1.2なんです。だから送信できた？
# ifconfig
----
eth0 Link encap:Ethernet HWaddr 00:13:72:19:5F:03
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::213:72ff:fe19:5f03/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:11141627 errors:0 dropped:0 overruns:0 frame:0
TX packets:2097997 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1560287011 (1.4 GiB) TX bytes:684781101 (653.0 MiB)
Interrupt:177

eth0:vpn Link encap:Ethernet HWaddr 00:13:72:19:5F:03
inet addr:192.168.1.11 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
Interrupt:177
----
メールクライアントのSMTPサーバーは、192.168.1.12にしてあります。
パケットの流れ方がおかしくなっている気がしますが、
どうしてでしょうかねぇ。


[ メッセージ編集済み 編集者: Jumpin' Jack Flash 編集日時 2007-04-26 09:36 ]
たらお
大ベテラン
会議室デビュー日: 2006/12/25
投稿数: 206
お住まい・勤務地: 東京・永代通り
投稿日時: 2007-04-27 07:14
試験構成が分からなくなってきました。

->192.168.1.12(VIP)
->->192.168.1.2(OpenVPN:192.168.1.11)
->->192.168.1.3

Gmailのサーバーからは、グローバルアドレスに向けて投げてきているはずなので、
それが192.168.1.11に変換されていることになります。
LBのプロセスをすり抜けて、直接ポート25を叩かれている感じですね。

_________________
＿福田太郎＿
Jumpin'' Jack Flash
大ベテラン
会議室デビュー日: 2006/01/24
投稿数: 198
投稿日時: 2007-04-29 21:11
この現象の理由がなんとなくわかりました。

コード:
　　　　　ロードバランサ
　　　　　　　　|
　　　　 -------+--------
　　　　|　　　　　　　　|
 リアルサーバ1　　リアルサーバ2
(OpenVPNサーバ)


リアルサーバでVIPが処理できないため、各リアルサーバで、
このようにしていました。
iptables -t nat -A PREROUTING -p tcp -d 192.168.1.12 -j REDIRECT

そのため、OpenVPNを経由するパケットがロードバランサに到達する前に
リアルサーバ1で処理されているように思います。

そこで、このようにしました。
iptables -t nat -A PREROUTING -i eth0 -p tcp -d 192.168.1.12 -j REDIRECT

すると、パケットがロードバランサまで到達し、正しくロードバランスされるように
なりました。

しかし、今度はリアルサーバ1の方に割り振られたときに送信することができなく
なりました。
コード:
# tcpdump -n host 192.168.1.12 and port 25
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
20:21:20.523496 IP 192.168.1.200.1492 > 192.168.1.12.smtp: S 447085879:447085879(0) win 62216 <mss 1336,nop,nop,sackOK>
20:21:20.523658 IP 192.168.1.200.1492 > 192.168.1.12.smtp: S 447085879:447085879(0) win 62216 <mss 1336,nop,nop,sackOK>
20:21:20.523685 IP 192.168.1.200.1492 > 192.168.1.12.smtp: S 447085879:447085879(0) win 62216 <mss 1336,nop,nop,sackOK>
20:21:20.523801 IP 192.168.1.200.1492 > 192.168.1.12.smtp: S 447085879:447085879(0) win 62216 <mss 1336,nop,nop,sackOK>
20:21:20.523811 IP 192.168.1.200.1492 > 192.168.1.12.smtp: S 447085879:447085879(0) win 62216 <mss 1336,nop,nop,sackOK>
20:21:20.523942 IP 192.168.1.200.1492 > 192.168.1.12.smtp: S 447085879:447085879(0) win 62216 <mss 1336,nop,nop,sackOK>
20:21:20.523951 IP 192.168.1.200.1492 > 192.168.1.12.smtp: S 447085879:447085879(0) win 62216 <mss 1336,nop,nop,sackOK>
20:21:20.524111 IP 192.168.1.200.1492 > 192.168.1.12.smtp: S 447085879:447085879(0) win 62216 <mss 1336,nop,nop,sackOK>
　：


OpenVPNクライアントからのパケットはそのまま通過させ、ロードバランサからの
パケットのみ自分宛として受け入れるようにするには、どう設定すればよいで
しょうか？

コード:
# ifconfig -a
----
br0       Link encap:Ethernet  HWaddr 00:13:72:19:5F:03  
          inet addr:192.168.1.11  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::213:72ff:fe19:5f03/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10674630 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2116271 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:948618828 (904.6 MiB)  TX bytes:656982082 (626.5 MiB)

eth0      Link encap:Ethernet  HWaddr 00:13:72:19:5F:03  
          inet addr:192.168.1.2  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::213:72ff:fe19:5f03/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:12210044 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2493952 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1684109974 (1.5 GiB)  TX bytes:746846972 (712.2 MiB)
          Interrupt:177 

eth0:vpn  Link encap:Ethernet  HWaddr 00:13:72:19:5F:03  
          inet addr:192.168.1.11  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          Interrupt:177 

eth0:0    Link encap:Ethernet  HWaddr 00:13:72:19:5F:03  
          inet addr:192.168.1.20  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          Interrupt:177 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:3336900 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3336900 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:235725331 (224.8 MiB)  TX bytes:235725331 (224.8 MiB)

sit0      Link encap:IPv6-in-IPv4  
          NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

tap0      Link encap:Ethernet  HWaddr 00:FF:F0:8C:24:C3  
          inet6 addr: fe80::2ff:f0ff:fe8c:24c3/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:218329 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8882303 errors:0 dropped:1 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:23299059 (22.2 MiB)  TX bytes:1209562157 (1.1 GiB)
----


よろしくお願いいたします。
F/A
ぬし
会議室デビュー日: 2006/03/18
投稿数: 312
お住まい・勤務地: Tokyo
投稿日時: 2007-05-01 18:23
> OpenVPNクライアントからのパケットはそのまま通過させ、ロードバランサからの
> パケットのみ自分宛として受け入れるようにするには、どう設定すればよいでしょうか？

ロードバランサからリアルサーバには、
宛先192.168.1.12で届くんでしたっけ？

192.168.1.2 か 192.168.1.3に宛先が書き換えられ、
送信元も192.168.1.12に書き換えられるので、
REDIRECTとか使う必要は無いように思うのですが、
そういうわけでもないのでしょうか？
あしゅ
ぬし
会議室デビュー日: 2005/08/05
投稿数: 613
投稿日時: 2007-05-01 19:41
別スレッドでも回答していたのですが、
かなり無茶な構成をしているように見えます。

全てをルータ一台で処理しようしてどつぼにはまっているのでは？

iptablesとLVSでの二重のNAT、さらにOpenVPNまでが絡むとなると、
カーネル内の処理順序などの実装の詳細に強く依存しそうに思います。

REDIRECTで一部がうまく行くように見えるのも、
リダイレクトの結果、ルーティング処理がリセットされた等の
実装的な理由でたまたま動いている気もしなくはないです。

あと、NATベースでロードバランスすると、
同一セグメントからの接続はロードバランスできません。

パケットが常にGWとして仮想サーバを通過する必要があるのに、
実サーバからそのまま到達できてしまうため、クライアントに
とっては見知らぬホストから返答があったように見えるためです。

OpenVPNがどうの、という問題はこの辺かもしれません。
Jumpin'' Jack Flash
大ベテラン
会議室デビュー日: 2006/01/24
投稿数: 198
投稿日時: 2007-05-02 16:22
引用:

F/Aさんの書き込み (2007-05-01 18:23) より:
> OpenVPNクライアントからのパケットはそのまま通過させ、ロードバランサからの
> パケットのみ自分宛として受け入れるようにするには、どう設定すればよいでしょうか？

ロードバランサからリアルサーバには、
宛先192.168.1.12で届くんでしたっけ？

192.168.1.2 か 192.168.1.3に宛先が書き換えられ、
送信元も192.168.1.12に書き換えられるので、
REDIRECTとか使う必要は無いように思うのですが、
そういうわけでもないのでしょうか？


ダイレクトルーティングのときに問題になるようです。

別スレで、いろいろとご意見をいただき、考えました。

コード:

　　　　　　 ルータ

　　　　　 192.168.1.1

　　　　　　　 NAT

　　　　　　　　|

　　　+---------+--------+

　　　|　　　　　　　　　|

LVSディレクタ 　　　LVSディレクタ

 192.168.1.12 -VRRP- 192.168.1.12

兼リアルサーバ　　　兼リアルサーバ

兼OpenVPNサーバ　　　192.168.1.3

 192.168.1.2


OpenVPN経由のパケットもそのまま処理してOK（ロードバランスされるはず）。


[ メッセージ編集済み 編集者: Jumpin' Jack Flash 編集日時 2007-05-02 16:27 ]
1

スキルアップ／キャリアアップ（JOB@IT）