LVS集群
章文嵩 ([email protected])
2002 年 3 月
本文介绍了Linux服务器集群系统――LVS（Linux Virtual Server）项目的产生背景和目标，并描述了LVS服务器集群框架及目前提供的软件，列举LVS集群系统的特点和一些实际应用，最后，本文谈论了LVS项目的开发进展和开发感触。
当今计算机技术已进入以网络为中心的计算时期。由于客户/服务器模型的简单性、易管理性和易维护性，客户/服务器计算模式在网上被大量采用。在九十年代中 期，万维网（World Wide Web）的出现以其简单操作方式将图文并茂的网上信息带给普通大众，Web也正在从一种内容发送机制成为一种服务平台，大量的服务和应用（如新闻服务、网 上银行、电子商务等）都是围绕着Web进行。这促进Internet用户剧烈增长和Internet流量爆炸式地增长，图1显示了1995至2000年与 Internet连接主机数的变化情况[1]，可见增长趋势较以往更迅猛。
图1：1995至2000年Internet主机数的变化
Internet的飞速发展给网络带宽和服务器带来巨大的挑战。从网络技术的发展来看，网络带宽的增长远高于处理器速度和内存访问速度的增长，如100M Ethernet、ATM、Gigabit Ethernet等不断地涌现，10Gigabit Ethernet即将就绪，在主干网上密集波分复用（DWDM）将成为宽带IP的主流技术[2,3]，Lucent已经推出在一根光纤跑800Gigabit的WaveStar? OLS 800G产品[4]。所以，我们深信越来越多的瓶颈会出现在服务器端。很多研究显示Gigabit Ethernet在服务器上很难使得其吞吐率达到1Gb/s的原因是协议栈（TCP/IP）和操作系统的低效，以及处理器的低效，这需要对协议的处理方法、操作系统的调度和IO的处理作更深入的研究。在高速网络上，重新设计单台服务器上的网络服务程序也是个重要课题。
比较热门的站点会吸引前所未有的访问流量，例如根据Yahoo的新闻发布，Yahoo已经每天发送6.25亿页面[5]。一些网络服务也收到巨额的流量， 如American Online的Web Cache系统每天处理50.2亿个用户访问Web的请求，每个请求的平均响应长度为5.5Kbytes。与此同时，很多网络服务因为访问次数爆炸式地增 长而不堪重负，不能及时处理用户的请求，导致用户进行长时间的等待，大大降低了服务质量。如何建立可伸缩的网络服务来满足不断增长的负载需求已成为迫在眉 睫的问题。
大部分网站都需要提供每天24小时、每星期7天的服务，对电子商务等网站尤为突出，任何服务中断和关键性的数据丢失都会造成直接的商业损失。例如，根据 Dell的新闻发布[6]，Dell现在每天在网站上的交易收入为一千四百万美元，一个小时的服务中断都会造成平均五十八万美元的损失。所以，这对网络服 务的可靠性提出了越来越高的要求。
现在Web服务中越来越多地使用CGI、动态主页等CPU密集型应用，这对服务器的性能有较高要求。未来的网络服务会提供更丰富的内容、更好的交互性、更高的安全性等，需要服务器具有更强的CPU和I/O处理能力。例如，通过HTTPS（Secure HTTP）取一个静态页面需要的处理性能比通过HTTP的高一个数量级，HTTPS正在被电子商务站点广为使用。所以，网络流量并不能说明全部问题，要考虑到应用本身的发展也需要越来越强的处理性能。
因此，对用硬件和软件方法实现高可伸缩、高可用网络服务的需求不断增长，这种需求可以归结以下几点：
- 可伸缩性（Scalability），当服务的负载增长时，系统能被扩展来满足需求，且不降低服务质量。
- 高可用性（Availability），尽管部分硬件和软件会发生故障，整个系统的服务必须是每天24小时每星期7天可用的。
- 可管理性（Manageability），整个系统可能在物理上很大，但应该容易管理。
- 价格有效性（Cost-effectiveness），整个系统实现是经济的、易支付的。
对称多处理（Symmetric Multi-Processor，简称SMP）是由多个对称的处理器、和通过总线共享的内存和I/O部件所组成的计算机系统。SMP是一种低并行度的结构，是我们通常所说的"紧耦合多处理系统"，它的可扩展能力有限，但SMP的优点是单一系统映像（Single System Image），有共享的内存和I/O，易编程。
由于SMP的可扩展能力有限，SMP服务器显然不能满足高可伸缩、高可用网络服务中的负载处理能力不断增长需求。随着负载不断增长，会导致服务器不断地升 级。这种服务器升级有下列不足：一是升级过程繁琐，机器切换会使服务暂时中断，并造成原有计算资源的浪费；二是越往高端的服务器，所花费的代价越大；三是 SMP服务器是单一故障点（Single Point of Failure），一旦该服务器或应用软件失效，会导致整个服务的中断。
通过高性能网络或局域网互联的服务器集群正成为实现高可伸缩的、高可用网络服务的有效结构。这种松耦合结构的服务器集群系统有下列优点：
-
性能
网络服务的工作负载通常是大量相互独立的任务，通过一组服务器分而治之，可以获得很高的整体性能。 -
性能/价格比
组成集群系统的PC服务器或RISC服务器和标准网络设备因为大规模生产降低成本，价格低，具有最高的性能/价格比。若整体性能随着结点数的增长而接近线性增加，该系统的性能/价格比接近于PC服务器。所以，这种松耦合结构比紧耦合的多处理器系统具有更好的性能/价格比。 -
可伸缩性
集群系统中的结点数目可以增长到几千个，乃至上万个，其伸缩性远超过单台超级计算机。 -
高可用性
在硬件和软件上都有冗余，通过检测软硬件的故障，将故障屏蔽，由存活结点提供服务，可实现高可用性。
当然，用服务器集群系统实现可伸缩网络服务也存在很多挑战性的工作：
-
透明性（Transparency）
如何高效地使得由多个独立计算机组成的松藕合的集群系统构成一个虚拟服务器；客户端应用程序与集群系统交互时，就像与一台高性能、高可用的服务器交互一样，客户端无须作任何修改。部分服务器的切入和切出不会中断服务，这对用户也是透明的。 -
性能（Performance）
性能要接近线性加速，这需要设计很好的软硬件的体系结构，消除系统可能存在的瓶颈。将负载较均衡地调度到各台服务器上。 -
高可用性（Availability）
需要设计和实现很好的系统资源和故障的监测和处理系统。当发现一个模块失败时，要这模块上提供的服务迁移到其他模块上。在理想状况下，这种迁移是即时的、自动的。 -
可管理性（Manageability）
要使集群系统变得易管理，就像管理一个单一映像系统一样。在理想状况下，软硬件模块的插入能做到即插即用（Plug & Play）。 -
可编程性（Programmability）
在集群系统上，容易开发应用程序。
针对高可伸缩、高可用网络服务的需求，我们给出了基于IP层和基于内容请求分发的负载平衡调度解决方法，并在Linux内核中实现了这些方法，将一组服务器构成一个实现可伸缩的、高可用网络服务的虚拟服务器。
虚拟服务器的体系结构如图2所示，一组服务器通过高速的局域网或者地理分布的广域网相互连接，在它们的前端有一个负载调度器（Load Balancer）。负载调度器能无缝地将网络请求调度到真实服务器上，从而使得服务器集群的结构对客户是透明的，客户访问集群系统提供的网络服务就像访 问一台高性能、高可用的服务器一样。客户程序不受服务器集群的影响不需作任何修改。系统的伸缩性通过在服务机群中透明地加入和删除一个节点来达到，通过检 测节点或服务进程故障和正确地重置系统达到高可用性。由于我们的负载调度技术是在Linux内核中实现的，我们称之为Linux虚拟服务器（Linux Virtual Server）。
图2：虚拟服务器的结构
在1998年5月，我成立了Linux Virtual Server的自由软件项目，进行Linux服务器集群的开发工作。同时，Linux Virtual Server项目是国内最早出现的自由软件项目之一。
Linux Virtual Server项目的目标 ：使用集群技术和Linux操作系统实现一个高性能、高可用的服务器，它具有很好的可伸缩性（Scalability）、可靠性（Reliability）和可管理性（Manageability）。
目前，LVS项目已提供了一个实现可伸缩网络服务的Linux Virtual Server框架，如图3所示。在LVS框架中，提供了含有三种IP负载均衡技术的IP虚拟服务器软件IPVS、基于内容请求分发的内核Layer-7交 换机KTCPVS和集群管理软件。可以利用LVS框架实现高可伸缩的、高可用的Web、Cache、Mail和Media等网络服务；在此基础上，可以开 发支持庞大用户数的、高可伸缩的、高可用的电子商务应用。
图3：Linux虚拟服务器框架
3.1 IP虚拟服务器软件IPVS
在调度器的实现技术中，IP负载均衡技术是效率最高的。在已有的IP负载均衡技术中有通过网络地址转换（Network Address Translation）将一组服务器构成一个高性能的、高可用的虚拟服务器，我们称之为VS/NAT技术（Virtual Server via Network Address Translation），大多数商品化的IP负载均衡调度器产品都是使用此方法，如Cisco的LocalDirector、F5的Big/IP和 Alteon的ACEDirector。在分析VS/NAT的缺点和网络服务的非对称性的基础上，我们提出通过IP隧道实现虚拟服务器的方法VS/TUN （Virtual Server via IP Tunneling），和通过直接路由实现虚拟服务器的方法VS/DR（Virtual Server via Direct Routing），它们可以极大地提高系统的伸缩性。所以，IPVS软件实现了这三种IP负载均衡技术，它们的大致原理如下（我们将在其他章节对其工作原 理进行详细描述），
-
Virtual Server via Network Address Translation（VS/NAT）
通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。 -
Virtual Server via IP Tunneling（VS/TUN）
采用NAT技术时，由于请求和响应报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。为了解决这个问题，调度器把请求报 文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多，采用 VS/TUN技术后，集群系统的最大吞吐量可以提高10倍。 -
Virtual Server via Direct Routing（VS/DR）
VS/DR通过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。同VS/TUN技术一样，VS/DR技术可极大地 提高集群系统的伸缩性。这种方法没有IP隧道的开销，对集群中的真实服务器也没有必须支持IP隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连 在同一物理网段上。
针对不同的网络服务需求和服务器配置，IPVS调度器实现了如下八种负载调度算法：
-
轮叫（Round Robin）
调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。 -
加权轮叫（Weighted Round Robin）
调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。 -
最少链接（Least Connections）
调度器通过"最少连接"调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载。 -
加权最少链接（Weighted Least Connections）
在集群系统中的服务器性能差异较大的情况下，调度器采用"加权最少链接"调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。 -
基于局部性的最少链接（Locality-Based Least Connections）
"基于局部性的最少链接" 调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器 是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用"最少链接"的原则选出一个可用的服务 器，将请求发送到该服务器。 -
带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）
"带复制的基于局部性最少链接"调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个 目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务 器组，按"最小连接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器，若服务器超载；则按"最小连接"原则从这个集群中选出一 台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的 程度。 -
目标地址散列（Destination Hashing）
"目标地址散列"调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。 -
源地址散列（Source Hashing）
"源地址散列"调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
3.2 内核Layer-7交换机KTCPVS
在基于IP负载调度技术中，当一个TCP连接的初始SYN报文到达时，调度器就选择一台服务器，将报文转发给它。此后通过查发报文的IP和TCP报文头地 址，保证此连接的后继报文被转发到该服务器。这样，IPVS无法检查到请求的内容再选择服务器，这就要求后端服务器组提供相同的服务，不管请求被发送到哪 一台服务器，返回结果都是一样的。但是，在有些应用中后端服务器功能不一，有的提供HTML文档，有的提供图片，有的提供CGI，这就需要基于内容的调度 (Content-Based Scheduling)。
由于用户空间TCP Gateway的开销太大，我们提出在操作系统的内核中实现Layer-7交换方法，来避免用户空间与核心空间的切换和内存复制的开销。在Linux操作系统的内核中，我们实现了Layer-7交换，称之为KTCPVS（Kernel TCP Virtual Server）。目前，KTCPVS已经能对HTTP请求进行基于内容的调度，但它还不很成熟，在其调度算法和各种协议的功能支持等方面，有大量的工作需要做。
虽然应用层交换处理复杂，它的伸缩性有限，但应用层交换带来以下好处：
- 相同页面的请求被发送到同一服务器，可以提高单台服务器的Cache命中率。
- 一些研究[5]表明WEB访问流中存在局部性。Layer-7交换可以充分利用访问的局部性，将相同类型的请求发送到同一台服务器，使得每台服务器收到的请求具有更好的相似性，可进一步提高单台服务器的Cache命中率。
- 后端服务器可运行不同类型的服务，如文档服务，图片服务，CGI服务和数据库服务等。
LVS集群的特点可以归结如下：
-
功能
有实现三种IP负载均衡技术和八种连接调度算法的IPVS软件。在IPVS内部实现上，采用了高效的Hash函数和垃圾回收机制，能正确处理所调度报文相 关的ICMP消息（有些商品化的系统反而不能）。虚拟服务的设置数目没有限制，每个虚拟服务有自己的服务器集。它支持持久的虚拟服务（如HTTP Cookie和HTTPS等需要该功能的支持），并提供详尽的统计数据，如连接的处理速率和报文的流量等。针对大规模拒绝服务（Deny of Service）攻击，实现了三种防卫策略。
有基于内容请求分发的应用层交换软件KTCPVS，它也是在Linux内核中实现。有相关的集群管理软件对资源进行监测，能及时将故障屏蔽，实现系统的高可用性。主、从调度器能周期性地进行状态同步，从而实现更高的可用性。 -
适用性
后端服务器可运行任何支持TCP/IP的操作系统，包括Linux，各种Unix（如FreeBSD、Sun Solaris、HP Unix等），Mac/OS和Windows NT/2000等。
负载调度器能够支持绝大多数的TCP和UDP协议：
无需对客户机和服务器作任何修改，可适用大多数Internet服务。协议 内 容 TCP HTTP，FTP，PROXY，SMTP，POP3，IMAP4，DNS，LDAP，HTTPS，SSMTP等 UDP DNS，NTP，ICP，视频、音频流播放协议等
-
性能
LVS服务器集群系统具有良好的伸缩性，可支持几百万个并发连接。配置100M网卡，采用VS/TUN或VS/DR调度技术，集群系统的吞吐量可高达1Gbits/s；如配置千兆网卡，则系统的最大吞吐量可接近10Gbits/s。 -
可靠性
LVS服务器集群软件已经在很多大型的、关键性的站点得到很好的应用，所以它的可靠性在真实应用得到很好的证实。有很多调度器运行一年多，未作一次重启动。 -
软件许可证
LVS集群软件是按GPL（GNU Public License）许可证发行的自由软件，这意味着你可以得到软件的源代码，有权对其进行修改，但必须保证你的修改也是以GPL方式发行。
LVS项目从成立到现在为止，受到不少关注，LVS集群系统已被应用于很多重负载的站点，就我所知该系统已在美、英、德、澳等国的几十个站点上正式使用。
我们没有上百台机器和高速的网络来实际测试LVS的终极性能，所以举LVS的应用实例来说明LVS的高性能和稳定性。我们所知的一些大型LVS应用实例如下：
-
英国国家JANET Cache Service（wwwcache.ja.net）是为英国150所以上的大学提供Web Cache服务。他们用28个结点的LVS集群代替了原有现50多台相互独立的Cache服务器，用他们的话说现在速度就跟夏天一样，因为夏天是放假期间没有很多人使用网络。
-
Linux的门户站点（www.linux.com）用LVS将很多台VA Linux SMP服务器组成高性能的WEB服务，已使用将近一年。
-
SourceForge（sourceforge.net）是在全球范围内为开发源码项目提供WEB、FTP、Mailing List和CVS等服务，他们也使用LVS将负载调度到十几台机器上。
-
世界上最大的PC制造商之一采用了两个LVS集群系统，一个在美洲，一个在欧洲，用于网上直销系统。
-
以RealPlayer提供音频视频服务而闻名的Real公司（www.real.com）使用由20台服务器组成的LVS集群，为其全球用户提供音频视频服务。在2000年3月时，整个集群系统已收到平均每秒20,000个连接的请求流。
-
NetWalk（www.netwalk.com）用多台服务器构造LVS系统，提供1024个虚拟服务，其中本项目的一个美国镜像站点（www.us.linuxvirtualserver.org）。
-
RedHat（www.redhat.com）从其6.1发行版起已包含LVS代码，他们开发了一个LVS集群管理工具叫Piranha，用于控制LVS集群，并提供了一个图形化的配置界面。
-
VA Linux（www.valinux.com）向客户提供基于LVS的服务器集群系统，并且提供相关的服务和支持。
-
TurboLinux的"世界一流Linux集群产品"TurboCluster实际上是基于LVS的想法和代码的，只是他们在新闻发布和产品演示时忘了致谢 。
-
红旗Linux和中软都提供基于LVS的集群解决方案，并在2000年9月召开的Linux World China 2000上展示。
在这里，再引用两位LVS用户的评论，来进一步说明LVS的性能和可靠性。
"We tried virtually all of the commercial load balancers, LVS beats them all for reliability, cost, manageability, you-name-it." — Jerry Glomph Black, Director, Internet & Technical Operations, Real Networks, Se attle Washington, USA
http://archive.linuxvirtualserver.org/html/lvs-users/2000-03/msg00180.html
http://marc.theaimsgroup.com/?1=linux-virtual-server&m=95385809030794&w=2
"I can say without a doubt that lvs toasts F5/BigIP solutions, at least in our real world implementations. I wouldn't trade a good lvs box for a Cisco Local Director either." — Drew Streib, Information Architect, VA Linux Systems, USA
http://archive.linuxvirtualserver.org/html/lvs-users/2000-03/msg00178.html
http://marc.theaimsgroup.com/?1=linux-virtual-server&m=95385694529750&w=2
LVS项目于1998年5月在网站上发布IPVS第一个版本源程序，一直得到了来自 Internet 的用户和开发者的鼓励和支持。应该说，刚开始发布的程序是非常简单的，由于用户的使用、反馈和期望，让我觉得这项工作的价值，并不断地化时间对该软件添加 新功能和完善，其中也得到其他开发者的帮助，所以该软件逐渐发展成为功能较齐全、有用的系统，这远远超出我当初成立项目时的想象。在这里，我要感谢 Julian Anastasov提供了很多系统的Bug fixes和改进，Joseph Mack博士编写了LVS HOWTO文档；还感谢一些厂商赞助我开发（如硬件设备等），和赞助我多次出国作相关的技术报告。
目前，正在进行的 LVS项目开发工作包括：
-
扩充IPVS对其他传输协议的支持，如AH（Authentication Header）和ESP（Encapsulating Security Payload ）等，这样IPVS调度器将实现IPSec的服务器集群。
-
提供一个统一的、功能较完善、更灵活的LVS集群管理软件。
-
扩充和改进KTCPVS的调度算法和多种协议的支持，使之功能较完备和系统更稳定。
-
在TCP粘合（TCP Splicing）和TCP转移（TCP Handoff）等方面，做一些尝试性工作，进一步改进LVS集群中的应用层调度。
最后，我谈一下自己多年来做自由软件开发的几点感触。一是通过自由软件方式可以使得软件具有顽强的生命力；我以前也做过几个独立的系统，如在SUN上用 Common Lisp开发的知识库系统和基于C++的对象数据库系统，有些地方也是做得非常漂亮的（如元级反射机制和对象的关系处理），但因为种种原因这些软件没有以 开放源码方式发布，现在它们在我导师的软件仓库里已无人问津，我也已经忘记里面的实现细节；而LVS项目是我做着玩的，一开始只是个很简单的程序，通过自 由软件的发布和开发，它发展成一个有用的、功能较齐全的软件，体现了自由软件的强大生命力。二是通过自由软件的集市开发，可以使得初始的想法不断地深入， 可以学到很多东西。三是做自由软件后时间会更有效率，由于用户的反馈和期待，会自觉不断地改进和完善系统，于是没有时间去玩游戏和网上聊天。四是做自由软 件会使得你有一点点成就感，每当收到用户的致谢和想到你的软件在实际系统中运行，会有一点满足。所以，行动起来吧，花一些时间做自由软件，你会有意想不到 的收获。
如果你对LVS项目感兴趣，请访问Linux Vritual Server项目的主页（http://www.LinuxVirtualServer.org/或者http://www.linux-vs.org/），你可以获得最新的 LVS 源代码和有关运行软件，及最新的文档资料。
如果你在使用LVS 的过程中遇到困难，请订阅我们的邮件列表[email protected]，提问、解答或者发表你的高见。
LVS集群的体系结构
章文嵩 ([email protected])
2002 年 4 月
本文主要介绍了LVS集群的体系结构。先给出LVS集群的通用体系结构，并讨论了其的设计原则和相应的特点；最后将LVS集群应用于建立可伸缩的Web、Media、Cache和Mail等网络服务。
1.引言
在过去的十几年中，Internet从几个研究机构相连为信息共享的网络发展成为拥有大量应用和服务的全球性网络，它正成为人们生活中不可缺少的 一部分。虽然Internet发展速度很快，但建设和维护大型网络服务依然是一项挑战性的任务，因为系统必须是高性能的、高可靠的，尤其当访问负载不断增 长时，系统必须能被扩展来满足不断增长的性能需求。由于缺少建立可伸缩网络服务的框架和设计方法，这意味着只有拥有非常出色工程和管理人才的机构才能建立 和维护大型的网络服务。
针对这种情形，本文先给出LVS集群的通用体系结构，并讨论了其的设计原则和相应的特点；最后将LVS集群应用于建立可伸缩的Web、Media、Cache和Mail等网络服务。
2.LVS集群的通用体系结构
LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服 务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。
图1：LVS集群的体系结构
为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。一般来说，LVS集群采用三层结构，其体系结构如图1所示，三层主要组成部分为：
- 负载调度器（load balancer），它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址（我们可称之为虚拟IP地址）上的。
- 服务器池（server pool），是一组真正执行客户请求的服务器，执行的服务有WEB、MAIL、FTP和DNS等。
- 共享存储（shared storage），它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。
调度器是服务器集群系统的唯一入口点（Single Entry Point），它可以采用IP负载均衡技术、基于内容请求分发技术或者两者相结合。在IP负载均衡技术中，需要服务器池拥有相同的内容提供相同的服务。当 客户请求到达时，调度器只根据服务器负载情况和设定的调度算法从服务器池中选出一个服务器，将该请求转发到选出的服务器，并记录这个调度；当这个请求的其 他报文到达，也会被转发到前面选出的服务器。在基于内容请求分发技术中，服务器可以提供不同的服务，当客户请求到达时，调度器可根据请求的内容选择服务器 执行请求。因为所有的操作都是在Linux操作系统核心空间中将完成的，它的调度开销很小，所以它具有很高的吞吐率。
服务器池的结点数目是可变的。当整个系统收到的负载超过目前所有结点的处理能力时，可以在服务器池中增加服务器来满足不断增长的请求负载。对大多数 网络服务来说，请求间不存在很强的相关性，请求可以在不同的结点上并行执行，所以整个系统的性能基本上可以随着服务器池的结点数目增加而线性增长。
共享存储通常是数据库、网络文件系统或者分布式文件系统。服务器结点需要动态更新的数据一般存储在数据库系统中，同时数据库会保证并发 访问时数据的一致性。静态的数据可以存储在网络文件系统（如NFS/CIFS）中，但网络文件系统的伸缩能力有限，一般来说，NFS/CIFS服务器只能 支持3~6个繁忙的服务器结点。对于规模较大的集群系统，可以考虑用分布式文件系统，如AFS[1]、GFS[2.3]、Coda[4]和 Intermezzo[5]等。分布式文件系统可为各服务器提供共享的存储区，它们访问分布式文件系统就像访问本地文件系统一样，同时分布式文件系统可提 供良好的伸缩性和可用性。此外，当不同服务器上的应用程序同时读写访问分布式文件系统上同一资源时，应用程序的访问冲突需要消解才能使得资源处于一致状 态。这需要一个分布式锁管理器（Distributed Lock Manager），它可能是分布式文件系统内部提供的，也可能是外部的。开发者在写应用程序时，可以使用分布式锁管理器来保证应用程序在不同结点上并发访 问的一致性。
负载调度器、服务器池和共享存储系统通过高速网络相连接，如100Mbps交换网络、Myrinet和Gigabit网络等。使用高速的网络，主要为避免当系统规模扩大时互联网络成为整个系统的瓶颈。
Graphic Monitor是为系统管理员提供整个集群系统的监视器，它可以监视系统的状态。Graphic Monitor是基于浏览器的，所以无论管理员在本地还是异地都可以监测系统的状况。为了安全的原因，浏览器要通过HTTPS（Secure HTTP）协议和身份认证后，才能进行系统监测，并进行系统的配置和管理。
2.1. 为什么使用层次的体系结构
层次的体系结构可以使得层与层之间相互独立，每一个层次提供不同的功能，在一个层次可以重用不同的已有软件。例如，调度器层提供了负载平衡、可伸缩 性和高可用性等，在服务器层可以运行不同的网络服务，如Web、Cache、Mail和Media等，来提供不同的可伸缩网络服务。明确的功能划分和清晰 的层次结构使得系统容易建设，以后整个系统容易维护，而且系统的性能容易被扩展。
2.2. 为什么是共享存储
共享存储如分布式文件系统在这个LVS集群系统是可选项。当网络服务需要有相同的内容，共享存储是很好的选择，否则每台服务器需要将相同的 内容复制到本地硬盘上。当系统存储的内容越多，这种无共享结构（Shared-nothing Structure）的代价越大，因为每台服务器需要一样大的存储空间，任何的更新需要涉及到每台服务器，系统的维护代价会非常高。
共享存储为服务器组提供统一的存储空间，这使得系统的内容维护工作比较轻松，如Webmaster只需要更新共享存储中的页面，对所有 的服务器都有效。分布式文件系统提供良好的伸缩性和可用性，当分布式文件系统的存储空间增加时，所有服务器的存储空间也随之增大。对于大多数 Internet服务来说，它们都是读密集型（Read-intensive）的应用，分布式文件系统在每台服务器使用本地硬盘作Cache（如 2Gbytes的空间），可以使得访问分布式文件系统本地的速度接近于访问本地硬盘。
此外，存储硬件技术的发展也促使从无共享的集群向共享存储的集群迁移。存储区域网（Storage Area Networks）技术解决了集群的每个结点可以直接连接/共享一个庞大的硬盘阵列，硬件厂商也提供多种硬盘共享技术，如光纤通道（Fiber Channel）、共享SCSI（Shared SCSI）。InfiniBand是一个通用的高性能I/O规范，使得存储区域网中以更低的延时传输I/O消息和集群通讯消息，并且提供很好的伸缩性。 InfiniBand得到绝大多数的大厂商的支持，如Compaq、Dell、Hewlett-Packard、IBM、Intel、Microsoft 和SUN Microsystems等，它正在成为一个业界的标准。这些技术的发展使得共享存储变得容易，规模生产也会使得成本逐步降低。
2.3. 高可用性
集群系统的特点是它在软硬件上都有冗余。系统的高可用性可以通过检测节点或服务进程故障和正确地重置系统来实现，使得系统收到的请求能被存活的结点处理。
通常，我们在调度器上有资源监测进程来时刻监视各个服务器结点的健康状况。当服务器对ICMP ping不可达时或者探测她的网络服务在指定的时间没有响应时，资源监测进程通知操作系统内核将该服务器从调度列表中删除或者失效。这样，新的服务请求就 不会被调度到坏的结点。资源监测进程能通过电子邮件或传呼机向管理员报告故障。一旦监测进程到服务器恢复工作，通知调度器将其加入调度列表进行调度。另 外，通过系统提供的管理程序，管理员可发命令随时可以将新机器加入服务来提高系统的处理性能，也可以将已有的服务器切出服务，以便对服务器进行系统维护。
现在前端的调度器有可能成为系统的单一失效点（Single Point of Failure）。一般来说，调度器的可靠性较高，因为调度器上运行的程序较少而且大部分程序早已经遍历过，但我们不能排除硬件老化、网络线路或者人为误 操作等主要故障。为了避免调度器失效而导致整个系统不能工作，我们需要设立一个从调度器作为主调度器的备份。两个心跳（Heartbeat）进程[6]分 别在主、从调度器上运行，它们通过串口线和UDP等心跳线来相互定时地汇报各自的健康状况。当从调度器不能听得主调度器的心跳时，从调度器通过ARP欺骗 （Gratuitous ARP）来接管集群对外的Virtual IP Address，同时接管主调度器的工作来提供负载调度服务。当主调度器恢复时，这里有两种方法，一是主调度器自动变成从调度器，二是从调度器释放 Virtual IP Address，主调度器收回Virtual IP Address并提供负载调度服务。这里，多条心跳线可以使得因心跳线故障导致误判（即从调度器认为主调度器已经失效，其实主调度器还在正常工作）的概论 降到最低。
通常，当主调度器失效时，主调度器上所有已建立连接的状态信息将丢失，已有的连接会中断。客户需要向重新连接，从调度器才会将新连接调 度到各个服务器上，这对客户会造成一定的不便。为此，IPVS调度器在Linux 内核中实现一种高效状态同步机制，将主调度器的状态信息及时地同步到从调度器。当从调度器接管时，绝大部分已建立的连接会持续下去。
基于LVS的Web集群的体系结构如图2所示：第一层是负载调度器，一般采用IP负载均衡技术，可以使得整个系统有较高的吞吐率；第二层是 Web服务器池，在每个结点上可以分别运行HTTP服务或HTTPS服务、或者两者都运行；第三层是共享存储，它可以是数据库，可以是网络文件系统或分布 式文件系统，或者是三者的混合。集群中各结点是通过高速网络相连接的。
图2：基于LVS的Web集群
对于动态页面（如PHP、JSP和ASP等），需要访问的动态数据一般存储在数据库服务器中。数据库服务运行在独立的服务器上，为所有Web服务器 共享。无论同一Web服务器上多个动态页面访问同一数据，还是不同Web服务器上多个动态页面访问同一数据，数据库服务器有锁机制使得这些访问有序地进 行，从而保证数据的一致性。
对于静态的页面和文件（如HTML文档和图片等），可以存储在网络文件系统或者分布式文件系统中。至于选择哪一种，看系统的规模和需求 而定。通过共享的网络文件系统或者分布式文件系统，Webmaster可以看到统一的文档存储空间，维护和更新页面比较方便，对共享存储中页面的修改对所 有的服务器都有效。
在这种结构下，当所有服务器结点超载时，管理员可以很快地加入新的服务器结点来处理请求，而无需将Web文档等复制到结点的本地硬盘上。
有些Web服务可能用到HTTP Cookie，它是将数据存储在客户的浏览器来追踪和标识客户的机制。使用HTTP Cookie后，来同一客户的不同连接存在相关性，这些连接必须被发送到同一Web服务器。一些Web服务使用安全的HTTPS协议，它是HTTP协议加 SSL（Secure Socket Layer）协议。另有些Web服务可能使用安全的HTTPS协议，它是HTTP协议加SSL协议。当客户访问HTTPS服务（HTTPS的缺省端口为 443）时，会先建立一个SSL连接，来交换对称公钥加密的证书并协商一个SSL Key，来加密以后的会话。在SSL Key的生命周期内，后续的所有HTTPS连接都使用这个SSL Key，所以同一客户的不同HTTPS连接也存在相关性。针对这些需要，IPVS调度器提供了持久服务的功能，它可以使得在设定的时间内，来自同一IP地 址的不同连接会被发送到集群中同一个服务器结点，可以很好地解决客户连接的相关性问题。
基于LVS的媒体集群的体系结构如图3所示：第一层是负载调度器，一般采用IP负载均衡技术，可以使得整个系统有较高的吞吐率；第二层是 Web服务器池，在每个结点上可以运行相应的媒体服务；第三层是共享存储，通过网络文件系统/分布式文件系统存储媒体节目。集群中各结点是通过高速网络相 连接。
图3：基于LVS的媒体集群
IPVS负载调度器一般使用直接路由方法（即VS/DR方法，将在以后文章中详细叙述），来架构媒体集群系统。调度器将媒体服务请求较均衡地分发到 各个服务器上，而媒体服务器将响应数据直接返回给客户，这样可以使得整个媒体集群系统具有很好的伸缩性。
媒体服务器可以运行各种媒体服务软件。目前，LVS集群对于Real Media、Windows Media和Apple Quicktime媒体服务都有很好的支持，都有真实的系统在运行。一般来说，流媒体服务都会使用一个TCP连接（如RTSP协议：Real-Time Streaming Protocol）进行带宽的协商和流速的控制，通过UDP将流数据返回客户。这里，IPVS调度器提供功能将TCP和UDP集中考虑，保证来自同一客户 的媒体TCP和UDP连接会被转发到集群中同一台媒体服务器，使得媒体服务准确无误地进行。
共享存储是媒体集群系统中最关键的问题，因为媒体文件往往非常大（一部片子需要几百兆到几千兆的存储空间），这对存储的容量和读的速度 有较高的要求。对于规模较小的媒体集群系统，例如有3至6个媒体服务器结点，存储系统可以考虑用带千兆网卡的Linux服务器，使用软件RAID和日志型 文件系统，再运行内核的NFS服务，会有不错的效果。对于规模较大的媒体集群系统，最好选择对文件分段（File Stripping）存储和文件缓存有较好支持的分布式文件系统；媒体文件分段存储在分布式文件系统的多个存储结点上，可以提高文件系统的性能和存储结点 间的负载均衡；媒体文件在媒体服务器上自动地被缓存，可提高文件的访问速度。否则，可以考虑自己在媒体服务器上开发相应的工具，如缓存工具能定时地统计出 最近的热点媒体文件，将热点文件复制到本地硬盘上，并替换缓存中的非热点文件，最后通知其他媒体服务器结点它所缓存的媒体文件以及负载情况；在媒体服务器 上有应用层调度工具，它收到客户的媒体服务请求，若所请求的媒体文件缓存在本地硬盘上，则直接转给本地媒体服务进程服务，否则先考虑该文件是否被其他媒体 服务器缓存；如该文件被其他服务器缓存并且该服务器不忙，则将请求转给该服务器上的媒体服务进程处理，否则直接转给本地媒体服务进程，从后端的共享存储中 读出媒体文件。
共享存储的好处是媒体文件的管理人员看到统一的存储空间，使得媒体文件维护工作比较方便。当客户访问不断增加使得整个系统超载时，管理员可以很快地加入新的媒体服务器结点来处理请求。
Real公司以其高压缩比的音频视频格式、Real媒体服务器和媒体播放器RealPlayer而闻名。Real公司正在使用以上结构将由 20多台服务器组成的LVS可伸缩Web和媒体集群，为其全球用户提供Web和音频视频服务。Real公司的高级技术主管声称LVS击败所有他们尝试过的 商品化负载均衡产品[7]。
有效的网络Cache系统可以大大地减少网络流量、降低响应延时以及服务器的负载。但是，若Cache服务器超载而不能及时地处理请求，反 而会增加响应延时。所以，Cache服务的可伸缩性很重要，当系统负载不断增长时，整个系统能被扩展来提高Cache服务的处理能力。尤其，在主干网上的 Cache服务可能需要几个Gbps的吞吐率，单台服务器（例如SUN目前最高端的Enterprise 10000服务器）远不能达到这个吞吐率。可见，通过PC服务器集群实现可伸缩Cache服务是很有效的方法，也是性能价格比最高的方法。
基于LVS的Cache集群的体系结构如图4所示：第一层是负载调度器，一般采用IP负载均衡技术，可以使得整个系统有较高的吞吐率； 第二层是Cache服务器池，一般Cache服务器放置在接近主干Internet连接处，它们可以分布在不同的网络中。调度器可以有多个，放在离客户接 近的地方。
图4：基于LVS的Cache集群
IPVS负载调度器一般使用IP隧道方法（即VS/TUN方法，将在以后文章中详细叙述），来架构Cache集群系统，因为Cache服务器可能被 放置不同的地方（例如在接近主干Internet连接处），而调度器与Cache服务器池可能不在同一个物理网络中。采用VS/TUN方法，调度器只调度 Web Cache请求，而Cache服务器将响应数据直接返回给客户。在请求对象不能在本地命中的情况下，Cache服务器要向源服务器发请求，将结果取回，最 后将结果返回给客户；若采用NAT技术的商品化调度器，需要四次进出调度器，完成这个请求。而用VS/TUN方法（或者VS/DR方法），调度器只调度一 次请求，其他三次都由Cache服务器直接访问Internet完成。所以，这种方法对Cache集群系统特别有效。
Cache服务器采用本地硬盘来存储可缓存的对象，因为存储可缓存的对象是写操作，且占有一定的比例，通过本地硬盘可以提高I/O的访 问速度。Cache服务器间有专用的多播通道（Multicast Channel），通过ICP协议（Internet Cache Protocol）来交互信息。当一台Cache服务器在本地硬盘中未命中当前请求时，它可以通过ICP查询其他Cache服务器是否有请求对象的副本， 若存在，则从邻近的Cache服务器取该对象的副本，这样可以进一步提高Cache服务的命中率。
为150多所大学和地区服务的英国国家JANET Web Cache网在1999年11月用以上LVS结构实现可伸缩的Cache集群[8]，只用了原有50多台相互独立Cache服务器的一半，用户反映网络速 度跟夏天一样快（学生放暑假）。可见，通过负载调度可以摸平单台服务器访问的毛刺（Burst），提高整个系统的资源利用率。
随着Internet用户不断增长，很多ISP面临他们邮件服务器超载的问题。当邮件服务器不能容纳更多的用户帐号时，有些ISP买更高档 的服务器来代替原有的，将原有服务器的信息（如用户邮件）迁移到新服务器是很繁琐的工作，会造成服务的中断；有些ISP设置新的服务器和新的邮件域名，新 的邮件用户放置在新的服务器上，如上海电信现在用不同的邮件服务器public1.sta.net.cn、public2.sta.net.cn到 public9.sta.net.cn放置用户的邮件帐号，这样静态地将用户分割到不同的服务器上，会造成邮件服务器负载不平衡，系统的资源利用率低，对 用户来说邮件的地址比较难记。
图5：基于LVS的可伸缩邮件集群
可以利用LVS框架实现高可伸缩、高可用的邮件服务系统。它的体系结构如图5所示：在前端是一个采用IP负载均衡技术的负载调度器；第二层 是服务器池，有LDAP（Light-weight Directory Access Protocol）服务器和一组邮件服务器。第三层是数据存储，通过分布式文件系统来存储用户的邮件。集群中各结点是通过高速网络相连接。
用户的信息如用户名、口令、主目录和邮件容量限额等存储在LDAP服务器中，可以通过HTTPS让管理员进行用户管理。在各个邮件服务 器上运行SMTP（Simple Mail Transfer Protocol）、POP3（Post Office Protocol version 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请求流负载较均衡地分发到各邮件服务器上，从上面各服务的处理 流程来看，不管请求被发送到哪一台邮件服务器处理，其结果是一样的。这里，将SMTP、POP3、IMAP4和HTTP/HTTPS运行在各个邮件服务器 上进行集中调度，有利于提高整个系统的资源利用率。
系统中可能的瓶颈是LDAP服务器，对LDAP服务中B+树的参数进行优化，再结合高端的服务器，可以获得较高的性能。若分布式文件系 统没有多个存储结点间的负载均衡机制，则需要相应的邮件迁移机制来避免邮件访问的倾斜。
这样，这个集群系统对用户来说就像一个高性能、高可靠的邮件服务器（例如上海电信只要用一个邮件域名 public.sta.net.cn就可以）。当邮件用户不断增长时，只要在集群中增加服务器结点和存储结点。用户信息的集中存储使得用户管理变得容易， 且集群系统有利于提高资源利用率。
本文给出LVS集群的通用体系结构，并讨论了它的设计原则和相应的特点；最后将LVS集群应用于建立可伸缩的Web、Media、 Cache和Mail网络服务，并指出了系统架设时应注意的要点。我们将在后续的文章中详细解释LVS集群的技术、实现和应用。
- J.H. Howard. An Overview of the Andrew File System. In Proceedings of the USENIX Winter Technical Conference, Dallas, TX, USA, February 1998.
- Kenneth W. Preslan, Andrew P. Barry, Jonathan E. Brassow, Grant M. Erickson, Erling Nygaard, Christopher J. Sabol, Steven R. Soltis, David C. Teigland, and Matthew T. O'Keefe. A 64-bit, Shared Disk File System for Linux. In Proceeding of 16th IEEE Mass Storage Systems Symposium, San Diego, CA, USA. March 15-18, 1999.
- Global File System Website. http://www.globalfilesystem.org.
- Coda File System Website. http://www.coda.cs.cmu.edu.
- InterMezzo File System Website. http://www.inter-mezzo.org.
- Alan Robertson, et al. Linux High Availability Project. http://www.linux-ha.org.
- Jerry Glomph Black. LVS testimonials from Real Networks. March 2000. http://marc.theaimsgroup.com/?l=linux-virtual-server&m=95385809030794&w=2
- Michael Sparks. Load Balancing the UK National JANET Web Cache Service Using Linux Virtual Servers. November 1999. http://wwwcache.ja.net/JanetService/PilotService.html.
[1] Information Navigators, Internet Growth Charts, http://navigators.com/stats.html
[2] Srinivasan Seetharaman. IP over DWDM. http://www.cis.ohio-state.edu-/~jain/cis788-99/ip_dwdm/
[3] Lucent Technologies. Web ProForum tutorial: DWDM. October 1999, http://www.webproforum.com/acrobat/dwdm.pdf
[4] Lucent Technologies. Lucent Technologies announces record-breaking 320-channel optical networking system. April 2000, http://www.lucent.com/press/0400/000417.nsb.html
[5] Yahoo! Inc., The Yahoo! Directory and Web Services, http://www.yahoo.com/
[6] Dell Inc. http://www.dell.com/
9. 关于作者
章文嵩博士，开放源码及Linux内核的开发者，著名的Linux集群项目－－LVS(Linux Virtual Server)的创始人和主要开发人员。他目前工作于国家并行与分布式处理重点实验室，主要从事集群技术、操作系统、对象存储与数据库的研究。他一直在自由软件的开发上花费大量时间，并以此为乐。