LVS

标签：LVS IP ko xz 服务器 xt

问题

LVS NAT模式必须设置默认路由指向DIR地址，如果不设置数据包RS服务器能否将数据包正确的返回给客户端。DR/TUN模式增加一条静态路由目标地址VIP地址，dev设备指向VIP的网口，如果不设置RS服务能否正确接收到Director Server发送的数据包
LVS DR/TUN模式，RS服务器一定配置VIP地址在选择的网络接口上吗，如果不配置能不能处理Director Server发送的数据包，具体的处理动作是丢弃还是接受
LVS IPVS的区别
LVS 的 IP 负载均衡技术是通过 IPVS 模块来实现的，IPVS 是 LVS集群系统的核心软件，它的主要作用是：安装在 Director Server 上，同时在 Director Server上虚拟出一个IP 地址，用户必须通过这个虚拟的 IP 地址访问服务器。这个虚拟 IP 一般称为 LVS 的VIP，即 Virtual IP。访问的请求首先经过 VIP 到达负载调度器，然后由负载调度器从Real Server 列表中选取一个服务节点响应用户的请求。在用户的请求到达负载调度器后，调度器如何将请求发送到提供服务的 Real Server 节点，而 Real Server节点如何返回数据给用户，是 IPVS 实现的重点技术。

ipvs工作于内核空间的INPUT链上，当收到用户请求某集群服务时，经过PREROUTING链，经检查本机路由表，送往INPUT链；在进入netfilter的INPUT链时，ipvs强行将请求报文通过ipvsadm定义的集群服务策略的路径改为FORWORD链，将报文转发至后端真实提供服务的主机
- ipvs ：工作于内核空间，主要用于使用户定义的策略生效
- ipvsadm : 工作于用户空间，主要用于用户定义和管理集群服务的工具
LVS 使用linux内核核心组件netfilter处理数据包过滤，数据包修改，跟踪等。那么LVS与netfilter是怎么结合使用的

LVS 背景

LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。本项目在1998年5月成立，是中国国内最早出现的自由软件项目之一。LVS采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序

一组服务器通过高速的局域网或者不同地址位置的广域网相互连接，前端有一个负载均衡器（load balancer），负载均衡器负责将网络请求分布均匀的分发真实的服务器上，服务器集群相对集群的结构相对应用是透明的，应用访问集群系统提供的服务器就像访问一台高性能、高可用的服务器一样，当流量高峰时可以快速扩展集群中的节点，也可以定期检查节点的状态当故障节点时动态地踢出故障节点

LVS工作及原理

https://developer.aliyun.com/article/542615“
“https://wsgzao.github.io/post/lvs/

LVS工作于IOS七层模型的第四层-传输层，通过对TCP, UDP, AH, EST, AH_EST, SCTP等工作在四层的协议的支持，根据目标地址和端口做出转发与否的决策，根据调度算法做出转发至哪一个端口的解决方案。

LVS将其控制程序ipvs嵌套至传输层数据流的Input钩子函数上，ipvs将发送至本调度器主机（director）上的数据流在input链上进行截流，通过对数据报文的分析根据自身的算法将数据流转发至后台真正提供服务的主机（Real Server）上，达到根据后端服务器负载能力均衡分配处理任务的效果。许多商业的集群产品，如RedHat的Piranha，Turbolinux公司的Turbo Cluster等都是基于LVS的核心代码实现的。

LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器(Director)具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。

IPVS: 称之为IP虚拟服务器(IP Virtual Server，简写为IPVS),是运行在LVS下的提供负载均衡功能的一种技术。当一个TCP连接的初始SYN报文到达时，IPVS就选择一台服务器，将报文转发给这台服务器。此后通过检查发报文的IP和TCP报文头地址，保证此连接的后继报文被转发到相同的服务器。这样，当IPVS无法检查到请求的内容而需要再选择服务器时，这就要求后端的服务器组提供相同的服务，不管请求被送到哪一台服务器，返回结果都应该是一样的。但是在有一些应用中后端的服务器可能功能不一，有的是提供HTML文档的Web服务器，有的是提供图片的Web服务器，有的是提供CGI的Web服务器。这时，就需要基于内容进行请求分发 (Content-Based Request Distribution)，同时基于内容请求分发可以提高后端服务器上访问的局部性

集群分类

负载均衡集群LB：Loadbalancingclusters
高可用性集群HA：High-availability(HA)clusters
高性能计算集群HP：High-performance(HPC)clusters，常指分布式集群

为什么需要负载均衡

由于网站中业务量的提高，访问量和数据流量的快速增长，其处理能力和计算强度也相应地增大，使得单一的服务器设备根本无法承担。负载均衡解决方案，让网站服务器轻松应对流量高峰，有效保证网站的稳定性。针对此情况而衍生出来的一种廉价有效透明的方法以扩展现有网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。这种技术就是负载均衡（Load Balance）。

负载均衡的功能

大量的并发访问或数据流量分担到多台节点设备上分别处理，有效保证每个请求都能最快处理；
网络接入均衡
多种负载均衡方式，有针对性的解决不同网站的压力分配问题
科学的数据同步及内容分发系统
完整的数据备份系统

负载均衡常用解决方案

