Linux服务器集群系统

时间 2019-11-13

原文原文链接

Linux服务器集群系统(一) LVS项目介绍

本文介绍了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）
   在集群系统上，容易开发应用程序。

Linux Virtual Server项目

针对高可伸缩、高可用网络服务的需求，咱们给出了基于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虚拟服务器框架

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负载均衡技术，它们的大体原理以下（咱们将在其余章节对其工做原理进行详细描述），

1. Virtual Server via Network Address Translation（VS/NAT）
   经过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文经过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。
2. Virtual Server via IP Tunneling（VS/TUN）
   采用NAT技术时，因为请求和响应报文都必须通过调度器地址重写，当客户请求愈来愈多时，调度器的处理能力将成为瓶颈。为了解决这个问题，调度器把请求报文经过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，因此调度器只处理请求报文。因为通常网络服务应答比请求报文大许多，采用 VS/TUN技术后，集群系统的最大吞吐量能够提升10倍。
3. Virtual Server via Direct Routing（VS/DR）
   VS/DR经过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。同VS/TUN技术同样，VS/DR技术可极大地提升集群系统的伸缩性。这种方法没有IP隧道的开销，对集群中的真实服务器也没有必须支持IP隧道协议的要求，可是要求调度器与真实服务器都有一块网卡连在同一物理网段上。

针对不一样的网络服务需求和服务器配置，IPVS调度器实现了以下八种负载调度算法：

1. 轮叫（Round Robin）
   调度器经过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而无论服务器上实际的链接数和系统负载。
2. 加权轮叫（Weighted Round Robin）
   调度器经过"加权轮叫"调度算法根据真实服务器的不一样处理能力来调度访问请求。这样能够保证处理能力强的服务器处理更多的访问流量。调度器能够自动问询真实服务器的负载状况，并动态地调整其权值。
3. 最少连接（Least Connections）
   调度器经过"最少链接"调度算法动态地将网络请求调度到已创建的连接数最少的服务器上。若是集群系统的真实服务器具备相近的系统性能，采用"最小链接"调度算法能够较好地均衡负载。
4. 加权最少连接（Weighted Least Connections）
   在集群系统中的服务器性能差别较大的状况下，调度器采用"加权最少连接"调度算法优化负载均衡性能，具备较高权值的服务器将承受较大比例的活动链接负载。调度器能够自动问询真实服务器的负载状况，并动态地调整其权值。
5. 基于局部性的最少连接（Locality-Based Least Connections）
   "基于局部性的最少连接" 调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工做负载，则用"最少连接"的原则选出一个可用的服务器，将请求发送到该服务器。
6. 带复制的基于局部性最少连接（Locality-Based Least Connections with Replication） "带复制的基于局部性最少连接"调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不一样之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按"最小链接"原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器，若服务器超载；则按"最小链接"原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以下降复制的程度。
7. 目标地址散列（Destination Hashing）
   "目标地址散列"调度算法根据请求的目标IP地址，做为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，不然返回空。
8. 源地址散列（Source Hashing）
   "源地址散列"调度算法根据请求的源IP地址，做为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，不然返回空。

内核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集群的特色

LVS集群的特色能够归结以下：

1. 功能
   有实现三种IP负载均衡技术和八种链接调度算法的IPVS软件。在IPVS内部实现上，采用了高效的Hash函数和垃圾回收机制，能正确处理所调度报文相关的ICMP消息（有些商品化的系统反而不能）。虚拟服务的设置数目没有限制，每一个虚拟服务有本身的服务器集。它支持持久的虚拟服务（如HTTP Cookie和HTTPS等须要该功能的支持），并提供详尽的统计数据，如链接的处理速率和报文的流量等。针对大规模拒绝服务（Deny of Service）攻击，实现了三种防卫策略。
   有基于内容请求分发的应用层交换软件KTCPVS，它也是在Linux内核中实现。有相关的集群管理软件对资源进行监测，能及时将故障屏蔽，实现系统的高可用性。主、从调度器能周期性地进行状态同步，从而实现更高的可用性。
2. 适用性
   后端服务器可运行任何支持TCP/IP的操做系统，包括Linux，各类Unix（如FreeBSD、Sun Solaris、HP Unix等），Mac/OS和Windows NT/2000等。
   负载调度器可以支持绝大多数的TCP和UDP协议：

   协议内容
   TCP HTTP，FTP，PROXY，SMTP，POP3，IMAP4，DNS，LDAP，HTTPS，SSMTP等
   UDP DNS，NTP，ICP，视频、音频流播放协议等
   无需对客户机和服务器做任何修改，可适用大多数Internet服务。
3. 性能
   LVS服务器集群系统具备良好的伸缩性，可支持几百万个并发链接。配置100M网卡，采用VS/TUN或VS/DR调度技术，集群系统的吞吐量可高达1Gbits/s；如配置千兆网卡，则系统的最大吞吐量可接近10Gbits/s。
4. 可靠性
   LVS服务器集群软件已经在不少大型的、关键性的站点获得很好的应用，因此它的可靠性在真实应用获得很好的证明。有不少调度器运行一年多，未做一次重启动。
5. 软件许可证
   LVS集群软件是按GPL（GNU Public License）许可证发行的自由软件，这意味着你能够获得软件的源代码，有权对其进行修改，但必须保证你的修改也是以GPL方式发行。

LVS集群的应用

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 项目于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项目的网络资源

若是你对LVS项目感兴趣，请访问Linux Vritual Server项目的主页（ http://www.LinuxVirtualServer.org/或者 http://www.linux-vs.org/），你能够得到最新的 LVS 源代码和有关运行软件，及最新的文档资料。

分享到：

分享0 收藏0 支持0 反对0

使用道具举报 php

骑虎

你们网大学一年级html

积分: 862
帖子: 161
精华: 11
经验: 584 点
威望: 0 点
金币: 458

2楼

发表于 2008-10-22 14:42:47 | 只看该做者

Linux服务器集群系统(二) LVS集群的体系结构

本文主要介绍了LVS集群的体系结构。先给出LVS集群的通用体系结构，并讨论了其的设计原则和相应的特色；最后将LVS集群应用于创建可伸缩的Web、Media、Cache和Mail等网络服务。

引言

在过去的十几年中，Internet从几个研究机构相连为信息共享的网络发展成为拥有大量应用和服务的全球性网络，它正成为人们生活中不可缺乏的一部分。虽然Internet发展速度很快，但建设和维护大型网络服务依然是一项挑战性的任务，由于系统必须是高性能的、高可靠的，尤为当访问负载不断增加时，系统必须能被扩展来知足不断增加的性能需求。因为缺乏创建可伸缩网络服务的框架和设计方法，这意味着只有拥有很是出色工程和管理人才的机构才能创建和维护大型的网络服务。

针对这种情形，本文先给出LVS集群的通用体系结构，并讨论了其的设计原则和相应的特色；最后将LVS集群应用于创建可伸缩的Web、Media、Cache和Mail等网络服务。

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）协议和身份认证后，才能进行系统监测，并进行系统的配置和管理。

为何使用层次的体系结构

层次的体系结构可使得层与层之间相互独立，每个层次提供不一样的功能，在一个层次能够重用不一样的已有软件。例如，调度器层提供了负载平衡、可伸缩性和高可用性等，在服务器层能够运行不一样的网络服务，如Web、Cache、Mail和Media等，来提供不一样的可伸缩网络服务。明确的功能划分和清晰的层次结构使得系统容易建设，之后整个系统容易维护，并且系统的性能容易被扩展。

为何是共享存储

共享存储如分布式文件系统在这个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等，它正在成为一个业界的标准。这些技术的发展使得共享存储变得容易，规模生产也会使得成本逐步下降。

高可用性

集群系统的特色是它在软硬件上都有冗余。系统的高可用性能够经过检测节点或服务进程故障和正确地重置系统来实现，使得系统收到的请求能被存活的结点处理。

