1、 UCLoud 中国云三强: 负载均衡设备报价, 负载均衡价格什么是负载均衡一台服务器的处理能力，主要受限于服务器自身的可扩展硬件能力。所以，在需要处理大量用户请求的时候，通常都会引入负载均衡器，将多台普通服务器组成一个系统，来完成高并发的请求处理任务。较早的负载均衡技术是通过 DNS 来实现的，将多台服务器配置为相同的域名，使不同客户端在进行域名解析时，从这一组服务器中的请求随机分发到不同的服务器地址，从而达到负载均衡的目的。图：多层次负载均衡但在使用 DNS 均衡负载时，由于 DNS 数据刷新的延迟问题，无法确保用户请求的完全均衡。而且，一旦其中某台服务器出现故障，即使修改了 DNS 配置
2、，UCLoud 中国云三强: 仍然需要等到新的配置生效后，故障服务器才不会被用户访问到。目前，DNS负载均衡仍在大量使用，但多用于实现“多地就近接入”的应用场景。1996 年之后，出现了新的网络负载均衡技术。通过设置虚拟服务地址（IP），将位于同一地域（Region）的多台服务器虚拟成一个高性能、高可用的应用服务池；再根据应用指定的方式，将来自客户端的网络请求分发到服务器池中。网络负载均衡会检查服务器池中后端服务器的健康状态，自动隔离异常状态的后端服务器，从而解决了单台后端服务器的单点问题，同时提高了应用的整体服务能力。网络负载均衡主要有硬件与软件两种实现方式，主流负载均衡解决方案中，硬件厂商
3、以 F5 为代表，软件主要为 NGINX 与 LVS。但是，无论硬件或软件实现，都逃不出基于四层交互技术的“报文转发”或基于七层协议的“请求代理”这两种方式。 四层的转发模式通常性能会更好，但七层的代理模式可以根据更多的信息做到更智能地分发流量。一般大规模应用中，这两种方式会同时存在。为什么要研发 Vortex?在研发 UCloud Vortex 之前，我们一直在思考是不是在重造轮子。这要求我们站在 2016 年这个时间点上去分析现状，深入思考各种负载均衡实现的优、劣势。负载均衡大致可分为以 F5、Netscaler 为代表的硬件负载均衡和以 LVS 为代表的软件负载均衡。不妨，我们先以 F5
4、 为代表来看硬件负载均衡的优劣势。UCLoud 中国云三强: F5 的硬件负载均衡产品又分单机和集群系列。12250v 是单机中的高端版本，能支撑每秒 150 万新建连接数，8000 万并发连接数，84G 数据吞吐量。从 F5的 datasheet 中，我们推算出并发连接数受限于内存，高端的 12250v 和次一级的 11050 内存相差 4 倍，并发连接数也是 4：1 的关系，后者大概为 2400万；根据 UCloud 自身云平台的运营经验，150 万新建连接在特定大压力场景下是非常危险的，很有可能被击穿；而 84G 的吞吐量，一般来说是够用的，数据中心南北向的流量有限。图：F5 12250
5、v集群系列中 VIPRION 4800 阵列是旗舰产品，每个阵列支持较多 8 个 Blade，每个 Blade 提供每秒 290 万新建连接数，1.8 亿并发连接数以及 140G 数据吞吐量。按线性比例计算，一个顶配的 VIPRION 4800 阵列能满足绝大多数海量互联网应用的业务需求了。其中，需要指出的是单片 Blade 都是用了普通 X86架构，2 块 Intel 12 核 CPU 配 256G 内存，这个转变使其支撑量产生了飞越，也进一步证实并发连接数与内存呈相关性。UCLoud 中国云三强: 从技术角度来说，我们认为硬件负载均衡较终的路线是回到 X86 服务器架构，通过横向扩展来提升
6、性能。这里软硬件的区分已经不再存在，因为如果 F5 能做到，具备深入研发能力的技术公司如 Google、Facebook 也能逼近甚至超越。从商业角度来说，硬件负载均衡产品过于昂贵，高端产品动辄五十万甚至数百万的价格对于用户是几乎不可承受的负担。在文章末尾，我们提供了一份根据网上数据整理后的比较内容，主要来源为 Google 搜索：F5 Networks - Price List - January 11th, 2014 - Amended for the WSCA-NASPO JP14001 Request for Proposal，供大家参考。从使用角度来说，硬件负载均衡是黑盒，有 BUG
7、 需要联系厂商等待解决，时间不可控、新特性迭代缓慢且需资深人员维护升级，也是变相增加昂贵的人力成本。再来看（开源）软件负载均衡代表 LVS. LVS 作为目前互联网时代较知名的负载均衡软件，在性能与成本方面结合地很好，阿里云的 SLB 产品也通过 LVS 实现，因此也继承了 LVS 的优点和缺点。LVS 较常用的有 NAT、DR 以及新的 FULL NAT 模式。以下是各模式详细的优缺点比较：UCLoud 中国云三强: 图:NAT、DR 和 FULL NAT 模式 优缺点对比我们认为 LVS 的每种模式都有较大的缺点，但这并不是较为致命的。较为致命的是 LVS 本质上是一个工作于 Linux
8、内核层的负载均衡器，它的上限取决于Linux 内核的网络性能，但 Linux 内核的网络路径过长导致了大量开销，使得LVS 单机性能较低。因此，Google 于 2016 年 3 月较新公布的负载均衡Maglev 实现完全绕过了 Linux 内核（Kernel Bypass），也就是说 Google 已经采用了与 LVS 不同的技术思路。LVS 在运维层面还要考虑容灾的问题，大多使用 Keepalived 完成主备模式的容灾。有 3 个主要缺点：1. 主备模式利用率低；2. 不能横向平行扩展；3. VRRP 协议存在脑裂 Split Brain 的风险。Split Brain 从逻辑角度来说是
9、无解的，除非更换架构。UCLoud 中国云三强: 也有少数公司通过 ECMP 等价路由协议搭配 LVS 来避免 Keepalived 的缺陷。综合来看，ECMP 有几个问题：1. 需要了解动态路由协议，LVS 和交换机均需要复杂配置；2. 交换机的 HASH 算法一般比较简单，增加删除节点会造成 HASH重分布，可能导致当前 TCP 连接全部中断；3. 部分交换机（华为 6810）的 ECMP 在处理分片包时会有 BUG。这些问题均在生产环境下，需要使用者有资深的运维专家、网络专家确保运营结果。UCLoud 中国云三强: 理性的剖析下，我们发现没有任何的负载均衡实现在价格、性能、部署难度、运维
10、人力成本各方面能达到较优，所以 Vortex 必然不是在重造轮子而是在推动这个领域的革新: Vortex 必须不能像 LVS 那样被 Linux 内核限制住性能，Vortex 也不能像 F5 那么的昂贵。Vortex 负载均衡器的设计理念用户使用负载均衡器较重要的需求是“High Availability”和“Scalability”，Vortex 的架构设计重心就是满足用户需求，提供极致的“可靠性”和“可收缩性”，而在这两者之间我们又把“可靠性”放在更重要的位置。1. Vortex 的 High Availability 实现四层负载均衡器的主要功能是将收到的数据包转发给不同的后端服务器，但
11、必须保证将五元组相同的数据包发送到同一台后端服务器，否则后端服务器将无法正确处理该数据包。以常见的 HTTP 连接为例，如果报文没有被发送到同一台后端服务器，操作系统的 TCP 协议栈无法找到对应的 TCP 连接或者是验证TCP 序列号错误将会无声无息的丢弃报文，发送端不会得到任何的通知。如果应用层没有超时机制的话，服务将会长期不可用。Vortex 的可靠性设计面临的较大问题就是如何在任何情况下避免该情况发生。Vortex 通过 ECMP 集群和一致性哈希来实现极致程度的可靠性。首先，我们来考察一下负载均衡服务器变化场景。 这种场景下，可能由于负载均衡服务器故障被动触发，也可能由于运维需要主动
12、增加或者减少负载均衡服UCLoud 中国云三强: 务器。此时交换机会通过动态路由协议检测负载均衡服务器集群的变化，但除思科的某些型号外大多数交换机都采用简单的取模算法，导致大多数数据包被发送到不同的负载均衡服务器。图：负载均衡服务器变化场景Vortex 服务器的一致性哈希算法能够保证即使是不同的 Vortex 服务器收到了数据包，仍然能够将该数据包转发到同一台后端服务器，从而保证客户应用对此类变化无感知，业务不受任何影响。这种场景下，如果负载均衡器是 LVS 且采用 RR (Round Robin)算法的话，该数据包会被送到错误的后端服务器，且上层应用无法得到任何通知。如果 LVS配置了 SH
13、(Source Hash)算法的话，该数据包会被送到正确的后端服务器，上层应用对此类变化无感知，业务不受任何影响；如果负载均衡器是 NGINX 的话，该数据包会被 TCP 协议栈无声无息地丢弃，上层应用不会得到任何通知。UCLoud 中国云三强: 图：后端服务器变化的场景其次，来考察后端服务器变化的场景。 这种场景下，可能由于后端服务器故障由健康检查机制检查出来，也可能由于运维需要主动增加或者减少后端服务器。此时，Vortex 服务器会通过连接追踪机制保证当前活动连接的数据包被送往之前选择的服务器，而所有新建连接则会在变化后的服务器集群中进行负载分担。同时，Vortex 一致性哈希算法能保证大
14、部分新建连接与后端服务器的映射关系保持不变，只有较少数量的映射关系发生变化，从而较大限度地减小了对客户端到端的应用层面的影响。这种场景下，如果负载均衡器是 LVS 且 SH 算法的话，大部分新建连接与后端服务器的映射关系会发生变化。某些应用，例如缓存服务器，如果发生映射关系的突变，将造成大量的 cache miss，从而需要从UCLoud 中国云三强: 数据源重新读取内容，由此导致性能的大幅下降。而 NGINX 在该场景下如果配置了一致性哈希的话可以达到和 Vortex 一样的效果。图：Vortex 一致性哈希算法的计算公式让我们来看一下负载均衡服务器和后端服务器集群同时变化的场景。 在这种场
15、景下，Vortex 能够保证大多数活动连接不受影响，少数活动连接被送往错误的后端服务器且上层应用不会得到任何通知。并且大多数新建连接与后端服务器的映射关系保持不变，只有较少数量的映射关系发生变化。UCLoud 中国云三强: 图：负载均衡服务器和后端服务器集群同时变化的场景如果负载均衡器是 LVS 且 SH 算法的话几乎所有活动连接都会被送往错误的后端服务器且上层应用不会得到任何通知（图四）。大多数新建连接与后端服务器的映射关系同样也会发生变化。如果是 NGINX 的话因为交换机将数据包送往不同的 NGINX 服务器，几乎所有数据包会被无声无息的丢弃，上层应用不会得到任何通知。图：不同变化带来的
16、影响对比UCLoud 中国云三强: 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 O
17、ut 的能力，但是考虑到网络设备的价格仍然希望单机性能够尽可能的强。例如，转发能力较好是能够达到 10G 甚至 40G的线速，同时能够支持尽可能高的每秒新建连接数。Vortex 利用 DPDK 提供的高性能用户空间 (user space) 网卡驱动、高效无锁数据结构成功的将单机性能提升到转发 14M PPS（10G, 64 字节线速），新建连接 200K CPS 以上。内核不是解决方案，而是问题所在！UCLoud 中国云三强: 基于 DR 转发方式LVS 支持四种转发模式：NAT 、DR、TUNNEL 和 FULLNAT，其实各有利弊。Vortex 在设计之初就对四种模式做了评估，较后发现在
18、虚拟化的环境下 DR 方式在各方面比较平衡，并且符合我们追求极致性能的理念。DR 方式较大的优点是好的性能，只有 request 需要负载均衡器处理，response 可以直接从后端服务器返回客户机，不论是吞吐还是延时都是较好的分发方式。其次，DR 方式不像 NAT 模式需要复杂的路由设置，而且不像 NAT 模式当client 和后端服务器处于同一个子网就无法正常工作。DR 的这个特性使他特别合适作为内网负载均衡。UCLoud 中国云三强: 此外，不像 FULLNAT 一样需要先修改源 IP 再使用 TOA 传递源地址，还得在负载均衡器和后端服务器上都编译非主线的 Kernel Module，
19、DR 可以KISS（ Keep It Simple, Stupid）地将源地址传递给后端服务器。虚拟化环境中已经采用 Overlay 虚拟网络了，所以 TUNNEL 的方式变得完全多余。而 DR 方式较大的缺点：需要 LB 和后端服务器在同一个二层网络，而这在 UCloud 的虚拟化网络中完全不是问题。主流的 SDN 方案追求的正是大二层带来的无缝迁移体验，且早已采用各种优化手段（例如 ARP 代理）来优化大二层虚拟网络。结语采用 Vortex 作为 UCloud 负载均衡产品 ULB 的核心引擎，通过一致性哈希算法的引入，并结合 ECMP 与 DPDK 的的服务架构，解决了利用 commod
20、ity server 实现 high availability + high scalability 的高性能软件负载均衡集群的课题。此外，本次 ULB 的更新还对原有功能进行了扩展，重新调整了用户交互并增加了数 10 个新的 feature，如优化了批量管理场景下的操作效率， SSL 证书提高为基本资源对象管理。未来，Vortex 将以 ULB 为产品形态输出更多的创新理念。附录：UCLoud 中国云三强: 按 7 折折扣并考虑每年 25%的降价幅度，上文提到的一套 12250v 价格约 87万人民币（生产环境中需要主备 2 台），一套包含一个机柜与 4 刀片的VIPRION 4800 价格约为 188 万人民币。
