首页 > 运维 > 负载均衡工作模式以及工作原理
2013
04-14

负载均衡工作模式以及工作原理

负载均衡的多种解决方案:

HTTP重定向

当用户发来请求的时候,Web服务器通过修改HTTP响应头中的Location标记来返回一个新的url,然后浏览器再继续请求这个新url,实际上就是页面重定向。
通过重定向,来达到“负载均衡”的目标。例如,我们在下载PHP源码包的时候,点击下载链接时,为了解决不同国家和地域下载速度的问题,它会返回一个离我们近的下载地址。重定向的HTTP返回码是302
这个重定向非常容易实现,并且可以自定义各种策略。但是,它在大规模访问量下,性能不佳。而且,给用户的体验也不好,实际请求发生重定向,增加了网络延时。
 

反向代理负载均衡

反向代理服务的核心工作主要是转发HTTP请求,扮演了浏览器端和后台Web服务器中转的角色。因为它工作在HTTP层(应用层),也就是网络七层结构中的第七层,因此也被称为“七层负载均衡”。可以做反向代理的软件很多,比较常见的一种是Nginx。
Nginx是一种非常灵活的反向代理软件,可以自由定制化转发策略,分配服务器流量的权重等。反向代理中,常见的一个问题,就是Web服务器存储的session数据,因为一般负载均衡的策略都是随机分配请求的。同一个登录用户的请求,无法保证一定分配到相同的Web机器上,会导致无法找到session的问题。

解决方案主要有两种:
1)配置反向代理的转发规则,让同一个用户的请求一定落到同一台机器上(通过分析cookie),复杂的转发规则将会消耗更多的CPU,也增加了代理服务器的负担。
2)将session这类的信息,专门用某个独立服务来存储,例如Redis/memchache,这个方案是比较推荐的。

反向代理服务,也是可以开启缓存的,如果开启了,会增加反向代理的负担,需要谨慎使用。这种负载均衡策略实现和部署非常简单,而且性能表现也比较好。
但是,它有“单点故障”的问题,如果挂了,会带来很多的麻烦。而且,到了后期Web服务器继续增加,它本身可能成为系统的瓶颈。
 

DNS负载均衡

DNS(Domain Name System)负责域名解析的服务,域名url实际上是服务器的别名,实际映射是一个IP地址,解析过程,就是DNS完成域名到IP的映射。而一个域名是可以配置成对应多个IP的。因此,DNS也就可以作为负载均衡服务。
这种负载均衡策略,配置简单,性能极佳。但是,不能自由定义规则,而且,变更被映射的IP或者机器故障时很麻烦,还存在DNS生效延迟的问题。
 

CDN/GSLB负载均衡

我们常用的CDN(Content Delivery Network,内容分发网络)实现方式,其实就是在同一个域名映射为多IP的基础上更进一步,通过GSLB(Global Server Load Balance,全局负载均衡)按照指定规则映射域名的IP。
一般情况下都是按照地理位置,将离用户近的IP返回给用户,减少网络传输中的路由节点之间的跳跃消耗。

CDN在Web系统中,一般情况下是用来解决较大的静态资源(html/Js/Css/图片/视频/文件等)的加载问题,让这些比较依赖网络下载的内容,尽可能离用户更近,提升用户体验。
这种方式,和前面的DNS负载均衡一样,性能极佳,而且支持配置多种策略。但是,搭建和维护成本非常高。互联网一线公司,会自建CDN服务,中小型公司一般使用第三方提供的CDN。

IP负载均衡

IP负载均衡服务是工作在网络层(修改IP)和传输层(修改端口,第四层),比起工作在应用层(第七层)性能要高出非常多。
原理是,他是对IP层的数据包的IP地址和端口信息进行修改,达到负载均衡的目的。这种方式,也被称为“四层负载均衡”。
常见的负载均衡方式,是LVS,通过IPVS(IP Virtual Server,IP虚拟服务)来实现。

LVS是Linux Virtual Server的简写,意即Linux虚拟服务器,是一个虚拟的服务器集群系统。

 
这个项目在1998年5月由章文嵩博士成立,是中国国内最早出现的自由软件项目之一。
 

Lvs 提供几种负载均衡集群机制:

 

DR模式  直接路由模式
NAT模式 网络地址转换模式
TUN模式 隧道模式
FULLNAT模式

LB 负载均衡(Load Balance)
RS 真实服务器(Real Server)
 

1.DR模式(Direct Routing)

负载均衡 (一) 工作模式以及工作原理
  DR模式下,客户端的请求包到达负载均衡器的虚拟服务IP端口后,负载均衡器不会改写请求包的IP和端口,但是会改写请求包的MAC地址为后端RS的MAC地址,然后将数据包转发;真实服务器处理请求后,响应包直接回给客户端,不再经过负载均衡器。所以DR模式的转发效率是最高的,特别适合下行流量较大的业务场景,比如请求视频等大文件。
 
  DR模式的特点:
