未必是这样的。VIP和RIP不一定是一个网段的。
我们可以手册中的 通过直接路由实现虚拟服务器（VS/DR）的图片。负载调度器只要有一个网口和真实服务器是通过不分段的网络连接起来就可以。真实服务器可以通过自己的路由器将响应报文发送给客户。
另一个问题,很多人都遇到过,为了节约服务器,keepalived主备上都有realserver, 最后发现主备两台lvs不正常,负载很高
下面来分析一下为什么.
由于keepalived 的ipvsadm 主备都运行的,只不过备没有得到vip
问题来了,如果一个用户到主的vip上被分到备上的realserver ,因为备上的ipvsadm也在工作,如果备上的这个用户又被备的keepalievd 分到主上的realserver上,这样会引起死循环.
以下是网上找的,另一个网友分析的:
配置的输出如下，可以见到有一个地方不一样，就是显示有个地方是 Local。
# ipvsadm -L -n
# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
FWM 6 rr
-> 192.168.1.233:3306 Local 1 0 0
-> 192.168.1.213:3306 Route 1 0 0
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
FWM 6 rr
-> 192.168.1.233:3306 Local 1 0 0
-> 192.168.1.213:3306 Route 1 0 0
二台机器上的配置都是这样(^-^上面其实有小修改)，在这种架构中，我只要停止我的备份的 keepalived ，就能正常的工作，不然一定有其中一台数据库连接到最后就中断停止在那个地方不动了。通过抓包，大量包被不断的转发来转发去。
详细分析：
客户端发送连接的请求到 VIP 的指定的端口
当前的 director 会选择二个 realserver 来转发请求,会传送数据给 localnode 的本机网卡或者备份的机器上指定的那个 MAC 的 eth0 (同时他也做为 realserver) . 正常的 LVS ，这些数据包会被监听这个 VIP 的程序接收。
如果数据包是发送给备份的 director 服务器的 eth0 接口。它会不能正常的被监听指定端口的程序所接收，因为数据包会首先先经过 ip_vs()。
这时，有 50% 的机会，这个包被转发给 。这时会生成标准的回应数据包给客户端。因为能正常的回应客户端，这时 LVS 的功能是正常的。我们想所有的包都直接给监听程序来处理。并不想直接通过 ip_vs() 来转发。
这时还有 50% 的数据包会直接在次转给主 LVS 的 eth0/VIP。
我们不想数据包从备份的 LVS 在次转回去给主 LVS 这样会形成 。
所以我们要让 eth0 上发到给 VIP 的包， 只要不是其它 LVS 发的，才使用 ip_vs() 来处理。
客户端发送连接的请求到 VIP 的指定的端口
当前的 director 会选择二个 realserver 来转发请求,会传送数据给 localnode 的本机网卡或者备份的机器上指定的那个 MAC 的 eth0 (同时他也做为 realserver) . 正常的 LVS ，这些数据包会被监听这个 VIP 的程序接收。
如果数据包是发送给备份的 director 服务器的 eth0 接口。它会不能正常的被监听指定端口的程序所接收，因为数据包会首先先经过 ip_vs()。
这时，有 50% 的机会，这个包被转发给 。这时会生成标准的回应数据包给客户端。因为能正常的回应客户端，这时 LVS 的功能是正常的。我们想所有的包都直接给监听程序来处理。并不想直接通过 ip_vs() 来转发。
这时还有 50% 的数据包会直接在次转给主 LVS 的 eth0/VIP。
我们不想数据包从备份的 LVS 在次转回去给主 LVS 这样会形成 。
所以我们要让 eth0 上发到给 VIP 的包， 只要不是其它 LVS 发的，才使用 ip_vs() 来处理。
简单来讲：当客户端发送数据包给 VIP 。比如我们的 Director1 (Master 主)这个接口正在工作，这时 LVS 能接收到这个包，然后根据 keepalived 的配置进行 load balance 。这时 Director1 会使用 LVS-DR 的功能给包路由给自己或者 Director2 (Backup)。
这时有个问题，在这个例子中因为我们使用了 keepalived 。这时 Director2 这台是一台 VIP 的备份服务器。这时 keepalived 默认会立即启动使用 ipvsadm 的规则来配置这台服务器怎么样做备份的处理.来使得更快的故障转移。所以这时这些规则这台备份的 Director2 主机都会存在。
这就有问题了。当从 Director1 (Master 主)，比如使用 rr 。会转发大约 50% 的包从 Director1 到 Director2 (Backup)的 3306 的端口。这时因为 Director2 因为这些 LVS-DR 的配置规则会接着给这些包，在做一次 load balance 。又发回去给 Director1，这时会产生一个死的循环。
随着时间的推移，不但不能正常的处理连接，您的服务器也会崩溃，在他们中间或后端不断的反复连接。
解决方案：给进入 eth0 的包打包 mark 的标记，当数据包是发给 VIP:80 并且 MAC 不其它 LVS 服务器的话. 才做个 mark ，这样才会对指定的 fwmark 进行 loadbalance 放入到 LVS 中处理。只要数据包是从任意其它的 MAC 地址(非 LVS 的转发)会被发往 VIP:port， 会不在进行 loadbalanced 而是直接转给后面监听的 demon 程序进行应用的处理。实际就是我们使用 iptables 来对进入的流量设置 MARK.然后配置 keepalived 只处理有 MARK 过的流量。不在使用以前绑定 VIP 和端口。
iptables 的配置如下：
同时服务于 LVS-DR，又要做为数据库的后端。所以我们要注意，只接收一个 director 的数据包。
这时我们在 Director1 中设置($MAC_Director2 是指我在 Director1 上所能见到从 Director2 发过来包的 MAC 地址) ：
iptables -t mangle -I PREROUTING -d $VIP -p tcp -m tcp --dport $VPORT -m mac ! --mac-source $MAC_Director2 -j MARK --set-mark 0x3
并在备份的 keepalived 的服务器 Director2 中设置：
iptables -t mangle -I PREROUTING -d $VIP -p tcp -m tcp --dport $VPORT -m mac ! --mac-source $MAC_Director1 -j MARK --set-mark 0x4
接着在 keepalived 中分别配置这二个。
Director1: virtual_server fwmark 3 {
Director2: virtual_server fwmark 4 {
Director1: virtual_server fwmark 3 {
Director2: virtual_server fwmark 4 {
其实这个的完整配置象如下：
keepalived 来根据 MARK 来配置的方法
本文原始链接： http://www.jbxue.com/article/1413.html