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

谁借莪１个温暖的怀抱￠ 2022-02-18 14:15 314阅读 0赞

LVS的背景：

> Internet的快速增长使多媒体网络服务器面对的访问数量快速增加，服务器需要具备提供大量并发访问服务的能力，因此对于大负载的服务器来讲，CPU、I/O处理能力很快会成为瓶颈。由于单台服务器的性能总是有限的，简单的提高硬件性能并不能真正解决这个问题。为此，必须采用多服务器和负载均衡技术才能满足大量并发访问的需要。Linux虚拟服务器(Linux Virtual Servers,LVS)使用负载均衡技术将多台服务器组成一个虚拟服务器。它为适应快速增长的网络访问需求提供了一个负载能力易于扩展，而价格低廉的解决方案。

LVS结构与工作原理

> LVS由前端的负载均衡器(Load Balancer，LB)和后端的真实服务器(Real Server，RS)群组成。RS间可通过局域网或广域网连接。LVS的这种结构对用户是透明的，用户只能看见一台作为LB的虚拟服务器(Virtual Server)，而看不到提供服务的RS群。当用户的请求发往虚拟服务器，LB根据设定的包转发策略和负载均衡调度算法将用户请求转发给RS。RS再将用户请求结果返回给用户。同请求包一样，应答包的返回方式也与包转发策略有关。

LVS的包转发策略：

> NAT (Network Address Translation)模式。LB收到用户请求包后，LB将请求包中虚拟服务器的IP地址转换为某个选定RS的IP地址，转发给RS；RS将应答包发给LB，LB将应答包中RS的IP转为虚拟服务器的IP地址，回送给用户。  
> IP隧道 (IP Tunneling)模式。LB收到用户请求包后，根据IP隧道协议封装该包，然后传给某个选定的RS；RS解出请求信息，直接将应答内容传给用户。此时要求RS和LB都要支持IP隧道协议。  
> DR(Direct Routing)模式。LB收到请求包后，将请求包中目标MAC地址转换为某个选定RS的MAC地址后将包转发出去，RS收到请求包后,可直接将应答内容传给用户。此时要求LB和所有RS都必须在一个物理段内,且LB与RS群共享一个虚拟IP。

我们先来试试DR模式的LVS

> DR模式下**调度器**和**服务器组**都必须在物理上有一个网卡通过不分段的局域网相连，即通过交换机或者高速的HUB相连，中间没有隔有路由器。VIP地址为调度器和服务器组共享，调度器配置的VIP地址是对外可见的，用于接收虚拟服务的请求报文；所有的服务器把VIP地址配置在各自的Non-ARP网络设备上，它对外面是不可见的，只是用于处理目标地址为VIP的网络请求。  
> ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70]

### 一、搭建DR模式的LVS ###

1.在Varnish服务器上配置更完备的yum源  
在对应共享yum源部署主机上查看拓展包名称  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70 1]  
在Varnish主机（server1）上编辑yum源文件

vim /etc/yum.repos.d/rhel-source.repo
    
    
    [rhel-source]
    name=Red Hat Enterprise Linux $releasever - $basearch - Source
    baseurl=http://172.25.70.250/rhel6.5/
    enabled=1
    gpgcheck=1
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
    
    [HighAvailability]		#高可用
    name=HighAvailability
    baseurl=http://172.25.70.250/rhel6.5/HighAvailability
    enabled=1
    gpgcheck=1
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
    
    [LoadBalancer]			#负载均衡
    name=LoadBalancer
    baseurl=http://172.25.70.250/rhel6.5/LoadBalancer
    enabled=1
    gpgcheck=1
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
    
    [ResilientStorage]		#弹性存储
    name=ResilientStorage
    baseurl=http://172.25.70.250/rhel6.5/ResilientStorage
    enabled=1
    gpgcheck=1
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
    
    [ScalableFileSystem]	#可扩展文件系统
    name=ScalableFileSystem
    baseurl=http://172.25.70.250/rhel6.5/ScalableFileSystem
    enabled=1
    gpgcheck=1
    gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
    
    #清理yum配置缓存
    yum clean all
    #查看可用yum仓库
    yum repolist

可以看到yum源配置成功  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70 2]  
给server2、server3也拷贝一份yum配置文件

scp rhel-source.repo root@server2:/etc/yum.repos.d/
    
    scp rhel-source.repo root@server3:/etc/yum.repos.d/

> LoadBalancer: 可以将来自客户端的请求分发到不同的服务器，通过将一系列的请求转发到不同的服务器可以提高服务器的性能，并可以自动地寻找最优的服务器转发请求，这样不仅提高了系统性能，同时达到了负载均衡的目的，满足了用户需求，因此 LoadBalancer 在应用场景中一般处于 web 服务器的前端，用来均衡发到 web 服务器的请求量，均衡负载，提高系统性能。LoadBalancer 可以连接多个web server，从而将多个 web server组成一个集群（cluster）， 集群中负载的分配通过 loadBalancer进行控制和管理。 当然为了更好地进行负载均衡，LoadBalancer 也可以构建为一个集群， 使用 LoadBalancer 构建的 web server cluster

3.在server1（虚拟服务器）上安装ipvsadm（调度器）  
ipvsadm是管理集群服务的命令行工具，用于管理LVS的策略规则  
显示调度次数ipvsadm -nl（-n不解析）

yum install ipvsadm -y

4.添加一台虚拟设备

