再读LVS

来源:互联网 发布:二进制转中文 Java 编辑:程序博客网 时间:2024/04/29 03:40
 警告:为了更深入地理解LVS,应该深入理解、测试8种调度算法中的每一种!!切记!!!

一、cluster 篇

在LVS框架中,提供了含有三种IP负载均衡技术的IP虚拟服务器软件IPVS、基于内容请求分发的内核Layer-7交换机KTCPVS和集群管理软件

在调度器的实现技术中,IP负载均衡技术是效率最高的。在已有的IP负载均衡技术中有通过网络地址转换(Network Address Translation)将一组服务器构成一个高性能的、高可用的虚拟服务器

Virtual Server via Network Address Translation(VS/NAT)
通过网络地址转换,调度器重写请求报文的目标地址,根据预设的调度算法,将请求分派给后端的真实服务器;真实服务器的响应报文通过调度器时,报文的源地址被重写,再返回给客户,完成整个负载调度过程。

Virtual Server via IP Tunneling(VS/TUN)---重写ip
采用NAT技术时,由于请求和响应报文都必须经过调度器地址重写,当客户请求越来越多时,调度器的处理能力将成为瓶颈。为了解决这个问题,调度器把请求报文通过IP隧道转发至真实服务器,而真实服务器将响应直接返回给客户,所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多,采用 VS/TUN技术后,集群系统的最大吞吐量可以提高10倍。

Virtual Server via Direct Routing(VS/DR)
VS/DR通过改写请求报文的MAC地址
,将请求发送到真实服务器,而真实服务器将响应直接返回给客户。同VS/TUN技术一样,VS/DR技术可极大地提高集群系统的伸缩性。这种方法没有IP隧道的开销,对集群中的真实服务器也没有必须支持IP隧道协议的要求,但是要求调度器与真实服务器都有一块网卡连在同一物理网段上。

针对不同的网络服务需求和服务器配置,IPVS调度器实现了如下八种负载调度算法:

轮叫(Round Robin)----rr
调度器通过"轮叫"调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载。

加权轮叫(Weighted Round Robin)-----wrr
调度器通过"加权轮叫"调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。

加权最少链接(Weighted Least Connections)------wlc
在集群系统中的服务器性能差异较大的情况下,调度器采用"加权最少链接"调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。

第二章

LVS集群的通用体系结构
LVS集群采用IP负载均衡技术和基于内容请求分发技术。

共享存储也不会影响访问速度,因为人们又引入了一个cache的概念:对于大多数 Internet服务来说,它们都是读密集型(Read-intensive)的应用,分布式文件系统在每台服务器使用本地硬盘作Cache(如 2Gbytes的空间),可以使得访问分布式文件系统本地的速度接近于访问本地硬盘。

存储区域网(Storage Area Networks)技术解决了集群的每个结点可以直接连接/共享一个庞大的硬盘阵列,硬件厂商也提供多种硬盘共享技术,如光纤通道(Fiber Channel)、共享SCSI(Shared SCSI)。

一般来说,调度器的可靠性较高,因为调度器上运行的程序较少而且大部分程序早已经遍历过,但我们不能排除硬件老化、网络线路或者人为误操作等主要故障。

主从调度器切换时,session是不会丢失的:IPVS调度器在Linux 内核中实现一种高效状态同步机制,将主调度器的状态信息及时地同步到从调度器。当从调度器接管时,绝大部分已建立的连接会持续下去。

主从切换的原理:当从调度器不能听得主调度器的心跳时,从调度器通过ARP欺骗(Gratuitous ARP)来接管集群对外的Virtual IP Address,同时接管主调度器的工作来提供负载调度服务。

一般web集群的架构:

第一层是负载调度器,一般采用IP负载均衡技术,可以使得整个系统有较高的吞吐率;第二层是 Web服务器池,在每个结点上可以分别运行HTTP服务或HTTPS服务、或者两者都运行;第三层是共享存储,它可以是数据库,可以是网络文件系统或分布式文件系统,或者是三者的混合。集群中各结点是通过高速网络相连接的。

