背景：
Load Balancing Cluster：
tcp: lvs
应用层: nginx, haproxy, apache, lighttpd, varnish, squid
扩容：
scale up
scale out
需要：
lvs: 内核空间
应用层：用户空间，因为能理解 应用层协议，能实现基于该协议的 精细化管理。 例如：
动静分离、后端主机健康状况检查
选择：根据需求 选择 BL Cluster
LVS: Linux Virtual Server
概念：
是一段 内核代码，类似于 netfilter ，
工作在内核中，只是一个框架，本身并不提供 功能 ，这个框架 提供了 能够 根据用户提供的转发 规则，将用户对于 服务应用的请求 转发到后端主机
根据用户 请求的服务器，在内核 中 判定（根据rules），如何 进行转发，转发到 那个 后端主机
名称由来：
LVS 一般不 运行 任何 Web 服务，但 却告诉 用户 我这有 某个服务 ，而是 将用户请求转发至 后端主机 ，因此被叫做VS
关键字：
内核代码: 框架，TCP/IP， tcp/udp
IP:Port, 集群服务
DNAT：目标地址 ，在LVS出去之前 可以 DNAT 多台主机，但是LVS 出现之后 ，DNAT 就只能 DNAT 1台 主机了
类似于netfilter
服务器术语：
调度器：Director, Dispatcher, Load Balancer
RealServer:
报文传输过程IP:
CIP :Client IP
VIP:Virtual Server IP
DIP:Director IP
RIP:Real Server IP
CIP<-->VIP<-->DIP<-->RIP
LVS调度算法抛砖：
rr: Round-Robin，轮叫,轮调
wrr: Weighted Round-Robin, 加权轮叫
图形描述：
LVS 工作机制：
LVS：章文嵩
iptables/netfilter
ipvsadm/ipvs
因为 netfilter 和ipvs 都要使用 LOCAL IN，FORWARD 这2个 HOOK, 在这2个点上不能同时存在规则
LVS 工作点特性
IP:Port （
L4 Switch, L4 Router）
四层交换，四层路由
交换机：以 MAC地址 进行报文转发 工作在 2层：数据链路层
路由器：以 IP地址 进行报文转发 工作在 3层：网络层
LVS：以 IP:Port 进行报文转发 工作在 4层：传输层 ,
类似于 路由器/交互机,所以叫做：
L4 Switch, L4 Route
LVS类型：
lvs-type：
NAT:
DR
TUN
FullNAT
NAT:
1、RealServer应该使用私有IP地址；
2、RealServer的网关应该指向DIP；
3、RIP和DIP应该在同一个网段内；
4、进出的报文都得经过Directory，在高负载下，Directory会成为系统性能瓶颈；
5、支持端口映射；
6、RealServer可以使用任意OS；
用途：由于 上面第4条，使得 其扩展受限 ，所以 这种type 很少使用
DR: Direct Routing
1、RealServer可以使用私有地址；
2、RealServer的网关一定不能指向DIP；
3、RealServer和Director要在同一物理网络内；DIP和RIP应该在同一网段；
4、入站报文经过Directory，出站则由RealServer直接响应Client；
5、不能做端口映射；
6、RealServer可以为大多数常见OS；
用途：改进了 NAT的 扩展问题，但是引入了 设置的 物理限制（同一机房）
TUN：Tunneling
1、RIP、DIP不能是私有地址；
2、RealServer的网关不能指向DIP；
3、入站报文经过Directory，出站则由RealServer直接响应Client；
4、不支持端口映射；
5、支持IP tunneling的OS才能用于RealServer；
6、Real Server 和 Director 不用在 同一个物理网络内
NAT(DNAT):
请求进来时：DNAT 人为设定 destination IP ，在LOCAL IN上进行NAT
请求出去时：SNAT LVS设定 source IP , 在FORWARD 上进行NAT
请求出去时：SNAT LVS设定 source IP , 在FORWARD 上进行NAT
DR: Direct Routing
响应过程不经过Director
客户端 访问的是VIP ，响应 不经过Director，就能 回到客户端 ，那么 Real Server 必须 能够 构建 VIP为源IP 地址的响应报文，怎么实现？
Director 提供2个网卡： VIP DIP
Real Server 提供2个网卡： RIP VIP
通过上面设置 我们可以让 Real Server 构建以VIP 的响应报文
路由器发现 要访问的VIP 在自己网段内，把报文接过来，然后动态ARP ,寻找VIP 的MAC地址 找到后 用该MAC封装报文，交给交换机，但是Director 、RealServer 都有VIP ，怎么才能让 Director 顺利接到报文，然后Load Balancing？
A. 路由器 设置使用静态ARP 绑定 VIP为Director MAC地址,这样路由器就不用ARP广播了，直接将报文 指定给 Director
B. 利用红帽 提供的 arptables ，使Real Server 拒绝响应 Router的 动态APR 广播。这样Router 仅能得到 Director MAC
C. 在 linux 2.6.4 之后，直接引进了2个参数 ，这2个参数 可以设定 主机路由响应方式：
1.只有APR广播经过的 网卡才响应ARP请求
1.只有APR广播经过的 网卡才响应ARP请求
2.直接接入的网络 的 网卡 才通告（ARP)该网络 IP:MAC ,那么不在 该网络的网卡 就不用做ARP通过
借用这种机制，我们可以这样屏蔽掉 Real Server 回应 Router对于VIP的动态ARP广播：
Real Server ： RIP eth0
VIP lo:0
并且让VIP 不在RIP 的网段上 ，那么 RIP 接入网络 ，只会通报 RIP 的MAC地址，而VIP 的MAC 地址 就不会通报了，而且Router 的ARP 广播报文 是通过 eth0 进入 本机的 ，因此lo:0也不会 回应 此次 ARP的
以上3种办法 都能达到： 仅让Director 会响应 Router的 关于VIP 的动态ARP 广播请求
报文交给了 Director ，但是 Director 要怎么 把报文转给 Real Server ，才能是 Real Server 构建响应报文时 使用VIP喃？
显然 不能以 目标地址为：RIP 的方式 给 Real Server 因为 访问的目标，才是 构建响应的 源（意思就是，我要访问 VIP ,你就得以 VIP 的身份 回应我）
所以 ，Diretor 转交报文 给 Real Server 时 ，必须 以VIP 为 目标 IP ，
并且 Diretor 对报文的做如下动作：修改 报文的目标MAC 为 Real Server MAC，确保报文送到的是 Real Server
Real Server 收到报文，发现目标MAC为自己 ，拆掉MAC , 发现 目标IP 为 VIP ，也是自己， 于是再拆 TCP 首部 交给 应用层服务， 最后响应报文 需要以 报文出去的 网卡 为 源IP 地址 构建响应报文（linux内在机制： 报文从哪个网卡离开，就把哪个网卡作为 源地址），但是 lo:0 是出不去的 ，只能从 eth0:出去，难道 又只能以 eth0:上的 RIP 构建响应报文吗？
强行定义 路由规则，明确告诉linux： 只要访问目标为 VIP 那么响应的 源IP 就必须是VIP
响应
报文从eth0出来后 交给的下一个 主机 ，那么 下个主机一定是 eth0（RIP)的网关。
由于RIP 与 VIP 不能同网段 ，那么VIP的网关 一定 不能与 RIP 的网关 为同一网关
由于RIP 与 VIP 不能同网段 ，那么VIP的网关 一定 不能与 RIP 的网关 为同一网关
注意：
因为Director 把报文给 Real Server时 ，使用的MAC 地址通信 （因为使用IP通信，那么又要ARP广播，那样得到的又是Director的VIP MAC地址），所以 DIP 与 VIP 必须在 同一个 物理网络内（同机房）
TUN：Tunneling
IP首部： 源IP:CIP 目标IP:VIP
伪IP首部: 源IP: DIP 目标IP: RIP
通过在 DIP 和 RIP 直接 搭建一个 IP 隧道 来 传输正在的报文，虽然RIP是中转站，但是 RIP与VIP 在同在 Real Server上，这样也是目的地了
FullNAT：
