LVS集群基础知识
LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。本项目在1998年5月由章文嵩博士成立，是中国国内最早出现的自由软件项目之一。
优点
1、开源，免费
2、在网上能找到一些相关技术资源
3、具有软件负载均衡的一些优点
缺点
1、最核心的就是没有可靠的支持服务，没有人对其结果负责；
2、功能比较简单，支持复杂应用的负载均衡能力较差，如算法较少等；
3、开启隧道方式需重编译内核；
4、配置复杂；
5、主要应用于LINUX，目前没有专门用于WINDOWS的版本，不过可以通过配置，使windows成为LVS集群中的real server（win2003、win2008中）。
从以上大家可以大概了解下LVS集群，那么我可以先从什么是集群说起。
一般我们的集群都是建立在单个服务器不能单独完成任务的时候，会将服务器配置升级或者添加同样的服务功能的服务器。
因此这两种方法我们一般称为向上扩展和向下扩展
Scale up : 向上扩展或垂直扩展
使用性能更好的主机来代替现在性能较差的主机
向上扩展是相当不划算的扩展
Scale out : 向外扩展或横向扩展
将一台服务器扩展到多台服务器
director ：调度器
dispatcher ：分发器
load balancer ：负载均衡器
而今天我们讲的就是向外扩展，但是不一定向外扩展就一定是最佳的方法，具体要视现场来确定。
架设集群之前要先来衡量下系统的指标：
1、可扩展性
表明了需要增加资源以完成更多的工作任务时，能够获得的划算地等同提升
2、可用性
在单位时间内，大多数或绝大多数的时间内都是可用的
0-1， 百分比， 99% --> 99.9% --> 99.99% --> 99.999%
可用性一般用几个9来衡量其可用性，99.999%五个9现在已经是很高了
3、性能
性能指的是响应时间
4、容量
在一定时间内系统能完成的工作量，容量必须是可有效利用的
解释2，在保证可接受性能的情况下能够达到的吞吐量
只有当我们衡量过后的指标是提升比较明显的才好进行架设集群，否则不建议架设集群，因为没有明显的提升对于集群架设就没有意义了。
Linux的集群类型：
LB、HA、HP
LB：负载均衡集群
LB集群调度器的实现：
工作在协议层次来划分：
tcp层的调度器
根据请求报文中的目标地址和端口进行调度
应用层的调度器
根据请求的内容进行调度，而且此种调度为"代理"方式
软件的实现方法：
tcp: lvs (Linux Virtual Server),haproxy, nginx
应用层：
http: haproxy, nginx, apache(proxy module, balancer module), ats(apache traffic server), squid, varnish
mysql: mysql-proxy
硬件的实现方法：
硬件不一定是代表硬件，也可能是有人有卖此种设备，而且此种设备是经过优化的
公司：产品
F5: Big-IP
Citrix: NetScaler
A10: A10
Array: Array
RedWare
我们的LVS是通过传输层来完成的。
LVS组成部分：
两段
1、ipvs
工作在内核中的主体，真正的组件，被称为LVS的东西
ipvs工作在iptables的INPUT链上
2、ipvsadm
工作在用户空间为工作在内核中的ipvs服务的
LVS的工作与iptables类似，由ipvs工作在内核接受ipvsadm的编写配置文本来工作。
ipvs工作与netfilter的INPUT链
ipvsadm用于在ipvs上定义集群服务，同时也得定义此集群服务对应于有哪个后端主机可用
根据所指定的调度方法(算法)做出调度决策
支持的协议：TCP, UDP, SCTP, AH, ESP, AH_ESP
lvs中的常用术语约定：
Host:
Director : 调度器
Real Server : RS, 后端提供服务的主机
IP:
Client IP : CIP
客户端的IP地址
Directory Virtual IP : VIP
调度器对外的IP地址
Directory : DIP
调度器自己的IP地址
Real IP : RIP
后端提供服务的主机IP地址
lvs的类型：这次只说明负载均衡的集群
第一种类型 lvs-nat：
masquerade
第二种类型 lvs-dr:
direct routing
第三种类型 lvs-tun:
tuneling
第四种类型 lvs-fullnat:
fullnat
lvs-nat模型：类似于DNAT，但支持多目标转发, 就是多目标的DNAT
它通过修改请求报文的目标地址为根据调度算法所挑选出的某RS的RIP来进行转发
架构特性：
(1) RS应该使用私有地址，即RIP应该为私有地址,各RS的网关必须指向DIP
(2) 请求报文和响应报文都经由Director转发；高负载场景中，Director易于成为系统瓶颈
(3) 支持端口映射
(4) RS可以使用任意类型的OS
(5) RS的RIP必须与Director的DIP在同一网络
lvs-dr模型 ： 直接路由
Director在实现转发时不修改请求报文的IP首部，而是通过直接封装MAC首部来完成转发，目标MAC是Director根据调度方法挑选出的某RS的MAC地址
拓扑结构有别于NAT类型
架构特性：
(1) 保证前端路由器将目标地址为VIP的请求报文通过ARP地址解析后送往Director
解决方案：
1、静态绑定：在前端路由直接将VIP对应的目标MAC静态配置为Director的MAC地址，不靠谱也不常用
2、arptables：在各RS上，通过arptables规则拒绝其响应对VIP的ARP广播请求
3、内核参数：在RS上修改内核参数，并结合地址的配置方式实现拒绝响应VIP对ARP的响应请求
(2) RS的RIP可以使用私有地址，但也可以使用公网地址，此时可通过互联网上的主机直接对此RS发起管理操作
(3) 请求报文必须经由Director调度，但响应报文必须不能经由Director
(4) 各RIP必须与DIP在同一物理网络中，就是不能通过路由器转发否则会被修改MAC地址，可以通过交换机交换
(5) 不支持端口映射
(6) RS可以使用大多数的OS
(7) RS的网关一定不能指向Director
lvs-tun模型: 不修改请求报文的IP首部，而是通过IP隧道机制在原有的IP报文之外再封装IP首部，经由互联网把请求报文交给选定的RS
内层ip： CIP-VIP
外层封装的IP：DIP-RIP
架构特性：
(1) RIP, DIP, VIP 都是公网地址
(2) RS的网关不能，也不可能指向DIP
(3) 请求报文由Director分发，但响应报文直接由RS响应给Client
(4) 不支持端口映射
(5) RS的OS必须得支持IP隧道
tun模型的集群一般很少用到，应为架设麻烦，并且安全性比较低。
lvs-fullnat模型：通过修改请求报文的源地址为DIP，目标地址为RIP来实现转发，对于响应报文而言，是通过修改源地址为VIP，目标地址为CIP来实现转发
架构特性：
(1) RIP, DIP可以使用私有地址
(2) RIP和DIP可以不在同一网络中，且RIP的网关未必需要指向DIP
(3) 支持端口映射
(4) RS的OS可以使用任意类型
(5) 请求报文经由Director，响应报文经由Director
fullnat模型lvs并不能直接实现，fullnat模型与nat模型类似不过更高级更安全，是比较理想的模型。
lvs scheduler：lvs的调度方法
grep -i 'IPVS' /boot/config-*-*.x86.64
查看ipvs支持哪些类型与调度器
grep -i 'IPVS SCHEDULER' -A 12 /boot/config-*-*.x86.64
查看ipvs支持哪些调度方法
静态方法：仅根据算法本身实现调度
RR: round-robin, 轮流、轮询、轮叫、轮调
WRR: weighted round-robin, 加权轮询，权重越大分配到的请求越多
承载能力大的主机会承载更多的请求，通过Overhead=conn/weight来计算承载能力
SH: Source ip Hashing, 源地址哈希，把来自同一个地址的请求统统定向至此前选定的RS；有一个哈希表记录源地址与RIP，之后从哈希表查询记录，然后通过表来确定是否有过访问，如果没有就通过算法配置一个RS，然后添加到哈希表中，下次再过来直接查询哈希表来确定RS
DH: Destination ip Hashing, 目标地址哈希，把访问同一个目标地址的请求，统统定向至此前选定的某RS
动态方法：根据算法及后端RS当前的负载状况实现调度
LC: least connection, 时刻关注后台RS的活动连接数与非活动连接数，看哪个活动数值低就分配给哪个RS
Overhead=Active*256+Inactive
Overhead: 活动数值，越低越优先
Active: 活动连接
Inactive: 非活动连接
WLC: weighted least connection, 加权最少连接数
Overhead=(Active*256+Inactive)/weight
SED: Shorted Expection Delay, 最短期望延迟
Overhead=(Active+1)*256/weight
NQ: Never Queue, 永不排队，刚开始先每个RS分一个连接，然后接下来的根据算法来分配
LBLC: Local-Based Least Connection, 基于本地的最少连接， 动态方式的DH算法
LBLCR: Replicated LBLC, 带复制的LBLC
