基于Linux的集群系统（三）实现过程之理论先导

OSI参考模型及TCP/IP参考模型

OSI模型（open system interconnection reference model）是基于国际标准化组织（ISO）的建议而发展起来的，它分为如图3-1所示的七层。当卫星和无线网络出现以后，现有的协议在和这些网络互联时出现了问题，所以需要一种新的参考体系结构，能无缝地连接多个网络。这个体系结构就是TCP/IP参考模型。

 

回页首

TCP 协议

因特网在传输层有两种主要的协议：一种是面向连接的协议，一种是无连接的协议。传输控制协议TCP是(transmission control protocol)专门用于在不可靠的因特网上提供可靠的、端对端的字节流通信的协议。通过在发送方和接收方分别创建一个称为套接字的通信端口就可以获得TCP服务。所有的TCP 连接均是全双工的和点到点的。

发送和接收方TCP实体以数据报的形式交换数据。一个数据报包含一个固定的20字节的头、一个可选部分以及0或多字节的数据。对数据报的大小有两个限制条 件：首先，每个数据报（包括TCP头在内）必须适合IP的载荷能力，不能超过65535字节；其次，每个网络都存在最大传输单元MTU（maximum transfer unit），要求每个数据报必须适合MTU。如果一个数据报进入了一个MTU小于该数据报长度的网络，那么处于网络边界上的路由器会把该数据报分解为多个 小的数据报。

TCP实体所采用的基本协议是滑动窗口协议。当发送方传送一个数据报时，它将启动计时器。当该数据报到达目的地后，接收方的TCP实体向回发送一个数据 报，其中包含有一个确认序号，它等于希望收到的下一个数据报的顺序号。如果发送方的定时器在确认信息到达之前超时，那么发送方会重发该数据报。

2.1 TCP数据报头

图3-2给出了TCP数据报头的格式。

 

源端口、目的端口：16位长。标识出远端和本地的端口号。

顺序号：32位长。表明了发送的数据报的顺序。

确认号：32位长。希望收到的下一个数据报的序列号。

TCP头长：4位长。表明TCP头中包含多少个32位字。

接下来的6位未用。 
ACK：ACK位置1表明确认号是合法的。如果ACK为0，那么数据报不包含确认信息，确认字段被省略。

PSH：表示是带有PUSH标志的数据。接收方因此请求数据报一到便可送往应用程序而不必等到缓冲区装满时才传送。

RST：用于复位由于主机崩溃或其它原因而出现的错误的连接。还可以用于拒绝非法的数据报或拒绝连接请求。

SYN：用于建立连接。

FIN：用于释放连接。

窗口大小：16位长。窗口大小字段表示在确认了字节之后还可以发送多少个字节。

校验和：16位长。是为了确保高可靠性而设置的。它校验头部、数据和伪TCP头部之和。

可选项：0个或多个32位字。包括最大TCP载荷，窗口比例、选择重发数据报等选项。

1. 最大TCP载荷：允许每台主机设定其能够接受的最大的TCP载荷能力。在建立连接期间，双方均声明其最大载荷能力，并选取其中较小的作为标准。如果一台主机未使用该选项，那么其载荷能力缺省设置为536字节。
2. 窗口比例：允许发送方和接收方商定一个合适的窗口比例因子。这一因子使滑动窗口最大能够达到232字节。
3. 选择重发数据报：这个选项允许接收方请求发送指定的一个或多个数据报。

2.2 连接管理

在TCP中建立连接采用三次握手的方法。为了建立连接，其中一方，如服务器，通过执行LISTEN和ACCEPT原语被动地等待一个到达的连接请求。

另一方，如客户方，执行CONNECT原语，同时要指明它想连接到的IP地址和端口号，设置它能够接受的TCP数据报的最大值，以及一些可选的用户数据。CONNECT原语发送一个SYN=1，ACK=0的数据报到目的端，并等待对方响应。

该数据报到达目的端后，那里的TCP实体将察看是否有进程在侦听目的端口字段指定的端口。如果没有，它将发送一个RST=1的应答，拒绝建立该连接。

如果某个进程正在对该端口进行侦听，于是便将到达的TCP数据报交给该进程，它可以接受或拒绝建立连接。如果接受，便发回一个确认数据报。一般情况下，TCP的连接建立过程如图3-3所示。

 

为了释放连接，每方均可发送一个FIN=1的TCP数据报，表明本方已无数据发送。当FIN数据报被确认后，那个方向的连接即告关闭。当两个方向上的连接 均关闭后，该连接就被完全释放了。一般情况下，释放一个连接需要4个TCP数据报：每个方向均有一个FIN数据报和一个ACK数据报。

2.3 传输策略

TCP 中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数 据。当滑动窗口为0时，发送方一般不能再发送数据报，但有两种情况除外，一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程。另一种情 况是发送方可以发送一个1字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。

2.4 拥塞控制

当加载到某个网络上的载荷能力超过其处理能力时，便会出现拥塞现象。对于因特网来说有两个潜在的问题--网络的容量和接收方的容量，应该分别进行处理。发送方始终保持两个窗口：接收方承认的窗口和拥塞窗口。取两个窗口的最小值作为可以发送的字节数。

当建立连接时，发送方将拥塞窗口大小初始化为该连接所用的最大数据报的长度值，并随后发送一个最大长度的数据报。如果该数据报在定时器超时之前得到了确 认，那么发送方会在原拥塞窗口的基础上再增加一个数据报的字节值，使其为两倍最大数据报的大小，然后发送两个数据报。当这些数据报中的每一个都被确认后， 拥塞窗口大小就再增加一个最大数据报的长度。当拥塞窗口是N个数据报的大小时，如果发送的所有N个数据报都被及时确认，那么将拥塞窗口大小增加N个数据报 对应的字节数目。拥塞窗口保持指数规律增大，直到数据传输超时或者达到接收方设定的窗口大小。拥塞窗口便设置为恰好不造成超时或达到接收方的窗口大小的字 节数。

2.5 定时器管理

TCP使用多个定时器，如重发定时器、持续定时器、"keep alive"定时器等。 最重要的是重发定时器。在发送一个数据报的同时，启动一个数据重发定时器。如果在定时器超时前该数据报被确认，则关闭该定时器；相反，如果在确认到达之前定时器超时，则需要重发该数据报。

持续定时器用于防止出现死锁情况。 当一个连接长时间闲置时，"keep alive"定时器会超时而使一方去检测另一方是否仍然存在。如果它未得到响应，便终止该连接。

回页首

UDP协议

因特网协议组也支持无连接的传输协议UDP（user data protocol）。 UDP使用底层的因特网协议来传送报文，提供与IP一样的不可靠的、无连接的数据报传输服务。它不使用确认信息对报文的到达进行确认，不对收到的数据报进 行排序，也不提供反馈信息来控制机器之间传输的信息流量。UDP通信的可靠性方面的工作，包括报文的丢失、重复、乱序等现象，由使用UDP的应用程序来承 担。