IPVS提供的会话保持功能能解决以下两个问题

简而言之:1,服务器想用http cookie来跟踪客户;2,https协议,ipvs能保证ssl key生命周期内的会话发往同一真机!

有些Web服务可能用到HTTP Cookie,它是将数据存储在客户的浏览器来追踪和标识客户的机制。使用HTTP Cookie后,来同一客户的不同连接存在相关性,这些连接必须被发送到同一Web服务器。一些Web服务使用安全的HTTPS协议,它是HTTP协议加 SSL(Secure Socket Layer)协议。另有些Web服务可能使用安全的HTTPS协议,它是HTTP协议加SSL协议。当客户访问HTTPS服务(HTTPS的缺省端口为 443)时,会先建立一个SSL连接,来交换对称公钥加密的证书并协商一个SSL Key,来加密以后的会话。在SSL Key的生命周期内,后续的所有HTTPS连接都使用这个SSL Key,所以同一客户的不同HTTPS连接也存在相关性。针对这些需要,IPVS调度器提供了持久服务的功能,它可以使得在设定的时间内,来自同一IP地址的不同连接会被发送到集群中同一个服务器结点,可以很好地解决客户连接的相关性问题。

IPVS负载调度器一般使用直接路由方法(即VS/DR方法,将在以后文章中详细叙述),来架构媒体集群系统

第三章:

VS/NAT、VS/TUN和VS/DR技术是LVS集群中实现的三种IP负载均衡技术

在以下描述中,我们称客户的socket和服务器的socket之间的数据通讯为连接,无论它们是使用TCP还是UDP协议。

基于RR-DNS的解决方法

DNS(BIND)服务器里面添加两条记录:

www 60  in  a  220.19.12.124

www 60  in  a  220.19.12.125

a用户解析到220.19.12.124则访问该真机;b用户解析到220.19.12.125则访问该真机;所以实现了负载均衡!

缺点:1,dns服务器是分布式的,会逐级缓存解析结果。所以同样会导致负载不均,若引入TTL,会增加流量!

      2,由于客户端会缓存dns解析结果,所以同一用户的请求会发往同一real server,有的用户访问一分钟,有的访问2个小时,这样就导致服务器负载及不平衡!

      3,若一台真机坏了,我们更改了RR-DNS的记录,但是dns同步需要时间延迟的!

调度器需要进行四次从核心到用户空间或从用户空间到核心空间的上下文切换和内存复制内核空间

基于应用层负载均衡调度的解决方法

在前端有一个基于应用层的负载调度器。当用户访问请求到达调度器时,请求会提交给作负载均衡调度的应用程序,分析请求,根据各个服务器的负载情况,选出一台服务器,重写请求并向选出的服务器访问,取得结果后,再返回给用户。

缺点:

第一,系统处理开销特别大。当请求到达负载均衡调度器至处理结束时,调度器需要进行四次从核心到用户空间或从用户空间到核心空间的上下文切换和内存复制;需要进行二次TCP连接,一次是从用户到调度器,另一次是从调度器到真实服务器;需要对请求进行分析和重写。这些处理都需要不小的CPU、内存和网络等资源开销,且处理时间长

第二,基于应用层的负载均衡调度器对于不同的应用,需要写不同的调度器。

基于IP层负载均衡调度的解决方法(用户访问的是一个虚拟的ip!)

用户通过虚拟IP地址(Virtual IP Address)访问服务时,访问请求的报文会到达负载调度器,由它进行负载均衡调度,从一组真实服务器选出一个,将报文的目标地址Virtual IP Address改写成选定服务器的地址,报文的目标端口改写成选定服务器的相应端口,最后将报文发送给选定的服务器。真实服务器的回应报文经过负载调度器时,将报文的源地址和源端口改为Virtual IP Address和相应的端口,再把报文发给用户。

vs/nat原理:

NAT的工作原理:报文头(目标地址、源地址和端口等)被正确改写后,客户相信它们连接一个IP地址,而不同IP地址的服务器组也认为它们是与客户直接相连的。

