LVS-DR模式+ldirectord+keepalived+tun隧道模式+wrr权重

2023-10-13 01:50

本文主要是介绍LVS-DR模式+ldirectord+keepalived+tun隧道模式+wrr权重,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

一、LVS简介

LVS(Linux Virtual Server)即Linux虚拟服务器,是由章文嵩博士主导的开源负载均衡项目,目前LVS已经被集成到Linux内核模块中。该项目在Linux内核中实现了基于IP的数据请求负载均衡调度方案,其体系结构如图1所示,终端互联网用户从外部访问公司的外部负载均衡服务器,终端用户的Web请求会发送给LVS调度器,调度器根据自己预设的算法决定将该请求发送给后端的某台Web服务器,比如,轮询算法可以将外部的请求平均分发给后端的所有服务器,终端用户访问LVS调度器虽然会被转发到后端真实的服务器,但如果真实服务器连接的是相同的存储,提供的服务也是相同的服务,最终用户不管是访问哪台真实服务器,得到的服务内容都是一样的,整个集群对用户而言都是透明的。最后根据LVS工作模式的不同,真实服务器会选择不同的方式将用户需要的数据发送到终端用户,LVS工作模式分为NAT模式、TUN模式、以及DR模式。

二、三种工作模式简介

DR: 在LVS(TUN)模式下,由于需要在LVS调度器与真实服务器之间创建隧道连接,这同样会增加服务器的负担。与LVS(TUN)类似,DR模式也叫直接路由模式,其体系结构如图4所示,该模式中LVS依然仅承担数据的入站请求以及根据算法选出合理的真实服务器,最终由后端真实服务器负责将响应数据包发送返回给客户端。与隧道模式不同的是,直接路由模式(DR模式)要求调度器与后端服务器必须在同一个局域网内,VIP地址需要在调度器与后端所有的服务器间共享,因为最终的真实服务器给客户端回应数据包时需要设置源IP为VIP地址,目标IP为客户端IP,这样客户端访问的是调度器的VIP地址,回应的源地址也依然是该VIP地址(真实服务器上的VIP),客户端是感觉不到后端服务器存在的。由于多台计算机都设置了同样一个VIP地址,所以在直接路由模式中要求调度器的VIP地址是对外可见的,客户端需要将请求数据包发送到调度器主机,而所有的真实服务器的VIP地址必须配置在Non-ARP的网络设备上,也就是该网络设备并不会向外广播自己的MAC及对应的IP地址,真实服务器的VIP对外界是不可见的,但真实服务器却可以接受目标地址VIP的网络请求,并在回应数据包时将源地址设置为该VIP地址。调度器根据算法在选出真实服务器后,在不修改数据报文的情况下,将数据帧的MAC地址修改为选出的真实服务器的MAC地址,通过交换机将该数据帧发给真实服务器。整个过程中,真实服务器的VIP不需要对外界可见。

==TUN:==在LVS(NAT)模式的集群环境中,由于所有的数据请求及响应的数据包都需要经过LVS调度器转发,如果后端服务器的数量大于10台,则调度器就会成为整个集群环境的瓶颈。我们知道,数据请求包往往远小于响应数据包的大小。因为响应数据包中包含有客户需要的具体数据,所以LVS(TUN)的思路就是将请求与响应数据分离,让调度器仅处理数据请求,而让真实服务器响应数据包直接返回给客户端。VS/TUN工作模式拓扑结构如图3所示。其中,IP隧道(IP tunning)是一种数据包封装技术,它可以将原始数据包封装并添加新的包头(内容包括新的源地址及端口、目标地址及端口),从而实现将一个目标为调度器的VIP地址的数据包封装,通过隧道转发给后端的真实服务器(Real Server),通过将客户端发往调度器的原始数据包封装,并在其基础上添加新的数据包头(修改目标地址为调度器选择出来的真实服务器的IP地址及对应端口),LVS(TUN)模式要求真实服务器可以直接与外部网络连接,真实服务器在收到请求数据包后直接给客户端主机响应数据。

NAT:

三、 DR模式

在这里插入图片描述
四层,在数据链路层,通过mac地址。同一个局域网

vip :virtual ip–172.25.7.100
实验:
node1:172.25.7.1–lvs调度服务器
node2:172.25.7.2–后台真实服务器
node3:172.25.7.3–后台真实服务器
真机:172.25.7.250
本次实验做好后的效果应该是:
在真机上:curl 172.25.7.100,轮询机制,第一次是node2回答,第二次是node3回答,第三次是node2回答,第四次是node3回答…
实验环境配置:
node1–lvs调度器上

