浅析国内负载均衡产品现状

【一、引言】

应用交付技术（本文主指负载均衡技术）在银行IT架构中处于极其重要的位置，肩负着保证业务安全、连续、稳定运行的重要使命。 在IT安全自主可控、国产化的整体大环境下，国内一些应用交付厂商在技术和服务上持续发力。 近期，我们挑选了应用交付市场份额相对较大的国内应用交付厂商，并结合数据中心实际应用场景，对其负载均衡产品的功能、性能、运维管理、数据分析等方面进行了全面测试，下面主要在其功能和性能方面的表现情况进行分析阐述。

【二、功能分析】

对于负载均衡产品而言，其组网架构、VIP代理模式、N+M集群、基础功能、高级功能及SSL卸载功能是实际生产环境使用中必备且具有代表性的功能项。 本次测试采用了六十四项测试用例，分别对国内厂商负载均衡产品在上述六大功能项的表现结果进行了比对分析，不同厂商的表现有较大差异。

1. 组网架构

(1) 典型组网模式

负载均衡设备在组网架构中主要有两种常见模式，即串联模式和并联模式。 其中，串联模式主要用于TCP Socket类型的业务，且业务系统对来源IP的访问具有安全审计、安全过滤、数据统计等需求，但系统自身又不具备从TCP Data中提取源IP地址能力的场景。

参与测试的厂商均支持两种组网模式，但在细节上仍存在差异。 需要强调的是，串联结构中的不同VLAN间应当默认安全隔离，否则会对服务器安全性造成隐患。 经测试，部分厂商达到了上述要求，然而某些厂商还需进行额外配置才可实现对不同VLAN的安全隔离，例如： 需要单独进行安全域以及安全级别的定义来实现隔离，或需单独配置ACL进行过滤隔离。 它们的共同缺点是当串联模式中的VLAN较多时，需要配置复杂的安全域或众多的ACL条目配置来满足安全需求。

(2) VIP地址独立性

在VIP功能方面，一般会要求负载均衡产品的VIP/SNAT 地址与设备接口IP地址要相互独立，参与测试的厂商全部支持。 回想三年前某知名国内产品对这一需求的不以为然，可以隐约看到国内产品的整体水平的提升，但仍有一些细节亟待改进和完善。

如在本次测试中某厂商仍需在业务接口下起子接口增加该VIP所在网段的IP地址，VIP才可正常对外提供服务，意味着业务规划包含多少个VIP网段就需要起多少个子接口的配置，无疑极大增加了配置复杂度。 在实际生产环境中负载均衡设备必然承载多种业务，且每一种业务必然会按照不同类型或级别规划不同IP地址。 基础配置如此复杂，定会给自动化运维工具的开发带来更繁复的逻辑判断和处理，因此，希望国内厂商设备在基础配置方面能够更加简洁、规范。

2. VIP代理模式

负载均衡设备的代理模式通常分为四层转发模式和全七层代理模式，两者关键技术区别在于客户端经过负载均衡设备时与后端服务器建立TCP连接机制的不同。

(1) 四层转发模式下客户端与服务器建立TCP连接过程

对于七层以上协议无特殊优化需求的业务系统，会考虑采用四层转发模式以提高转发效率，负载均衡设备在四层转发模式下通常会有更强的新建、并发及吞吐能力。

(2) 七层代理模式下客户端与服务器建立TCP连接过程

在B/S架构的业务系统环境中，要求七层代理模式支持当客户端与负载均衡设备建立TCP三次握手，且收到应用层的请求报文后，负载均衡设备再与后端服务器建立TCP连接交互数据。 该模式在特定场景下对后端服务器是一种更安全的保护。 同时，也能在一定程度上体现厂商对七层协议报文的控制能力，例如可对七层协议内容做更多优化、重写或安全过滤等操作。 该七层代理模式一个典型应用场景为可对七层协议的非法请求或者攻击特征报文，负载均衡设备就就可直接识别并阻断，避免与后端服务器建立不必要的连接消耗不必要的服务资源。 某国内厂商目前不支持上面所述全七层代理模式，其七层代理模式为只要前端TCP三次握手完成后就会和后端服务器建立TCP连接（而不管该连接是否必要），在后面高级功能测试中也验证了在此种代理模式下，设备对七层协议报文的控制能力也相对较弱。