用户请求示意图:

1 用户(requests)----->2 调度器(Scheduling&rewriting packets)-------->3 真机(processing the request)

5 用户(replies<-------4 调度器(rewriting&replies)<-------------------------|

在第2步的时候调度器在连接Hash 表中记录这个连接,当这个连接的下一个报文到达时,从连接Hash表中可以得到原选定服务器的地址和端口,进行同样的改写操作,并将报文传给原选定的服务器.同时在连接上引入一个状态机,在UDP中,我们只设置一个UDP状态。不同状态的超时值是可以设置的,在缺省情况下,SYN状态的超时为1分钟,ESTABLISHED状态的超时为15分钟,FIN状态的超时为1分钟;UDP状态的超时为5分钟。当连接终止或超时,调度器将这个连接从连接Hash表中删除。对改写后的报文,应用增量调整Checksum的算法调整TCP Checksum的值,避免了扫描整个报文来计算Checksum的开销。

注意:有的服务将ip地址和端口放在数据里面传输,这样ipvs就会有问题,必须要专门的程序做转换

比如:FTP   H..323

【知识点】

IP协议:包含原地址和目标地址

TCP协议:包含原端口和目标端口

通常web访问的话会看到[source IP:source PORT + dest IP + dest PORT] ,这是因为TCP协议在四层,IP协议在三层,这样提到TCP协议的话就已经包含了IP协议的信息! 这么复杂的关系都搞清楚了,厉害厉害~

下面举例说明下访问web的流程吧:

用户202.111.2.8 想访问118.126.1.5的web服务

source=202.111.2.8:3354  dest=118.126.1.5:80

到达调度器;调度器选好真机后改写目标ip及port;将该连接记入hash表;启动状态机

source=202.111.2.8:3354  dest=192.168.1.3:80

到达真机;处理。。。完事再返回给调度器

source=192.168.1.3:80  dest= 202.111.2.8:3354

调度器改写源地址为VIP;返回给客户端

source=118.126.1.5:80  dest= 202.111.2.8:3354

客户端收到返回数据

注意:客户的信息始终记录在报文里面

 

vs/tun原理:

· IP隧道(ip tunneling)也叫IP封装(ip encapsulation),就是将一个ip报文封装在另一个ip报文里面。

vs/tun工作流程:

1)调度器和真机之间用隧道通信;

2)VIP分别配置在调度器上面和真实服务器上

3)调度器在VIP上接收用户请求,再通过隧道转发给真机,真机处理完后用自己的VIP直接回复客户!

 

vs/dr原理:

1)调度器和真实服务器上都要配置一个VIP

2)调度器和真实服务器必须处在同一物理网段(狭隘地理解为连接在同一个交换机上)

3)真实服务器必须是Non-ARP的!

vs/dr工作流程:

在VS/DR 中,调度器根据各个服务器的负载情况,动态地选择一台服务器------>不修改也不封装IP报文,而是将数据帧的MAC地址改为选出服务器的MAC地址--------->再将修改后的数据帧在与服务器组的局域网上发送--------->因为数据帧的MAC地址是选出的服务器,所以真实服务器收到这个数据帧------->真实服务器从接收到的帧中得该IP报文-------->当服务器发现报文的目标地址VIP是在本地的网络设备上,服务器处理这个报文-------->然后根据路由表将响应报文直接返回给客户

【重点说明】原理2)提到真实服务器必须是Non-ARP:因为如果真机开启arp的话,那么客户端过来的数据包说“我是客户端的IP,我的MAC地址是XXXX,请问VIP对应的MAC地址是多少?”此时所有的真实服务器和负载调度器都作出了响应!这样就乱套了!所以为了避免真实服务器直接响应客户端的请求,必须关闭它!

查看:

[root@master ~]# ipvsadm –l                         //注意看,每一行都有特定意义

[root@master ~]# ipvsadm -l –timeout                            //tcp、tcpfin、udp的超时(秒)

[root@master ~]# ipvsadm -l –stats                                  //统计信息