负载均衡研究 基础

1.概念:php

  负载均衡是由多台服务器以对称的方式组成一个服务器集合,每台服务器都具备等价的地位,均可以单独对外提供服务而无须其余服务器的辅助。经过某种负载分担技术,将外部发送来的请求均匀分配到对称结构中的某一台服务器上,而接收到请求的服务器独立地回应客户的请求。均衡负载可以平均分配客户请求到服务器列阵,籍此提供快速获取重要数据,解决大量并发访问服务问题。html

  负载平衡主要应用于Web网站,高流量的文件下载网站,NNTP(Network News Transfer Protocol)服务和DNS服务。负载平衡器一般是一个软体程序,这个程序侦听一个外部端口,互联网用户能够经过这个端口来访问服务,而做为负载平衡器的软体会将用户的请求转发给后台内网服务器,内网服务器将请求的响应返回给负载平衡器,负载平衡器再将响应发送到用户,这样就向互联网用户隐藏了内网结构,阻止了用户直接访问后台(内网)服务器,使得服务器更加安全,能够阻止对核心网络栈和运行在其它端口服务的攻击。前端

2.网络负载均衡的优势
第一,网络负载均衡能将传入的请求传播到多达32台服务器上,便可以使用最多32台服务器共同分担对外的网络请求服务。网络负载均衡技术保证即便是在负载很重的状况下,服务器也能作出快速响应;
第二,网络负载均衡对外只需提供一个IP地址(或域名);
第三,当网络负载均衡中的一台或几台服务器不可用时,服务不会中断。网络负载均衡自动检测到服务器不可用时,可以迅速在剩余的服务器中从新指派客户机通信。这项保护措施可以帮助你为关键的业务程序提供不中断的服务,并能够根据网络访问量的增长来相应地增长网络负载均衡服务器的数量;
第四,网络负载均衡可在普通的计算机上实现。nginx

3.算法web

  负载均衡器有各类各样的工做排程算法(用于决定将前端用户请求发送到哪个后台服务器),最简单的是随机选择和轮询。更为高级的负载均衡器会考虑其它更多的相关因素,如后台服务器的负载,响应时间,运行状态,活动链接数,地理位置,处理能力,或最近分配的流量。算法

4.构架数据库

  高性能系统一般会使用多层负载均衡。另外专用的硬件负载均衡器以及纯软件负载均衡器,包括开源的,例如Apache Web服务器的mod proxy balancer扩展,nginxVarnishPound反向代理和负载均衡器。使用Gearman将合适的计算任务分发给多台计算机,如此大量的任务就能够更快的完成了。编程

5.持续性浏览器

  负载均衡器须要处理的一个重要问题是:如何保存用户会话?若是会话信息保存在后台服务器,用户接下来的请求可能会被分配到不一样的后台服务器,此时用户会话就没法继续。负载均衡器能够缓存用户会话,而后将用户请求分发到不一样的后台服务器。可是这将带来负载均衡器的负载问题。一个解决方案是将一个用户会话中的全部请求都发送到同一个后台服务器。即persistence或stickiness。这个方法的不足之处在于没法容错,若是后台服务器故障,它提供的会话就会没法取得,任何依赖于它的会话都会丢失。第二个方案是依据用户名,客户端IP来分配提供服务的服务器,也能够随机分配。由于客户多是经过DHCP,NAT或者Web代理来链接 Internet的,其IP地址可能常常变换,这使得这个方案的服务质量没法保障。随机分配由负载均衡器将会话信息存储保存。若是负载均衡器被替换或故 障,这些信息可会会丢失;另外(负载均衡器)负载较高的时候,为保证分配表空间不会被耗尽,超时的分配信息必须被删除。随机分配方法也要求客户会维持会话 状态,若是客户浏览器禁用了cookies的功能,就会引发问题。优秀的负载均衡器会使用多种持续(会话保持)技术,以免其中某些不能够用时引发故障。另一个方案是将每一会话信息保存到一个数据库中。因为这个方案会增长数据库的负载,因此这个方案对性能的提升并很差。数据库最好是用来存储会话时间比较长的会话数据。为了不数据库出现单点故障,而且提升其扩展性,数据库一般会复制到多台服务器上,经过负载均衡器来分发请求到数据库服务器上。微软ASP.net中的状态服务器技术就是一个典型的会话数据库的例子。集群中的全部服务器都将它们的会话信息保存到状态服务器上,同时它们能够向状态服务器查询会话数据。幸运的是有一种更有效的方法,一般客户浏览器能够保存用户的每一个会话信息。例如使用浏览器cookie,对数据加密并加上一个时间戳就能够保证安全了;URL重写。 将会话信息存储在客户端一般是首选方案,由于这样负载均衡器就能够灵活的选择后台服务器来处理用户请求。然而这种方法不适应于一些较复杂的电子商务,由于电子商务中会话数据较大,并且须要服务器须要常常从新处理会话信息;与此同时URL重写因为用户能够改变会话流数据而存在安全问题;加密客户端 cookies也一直存在着安全方面的争议,除非全部的会话都经过HTTPS,可是HTTPS很容易遭到中间人攻击。缓存

