对于负载均衡的一大应用就是处理服务器的任务。如何进行有效的配置和规划，让每一个服务器接受到等量的工作，这就是服务器负载均衡设备的工作。在整个服务器集群中，若有一个服务器出现了故障，只需将它提出到集群之外进行维修，之后在加入集群中就可以了。中间，负载均衡能自动进行任务的从新分配，不会造成单个集中性的负载问题。

服务器负载如何分担?

服务器负载均衡(SLB)设备的功能越来越高级,有越来越多的产品通过解释URL等HTTP头中的应用种类信息来分流数据

SLB设备既可以应用于面向执行交易处理的手机站点,也可以按客户端种类将通信分流到特定服务器?支持防火墙设备?VPN设备和入侵检测系统(IDS,Intrusion Detection System)的负载均衡设备相继出台?

负载均衡的主要用法

负载均衡的目的不同,对产品所要求的功能也不同?负载均衡设备有以下几种主要用法:

(1)将来自用户的接入请求分散给多个服务器,要求这种产品有SLB功能和3/4层交换功能;

(2)将通信流量分散给多台防火墙设备?入侵检测系统和VPN设备;

(3)将来自用户的接入请求分散给Internet上不同站点的服务器,要求这种产品有站点间的负载均衡功能;

(4)将交易处理分散给适当的服务器,要求这种产品有支持应用层的负载均衡功能?

其中,需求量最大的是(1)?

精确识别HTTP头

支持应用层的SLB设备,具有识别应用种类信息并据此分配通信流量的功能?在EC站点,对于交易类处理过程,有时同一客户端与服务器之间要有多次反复的数据交换;在这种情况下,需要有管理会话?将来自同一用户的通信量分配给同一个服务器的能力?

作为负载分配条件,可以利用下述4种信息:

(1)URL;

(2)Cookie ;

(3)SSL会话ID;

(4)源IP地址和端口号?

其中(1)?(2)是包含在HTTP头中的信息,这是只有支持应用层才会有的功能?过去的SLB产品中也支持(2)~(4),最近,也开始向支持(1)的方向发展?支持应用层的所有SLB设备,都已经或计划不久要支持(1)?

支持服务器ID

在执行交易处理的接收手机接入请求的站点中,为了有效进行负载均衡,有越来越多可以利用服务器ID的产品问世?这种产品通过识别存储在URL中的服务器ID,将通信量分配给适当的服务器?支持应用层的产品,基本上都有这个功能?若将来自特定用户的接入请求分配给同一个服务器,可以使系统既容易构筑,也不易形成瓶颈?因此,要利用各种信息来实现会话管理,将会话ID存储到由服务器返给用户的URL参量和Cookie中,或利用SSL会话ID对会话进行管理?SLB设备参照会话管理信息,将交易处理的通信量分配给适当的服务器?

在接收手机上网的站点中,多数采用将会话ID存储到URL的方法?现在的浏览器电话基本上都支持Cookie和SSL,过去的SLB设备,不能参照存储到URL的信息来决定分配对象,而最近的产品基本上都做到了这点?但是,如果利用URL和Cookie等HTTP头信息来管理会话,要大量消耗SLB设备CPU的处理能力?随着同时进行会话数目的增加,要检测的会话ID也增多,CPU的负荷越来越重?于是,存储在URL中的 服务器ID应运而生,在服务器端与会话ID一起,作为用于识别服务器的ID发布,附加在URL中返给用户?此后,SLB设备按服务器ID来分配通信量即可?而且,即使同时的会话数增加,对SLB设备的影响也不大?

按不同终端来切换服务器

通过识别URL等HTTP头来分配通信量的功能,除用于会话管理外,还可用于其它用途,如按客户端种类和所要求的处理来分配通信量?用HTTP头的“User-Agent"项,判断浏览器类型(客户机类型), 可以将通信传送给保有相应客户机内容的服务器?如果希望由不同服务器分别提供面向手机的内容和面向PC的内容,这是个非常方便的功能?此外,还可将对HTML文件和图像文件等静态数据的请求传送给缓存服务器;将对CGI和JSP等动态数据的请求传送给应用服务器?

均等分配服务器负载

哪个产品都能用Ping来确认服务器的响应速度,用TCP/UDP端口来确定不同“应用"类型的状态 ?但仅靠这样的功能,实际上还无法弄清楚分配目标服务器是否是轻载?如果能深入检测到应用的状态,就能确实做到由负荷轻的服务器处理通信?同时,也可以避免发生这样的问题:将请求分配到了TCP/IP处于运行状态而Web服务器等的应用却处于宕机状态的服务器?

美国Hydraweb Technologies公司的Hydra系列?Coyote Point Systems公司 的Equalizer 系列和以色列Radware公司的WSD-Pro+ 系列,在服务器中装入专用代理软件,具有根据CPU和内存利用率来分配通信的功能?例如,两台Web服务器的CPU利用率分别是25%和50%,可以按2:1的比例来分配通信量?

