《LVS集群中的IP负载均衡技术》由会员分享,可在线阅读,更多相关《LVS集群中的IP负载均衡技术(10页珍藏版)》请在金锄头文库上搜索。
1、1.1.前言前言 在前面文章中,讲述了可伸缩网络服务的几种结构,它们都需要一个前端的负载调度器 (或者多个进行主从备份)。我们先分析实现虚拟网络服务的主要技术,指出 IP 负载均衡 技术是在负载调度器的实现技术中效率最高的。在已有的 IP 负载均衡技术中,主要有通过 网络地址转换(Network Address Translation)将一组服务器构成一个高性能的、高可用 的虚拟服务器,我们称之为 VS/NAT 技术(Virtual Server via Network Address Translation)。在分析 VS/NAT 的缺点和网络服务的非对称性的基础上,我们提出了通过 IP 隧
2、道实现虚拟服务器的方法 VS/TUN (Virtual Server via IP Tunneling),和通过直 接路由实现虚拟服务器的方法 VS/DR(Virtual Server via Direct Routing),它们可以 极大地提高系统的伸缩性。VS/NATVS/NAT、VS/TUNVS/TUN 和和 VS/DRVS/DR 技术是技术是 LVSLVS 集群中实现的三种集群中实现的三种 IPIP 负负 载均衡技术载均衡技术,我们将在文章中详细描述它们的工作原理和各自的优缺点。在以下描述中,我们称客户的 socket 和服务器的 socket 之间的数据通讯为连接,无论它 们是使用
3、TCP 还是 UDP 协议。下面简述当前用服务器集群实现高可伸缩、高可用网络服务 的几种负载调度方法,并列举几个在这方面有代表性的研究项目。2.2.实现虚拟服务的相关方法实现虚拟服务的相关方法在网络服务中,一端是客户程序,另一端是服务程序,在中间可能有代理程序。由此看来, 可以在不同的层次上实现多台服务器的负载均衡。用集群解决网络服务性能问题的现有方 法主要分为以下四类。 2.1. 基于 RR-DNS 的解决方法,它的结构和工作流程如下图所示:有一组 WEB 服务器,他们通过分布式文件系统 AFS(Andrew File System)来共享所有的 HTML 文档。这组服务器拥有相同的域名(如
4、 www.ncsa.uiuc.edu),当用户按照这个域名 访问时, RR-DNS 服务器会把域名轮流解析到这组服务器的不同 IP 地址,从而将访问负载 分到各台服务器上。这种方法带来几个问题。第一,域名服务器是一个分布式系统,是按照一定的层次结构组 织的。当用户就域名解析请求提交给本地的域名服务器,它会因不能直接解析而向上一级 域名服务器提交,上一级域名服务器再依次向上提交,直到 RR-DNS 域名服器把这个域名解 析到其中一台服务器的 IP 地址。可见,从用户到 RR-DNS 间存在多台域名服器,而它们都 会缓冲已解析的名字到 IP 地址的映射,这会导致该域名服器组下所有用户都会访问同一
5、WEB 服务器,出现不同 WEB 服务器间严重的负载不平衡。为了保证在域名服务器中域名到 IP 地址的映射不被长久缓冲,RR-DNS 在域名到 IP 地址的映射上设置一个 TTL(Time To Live)值,过了这一段时间,域名服务器将这个映射从缓冲中淘汰。当用户请求,它会再向 上一级域名服器提交请求并进行重新影射。这就涉及到如何设置这个 TTL 值,若这个值太 大,在这个 TTL 期间,很多请求会被映射到同一台 WEB 服务器上,同样会导致严重的负载 不平衡。若这个值太小,例如是,会导致本地域名服务器频繁地向 RR-DNS 提交请求,增 加了域名解析的网络流量,同样会使 RR-DNS 服务
6、器成为系统中一个新的瓶颈。第二,用户机器会缓冲从名字到 IP 地址的映射,而不受 TTL 值的影响,用户的访问请求会 被送到同一台 WEB 服务器上。由于用户访问请求的突发性和访问方式不同,例如有的人访 问一下就离开了,而有的人访问可长达几个小时,所以各台服务器间的负载仍存在倾斜 (Skew)而不能控制。假设用户在每个会话中平均请求数为 20,负载最大的服务器获得的 请求数额高于各服务器平均请求数的平均比率超过百分之三十。也就是说,当 TTL 值为 0 时,因为用户访问的突发性也会存在着较严重的负载不平衡。第三,系统的可靠性和可维护性差。若一台服务器失效,会导致将域名解析到该服务器的 用户看到
7、服务中断,即使用户按“Reload”按钮,也无济于事。系统管理员也不能随时地 将一台服务器切出服务进行系统维护,如进行操作系统和应用软件升级,这需要修改 RR- DNS 服务器中的 IP 地址列表,把该服务器的 IP 地址从中划掉,然后等上几天或者更长的 时间,等所有域名服器将该域名到这台服务器的映射淘汰,和所有映射到这台服务器的客 户机不再使用该站点为止。2.2. 基于客户端的解决方法基于客户端的解决方法需要每个客户程序都有一定的服务器集群的知识,进而把以负载均 衡的方式将请求发到不同的服务器。例如,Netscape Navigator 浏览器访问 Netscape 的 主页时,它会随机地从
8、一百多台服务器中挑选第 N 台,最后将请求送往 。然而,这不是很好的解决方法,Netscape 只是利用它的 Navigator 避免了 RR-DNS 解析的麻烦,当使用 IE 等其他浏览器不可避免的要进行 RR-DNS 解析。Smart Client3是 Berkeley 做的另一种基于客户端的解决方法。服务提供一个 Java Applet 在客户方浏览器中运行,Applet 向各个服务器发请求来收集服务器的负载等信息, 再根据这些信息将客户的请求发到相应的服务器。高可用性也在 Applet 中实现,当服务器 没有响应时,Applet 向另一个服务器转发请求。这种方法的透明性不好,Apple
9、t 向各服务器查询来收集信息会增加额外的网络流量,不具有普遍的适用性。2.3. 基于应用层负载均衡调度的解决方法多台服务器通过高速的互联网络连接成一个集群系统,在前端有一个基于应用层的负载调 度器。当用户访问请求到达调度器时,请求会提交给作负载均衡调度的应用程序,分析请 求,根据各个服务器的负载情况,选出一台服务器,重写请求并向选出的服务器访问,取 得结果后,再返回给用户。基于应用层负载均衡调度的多服务器解决方法也存在一些问题。第一,系统处理开销特别 大,致使系统的伸缩性有限。当请求到达负载均衡调度器至处理结束时,调度器需要进行 四次从核心到用户空间或从用户空间到核心空间的上下文切换和内存复制
10、;需要进行二次 TCP 连接,一次是从用户到调度器,另一次是从调度器到真实服务器;需要对请求进行分 析和重写。这些处理都需要不小的、内存和网络等资源开销,且处理时间长。所构 成系统的性能不能接近线性增加的,一般服务器组增至 3 或 4 台时,调度器本身可能会成 为新的瓶颈。所以,这种基于应用层负载均衡调度的方法的伸缩性极其有限。第二,基于 应用层的负载均衡调度器对于不同的应用,需要写不同的调度器。以上几个系统都是基于 HTTP 协议,若对于 FTP、Mail、POP3 等应用,都需要重写调度器。2.4. 基于 IP 层负载均衡调度的解决方法用户通过虚拟 IP 地址(Virtual IP Add
11、ress)访问服务时,访问请求的报文会到达负载调 度器,由它进行负载均衡调度,从一组真实服务器选出一个,将报文的目标地址 Virtual IP Address 改写成选定服务器的地址,报文的目标端口改写成选定服务器的相应端口,最 后将报文发送给选定的服务器。真实服务器的回应报文经过负载调度器时,将报文的源地 址和源端口改为 Virtual IP Address 和相应的端口,再把报文发给用户。Berkeley 的 MagicRouter8、Cisco 的 LocalDirector、 Alteon 的 ACEDirector 和 F5 的 Big/IP 等都 是使用网络地址转换方法。Magic
12、Router 是在 Linux 1.3 版本上应用快速报文插入技术, 使得进行负载均衡调度的用户进程访问网络设备接近核心空间的速度,降低了上下文切换 的处理开销,但并不彻底,它只是研究的原型系统,没有成为有用的系统存活下来。Cisco 的 LocalDirector、Alteon 的 ACEDirector 和 F5 的 Big/IP 是非常昂贵的商品化系统,它 们支持部分 TCP/UDP 协议,有些在 ICMP 处理上存在问题。IBM 的 TCP Router9使用修改过的网络地址转换方法在 SP/2 系统实现可伸缩的 WEB 服务 器。TCP Router 修改请求报文的目标地址并把它转发
13、给选出的服务器,服务器能把响应报 文的源地址置为 TCP Router 地址而非自己的地址。这种方法的好处是响应报文可以直接返 回给客户,坏处是每台服务器的操作系统内核都需要修改。IBM 的 NetDispatcher10是 TCP Router 的后继者,它将报文转发给服务器,而服务器在 non-ARP 的设备配置路由器的 地址。这种方法与 LVS 集群中的 VS/DR 类似,它具有很高的可伸缩性,但一套在 IBM SP/2 和 NetDispatcher 需要上百万美金。总的来说,IBM 的技术还挺不错的。 在贝尔实验室的 ONE-IP11中,每台服务器都独立的 IP 地址,但都用 IP
14、Alias 配置上同 一 VIP 地址,采用路由和广播两种方法分发请求,服务器收到请求后按 VIP 地址处理请求, 并以 VIP 为源地址返回结果。这种方法也是为了避免回应报文的重写,但是每台服务器用IP Alias 配置上同一 VIP 地址,会导致地址冲突,有些操作系统会出现网络失效。通过广 播分发请求,同样需要修改服务器操作系统的源码来过滤报文,使得只有一台服务器处理 广播来的请求。 微软的 Windows NT 负载均衡服务(Windows NT Load Balancing Service,WLBS)12是 1998 年底收购 Valence Research 公司获得的,它与 ONE
15、-IP 中的基于本地过滤方法一样。 WLBS 作为过滤器运行在网卡驱动程序和 TCP/IP 协议栈之间,获得目标地址为 VIP 的报文, 它的过滤算法检查报文的源 IP 地址和端口号,保证只有一台服务器将报文交给上一层处理。 但是,当有新结点加入和有结点失效时,所有服务器需要协商一个新的过滤算法,这会导 致所有有 Session 的连接中断。同时,WLBS 需要所有的服务器有相同的配置,如网卡速度 和处理能力。 3.3. 通过通过 NATNAT 实现虚拟服务器(实现虚拟服务器(VS/NATVS/NAT) 由于 IPv4 中 IP 地址空间的日益紧张和安全方面的原因,很多网络使用保留 IP 地址
16、 (10.0.0.0/255.0.0.0、 172.16.0.0/255.128.0.0 和 192.168.0.0/255.255.0.0)64, 65, 66。这些地址不在 Internet 上使用,而是专门为内部网络预留的。当内部网络中的 主机要访问 Internet 或被 Internet 访问时,就需要采用网络地址转换(Network Address Translation, 以下简称 NAT),将内部地址转化为 Internets 上可用的外部地址。NAT 的 工作原理是报文头(目标地址、源地址和端口等)被正确改写后,客户相信它们连接一个 IP 地址,而不同 IP 地址的服务器组也认为它们是与客户直接相连的。由此,可以用 NAT 方法将不同 IP 地址的并行网络服务变成在一个 IP 地址上的一个虚拟服务。VS/NAT 的体系结构如图 2 所示。在一组服务器前有一个调度器,它们是通过 Switch/HUB 相连接的。这些服务器提供相同的网络服务、相同的内容,即不管请求被发送到哪一台服 务