LVS集群实验

avatar
作者
猴君
阅读量:0

NAT模式

  • 本质是多目标IP的DNAT，通过将请求报文中的目标地址和目标端口修改为某挑出的RS的RIP和PORT实现转发
  • RIP和DIP应在同一个IP网络，且应使用私网地址:RS的网关要指向DIP
  • 请求报文和响应报文都必须经由Direclor转发，Direclor易于成为系统瓶颈
  • 支持端口映射，可修改请求报文的目标PORTVS必须是Linux系统，RS可以是任意OS系统

  • 客户端发送访问请求，请求数据包中含有请求来源(cip)，访问目标地址(VIP)访问目标端口9000port)
  • VS服务器接收到访问请求做DNAT把请求数据包中的目的地由VIP换成RS的RIP和相应端口
  • RS1相应请求，发送响应数据包，包中的相应保温为数据来源(RIP1)响应目标(CIP)相应端口(9000port)
  • VS服务器接收到响应数据包，改变包中的数据来源(RIP1-->VIP),响应目标端口(9000-->80)
  • VS服务器把修改过报文的响应数据包回传给客户端
  • Ivs的NAT模式接收和返回客户端数据包时都要经过lvs的调度机，所以Ivs的调度机容易阻塞

 实验过程       

实验前准备

一台LVS（两张网卡一个仅主机，一个NAT）

一台测试机（可以用自己电脑的cmd）

webserver1（仅主机网卡）

webserver2（仅主机网卡）

虚拟机关闭防火墙和selinux

每台主机必须有可用ip

LSV主机配置

ip信息
  • NAT网卡ip  172.25.119.100/24
  • 仅主机网卡ip   169.254.199.100/24

路由信息

查看命令

route  -n

如果没有 router 命令 用下面的命令下载

yum install -y net-tools-2.0-0.62.20160912git.el9.x86_64

LVS中打开内核路由功能

在 /etc/sysctl.conf 中写入 net.ipv4.ip_forward = 1

安装ipvsadm

yum install ipvsadm -y

书写策略

[root@LVS ~]# ipvsadm -A -t 172.25.119.100:80 -s rr
[root@LVS ~]# ipvsadm -a -t 172.25.119.100:80 -r 169.254.199.10:80 -m
[root@LVS ~]# ipvsadm -a -t 172.25.119.100:80 -r 169.254.199.20:80 -m

查看策略

ipvsadm  -Ln

webserver1配置

ip信息

仅主机网卡 169.254.199.10/24

路由信息

下载http服务做测试

yum install httpd -y

开启http服务

systemctl enable --now httpd

在index.html中写入内容以做测试查看

echo webserver1  169.254.199.10 > /var/www/html/index.html

webserver2配置

ip信息

仅主机网卡 169.254.1199.20

路由信息

下载http服务做测试

yum install httpd -y

开启http服务

systemctl enable --now httpd

在index.html中写入内容以做测试查看

echo webserver2  169.254.199.20 > /var/www/html/index.html

测试

我直接用的本地主机的cmd进行的测试

DR模式

  • 客户端发送数据帧给vs调度主机帧中内容为客户端IP+客户端的MAC+VIP+VIP的MAC
  • VS调度主机接收到数据帧后把帧中的VIP的MAC该为RS1的MAC，此时帧中的数据为客户端IP+客户端的MAC+VIP+RS1的MAC
  • RS1得到2中的数据包做出响应回传数据包，数据包中的内容为VIP+RS1的MAC+客户端IP+客户端IP的MAC

DR模式的特点

  • Director和各RS都配置有VIP
  • 确保前端路由器将目标IP为VIP的请求报文发往Director
  • 在前端网关做静态绑定VIP和Director的MAC地址
  • RS的RIP可以使用私网地址，也可以是公网地址;RIP与DIP在同一IP网络;
  • RIP的网关不能指向DIP，以确保响应报文不会经由Director
  • RS和Director要在同一个物理网络
  • 请求报文要经由Director，但响应报文不经由Director，而由RS直接发往Client
  • 不支持端口映射(端口不能修败)
  • RS可使用大多数OS系统

实验

实验前准备

虚拟机关闭防火墙和selinux

五台主机：

client（一张NAT网卡 ip  172.25.119.200/24）

router（一张NAT网卡ip172.15.119.100/24 一张仅主机网卡ip 169.254.199.100）

LVS    （仅主机网卡 169.154.199.50/24   环回地址169.254.199.200/24）

webserver1   （仅主机网卡 169.154.199.10/24   环回地址169.254.199.200/24）

webserver2     （仅主机网卡 169.154.199.20/24   环回地址169.254.199.200/24）

client配置

IP信息

路由信息

router配置

ip 信息

路由信息

LVS配置

ip信息

创建环回（临时，重启后失效）