利用代理功能可以详细把握服务器和应用的状况,但在服务器端安装代理软件比较费事?要想省事,还有一种方法就是利用SNMP的信息?如果利用支持SNMP的服务器和OS,不装入代理软件也能掌握服务器的状态?F5 Networks公司的BIG-IP?思科的Local Director?CSS系列 和WSD-Pro+等产品,支持SNMP监视功能?另外,还可以从应用侧来控制通信的分配?例如,在用某个检索数据库进行重要处理之际,将更多的通信分配给参照其它检索数据库的Web服务器?

加速HTTP通信的产品

可加速Web服务器响应速度?减轻负荷的产品现在已经上市,如BIG-IP和美国Clickarray Networks公司的 Array 系列产品?这种产品具有减少HTTP通信中“建立/切断TCP连接"开销的功能?

在通常的HTTP通信中,每次传输文件都要建立和断开TCP连接?TCP连接的建立/切断,对于HTTP通信来说是开销,会引起响应速度下降和负荷增加?因此,在HTTP/1.1中,规定用一次TCP连接?集中传输多个文件?在一页上有多个图像文件的站点中,由于削减了建立/切断TCP连接的开销,可望大幅提高响应速度?在SLB设备中,有两种情况可以建立永久性TCP连接:(1)在SLB设备与Web服务器之间,用永久性TCP连接集中传输多个用户请求的多个文件;(2)在客户机和SLB设备之间,每个客户端实现一个TCP连接,集中传输多个文件?这种通信方法通常叫做“保持通话连接(Keep Alive)"?

支持多重防火墙的产品

还有在多重防火墙和VPN设备中可使用的负载均衡设备?如BIG-IP?Alteon系列等?在构筑大规模Intranet和使用VPN进行企业内外频繁通信时,防火墙和VPN往往会成为瓶颈?在这种情况下,最好导入支持防火墙负载均衡的产品?在导入这些产品时,要设置两台负载均衡设备,将多个防火墙和VPN设备夹在中间来分散流向防火墙和VPN的通信量?这种情况下,如果 “往返" 的通信不是通过同一个防火墙和VPN,就不能正确工作?因此,在Internet侧和Intranet侧设置的负载均衡设备要相互协调?

还有支持IDS的负载均衡的产品,如Alteon 和美国Toplayer公司的AppSwitch3500 等?如果简单分散流向IDS的通信量,恐怕不能检测出诸如DoS(Denial of Service)这类连续通信构成的攻击?因此,支持IDS的负载均衡产品具有这样的功能:以送达目标IP地址作为判定条件,将一连串连续的通信分配给特定的IDS?

通过Internet进行站点间负载均衡

有的产品具有通过Internet实现站点间负载均衡的功能?最近,越来越多的产品标准配置有站点间负载均衡功能或通过“可选项"追加这个功能?

Array系列和Foundry公司的ServerIron系列的标准配置有站点间负载均衡功能;BIG-IP和Equalizer系列,可以通过“选项"选择支持站点间负载均衡功能?

F5 Networks公司的3DNS?思科的Content Router 4400?北电的Personal Content Director以及Hydra 等都是用于站点间负载均衡的专用设备?这些专用设备与站点内的SLB设备并用,可以掌握各站点的负荷状况,精确控制分配对象?

URL改写与CDS联合

在不改变服务器上内容的情况下,具有支持CDS(Content Delivery Service)功能的产品也开始面市?利用CDS时,必须将内容中的URL改写成专用的标识?尽管有改写工具,但要一个一个的改写服务器上的内容也很烦琐?使用URL的改写功能,就无须变更服务器上的内容?今后,与CDS联合起来实现负载均衡也是一种方向?如果利用配置有逆向代理缓存(Reverse Proxy cache )功能的Array系列,也可以构筑简易CDS?

SLB设备的选择标准

注意吞吐量—在选择产品时,吞吐量是重要的技术指标?在识别应用层时,必须将分割成包的信息复元成“应用",这无疑加重了处理负担?目标吞吐量的计算方法,各个厂家往往不同?在安装必要的处理时是否能达到所需要的吞吐量,必须要得到厂家的确认?在使用SSL时,为了识别应用层的信息,事先必须要解密SSL?如果要选择配置有加速器功能的产品和可追加加速器功能的产品,SSL的处理不会成为瓶颈?Intel的7180/7185 e-Commerce Director和Array 系列,其标准配置有加速器,BIG-IP用选项可以追加?

注意各产品分配条件定义上的差异—在分配条件的定义方法上,各产品是有差别的?例如,在HTTP头中包含有特定字符串时,作为分配通信的判定方法,BIG-IP系列产品和其它产品就有所不同?另外,对HTTP头内容的解释,不同产品也有所不同?在SLB设备中,有的产品只能解释Cookie和URL等有限的HTTP头,有的产品能解释的字节数有限制?在应用时,一定要充分确认是否满足识别HTTP头所需要的条件?