DSAS開発者の部屋

NATによる負荷分散では、パケットの書き換えコストがロードバランサに集中してしまいますが、リアルサーバに特殊な設定をしなくてもよいという手軽さがあります。DSRの場合はロードバランサとリアルサーバが協調しあって分散環境を構成するため、リアルサーバ側にも若干の小細工が必要になってしまいます。

一般的(?)に大規模システムを構築する場合は、「ネットワーク機器の整備はこの部門」、「サーバの調達はこのベンダーさん」、「インストールはあのグループ」みたいに役割が組織の壁で仕切られている事が多いのではないでしょうか。そうすると「L4スイッチでDSRするからサーバ側の設定もよろしくね☆」みたいな事は実際問題として難しいのかもなあと思っていたりします。サーバをインストールして設定してローカルでの接続が確認できたからといって、DSRで外部から繋がるとは限らないので、トラブルシューティングというか切り分けが面倒になってしまいがちなんです。

KLabのようなベンチャー企業では、限られているリソースをフル活用して全力でシステムを組み上げなければなりません。「検証用」と称して高額な機器を買うことはなかなかできませんが、システム全体で最も効率がよいと思われる方法を模索しながらじっくりと組み上げていける楽しみがあります。日頃からそんな事をやっている物好きなお兄さん達にとって、「Linuxでロードバランサ」という題材は絶好のオモチャだったりするわけです。

