LVS/DR模式(直接路由模式)（ipvsadm+ipvs）(2)

lvs(LB集群的一个实现)
硬件:F5 BIG-IP 太贵

软件：
lvs（四层）
haproxy
nginx （七层）
varnish

lvs 基础知识

lvs指的是Linux虚拟服务器，是一个虚拟的服务器集群系统。其主要用于多服务器的负载均衡。

   优点： 廉价，可把许多低性能的服务器组合在一起形成一个超级服务器。 易用，配置非常简单，且有多种负载均衡的方法。
    稳定可靠，即使在集群的服务器中某台服务器无法正常工作，也不影响整体效果。 另外可扩展性也非常好。

lvs的定义：

LVS的全称是Linux virtual
server，即Linux虚拟服务器，它是封装在linux的内核中的。之所以是虚拟服务器，是因为LVS自身是个负载均衡器，不接受处理请求，而是将请求转发至位与它后端真正的服务器realserver上。
LVS是四层（传输层tcp/udp），七层（应用层）的负载均衡工具，只不过大众一般都使用它的四层负载均衡功能ipvs，而七层的内容分发负载工具ktcpvs（kernel
tcp virtual server）不怎么完善，使用的人并不多。
ipvs是集成在内核中的框架，可以通过用户空间的程序ipvsadm工具来管理，该工具可以定义一些规则来管理内核中的ipvs。就像iptables和netfilter关系一样。

很重要！！！！！！！！

lvs附着于netfiler
五个内置的钩子函数
PREROUTING ---> INPUT（流向内部)
PREROUTING----> FORWARD ---> POSTROUTING(转发)‘
OUTPUT---> POSTROUTING(流向外部)
1. 当用户向负载均衡调度器（Director Server）发起请求，调度器将请求发往至内核空间
2. PREROUTING链首先会接收到用户请求，判断目标IP确定是本机IP，将数据包发往INPUT链
3. IPVS是工作在INPUT链上的，当用户请求到达INPUT时，IPVS会将用户请求和自己已定义好的集群服务进行比对，如果用户请求的就是定义的集群服务，那么此时IPVS会强行修改数据包里的目标IP地址及端口，并将新的数据包发往POSTROUTING链
4. POSTROUTING链接收数据包后发现目标IP地址刚好是自己的后端服务器，那么此时通过选路，将数据包最终发送给后端的服务器

lvs工作于INPUT
PREROUTING ---> INPUT(lvs在此强行改变数据流向)--->POSTROUTING

lvs是由两部份组成的
1.ipvs(ip virrual server):一段代码(工作在内核)是真正生效实现调度的代码
2.ipvsadm（工作在用户空间，负责为ipvs内核框架编写规则）
定义谁是集群服务，而谁是后端真实地服务器
ipvsadm(工作在用户空间的命令行工具 写具体的规则 用于管理集群服务)/ipvs(工作在内核中的netfilter input钩子函数上)

lvs相关术语
1. DS：Director Server。指的是前端负载均衡器节点。
2. RS：Real Server。后端真实的工作服务器。
3. VIP：向外部直接面向用户请求，作为用户请求的目标的IP地址。
4. DIP：Director Server IP，主要用于和内部主机通讯的IP地址。
5. RIP：Real Server IP，后端服务器的IP地址。
6. CIP：Client IP，访问客户端的IP地址。

lvs 四种工作模式

DR（直接路由）模式

TUN（隧道）模式

NAT （网络地址转换）模式

Full-Nat模式

LVS模式一：DR（Direct Routing）直接路由模式

