DHCP 負載平衡演算法

DHCP 負載平衡演算法

（RFC3074 ——DHC Load Balancing Algorithm）

 

1.簡介

解決網路過載的問題的一個解決方法是在現有的DNS中加入動態負載平衡的特性。

　　隨著計算機網路的應用的日益廣泛，在互聯網上的負載也變得日益擁擠，這經常導致伺服器無法正常地響應，並且影響了一些應用程式的崩潰。而且，這種現象的發生是動態的。解決這個問題的一個方法是建造更加強大的伺服器，而另外一個途徑就是將客戶請求分散到多個伺服器上。後者是解決這個問題的一種巧妙的方法，透過這種方法實際上是一種平衡的藝術，可以避免一些伺服器過於繁忙而另外的伺服器非常空閒的狀態。跨伺服器的需求分配技術成為網路技術的一個重要課題。

　　我們來考慮這麼兩種情況：首先，每個TCP進程會消耗32比特的記憶體，這樣，一個有32MB記憶體的伺服器從理論上支持100萬的連接。其次，在多個擁有同樣內容的伺服器中，用戶總是喜歡根據他們自己的經驗（或者是一些監測數據）訪問一些服務負載較小的伺服器，比如說，GetRight就可以選擇一個較佳的伺服器進行FTP下載。但是，我們可以可以透過定期地監測伺服器的狀態並將請求指向最佳伺服器來實現請求的分配。這種在多個伺服器中根據伺服器負載動態定向請求的技術稱之為動態負載平衡。這個功能可以加入域名服務（DNS）中，而這是因為域名伺服器本身就充當了解析客戶請求的主要責任，而具有這種特性的DNS稱為dlbDNS(dynamic load balance DNS)。在這裡，最佳伺服器指的是透過一種排名演算法的出最佳排名的伺服器。

　　在這裡，我們將要解釋透過dlbDNS對DNS擴展所帶來的好處。首先，我們必須要考慮dlbDNS設計應該達到的性能：

　　（1）新的設計必須與原來的DNS應用相容。

　　（2）該設計必須要易於配置。

　　（3）負載平衡必須快速而且有效。

　　（4）一個主機可以屬於多個組或者簇。

　　（5）對一個請求的響應應當動態地產生。

　　（6）對伺服器的監控應當由不同的進程所產生。

　　（7）TTL的值應當設為最小以防止其他名字伺服器的緩存的響應。

　　（8）最終的設計應當是一個通用性的名字伺服器，可以被同時用於簡單的、反向                                                            的和動態的請求。

　　（9）對錯誤應當有所響應。

　　（10）負載平衡的過程對用戶來說是透明的。



　　負載平衡模型
　　有四種負載平衡平衡模型可供使用：首先，RFC1794描述了使用一個特別區域代理以從外部資源獲得資訊的負載平衡方法，這樣，一個新的區域透過名字伺服器被載入。這個方法的問題是大量的資訊量，包括靜態的或者是可能需要分配的資訊量，都在區域中進行迴圈地傳送。同時，這個方法也不支持根據被請求的名字所回應的動態創建的虛擬/動態域名。

　　第二個模型是透過一個專門的負載平衡伺服器來解釋請求並將其指向一個最佳伺服器。這種設計由負載伺服器在內部使用虛擬的IP地址。而這種伺服器的問題在於需要在被監控地伺服器群中加入另外一台伺服器而不是使用現有的資源。

　　第三個模型是透過一個遠程監視系統來監視不同伺服器的性能，從而提供給DNS一個反饋。這個設計可以幫助解決無法直接觀測的系統問題，同時提供給用戶以訪問時間的測算。這種方式的問題就是在於需要依靠遠程網路進行監視並且分發數據。

　　最後一種方案就是透過內部監視系統來監視伺服器的性能，並且提供給DNS的反饋。這主要的優點就是易維護性和管理性，而且也沒有安全方面的問題。dlbDNS就是使用的這種方式。

　　

　　負載平衡演算法
　　最初，負載平衡只是為了允許DNS代理可以支持機器簇的概念，在這裡，這些機器的功能都是類似的或者相同的。而且，它並不需要特別關心選擇了哪台機器。這樣，負載就被平均地分配在一系列實際上並不相同的主機上。因為機器有著不同的配置和能力，這樣，我們就需要更加複雜的演算法。

1.1描述

RFC3074是針對DHC負載平衡演算法來作講解，我們就RFC3074來作了解︰

 

