一、集群
系统扩展方式有两种, 一种是向上扩展(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_642.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算法