负载均衡研究之 基础篇

转载网址：http://www.cnblogs.com/RunForLove/p/4355925.html

1.概念：

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

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

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

3.算法

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

4.构架

　　高性能系统通常会使用多层负载均衡。另外专用的硬件负载均衡器以及纯软件负载均衡器，包括开源的，例如Apache Web服务器的mod proxy balancer扩展，nginx，Varnish和Pound反向代理和负载均衡器。使用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.待解决的问题

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

　　轮循均衡（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文件的访问请求，如果收到错误信息，则认为服务器出现故障。