五、LVS原理

目录

5.1 LVS 相关原理 

5.1.1 LVS集群的体系结构以及特点

5.1.1.1 LVS简介

5.1.1.2 LVS体系结构

5.1.1.3 LVS相关术语

5.1.1.4 LVS工作模式

5.1.1.5 LVS调度算法

5.1.2 LVS-DR集群介绍

5.1.2.1 LVS-DR模式工作原理

5.1.2.2 LVS-DR模式应用特点

5.1.2.3 LVS-DR模式ARP抑制

5.1.3 LVS – NAT 模式

5.1.4 LVS – TUN 模式

5.1.5 ipvsadm工具使用

5.1.5.1 实例 1

5.1.5.2 大写和小写选项的实际应用

5.1.5.3 ipvsadm-save

5.1.5.4 开机自启加载


5.1 LVS 相关原理 

5.1.1 LVS集群的体系结构以及特点

5.1.1.1 LVS简介

LVS是Linux Virtual Server的简称,也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目,它的官方站点是www.linuxvirtualserver.org。现在LVS已经是 Linux标准内核的一部分,在Linux2.4内核以前,使用LVS时必须要重新编译内核以支持LVS功能模块,但是从Linux2.4内核以后,已经完全内置了LVS的各个功能模块,无需给内核打任何补丁,可以直接使用LVS提供的各种功能。

使用LVS技术要达到的目标是:通过LVS提供的负载均衡技术和Linux操作系统实现一个高性能、高可用的服务器群集,它具有良好可靠性、可扩展性和可操作性。从而以低廉的成本实现最优的服务性能。

LVS自从1998年开始,发展到现在已经是一个比较成熟的技术项目了。可以利用LVS技术实现高可伸缩的、高可用的网络服务,例如WWW服务、Cache服务、DNS服务、FTP服务、MAIL服务、视频/音频点播服务等等,有许多比较著名网站和组织都在使用LVS架设的集群系统,例如:Linux的门户网站(www.linux.com)、向RealPlayer提供音频视频服务而闻名的Real公司(www.real.com)、全球最大的开源网站(sourceforge.net)等。

5.1.1.2 LVS体系结构

使用LVS架设的服务器集群系统有三个部分组成:最前端的负载均衡层,用Load Balancer表示,中间的服务器群组层,用Server Array表示,最底端的数据共享存储层,用Shared Storage表示。

​        Load Balancer层:位于整个集群系统的最前端,有一台或者多台负载调度器(Director Server)组成,LVS模块就安装在Director Server上,而Director的主要作用类似于一个路由器,它含有完成LVS功能所设定的路由表,通过这些路由表把用户的请求分发给Server Array层的应用服务器(Real Server)上。同时,在Director Server上还要安装对Real Server服务的监控模块Ldirectord,此模块用于监测各个Real Server服务的健康状况。在Real Server不可用时把它从LVS路由表中剔除,恢复时重新加入。

​        Server Array层:由一组实际运行应用服务的机器组成,Real Server可以是WEB服务器、MAIL服务器、FTP服务器、DNS服务器、视频服务器中的一个或者多个,每个Real Server之间通过高速的LAN或分布在各地的WAN相连接。在实际的应用中,Director Server也可以同时兼任Real Server的角色。

​        Shared Storage层:是为所有Real Server提供共享存储空间和内容一致性的存储区域,在物理上,一般有磁盘阵列设备组成,为了提供内容的一致性,一般可以通过NFS网络文件系统共享数据,但是NFS在繁忙的业务系统中,性能并不是很好,此时可以采用集群文件系统,例如Red hat的GFS文件系统,oracle提供的OCFS2文件系统等。

5.1.1.3 LVS相关术语

为了方便大家探讨LVS技术,LVS社区提供了一个命名的约定,内容如下表

名称缩写说明
虚拟IP地址(Virtual IP Address)VIPDirector用于向客户端计算机提供服务的IP地址
真实IP地址(Real Server IP Address)RIP在集群下面节点上使用的IP地址
Director的IP地址(Director IP Address)DIPDirector用于连接内外网网络的IP地址
客户端主机IP地址(Client IP Address)CIP客户端用户计算机请求集群服务器的IP地址,该地址用作发送给集群的请求的源IP地址


LVS集群内部的节点称为真实服务器(Real Serve),也叫做集群节点。请求集群服务的计算机称为客户计算机。与计算机通常在网上交换数据包的方式相同,客户计算机、Director和真实服务器使用IP地址彼此进行通信。不同架构角色命名情况如下图:

5.1.1.4 LVS工作模式

LVS的IP负载均衡技术是通过IPVS模块来实现的,IPVSLVS集群系统的核心软件,它的主要作用是:安装在Director Server上,同时在Director Server上虚拟出一个IP地址,用户必须通过这个虚拟的IP地址访问服务。这个虚拟IP一般称为LVS的VIP,即Virtual IP。访问的请求首先经过VIP到达负载调度器,然后由负载调度器从Real Server列表中选取一个服务节点响应用户的请求
  当用户的请求到达负载调度器后,调度器如何将请求发送到提供服务的Real Server节点,而Real Server节点如何返回数据给用户,是IPVS实现的重点技术,IPVS实现负载均衡机制有三种,分别是NAT、TUN和DR。

VS/NAT: 即(Virtual Server via Network Address Translation)
  也就是网络地址翻译技术实现虚拟服务器,当用户请求到达调度器时,调度器将请求报文的目标地址(即虚拟IP地址)改写成选定的Real Server地址,同时报文的目标端口也改成选定的Real Server的相应端口,最后将报文请求发送到选定的Real Server。在服务器端得到数据后,Real Server返回数据给用户时,需要再次经过负载调度器将报文的源地址和源端口改成虚拟IP地址和相应端口,然后把数据发送给用户,完成整个负载调度过程。

VS/TUN :即(Virtual Server via IP Tunneling)
  也就是IP隧道技术实现虚拟服务器。它的连接调度和管理与VS/NAT方式一样,只是它的报文转发方法不同,VS/TUN方式中,调度器采用IP隧道技术将用户请求转发到某个Real Server,而这个Real Server将直接响应用户的请求,不再经过前端调度器,此外,对Real Server的地域位置没有要求,可以和Director Server位于同一个网段,也可以是独立的一个网络。因此,在TUN方式中,调度器将只处理用户的报文请求,集群系统的吞吐量大大提高。

VS/DR: 即(Virtual Server via Direct Routing) 
  也就是用直接路由技术实现虚拟服务器。它的连接调度和管理与VS/NAT和VS/TUN中的一样,但它的报文转发方法又有不同,VS/DR通过改写请求报文的MAC地址,将请求发送到Real Server,而Real Server将响应直接返回给客户,免去了VS/TUN中的IP隧道开销。这种方式是三种负载调度机制中性能最高最好的,但是必须要求Director Server与Real Server都有一块网卡连在同一物理网段上。

