1、Linux 服务器集群系统(二)LVS 集群的体系结构本文主要介绍了 LVS 集群的体系结构。先给出 LVS 集群的通用体系结构,并讨论了其的设计原则和相应的特点;最后将 LVS 集群应用于建立可伸缩的 Web、Media、Cache 和 Mail 等网络服务。1.引言 在过去的十几年中,Internet 从几个研究机构相连为信息共享的网络发展成为拥有大量应用和服务的全球性网络,它正成为人们生活中不可缺少的 一部分。虽然 Internet 发展速度很快,但建设和维护大型网络服务依然是一项挑战性的任务,因为系统必须是高性能的、高可靠的,尤其当访问负载不断增 长时,系统必须能被扩展来满足不断增长的
2、性能需求。由于缺少建立可伸缩网络服务的框架和设计方法,这意味着只有拥有非常出色工程和管理人才的机构才能建立 和维护大型的网络服务。针对这种情形,本文先给出 LVS 集群的通用体系结构,并讨论了其的设计原则和相应的特点;最后将 LVS 集群应用于建立可伸缩的 Web、Media、Cache 和 Mail 等网络服务。2.LVS 集群的通用体系结构 LVS 集群采用 IP 负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服 务器的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的,而且无
3、需修改客户端和服务器端的程序。图 1:LVS 集群的体系结构为此,在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。一般来说,LVS 集群采用三层结构,其体系结构如图 1 所示,三层主要组成部分为: 负载调度器(load balancer),它是整个集群对外面的前端机,负责将客户的请求发送到一组服务器上执行,而客户认为服务是来自一个 IP 地址(我们可称之为虚拟 IP 地址)上的。 服务器池(server pool),是一组真正执行客户请求的服务器,执行的服务有WEB、MAIL 、FTP 和 DNS 等。 共享存储(shared storage),它为服务器池提供一个共享的存储区,这
4、样很容易使得服务器池拥有相同的内容,提供相同的服务。调度器是服务器集群系统的唯一入口点(Single Entry Point),它可以采用 IP 负载均衡技术、基于内容请求分发技术或者两者相结合。在 IP 负载均衡技术中,需要服务器池拥有相同的内容提供相同的服务。当 客户请求到达时,调度器只根据服务器负载情况和设定的调度算法从服务器池中选出一个服务器,将该请求转发到选出的服务器,并记录这个调度;当这个请求的其 他报文到达,也会被转发到前面选出的服务器。在基于内容请求分发技术中,服务器可以提供不同的服务,当客户请求到达时,调度器可根据请求的内容选择服务器 执行请求。因为所有的操作都是在 Linu
5、x 操作系统核心空间中将完成的,它的调度开销很小,所以它具有很高的吞吐率。服务器池的结点数目是可变的。当整个系统收到的负载超过目前所有结点的处理能力时,可以在服务器池中增加服务器来满足不断增长的请求负载。对大多数 网络服务来说,请求间不存在很强的相关性,请求可以在不同的结点上并行执行,所以整个系统的性能基本上可以随着服务器池的结点数目增加而线性增长。共享存储通常是数据库、网络文件系统或者分布式文件系统。服务器结点需要动态更新的数据一般存储在数据库系统中,同时数据库会保证并发 访问时数据的一致性。静态的数据可以存储在网络文件系统(如 NFS/CIFS)中,但网络文件系统的伸缩能力有限,一般来说,
6、NFS/CIFS 服务器只能 支持 36 个繁忙的服务器结点。对于规模较大的集群系统,可以考虑用分布式文件系统,如AFS1、GFS2.3、Coda4和 Intermezzo5等。分布式文件系统可为各服务器提供共享的存储区,它们访问分布式文件系统就像访问本地文件系统一样,同时分布式文件系统可提 供良好的伸缩性和可用性。此外,当不同服务器上的应用程序同时读写访问分布式文件系统上同一资源时,应用程序的访问冲突需要消解才能使得资源处于一致状 态。这需要一个分布式锁管理器(Distributed Lock Manager),它可能是分布式文件系统内部提供的,也可能是外部的。开发者在写应用程序时,可以使用
7、分布式锁管理器来保证应用程序在不同结点上并发访 问的一致性。负载调度器、服务器池和共享存储系统通过高速网络相连接,如 100Mbps 交换网络、Myrinet 和Gigabit 网络等。使用高速的网络,主要为避免当系统规模扩大时互联网络成为整个系统的瓶颈。Graphic Monitor 是为系统管理员提供整个集群系统的监视器,它可以监视系统的状态。Graphic Monitor 是基于浏览器的,所以无论管理员在本地还是异地都可以监测系统的状况。为了安全的原因,浏览器要通过 HTTPS(Secure HTTP)协议和身份认证后,才能进行系统监测,并进行系统的配置和管理。2.1. 为什么使用层次的
8、体系结构层次的体系结构可以使得层与层之间相互独立,每一个层次提供不同的功能,在一个层次可以重用不同的已有软件。例如,调度器层提供了负载平衡、可伸缩 性和高可用性等,在服务器层可以运行不同的网络服务,如 Web、Cache、Mail 和 Media 等,来提供不同的可伸缩网络服务。明确的功能划分和清晰 的层次结构使得系统容易建设,以后整个系统容易维护,而且系统的性能容易被扩展。2.2. 为什么是共享存储共享存储如分布式文件系统在这个 LVS 集群系统是可选项。当网络服务需要有相同的内容,共享存储是很好的选择,否则每台服务器需要将相同的 内容复制到本地硬盘上。当系统存储的内容越多,这种无共享结构(
9、Shared-nothing Structure)的代价越大,因为每台服务器需要一样大的存储空间,任何的更新需要涉及到每台服务器,系统的维护代价会非常高。共享存储为服务器组提供统一的存储空间,这使得系统的内容维护工作比较轻松,如 Webmaster只需要更新共享存储中的页面,对所有 的服务器都有效。分布式文件系统提供良好的伸缩性和可用性,当分布式文件系统的存储空间增加时,所有服务器的存储空间也随之增大。对于大多数 Internet 服务来说,它们都是读密集型(Read-intensive)的应用,分布式文件系统在每台服务器使用本地硬盘作 Cache(如 2Gbytes 的空间),可以使得访问分
10、布式文件系统本地的速度接近于访问本地硬盘。此外,存储硬件技术的发展也促使从无共享的集群向共享存储的集群迁移。存储区域网(Storage Area Networks)技术解决了集群的每个结点可以直接连接/共享一个庞大的硬盘阵列,硬件厂商也提供多种硬盘共享技术,如光纤通道(Fiber Channel)、共享 SCSI(Shared SCSI)。InfiniBand 是一个通用的高性能 I/O 规范,使得存储区域网中以更低的延时传输 I/O 消息和集群通讯消息,并且提供很好的伸缩性。 InfiniBand 得到绝大多数的大厂商的支持,如Compaq、Dell、Hewlett-Packard、IBM
11、、Intel、Microsoft 和 SUN Microsystems 等,它正在成为一个业界的标准。这些技术的发展使得共享存储变得容易,规模生产也会使得成本逐步降低。2.3. 高可用性集群系统的特点是它在软硬件上都有冗余。系统的高可用性可以通过检测节点或服务进程故障和正确地重置系统来实现,使得系统收到的请求能被存活的结点处理。通常,我们在调度器上有资源监测进程来时刻监视各个服务器结点的健康状况。当服务器对 ICMP ping 不可达时或者探测她的网络服务在指定的时间没有响应时,资源监测进程通知操作系统内核将该服务器从调度列表中删除或者失效。这样,新的服务请求就 不会被调度到坏的结点。资源监测
12、进程能通过电子邮件或传呼机向管理员报告故障。一旦监测进程到服务器恢复工作,通知调度器将其加入调度列表进行调度。另 外,通过系统提供的管理程序,管理员可发命令随时可以将新机器加入服务来提高系统的处理性能,也可以将已有的服务器切出服务,以便对服务器进行系统维护。现在前端的调度器有可能成为系统的单一失效点(Single Point of Failure)。一般来说,调度器的可靠性较高,因为调度器上运行的程序较少而且大部分程序早已经遍历过,但我们不能排除硬件老化、网络线路或者人为误 操作等主要故障。为了避免调度器失效而导致整个系统不能工作,我们需要设立一个从调度器作为主调度器的备份。两个心跳(Hear
13、tbeat)进程6分 别在主、从调度器上运行,它们通过串口线和 UDP 等心跳线来相互定时地汇报各自的健康状况。当从调度器不能听得主调度器的心跳时,从调度器通过 ARP 欺骗 ( Gratuitous ARP)来接管集群对外的 Virtual IP Address,同时接管主调度器的工作来提供负载调度服务。当主调度器恢复时,这里有两种方法,一是主调度器自动变成从调度器,二是从调度器释放 Virtual IP Address,主调度器收回 Virtual IP Address 并提供负载调度服务。这里,多条心跳线可以使得因心跳线故障导致误判(即从调度器认为主调度器已经失效,其实主调度器还在正常工
14、作)的概论 降到最低。通常,当主调度器失效时,主调度器上所有已建立连接的状态信息将丢失,已有的连接会中断。客户需要向重新连接,从调度器才会将新连接调 度到各个服务器上,这对客户会造成一定的不便。为此,IPVS 调度器在 Linux 内核中实现一种高效状态同步机制,将主调度器的状态信息及时地同步到从调度器。当从调度器接管时,绝大部分已建立的连接会持续下去。3.可伸缩 Web 服务基于 LVS 的 Web 集群的体系结构如图 2 所示:第一层是负载调度器,一般采用 IP 负载均衡技术,可以使得整个系统有较高的吞吐率;第二层是 Web 服务器池,在每个结点上可以分别运行 HTTP服务或 HTTPS
15、服务、或者两者都运行;第三层是共享存储,它可以是数据库,可以是网络文件系统或分布 式文件系统,或者是三者的混合。集群中各结点是通过高速网络相连接的。图 2:基于 LVS 的 Web 集群对于动态页面(如 PHP、 JSP 和 ASP 等),需要访问的动态数据一般存储在数据库服务器中。数据库服务运行在独立的服务器上,为所有 Web 服务器 共享。无论同一 Web 服务器上多个动态页面访问同一数据,还是不同 Web 服务器上多个动态页面访问同一数据,数据库服务器有锁机制使得这些访问有序地进 行,从而保证数据的一致性。对于静态的页面和文件(如 HTML 文档和图片等),可以存储在网络文件系统或者分布
16、式文件系统中。至于选择哪一种,看系统的规模和需求 而定。通过共享的网络文件系统或者分布式文件系统,Webmaster 可以看到统一的文档存储空间,维护和更新页面比较方便,对共享存储中页面的修改对所 有的服务器都有效。在这种结构下,当所有服务器结点超载时,管理员可以很快地加入新的服务器结点来处理请求,而无需将 Web 文档等复制到结点的本地硬盘上。有些 Web 服务可能用到 HTTP Cookie,它是将数据存储在客户的浏览器来追踪和标识客户的机制。使用 HTTP Cookie 后,来同一客户的不同连接存在相关性,这些连接必须被发送到同一 Web 服务器。一些 Web 服务使用安全的 HTTPS
17、 协议,它是 HTTP 协议加 SSL(Secure Socket Layer)协议。另有些 Web 服务可能使用安全的 HTTPS 协议,它是 HTTP 协议加 SSL 协议。当客户访问HTTPS 服务(HTTPS 的缺省端口为 443)时,会先建立一个 SSL 连接,来交换对称公钥加密的证书并协商一个 SSL Key,来加密以后的会话。在 SSL Key 的生命周期内,后续的所有 HTTPS连接都使用这个 SSL Key,所以同一客户的不同 HTTPS 连接也存在相关性。针对这些需要,IPVS调度器提供了持久服务的功能,它可以使得在设定的时间内,来自同一 IP 地 址的不同连接会被发送到集
18、群中同一个服务器结点,可以很好地解决客户连接的相关性问题。4.可伸缩媒体服务基于 LVS 的媒体集群的体系结构如图 3 所示:第一层是负载调度器,一般采用 IP 负载均衡技术,可以使得整个系统有较高的吞吐率;第二层是 Web 服务器池,在每个结点上可以运行相应的媒体服务;第三层是共享存储,通过网络文件系统/分布式文件系统存储媒体节目。集群中各结点是通过高速网络相 连接。图 3:基于 LVS 的媒体集群IPVS 负载调度器一般使用直接路由方法(即 VS/DR 方法,将在以后文章中详细叙述),来架构媒体集群系统。调度器将媒体服务请求较均衡地分发到 各个服务器上,而媒体服务器将响应数据直接返回给客户
19、,这样可以使得整个媒体集群系统具有很好的伸缩性。媒体服务器可以运行各种媒体服务软件。目前,LVS 集群对于 Real Media、Windows Media 和Apple Quicktime 媒体服务都有很好的支持,都有真实的系统在运行。一般来说,流媒体服务都会使用一个 TCP 连接(如 RTSP 协议:Real-Time Streaming Protocol)进行带宽的协商和流速的控制,通过 UDP 将流数据返回客户。这里, IPVS 调度器提供功能将 TCP 和 UDP 集中考虑,保证来自同一客户 的媒体 TCP 和 UDP 连接会被转发到集群中同一台媒体服务器,使得媒体服务准确无误地进行
20、。共享存储是媒体集群系统中最关键的问题,因为媒体文件往往非常大(一部片子需要几百兆到几千兆的存储空间),这对存储的容量和读的速度 有较高的要求。对于规模较小的媒体集群系统,例如有 3 至 6 个媒体服务器结点,存储系统可以考虑用带千兆网卡的 Linux 服务器,使用软件 RAID 和日志型 文件系统,再运行内核的 NFS 服务,会有不错的效果。对于规模较大的媒体集群系统,最好选择对文件分段(File Stripping)存储和文件缓存有较好支持的分布式文件系统;媒体文件分段存储在分布式文件系统的多个存储结点上,可以提高文件系统的性能和存储结点 间的负载均衡;媒体文件在媒体服务器上自动地被缓存,
21、可提高文件的访问速度。否则,可以考虑自己在媒体服务器上开发相应的工具,如缓存工具能定时地统计出 最近的热点媒体文件,将热点文件复制到本地硬盘上,并替换缓存中的非热点文件,最后通知其他媒体服务器结点它所缓存的媒体文件以及负载情况;在媒体服务器 上有应用层调度工具,它收到客户的媒体服务请求,若所请求的媒体文件缓存在本地硬盘上,则直接转给本地媒体服务进程服务,否则先考虑该文件是否被其他媒体 服务器缓存;如该文件被其他服务器缓存并且该服务器不忙,则将请求转给该服务器上的媒体服务进程处理,否则直接转给本地媒体服务进程,从后端的共享存储中 读出媒体文件。共享存储的好处是媒体文件的管理人员看到统一的存储空间
22、,使得媒体文件维护工作比较方便。当客户访问不断增加使得整个系统超载时,管理员可以很快地加入新的媒体服务器结点来处理请求。Real 公司以其高压缩比的音频视频格式、Real 媒体服务器和媒体播放器 RealPlayer 而闻名。Real 公司正在使用以上结构将由 20 多台服务器组成的 LVS 可伸缩 Web 和媒体集群,为其全球用户提供 Web 和音频视频服务。 Real 公司的高级技术主管声称 LVS 击败所有他们尝试过的 商品化负载均衡产品7。5.可伸缩 Cache 服务有效的网络 Cache 系统可以大大地减少网络流量、降低响应延时以及服务器的负载。但是,若Cache 服务器超载而不能及
23、时地处理请求,反 而会增加响应延时。所以, Cache 服务的可伸缩性很重要,当系统负载不断增长时,整个系统能被扩展来提高 Cache 服务的处理能力。尤其,在主干网上的 Cache 服务可能需要几个 Gbps 的吞吐率,单台服务器(例如 SUN 目前最高端的Enterprise 10000 服务器)远不能达到这个吞吐率。可见,通过 PC 服务器集群实现可伸缩Cache 服务是很有效的方法,也是性能价格比最高的方法。基于 LVS 的 Cache 集群的体系结构如图 4 所示:第一层是负载调度器,一般采用 IP 负载均衡技术,可以使得整个系统有较高的吞吐率; 第二层是 Cache 服务器池,一般
24、 Cache 服务器放置在接近主干 Internet 连接处,它们可以分布在不同的网络中。调度器可以有多个,放在离客户接 近的地方。图 4:基于 LVS 的 Cache 集群IPVS 负载调度器一般使用 IP 隧道方法(即 VS/TUN 方法,将在以后文章中详细叙述),来架构Cache 集群系统,因为 Cache 服务器可能被 放置不同的地方(例如在接近主干 Internet 连接处),而调度器与 Cache 服务器池可能不在同一个物理网络中。采用 VS/TUN 方法,调度器只调度 Web Cache 请求,而 Cache 服务器将响应数据直接返回给客户。在请求对象不能在本地命中的情况下,Ca
25、che 服务器要向源服务器发请求,将结果取回,最 后将结果返回给客户;若采用 NAT 技术的商品化调度器,需要四次进出调度器,完成这个请求。而用 VS/TUN 方法(或者 VS/DR 方法),调度器只调度一 次请求,其他三次都由 Cache 服务器直接访问 Internet 完成。所以,这种方法对 Cache 集群系统特别有效。Cache 服务器采用本地硬盘来存储可缓存的对象,因为存储可缓存的对象是写操作,且占有一定的比例,通过本地硬盘可以提高 I/O 的访 问速度。Cache 服务器间有专用的多播通道(Multicast Channel),通过 ICP 协议(Internet Cache P
26、rotocol)来交互信息。当一台 Cache 服务器在本地硬盘中未命中当前请求时,它可以通过 ICP 查询其他 Cache 服务器是否有请求对象的副本, 若存在,则从邻近的 Cache 服务器取该对象的副本,这样可以进一步提高 Cache 服务的命中率。为 150 多所大学和地区服务的英国国家 JANET Web Cache 网在 1999 年 11 月用以上 LVS 结构实现可伸缩的 Cache 集群8,只用了原有 50 多台相互独立 Cache 服务器的一半,用户反映网络速 度跟夏天一样快(学生放暑假)。可见,通过负载调度可以摸平单台服务器访问的毛刺(Burst),提高整个系统的资源利用
27、率。6.可伸缩邮件服务随着 Internet 用户不断增长,很多 ISP 面临他们邮件服务器超载的问题。当邮件服务器不能容纳更多的用户帐号时,有些 ISP 买更高档 的服务器来代替原有的,将原有服务器的信息(如用户邮件)迁移到新服务器是很繁琐的工作,会造成服务的中断;有些 ISP 设置新的服务器和新的邮件域名,新 的邮件用户放置在新的服务器上,如上海电信现在用不同的邮件服务器、 到 放置用户的邮件帐号,这样静态地将用户分割到不同的服务器上,会造成邮件服务器负载不平衡,系统的资源利用率低,对 用户来说邮件的地址比较难记。图 5:基于 LVS 的可伸缩邮件集群可以利用 LVS 框架实现高可伸缩、
28、高可用的邮件服务系统。它的体系结构如图 5 所示:在前端是一个采用 IP 负载均衡技术的负载调度器;第二层 是服务器池,有 LDAP(Light-weight Directory Access Protocol)服务器和一组邮件服务器。第三层是数据存储,通过分布式文件系统来存储用户的邮件。集群中各结点是通过高速网络相连接。用户的信息如用户名、口令、主目录和邮件容量限额等存储在 LDAP 服务器中,可以通过 HTTPS让管理员进行用户管理。在各个邮件服务 器上运行 SMTP(Simple Mail Transfer Protocol)、POP3(Post Office Protocol vers
29、ion 3)、IMAP4(Internet Message Access Protocol version 4)和 HTTP/HTTPS 服务。SMTP 接受和转发用户的邮件,SMTP 服务进程查询 LDAP 服务器获得用户信息,再存储邮件。POP3 和 IMAP4 通 过 LDAP 服务器获得用户信息,口令验证后,处理用户的邮件访问请求。这里,需要有机制避免不同服务器上的 SMTP、POP3 和 IMAP4 服务进程对用户 邮件的读写冲突。HTTP/HTTPS 服务是让用户通过浏览器可以访问邮件。IPVS 调度器将 SMTP、POP3、IMAP4 和 HTTP/HTTPS 请求流负载较均衡地
30、分发到各邮件服务器上,从上面各服务的处理 流程来看,不管请求被发送到哪一台邮件服务器处理,其结果是一样的。这里,将 SMTP、POP3、IMAP4 和 HTTP/HTTPS 运行在各个邮件服务器 上进行集中调度,有利于提高整个系统的资源利用率。系统中可能的瓶颈是 LDAP 服务器,对 LDAP 服务中 B+树的参数进行优化,再结合高端的服务器,可以获得较高的性能。若分布式文件系 统没有多个存储结点间的负载均衡机制,则需要相应的邮件迁移机制来避免邮件访问的倾斜。这样,这个集群系统对用户来说就像一个高性能、高可靠的邮件服务器(例如上海电信只要用一个邮件域名 就可以)。当邮件用户不断增长时,只要在
31、集群中增加服务器结点和存储结点。用户信息的集中存储使得用户管理变得容易, 且集群系统有利于提高资源利用率。7.小结本文给出 LVS 集群的通用体系结构,并讨论了它的设计原则和相应的特点;最后将 LVS 集群应用于建立可伸缩的 Web、Media、 Cache 和 Mail 网络服务,并指出了系统架设时应注意的要点。我们将在后续的文章中详细解释 LVS 集群的技术、实现和应用。 Linux 服务器集群系统(三)LVS 集群中的 IP 负载均衡技术本文在分析服务器集群实现虚拟网络服务的相关技术上,详细描述了 LVS 集群中实现的三种 IP 负载均衡技术(VS/NAT、VS/TUN 和 VS/DR)
32、的工作原理,以及它们的优缺点。1.前言在 前面文章中,讲述了可伸缩网络服务的几种结构,它们都需要一个前端的负载调度器(或者多个进行主从备份)。我们先分析实现虚拟网络服务的主要技术,指出 IP 负载均衡技术是在负载调度器的实现技术中效率最高的。在已有的 IP 负载均衡技术中,主要有通过网络地址转换(Network Address Translation)将一组服务器构成一个高性能的、高可用的虚拟服务器,我们称之为VS/NAT 技术(Virtual Server via Network Address Translation)。在分析 VS/NAT 的缺点和网络服务的非对称性的基础上,我们提出了通
33、过 IP 隧道实现虚拟服务器的方法 VS/TUN (Virtual Server via IP Tunneling),和通过直接路由实现虚拟服务器的方法 VS/DR(Virtual Server via Direct Routing),它们可以极大地提高系统的伸缩性。 VS/NAT、VS/TUN 和VS/DR 技术是 LVS 集群中实现的三种 IP 负载均衡技术,我们将在文 章中详细描述它们的工作原理和各自的优缺点。在以下描述中,我们称客户的 socket 和服务器的 socket 之间的数据通讯为连接,无论它们是使用TCP 还是 UDP 协议。下面简述当前用服务器集群实现高可伸缩、高可用网络
34、服务的几种负载调度方法,并列举几个在这方面有代表性的研究项目。2.实现虚拟服务的相关方法在网络服务中,一端是客户程序,另一端是服务程序,在中间可能有代理程序。由此看来,可以在不同的层次上实现多台服务器的负载均衡。用集群解决网络服务性能问题的现有方法主要分为以下四类。2.1. 基于 RR-DNS 的解决方法NCSA 的可伸缩的 WEB 服务器系统就是最早基于 RR-DNS(Round-Robin Domain Name System)的原型系统 1,2。它的结构和工作流程如下图所示:图 1:基于 RR-DNS 的可伸缩 WEB 服务器 (注:本图来自文献【9】)有 一组 WEB 服务器,他们通过
35、分布式文件系统 AFS(Andrew File System)来共享所有的 HTML文档。这组服务器拥有相同的域名(如 www.ncsa.uiuc.edu),当用户按照这个域名访问时, RR-DNS 服务器会把域名轮流解析到这组服务器的不同 IP 地址,从而将访问负载分到各台服务器上。这种方法带来几个问题。第一,域名服务 器是一个分布式系统,是按照一定的层次结构组织的。当用户就域名解析请求提交给本地的域名服务器,它会因不能直接解析而向上一级域名服务器提交,上一级域 名服务器再依次向上提交,直到 RR-DNS 域名服器把这个域名解析到其中一台服务器的IP 地址。可见,从用户到 RR-DNS 间存
36、在多台域名服器,而它们都 会缓冲已解析的名字到 IP 地址的映射, 这会导致该域名服器组下所有用户都会访问同一 WEB 服务器,出现不同 WEB 服务器间严重的负载不平衡。为了保证在域 名服务器中域名到 IP 地址的映射不被长久缓冲,RR-DNS 在域名到 IP 地址的映射上设置一个 TTL(Time To Live)值,过了这一段时间,域名服务器将这个映射从缓冲中淘汰。当用户请求,它会再向上一级域名服器提交请求并进行重新影射。这就涉及到如何设置这个 TTL 值,若这个值太大,在这个 TTL 期间,很多请求会被映射到同一台 WEB 服务器上,同样会导致严重的负载不平衡。若这个值太小,例如是,会
37、导致本地 域名服务器频繁地向 RR-DNS 提交请求,增加了域名解析的网络流量,同样会使 RR-DNS 服务器成为系统中一个新的瓶颈。第二,用户机器 会缓冲从名字到 IP 地址的映射,而不受 TTL 值的影响,用户的访问请求会被送到同一台 WEB 服务器上。由于用户访问请求的突发性和访问方式不同,例如有的 人访问一下就离开了,而有的人访问可长达几个小时,所以各台服务器间的负载仍存在倾斜(Skew)而不能控制。假设用户在每个会话中平均请求数为 20,负 载最大的服务器获得的请求数额高于各服务器平均请求数的平均比率超过百分之三十。也就是说,当 TTL 值为 0 时,因为用户访问的突发性也会存在着较
38、严重的负 载不平衡。第三,系统的可靠性和可维护性差。若一台服务器失效,会导致将域名解析到该服务器的用户看到服务中断,即使用户按 “Reload”按钮,也无济于事。系统管理员也不能随时地将一台服务器切出服务进行系统维护,如进行操作系统和应用软件升级,这需要修改 RR-DNS 服 务器中的 IP 地址列表,把该服务器的 IP 地址从中划掉,然后等上几天或者更长的时间,等所有域名服器将该域名到这台服务器的映射淘汰,和所有映射到这台服 务器的客户机不再使用该站点为止。2.2. 基于客户端的解决方法基 于客户端的解决方法需要每个客户程序都有一定的服务器集群的知识,进而把以负载均衡的方式将请求发到不同的服
39、务器。例如,Netscape Navigator 浏览器访问 Netscape 的主页时,它会随机地从一百多台服务器中挑选第 N 台,最后将请求送往 。 然而,这不是很好的解决方法,Netscape 只是利用它的 Navigator 避免了 RR-DNS 解析的麻烦,当使用 IE 等其他浏览器不可避免的要进行 RR-DNS 解析。Smart Client3是 Berkeley 做的另一种基于客户端的解决方法。服务提供一个 Java Applet 在客户方浏览器中运行,Applet 向各个服务器发请求来收集服务器的负载等信息,再根据这些信息将客户的请求发到相应的服务器。高可用性也 在 Apple
40、t 中实现,当服务器没有响应时,Applet 向另一个服务器转发请求。这种方法的透明性不好,Applet 向各服务器查询来收集信息会增加额 外的网络流量,不具有普遍的适用性。2.3. 基于应用层负载均衡调度的解决方法多 台服务器通过高速的互联网络连接成一个集群系统,在前端有一个基于应用层的负载调度器。当用户访问请求到达调度器时,请求会提交给作负载均衡调度的应用程 序,分析请求,根据各个服务器的负载情况,选出一台服务器,重写请求并向选出的服务器访问,取得结果后,再返回给用户。应用层负载均衡调度 的典型代表有 Zeus 负载调度器4、pWeb5、Reverse-Proxy6和SWEB7等。Zeus
41、 负载调度器是 Zeus 公司的商业 产品,它是在 Zeus Web 服务器程序改写而成的,采用单进程事件驱动的服务器结构。pWeb 就是一个基于 Apache 1.1 服务器程序改写而成的并行 WEB 调度程序,当一个 HTTP 请求到达时, pWeb 会选出一个服务器,重写请求并向这个服务器发出改写后的请求,等结果 返回后,再将结果转发给客户。Reverse-Proxy 利用 Apache 1.3.1 中的 Proxy 模块和 Rewrite 模块实现一个可伸缩 WEB 服务器,它与 pWeb 的不同之处在于它要先从 Proxy 的 cache 中查找后,若 没有这个副本,再选一台服务器,
42、向服务器发送请求,再将服务器返回的结果转发给客户。SWEB 是利用 HTTP 中的 redirect 错误代码,将客户请求到 达一台 WEB 服务器后,这个 WEB 服务器根据自己的负载情况,自己处理请求,或者通过redirect 错误代码将客户引到另一台 WEB 服务器,以实现一个 可伸缩的 WEB 服务器。基于应用层负载均衡调度的多服务器解决方法也存在一些问题。第一,系统处理开销特别大,致使系统的伸缩性有限。当请 求到达负载均衡调度器至处理结束时,调度器需要进行四次从核心到用户空间或从用户空间到核心空间的上下文切换和内存复制;需要进行二次 TCP 连接,一次是 从用户到调度器,另一次是从调
43、度器到真实服务器;需要对请求进行分析和重写。这些处理都需要不小的、内存和网络等资源开销,且处理时间长。所构成系 统的性能不能接近线性增加的,一般服务器组增至 3 或 4 台时,调度器本身可能会成为新的瓶颈。所以,这种基于应用层负载均衡调度的方法的伸缩性极其有限。第 二,基于应用层的负载均衡调度器对于不同的应用,需要写不同的调度器。以上几个系统都是基于 HTTP 协议,若对于 FTP、Mail、POP3 等应用,都需 要重写调度器。2.4. 基于 IP 层负载均衡调度的解决方法用 户通过虚拟 IP 地址(Virtual IP Address)访问服务时,访问请求的报文会到达负载调度器,由它进行负
44、载均衡调度,从一组真实服务器选出一个,将报文的目标地址 Virtual IP Address 改写成选定服务器的地址,报文的目标端口改写成选定服务器的相应端口,最后将报文发送给选定的服务器。真实服务器的回应报文经过负载调度器 时,将报文的源地址和源端口改为 Virtual IP Address 和相应的端口,再把报文发给用户。Berkeley 的 MagicRouter8、Cisco 的LocalDirector、 Alteon 的 ACEDirector 和 F5 的 Big/IP 等都是使用网络地址转换方法。MagicRouter 是在 Linux 1.3 版本上应用快速报文插入技术,使得
45、进行负载均衡调度的用户进程访问网络设备接近核心空间的速度,降低了上下文切换的处理开销,但并不彻底,它只是研 究的原型系统,没有成为有用的系统存活下来。Cisco 的 LocalDirector、Alteon 的 ACEDirector 和 F5的 Big/IP 是非常 昂贵的商品化系统,它们支持部分 TCP/UDP 协议,有些在 ICMP 处理上存在问题。IBM 的 TCP Router9使用修改过的网络地址转换方法在 SP/2 系统实现可伸缩的 WEB 服务器。TCP Router 修改请求报文的目标地址并把它转发给选出的服务器,服务器能把响应报文的源地址置为 TCP Router 地址而非
46、自己的地址。这种方法的好处是响应报文可以直接返回给客户,坏处是每台服务器的操作系统内核都需要修改。IBM 的 NetDispatcher10是 TCP Router 的后继者,它将报文转发给服务器,而服务器在 non-ARP 的设备配置路由器的地址。这种方法与 LVS 集群中的 VS/DR 类似,它具有很高的 可伸缩性,但一套在 IBM SP/2 和 NetDispatcher 需要上百万美金。总的来说,IBM 的技术还挺不错的。在贝尔实验室的 ONE-IP11中,每台服务器都独立的 IP 地址,但都用 IP Alias 配置上同一 VIP地址,采用路由和广播两种方法分发请求,服务器收到请求后
47、按 VIP 地址处理请求,并以 VIP 为源地址返回结果。这种方法也是为 了避免回应报文的重写,但是每台服务器用 IP Alias 配置上同一VIP 地址,会导致地址冲突,有些操作系统会出现网络失效。通过广播分发请求,同样需要修改服务器操作系统的源码来过滤报文,使得只 有一台服务器处理广播来的请求。微软的 Windows NT 负载均衡服务( Windows NT Load Balancing Service,WLBS )12是1998 年底收购 Valence Research 公司获得的,它与 ONE-IP 中的基于本地过滤方法一样。WLBS 作为过滤器运行在网卡驱动程序和 TCP/IP
48、协议栈之间,获得目标地址 为 VIP 的报文,它的过滤算法检查报文的源 IP 地址和端口号,保证只有一台服务器将报文交给上一层处理。但是,当有新结点加入和有结点失效时,所有服务器 需要协商一个新的过滤算法,这会导致所有有 Session的连接中断。同时,WLBS 需要所有的服务器有相同的配置,如网卡速度和处理能力。3. 通过 NAT 实现虚拟服务器( VS/NAT)由 于 IPv4 中 IP 地址空间的日益紧张和安全方面的原因,很多网络使用保留 IP 地址(10.0.0.0/255.0.0.0、 172.16.0.0/255.128.0.0 和 192.168.0.0/255.255.0.0)
49、64, 65, 66。这些地址不在 Internet 上使用,而是专门为内部网络预留的。当内部网络中的主机要访问Internet 或被 Internet 访问时,就需要 采用网络地址转换(Network Address Translation, 以下简称 NAT),将内部地址转化为 Internets 上可用的外部地址。NAT 的工作原理是报文头(目标地址、源地址和端口等)被正确改写后,客户相信 它们连接一个 IP 地址,而不同 IP 地址的服务器组也认为它们是与客户直接相连的。由此,可以用 NAT 方法将不同 IP 地址的并行网络服务变成在一个 IP 地址 上的一个虚拟服务。VS/NAT 的体系结构如图 2 所示。在一组服务器前有一个调度器,它们是通过 Switch/HUB 相连接的。这些服务器 提供相同的网络服务、相同的内容,即不管请求被发送到哪一台服务器,执行结果是一样的。服务的内容可以复制到每台服务器的本地硬盘上,可以通过网络文件系 统(如NFS)共享,也可以通过一个分布式文件系统来提供。图 2:VS/NAT