负载均衡设备报价负载均衡价格.docx

负载均衡设备报价负载均衡价格.docx

《负载均衡设备报价负载均衡价格.docx》由会员分享，可在线阅读，更多相关《负载均衡设备报价负载均衡价格.docx（11页珍藏版）》请在冰豆网上搜索。

负载均衡设备报价负载均衡价格

负载均衡设备报价,负载均衡价格

什么是负载均衡

一台服务器的处理能力，主要受限于服务器自身的可扩展硬件能力。

所以，在需要处理大量用户请求的时候，通常都会引入负载均衡器，将多台普通服务器组成一个系统，来完成高并发的请求处理任务。

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

图：

多层次负载均衡

但在使用DNS均衡负载时，由于DNS数据刷新的延迟问题，无法确保用户请求的完全均衡。

而且，一旦其中某台服务器出现故障，即使修改了DNS配置，仍然需要等到新的配置生效后，故障服务器才不会被用户访问到。

目前，DNS负载均衡仍在大量使用，但多用于实现“多地就近接入”的应用场景。

1996年之后，出现了新的网络负载均衡技术。

通过设置虚拟服务地址（IP），将位于同一地域（Region）的多台服务器虚拟成一个高性能、高可用的应用服务池；再根据应用指定的方式，将来自客户端的网络请求分发到服务器池中。

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

网络负载均衡主要有硬件与软件两种实现方式，主流负载均衡解决方案中，硬件厂商以F5为代表，软件主要为NGINX与LVS。

但是，无论硬件或软件实现，都逃不出基于四层交互技术的“报文转发”或基于七层协议的“请求代理”这两种方式。

四层的转发模式通常性能会更好，但七层的代理模式可以根据更多的信息做到更智能地分发流量。

一般大规模应用中，这两种方式会同时存在。

为什么要研发Vortex?

在研发UCloudVortex之前，我们一直在思考是不是在重造轮子。

这要求我们站在2016年这个时间点上去分析现状，深入思考各种负载均衡实现的优、劣势。

负载均衡大致可分为以F5、Netscaler为代表的硬件负载均衡和以LVS为代表的软件负载均衡。

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

F5的硬件负载均衡产品又分单机和集群系列。

12250v是单机中的高端版本，能支撑每秒150万新建连接数，8000万并发连接数，84G数据吞吐量。

从F5的datasheet中，我们推算出并发连接数受限于内存，高端的12250v和次一级的11050内存相差4倍，并发连接数也是4：

1的关系，后者大概为2400万；根据UCloud自身云平台的运营经验，150万新建连接在特定大压力场景下是非常危险的，很有可能被击穿；而84G的吞吐量，一般来说是够用的，数据中心南北向的流量有限。

图：

F512250v

集群系列中VIPRION4800阵列是旗舰产品，每个阵列支持较多8个Blade，每个Blade提供每秒290万新建连接数，1.8亿并发连接数以及140G数据吞吐量。

按线性比例计算，一个顶配的VIPRION4800阵列能满足绝大多数海量互联网应用的业务需求了。

其中，需要指出的是单片Blade都是用了普通X86架构，2块Intel12核CPU配256G内存，这个转变使其支撑量产生了飞越，也进一步证实并发连接数与内存呈相关性。

从技术角度来说，我们认为硬件负载均衡较终的路线是回到X86服务器架构，通过横向扩展来提升性能。

这里软硬件的区分已经不再存在，因为如果F5能做到，具备深入研发能力的技术公司如Google、Facebook也能逼近甚至超越。

从商业角度来说，硬件负载均衡产品过于昂贵，高端产品动辄五十万甚至数百万的价格对于用户是几乎不可承受的负担。

在文章末尾，我们提供了一份根据网上数据整理后的比较内容，主要来源为Google搜索：

F5Networks-PriceList-January11th,2014-AmendedfortheWSCA-NASPOJP14001RequestforProposal，供大家参考。

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

再来看（开源）软件负载均衡代表LVS. LVS作为目前互联网时代较知名的负载均衡软件，在性能与成本方面结合地很好，阿里云的SLB产品也通过LVS实现，因此也继承了LVS的优点和缺点。

LVS较常用的有NAT、DR以及新的FULLNAT模式。

以下是各模式详细的优缺点比较：

图:

NAT、DR和FULLNAT模式优缺点对比

我们认为LVS的每种模式都有较大的缺点，但这并不是较为致命的。

较为致命的是LVS本质上是一个工作于Linux内核层的负载均衡器，它的上限取决于Linux内核的网络性能，但Linux内核的网络路径过长导致了大量开销，使得LVS单机性能较低。

因此，Google于2016年3月较新公布的负载均衡Maglev实现完全绕过了Linux内核（KernelBypass），也就是说Google已经采用了与LVS不同的技术思路。

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

有3个主要缺点：

1.主备模式利用率低；