一般，咱们在调度器上有资源监测进程来时刻监视各个服务器结点的健康情况。当服务器对ICMP ping不可达时或者探测她的网络服务在指定的时间没有响应时，资源监测进程通知操做系统内核将该服务器从调度列表中删除或者失效。这样，新的服务请求就不会被调度到坏的结点。资源监测进程能经过电子邮件或传呼机向管理员报告故障。一旦监测进程到服务器恢复工做，通知调度器将其加入调度列表进行调度。另外，经过系统提供的管理程序，管理员可发命令随时能够将新机器加入服务来提升系统的处理性能，也能够将已有的服务器切出服务，以便对服务器进行系统维护。

如今前端的调度器有可能成为系统的单一失效点（Single Point of Failure）。通常来讲，调度器的可靠性较高，由于调度器上运行的程序较少并且大部分程序早已经遍历过，但咱们不能排除硬件老化、网络线路或者人为误操做等主要故障。为了不调度器失效而致使整个系统不能工做，咱们须要设立一个从调度器做为主调度器的备份。两个心跳（Heartbeat）进程分别在主、从调度器上运行，它们经过串口线和UDP等心跳线来相互定时地汇报各自的健康情况。当从调度器不能听得主调度器的心跳时，从调度器经过ARP欺骗（Gratuitous ARP）来接管集群对外的Virtual IP Address，同时接管主调度器的工做来提供负载调度服务。当主调度器恢复时，这里有两种方法，一是主调度器自动变成从调度器，二是从调度器释放 Virtual IP Address，主调度器收回Virtual IP Address并提供负载调度服务。这里，多条心跳线可使得因心跳线故障致使误判（即从调度器认为主调度器已经失效，其实主调度器还在正常工做）的概论降到最低。

一般，当主调度器失效时，主调度器上全部已创建链接的状态信息将丢失，已有的链接会中断。客户须要向从新链接，从调度器才会将新链接调度到各个服务器上，这对客户会形成必定的不便。为此，IPVS调度器在Linux 内核中实现一种高效状态同步机制，将主调度器的状态信息及时地同步到从调度器。当从调度器接管时，绝大部分已创建的链接会持续下去。

可伸缩Web服务

基于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击败全部他们尝试过的商品化负载均衡产品。

可伸缩Cache服务

有效的网络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、POP三、 IMAP4和HTTP/HTTPS请求流负载较均衡地分发到各邮件服务器上，从上面各服务的处理流程来看，无论请求被发送到哪一台邮件服务器处理，其结果是同样的。这里，将SMTP、POP三、IMAP4和HTTP/HTTPS运行在各个邮件服务器上进行集中调度，有利于提升整个系统的资源利用率。

系统中可能的瓶颈是LDAP服务器，对LDAP服务中B+树的参数进行优化，再结合高端的服务器，能够得到较高的性能。若分布式文件系统没有多个存储结点间的负载均衡机制，则须要相应的邮件迁移机制来避免邮件访问的倾斜。

这样，这个集群系统对用户来讲就像一个高性能、高可靠的邮件服务器（例如上海电信只要用一个邮件域名public.sta.net.cn就能够）。当邮件用户不断增加时，只要在集群中增长服务器结点和存储结点。用户信息的集中存储使得用户管理变得容易，且集群系统有利于提升资源利用率。

小结

本文给出LVS集群的通用体系结构，并讨论了它的设计原则和相应的特色；最后将LVS集群应用于创建可伸缩的Web、Media、Cache和Mail网络服务，并指出了系统架设时应注意的要点。咱们将在后续的文章中详细解释LVS集群的技术、实现和应用。

使用道具举报前端

骑虎

你们网大学一年级node

积分: 862
帖子: 161
精华: 11
经验: 584 点
威望: 0 点
金币: 458

3楼

发表于 2008-10-22 14:51:33 | 只看该做者

Linux服务器集群系统(三) LVS集群的体系结构

本文在分析服务器集群实现虚拟网络服务的相关技术上，详细描述了LVS集群中实现的三种IP负载均衡技术（VS/NAT、VS/TUN和VS/DR）的工做原理，以及它们的优缺点。

前言

在前面文章中，讲述了可伸缩网络服务的几种结构，它们都须要一个前端的负载调度器（或者多个进行主从备份）。咱们先分析实现虚拟网络服务的主要技术，指出 IP负载均衡技术是在负载调度器的实现技术中效率最高的。在已有的IP负载均衡技术中，主要有经过网络地址转换（Network Address Translation）将一组服务器构成一个高性能的、高可用的虚拟服务器，咱们称之为VS/NAT技术（Virtual Server via Network Address Translation）。在分析VS/NAT的缺点和网络服务的非对称性的基础上，咱们提出了经过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协议。下面简述当前用服务器集群实现高可伸缩、高可用网络服务的几种负载调度方法，并列举几个在这方面有表明性的研究项目。

实现虚拟服务的相关方法

在网络服务中，一端是客户程序，另外一端是服务程序，在中间可能有代理程序。由此看来，能够在不一样的层次上实现多台服务器的负载均衡。用集群解决网络服务性能问题的现有方法主要分为如下四类。

基于RR-DNS的解决方法

NCSA的可伸缩的WEB服务器系统就是最先基于RR-DNS（Round-Robin Domain Name System）的原型系统[1,2]。它的结构和工做流程以下图所示：

图1：基于RR-DNS的可伸缩WEB服务器

有一组WEB服务器，他们经过分布式文件系统AFS(Andrew File System)来共享全部的HTML文档。这组服务器拥有相同的域名（如www.ncsa.uiuc.edu），当用户按照这个域名访问时, RR-DNS服务器会把域名轮流解析到这组服务器的不一样IP地址，从而将访问负载分到各台服务器上。

这种方法带来几个问题。第一，域名服务器是一个分布式系统，是按照必定的层次结构组织的。当用户就域名解析请求提交给本地的域名服务器，它会因不能直接解析而向上一级域名服务器提交，上一级域名服务器再依次向上提交，直到RR-DNS域名服器把这个域名解析到其中一台服务器的IP地址。可见，从用户到 RR-DNS间存在多台域名服器，而它们都会缓冲已解析的名字到IP地址的映射,这会致使该域名服器组下全部用户都会访问同一WEB服务器，出现不一样 WEB服务器间严重的负载不平衡。为了保证在域名服务器中域名到IP地址的映射不被长久缓冲，RR-DNS在域名到IP地址的映射上设置一个 TTL(Time To Live)值，过了这一段时间，域名服务器将这个映射从缓冲中淘汰。当用户请求，它会再向上一级域名服器提交请求并进行从新影射。这就涉及到如何设置这个 TTL值，若这个值太大，在这个TTL期间，不少请求会被映射到同一台WEB服务器上，一样会致使严重的负载不平衡。若这个值过小，例如是０，会致使本地域名服务器频繁地向RR-DNS提交请求，增长了域名解析的网络流量，一样会使RR-DNS服务器成为系统中一个新的瓶颈。

第二，用户机器会缓冲从名字到IP地址的映射，而不受TTL值的影响，用户的访问请求会被送到同一台WEB服务器上。因为用户访问请求的突发性和访问方式不一样，例若有的人访问一下就离开了，而有的人访问可长达几个小时，因此各台服务器间的负载仍存在倾斜（Skew）而不能控制。假设用户在每一个会话中平均请求数为20，负载最大的服务器得到的请求数额高于各服务器平均请求数的平均比率超过百分之三十。也就是说，当TTL值为0时，由于用户访问的突发性也会存在着较严重的负载不平衡。

第三，系统的可靠性和可维护性差。若一台服务器失效，会致使将域名解析到该服务器的用户看到服务中断，即便用户按“Reload”按钮，也无济于事。系统管理员也不能随时地将一台服务器切出服务进行系统维护，如进行操做系统和应用软件升级，这须要修改 RR-DNS服务器中的IP地址列表，把该服务器的IP地址从中划掉，而后等上几天或者更长的时间，等全部域名服器将该域名到这台服务器的映射淘汰，和所有映射到这台服务器的客户机再也不使用该站点为止。

