读透DNS负载均衡的排名算法

通过这篇文章，我们从算法和排名原理上来深层次的学习负载均衡的知识。另外以解析了DNS负载均衡的应用意义，以及对它的发展前景进行了简要的分析。

前面我们介绍了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/获得?