数据包在LB转发过程中,源/目的IP端口都不会变化
  LB只是将数据包的MAC地址改写为RS的MAC地址,然后转发给相应的RS。
 
每台RS上都必须在环回网卡上绑定LB的虚拟服务IP
  因为LB转发时并不会改写数据包的目的IP,所以RS收到的数据包的目的IP仍是LB的虚拟服务IP。为了保证RS能够正确处理该数据包,而不是丢弃,必须在RS的环回网卡上绑定LB的虚拟服务IP。这样RS会认为这个虚拟服务IP是自己的IP,自己是能够处理这个数据包的。否则RS会直接丢弃该数据包!
 
RS上的业务进程必须监听在环回网卡的虚拟服务IP上,且端口必须和LB上的虚拟服务端口一致
  因为LB不会改写数据包的目的端口,所以RS服务的监听端口必须和虚拟服务端口一致,否则RS会直接拒绝该数据包。
 
RS处理完请求后,响应直接回给客户端,不再经过LB
  因为RS收到的请求数据包的源IP是客户端的IP,所以理所当然RS的响应会直接回给客户端,而不会再经过LB。这时候要求RS和客户端之间的网络是可达的。
 
LB和RS须位于同一个子网
  因为LB在转发过程中需要改写数据包的MAC为RS的MAC地址,所以要能够查询到RS的MAC。而要获取到RS的MAC,则需要保证二者位于一个子网,否则LB只能获取到RS网关的MAC地址。

 

2.NAT模式(Network Address Translation)

负载均衡 (一) 工作模式以及工作原理
  NAT模式下,请求包和响应包都需要经过LB处理。当客户端的请求到达虚拟服务后,LB会对请求包做目的地址转换(DNAT),将请求包的目的IP改写为RS的IP。当收到RS的响应后,LB会对响应包做源地址转换(SNAT),将响应包的源IP改写为LB的IP。

 
  NAT模式的特点:

LB会修改数据包的地址
  对于请求包,会进行DNAT;对于响应包,会进行SNAT。
 
LB会透传客户端IP到RS(DR模式也会透传)
  虽然LB在转发过程中做了NAT转换,但是因为只是做了部分地址转发,所以RS收到的请求包里是能看到客户端IP的。
 
需要将RS的默认网关地址配置为LB的浮动IP地址
  因为RS收到的请求包源IP是客户端的IP,为了保证响应包在返回时能走到LB上面,所以需要将RS的默认网关地址配置为LB的虚拟服务IP地址。当然,如果客户端的IP是固定的,也可以在RS上添加明细路由指向LB的虚拟服务IP,不用改默认网关。
 
LB和RS须位于同一个子网,并且客户端不能和LB/RS位于同一子网
  因为需要将RS的默认网关配置为LB的虚拟服务IP地址,所以需要保证LB和RS位于同一子网。
 
  又因为需要保证RS的响应包能走回到LB上,则客户端不能和RS位于同一子网。否则RS直接就能获取到客户端的MAC,响应包就直接回给客户端了,不会走网关,也就走不到LB上面了。这时候由于没有LB做SNAT,客户端收到的响应包源IP是RS的IP,而客户端的请求包目的IP是LB的虚拟服务IP,这时候客户端无法识别响应包,会直接丢弃。
 

3.TUN模式 (tunnel)

负载均衡 (一) 工作模式以及工作原理
  采用NAT模式时,由于请求和响应的报文必须通过调度器地址重写,当客户请求越来越多时,调度器处理能力将成为瓶颈。
为了解决这个问题,调度器把请求的报文通过IP隧道转发到真实的服务器。真实的服务器将响应处理后的数据直接返回给客户端。
这样调度器就只处理 入站请求报文,由于一般网络服务应答数据比请求报文大很多,采用TUN模式后,集群系统的最大吞吐量可以提高10倍。
   
  TUN和NAT模式不同的是,它在LB和RS之间的传输不用改写IP地址。而是把客户请求包封装在一个IP tunnel里面,然后发送给RS节点服务器,节点服务器接收到之后解开IP tunnel后,进行响应处理。
并且直接把包发送给客户端,不用经过LB服务器。
 

4.FULLNAT模式

负载均衡 (一) 工作模式以及工作原理
FULLNAT模式
  FULLNAT模式下,LB会对请求包和响应包都做SNAT+DNAT。
 
  FULLNAT模式的特点:

LB完全作为一个代理服务器
  FULLNAT下,客户端感知不到RS,RS也感知不到客户端,它们都只能看到LB。此种模式和七层负载均衡有点相似,只不过不会去解析应用层协议,而是在TCP层将消息转发
LB和RS对于组网结构没有要求
  不同于NAT和DR要求LB和RS位于一个子网,FULLNAT对于组网结构没有要求。只需要保证客户端和LB、LB和RS之间网络互通即可


本文》有 0 条评论

留下一个回复