前面我們介紹了DNS負載均衡的一些概念，那么現在針對這種負載均衡技術，我們再來討論一下相關的算法問題，以及排名問題。這個是在服務器負載應用中很重要的一個概念。那么更多的知識，我們還是從下文中來了解吧，望大家能對這方面的問題有個總結。

負載均衡算法

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

“循環算法A"可以以一種循環方式在服務器中平均的分配請求｡但是,盡管這些請求是被動態地處理,對于不同的性能特點的忽視使這種算法的一個問題｡

“負載平均算法A"可以根據服務器的負載分配請求｡這個設計非常簡單而且也較為低廉｡但是這種算法卻不能應付服務器在配置和潛力方面有差異的情況｡

“排名算法A"基于如下所示的用戶的數目和負載平均的列表｡這個算法是比較合理的,因為它根據最少的單個訪問以及較低負載平均來進行排名***主機的｡這個算法在dlbDNS中確定***服務器的時候被使用｡

WT_PER_USER=100

USER_PER_LOAD_UNIT=3

FUDGE=(TOT_USER-UNIQ_USER)*(WT_PER_USER/5)

WEIGHT=(UNIQ_USER*WT_PER_USER)+(USER_PER_LOAD_UNIT*LOAD)+FUDGE

在這個列表中,變量的名稱的含義如下:

TOT_USER:登錄的用戶的總數

UNIQ_USERS:登錄的不重復用戶的數目(比如說,用戶a和用戶b就是兩個不重復的用戶,而不管他們登錄了多少次)

LOAD:***一分鐘的負載平均乘100

WT_PER_USER:每個用戶的負載量

FUDGE:如果用戶多次登錄之后的修正參數

WEIGHT:服務器的排名

dlbDNS的使用

首先,我們從InternetSoftwareConsortium(http://www.isc.org/bind.html)下載BIND8.1.2(在BIND8.1.2中就支持了dlbDNS的特性),在示例中DNS被安裝在dydns.clinux.org上,在一個獨立的Linux工作站上進行測試｡請看我們的配置:

在我們的配置中,由一個新的屬性稱為DNAME被加入來區分參加到動態負載均衡的主機｡在我們上面這個配置中,我們可以看到,back1.dydns.clinux.org,back2.dydns.clinux.org和b.dydns.clinux.org被用來充當www1.dydns.clinux.org的動態負載,hack1.dydns.clinux.org,hack2.dydns.clinux.org和h.dydns.clinux.org被用來充當www2.dydns.clinux.org的動態負載｡

服務器端的算法

以下是dlbDNS中的算法｡如果一個服務器的請求是DNAME類型,那么,服務器就會進行如下的一些動作:

1､確定在這個服務中參與的服務器的集合｡

2､通過和每個服務器建立一個同步的非連接性的連接獲取每個參與的服務器的排名值｡

3､根據返回的排名值,確定***服務器｡

4､處理錯誤信息｡

排名服務算法

一個排名服務運行在參與到動態負載均衡的每個服務器上,以下是算法:

1､從dlbDNS接收排名請求｡

2､每一分鐘都對主機的排名進行計算,而不是在得到請求的時候才進行計算｡因為回應時非常重要的一個因素｡

3､確認主機排名是每分鐘都進行更新的｡

4､處理錯誤情況,比如說dlbDNS在未等待主機回應的情況下關閉了UDP接口｡

dlbDNS的好處

這個就不需要多說了,除了可以充分地利用資源之外,因為我們通過DNS來實現負載均衡,這樣FTP和TELNET之類的程序也可以使用dlbDNS｡

發展方向

目前,在通過BIND的代碼中,gethostbyname系統將不能正常工作,這個問題可以通過一個主機和IP地址的列表的配置文件來解決｡當然,我們希望由一個更好的解決方法｡

第二,排名算法還不完善,算法還不能考慮處理器的數目,對CPU和內存的考慮會使得算法更加有效｡

第三,在Linux服務器上,排名算法使用的是/proc文件結構中的文件,這樣只能說是動態平衡配置,應該還需要一個更加強大的設計｡

備注:dlbDNS的源代碼可以從http://www.cs.twsu.edu/~hcvillia/acads/project/獲得｡