大云制造 | 大云软负载均衡BC-SLB-C V1.0发布！

Posted 2021-04-15 苏研大云人

友情提示：全文2000多文字，预计阅读时间6分钟

背 景

随着云计算及大数据技术的迅猛发展，流量和后台复杂度越来越高，企业对负载均衡组件的需求越来越强烈。主流的云服务提供商都在第一时间上线了相应的负载均衡服务。而相关的开源软负载均衡组件经过这么多年发展，已经非常成熟，其在X86架构的先天优势，以其兼容性，丰富度，低成本的特性，已经作为云上服务的首选。如果还是沿用采购负载服务器软硬件的方式，成本，运维，扩展等都是很大的问题。移动云急需要一个高性能软负载均衡方案，来满足内部负载，云化快速部署，灵活配置的需求。

面临的挑战

OpenStack原生支持软负载均衡，其中Lbaasv2作为OpenStack社区的标准，提供了丰富的插件和驱动。但是开源负载均衡插件只能在现有的框架下，提供有限的服务，原生最典型的插件就是Haproxy，其有诸多缺点：

功能上不支持UDP，不支持POP/SMTP等邮件协议，不支持扩展功能，重载配置的时候需要重启进程，不支持HTTP缓存也限制了其提供Web服务的能力

性能上由于其框架的限制，多进程支持不够友好，在大并发，高流量的时候存在瓶颈

原生Haproxy插件不支持高可用，不支持多规格服务，无法动态扩容，缺乏云上相关产品、工具、服务等周边

所以原生的Haproxy更多的是作为一个基于Lbaasv2框架的参考实现存在于组件里，或者满足一些没有自主研发能力，需求不是很严格，但是急需相关软负载均衡服务的云场景。但是真正要提供商业化的负载均衡服务，其可运维能力，监控告警能力，高可用能力等等，都是极其重要的，仅依靠一个开源插件是远达不到要求的。而在OpenStack环境中，基于Lbaasv2框架，参考Haproxy自研Plugin驱动，提供完善的周边工具的方案，成为了云上部署开源负载均衡服务的最佳选择。

我们的方案

经过前期调研和讨论，我们发现LVS在性能上具有得天独厚的优势，但是其只支持四层负载，无法完全满足需求，如用户的HTTP、HTTPS场景，迫切需要提供七层负载均衡的能力。那LVS+Haproxy是否满足需求呢？鉴于上文提到的Haproxy的缺点，我们选择寻找替代方案。而nginx在社区的活跃度，功能完善程度上，远超Haproxy，经过一系列测试，完全可以满足我们的需求，所以一致决定选择采用LVS+Nginx搭配来提供软负载均衡四层加七层的服务。

业务架构

BC-SLB-C 的业务架构图如下，可以提供四层和七层负载均衡服务：

四层采用LVS + Keepalived的方式实现负载均衡，默认采用主备集群模式，可以根据业务需求灵活配置LVS实例数量，比如采取一主多备的集群模式，进一步提升系统的高可用性。

七层采用Nginx实现负载均衡，并根据云计算场景需求进行了个性化配置，添加了很多高级功能和调优配置，可以根据业务需求横向动态扩展Nginx实例数量，提升集群服务性能。

图1 业务架构

灵活部署

BC-SLB-C 可以根据用户选择的规格灵活配置Nginx集群实例数量，在业务高峰时可以动态扩展负载均衡实例数量以满足高并发需求，用户也可以根据需要增加后端云主机实例数量，当需求减少时，可以缩减后端云主机实例以降低成本。

图2 灵活扩展

以上方案经过我们的优化测试，性能并不低于开源负载均衡，而且兼容所有的Lbaasv2接口，配合自主研发的运维监控工具，在技术上，而且架构灵活，支持高可用，已经可以涵盖支持绝大多数商业负载均衡产品的功能。

性能表现

BC-SLB-C 基于开源的驱动性能如何，我们看下对比：

图3 性能对比

带宽上Haproxy只有不到700Mbps，阿里云为1.4Gbps，而BC-SLB-C可以达到2.1Gbps左右，已经远超开源Haproxy，甚至超过阿里云（带宽KB*8/1024）。

QPS上Haproxy只有26084，阿里云在37699左右，而BC-SLB-C通过调优Nginx和内核参数，达到了61044，远远超过了阿里云。

以上图数据由wrk在内网环境测得，由于使用LVS 加Nginx的方案，只要LVS不存在瓶颈，通过对Nginx节点调优或者增加节点，还可以达到更高。

未来思考

OpenStack的组件版本众多，如何在多版本之间提供支持，快速兼容，需要把网络，SDN，接口层都考虑进去提供统一的操作方案。而云上考虑的不仅仅是负载均衡功能、性能，在运维、监控、告警、可配置性等方面，都需要支持并完善。下一步我们计划继续对标主流的厂商如阿里云，提供多规格的负载均衡服务，在系统加速，网络加速，物理机支持等方向进行重点突破。

结语

简历可发至[e-mail]

-End：）

往期精选

1、

2、

3、