硬件
1. F5，应用交付网络（ADN）领域的全球领先厂商，全球市场份额第一
2. A10， A10 公司是应用交付网络（ADN）领域的全球领先厂商，全球市场份额第三。其总部位于美国硅谷
3. 深信服: 深信服应用交付AD产品具备服务器负载均衡、链路负载均衡、单边加速、智能优化技术、SSL加速、商业智能分析等优势功能，将用户访问请求智能匹配到最优的链路，并为用户选择响应最快的服务器，提升用户使用体验，并为企业提供科学管理的决策
4. Citrix NetScaler:中文名为负载均衡，指的是对于一个三层架构web应用来说，客户端的请求将通过NetScaler与后台服务器建立链接
软件
1. lvs
2. haproxy
3. nginx
4. Piranha 商用

LVS术语

VS Virtual Server 虚拟服务器，通常指负载均衡服务器
RS Real Server 真实服务器，通常是指提供应用服务的服务器
DR Director负载均衡调度器
VIP 对外提供服务的IP地址，可以是公网也可以是局域网内网地址
DIP Director IP 调度器IP
RIP Real Server 真实服务器的IP
CIP 客户端访问的IP

LVS模式

http://www.linuxvirtualserver.org/Documents.html
https://wsgzao.github.io/post/lvs/

LVS负载均衡模式，常见的三种 VS/NAT、VS/TUN、VS/DR，还有一种是VS/fullnat双向转换

VS/NAT 地址转换模式

负载均衡器通过重写请求报文的目的地址实现网络地址转换，根据设定的负载均衡算法将请求分配给后端真实的服务器，真实接收到报文处理并响应需要通过负载均衡器，报文的源地址被重写，然后返回给客户端，从而完成整个网络负载的过程

但是NAT也有缺点，在一些高并发的情况下，所有请求都需要经过负载均衡器进行地址转换，此时负载均衡器可能成为整个链路的瓶颈

VS/NAT功能/限制

DR服务器必须要有二个网络接口，即内网&外网，但是不是必须看具体环境
RS的网关要指向DIP，RIP仅用于各个节点之间的通信
请求和响应报文都要经由director转发
支持端口映射
RS可以使用任意OS

VS/NAT缺点

通常应用在较大规模应用场景中，但是Director易成为整个架构的瓶颈

VS/NAT工作原理

当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。此时报文的源IP为CIP，目标IP为VIP
PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链
IPVS比对数据包请求的服务是否为集群服务，若是，修改数据包的目标IP地址为后端服务器IP，然后将数据包发至POSTROUTING链。此时报文的源IP为CIP，目标IP为RIP
POSTROUTING链通过选路，将数据包发送给Real Server
Real Server比对发现目标为自己的IP，开始构建响应报文发回给Director Server。此时报文的源IP为RIP，目标IP为CIP
Director Server在响应客户端前，此时会将源IP地址修改为自己的VIP地址，然后响应给客户端。此时报文的源IP为VIP，目标IP为CIP

VS/TUN 隧道模式

VS/TUN工作原理