1.yum install ipvsadm -y #安装管理虚拟ip的软件可以使用ipvsadm --help查看帮助
2.ipvsadm -A -t 172.25.7.100:80 -s rr #添加虚拟服务-A:add virtual service with options-t:tcp协议-s:rr 模式设为rr,轮询,共10种工作模式
3.ipvsadm -a -t 172.25.7.100:80 -r 172.25.7.2:80 -g#添加真实服务-a:add real server-r:real-server-g:direct routing(default)ipvsadm -a -t 172.25.7.100:80 -r 172.25.7.3:80 -g
4.ipvsadm -ln #查看规则
5.ip addr add 172.25.7.100/24 dev eth0 #添加虚拟ip,vip
6.ip addr show eth0 #查看是否添加成功

node2–真实后端服务器

 1  yum install httpd -y #安装appache2  vim /var/www/html/index.htmlser2222  #里面的内容3  systemctl start httpd4  ip addr add 172.25.7.100/32 dev eth0  #因为是dr工作模式,所以在每个真实的后端服务器也添加vip5  ip addr show eth0  #查看是否添加上

node2–真实后端服务器

 1  yum install httpd -y #安装appache2  vim /var/www/html/index.htmlser3333 #里面的内容3  systemctl start httpd4  ip addr add 172.25.7.100/32 dev eth0  #因为是dr工作模式,所以在每个真实的后端服务器也添加vip5  ip addr show eth0  #查看是否添加上

第一次真机测试:
node2,node3的mac地址响应未DROP
真机上:

curl 172.25.7.100

有时候是node2和node3轮流回应,有时候是node2一直回应,有时候是node3一直回应.。因为node1,node2,node3都有vip:172.25.7.100,并且在同一局域网,当真机上有访问请求vip172.25.7.100的时候,node1,node2,node3会争抢,谁先抢上谁就先回答。这显然不符合lvs调度机制。
来看下效果:
1.调度器没抢上
在这里插入图片描述在这里插入图片描述2.1.调度器抢上了客户端的请求响应
在这里插入图片描述
看似这次成功了,其实是碰运气,这样可不行。
第二次真机测试:
将node2,node3的mac地址响应DROP,只有node1可以响应,不会出现调度器和后端服务器争抢vip
node2上:

yum whatprovides */arptables #查询管理mac地址的软件
yum install arptables-0.0.4-8.el7.x86_64 -y #安装
arptables -A INPUT -d 172.25.7.100 -j DROP #丢弃客户端对vip172.25.7.100的响应(让此mac闭嘴)
arptables -A OUTPUT -s 172.25.7.100 -j mangle --mangle-ip-s 172.25.7.2  #将真实后端服务器node2的响应回答,这个来源变为vip:172.25.7.100

node3上:

yum whatprovides */arptables #查询管理mac地址的软件
yum install arptables-0.0.4-8.el7.x86_64 -y #安装
arptables -A INPUT -d 172.25.7.100 -j DROP #丢弃客户端对vip172.25.7.100的响应(让此mac闭嘴)
arptables -A OUTPUT -s 172.25.7.100 -j mangle --mangle-ip-s 172.25.7.3  #将真实后端服务器node3的响应回答,这个来源变为vip:172.25.7.100

真机:
在这里插入图片描述

四、 ldirectord --监视真实服务器

该软件的作用:监视集群节点,这个程序在启动的时候自动建立IPVS表,然后监视集群节点的健康状况,在发现失效节点时(某个真实服务器损坏),自动将其从IPVS表移除

实验背景:
用户在访问vip请求的时候,假如某个后端真实服务器挂掉了,在轮询应答时,用户会看到报错。
将node2的httpd关闭(模仿该机挂掉)
在这里插入图片描述客户端看到的情况:
在这里插入图片描述如何解决此问题?
先将上个实验的ipvs删除掉:ipvsadm -C
在这里插入图片描述
1.下载ldirectord-3.9.5-3.1.x86_64.rpm
2.安装此软件。安装需要有高可用作为yum源,解决安装依赖性,yum源配置见下图:
在这里插入图片描述3.查看配置文件,并cp到/etc/ha.d/下(配置文件得cp到/etc/下)
在这里插入图片描述
4.修改配置文件
vim /etc/ha.d/ldirectord.cf
在这里插入图片描述5.重启服务并查看
在这里插入图片描述6.一般在node1调度器上也下载httpd。写入index.html文件。
作用:node1和node2都挂了,它能顶一会

在这里插入图片描述
**正常情况:**客户端连接测试,node2和node3轮询回答
在这里插入图片描述
node2挂掉:
[root@node2 ~]# systemctl stop httpd

查看规则:自动将Node2清除规则,用户访问仍然正常

在这里插入图片描述在这里插入图片描述noed3也挂掉:
规则中只有调度器本身了
在这里插入图片描述回答问题也由调度器回答,为了实验效果,node1,node2,node3下面的index.html文件不一样,其实得是一样,保证用户看到的东西都是一样的。

