其他分享
首页 > 其他分享> > IPVS的简单了解

IPVS的简单了解

作者:互联网

IPVS (IP Virtual Server)实现了传输层负载均衡,也就是我们常说的4层我们知道ipvs 会使用 iptables 进行包过滤、SNAT、masquared(伪装)。

Linux负载均衡LVS(IPVS)

LVS是Linux Virtual Server的简称,也就是Linux虚拟服务器, 是一个由章文嵩博士发起的自由软件项目,现在已经是 Linux标准内核的一部分。LVS是一种叫基于TCP/IP的负载均衡技术,转发效率极高,具有处理百万计并发连接请求的能力。
LVS的IP负载均衡技术是通过IPVS模块实现的。IPVS模块是LVS集群的核心软件模块,它安装在LVS集群作为负载均衡的主节点上,虚拟出一个IP地址和端口对外提供服务。用户通过访问这个虚拟服务(VS),然后访问请求由负载均衡器(LB)调度到后端真实服务器(RS)中,由RS实际处理用户的请求给返回响应。

IPVS有三种转发模式

1.DR模式(Direct Routing)
2.NAT模式(Network Address Translation)
3.FULLNAT模式
三种转发模式性能从高到低:DR > NAT >FULLNAT。

1.DR模式(Direct Routing)

DR模式下,客户端的请求包到达负载均衡器的虚拟服务IP端口后,负载均衡器不会改写请求包的IP和端口,但是会改写请求包的MAC地址为后端RS的MAC地址,然后将数据包转发;真实服务器处理请求后,响应包直接回给客户端,不再经过负载均衡器。所以DR模式的转发效率是最高的,特别适合下行流量较大的业务场景,比如请求视频等大文件。

  DR模式的特点:

数据包在LB转发过程中,源/目的IP端口都不会变化
  LB只是将数据包的MAC地址改写为RS的MAC地址,然后转发给相应的RS。

每台RS上都必须在环回网卡上绑定LB的虚拟服务IP
  因为LB转发时并不会改写数据包的目的IP,所以RS收到的数据包的目的IP仍是LB的虚拟服务IP。为了保证RS能够正确处理该数据包,而不是丢弃,必须在RS的环回网卡上绑定LB的虚拟服务IP。这样RS会认为这个虚拟服务IP是自己的IP,自己是能够处理这个数据包的。否则RS会直接丢弃该数据包!

RS上的业务进程必须监听在环回网卡的虚拟服务IP上,且端口必须和LB上的虚拟服务端口一致
  因为LB不会改写数据包的目的端口,所以RS服务的监听端口必须和虚拟服务端口一致,否则RS会直接拒绝该数据包。

RS处理完请求后,响应直接回给客户端,不再经过LB
  因为RS收到的请求数据包的源IP是客户端的IP,所以理所当然RS的响应会直接回给客户端,而不会再经过LB。这时候要求RS和客户端之间的网络是可达的。

LB和RS须位于同一个子网
  因为LB在转发过程中需要改写数据包的MAC为RS的MAC地址,所以要能够查询到RS的MAC。而要获取到RS的MAC,则需要保证二者位于一个子网,否则LB只能获取到RS网关的MAC地址。

2. NAT模式(Network Address Translation)

NAT模式下,请求包和响应包都需要经过LB处理。当客户端的请求到达虚拟服务后,LB会对请求包做目的地址转换(DNAT),将请求包的目的IP改写为RS的IP。当收到RS的响应后,LB会对响应包做源地址转换(SNAT),将响应包的源IP改写为LB的IP。

  NAT模式的特点:

LB会修改数据包的地址
  对于请求包,会进行DNAT;对于响应包,会进行SNAT。

LB会透传客户端IP到RS(DR模式也会透传)
  虽然LB在转发过程中做了NAT转换,但是因为只是做了部分地址转发,所以RS收到的请求包里是能看到客户端IP的。

需要将RS的默认网关地址配置为LB的浮动IP地址
  因为RS收到的请求包源IP是客户端的IP,为了保证响应包在返回时能走到LB上面,所以需要将RS的默认网关地址配置为LB的虚拟服务IP地址。当然,如果客户端的IP是固定的,也可以在RS上添加明细路由指向LB的虚拟服务IP,不用改默认网关。

