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

题记

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