负载平衡(英语:load balancing)是一种电子计算机技术,用来在多个计算机(计算机集群)、网络连接、CPU、磁碟驱动器或其他资源中分配负载,以达到最佳化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。 使用带有负载平衡的多个伺服器组件,取代单一的组件,可以通过冗余提高可靠性。负载平衡服务通常是由专用软件和硬件来完成。 主要作用是将大量作业合理地分摊到多个操作单元上进行执行,用于解决互联网架构中的高并发和高可用的问题。
此条目翻译自英语维基百科,需要相关领域的编者协助校对翻译。 |
基于互联网的服务
负载均衡最重要的一个应用是利用多台伺服器提供单一服务,这种方案有时也被称为伺服器农场。通常,负载平衡主要应用于Web网站,大型的Internet Relay Chat网络,高流量的文件下载网站,NNTP(Network News Transfer Protocol)服务和DNS服务。现在负载平衡器也开始支持数据库服务,称之为数据库负载平衡器。
对于互联网服务,负载平衡器通常是一个软件程序,这个程序侦听一个外部端口,互联网用户可以通过这个端口来访问服务,而作为负载平衡器的软件会将用户的请求转发给后台内网伺服器,内网伺服器将请求的响应返回给负载平衡器,负载平衡器再将响应发送到用户,这样就向互联网用户隐藏了内网结构,阻止了用户直接访问后台(内网)伺服器,使得服务器更加安全,可以阻止对核心网络栈和运行在其它端口服务的攻击。
当所有后台伺服器出现故障时,有些负载平衡器会提供一些特殊的功能来处理这种情况。例如转发请求到一个备用的负载平衡器、显示一条关于服务中断的消息等。负载平衡器使得IT团队可以显著提高容错能力。它可以自动提供大量的容量以处理任何应用程序流量的增加或减少。[1]
DNS轮循(或DNS的循环机制),是指一种负载分发,负载均衡或者容错性地提供多个冗余的IP服务主机的技术。
当前,负载均衡器有各种各样的工作排程演算法(用于决定将前端用户请求发送到哪一个后台服务器),最简单的是随机选择和轮询。更为高级的负载均衡器会考虑其它更多的相关因素,如后台服务器的负载,响应时间,运行状态,活动连接数,地理位置,处理能力,或最近分配的流量。
高性能系统通常会使用多层负载均衡。另外专用的硬件负载均衡器以及纯软件负载均衡器,包括开源的,例如Apache Web服务器的mod proxy balancer扩展,nginx,Varnish和Pound反向代理和负载均衡器。使用Gearman将合适的计算任务分发给多台计算机,如此大量的任务就可以更快的完成了。
对于一个多层次架构体系,在负载均衡器或网络分发器后面有两种设计,术语称之为Bowties和Stovepipes。Stovepipe设计中,事务是从顶部分发的,然后从一个固定通道通过一系列硬件和软件设备,到达最终目的地。如果使用Bowties设计,在每一层中事务处理有多条路径可供选择。在事务处理的网络结构中可能会是Stovepipes,也可以是Bowties,或者根据每一层的实际需求采用杂货构架。
负载均衡器需要处理的一个重要问题是:如何保存用户会话?如果会话信息保存在后台服务器,用户接下来的请求可能会被分配到不同的后台服务器,此时用户会话就无法继续。负载均衡器可以缓存用户会话,然后将用户请求分发到不同的后台服务器。但是这将带来负载均衡器的负载问题。
理想下,在负载均衡后面的服务器集群(Server cluster)不应该保存会话(session-aware),如此一来,一个用户不管什么时候连接任何一个后端服务器都不会收到影响。常用的方案是通过一个磁盘数据库(传统数据库)或者一个内存数据库(如: Memcached),实例可参考:Django 缓存框架。[2] 将会话信息存到磁盘数据库的这个方案由于会增加数据库的负载,所以这个方案对性能的提高并不好。磁盘数据库最好是用来存储会话时间比较长的会话数据。
为了避免数据库出现单点故障,并且提高其扩展性,数据库通常会复制到多台服务器上,通过负载均衡器来分发请求到数据库服务器上。微软ASP.NET中的状态服务器技术就是一个典型的会话数据库的例子。集群中的所有服务器都将它们的会话信息保存到状态服务器上,同时它们可以向状态服务器查询会话数据。
另一个简单的解决方案是,将一个指定的用户的的今后的所有请求都会发送到同一个后台服务器——这种方案也被称为“粘性(sticky)会话”或者“持续化(persistence)”。但该方案的不足之处在于:无法容错(故障转移),假如后台服务器故障,该用户的所有的会话的访问,自然地会话本身也将丢失。即便是数据库服务器也发生该情况。虽然Web服务(Web Service)不存在状态和粘性(sticky),但是用户和数据库存是绑定的(存在粘性)。
第二个方案是依据用户名,客户端IP来分配提供服务的服务器,也可以随机分配。因为客户可能是通过DHCP,NAT或者Web代理来连接Internet的,其IP地址可能经常变换,这使得这个方案的服务质量无法保障。随机分配由负载均衡器将会话信息存储保存。如果负载均衡器被替换或故障,这些信息可能会丢失;另外(负载均衡器)负载较高的时候,为保证分配表空间不会被耗尽,超时的分配信息必须被删除。随机分配方法也要求客户会维持会话状态,如果客户浏览器禁用了cookies的功能,就会引起问题。优秀的负载均衡器会使用多种持续(会话保持)技术,以避免其中某些不可以用时引起故障。
幸运的是有一种更有效的方法,通常客户浏览器可以保存用户的每个会话信息。例如使用浏览器cookie,对数据加密并加上一个时间戳就可以保证安全了;URL重写。将会话信息存储在客户端通常是首选方案,因为这样负载均衡器就可以灵活的选择后台服务器来处理用户请求。然而这种方法不适应于一些较复杂的电子商务,因为电子商务中会话数据较大,而且需要服务器需要经常重新处理会话信息;与此同时,URL重写由于用户可以改变会话流数据而存在安全问题;加密客户端cookies也一直存在着安全方面的争议,因为HTTP很容易遭到中间人攻击,除非所有的会话都通过HTTPS,否则无法保证安全性。
不论是软件负载均衡器,还是硬件负载均衡器都有一系列的特性:
- 不对称负载调节。可以对后台服务器设置权重因子,权重因子用于控制服务器的请求处理量,进而控制服务器的负载。当后台服务器的处理能力不是等同的时候,这是一种控制服务器负载的简单方法。
- 优先启动。当出现故障的服务器达到某个阈值,或者服务器负载过高时,备用服务器必需可以及时上线提供服务。
- 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 flood攻击,并且通常将工作从服务器分载到更有效的平台。
- HTTP压缩。使用gzip和Deflate等算法压缩HTTP数据,以减少网络上的数据传输量。对于响应时间较长,传输距离较远的用户,这一特性对于缩短响应时间效果明显。这个特性会耗费负载均衡器更多的CPU,这一功能也可以由Web服务器来完成。
- TCP offload。不同的厂商叫法可能不一样。其主要思想是一样的,通常每个用户的每个请求都会使用一个不同的TCP连接,这个特性利用HTTP/1.1将来自多个用户的多个请求合并为单个TCP socket再转发给后台服务器。
- TCP缓冲。负载均衡器可以暂存后台服务器对客户的响应数据,再将它们转发给那些响应时间较长网速较慢的客户,如此后台Web服务器就可以释放相应的线程去处理其它任务如直接整个响应数据直接发送给网速较快的用户。
- 后台服务器直接响应用户(Direct Server Return)。这是不对称负载分布的一项功能,在不对称负载分布中请求和回应通过不同的网络路径。
- (服务器)健康检查。负载均衡器可以检查后台服务器应用层的健康状况并从服务器池中移除那些出现故障的服务器。
- HTTP缓存。负载均衡器可以存储静态内容,当用户请求它们时可以直接响应用户而不必再向后台服务器请求。
- 内容过滤。有些负载均衡器可以按要求修改通过它的数据。
- HTTP安全。有些负载均衡器可以隐藏HTTP出错页面,删除HTTP响应头中的服务器标示信息,加密cookies以防止用户修改。
- 优先队列。也可称之为流量控制。它可以对不同的内容设定不同的优先级。
- 内容感知开关(Content-aware switching)。大多数负载均衡器可以基于用户请求的URL发送请求到不同的后台服务器,无论内容是加密(HTTPS)还是没有加密(HTTP)。
- 用户授权。对来自不同身份验证源的用户进行验证,然后再允许他们访问一个网站。
- 可编程的流量控制。不只一种负载均衡器允许使用脚本编程来定制负载均衡方法、任意的流量控制以及其它功能。
- 防火墙功能。由于安全的原因,不允许用户直接访问后台服务器。防火墙是由一系列规则构成,它们决定着哪些请求可以通过一个接口而哪些不被允许。
- 入侵阻止功能。在防火墙保障网络层/传输层安全的基础上,提供应用层安全防范。
在电信行业的应用
负载均衡对通讯链路的冗余是非常有用的。例如,一家公司可能有多条互联网接入线路以保证某一条故障时仍可以正常接入互联网。
故障转移的架构意味着一条连接正常使用,另外一条连接作为备用,当第一条出现故障时才会被启用。
使用负载均衡器,两条(多条)连接可以都投入使用。有一个设备或者程序实时监控着所有连接的连通性,并且对正在发送的包进行选路。同时使用多条连接可以增加带宽。
许多电信公司在其内部网络或连接到外部网络(其它电信网络)都有多条线路可以使用。为避免某条链路出现网络堵塞,最小化连接其它网络的费用或者提高网络的可靠性,它们使用负载均衡将流量从一条链路转移到另一条链路。IEEE 802.1aq - Shortest Path Bridging
- 更多信息请查看路由
负载均衡的另一个用途是监控网络活动。负载均衡器能用于将巨大的网络流量分割为几个子流并使用网络分析器,每个都读取原始数据的一部分。这对于监视10GbE, STM64高速网络非常有用,在这些网络上由于数据量太大进行复杂的数据处理几乎是不可能的。
在电子邮件伺服器的应用 Anti-spam Gateway或Anti-spam伺服器端软体 与备援关系 系统纪录档案的扫描(log scan)
与故障转移的关系
负载均衡经常被用于实现故障转移-当一个或多个组件出现故障时能持续提供服务这些组件都在持续监控(例如:Web服务器通过请求一个已知页面来监控是否正常工作)中,当一个组件没有响应,负载均衡器就会发现并不再向其发送数据。同样当一个组件重新上线,负载均衡器会重新开始向其发送数据。为了能够如前所述正常工作,负载均衡体系中至少要有一个冗余服务。采用一用一备方案(一个组件提供服务,一个备用,当主组件故障时备用组件将接管继续提供服务)比故障转移方案更加经济,灵活。有些类型的RAID系统使用的热备份功能跟这是类似的作用。
参考文献
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.