• 締切済み

同一セグメントでのLVS

LinuxでLVSを利用してロードバランサを構築しています。 構成1: LB[keepalived(192.168.1.1)]仮想(192.168.0.3) A[Apache(192.168.0.1)] B[Apache(192.168.0.2)] 構成2: A[Apache+keepalived(192.168.0.1)]仮想(192.168.0.3) B[Apache(192.168.0.2)] DSASのページなどを参考にしているのですが、構成1の3台構成NATであれば問題なく動きます。しかし構成2の同一セグメントでサーバそのものに仮想を持たせるとうまくいきません。どうもAが仮想を持った際に192.168.0.2への振り分けが発生しても、自身で処理しようとしているのか失敗してしまいます。設定は以下の通りです。何が足りないのか教えて頂けると助かります。尚、問題切り分けとしてvrrpは片系です。 ---keepalived.conf virtual_server_group HTTP3 { 192.168.0.3 80 } virtual_server group HTTP3 { delay_loop 10 lvs_sched rr lvs_method DR protocol TCP virtualhost 192.168.0.3 real_server 192.168.0.1 80 { weight 1 inhibit_on_failure HTTP_GET { url { path /test.html status_code 200 } connect_timeout 3 } } real_server 192.168.0.2 80 { weight 1 inhibit_on_failure HTTP_GET { url { path /test.html status_code 200 } connect_timeout 3 } } } vrrp_instance VI3 { state MASTER interface bond0 lvs_sync_daemon_interface bond0 garp_master_delay 5 virtual_router_id 3 priority 100 nopreempt advert_int 1 virtual_ipaddress { 192.168.0.3/24 dev bond0 } } --- ---投入コマンド echo 0 > /proc/sys/net/ipv4/conf/bond0/rp_filter iptables -t mangle -A PREROUTING -d 192.168.0.3 -j MARK --set-mark 1 ip rule add prio 3 fwmark 1 table 3 ip route add local 0/0 dev lo table 3 iptables -t nat -A PREROUTING -p tcp -d 192.168.0.3 -j REDIRECT ---

みんなの回答

回答No.4

かなり前の投稿なのでいまさらですが、こちらの投稿を参考に下記の設定を行って 実現できましたので、記載させていただきます。 お話にあったように、「keepalivedが受け取る前にApacheが受け取ってしまうのか、バランシングをせずに全てAのみで処理されてしまうのです。」という部分がありましたので、 master, backupそれぞれになった際に、iptablesの設定を動的に書き換えるシェルを実行し、 VIP宛のパケットがkeepalivedで処理されるようにしました。(単純にiptablesのコマンドを叩いているだけです) keepalived.confの設定は両サーバーとも同じです。 - keepalived.conf vrrp_instance V_WEB { state BACKUP ~~~ 省略 notify_master "/bin/sh /etc/keepalived/notify_master.sh" notify_backup "/bin/sh /etc/keepalived/notify_backup.sh" } - notify_master.sh #!/bin/sh iptables -t nat -D PREROUTING -d 192.168.0.3 -j REDIRECT - notify_backup.sh iptables -t nat -D PREROUTING -d 192.168.0.3 -j REDIRECT iptables -t nat -A PREROUTING -d 192.168.0.3 -j REDIRECT

すると、全ての回答が全文表示されます。
  • t-okura
  • ベストアンサー率75% (253/335)
回答No.3

> できない!というずばりの回答を頂きましたが、今は出来るようです。 どうも貴重な情報をありがとうございます。 keepalived ではなく ldirectord ですが試してみたところ、下記のように できました。 # ipvsadm -L -n IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.0.3:80 rr -> 192.168.0.11:80 Route 1 0 0 -> 192.168.0.12:80 Route 1 0 0 -> 192.168.0.10:80 Local 1 0 0 昔できなかったのは、ループバックアドレス 127.0.0.1 だったのかもし れません。 本題の同居しているサーバ自身からのアクセスは、こちらでも振り分け されません。tcpdump してみると lo にパケットが現れています。振り 分けするには eth0 経由にすればよいのではないかと思うのですが、 lo のパケットを eth0 にまわす方法はわかりません。

del4thta
質問者

補足

ご回答及び検証ありがとうございます。 やはり出来るのは間違いないみたいですが(ldirectordも中身はLVSですよね?最近ultramonkeyのサイトが繋がらないのは何故?) 、だとするとt-okura様の言うとおり問題はloに飛んでいるパケットをeth0などの外部にRoutingしてやれば行けるのかも!と思ってiptablesを叩きまくりましたが、うまくいきませんでした(eth0にDNATしてみても、やっぱり振り分けるより先にApacheが食べてしまってるように見える)。ただ少し光明が見えてきた気がするのですが。 何か良い手段がありましたらご教授下さい。

