负载均衡策略基础的呈现

随着服务器的不断升级，对负载均衡技术的要求也越来越高。更简便的操作，更强的功能，一项项更高的标准促进着技术的发展和进步。那么，一个有效的网络规划和应用方案也就是现在的热门话题了。基于此，我们来谈一谈负载均衡策略的问题。

负载均衡策略

在实际应用中,我们可能不想仅仅是把客户端的服务请求平均地分配给内部服务器,而不管服务器是否宕机?而是想使Pentium III服务器比Pentium II能接受更多的服务请求,一台处理服务请求较少的服务器能分配到更多的服务请求,出现故障的服务器将不再接受服务请求直至故障恢复等等?

选择合适的负载均衡策略,使多个设备能很好的共同完成任务,消除或避免现有网络负载分布不均?数据流量拥挤反应时间长的瓶颈?在各负载均衡方式中,针对不同的应用需求,在OSI参考模型的第二?三?四?七层的负载均衡都有相应的负载均衡策略?

负载均衡策略的优劣及其实现的难易程度有两个关键因素:

一?负载均衡算法

考虑到服务请求的不同类型?服务器的不同处理能力以及随机选择造成的负载分配不均匀等问题,为了更加合理的把负载分配给内部的多个服务器,就需要应用相应的能够正确反映各个服务器处理能力及网络状态的负载均衡算法:

轮循均衡(Round Robin):每一次来自网络的请求轮流分配给内部中的服务器,从1至N然后重新开始?此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况?

权重轮循均衡(Weighted Round Robin):根据服务器的不同处理能力,给每个服务器分配不同的权值,使其能够接受相应权值数的服务请求?例如:服务器A的权值被设计成1,B的权值是3,C的权值是6,则服务器A?B?C将分别接受到10%?30%?60%的服务请求?此种均衡算法能确保高性能的服务器得到更多的使用率,避免低性能的服务器负载过重?

随机均衡(Random):把来自网络的请求随机分配给内部中的多个服务器?权重随机均衡(Weighted Random):此种均衡算法类似于权重轮循算法,不过在处理请求分担时是个随机选择的过程?

响应速度均衡(Response Time):负载均衡设备对内部各服务器发出一个探测请求(例如Ping),然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求?此种均衡算法能较好的反映服务器的当前运行状态,但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间,而不是客户端与服务器间的最快响应时间?

最少连接数均衡(Least Connection):客户端的每一次请求服务在服务器停留的时间可能会有较大的差异,随着工作时间加长,如果采用简单的轮循或随机均衡算法,每一台服务器上的连接进程可能会产生极大的不同,并没有达到真正的负载均衡?最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录,记录当前该服务器正在处理的连接数量,当有新的服务连接请求时,将把当前请求分配给连接数最少的服务器,使均衡更加符合实际情况,负载更加均衡?此种均衡算法适合长时处理的请求服务,如FTP?

处理能力均衡:此种均衡算法将把服务请求分配给内部中处理负荷(根据服务器CPU型号?CPU数量?内存大小及当前连接数等换算而成)最轻的服务器,由于考虑到了内部服务器的处理能力及当前网络运行状况,所以此种均衡算法相对来说更加精确,尤其适合运用到第七层(应用层)负载均衡的情况下?

DNS响应均衡(Flash DNS):在Internet上,无论是HTTP?FTP或是其它的服务请求,客户端一般都是通过域名解析来找到服务器确切的IP地址的?在此均衡算法下,分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求,并在同一时间内把此域名解析成各自相对应服务器的IP地址(即与此负载均衡设备在同一位地理位置的服务器的IP地址)并返回给客户端,则客户端将以最先收到的域名解析IP地址来继续请求服务,而忽略其它的IP地址响应?在种均衡策略适合应用在全局负载均衡的情况下,对本地负载均衡是没有意义的?

二?对网络系统状况的检测方式和能力

尽管有多种的负载均衡算法可以较好的把数据流量分配给服务器去负载,但如果负载均衡策略没有对网络系统状况的检测方式和能力,一旦在某台服务器或某段负载均衡设备与服务器网络间出现故障的情况下,负载均衡设备依然把一部分数据流量引向那台服务器,这势必造成大量的服务请求被丢失,达不到不间断可用性的要求?所以良好的负载均衡策略应有对网络故障?服务器系统故障?应用服务故障的检测方式和能力:

Ping侦测:通过ping的方式检测服务器及网络系统状况,此种方式简单快速,但只能大致检测出网络及服务器上的操作系统是否正常,对服务器上的应用服务检测就无能为力了?

TCP Open侦测:每个服务都会开放某个通过TCP连接,检测服务器上某个TCP端口(如Telnet的23口,HTTP的80口等)是否开放来判断服务是否正常?

HTTP URL侦测:比如向HTTP服务器发出一个对main.html文件的访问请求,如果收到错误信息,则认为服务器出现故障?

负载均衡策略的优劣除受上面所讲的两个因素影响外,在有些应用情况下,我们需要将来自同一客户端的所有请求都分配给同一台服务器去负担,例如服务器将客户端注册?购物等服务请求信息保存的本地数据库的情况下,把客户端的子请求分配给同一台服务器来处理就显的至关重要了?有两种方式可以解决此问题,一是根据IP地址把来自同一客户端的多次请求分配给同一台服务器处理,客户端IP地址与服务器的对应信息是保存在负载均衡设备上的;二是在客户端浏览器cookie内做独一无二的标识来把多次请求分配给同一台服务器处理,适合通过代理服务器上网的客户端?

还有一种路径外返回模式(Out of Path Return),当客户端连接请求发送给负载均衡设备的时候,中心负载均衡设备将请求引向某个服务器,服务器的回应请求不再返回给中心负载均衡设备,即绕过流量分配器,直接返回给客户端,因此中心负载均衡设备只负责接受并转发请求,其网络负担就减少了很多,并且给客户端提供了更快的响应时间?此种模式一般用于HTTP服务器群,在各服务器上要安装一块虚拟网络适配器,并将其IP地址设为服务器群的VIP,这样才能在服务器直接回应客户端请求时顺利的达成三次握手?