特别提示:(VS/DR)模式是互联网使用的最多多的一种模式,在LVS-DR配置中,Director将所有入站请求转发给集群内部节点,但集群内部的节点直接将他们的回复发送给客户端计算机(没有通过Director回来)。如下图所示

模式NATTUNDR
Real ServeranyTunnelingNon-arp device
Real server networkprivateLAN/WANLAN
Real server numberlow (10~20)High (100)High (100)
Real server gatewayload balancerown routerOwn router
优点端口转换支持WAN性能最好
缺点性能瓶颈需要支持隧道,不支持端口转换

不支持跨网段和端口转换

工作层次网络层、传输层网络层、传输层数据链路层、网络层

解释:

  • NAT: 这种模式适用于任何类型的Real Server,Real Server网络通常是私有的,最多支持10到20个Real Server,Real Server的网关是负载均衡器。优点是可以进行端口转换,缺点是存在性能瓶颈。它主要工作在OSI模型的第三层(网络层)和第四层(传输层)。NAT允许内部网络使用私有IP地址,并通过公共IP地址进行外部通信。
  • TUN: 这种模式要求Real Server支持隧道,Real Server网络可以是局域网或广域网,支持较多数量的Real Server(高达100个),Real Server有自己的路由器。优点是支持WAN,缺点是需要支持隧道,不支持端口转换。这种技术可以用于实现虚拟专用网(VPN),并通常工作在OSI模型的第三层(网络层)和第四层(传输层)。
  • DR: 这种模式适用于非ARP设备的Real Server,Real Server网络是局域网,同样支持大量Real Server(高达100个),Real Server有自己的路由器。优点是性能最佳,缺点是不支持跨网段和端口转换。工作在数据链路层。

5.1.1.5 LVS调度算法

调度方法决定了如何在这些集群节点之间分布工作负荷。

​    当Director收到来自客户端计算机访问她的VIP上的集群服务的入站请求时,Director必须决定那个集群节点应该获得请求。Director可用于做出该决定的调度方法分成两个基本类别:

固定调度算法:rr,wrr,dh,sh

动态调度算法:lc, wlc,lblc,lblcr,SED,NQ(后两种官方站点没提到)

10种调度算法见如下表格:

算法                                                                           说明
rr循环调度(Round-Robin),它将请求依次分配不同的RS,也就是在RS中均匀请求。这种算法简单,但是只适合于处理性能相差不大的情况
wrr加权轮循调度(Weighted Round-Robin)它将依据不同RS的权重分配任务。权重较高的RS将优先获得任务,并且分配到的连接数将比权重较低的RS更多。相同权重的RS得到相同数目的连接数。
dh目的哈希调度(Destination Hashing)以目的地为关键字查找一个静态hash表来获得需要的RS。
sh源地址哈希调度(source hashing)以源地址为关键字查找一个静态hash表来获得需要的RS。
wlc加权最小连接数调度(weighted leastconnection)假设各台RS的权重依次为wi(i=1..n),当前的TCP连接数依次为Ti (i=1..n),依次选取Ti/Wi为最小的RS作为下一个分配的RS。
lc最小连接数调度(Least-Connection),IPVS表存储了所有的活动的连接。把新的连接请求发送到当前连接数最小的RS。
lbcl基于地址的最小连接数调度(locality-Based Least-Connection)将来自同一目的地的请求分配给同一台RS如果这台服务器尚未负荷,则分配给连接数最小的RS,并以它为下一次分配的首先考虑。
lbclcr基于地址带重复最小连接数调度(Locality-Based Least-Connection with Replication)对于某一目的地,为其分配子集中连接数最小RS;如果服务器中所有子集均已满负荷,则从集群中选择一个连接数较小服务器,将它加入到此子集并分配连接;若一定时间内,未做任何修改,则将子集中负载最大的节点从子集删除。
SED最短期望的延迟(shortest expected delay scheduling SED)(SED)基于wlc算法。这个必须举例来说了ABC三台机器分别权重123,连接数也分别是123.那么如果使用wlc算法的话一个新请求进入时它可能会分给ABC中的任意一个。 使用sed算法后会进这样一个运算 A(1+1)/1 B(1+2)/2 C(1+3)/3 根据运算结果,把连接交给C。
NQ最少队列调度(Never Queue Scheduling NQ)(NQ)无需队列。如果有realserver的连接数=0就直接分配过去,不需要在进行sed运算


详细讲述最常用的四种调度算法:

轮询调度(Round Robin)

  “轮询”调度也叫1:1调度,调度器通过“轮询”调度算法将外部用户请求按顺序1:1的分配到集群中的每个Real Server上,这种算法平等地对待每一台Real Server,而不管服务器上实际的负载状况和连接状态。 

加权轮询调度(Weighted Round Robin)

  “加权轮询”调度算法是根据Real Server的不同处理能力来调度访问请求。可以对每台Real Server设置不同的调度权值,对于性能相对较好的Real Server可以设置较高的权值,而对于处理能力较弱的Real Server,可以设置较低的权值,这样保证了处理能力强的服务器处理更多的访问流量。充分合理的利用了服务器资源。同时,调度器还可以自动查询Real Server的负载情况,并动态地调整其权值。

最少链接调度(Least Connections) 

“最少连接”调度算法动态地将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能,采用“最小连接”调度算法可以较好地均衡负载。

加权最少链接调度(Weighted Least Connections)

   “加权最少链接调度”是“最少连接调度”的超集,每个服务节点可以用相应的权值表示其处理能力,而系统管理员可以动态的设置相应的权值,缺省权值为1,加权最小连接调度在分配新连接请求时尽可能使服务节点的已建立连接数和其权值成正比。

静态方法 仅根据算法本身进行调度

1、轮询算法RR:roundrobin,轮询,较常用

2、加权轮询算法WRR:Weighted RR,较常用

3、源地址哈希算法SH:Source Hashing,实现session sticky,源IP地址hash;将来自于同一个IP地址 的请求始终发往第一次挑中的RS,从而实现会话绑定 NAT 多目标的DNAT,四层,支持端口修改,请求报文和响应报文都要经过LVS DR 默认模式,二层,只修改MAC,不支持端口修改,性能好,LVS负载比小,LVS和RS并在同一网段,请求 报文经过LVS,响应报文不经过LVS TUNNEL 三层,添加一个新的IP头,支持LVS和RS并在不在同一网段,不支持端口修改,请求报文经过 LVS,响应报文不经过LVS FULLNAT 多目标的SNAT+DNAT,四层,支持端口修改,请求报文和响应报文都要经过LVS

