LVS：Linux Virtual Server
所谓虚拟的服务就是，当客户端请求服务时，将服务在前端调度器上，通过一定方式负载到后端多台服务器上，但对于客户端来说是不可见的，像在访问同一台服务器一样，这就是虚拟的意思
原理
ipvs：使用LVS服务时，在linux内核当中的一个过滤框架，作用在Input链上，通过解析用户请求的ip和端口号，判断是否是集群服务（若较老的版本内核中没有内置则需自行编译安装）
当用户请求到达，进入调度器内核空间，由于请求的是本地地址，转发到Input链，通过请求的ip和端口，判断请求的服务是否是集群服务，若不是则根据端口号进入用户空间访问本地服务，是的话将请求报文在Input链上进行处理，转发到FORWARD链，最后到达POSTROUTING链，转发到相应的后端服务节点
所以LVS和iptables不能同时使用
ipvsadm：是LVS在用户空间对集群服务进行管理的工具
调度算法实现负载
Scheduler Method（调度方法）：当客户端请求到达时，调度器以什么标准选择后端较为合适的服务器节点进行请求分发
两种类型调度
静态调度：不考虑后台服务器的连接负载情况
rr（Round Robin ）：轮询
wrr：weight 加权轮询，在轮询之前，计算各服务器权重的比例，再进行调度
sh：source hash 源地址哈希：记录客户端的哈希和对应服务器，下次来自同一主机的请求将根据之前的记录，分配相同的服务器节点处理
cookie和session：客户端第一次发起访问时，服务端发送cookie给客户端，客户端保存cookie，之后每次请求都会附加cookie信息，服务端以此对客户端进行标识，并在服务器端的内存内部保存有用户浏览的记录、url等信息，这就是session
session share：服务集群后端服务节点间session 共享（通过网络，或同步到共享存储当中），这样的话客户端的浏览记录等信息就实现了共享，即使客户请求被分配到不同的节点，即使服务器节点故障，浏览信息是同步的。若是session shared，则不需要这种调度算法，当服务器发生故障，session share也是很好的预防措施
dh：destination hash 目标地址哈希（针对缓存服务器，第一次请求获得的缓存可能其他的缓存服务器没有缓存，请求同样的内容时，分配到相同的缓存服务器，无需再次缓存）
动态调度
lc：最少连接
比较后端realserver的 active*256+inactive，挑选值小的发送请求
wlc：加权最少连接（lpvs默认）
比较后端realserver的 （active*256+inactive）/ 权重，挑选值小的发送请求
sed：shortest expect delay 最短期望延迟
（active+1）*256/ weight
nq：never queue 永不排队
在sed基础上第一次无论如何每台服务器都发送一次请求
LBLC：Locality-Based lc 基于本地最少连接
考虑 cache 连接数，但相同的请求尽可能发送给同一个缓存服务器，相当于动态的 dh
LBLCR：LBLC with Replication Scheduling 带缓存复制功能
LBLC会考虑最小连接数，但还是会对相同用户请求分发到相同后端缓存服务器，而LBLCR直接对后端的缓存服务器动态调度，并且缓存共享（指部分共享，当请求的缓存服务器没有缓存时，而另外的服务器有，则同步请求的缓存内容）
LVS三种模式：
NAT：地址转换
DR：直接路由
TUN：隧道模型
NAT模型
实现原理：客户端发起请求，请求到达Director负载均衡器后，根据调度算法，选择适当的后端服务节点进行请求分发，Director再利用返回结果对客户端做出响应，实现负载均衡
规则：
集群节点跟director必须在同个网络中
RIP通常是私有地址，仅用于集群节点间通信
director处于client和Realserver之间，负责处理进出的所有通信
realserver必须将网关指向DIP
以下为一个简单的实验和注意的点
1：地址规划
2：安装ipvsadm
3：查看是否支持ipvs内核功能
4：注意Director和Realserver间的时间同步
5：注意ipvsadm和iptables的使用不可以共存，因为使用的都是netfilter框架的过滤机制
6：地址配置：
Direct两个网卡分别面向内网和外部网络，虚拟机模式下，内部网络应使用host-only模式
Realserver网关因指向Direct的内网地址
7：开始配置lvs（使用rr轮询调度）
-t使用tcp协议的集群，-s指定调度算法，-r指定realserver，-m指定为nat模型
8：查看配置
9：测试
RS1网页内容为：This is Realserver1
RS2网页内容为：This is Realserver2
从结果看出已实现轮询调度功能
若外部主机测试不成功，可能是网卡转发功能没有启动
10：查看连接状态
11：修改调度算法为（wrr加权轮询，并验证）
效果
DR模型
首先，DR模型相对于NAT模型的好处在于Director只接收请求并转发给 Real server，不响应请求，大大增强性能
实现原理：Director和Realserver都配有VIP地址和自身的网卡地址，客户端发起请求，ip报头的源目地址为CIP和VIP，Direct接收到报文后，发现请求的是集群服务，将不改变ip以上的报文数据，源目地址还是CIP和VIP，直接将MAC地址改为Direct MAC和RS MAC，将报文转发给Realserver，Realserver收到报文后，接收请求，生成响应报文，并直接做出响应
流程：
为了实现以上的解决方案，需要解决以下两个问题
1：Director和Realserver都配有VIP地址，若同个网络中有很多个相同的ip地址，将会造成ARP混乱，而我们只需要通告Director的VIP即可
利用arp的通告响应级别机制
arp_announce
级别0：默认级别，本地任何接口地址全部通告
级别1：尽可能不通告和对方网络地址不相同的地址
级别2：不通告和对方网络地址不相同的地址，如：本地的eth0和lo口配的是不同的地址，lo口的地址将不会通告到eth0接口连接的网络中
arp_ignore
级别0：默认级别，本地有的，都给予响应
级别1：只有在请求的地址配置在请求到达的接口上时才给予响应
可以将VIP设置在Realserver的Lookback口，不做通告和响应
同时Director的VIP可设置在eth0:0上，正常的回复arp请求
或者若对出口路由有控制权的时候，对于VIP直接指静态路由到Director即可
2：Realserver收到报文后，做出响应，此时源目ip为VIP和CIP，报文如何到达Client
一般情况下，CIP为公网ip，是网络上客户端的ip，VIP也为公网ip，当RIP和VIP不在同一个网段中时，为了让响应报文正常发送，须将Realserver的网关指向出口设备（可能是运营商设备），RIP可以是私网地址，也可以是公网地址
规则
各集群节点和director必须在同一个物理网络中
RIP可以使用公网地址，实现便捷的网络管理
director只接收请求，通过real直接响应客户请求
不支持端口映射
要求能隐藏 vip 的操作系统作为realserver
能比nat模型支持更多的节点
实验（利用内部网络做简单模拟，出口路由设备非运营商设备的情况下）
实验规划：
1：按照规划先配好地址，实验环境下地址都应为桥接模式
2：Realserver应先配置arp的响应级别再配置Lo口的VIP地址，还要设置
echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
ifconfig lo:0 192.168.199.133 netmask 255.255.255.255 broadcast 192.168.199.133 up #广播地址为VIP地址，指网络中只有本身一个地址
route add -host 192.168.199.133 dev lo:0 #默认路由表示在当请求的是192.168.199.133这个VIP地址时，进行响应时应该通过lo:0出去，即响应时的ip为VIP而不是eth0的ip
3：在Director上的配置
ifconfig eth0:0 192.168.199.133 netmask 255.255.255.255 broadcast 192.168.199.133 up
router add -host 192.168.199.133 dev lo:0
本文出自 “Call me Boxin” 博客，请务必保留此出处http://boxinknown.blog.51cto.com/10435935/1672206
原文地址：http://boxinknown.blog.51cto.com/10435935/1672206
