一、LVS简介
1、LVS
LVS：Linux Virtual Server
作者：章文嵩
也被称作layer4 router/layer4 switch
根据目标地址和端口作出转发与否决策，根据调度方法作出转发至哪一个后端服务器的决策
2、组成部分
ipvs/ipvsadm
ipvs：
是框架，需要依赖于规则；工作于内核中，是真正实现将用户请求转发功能的组件，ipvs工作于netfilter的INPUT链接，
ipvs打破了netfilter的工作模式，所以ipvs和netfilter的过滤功能不应该同时使用
ipvsadm：
用于在ipvs上定义集群服务，同时也得定义此集群服务对应于有哪些后端主机可用
支持协议：TCP，UDP，SCTP，AH，ESP，AH_ESP
3、LVS中的常用术语约定
Host:
Director：调度器
Real Server：RS，后端正在提供服务的的主机
IP：
Client：CIP，用户的ip
Directory Virtual IP：VIP；调度器上对外向客户公布的IP，可以转移
Real IP：RIP；后端真正提供服务的主机通信的ip
Directory IP：DIP；调度器上与RIP通信的ip
二、LVS的类型
NAT：相当于多目标的iptables的DNAT
DR：direct routing
TUN：tunneling
FULLNAT：fullnat
原生不支持，需要向内核打补丁，重新编译
1、NAT类型
架构：
在一组RS前有一个Director，它们通过Swith相连接，这些RS提供相同的网络服务、相同的内容，即不管请求被发送到哪一台RS，执行结果都一样。服务的内容可以复制到每台服务器的本地硬盘上，也可以通过文件系统（如NFS）共享，也可以通过一个分布式文件系统来提供
工作原理：类似于iptables的DNAT，但支持多目标转发
用户通过VIP访问网络服务时，请求报文达到Director，Director根据调度方法（算法）从一组RS中选出一台服务器，将请求报文的目标地址改写成选定RIP，目标端口改写成选定RS的相应端口，当来自RS的响应报文经过Direcctor时，调度器将报文的源地址和源端口改为VIP和相应的端口，再把报文发给用户。
架构特性：
1）RRIP应该为私有地址，各RS的网关必须指向DIP
2）请求和响应报文都经由Director转发，高负载场景中，Director易成为系统瓶颈
3）支持端口映射
4）RS可使用任意类型OS
5）RS的RIP必须与DIP在同一网络
6）服务器集群的结构对用户而言是透明的，用户所看到的只是在Director上提供服务
NAT类型适用于并发不是特别高场景中，RS 10台以内
2、DR类型 （Direct Routing）
直接路由，通过MAC地址转发
大多数Internet服务都有这样的特性：请求报文较短而响应报文往往包含大量的数据。
如果能将请求和响应分开处理，即Director只负责调度请求，而响应直接返回给客户，这将极大第提高整个集群系统的吞吐量。
架构：
工作原理
Director在实现转发时不修改请求报文IP首部，而是通过直接封装MAC首部完成转发。目标MAC是Director根据调度算法选定的RS的MAC地址
架构特性：
1）VIP被Director和RS组共享
2）让前端路由将请求发往VIP时，只能发往Director上的VIP
解决方案：
静态绑定：在前端路由直接将VIP对应的目标MAC地址静态配置为Director的MAC地址 此方法不实用：
未必有路由器的配置权限
Director调用时静态地址绑定将难以适用
arptables：在各RS上，通过arptables规则拒绝其响应VIP的ARP广播请求（不常用）
内核参数：在各RS上修改内核参数，并结合地址的配置方式实现拒绝响应VIP的ARP广播请求（将RS上的VIP配置为lo接口的别名，限制linux仅对对应接口响应）
3）RS的RIP可以使用私有IP，此时也可以使用公网IP，此时可以通过互联网直接对此RS发起管理操作
4）Director只负责调度请求报文，而响应报文直接返回给用户，请求报文必须经由Director调度，但响应报文必须不经过Director调度
5）各RIP必须DIP在同一物理网段中（不能有路由器分隔，广播报文要能到达），最好在同一网络中
6）不支持端口映射
7）RS可以使用大多数的OS
8）RS的网关一定不能指向Director
3、lvs-tun类型
扩展的dr类型，跨互联网
工作原理：
不修改请求报文IP首部，而是通过IP隧道机制在原有的IP报文之外再封装IP首部，经由互联网把请求报文转发给选定的RS
内层IP首部CIP,VIP
外层IIP首部DIP,RIP
架构特性：
1）RIP,DIP（可以不是）,VIP都必须是公网IP
2）RS的网关不可能指向DIP；RS和Directory不在同一个地理位置
3）请求报文由Director分发，但响应报文直接由RS响应给Client
4）不支持端口映射
5）RS的OS必须支持IP隧道技术
4、FULLNAT类型
工作原理：
通过修改请求报文的源地址为DIP,目标地址为RIP来实现转发，对于响应报文而言，修改源地址为VIP，目标地址为CIP来实现转发
架构特性：
1）RIP，DIP可以使用私有地址
2）RIP，DIP可以不在同一网段中，且RS的网关未必需要指向Director
3) 支持端口映射
4）RS的OS可以使用任意类型
5）请求报文经由Director，响应报文经由Director
三、LVS Scheduler
LVS的调度方法
1、静态方法
仅根据算法本身实现调度；起点公平
RR：round robin 轮询/轮叫/轮调/轮流
WRR：weighted round-robin 加权轮询
DH：Destionation ip Hashing 目标地址哈希，用的不多
SH：source ip Hashing 源地址哈希，用的不多
SH：Source ip Hashing，源地址哈希 当请求到达调度器时，调度器会在内存中找一段空间，将请求中的源地址抽取出来，做哈希计算。如果该用户是第一次请求，它会通过算法挑一台后端RS，并将这台RS和用户请求的哈希计算的结果对应起来，保存在哈希表中。所以，当用户请求到达时，会先查这张表。因此，它会将来自同一个地址请求，统统定向至此前选定的RS。这是一种反负载均衡的算法。那这种算法意义何在？会话保持，防止购物车中的信息刷新后没了。 DH：Destination ip Hashing, 目标地址哈希，这里指的是响应报文中的目标地址 特殊场景中才会用到，比如一个公司有多个入口；为了防止用户的请求是通过第一个防火墙进来，但响应是通过第二个防火墙出去，但防火墙只允许通过它出去的响应报文才能进来，导致用户无法收到响应报文的情况。因此在公司内部搞一个调度器，将用户请求为某目标的。可以增加缓存的命中率，这种场景很少见。 |
2、动态方法
根据算法及后端RS当前的负载状况实现调度；结果公平
LC：Least connection 最少连接
优先分配给Overhead（负载值）小的RS，相同Overhead就自上而下分配
Overhead(负载值) = Active*256(活动连接数) + Inactive（非活动连接数）
WLC：weighted Least connection 加权最少连接(lvs默认使用的算法)
Overhead = (Active*256+Inactive)/weighted
SED：Shorted Expection Delay 最短期望延迟
Overhead=(Active+1)*256/weighted
NQ：Never Queue 永不排队，第一轮先自上而下分配，第二轮开始计算最少连接
LBLC：Local-Based Least Connetion 动态方式的DH的算法，用的不多
它的主要目的跟dh一样，只是dh并不考虑cache server的负载情况，lblc考虑而已。尽管要保证命中的提高，并同样的请求发送给同一个cache server但也要考虑轮询新的连接用一个相对空闲的cache server来响应。
LBLCR：Replicated LBLC 带复制的LBLC，用的不多
“带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标 IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入。
4、集群Session持久机制
Session sticky(粘性)：
基于源IP绑定，SH算法，基于cookie绑定
反均衡，服务器故障时session问题解决不了
Session Replication Cluster：
Session复制集群，适用于少数RS（3-5个RS)
各RS做成多播集群，RS之间以多播方式“复制”各session，从而每个RS会持有所有session
这个集群缺点在于，后端每台RS都要维护RS数量倍数的会话，RS数量越多，RS的压力就越大。
Session Server：
使用独立的服务器，专用于共享存储session信息（redis，memcached）
session server需要高可用
基于cookie而不再是IP做调度：
用户在访问服务器时，服务器会给客户端发一个瘦cookie，而后将每个cookie和session的对应关系，保存在一个表中。此后客户端请求时，服务器通过追踪客户端提交的cookie来关联它的session。由于LVS工作在4层而不是应用层，因此不支持。因此haproxy和Nginx便有了用武之地。
wlc是lvs的默认调度算法，要考虑session的话，就只能使用SH了。因为lvs工作在四层，所以无法基于cookie做调度。而正因为lvs工作在四层，所以它的连接数不受套接字的限制，才能有那么好的性能。
