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

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

openstack现有的负载均衡解决方案，不管是lbaas plugin仍是octavia，后端都是基于haproxy的，因为haproxy自己的限制，其单任务最高并发不会超过5万，经本人亲测，利用octavia，在openstack云主机上运行haproxy最高达到过3万并发，全部若是要想达到更高基本的并发，就须要从新设计负载均衡的架构了。

废话很少，先上实现架构图：

如上图，利用lvs的dr转发模式把外部请求分发到多个haproxy，而后由haproxy提供4、七层负载均衡服务。借助这种方式咱们就能横向扩展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丰富的四、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环境中，有如下几点须要注意：

一、 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

二、 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功能有任何影响）

三、因为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的方式实。