一个UDP数据报包括一个8字节的头和数据部分。报头的格式如下图3-4所示，它包括四个长为16字节的字段。源端口和目的端口的作用与TCP中的相同， 是用来标明源端和目的端的端口号。UDP长度字段指明包括8个字节的头和数据在内的数据报长度。UDP校验和字段是可选项，用于纪录 UDP头、UDP伪头、用户数据三者的校验和。

 

回页首

IP协议

IP协议提供了不可靠的、无连接的数据报传输机制。TCP/IP是为了适应物理网络的多样性而设计的，而这种适应性主要是通过IP层来体现的。由于物理网 络的多样性，各种物理网络的数据帧格式、地址格式之间的差异很大。为了将这些底层的细节屏蔽起来，使得采用不同物理网络的网络之间进行通讯， TCP/IP分别采用了IP数据报和IP地址作为物理数据帧与物理地址的统一描述形式。 这样IP向上层提供统一的IP数据报和统一的IP地址，使得各种物理帧及物理地址的差异性对上层协议不复存在。

4.1 IP数据报头

一个IP数据报由一个头部和数据部分构成。头部包括一个20字节的固定长度部分和一个可选任意长度部分。头部格式如图3-5所示。

 

版本：4位长。记录了数据报对应的协议版本号。当前的IP协议有两个版本：IPV4 和IPV6。

IHL：4位长。代表头部的总长度，以32位字节为一个单位。

服务类型：8位长。使主机可以告诉子网它想要什么样的服务。如下图所示，服务类型域又分为了5个部分。优先权字段是标志优先级的；三个标志位分别代表延迟、吞吐量、可靠性。

 

总长：16位。指头部和数据的总长。最大长度是65535个字节。

标识：16位。通过它使目的主机判断新来的分段属于哪个分组，所有属于同一分组的分段包含同样的标识值。

DF：代表不要分段。它命令路由器不要将数据报分段，因为目的端不能重组分段。

MF：代表还有进一步的分段，用它来标志是否所有的分组都已到达。除了最后一个分段的所有分段都设置了这一位。

分段偏移：13位。标明分段在当前数据报的什么位置。

生命期：8位。用来限制分组生命周期的计数器。它在每个节点中都递减，而且当在一个路由器中排队时可以倍数递减。

协议：8位。说明将分组发送给那个传输进程，如TCR、VDP等。

头校验和：16位。仅用来校验头部。

源地址： 32位。产生IP数据报的源主机IP地址。

目的地址：32位。IP数据报的目的主机的IP地址。

可选项：是变长的。每个可选项用一个字节标明内容。有些可选项还跟有一字节的可选项长度字段，其后是一个或多个数据字节。现在已定义了安全性、严格的源路由选择、松的源路由选择、记录路由和时间标记五个可选项。但不是所有的路由器都支持全部5个可选项。

安全性选项说明了信息的安全程度。

严格的源路由选择选项以一系列的IP地址方式，给出了从源到目的地的完整路径。数据报必须严格地从这条路径传送。当路由选择表崩溃，系统管理员发送紧急分组时，或作时间测量时，此字段很有用。

松的源路由选择选项要求分组遍及所列的路由器，但它可以在其间穿过其它的路由器。

记录路由选项让沿途的路由器都将其IP地址加到可选字段之后，这使系统管理者可以跟踪路由选择算法的错误。

时间标记选项像记录路由选项一样，除了记录32位的IP地址外，每个路由器还要记录一个32位的时间标记。同样地，这一选择可用来为路由选择算法查错。

4.2 IP数据报的分段与重组

IP 数据报是通过封装为物理帧来传输的。由于因特网是通过各种不同物理网络技术互连起来的，在因特网的不同部分，物理帧的大小（最大传输单元MTU）可能各不 相同。为了最大程度的利用物理网络的能力，IP模块以所在的物理网络的MTU做为依据，来确定IP数据报的大小。当IP数据报在两个不同MTU的网络之间 传输时，就可能出现IP数据报的分段与重组操作。

在IP头中控制分段和重组的IP头域有三个：标识域、标志域、分段偏移域。标识是源主机赋予IP数据报的标识符。目的主机根据标识域来判断收到的IP数据 报分段属于哪一个数据报，以进行IP数据报重组。标志域中的DF位标识该IP数据报是否允许分段。当需要对IP数据报进行分段时，如果DF位置1，网关将 会抛弃该IP数据报，并向源主机发送出错信息。标志域中的MF位标识该IP数据报分段是否是最后一个分段。分段偏移域记录了该IP数据报分段在原IP数据 报中的偏移量。偏移量是8字节的整数倍。分段偏移域被用来确定该IP数据报分段在IP数据报重组时的顺序。

IP数据报在被传输过程中，一旦被分段，各段就作为独立的IP数据报进行传输，在到达目的主机之前有可能会被再次或多次分段。但是IP数据报分段的重组都只在目的主机进行。

4.3 IP对输入数据报的处理

IP对输入数据报的处理分为两种，一种是主机对数据报的处理，一种是网关对数据报的处理。

当IP数据报到达主机时，如果IP数据报的目的地址与主机地址匹配，IP接收该数据报并将它传给高级协议软件处理；否则抛弃该IP数据报。

网关则不同，当IP数据报到达网关IP层后，网关首先判断本机是否是数据报到达的目的主机。如果是，网关将接收到的IP数据报上传给高级协议软件处理。如果不是，网关将对接收到的IP数据报进行寻径，并随后将其转发出去。

4.4 IP对输出数据报的处理

IP对输出数据报的处理也分为两种，一种是主机对数据报的处理，一种是网关对数据报的处理。

对于网关来说，IP接收到IP数据报后，经过寻径，找到该IP数据报的传输路径。该路径实际上是全路径中的下一个网关的IP地址。然后，该网关将该IP数 据报和寻径到的下一个网关的地址交给网络接口软件。网络接口软件收到IP数据报和下一个网关地址后，首先调用ARP完成下一个网关IP地址到物理地址的映 射，然后将IP数据报封装成帧，最后由子网完成数据报的物理传输。

回页首

ICMP协议

ICMP(Internet Control Message Protocol)-因特网控制报文协议。ICMP主要用于差错信息和控制信息的构造及某些网络信息的获取。ICMP与IP 同属IP层，但ICMP报文是经IP封装后，作为IP数据报发送出去的。不把ICMP作为一个独立的协议层次，是因为ICMP不是上层协议的基础，在概念上构不成一个独立的层次。

ICMP消息包括以下类型：目的不可达、超时、参数问题、源端抑制、重定向、回声请求、回声应答、时间标记请求、时间标记应答。

目的不可达消息用来报告子网或路由器不能定位目的地，或设置了DF位的分组不能绕过"小分组"网络。

