LVS是什么???

       首先简单介绍一下LVS (Linux Virtual Server)到底是什么东西?其实它是一种集群(Cluster)技术,LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服务器的故障,从而将一组服务器构成一个高性能的、高可用的虚拟服务器。为此,在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。

LVS集群的体系结构有三个主要组成部分:

       1.负载调度器(load balancer),它是整个集群对外面的前端机,负责将客户的请求发送到一组服务器上执行,而客户认为服务是来自一个IP地址上的。它可以是用IP负载均衡技术的负载调度器,也可以是基于内容请求分发的负载调度器,还可以是两者的结合。

       2.服务器池(server pool),是一组真正执行客户请求的服务器,执行的服务有WEB、MAIL、FTP和DNS等。

       3.后端存储(backend storage),它为服务器池提供一个共享的存储区,这样很容易使得服务器池拥有相同的内容,提供相同的服务。

PS:调度器采用IP负载均衡技术、基于内容请求分发技术或者两者相结合。在IP负载均衡技术中,需要服务器池拥有相同的内容提供相同的服务。当客户请求到达时,调度器只根据负载情况从服务器池中选出一个服务器,将该请求转发到选出的服务器,并记录这个调度;当这个请求的其他报文到达,也会被转发到前面选出的服务器。在基于内容请求分发技术中,服务器可以提供不同的服务,当客户请求到达时,调度器可根据请求的内容和服务器的情况选择服务器执行请求。因为所有的操作都是在操作系统核心空间中将完成的,它的调度开销很小,所以它具有很高的吞吐率。


        服务器池的结点数目是可变的。当整个系统收到的负载超过目前所有结点的处理能力时,可以在服务器池中增加服务器来满足不断增长的请求负载。对大多数网络服务来说,结点与结点间不存在很强的相关性,所以整个系统的性能可以随着服务器池的结点数目增加而线性增长。


        后端存储通常用容错的分布式文件系统,如AFS、GFS、Coda和Intermezzo等。分布式文件系统为各服务器提供共享的存储区,它们访问分布式文件系统就像访问本地文件系统一样。同时,分布式文件系统提供良好的伸缩性和可用性。然而,当不同服务器上的应用程序同时访问分布式文件系统上同一资源时,应用程序的访问冲突需要消解才能使得资源处于一致状态。这需要一个分布式锁管理器(Distributed Lock Manager),它可能是分布式文件系统内部提供的,也可能是外部的。开发者在写应用程序时,可以使用分布式锁管理器来保证应用程序在不同结点上并发访问的一致性。


         负载调度器、服务器池和分布式文件系统通过高速网络相连,如100Mbps交换机、Myrinet、CompactNET和Gigabit交换机等。使用高速的网络,主要为避免当系统规模扩大时互联网络成为瓶颈。

LVS集群采用IP负载均衡技术:

         1.通过NAT实现虚拟服务器(VS/NAT)。

         2.通过直接路由实现虚拟服务器(VS/DR)。

         3.通过IP隧道实现虚拟服务器(VS/TUN)。

1.通过NAT实现虚拟服务器(VS/NAT):

wKiom1YZ6fbhDPgXAAMRlA8LINY804.jpg

LVS NAT的特性:

  1.RS的Rip应该使用私有地址;

  2.RS的网关必须指向Dip;

  3.Rip和Dip必须在同一网段内;

  4.请求和响应的报文都得经过Director,在高负载场景中,Director很可能成为性能瓶颈;

  5.支持端口映射;

  6.RS可以使用任意支持集群服务的OS;

说明:客户通过Virtual IP Address(Vip)访问网络服务时,请求报文到达Dirctor,Dirctor根据连接调度算法从一组真实服务器中选出一台服务器,将报文的目标地址Vip(Virtual IP Address)改写成选定Rip,报文的目标端口改写成选定服务器的相应端口,最后将修改后的报文发送给选出的服务器。同时,调度器在连接Hash表中记录这个连接,当这个连接的下一个报文到达时,从连接Hash表中可以得到原选定服务器的地址和端口,进行同样的改写操作,并将报文传给原选定的服务器。当来自真实服务器的响应报文经过Dirctor时,Dirctor将响应报文的Rip和源端口改为Vip(Virtual IP Address)和相应的端口,再把报文发给用户。我们在连接上引入一个状态机,不同的报文会使得连接处于不同的状态,不同的状态有不同的超时值。在TCP连接中,根据标准的TCP有限状态机进行状态迁移;在UDP中,我们只设置一个UDP状态。不同状态的超时值是可以设置的,在缺省情况下,SYN状态的超时为1分钟,ESTABLISHED状态的超时为15分钟,FIN状态的超时为1分钟;UDP状态的超时为5分钟。当连接终止或超时,Dirctor将这个连接从连接Hash表中删除。这样,客户所看到的只是在Vip(Virtual IP Address)上提供的服务,而服务器集群的结构对用户是透明的。对改写后的报文,应用增量调整Checksum的算法调整TCP Checksum的值,避免了扫描整个报文来计算Checksum的开销。