ip a a 169.254.199.200/32 dev lo

路由信息

在LVS中打开内核路由功能

写策略以及查看策略

webserver1配置

ip信息

创建环回（临时，重启后失效）

ip a a 169.254.199.200/32 dev lo

路由信息

vip(环回)不对外响应

下载http服务做测试

yum install httpd -y

开启http服务         

systemctl enable --now httpd

在index.html中写入内容以做测试查看

echo webserver1  169.254.199.10 > /var/www/html/index.html

webserver2配置

ip信息

创建环回（临时，重启后失效）

ip a a 169.254.199.200/32 dev lo

路由信息   
vip(环回)不对外响应

下载http服务做测试

yum install httpd -y

开启http服务

systemctl enable --now httpd

在index.html中写入内容以做测试查看

echo webserver1  169.254.199.10 > /var/www/html/index.html

测试

防火墙解决轮询调度的错误

以http和https为例，当我们在RS中同时开放80和443端口，那么默认控制是分开轮询的，这样我们就出现了一个轮询错乱的问题
当我第一次访问80被轮询到webserver1后下次访问443仍然可能会被轮询到webserver1上

实验

出错示范

在上面DR实验的基础上，我们做一下更改操作

DR实验的策略

ipvsadm -A -t 169.254.199.200:80  -s rr

ipvsadm -a -t 169.254.199.200:80   -r 169.254.199.10:80 -g

ipvsadm -a -t 169.254.199.200:80   -r 169.254.199.20:80 -g

我们再添加一个策略

ipvsadm -A -t 169.254.199.200:443  -s rr

ipvsadm -a -t 169.254.199.200:443 -r 169.254.199.10:443 -g

ipvsadm -a -t 169.254.199.200:443 -r 169.254.199.20:443 -g

如图

访问测试

curl 169.254.199.200;curl -k https://169.254.199.200

返回的结果将会是：

webserver1 169.254.199.10

webserver1 169.254.199.10

或者

webserver2 169.254.199.20

webserver2 169.254.199.20

   

优化示范

我们可以使用防火墙来解决轮询调度算法中的这一问题

首先我们先清除之前的策略

ipvsadm -C

然后我们给80,443端口打上标签，将他们作为一个整体

被打上标记的会视为同一个         标签名字66

写上策略

访问测试

LVS算法

静态算法

  • RR：roundrobin 轮询 RS分别被调度，当RS配置有差别时不推荐

ipvsadm -A -t 169.254.199.200:80  -s rr

  • WRR：Weighted RR，加权轮询根据RS的配置进行加权调度，性能差的RS被调度的次数少

ipvsadm -A -t 169.254.199.200:80  -s wrr

  • SH：Source Hashing，实现session sticky，源IP地址hash；将来自于同一个IP地址的请求始终发往第一次挑中的RS，从而实现会话绑定

ipvsadm -A -t 169.254.199.200:80  -s sh

  • DH：Destination Hashing；目标地址哈希，第一次轮询调度至RS，后续将发往同一个目标地址的请求始终转发至第一次挑中的RS，典型使用场景是正向代理缓存场景中的负载均衡，如：宽带运营商

ipvsadm -A -t 169.254.199.200:80 s dh

动态

  • LC：least connections（最少链接发）
  • 适用于长连接应用Overhead（负载值）=activeconns（活动链接数）x256+inactiveconns（非活 动链接数）
  • WLC：Weighted LC（权重最少链接） 默认调度方法Overhead=(activeconns ）x                      256+inactiveconns)/weight
  • SED：Shortest Expection Delay, 初始连接高权重优先Overhead=(activeconns+1+inactiveconns) x 256/weight 但是，当webserver1的权重为1，webserver2的权重为10，经过运算前几次的调度都会被node2承接
  • NQ：Never Queue，第一轮均匀分配，后续SED
  • LBLC：Locality-Based LC，动态的DH算法，使用场景：根据负载状态实现正向代理
  • LBLCR：LBLC with Replication，带复制功能的LBLC，解决LBLC负载不均衡问题，从负载重的复制 到负载轻的RS

    相关阅读
    1. 如何查看和设置我的Android N设备的权限？
    2. 如何在安卓手机上自定义应用图标？
    3. 如何在安卓微信中同时听语音和查看图片？
    4. 华为哪些设备将支持升级至安卓7.0？
    5. 微信安卓软件中Q10功能有哪些独特之处？
    6. 安卓用户如何挑选最佳视频播放器应用？
    7. 安卓系统中用户文件目录的确切位置是什么？
    8. 小米4用户如何安全升级到安卓8.0系统？
    9. 如何成功将魅蓝5升级至安卓原生7.0版本？
    10. 16GB存储的安卓手机是否能满足日常需求？

    广告一刻

    为您即时展示最新活动产品广告消息，让您随时掌握产品活动新动态！