4、目标地址哈希算法DH:Destination Hashing;目标地址哈希,第一次轮询调度至RS,后续将发往 同一个目标地址的请求始终转发至第一次挑中的RS,典型使用场景是正向代理缓存场景中的负载均衡, 如: Web缓存

动态方法

主要根据每RS当前的负载状态及调度算法进行调度Overhead=value 较小的RS将被调度

1、最少连接算法LC:least connections 适用于长连接应用

Overhead=activeconns*256+inactiveconns

2、加权最少连接算法WLC:Weighted LC,默认调度方法,较常用

Overhead=(activeconns*256+inactiveconns)/weight

3、最短期望延迟算法SED:Shortest Expection Delay,初始连接高权重优先,只检查活动连接,而不考虑 非活动连接

Overhead=(activeconns+1)*256/weight

4、最少队列算法NQ:Never Queue,第一轮均匀分配,后续SED

5、基于局部的最少连接算法LBLC:Locality-Based LC,动态的DH算法,使用场景:根据负载状态实现 正向代理,实现Web Cache等

6、带复制的基于局部的最少连接算法LBLCR:LBLC with Replication,带复制功能的LBLC,解决LBLC 负载不均衡问题,从负载重的复制到负载轻的RS,,实现Web Cache等

内核版本 4.15 版本后新增调度算法:FO和OVF FO(Weighted Fail Over)调度算法,在此FO算法中,遍历虚拟服务所关联的真实服务器链表,找到还未 过载(未设置IP_VS_DEST_F_OVERLOAD标志)的且权重最高的真实服务器,进行调度,属于静态算法

OVF(Overflow-connection)调度算法,基于真实服务器的活动连接数量和权重值实现。将新连接调度 到权重值最高的真实服务器,直到其活动连接数量超过权重值,之后调度到下一个权重值最高的真实服 务器,在此OVF算法中,遍历虚拟服务相关联的真实服务器链表,找到权重值最高的可用真实服务器。,属 于动态算法 一个可用的真实服务器需要同时满足以下条件:

未过载(未设置IP_VS_DEST_F_OVERLOAD标志)

真实服务器当前的活动连接数量小于其权重值

其权重值不为零

5.1.2 LVS-DR集群介绍

LVS的基本工作原理

  1. 当用户向负载均衡调度器(Director Server)发起请求,调度器将请求发往至内核空间

  2. PREROUTING链首先会接收到用户请求,判断目标IP确定是本机IP,将数据包发往INPUT链

  3. IPVS是工作在INPUT链上的,当用户请求到达INPUT时,IPVS会将用户请求和自己已定义好的集群服务进行比对,如果用户请求的就是定义的集群服务,那么此时IPVS会强行修改数据包里的目标IP地址及端口,并将新的数据包发往POSTROUTING链

  4. POSTROUTING链接收数据包后发现目标IP地址刚好是自己的后端服务器,那么此时通过选路,将数据包最终发送给后端的服务器

5.1.2.1 LVS-DR模式工作原理

首先,来自客户端计算机CIP的请求被发送到Director的VIP。然后Director使用相同的VIP目的IP地址将请求发送到集群节点或真实服务器。然后,集群某个节点将回复该数据包,并将该数据包直接发送到客户端计算机(不经过director),并且以此回复数据包使用的目的VIP 地址作为源IP地址。因此,实际上是客户计算机被“欺骗”了,客户计算机始终认为它正与同一台计算机对话,而实际上它正在发送请求数据包给一台计算机(LB),并从另一台计算机(RS)接收回复的数据包。

LVS DR模式集群结构图分解展示:

图1:LVS DR模式集群结构图

图2:客户端准备发出请求报文

图3:报文到达调度器后的改变

图4:RS处理报文后的报文情况

5.1.2.2 LVS-DR模式应用特点

1)所有集群节点RS必须和Director在相同的物理网段(即同一个局域网中);
2)所有客户端入站(而不是出站)请求由Director首先接收,并转发给集群节点RS;
3)集群节点RS通常来说最好带外部IP,而不使用Director及某固定机器作为默认网关,以便将数据包直接回复给客户端计算机,且不会产生回包的瓶颈;
4)所有集群节点RS上必须在lo网卡上绑定VIP地址,以便验证通过目的IP非RS的数据包;
5)由于所有集群节点RS上必须在lo网卡上绑定VIP地址,因此,带来arp问题,即集群节点RS默认会相应发往Director VIP的数据包。因此要对所有集群节点RS做ARP抑制处理,把响应VIP的请求交给LVS Director;
6)很多操作系统都可以用在集群内部的RS真实服务器上只要该操作系统能够实现ARP隐藏,如:Windows,linux,unix;
7)LVS/DR模式不需要开启调度器转发功能,这点和LVS/NAT模式是不同的。
8)LVS/DR Director(服务器数量100台)可以比LVS-NAT Director(服务器数量10-20台)承受更多的并发请求和转发更多的服务器数量。

5.1.2.3 LVS-DR模式ARP抑制

如果不抑制RS端arp影响

图1:抑制RS端arp前的广播情况 图2:抑制RS端arp前响应情况 提示:广播消息会通过物理网卡到达真实服务器,而真实服务器上有VIP,所以,会响应此请求

抑制RS端arp响应后

图1:抑制RS端arp后广播情况                                 图2:抑制RS后arp响应情况图

LVS DR类型:

1、让前端路由将请求发往VIP时,只能是Dirctor上的VIP;

解决方案:

(1) 静态地址绑定;

未必有路由器的配置权限;

Director调用时静态地址绑定将难以适用;

(2) arptables

Disable ARP for VIP

Basically, we have the following commands to disable ARP for VIP at real servers.

arptables -F

arptables -A INPUT -d $VIP -j DROP

arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP

(3) 修改Linux内核参数,将RS上的VIP配置为lo接口的别名,限制Linux仅对对应接口的ARP请求做响应;

完整过程流程图

