3-02 LVS-DR集群

Posted 2020-09-25

LVS-DR集群

DR=Direct Routing(直接路由)

director 分配请求到不同的 real server。real server 处理请求后直接回应给用户，这样 director 负载均衡器仅处理客户机与服务器的一半连接。负载均衡器仅处理一半的连接，避免了新的性能瓶颈，同样增加了系统的可伸缩性。Direct Routing 由于采用物理层（修改 MAC 地址）技术，因此所有服务器都必须在一个网段中。

IP= IP Tunneling(IP 隧道)

director 分配请求到不同的 real server。real server 处理请求后直接回应给用户，这样 director 负载均衡器仅处理客户机于服务器的一半连接。IP Tunneling 技术极大地提高了 director 的调度处理能力，同时也极大地提高了系统能容纳的最大节点数，可以超过 100 个节点。real server 可以在任何 LAN 接WAN 上运行，这意味着允许地理上的分布，这在灾难恢复中有重要意义。服务器必须拥有正式的公网 IP地址用于不客户机直接通信，并且所有服务器必须支持 IP 隧道协议。

Direct Routing 和 IP Tunneling 区别

Direct Routing与IP Tunneling 相比，没有 IP 封装的开销，但由于采用物理层（修改 MAC 地址）技术，所有服务器都必须在一个物理网段。

LVS-DR工作原理拓扑

Lvs-dr的工作原理：Deiector收到请求，将请求转发给了我们的realserver，但是接下来的工作就是我们的realserver和们的客户端进行通讯了，所以原理图如下

 

 

lvs-dr工作流程

工作原理也就是：MAC 转换过程 （过程，和实验IP没有关系）

实例场景设备清单： director 分发器,IP: 192.168.54.120, VIP : 192.168.57.126

 

 

1：  client 基本信息： IP：192.168.57.135

       向目标 vip 发出链接请求，Director 接收。此时 IP 包头及数据帧头信息如下：

 

 

2：  Director 分发器根据负载均衡算法选择一台 active 的 realserver(假设是 192.168.57.122)，将此RIP 所在网卡的 mac 地址作为目标 mac 地址，发送到局域网里。此时 IP 包头及数据帧头信息如下：

 

 

       整个过程不会修改IP报文的内容!     [访问客户端无论多么复杂，我们可以认为客户端与LVS链接的时候属于同一网段的公网地址]

3：  realserver(192.168.57.122)在局域网中收到这个帧，拆开后发现目标 IP(VIP)与本地匹配，于是处理这个报文。随后重新封装报文，发送到局域网。此时 IP 包头及数据帧头信息如下：

 

 

4：  如果 client 与 VS 同一网段，那么client(192.168.57.135)将收到这个回复报文。如果跨了网段，那么报文通过 gateway路由器经由 Internet 返回给用户。

归纳一下：1）接收client的请求，根据你设定的负载均衡算法选取一台realserver的ip；

2）以选取的这个ip对应的mac地址作为目标mac，然后重新将IP包封装成帧转发给这台RS；

3）在hash table中记录连接信息。

数据包、数据帧的大致流向是这样的：client --> VS --> RS --> client

选择LVS-DR的原因

因为 NAT 模式效率太低。DR全部使用的公网地址，也就随之即来的成本问题!

LVS-DR集群

 

 

分发器IP配置

从拓扑图看出我们的eth0有两个IP地址，所以我们需要配置eht0和eth0:1两个IP

DIP===eth0===192.168.1.11                 VIP===eth0:1===192.168.1.111

[[email protected] ~]# cd /etc/sysconfig/network-scripts/

[[email protected] network-scripts]# cp ifcfg-eth0 ifcfg-eth0:1

[[email protected] network-scripts]# vim ifcfg-eth0

DEVICE=eth0

TYPE=Ethernet

UUID=4a887011-0d0d-4d90-9a48-6314af3eca79

ONBOOT=yes

NM_CONTROLLED=yes

BOOTPROTO=none

IPADDR=192.168.1.11

PREFIX=24

GATEWAY=192.168.1.254

