友情提醒：实验环境为：Centos 6.6 x86_64 + vmware workstation 10
内容概括：
1)LVS的点滴汇总
2)实现LVS-nat模型
3)实现LVS-DR模型
一 LVS的点滴汇总
LVS是Linux Virtual Server的简称，基于IP和端口的负载均衡软件。该开源项目的发起者和主要开发者为章文嵩博士。
1.1)LVS的组件：
有2部分组成：
ipvs：工作在内核空间netfilter/iptables框架的input链上。
ipvsadm：工作在用户空间的一个命令工具，主要用于复制均衡规则的定制和管理
ipvsadm定义好集群服务和负载均衡规则后，ipvs在input链上截取相应端口和目标地址的服务包，改写目标地址，通过forward，postrouting链发往后端的真正提供服务的主机。
iptables规则和ipvsadm定义的规则不能共存。
1.2)LVS支持的协议：
目前支持：tcp/udp/sctp/ah/esp/ah_esp
1.3)术语约定：
主机类：
Director：调度器，做为网络构架的唯一入口。
Real Server：简称RS，隐藏于后端提供服务的真正主机。
IP类：
用户(cip)<--->(vip)LVS-Director(dip)<---->(rip)real server
1.4)LVS的工作模型由四种：
lvs-nat: 后端real server真正隐藏，接受和返回给客户端的数据包均需经由 lvs-Director转发，
后端realserver 与 lvs要求在同一个物理局域网内。
lvs-dr: Lvs-Director接受客户端的请求数据包，给返回给客户端的应答包由后端realserver直接返回，后端realserver与lvs要求在同一个物理局域网内。
lvs-tun: Lvs-Director接受客户端的请求数据包，给返回给客户端的应答包由后端realserver直接返回，后端realserver与lvs不在同一个物理局域网内，可以夸地域实现。
lvs-fullnat: 这个目前不是LVS标准模型，由阿里巴巴集团开发人员研制出的一种新型结构，是lvs-nat模型的改进型，Lvs-Director与realserver可以跨路由器协同工作。
1.5）LVS的调度方法：
静态方法：调度时仅根据算法本身实现调度，而不管后端realserver的负载情况,追求的是起点公平。
RR:round-robin，轮询。
根据配置lvs-director指定的realserver的次序，挨个来应答请求。
存在的问题是：不论realserver性能的高低而得到同等的待遇，没有发挥出高性能realsever的能力。
WRR：weighted round-robin，加权轮询：给lvs一个权重值，值越大承受越多。
计算方法：overhead=conn/weight
在配置director上配置realserver时，指定了每个realserver的权重值，比如第一realserver 权重 1 ，第二个realserver的权重为4，那么前5个连接请求第二个realserver占据4个后第一个realserver才占据1个，二者之间始终保存1:4的关系。
存在问题：可能会出现这种场景：第二个realserver上的4个链接都没有断开，而第一个realserve上的唯一的一个连接处理完毕已经空闲，而第二个realserver还在处理4个连接。新来了5个连接，第二个realserver分的4个，第一个realserver分的1个。此时第二个realserve上有8个连接要处理，而第一个realserve上只需处理1个链接。
RR与WRR，算法的优点是其简洁性，它无需记录当前所有连接的状态，是一种无状态调度，不管服务器的当前连接数和响应速度。
DH：destination ip hashing，目标地址散列调度，特殊场景中使用，例如有多出口时。
该算法是针对目标IP地址的负载均衡，通过散列（Hash）函数将目标IP地址与后台Realserver组成key：value对应关系的散列表，根据请求包文的目标IP地址，作为键（Hash
Key）从静态分配的散列表找出对应的缓存或出口服务器。
SH：source hashing，源地址哈希，来源相同的主机始终发向同一个realserver实现会话绑定。
它采用的散列函数与目标地址散列调度算法
的相同。除了将请求的目标IP地址换成请求的源IP地址外，它的算法流程与目标地址散列调度算法的基本相似。在实际应用中，源地址散列调度和目标地址散列
调度可以结合使用在防火墙集群中，它们可以保证整个系统的唯一出入口。
动态方法：根据算法及后端RS当前的负载状况实现调度 。根据overhead值挑选最小的realserver进行应答响应。
LC：least connection
计算方法：overhead=Active*256+Inactive
这种调度算法分配连接时根据overhead和在realserver上的顺序来分配连接的。连接来临时overhead小的分的连接，若overhead相同，按照在director上的realserve顺序来分配。
WLC:weighted least connection
计算方法：overhead=(Active*256+Inactive)/weight
wlc是lc的改进，在分配连接时增加了weight值，使得权重大的realserver分的连接数增加。可以给性能高的realserver配置合理的权重值，使其发挥更大的能力。当权重设计不合理，会出现权重高的机器忙死，权重低的机器闲死。wlc是默认的调度方式。
SED:Shorted Expection Delay，最短期望延迟
计算方法：overhead=(Active+1)*256/weight
SED虽是wlc的改进，但是并没有克服权重设置不合理带来的缺陷：当权重设计不合理，会出现权重高的机器忙死，权重低的机器闲死。
NQ:Never Queue ，永不排队
NQ是SED的改进，初始时让每个realserver根据权重分的一个连接，而后按照SED的overhead的计算公式，决定下面的连接分配情况。
LBLC:基于本地的最少连接 Local-Based Least Connection
动态方式的DH算法
将去往相同地址的连接定向到同一个出口上，若在出口上设定有缓存服务器，这能提高cache命中率。当出口server负担过重时也会定向至另外的server上，虽然这降低了命中，破坏lvs的初衷。
LBLCR:带复制的LBLC
出口服务器上配置有缓存功能，将去往某些域名的连接出口定向至1号server上，这样提高cache命中，当1号负担过重时，将部分连接调至2号server上，同时将cache中的内容也复制一份给2号server。
1.6）ipvsadm命令的使用格式：
安装命令：#yum -y install ipvsadm
用法：
管理集群服务:创建，修改,删除
#ipvsadm -A|-E -t|-u|-f service-address [-s scheduler]
#ipvsadm -D -t|-u|-f service-address
-A:创建
-E:修改
-D:删除
-t:tcp,后面的service-address的格式：vip:port,如：192.168.0.1:80
-u:udp,后面的service-address的格式：vip:port,如：192.168.0.1:80
-f:承载协议为tcp或udp，但该类报文会经由iptables/netfilter打标记，即防火墙标记，其service-address的格式“FWM",例如 "10"
-s scheduler:指定算法。默认为wlc
管理集群服务的RS:添加，修改，移除
#ipvsadm -a|-e -t|-u|-f service-address -r server-address [-g|-i|-m] [-w weight]
#ipvsadm -d -t|-u|-f service-address -r server-address
#ipvsadm -C
-r server-address:指明Real Server，格式：ip[:port],如：192.168.1.1:80
-g:指明lvs类型为 lvs-dr，默认类型。
-i:指明lvs类型为 lvs-tun
-m:指明lvs类型为lvs-nat
-w weight:指定权重。
-d:删除已定义的realserver
-C:清空已定义的ipvsadm的规则
规则存取：
保存规则：
#service ipvsadm save
-->规则保存至/etc/sysconfig/ipvsadm
#ipvsadm -S > /etc/sysconfig/ipvsadm
#ipvsadm-save > /etc/sysconfig/ipvsadm
读取规则：
#service ipvsadm restart
#ipvsadm -R < /etc/sysconfig/ipvsadm
#ipvsadm-restore</etc/sysconfig/ipvsadm
规则和统计数据查看:
#ipvsadm -L -n [option]
#ipvsadm -Z
-L 显示规则
-n 数字表示
-Z 情况数据统计值
option：
-c 显示当前的活动链接分配
--stats 显示统计数据
--rates 列出速率
--exact 显示精确值
二 Lvs-Nat模型的实现：
2.1)Lvs-nat模型下数据包ip头地址的转换
请求包头：client(cip,vip)--->lvs(dip)-->(cip,rip)-->realserver
响应包头： client(vip,cip)<---lvs(dip)<--(rip,cip)<--realserver
2.2) Lvs-nat架构特性：
(1):rip为私有地址，vip为公网地址
(2):read sever网关指向dip，rip与dip在同一网段中。
(3):请求和相应报文都经由Director转发，lvs在高负载场景下成为系统同瓶颈。
(4):lvs必须为linux，real server可以是任意OS
2.3)实验环境：
| 主机 | 角色 | IP地址 |
| Test01 | LVS Director | vip：192.168.100.1 [vmnet8] dip：172.16.0.1 [vmnet3] |
| Test02 | LVS realserver,提供简单的web服务 | rip:172.16.0.2 [vmnet3] |
| Test03 | LVS realserver,提供简单的web服务 | rip:172.16.0.3 [vmnet3] |
| win7 | 客户机，发起web请求 | cip:192.168.100.100 [vmnet8] |
实验拓扑图：
2.4)实验步骤：
2.4.1) 网卡桥接，I地址设定和相应的web服务
设定Test02：
[root@Test02 ~]# service iptables stop [root@Test02 ~]#setenforce 0 [root@Test02 ~]#yum -y install httpd [root@Test02 ~]#ip addr add 172.16.0.2/24 dev eth2 [root@Test02 ~]#touch /var/www/html/index.html [root@Test02 ~]#echo "<h1>privateli-Test02,web station,172.16.0.2 is my address</h1>">/var/www/html/index.html [root@Test02 ~]#service httpd start #实际中相同端口的集群服务内容应该一致，但在这个实验中为了测试效果，故设定web内容不一致。
设定Test03：
[root@Test03 ~]# service iptables stop [root@Test03 ~]#setenforce 0 [root@Test03 ~]#yum -y install httpd [root@Test03 ~]#ip addr add 172.16.0.3/24 dev eth2 [root@Test03 ~]#touch /var/www/html/index.html [root@Test03 ~]#echo "<h1>privateli-Test03,web station,172.16.0.3 is my address</h1>">/var/www/html/index.html [root@Test03 ~]#service httpd start #实际中相同端口的集群服务内容应该一致，但在这个实验中为了测试效果，故设定web内容不一致。
设定Test01：
[root@Test03 ~]# service iptables stop [root@Test03 ~]#setenforce 0 [root@Test03 ~]#ip addr add 172.16.0.1/24 dev eth2 [root@Test03 ~]#ip addr add 192.168.100.1/24 dev eth1 [root@Test03 ~]#
2.4.2)路由设定：
用为是LVS-NAT模型，需要realserver的 rip网卡的网关设定为Directory的dip
[root@Test03 ~]# ip route add default via 172.16.0.1 [root@Test02 html]# ip route add default via 172.16.0.1
2.4.3)Lvs-director Test01上启动ipv4数据包转发：
[root@Test01 ~]# echo 1 >/proc/sys/net/ipv4/ip_forward
2.4.4）lvs-director上设定服务：
#安装ipvadm工具
[root@Test01 ~]# yum -y install ipvsadm
#设定集群服务：
[root@Test01 ~]# ipvsadm -L -n IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn [root@Test01 ~]# ipvsadm -A -t 192.168.100.1:80 -s rr [root@Test01 ~]# ipvsadm -a -t 192.168.100.1:80 -r 172.16.0.2:80 -m [root@Test01 ~]# ipvsadm -a -t 192.168.100.1:80 -r 172.16.0.3:80 -m [root@Test01 ~]# ipvsadm -L -n IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn TCP 192.168.100.1:80 rr -> 172.16.0.2:80 Masq 1 0 0 -> 172.16.0.3:80 Masq 1 0 0 [root@Test01 ~]#
2.4.5)win7 上测试效果
再次刷新：
三 LVS-DR模型的实现：
3.1)LVS-DR模型下数据包IP头部和帧的转换：
请求包文IP头部：
client->(cip,vip)->Director->[MAC-DIP,MAC-RIP](cip,vip)--->(rip)realserver-->(lo:0 vip)realserver
响应报文的IP头部：
client<--(vip,cip)<---(rip)realserver<--(vip,cip)---(lo:0vip)realserver
3.2)构建特性：
(1):保证前端路由器将目标地址为vip的请求报文通过ARP地址解析送往Director
解决方案：
静态绑定：前段路由直接将VIP对应的mac地址静态配置为director的mac地址
artables：在各RS上,通过arptables规则拒绝其响应对vip的arp广播地址请求
内核参数：在RS上修改内核参数，并结合地址的配置方式实现拒绝响应对vip的arp广播请求
(2):RS的rip可以使用私有地址，也可使用公网地址
(3):请求报文必须经由director调度，但响应报文必须不能经由director
(4):各RIP必须与DIP在同一个物理网络中
(5)：不支持端口映射
(6):RS可以使用大多数的OS
(7):RS的网关一定不能指向Director
3.3)部署要点:
(1)各RS直接回应client的请求，因此，各RS均得配置VIP，不然客户端收到的数据包源地址不是vip，则会丢弃收到的数据包。
(2)Director不会修改/拆除请求报文的IP首部，而是
通过封装新的帧首部（源MAC为director的dir
端口的MAC，目标mac为rs的rip端口的mac）
Director的vip地址配置在dir网卡的别名上。
(3)RS上vip配置在lo网卡的别名上若lo:0,并配置有arp应答抑制；只有Director上的vip参与本地路由通 信，也就是参阅arp应答。
(4)linux上配置的IP地址属于内核的而不是网卡， linux上响应报文从哪个接口出去就封装该接口的IP源IP
因此，需设定RS上相应报文的从lo别名网卡（也就是配置有vip的网卡)发出，通过rip网卡流经网关返回给client。
3.4）实验环境
3.5）实验步骤
未完待续。。。。。