客户端请求 VIP 时,通过因特网先到达调度器,调度器会根据调度算法将这个请求转发给真实的服务器,转发的过程中仅仅是修改了数据报文中的MAC地址。当真实服务器接受到数据请求后进行处理,然后发送响应给客户端,但此时的源 IP 为真实的服务器 IP,即 RIP,目标 IP为客户端 IP,即 CIP,但是客户端并没有请求RIP,所以客户端是不会接收数据响应,所以,就要修改源 IP 为 VIP,但是不可以将VIP 设置在出口网卡上,否则会响应客户端的 arp 请求。失去了调度的意义,因此要在 lo 接口配置 VIP,并且将 VIP 隐蔽,即设置 NETMASK 为255.255.255.255,这样,数据响应从真实服务器出去的时候的源 IP 是 VIP,目的 IP 是
CIP,客户端就会接收次数据响应,从真实服务器到客户端是通过Internet。

1.DR 模式需要调度器与真实服务器在同一个物理网络。即通过交换机或者高速的HUB相连，中间没有隔有路由器。

2.VIP地址为调度器和服务器组共享，调度器配置的VIP地址是对外可见的，用于接收虚拟服务的请求报文。

3.所有的服务器把VIP地址配置在各自的Non-ARP网络设备上，它对外面是不可见的，只是用于处理目标地址为VIP的网络请求。

优点:性能最高
缺点:要求调度器的网卡必须与物理网卡在一个物理网段上

DR模式工作原理：

Client发送请求 -->prerouting --> INPUT— DS(调度器) --> -->postrouting
–>RS（真正的服务器）–>lo回环接口 --> 网卡eth0 -->Client 整个过程的数据流向如下 用户（client）发送请求给调度器(DS)，DS调度器先把请求发往prerouting链（内核空间kernal space），确定请求的是不是VIP 到了INPUT链之后，如果请求的是集群服务，会在这里修改MAC地址，把源MAC地址改为DS的MAC地址
把目的MAC地址改为RS的MAC地址，此时IP仍然不变，处理完成后把请求发往postrouting链
检测请求的是否为RS（会检测请求的MAC地址），如果是，接受请求，把请求通过回环接口发给出口的网卡，再发回给客户端
数据在系统内的交流用的是回环接口，与外部的交流用的是网卡eth0
DR模式高效的原因就是RS服务器会直接响应客户端的请求，发送的请求一直往前发送数据包，不会再返回数据包给调度器
注意：这里的prerouting，input，postrouting都是iptables防火墙里面的链，如果不懂先回去复习iptables

配置ipvsadm

做本次实验需要一个纯净的环境，避免之前的varnish影响。

实验环境：

server1 172.25.63.1 Realserver1 apache服务
server2 172.25.63.2 Realserver2 apache服务
server3  172.25.63.3 ipvsadm调度器
物理机   172.25.63.250   用来测试

（1）首先下载ipvsadm并编写策略，启动服务

yum install  ipvsadm -y  安装服务
此时的虚拟机版本是7.5的，7.5版本的yum源的packages安装包中有LoadBalancer负载均衡模块，因此不再需要搭建负载均衡的yum源
如果是6.5版本的yum源，需要搭建负载均衡的yum源才可以安装这个服务
ipvsadm -A -t 172.25.15.100:80 -s rr  设置客户端进入lvs调度器的入口地址，调度算法是轮询
ipvsadm -a -t 172.25.15.100:80 -r 172.25.15.2:80 -g   设置lvs的策略：入口的第一台后端服务器的信息
ipvsadm -a -t 172.25.15.100:80 -r 172.25.15.3:80 -g    -g设置lvs的策略：入口的第二台后端服务器的信息
-s表示调度算法，rr表示轮询，-g表示lvs调度器工作在DR模式
cat /etc/sysconfig/ipvsadm     
systemctl start ipvsadm.service

注意：

	-A：增加一台虚拟设备
	-a：增加真实服务器的操作
	-t：tcp服务地址
	-s：调度算法（调度算法分别有10种，为rr/wrr/lc/wlc/lblc/lblcr/dh/sh/sed/nq
	-r：对应的真实ip
	-g：rh（路由）
	rr：调度算法，轮循

设置DR模式的访问策略
ipvsadm -l列出策略（查看调度策略）
注意此处把server3的子网掩码设置为24