这张图展示了一个典型的Linux Virtual Server (LVS) 系统的网络拓扑结构,其中包含了不同的网络设备和服务器角色。这个系统采用了Direct Routing (DR) 模式,这是一种LVS负载均衡技术,用于在多台Real Server之间分发流量。

  1. Internet: 连接到互联网的客户端发起HTTP请求,例如访问一个网站。
  2. LVS: Linux Virtual Server作为负载均衡器,它拥有两个网络接口eth0和eth1,并配置了VIP (Virtual IP Address),即10.0.0.100/32。 eth0连接到内部网络,eth1连接到外部网络。LVS通过路由协议RIP学习到DIPs (Director IP Addresses) 的信息。
  3. Router: 路由器负责将数据包从LVS发送到Real Servers,并将响应的数据包返回给LVS。
  4. Real Servers: 两台Real Server (RS1 和 RS2) 分别运行在不同的子网中,它们都拥有自己的DIP (Director IP Address) 并监听相同的端口80。在DR模式下,LVS将修改数据包的目标MAC地址,使其指向Real Server的MAC地址,这样数据包就可以直接到达Real Server,而不需要经过路由器或防火墙。
  5. Firewall: 防火墙可能位于LVS和Real Server之间,提供安全保护。
  6. Switch: 开关连接了Real Server和路由器。

表格显示了数据包在网络中的传输路径:

  1. 客户端发出HTTP请求,源IP地址为192.168.10.123,源MAC地址为MACinternet,目的IP地址为10.0.0.100,目的MAC地址为MACrouter-eth1
  2. 数据包到达路由器eth1接口,源IP地址为192.168.10.123,源MAC地址为MACrouter-eth0,目的IP地址为10.0.0.100,目的MAC地址为MAClvs
  3. LVS收到数据包,源IP地址为192.168.10.123,源MAC地址为MACIys,目的IP地址为10.0.0.100,目的MAC地址为MACrs1
  4. 数据包到达RS1,源IP地址为10.0.0.100,源MAC地址为MACrs1 eth0,目的IP地址为192.168.10.123,目的MAC地址为MACrouter-eth0
  5. RS1响应数据包,源IP地址为10.0.0.100,源MAC地址为MACrouter-eth1,目的IP地址为192.168.10.123,目的MAC地址为MACinternet

在这个例子中,LVS使用DR模式将请求直接转发到Real Server,然后Real Server直接将响应发送回客户端,无需经过LVS。这种模式的优点是可以提高效率,因为数据包不会在LVS和Real Server之间来回传递。

DR模式的特点:

1. Director和各RS都配置有VIP

2. 确保前端路由器将目标IP为VIP的请求报文发往Director

        在前端网关做静态绑定VIP和Director的MAC地址

        在RS上使用arptables工具

arptables -A IN -d $VIP -j DROP

arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP

在RS上修改内核参数以限制arp通告及应答级别

不主动不负责不拒绝--M49-强福安语录

/proc/sys/net/ipv4/conf/all/arp_ignore

/proc/sys/net/ipv4/conf/all/arp_announce

3. RS的RIP可以使用私网地址,也可以是公网地址;RIP与DIP在同一IP网络;RIP的网关不能指向 DIP,以确保响应报文不会经由Director

4. RS和Director要在同一个物理网络

5. 请求报文要经由Director,但响应报文不经由Director,而由RS直接发往Client

6. 不支持端口映射(端口不能修改)

7. 无需开启 ip_forward

8. RS可使用大多数OS系统

5.1.3 LVS – NAT 模式

LVS/NAT原理

(a). 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP

(b). PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链

(c). IPVS比对数据包请求的服务是否为集群服务,若是,修改数据包的目标IP地址为后端服务器IP,然后将数据包发至POSTROUTING链。 此时报文的源IP为CIP,目标IP为RIP

(d). POSTROUTING链通过选路,将数据包发送给Real Server

(e). Real Server比对发现目标为自己的IP,开始构建响应报文发回给Director Server。 此时报文的源IP为RIP,目标IP为CIP

(f). Director Server在响应客户端前,此时会将源IP地址修改为自己的VIP地址,然后响应给客户端。 此时报文的源IP为VIP,目标IP为CIP

工作逻辑图

模式特点

  • 集群节点,必须在一个网络中

  • 真实服务器必须将网关指向负载调度器

  • RIP 通常都是私有 IP,仅用于各个集群节点通信

  • 负载调度器必须位于客户端和真实服务器之间,充当网关

  • 支持端口映射

  • 负载调度器操作系统必须是 Linux ,真实服务器可以使用任意系统

5.1.4 LVS – TUN 模式

LVS/TUN原理

(a) 当用户请求到达Director Server,此时请求的数据报文会先到内核空间的PREROUTING链。 此时报文的源IP为CIP,目标IP为VIP 。

(b) PREROUTING检查发现数据包的目标IP是本机,将数据包送至INPUT链

(c) IPVS比对数据包请求的服务是否为集群服务,若是,在请求报文的首部再次封装一层IP报文,封装源IP为为DIP,目标IP为RIP。然后发至POSTROUTING链。 此时源IP为DIP,目标IP为RIP

(d) POSTROUTING链根据最新封装的IP报文,将数据包发至RS(因为在外层封装多了一层IP首部,所以可以理解为此时通过隧道传输)。 此时源IP为DIP,目标IP为RIP

(e) RS接收到报文后发现是自己的IP地址,就将报文接收下来,拆除掉最外层的IP后,会发现里面还有一层IP首部,而且目标是自己的lo接口VIP,那么此时RS开始处理此请求,处理完成之后,通过lo接口送给eth0网卡,然后向外传递。 此时的源IP地址为VIP,目标IP为CIP

(f) 响应报文最终送达至客户端

工作逻辑图

模式特点

  • 集群节点不必位于同一个物理网络但必须都拥有公网 IP(或都可以被路由)

  • 真实服务器不能将网关指向负载调度器

  • RIP 必须是公网地址

  • 负载调度器只负责入站请求

  • 不支持端口映射功能

  • 发送方和接收方必须支持隧道功能

5.1.5 ipvsadm工具使用

安装ipvsadm

[root@localhost ~]# yum install ipvsadm

常用的参数

-A --add-service添加一条新的虚拟服务
-E --edit-service编辑虚拟服务
-D --delete-service删除虚拟服务
-C --clear清除所有的虚拟服务规则
-R --restore恢复虚拟服务规则
-a --add-server在一个虚拟服务中添加一个新的真实服务器
-e --edit-server编辑某个真实服务器
-d --delete-server删除某个真实服务器
-L | -l --list显示内核中的虚拟服务规则
-n --numeric以数字形式显示IP端口
-c --connection显示ipvs中目前存在的连接,也可以用于分析调度情况
-Z --zero将转发消息的统计清零
-p --persistent配置持久化时间
--set tcp tcpfin udp配置三个超时时间(tcp/tcpfin/udp)
-t | -uTCP/UDP协议的虚拟服务
-g | -m | -iLVS模式为:DR | NAT | TUN
-w配置真实服务器的权重
-s配置负载均衡算法,如:rr, wrr, lc等
--timeout显示配置的tcp/tcpfin/udp超时时间
--stats显示历史转发消息统计(累加值)
--rate显示转发速率信息(瞬时值)