RFC3074講述了一種Internet社區的Internet標準跟蹤協定，它需要進一步進行討論和建議以得到改進。請參考最新版的“Internet正式協定標準” (STD1)來獲得本協定的標準化程度和狀態。

 

 

RFC3074建議了一種負載平衡演算法，它讓多個合作的伺服器決定哪一個來爲客戶服務，而不必在初始設置時作任何資訊交換。

當存在多個DHCP 伺服器時，根據伺服器端散列存儲的客戶MAC 位址來選擇伺服器。建議的技術提供了高效選擇伺服器的手段，當網路上存在多個DHCP 伺服器時，不需要改變用戶端的設置。對於選擇目標伺服器作爲轉向代理，例如 BOOTP 中繼也採用同樣的方法。

 

本協定最初用來支援對特定的 DHCP 失敗請求協定的負載平衡優化。作者後來意識到可以用來優化多個合作的 DHCP 服務和 BOOTP 中繼代理。本建議可以設置每個參與的伺服器接受一個預先設置的客戶負載百分比。這可以通過確定性的散列演算法來達到，對於具有同樣特性的其他協定也能很容易的做到。

 

2. 術語

2.1. 要求的術語

 

以下術語是參考RFC2119所得來︰

 

1.MUST

   這個關鍵字，或是術語"REQUIRED"或"SHALL"，意味著他們的定義是一個絕對的規範的必要條件。

2.MUST NOT

   這個片語，或是片語"SHALL NOT"，意味著他們的定義是一個絕對的規範的禁止的條件。

3.SHOULD

   這個關鍵字，或是形容詞"EWCOMMENED"，意味著在特殊的環境下可能存在正當的理由忽略一個特殊的專案，但是完整的含義必須能被理解並且要仔細的考慮在重新選擇一條不同的路徑之前。

4.SHOULD NOT

   這個片語，或是片語"NOT RECOMMENDED"，意味著在特殊的環境下可能存在正當的理由當特殊的行爲可接受或是甚至有效，但是完整的含義應該被理解並且這種情況應該被仔細考慮當暗含某種行爲用標簽描述前。

5.MAY

   這個關鍵字，或是形容詞"OPTIONAL"，意味著一個專案是真正可選的。一個買主可以選擇包含專案因爲一個特殊的市場要求或是因爲買主覺得它能夠增強産品當另一個買主可能遺漏了同樣的專案時。一個沒有包含一個特殊物件MUST的工具準備用來與另一個不包含這個物件的工具間相互起作用，因此或許有簡化的功能。在同樣的脈絡裏一個包含了特殊物件MUST的工具準備用來和另一個沒有包含這個物件的工具間相互作用。

6.這些命令使用向導

        在RFC3074定義的命令必須小心謹慎的使用。特別的，他們必須僅僅用在爲相互間交流或限制潛在性的有害行爲實際上確實需要的地方。例如，他們不必用來強加一個特殊方法在爲相互作用間不需要的方法的地方。

7.安全方面的考慮

 這些習語經常用來指定安全含義的行爲。沒有暗含一個關鍵字MUST或SHOULD，或在作某些事的說明時定義爲MUST NOT或SHOULD NOT的影響將是非常的敏感的。本文作者應該慢慢的詳細描述沒有遵循建議或要求的安全暗示作爲大多數的執行者將不會有産生規範的經歷和討論的而得的好處。

2.2. 負載平衡術語

本文檔介紹了以下術語：

 

     服務延遲 （Service Delay）, SD

 

參加負載平衡方案中的伺服器允許對客戶機延遲服務，而不是忽略客戶請求。

 

散列桶分配 （Hash Bucket Assignments）, HBA

參加負載平衡方案伺服器的配置節名稱，設置散列桶的大小。

 

伺服器 ID （Server ID）, SID

對參與的伺服器指定 ID 。從 DHCP 的行文來說， SID 就是指伺服器的 IP 地址或者 DNS 名字。

 

服務事務 (Service Transaction) , ST客戶機和伺服器之間資訊交換的集合，例如 DHCP 伺服器和客戶機之間

 

DISCOVER/OFFER/REQUEST/ACK 資訊的交換就是一種服務事務。

 

服務事務 ID (Service Transaction ID), STID負載平衡中單個客戶請求屬性。

3. 背景知識和外部需求

因爲 DHCP 客戶機採用 UDP 廣播來聯繫 DHCP 伺服器，因此，客戶機的   DHCPDISCOVER 消息可以被多台伺服器接收到。所有接收到這條廣播的伺服器會 對客戶機作出回應，來讓客戶機決定採用哪一台伺服器。