6.负载均衡器的特性

  • 不对称负载调节。能够对后台服务器设置权重因子,权重因子用于控制服务器的请求处理量,进而控制服务器的负载。当后台服务器的处理能力不是等同的时候,这是一种控制服务器负载的简单方法。
  • 优先启动。当出现故障的服务器达到某个阀值,或者服务器负载太高时,备用服务器必需能够及时上线提供服务。
  • SSL截断和加速。依赖服务器负载,处理加密数据或者经过SSL进行的受权请求会消耗Web服务器的大量CPU,随着需求增长用户会明显感受到响应时间变长。为了消除Web服务器上这部分(处理加密)负载,负载均衡器可能会将SSL通信截断在负载均衡器上。有些硬件负载均衡器上包含 有专门用于处理SSL的硬件。当负载均衡器截断SSL链接请求,再将用户请求转发给后台前将HTTPS变为HTTP。只有负载均衡器不超载,这个特性不会影响用户体验。这种方法的负面效应是,因为全部SSL都由负载均衡器一台设备来处理,它会致使负载均衡器成为负载均衡体系的一个瓶颈。若是不使用这个特 性,SSL请求将会分发给各个Web服务器处理。是否采用这一特性,须要分析比较二者的资金投入状况,含有处理SSL特殊硬件的负载均衡器一般价格高昂,而Web服务器通常比较廉价。增长少许的Web服务器的花费可能明显比升级负载均衡器要少。另外,一些服务器厂商如Oracle/Sun也开始在它们的 CPU中加入加密加速模块,例如T2000。在负载均衡器上截断SSL的另外一个优势是容许负载均衡器能够对基于HTTPS请求数据进行负载均衡或内容交 换。
  • DDOS攻击防御。负载均衡器能够提供例如SYN cookies特性和延时绑定(在TCP握手完成以前,后台服务器不会与用户通信)来减缓SYN flook攻击,and generally offload work from the servers to a more efficient platform.
  • HTTP压缩。使用gzip压缩HTTP数据,以减小网络上的数据传输量。对于响应时间较长,传输距离较远的用户,这一特性对于缩短响应时间效果明显。这个特性会要求更多一些的负载均衡器CPU,这一功能也能够由Web服务器来完成。
  • TCP offload。不一样的厂商叫法可能不同。其主要思想是同样的,一般每一个用户的每一个请求都会使用一个不一样的TCP链接,这个特性利用HTTP/1.1未来自多个用户的多个请求合并为单个TCP socket再转发给后台服务器。
  • TCP缓冲。负载均衡器能够暂存后台服务器对客户的响应数据,再将它们转发给那些响应时间较长网速较慢的客户,如此后台Web服务器就能够释放相应的线程去处理其它任务如直接整个响应数据直接发送给网速较快的用户。
  • 后台服务器直接响应用户(Direct Server Return)。这是不对称负载分布的一项功能,在不对称负载分布中请求和回应经过不一样的网络路径。
  • 服务器)健康检查。负载均衡器能够检查后台服务器应用层的健康情况并从服务器池中移除那些出现故障的服务器。
  • HTTP缓存。负载均衡器能够存储静态内容,当用户请求它们时能够直接响应用户而没必要再向后台服务器请求。
  • 内容过滤。有些负载均衡器能够按要求修改经过它的数据。
  • HTTP安全。有些负载均衡器能够隐藏HTTP出错页面,删除HTTP响应头中的服务器标示信息,加密cookies以防止用户修改。
  • 优先队列。也可称之为流量控制。它能够对不一样的内容设定不一样的优先级。
  • ontent-aware switching(内容感知开关)。大多数负载均衡器能够基于用户请求的URL发送请求到不一样的后台服务器,不管内容是加密(HTTPS)仍是没有加密(HTTP)。
  • 用户受权。对来自不一样身份验证源的用户进行验证,而后再容许他们访问一个网站。
  • 可编程的流量控制。不仅一种负载均衡器容许使用脚本编程来定制负载均衡方法,任意的流量控制以及其它功能。
  • 防火墙功能。因为安全的缘由,不容许用户直接访问后台服务器。防火墙是由一系列规则构成,它们决定着哪些请求能够经过一个接口而哪些不被容许。
  • 入侵阻止功能。在防火墙保障网络层/传输层安全的基础上,提供应用层安全防范。