2.不能横向平行扩展；

3.VRRP协议存在脑裂SplitBrain的风险。

SplitBrain从逻辑角度来说是无解的，除非更换架构。

也有少数公司通过ECMP等价路由协议搭配LVS来避免Keepalived的缺陷。

综合来看，ECMP有几个问题：

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

2.交换机的HASH算法一般比较简单，增加删除节点会造成HASH重分布，可能导致当前TCP连接全部中断；

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

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

理性的剖析下，我们发现没有任何的负载均衡实现在价格、性能、部署难度、运维人力成本各方面能达到较优，所以Vortex必然不是在重造轮子而是在推动这个领域的革新:

Vortex必须不能像LVS那样被Linux内核限制住性能，Vortex也不能像F5那么的昂贵。

Vortex负载均衡器的设计理念

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

1.Vortex的HighAvailability实现

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

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

如果应用层没有超时机制的话，服务将会长期不可用。

Vortex的可靠性设计面临的较大问题就是如何在任何情况下避免该情况发生。

Vortex通过ECMP集群和一致性哈希来实现极致程度的可靠性。

首先，我们来考察一下负载均衡服务器变化场景。

 这种场景下，可能由于负载均衡服务器故障被动触发，也可能由于运维需要主动增加或者减少负载均衡服务器。

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

图：

负载均衡服务器变化场景

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

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

如果LVS配置了SH（SourceHash）算法的话，该数据包会被送到正确的后端服务器，上层应用对此类变化无感知，业务不受任何影响；如果负载均衡器是NGINX的话，该数据包会被TCP协议栈无声无息地丢弃，上层应用不会得到任何通知。

图：

后端服务器变化的场景

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

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

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

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

这种场景下，如果负载均衡器是LVS且SH算法的话，大部分新建连接与后端服务器的映射关系会发生变化。

某些应用，例如缓存服务器，如果发生映射关系的突变，将造成大量的cachemiss，从而需要从数据源重新读取内容，由此导致性能的大幅下降。

而NGINX在该场景下如果配置了一致性哈希的话可以达到和Vortex一样的效果。

图：

Vortex一致性哈希算法的计算公式

让我们来看一下负载均衡服务器和后端服务器集群同时变化的场景。

 在这种场景下，Vortex能够保证大多数活动连接不受影响，少数活动连接被送往错误的后端服务器且上层应用不会得到任何通知。

并且大多数新建连接与后端服务器的映射关系保持不变，只有较少数量的映射关系发生变化。

图：

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

如果负载均衡器是LVS且SH算法的话几乎所有活动连接都会被送往错误的后端服务器且上层应用不会得到任何通知（图四）。

大多数新建连接与后端服务器的映射关系同样也会发生变化。

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

图：

不同变化带来的影响对比

2.Vortex的Scalability实现

2.1基于ECMP集群的ScalingOut设计

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

一般路由机支持至少16或32路ECMP集群，特殊的SDN交换机支持多达256路ECMP集群。

而一致性哈希的使用是的ECMP集群的变化对上层应用基本无感知，用户业务不受影响。

2.2基于DPDK的ScalingUp设计

虽然ECMP提供了良好的ScalingOut的能力，但是考虑到网络设备的价格仍然希望单机性能够尽可能的强。

例如，转发能力较好是能够达到10G甚至40G的线速，同时能够支持尽可能高的每秒新建连接数。

Vortex利用DPDK提供的高性能用户空间（userspace）网卡驱动、高效无锁数据结构成功的将单机性能提升到转发14MPPS（10G,64字节线速），新建连接200KCPS以上。

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

基于DR转发方式

LVS支持四种转发模式：

NAT、DR、TUNNEL和FULLNAT，其实各有利弊。

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

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

其次，DR方式不像NAT模式需要复杂的路由设置，而且不像NAT模式当client和后端服务器处于同一个子网就无法正常工作。

DR的这个特性使他特别合适作为内网负载均衡。

此外，不像FULLNAT一样需要先修改源IP再使用TOA传递源地址，还得在负载均衡器和后端服务器上都编译非主线的KernelModule，DR可以KISS（KeepItSimple,Stupid）地将源地址传递给后端服务器。

虚拟化环境中已经采用Overlay虚拟网络了，所以TUNNEL的方式变得完全多余。

而DR方式较大的缺点：

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

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

结语

采用Vortex作为UCloud负载均衡产品ULB的核心引擎，通过一致性哈希算法的引入，并结合ECMP与DPDK的的服务架构，解决了利用commodityserver实现highavailability+highscalability的高性能软件负载均衡集群的课题。

此外，本次ULB的更新还对原有功能进行了扩展，重新调整了用户交互并增加了数10个新的feature，如优化了批量管理场景下的操作效率，SSL证书提高为基本资源对象管理。

未来，Vortex将以ULB为产品形态输出更多的创新理念。

附录：

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