负载均衡的原理说明

大家都知道一台服务器的处理能力，主要受限于服务器自身的可扩展硬件能力。所以，在需要处理大量用户请求的时候，通常都会引入负载均衡器，将多台普通服务器组成一个系统，来完成高并发的请求处理任务。

之前负载均衡只能通过DNS来实现，1996年之后，出现了新的网络负载均衡技术。通过设置虚拟服务地址（IP），将位于同一地域（Region）的多台服务器虚拟成一个高性能、高可用的应用服务池；再根据应用指定的方式，将来自客户端的网络请求分发到

服务器池中。网络负载均衡会检查服务器池中后端服务器的健康状态，自动隔离异常状态的后端服务器，从而解决了单台后端服务器的单点问题，同时提高了应用的整体服务能力。

网络负载均衡主要有硬件与软件两种实现方式，主流负载均衡解决方案中，硬件厂商以F5为代表目前市场占有率超过50%，软件主要为NGINX与LVS。但是，无论硬件或软件实现，都逃不出基于四层交互技术的“转发”或基于七层协议的“代理”这两种方式。 四层的转发模式通常性能会更好，但七层的代理模式可以根据更多的信息做到更智能地分发流量。一般大规模应用中，这两种方式会同时存在。

2007年F5提出了ADC（Application delivery controller）的概念为传统的负载均衡器增加了大量的功能，常用的有：SSL卸载、压缩优化和TCP连接优化。NGINX也支持很多ADC的特性，但F5的中高端型号会通过硬件加速卡来实现SSL卸载、压缩优化这一类CPU密集型的操作，从而可以提供更好的性能。

F5推出ADC以后，各种各样的功能有很多，但其实我们最常用的也就几种。这里我也简单的总结了一下，并和LVS、Nginx对比了一下。

SSL卸载和压缩优化，主要是将CPU密集型的加解密和压缩操作移到负载均衡器上进行；TCP连接优化主要指的是用户和负载均衡器短连接的同时，负载均衡器和后端服务器建立长连接。

不过我们本次主要介绍四层负载均衡，所以这些高级ADC功能不会涉及到。

F5的硬件负载均衡产品又分单机Big IP系列和集群VISRION系列，都是X86架构，配合自研的TMOS（Traffic Management Operating System），再加上硬件加速卡（Cavium提供）处理SSL和压缩等CPU密集型操作。

L4 CPS：四层每秒新建连接数。测试的时候一般采用TCP短连接，每次请求128字节。体现CPU性能，最重要的性能指标，没有之一。

L4最大并发连接数：体现内存大小

L7 RPS：七层每秒请求数。测试时每连接10个128字节HTTP请求。主要体现HTTP协议栈性能

这些性能指标实际上就是一个负载均衡器最关键的指标了。大家如有采购硬件负载均衡器一定要看这个。

有很多小牌子的硬件负载均衡器经常不标注L4 CPS，只是笼统地说10G负载均衡，其实差别很大的。

硬件负载均衡在功能、易用性和可扩展性上都做得不错，但是也有不少缺点。从商业角度来说，硬件负载均衡产品过于昂贵，高端产品动辄五十万甚至数百万的价格对于用户是几乎不可承受的负担。

从使用角度来说，硬件负载均衡是黑盒，有BUG需要联系厂商等待解决，时间不可控、新特性迭代缓慢且需资深人员维护升级，也是变相增加昂贵的人力成本。

相信除了很多不差钱的公司，大家还是用软件负载均衡比较多。

软件四层负载均衡最常见的就是LVS了。

LVS最常用的有NAT、DR以及新的FULL NAT模式。上图比较了几种常见转发模式的优缺点。

我们认为LVS的每种转发模式都有其优点和缺点，但最大的问题还是其复杂性。

我第一次看到这三种转发方式、还有F5的单臂模式、双臂模式都会有云里雾里的感觉。

雪上加霜的是咱们还需要考虑LVS的性能扩展和容灾方法，这使得整个方案更加的复杂。

常见的有基于Keepalived的主备方式和ECMP两种。Keepalived主备模式设备利用率低；不能横向扩展；VRRP协议，有脑裂的风险。

而ECMP的方式需要了解动态路由协议，LVS和交换机均需要较复杂配置；交换机的HASH算法一般比较简单，增加删除节点会造成HASH重分布，可能导致当前TCP连接全部中断；部分交换机的ECMP在处理分片包时会有Bug，说起来心中满满的都是血泪呀。