超时消息用来报告报文由于计时器为零而被丢弃。

参数问题消息表明在头部字段中发现了非法值。

源端抑制消息用来抑制发送过多分组的主机。当主机收到这个消息，就要减慢发送速度。

重定向消息在路由器发现可能出现了路由错误时发送。

回声请求和回声应答消息用来测试目的是否可达且正常运行。收到回声请求消息，目的端应该往回发一个回声应答消息。时间标记请求和时间标记应答与此类似，只是消息到达时间和应答发出时间应加入应答中，其好处是可以用来测试网络性能。

回页首

IP在Linux上的实现

如图3-6所示，Linux以分层的软件结构实现了TCP/IP协议。BSD套接字由一般性的套接字管理软件INET套接字层支持。INET套接字管理着 基于IP的TCP或UDP协议端。在传输UDP数据报时，Linux不必关心数据报是否安全到达目的端。但对TCP数据报来说，Linux需要对数据报进 行编号，数据报的源端和目的端需要协调工作，以便保证数据报不会丢失，或以错误的顺序发送。IP层包含的代码需要处理数据报的报头信息，并且必须将传入的 数据报发送到TCP或 UDP两者中正确的一层处理。在IP层之下是Linux的网络设备层，其中包括以太网设备或PPP设备等。和Linux系统中的其它设备不同，网络设备并 不总代表实际的物理设备，例如，回环设备就是一个纯软件设备。ARP协议提供地址解析功能，因此它处于IP层和网络设备层之间。

 

6.1 套接字缓冲区

Linux 利用套接字缓冲区在协议层和网络设备之间传送数据。Sk_buff包含了一些指针和长度信息，从而可让协议层以标准的函数或方法对应用程序的数据进行处 理。如图3-7所示，每个sk_buff均包含一个数据块、四个数据指针以及两个长度字段。利用四个数据指针，各协议层可操纵和管理套接字缓冲区的数据， 这四个指针的用途如下。

Head：指向内存中数据区的起始地址。Sk_buff和相关数据块在分配之后，该指针的值是固定的。

Data：指向协议数据的当前起始地址。该指针的值随当前拥有Sk_buff的协议层的变化而变化。

Tail：指向协议数据的当前结尾地址。和data指针一样，该指针的值也随当前拥有Sk_buff的协议层的变化而变化。

End：指向内存中数据区的结尾。和head指针一样，Sk_buff被分配之后，该指针的值也固定不变。

Sk_buff的两个长度字段，len和truesize，分别描述当前协议数据报的长度和数据缓冲区的实际长度。

 

6.2 接收IP数据报

当 网络设备从网络上接收到数据报时，它必须将接收到的数据转换为sk_buff数据结构，然后将该结构添加到backlog队列中排队。当backlog队 列变得很大时，接收到的sk_buff数据将会被丢弃。当新的sk_buff添加到backlog队列时，网络底层程序将被标志为就绪状态，从而可以让调 度程序调度底层程序进行处理。

调度程序最终会运行网络的底层处理程序。这时，网络底层处理程序将处理任何等待传输的数据报，但在这之前，底层处理程序首先会处理sk_buff结构的backlog队列。底层处理程序必须确定将接收到的数据报传递到哪个协议层。

在Linux进行网络层的初始化时，每个协议要在ptype_all链表或ptype_base哈希表中添加packet_type数据结构以进行注册。 Packet_type数据结构包含协议类型、指向网络设备的指针、指向协议的接收数据处理例程的指针等 。Ptype_base是一个哈希表，其哈希函数以协议标识符为参数，内核通常利用该哈希表判断应当接受传入的网络数据报的协议。通过检查 ptype_all链表和ptype_base哈希表，网络底层处理程序会复制新的sk_buff，最终，sk_buff会传递到一个或多个目标协议的处 理例程。

6.3 发送IP 数据报

网络处理代码必须建立sk_buff来包含要传输的数据，并且在协议层之间传递数据时，需要添加不同的协议头和协议尾。

首先，IP协议需要决定要使用的网络设备，网络设备的选择依赖于数据报的最佳路由。对于只利用调制解调器和PPP协议连接的计算机来说，路由的选择比较容易，但是对于连接到以太网的计算机来说，路由的选择是比较复杂的。

对每个要传输的IP数据报，IP利用路由表解析目标IP地址的路由。对每个可从路由表中找到路由的目标IP地址，路由表返回一个rtable数据结构描述 可使用的路由。这包括要使用的源地址、网络设备的device数据结构的地址以及预先建立的硬件头信息。该硬件头信息和网络设备相关，包含了源和目标的物 理地址以及其它的介质信息。

6.4 数据报的分段与重组

当 传输IP数据报时，IP从IP路由表中找到发送该IP数据报的网络设备，网络设备对应的device数据结构中包含由一个mtu字段，该字段描述最大的传 输单元。如果设备的mtu小于等待发送的IP数据报的大小，就需要将该IP数据报划分为小的片断。每个片断由一个sk_buff代表，其中的IP头标记为 数据报片断，以及该片断在IP数据报中的偏移。最后的数据报被标志为最后的IP片断。如果分段过程中IP不能分配sk_buff，则传输失败。

IP片断的接收较片断的发送更加复杂一些，因为IP片断可能以任意的顺序接收到，而在重组之前，必须接受到所有的片断。每次接收到IP数据报时，IP 要检查是否是一个分段数据报。当第一次接收到分段的消息时，IP建立一个新的ipq数据结构，并将它链接到由等待重组的IP片断形成的ipqueue链表 中。随着其他IP片断的接收，IP找到正确的ipq数据结构，同时建立新的ipfrag数据结构描述该片断。每个ipq数据结构中包含有其源和目标IP地 址、高层协议的标识符以及该IP帧的标识符，从而唯一描述了一个分段的IP接收帧。当所有的片断接收到之后，它们被组合成单一的sk_buff并传递到上 一级协议层处理。如果定时器在所有的片断到达之前到期，ipq数据结构和ipfrag被丢弃，并假定消息已经在传输中丢失，这时，高层协议需要请求源主机 重新发送丢失的信息。

  

在计算机硬件价格下降、计算机网络拓扑发展的情况下，分布式计算机系统给用户提供了一个丰富的资源集合。人们在研究分布式系统时，就注意到了这样一个问 题：在一个由网络连接起来的多计算机环境中，在某一时刻，一些计算机的负载比较重，而另外一些计算机的负载却比较轻。平衡各计算机之间的负载是任务分配与 调度的一个主要目标，它能够提高整个系统的性能。

为了改善系统的性能，通过在多台计算机之间合理地分配负载，使各台计算机的负载基本均衡，这种计算能力共享的形式，通常被称为负载平衡或负载共享。一般来说，"负载平衡"要达到的目标是使各台计算机之间的负载基本均衡，而"负载共享"意味着只是简单的负载的重新分配。

