LVS负载均衡-废话概念

        LVS（Linux Virtual Server）是一个用来实现负载均衡的软件系统，由实际工作于内核部分的ipvs框架和在用户空间用于编写规则的ipvsadm组成。工作方式是通过所设定的调度方式和规则来分发访问请求给后端的生产服务器。章文嵩博士是LVS的创始人和主要开发人员。

       负载均衡分为网络层负载均衡和应用层负载均衡，LVS现在还是属于是网络层的。但是在以后应该会有应用层的功能。

       在集群中时间一定要同步。

一、概念部分：

调度算法

LVS怎样分发访问请求，全看定义的调度算法了。

 

首先是静态调度，只是简单的分发，而不会把后端服务器的负载计算进来。

1. 轮叫（Round Robin）：定义时使用rr。最简单的按所定义的服务器顺序向后依序分发。

2. 加权轮叫（Weighted Round Robin）：定义时使用wrr。加权顺序的分发，如：权重为2，就分给此服务器2次访问请求，然后再把访问请求发给下台服务器。

   
   

3. 源地址散列（Source Hashing)：sh。以访问的源地址和所分发的服务器地址来记录一张hash表，在连接断开以后源地址再次访问的时候LVS根据表中的记录把请求发到对应的服务器，因为非常影响均衡效果，所以很少会用。

   
   

4. 目标地址散列（Destination Hashing）：dh。对这个不怎么了解，跟Source Hashi差不多，就是变成了目标地址。

5. 
   

动态调度，根据不同服务器的连接数的不同，动态的调整。

1. 最少链接（Least Connections）：lc。顾名思义，总是把请求分给最少链接的服务器。计算方式就是Overhead=Active*256+Inactive（活动连接*256+非活动连接）。但是所带来的问题就是，各台服务器性能不同怎么办。

   
   

2. 加权最少链接（Weighted Least Connections）：wlc。默认的调度算法。Overhead=(Active*256+Inactive)/weight。这样就弥补了性能不同的问题，但是在连接数都是0的情况下，计算结果都是一样的0，这样就按所定义服务器的顺序来分配了。看起来也不是什么重要的问题，一般也是用这个算法（算法也是有开销的，太高级的算法，开销自然也大）。不过还是有解决这个问题的算法。

   
   

3. 最短期望延迟（Shortest Expected Delay）：sed。为了避免wlc算法中在计算都是0开销的情况下，而产生的分配了一个非常差的服务器。所以这里的算法是Overhead=(Active+1)*256/weight，加1以后也就没有0，也就不会产生计算出相同的值了。但是又有问题了，如果一台服务器的权重是300，一台是50，这样在访问请求不多的情况下，很可以是300的那台一直在工作，50的那台一直在闲着。虽说也不是什么大问题，不过还是有解决这个问题的算法。

   
   

4. 最少队列调度（Never Queue Scheduling NQ）：nq。只要服务器的连接数为0，就抛开算法把访问请求先给那台服务器，只有所有服务器的连接数都不是0以后，再按sed算法来调度。

   
   

5. 基于局部性的最少链接（Locality-Based Least Connections）

6. 带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）

上面有的可能介绍的不是很详细，还有5、6都不知道怎么介绍：可以看下面两个网址，介绍的很请楚。

http://zh.linuxvirtualserver.org/node/2903

http://www.linuxvirtualserver.org/zh/lvs1.html

注意：只要tcp连接没有中断，都是会调度到同一台服务器的，LVS维持着一张连接表，用以保持着那些正在建立tcp连接或是已经建立连接的会话是同一台服务器。而调度到不同服务器的都是新的连接请求。

而在表中那些连接所保持的超时时间是可以设置的，下面列出一些数据，不过不是完全固定的，可能会因为一些别的机制，而在背地里发生改变，就算它显示的是15分钟，可能一分钟之后就没有了。

在缺省情况下，SYN状态的超 时为1分钟，ESTABLISHED状态的超时为15分钟，FIN状态的超时为1分钟；UDP状态的超时为5分钟。当连接终止或超时，调度器将这个连接从表中删除

lvs类型：

• NAT模型：用dnat功能实现的lvs。

图中VIP就是代表虚拟IP，是对外的IP。 Director就是LVS调度器了，DIP就是Director的IP。Real Server就是直正给客户提供服务的服务器了，RIP就是Real Server的IP了，而CIP就是客户端的IP了。

• Director是唯一对外的主机，内部主机对外是透明的，提高了安全性。

• 同样的，所有数据都经过Director，高负载情况下是个瓶颈。

• 支持端口映射
  

• 内部主机用的都是私有IP，因为只有Direcotr一台主机对外。

• DIP与RIP要在同一个网络中。
  

• 内部主机要以Director为网关，这样发去外部的数据才能到达Director。

• CIP发送请求给VIP，Director把收到的访问请求的目标地址和端口改为某个Real Server的ip和端口并记录在nat表中，然后从DIP网卡发出到内部，此时源地址是CIP，目标地址是某个Real Server，某个Real Server收到访问自己的访问请求并回复，此时目标地址是CIP，源地址是Real Server的RIP，Director收到Real Server的数据，查找nat表，再把源地址改为VIP，并从VIP网卡发出。

• DR模型：

• 上面图有点乱： 大概意思就是：LVS和各Real Server都拥有VIP地址。访问请求来的时候是从客户到LVS的VIP，而返回的时候就直接从Real Server的VIP返回了。

• 数据来的时候经过Director，在走的时候一定不能经过Director，DR模型就是为了避免这个。

