现在的位置: 首页 > 综合 > 正文

负载均衡分类

2013年07月17日 ⁄ 综合 ⁄ 共 6402字 ⁄ 字号 评论关闭
广 义上的负载均衡既可以设置专门的网关、负载均衡器,也可以通过一些专用软件与协议来实现。对一个网络的负载均衡应用, 从网络的不同层次入手,根据网络瓶颈所在进行具体分析。从客户端应用为起点纵向分析,参考OSI的分层模型,可以把负载均衡技术的实现分为客户端负载均衡 技术、应用服务器技术、高层协议交换、网络接入协议交换等几种方式。
负载均衡的分类

◆基于客户端的负载均衡

这 种模式指的是在网络的客户端运行特定的程序,该程序通过定期或不定期的收集服务器群的运行参数:CPU占用情况、磁盘 IO、内存等动态信息,再根据某种选择策略,找到可以提供服务的最佳服务器,将本地的应用请求发向它。如果负载信息采集程序发现服务器失效,则找到其他可 替代的服务器作为服务选择。整个过程对于应用程序来说是完全透明的,所有的工作都在运行时处理。 因此这也是一种动态的负载均衡技术。

但 这种技术存在通用性的问题。因为每一个客户端都要安装这个特殊的采集程序;并且,为了保证应用层的透明运行,需要针对每一个应用程序加以修改,通过动态链 接库或者嵌入的方法,将客户端的访问请求能够先经过采集程序再发往服务器,以重定向的过程进行。对于每一个应用几乎要对代码进行重新开发,工作量比较大。

所 以,这种技术仅在特殊的应用场合才使用到,比如在执行某些专有任务的时候,比较需要分布式的计算能力,对应用的开发没有太多要求。另外,在采用JAVA构 架模型中,常常使用这种模式实现分布式的负载均衡,因为java应用都基于虚拟机进行,可以在应用层和虚拟机之间设计一个中间层,处理负载均衡的工作。

◆应用服务器的负载均衡技术

如果将客户端的负载均衡层移植到某一个中间平台,形成三层结构,则客户端应用可以不需要做特殊的修改,透明的通过中间层应用服务器将请求均衡到相应的服务结点。比较常见的实现手段就是反向代理技术。

 

    普通代理方式是代理内部网络用户访问internet上服务器的连接请求,客户端指定代理服务器,并将本来要直接发送到internet上服务器的连接请 求发送给代理服务器处理。反向代理(Reverse Proxy)方式是指以代理服务器来接受internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给 internet上请求连接的客户端,此时代理服务器对外就表现为一个服务器。反向代理负载均衡技术就是把将来自internet上的连接请求以反向代理 的方式动态地转发给内部网络上的多台服务器进行处理,从而达到负载均衡的目的。

 

   反向代理负载均衡能以软件方式来实现,如apache mod_proxy、netscape proxy等,也可以在高速缓存器、负载均衡器等硬件设备上实现。反向代理负载均衡可以将优化的负载均衡策略和代理服务器的高速缓存技术结合在一起,提升 静态网页的访问速度,提供有益的性能;由于网络外部用户不能直接访问真实的服务器,因此还具备额外的安全性。

反向代理服务器本身虽然可以达到很高效率,但是针对每一次代理,代理服务器就必须维护两个连接,一个对外的连接,一个对内的连接,因此对于特别高的连接请 求,代理服务器的负载也就非常之大。反向代理能够执行针对应用协议而优化的负载均衡策略, 每次仅访问最空闲的内部服务器来提供服务。但是随着并发连接数量的增加,代理服务器本身的负载也变得非常大,最后反向代理服务器本身会成为整个架构体系的 瓶颈。

◆基于域名系统的负载均衡

NCSA的可扩展Web是最早使用动态 DNS轮询技术的web系统。在DNS中为多个IP地址配置同一个域名,因而查询这个域名的客户机将得到这多个IP地址中的某一个,从而使得不同的客户访 问不同的服务器,达到负载均衡的目的。在很多知名的web站点都使用了这个技术:包括早期的yahoo站点、163等。动态DNS轮询实现起来简单,无需 复杂的配置和管理,一般支持bind8.2以上的类unix系统都能够运行,因此广为使用。

DNS负载均衡是一种简单而有效的方法,但是存在不少问题。

首先域名服务器无法知道服务结点是否有效,如果服务结点失效,域名系统依然会将域名解析到该节点上,造成用户访问失效。

其 次,在于DNS的数据刷新时间TTL(Time to LIVE)标志,一旦超过设定的TTL,其他DNS服务器就需要和这个服务器交互,以重新获得地址数据,就有可能获得不同IP地址。因此为了使地址能随机 分配,就应使TTL尽量短,不同地方的DNS服务器能更新对应的地址,达到随机获得地址。然而将TTL设置得过短,将使DNS流量大增,而造成额外的网络 问题。