在这里插入图片描述

五、keepalived–给调度器加个备用

因为此实验做的是调度器的备用,所以需要再快照一个虚拟机server4,ip为172.25.7.4
接下来要做的工作是在node1和node2上都安装keepalived 并配置好文件。

1.node1安装

1.做之前先删除node1上的vip:
在这里插入图片描述2.在node1上下载keepalived

在这里插入图片描述安装并检测:

./configure --prefix=/usr/local/keepalived --with-init=systemd

在这里插入图片描述
yum install gcc -y # 安装后再次再次检测:
在这里插入图片描述
yum install openssl-devel -y #安装后再次检测

在这里插入图片描述缺失的包已安装,现在编译安装:
make & make install

在这里插入图片描述

2.node2安装

1.从node1上scp过去一个keepalived安装包
2. yum install gcc -y  #安装依赖性软件gcc
3. yum install openssl-devel -y #安装依赖性软件openssl
4. #指定安装路径
5.  #编译并安装

3.node1和node4做软链接

node1:
1.ln -s /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
2.ln -s /usr/local/keepalived/etc/keepalived/ /etc/
3.ln -s /usr/local/keepalived/sbin/keepalived /sbin/node4:
1.ln -s /usr/local/keepalived/etc/sysconfig/keepalived /etc/sysconfig/
2.ln -s /usr/local/keepalived/etc/keepalived/ /etc/
3.ln -s /usr/local/keepalived/sbin/keepalived /sbin/

在这里插入图片描述在这里插入图片描述

4.修改配置文件

首先把上个实验的ldirectord服务给关闭了,并设置开机不自启

systemctl stop ldirectord.service
systemctl disable ldirectord.service

在这里插入图片描述

在这里插入图片描述

将换好后的配置文件scp复制给node4一份:
在这里插入图片描述
将第18行stat改为BACKUP,优先级改为50

在这里插入图片描述

5.node1和node4都重启keepalived服务

在这里插入图片描述在这里插入图片描述node1上查看规则:

在这里插入图片描述
node4上安装ipvsamd 并查看规则:
yum install ipvsadm -y
在这里插入图片描述

6.测试

要想看到轮回效果,还需要把配置文件的第36行保持会话功能注释掉。

在这里插入图片描述
真机测试:

在这里插入图片描述现在加入node1挂掉,客户端是否受影响,当然不会,node4顶上:
在这里插入图片描述
客户端一切正常:
在这里插入图片描述

六、wrr模式,给后端服务器设置权重

所需主机:三台,node1,node2,noed31.node1添加规则:

1.ipvsadm -A -t 172.25.7.100:80 -s wrr
2.ipvsadm -a -t 172.25.7.100:80 -r 172.25.7.2:80 -g -w 2 #-g是dr模式
3.ipvsadm -a -t 172.25.7.100:80 -r 172.25.7.3:80 -g -w 1
4. ip addr add 172.25.7.100 dev eth0#添加vip

查看规则是否添加上:

ipvsadm -ln

在这里插入图片描述

客户端测试:

在这里插入图片描述

七、隧道模式

在这里插入图片描述做之前清楚原有规则ipvsadm -C

在这里插入图片描述
node1:

 1.modprobe ipip2.ip addr del 172.25.7.100/32 dev eth0 #删除原来的etho里的vip3. ip addr add 172.25.7.100/24 dev tunl0 #将vip加到隧道里4.ip link set up tunl05.ipvsadm -A -t 172.25.7.100:80 -s rr6. ipvsadm -a -t 172.25.7.100:80 -r 172.25.7.2 -i #-i隧道模式7. ipvsadm -a -t 172.25.7.100:80 -r 172.25.7.3 -i8.ipvsadm -ln

在这里插入图片描述node2:

 1. ip addr del 172.25.7.100/32 dev eth02. modprobe ipip3. ip addr add 172.25.7.100/32 dev tunl04. ip link set up tunl05. sysctl -a|grep rp_filter #查看一下,将所有1变为06. sysctl -w net.ipv4.conf.all.rp_filter=07. sysctl -w net.ipv4.conf.default.rp_filter=08. sysctl -w net.ipv4.conf.eth0.rp_filter=09. sysctl -w net.ipv4.conf.tunl0.rp_filter=010. sysctl -a|grep rp_filter #检查一下11. sysctl -p

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
node3:

 1. ip addr del 172.25.7.100/32 dev eth02. modprobe ipip3. ip addr add 172.25.7.100/32 dev tunl04. ip link set up tunl05. sysctl -a|grep rp_filter #查看一下,将所有1变为06. sysctl -w net.ipv4.conf.all.rp_filter=07. sysctl -w net.ipv4.conf.default.rp_filter=08. sysctl -w net.ipv4.conf.eth0.rp_filter=09. sysctl -w net.ipv4.conf.tunl0.rp_filter=010. sysctl -a|grep rp_filter #检查一下11. sysctl -p