基于客户端的解决方法

基于客户端的解决方法须要每一个客户程序都有必定的服务器集群的知识，进而把以负载均衡的方式将请求发到不一样的服务器。例如，Netscape Navigator浏览器访问Netscape的主页时，它会随机地从一百多台服务器中挑选第N台，最后将请求送往wwwN.netscape.com。然而，这不是很好的解决方法，Netscape只是利用它的Navigator避免了RR-DNS解析的麻烦，当使用IE等其余浏览器不可避免的要进行 RR-DNS解析。

Smart Client[3]是Berkeley作的另外一种基于客户端的解决方法。服务提供一个Java Applet在客户方浏览器中运行，Applet向各个服务器发请求来收集服务器的负载等信息，再根据这些信息将客户的请求发到相应的服务器。高可用性也在Applet中实现，当服务器没有响应时，Applet向另外一个服务器转发请求。这种方法的透明性很差，Applet向各服务器查询来收集信息会增长额外的网络流量，不具备广泛的适用性。

基于应用层负载均衡调度的解决方法

多台服务器经过高速的互联网络链接成一个集群系统，在前端有一个基于应用层的负载调度器。当用户访问请求到达调度器时，请求会提交给做负载均衡调度的应用程序，分析请求，根据各个服务器的负载状况，选出一台服务器，重写请求并向选出的服务器访问，取得结果后，再返回给用户。

应用层负载均衡调度的典型表明有Zeus负载调度器[4]、pWeb[5]、Reverse-Proxy[6]和SWEB[7]等。Zeus负载调度器是 Zeus公司的商业产品，它是在Zeus Web服务器程序改写而成的，采用单进程事件驱动的服务器结构。pWeb就是一个基于Apache 1.1服务器程序改写而成的并行WEB调度程序，当一个HTTP请求到达时，pWeb会选出一个服务器，重写请求并向这个服务器发出改写后的请求，等结果返回后，再将结果转发给客户。Reverse-Proxy利用Apache 1.3.1中的Proxy模块和Rewrite模块实现一个可伸缩WEB服务器，它与pWeb的不一样之处在于它要先从Proxy的cache中查找后，若没有这个副本，再选一台服务器，向服务器发送请求，再将服务器返回的结果转发给客户。SWEB是利用HTTP中的redirect错误代码，将客户请求到达一台WEB服务器后，这个WEB服务器根据本身的负载状况，本身处理请求，或者经过redirect错误代码将客户引到另外一台WEB服务器，以实现一个可伸缩的WEB服务器。

基于应用层负载均衡调度的多服务器解决方法也存在一些问题。第一，系统处理开销特别大，导致系统的伸缩性有限。当请求到达负载均衡调度器至处理结束时，调度器须要进行四次从核心到用户空间或从用户空间到核心空间的上下文切换和内存复制；须要进行二次 TCP链接，一次是从用户到调度器，另外一次是从调度器到真实服务器；须要对请求进行分析和重写。这些处理都须要不小的CPU、内存和网络等资源开销，且处理时间长。所构成系统的性能不能接近线性增长的，通常服务器组增至3或4台时，调度器自己可能会成为新的瓶颈。因此，这种基于应用层负载均衡调度的方法的伸缩性极其有限。第二，基于应用层的负载均衡调度器对于不一样的应用，须要写不一样的调度器。以上几个系统都是基于HTTP协议，若对于FTP、Mail、 POP3等应用，都须要重写调度器。

基于IP层负载均衡调度的解决方法

用户经过虚拟IP地址（Virtual IP Address）访问服务时，访问请求的报文会到达负载调度器，由它进行负载均衡调度，从一组真实服务器选出一个，将报文的目标地址Virtual IP Address改写成选定服务器的地址，报文的目标端口改写成选定服务器的相应端口，最后将报文发送给选定的服务器。真实服务器的回应报文通过负载调度器时，将报文的源地址和源端口改成Virtual IP Address和相应的端口，再把报文发给用户。Berkeley的MagicRouter[8]、Cisco的LocalDirector、 Alteon的ACEDirector和F5的Big/IP等都是使用网络地址转换方法。MagicRouter是在Linux 1.3版本上应用快速报文插入技术，使得进行负载均衡调度的用户进程访问网络设备接近核心空间的速度，下降了上下文切换的处理开销，但并不完全，它只是研究的原型系统，没有成为有用的系统存活下来。Cisco的LocalDirector、Alteon的ACEDirector和F5的Big/IP是很是昂贵的商品化系统，它们支持部分TCP/UDP协议，有些在ICMP处理上存在问题。

IBM的TCP Router[9]使用修改过的网络地址转换方法在SP/2系统实现可伸缩的WEB服务器。TCP Router修改请求报文的目标地址并把它转发给选出的服务器，服务器能把响应报文的源地址置为TCP Router地址而非本身的地址。这种方法的好处是响应报文能够直接返回给客户，坏处是每台服务器的操做系统内核都须要修改。IBM的 NetDispatcher[10]是TCP Router的后继者，它将报文转发给服务器，而服务器在non-ARP的设备配置路由器的地址。这种方法与LVS集群中的VS/DR相似，它具备很高的可伸缩性，但一套在IBM SP/2和NetDispatcher须要上百万美金。总的来讲，IBM的技术还挺不错的。

在贝尔实验室的ONE-IP[11]中，每台服务器都独立的IP地址，但都用IP Alias配置上同一VIP地址，采用路由和广播两种方法分发请求，服务器收到请求后按VIP地址处理请求，并以VIP为源地址返回结果。这种方法也是为了避免回应报文的重写，可是每台服务器用IP Alias配置上同一VIP地址，会致使地址冲突，有些操做系统会出现网络失效。经过广播分发请求，一样须要修改服务器操做系统的源码来过滤报文，使得只有一台服务器处理广播来的请求。

微软的Windows NT负载均衡服务（Windows NT Load Balancing Service，WLBS）[12]是1998年末收购Valence Research公司得到的，它与ONE-IP中的基于本地过滤方法同样。WLBS做为过滤器运行在网卡驱动程序和TCP/IP协议栈之间，得到目标地址为VIP的报文，它的过滤算法检查报文的源IP地址和端口号，保证只有一台服务器将报文交给上一层处理。可是，当有新结点加入和有结点失效时，全部服务器须要协商一个新的过滤算法，这会致使全部有Session的链接中断。同时，WLBS须要全部的服务器有相同的配置，如网卡速度和处理能力。