示例:

  1.  管理虚拟服务

  • 添加一个虚拟服务192.168.1.100:80,使用轮询算法

ipvsadm -A -t 192.168.1.100:80 -s rr
  • 修改虚拟服务的算法为加权轮询

ipvsadm -E -t 192.168.1.100:80 -s wrr
  • 删除虚拟服务

ipvsadm -D -t 192.168.1.100:80
  1. 管理真实服务

  • 添加一个真实服务器192.168.1.123,使用DR模式,权重2

ipvsadm -a -t 192.168.1.100:80 -r 192.168.1.123 -g -w 2
  • 修改真实服务器的权重

ipvsadm -e -t 192.168.1.100:80 -r 192.168.1.123 -g -w 5
  • 删除真实服务器

ipvsadm -d -t 192.168.1.100:80 -r 192.168.1.123
  1. 查看统计

  • 查看当前配置的虚拟服务和各个RS的权重

ipvsadm -Ln

 查看当前ipvs模块中记录的连接(可用于观察转发情况)

ipvsadm -lnc
  • 查看ipvs模块的转发情况统计

ipvsadm -Ln --stats | --rate

另外,--stats和--rate统计在分析问题时经常用到,输出各项的含义:

--stat选项是统计自该条转发规则生效以来的包

1. Conns  (connections scheduled) 已经转发过的连接数 
2. InPkts  (incoming packets)    入包个数 
3. OutPkts (outgoing packets)    出包个数 
4. InBytes (incoming bytes)     入流量(字节)  
5. OutBytes (outgoing bytes)     出流量(字节)

--rate选项是显示速率信息

1. CPS   (current connection rate)  每秒连接数 
2. InPPS  (current in packet rate)  每秒的入包个数 
3. OutPPS  (current out packet rate)  每秒的出包个数 
4. InBPS  (current in byte rate)   每秒入流量(字节) 
5. OutBPS  (current out byte rate)   每秒入流量(字节) 

5.1.5.1 实例 1

首先,创建一个HTTP服务,使用轮询(Round Robin)调度算法。

[root@localhost /] ipvsadm -A -t 192.168.239.151:80 -s rr
[root@localhost /] ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.239.151:80 rr

接下来,创建一个数据库服务,使用加权最小连接(Weighted Least Connections)调度算法。

[root@localhost /] ipvsadm -A -t 192.168.239.151:3306 -s wlc

添加第二个后端服务器至HTTP服务

1[root@localhost /] ipvsadm -a -t 192.168.239.151:80 -r 192.168.239.149:80 -m

添加后端服务器至数据库服务

最后,将后端服务器添加至数据库服务,使用DR模式。

[root@localhost /] ipvsadm -a -t 192.168.239.151:3306 -r 192.168.239.149:80 -g

最终配置验证

[root@localhost /] ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.239.151:80 rr
  -> 192.168.239.148:80           Masq    1      0          0         
  -> 192.168.239.149:80           Masq    1      0          0         
TCP  192.168.239.151:3306 wlc
  -> 192.168.239.149:3306         Route   1      0          0 

首先,我们检查IPVS的初始状态:

[root@localhost /] ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.239.151:80 rr
  -> 192.168.239.148:80           Masq    1      0          0         
  -> 192.168.239.149:80           Masq    1      0          0         
TCP  192.168.239.151:3306 wlc
  -> 192.168.239.149:3306         Route   1      0          0 

输出显示有两个服务正在运行:

  • HTTP服务(TCP 192.168.239.151:80),使用轮询(RR)调度算法。
  • 数据库服务(TCP 192.168.239.151:3306),使用加权最少连接(WLC)调度算法。

修改后端服务器权重

使用-e选项成功更新后端服务器的权重:

[root@localhost /] ipvsadm -e -t 192.168.239.151:3306 -r 192.168.239.149:80 -g -w 2

更改服务调度算法

[root@localhost /] ipvsadm -E -t 192.168.239.151:80 -s wrr

调整后端服务器权重

分别调整HTTP服务下的两个后端服务器权重:

[root@localhost /] ipvsadm -e -t 192.168.239.151:80 -r 192.168.239.148:80 -m -w 3

[root@localhost /] ipvsadm -e -t 192.168.239.151:80 -r 192.168.239.149:80 -m -w 4

最终状态确认

最后,我们再次检查IPVS的状态,确认所有更改均已生效:

[root@localhost /] ipvsadm -Ln


大小写选项区别

ipvsadm 命令中,大写和小写的选项有着明确的区别,它们分别针对不同的目标执行不同的操作。下面是对这些选项更为详细的解析:

大写选项 (用于操作虚拟服务器 - Virtual Services)

  • -A (Add-service):用于向内核的虚拟服务器表中添加一条新的虚拟服务器记录,即创建一个新的服务。虚拟服务由其 IP 地址、端口号和协议三元组唯一标识。

  • -D (Delete-service):从内核的虚拟服务器表中删除一个虚拟服务,即移除一个已有的服务。

  • -E (Edit-service):编辑一个已存在的虚拟服务的属性,比如更改其调度算法或其他配置参数。

  • -S (Show-service):显示一个虚拟服务的详细信息,包括它的调度算法、标志以及与之关联的所有后端服务器的信息。

小写选项 (用于操作真实服务器 - Real Servers)

  • -a (Add-realserver):向一个已存在的虚拟服务中添加一个后端服务器,即一个真实的服务器,用于处理该服务的请求。

  • -d (Delete-realserver):从一个虚拟服务中删除一个后端服务器,即移除一个真实服务器,使其不再接收来自该服务的流量。

  • -e (Edit-realserver):编辑一个已存在的后端服务器的属性,比如更改其权重、健康检查参数、或转发模式。

  • -s (Set-realserver):设置一个后端服务器的调度算法的参数,尽管这个选项在某些版本的文档中可能不被提及,但它可以用来调整后端服务器的特定参数,如其调度权重。

5.1.5.2 大写和小写选项的实际应用

大写选项示例

  1. -A (Add-service):添加一个新的虚拟服务

    ipvsadm -A -t 192.168.1.10:80 -s rr

    这将在内核的虚拟服务器表中添加一个新的虚拟服务,监听在 IP 地址 192.168.1.10 的 80 端口,并使用轮询(round-robin)作为调度算法。

  2. -D (Delete-service):删除一个已存在的虚拟服务

    ipvsadm -D -t 192.168.1.10:80

    这将从内核的虚拟服务器表中删除监听在 IP 地址 192.168.1.10 的 80 端口的虚拟服务。

  3. -E (Edit-service):编辑一个已存在的虚拟服务

    ipvsadm -E -t 192.168.1.10:80 -s wlc

    这将把监听在 IP 地址 192.168.1.10 的 80 端口的虚拟服务的调度算法更改为加权最少连接(weighted least connections)。

  4. -S (Show-service):显示一个虚拟服务的详细信息

    ipvsadm -S -t 192.168.1.10:80

    这将显示监听在 IP 地址 192.168.1.10 的 80 端口的虚拟服务的详细信息,包括其调度算法、标志以及与之关联的所有后端服务器的信息。

