大容量邮件系统的负载均衡方案.doc

大容量邮件系统的负载均衡方案 smtp server 每投递一封邮件，都需要做DNS解析。投递的速度和DNS解析时间密切相关。dlbDNS的应用能够大大加快smtp投递速度。在邮件系统集群方案中，往往忽略DNS的速度。 解决网络过载的问题的一个解决方法是在现有的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_US