NAT和DR都有距离的限制，必须在很近的距离内，因为双绞线的限制(私网地址必须在同一个物理网络)
接上次课课件：
lvs-tun：---RS不在同一个机房，所以不需要做拒绝arp广播和响应，这种模型应用不多(有个问题，巨型帧---客户端请求数据超过mtu)
转发方式：不修改请求报文的IP首部(源IP为CIP，目标IP为VIP)，而是在原IP报文之外再封装一个IP首部(源IP是DIP，目标IP是RIP)，将报文发往挑选出的目标RS；RS直接响应给客户端(源IP是VIP，目标IP是CIP)；
(1)DIP,VIP,RIP都应该是公网地址；
(2)RS的网关不能，也不可能指向DIP；
(3)请求报文要经由Director，但响应不能经由Director；
(4)不支持端口映射；
(5)RS的OS得支持隧道功能；
lvs-fullnat：---非标准类型
通过同时修改请求报文的源IP地址和目标IP地址进行转发；
CIP<-->DIP
VIP<-->RIP
(1)VIP是公网地址，RIP和DIP是私网地址，且通常不在同一IP网络；因此，RIP的网关一般不会指向DIP；
(2)RS收到的请求报文源地址是DIP，因此，只能响应给DIP；但Direcotr还要将其发往Client；
(3)请求和响应报文都经由Director；
(4)支持端口映射；
注意：此类型默认不支持；
总结：
lvs-nat,lvs-fullnat:请求和响应报文都经由Director；
lvs-nat：RIP的网关要指向DIP；
lvs-fullnat：RIP和DIP未必在同一IP网络，但要能通信；
lvs-dr,lvs-tun：请求报文要经由Director，但响应报文由RS直接发往Client；
lvs-dr：通过封装新的MAC首部实现，通过MAC网络转发；
lvs-tun：通过在原IP报文之外封装新的IP首部实现转发，支持远距离通信；ipvs scheduler：
根据其调度时是否考虑各RS当前的负载状态，可分为静态方法和动态方法两种：
静态方法：仅根据算法本身进行调度；---一般短链接使用这种调度方法
RR：roundrobin，轮询；
WRR：Weighted RR，加权轮询；---有的服务器计算能力比较强,会虚拟出几台服务器的能力
SH：Source Hashing，实现session sticy(黏性)，源IP地址hash；将来自同一个IP地址的请求始终发往第一次挑中的RS，从而实现会话绑定；---用户第一次访问，一般是加权轮询，在内存建立一个hash表，以源IP为键，以RIP为值---有个问题，server down了，session也就丢了，而且lvs工作在四层，不能进行cookie绑定
DH：Destination Hashing；目标地址哈希，将发往同一个目标地址的请求始终转发至第一次挑中的RS，典型使用场景是正向代理缓存场景中的负载均衡；
动态方法：主要根据每RS当前的负载状态及调度算法进行调度;---适用于长连接---非活动连接对资源的依赖很少很少，重量是活动连接的256分之一
Overhead=负载值
LC:least connections---最少连接，谁小就挑选谁
Overhead=activeconns*256+inactiveconns
WLC:Weighted LC---加权最少连接，谁重就选谁，默认算法，有问题，刚开始没有连接，恰好轮询时第一台性能最差
Overhead=(activeconns*256+inactiveconns)/weight
SED:Shortest Expection Delay---最短期望延迟
Overhead=(activeconns+1)*256/weight
NQ:Never Queue不排队保证每个server都有链接
LVLC:Locality-Based LC，动态的DH算法；如果没有绑定，不是轮询而是根据后端服务器的负载来调度
LBLCR:LBLC with Replicaion，带复制功能的LBLC；两个缓存服务器之间允许缓存协议的共享ipvsadm/ipvs：---ipvs是内核的直接功能，只要内核编译时开启此功能就能用，ipvsadm是用户空间工具，只要装安装包就能用，不需要监听任何服务和端口
集群和集群之上的各RS是分开管理的；
集群定义
RS定义
ipvs：
~]#grep -i "ipvs" -C 10 /boot/config-VERSION-RELEASE.x86_64---从这个内核编译信息配置模板的上下文中查找关键字的上下10行
支持的协议：TCP，UDP，AH，ESP,AH_ESP,SCTP;---都是四层协议
ipvs集群：
集群服务
服务商的RS
yum info ipvsadm---查看这个包信息
正向代理：代表客户端发出请求的
反向代理：代表服务端提供服务的
原文：https://blog.51cto.com/13852573/2364126