解决网络过载的问题的一个解决方法是在现有的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代理可以支持机器簇的概念，在这里，这些机器的功能都是类似的或者相同的。而且，它并不需要特别关心选择了哪台机器。这样，负载就被平均地分配在一系列实际上并不相同的主机上。因为机器有着不同的配置和能力，这样，我们就需要更加复杂的算法。
“循环算法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的使用
首先，我们从Internet Software Consortium (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的动态负载。如下列表：
named.hosts.clinux
;
;
;named.hosts.wsu
; http://www1.cs.twsu.edu
www1 IN DNAME back1.dydns.clinux.org.
www1 IN DNAME back2.dydns.clinux.org.
www1 IN DNAME b.dydns.clinux.org.
服务器端的算法
以下是dlbDNS中的算法。如果一个服务器的请求是DNAME类型，那么，服务器就会进行如下的一些动作：
1、确定在这个服务中参与的服务器的集合。
2、通过和每个服务器建立一个同步的非连接性的连接获取每个参与的服务器的排名值。
3、根据返回的排名值，确定最佳服务器。
4、处理错误信息。
排名服务算法
一个排名服务运行在参与到动态负载平衡的每个服务器上，以下是算法：
1、从dlbDNS接收排名请求。
2、每一分钟都对主机的排名进行计算，而不是在得到请求的时候才进行计算。因为回应时非常重要的一个因素。
3、确认主机排名是每分钟都进行更新的。
4、处理错误情况，比如说dlbDNS在未等待主机回应的情况下关闭了UDP接口。
（如图）
模型
如图所示的是dlbDNS的功能。由C所标明的路线指出了通过排名服务更新服务器排名的过程。由B所标明的路线指出了通过dlbDNS和排名服务所确定最佳服务器的通讯。由A所标明的路径指出了用户请求的路径。在图中，因为HOST 1比另外两台服务器有更好的一个排名，所以请求被定向到了HOST 1上。
dlbDNS的好处
这个就不需要多说了，除了可以充分地利用资源之外，因为我们通过DNS来实现负载平衡，这样FTP和TELNET之类的程序也可以使用dlbDNS。
发展方向
目前，在通过BIND的代码中，gethostbyname系统将不能正常工作，这个问题可以通过一个主机和IP地址的列表的配置文件来解决。当然，我们希望由一个更好的解决方法。
第二，排名算法还不完善，算法还不能考虑处理器的数目，对CPU和内存的考虑会使得算法更加有效。
第三，在Linux服务器上，排名算法使用的是/proc文件结构中的文件，这样只能说是动态平衡配置，应该还需要一个更加强大的设计。
备注：dlbDNS的源代码可以从http://www.cs.twsu.edu/~hcvillia/acads/project/获得
- 李冬([email protected]) 供稿