LB和RS须位于同一个子网,并且客户端不能和LB/RS位于同一子网
  因为需要将RS的默认网关配置为LB的虚拟服务IP地址,所以需要保证LB和RS位于同一子网。

  又因为需要保证RS的响应包能走回到LB上,则客户端不能和RS位于同一子网。否则RS直接就能获取到客户端的MAC,响应包就直接回给客户端了,不会走网关,也就走不到LB上面了。这时候由于没有LB做SNAT,客户端收到的响应包源IP是RS的IP,而客户端的请求包目的IP是LB的虚拟服务IP,这时候客户端无法识别响应包,会直接丢弃。

3. FULLNAT模式

FULLNAT模式下,LB会对请求包和响应包都做SNAT+DNAT。

  FULLNAT模式的特点:

LB完全作为一个代理服务器
  FULLNAT下,客户端感知不到RS,RS也感知不到客户端,它们都只能看到LB。此种模式和七层负载均衡有点相似,只不过不会去解析应用层协议,而是在TCP层将消息转发
LB和RS对于组网结构没有要求
  不同于NAT和DR要求LB和RS位于一个子网,FULLNAT对于组网结构没有要求。只需要保证客户端和LB、LB和RS之间网络互通即可。
虽然FULLNAT模式的性能比不上DR和NAT,但是FULLNAT模式没有组网要求,允许LB和RS部署在不同的子网中,这给运维带来了便利。并且 FULLNAT模式具有更好的可拓展性,可以通过增加更多的LB节点,提升系统整体的负载均衡能力。

IPVS支持的调度算法

对于后端的RS集群,LB是如何决策应该把消息调度到哪个RS节点呢?这是由负载均衡调度算法决定的。IPVS常用的调度算法有:

轮询(Round Robin)
  LB认为集群内每台RS都是相同的,会轮流进行调度分发。从数据统计上看,RR模式是调度最均衡的。

加权轮询(Weighted Round Robin)
  LB会根据RS上配置的权重,将消息按权重比分发到不同的RS上。可以给性能更好的RS节点配置更高的权重,提升集群整体的性能。

最小连接数(Least Connections)
  LB会根据和集群内每台RS的连接数统计情况,将消息调度到连接数最少的RS节点上。在长连接业务场景下,LC算法对于系统整体负载均衡的情况较好;但是在短连接业务场景下,由于连接会迅速释放,可能会导致消息每次都调度到同一个RS节点,造成严重的负载不均衡。

加权最小连接数(Weighted Least Connections)
  最小连接数算法的加权版~

地址哈希(Address Hash)
  LB上会保存一张哈希表,通过哈希映射将客户端和RS节点关联起来。

为什么使用IPVS,IPVS的应用场景

尽管 Kubernetes 在版本v1.6中已经支持5000个节点,但使用 iptables 的 kube-proxy 实
际上是将集群扩展到5000个节点的瓶颈。 在5000节点集群中使用 NodePort 服务,如
果有2000个服务并且每个服务有10个 pod,这将在每个工作节点上至少产生20000个
iptable 记录,这可能使内核非常繁忙。
ipvs (IP Virtual Server) 实现了传输层负载均衡,也就是我们常说的4层LAN交换,作为
Linux 内核的一部分。ipvs运行在主机上,在真实服务器集群前充当负载均衡器。ipvs
可以将基于TCP和UDP的服务请求转发到真实服务器上,并使真实服务器的服务在单个
IP 地址上显示为虚拟服务。

ipvs vs iptables:

我们知道kube-proxy支持 iptables 和 ipvs 两种模式, 在kubernetes v1.8 中引入了 ipvs
模式,在 v1.9 中处于 beta 阶段,在 v1.11 中已经正式可用了。iptables 模式在 v1.1 中
就添加支持了,从 v1.2版本开始 iptables 就是 kube-proxy 默认的操作模式,ipvs 和
iptables 都是基于netfilter的。ipvs 会使用 iptables 进行包过滤、SNAT、masquared。
具体来说,ipvs 将使用ipset来存储需要DROP或masquared的流量的源或目标地址,
以确保 iptables 规则的数量是恒定的,这样我们就不需要关心我们有多少服务了。

启动ipvs的要求:

文章内容来自:https://www.jianshu.com/p/89f126b241db

标签:LB,RS,IP,ipvs,模式,IPVS,了解,简单,客户端
来源: https://www.cnblogs.com/abzor/p/15131025.html