前置きが長くなってしまいましたが、そろそろ作業に取りかかりましょうか(^^;

ネットワーク構成は前回と一緒になります。
まずは、各マシンにおいて以下のコマンドを実行します。

lv1とlv2の設定変更

eth0に割り当ててあったWEBサービス用の仮想IPアドレス(10.10.31.100)を削除します。

   # ip addr del 10.10.31.100 dev eth0

ちょっとしたおまじないをかけます（説明は後述）

  # iptables -t mangle -A PREROUTING -d 10.10.31.100 -j MARK --set-mark 1

  # ip rule add prio 100 fwmark 1 table 100

  # ip route add local 0/0 dev lo table 100

  # echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter

w101とw102の設定変更

こちらにもちょっとしたおまじないをかけます（やっぱし説明は後述）

   # iptables -t nat -A PREROUTING -d 10.10.31.100 -j REDIRECT

keepalived.confを変更

lv1,lv2 の /usr/klab/etc/keepalived.conf の lvs_method を DR にします。

（変更前）

  lvs_method  NAT

（変更後）

  lvs_method  DR

keepalivedを起動

lv1 と lv2 の keepalived を起動します。

   # /usr/klab/sbin/keepalived -n -f /usr/klab/etc/keepalived.conf --check --vrrp

設定は以上です。
client から今まで通り example.org にアクセスしてみてください。
きっと今までと同じ結果が返って来ると思います。

 client:~$ curl -H 'Host: example.org' http://10.10.31.100

 w101 nano

 client:~$ curl -H 'Host: example.org' http://10.10.31.100

 w102 desu

はい、これで DSR のできあがりです。おつかれさまでしたあぁ〜
・・・って終わってしまうのは少し寂しすぎますね(^^;

とりあえず、ちゃんと DSRとして動いているかどうか tcpdump でパケットを追ってみましょう。
流れを追いやすいように client からtelnetで 10.10.31.100 の 80 番ポートに接続する様子を追ってみます。

※tcpdumpの使い方は 「ネットワークパケットを覗いちゃえ」 も参考にしてください。

 client:$ telnet 10.10.31.100 80

すると、lv1(lv2)ではこんな結果になります。

root@lv1:~# tcpdump -n -i eth0 port 80 and host 10.10.31.200

IP 10.10.31.200.54546 > 10.10.31.100.80: S 2507165666:2507165666(0)

IP 10.10.31.100.80 > 10.10.31.200.54546: S 3509055605:3509055605(0) ack

IP 10.10.31.200.54546 > 10.10.31.100.80: . ack 



root@lv1:~# tcpdump -n -i eth1 port 80 and host 10.10.31.200

IP 10.10.31.200.48185 > 10.10.31.100.80: S 2923294161:2923294161(0)

IP 10.10.31.100.80 > 10.10.31.200.48185: S 3928787480:3928787480(0) ack

IP 10.10.31.200.48185 > 10.10.31.100.80: . ack

同様に w101(w102)ではこうなります。

root@w101:~# tcpdump -n -i eth0 port 80 and host 10.10.31.200

IP 10.10.31.200.48185 > 10.10.31.100.80: S 2923294161:2923294161(0)

IP 10.10.31.100.80 > 10.10.31.200.48185: S 3928787480:3928787480(0) ack 

IP 10.10.31.200.48185 > 10.10.31.100.80: . ack

10.10.31.200 から送られた 10.10.31.100 宛のパケットが アドレス変換されないまま w101 に到達していることがわかると思います。また、w101 ではこのパケットに対する ACK をちゃんと返しているので TCP接続が正常に完了できていることもわかるかと思います。

意外とあっさり終わって拍子抜けしてしまいましたか？
このシステム上には 10.10.31.100 という IPアドレスを持ってるマシンがいないにも関わらず、WEBサービスとしてこのアドレスを利用できるのがこの構成の特徴というか面白いところだと思います。
　
　
さて、それでは説明を後回しにしていた各設定の意味を順に追っていくことにしましょう。
　
　
lv1:# ip addr del 10.10.31.100 dev eth0

ここでは、NAT構成で使っていた WEBサービス用の仮想IPアドレスを削除しています。
DSR構成では、リアルサーバがこのアドレスをソースとしたパケットを返すわけですが、lv1でこのアドレスを割り当てたままだと、「自分のIPアドレスを他人が偽装している」とみなして破棄してしまうようです。今回のようにリアルサーバからの戻りパケットがlv1を経由するような構成の場合は要注意です。もちろん、リアルサーバのデフォルトゲートウエイを別のルータに向ける場合はこの限りではありません。
　
　
　　
lv1:# iptables -t mangle -A PREROUTING -d 10.10.31.100 -j MARK --set-mark 1

lv1 に届いた 10.10.31.100 宛のパケットに対して mark 値を 1 にセットするように netfilterを設定します。
　
　
　
lv1:# ip rule add prio 100 fwmark 1 table 100

mark 値が 1 のパケットは 100 番の経路テーブルを適用させるようにします。
　
　
　
lv1:# ip route add local 0/0 dev lo table 100
　
全てのパケットをローカルデバイスにルーティングするような設定を 100番の経路テーブルに追加します。


さて、Linuxにはポリシールーティングという機能があることをご存じでしょうか。
カーネル構築時に CONFIG_IP_MULTIPLE_TABLES=y とする事で有効になる機能ですが、その名の通り複数の経路テーブルを持つことができる機能です。通常 route コマンドで参照や設定をしているテーブルは、256個あるテーブルの中の1つに過ぎなかったりします。興味のある方は、以下のコマンドを実行してみてください。

 ip route list table 0

 ip route list table 254

 ip route list table 255

この辺の詳しい話はまた別の機会にでもしたいと思います。
参考程度ですが メンテナンス回線の経路（Linuxのポリシールーティングの活用） でも若干触れています。

とりあえず今は

「ある条件にマッチしたパケットを特定の経路テーブルで評価させる事ができる」

ということだけ理解してください。

で、話を戻すと・・・ここでは、

1) 10.10.31.100 宛のパケットに mark=1をセットする(netfilterの機能)
2) mark=1 のパケットは 100番の経路テーブルを使う(ポリシールーティングの機能)
3) 100番の経路テーブルでは すべてのパケットをローカルデバイスに流すように定義しておく

これらの設定によって、10.10.31.100を IPエイリアスで割り当てなくても LVS の処理に流すという芸当ができてしまうわけです。
　
　
　
lv1:# echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter

rp_filterを無効にします。これが有効のままだと、カーネルのソースアドレス認証(Source Address Verification)という機能が働いてしまうため、リアルサーバからの応答パケットをフィルタしてしまいます。
　
　
　
w101:# iptables -t nat -A PREROUTING -d 10.10.31.100 -j REDIRECT