最后,它不能区分服务器的差异,也不能反映服务器的当前运行状态。当使用DNS负载均衡的时候,必须尽量保证不同的客户计 算机能均匀获得不同的地址。例如,用户A可能只是浏览几个网页,而用户B可能进行着大量的下载,由于域名系统没有合适的负载策略,仅仅是简单的轮流均衡, 很容易将用户A的请求发往负载轻的站点,而将B的请求发往负载已经很重的站点。因此,在动态平衡特性上,动态DNS轮询的效果并不理想。

 

◆高层协议内容交换技术

     除了上述的几种负载均衡方式之外,还有在协议内部支持负载均衡能力的技术,即URL交换或七层交换,提供了一种对访问流量的高层控制方式。Web内容交换 技术检查所有的HTTP报头,根据报头内的信息来执行负载均衡的决策。例如可以根据这些信息来确定如何为个人主页和图像数据等内容提供服务,常见的有 HTTP协议中的重定向能力等。

HTTP运行于TCP连接的最高层。客户端通过恒定的端口号80的TCP服务直接连接到服务器,然后通过TCP连接向服务器端发送一个HTTP请求。协议交换根据内容策略来控制负载,而不是根据TCP端口号,所以不会造成访问流量的滞留。

由于负载均衡设备要把进入的请求分配给多个服务器,因此,它只能在TCP连接时建立,且HTTP请求通过后才能确定如何进行负载的平衡。当一个网站的点击 率达到每秒上百甚至上千次时,TCP连接、HTTP报头信息的分析以及进程的延时将会变得很大,有可能成为系统的性能瓶颈,因此要尽可能提高这几个部份的 性能。

在HTTP请求和报头中有很多对负载均衡有用的信息,可以从这些信息中获知客户端所请求的URL和网页,利用这个信息,负载均衡设备就可以将所有的图像请 求引导到一个图像服务器,或者根据URL的数据库查询内容调用CGI程序,将请求引导到一个专用的高性能数据库服务器。

如果网络管理员熟悉内容交换技术,他可以根据HTTP报头的cookie字段来使用Web内容交换技术改善对特定客户的服务,如果能从HTTP请求中找到 一些规律,还可以充分利用它作出各种决策。除了TCP连接表的问题外,如何查找合适的HTTP报头信息以及作出负载平衡决策的过程,是影响Web内容交换 技术性能的重要问题。如果Web服务器已经为图像服务、SSL对话、数据库事务服务之类的特殊功能进行了优化,那么,采用这个层次的流量控制将可以提高网 络的性能。

◆网络地址转换(Network Address Translation,NAT)

大型的网络一般都是由大量专用技术设备组成的,如包括防火墙、路由器、第3、4层交换机、负载均衡设备、缓冲服务器和Web 服务器等。如何将这些技术设备有机地组合在一起,是一个直接影响到网络性能的关键性问题。现在许多交换机提供第四层交换功能,对外提供一个一致的IP地 址,并映射为多个内部IP地址,对每次TCP和UDP连接请求,根据其端口号,按照即定的策略动态选择一个内部地址,将数据包转发到该地址上,达到负载均 衡的目的。很多硬件厂商将这种技术集成在他们的交换机中,作为他们第四层交换的一种功能来实现,一般采用随机选择、根据服务器的连接数量或者响应时间进行 选择的负载均衡策略来分配负载。由于地址转换相对来讲比较接近网络的低层,因此就有可能将它集成在硬件设备中,通常这样的硬件设备是局域网交换机。

当前局域网交换机所谓的第四层交换技术,就是按照IP地址和TCP端口进行虚拟连接的交换,直接将数据包发送到目的计算机的相应端口。通过交换机将来自外 部的初始连接请求,分别与内部的多个地址相联系,此后就能对这些已经建立的虚拟连接进行交换。 因此,一些具备第四层交换能力的局域网交换机,就能作为一个硬件负载均衡器,完成服务器的负载均衡。

由于第四层交换基于硬件芯片,因此其性能非常优秀,尤其是对于网络传输速度和交换速度远远超过普通的数据包转发。然而, 正因为它是使用硬件实现的,因此也不够灵活,仅仅能够处理几种最标准的应用协议的负载均衡,如HTTP。当前负载均衡主要用于解决服务器的处理能力不足的 问题,因此并不能充分发挥交换机带来的高网络带宽的优点。

使用基于操作系统的第四层交换技术因此孕育而生。通过开放源码的Linux,将第四层交换的核心功能做在系统的核心层,能够在相对高效稳定的核心空间进行 IP包的数据处理工作,其效率不比采用专有OS的硬件交换机差多少。同时又可以在核心层或者用户层增加基于交换核心的负载均衡策略支持,因此在灵活性上远 远高于硬件系统,而且造价方面有更好的优势。

 

混合型负载均衡

