lvs(1)

zhaolu

一、集群
　　系统扩展方式有两种, 一种是向上扩展(scale up), 通过提升CPU规格、磁盘空间、内存空间等方式来提高性能; 第二种就是通过横向扩展(scale out), 通过将一组相互独立、通过高速网络互连的计算机(这些计算机都提供相同的服务)组成一个组, 并以单一系统模式进行管理. 当客户端与集群通信时, 对客户端来说集群就想一个独立的服务器.

1.1 集群类型
　　集群有三种类型:

• LB(Load Banlancing): 负载均衡, 根据算法将请求分摊后端多个服务器上进行处理, 从而提高服务的并发性能和可用性.
  
• HA(High availability): 高可用, 相同的两个及以上运行相同服务的主机, 在一个发生故障时可以及时切换到其他健康的主机上, 避免业务因故障而中断.
  
• HP(High Performancing): 高性能集群,
  

1.2 LB集群的实现


类型
名称




硬件
BIGIP(F5), NetScaler(Citrix), A10(A10), Array, Redware


软件
lvs, haproxy, nginx, ats(Apache Traffic Server), Perbal


传输层
lvs, haproxy(mode tcp)


应用层
haproxy, nginx, ats, perbal

二、lvs
　　lvs(Linux Virual Server)是软件LB的实现, 工作在传输层, 根据请求报文的目标IP和PORT将其转发至后端主机集群中的某一台主机(根据挑选算法). lvs的实现是ipvs, 命令行工具是ipvsadm.
　　ipvs支持TCP、UDP、AH、EST、AH_EST、SCTP等诸多协议. 一个ipvs主机可以同时定义多个cluster service; 一个cluster service上至少应该有一个RealServer(定义时需要指明lvs-type和lvs scheduler).
　　ipvs工作在内核空间, 附着在netfilter的INPUT链上, 当一个请求进入之后通过PREROUTING链到达INPUT链之后, 会在INPUT链上强制修改请求从POSTROUTING链出主机到达后端的RealServer之上.
　　详细流程请看下图:  

　　查看内核是否支持ipvs:

$ grep -i -A 10 'IPVS' /boot/config-VERSION.x86_64
2.1 lvs术语

• 调度器: director, dispatcher, balancer
  
• DIP: Director IP
  
• VIP: Director Virtual IP
  
• CIP: Client IP
  
• RIP: Realserver IP
  

2.2 lvs类型

2.2.1 lvs-nat
　　多目标的DNAT(iptables), 它通过修改请求报文的目标IP地址(同时可能修改目标端口)至挑选出某RS的RIP实现地址转发.
　　请求报文流程图:  

• 用户对director发起请求, 这时在三层的首部中, 源地址是CIP, 目标地址是VIP;
  
• 报文从director的配置了VIP这种网卡进入被PREROUTING链捕获, 本应该交由FORWARD链, 但此时IPVS强行修改路径将数据包从PREROUTING链转发至INPUT链上; 并且将目标地址改为RIP, 将报文交由POSTROUTING链;
  
• 然后从配置了DIP这张网卡出去, 交给后端的RealServer(通过挑选算法.)
  

　　响应报文流程图:  

• RealServer收到请求后, 将响应报文封装, 此时数据包的目标地址是CIP, 源地址是RIP;
  
• 数据包被发送至Director, 从配置了DIP的网卡进入, 交由PREROUTING链, 然后转发至INPUT链, 这时数据包的目标地址不变, 仍然是CIP, 而源地址被修改为VIP;
  
• 然后交由POSTROUTING链, 从配置了VIP的网卡出去, 通过路由器发送给互联网的Client.
  

　　配置lvs-nat的注意事项:

• RS和DIP应该使用私网地址, 且RS的网关要指向DIP.
  
• 请求和响应报文都要经由director转发; 极高负载的场景中, director可能会成为系统瓶颈.
  
• 支持端口映射.
  
• RS可以使用任意OS.
  
• RS的RIP和director的DIP必须在同一IP的网络.
  

2.2.2 lvs-dr(Direct Routing)
　　它通过修改报文的目标MAC地址进行转发.
　　请求报文流程图:  

• Clint对director发起请求, 这时在三层的首部中, 源地址是CIP, 目标地址是VIP; 在二层的首部中源mac是CIP-MAC, 目标mac是VIP-MAC;
  
• VIP配置在网卡ens33的别名上(ens33:0); 数据包从ens33:0进入, 在到达INPUT链后;
  
• 此时源IP和目标IP均未修改, IPVS只是修改了源MAC为DIP-MAC, 目标MAC为RIP-MAC;
  