经过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）[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的体系结构

客户经过Virtual IP Address（虚拟服务的IP地址）访问网络服务时，请求报文到达调度器，调度器根据链接调度算法从一组真实服务器中选出一台服务器，将报文的目标地址 Virtual IP Address改写成选定服务器的地址，报文的目标端口改写成选定服务器的相应端口，最后将修改后的报文发送给选出的服务器。同时，调度器在链接Hash 表中记录这个链接，当这个链接的下一个报文到达时，从链接Hash表中能够获得原选定服务器的地址和端口，进行一样的改写操做，并将报文传给原选定的服务器。当来自真实服务器的响应报文通过调度器时，调度器将报文的源地址和源端口改成Virtual IP Address和相应的端口，再把报文发给用户。咱们在链接上引入一个状态机，不一样的报文会使得链接处于不一样的状态，不一样的状态有不一样的超时值。在TCP 链接中，根据标准的TCP有限状态机进行状态迁移，这里咱们不一一叙述，请参见W. Richard Stevens的《TCP/IP Illustrated Volume I》；在UDP中，咱们只设置一个UDP状态。不一样状态的超时值是能够设置的，在缺省状况下，SYN状态的超时为1分钟，ESTABLISHED状态的超时为15分钟，FIN状态的超时为1分钟；UDP状态的超时为5分钟。当链接终止或超时，调度器将这个链接从链接Hash表中删除。

这样，客户所看到的只是在Virtual IP Address上提供的服务，而服务器集群的结构对用户是透明的。对改写后的报文，应用增量调整Checksum的算法调整TCP Checksum的值，避免了扫描整个报文来计算Checksum的开销。

在一些网络服务中，它们将IP地址或者端口号在报文的数据中传送，若咱们只对报文头的IP地址和端口号做转换，这样就会出现不一致性，服务会中断。因此，针对这些服务，须要编写相应的应用模块来转换报文数据中的IP地址或者端口号。咱们所知道有这个问题的网络服务有FTP、IRC、H.32三、 CUSeeMe、Real Audio、Real Video、Vxtreme / Vosiac、VDOLive、VIVOActive、True Speech、RSTP、PPTP、StreamWorks、NTT AudioLink、NTT SoftwareVision、Yamaha MIDPlug、iChat Pager、Quake和Diablo。

下面，举个例子来进一步说明VS/NAT，如图3所示：

图3：VS/NAT的例子

VS/NAT 的配置以下表所示，全部到IP地址为202.103.106.5和端口为80的流量都被负载均衡地调度的真实服务器172.16.0.2:80和 172.16.0.3:8000上。目标地址为202.103.106.5:21的报文被转移到172.16.0.3:21上。而到其余端口的报文将被拒绝。

Protocol	Virtual IP Address	Port	Real IP Address	Port	Weight
TCP	202.103.106.5	80	172.16.0.2	80	1
172.16.0.3	8000	2
TCP	202.103.106.5	21	172.16.0.3	21	1

从如下的例子中，咱们能够更详细地了解报文改写的流程。

访问Web服务的报文可能有如下的源地址和目标地址：

SOURCE

202.100.1.2:3456

DEST

202.103.106.5:80

调度器从调度列表中选出一台服务器，例如是172.16.0.3:8000。该报文会被改写为以下地址，并将它发送给选出的服务器。

SOURCE

202.100.1.2:3456

DEST

172.16.0.3:8000

从服务器返回到调度器的响应报文以下：

SOURCE

172.16.0.3:8000

DEST

202.100.1.2:3456

响应报文的源地址会被改写为虚拟服务的地址，再将报文发送给客户：

SOURCE

202.103.106.5:80

DEST

202.100.1.2:3456

这样，客户认为是从202.103.106.5:80服务获得正确的响应，而不会知道该请求是服务器172.16.0.2仍是服务器172.16.0.3处理的。

经过IP隧道实现虚拟服务器（VS/TUN）

在 VS/NAT的集群系统中，请求和响应的数据报文都须要经过负载调度器，当真实服务器的数目在10台和20台之间时，负载调度器将成为整个集群系统的新瓶颈。大多数Internet服务都有这样的特色：请求报文较短而响应报文每每包含大量的数据。若是能将请求和响应分开处理，即在负载调度器中只负责调度请求而响应直接返回给客户，将极大地提升整个集群系统的吞吐量。

IP隧道（IP tunneling）是将一个IP报文封装在另外一个IP报文的技术，这可使得目标为一个IP地址的数据报文能被封装和转发到另外一个IP地址。IP隧道技术亦称为IP封装技术（IP encapsulation）。IP隧道主要用于移动主机和虚拟私有网络（Virtual Private Network），在其中隧道都是静态创建的，隧道一端有一个IP地址，另外一端也有惟一的IP地址。

咱们利用IP隧道技术将请求报文封装转发给后端服务器，响应报文能从后端服务器直接返回给客户。但在这里，后端服务器有一组而非一个，因此咱们不可能静态地创建一一对应的隧道，而是动态地选择一台服务器，将请求报文封装和转发给选出的服务器。这样，咱们能够利用IP隧道的原理将一组服务器上的网络服务组成在一个IP地址上的虚拟网络服务。VS/TUN的体系结构如图4所示，各个服务器将VIP地址配置在本身的IP隧道设备上。

图4：VS/TUN的体系结构

VS/TUN 的工做流程如图5所示：它的链接调度和管理与VS/NAT中的同样，只是它的报文转发方法不一样。调度器根据各个服务器的负载状况，动态地选择一台服务器，将请求报文封装在另外一个IP报文中，再将封装后的IP报文转发给选出的服务器；服务器收到报文后，先将报文解封得到原来目标地址为VIP的报文，服务器发现VIP地址被配置在本地的IP隧道设备上，因此就处理这个请求，而后根据路由表将响应报文直接返回给客户。

图5：VS/TUN的工做流程

在这里须要指出，根据缺省的TCP/IP协议栈处理，请求报文的目标地址为VIP，响应报文的源地址确定也为VIP，因此响应报文不须要做任何修改，能够直接返回给客户，客户认为获得正常的服务，而不会知道到底是哪一台服务器处理的。

图6：半链接的TCP有限状态机

经过直接路由实现虚拟服务器（VS/DR）

跟 VS/TUN方法相同，VS/DR利用大多数Internet服务的非对称特色，负载调度器中只负责调度请求，而服务器直接将响应返回给客户，能够极大地提升整个集群系统的吞吐量。该方法与IBM的NetDispatcher产品中使用的方法相似（其中服务器上的IP地址配置方法是类似的），但IBM的 NetDispatcher是很是昂贵的商品化产品，咱们也不知道它内部所使用的机制，其中有些是IBM的专利。

VS/DR 的体系结构如图7所示：调度器和服务器组都必须在物理上有一个网卡经过不分断的局域网相连，如经过高速的交换机或者HUB相连。VIP地址为调度器和服务器组共享，调度器配置的VIP地址是对外可见的，用于接收虚拟服务的请求报文；全部的服务器把VIP地址配置在各自的Non-ARP网络设备上，它对外面是不可见的，只是用于处理目标地址为VIP的网络请求。

图7：VS/DR的体系结构

VS/DR 的工做流程如图8所示：它的链接调度和管理与VS/NAT和VS/TUN中的同样，它的报文转发方法又有不一样，将报文直接路由给目标服务器。在VS/DR 中，调度器根据各个服务器的负载状况，动态地选择一台服务器，不修改也不封装IP报文，而是将数据帧的MAC地址改成选出服务器的MAC地址，再将修改后的数据帧在与服务器组的局域网上发送。由于数据帧的MAC地址是选出的服务器，因此服务器确定能够收到这个数据帧，从中能够得到该IP报文。当服务器发现报文的目标地址VIP是在本地的网络设备上，服务器处理这个报文，而后根据路由表将响应报文直接返回给客户。

图8：VS/DR的工做流程

在VS/DR中，根据缺省的TCP/IP协议栈处理，请求报文的目标地址为VIP，响应报文的源地址确定也为VIP，因此响应报文不须要做任何修改，能够直接返回给客户，客户认为获得正常的服务，而不会知道是哪一台服务器处理的。

VS/DR负载调度器跟VS/TUN同样只处于从客户到服务器的半链接中，按照半链接的TCP有限状态机进行状态迁移。

三种方法的优缺点比较

三种IP负载均衡技术的优缺点概括在下表中：

	VS/NAT	VS/TUN	VS/DR
Server	any	Tunneling	Non-arp device
server network	private	LAN/WAN	LAN
server number	low (10~20)	High (100)	High (100)
server gateway	load balancer	own router	Own router

注：以上三种方法所能支持最大服务器数目的估计是假设调度器使用100M网卡，调度器的硬件配置与后端服务器的硬件配置相同，并且是对通常Web服务。使用更高的硬件配置（如千兆网卡和更快的处理器）做为调度器，调度器所能调度的服务器数量会相应增长。当应用不一样时，服务器的数目也会相应地改变。因此，以上数据估计主要是为三种方法的伸缩性进行量化比较。

Virtual Server via NAT

VS/NAT 的优势是服务器能够运行任何支持TCP/IP的操做系统，它只须要一个IP地址配置在调度器上，服务器组能够用私有的IP地址。缺点是它的伸缩能力有限，当服务器结点数目升到20时，调度器自己有可能成为系统的新瓶颈，由于在VS/NAT中请求和响应报文都须要经过负载调度器。咱们在Pentium 166 处理器的主机上测得重写报文的平均延时为60us，性能更高的处理器上延时会短一些。假设TCP报文的平均长度为536 Bytes，则调度器的最大吞吐量为8.93 MBytes/s. 咱们再假设每台服务器的吞吐量为800KBytes/s，这样一个调度器能够带动10台服务器。（注：这是很早之前测得的数据）

基于VS/NAT的的集群系统能够适合许多服务器的性能要求。若是负载调度器成为系统新的瓶颈，能够有三种方法解决这个问题：混合方法、VS/TUN和 VS /DR。在DNS混合集群系统中，有若干个VS/NAT负载调度器，每一个负载调度器带本身的服务器集群，同时这些负载调度器又经过RR-DNS组成简单的域名。但VS/TUN和VS/DR是提升系统吞吐量的更好方法。

对于那些将IP地址或者端口号在报文数据中传送的网络服务，须要编写相应的应用模块来转换报文数据中的IP地址或者端口号。这会带来实现的工做量，同时应用模块检查报文的开销会下降系统的吞吐率。

Virtual Server via IP Tunneling

在 VS/TUN的集群系统中，负载调度器只将请求调度到不一样的后端服务器，后端服务器将应答的数据直接返回给用户。这样，负载调度器就能够处理大量的请求，它甚至能够调度百台以上的服务器（同等规模的服务器），而它不会成为系统的瓶颈。即便负载调度器只有100Mbps的全双工网卡，整个系统的最大吞吐量可超过1Gbps。因此，VS/TUN能够极大地增长负载调度器调度的服务器数量。VS/TUN调度器能够调度上百台服务器，而它自己不会成为系统的瓶颈，能够用来构建高性能的超级服务器。

VS/TUN技术对服务器有要求，即全部的服务器必须支持“IP Tunneling”或者“IP Encapsulation”协议。目前，VS/TUN的后端服务器主要运行Linux操做系统，咱们没对其余操做系统进行测试。由于“IP Tunneling”正成为各个操做系统的标准协议，因此VS/TUN应该会适用运行其余操做系统的后端服务器。

Virtual Server via Direct Routing

跟VS/TUN方法同样，VS/DR调度器只处理客户到服务器端的链接，响应数据能够直接从独立的网络路由返回给客户。这能够极大地提升LVS集群系统的伸缩性。

跟VS/TUN相比，这种方法没有IP隧道的开销，可是要求负载调度器与实际服务器都有一块网卡连在同一物理网段上，服务器网络设备（或者设备别名）不做ARP响应，或者能将报文重定向（Redirect）到本地的Socket端口上。

小结

本文主要讲述了LVS集群中的三种IP负载均衡技术。在分析网络地址转换方法（VS/NAT）的缺点和网络服务的非对称性的基础上，咱们给出了经过IP隧道实现虚拟服务器的方法VS/TUN，和经过直接路由实现虚拟服务器的方法VS/DR，极大地提升了系统的伸缩性。

使用道具举报 linux

骑虎

你们网大学一年级算法

积分: 862
帖子: 161
精华: 11
经验: 584 点
威望: 0 点
金币: 458

4楼

发表于 2008-10-22 15:03:06 | 只看该做者

Linux服务器集群系统(四) LVS集群的负载调度

本文主要讲述了LVS集群的IP负载均衡软件IPVS在内核中实现的各类链接调度算法。针对请求的服务时间变化很大，给出一个动态反馈负载均衡算法，它结合内核中的加权链接调度算法，根据动态反馈回来的负载信息来调整服务器的权值，来进一步避免服务器间的负载不平衡。

前言

在上一篇文章中，咱们主要讲述了LVS集群中实现的三种IP负载均衡技术，它们主要解决系统的可伸缩性和透明性问题，如何经过负载调度器将请求高效地分发到不一样的服务器执行，使得由多台独立计算机组成的集群系统成为一台虚拟服务器；客户端应用程序与集群系统交互时，就像与一台高性能的服务器交互同样。

本文将主要讲述在负载调度器上的负载调度策略和算法，如何将请求流调度到各台服务器，使得各台服务器尽量地保持负载均衡。文章主要由两个部分组成。第一部分描述IP负载均衡软件IPVS在内核中所实现的各类链接调度算法；第二部分给出一个动态反馈负载均衡算法（Dynamic-feedback load balancing），它结合内核中的加权链接调度算法，根据动态反馈回来的负载信息来调整服务器的权值，来进一步避免服务器间的负载不平衡。

在下面描述中，咱们称客户的socket和服务器的socket之间的数据通信为链接，不管它们是使用TCP仍是UDP协议。对于UDP数据报文的调度，IPVS调度器也会为之创建调度记录并设置超时值（如5分钟）；在设定的时间内，来自同一地址（IP地址和端口）的UDP数据包会被调度到同一台服务器。

内核中的链接调度算法

IPVS 在内核中的负载均衡调度是以链接为粒度的。在HTTP协议（非持久）中，每一个对象从WEB服务器上获取都须要创建一个TCP链接，同一用户的不一样请求会被调度到不一样的服务器上，因此这种细粒度的调度在必定程度上能够避免单个用户访问的突发性引发服务器间的负载不平衡。

在内核中的链接调度算法上，IPVS已实现了如下八种调度算法：

* 轮叫调度（Round-Robin Scheduling）
* 加权轮叫调度（Weighted Round-Robin Scheduling）
* 最小链接调度（Least-Connection Scheduling）
* 加权最小链接调度（Weighted Least-Connection Scheduling）
* 基于局部性的最少连接（Locality-Based Least Connections Scheduling）
* 带复制的基于局部性最少连接（Locality-Based Least Connections with Replication Scheduling）
* 目标地址散列调度（Destination Hashing Scheduling）
* 源地址散列调度（Source Hashing Scheduling）

下面，咱们先介绍这八种链接调度算法的工做原理和算法流程，会在之后的文章中描述怎么用它们。

轮叫调度

轮叫调度（Round Robin Scheduling）算法就是以轮叫的方式依次将请求调度不一样的服务器，即每次调度执行i = (i + 1) mod n，并选出第i台服务器。算法的优势是其简洁性，它无需记录当前全部链接的状态，因此它是一种无状态调度。

在系统实现时，咱们引入了一个额外条件，当服务器的权值为零时，表示该服务器不可用而不被调度。这样作的目的是将服务器切出服务（如屏蔽服务器故障和系统维护），同时与其余加权算法保持一致。因此，算法要做相应的改动，它的算法流程以下：

轮叫调度算法流程

假设有一组服务器S = {S0, S1, …, Sn-1}，一个指示变量i表示上一次选择的
服务器，W(Si)表示服务器Si的权值。变量i被初始化为n-1，其中n > 0。
j = i;
do {
j = (j + 1) mod n;
if (W(Sj) > 0) {
i = j;
return Si;
}
} while (j != i);
return NULL;

轮叫调度算法假设全部服务器处理性能均相同，无论服务器的当前链接数和响应速度。该算法相对简单，不适用于服务器组中处理性能不一的状况，并且当请求服务时间变化比较大时，轮叫调度算法容易致使服务器间的负载不平衡。

虽然Round-Robin DNS方法也是以轮叫调度的方式将一个域名解析到多个IP地址，但轮叫DNS方法的调度粒度是基于每一个域名服务器的，域名服务器对域名解析的缓存会妨碍轮叫解析域名生效，这会致使服务器间负载的严重不平衡。这里，IPVS轮叫调度算法的粒度是基于每一个链接的，同一用户的不一样链接都会被调度到不一样的服务器上，因此这种细粒度的轮叫调度要比DNS的轮叫调度优越不少。

加权轮叫调度

加权轮叫调度（Weighted Round-Robin Scheduling）算法能够解决服务器间性能不一的状况，它用相应的权值表示服务器的处理性能，服务器的缺省权值为1。假设服务器A的权值为1，B的权值为2，则表示服务器B的处理性能是A的两倍。加权轮叫调度算法是按权值的高低和轮叫方式分配请求到各服务器。权值高的服务器先收到的链接，权值高的服务器比权值低的服务器处理更多的链接，相同权值的服务器处理相同数目的链接数。加权轮叫调度算法流程以下：

加权轮叫调度算法流程

假设有一组服务器S = {S0, S1, …, Sn-1}，W(Si)表示服务器Si的权值，一个
指示变量i表示上一次选择的服务器，指示变量cw表示当前调度的权值，max(S)
表示集合S中全部服务器的最大权值，gcd(S)表示集合S中全部服务器权值的最大
公约数。变量i和cw最初都被初始化为零。
while (true) {
if (i == 0) {
cw = cw - gcd(S);
if (cw <= 0) {
cw = max(S);
if (cw == 0)
return NULL;
}
} else i = (i + 1) mod n;
if (W(Si) >= cw)
return Si;
}

例如，有三个服务器A、B和C分别有权值四、3和2，则在一个调度周期内(mod sum(W(Si)))调度序列为AABABCABC。加权轮叫调度算法仍是比较简单和高效。当请求的服务时间变化很大，单独的加权轮叫调度算法依然会致使服务器间的负载不平衡。

从上面的算法流程中，咱们能够看出当服务器的权值为零时，该服务器不被被调度；当全部服务器的权值为零，即对于任意i有W(Si)=0，则没有任何服务器可用，算法返回NULL，全部的新链接都会被丢掉。加权轮叫调度也无需记录当前全部链接的状态，因此它也是一种无状态调度。

最小链接调度

最小链接调度（Least-Connection Scheduling）算法是把新的链接请求分配到当前链接数最小的服务器。最小链接调度是一种动态调度算法，它经过服务器当前所活跃的链接数来估计服务器的负载状况。调度器须要记录各个服务器已创建链接的数目，当一个请求被调度到某台服务器，其链接数加1；当链接停止或超时，其链接数减一。

在系统实现时，咱们也引入当服务器的权值为零时，表示该服务器不可用而不被调度，它的算法流程以下：

最小链接调度算法流程

假设有一组服务器S = {S0, S1, ..., Sn-1}，W(Si)表示服务器Si的权值，
C(Si)表示服务器Si的当前链接数。
for (m = 0; m < n; m++) {
if (W(Sm) > 0) {
for (i = m+1; i < n; i++) {
if (W(Si) <= 0)
continue;
if (C(Si) < C(Sm))
m = i;
}
return Sm;
}
}
return NULL;

当各个服务器有相同的处理性能时，最小链接调度算法能把负载变化大的请求分布平滑到各个服务器上，全部处理时间比较长的请求不可能被发送到同一台服务器上。可是，当各个服务器的处理能力不一样时，该算法并不理想，由于TCP链接处理请求后会进入TIME_WAIT状态，TCP的TIME_WAIT通常为2 分钟，此时链接还占用服务器的资源，因此会出现这样情形，性能高的服务器已处理所收到的链接，链接处于TIME_WAIT状态，而性能低的服务器已经忙于处理所收到的链接，还不断地收到新的链接请求。

加权最小链接调度

加权最小链接调度（Weighted Least-Connection Scheduling）算法是最小链接调度的超集，各个服务器用相应的权值表示其处理性能。服务器的缺省权值为1，系统管理员能够动态地设置服务器的权值。加权最小链接调度在调度新链接时尽量使服务器的已创建链接数和其权值成比例。加权最小链接调度的算法流程以下：

加权最小链接调度的算法流程

假设有一组服务器S = {S0, S1, ..., Sn-1}，W(Si)表示服务器Si的权值，
C(Si)表示服务器Si的当前链接数。全部服务器当前链接数的总和为
CSUM = ΣC(Si)  (i=0, 1, .. , n-1)。当前的新链接请求会被发送服务器Sm，
当且仅当服务器Sm知足如下条件
  (C(Sm) / CSUM)/ W(Sm) = min { (C(Si) / CSUM) / W(Si)}  (i=0, 1, . , n-1)
  其中W(Si)不为零
由于CSUM在这一轮查找中是个常数，因此判断条件能够简化为
  C(Sm) / W(Sm) = min { C(Si) / W(Si)}  (i=0, 1, . , n-1)
  其中W(Si)不为零
由于除法所需的CPU周期比乘法多，且在Linux内核中不容许浮点除法，服务器的
权值都大于零，因此判断条件C(Sm) / W(Sm) > C(Si) / W(Si) 能够进一步优化
为C(Sm)*W(Si) > C(Si)* W(Sm)。同时保证服务器的权值为零时，服务器不被调
度。因此，算法只要执行如下流程。
for (m = 0; m < n; m++) {
if (W(Sm) > 0) {
for (i = m+1; i < n; i++) {
if (C(Sm)*W(Si) > C(Si)*W(Sm))
m = i;
}
return Sm;
}
}
return NULL;

基于局部性的最少连接调度

基于局部性的最少连接调度（Locality-Based Least Connections Scheduling，如下简称为LBLC）算法是针对请求报文的目标IP地址的负载均衡调度，目前主要用于Cache集群系统，由于在Cache集群中客户请求报文的目标IP地址是变化的。这里假设任何后端服务器均可以处理任一请求，算法的设计目标是在服务器的负载基本平衡状况下，将相同目标IP地址的请求调度到同一台服务器，来提升各台服务器的访问局部性和主存Cache命中率，从而整个集群系统的处理能力。

LBLC调度算法先根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于其一半的工做负载，则用“最少连接”的原则选出一个可用的服务器，将请求发送到该服务器。该算法的详细流程以下：

LBLC调度算法流程

假设有一组服务器S = {S0, S1, ..., Sn-1}，W(Si)表示服务器Si的权值，
C(Si)表示服务器Si的当前链接数。ServerNode[dest_ip]是一个关联变量，表示
目标IP地址所对应的服务器结点，通常来讲它是经过Hash表实现的。WLC(S)表示
在集合S中的加权最小链接服务器，即前面的加权最小链接调度。Now为当前系统
时间。
if (ServerNode[dest_ip] is NULL) then {
n = WLC(S);
if (n is NULL) then return NULL;
ServerNode[dest_ip].server = n;
} else {
n = ServerNode[dest_ip].server;
if ((n is dead) OR
(C(n) > W(n) AND
there is a node m with C(m) < W(m)/2))) then {
n = WLC(S);
if (n is NULL) then return NULL;
ServerNode[dest_ip].server = n;
}
}
ServerNode[dest_ip].lastuse = Now;
return n;

