负载均衡的基础原理说明
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
大家都知道一台服务器的处理能力,主要受限于服务器自身的可扩展硬件能力。所以,在需要处理大量用户请求的时候,通常都会引入负载均衡器,将多台普通服务器组成一个系统,来完成高并发的请求处理任务。
之前负载均衡只能通过DNS来实现,1996年之后,出现了新的网络负载均衡技术。通过设置虚拟服务地址(IP),将位于同一地域(Region)的多台服务器虚拟成一个高性能、高可用的应用服务池;再根据应用指定的方式,将来自客户端的网络请求分发到
服务器池中。网络负载均衡会检查服务器池中后端服务器的健康状态,自动隔离异常状态的后端服务器,从而解决了单台后端服务器的单点问题,同时提高了应用的整体服务能力。
网络负载均衡主要有硬件与软件两种实现方式,主流负载均衡解决方案中,硬件厂商以F5为代表目前市场占有率超过50%,软件主要为NGINX与LVS。但是,无论硬件或软件实现,都逃不出基于四层交互技术的“转发”或基于七层协议的“代理”这两种方式。四层的转发模式通常性能会更好,但七层的代理模式可以根据更多的信息做到更智能地分发流量。一般大规模应用中,这两种方式会同时存在。
2007年F5提出了ADC(Application delivery controller)的概念为传统的负载均衡器增加了大量的功能,常用的有:SSL卸载、压缩优化和TCP连接优化。NGINX也支持很多ADC的特性,但F5的中高端型号会通过硬件加速卡来实现SSL卸载、压缩优化这一类CPU密集型的操作,从而可以提供更好的性能。
F5推出ADC以后,各种各样的功能有很多,但其实我们最常用的也就几种。这里我也简单的总结了一下,并和LVS、Nginx对比了一下。
SSL卸载和压缩优化,主要是将CPU密集型的加解密和压缩操作移到负载均衡器上进行;TCP连接优化主要指的是用户和负载均衡器短连接的同时,负载均衡器和后端服务器建立长连接。
不过我们本次主要介绍四层负载均衡,所以这些高级ADC功能不会涉及到。
F5的硬件负载均衡产品又分单机Big IP系列和集群VISRION系列,都是X86架构,配合自研的TMOS(Traffic Management Operating System),再加上硬件加速卡(Cavium提供)处理SSL和压缩等CPU密集型操作。
L4 CPS:四层每秒新建连接数。测试的时候一般采用TCP短连接,每次请求128字节。体现CPU性能,最重要的性能指标,没有之一。
L4最大并发连接数:体现内存大小
L7 RPS:七层每秒请求数。测试时每连接10个128字节HTTP请求。主要体现HTTP 协议栈性能
这些性能指标实际上就是一个负载均衡器最关键的指标了。大家如有采购硬件负载均衡器一定要看这个。
有很多小牌子的硬件负载均衡器经常不标注L4 CPS,只是笼统地说10G负载均衡,其实差别很大的。
硬件负载均衡在功能、易用性和可扩展性上都做得不错,但是也有不少缺点。从商业角度来说,硬件负载均衡产品过于昂贵,高端产品动辄五十万甚至数百万的价格对于用户是几乎不可承受的负担。
从使用角度来说,硬件负载均衡是黑盒,有BUG需要联系厂商等待解决,时间不可控、新特性迭代缓慢且需资深人员维护升级,也是变相增加昂贵的人力成本。
相信除了很多不差钱的公司,大家还是用软件负载均衡比较多。
软件四层负载均衡最常见的就是LVS了。
LVS最常用的有NAT、DR以及新的FULL NAT模式。上图比较了几种常见转发模式的优缺点。
我们认为LVS的每种转发模式都有其优点和缺点,但最大的问题还是其复杂性。
我第一次看到这三种转发方式、还有F5的单臂模式、双臂模式都会有云里雾里的感觉。雪上加霜的是咱们还需要考虑LVS的性能扩展和容灾方法,这使得整个方案更加的复杂。
常见的有基于Keepalived的主备方式和ECMP两种。Keepalived主备模式设备利用率低;不能横向扩展;VRRP协议,有脑裂的风险。
而ECMP的方式需要了解动态路由协议,LVS和交换机均需要较复杂配置;交换机的HASH算法一般比较简单,增加删除节点会造成HASH重分布,可能导致当前TCP连接全部中断;部分交换机的ECMP在处理分片包时会有Bug,说起来心中满满的都是血泪呀。
如图:UCloud Vortex负载均衡器的设计理念
用户使用负载均衡器最重要的需求是“High Availability”和“Scalability”,Vortex 的架构设计重心就是满足用户需求,提供极致的“可靠性”和“可收缩性”,而在这两者之间我们又把“可靠性”放在更重要的位置。
值得一提的是今年3月举办的第十三届网络系统设计与实现USENIX研讨会(NSDI '16)上,来自谷歌、加州大学洛杉矶分校、SpaceX公司的工程师们分享了《Maglev:快速、可靠的软件网络负载均衡器》,介绍了从2008年开始在生产环境投入使用的软件负载均衡器。其设计理念和我们非常相似,同样是ECMP + 一致性哈希;同样是Kernel Bypass模式;单机性能也和我们的Vortex非常接近。
关于Vortex的High Availability实现
四层负载均衡器的主要功能是将收到的数据包转发给不同的后端服务器,但必须保证将五元组相同的数据包发送到同一台后端服务器,否则后端服务器将无法正确处理该数据包。
以常见的HTTP连接为例,如果报文没有被发送到同一台后端服务器,操作系统的TCP 协议栈无法找到对应的TCP连接或者是验证TCP序列号错误将会无声无息的丢弃报文,发送端不会得到任何的通知。如果应用层没有超时机制的话,服务将会长期不可用。Vortex的可靠性设计面临的最大问题就是如何在任何情况下避免该情况发生。Vortex 通过ECMP集群和一致性哈希来实现极致程度的可靠性。
首先,我们来考察一下负载均衡服务器变化场景。这种场景下,可能由于负载均衡服务器故障被动触发,也可能由于运维需要主动增加或者减少负载均衡服务器。
此时交换机会通过动态路由协议检测负载均衡服务器集群的变化,但除思科的某些型号外大多数交换机都采用简单的取模算法,导致大多数数据包被发送到不同的负载均衡服务器。