只在虚拟机局域网下进行过测试，在服务器上我个人理解应该是把VIP设置成调度器的公网IP这样才能解析，就是不知道对不对，也没几台服务器供我测试一下。。
VS/NAT： 网络地址转换模式， 进站/出站的数据流量经过分发器（调度器）
1、由于NAT模式下，进出数据都在调度器进行，因此支持后端真实服务器数量较少
2、调度（Dip）和Vip需要工作在不同的网络中
3、所有的真实服务器的网关地址必须指向Dip
4、调度器需要双网卡，启用路由转发功能
下面是虚拟机实验步骤：
调度器：192.168.26.130
nginx1:192.168.26.129
nginx2:192.168.26.128
首先是调度器操作：
1.在网卡上添加一个IP
# ip addr add dev ens33 192.168.1.100/24（或添加一张物理网卡为桥接模式）2.开启路由转发
# vim /etc/sysctl.conf
net.ipv4.ip_forward = 1
# sysctl -p临时开启
# echo 1 > /proc/sys/net/ipv4/ip_forward3.安装ipvsadm并定义分发策略
# yum -y install ipvsadm
# ipvsadm -C //清除所有规则
# ipvsadm -A -t 192.168.1.100:80 -s rr-A 添加一个调度器
-s 指定调度算法 (rr是轮叫调度，调度算法的笔记在最后)
-a 向某个调度器添加一个真实服务器
-t TCP协议传输
-m 使用LVS-NAT模式
-r 真实服务器
# ipvsadm -a -t 192.168.1.100:80 -r 192.168.26.128 -m
# ipvsadm -a -t 192.168.1.100:80 -r 192.168.26.129 -m然后是后方真实web服务器的配置，必须指定网关为调度器的IP
1.安装nginx
.....
2.添加网关
# route add default gw 192.168.26.130如果没有route命令就安装一下
# yum install net-tools做负载均衡两台配置肯定是一样的了，我这里随便区分了下，然后使用和调度器VIP同一网段的客户端访问
# ipvsadm -L -n --stats
1. Conns (connections scheduled) 已经转发过的连接数
2. InPkts (incoming packets) 入包个数
3. OutPkts (outgoing packets) 出包个数
4. InBytes (incoming bytes) 入流量（字节）
5. OutBytes (outgoing bytes) 出流量（字节)
以上为LVS的NAT模式简单测试。
VS/NAT模式的原理是：当调度器收到Client请求时，调度器将数据包的目标IP由VIP转换为选中的Real Server的RIP来实现分发，要求RS将网关指 向调度器的DIP。
特点是：配置简单，所有的入站、出站数据包都经过分发器。当数据量比较大时，分发器可能会出现网络瓶颈！因而支持的RS数量少。
VS/DR： 直接路由模式，只有进站的数据流量经过分发器
调度器和真实服务器必须在同一网段
VS/DR模式的原理是： 当一个client发送一个请求到VIP，调度器根据VIP，在后端真实服务器中选择一台Real-server，然后将client的请求包发给选择的Real-server，最后选择的Real-server把应答包直接传给client。
特点：解决了lvs-NAT模式下调度器瓶颈问题。
以下为实验操作步骤：
调度器：192.168.26.130
nginx1:192.168.26.129
nginx2:192.168.26.128
两台RS服务器：
# ip addr add dev lo 192.168.26.123/32
//在lo接口上绑定VIP
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
//non-arp：避免出现IP冲突
# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
//RS以适当IP传输数据（让RS用VIP回复数据）因为LVS和real server都配置了VIP，client或者网关设备都可能arp学到LVS和real server的mac，也就会发生IP冲突，且无法实现负载均衡功能。为了避免这种情况发生，可通过内核参数arp_ignore和arp_announce的配置，只允许LVS应答VIP的arp请求，抑制real server应答VIP的arp请求和发送免费arp。（抑制ARP还可使用arptables）
nginx的配置过程就略过了，随便改点加以区分就行
调度器操作：
# ip addr add dev lo 192.168.26.123/32
# yum -y install ipvsadm
# ipvsadm -C
# ipvsadm -A -t 192.168.26.123:80 -s rr
# ipvsadm -a -t 192.168.26.123:80 -r 192.168.26.129 -g
# ipvsadm -a -t 192.168.26.123:80 -r 192.168.26.128 -g
# ipvsadm -Ln
LVS调度算法：
调度算法用于决定LVS如何选择后端的RealServer
1. 轮叫调度（Round Robin）(简称rr)
调度器通过“轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
2. 加权轮叫（Weighted Round Robin）（简称wrr)
调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器能处理更多的访问流量。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
3. 最少链接（Least Connections）(LC)
调度器通过“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用 “最小连接” 调度算法可以较好地均衡负载。
4.加权最少链接（Weighted Least Connections）(WLC)
在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少链接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负
载。调度器可以自动问询真实服务器的负载情况，并动态地调整其权值。
LVS的默认调度算法。
5. 基于局部性的最少链接（Locality-Based Least Connections）(LBLC)
“基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。该算法根据请求的目标IP地址找出该目标IP地址最近使用的
服务器，若该服务器是可用的且没有超载，将请求发送到该服务器；若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少链接”
的原则选出一个可用的服务器，将请求发送到该服务器。
6. 带复制的基于局部性最少链接（Locality-Based Least Connections with Replication）(LBLCR)
“带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统。它与LBLC算法的不同之处是它要维护从一个目标
IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按
“最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台
服务器，将该服务器加入到服务器组中，将请求发送到该服务器。同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复
制的程度。
7. 目标地址散列（Destination Hashing）(DH)
“目标地址散列”调度算法根据请求的目标IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
8. 源地址散列（Source Hashing）(SH)
“源地址散列”调度算法根据请求的源IP地址，作为散列键（Hash Key）从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。
9. 最短的期望的延迟（Shortest Expected Delay Scheduling SED）(SED)
基于wlc算法。这个必须举例来说了
ABC三台机器分别权重123 ，连接数也分别是123。那么如果使用WLC算法的话一个新请求进入时它可能会分给ABC中的任意一个。使用sed算法后会进行这样一个运算
A(1+1)/1
B(1+2)/2
C(1+3)/3
根据运算结果，把连接交给C。
10.最少队列调度（Never Queue Scheduling NQ）(NQ)
无需队列。如果有台 realserver的连接数＝0就直接分配过去，不需要在进行sed运算