小写选项示例

  1. -a (Add-realserver):向一个已存在的虚拟服务中添加一个后端服务器

    ipvsadm -a -t 192.168.1.10:80 -r 192.168.1.11:80 -m

    这将在监听在 IP 地址 192.168.1.10 的 80 端口的虚拟服务中添加一个后端服务器,其 IP 地址为 192.168.1.11,端口为 80,并使用 MASQUERADE 方式进行流量转发。

  2. -d (Delete-realserver):从一个虚拟服务中删除一个后端服务器

    ipvsadm -d -t 192.168.1.10:80 -r 192.168.1.11:80

    这将从监听在 IP 地址 192.168.1.10 的 80 端口的虚拟服务中删除 IP 地址为 192.168.1.11 的后端服务器。

  3. -e (Edit-realserver):编辑一个已存在的后端服务器

    ipvsadm -e -t 192.168.1.10:80 -r 192.168.1.11:80 -w 2

    这将把监听在 IP 地址 192.168.1.10 的 80 端口的虚拟服务中,IP 地址为 192.168.1.11 的后端服务器的权重更改为 2。

  4. -s (Set-realserver):设置一个后端服务器的调度算法参数 注意:-s 通常用于设置服务的调度算法,但在某些上下文中,它也可以被解释为用于后端服务器参数的设置。然而,在大多数情况下,-s-E 一起使用来修改服务的调度算法,而不是直接用于后端服务器的参数设置。因此,这里的示例将展示如何使用 -E 来修改服务的调度算法,而不是 -s

    ipvsadm -E -t 192.168.1.10:80 -s wlc

5.1.5.3 ipvsadm-save

ipvsadm 命令用于在运行时动态地配置 IPVS 规则,这些规则存储在内核的内存中。这意味着,当你使用 ipvsadm 增加或修改虚拟服务器或后端服务器的规则时,所做的更改不会永久保存。一旦系统重启,所有动态配置的 IPVS 规则都会丢失,内核将恢复到其默认状态,没有先前的规则集。

[root@localhost ~] ipvsadm-save
-A -t 192.168.239.151:http -s wrr
-a -t 192.168.239.151:http -r 192.168.239.148:http -m -w 3
-a -t 192.168.239.151:http -r 192.168.239.149:http -m -w 4
-A -t 192.168.239.151:mysql -s wlc
-a -t 192.168.239.151:mysql -r 192.168.239.149:mysql -g -w 5
[root@localhost ~] ipvsadm-save -n
-A -t 192.168.239.151:80 -s wrr
-a -t 192.168.239.151:80 -r 192.168.239.148:80 -m -w 3
-a -t 192.168.239.151:80 -r 192.168.239.149:80 -m -w 4
-A -t 192.168.239.151:3306 -s wlc
-a -t 192.168.239.151:3306 -r 192.168.239.149:3306 -g -w 5


# 使用 ipvsadm-save 命令无参数调用,输出当前 IPVS 配置,其中服务端口使用协议名称表示
ipvsadm-save
# 创建一个虚拟服务器,其 IP 地址为 192.168.239.151,监听 HTTP 协议,默认端口 80,调度算法为加权轮询(WRR)
-A -t 192.168.239.151:http -s wrr
# 在上述虚拟服务器中添加第一个后端服务器,其 IP 地址为 192.168.239.148,监听 HTTP 协议,默认端口 80,使用 MASQUERADE(伪装)转发模式,权重为 3
-a -t 192.168.239.151:http -r 192.168.239.148:http -m -w 3
# 在同一虚拟服务器中添加第二个后端服务器,其 IP 地址为 192.168.239.149,监听 HTTP 协议,默认端口 80,使用 MASQUERADE(伪装)转发模式,权重为 4
-a -t 192.168.239.151:http -r 192.168.239.149:http -m -w 4
# 创建另一个虚拟服务器,其 IP 地址为 192.168.239.151,监听 MySQL 协议,默认端口 3306,调度算法为加权最少连接(WLC)
-A -t 192.168.239.151:mysql -s wlc
# 在上述 MySQL 虚拟服务器中添加一个后端服务器,其 IP 地址为 192.168.239.149,监听 MySQL 协议,默认端口 3306,使用 ROUTE(路由)转发模式,权重为 5
-a -t 192.168.239.151:mysql -r 192.168.239.149:mysql -g -w 5

# 使用 ipvsadm-save 命令并添加 -n 参数调用,输出当前 IPVS 配置,其中服务端口使用数字表示而非协议名称
ipvsadm-save -n
# 创建一个虚拟服务器,其 IP 地址为 192.168.239.151,监听端口 80,调度算法为加权轮询(WRR)
-A -t 192.168.239.151:80 -s wrr
# 在上述虚拟服务器中添加第一个后端服务器,其 IP 地址为 192.168.239.148,监听端口 80,使用 MASQUERADE(伪装)转发模式,权重为 3
-a -t 192.168.239.151:80 -r 192.168.239.148:80 -m -w 3
# 在同一虚拟服务器中添加第二个后端服务器,其 IP 地址为 192.168.239.149,监听端口 80,使用 MASQUERADE(伪装)转发模式,权重为 4
-a -t 192.168.239.151:80 -r 192.168.239.149:80 -m -w 4
# 创建另一个虚拟服务器,其 IP 地址为 192.168.239.151,监听端口 3306,调度算法为加权最少连接(WLC)
-A -t 192.168.239.151:3306 -s wlc
# 在上述 MySQL 虚拟服务器中添加一个后端服务器,其 IP 地址为 192.168.239.149,监听端口 3306,使用 ROUTE(路由)转发模式,权重为 5
-a -t 192.168.239.151:3306 -r 192.168.239.149:3306 -g -w 5

为了保存这些配置,应当将 ipvsadm-save 的输出重定向到一个文件中,例如:

ipvsadm-save > /etc/ipvs.conf

然后,在系统重启后,你可以使用以下命令来恢复这些配置:

ipvsadm-restore < /etc/ipvs.conf

这样做可以确保即使在系统重启后, IPVS 配置仍然有效,无需手动重新配置。

示例:

保存 IPVS 配置到清空现有配置,恢复配置的整个过程,包括每个步骤的具体操作和验证配置状态的方法。