DNS1=192.168.1.254

HWADDR=00:0C:29:2D:60:43        #若配置文件有MAC，必须和eth0：1的MAC一样

[[email protected] network-scripts]# vim ifcfg-eth0:1

DEVICE=eth0:1                   #修改名称

UUID=4a887011-0d0d-4d90-9a48-6314af3eca79            

TYPE=Ethernet

ONBOOT=yes                      #开机启动

NM_CONTROLLED=yes

BOOTPROTO=none

IPADDR=192.168.1.111            #修改IP地址

PREFIX=24

GATEWAY=192.168.1.254

DNS1=192.168.1.254

DEFROUTE=yes

IPV4_FAILURE_FATAL=yes

IPV6INIT=no

HWADDR=00:0C:29:2D:60:43        #若配置文件有MAC，必须和eth0的MAC一样

[[email protected] network-scripts]# ifdown eth0 ; ifup eth0

[[email protected] network-scripts]# ifconfig                //查看能否有两个IP地址

eth0      Link encap:Ethernet  HWaddr 00:0C:29:2D:60:43                        

          inet addr:192.168.1.11  Bcast:192.168.1.255  Mask:255.255.255.0

……

 

eth0:1    Link encap:Ethernet  HWaddr 00:0C:29:2D:60:43 

          inet addr:192.168.1.111  Bcast:192.168.1.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

两台RealServer的IP配置

[[email protected] ~]# cd /etc/sysconfig/network-scripts/

[[email protected] network-scripts]# cp ifcfg-lo ifcfg-lo:1

[[email protected] network-scripts]# vim ifcfg-lo:1

DEVICE=lo:1                     #修改名称

IPADDR=192.168.1.111            #修改IP

NETMASK=255.255.255.255         #代表这台设备

ONBOOT=yes

NAME=loopback

[[email protected] network-scripts]# ifdown lo ; ifup lo

[[email protected] network-scripts]# ifconfig lo:1

lo:1      Link encap:Local Loopback 

          inet addr:192.168.1.111  Mask:255.255.255.255

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

 

[[email protected] ~]# cd /etc/sysconfig/network-scripts/

[[email protected] network-scripts]# cp ifcfg-lo ifcfg-lo:1

[[email protected] network-scripts]# vim ifcfg-lo:1

DEVICE=lo:1

IPADDR=192.168.1.111

NETMASK=255.255.255.255

ONBOOT=yes

NAME=loopback

[[email protected] network-scripts]# ifdown lo ; ifup lo

[[email protected] network-scripts]# ifconfig lo:1

lo:1      Link encap:Local Loopback 

          inet addr:192.168.1.111  Mask:255.255.255.255

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

分发器配置LVS-DR规则

[[email protected] network-scripts]# cd

[[email protected] ~]# rpm -ivh /media/Packages/ipvsadm-1.26-2.el6.x86_64.rpm

[[email protected] ~]# ipvsadm -A -t 192.168.1.111:80 -s rr

-t: TCP协议的集群

-u: UDP协议的集群

           -f: FWM: 防火墙标记

 [[email protected] ~]# ipvsadm -a -t 192.168.1.111:80 -r 192.168.1.13:80 -g       //-g 表示--gatewaying，DR模式

[[email protected] ~]# ipvsadm -a -t 192.168.1.111:80 -r 192.168.1.15:80 -g

[[email protected] ~]# 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.1.111:80 rr

  -> 192.168.1.13:80              Route   1      0          0        

  -> 192.168.1.15:80              Route   1      0          0

三个LVS 模式中，只有NAT模式需要开启 路由转发功能。 DR和TUN模式不需要开启。

测试数据站

[[email protected] network-scripts]# cd

[[email protected] ~]# vim /etc/sysctl.conf

net.ipv4.conf.eth0.arp_ignore = 1           #追加这两行

net.ipv4.conf.eth0.arp_announce = 2

net.ipv4.conf.all.arp_ignore = 1

net.ipv4.conf.all.arp_announce = 2

-----------------------------------------------------------------------------------