负载平衡包括两种，一种是静态负载平衡，一种是动态负载平衡。只是利用系统负载的平均信息，而忽视系统当前的负载状况的方法被称为静态负载平衡。根据系统当前的负载状况来调整任务划分的方法被称为动态负载平衡。

导致负载不平衡主要是由于：

1. 某些算法的迭代大小不是固定的，但迭代的大小在编译时却可以被求得；
2. 某些算法的迭代大小不是固定的，并且迭代的大小依赖于被处理的数据，在编译时无法求得；
3. 即使迭代大小是固定的，也会有许多不定因素导致计算速度的差异。

考察这三个原因，对第一种情况可在编译时估计各迭代的工作量，按照处理节点的处理能力分布迭代，这就是静态负载平衡的方法。对第二、三种情况来说，必须采 用动态负载平衡的手段，在运行过程中根据各个处理节点完成任务的情况，动态地迁移任务，实现动态负载平衡。进行动态负载平衡需要考察处理节点的处理能力， 它的基本依据是根据处理节点先前的处理速度预见未来的处理速度。

负载平衡算法

一个负载平衡算法都包含以下三个组成部分：

1. 信息策略：制定任务放置策略的制定者使用的负载和任务量，以及信息分配的方式。
2. 传送策略：基于任务和计算机负载，判断是否要把一个任务传送到其它计算机上处理。
3. 放置策略：对于适合传送到其它计算机处理的任务，选择任务将被传送的目的计算机。

负载平衡的上述三个部分之间是以不同的方式相互作用的。放置策略利用信息策略提供的负载信息，仅当任务被传送策略判断为适于传送之后才行动。

总之，负载平衡的目标是：提供最短的平均任务响应时间； 能适于变化的负载；是可靠的负载平衡机制。

回页首

信息策略

人们用来描述负载信息采用的参数有：

1. 运行队列中的任务数；
2. 系统调用的速率；
3. CPU上下文切换率；
4. 空闲CPU时间百分比；
5. 空闲存储器的大小（K字节）；
6. 1分钟内的平均负载。对于这些单个的负载描述参数，第（1）个，即采用运行队列中的任务数作为描述负载的参数被证明是最有效的，即它的平均任务响应时间最 短，并且已经得到广泛应用。但是，如果为了使系统信息更全面而采集了更多的参数，则往往由于增加了额外开销，却得不到所希望的性能改善。例如，采用将六个 参数中的某两个进行"AND"或"OR"组合，得到的平均响应时间反而比单个参数的平均响应时间还要差一些。

回页首

传送策略

为了简单起见，在选用传送策略时，多选用阀值策略。例如，Eager等人的方法是：在判断是否要在本地处理一个任务时，无需交换计算机之间的状态信息，一 旦服务队列或等待服务队列的长度大于阀值时，就传送这个任务，而且传送的是刚刚接收的任务。而进程迁移能够迁移正在执行的任务，是对这种只能传送刚刚接收 的任务的一种改进。

Zhou在模拟研究七个负载平衡算法时，其传送策略都采用阀值策略。它的阀值策略基于两个阀值∶计算机的负载阀值Load和任务执行时间阀值TCPU。如果计算机的负载超过Load并且任务的执行时间超过TCPU时，就把此任务传送到其它计算机执行。

回页首

放置策略

经过总结，共有以下四种放置策略。

1. 集中策略。每隔P秒，其中一个计算机被指定为"负载信息中心"（LIC），接受所有其它负载的变更值，并把它们汇集到一个"负载向量"中，然后把负载向量 广播给所有其它的计算机。当一台计算机认为一个任务适于传送到其它计算机上执行时，它就给LIC发送一个请求，并告知当前负载的值。LIC选一台具有最短 运行队列长度的计算机，并且通知任务所在的计算机把任务发送给它，同时，它把目的主机负载值增加1。
2. 阀值策略。随机选择一台计算机，判断若把任务传送到那台计算机后，那台计算机的任务队列长度是否会超过阀值。如果不超过阀值，就传送此任务；否则，随机选 择另一台计算机，并以同样方式判断，继续这样做直到找到一台合适的目的计算机，或探测次数超过一个静态值限制LP，当任务真正到达计算机以后，不管状态如 何，必须处理该任务。
3. 最短任务队列策略。随机选择LP台不同的计算机，察看每台计算机的任务队列长度，任务被传送到具有最短任务队列长度的计算机。当任务真正到达计算机，无论 状态如何，目的计算机必须处理该任务。对此策略的一个简单改进时，无论何时，遇到一台队列长度为0的计算机时，不再继续探测，因为可以确定此计算机是一台 可以接受的目的计算机。
4. 保 留策略。 当一个任务从一台计算机离开时，该计算机检查本地负载，如果负载小于阀值T1，就探测其它计算机，并在R个负载大于T1的计算机中登记该计算机的名字，并 把登记的内容保留到一个栈中。当一个任务到达一台超载的计算机时，就把这个任务传送到此台计算机栈顶的计算机上。如果一个计算机的负载低于T1，就清空栈 里保留的所有计算机名。

Zhou的论文中，比较了（2）和（3） 三种策略，结论是：以简单（计算不昂贵）的方式，利用少量状态信息，第（2）中方法往往获得比第（3）种方法更好的效果。第（3）中方法比较复杂，它必须用性能的改善来补偿额外花费，所以取得的效果会稍差一些[2]。

回页首

算法实现

目前，常见的算法有：中心任务调度策略、梯度模型策略、发送者启动策略和接收者启动策略。

1. 中心任务调度策略

   顾名思义，中心任务调度策略就是让一个特定的处理节点担任计算任务分配器的角色，我们称之为调度节点，而把其它完成计算任务的处理节点称作计算节点。调度节点为了掌握任务分布情况，需要维护一个任务分布表。

   在任务启动时，调度节点装入任务的预分布情况表，而计算节点则开始完成分配给它的计算任务。在执行过程中，计算节点按照一定的周期向调度节点提交计算任务 完成情况，由调度节点根据这些信息判断处理节点的处理能力，发出任务迁移指令，控制任务从重负载节点向轻负载节点流动，同时还要随之更新在调度节点上的任 务分布表。

   中心任务调度的优点显而易见：调度节点掌握所有节点的处理能力和任务的分布情况，因此它可以在综合各种因素的基础上找到最佳的任务迁移方式。但是在计算节 点很多时，所有计算机点都必然与中心节点通讯，必然导致严重的冲突，这会大大降低动态负载平衡的效率，甚至抵消动态负载平衡所带来的一切好处。

   另外，还应该注意到，调度节点在判断是否进行任务迁移时，计算节点必须等待，这无疑又浪费了计算节点的处理能力。一种改进的方法是调度节点在收到计算节点 的当前任务完成情况时，立即存储之，并把根据上次的信息做出的判断返回给计算节点以减少延迟，在空闲时再根据本次收到的信息做出判断，留到下次使用。这样 就把调度节点进行任务迁移决策的时间和计算节点完成计算任务的时间重叠了起来，降低了动态负载平衡的开销。

