企业负载均衡集群------LVS（一）---LVS的基本介绍以及工作原理以及DR模式

企业负载均衡集群------LVS（一)----LVS的基本介绍以及工作原理以及DR模式

在前面我们可能了解了varnish也可以做负载均衡，这就好比在生活中我们可能会身兼数职，但是很专业的就屈指可数，而LVS就是专门来做负载均衡的。

1.LVS的基本介绍以及工作原理

1. 什么是LVS
   lvs是linux virtual server的简称，也就是Linux虚拟服务器。这是一个开源项目，它的官方网站是http://www.linuxvirtualserver.org ，现在lvs已经是linux内核标准的一部分。
   通过lvs达到的负载均衡技术和linux操作系统实现一个高性能高可用的linux服务器集群，它具有良好的可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的性能。据业界测试，它的负载均衡已经达到了和硬件一样的水平，所以也为我们节约了很高的成本。
2. LVS的特点
   通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能、高可用的服务器群集，它具有良好可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的服务性能。
   特点总结：

高并发连接：LVS基于内核网络层面工作，有超强的承载能力和并发处理能力。单台LVS负载均衡器，可支持上万并发连接。稳定性强，是工作在网络4层之上仅作分发之用，这个特点也决定了它在负载均衡软件里的性能最强，稳定性最好，对内存和cpu资源消耗极低。
成本低廉：硬件负载均衡器少则十几万，多则几十万上百万，LVS只需一台服务器和就能免费部署使用，性价比极高。
配置简单：LVS配置非常简单，仅需几行命令即可完成配置，也可写成脚本进行管理。
支持多种算法：支持多种论调算法，可根据业务场景灵活调配进行使用
支持多种工作模型：可根据业务场景，使用不同的工作模式来解决生产环境请求处理问题。
应用范围广：因为LVS工作在4层，所以它几乎可以对所有应用做负载均衡，包括http、数据库、DNS、ftp服务等等。
缺点：工作在4层，不支持7层规则修改，机制过于庞大，不适合小规模应用。

3. LVS的工作原理

组成：
LVS由两部分程序组成，包括ipvs和ipvsadm
ipvs(ip virtual server)：一段代码工作在内核空间，叫ipvs，是真正生效实现调度的代码。
ipvsadm：另外一段代码工作在用户空间，叫ipvsadm，负责为ipvs内核框架编写规则，定义谁是集群服务，而谁是后端真实的服务器(Real Server)。

访问流程：
1.当客户端的请求到达负载均衡器的内核空间时，首先会到达PREROUTING链。
2.当内核发现请求数据包的目的地址是本机时，将数据包送往INPUT链。
3.LVS由用户空间的ipvsadm和内核空间的IPVS组成，ipvsadm用来定义规则，IPVS利用ipvsadm定义的规则工作，IPVS工作在INPUT链上,当数据包到达INPUT链时，首先会被IPVS检查，如果数据包里面的目的地址及端口没有在规则里面，那么这条数据包将经过INPUT链送至用户空间，交给用户空间的进程来处理。
4.如果数据包里面的目的地址及端口在规则里面，那么这条数据报文将被修改目的地址为事先定义好的后端服务器，并送往POSTROUTING链。
5.最后经由POSTROUTING链发往后端服务器

另外，LVS中有一些常见的术语，这里我们解释一下：
ipvsad ##用户空间的命令行工具，用于管理集群服务及集群服务上的RS等；
IPVS ##工作于内核上的netfilter INPUT HOOK之上的程序，可根据用户定义的集群实现请求转发；
VS Virtual Server ##虚拟服务
Director, Balancer 负载均衡器、分发器
DS Director Server ##指前端负载均衡器节点
RS Real Server ##后端请求处理服务器
CIP Client IP ##客户端IP
VIP Director Virtual IP ##负载均衡器虚拟IP
DIP Director IP ##负载均衡器IP
RIP Real Server IP ##后端请求处理服务器IP

2.LVS-----DR模式

1. 什么是DR模式？

DR（Direct Routing）直接路由模式

原理：

在一台主机上面搭建lvs服务器，设置LVS的工作模式是DR模式，LVS仅仅是一个调度器，它会把客户端的请求转发给后端服务器。
DR（直接路由）模式直接由后端服务器把数据返回给客户端，不需要逆向发送数据包，此时lvs调度器叫做DS调度器(Director Server)，RS是真正的后端web服务器(Real Server)，LVS专注做调度时效率很高。
DR模式改变的是MAC地址。

Client发送请求 --> DS(调度器) -->prerouting --> INPUT -->postrouting -->RS(Real Server)–>lo --> 网卡eth0 -->Client

对具体过程的描述：

用户（client）发送请求给调度器(DS)，DS调度器先把请求发往prerouting链（内核空间kernal space），确定请求的是不是VIP
到了INPUT链之后，如果请求的是集群服务，会在这里修改MAC地址，把源MAC地址改为DS的MAC地址，把目的MAC地址改为RS的MAC地址，此时IP仍然不变，处理完成后把请求发往postrouting链
postrouting链检测请求的是否为RS（会检测请求的MAC地址），如果是，接受请求，把请求通过回环接口发给出口的网卡，再发回给客户端

