1、 大家都知道一台服务器的处理能力，主要受限于服务器自身的可扩展硬件能力。所以，在需要处理大量用户请求的时候，通常都会引入负载均衡器，将多台普通服务器组成一个系统，来完成高并发的请求处理任务。之前负载均衡只能通过 DNS 来实现，1996 年之后，出现了新的网络负载均衡技术。通过设置虚拟服务地址（IP），将位于同一地域（Region）的多台服务器虚拟成一个高性能、高可用的应用服务池；再根据应用指定的方式，将来自客户端的网络请求分发到服务器池中。网络负载均衡会检查服务器池中后端服务器的健康状态，自动隔离异常状态的后端服务器，从而解决了单台后端服务器的单点问题，同时提高了应用的整体服务能力。网络负载
2、均衡主要有硬件与软件两种实现方式，主流负载均衡解决方案中，硬件厂商以 F5 为代表目前市场占有率超过 50%，软件主要为 NGINX 与 LVS。但是，无论硬件或软件实现，都逃不出基于四层交互技术的“转发”或基于七层协议的“代理”这两种方式。 四层的转发模式通常性能会更好，但七层的代理模式可以根据更多的信息做到更智能地分发流量。一般大规模应用中，这两种方式会同时存在。2007 年 F5 提出了 ADC（Application delivery controller）的概念为传统的负载均衡器增加了大量的功能，常用的有：SSL 卸载、压缩优化和 TCP 连接优化。NGINX也支持很多 ADC 的特
3、性，但 F5 的中高端型号会通过硬件加速卡来实现 SSL 卸载、压缩优化这一类 CPU 密集型的操作，从而可以提供更好的性能。F5 推出 ADC 以后，各种各样的功能有很多，但其实我们最常用的也就几种。这里我也简单的总结了一下，并和 LVS、Nginx 对比了一下。SSL 卸载和压缩优化，主要是将 CPU 密集型的加解密和压缩操作移到负载均衡器上进行；TCP 连接优化主要指的是用户和负载均衡器短连接的同时，负载均衡器和后端服务器建立长连接。不过我们本次主要介绍四层负载均衡，所以这些高级 ADC 功能不会涉及到。F5 的硬件负载均衡产品又分单机 Big IP 系列和集群 VISRION 系列，都
4、是 X86 架构，配合自研的 TMOS（Traffic Management Operating System），再加上硬件加速卡（Cavium 提供）处理 SSL 和压缩等 CPU 密集型操作。L4 CPS：四层每秒新建连接数。测试的时候一般采用 TCP 短连接，每次请求 128 字节。体现 CPU 性能，最重要的性能指标，没有之一。L4 最大并发连接数：体现内存大小L7 RPS：七层每秒请求数。测试时每连接 10 个 128 字节 HTTP 请求。主要体现HTTP 协议栈性能这些性能指标实际上就是一个负载均衡器最关键的指标了。大家如有采购硬件负载均衡器一定要看这个。有很多小牌子的硬件负载均
5、衡器经常不标注 L4 CPS，只是笼统地说 10G 负载均衡，其实差别很大的。硬件负载均衡在功能、易用性和可扩展性上都做得不错，但是也有不少缺点。从商业角度来说，硬件负载均衡产品过于昂贵，高端产品动辄五十万甚至数百万的价格对于用户是几乎不可承受的负担。从使用角度来说，硬件负载均衡是黑盒，有 BUG 需要联系厂商等待解决，时间不可控、新特性迭代缓慢且需资深人员维护升级，也是变相增加昂贵的人力成本。相信除了很多不差钱的公司，大家还是用软件负载均衡比较多。软件四层负载均衡最常见的就是 LVS 了。LVS 最常用的有 NAT、DR 以及新的 FULL NAT 模式。上图比较了几种常见转发模式的优缺点。
6、我们认为 LVS 的每种转发模式都有其优点和缺点，但最大的问题还是其复杂性。我第一次看到这三种转发方式、还有 F5 的单臂模式、双臂模式都会有云里雾里的感觉。雪上加霜的是咱们还需要考虑 LVS 的性能扩展和容灾方法，这使得整个方案更加的复杂。常见的有基于 Keepalived 的主备方式和 ECMP 两种。Keepalived 主备模式设备利用率低；不能横向扩展；VRRP 协议，有脑裂的风险。而 ECMP 的方式需要了解动态路由协议，LVS 和交换机均需要较复杂配置；交换机的HASH 算法一般比较简单，增加删除节点会造成 HASH 重分布，可能导致当前 TCP连接全部中断；部分交换机的 ECM
7、P 在处理分片包时会有 Bug，说起来心中满满的都是血泪呀。如图：UCloud Vortex 负载均衡器的设计理念用户使用负载均衡器最重要的需求是“High Availability”和“Scalability”，Vortex的架构设计重心就是满足用户需求，提供极致的“可靠性”和“可收缩性”，而在这两者之间我们又把“可靠性”放在更重要的位置。值得一提的是今年 3 月举办的第十三届网络系统设计与实现 USENIX 研讨会（NSDI 16）上， 来自谷歌、加州大学洛杉矶分校、SpaceX 公司的工程师们分享了Maglev：快速、可靠的软件网络负载均衡器，介绍了从 2008 年开始在生产环境投入使用
8、的软件负载均衡器。其设计理念和我们非常相似，同样是 ECMP + 一致性哈希；同样是 Kernel Bypass 模式；单机性能也和我们的 Vortex 非常接近。关于 Vortex 的 High Availability 实现四层负载均衡器的主要功能是将收到的数据包转发给不同的后端服务器，但必须保证将五元组相同的数据包发送到同一台后端服务器，否则后端服务器将无法正确处理该数据包。以常见的 HTTP 连接为例，如果报文没有被发送到同一台后端服务器，操作系统的TCP 协议栈无法找到对应的 TCP 连接或者是验证 TCP 序列号错误将会无声无息的丢弃报文，发送端不会得到任何的通知。如果应用层没有超
9、时机制的话，服务将会长期不可用。Vortex 的可靠性设计面临的最大问题就是如何在任何情况下避免该情况发生。Vortex通过 ECMP 集群和一致性哈希来实现极致程度的可靠性。首先，我们来考察一下负载均衡服务器变化场景。 这种场景下，可能由于负载均衡服务器故障被动触发，也可能由于运维需要主动增加或者减少负载均衡服务器。此时交换机会通过动态路由协议检测负载均衡服务器集群的变化，但除思科的某些型号外大多数交换机都采用简单的取模算法，导致大多数数据包被发送到不同的负载均衡服务器。Vortex 服务器的一致性哈希算法能够保证即使是不同的 Vortex 服务器收到了数据包，仍然能够将该数据包转发到同一台
10、后端服务器，从而保证客户应用对此类变化无感知，业务不受任何影响。这种场景下，如果负载均衡器是 LVS 且采用 RR (Round Robin)算法的话，该数据包会被送到错误的后端服务器，且上层应用无法得到任何通知。如果 LVS 配置了 SH(Source Hash)算法的话，该数据包会被送到正确的后端服务器，上层应用对此类变化无感知，业务不受任何影响；如果负载均衡器是 NGINX 的话，该数据包会被 TCP 协议栈无声无息地丢弃，上层应用不会得到任何通知。其次，来考察后端服务器变化的场景。这种场景下，可能由于后端服务器故障由健康检查机制检查出来，也可能由于运维需要主动增加或者减少后端服务器。此
11、时，Vortex 服务器会通过连接追踪机制保证当前活动连接的数据包被送往之前选择的服务器，而所有新建连接则会在变化后的服务器集群中进行负载分担。同时，Vortex 一致性哈希算法能保证大部分新建连接与后端服务器的映射关系保持不变，只有最少数量的映射关系发生变化，从而最大限度地减小了对客户端到端的应用层面的影响。这种场景下，如果负载均衡器是 LVS 且 SH 算法的话，大部分新建连接与后端服务器的映射关系会发生变化。某些应用，例如缓存服务器，如果发生映射关系的突变，将造成大量的 cache miss，从而需要从数据源重新读取内容，由此导致性能的大幅下降。而 NGINX 在该场景下如果配置了一致性
12、哈希的话可以达到和 Vortex 一样的效果。最后，让我们来看一下负载均衡服务器和后端服务器集群同时变化的场景。在这种场景下，Vortex 能够保证大多数活动连接不受影响，少数活动连接被送往错误的后端服务器且上层应用不会得到任何通知。并且大多数新建连接与后端服务器的映射关系保持不变，只有最少数量的映射关系发生变化。如果负载均衡器是 LVS 且 SH 算法的话几乎所有活动连接都会被送往错误的后端服务器且上层应用不会得到任何通知。大多数新建连接与后端服务器的映射关系同样也会发生变化。如果是 NGINX 的话因为交换机将数据包送往不同的 NGINX 服务器，几乎所有数据包会被无声无息的丢弃，上层应用
13、不会得到任何通知。可收缩性的设计是基于 ECMP 集群的 Scaling Out 设计Vortex 采用动态路由的方式通过路由器 ECMP（Equal-cost multi-path routing）来实现 Vortex 集群的负载均衡。一般路由机支持至少 16 或 32 路 ECMP 集群，特殊的 SDN 交换机支持多达 256 路ECMP 集群。而一致性哈希的使用是的 ECMP 集群的变化对上层应用基本无感知，用户业务不受影响。虽然 ECMP 提供了良好的 Scaling Out 的能力，但是考虑到网络设备的价格仍然希望单机性能够尽可能的强。例如，转发能力最好是能够达到 10G 甚至 40
14、G 的线速，同时能够支持尽可能高的每秒新建连接数。内核不是解决方案，而是问题所在！从上图可以看到随着高速网络的发展 64 字节小包线速的要求越来越高，对 10G 网络来说平均 67ns，对 40G 网络来说只有 17ns。而于此同时 CPU、内存的速度提升却没有那么多。以 2G 主频的 CPU 为例，每次命中 L3 缓存的读取操作需要约 40 个 CPU 周期，而一旦没有命中缓存从主存读取则需要 140 个 CPU 周期。为了达到线速就必须采用多核并发处理、批量数据包处理的方式来摊销单个数据包处理所需要的 CPU 周期数。此外，即使采用上述方式，如果没有得到充分的优化，发生多次 cache m
15、iss 或者是 memory copy 都无法达到 10G 线速的目标。像 NGINX 这样的代理模式，转发程序因为需要 TCP 协议栈的处理以及至少一次内存复制性能要远低于 LVS。而 LVS 又因为通用 Kernel 的限制，会考虑节省内存等设计策略，而不会向 Vortex 一样在一开始就特别注重转发性能。例如 LVS 缺省的连接追踪 HASH 表大小为 4K，而 Vortex 直接使用了 50%以上的内存作为连接追踪表。Vortex 通过 DPDK 提供函数库充分利用 CPU 和网卡的能力从而达到了单机 10G 线速的转发性能。用户空间驱动，完全 Zero-Copy采用批处理摊销单个报文
16、处理的成本充分利用硬件特性Intel DataDirect I/O Technology (Intel DDIO)NUMAHuge Pages，Cache Alignment，Memory channel useVortex 直接采用多队列 10G 网卡，通过 RSS 直接将网卡队列和 CPU Core 绑定，消除线程的上下文切换带来的开销。Vortex 线程间采用高并发无锁的消息队列通信。除此之外，完全不共享状态从而保证转发线程之间不会互相影响。Vortex 在设计时尽可能的减少指针的使用、采用连续内存数据结构来降低 cache miss。通过这样一系列精心设计的优化措施，最终 Vortex
17、 的单机性能远超 LVS，甚至超过了Google Maglev 的水平。LVS 支持四种转发模式：NAT、DR、TUNNEL 和 FULLNAT，其实各有利弊。Vortex 在设计之初就对四种模式做了评估，最后发现在虚拟化的环境下 DR 方式在各方面比较平衡，并且符合我们追求极致性能的理念。DR 方式最大的优点是绝佳的性能，只有 request 需要负载均衡器处理，response 可以直接从后端服务器返回客户机，不论是吞吐还是延时都是最好的分发方式。其次，DR 方式不像 NAT 模式需要复杂的路由设置，而且不像 NAT 模式当 client 和后端服务器处于同一个子网就无法正常工作。DR 的
18、这个特性使他特别合适作为内网负载均衡。此外，不像 FULLNAT 一样需要先修改源 IP 再使用 TOA 传递源地址，还得在负载均衡器和后端服务器上都编译非主线的 Kernel Module，DR 可以KISS（ Keep It Simple, Stupid）地将源地址传递给后端服务器。最后，虚拟化环境中已经采用 Overlay 虚拟网络了，所以 TUNNEL 的方式变得完全多余。而 DR 方式最大的缺点：需要 LB 和后端服务器在同一个二层网络，而这在 UCloud 的虚拟化网络中完全不是问题。主流的 SDN 方案追求的正是虚拟化的大二层网络带来的无缝迁移体验，且早已采用各种优化手段（例如
19、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 并发连接数。