此外，对关联变量 ServerNode[dest_ip]要进行周期性的垃圾回收（Garbage Collection），将过时的目标IP地址到服务器关联项进行回收。过时的关联项是指哪些当前时间（实现时采用系统时钟节拍数jiffies）减去最近使用时间超过设定过时时间的关联项，系统缺省的设定过时时间为24小时。

带复制的基于局部性最少连接调度

带复制的基于局部性最少连接调度（Locality-Based Least Connections with Replication Scheduling，如下简称为LBLCR）算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不一样之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。对于一个“热门”站点的服务请求，一台Cache 服务器可能会忙不过来处理这些请求。这时，LBLC调度算法会从全部的Cache服务器中按“最小链接”原则选出一台Cache服务器，映射该“热门”站点到这台Cache服务器，很快这台Cache服务器也会超载，就会重复上述过程选出新的Cache服务器。这样，可能会致使该“热门”站点的映像会出现在全部的Cache服务器上，下降了Cache服务器的使用效率。LBLCR调度算法将“热门”站点映射到一组Cache服务器（服务器集合），当该“热门”站点的请求负载增长时，会增长集合里的Cache服务器，来处理不断增加的负载；当该“热门”站点的请求负载下降时，会减小集合里的Cache服务器数目。这样，该“热门”站点的映像不太可能出如今全部的Cache服务器上，从而提供Cache集群系统的使用效率。