显示调度次数（-l列出当前的策略，-n不解析）

ipvsadm  -l
ipvsadm  -ln

（2）给server1,server2,server3添加VIP（172.25.63.100）

将子网掩码设置为32，是因为请求从调度器过来时，不对外提供服务的，只提供内部通信

（3）在server1和server2上安装httpd服务，并编写默认发布页面


以上情况，server1，2，3都有可能被访问到

如果绑定的MAC地址是server3，则在server1,2轮询

如果绑定的MAC地址是server1或server2的，那么我们会发现，在测试端根本不会形成轮叫，而是直接去了MAC绑定的后端服务器 （显然这样在企业中是不允许的）
(4)在物理机测试
会发现访问的一直是server2中的测试页

查看MAC地址是server2的MAC地址，无法轮询
发现是server3的MAC地址

注意：此时客户端访问资源有时候轮询，有时候不轮询，出现这样的现象是为什么呢？

造成这种情况的原因是因为DR模式是通过修改MAC地址进行访问的，调度器和两台web服务器上都有172.25.63.100这个入口地址ip
所以客户端在请求的时候，三台虚拟机都有可能回复请求，客户端会记录回复他的那台虚拟机的mac地址
所以下次在访问的时候他会找记录过的mac地址对应的虚拟机（有可能是真实的服务器）直接访问
这在现实中是不允许的，因为如果请求全部发往后端某一台真正的服务器的话，这台服务器会因为压力过大而宕机
而且，直接访问后端的真正的服务器，我们的server1（LVS调度器）也就没有起到作用
并没有实现真正意义上的负载均衡，这也是DR模式的一个缺点 这就类似于DDOS攻击，有可能会导致后端服务器瘫痪，造成用户不能正常访问资源

解决MAC地址无法成功绑定的情况：
会造成DDOS攻击，导致后端服务器瘫痪
因为客户端第一次访问172.25.63.100的时候server1,server2,server3均可以接收客户端的请求，这个是随机的
有可能不会经过lvs调度器，客户端直接问web服务器要资源
在两个web后端上进行设置，防止ddos攻击

要解决这样不合理的情况，解决的方法只有一直绑定sever3的MAC地址，所以我门要配置server1和server2的arp路由策略

（1）两台主机上都安装并添加策略

yum install -y arptables_jf  安装针对MAC地址的防火墙管理工具

#当网内广播需要172.25.63.100这个ip时，它将丢弃网内的所有请求
arptables -A INPUT -d 172.25.63.100 -j DROP  丢弃客户端的直接访问
#当它自身需要在网内发包时，伪装为自己原本的ip172.25.63.2
arptables -A OUTPUT -s 172.25.15.100 -j mangle --mangle-ip-s 172.25.63.2  
 使自己以172.25.8.100的身份发送资源给客户端
#查看策略，
arptables  -nL

man arptable可以查看设置规则

在真机上面进行测试
此时做完这个：就可以实现调度了
web2和web3就不会接受客户端的请求了，每次客户端的访问只能由调度器接受
只有调度器才会接收这个请求，因此也就是通过lvs调度器的mac地址，因此可以实现正常访问
通过调度器访问时，因为调度器里面设置了调度规则，因此可以实现正常访问

可以看到客户端此时访问的MAC地址是lvs调度器的MAC地址
还可以设置权重，
当一台真实服务器关闭服务
在轮询到server2的时候报错，拒绝服务，但是我们不能把错误的页面呈现给客户，因此需要健康检查。后面的ldirectord会讲到。

----------------------------------------------------------------------------------------
划分：上面是自己写的
下面是听课内容，做笔记用

规则和iptables一样 都是直接到内存生效
可以使用ipvsadm-save保存
也提供了保存的文件ipvsadm-config
ipvsadm

ipvsadm：
			程序包：ipvsadm
				Unit File: ipvsadm.service
				主程序：/