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

相关文章

Java设计模式---迭代器模式(Iterator)解读

《Java设计模式---迭代器模式(Iterator)解读》:本文主要介绍Java设计模式---迭代器模式(Iterator),具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,... 目录1、迭代器(Iterator)1.1、结构1.2、常用方法1.3、本质1、解耦集合与遍历逻辑2、统一

Java 线程安全与 volatile与单例模式问题及解决方案

《Java线程安全与volatile与单例模式问题及解决方案》文章主要讲解线程安全问题的五个成因(调度随机、变量修改、非原子操作、内存可见性、指令重排序)及解决方案,强调使用volatile关键字... 目录什么是线程安全线程安全问题的产生与解决方案线程的调度是随机的多个线程对同一个变量进行修改线程的修改操

Redis Cluster模式配置

《RedisCluster模式配置》:本文主要介绍RedisCluster模式配置,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录分片 一、分片的本质与核心价值二、分片实现方案对比 ‌三、分片算法详解1. ‌范围分片(顺序分片)‌2. ‌哈希分片3. ‌虚

RabbitMQ工作模式中的RPC通信模式详解

《RabbitMQ工作模式中的RPC通信模式详解》在RabbitMQ中,RPC模式通过消息队列实现远程调用功能,这篇文章给大家介绍RabbitMQ工作模式之RPC通信模式,感兴趣的朋友一起看看吧... 目录RPC通信模式概述工作流程代码案例引入依赖常量类编写客户端代码编写服务端代码RPC通信模式概述在R

SQL Server身份验证模式步骤和示例代码

《SQLServer身份验证模式步骤和示例代码》SQLServer是一个广泛使用的关系数据库管理系统,通常使用两种身份验证模式:Windows身份验证和SQLServer身份验证,本文将详细介绍身份... 目录身份验证方式的概念更改身份验证方式的步骤方法一:使用SQL Server Management S

Nginx使用Keepalived部署web集群(高可用高性能负载均衡)实战案例

《Nginx使用Keepalived部署web集群(高可用高性能负载均衡)实战案例》本文介绍Nginx+Keepalived实现Web集群高可用负载均衡的部署与测试,涵盖架构设计、环境配置、健康检查、... 目录前言一、架构设计二、环境准备三、案例部署配置 前端 Keepalived配置 前端 Nginx

Redis高可用-主从复制、哨兵模式与集群模式详解

《Redis高可用-主从复制、哨兵模式与集群模式详解》:本文主要介绍Redis高可用-主从复制、哨兵模式与集群模式的使用,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝... 目录Redis高可用-主从复制、哨兵模式与集群模式概要一、主从复制(Master-Slave Repli

一文带你搞懂Redis Stream的6种消息处理模式

《一文带你搞懂RedisStream的6种消息处理模式》Redis5.0版本引入的Stream数据类型,为Redis生态带来了强大而灵活的消息队列功能,本文将为大家详细介绍RedisStream的6... 目录1. 简单消费模式(Simple Consumption)基本概念核心命令实现示例使用场景优缺点2

Nginx location匹配模式与规则详解

《Nginxlocation匹配模式与规则详解》:本文主要介绍Nginxlocation匹配模式与规则,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、环境二、匹配模式1. 精准模式2. 前缀模式(不继续匹配正则)3. 前缀模式(继续匹配正则)4. 正则模式(大

Linux系统配置NAT网络模式的详细步骤(附图文)

《Linux系统配置NAT网络模式的详细步骤(附图文)》本文详细指导如何在VMware环境下配置NAT网络模式,包括设置主机和虚拟机的IP地址、网关,以及针对Linux和Windows系统的具体步骤,... 目录一、配置NAT网络模式二、设置虚拟机交换机网关2.1 打开虚拟机2.2 管理员授权2.3 设置子