2. 梯度模型策略

   在中心任务调度策略中，计算节点越多，冲突就越多。为了减少冲突，适应大量处理节点的需要。梯度模型策略、发送者启动策略和接收者启动策略都不设置专用的调度节点，而且每个节点只与一部分节点进行交互，以减少由负载平衡导致的冲突。

   在梯度模型策略中，所有处理节点仅与直接相邻的节点进行交互，并引入两个阀值：M ₁ 和Mh。在运行过程中，我们将所在节点划分成三类：设一个节点的剩余任务量为t，如果t < M ₁则称之为轻负载节点；如果M ₁< t < M _h则称之为中负载节点；如果t > M _h则称之为重负载节点。另外，把从一个节点到与之最接近的轻负载节点的最短距离定义为这个节点的梯度。

   在启动时，每个节点都是重负载节点，梯度都是无穷大。在计算过程中，周期性地检查其剩余负载是否大于M1。当某一节点发现自身剩余的负载小于M1时就把它 的梯度设为零，随后把自身当前的梯度与相邻节点间的距离之和发送给相邻的节点。相邻的节点接收到这个新梯度，就与自身当前梯度进行比较。 如果自身梯度小于等于新梯度，则不做任何事；如果自身梯度大于新梯度，则将自身梯度设置为新梯度，并向发送给它新梯度信息的节点一样传播新梯度。这样，梯 度信息（实际上就是计算任务完成的情况）就会被传播开来，重负载节点就可以把它多余的负载发送给向临界点中梯度最小的节点。于是，计算任务就在梯度的引导 之下从重负载节点流向轻负载节点。

   可是，按照这种方式，有可能导致过多的计算任务涌向一个轻负载节点。如果轻负载节点接收了过多的新任务，就有可能重新变成中负载甚至重负载节点。一旦出现 这种情况，梯度信息就不再能够正确地引导计算任务了。为此，必须使轻负载节点察看要接受的计算任务，如果接收计算任务使本节点脱离轻节点状态，就拒绝接受 它。这虽然延迟了任务的接收，但随着时间的推移，轻负载节点实际上不久就可以接受被它拒绝接受的任务了，同时还可以保持节点的梯度的有效性。

3. 发送者启动策略

   发送者启动策略也引入了一个阀值M来把所有的处理节点划分成轻负载节点和重负载节点，所有当前剩余负载t > M的节点都被称为重负载节点，t < M的节点被称为轻负载节点。发送者启动策略还需要为每个节点定义一个相关域，节点只与它的相关域中的节点进行交互和任务传递。一个直观的相关域的定义是把所有与之相邻的节点作为相关域。

   在启动时，所有节点开始执行计算任务。在执行一段时间之后，节点就开始检查其自身是否是重负载节点。如果是重负载节点，则它就试图在相关域中均匀地分布任务。具体地：设该重负载节点的负载为l _p，相关域中有K个节点，其负载分别为l ₁，…….， l _k，则平均负载L _avg为：

   
    
   

   为了达到均匀分布，应求得重负载节点应该传递给每个相关域中节点的负载量m _k。我们首先引入h _k以避免负载被迁移到相关域中负载最重的重负载节点。如果L _avg> l _k，则 ，否则h _k= 0。那么m _k为

   
    
   

   随后该节点就可以按照m _k向各个相关节点发送任务了。

4. 接收者启动策略

   接收者启动策略与发送者启动策略除了是由轻负载节点启动，要求其它节点把任务发送给它之外，其它基本相同。

   接收者启动策略同样引入M以区分轻、重负载节点，引入相关域以确定交互范围。

   在启动时，所有节点开始执行计算任务，经过一段时间之后，一旦某个节点发现自身成为轻负载节点，就试图在它的相关域中均匀地分布负载。具体地：设该轻负载节点的负载为l _p ，相关域中有K个节点，其负载分别为l 1 ，…….， l _k，则平均负载L _avg为：

   
    
   

   为了达到均匀分布，应求得相关域中节点应该传递给轻负载节点的负载量m _k。我们首先引入权h _k以避免负载从负载更轻的相关域中的节点被迁移到该节点。如果L _avg< l _k， 则 ， 否则h _k=0。那么m _k为：

   
    
   

   随后该节点就可以按照m _k发出接受任务的请求了。

近年来，Internet的发展步入黄金时期，网上信息交换的数量正在呈指数形式的增长。特别是，由于电子商务的蓬勃发展，人们已经预计在下一世纪，网上消费将成为日常生活的重要形式。

随着网络硬件设备的飞速进步，网络带宽的瓶颈效应日趋减弱，WEB服务器的性能问题逐渐显现出来。单一的服务器系统处理客户请求的能力有限，如何处理快速增长的客户请求，是当前研究人员关注的重要问题。从目前的研究方向看，服务器方向的研究可以归结为两个方面：

1. 从实现机制上入手。主要研究Caching技术、预取技术等。这方面的研究主要从客户访问行为分析入手，研究可以缩小响应时间的方法，这些技术可以在现有服务器设备的基础上尽可能地提高系统的性能，但性能提高的程度有限。
2. 从体系结构入手。将过去单一的服务器结构扩充为集群式服务器结构。这种改造可能需要增加较大的开销，但可以显著提高服务器的总体性能。

体系结构研究	软件技术研究
单机服务器	协议分析
	缓存机制Caching
	预取技术Pre-fetching
	请求调度
集群服务器	节点分发

就某一商业Web站点而言，人们通常会认为，日访问人数越多，说明销售的潜力越大，潜在的购买者越多。但统计结果向我们显示的却是另一种结果。随着日访问 人数的增加，销售量上升到一定程度后，反而下降。图1给出的是某汽车销售网站网上销售的模拟计算结果。注意，当网站日查询业务量为正常的120%或更高 时，访问的服务时间明显增长，使得日收益反而比正常情况下降很多。

图1：某汽车销售商网上销售模拟计算结果

	正常	正常+10%	正常＋20％	正常＋30％
日查询业务量	92448	101693	110938	120182
服务器响应时间	2.86	3.80	5.67	11.28
损失交易比例	0	0	60%	95%
每日交易量	4622	5085	2219	300
日收入	83203	91524	39938	5408
可能的日收益	83203	91524	99844	108164
损失的日收益			59906	102756

