半虚拟化的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
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
echo "1">/proc/sys/net/ipv4/conf/all/arp_ignoreecho "2">/proc/sys/net/ipv4/conf/all/arp_announce
arping 10.1.1.13
