LVS集群实验

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值