基于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的方式实。