[高可用]Ubuntu下Haproxy + Keepalived 实现SuperMap iServer高可用负载均衡实现（2）

q9989

题记
　　Haproxy是一个高性能的TCP/HTTP复杂均衡服务器软件，速度快，可靠性高。可以轻松支持几十万的并发连接，而且支持Session。这也是OpenStack的高可用搭建比较推荐的配置组合。
测试
　　上一篇我们已经将基于haproxy+keepalived的iserver负载均衡和高可用搭建完毕，这一篇我们就进行一下故障模拟
　　1、刷新http://10.0.0.200:8090/iserver/manager/services 我们可以看到会来回切换不同的iserver机器，这是实现了负载均衡的功能。
　　因为我们的负载均衡方式为roundrobin，也就是让所有的节点轮流上场，当然，也有source，该方式主要是当集群的节点数量不变，来自某个Ip的用户，会始终被Haproxy分配到固定的一个节点上，这也就解决了session问题。
　　更多blance调度方式参考：

• roundrobin动态 支持权重和在服务器运行时调整，支持慢速启动
  
• static-rr静态 不支持在服务器运行时调整，不支持慢速启动
  
• leastconn 最少连接，只建议使用非常长的会话
  
• source：后端服务器时动态服务器时使用，类似于nginx的iphash
  
• Hash-type：map-based静态 hash码取余 计算ip的hash码除以所有的服务器数，余数得几就放在第几个服务器
  
• Hash-type：consistent 动态  一致性hash hash环
  

　　故障模拟

1、当两个负载均衡节点的keepalived服务都正常，我们可以通过外部ping命令来获得正确的输出结果。


C:\Users\Administrator>ping 10.0.0.200 -t
正在 Ping 10.0.0.200 具有 32 字节的数据:
来自 10.0.0.200 的回复: 字节=32 时间<1ms TTL=64
来自 10.0.0.200 的回复: 字节=32 时间<1ms TTL=64
来自 10.0.0.200 的回复: 字节=32 时间<1ms TTL=64
来自 10.0.0.200 的回复: 字节=32 时间<1ms TTL=64
　　2、当我们讲VIP1的keepalived服务停止掉
　　我们可以看到，该机器的eth0的虚拟IP已经没有了


root@vip1:~# service keepalived stop
* Stopping keepalived keepalived                                                                                               [ OK ]
root@vip1:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:d6:af:8c brd ff:ff:ff:ff:ff:ff
inet 10.0.0.10/24 brd 10.0.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fed6:af8c/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:0c:29:d6:af:96 brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:0c:29:d6:af:a0 brd ff:ff:ff:ff:ff:ff
　　查看ping输出信息

我们可以看到，不到1s中，就能重新ping通，系统已经连接的VIP2的备用节点。


C:\Users\Administrator>ping 10.0.0.200 -t
正在 Ping 10.0.0.200 具有 32 字节的数据:
来自 10.0.0.200 的回复: 字节=32 时间<1ms TTL=64
来自 10.0.0.200 的回复: 字节=32 时间<1ms TTL=64
来自 10.0.0.200 的回复: 字节=32 时间<1ms TTL=64
来自 10.0.0.200 的回复: 字节=32 时间<1ms TTL=64
来自 10.0.0.200 的回复: 字节=32 时间<1ms TTL=64
请求超时。
来自 10.0.0.200 的回复: 字节=32 时间<1ms TTL=64
来自 10.0.0.200 的回复: 字节=32 时间<1ms TTL=64
来自 10.0.0.200 的回复: 字节=32 时间<1ms TTL=64
来自 10.0.0.200 的回复: 字节=32 时间<1ms TTL=64
来自 10.0.0.200 的回复: 字节=32 时间<1ms TTL=64
来自 10.0.0.200 的回复: 字节=32 时间<1ms TTL=64
　　查看VIP2的网络信息

我们看到，虚拟IP已经飘到VIP2机器上了。


root@vip2:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:cc:37:03 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.9/24 brd 10.0.0.255 scope global eth0
valid_lft forever preferred_lft forever
inet 10.0.0.200/32 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fecc:3703/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:0c:29:cc:37:0d brd ff:ff:ff:ff:ff:ff
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:0c:29:cc:37:17 brd ff:ff:ff:ff:ff:ff