究其原因，我们不难发现，服务器的性能是导致这种现象的最根本的原因。当服务器负载接近边界时，负载的一个小小的增长都有可能使服务器陷入象死锁那样的一 种境地。由此可以得出，如何优化Web服务器性能将是今后一段时间研究的一个热点。许多服务器制造商都在努力推出性能更加优良的服务器，但是单一服务器结 构有一个致命的缺陷，那就是由于服务器的处理能力有限，有可能会出现死锁的情况。死锁的产生是由于新请求的到达率大于系统服务率，系统没有能力在短期内处 理所有的请求，导致等待队列溢出，系统 稳定状态转为不稳定状态，最后崩溃。集群服务器具有良好的可扩展性，可以随着负载的增大动态地向集群中增加服务器，从而就避免了由于处理能力不足而导致的 系统崩溃。

回页首

粗粒度分发策略

在集群系统中，粒度指的是负载调度和迁移的单位。集群系统中的粗粒度指的是调度和迁移的单位是服务，而细粒度指的是进程。目前，关于集群式服务器的研究主 要集中在体系结构和负载平衡策略的研究上，其中负载平衡策略的研究又是体系结构研究的基础。早期的集群式服务器系统常采用Round-Robin DNS算法实现客户请求的分发。实际上是一种粗粒度的负载分配策略。

1.1 工作原理

正常情况下，域名服务器将主机名映射为一个IP地址，为了改善负载平衡状况，早期的集群服务器系统采用RR－DNS(Round-Robin DNS)调度算法将一个域名映射为一组IP地址，允许客户端链接到服务器集群中的某一台服务器上，由此提供了服务器站点的伸缩性。一些可伸缩Web服务器(例如Eddie和NCSA的Scalable Web Server)采用RR-DNS实现负载平衡，一些高吞吐率的站点(Yahoo)也继续采用这种简单应用。图2为这类服务器结构的工作原理图。

图 2 基于DNS机制的集群服务器结构
 

RR－DNS在解析域名时，附加一个生存期(TTL：Time-To-Live)，这样一个请求生成后TTL时间内没有获得应答信息，可以向RR－DNS获取不同的IP地址。

1.2 工作流程

1. 客户发出地址请求(URL) 
   地址请求报文到达DNS
2. DNS选择服务器IP地址和TTL
3. 地址映象(URL->ADDRESS 1) 
   地址映象(URL->ADDRESS 1)
4. 客户向服务器1发出文档请求
5. 服务器1响应客户的文档请求

1.3 存在缺陷

在一个TTL时期内，多个域名请求将被映射到相同的IP地址，这样大量的客户端请求可能出现在同一服务器上，导致明显的负载失衡。如果TTL很小，又会明显增加域名解析的网络负载。

另一个相关问题是由于客户端缓存域名－IP地址解析结果，客户端可以在未来的任意时刻发送请求，导致服务器的负载无法得到控制，出现服务器负载失衡。

1.4 相关算法研究

为解决请求的负载分布均衡问题，研究者对RR－DNS算法进行了多种改进，这些改进依据TTL的设定形式可分为TTL恒定算法和自适应TTL算法。

TTL恒定算法 TTL恒定算法根据用户使用系统状态信息的情况又可分为系统无状态算法、基于服务器状态算法、基于客户状态算法和基于服务器/客户状态算法。

1. SSL：系统无状态算法system-stateless algorithm

   系统无状态算法指DNS服务器按固定时间间隔将客户请求分发到不同服务器上。例如时刻  的客户接受服务器k1的服务，时刻  的客户接受服务器k2的服务，式中的 为TTL值。客户获取服务器地址后，将地址缓存在客户端，然后根据需要，向服务器发请求。

   使用系统无状态算法，DNS只能控制部分请求的流向，由于不考虑服务器的容量和可用性，以及客户请求到达的不确定性，导致服务器超载或将请求发送到不可用服务器上，此算法性能很差，没有实用价值。

2. SSB：基于服务器状态算法Server-state-based algorithm

   获取服务器状态的目的是为了选择可用性更高的服务器处理客户请求，防止服务器阻塞或服务失败。服务器状态算法需要使用简单的服务器侦听机制(例如心跳协议 等)对服务器状态进行定时跟踪。当客户请求到达时，将负载最轻的服务器地址映射给客户端。SUN-SCALR在实现上就是采用这种机制。

3. CSB：基于客户状态算法Client-state-based algorithm

   来自客户端的信息可归结为客户访问的平均负载状况和客户分布情况。如果不考虑客户的优先级高低，CSB算法使用HLW(hidden load weight)参量描述新客户的到达率(TTL周期内，访问服务器的新客户数量)，根据新客户到达率，进行服务器分配，这类算法的典型代表是MRRP(multitier round-robin policy)。

   另外，Cisco的Distributed Director在实现上也采用CSB策略，Distributed Director在服务器集群中充当主域名服务器，根据客户－服务器的拓扑距离和新客户到达率，选择最适合的服务器分发给客户。

4. SCSB：基于服务器/客户状态的算法server and client state based algorithm

   在DNS算法中，同时使用服务器状态和客户状态信息时，获得的性能往往是最高的。例如Distributed Director的DNS算法以服务器可用信息和客户的距离信息为指标分配处理服务器。当节点服务器超载，服务器发送异步警报反馈信息给DNS控制器，控 制器将此服务器从可用服务器表中剔除，根据客户状态信息选择最有利的服务器处理客户请求。使用此算法需要对服务器状态进行动态分析和预测。

5. WRR：带有权重的RR算法 Weight Round-Robin algorithm

   根据各台实际服务器的处理能力给它们分配不同的权重，使具有相同权重的服务器获得链接的概率相同，高权重的服务器获得链接的概率比低权重服务器获得链接的概率大。

自适应TTL算法[20] 
为平衡多服务器节点的负载，特别是异构服务器的负载，人们提出了自适应的TTL算法。这类算法使用基于服务器/客户状态DNS策略选择节点服务器，并动态 调整TTL值。在异构服务器集群中，根据各服务器容量不同，设置的TTL值也不完全相同，由此控制因负载不对称造成的超载问题。

自适应TTL算法使用两步表决机制：首先DNS选择服务器的方法和基于客户状态算法相似；第二步，DNS根据负载分布情况、服务器处理能力和服务器的繁忙程度选择合适的TTL值，服务器越忙，设定的TTL值越小。

另外，自适应TTL算法的可扩展性很强，算法实现中的数据都可以动态获得。使用自适应TTL算法可以使服务器集群比较容易地从局域网拓展到广域网。

1.5 DNS算法比较

由于客户端和中间域名服务器缓存URL－IP地址映射，使用服务器状态信息的DNS算法不能保证负载平衡[15]，每个地址缓存都有可能引发大量的客户请求阻塞集群中的某个服务器节点。因此，合理地预测客户请求的到达率对于选择服务器更加有效。

使用客户到达率信息和服务器监听的调度算法可以获得更高可用性的服务器。但是这种算法明显不适于异构型集群服务器。

为平衡分布系统的请求负载，自适应TTL算法是最可靠、有效的。但是，这种算法忽略了客户－服务器距离的重要性。