如果使用了 BOOTP 中繼代理，一般它會轉發或者向所有配置的服務器重新廣播客戶機的請求，因此也存在同樣低效的問題。

優化演算法允許伺服器採用計算“服務”和“不服務”的比例來讓每一個事務選擇。轉發代理也可以採用同樣的計算方法選擇轉發目的地。

 

在每一種例子中，對伺服器的選擇是可計算的，而不必要求參與者協商誰來回應。

 

因爲幾乎不能預測下一個請求會來自哪一台客戶機，所以該演算法逼近自然界的概率。對短期而言，實際的客戶機得到的請求百分比會偏離期望的百分比，但是隨著請求次數的增加，每一台伺服器的負載百分比就會達到配置的百分比。

 

 

4. 概覽

DHCP 伺服器必須使用客戶機標記選項作爲 STID ，如果沒有客戶機標記的話，   DHCP 包的 hlen 域 必須使用要散列的資料長度，而 chaddr 的內容必須爲要散列的資料。最多用到用戶端標記或者 chaddr 的最初 16 位元組。

 

本建議把 STID 映射爲第6節中函數用到的散列值。返回的散列值就能用來決定誰能回應客戶機的請求，或者誰是轉發目標。

提供的散列函數産生0 到 255 的散列值，産生相當平坦的散列桶分佈，對於每一個參與的伺服器，通過分配指定的散列值來分配資源。

伺服器僅當那些請求機器的 STID 匹配分配的散列值中的一個時才會接受請求。

 

任何沒有對伺服器分配的散列桶會導致一些客戶的 ST 完全被忽略。 STID 並非一定要唯一，但是必須有足夠餘量能分佈到每一台伺服器。

HBA 可以以消息傳送，封包在其他協定中，例如：e-mail 或者 DHCP Failover    協定。

 

DHCP 伺服器實現可以採取可配置的策略，來處理負載平衡已經配置好，但是伺服器不能回應或者不符合預定的分配位址的情況。

 

DHCP 伺服器的這項功能可以通過設置 DS 參數來達到。來讓伺服器延遲對客戶機的請求。

 

DHCP 伺服器應該利用客戶機請求的 secs 域的值，如果這個值不爲0 的話。

 

因爲有些客戶可能沒能正確實現 secs 域，DHCP 伺服器應該記錄客戶事務的第一次情況，如果第二次請求包中的 secs 域依然爲0 ，那麽DHCP 伺服器就可以採用請求之間延時，而不再使用 secs 域。

 

5.1 設置

 

設置步驟包括分配散列值給伺服器，這一步通過提供一個或者多個散列桶分配來實現。這可以通過配置文件，Windows NT 註冊表，EEPROM 等得到。另外，散列桶的值可以採用一些貪婪演算法來分配。例如：“所有奇數由A 伺服器服務，所有偶數由B 伺服器服務。”

 

5.2 面向伺服器的 HBA

當設置爲一個指定的伺服器時，HBA 應該採用 32 位八進制的簡單點陣圖。

 

HBA 點陣圖的第一個八進制代表了 HBA 值 0-7，下一個爲 8-15，依此類推，第32個代表 248-255，在每一個八進位數字中，最小位代表了那個八進位數中最小的HBA 值。

 

HBA 的每個位和每個可能的散列值對應。如果點陣圖中的位元是設置的話，意味著接收伺服器必須服務客戶機的請求，這時，STID 産生對應的散列值。

 

例如，如果一台伺服器的HBA 如下：  

            FF FF FF FF FF FF 00 00 ( 0   - 63 )

            FF FF FF FF FF FF FF FF ( 64 - 127 )

            00 00 00 00 00 00 00 00 (128 - 191 )

            00 00 00 00 00 00 00 00 (192 - 255 )

 

那麽它必須服務那些STID 散列值在 0-47 和64-127 之間的客戶機請求。

 

5.3 延遲服務參數

 

延遲服務參數是可選的。

 

如果這個參數沒有設置，那麽 HBA 會設置一個嚴格的服務/不服務規則。

如果參數已經設置，對於本來不服務於一些特定客戶請求的伺服器，可以在 S 秒以後回應請求。伺服器可以利用BOOTP 消息頭中的 secs 域來決定客戶嘗試獲得服務的請求時間，否則它會採用其他辦法繼續請求。

5.4 轉向 HBA

當設置爲轉向代理時，(例如，BOOTP 中繼) 可能會使用包含伺服器ID/散列桶值對的HBA。

 

這裏，伺服器 ID (SID) 決定了伺服器對指定的散列桶負責，轉向代理轉發每個客戶請求， STID 産生指定的散列值給 SID 決定的伺服器。

 