7.四层负载均衡和七层负载均衡的区别

  四层负载均衡是经过报文中的目标地址和端口,再加上负载均衡设备设置的服务器选择方式,决定最终选择的内部服务器与请求客户端创建TCP链接,而后发送Client请求的数据。具体过程以下:在四层负载设备中,把client发送的报文目标地址(原来是负载均衡设备的IP地址),根据均衡设备设置的选择web服务器的规则选择对应的web服务器IP地址,这样client就能够直接跟此服务器创建TCP链接并发送数据。

  七层负载均衡,也称内容交换,也就是主要经过报文中的真正有意义的应用层内容,再加上负载均衡设备设置的服务器选择方式,决定最终选择的服务器。具体过程以下:七层负载均衡服务器起了一个代理服务器的做用,咱们知道创建一次TCP链接要三次握手;而client要访问webserver以前,要先与七层负载设备进行三次握手后创建TCP链接,把要访问的报文信息发送给七层负载均衡;而后七层负载均衡再根据设置的均衡规则选择特定的webserver,而后经过三次握手与此台webserver创建TCP链接,而后webserver把须要的数据发送给七层负载均衡设备,负载均衡设备再把数据发送给client;因此,七层负载均衡设备起到了代理服务器的做用。带来的好处:使整个网络更“智能化”,能把对图片类的请求转发到图片服务器,对文字的请求转发到文字服务器。能够有效防止 SYN Flood攻击,是网站更安全。带来的缺点:带来设备配置复杂,负载均衡压力增高以及故障排查上的复杂性等问题。

  补充:所谓四层就是基于IP+端口的负载均衡;七层就是基于URL等应用层信息的负载均衡;同理,还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。 换句换说,二层负载均衡会经过一个虚拟MAC地址接收请求,而后再分配到真实的MAC地址;三层负载均衡会经过一个虚拟IP地址接收请求,而后再分配到真实的IP地址;四层经过虚拟IP+端口接收请求,而后再分配到真实的服务器;七层经过虚拟的URL或主机名接收请求,而后再分配到真实的服务器。所谓的四到七层的负载均衡,就是在对后台的服务器进行负载均衡时,依据四层的信息或七层的信息来决定怎么样转发流量。好比四层的负载均衡,就是经过发布三层的IP地址(VIP),而后加四层的端口号,来决定哪些流量须要作负载均衡,对须要处理的流量进行NAT处理,转发至后台服务器,并记录下这个TCP或者UDP的流量是由哪台服务器处理的,后续这个链接的全部流量都一样转发到同一台服务器处理。七层的负载均衡,就是在四层的基础上(没有四层是绝对不可能有七层的),再考虑应用层的特征,好比同一个Web服务器的负载均衡,除了根据VIP加80端口辨别是否须要处理的流量,还可根据七层的URL、浏览器类别、语言来决定是否要进行负载均衡。举个例子,若是你的Web服务器分红两组,一组是中文语言的,一组是英文语言的,那么七层负载均衡就能够当用户来访问你的域名时,自动辨别用户语言,而后选择对应的语言服务器组进行负载均衡处理。

8.应用

  负载均衡对通信链路的冗余是很是有用的。如一家公司可能有多条互联网接入线路以保证某一条故障时仍能够正常接入互联网。故障转移的架构意味着一条链接正常使用,另一条链接做为备用,当第一条出现故障时才会被启用。使用负载均衡器,两条链接能够都投入使用。有一个设备或者程序实时监控着全部链接的连通性,而且对正在发送的包进行选路。同时使用多条链接能够增长带宽。许多电信公司在其内部网络或链接到外部网络都有多条线路可使用。为避免某条链路出现网络堵塞,最小化链接其它网络的费用或者提升网络的可靠性,它们使用负载均衡将流量从一条链路转移到另外一条链路。负载均衡的另外一个用途是监控网络活动。负载均衡器能用于将巨大的网络流量分割为几个子流并使用网络分析器,每一个都读取原始数据的一部分。这对于监视10GbE高速网络很是有用,在这些网络上因为数据量太大进行复杂的数据处理几乎是不可能的。负载均衡常常被用于实现故障转移当一个或多个组件出现故障时能持续提供服务。这些组件都在持续监控中,当一个组件没有响应,负载均衡器就会发现并再也不向其发送数据。一样当一个组件从新上线,负载均衡器会从新开始向其发送数据。为了可以如前所述正常工做,负载均衡体系中至少要有一个冗余服务。采用一用一备方案(一个组件提供服务,一个备用,当主组件故障时备用组件将接管继续提供服务)比故障转移方案更加经济,灵活。

9.健康检查

  负载均衡设备必须检测后台服务器是否在正常工做,若是发现某一台服务器出现了故障,则须要把这台服务器从负载均衡组里面摘掉。当故障服务器恢复服务的时候,再把服务器从新加入到负载均衡组里面进行处理。

10.待解决的问题

  负载均衡策略的优劣及其实现的难易程度有两个关键因素:1、负载均衡算法,2、对网络系统情况的检测方式和能力。 考虑到服务请求的不一样类型、服务器的不一样处理能力以及随机选择形成的负载分配不均匀等问题,为了更加合理的把负载分配给内部的多个服务器,就须要应用相应的可以正确反映各个服务器处理能力及网络状态的负载均衡算法

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

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

  响应速度均衡(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文件的访问请求,若是收到错误信息,则认为服务器出现故障。

相关文章
相关标签/搜索