负载均衡集群的实现方式之一LVS

gdx

负载均衡集群的实现方式之一LVS(原理篇)

一：关于集群

• 集群分类
  
• 一般来说，集群按照结构与功能可以分为以下常见的几类：
  
• 负载均衡集群  LB（Load Balance Cluster）
  
•      注：负载均衡集群，一般通过一个或者多个前端负载均衡器，将到达其的负载通过某种算法分发到后台的一组服务器之上，从而达到整个集群系统的高性能和高可用的状态。
  
•      实现LB的常见的有软件实现方式：LVS和Haproxy
  
•                  硬件实现方式：BigIp(F5), A10(IBM) ,Citrix(Netscaler)
  
• 高可用集群：HA（High Availability Cluster）
  
•       一般是指当集群中的某个节点失效或者down机等原因而不能正常工作时，其上的任务会自动的转移到其他正常工作的节点之上，
  
•       或者是集群中的某个节点进行离线维护再上线，该过程并不影响整个集群系统的正常工作
  
•      实现LA集群的的常见软件方式有：hearbeat，keepalived，ultramokey等
  
• 高性能集群：Hp
  
•      高性能计算集群采用将计算任务分配到集群的不同计算节点而提高计算能力，因而主要应用在科学计算领域。
  
•      实现LP的常见软件方式有：bowerful  
  

　　二：LVS初步介绍

• 下面我们开始介绍一下LB负载均衡集群中常见的一种DR模型架构，通过LVS实现。  
  
• 那么什么是lVS呢？  
  
• LVS是 linux virtual server的缩写  
  
• LVS的DR模型大致如下图
  

• 实现LVS的三种不同方式有LVS-DNAT, LVS-DR,LVS-TRUN.
  
• 这里我们重点说明DR模型。
  
• 从上图简单的DR模型中，我们可以看出DR模式大致可以分为
  
• 1:前端的Director负载调度器
  
• 2:提供web服务的服务器群（当然还可以提供其他的服务,比如ftp服务等）
  
• 3:为web服务器群提供共享数据的共享池
  

• 在架构之前我们先说说LVS的理论基础：
  
• 说到LVS（国防科技大学的章文嵩博士创立）,LVS通过IP负载均衡技术和基于内容分发技术实现，
  
• 其在linux上提供LVS功能的是工作在内核中的ipvs模块及在用户层的ipvsadm应用程序。
  
• ipvs通过不同的算法实现对不同用户的不同请求分发到后台的Real  Server上，进而实现负载均衡算法。
  
• 所有lvs的调度器也可以称为4层交换（根据不同的端口和地址转发数据包）
  

　　三：LVS的调度算法

• LVS的负载均衡算法有动态和静态之分：
  
• 静态算法:
  
•        1:rr(Round-robin):负载调度器将用户的请求轮询的分发到不同的服务器上
  
•                           （用户请求被等比例的分发到服务器上,不同性能的服务有着同样的负载）
  
•        2：wrr(weight Routnd-robin)：负载调度器将用户的请求根据不同服务器的权重分发（不同性能的服务器有着不同的负载）
  
•        3：dh(Destination hashing)： 目标地址散列调度：根据目标地址通过hash算法就行调度实现负载均衡,                                    
  
•        4:sh(Source hashing):源地址散列地址调度，根据源地址通过hash算法就行调度实现负载均衡）
  
• 动态算法：
  
•        1：lc: least connection  （最近最少连接）  
  
•                      基于overhead来进行负载均衡(最少overhead 优先负载),
  
•                      通过活动连接个数×256+非活动连接的方式判断overhead
  
•        2：wlc : weight least connetion(加权最少连接)
  
•                   采用的方式是overhead/权重值的算法
  
•                    Overhead=活动连接个数×256+非活动连接个数
  
•                    wlc是Linux企业集群默认算法（考虑到了非活动连接数，来实现负载均衡，其平衡企业负载方面做得相当出色)
  
•        3:sed ：最少期望延迟  ，这个算法在计算权重值的时候不再考虑非活动连接数
  
•                       采用(活动连接数+1)*256/权重值 的方式判断overhead
  
•        4：NQ: never queue （永不排队）
  
•                               当某个real server只要有空闲连接时就将请求分发到其上面
  
•        5:LBLC:基于本地的最少连接 locality-based least connection  该算法是静态的dh算法的扩展，主要用户cache集群
  
•        6:LBLCR：Locality-Based Least-Connection with replication Scheduling：带复制的基于本地最少连接
  
•                 其应用的场景是，后台的服务器如果是cache服务器的时候，多个cache服务器之间可以共享资源
  
• DR模型特性：
  
•   1：所有集群节点必须要在同一个物理网络中
  
•   2：RIP可以使用公有，私有地址，不支持端口映射
  
•   3：director 仅处理入站请求，出站不经过director(解决了lvs-dnat的调度器负载较大的瓶颈问题)
  
•   4:集群节点不再使用director作为他们的网关
  
•   5：DR模型比NAT模型可以使用更多的Real server（NAT模型最多支持10个real server）
  

　　四：LVS的工作流程

• 通过上面的理论知识我们可以总结一下lvs-dr模型的工作流程：
  
• 首先我们得了解一下工作在DR模型中的几个ip
  
• CIP:客户端ip
  
• VIP：调度器前端提供用户访问的Ip
  
• DIP：调度器后端实现与real-server通信的ip
  
• RIP:工作在real-server上的ip
  

• DR模型的工作过程：
  
• 首先由CIP发起一个请求到Director调度器的VIP,
  
• Director调度器通过拆分tcp/ip报文得到大致如下信息:
  
•    源ip:CIP
  
•    目的ip:VIP
  
•    源MAC:前端的路由器（架构不同这里的MAC地址可能不同）
  
•    目的MAC:Director调度器的前端vip端口的MAC地址
  
• 当Director调度器得到如上信息后,会将该tcp/ip报文的目的MAC地址重新封装，
  
• （从其维护的real server列表中根据调度算法将目的MAC地址改为其中一个real server的MAC地址,源ip地址和目的ip地址不变，再次封装转发到前面的路由器（也可能是其他的设备）,
  
• 该设备受到这样的报文后，进而转发到real server ,随后受到报文的real server根据CIP的请求内容直接对clinet做出响应,而不再经过Director的转发过程。
  
• ----该过程本想通过抓包工具得到更多的详细信息，目前正在努力获得中。
  

　　五：总结

• 通过对DR模型的分析了解总结LVS-DR模型的相关优点和缺点，
  
• 优点：
  
• 我们可以发现DR模型相比于lvs-DNAT模型而言,Director调度器的负载压力得到较大的解脱，
  
• 因此 在后台的服务池中我们承载更多的服务器，不再考虑Director调度器的瓶颈问题,
  
• 这也是目前大多是企业采用DR模型的原因之一吧
  
• 缺点：由于lvs-DR模型的所有节点必须工作在用一个物理网络,所以不能跨区域使用（当然lvs-TRUN可以实现）,由于该种负载均衡集群是基于软件的实现方式，
  因此集群对高并发的用户响应能力相比硬件的实现方式偏低（经过良好配置和优化后的lvs，到达400W个活动会话的能力已经能够应付中小型企业了）
  

　　如有理解不到位，或者错误的地方,欢迎您的批评,指正,交流,,谢谢！！
　　---------------------------交流共同进步-----------------------------------
　　-------------------------- 期待您的留言-----------------------------------