伺服器 ID 可以是任意伺服器屬性的唯一值，（例如 IP 位址，DNS 名字等），只要在中繼代理中的上下文有意義就可以了。

轉發器可以設置爲轉發指定的包到多台伺服器，例如，BOOTP中繼可以設置爲把負載分割爲兩個基本的備份伺服器對，每一個對運行 DHCP  Failover 協定。在這個例子中，一個目標爲伺服器對的包就會轉發到基本的和輔助的伺服器對。

一個轉發代理的可能配置文件設置如下：

   192.33.43.11 192.33.43.12: 0..24;

   192.33.43.13: 25..55;

   192.33.43.15: 56..128;

   192.33.43.16: 129 130 131 200..202;

以上的配置文件包含4 個 HBA，第一行的含義爲：

“客戶請求産生的 STID 散列值在0-24 之間時，轉發到伺服器 192.33.43.11 和192.33.43.12”。

第四行的含義是：“ STID 散列值爲129,139,131,200,201或者202時，轉發到 192.33.43.16 ”。

6. 負載平衡的散列函數

下面的散列函數採用 C 語言來實現，利用了"Pearson 的散列" 演算法。

  

這個函數具有計算的廉價性，對每一個鍵位元組作一次陣列搜索和 xor 操作。

爲了讓本建議運作，所有其他的實現方法必須使用這個散列函數。混合表集合的數值如下： 

/* 256 個唯一值的混合表，採用僞隨機排序。*/

 

unsigned char loadb_mx_tbl[256] ={

251, 175, 119, 215, 81, 14, 79, 191, 103, 49, 181, 143, 186, 157, 0,

232, 31, 32, 55, 60, 152, 58, 17, 237, 174, 70, 160, 144, 220, 90, 57,

223, 59, 3, 18, 140, 111, 166, 203, 196, 134, 243, 124, 95, 222, 179,

197, 65, 180, 48, 36, 15, 107, 46, 233, 130, 165, 30, 123, 161, 209, 23,97, 16, 40, 91, 219, 61, 100, 10, 210, 109, 250, 127, 22, 138, 29, 108,244, 67, 207, 9, 178, 204, 74, 98, 126, 249, 167, 116, 34, 77, 193,200, 121, 5, 20, 113, 71, 35, 128, 13, 182, 94, 25, 226, 227, 199, 75,27, 41, 245, 230, 224, 43, 225, 177, 26, 155, 150, 212, 142, 218, 115,241, 73, 88, 105, 39, 114, 62, 255, 192, 201, 145, 214, 168, 158, 221,148, 154, 122, 12, 84, 82, 163, 44, 139, 228, 236, 205, 242, 217, 11,187, 146, 159, 64, 86, 239, 195, 42, 106, 198, 118, 112, 184, 172, 87,2, 173, 117, 176, 229, 247, 253, 137, 185, 99, 164, 102, 147, 45, 66,231, 52, 141, 211, 194, 206, 246, 238, 56, 110, 78, 248, 63, 240, 189,93, 92, 51, 53, 183, 19, 171, 72, 50, 33, 104, 101, 69, 8, 252, 83, 120,76, 135, 85, 54, 202, 125, 188, 213, 96, 235, 136, 208, 162, 129, 190,132, 156, 38, 47, 1, 7, 254, 24, 4, 216, 131, 89, 21, 28, 133, 37, 153,149, 80, 170, 68, 6, 169, 234, 151

};

 

unsigned char loadb_p_hash(

        const unsigned char *key,       /* 要散列的鍵值 */

        const int len )                 /* 鍵長度（bytes） */

{

unsigned char hash = len;

int i;

 

        for (i=len ; i > 0 ; )

            hash = loadb_mx_tbl [ hash ^ key[ --i ] ];

 

        return( hash );

}

 

int accept_service_request(

        const unsigned char HBA[32],    /* 散列桶二進位表 */

        const unsigned char *key,       /* 服務事務 id   */

        const int len )                /* 長度   */

{

unsigned char hash = loadb_p_hash(key,len);

int index          = (hash >> 3) & 31;

int bitmask        = 1 << (hash & 7);

 

        /* 服務事務的話，返回 1 */

        return((HBA[index] & bitmask) != 0);

}

 

7. 安全考慮

 

本建議本身不構成安全問題，也不會影響現存的安全設置。採用這個演算法的伺服器保證HBA 的內容能在網路上傳送，這個消息能防止竄改。因爲對 HBA 的篡改會導致一些或者所有客戶拒絕服務。