しつこいですが、リアルサーバにも 10.10.31.100 というアドレスを割り当てていません。
しかし、LVS の機能によって 10.10.31.100 宛のパケットがリアルサーバに届きます。
その場合、Linuxはフォワーディングするなり破棄するなりの動作をしますが、-j REDIRECT を指定されたパケットは送信先アドレスが自分自身のIPアドレスに変換されてローカルデバイスに渡されます。各リアルサーバの内部でこっそりとアドレス変換(DNAT)をしてくれるようになるんです。

また、「リアルサーバがVIPを意識するのいやじゃあ」という方には、

lv1:# iptables -t mangle -A POSTROUTING -d 10.10.31.100 -j TOS --set-tos 2

とした上で、上記のコマンドの代わりに

w101:# iptables -t nat -A PREROUTING -m tos --tos 2 -j REDIRECT

とかすると、LVSマシン上のiptablesだけで VIPを管理できるようになるのでお手軽かもしれません。ただし、この方法は思わぬ落とし穴もありますので「動けばいいや」的な方にはあまりお勧めできません(^^;
　
　
今回紹介した手法以外にも、

● iptables -j REDIRECT を使わずに VIP を IP Alias でリアルサーバに割り当てる
　 ※リアルサーバのarp応答をなんらかの方法で抑制する必要があるかもしれません。

● ポリシールーティングとMARKを使わずに VIP を IP Alias で LVSマシンに割り当てる
※応答パケットを処理するために、カーネルに特殊なパッチ(forward_shared)をあてる必要があります

● リアルサーバの戻りのパケットは LVSマシンじゃない別のルータを経由させる
※ naoyaさんがこの構成を試しているようです


などでも構築可能です。
仕組みさえ理解できれば様々な運用形態が考えられるのも DSR の大きな特徴です。
DSASでは IP Alias を使わずに構成し、リアルサーバの応答パケットをLVSマシンに返すようにしていますが、それは以下のような背景があったためです。

●サービス追加(IPアドレスを追加)する度にノードに新IPアドレスを割り当てたくない
　DSASは共用プラットフォームなのでIPアドレスの数が膨大になってしまいます
　稼働しているサーバ上でipコマンドやifconfigコマンドでIPアドレスを追加するのは超怖いです
　iptablesだけでVIPを追加できるならそのほうがラクチンなんです（運用上の事情もあり）

●リアルサーバからの応答パケットもLVSマシンを経由させたい
　DSASのロードバランサはルータとファイアウォールも兼ねています。
　外部との通信制御（フィルタリングポリシ）をLVSマシン上で一元管理したかったのです。
　DSRであればLVSマシンの仕事は転送だけなので、ボトルネックになるほどの負荷はかかりません。
　上流回線が100Mbpsなら、ギガビットスイッチとGNIC付きのサーバでワイヤーレート出せます。
　そのため、あえて応答用のGWを別立てする必要がなかったのです。
　もし別に立てるのであれば、そこも冗長化しないといけなくなります。


いかがでしたでしょうか。
「ロードバランサを入れたいけどちょっと・・・」と思っている方の参考になれば幸いです。
不明な点などがあれば、遠慮なくコメントなりトラックバックなり頂けるとモチベーションがあがるかもしれません（笑）

負荷分散環境って、データセンターだけで構築すれば良いというものじゃなく、開発者の手元にも必要なものだと思います。Webアプリを開発したのはいいけれど、負荷分散環境にもっていったら動作がおかしくなったなんて事ありませんか？高負荷に耐えられるシステムを開発するには、開発環境にもロードバランサを置くべきです。しかしながら、コストの都合上でそれができない現場も少なくないはずです。

そんな時に Linux でさくっと負荷分散環境を作ることができれば、開発効率や製品品質の向上が期待できるのではないでしょうか。ちなみにKLabでは、開発環境として、mini-DSAS というシステムを構築しており、開発者が自由に負荷分散システムに触れる事ができる体制になっています。

参考

Manpage of IPTABLES

Linux Advanced Routing & Traffic Control HOWTO

Iptables Tutorial

Iptablesチュートリアル 日本語訳

Julian's Software and Patches page.
LVSの開発者の一人 Julian さんが作っているカーネルパッチがいっぱいあります。
かなりトリッキーというか通好みのパッチがいっぱいあるので結構オススメです。

iptablesによる負荷分散とDoS対策