谈谈VIP漂移那点破事
一直以来都是用nginx的upstream模块做网站最前端的负载均衡，为了防止nginx本身宕机导致网站不能访问，通常都会做两套nginx反向代理，然后用keepalive之类的软件提供VIP。
常见的环境是nginx主节点和从节点各有一个公网IP，一个私有IP，VIP地址也使用公网IP来提供，正常情况下VIP只会在nginx主节点上工作，只有主节点宕机或者网络不可达等情况下，VIP才会漂移到nginx从节点上。如果keepalive配置了非抢占模式，则主节点恢复后，VIP也不会漂移会主节点，而是继续在从节工作。这种配置要求机房网络不做mac地址绑定。
最近做的两套培训系统测试情况如下:
系统一：主从节点做双网卡绑定，都只有一个私有IP，VIP也为私有IP，通过防火墙的NAT转发用户的访问请求。主节点宕机后，VIP可以漂移至从节点，但用户无法访问网站，telnet防火墙公网IP的80端口提示无法连接。
系统二：主从节点各有两张网卡，分别配置一个公网IP和一个私有IP。VIP地址也使用公网IP来提供。
主节点宕机后，VIP可以漂移至从节点，但用户无法ping通VIP，自然网站也就打不开。
于是分别对这两种情况进行排查：
系统二：属于比较常见的配置方案。VIP漂移后无法ping通，第一反应询问机房工作人员，是否相应的设备做了mac地址绑定。得知无绑定策略后继续排查。
发现配置net.ipv4.ip_nonlocal_bind = 1 参数并使其生效后重新测试正常。
系统一：情况有点特殊，按系统二的解决方法尝试无果后，怀疑端口路由器映射上出现问题。于是继续测试VIP漂移，发现VIP漂移到从节点后，防火墙上的arp表中vip对应的mac地址依旧是主节点网卡的mac地址，原来防火墙才是罪魁祸首，坑爹的货。机房使用的防火墙型号华为Quidway Eudemon1000E，据说默认配置下，这个arp地址表自动刷新需要20分钟！
好吧！于是用下面的命名手工刷新后，万事大吉，网站访问也很顺畅，比较郁闷的是当主节点重新抢占VIP后，依然需要手工刷新下，否则防火墙还是把请求转给从节点响应。
# arping -I 网卡地址 -c 3 -s VIP地址 网关地址
后记：
要彻底解决系统一的问题，可以从两方面去着手，首先是考虑去调整防火墙的arp表的自动刷新时间；其次是考虑在从节点上部署一个无限循环的脚本，时时去检测是否抢占到了VIP，若抢占成功，则运行前面的刷新命令，命令成功运行后退出脚本，同时可以用nagios监控该脚本，了解最新的主从切换情况。切记，循环运行一次接受后sleep 1秒，否则会死机的哦！
如果在主节点上也部署类似的脚本，则会对网络带来负担，因而主节点恢复后的刷新手工运行下就好了，如果忘记运行了，从节点依然可以工作，无伤大雅！