算法名称		优点	缺点
固定 TTL 算法	系统无状态算法	简单	不实用
	基于服务器状态算法	提高服务器可用性	不能保证负载均衡
	基于客户状态算法
	基于服务器/客户状态算法	可以获得更高可用性的服务器	不适于异构型集群服务器
自适应TTL算法		DNS算法中可靠性最好、效率最高的算法	忽略了客户－服务器距离的重要性

回页首

细粒度分发策略

为实现客户请求的集中调度和完全路由控制，采用细粒度负载分配策略的服务器结构中必须包含一个路由器节点──平衡器(可能是一个硬件路由器或集群服务器中配置专用软件的节点)接收发向Web站点的所有请求，根据某种负载平衡算法将请求转发到不同的服务器节点上。

与基于DNS的体系结构不同的是，平衡器采用单一的、虚拟IP地址IP-SVA(single virtual IP adress)，这个IP地址是众所周知的一个IP地址，而节点服务器的实际地址对用户是透明的。由于此机制是在URL层进行请求的处理，Web页中包含的多个目标，可以由集群中的不同节点提供，这样提供了比RR－DNS更细粒度的控制策略。

根据路由机制的不同，细粒度负载分配策略又可分为报文重写(单向重写或双向重写)、报文转发和HTTP重定向。

2.1 PDR：报文双向重写策略

PDR 采用集中调度方式完成客户请求的路由控制，服务器系统的平衡器负责客户请求的接收、分发和结果的返回工作。与RR－DNS策略不同，平衡器在IP层进行地 址重写，使用动态地址映射表，实现客户请求的重定向。采用单一的虚拟IP地址(IP-SVA)，用户可见的只是平衡器，节点服务器是透明的。在选择节点服 务器时采用的调度策略主要有：Round Robin（轮转）、Weighted Round Robin（加权轮转）、Least Connection（最少连接）和Weighted Least Connection（加权最少连接）。平衡器将客户和节点服务器的映射添加到映射表中，这样就保证了同一客户的所有请求都发送到同一台节点服务器上，从 而保证了访问的持续性。采用PDR策略的典型代表是Cisco的Local Director，从路由机制上看，Local Director当前采用最少连接数策略。图1-3给出了Local Director处理客户请求的原理图。

图 3 LocalDirector原理图
 

工作流程

1. 客户向服务器发出请求
2. 平衡器选择客户请求的处理节点
3. 将客户请求的目的IP地址(IP-SVA)改写为节点服务器地址(address1)
4. 将客户请求发送给处理节点
5. 处理节点将结果返回给平衡器
6. 平衡器将应答报文的源IP地址(address1)改写为IP-SVA
7. 客户接收应答报文

性能分析 
与粗粒度负载平衡策略不同，PDR在IP级进行负载平衡分配，这样就省去了从应用层到IP层的通讯开销，因此有效缩短了服务器处理时间。较DNS机制，性能提高很大。但是这种策略也存在如下问题：

1. 平衡器容量有限，导致系统可伸缩性不高。另外，平衡器可能成为整个服务器集群的瓶颈。
2. 此机制只适于在局域网范围内实现。

2.2 PSR：报文单向重写策略

在某些体系结构中，平衡器对接收的客户请求进行二次路由，将客户报文的目的IP地址改写为实际处理节点的IP地址，例如基本的TCP路由机制[15]。

在TCP路由机制中，服务器集群由一组节点服务器和一个TCP路由器组成，TCP路由器充当IP地址平衡器。当客户请求到达TCP路由器时，由于IP- SVA是唯一公开的IP地址，平衡器将请求报文中的目标IP地址重写为节点服务器的私有IP地址。由于一个客户请求可能是由多个报文构成，TCP路由器在 地址表中记录客户(具有相同的源IP地址)与执行服务器的地址映射，保证来自同一客户的所有报文都能到达同一台节点服务器。服务器在发送应答报文给客户 时，将平衡器的IP-SVA写入源IP地址，这样客户并不知道请求是由隐藏的执行服务器完成。图4给出了服务器使用报文单向重写策略时，客户请求的执行过 程。

工作流程：

1. 客户向服务器发出请求
2. 平衡器进行地址解析，选择执行服务器
3. 平衡器用执行服务器的私有地址(address1)替换客户请求报文的目的IP地址
4. 客户请求报文二次路由，到达执行服务器
5. 执行服务器处理客户请求，并将IP-SVA写入应答报文的源IP地址中
6. 客户接收应答报文

图 4：报文单向重写示意图
 

性能分析 
使用报文单向重写机制可以提高系统可用性程度，当平衡器节点出现故障时，路由表可以由原平衡器迁移到新的服务器上，服务器的结构也可以从局域网拓展到广域网。但是这种机制导致服务器结构透明性较差，而且执行服务器和平衡器在判断客户请求是否结束上存在困难。

2.3 PF：报文转发

由 于报文重写增加了平衡器处理请求的复杂度，导致平衡器负载加重，研究者提出了报文转发策略(PF)。采用PF策略，平衡器和执行服务器共用一个IP- SVA地址，客户请求报文到达平衡器后，平衡器根据调度选择执行服务器，利用执行服务器的物理地址(MAC)将报文转发给执行节点。转发过程中不需要进行 地址解析，所以不必改动客户请求报文。采用PF策略的典型代表是IBM的Network Dispatcher。

局域网内部的Network Dispatcher集群处理客户请求的原理与图5相似，其工作流程如下：

1. 客户向服务器发出请求报文；
2. 平衡器根据负载平衡策略选择执行服务器；
3. 平衡器利用执行服务器的私有MAC地址转发客户报文；
4. 客户报文路由；
5. 执行服务器处理客户请求；
6. 执行服务器将应答报文发送给客户。

为 了将服务器集群从局域网拓展到广域网，Network Dispatcher采用两级平衡器机制，图5显示了广域网服务器集群的原理图。一级平衡器到二级服务器之间采用类似报文单向重写策略，平衡器将客户请求 报文的目的地址(IP-SVA)改写为二级平衡器的IP地址，选择二级平衡器的原则是根据客户-服务器间的距离，将客户请求分发到最近的服务器子群上。二 级平衡器将客户请求报文的目的地址改回IP-SVA，然后将报文转发到执行服务器上，服务器子群要求必须在同一局域网中。

图 5：广域网实现的报文转发
 

在广域网环境下，实现客户请求报文处理的流程是：

1. 客户向服务器发送请求报文；
2. 一级平衡器根据客户－服务器距离选择二级平衡器；
3. 一级平衡器将客户报文的目的地址改写为二级平衡器的IP地址；
4. 客户请求报文由一级平衡器向二级平衡器路由；
5. 二级平衡器根据负载平衡策略选择执行服务器；
6. 二级平衡器将客户请求报文的目的地址改写为IP-SVA；
7. 客户请求报文转发；
8. 执行服务器将应答报文直接传送给客户。