3. N+M集群

在多活数据中心架构中，负载均衡设备会采用多中心部署，多台负载均衡设备要求形成一组集群，这就要求厂商设备支持N+M集群技术，一方面达到设备级的多冗余高可用，另一方面可实现多中心级的安全高可用。 典型的N+M集群部署场景为在大二层架构下同城双中心部署，两个不同的数据中心分别部署两台负载均衡设备，四台设备形成一组N+M集群，根据实际的需求同一组集群内不同设备可承载不同的业务流量。

测试过程中，除去一家仅支持双机主备模式而不支持N+M集群模式的厂商，对其他支持N+M集群模式的国内厂商重点验证了如下关键能力：

(1) 设备是否具有独立的带外MGMT管理口，是否支持独立管理路由表与业务路由表；

(2) 集群心跳是否支持带外MGMT管理口与业务接口双心跳；

(3) 集群内是否支持TCP长连接镜像；

(4) 集群内是否支持会话保持表镜像；

(5) 集群是否支持业务接口流量监测，触发集群内设备切换。

我们重点关注之一的MGMT带外管理口与业务接口在集群内可作为双心跳，是要保证任何链路的抖动都不会影响集群状态（如同城双中心的裸光纤抖动）。 数据中心管理网络与业务网络一般都会是两张独立的物理网络，两张网同时出现故障引起集群抖动的概率将非常低，因此可确保集群状态足够稳定。 集群稳定如此重要，是因为负载均衡设备都会集中运行多种实时交易类业务，每秒都会有上千笔交易发生，一旦集群内发生抖动出现脑裂引起IP地址冲突，恢复起来可能就会是分钟级别的，带来的影响也许就是大量的交易损失或是资金入账延迟、错账等故障，若是核心系统前端负载均衡设备异常，甚至会带来全行业务中断的风险。

经测试仍有厂商无法支持带外管理口与业务口同时做双心跳，无疑在集群的稳定性少了一层更安全的保障。 同时某厂商无法将会话保持表镜像给集群其它设备等。 无论是TCP连接镜像功能、会话保持镜像功能，还是业务接口流量监测功能的要求，其目的都是确保负载均衡产品在出现设备故障或集群内发生设备切换的情况下，仍然能够确保各类业务系统的连续性与稳定性。

4. 负载均衡基础功能

负载均衡设备要实现基本负载均衡能力，有三项能力是必须具备的： 一是负载均衡算法； 二是会话保持功能； 三是对服务器的健康检查方法。 针对这三项基础功能的常用指标进行了测评和分析，没有针对各项功能的种类数目进行横向对比（如负载均衡算法种类数量、健康检查方法数量等）。 所测试的国内厂商对以上基本功能均支持，但重点对比了细节，以便更客观地反映出负载均衡产品的成熟度。

(1) 负载均衡算法

上图所示功能厂商均可支持，在这里重点分析“比率负载均衡算法”机制差异。 比率的负载均衡算法，最初是用在一组服务器集群内服务器之间存在不同性能差异场景，因此按照不同比率在不同的服务器间进行流量分配。 然而，现在使用的更多场景为： 当一个业务系统有新的功能或新的应用架构要上线部署，经常会采用在原有服务器集群中增加含有新功能或新应用架构服务器的方式，并通过比率的算法把总交易量逐量切到新服务器上，待验证新服务器业务功能无问题后，然后通过调整算法将全量交易平均分配到后端所有服务器上，或者再把老服务器平滑下线。

在采用以上比率算法进行连接配备时，不同的分配机制会带来不同的结果。 例如在四台服务器上设置比率100:100:100:1之后，负载均衡设备连接分配原理有如下两种：