LVS NAT的性能瓶颈:

          VS/NAT 的优点是服务器可以运行任何支持TCP/IP的操作系统,它只需要一个IP地址配置在Dirctor上,服务器组可以用私有的IP地址。缺点是它的伸缩能力有限,当服务器结点数目升到20时,Dirctor本身有可能成为系统的新瓶颈,因为在VS/NAT中请求和响应报文都需要通过负载Dirctor。 我们在Pentium 166 处理器的主机上测得重写报文的平均延时为60us,性能更高的处理器上延时会短一些。假设TCP报文的平均长度为536 Bytes,则Dirctor的最大吞吐量为8.93 MBytes/s. 我们再假设每台服务器的吞吐量为800KBytes/s,这样一个Dirctor可以带动10台real server。如果能将请求和响应分开处理,即在负载调度器(Director)中只负责调度请求而响应直接(RealServer)返回给客户,将极大地提高整个集群系统的吞吐量。


2.通过直接路由实现虚拟服务器(VS/DR):

Vip,Dip,Rip在同一网段使用私有地址时:

wKiom1YZ7W3Bc0aCAAQ2FSz-b8k845.jpg

Vip,Dip和Rip不在同一网段,Rip使用私有地址时:

wKioL1YZ7v7g6cQRAAUgJ52H5iA569.jpg

LVS DR类型的特性:

  1.RS可以使用私有地址,还可以使用公网地址,使用公网地址时可以直接通过互联网连入RS,以实现配置、监控等;

  2.RS的网关一定不能指向DIP;

  3.RS跟Dirctory要在同一物理网络内(不能有路由器分隔);

  4.请求报文经过Directory,但响应报文一定不经过Director;

  5.不支持端口映射;

  6.RS可以使用大多数的操作系统;

问题:如何解决前端路由将客户端请求报文发往Vip时,只能是Dirctor上的Vip(所有的RS上都要关闭对ARP广播的响应)???

解决方法:修改linux内核参数,将RS上的Vip配置在lo接口的别名上,限制linux仅对对应接口的ARP请求做相应;

                 1.arp_ignore          ###定义接受到ARP请求时的相应级别

                         0:只要本地配置的有相应地址,就给予响应;

                         1:仅在请求的目标地址配置请求到达的接口上的时候,才给予响应;

              2:只回答目标IP地址是来访网络接口本地地址的ARP查询请求,且来访IP必须在该网络接口的子网段内;

              3:不回应该网络界面的arp请求,而只对设置的唯一和连接地址做出回应;

              4-7:保留未使用;

                         8:不回应所有(本地地址)的arp查询;

PS:默认是0,只要这台机器上面任何一个设备上面有这个ip,就响应arp请求,并发送MAC地址应答;

                 2.arp_announce    ###定义将自己地址向外通告是的通告级别

                         0: 将本地任何接口上的任何地址向外通告;

                         1:试图仅想目标网络通告与其网络匹配的地址;

                         2:仅向与本地借口上地址匹配的网络进行通告;

说明:Dirctor和RS组都必须在物理上有一个网卡通过不分段的局域网相连,即通过交换机或者高速的HUB相连,中间没有隔有路由器。Vip地址为Director和RS组共享(在Director和各个RS上都必须配置同一个Vip),Director配置的Vip地址是对外可见的,用于接收虚拟服务的请求报文;所有的RS把Vip地址配置在各自的Non-ARP网络设备上,它对外面是不可见的,只是用于处理目标地址为Vip的网络请求。

在VS/DR模型中,当客户端请求报文到达Director,Director根据各个RS的负载情况,动态地选择一台RS,不修改也不封装IP报文,而是将数据帧的MAC地址改为选出RS的MAC地址,再将修改后的数据帧在与RS组的局域网上发送。因为数据帧的MAC地址是选出的RS,所以RS肯定可以收到这个数据帧,从中可以获得该IP报文。当RS发现报文的目标地址Vip是在本地的网络设备上,RS处理这个报文,然后根据路由表将响应报文直接返回给客户不再经过Director。在VS/DR中,请求报文的目标地址为Vip,响应报文的源地址也为Vip,所以响应报文不需要作任何修改,可以直接返回给客户,客户认为得到正常的服务,而不会知道是哪一台服务器处理的。