# 使用 ipvsadm-save -n 命令导出当前 IPVS 的配置,其中端口号以数字形式显示,便于脚本解析
[root@localhost ~] ipvsadm-save -n
# 以下是导出的具体配置详情
-A -t 192.168.239.151:80 -s wrr                  # 创建一个虚拟服务器,IP 地址为 192.168.239.151,监听端口 80,调度算法为加权轮询(WRR)
-a -t 192.168.239.151:80 -r 192.168.239.148:80 -m -w 3  # 添加一个后端服务器,IP 地址为 192.168.239.148,监听端口 80,使用 MASQUERADE(伪装)转发模式,权重为 3
-a -t 192.168.239.151:80 -r 192.168.239.149:80 -m -w 4  # 添加另一个后端服务器,IP 地址为 192.168.239.149,监听端口 80,使用 MASQUERADE(伪装)转发模式,权重为 4
-A -t 192.168.239.151:3306 -s wlc                # 创建另一个虚拟服务器,IP 地址为 192.168.239.151,监听端口 3306,调度算法为加权最少连接(WLC)
-a -t 192.168.239.151:3306 -r 192.168.239.149:3306 -g -w 5  # 添加一个后端服务器,IP 地址为 192.168.239.149,监听端口 3306,使用 ROUTE(路由)转发模式,权重为 5

# 将 ipvsadm-save -n 的输出重定向到 ipvs.conf 文件中,用于保存当前配置
[root@localhost ~] ipvsadm-save -n > ipvs.conf

# 查看 ipvs.conf 文件内容,确认配置已正确保存
[root@localhost ~] cat ipvs.conf 
-A -t 192.168.239.151:80 -s wrr
-a -t 192.168.239.151:80 -r 192.168.239.148:80 -m -w 3
-a -t 192.168.239.151:80 -r 192.168.239.149:80 -m -w 4
-A -t 192.168.239.151:3306 -s wlc
-a -t 192.168.239.151:3306 -r 192.168.239.149:3306 -g -w 5

# 清空当前 IPVS 配置,准备恢复之前的配置
[root@localhost ~] ipvsadm -C

# 验证 IPVS 配置已被清空
[root@localhost ~] ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn

# 使用 ipvsadm-restore 命令从 ipvs.conf 文件恢复之前保存的配置
[root@localhost ~] ipvsadm-restore < ipvs.conf 

# 验证配置已成功恢复
[root@localhost ~] ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.239.151:80 wrr                  # 虚拟服务器恢复,监听端口 80,使用 WRR 调度算法
  -> 192.168.239.148:80           Masq    3      0          0         # 后端服务器恢复,权重为 3
  -> 192.168.239.149:80           Masq    4      0          0         # 另一后端服务器恢复,权重为 4
TCP  192.168.239.151:3306 wlc                # 另一虚拟服务器恢复,监听端口 3306,使用 WLC 调度算法
  -> 192.168.239.149:3306         Route   5      0          0         # 后端服务器恢复,权重为 5

5.1.5.4 开机自启加载

要在使用 Systemd 的系统中实现 IPVS 配置的开机自启动,你需要创建一个 Systemd 服务单元文件,该文件定义了在系统启动时如何加载 IPVS 的配置。以下是详细的步骤:

步骤 1: 创建服务单元文件

/etc/systemd/system 目录下创建一个新的服务单元文件,命名为 ipvs.service。你可以使用你喜欢的文本编辑器(如 vi, vim, nano 等)来创建这个文件。

vim /etc/systemd/system/ipvs.service

步骤 2: 编辑服务单元文件

ipvs.service 文件中,输入以下内容:

[Unit]
Description=IPVS Configuration Service
After=network.target

[Service]
Type=simple
ExecStart=/sbin/ipvsadm-restore < /etc/ipvs.conf

[Install]
WantedBy=multi-user.target

这个配置文件做了以下几件事:

  • 定义了一个名为 "IPVS Configuration Service" 的服务。
  • 设置服务在 network.target 之后启动,确保网络服务已经准备好。
  • 使用 Type=simple 指定服务类型。
  • ExecStart 指令定义了服务启动时要执行的命令,这里使用 ipvsadm --restore 从 /etc/ipvs.conf 文件加载 IPVS 配置。
  • WantedBy 指令确保服务被包含在 multi-user.target 中,这是典型的多用户运行级别的目标。

步骤 3: 重新加载 Systemd 配置

编辑完文件后,你需要通知 Systemd 重新加载配置,以便它能够识别新创建的服务单元文件。

systemctl daemon-reload

步骤 4: 启用并启动服务

启用 ipvs.service,这样它会在每次系统启动时自动运行。

systemctl enable ipvs.service

也可以立即启动服务,以测试配置是否正确。

systemctl start ipvs.service

步骤 5: 检查服务状态

最后,检查 ipvs.service 的状态,确认一切按预期运行。

systemctl status ipvs.service

如果一切顺利,应该看到服务的状态为 active,且没有错误信息。这表明你的 IPVS 配置将自动在系统启动时加载。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:/a/701432.html

如若内容造成侵权/违法违规/事实不符,请联系我们进行投诉反馈qq邮箱809451989@qq.com,一经查实,立即删除!

相关文章

解决layui框架自带的excel导出长数据变科学计数法(使用\t和不使用\t的方法)

前言:项目中需要导出excel时,如果是大项目、要求高,当然使用第三方插件,或者后台导出是必要的,但是如果是一些小型项目,并且对导出excel样式要求不是很严格的,而且前端框架用的是layui的,layui框架自带的excel导出就成了我们最方便快捷的选择,但是在导出数据时会遇到一…

[CUDA编程] cuda graph优化心得

CUDA Graph 1. cuda graph的使用场景 cuda graph在一个kernel要多次执行&#xff0c;且每次只更改kernel 参数或者不更改参数时使用效果更加&#xff1b;但是如果将graph替换已有的kernel组合&#xff0c;且没有重复执行&#xff0c;感觉效率不是很高反而低于原始的kernel调用…

2024年6月份实时获取地图边界数据方法,省市区县街道多级联动【附实时geoJson数据下载】

首先&#xff0c;来看下效果图 在线体验地址&#xff1a;https://geojson.hxkj.vip&#xff0c;并提供实时geoJson数据文件下载 可下载的数据包含省级geojson行政边界数据、市级geojson行政边界数据、区/县级geojson行政边界数据、省市区县街道行政编码四级联动数据&#xff0…

根据mooc 数据库旧代码 实现剥离数据库链接单独成类,并进行测试

数据源详情链接&#xff0c;SQLserver 2019 代码复制粘贴可产生数据 数据库JDBC 查询sqlserver 2019 利用模板实现输入查询-CSDN博客 效果如下 剥离的链接模块 Slinkv2.java package SQLadd;import java.sql.Connection; import java.sql.DriverManager; import java.sql.Re…

