从Google Maglev说起，如何造一个牛逼的负载均衡？

640?wx_fmt=gif

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年这个时间点上去分析现状，深入思考各种负载均衡实现的优、劣势。负载均衡大致可分为以F5、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个主要缺点：

主备模式利用率低；
不能横向平行扩展；
VRRP协议存在脑裂Split Brain的风险。Split Brain从逻辑角度来说是无解的，除非更换架构。

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

需要了解动态路由协议，LVS和交换机均需要复杂配置；
交换机的HASH算法一般比较简单，增加删除节点会造成HASH重分布，可能导致当前TCP连接全部中断；
部分交换机（华为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
采用批处理摊销单个报文处理的成本
充分利用硬件特性

1. Intel DataDirect I/O Technology (Intel DDIO)
2. NUMA
3. Huge Pages，Cache Alignment，Memory channel use

Vortex直接采用多队列10G网卡，通过RSS直接将网卡队列和CPU Core绑定，消除线程的上下文切换带来的开销。Vortex线程间采用高并发无锁的消息队列通信。除此之外，完全不共享状态从而保证转发线程之间不会互相影响。Vortex在设计时尽可能的减少指针的使用、采用连续内存数据结构来降低cache miss。通过这样一系列精心设计的优化措施，Vortex的单机性能远超LVS。单机性能横向测试比较，参见下图：