第一种分配机制是将第一个连接分配给比率为100的服务器一，接着第二个连接分配给比率为100的服务器二，依次第三个连接分配给比率为100的服务器三，第四个连接分配给比率为1的服务器四，后续的连接将在三台比率为100的服务器间轮询分配，直到该三台服务器分配完100个连接后，接着的下一个连接会再次分配给比率为1的服务器四，依次循环；

第二种分配机制是将前100个连接会先全部先分配给比率为100的服务器一，之后的100个连接全部分配给比率为100的服务器二，依此类推，第301个连接才会到比率为1的服务器四。

显然第一种分配原理更优，如果是第二种原理，比率为100服务器若无法承受瞬时100个连接的压力，将导致该服务对外服务异常。 尽管如此，在测试的厂商中仍有厂商采用的是第二种分配原理。

(2) 会话保持功能

Cookie的会话保持功能在Web应用场景一般都是最佳的选择。 在Cookie的会话保持中常采用Cookie插入方式，即负载均衡设备会在HTTP Respond头部插入Cookie值返回给客户端，客户端接下来的访问将会带上这个cookie值。 然而，该Cookie值会包含后端服务器信息，如服务器真实IP或服务端口等。 经测试仍有厂商不支持对Cookie值采用公有加密算法进行加密，而是通过相关公式反转得出的密文Cookie值。 这意味着对方一旦知道加密公式就可反推出服务器的相关真实信息，如果是在互联网环境中传输对服务器来说就会存在一定的安全隐患。

(3) 健康检查方法

在健康检查方法上，对于多种健康检查方法的组合需求，其中一家厂商仅支持两种组合，无法配置两种以上的健康检查组合。 针对“健康检查探测端口要与服务器对外提供的服务端口不同”这一需求，也仍有厂商不支持，而该需求在实际生产环境多数是为了既能减轻对真实服务端口的探测压力，又能达到反应服务器健康状态的应用场景。

5. 负载均衡高级功能

在高级功能测试中，重点测试了十八项内容，包括管理类和应用类的功能，测试项均是在实际生产环境中遇到的业务需求，或是通过高级功能解决了生产环境中遇到的特定问题。

针对以上高级功能厂商均可满足数据中心应用场景。 这里仅重点讨论“连接数限制”功能细节上的差异，在实际的环境中有部分业务系统平时交易流量相对较小，只有在特定时期才会出现流量突增，如限量理财产品发售，“纪念币发行”或是“双十一抢购”等。 为确保产品顺利销售，同时需要防止瞬间的突发流量将业务系统服务器压垮导，从而致服务器无法对外提供服务。 这种情况一般会提前对该业务系统在负载均衡设备上进行新建或者并发连接数限制。 因此对“连接数限制”功能提出了四种要求：

(1) 可针对VIP的新建和并发进行限制；

(2) 达到连接数限制后，支持返回自定义友好界面提示；

(3) 达到连接数限制后，管理界面VIP需要有状态标识，需要有syslog日志告警；

(4) 针对带有会话保持的客户端，可设置不受连接数限制，可连续访问业务系统。

本次测试的厂商均支持连接数限制，但其中有厂商在连接数达到限制后不支持返回给客户端友好界面提示，还有厂商在连接数达到上限后没有日志告警。

针对有会话保持的客户端可不受连接数限制的特殊功能，同样有厂商不支持。 然而，如果厂商不支持此功能，那么在设置了总连接数限制后，当在没达到总连接数前，已经登陆系统开始做相关交易的客户，一旦在总连接数达到上限后，该客户就会出现访问缓慢或直接被粗暴拒绝掉的情况，如此可能就会影响客户资金交易的完整性。 因此，希望国内厂商在类似功能点的细节处理上，能够进一步改进和完善。

6. SSL卸载功能