在ensp上配置动态路由协议实验设计

动态路由协议是用来在网络中自动更新路由信息的一种技术&#xff0c;它可以让网络设备&#xff08;如路由器&#xff09;根据当前网络的状态调整数据的传输路径。这种协议特别适用于大型复杂的网络环境&#xff0c;可以有效地处理网络配置的变化&#xff0c;如链接的添加、删除…

flutter报错You are currently using Java 1.8

flutter报错Could not run phased build action using connection to Gradle distribution ‘https://services.gradle.org/distributions/gradle-7.6.3-all.zip’.\r\norg.gradle.api.ProjectConfigurationException: A problem occurred configuring root project ‘android’…

Android RelativeLayout Rtl布局下的bug:paddingStart会同时作用于左右内边距

问题现象 如上图&#xff0c;只是设置了paddingStart&#xff0c;在RTL布局下&#xff0c;左右都产生了10dp的间距。其他布局如LinearLayout&#xff0c;FrameLayout则没有这个问题。 private void positionAtEdge(View child, LayoutParams params, int myWidth) {if (isLayou…

问题:一般在管理工作复杂、面广且管理分工比较细致的单位,常采用()组织形式。 #媒体#媒体

问题&#xff1a;一般在管理工作复杂、面广且管理分工比较细致的单位&#xff0c;常采用()组织形式。 A&#xff0e;直线式 B&#xff0e;职能式 C&#xff0e;矩阵式 D&#xff0e;团队式 参考答案如图所示

使用易备数据备份软件,简单快速地备份 Oracle 数据库

易备数据备份软件能够以简单高效的方式&#xff0c;实现对 Oracle 数据库的保护。 易备数据备份软件数据库备份功能的关键特性 自动保护网站数据库及应用程序实时备份&#xff0c;不需要任何中断或数据库锁定基于日期和时间的备份任务计划可恢复到一个已存在的数据库或创建一…

Web前端大作业:基于html+css+js的仿淘宝首页前端项目(内附源码)

文章目录 一、项目介绍二、项目展示三、源码展示四、源码获取 一、项目介绍 这个项目是一个Web前端大作业,目的是让学生们通过实践仿设计淘宝官网的前端页面,来全面锻炼他们的HTML、CSS和JavaScript编程能力,以及产品需求分析、界面设计、交互设计等软实力。 淘宝作为国内最大…

TMCM-BB1是单轴板驱动器

TMCM-BB4 简介 TMCM-BB1和TMCM-BB4是Trinamic插槽式模块的基板。TMCM-BB1是单轴板&#xff0c;提供对一个MCU模块和一个驱动器模块的访问。TMCM-BB4是一个4轴板&#xff0c;提供对41模块插槽的访问。TMCM-0930模块采用单36针PCI插座&#xff0c;整个系统采用主MCU&#xff08;…

【精品方案推荐】大数据治理平台建设解决方案(66页PPT)

随着企业数据量的迅速增长和复杂化&#xff0c;如何有效管理、分析和利用这些数据成为企业面临的重要挑战。大数据治理平台作为解决这一问题的关键工具&#xff0c;旨在为企业提供全面、高效的数据管理、安全保障和业务支持。 问题1&#xff1a;上大数据平台要废弃已上线的传统…

BitMEX 联合创始人 Arthur Hayes 加入 Covalent 担任战略顾问

Arthur Hayes 加入 Covalent Network&#xff08;CQT&#xff09;&#xff0c;成为其战略顾问。 Hayes 认为 Covalent 与其竞争对手如 The Graph 相比&#xff0c;Covalent Network 的 CQT 代币一直被相对低估&#xff0c;他希望帮助 Covalent Network&#xff08;CQT&#x…

【深度学习】数竹签演示软件系统

往期文章列表&#xff1a; 【YOLO深度学习系列】图像分类、物体检测、实例分割、物体追踪、姿态估计、定向边框检测演示系统【含源码】 【深度学习】物体检测/实例分割/物体追踪/姿态估计/定向边框/图像分类检测演示系统【含源码】 【深度学习】YOLOV8数据标注及模型训练方法整…

Playwright+Python+Pytest:基础方法二次封装简化及链式调用

引言 随着Web应用的日益复杂化&#xff0c;自动化测试成为了确保软件质量的关键环节。Playwright 是一个强大的自动化库&#xff0c;它支持在 Chromium、Firefox 和 WebKit 中运行自动化脚本。本文将介绍如何使用 Playwright 的 Python 同步 API 来简化点击和填充操作&#xf…

UnityAPI学习之Animator的基本使用

动画与动画控制器 示例1&#xff1a; 创建Animator对动画控制器进行统一管理&#xff0c;在Gris中创建Animator组件&#xff0c;并对其中的Controller属性进行赋值 在进行动画创作前&#xff0c;需先将图片的Texture Type属性改为Sprite(2D and UI) 再将一系列图片拖入Gris物…

【java计算机毕设】图书商城管理系统MySQL springboot vue html maven送文档

1项目功能介绍 【java计算机毕设】图书商城管理系统 Java Spring Boot vue HTML MySQL 赠送文档 PPT 2项目简介 系统功能&#xff1a; 图书商城管理系统包括管理员和用户两种角色。 管理员的功能包括在个人中心修改个人信息&#xff0c;以及在基础数据管理中管理会员等级类型和…

idea安装步骤 激活码分享2024 最新版本 ,附激活码,亲测到2099

1.下载安装IDEA 略 一步一步确定安装&#xff0c;然后打开 这里提示输入激活码&#xff0c;先关闭应用&#xff01;&#xff01;&#xff01; 2.下载工具 打开下载好的工具&#xff08;下载后记得不要删除和移动&#xff0c;然后安装的路径尽量不要带中文路径、删掉就会失效…

Maven认识与学习

1. Maven介绍 1.2 初识Maven 1.2.1 什么是Maven Maven是Apache旗下的一个开源项目&#xff0c;是一款用于管理和构建java项目的工具。 官网&#xff1a;Maven – Welcome to Apache Maven Apache 软件基金会&#xff0c;成立于1999年7月&#xff0c;是目前世界上最大的最受…

正大国际期货:如何培养个好心态呢?

期货市场中的心态之道 在期货市场中&#xff0c;每一个交易者都像是航行在波涛汹涌的大海中的舵手。市场的波动、信息的繁杂、情绪的起伏&#xff0c;都如同海上的风浪&#xff0c;不断考验着每一位舵手的意志和心态。那么&#xff0c;如何在这样的环境中保持一个好的心态呢&am…