基於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"