如图：UCloud Vortex负载均衡器的设计理念

用户使用负载均衡器最重要的需求是“High Availability”和“Scalability”，Vortex的架构设计重心就是满足用户需求，提供极致的“可靠性”和“可收缩性”，而在这两者之间我们又把“可靠性”放在更重要的位置。

值得一提的是今年3月举办的第十三届网络系统设计与实现USENIX研讨会（NSDI '16）上， 来自谷歌、加州大学洛杉矶分校、SpaceX公司的工程师们分享了《Maglev：快速、可靠的软件网络负载均衡器》，介绍了从2008年开始在生产环境投入使用的软件负载均衡器。其设计理念和我们非常相似，同样是ECMP + 一致性哈希；同样是Kernel Bypass模式；单机性能也和我们的Vortex非常接近。

关于Vortex的High Availability实现

四层负载均衡器的主要功能是将收到的数据包转发给不同的后端服务器，但必须保证将五元组相同的数据包发送到同一台后端服务器，否则后端服务器将无法正确处理该数据包。

以常见的HTTP连接为例，如果报文没有被发送到同一台后端服务器，操作系统的TCP协议栈无法找到对应的TCP连接或者是验证TCP序列号错误将会无声无息的丢弃报文，发送端不会得到任何的通知。如果应用层没有超时机制的话，服务将会长期不可用。

Vortex的可靠性设计面临的最大问题就是如何在任何情况下避免该情况发生。Vortex通过ECMP集群和一致性哈希来实现极致程度的可靠性。

首先，我们来考察一下负载均衡服务器变化场景。 这种场景下，可能由于负载均衡服务器故障被动触发，也可能由于运维需要主动增加或者减少负载均衡服务器。

此时交换机会通过动态路由协议检测负载均衡服务器集群的变化，但除思科的某些型号外大多数交换机都采用简单的取模算法，导致大多数数据包被发送到不同的负载均衡服务器。

Vortex服务器的一致性哈希算法能够保证即使是不同的Vortex服务器收到了数据包，仍然能够将该数据包转发到同一台后端服务器，从而保证客户应用对此类变化无感知，业务不受任何影响。

这种场景下，如果负载均衡器是LVS且采用RR (Round Robin)算法的话，该数据包会被送到错误的后端服务器，且上层应用无法得到任何通知。

如果LVS配置了SH(Source Hash)算法的话，该数据包会被送到正确的后端服务器，上层应用对此类变化无感知，业务不受任何影响；

如果负载均衡器是NGINX的话，该数据包会被TCP协议栈无声无息地丢弃，上层应用不会得到任何通知。

其次，来考察后端服务器变化的场景。

这种场景下，可能由于后端服务器故障由健康检查机制检查出来，也可能由于运维需要主动增加或者减少后端服务器。

此时，Vortex服务器会通过连接追踪机制保证当前活动连接的数据包被送往之前选择的服务器，而所有新建连接则会在变化后的服务器集群中进行负载分担。

同时，Vortex一致性哈希算法能保证大部分新建连接与后端服务器的映射关系保持不变，只有最少数量的映射关系发生变化，从而最大限度地减小了对客户端到端的应用层面的影响。

这种场景下，如果负载均衡器是LVS且SH算法的话，大部分新建连接与后端服务器的映射关系会发生变化。某些应用，例如缓存服务器，如果发生映射关系的突变，将造成

大量的cache miss，从而需要从数据源重新读取内容，由此导致性能的大幅下降。而NGINX在该场景下如果配置了一致性哈希的话可以达到和Vortex一样的效果。

最后，让我们来看一下负载均衡服务器和后端服务器集群同时变化的场景。在这种场景下，Vortex能够保证大多数活动连接不受影响，少数活动连接被送往错误的后端服务器且上层应用不会得到任何通知。并且大多数新建连接与后端服务器的映射关系保持不变，只有最少数量的映射关系发生变化。

如果负载均衡器是LVS且SH算法的话几乎所有活动连接都会被送往错误的后端服务器且上层应用不会得到任何通知。大多数新建连接与后端服务器的映射关系同样也会发生变化。

如果是NGINX的话因为交换机将数据包送往不同的NGINX服务器，几乎所有数据包会被无声无息的丢弃，上层应用不会得到任何通知。

可收缩性的设计是基于ECMP集群的Scaling Out设计

