标签：keepalived

先森刚接触运维，当然要学习部署各种集群环境，从最开始的LVS+nginx搭建，到现在Keepalived+lvs+nginx+tomcat搭建，集群的搭建也开始慢慢的得心应手了。不过，前进的道路上总是荆棘遍布。先森的LVS用的是DR模式下的RR轮询算法，这个算法会实现的效果是每个访问会轮流分布到后端服务器1、2、3..上面去，后端服务器相当于在和访问打车轮战。keepalived+lvs+nginx+tomcat拓扑图然而，先森环境部署好之后，要刷新很久之后，才换切换到另一个后端服务器，虽然这也是一定意义上的达到了目标，但心中总还是有个疙瘩。那么为什么会出现这样的问题呢？影响因素经过先森的测试，影响刷新轮询的配置keepalived、Nginx、Tomcat分别有一个，也就是一共有三个配置会影响到。keepalived配置首先，在keepalived的配置文件中，存在一个会话保持时间的配置。vim /etc/keepalived/keepalived.confpersistence_timeout 50    #50秒为默认值会话保持时间这里有个默认为50秒的会话保持时间。如果设置了这一项，那么久会等待50秒后才会切换realserver。如果上面的这样配置已经删除或注释，但问题依旧存在，那么一定就是Nginx和Tomcat的配置问题了。Nginx配置编辑打开到nginx的配置文件：vim /usr/local/nginx/conf/nginx.conf在http模块下面就存在影响刷新轮询的配置：Nginx的配置在nginx.conf中，有一项配置：keepalive_timeout  65;这是nginx默认的连接超时时间，默认为65秒。将数字改为0即可。或者把上图中65那行注释，0那行取消注释就好。Tomcat配置同样的，在Tomcat中也有相关配置。同样编辑打开Tomcat的配置文件：vim /web/soft/tomcat/conf/server.xml找到设置Http访问端口那一段：Tomcat的配置在server.xml中，设置外部访问端口那一段，有个connectionTimeout的设置，即连接超时时间：connectionTimeout="20000"这个值默认是2000毫秒，将其改为10毫秒左右即可。不可以改为0，设置为0表示永不超时。警告总体来说，上面的三个配置都是修改的会话保持时间。但是会话保持时间是不能随意修改的。什么是会话保持呢？会话保持是指在负载均衡器上有一种机制，在作负载均衡的同时，还保证同一用户相关连的访问请求会被分配到同一台服务器上。会话保持有什么作用呢？举例说明一下如果有一个用户访问请求被分配到服务器A，并且在服务器A登录了，并且在很短的时间，这个用户又发出了一个请求，如果没有会话保持功能的话，这个用户的请求很有可能会被分配到服务器B去，这个时候在服务器B上是没有登录的，所以你要重新登录，但是用户并不知道自己的请求被分配到了哪里，用户的感觉就是登录了，怎么又要登录，用户体验很不好。所以，切记的是，修改上面的三项会话保持时长的配置仅仅只是用于环境测试，如果在生产环境，一定要按照需求设置。

先森在模拟搭建LVS+Keepalived的环境，LVS是做负载均衡的，Keepalived是做高可用的。在搭建好之后，先森遇到了一个奇怪的问题，两个负载均衡器MASTER和BACKUP都抢占到了VIP。不过还好的是，实际上同一时间内只有一个VIP在起作用。下面就来谈谈先森的解决过程。解决过程通过不停的查找问题，我发现，只需要关闭备用负载均衡器的防火墙，那么主备服务器都有VIP的情况就会得以解决。由此可以肯定，问题就是出现在了防火墙这里。首先用tcpdump查看一下vrrp的组播情况，这个随便在同网络的任意一台服务器抓包即可：tcpdump vrrp -n    # -n:不把主机的网络地址转换成名字查看下抓包的结果：tcpdump抓包由上图可以看到，192.168.2.79和192.168.2.53两个IP在轮流发送组播信号。而正常的应该是由MASTER服务器发送组播，如果BACKUP收不到MASTER的组播信号了，那么判定MASTER宕机了，BACKUP就会接手VIP。2016年12月01日更新SElinux首先，先确定服务器的SElinux是否设置为关闭。一般都是将其关闭的，在CentOS先森尝试了启用，但是也没有firewall-cmd这个命令，无法添加端口，所以还是将其关闭吧。查看SElinux的状态：getenforce可能的结果有三个：Enforcing         #强制开启Permissive        #宽容模式Disabled          #关闭如果是Enforcing强制模式，就需要关闭：setenforce 0    #设置为宽容模式但这样只在本次生效，重启服务器后将失效。如果要永久关闭，还需要修改配置文件：sed -i 's/=enforcing/=disabled/g' /etc/sysconfig/selinuxiptables防火墙如果将SElinux关闭问题依旧存在，则可能是防火墙将MASTER的VRRP组播给挡住了。首先将防火墙关闭，确定防火墙是否为罪魁祸首。service iptables stop如果关闭防火墙，keepalived问题解决了，那么问题就简单了，我们只需要让VRRP组播其通过防火墙即可。我们只需要在防火墙中增加一条规则即可：-A INPUT -p vrrp -j ACCEPT但是这里有个坑，默认的防火墙中基本是如下配置：# Firewall configuration written by system-config-firewall# Manual customization of this file is not recommended.*filter:INPUT ACCEPT [0:0]:FORWARD ACCEPT [0:0]:OUTPUT ACCEPT [0:0]-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT-A INPUT -p icmp -j ACCEPT-A INPUT -i lo -j ACCEPT-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT-A INPUT -j REJECT --reject-with icmp-host-prohibited-A FORWARD -j REJECT --reject-with icmp-host-prohibitedCOMMIT添加规则一定不要在-A INPUT -j REJECT --reject-with icmp-host-prohibited之后，一定要加在其前面。防火墙配置这时候重启防火墙后查看BACKUP的ip，就会发现VIP已经不在了。再关闭一下MASTER的keepalived，并打开BACKUP的日志，就可以看到正确的内容：tail -f /var/log/messagesKeepalived切换VIP总结如果不是防火墙的原因，那么久应该仔细查看配置文件中的vrrp_sync_group中设置的VRRP组等设置是否相同，当然还有其他的可能性，但大多都是VRRP组播信号的问题。在解决问题的过程中，排除法无疑是最简单粗暴定位问题的方法，要灵活运用。Keepalived是个很好玩也很好用的软件，建议朋友们多研究研究。