• 由于DIP和RIP处于同一个网络中, 所以是通过二层传输; POSTROUTING链检查目标MAC为RIP-MAC, 便将数据包交由配置了DIP的网卡ens33发送至后端的RealServer上(通过挑选算法).
  
• 数据包从RIP进入RealServer, 然后被交给绑定了VIP的lo:0(lo的别名), lo:0将数据包解包后将请求报文交给用户空间的应用获取Client请求的资源.
  

　　响应报文流程图:  

• lo:0获取请求报文后, 此时目标地址为CIP, 源地址为VIP; 目标MAC被修改CIP-MAC, 源MAC被修改为VIP-MAC;
  
• lo:0将数据包发送给配置了RIP的网卡(ens33), 此时数据包将被通过互联网路由发回给Client.
  

　　配置lvs-dr的注意事项:

• 保证前端路由器将目标IP为VIP的请求报文发送给director:
  
  
  
  • 静态绑定
    
  • arptables
    
  • 修改RS主机内核参数
    
  
  
• RS的RIP可以使用私有地址, 也可以使用公网地址;
  
• RS跟Director必须在同一物理网络中;
  
• 请求报文经由Director调度, 但响应报文一定不能经由Director;
  
• 不支持端口映射;
  
• RS可以是大多数OS;
  
• RS的网关不能指向DIP.
  

2.2.3 lvs-tun
　　不修改请求报文的IP首部, 而是通过在原有IP首部(cip  vip)之外, 在封装一个首部(dip  rip).
　　请求报文流程图:  

• 当用户请求到达Director时, 请求的数据报文会被绑定了vip的网卡交由PREROUTING链后转交给INPUT链, 此时源IP为CIP, 目标IP为VIP;
  
• 此时IPVS会在原来的数据报文的首部在封装一层IP报文, 封装源IP为DIP, 目标IP为RIP, 并且将重新封装后的数据包交由POSTROUTING链, 然后在从绑定了DIP的网卡发送给后端的RS.
  
• RS接受到数据包, 解包后发现里面还有一层IP首部, 而且目标IP是回环接口的VIP(lo:0), 就将数据包转发给回环接口, 回环接口接到数据包并解包, 将请求报文发给用户空间的APP获取相应的资源.
  

　　响应报文流程图:  

• 回环接口获取响应报文后, 将报文封装通过本机的物理网卡发送出去, 此时数据包首部的源IP为VIP, 目标IP为CIP;
  
• 数据包经过重重路由后发送至Client.
  

　　lvs-tun模型的注意事项:

• RIP, DIP, VIP全得是公网地址;
  
• RS的网关不能指向DIP
  
• 请求报文必须经由director调度, 但响应报文必须不能经由director;
  
• 不支持端口映射;
  
• RS的OS必须支持隧道功能.
  

2.2.4 lvs-fullnat
　　director通过同时修改请求报文的目标地址和源地址进行转发.
　　流程图参考lvs-nat模型.
　　lvs-fullnat模型的注意事项:

• vip是公网地址, RIP和DIP是私网地址, 二者无须在同一网络中;
  
• RS接收到的请求报文的源地址为DIP, 因此要响应给DIP;
  
• 请求报文和响应报文都必须经由director;
  
• 支持端口映射机制;
  
• RS可以是任意OS.
  

三、lvs scheduler
　　调度方法有总的来说分为静态方法和动态方法:

• 静态方法: 仅根据算法本身进行调度
  
  
  
  • RR: Round Robin, 轮询
    
  • WRR: Weight Round Robin, 加权轮询
    
  • SH: Source Hash, 源地址IP hash, 实现会话保持的机制, 将来自同一个IP的请求始终调度至同一个RS
    
  • DH: Destination Hash, 目标地址IP hash, 将对同一目标的请求始终发往同一个RS
    
  
  
• 动态方法: 根据算法及各RS的当前负载状态进行调度, 根据overhead来计算
  
  
  
  • LC: Least Connection, 最少连接数量, 如果所有RS的连接数为0, 则从RS列表中至上而下开始调度; overhead=Active*256+Inactive
    
  • WLC: Weighted Least Connection, 加权的最少连接数; Overhead=(Active*256+Inactive)/Weight
    
  • SED: Shortest Expection Delay, 最短期望延迟; Overhead=(Active+1)*256/weight
    
  • NQ: Never Queue, SED算法的改进
    
  • LBLC: Locality-Based Least Connection, 即为动态的DH算法, 正向代理情形下的cache server调度
    
  • LBLCR: Locality-Based Least Connection with Replication, 带复制的LBLC算法