在应用交付范围内，一般都会把服务器负载均衡功能与SSL卸载功能区分出来，并且在组网架构中把这两个功能进行解耦，把SSL卸载功能独立采用多台带有SSL硬件芯片的设备处理，此种架构的优点是能够使服务器负载和SSL卸载各自计算资源得到最大利用。 针对数据中心SSL加解密的实际环境，对下图所列功能进行了全面测试验证。

根据结果分析可知，国内已有厂商对SSL功能的支持非常完善，不论是在通用的算法还是基于特定的场景算法上都可灵活配置。 在实际应用中尤其在SSL双向验证过程中，不同场景下对SSL算法种类和加密套件组合顺序的需求也会有所不同，甚至是定制化的需求。

目前，国内厂商在SSL卸载方面已具备较高的水平。 针对国内SSL特殊需求定制化方面，相信无论是在开发效率还是问题解决支持程度上，国内厂商较国外厂商都会具有一定的优势。

【三、性能方面】

在性能方面要求厂商提供了中高端设备型号，分别对四七层的新建连接、并发连接和吞吐设定了可满足实际生产环境需求的固定值进行了测试，对比了设备性能在达到固定值后CPU和内存利用率的表现情况。

以上测试结果的预配条件为： 采用轮询负载均衡算法，不开启会话保持与连接复用，不开启Web缓存和压缩功能，请求页面大小设置为1024Byte的静态页面。

在本次性能测试中没有以验证厂商设备最大性能指标的方式进行测试，而是以高于实际生产环境业务峰值性能指标的五倍作为基准值，在压力达到该基准值后，重点比较了各厂商设备CPU和内存压力情况。

从性能表现结果来看，厂商设备在四七层新建、并发、吞吐方面均表现良好，新建能到达每秒万级以上，并发可达到千万以上，虽然在此期间有厂商CPU、内存会持续在高位（不同厂商的硬件配置存在一定差异），但CPU和内存均能够稳定在一定的数值范围内，在持续高新建、高并发、高吞吐条件下，CPU和内存利用率可持续稳定，无较大抖动发生，在一定程度上能够反映出设备在处理分发四七层流量时的交付能力。

综合测试结果分析可知，国内负载均衡设备厂商在关键能力指标上，如四七层的高新建高并发以及高吞吐上并不存在明显瓶颈，且设备在硬件配置上也均可支持扩展更大的容量需求。

【四、测试环境说明】

本文对各厂商负载均衡产品相关功能及性能的测试分析，主要基于数据中心内实际应用类型和特点制定的测试场景和用例。

1. 测试环境拓扑图

2. 国内厂商设备性能参测要求

【五、结束语】

在金融科技时代，银行IT信息系统持续安全稳定运行是保障业务及时、有效、连续开展的基础。 应用交付技术与应用业务耦合度非常紧密，设备任意一个参数的设定不当，任何一次的故障，业务系统都可能会受到较大的影响。 因此，负载均衡设备能否保持长期的稳态安全运行，保证业务的敏捷交付，对于银行业务而言，是所有设备厂商选择条件的重中之重。

通过本次相对充分的测试与分析，对当前国内负载均衡产品的现状有了更直观的了解和掌握。 本文虽然仅针对其特定功能和性能进行了简要分析和阐述，但结合整体的测评结果可见，国内应用交付厂商在四七层技术领域上一直在持续创新、不断的完善，无论在基础功能还是特殊应用场景下的高级功能上都有了较大的提升，但在一些功能细节和四七层流量的处理机制上仍与国外的优秀厂商存在一些差距。 同时，国内厂商设备在运维管理、告警日志、数据挖掘等方面，尤其是设备运行的稳定性，都需要在真实的生产环境中长期使用才能得以更好的检验和验证。

作者介绍：

王全： 应用交付架构师。 任职民生银行总行信息科技部网络管理中心，负责总行数据中心网络规划、建设、运维等工作，在应用交付/负载均衡技术领域具有十年以上的研究及实践经验。

本文转载自公众号：民生运维， 点击查看原文