ipvsadm -A -t 172.25.70.100:80 -s rr
    
     =======================================
      -A 增加一台虚拟设备
      -t --tcp-service  service-address
      -s scheduler      one of rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq

为了实验效果明显，我们采用rr算法 （轮叫）

5.添加后端实际服务器

ipvsadm -a -t 172.25.70.100:80 -r 172.25.70.2:80 -g
     ipvsadm -a -t 172.25.70.100:80 -r 172.25.70.3:80 -g
     #给server1（虚拟服务器）添加ip172.25.70.100 
     ip addr add 172.25.70.100/24 dev eth0
     #给server2和server3添加ip 
     ip addr add 172.25.70.100/32 dev eth0

server1  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70 3]  
server2  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70 4]  
server3  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70 5]  
6.在物理机端（测试端）访问172.25.70.100，查看缓存的MAC地址  
在物理机端：arp -d 172.25.70.100 删除现有绑定MAC地址

curl 172.25.70.100    #重新获得ip和MAC地址
    arp -an | grep 100    #查看绑定的MAC地址
    ==================================
    server1的MAC：52:54:00:90:dd:bd
    server2的MAC：52:54:00:29:2e:f5
    server3的MAC：52:54:00:82:e6:25

MAC地址缓存的是server2时，无法轮询  
![在这里插入图片描述][20190417174110621.png]  
MAC地址缓存的是server3时，无法轮询  
![在这里插入图片描述][20190417174540694.png]  
如果绑定的MAC地址是sever2或sever3的，那么我们会发现，在测试端根本不会形成轮叫，而是直接去了MAC绑定的后端服务器。

注意： 此时的客户端进行访问的时候，会随机选取，后端谁抢到就是谁的，（因为arpip广播）

7.在server2和server3中下载yum install -y arptables\_jf，防止在物理机中测试时直接访问server2和server3

server2

yum install -y arptables_jf
    ========================================
    arptables -A IN -d 172.25.70.100 -j DROP   
    # 当网内广播需要172.25.70.100这个ip时，它丢弃所有网内的请求
    arptables -A OUT -s 172.25.70.100 -j mangle --mangle-ip-s 172.25.70.2
    # 当它自身需要在网内发包时，伪装为自己原本的ip172.25.70.2
    /etc/init.d/arptables_jf save   #保存添加的两条策略
    /etc/init.d/arptables_jf start  #打开arptables服务

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70 6]  
server3

yum install -y arptables_jf
    ========================================
    arptables -A IN -d 172.25.70.100 -j DROP   
    # 当网内广播需要172.25.70.100这个ip时，它丢弃所有网内的请求
    arptables -A OUT -s 172.25.70.100 -j mangle --mangle-ip-s 172.25.70.3
    # 当它自身需要在网内发包时，伪装为自己原本的ip172.25.70.2
    /etc/init.d/arptables_jf save   #保存添加的两条策略
    /etc/init.d/arptables_jf start  #打开arptables服务

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70 7]

> 什么是arptables：（可类比与iptables防火墙的用法）  
> arptables用于建立、获取、修改内核的arp包处理表.有几个不同的表，每个表分别含有几条内建的处理链,同时允许用户自定义处理链， 每条链是一些规则的列表，每条规则匹配特定的包.每条规则指定一个对匹配的包的操作.这个操作也叫做‘目标’，这个目标也可是跳转到同一个表中的另外的链

> 1.内建目标： ACCEPT, DROP, QUEUE,  
> RETURN.是几个最基本的目标，ACCEPT指接受这个包，DORP指丢掉这个包，QUEUE指把包传到用户空间（如果内核指定了的话），RETURN指返回到上一条链，接着执行上一条链跳转过来哪条规则的下一个规则.每条链都有一个默认目标，当包经过所有规则都没被匹配，则发给默认目标

> 2.表：  
> 一边至少有一个内建的表（filter表）-t常常用于指定要操作的表.filter表有两个内建的链，IN和OUT，IN用于处理目标为发给本机目标为本机的包，OUT处理本机发出去的包.

8.在测试端测试

arp -d 172.25.70.100
    curl 172.25.70.100
    curl 172.25.70.100
    arp -an | grep 100

![在这里插入图片描述][20190417182211680.png]  
分析：出现轮询机制，经过多次清理缓存也不会使轮询失效。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70]: /images/20220218/7a07bdf0c1bb4cf7ba43ac62be262f0e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70 1]: /images/20220218/6336f8e2bf974029b4632912ba529d3b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70 2]: /images/20220218/7a5518468ee94bab9ff051610457d082.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70 3]: /images/20220218/0377812773b2413ba34a96e7ca69a8bc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70 4]: /images/20220218/84ceb35a0bfb445a9a43bf6529b88f38.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70 5]: /images/20220218/68bed42f866f4368a8b7ccd235f69827.png
[20190417174110621.png]: /images/20220218/4b7a521d0c414e1196961a8713fc4c38.png
[20190417174540694.png]: /images/20220218/fe79de69ab1b4e4c9fd57a4afe2237d1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70 6]: /images/20220218/acc45833827b49b2ad389fb89b34ab37.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzNTcwMzY5_size_16_color_FFFFFF_t_70 7]: /images/20220218/19fdacd2c18a44e78823dd058bec7a54.png
[20190417182211680.png]: /images/20220218/e0bb9fada4714f9aa78cd9d052019ee6.png