随着负载数量的增长，相应的处理变得越来越复杂(每个服务器节点每秒处理的请求数量有限)，目前路由器只负责接收报文，但链接的复杂性、每个请求的返回数据量都限制了路由器的可伸缩性。

2.4 HTTP重定向策略

集 中式平衡器接收所有客户请求，使用HTTP重定向机制将客户请求分发到不同的执行服务器上。平衡器根据特殊的响应状态码，指明客户请求文件在服务器上的位 置，因此重定向机制是高度透明的。与其他分发机制不同的是，HTTP重定向机制不需要对通讯报文的IP地址进行修改，HTTP重定向机制可以由以下两种技 术实现。

2.4.1 基于服务器状态分发 
在分布式服务器集群体系结构中，修正现有的HTTP协议，增加新方法实现对Web服务器的管理，改变平衡器与执行服务器间的信息交换。由于平衡器需要考虑 服务器的负载情况，每个执行服务器必须周期性地报告处理进程数量和客户请求到达率。平衡器选择负载最轻的执行服务器处理新的客户请求。

2.4.2 基于位置的分发 
Cisco的Distributed Director提供了两种分发模式，第一种是基于DNS的SCSB策略，第二种为HTTP重定向策略。Distributed Director评估客户－服务器距离和节点可用性，将客户请求重定向到最合适的执行服务器。

回页首

细粒度分发策略的比较

基于平衡器的报文双向重写机制的问题是，平衡器必须对应答报文进行重写，而应答报文的数量明显超过请求报文的数量。

使用TCP路由器结构的报文单向重写机制，由于执行服务器处理众多的应答报文，减轻了平衡器的负载。广域网环境下的Network Dispatcher仅对请求报文进行两次重写，因而执行效率更高。

报文转发机制可以有效避免报文重写带来的开销，然而共享单IP地址导致静态调度策略失效(服务器状态不决定路由)。基于路由的平衡器需要对每个报文进行二次路由，基于广播的平衡器需要把报文广播到每个执行服务器，这样明显加重了服务器负载。

局域网环境下的Network Dispatcher结构避免了共享IP地址、TCP路由和双向重写的开销等问题，但是它只能在同一网段内实现，可伸缩性很差。HTTP重定向可以很好地应用于局域网和广域网中，但必须复制一定数量的TCP连接。

回页首

各种负载平衡策略的比较

基于DNS机构的实现机制可以明显减轻服务器的瓶颈效应，可伸缩能力得到加强，服务器环境从局域网拓展到广域网。但是，使用这种结构，服务器的数量不能超 过32台(受UDP报文长度的限制)。基于DNS结构的服务器通过地址映射决定客户请求的目的地址，然而，这种粗粒度负载平衡机制要求TTL必须大于0， 由于客户端对服务器地址进行缓存，导致服务器负载平衡不能保证，人们提出了基于状态信息算法和自适应TTL算法对DNS策略的性能进行改进。总的来说，单 纯基于DNS策略的服务器适合于小规模的同构型服务器集群，但不适于异构性服务器结构。

基于平衡器结构的服务器由于受到单仲裁入口的限制，客户请求迅速增长可能导致平衡器成为系统瓶颈；由于平衡器对客户请求报文重写或转发，增加了客户等待延 迟，降低了服务器性能；另外使用集中调度策略，若平衡器当机，则整个系统都会崩溃。从另一方面讲，平衡器实现的细粒度负载平衡策略，共享服务器IP地址又 克服客户端网络层地址缓存问题。基于服务器拓扑结构实现的报文重写和转发策略是目前局域网或高速广域网中集群服务器实现的主要策略。

改进执行服务器处理过程将原有的请求集中控制改为部分分布控制，是服务器结构研究的一种进步，与平衡器结构服务器相同，这种技术也是一种细粒度负载平衡策略，但它带来的客户等待延迟要比其他策略增加很多。

从目前集群式服务器结构研究的现状分析可以看出，今后服务器集群的发展趋势将是面向广域网的分布控制的服务器集群研究。

参考资料

• Andrew S. Tanenbaum ,《计算机网络》, 清华大学出版社，1998
  
  
• 刘振英、张毅等，多机系统的动态负载平衡，《计算机科学》, Vol. 26 , No 1:38-40, 1999
  
  
• Eager D L,et al. Adaptive load sharing in homogeneous distributed systems. IEEE Tran. On Software Engineering, SE-12(5)，1986
  
  
• Zhou S. A trace-driven simulation stydy of dynamic load balancing. IEEE Tran . On Software Engineering. SE-14(9):1327~1341，1988
  
  
• 魏永明、杨飞月、吴漠霖，《Linux实用教程》，电子工业出版社，1999
  
  
• 胡子昂、王立，算法、网络拓扑及调度频率与动态负载平衡的关系，《计算机工程与科学》，Vol.22.No.1, 2000
  
  
• Aaron Mackee，A TurboLinux Technical Case Study,www.turbolinux.com
  
  
• www.linuxvirtualserver.com
  
  
• aniel A.Menasce, "CS672-Computer System Performance Evaluation" http://www.cs.gmu. edu/faculty/menasce.html
  
  
• Louis P.Slothouber, "A model of Web Server Performance", http://louvx.biap.com/webperfor mance/modelpaperhead.html
  
  
• V.Cardellini, M.Colajanni et al, "DNS Dispatching Algorithms with State Estimators for Scalable Web Server Clusters", World Wide Web J.Baltzer Science Bussum, Netherlands Vol 2, No.2 July 1999
  
  
• M.Colajanni et al, "Analysis of Task Assignment Policies in Scalable Web Server Systems", IEEE Trans Parallel and Distributed Systems, Vol.9 No.6, June 1998, pp585-600
  
  
• D.M.Dias et al, "A Scalable and Highly Available Web Server", Proc 41st IEEE Computer Soc. Int'l Conf, IEEE Computer Soc. Press, Los Alamitos, Calif, Feb,1996, pp85-92
  
  
• "Network Dispatcher : a connection router for scalable Internet Services",In Proceedings of the 7th Interional WWW conference , Brisbance Australia , April 1998 http://decweb .ethz.ch/www/1899/com1899.htm
  
  
• D.L.Eager E,D Lazowska and J,Zahorjan , "Adaptive load sharing in homogeneous distributed systems", IEEE Transactions on Software Engineering ,12(5):662-675, May 1986
  
  
• IBM "IBM parallel system support programs for AIX : group services programming guide and reference" 1996 SC28-1675-00
  
  
• O.Kremien and J.Kramer,"Methodical analysis of adaptive load sharing algorithms", IEEE Transactions on Parallel and Distributed Processing 3(6), November 1992
  
  
• Daniel Ridge,"Beowulf Harnessing the Power of Parallelism in a Pile of PCs"