半虚拟化的xen下不可能成功配置lvs的DR模式

起这个名字的时候心里还是有些小纠结的。最近两周尽在研究lvs+keepalived实现负载均衡更可用的。无奈环境所限，不能找到实际的四台机器，只能在自己的小破本上，琢磨着虚拟出2+2的高可用环境。又因为小本只有2G内存，感觉不能在VirtualBox下完全虚拟化4台linux，又趁着前一阵子玩xen，于是在一个机器下装了xen。情况还不错，在半虚拟化的xen中跑个机器感觉100M内存就足够了，于是我在半虚拟化中配lvs及keepalived的悲剧之旅就开始了。

如果你也正准备跟我一样 在半虚拟化环境下实验负载平衡高可用，请注意！

先说说lvs+keepalived的2+2架构
推荐几篇文章导读
lvs中文站
keepalived的一篇官方中文手册

简要的说这几篇文章，主要讲了这个意思。
VS/DR模式和VS/TUN模式比较适合构建大规模的集群，这种集群中的每台机器都不用走总路由，可以直接将相应报文发还给客户。

之前我也搭建过VS/NAT模式，所以这次便试试VS/DR。VS/DR包括负载均衡器(Director)和真实服务器(Real Server RS)
假设虚拟IP是VIP=10.1.1.1
配置RS的要点是：

• 给RS配置一个lo:0地址，该地址就是VIP，广播地址也是VIP（不清楚为什么），使得RS可以勉强接受目的地址是VIP的报文。
• 同时一定要关闭RS的arp功能，这样就不会使ARP相应VIP时发生错乱。

配置Director的要点是：

• 不需要给Director配置eth0:0的VIP地址，有keepalived在的话，直接在/etc/keepalived/keepavlied.conf文件中指定VIP地址，然后keepalived -D启动后，可以通过ip add命令查看多出来的VIP地址（在ifconfig下是看不到的）
• 如果配置成功，则应该可以ping通VIP地址

那么为什么客户端访问这样一个所有机器都拥有的VIP仍然可以获得相应而不会错乱呢？
这是因为客户端在发出对VIP的请求时，RS会保持沉默，因为我们之前已经关闭了RS的arp相应。而Director在截获请求后，会在lvs中也就是ipvsadm中查找这个VIP对应的RS地址，把报文中的MAC替换成被重定位的RS的MAC地址。
关键就在这个地方。因为这是发生在数据链路层的事，所以只要MAC地址对了，就一定能发到对应的RS服务器上。反之。如果MAC地址不对，就不能成功。

半虚拟化下不能获得正确MAC！
如果你能ping通VIP，但是却无法正常运行RS上的服务。请先下载软件arping

apt-get install arping

我们使用命令arp -a查看下

root@xen-test0:~# arp -a
? (10.1.1.13) at fe:ff:ff:ff:ff:ff [ether] on eth0
? (10.1.1.14) at fe:ff:ff:ff:ff:ff [ether] on eth0
? (10.1.1.138) at fe:ff:ff:ff:ff:ff [ether] on eth0
? (10.1.1.254) at fe:ff:ff:ff:ff:ff [ether] on eth0

结果很奇怪，另一个虚拟机10.1.1.13的mac地址居然是fe:ff:ff:ff:ff:ff？这说明在xen的半虚拟化下，当使用查询一个虚拟机，比如10.1.1.13的mac地址之时，DomU先是连接到Dom0，Dom0返回的是vifx.0的mac地址，如上所示。

如果关闭Dom0的arp应答功能如何？
我尝试

echo "1">/proc/sys/net/ipv4/conf/all/arp_ignore
echo "2">/proc/sys/net/ipv4/conf/all/arp_announce

然后再进行进行arp请求

arping 10.1.1.13

可惜Dom0仍然会进行arp应答，所以这就造成在解析VIP时，mac地址出错，从而无法成功搭建keepalived


最后附上keepalived.conf的配置文以及realserver停止arp的脚本。均从文首链接中摘录而来。