在有些大型网络,由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异,可以考虑给每个服务器群采用最合适的负载均衡方式,然后又在这多个服务器 群间再一次负载均衡或群集起来以一个整体向外界提供服务(即把这多个服务器群当做一个新的服务器群),从而达到最佳的性能,这种方式称之为混合型负载均 衡。这种方式有时也用于单台均衡设备的性能不能满足大量连接请求的情况下。

下图展示了一个应用示例,三个服务器群针对各自的特点,分别采用了不同的负载均衡方式。当客户端发出域名解析请求时,DNS服务器依次把它解析成三个服务器集群的VIP,如此把客户端的连接请求分别引向三个服务器群,从而达到了再一次负载均衡的目的。

在图中,负载均衡设备在网络拓朴上,可以处于外部网和内部网络间网关的位置,也可以和内部服务器群处于并行的位置,甚至可以处于内部网络或internet上的任意位置,特别是在采用群集负载均衡时,根本就没有单独的负载均衡设备。

服务器群内各服务器只有提供相同内容的服务才有负载均衡的意义,特别是在DNS负载均衡时。要不然,这样会造成大量连接请求的丢失或由于多次返回内容的不同给客户造成混乱。 

 

下面以在apachemod_proxy下做的反向代理负载均衡为配置实例:在站点www.test.com,我们按提供的内容进行分类,不同的服 务器用于提供不同的内容服务,将对http://www.test.com/news的访问转到IP地址为192.168.1.1的内部服务器上处理,对 http://www.test.com/it的访问转到服务器192.168.1.2上,对http://www.test.com/life的访问转 到服务器192.168.1.3上,对http://www.test.com/love的访问转到合作站点http://www.love.com上, 从而减轻本apache服务器的负担,达到负载均衡的目的。
首先要确定域名www.test.com在DNS上的记录对应apache服务器接口上具有internet合法注册的IP地址,这样才能使internet上对www.test.com的所有连接请求发送给本台apache服务器。
在本台服务器的apache配置文件httpd.conf中添加如下设置:
proxypass     /news      http://192.168.1.1
proxypass     /it      http://192.168.1.2
proxypass     /life     http://192.168.1.3
proxypass     /live     http://www.live.com
注意,此项设置最好添加在httpd.conf文件“Section 2”以后的位置,服务器192.168.1.1-3也应是具有相应功能的www服务器,在重启服务时,最好用apachectl configtest命令检查一下配置是否有误。

接下来也是我真正想要介绍的2.2版本后在mod_proxy中新添加的mod_proxy_balancer模块给我们带来的新功能。

首先将在主配置文件http.conf以下Module的注释去掉
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
LoadModule proxy_http_module modules/mod_proxy_http.so

再并增加以下元素
ProxyRequests Off
ProxyPass /test  balancer://xuanfei stickysession=jsessionid nofailover=On
<proxy balancer://xuanfei/>
BalancerMember http://192.168.28.131  loadfactor=1
BalancerMember http://192.168.28.130  loadfactor=1
</proxy>
ProxyPass为代理转发的Url,即将所有访问/test的请求转发到群集balancer://xuanfei
loadfactor为各主机间的负载比例参数,可是设置不同指数
BalancerMember为群集的成员,即群集服务器A或B,负载均衡服务器会根据均衡规则来将请求转发给BalancerMember。

配置好后,启动Apahce服务<Location /server-status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from all
</Location>
访问xuanfei/test就会看到群集服务器中应用返回的结果。恭喜你,负载均衡和群集已经配置成功了!

而且还可以同样在http.conf主配置文件主添如下元素:
<Location /balancer-manager>
SetHandler balancer-manager
Order Deny,Allow
Deny from all
Allow from all
</Location>
如果配置成功后你可以可以在地址栏输入 xuanfei/balancer-manager,将可以清楚的看到各节点的工作运行状态:)

同样还可以同样在http.conf主配置文件主添如下元素:
<Location /server-status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from all
</Location>
便可以方便的观测到主服务器的当前运行状态,只要在地址栏输入 xuanfei/server-status

用ab对apache负载均衡集群的性能测试对比报告

   小结:apache自带mod_proxy功能模块中目前可以实现两种不同的负载均衡集群实现方式,第一种是分工合作的的形式,通过各台主机负责不同的 任务而实现任务分工。第二种是不同的机器在担任同样的任务,某台机器出现故障主机可以自动检测到将不会影响到客户端,而第一种却不能实现但第一种实现方式 的优点在于他是主服务器负担相应没第二种大因为台只是提供跳转指路功能,形象的说他不给你带路只是告诉你有条路可以到,但到了那是否可以看到你见的人他已 经不会去管你了:)。相比之下第二种性能要比第一种会好很多;但他们都有个共同点都是一托N形式来完成任务的所以你的主机性能一定要好。

抱歉!评论已关闭.