LBLCR 算法先根据请求的目标IP地址找出该目标IP地址对应的服务器组；按“最小链接”原则从该服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载；则按“最小链接”原则从整个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以下降复制的程度。LBLCR调度算法的流程以下：

LBLCR调度算法流程

假设有一组服务器S = {S0, S1, ..., Sn-1}，W(Si)表示服务器Si的权值，
C(Si)表示服务器Si的当前链接数。ServerSet[dest_ip]是一个关联变量，表示
目标IP地址所对应的服务器集合，通常来讲它是经过Hash表实现的。WLC(S)表示
在集合S中的加权最小链接服务器，即前面的加权最小链接调度；WGC(S)表示在
集合S中的加权最大链接服务器。Now为当前系统时间，lastmod表示集合的最近
修改时间，T为对集合进行调整的设定时间。
if (ServerSet[dest_ip] is NULL) then {
n = WLC(S);
if (n is NULL) then return NULL;
add n into ServerSet[dest_ip];
} else {
n = WLC(ServerSet[dest_ip]);
if ((n is NULL) OR
      (n is dead) OR
      (C(n) > W(n) AND
      there is a node m with C(m) < W(m)/2))) then {
n = WLC(S);
if (n is NULL) then return NULL;
add n into ServerSet[dest_ip];
} else
if (|ServerSet[dest_ip]| > 1 AND
      Now - ServerSet[dest_ip].lastmod > T) then {
m = WGC(ServerSet[dest_ip]);
remove m from ServerSet[dest_ip];
}
}
ServerSet[dest_ip].lastuse = Now;
if (ServerSet[dest_ip] changed) then
ServerSet[dest_ip].lastmod = Now;
return n;