Vortex采用动态路由的方式通过路由器ECMP（Equal-cost multi-path routing）来实现Vortex集群的负载均衡。

一般路由机支持至少16或32路ECMP集群，特殊的SDN交换机支持多达256路ECMP集群。而一致性哈希的使用是的ECMP集群的变化对上层应用基本无感知，用户业务不受影响。

虽然ECMP提供了良好的Scaling Out的能力，但是考虑到网络设备的价格仍然希望单机性能够尽可能的强。例如，转发能力最好是能够达到10G甚至40G的线速，同时能够支持尽可能高的每秒新建连接数。

内核不是解决方案，而是问题所在！

从上图可以看到随着高速网络的发展64字节小包线速的要求越来越高，对10G网络来说平均67ns，对40G网络来说只有17ns。而于此同时CPU、内存的速度提升却没有那么多。

以2G主频的CPU为例，每次命中L3缓存的读取操作需要约40个CPU周期，而一旦没有命中缓存从主存读取则需要140个CPU周期。

为了达到线速就必须采用多核并发处理、批量数据包处理的方式来摊销单个数据包处理所需要的CPU周期数。此外，即使采用上述方式，如果没有得到充分的优化，发生多次cache miss或者是memory copy都无法达到10G线速的目标。

像NGINX这样的代理模式，转发程序因为需要TCP协议栈的处理以及至少一次内存复制性能要远低于LVS。

而LVS又因为通用Kernel的限制，会考虑节省内存等设计策略，而不会向Vortex一样在一开始就特别注重转发性能。

例如LVS缺省的连接追踪HASH表大小为4K，而Vortex直接使用了50%以上的内存作为连接追踪表。Vortex通过DPDK提供函数库充分利用CPU和网卡的能力从而达到了单机10G线速的转发性能。

•用户空间驱动，完全Zero-Copy•采用批处理摊销单个报文处理的成本

•充分利用硬件特性

•Intel DataDirect I/O Technology (Intel DDIO)

•NUMA

•Huge Pages，Cache Alignment，Memory channel use

Vortex直接采用多队列10G网卡，通过RSS直接将网卡队列和CPU Core绑定，消除线程的上下文切换带来的开销。Vortex线程间采用高并发无锁的消息队列通信。

除此之外，完全不共享状态从而保证转发线程之间不会互相影响。Vortex在设计时尽可能的减少指针的使用、采用连续内存数据结构来降低cache miss。

通过这样一系列精心设计的优化措施，最终Vortex的单机性能远超LVS，甚至超过了Google Maglev的水平。

LVS支持四种转发模式：NAT、DR、TUNNEL和FULLNAT，其实各有利弊。

Vortex在设计之初就对四种模式做了评估，最后发现在虚拟化的环境下DR方式在各方面比较平衡，并且符合我们追求极致性能的理念。

DR方式最大的优点是绝佳的性能，只有request需要负载均衡器处理，response可以直接从后端服务器返回客户机，不论是吞吐还是延时都是最好的分发方式。

其次，DR方式不像NAT模式需要复杂的路由设置，而且不像NAT模式当client和后端服务器处于同一个子网就无法正常工作。DR的这个特性使他特别合适作为内网负载均衡。

此外，不像FULLNAT一样需要先修改源IP再使用 TOA 传递源地址，还得在负载均衡器和后端服务器上都编译非主线的Kernel Module，DR可以KISS（Keep It Simple, Stupid）地将源地址传递给后端服务器。最后，虚拟化环境中已经采用Overlay虚拟网络了，所以TUNNEL的方式变得完全多余。而DR方式最大的缺

点：需要LB和后端服务器在同一个二层网络，而这在UCloud的虚拟化网络中完全不是问题。

主流的SDN方案追求的正是虚拟化的大二层网络带来的无缝迁移体验，且早已采用各种优化手段（例如ARP代理）来优化大二层虚拟网络。

通过采用Vortex作为UCloud负载均衡产品ULB的4层转发核心引擎，通过一致性Hash算法的引入，并结合ECMP与DPDK的的服务架构，解决了利用commodity server实现high availability + high scalability的高性能软件负载均衡集群的课题。

最后，Vortex实现了在单台通用高性价比1U服务器上达到了10G BPS；14M PPS（64字节线速）；200K CSP；30M并发连接数的性能。Vortex能够为UCloud的客户在方便、易用的同时提供单个IP支持最大120G BPS；150M PPS；3M CPS；100M并发连接数。