客户端测试:
在这里插入图片描述

这篇关于LVS-DR模式+ldirectord+keepalived+tun隧道模式+wrr权重的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/199944

相关文章

在JS中的设计模式的单例模式、策略模式、代理模式、原型模式浅讲

1. 单例模式(Singleton Pattern) 确保一个类只有一个实例,并提供一个全局访问点。 示例代码: class Singleton {constructor() {if (Singleton.instance) {return Singleton.instance;}Singleton.instance = this;this.data = [];}addData(value)

模版方法模式template method

学习笔记,原文链接 https://refactoringguru.cn/design-patterns/template-method 超类中定义了一个算法的框架, 允许子类在不修改结构的情况下重写算法的特定步骤。 上层接口有默认实现的方法和子类需要自己实现的方法

【iOS】MVC模式

MVC模式 MVC模式MVC模式demo MVC模式 MVC模式全称为model(模型)view(视图)controller(控制器),他分为三个不同的层分别负责不同的职责。 View:该层用于存放视图,该层中我们可以对页面及控件进行布局。Model:模型一般都拥有很好的可复用性,在该层中,我们可以统一管理一些数据。Controlller:该层充当一个CPU的功能,即该应用程序

迭代器模式iterator

学习笔记,原文链接 https://refactoringguru.cn/design-patterns/iterator 不暴露集合底层表现形式 (列表、 栈和树等) 的情况下遍历集合中所有的元素

《x86汇编语言:从实模式到保护模式》视频来了

《x86汇编语言:从实模式到保护模式》视频来了 很多朋友留言,说我的专栏《x86汇编语言:从实模式到保护模式》写得很详细,还有的朋友希望我能写得更细,最好是覆盖全书的所有章节。 毕竟我不是作者,只有作者的解读才是最权威的。 当初我学习这本书的时候,只能靠自己摸索,网上搜不到什么好资源。 如果你正在学这本书或者汇编语言,那你有福气了。 本书作者李忠老师,以此书为蓝本,录制了全套视频。 试

利用命令模式构建高效的手游后端架构

在现代手游开发中,后端架构的设计对于支持高并发、快速迭代和复杂游戏逻辑至关重要。命令模式作为一种行为设计模式,可以有效地解耦请求的发起者与接收者,提升系统的可维护性和扩展性。本文将深入探讨如何利用命令模式构建一个强大且灵活的手游后端架构。 1. 命令模式的概念与优势 命令模式通过将请求封装为对象,使得请求的发起者和接收者之间的耦合度降低。这种模式的主要优势包括: 解耦请求发起者与处理者

springboot实战学习(1)(开发模式与环境)

目录 一、实战学习的引言 (1)前后端的大致学习模块 (2)后端 (3)前端 二、开发模式 一、实战学习的引言 (1)前后端的大致学习模块 (2)后端 Validation:做参数校验Mybatis:做数据库的操作Redis:做缓存Junit:单元测试项目部署:springboot项目部署相关的知识 (3)前端 Vite:Vue项目的脚手架Router:路由Pina:状态管理Eleme

状态模式state

学习笔记,原文链接 https://refactoringguru.cn/design-patterns/state 在一个对象的内部状态变化时改变其行为, 使其看上去就像改变了自身所属的类一样。 在状态模式中,player.getState()获取的是player的当前状态,通常是一个实现了状态接口的对象。 onPlay()是状态模式中定义的一个方法,不同状态下(例如“正在播放”、“暂停

软件架构模式:5 分钟阅读

原文: https://orkhanscience.medium.com/software-architecture-patterns-5-mins-read-e9e3c8eb47d2 软件架构模式:5 分钟阅读 当有人潜入软件工程世界时,有一天他需要学习软件架构模式的基础知识。当我刚接触编码时,我不知道从哪里获得简要介绍现有架构模式的资源,这样它就不会太详细和混乱,而是非常抽象和易

使用Spring Boot集成Spring Data JPA和单例模式构建库存管理系统

引言 在企业级应用开发中,数据库操作是非常重要的一环。Spring Data JPA提供了一种简化的方式来进行数据库交互,它使得开发者无需编写复杂的JPA代码就可以完成常见的CRUD操作。此外,设计模式如单例模式可以帮助我们更好地管理和控制对象的创建过程,从而提高系统的性能和可维护性。本文将展示如何结合Spring Boot、Spring Data JPA以及单例模式来构建一个基本的库存管理系统