LVS（ipvs ipvsadm）–>IPVS改变数据包的ip和端口–>POSTROUTING–>后端服务器

注意：
1.数据在系统内的交流用的是回环接口，与外部之间的交流用的是网卡eth0
2.DR模式高效的原因就是RS服务器会直接响应客户端的请求，发送的请求一直往前发送数据包，不会再返回数据包给调度器

DR模式的特性：

1.DR模式下调度器和服务器组都必须在物理上有一个网卡通过不分段的局域网相连，即通过交换机或者高速的HUB相连，中间没有隔有路由器。
2.VIP地址为调度器和服务器组共享，调度器配置的VIP地址是对外可见的，用于接收虚拟服务的请求报文
3.所有的服务器把VIP地址配置在各自的Non-ARP网络设备上，它对外面是不可见的，只是用于处理目标地址为VIP的网络请求。
4.所有的请求报文经由Director Server，但响应报文必须不能经过Director Server
5.不支持地址转换，也不支持端口映射
6.RS的网关绝不允许指向DIP
7.所有的请求报文都是由调度器（DS）进行调度的
8.MAC地址在第二层，属于数据链路层，还没有到IP所在的网络层
9.RIP和DIP必须处于同一网段中，以便使用MAC地址进行通信
10.后端服务器（Real Server）上必须配置VIP地址，以便接收LVS调度器（Director）转发过来的数据包，以及作为响应报文的源IP
11.后端服务器（Real Server）响应给客户端的数据包的源和目的IP为VIP—>CIP

2. 实验环境的部署
   在做实验之前首先我们需要3台虚拟机：这里我用的是 sever1 sever2 sever3 这三台服务器，我用的是虚拟机server1作为lvs调度器，而server2和server3作为后端服务器

为了方便观察实验结果，我们提前在server2和server3中安装apache，并且写好测试页，注意区分色server2 和 server3 的测试页内容。

3. 配置ipvsadm
   用server1做director server：

首先 yum install ipvsadm -y
ipvsadm -l		#查看策略（解析ip与域名的对应关系，查看速度较慢）
ipvsadm -ln		#-n不解析（速度快）
ipvsadm -A -t 192.168.43.100:80 -s rr	#添加策略：tcp，通过80端口访问192.168.43.100，以轮询的调度算法
ipvsadm -a -t 192.168.43.100:80 -r 192.168.43.72:80 -g	#添加策略：tcp，通过80端口访问192.168.43.100，以轮询的调度算法，使用DR（直接路由）模式，转发到192.168.43.72的80端口
ipvsadm -a -t 192.168.43.100:80 -r 192.168.43.73:80 -g	##添加策略：tcp，通过80端口访问172.25.254.100，以轮询的调度算法，使用DR（直接路由）模式，转发到192.168.43.73的80端口
ipvsadm -ln

ipvsadm安装成功



添加完策略之后，会在 /etc/sysconfig/ipvsadm 里面出现我们写的策略信息。

参数的解释：

4. 添加VIP

在server1 server2 server3中分别添加VIP地址：

ip addr add 192.168.43.100/32 dev eth0	#添加VIP地址到eth0上
ip addr show
注意：此处的/32即掩码设置为32，表示对外不可见

在三台虚拟机中添加完VIP之后，我们查看IP就可以看到 192.168.43.100 这个虚拟IP

5. 测试
   我们发现并没有发生轮询
   
   我们发现并没有发生轮询
   注意：用上面的方法配置lvs，server1、2、3都有可能被访问到，只是我们绑定的MAC地址是server3 的，而并不是说只能访问server3 ，因为被server3抢答到而已。
   

当删除MAC地址之后，重新访问，发现可以访问到server2了


总结：

1 . 如果绑定的MAC地址是server1，则能访问server2 和 server3 ，就可以发生轮询。
2 .如果绑定的MAC地址是sever2或着sever3的，那么我们会发现，在测试端根本不会形成轮询，而是直接去了MAC绑定的后端服务器 （像这里我们就绑定了server3，所以我们只能访问server3，而不能发生轮询。

那么，怎么解决这个问题呢？

6. 解决方法

为了避免三台服务器进行抢答，所以我们就只能绑定server1（调度器）的MAC地址，这样就可以进行轮询了。

那么，怎样保证只能绑定server1（调度器）的MAC地址呢？

我们需要去配置server2和server3的arp路由策略，为arptables网络的用户控制过滤的守护进程。

在server2中：

1. yum install arptables.x86_64 -y
2. arptables -A INPUT -d 192.168.43.100 -j DROP	
3. arptables -A OUTPUT -s 192.168.43.100 -j mangle --mangle-ip-s 192.168.43.72	

在server3中：

1. yum install arptables.x86_64 -y
2. arptables -A INPUT -d 192.168.43.100 -j DROP	
3. arptables -A OUTPUT -s 192.168.43.100 -j mangle --mangle-ip-s 192.168.43.73	

测试：


这就达到了我们想要的结果