从Google Maglev到UCloud Vortex，如何造一个牛逼的负载均衡？

Maglev是谷歌为本身的数据中心研发的解决方案，并于2008开始用于生产环境。在第十三届网络系统设计与实现USENIX研讨会（NSDI ‘16）上， 来自谷歌、加州大学洛杉矶分校、SpaceX公司的工程师们分享了这一商用服务器负载均衡器Maglev的详细信息。Maglev安装后不须要预热5秒内就能应付每秒100万次请求使人惊叹不已。在谷歌的性能基准测试中，Maglev实例运行在一个8核CPU下，网络吞吐率上限为12M PPS(数据包每秒)，若是Maglev使用Linux内核网络堆栈则速度会小于4M PPS。

无独有偶，国内云服务商UCloud进一步迭代了负载均衡产品——Vortex，成功地提高了单机性能。在技术实现上，UCloud Vortex与Google Maglev颇为类似。以一台普通性价比的x86 1U服务器为例，Vortex能够实现吞吐量达14M PPS(10G, 64字节线速)，新建链接200k CPS以上，并发链接数达到3000万、10G线速的转发。在本文中，UCloud网络研发团队分享UCloud Vortex的具体实现。

什么是负载均衡

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

最先的负载均衡技术是经过DNS来实现的，将多台服务器配置为相同的域名，使不一样客户端在进行域名解析时，从这一组服务器中的请求随机分发到不一样的服务器地址，从而达到负载均衡的目的。

图：多层次负载均衡

但在使用DNS均衡负载时，因为DNS数据刷新的延迟问题，没法确保用户请求的彻底均衡。并且，一旦其中某台服务器出现故障，即便修改了DNS配置，仍然须要等到新的配置生效后，故障服务器才不会被用户访问到。目前，DNS负载均衡仍在大量使用，但多用于实现“多地就近接入”的应用场景。

1996年以后，出现了新的网络负载均衡技术。经过设置虚拟服务地址（IP），将位于同一地域（Region）的多台服务器虚拟成一个高性能、高可用的应用服务池；再根据应用指定的方式，未来自客户端的网络请求分发到服务器池中。网络负载均衡会检查服务器池中后端服务器的健康状态，自动隔离异常状态的后端服务器，从而解决了单台后端服务器的单点问题，同时提升了应用的总体服务能力。

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

为何要研发Vortex?

在研发UCloud Vortex以前，咱们一直在思考是否是在重造轮子。这要求咱们站在2016年这个时间点上去分析现状，深刻思考各类负载均衡实现的优、劣势。负载均衡大体可分为以F五、Netscaler为表明的硬件负载均衡和以 LVS 为表明的软件负载均衡。

不妨，咱们先以F5为表明来看硬件负载均衡的优劣势。

F5的硬件负载均衡产品又分单机和集群系列。12250v是单机中的高端版本，能支撑每秒150万新建链接数，8000万并发链接数，84G数据吞吐量。从F5的datasheet中，咱们推算出并发链接数受限于内存，高端的12250v和次一级的11050内存相差4倍，并发链接数也是4：1的关系，后者大概为2400万；根据UCloud自身云平台的运营经验，150万新建链接在特定大压力场景下是很是危险的，颇有可能被击穿；而84G的吞吐量，通常来讲是够用的，数据中心南北向的流量有限。

图：F5 12250v

集群系列中VIPRION 4800阵列是旗舰产品，每一个阵列支持最多8个Blade，每一个Blade提供每秒290万新建链接数，1.8亿并发链接数以及140G数据吞吐量。按线性比例计算，一个顶配的VIPRION 4800阵列能知足绝大多数海量互联网应用的业务需求了。其中，须要指出的是单片Blade都是用了普通X86架构，2块Intel 12核CPU 配256G内存，这个转变使其支撑量产生了飞越，也进一步证明并发链接数与内存呈相关性。

从技术角度来讲，咱们认为硬件负载均衡最终的路线是回到X86服务器架构，经过横向扩展来提高性能。这里软硬件的区分已经再也不存在，由于若是F5能作到，具有深刻研发能力的技术公司如Google、Facebook也能逼近甚至超越。

从商业角度来讲，硬件负载均衡产品过于昂贵，高端产品动辄五十万甚至数百万的价格对于用户是几乎不可承受的负担。在文章末尾，咱们提供了一份根据网上数据整理后的比较内容，主要来源为Google搜索：F5 Networks - Price List - January 11th, 2014 - Amended for the WSCA-NASPO JP14001 Request for Proposal，供你们参考。

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

再来看（开源）软件负载均衡表明LVS. LVS做为目前互联网时代最知名的负载均衡软件，在性能与成本方面结合地很好，阿里云的SLB产品也经过LVS实现，所以也继承了LVS的优势和缺点。LVS最经常使用的有NAT、DR以及新的FULL NAT模式。如下是各模式详细的优缺点比较：