此外，对关联变量 ServerSet[dest_ip]也要进行周期性的垃圾回收（Garbage Collection），将过时的目标IP地址到服务器关联项进行回收。过时的关联项是指哪些当前时间（实现时采用系统时钟节拍数jiffies）减去最近使用时间（lastuse）超过设定过时时间的关联项，系统缺省的设定过时时间为24小时。

目标地址散列调度

目标地址散列调度（Destination Hashing Scheduling）算法也是针对目标IP地址的负载均衡，但它是一种静态映射算法，经过一个散列（Hash）函数将一个目标IP地址映射到一台服务器。

目标地址散列调度算法先根据请求的目标IP地址，做为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，不然返回空。该算法的流程以下：

目标地址散列调度算法流程

假设有一组服务器S = {S0, S1, ..., Sn-1}，W(Si)表示服务器Si的权值，
C(Si)表示服务器Si的当前链接数。ServerNode[]是一个有256个桶（Bucket）的
Hash表，通常来讲服务器的数目会运小于256，固然表的大小也是能够调整的。
算法的初始化是将全部服务器顺序、循环地放置到ServerNode表中。若服务器的
链接数目大于2倍的权值，则表示服务器已超载。
n = ServerNode[hashkey(dest_ip)];
if ((n is dead) OR
(W(n) == 0) OR
(C(n) > 2*W(n))) then
return NULL;
return n;

在实现时，咱们采用素数乘法Hash函数，经过乘以素数使得散列键值尽量地达到较均匀的分布。所采用的素数乘法Hash函数以下：

素数乘法Hash函数

static inline unsigned hashkey(unsigned int dest_ip)
{
return (dest_ip* 2654435761UL) & HASH_TAB_MASK;
}
其中，2654435761UL是2到2^32 (4294967296)间接近于黄金分割的素数，
(sqrt(5) - 1) / 2 = 0.618033989
2654435761 / 4294967296 = 0.618033987

源地址散列调度

源地址散列调度（Source Hashing Scheduling）算法正好与目标地址散列调度算法相反，它根据请求的源IP地址，做为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，不然返回空。它采用的散列函数与目标地址散列调度算法的相同。它的算法流程与目标地址散列调度算法的基本类似，除了将请求的目标IP地址换成请求的源IP地址，因此这里不一一叙述。

在实际应用中，源地址散列调度和目标地址散列调度能够结合使用在防火墙集群中，它们能够保证整个系统的惟一出入口。

动态反馈负载均衡算法

动态反馈负载均衡算法考虑服务器的实时负载和响应状况，不断调整服务器间处理请求的比例，来避免有些服务器超载时依然收到大量请求，从而提升整个系统的吞吐率。图1显示了该算法的工做环境，在负载调度器上运行Monitor Daemon进程，Monitor Daemon来监视和收集各个服务器的负载信息。Monitor Daemon可根据多个负载信息算出一个综合负载值。Monitor Daemon将各个服务器的综合负载值和当前权值算出一组新的权值，若新权值和当前权值的差值大于设定的阀值，Monitor Daemon将该服务器的权值设置到内核中的IPVS调度中，而在内核中链接调度通常采用加权轮叫调度算法或者加权最小链接调度算法。

动态反馈负载均衡算法的工做环境

链接调度

当客户经过TCP链接访问网络访问时，服务所需的时间和所要消耗的计算资源是千差万别的，它依赖于不少因素。例如，它依赖于请求的服务类型、当前网络带宽的状况、以及当前服务器资源利用的状况。一些负载比较重的请求须要进行计算密集的查询、数据库访问、很长响应数据流；而负载比较轻的请求每每只须要读一个 HTML页面或者进行很简单的计算。

请求处理时间的千差万别可能会致使服务器利用的倾斜（Skew），即服务器间的负载不平衡。例如，有一个WEB页面有A、B、C和D文件，其中D是大图像文件，浏览器须要创建四个链接来取这些文件。当多个用户经过浏览器同时访问该页面时，最极端的状况是全部D文件的请求被发到同一台服务器。因此说，有可能存在这样状况，有些服务器已经超负荷运行，而其余服务器基本是闲置着。同时，有些服务器已经忙不过来，有很长的请求队列，还不断地收到新的请求。反过来说，这会致使客户长时间的等待，以为系统的服务质量差。

简单链接调度

简单链接调度可能会使得服务器倾斜的发生。在上面的例子中，若采用轮叫调度算法，且集群中正好有四台服务器，必有一台服务器老是收到D文件的请求。这种调度策略会致使整个系统资源的低利用率，由于有些资源被用尽致使客户的长时间等待，而其余资源空闲着。

实际TCP/IP流量的特征

文献[1]说明网络流量是呈波浪型发生的，在一段较长时间的小流量后，会有一段大流量的访问，而后是小流量，这样跟波浪同样周期性地发生。文献 [2,3,4,5]揭示在WAN和LAN上网络流量存在自类似的特征，在WEB访问流也存在自类似性。这就须要一个动态反馈机制，利用服务器组的状态来应对访问流的自类似性。

动态反馈负载均衡机制

TCP/IP流量的特征通俗地说是有许多短事务和一些长事务组成，而长事务的工做量在整个工做量占有较高的比例。因此，咱们要设计一种负载均衡算法，来避免长事务的请求总被分配到一些机器上，而是尽量将带有毛刺（Burst）的分布分割成相对较均匀的分布。

咱们提出基于动态反馈负载均衡机制，来控制新链接的分配，从而控制各个服务器的负载。例如，在IPVS调度器的内核中使用加权轮叫调度（Weighted Round-Robin Scheduling）算法来调度新的请求链接；在负载调度器的用户空间中运行Monitor Daemon。Monitor Daemon定时地监视和收集各个服务器的负载信息，根据多个负载信息算出一个综合负载值。Monitor Daemon将各个服务器的综合负载值和当前权值算出一组新的权值。当综合负载值表示服务器比较忙时，新算出的权值会比其当前权值要小，这样新分配到该服务器的请求数就会少一些。当综合负载值表示服务器处于低利用率时，新算出的权值会比其当前权值要大，来增长新分配到该服务器的请求数。若新权值和当前权值的差值大于设定的阀值，Monitor Daemon将该服务器的权值设置到内核中的IPVS调度中。过了必定的时间间隔（如2秒钟），Monitor Daemon再查询各个服务器的状况，并相应调整服务器的权值；这样周期性地进行。能够说，这是一个负反馈机制，使得服务器保持较好的利用率。