• 不支持端口映射。

• Real Server的网关一定不能是Director。

• 没有NAT模型的瓶颈问题。

• 也没有了nat模型中对内部主机形成的保护。
  

• DIP和RIP可以是公网地址也可以是私有地址，但一定要在同一个网络中。

• 如果是公有地址，过程大约就是：

1. CIP发送请求给VIP。

2. 在数据到达Switch交换机以前的路由器时，路由器会发送ARP广播来获取VIP的MAC地址，这时只有Director会响应，Real Server虽然有VIP的地址，但是经过某些配置不会去回应这个请求。

   
   

3. 路由器收到MAC地址以后，封装数据帧，MAC地址为Director。

4. 封装有目标MAC的数据帧到达Switch，交换机查找自己的MAC-端口表（如果没有对应项，就广播 发送数据帧），从对应端口把数据发出，到达Director。

   
   

5. 数据从网卡进入，网卡驱动程序检测目标MAC是自己，所以数据到达网络层经过Director内部的路由以后到达Director的INPUT链，在INPUT口上有IPVS的规则存在，所以会在这里匹配规则，一旦匹配成功直接把数据从INPUT口弹出去（注意：并不会从INPUT口进入主机更高层）并且把数据帧的目标MAC地址改为Real Server其中一台主机的MAC地址。

   
   

6. 数据又回到Switch中，交换机把数据从所对应的目标MAC的端口发出。

7. 数据到达Real Server，一直到达网络层，发现目标地址是VIP，是自己的IP地址，经过主机内部的路由进入INPUT口，并且拆除IP封装。Real Server把数据处理完成以后在网络层封装上源地址为VIP，目标地址为CIP的IP层报文。 然后从OUTPUT链出来，经过主机内部路由，数据就被发送到了网关。最终传回到客户机。

在做配置的时候，如果只有一张网卡，要注意把DIP的地址放在网卡的主地址上，VIP地址放到网卡的别名上。如：eth0为DIR，eth0:0为VIP。 因为arp广播的问题，主位是DIP的情况下，广播源就是DIP。Real Server收到以后会正常的响应RIP的MAC地址。 但如果是主位是VIP，那么广播源就是VIP了，Real Server收到以后就直接响应给自己的VIP地址了。

• 如果是私有地址的话，在数据返回的线上需要加一个内网的路由器，而数据传送过程，对比于公网的也就是网关改了而已，原来的网关是Route A，现在是Route B了。

  
  

• 在下面这张图中，如果不加Route B的话，主要问题就是Route A和RIP不在一个网段，而导致数据根本就不会离开Real Server的网卡（在网络层路由的时候数据就返回了），因为Real Serve内部没有对应的路由条目来到达Route A。

  
  

• 如果在Real Serve加上到Route A的路由，再在Route A上加上到Real Server的路由，就也可以用，但是手动添加路由条目还不如加个路由器来的干净利落。而且如果有前端路由器的权限直接加上个IP地址就更简单了。

  
  

• 所以要在内网加个网关(Route B)，Real Server要把网关指向Route B，这样也就有了可以通信的默认路由来把数据给转出去。
  

• 至于上面所说的不在一个网段，是因为： VIP是公网地址，Route A对应于Director的网卡应该是同一个网段的，而且也是Director的网关，当然也是一个公网地址啦。

  
  

• 虽说Real Server有VIP地址，但那是隐藏的地址，目的就是不让它发送arp响应和广播，而且也是没有路由条目的。它的作用就是封装报文件的时候，源地址封装成VIP。

  
  

• 网络底层通信靠的是MAC地址和ARP。
  

• 访问过程也就是下面这个节奏，Route B如果与Route A在同一个网段内的话，下一跳也可以指向Route A。
  

  
  

在DR模型中，请求的目标地址始终是VIP,源地址是CIP，不会发生变化。而回复的时候的目标地址就是CIP，源地址是VIP。

TUN模型：跟DR模型并不多，只不过Director与Real Server不是在同一个网络中了。

• Director不能再依靠改变目标MAC地址来把请求弹给各Real Server了。而是依靠IP隧道技术。

• IP隧道（IP tunneling）是将一个IP报文封装在另一个IP报文中的技术。

• 在传传过程中，网络中的路由器只查看第一层IP报文并完成路由转发，而不会拆开再看里面有什么东西。一直到数据到达目标主机，主机查看IP报文，发现是自己RIP地址的。所以拆开IP，拆开以后发现是配置在IP隧道上的VIP地址，最终是按VIP地址来处理请求。然后Real Server会封装源地址为VIP,目标地址为CIP的报文并回复。

  
  

• VIP、DIP、RIP都得是公网地址
  

  
  

• 各Real Server的VIP在网络上是不可见的，是路由不到的地址， 维一可以路由到的VIP地址就是Director的VIP了。 各Real Server只有RIP是可达的。

• 各个服务器的网关都是自己网络中的网关，不可能是DIP。

• Director根据自己的调度算法选择一台Real Server，然后封装双层IP报文，里面的就是VIP了，然后外面的就是所选的RIP了。

• 隧道技术是一种点对点的链接，因而必须在链接的两端配置隧道协议。

• 这种模型的没有做过实验，也不是很了解。而且这种模型下DIP是不是可以不用呢。 

没想写着写着就这么多了，实际配置就写在下一篇吧。 写的很乱，而且都是自己所想的，难免会有想错的地方。还是那句老话，有错误请帮忙指点一下。 谢谢大家。