VS/DR负载Director也只处于从客户到服务器的半连接中,按照半连接的TCP有限状态机进行状态迁移。


3.通过IP隧道实现虚拟服务器(VS/TUN):

wKioL1YaAp-QgFrQAATIyetg1r4770.jpg

LVS TUN类型(IP隧道):

   1.Rip,Dip,Vip都得是公网地址;

   2.RS的网关不会指向也不可能指向Dip;

   3.请求报文经过Directory,但响应报文一定不经过Director;

   4.不支持端口映射;

   5.RS的OS必须得支持IP Tunneling”或者“IP Encapsulation”协议

说明:IP隧道(IP tunneling)是将一个IP报文封装在另一个IP报文的技术,这可以使得目标为一个IP地址的数据报文能被封装和转发到另一个IP地址。IP隧道技术亦称为IP封装技术(IP encapsulation)。IP隧道主要用于移动主机和虚拟私有网络(Virtual Private Network),在其中隧道都是静态建立的,隧道一端有一个IP地址,另一端也有唯一的IP地址。

           我们利用IP隧道技术将请求报文封装转发给后端服务器,响应报文能从后端服务器直接返回给客户。但在这里,后端服务器有一组而非一个,所以我们不可能静态地建立一一对应的隧道,而是动态地选择一台服务器,将请求报文封装和转发给选出的服务器。这样,我们可以利用IP隧道的原理将一组服务器上的网络服务组成在一个IP地址上的虚拟网络服务。各个服务器将VIP地址配置在自己的IP隧道设备上。

           Director根据各个RS的负载情况,动态地选择一台RS,将请求报文封装在另一个IP报文中,这个IP报文的源IP是Dip目标IP是Rip,再将封装后的IP报文转发给选出的RS;RS收到报文后,先将报文解封获得原来目标地址为Vip的报文,RS发现Vip地址被配置在本地的IP隧道设备上,所以就处理这个请求,然后根据路由表将响应报文直接返回给客户不再经过Director。


十种调度算法:

        IPVS在内核中的负载均衡调度是以连接为粒度的。在HTTP协议(非持久)中,每个对象从WEB服务器上获取都需要建立一个TCP连接,同一用户的不同请求会被调度到不同的服务器上,所以这种细粒度的调度在一定程度上可以避免单个用户访问的突发性引起服务器间的负载不平衡。

分为两大类:

        静态调度算法: Director只根据算法本身进行调度,不考虑后端RS的负载情况              

                    轮叫调度  rr:(Round-Robin Scheduling)

                    加权轮叫调度  wrr:(Weighted Round-Robin Scheduling)

                    源地址散列调度  sh:(Source Hashing Scheduling)

                    目标地址散列调度  dh:(Destination Hashing Scheduling)

        动态调度算法: Director根据算法及RS的负载情况进行调度               

                    最小连接调度  lc:(Least-Connection Scheduling)

PS:最小连接 查看每个节点的active 和inactive数量,根据active* 256+inactive 的值,哪个结果小,就将请求发送给该RS;

                    加权最小连接调度  wlc:(Weighted Least-Connection Scheduling)

PS:加权最小连接 查看每个节点的active 和inactive数量,根据(active* 256+inactive)/weighted 的值,哪个结果小,就将请求发送给该RS;

                    基于局部性的最少链接  lblc:(Locality-Based Least Connections Scheduling)

PS:当Director和RS之间有squid或varnish缓存服务器时,需要在Director上设置,使请求分别到两台缓存服务器上;

                    带复制的基于局部性最少链接  lblcr:(Locality-Based Least Connections with Replication Scheduling)

PS:在LBLC的基础上,若其中一部分人不在访问网站,则下面一台缓存服务器将不会有页面缓存,这时候该缓存服务器将会空闲下来。该算法使下面一台缓存服务器自动复制上面一台缓存服务器的网页,用于提供缓存;

                    最短预期延时调度  sed:(Shortest Expected Delay Scheduling)

PS:最短预期延时连接 查看每个节点的active 和inactive数量,根据(active + 1)* 256/weighted 的值,哪个结果小,就将请求发送给该RS;

                    不排队调度  nq:(Never Queue Scheduling)

PS:永不排队 若果某个节点未处于活动连接,就将下一个请求发送给该节点进行处理;


PS:参考网站  http://zh.linuxvirtualserver.org/handbooks