大致原理，在原有的IP报文外再次封装多一层IP首部，内部IP首部(源地址为CIP，目标IIP为VIP)，外层IP首部(源地址为DIP，目标IP为RIP

当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。此时报文的源IP为CIP，目标IP为VIP 。
PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链
IPVS比对数据包请求的服务是否为集群服务，若是，在请求报文的首部再次封装一层IP报文，封装源IP为DIP，目标IP为RIP。然后发至POSTROUTING链。此时源IP为DIP，目标IP为RIP
POSTROUTING链根据最新封装的IP报文，将数据包发至RS（因为在外层封装多了一层IP首部，所以可以理解为此时通过隧道传输）。此时源IP为DIP，目标IP为RIP
RS接收到报文后发现是自己的IP地址，就将报文接收下来，拆除掉最外层的IP后，会发现里面还有一层IP首部，而且目标是自己的lo接口VIP，那么此时RS开始处理此请求，处理完成之后，通过lo接口送给eth0网卡，然后向外传递。此时的源IP地址为VIP，目标IP为CIP
响应报文最终送达至客户端

VS/TUN功能/限制

集群节点可以跨越Internet
Director的VIP和RIP必须为公网IP（不一定，看场景）
Director仅处理入站请求，响应报文则由RealServer直接发往客户端
Real Server的网关不能指向Director
只有支持隧道协议功能的OS才能作为RealServer（需要所有的服务器支持”IP Tunneling”(IP Encapsulation)协议）
不支持端口映射

VS/DR 直接路由模式

VS/DS工作原理

主要通过修改请求报文的目标MAC地址进行转发

当用户请求到达Director Server，此时请求的数据报文会先到内核空间的PREROUTING链。此时报文的源IP为CIP，目标IP为VIP
PREROUTING检查发现数据包的目标IP是本机，将数据包送至INPUT链
IPVS比对数据包请求的服务是否为集群服务，若是，将请求报文中的源MAC地址修改为DIP的MAC地址，将目标MAC地址修改RIP的MAC地址，然后将数据包发至POSTROUTING链。此时的源IP和目的IP均未修改，仅修改了源MAC地址为DIP的MAC地址，目标MAC地址为RIP的MAC地址
由于DS和RS在同一个网络中，所以是通过二层来传输。POSTROUTING链检查目标MAC地址为RIP的MAC地址，那么此时数据包将会发至Real Server。
RS发现请求报文的MAC地址是自己的MAC地址，就接收此报文。处理完成之后，将响应报文通过lo接口传送给eth0网卡然后向外发出。此时的源IP地址为VIP，目标IP为CIP
响应报文最终送达至客户端

VS/DR功能/限制

保证客户端请求路由VIP目标地址的报文必须发给Director Server，而不是RS
RS可以使用私有地址；也可以是公网地址，如果使用公网地址，此时可以通过互联网对RIP进行直接访问
RS跟Director Server必须在同一个网段中
所有的请求报文经由Director Server，但响应报文必须不能进过Director Server
不支持地址转换，也不支持端口映射
RS可以是大多数常见的操作系统
RS的网关绝不允许指向DIP(因为我们不允许他经过director)
RS上的lo接口配置VIP的IP地址，同时必须设置屏蔽局域网发到arp广播应答级别（arp_announce arp_ignore）
- arp_ignore:定义接受到ARP请求时的相应级别
  0：只要本地配置的有相应地址，就给予响应
  1：仅在请求的目标地址配置请求到达的接口上的时候，才给予响应（当别人的arp请求过来的时候，如果接收的设备上面没有这个ip，就不响应，默认是0，只要这台机器上面任何一个设备上面有这个ip，就响应arp请求，并发送MAC地址应答。）
  2：只回答目标IP地址是来访网络接口本地地址的ARP查询请求,且来访IP必须在该网络接口的子网段内
  3：不回应该网络界面的arp请求，而只对设置的唯一和连接地址做出回应
  4-7：保留未使用
  8：不回应所有（本地地址）的arp查询
- arp_announce：定义将自己地址向外通告是的通告级别
  0: 将本地任何接口上的任何地址向外通告
  1：试图仅想目标网络通告与其网络匹配的地址 2：仅向与本地借口上地址匹配的网络进行通告

VS/DR缺点

唯一的缺陷在于它要求LVS 调度器及所有应用服务器在同一个网段中，因此不能实现集群的跨网段应用

VS/DR问题总结

https://blog.csdn.net/liupeifeng3514/article/details/79038577
“https://blog.csdn.net/linhaoyanglinhao/article/details/126890606“

“http://linbo.github.io/2017/08/20/lvs-dr#fn:1“

LVS/DR如何处理请求报文的，会修改IP包内容吗？
vs/dr本身不会关心IP层以上的信息，即使是端口号也是tcp/ip协议栈去判断是否正确，vs/dr本身主要做这么几个事：
- ①接收client的请求，根据你设定的负载均衡算法选取一台realserver的ip；
- ②以选取的这个ip对应的mac地址作为目标mac，然后重新将IP包封装成帧转发给这台RS；
- ③在hash table中记录连接信息。
- vs/dr做的事情很少，也很简单，所以它的效率很高，不比硬件负载均衡设备差多少，数据包、数据帧的大致流向是这样的：client –> VS –> RS –> client

RealServer为什么要在lo接口上配置VIP？在出口网卡上配置VIP可以吗？
既然要让RS能够处理目标地址为vip的IP包，首先必须要让RS能接收到这个包。在lo上配置vip能够完成接收包并将结果返回client。不可以将VIP设置在出口网卡上,否则会响应客户端的arp request,造成client/gateway arp table紊乱，以至于整个load balance都不能正常工作。

RealServer为什么要抑制arp帧？
我们知道仰制arp帧需要在server上执行以下命令，如下：
- echo “1” >/proc/sys/net/ipv4/conf/lo/arp_ignore‘
- echo “2” >/proc/sys/net/ipv4/conf/lo/arp_announce
- echo “1” >/proc/sys/net/ipv4/conf/all/arp_ignore
- echo “2” >/proc/sys/net/ipv4/conf/all/arp_announce
- 因为arp对逻辑口没有意义。实际上起作用的只有以下两条:
- echo “1” >/proc/sys/net/ipv4/conf/all/arp_ignor
- echo “2” >/proc/sys/net/ipv4/conf/all/arp_announce
- 即对所有的物理网卡设置arp仰制。对仰制所有的物理网卡设置arp仰制是为了让CIP发送的请求顺利转交给DIR以及防止整个LVS环境arp表混乱，不然容易导致整个lvs不能工作。

LVS/DR load balancer（director）与RS为什么要在同一网段中？
lvs/dr它是在数据链路层来实现的，即RIP必须能够接受到DIR的arp请求，如果不在同一网段则会隔离arp，这样arp请求就不能转发到指定的RIP上，所以director必须和RS在同一网段里面。
为什么director上eth0接口除了VIP另外还要配一个ip（即DIP）？
如果是用了keepalived等工具做HA或者Load Balance,则在健康检查时需要用到DIP。没有健康检查机制的HA或者Load Balance则没有存在的实际意义。
LVS/DR ip_forward需要开启吗？
不需要。因为director跟realserver是同一个网段，无需开启转发。
director的vip的netmask一定要是255.255.255.255吗？
lvs/dr里，director的vip的netmask 没必要设置为255.255.255.255，director的vip本来就是要像正常的ip地址一样对外通告的,不要搞得这么特殊。
RS设置 lo:0而不设置ens33:0的原因
- 因为“负载调度机”转发时并不会改写数据包的目的IP，所以“节点服务器”收到的数据包的目的IP仍是“负载调度器”的虚拟服务IP。为了保证“节点服务器”能够正确处理该数据包，而不是丢弃，必须在“节点服务器”的环回网卡上绑定“负载调度器”的虚拟服务IP。这样“节点服务器”会认为这个虚拟服务IP是自己的IP，自己是能够处理这个数据包的。否则“节点服务器”会直接丢弃该数据包！
- “节点服务器”上的业务进程必须监听在环回网卡的虚拟服务IP上，且端口必须和“负载调度机”上的虚拟服务端口一致。因为“负载调度机”不会改写数据包的目的端口，所以“节点服务器”服务的监听端口必须和虚拟服务端口一致，否则“节点服务器”会直接拒绝该数据包。
- “节点服务器”处理完请求后，响应直接回给客户端，不再经过“负载调度机”。因为“节点服务器”收到的请求数据包的源IP是客户端的IP，所以理所当然“节点服务器”的响应会直接回给客户端，而不会再经过“负载调度机”。这时候要求“节点服务器”和客户端之间的网络是可达的。
- “负载调度机”和“节点服务器”须位于同一个子网。因为“负载调度机”在转发过程中需要改写数据包的MAC为“节点服务器”的MAC地址，所以要能够查询到“节点服务器”的MAC。而要获取到“节点服务器”的MAC，则需要保证二者位于一个子网，否则“负载调度机”只能获取到“节点服务器”网关的MAC地址

VS/FULLNAT

https://www.cnblogs.com/gaoxu387/p/7941381.html

无论是 DR 还是 NAT 模式，不可避免的都有一个问题：LVS 和 RS 必须在同一个 VLAN 下，否则 LVS 无法作为 RS 的网关。

这引发的两个问题是：

同一个 VLAN 的限制导致运维不方便，跨 VLAN 的 RS 无法接入。
LVS 的水平扩展受到制约。当 RS 水平扩容时，总有一天其上的单点 LVS 会成为瓶颈。

Full-NAT 由此而生，解决的是 LVS 和 RS 跨 VLAN 的问题，而跨 VLAN 问题解决后，LVS 和 RS 不再存在 VLAN 上的从属关系，可以做到多个 LVS 对应多个 RS，解决水平扩容的问题。

Full-NAT 相比 NAT 的主要改进是，在 SNAT/DNAT 的基础上，加上另一种转换，转换过程如下：

在包从 LVS 转到 RS 的过程中，源地址从客户端 IP 被替换成了 LVS 的内网 IP。

内网 IP 之间可以通过多个交换机跨 VLAN 通信。

当 RS 处理完接受到的包，返回时，会将这个包返回给 LVS 的内网 IP，这一步也不受限于 VLAN。

LVS 收到包后，在 NAT 模式修改源地址的基础上，再把 RS 发来的包中的目标地址从 LVS 内网 IP 改为客户端的 IP。

Full-NAT 主要的思想是把网关和其下机器的通信，改为了普通的网络通信，从而解决了跨 VLAN 的问题。采用这种方式，LVS 和 RS 的部署在 VLAN 上将不再有任何限制，大大提高了运维部署的便利性。

总结

1.FULL NAT 模式也不需要 LBIP 和 realserver ip 在同一个网段； full nat 跟 nat 相比的优点是：保证 RS 回包一定能够回到 LVS；因为源地址就是 LVS–> 不确定

2.full nat 因为要更新 sorce ip 所以性能正常比 nat 模式下降 10%

LVS调度算法

https://developer.aliyun.com/article/542615

四种静态算法

RR
根据规则依次论调,不考虑RS的性能。轮到谁就转发给谁。
WRR
加权轮询，加入了weight（权重），可以根据RS的性能为其设置权重值，权重越大功能越强，但是无法发现当前的服务器的运行情况如何。
DH
目标地址hash，适用于前端是一个director后端是几个缓存服务器的情况，当客户端第一次访问到的是RS1的时候，DH这种算法能保证在客户端刷新后还是访问的RS1
SH
源地址hash，用于保证响应的报文和请求的报文是同一个路径。

六种动态算法

考虑后端服务器当前负载后再进行分配：

LC east connection，当一个用户请求过来的时候，Director会计算一下哪台RS的连接数最小，那么这台RS就获得了下次响应客户端请求的机会，计算的方法Overhead=active*256+inactive,如果两者的结果是相同的则从LVS中的规则依次往下选择RS。这种算法也是不考虑服务器的性能的。
WLC 这个就是加了权重的LC，考虑了RS的性能，即性能好的就给的权重值大一些，性能差的给的权重值小一些。缺点就是如果Overhead相同，则会按规则表中的顺序，由上而下选择RS，Overhead=(active*256+inactive)/weight
SED 就是对WLC的情况的补充，Overhead=(active+1)*256/weight，加1，就是为了让其能够比较出大小。
NQ 即never queue，基本和SED相同，避免了SED当中的性能差的服务器长时间被空闲的弊端，它是将第一个请求给性能好的服务器，第二个请求一定是给空闲的服务器不论它的性能的好与坏。之后还是会把请求给性能好的服务器。
LBLC 它就是动态DH和LC的组合，适用于cache集群，对于从来没有来过的那些新的请求会分给当前连接数较少的那台服务器。
LBLCR 带有复制功能的LBLC，它的适用场景这里举例说明一下，比如说现在有RS1和RS2,第一次访问RS1的5个请求第二次又来了，理所应到Director将会将其交给RS1，而此时在RS2是非常闲的，所以此时最好的处理方法就是可以将后来的这5个请求分别交给RS1和RS2，所以此时就需要把客户端第一次请求的资源复制下来。（特殊情况）

LVS 配置

持久配置

lvs persistence: lvs的持久连接;
功能：无论ipvs使用何种调度方法，其都能实现将来自于同一个Client的请求始终定向至第一次调度时挑选出的RS;
和sh调度算法比较优点：
sh：会一直将一个用户请求定义到一个后端server，不会考虑后端服务器状态;对多个共享的同一组RS的服务器,需要统一进行绑定，sh算法无法实现;
持久连接：第一次会根据设置的调度算法（rr，wlc……）调度到后端，在指定的会话存活时间使用持久连接，会话存活时间到期之后，还是根据调度算法进行调度。

persistence template(持久连接模板)：

持久连接的实现方式：

PPC：每端口持久；持久连接生效范围仅为单个集群服务；如果有多个集群服务，每服务被单独持久调度；
PFWM：每FWM持久：持久连接生效范围为定义为同一个FWM下的所有服务；
PCC：每客户端持久；持久连接生效范围为所有服务；定义集群服务时，其TCP或UDP协议的目标端口要使用0；
director会将用户的任何请求都识别为集群服务,并向RS进行调度;
TCP: 1-65535; UDP: 1-65535

lvs persistence语法

ipvsadm-A -t|-u|-f service-address -s $schedular -p [n]

无-p选项：不启用持久连接

-p n：指定持久时长，省略时长，默认为360秒

其他注意事项：

关于时间同步：各节点间的时间偏差不大于1s，建议使用统一的ntp服务器进行更新时间；
DR模型中的VIP的MAC广播问题：

安装LVS管理工具ipvsadm

默认情况下，linux系统不自带ipvsadm管理工具包

[14:19:00] root@Tools:~ # dnf install ipvsadm
上次元数据过期检查：1:18:43 前，执行于 2023年10月10日 星期二 13时00分21秒。
依赖关系解决。
=====================================================================================================
 软件包                架构                 版本                       仓库                     大小
=====================================================================================================
安装:
 ipvsadm               x86_64               1.31-1.el8                 AppStream                59 k

事务概要
=====================================================================================================
安装  1 软件包

总下载：59 k
安装大小：86 k
确定吗？[y/N]： y
下载软件包：
ipvsadm-1.31-1.el8.x86_64.rpm                                        3.2 MB/s |  59 kB     00:00
-----------------------------------------------------------------------------------------------------
总计                                                                 3.0 MB/s |  59 kB     00:00
运行事务检查
事务检查成功。
运行事务测试
事务测试成功。
运行事务
  准备中  :                                                                                      1/1
  安装    : ipvsadm-1.31-1.el8.x86_64                                                            1/1
  运行脚本: ipvsadm-1.31-1.el8.x86_64                                                            1/1
  验证    : ipvsadm-1.31-1.el8.x86_64                                                            1/1

已安装:
  ipvsadm-1.31-1.el8.x86_64

完毕！

启用ip_vs模块

查看系统内核是否启用ip_vs模块

[13:54:37] root@Tools:~ # lsmod | grep vs

检查系统中是否安装ipvs模块

[13:55:04] root@Tools:~ # grep CONFIG_IP_VS /boot/config-$(uname -r)
CONFIG_IP_VS=m
CONFIG_IP_VS_IPV6=y
# CONFIG_IP_VS_DEBUG is not set
CONFIG_IP_VS_TAB_BITS=12
CONFIG_IP_VS_PROTO_TCP=y
CONFIG_IP_VS_PROTO_UDP=y
CONFIG_IP_VS_PROTO_AH_ESP=y
CONFIG_IP_VS_PROTO_ESP=y
CONFIG_IP_VS_PROTO_AH=y
CONFIG_IP_VS_PROTO_SCTP=y
CONFIG_IP_VS_RR=m
CONFIG_IP_VS_WRR=m
CONFIG_IP_VS_LC=m
CONFIG_IP_VS_WLC=m
CONFIG_IP_VS_FO=m
CONFIG_IP_VS_OVF=m
CONFIG_IP_VS_LBLC=m
CONFIG_IP_VS_LBLCR=m
CONFIG_IP_VS_DH=m
CONFIG_IP_VS_SH=m
CONFIG_IP_VS_MH=m
CONFIG_IP_VS_SED=m
CONFIG_IP_VS_NQ=m
CONFIG_IP_VS_SH_TAB_BITS=8
CONFIG_IP_VS_MH_TAB_INDEX=12
CONFIG_IP_VS_FTP=m
CONFIG_IP_VS_NFCT=y
CONFIG_IP_VS_PE_SIP=m

[14:31:10] root@Tools:~ #  cd /lib/modules/$(uname -r)/kernel/net/netfilter
[14:31:15] root@Tools:/lib/modules/4.18.0-348.7.1.el8_5.x86_64/kernel/net/netfilter # ls
ipset                          nf_synproxy_core.ko.xz  xt_cgroup.ko.xz       xt_multiport.ko.xz
ipvs                           nf_tables.ko.xz         xt_CHECKSUM.ko.xz     xt_nat.ko.xz
nf_conncount.ko.xz             nf_tables_set.ko.xz     xt_CLASSIFY.ko.xz     xt_NETMAP.ko.xz
nf_conntrack_amanda.ko.xz      nft_chain_nat.ko.xz     xt_cluster.ko.xz      xt_NFLOG.ko.xz
nf_conntrack_broadcast.ko.xz   nft_compat.ko.xz        xt_comment.ko.xz      xt_NFQUEUE.ko.xz
nf_conntrack_ftp.ko.xz         nft_connlimit.ko.xz     xt_connbytes.ko.xz    xt_osf.ko.xz
nf_conntrack_h323.ko.xz        nft_counter.ko.xz       xt_connlabel.ko.xz    xt_owner.ko.xz
nf_conntrack_irc.ko.xz         nft_ct.ko.xz            xt_connlimit.ko.xz    xt_physdev.ko.xz
nf_conntrack.ko.xz             nft_dup_netdev.ko.xz    xt_connmark.ko.xz     xt_pkttype.ko.xz
nf_conntrack_netbios_ns.ko.xz  nft_fib_inet.ko.xz      xt_CONNSECMARK.ko.xz  xt_policy.ko.xz
nf_conntrack_netlink.ko.xz     nft_fib.ko.xz           xt_conntrack.ko.xz    xt_quota.ko.xz
nf_conntrack_pptp.ko.xz        nft_fib_netdev.ko.xz    xt_cpu.ko.xz          xt_rateest.ko.xz
nf_conntrack_sane.ko.xz        nft_flow_offload.ko.xz  xt_CT.ko.xz           xt_RATEEST.ko.xz
nf_conntrack_sip.ko.xz         nft_fwd_netdev.ko.xz    xt_dccp.ko.xz         xt_realm.ko.xz
nf_conntrack_snmp.ko.xz        nft_hash.ko.xz          xt_devgroup.ko.xz     xt_recent.ko.xz
nf_conntrack_tftp.ko.xz        nft_limit.ko.xz         xt_dscp.ko.xz         xt_REDIRECT.ko.xz
nf_dup_netdev.ko.xz            nft_log.ko.xz           xt_DSCP.ko.xz         xt_sctp.ko.xz
nf_flow_table_inet.ko.xz       nft_masq.ko.xz          xt_ecn.ko.xz          xt_SECMARK.ko.xz
nf_flow_table.ko.xz            nft_nat.ko.xz           xt_esp.ko.xz          xt_set.ko.xz
nf_log_syslog.ko.xz            nft_numgen.ko.xz        xt_hashlimit.ko.xz    xt_socket.ko.xz
nf_nat_amanda.ko.xz            nft_objref.ko.xz        xt_helper.ko.xz       xt_state.ko.xz
nf_nat_ftp.ko.xz               nft_queue.ko.xz         xt_hl.ko.xz           xt_statistic.ko.xz
nf_nat_irc.ko.xz               nft_quota.ko.xz         xt_HL.ko.xz           xt_string.ko.xz
nf_nat.ko.xz                   nft_redir.ko.xz         xt_HMARK.ko.xz        xt_tcpmss.ko.xz
nf_nat_sip.ko.xz               nft_reject_inet.ko.xz   xt_IDLETIMER.ko.xz    xt_TCPMSS.ko.xz
nf_nat_tftp.ko.xz              nft_reject.ko.xz        xt_iprange.ko.xz      xt_TCPOPTSTRIP.ko.xz
nfnetlink_cthelper.ko.xz       nft_socket.ko.xz        xt_ipvs.ko.xz         xt_TEE.ko.xz
nfnetlink_cttimeout.ko.xz      nft_tproxy.ko.xz        xt_length.ko.xz       xt_TPROXY.ko.xz
nfnetlink.ko.xz                nft_xfrm.ko.xz          xt_limit.ko.xz        xt_TRACE.ko.xz
nfnetlink_log.ko.xz            xt_addrtype.ko.xz       xt_LOG.ko.xz
nfnetlink_queue.ko.xz          xt_AUDIT.ko.xz          xt_mac.ko.xz
nf_osf.ko.xz                   xt_bpf.ko.xz            xt_mark.ko.xz

启用ipvs

[13:58:14] root@Tools:/lib/modules/4.18.0-348.7.1.el8_5.x86_64/kernel/net/netfilter # sudo modprobe ip_vs

[14:19:07] root@Tools:~ # lsmod | grep ip_vs
ip_vs                 172032  0
nf_conntrack          172032  6 xt_conntrack,nf_nat,ipt_MASQUERADE,xt_nat,nf_conntrack_netlink,ip_vs
nf_defrag_ipv6         20480  2 nf_conntrack,ip_vs
libcrc32c              16384  5 nf_conntrack,nf_nat,nf_tables,xfs,ip_vs

查看LVS运行状态

ipvsadm常用参数

lvs与iptables配置类似，LVS&IPTABLES都使用到netfilter实现数据包过滤也修改

1.定义集群服务格式：
添加集群服务：
ipvsadm -A|E -t|u|f service-address [-s scheduler][-p [timeout]] [-M netmask]
-A                  表示添加一个新的集群服务
-E                  编辑一个集群服务
-t                  表示tcp协议
-u                  表示udp协议
-f                  表示firewall-Mark,防火墙标记
service-address：     集群服务的IP地址，即VIP
-s                    指定调度算法，默认调度算法是wlc
-p                    持久连接时长，默认情况下300秒，如#ipvsadm -Lcn ，查看持久连接状态
-M                    定义掩码
ipvsadm -D -t|u|f service-address      删除一个集群服务
ipvsadm -C                             清空所有的规则
ipvsadm -R                             重新载入规则
ipvsadm -S [-n]                        保存规则

2.向集群服务添加RealServer规则：
添加RealServer规则
ipvsadm -a|e -t|u|f service-address -r server-address
              [-g|i|m] [-w weight]
-a                 添加一个新的realserver规则
-e                 编辑realserver规则
-t                 tcp协议
-u                 udp协议
-f                 firewall-Mark，防火墙标记
service-address    realserver的IP地址
-g                 表示定义为LVS-DR模型
-i                 表示定义为LVS-TUN模型
-m                 表示定义为LVS-NAT模型
-w                 定义权重，后面跟具体的权值
ipvsadm -d -t|u|f service-address -r server-address          --删除一个realserver
ipvsadm -L|l [options]                                       --查看定义的规则
如：#ipvsadm -L -n  
ipvsadm -Z [-t|u|f service-address]                          --清空计数器

3.其它参数
-c                  显示LVS目前的连接信息 如：ipvsadm -L -c
-L                  显示“tcp tcpfin udp”的timeout值，如：ipvsadm -L --timeout
-L                  显示同步守护进程状态，例如：ipvsadm -L --daemon
-L                  显示统计信息，例如：ipvsadm -L --stats
-L                  显示速率信息，例如：ipvsadm -L  --rate
-L                  对虚拟服务器和真实服务器排序输出，例如：ipvsadm -L --sort

[root@hostname ~]# ipvsadm -Ln --stats
IP Virtual Server version 1.2.1 (size=1048576)
Prot LocalAddress:Port               Conns   InPkts  OutPkts  InBytes OutBytes
  -> RemoteAddress:Port
TCP  10.192.0.250:8080             5989211    1568M        0   22417G        0
  -> 10.192.0.17:8080              1975289    1862M        0    7328G        0
  -> 10.192.0.18:8080              1990696    1944M        0    7469G        0
  -> 10.192.0.19:8080              2023226    2055M        0    7620G        0
TCP  10.192.0.251:80                   351     2050        0   181190        0
  -> 10.192.0.15:80                    263     1507        0   126452        0
  -> 10.192.0.16:80                     72      460        0    48082        0
TCP  10.192.0.251:443              8712990    2650M        0   22315G        0
  -> 10.192.0.15:443               7324762  493741K        0   19194G        0
  -> 10.192.0.16:443                275996  383680K        0     568G        0

输出状态解释

https://developer.aliyun.com/article/434430

ActiveConn是活动连接数，也就是tcp连接状态的ESTABLISHED。
InActConn是指除了ESTABLISHED以外所有的其它状态的tcp连接。

那既然这样，为什么从lvs里看的ActiveConn会比在真实机上通过netstats看到的ESTABLISHED高很多呢?问得好！这也是笔者一直迷惑而渐渐清晰的一个问题。原来lvs自身也有一个默认超时时间。可以用ipvsadm -L –timeout查看，默认是900 120 300，分别是TCP TCPFIN UDP的时间.也就是说一条tcp的连接经过lvs后，lvs会把这台记录保存15分钟，而不管这条连接是不是已经失效！所以如果你的服务器在15分钟以内有大量的并发请求连进来的时候，你就会看到这个数值直线上升。

其实很多时候，我们看lvs的这个连接数是想知道现在的每台机器的真实连接数吧？怎么样做到这一点呢？其实知道现在的ActiveConn是怎样产生的，做到这一点就简单了。举个例子：比如你的lvs是用来负载网站，用的模式是dr，后台的web server用的nginx。这时候一条请求过来，在程序没有问题的情况下，一条连接最多也就五秒就断开了。这时候你可以这样设置：ipvsadm –set 5 10 300。设置tcp连接只保持5秒中。如果现在ActiveConn很高你会发现这个数值会很快降下来，直到降到和你用nginx的status看当前连接数的时候差不多。你可以继续增加或者减小5这个数值，直到真实机的status连接数和lvs里的ActiveConn一致。

阿里云SLB

https://developer.aliyun.com/article/1803
”https://help.aliyun.com/zh/slb/classic-load-balancer/product-overview/architecture?spm=a2c4g.11186623.0.0.65f93365ilI1ms“

SLB功能

SLB功能介绍 SLB（Server Load Balance）服务通过设置虚拟服务地址（IP），将位于同一地域（Region）的多台云服务器（Elastic Compute Service，简称ECS）资源虚拟成一个高性能、高可用的应用服务池；再根据应用指定的方式，将来自客户端的网络请求分发到云服务器池中。

SLB服务会检查云服务器池中ECS的健康状态，自动隔离异常状态的ECS，从而解决了单台ECS的单点问题，同时提高了应用的整体服务能力。在标准的负载均衡功能之外，SLB服务还具备TCP与HTTP抗DDoS攻击的特性，增强了应用服务器的防护能力。

SLB服务是ECS面向多机方案的一个配套服务，需要同ESC结合使用。

SLB架构

整个SLB系统由3部分构成：四层负载均衡，七层负载均衡和控制系统，如下图所示；

四层负载均衡，采用开源软件LVS（linux virtual server），并根据云计算需求对其进行了定制化；该技术已经在阿里巴巴内部业务全面上线应用2年多详见第3节；
七层负载均衡，采用开源软件Tengine；该技术已经在阿里巴巴内部业务全面上线应用3年多；参见第4节；
控制系统，用于配置和监控负载均衡系统；

LVS特点

LVS是全球最流行的四层负载均衡开源软件，由章文嵩博士（当前阿里云产品技术负责人）在1998年5月创立，可以实现LINUX平台下的负载均衡。
LVS是基于linux netfilter框架实现（同iptables）的一个内核模块，名称为ipvs；其钩子函数分别HOOK在LOCAL_IN和FORWARD两个HOOK点

在云计算大规模网络环境下，官方LVS存在如下问题；

问题1：LVS支持NAT/DR/TUNNEL三种转发模式，上述模式在多vlan网络环境下部署时，存在网络拓扑复杂，运维成本高的问题；
问题2：和商用负载均衡设备（如，F5）相比，LVS缺少DDOS攻击防御功能；
问题3：LVS采用PC服务器，常用keepalived软件的VRRP心跳协议进行主备部署，其性能无法扩展；
问题4：LVS常用管理软件keepalived的配置和健康检查性能不足；

为了解决上述问题，阿里云在官方LVS基础上进行了定制化；

解决1：新增转发模式FULLNAT，实现LVS-RealServer间跨vlan通讯；
1. FULLNAT实现主要思想：引入local address（内网ip地址），cip-vip转换为lip->rip，而 lip和rip均为IDC内网ip，可以跨vlan通讯；
2. IN/OUT的数据流全部经过LVS，为了保证带宽，采用万兆（10G）网卡；
3. FULLNAT转发模式，当前仅支持TCP协议；
解决2：新增synproxy等攻击TCP标志位DDOS攻击防御功能，LVS针对TCP标志位DDOS攻击，采取如下策略；
1. Synflood攻击，利用synproxy模块进行防御，如下图所示；实现主要思想：参照linux tcp协议栈中syncookies的思想，LVS代理TCP三次握手；代理过程：client发送syn包给LVS，LVS构造特殊seq的synack包给client，client回复ack给LVS，LVS验证ack包中ack_seq是否合法；如果合法，则LVS再和Realserver建立3次握手；
2. Ack/fin/rstflood攻击，查找连接表，如果不存在，则直接丢弃；
解决3：采用LVS集群部署方式；
1. LVS集群部署方式实现的主要思想：LVS和上联交换机间运行OSPF协议，上联交换机通过ECMP等价路由，将数据流分发给LVS集群，LVS集群再转发给业务服务器；
  健壮性：lvs和交换机间运行ospf心跳，1个vip配置在集群的所有LVS上，当一台LVS down，交换机会自动发现并将其从ECMP等价路由中剔除；
  可扩展：如果当前LVS集群无法支撑某个vip的流量，LVS集群可以进行水平扩容；
2. 集群部署方式极大的保证了异常情况下，负载均衡服务的稳定性；
解决4：优化keepalived性能；
1. 对LVS管理软件keepalived进行了全面优化；
2. 优化了网络异步模型，select改为epoll方式；
3. 优化了reload过程；

ali-LVS开源地址 https://github.com/alibaba/LVS

入网流量路径

对于入网流量，CLB会根据用户在控制台或API上配置的转发策略，对来自前端的访问请求进行转发和处理，数据流转如下图所示。

TCP/UDP协议和HTTP/HTTPS协议的流量都需要经过LVS集群进行转发。
LVS集群内的每一台节点服务器均匀地分配海量访问请求，并且每一台节点服务器之间都有会话同步策略，以保证高可用。
- 如果相应的CLB实例服务端口使用的是四层协议（TCP或UDP），那么LVS集群内每个节点都会根据CLB实例的策略，将其承载的服务请求按策略直接分发到后端ECS服务器。
- 如果相应的CLB实例服务端口使用的是七层HTTP协议，那么LVS集群内每个节点会先将其承载的服务请求均分到Tengine集群，Tengine集群内的每个节点再根据CLB策略，将服务请求按策略最终分发到后端ECS服务器。
- 如果相应的CLB实例服务端口使用的是七层HTTPS协议，与上述HTTP处理过程类似，差别是在按策略将服务请求最终分发到后端ECS服务器前，先调用Key Server进行证书验证及数据包加解密等前置操作。

出网流量路径

CLB和后端ECS之间是通过内网进行通信的。

如果ECS仅仅处理来自CLB的请求，可以不购买公网带宽（ECS、公网IP、弹性公网IP、NAT网关等）。
早期创建的一些ECS上直接分配了公网IP（在实例中执行ipconfig命令可以查看公网IP地址），此类ECS如果仅通过CLB对外提供服务，即便在公网接口（网卡）上看到有流量统计，也不会产生ECS的公网费用。
如果需要直接通过后端ECS对外提供服务，或后端ECS有访问外网的需求，那么需要相应的配置或购买ECS、公网IP、弹性公网IP、NAT网关等服务。

ECS的公网流量访问路径如下图所示

总体原则：流量从哪里进来，就从哪里出去。

通过CLB进入的流量在CLB上限速或计费，仅收取出方向流量费用，入方向流量不收取（在未来可能会改变），CLB到ECS之间是阿里云内网通信，不收取流量费用。
来自弹性公网IP或NAT网关的流量，分别在弹性公网IP或NAT网关上进行限速或计费。如果在购买ECS时选择了公网带宽，限速/计费点在ECS上。
CLB仅提供被动访问公网的能力，即后端ECS只能在收到通过CLB转发来的公网的请求时，才能访问公网回应该请求，如后端ECS希望主动发起公网访问，则需要配置或购买ECS公网带宽、弹性公网IP或NAT网关来实现。
ECS公网带宽（购买ECS时配置）、弹性公网IP、NAT网关均可以实现ECS的双向公网访问（访问或被访问），但没有流量分发和负载均衡的能力。

标签：LVS,IP,ko,xz,服务器,xt
From： https://www.cnblogs.com/apink/p/18378981

问题