图:NAT、DR和FULL NAT模式 优缺点对比

咱们认为LVS的每种模式都有较大的缺点，但这并非最为致命的。最为致命的是LVS本质上是一个工做于Linux内核层的负载均衡器，它的上限取决于Linux内核的网络性能，但Linux内核的网络路径过长致使了大量开销，使得LVS单机性能较低。所以，Google于2016年3月最新公布的负载均衡Maglev实现彻底绕过了Linux内核（Kernel Bypass），也就是说Google已经采用了与LVS不一样的技术思路。

LVS在运维层面还要考虑容灾的问题，大多使用Keepalived完成主备模式的容灾。有3个主要缺点：

1. 主备模式利用率低；

2. 不能横向平行扩展；

3. VRRP协议存在脑裂Split Brain的风险。Split Brain从逻辑角度来讲是无解的，除非更换架构。

也有少数公司经过ECMP等价路由协议搭配LVS来避免Keepalived的缺陷。综合来看，ECMP有几个问题：

1. 须要了解动态路由协议，LVS和交换机均须要复杂配置；

2. 交换机的HASH算法通常比较简单，增长删除节点会形成HASH重分布，可能致使当前TCP链接所有中断；

3. 部分交换机（华为6810）的ECMP在处理分片包时会有BUG。

这些问题均在生产环境下，须要使用者有资深的运维专家、网络专家确保运营结果。

理性的剖析下，咱们发现没有任何的负载均衡实如今价格、性能、部署难度、运维人力成本各方面能达到最优，因此Vortex必然不是在重造轮子而是在推进这个领域的革新: Vortex必须不能像LVS那样被Linux内核限制住性能，Vortex也不能像F5那么的昂贵。

Vortex负载均衡器的设计理念

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

1. 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 一致性哈希算法的计算公式

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

图：负载均衡服务器和后端服务器集群同时变化的场景

若是负载均衡器是LVS且SH算法的话几乎全部活动链接都会被送往错误的后端服务器且上层应用不会获得任何通知（图四）。大多数新建链接与后端服务器的映射关系一样也会发生变化。若是是NGINX的话由于交换机将数据包送往不一样的NGINX服务器，几乎全部数据包会被无声无息的丢弃，上层应用不会获得任何通知。

图：不一样变化带来的影响对比

2. Vortex的Scalability实现

2.1 基于ECMP集群的Scaling Out设计

Vortex采用动态路由的方式经过路由器ECMP（Equal-cost multi-path routing）来实现Vortex集群的负载均衡。通常路由机支持至少16或32路ECMP集群，特殊的SDN交换机支持多达256路ECMP集群。而一致性哈希的使用是的ECMP集群的变化对上层应用基本无感知，用户业务不受影响。

2.2 基于DPDK的Scaling Up设计

虽然ECMP提供了良好的Scaling Out的能力，可是考虑到网络设备的价格仍然但愿单机性可以尽量的强。例如，转发能力最好是可以达到10G甚至40G的线速，同时可以支持尽量高的每秒新建链接数。Vortex利用DPDK提供的高性能用户空间 (user space) 网卡驱动、高效无锁数据结构成功的将单机性能提高到转发14M PPS（10G, 64字节线速），新建链接200K CPS以上。

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

图：DPDK性能数据图

从上图能够看到随着高速网络的发展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%以上的内存做为链接追踪表。

下图简明地比较了三者在实现上的差别：

图：LVS、Google Maglev和UCloud Vortex 实现差别

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。单机性能横向测试比较，参见下图：

图：单机性能横向测试比较

基于DR转发方式

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的核心引擎，经过一致性哈希算法的引入，并结合ECMP与DPDK的的服务架构，解决了利用commodity server实现 high availability + high scalability 的高性能软件负载均衡集群的课题。

此外，本次ULB的更新还对原有功能进行了扩展，从新调整了用户交互并增长了数10个新的feature，如优化了批量管理场景下的操做效率， SSL证书提升为基本资源对象管理。将来，Vortex将以ULB为产品形态输出更多的创新理念。

附录：

按7折折扣并考虑每一年25%的降价幅度，上文提到的一套12250v价格约87万人民币（生产环境中须要主备2台），一套包含一个机柜与4刀片的VIPRION 4800价格约为188万人民币。

做者介绍：

Y3(俞圆圆)，UCloud基础云计算研发中心总监，负责超大规模的虚拟网络及下一代NFV产品的架构设计和研发。在大规模、企业级分布式系统、面向服务架构、TCP/IP协议栈、数据中心网络、云计算平台的研发方面积累了大量的实战经验。曾经分别供职于Microsoft Windows Azure和Amazon AWS EC2，历任研发工程师，高级研发主管，首席软件开发经理，组建和带领过实战能力极强的研发团队。

（文章首发于：http://www.infoq.com/cn/articles/Maglev-...）