すると、全ての回答が全文表示されます。
  • t-okura
  • ベストアンサー率75% (253/335)
回答No.2

DSR(Direct Server Return)の構成をされていますが、DSR は、ロードバラ ンサの IP に届いたアクセスを振り分け先のサーバが、あたかも自分がそ の IP を持つサーバであるかのように振る舞って、クライアントに直接応 答を返すものです。応答パケットのソースアドレスは、ロードバランサの アドレスになります。 このことを実現するため、振り分け先のサーバは、ロードバランサあての アクセスを自分自身に取り込みます。つまり、DSR 構成のサーバ にロードバランサあてのアクセスがあると、自分自身で処理してしまうた め、振り分けが行われません。 なお、LVS では DSR 構成でなくてもロードバランサとリアルサーバを 同居させることはできないはずです。数年前に散々テストして、できない という情報を見つけました。もっとも、そのころ keepalived に DSR を行 うような機能はなかったので、変わっているかもしれません。

del4thta
質問者

補足

ご回答ありがとうございます。 できない!というずばりの回答を頂きましたが、今は出来るようです。下記の補足にも記述しました通り、別サーバにクライアントがあれば出来てしまうのです。はてなの中の人+ultramonkleyなどを参考に出来た次第です。 http://d.hatena.ne.jp/hirose31/20060817/1155795703 http://72.14.235.104/search?sourceid=navclient&hl=ja&ie=UTF-8&rls=GGLJ,GGLJ:2006-36,GGLJ:ja&q=cache:http%3A%2F%2Fultramonkey.jp%2F2.0.1%2Ftopologies%2Fsl-ha-lb-eg.html tcpdumpで内容を確認しましたが、srcMACが違う以外は同じパケットが飛んでいるように見えます。確かにDSRであればIPは書き換えないので自身でそのパケットを取り込んでしまうのでダメそうな気もしますが、外部から出来て自身から出来ないのはおかしい!と思い、何か方法があるのではないかと模索しているところです。 何か良いアイデアがありましたら宜しくお願い致します。

すると、全ての回答が全文表示されます。
  • ops
  • ベストアンサー率52% (13/25)
回答No.1

はじめまして、 掲題は同一セグメントのLVSと記載がありましたが、 2台でLVS構成構築可否なのでしょうか?との質問と見受けられますが。 1台がLVSの旗振り役+REALサーバ、2台目がリアルサーバー。 ミッションクリティカルなら 正直、LVSが2台構成でその配下へREALサーバーが繋がります。 http://www.thinkit.co.jp/free/compare/17/9/ 2の構成の利点、なぜそのような構成にしたいのか利点がわかりません。 LVS+REALサーバ役のサーバーに障害発生した場合どうしますか。 回答により余談になってしまいましたね。(^^;;)

参考URL:
http://www.thinkit.co.jp/free/compare/17/9/
del4thta
質問者

補足

ご回答ありがとうございます。 当方が考えているものは、ご認識通り2台でLVS+REALサーバです。 2台で済ませたいのは単にサーバ数を減らしたいからです。 A[Apache+keepalived(192.168.0.1)]仮想(192.168.0.3) B[Apache(192.168.0.2)] AのkeepalivedがMASTERとなり(vrrpにて仮想を持つ)AとBのApacheにバランシングをしていて、Aのkeepalivedに障害があった際にBのkeepalivedがMASTERとなり、継続してAとBのApacheにバランシングをさせたいのです。上記設定にて別サーバのクライアントからアクセスをすると、AとBのApacheにバランシングされる事、Aのkeepalivedだけを落としてもBのkeepalivedが状態を引き継ぎAとBのApacheにバランシングを継続する事、AをシャットダウンしてもBが全てを引き継ぐ事も確認しています。 問題なのは、クライアントがAの上にいることなのです。クライアントが仮想(192.168.0.3)へのパケットを送信した際、期待する動作としては自身のkeepalivedがそのパケットを受け取り、dstMACを書き換えてAとBにバランシングしてほしいのですが、keepalivedが受け取る前にApacheが受け取ってしまうのか、バランシングをせずに全てAのみで処理されてしまうのです。 ちょっとややこしい話ですが、以下のようなものをイメージして頂ければ。  A     B Client  Client  |   ×  | Apache Apache

すると、全ての回答が全文表示されます。

関連するQ&A