高可用LB方案

前几天的碰到一个问题，线上的LB服务因为内存问题挂掉了，导致所有的生产环境服务都直接down掉了，因为没有专业的运维，线上环境都是研发直接来管理的，这里有几个问题：

1. 导致内存不停增长，是因为每次切割haproxy的日志的时候，会通过-st的命令重启haproxy，但是因为旧的进程会管理旧的连接直至连接断开才会退出，但是我们用haproxy来代理MQTT这种长连接，所以导致进程一直残留，相当于每天多了一个进程，最终内存不够倒是服务被kill

2. 线上环境服务器的资源使用情况没有监控及报警，就算没有这个问题最后也会有类似的问题产生

3. 架构设计LB没有任何冗余，所以只有LB挂了，那整个服务肯定都会全部失联

 

然后是针对既有的问题做优化

1. 测试切割haproxy日志时不需要重启haproxy也会继续记录日志，那就不需要根据教程讲的必须重启haproxy，这样也不会有服务一直变多的问题

2. 阿里云对ECS有提供监控与报警的方案，目前已经配置每台服务器CPU，内存使用超过一定阈值都会直接钉钉+短信报警，另外对主要的一些服务的进程也做了监控，找不到进程也会直接报警

3. 对目前的架构进行优化，保证LB的高可用

 

通过查找资料，有以下几个方案：

1. haproxy + keepalive 主从配置

如上图，两台服务器分别是101及102，两台服务器上都部署haproxy，配置一样，然后两台都部署keepalive，101作为主，102作为从，此时网关通过虚拟IP 192.168.1.2 的 ARM协议会被101进行解析到101的一个mac地址，之后消息都会被101解析

当101挂掉时，虚拟IP 192.168.1.2 的 ARM协议会被102进行解析到102的一个mac地址，之后消息都会被102解析

以上只有挂掉一个就不会影响LB服务

2. LVS-DR

LVS本身不是高可用的方案而是跟haproxy类型的负载均衡方案，LVS-DR是LVS的一种模式，这种模式仅适用于同一个局域网内，主要的模式是虚拟IP进来的消息进行ARP解析时，所有的服务器都已经配置ARP抑制，只有100这台服务器(调度服务器)会进行相应，他会根据每台服务器的负载情况，将对应服务器的MAC地址进行响应，完成解析之后的消息将会直接通过局域网路由到指定的服务器，不在经过调度器，所以效率非常高，而且这里的101，102我们可以实际使用haproxy服务器替代，相当于做了两层LB，并且有冗余

这时候有一个问题是调度服务器依然是只有一个，所以当调度服务器发生故障，服务依旧会直接挂掉，所以还是需要通过keepalive对调度服务器做主从备份

这个方案跟第一个方案基本思路都是通过keepalive做高可用，对外都是通过vip实现统一的一个ip，但是第二个方案除高可用之外，对负载能力会增加很多

3. 阿里云SLB

阿里云SLB是阿里云提供的现成的高可用LB的服务，之所以必须提到SLB是因为，阿里云之前有提供havip的服务来支持虚拟ip，但是跟客服咨询之后都已经下架，所以目前想在阿里云上使用高可用的LB服务，只有使用他们家的SLB，他们这个其实就是 LVS集群 + keepalive 方案实现