参数说明：

arp_ignore 为：1  只回答目标 IP 地址是访问本网络接口（eth0）的 ARP 查询请求。 

自己的理解：

在设置参数的时候将 arp_ignore 设置为 1，意味着当别人的 arp 请求过来的时候，如果接收的网卡设备上面没有这个 ip，就不做出响应，默认是 0，只要这台机器上面任何一个网卡设备上面有这个 ip，就响应arp 请求，并发送 mac 地址。

arp_announce  （宣告） 为 2 

对查询目标使用最适当的本地地址。例如，如果在 eth0 接口上接受到了一个 VIP 的 arp 请求包。内核判断这个 VIP 地址是不是 eth0 接口上的 IP 一样。如果一样，则回复这个包。如果不一样，就丢弃不回应。 或者使用命令：不过是临时生效

 echo 2 >  /proc/sys/net/ipv4/conf/eth0/arp_announce

 echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_ignore

[[email protected] ~]# sysctl -p

[[email protected] ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 | grep GATEWAY

GATEWAY=192.168.1.254                           #网关要正确

[[email protected] ~]# yum install -y httpd

[[email protected] ~]# echo Pualinux13 > /var/www/html/index.html

[[email protected] ~]# service httpd restart

 

[[email protected] network-scripts]# cd

[[email protected] ~]# vim /etc/sysctl.conf

net.ipv4.conf.eth0.arp_ignore = 1                       #追加这四行

net.ipv4.conf.eth0.arp_announce = 2

net.ipv4.conf.all.arp_ignore = 1

net.ipv4.conf.all.arp_announce = 2

[[email protected] ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 | grep GATEWAY

GATEWAY=192.168.1.254                           #网关要正确

[[email protected] ~]# yum install -y httpd

[[email protected] ~]# echo Pualinxu15 > /var/www/html/index.html

[[email protected] ~]# service httpd restart

 

注意，在前面我们重启网卡的时候，我们没有做ARP处理方案的时候，可能网卡是无法重启成功的，你也可以配置好VIP和Arp相关的处理方式之后，在重新启动，效果一样，只是一个启动顺序的问题而已!

测试集群运作

如果VMware模拟环境，这里你可能出现刷新一直都在一个页面，但你的配置确实很正常的话，那就没有问题，可以用Linux做轮询演示：

 

 

Linux下使用elinks做轮询演示：

[[email protected] ~]# yum install -y elinks

[[email protected] ~]# elinks http://192.168.1.111 –dump

Pualinux13

[[email protected] ~]# elinks http://192.168.1.111 –dump

   Pualinux15

LVS集中调度模式

-s rr               轮询法                                                     -s wrr     带权重的轮询

       -s lc               最少链接法                                              -s wlc     带权重的最少链接法

       -s lblc            基于本地的最少链接法                            -s dh             目标散列法

       -s sh             散列法                                                     -s sed           最短周期延迟法

       -s nq             永不排队法                                              -s=scheduler=调度的意思

调度散发配置后立即生效，就像iptables规则一样

rr轮询    round robin

       在服务器中无穷的循环中遍历

wrr带权重轮询    Weighted Round Robin

       基于集群节点可以处理多少来分配给每个节点一个权重值。权重值为 2 的服务器将收到权重值为 1 的服务器的两倍的连接数量。如果服务器的权重为 0 ，则不会收到新的连接请求(但当前活动的已经建立的连接将不会丢失)。

lc最少链接法       Least-Connection

       当新的请求到达 director 时，director 查看活动和非活动的连接数量，以确定把请求分发给哪个服务器。director 将集群节点目前的活动连接数量 x256 再加上不活动的连接数量，得到节点的开销值。最低开销值的节点胜出，被分发给新的入站请求。（如果开销一样，则第一个节点被选中）

wlc带权重的最少链接法     Weighted Least-Connection

       先如上算出集群节点的开销值，然后除以分配给其的权重值，最小值节点胜出，将入站请求分发给它。

lblc基于本地的最少链接法        Locality-Based  Least-Connection

       基于局部的最小连接，当 real server 是缓存服务器时用得比较多

dh目标散列法      Destination Hashing

sh散列法      Source  Hashing

       同一个 ip 的客户端总是分发给同一个 real server。 让客户端总是能访问到自己的会话信息，这种机制叫会话保持。

基于 ip 地址标识客户端的缺点：很多内网用户会伪装成公网 ip，来访问服务器，不能人为的控制负载均衡。

       比较高级的方法是基于客户端提供我们的 session id 来实现会话保持。haproxy(做负载均衡的软件)可以实现基于会话信息来判断保持会话。

如何保持会话一致：如果总是保持和一个 RS 会话，这台 RS 如果故障了，要确定另一个 RS 也有会话信息，所有的 RS保持数据同步。

       会话同步的方法：所有的 RS 把自己的会话信息保存到数据库当中(memcached 软件）。

sed最短周期延迟法    Shortest Expected Delay 最短延时预测  (Ci+1)/Ui  Ci 连接数  Ui 权重值

       在 wlc 方法上做了轻微改进，这些服务使用 tcp,而且当群节点在处理每个请求时保持在活动状态。

计算方法： 每个休群节点的开销值是通过将活动的连接数加 1 计算的。然后开销值除以分配给每个节点的权重，以取得 SED 值，具有最低 SED 值的集群节点胜出。

nq永不排队法      Never  Queue

没有队列，分配请求给空闲的服务器，没有空闲的就找响应最快的，如果集群节点中没有活动的连接 ，不管每个集群节点 SED 计算值的结果，它始终被 分配置服务的新入站请求。

HTTP 的会话(session)信息：

cookies 客户端(client)自己保存缓存

会话(session)服务器(server)端保存

LVS DR wrr调度算法

实现我们访问，轮询的时候在15上轮询两次之后，13上一次，2：1的比例承担我们的访问负载！

算法配置

[[email protected] ~]# ipvsadm -C

[[email protected] ~]# ipvsadm -A -t 192.168.1.111:80 -s wrr

[[email protected] ~]# ipvsadm -a -t 192.168.1.111:80 -r 192.168.1.13:80 -g -w 10

[[email protected] ~]# ipvsadm -a -t 192.168.1.111:80 -r 192.168.1.15:80 -g -w 20

[[email protected] ~]# ipvsadm -L -n –stats

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port               Conns   InPkts  OutPkts  InBytes OutBytes

  -> RemoteAddress:Port

TCP  192.168.1.111:80                    0        0        0        0        0

  -> 192.168.1.13:80                     0        0        0        0        0

  -> 192.168.1.15:80                     0        0        0        0        0

测试

物理机上刷新http://192.168.1.111，或者linux elinks测试

[[email protected] ~]# elinks http://192.168.1.111 -dump

   Pualinux15

 [[email protected] ~]# elinks http://192.168.1.111 -dump

   Pualinux15

 [[email protected] ~]# elinks http://192.168.1.111 -dump

   Pualinux13

刷新的过程中我们发现，15的页面我们看到两次之后才会变为Pualinxu13，也就是访问了15两次之后才访问一次13

[[email protected] ~]# ipvsadm -L -n –stats                  //状态说明问题

IP Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port               Conns   InPkts  OutPkts  InBytes OutBytes

  -> RemoteAddress:Port

TCP  192.168.1.111:80                    36      216        0    22086        0

  -> 192.168.1.13:80                    12       72        0     7392        0

  -> 192.168.1.15:80                    24      144        0    14694        0

可以看到，一共36次连接，64承担了24次，62承担了12次，是2:1的关系，说明权重越大，获得的连接越多

LVS DR wrr 权重为0

[[email protected] ~]# ipvsadm -C

[[email protected] ~]# ipvsadm -A -t 192.168.1.111:80 -s wrr

[[email protected] ~]# ipvsadm -a -t 192.168.1.111:80 -r 192.168.1.13 -g -w 0

[[email protected] ~]# ipvsadm -a -t 192.168.1.111:80 -r 192.168.1.15 -g -w 20

客户单物理机刷新页面，多次之后查看

[[email protected] ~]# ipvsadm -L -n --stats

P Virtual Server version 1.2.1 (size=4096)

Prot LocalAddress:Port               Conns   InPkts  OutPkts  InBytes OutBytes

  -> RemoteAddress:Port

TCP  192.168.1.111:80                    21      126        0    12936        0

  -> 192.168.1.13:80                      0        0        0        0        0

  -> 192.168.1.15:80                     21      126        0    12936        0

可以看到所有的链接都给了15，为0的权重不接收链接

此外：发现InPkts是有的，OutPkts为0，  因为数据包出去时，直接交给了 real server，而没有交给 Director!

网站压力测试命令

语法： ab -n 数字  -c 数字  http://链接

-n requests Number of requests to perform                                      #在测试会话中所执行的请求总个数。默认时，仅执行一个请求

-c concurrency Number of multiple requests to make                       #一次产生的请求个数，并发数。默认是一次一个。

[[email protected] ~]# yum install -y httpd-tools

[[email protected] ~]# ab -n 1000 -c 1000 http://192.168.1.111/      #共1000 个请求。 一次要执行 1000 个并发请求。

his is ApacheBench, Version 2.3 <$Revision: 655654 $>

Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

Licensed to The Apache Software Foundation, http://www.apache.org/

 

Benchmarking 192.168.1.111(be patient)          #patient 耐心

Completed 100 requests

Completed 200 requests

Completed 300 requests

Completed 400 requests

Completed 500 requests

Completed 600 requests

Completed 700 requests

Completed 800 requests

Completed 900 requests

Completed 1000 requests

Finished 1000 requests                              # 完成1000个请求

 

Server Software:        Apache/2.2.15               # 被测试的 httpd 服务器版本：平台 apache 版本

Server Hostname:        192.168.1.111               # 192.168.1.11 服务器主机名

Server Port:            80                          # 服务器端口      

 

Document Path:          /                           # 测试的页面文档

Document Length:        13 bytes                    # 文档大小

 

Concurrency Level:      1000                    # 并发数

Time taken for tests:   2.919 seconds           # 整个测试花费的时间

Complete requests:      1000                        # 完成的请求数量

Failed requests:        0                           # 失败的请求数量

Write errors:           0

Total transferred:      280280 bytes                # 整个测试过程中总传输字节数

HTML transferred:       13013 bytes                 # 整个场景中的 HTML 内容传输量

Requests per second:    342.56 [#/sec] (mean) # 每秒处理请求数。

#大家最关心的指标之一，相当于服务器中的每秒事务数 ，后面括号中的 mean 表示这是一个平均值

Time per request:       2919.174 [ms] (mean)

#大家最关心的指标之二，平均请求响应时间 ，后面括号中的 mean 表示这是一个平均值

Time per request:       2.919 [ms] (mean, across all concurrent requests)   # 每个请求的时间

#2.919[毫秒]（意思是说，在所有的并发请求）  每个请求实际运行时间的平均值。

#由于对于并发请求，cpu 实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个 Time per request 时间约等于第二个 Time per request 时间乘以并发请求数

Transfer rate:          93.76 [Kbytes/sec] received     #传输速率，平均每秒网络上的流量，可以帮劣排除是否存在网络流量过大导致响应时间延长的问题

Connection Times (ms)       # 连接时间（毫秒）

              min  mean[+/-sd] median   max

Connect:        0  204 398.6      1    1077

Processing:    18  384 846.8     71    2816

Waiting:       17  382 847.0     70    2812

Total:         56  588 943.3     77    2907

 

Percentage of the requests served within a certain time (ms)    #在一定的时间内提供服务的请求的百分比（毫秒）

  50%     77

  66%    120

  75%   1119

  80%   1134

  90%   2850

  95%   2868

  98%   2880

  99%   2890

 100%   2907 (longest request)

 #整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中 50％的用户响应时间小于77 毫秒，60％ 的用户响应时间小于120 毫秒，最大的响应时间小于2907 毫秒