在加权轮叫调度算法中，当服务器的权值为零，已创建的链接会继续获得该服务器的服务，而新的链接不会分配到该服务器。系统管理员能够将一台服务器的权值设置为零，使得该服务器安静下来，当已有的链接都结束后，他能够将该服务器切出，对其进行维护。维护工做对系统都是不可少的，好比硬件升级和软件更新等，零权值使得服务器安静的功能很主要。因此，在动态反馈负载均衡机制中咱们要保证该功能，当服务器的权值为零时，咱们不对服务器的权值进行调整。

综合负载

在计算综合负载时，咱们主要使用两大类负载信息：输入指标和服务器指标。输入指标是在调度器上收集到的，而服务器指标是在服务器上的各类负载信息。咱们用综合负载来反映服务器当前的比较确切负载状况，对于不一样的应用，会有不一样的负载状况，这里咱们引入各个负载信息的系数，来表示各个负载信息在综合负载中轻重。系统管理员根据不一样应用的需求，调整各个负载信息的系数。另外，系统管理员设置收集负载信息的时间间隔。

输入指标主要是在单位时间内服务器收到新链接数与平均链接数的比例，它是在调度器上收集到的，因此这个指标是对服务器负载状况的一个估计值。在调度器上有各个服务器收到链接数的计数器，对于服务器Si，能够获得分别在时间T1和T2时的计数器值Ci1和Ci2，计算出在时间间隔T2-T1内服务器Si收到新链接数Ni = Ci2 - Ci1。这样，获得一组服务器在时间间隔T2-T1内服务器Si收到新链接数{Ni}，服务器Si的输入指标INPUTi为其新链接数与n台服务器收到平均链接数的比值，其公式为

服务器指标主要记录服务器各类负载信息，如服务器当前CPU负载LOADi、服务器当前磁盘使用状况Di、当前内存利用状况Mi和当前进程数目Pi。有两种方法能够得到这些信息；一是在全部的服务器上运行着SNMP（Simple Network Management Protocol）服务进程，而在调度器上的Monitor Daemon经过SNMP向各个服务器查询得到这些信息；二是在服务器上实现和运行收集信息的Agent，由Agent定时地向Monitor Daemon报告负载信息。若服务器在设定的时间间隔内没有响应，Monitor Daemon认为服务器是不可达的，将服务器在调度器中的权值设置为零，不会有新的链接再被分配到该服务器；若在下一次服务器有响应，再对服务器的权值进行调整。再对这些数据进行处理，使其落在[0, ∞)的区间内，1表示负载正好，大于1表示服务器超载，小于1表示服务器处于低负载状态。得到调整后的数据有DISKi、MEMORYi和 PROCESSi。

另外一个重要的服务器指标是服务器所提供服务的响应时间，它能比较好地反映服务器上请求等待队列的长度和请求的处理时间。调度器上的Monitor Daemon做为客户访问服务器所提供的服务，测得其响应时间。例如，测试从WEB服务器取一个HTML页面的响应延时，Monitor Daemon只要发送一个“GET /”请求到每一个服务器，而后记录响应时间。若服务器在设定的时间间隔内没有响应，Monitor Daemon认为服务器是不可达的，将服务器在调度器中的权值设置为零。一样，咱们对响应时间进行如上调整，获得RESPONSEi。

这里，咱们引入一组能够动态调整的系数Ri来表示各个负载参数的重要程度，其中ΣRi = 1。综合负载能够经过如下公式计算出：

例如，在WEB服务器集群中，咱们采用如下系数{0.1, 0.3, 0.1, 0.1, 0.1, 0.3}，认为服务器的CPU负载和请求响应时间较其余参数重要一些。若当前的系数Ri不能很好地反映应用的负载，系统管理员能够对系数不断地修正，直到找到贴近当前应用的一组系数。

另外，关于查询时间间隔的设置，虽然很短的间隔能够更确切地反映各个服务器的负载，可是很频繁地查询（如1秒钟几回）会给调度器和服务器带来必定的负载，如频繁执行的Monitor Daemon在调度器会有必定的开销，一样频繁地查询服务器指标会服务器带来必定的开销。因此，这里要有个折衷（Tradeoff），咱们通常建议将时间间隔设置在5到20秒之间。

权值计算

当服务器投入集群系统中使用时，系统管理员对服务器都设定一个初始权值DEFAULT_WEIGHTi，在内核的IPVS调度中也先使用这个权值。而后，随着服务器负载的变化，对权值进行调整。为了不权值变成一个很大的值，咱们对权值的范围做一个限制[DEFAULT_WEIGHTi, SCALE*DEFAULT_WEIGHTi]，SCALE是能够调整的，它的缺省值为10。

Monitor Daemon周期性地运行，若DEFAULT_WEIGHTi不为零，则查询该服务器的各负载参数，并计算出综合负载值AGGREGATE_LOADi。咱们引入如下权值计算公式，根据服务器的综合负载值调整其权值。

在公式中，0.95是咱们想要达到的系统利用率，A是一个可调整的系数（缺省值为5）。当综合负载值为0.95时，服务器权值不变；当综合负载值大于 0.95时，权值变小；当综合负载值小于0.95时，权值变大。若新权值大于SCALE*DEFAULT_WEIGHTi，咱们将新权值设为 SCALE*DEFAULT_WEIGHTi。若新权值与当前权值的差别超过设定的阀值，则将新权值设置到内核中的IPVS调度参数中，不然避免打断 IPVS调度的开销。咱们能够看出这是一个负反馈公式，会使得权值调整到一个稳定点，如系统达到理想利用率时，权值是不变的。

在实际使用中，若发现全部服务器的权值都小于他们的DEFAULT_WEIGHT，则说明整个服务器集群处于超载状态，这时须要加入新的服务器结点到集群中来处理部分负载；反之，若全部服务器的权值都接近于SCALE*DEFAULT_WEIGHT，则说明当前系统的负载都比较轻。

一个实现例子

咱们在RedHat集群管理工具Piranha[6]中实现了一个简单的动态反馈负载均衡算法。在综合负载上，它只考虑服务器的CPU负载（Load Average），使用如下公式进行权值调整：

服务器权值调整区间为[DEFAULT_WEIGHTi, 10*DEFAULT_WEIGHTi]，A为DEFAULT_WEIGHTi /2，而权值调整的阀值为DEFAULT_WEIGHTi /4。1是所想要达到的系统利用率。Piranha每隔20秒查询各台服务器的CPU负载，进行权值计算和调整。

小结本文主要讲述了IP虚拟服务器在内核中实现的八种链接调度算法： * 轮叫调度（Round-Robin Scheduling） * 加权轮叫调度（Weighted Round-Robin Scheduling） * 最小链接调度（Least-Connection Scheduling） * 加权最小链接调度（Weighted Least-Connection Scheduling） * 基于局部性的最少连接（Locality-Based Least Connections Scheduling） * 带复制的基于局部性最少连接（Locality-Based Least Connections with Replication Scheduling） * 目标地址散列调度（Destination Hashing Scheduling） * 源地址散列调度（Source Hashing Scheduling）由于请求的服务时间差别较大，内核中的链接调度算法容易使得服务器运行出现倾斜。为此，给出了一个动态反馈负载均衡算法，结合内核中的加权链接调度算法，根据动态反馈回来的负载信息来调整服务器的权值，来调整服务器间处理请求数的比例，从而避免服务器间的负载不平衡。动态反馈负载算法能够较好地避免服务器的倾斜，提升系统的资源使用效率，从而提升系统的吞吐率。