基于openstack搭建百万级并发负载均衡器的解决方案

最近，喜欢研究一些国外技术大咖们的文章，而这篇文章是基于openstack负载均衡器的解决方案，做的一些总结~希望能够给小伙伴带来一些灵感或者帮助。

openstack现有的负载均衡解决方案，无论是lbaas plugin还是octavia，后端都是基于haproxy的，由于haproxy本身的限制，其单任务最高并发不会超过5万，经本人亲测，利用octavia，在openstack云主机上运行haproxy最高达到过3万并发，所有如果要想达到更高基本的并发，就需要重新设计负载均衡的架构了。

废话不多，先上实现架构图：

如上图，利用lvs的dr转发模式把外部请求分发到多个haproxy，然后由haproxy提供四、七层负载均衡服务。借助这种方式我们就能横向扩展haproxy集群了，整个集群的能力最终由LVS决定，由于lvs特殊的流量转发的处理方式，所以其性能我们完全没必要担心（后面会有解释）。

【01 LVS】

Linux Virtual Server是一个由章文嵩博士发起的一个开源项目，它的官方网站是 http://www.linuxvirtualserver.org现在 LVS 已经是 Linux 内核标准的一部分。LVS能提供高性能的四层负载均衡功能。

LVS有三种转发方式：DR、NAT、TUN，其中DR模式下LVS仅处理二层包头，LVS仅作为访问入口，不作为网关，且后端返回流量不需要进过LVS，因此，LVS对于大流量的转发有很高的处理性能。这次我们借助LVS的DR转发模式提供高速转发功能，在结合haproxy丰富的4、7层功能，来达到我们的需求。

【02 Keepalived】

Keepalived顾名思义keepalilved是实现多机热备的软件，LVS作为负载均衡集群的访问入口，自然要考虑到单点故障的问题，keepaived+lvs的模式是目前业内的首选解决方案，当前端接收请求的lvs虚机出现健康问题时，keepalived会迅速转移VIP到健康的LVS虚机上，保证整个业务不间断。

另外Keepalived不仅能监控前端lvs的健康状况，还能监控后端haproxy集群每台haproxy虚机的健康状况，实时剔除不健康的虚机，并发出报警。

【03 VIP】

整个集群对外的IP，VIP分布在haproxy集群的每台机器及LVS虚机上（只能有一台LVS虚机拥有VIP），LVS上的VIP作为请求的目的IP，haproxy上的VIP作为应答的原IP。配置VIP有很多注意事项，我后面会给出一些配置链接作为参考。

【04 RIP】

haproxy虚机的真实IP，用于haproxy集群内部通讯，接收lvs分发过来的流量，及管理虚机的IP。

【05 Haproxy】

这个就不做介绍了，凡是在openstack上捣鼓负载均衡的小伙伴们对它应该有了深入的了解了。

参考链接：

LVS相关：

http://www.cnblogs.com/liwei0526vip/p/6370103.html

http://www.cnblogs.com/czh-liyu/archive/2011/11/29/2267963.html

http://www.cnblogs.com/danbo/p/4609202.html

keepalived相关：

http://freeloda.blog.51cto.com/2033581/1280962

http://www.cnblogs.com/edisonchou/p/4281978.html

http://blog.csdn.net/xyang81/article/details/52554398

更详细的资料，小伙伴们就需要自己在网上找了，自己动手试着搭建一套，能对上面架构有更深刻的理解。

注意！！！（在小伙伴们迫不及待想验证这个架构时一定要先阅读这儿）

参考链接的配置是在正常物理机上的配置，但在openstack环境中，有以下几点需要注意：

1、 openstack默认开启了防arp欺骗（这个会过滤掉源IP和目的IP为VIP的数据包），且在ovs流表和iptables规则中均有防arp欺骗的规则，在配置文件中关闭防arp欺骗，也只是去掉了ovs流表的规则，iptables中的规则依然存在。正确的解决方案是在配置集群之前要为每个haproxy虚拟机的port添加allowed_address_pairs。添加方法：neutron port-update--allowed-address-pair ip_address=VIP

2、 openstack会利用iptables规则检查非法的tcp连接（即：请求和应答不在同一端口上的连接（有没有一种它就是故意针对lvs dr转发模式的感觉）），这里解决方案给出两种：

2.1如果仅是在验证阶段，改变下面三个内核参数：

net.bridge.bridge-nf-call-ip6tables = 0

net.bridge.bridge-nf-call-iptables = 0

net.bridge.bridge-nf-call-arptables = 0

2.2如果小伙伴觉得方案可行，想要实现代码时：

修改neutron代码：neutron/agent/linux/iptables_firewall.py，

需要注释掉625行（仅此一行，小伙伴们大可放心，不会对neutron功能有任何影响）

3、由于VIP是我们手动设置上的，在neutron数据库中没有记录，neutron为后续虚拟机分配IP时可能会重复，因此我们要先创建一个port占用VIP，创建方法：

neutron port-create--fixed-ip ip_address=VIP

最后给出实现该方案的编码建议：

依然利用octavia的架构，octavia-api不变。添加octavia.amphora.drivers、octavia.compute.drivers和octavia.network.drivers，可根据用户创建负载均衡时选择的最大连接数决定启动多少haproxy虚机。

另，还可实现octavia的多provider，如果用户要求并发数不多，后端可用namespace，如果用户要求稍大并发可用octavia的默认方法用单个虚拟机haproxy实现，如果要求大并发就用lvs+haproxy的方式实。