Kubernetes 网络分析之 IPVS 模式基础 LVS

陈sir的知识库
3,813 阅读12分钟

lvs简介

首先解释下下文中出现的各种术语：

  • Director: 负载均衡调度器, 负责在前端接受用户请求根据特定的算法转发到后端Real Server
  • Real Server: 后端提供服务的服务器
  • VIP: Director接受用户请求的IP地址
  • DIP: Director和Real Server联系的IP地址
  • RIP: Real Server的IP地址
  • CIP: Client IP, 客户端的IP地址

LVS其实由两个组件组成, 在用户空间的ipvsadm和内核空间的ipvs, ipvs工作在INPUT链上, 如果有请求报文被ipvs事先定义，就会将请求报文直接截取下根据其特定的模型修改请求报文, 再转发到POSTROUTING链上送出TCP/IP协议栈其报文流经过程如下：

  1. 当客户端的请求到达负载均衡器的内核空间时，首先会到达PREROUTING链。

  2. 当内核发现请求数据包的目的地址是本机时，将数据包送往INPUT链。

  3. LVS由用户空间的ipvsadm和内核空间的IPVS组成，ipvsadm用来定义规则，IPVS利用ipvsadm定义的规则工作，IPVS工作在INPUT链上,当数据包到达INPUT链时，首先会被IPVS检查，如果数据包里面的目的地址及端口没有在规则里面，那么这条数据包将被放行至用户空间。

  4. 如果数据包里面的目的地址及端口在规则里面，那么这条数据报文将被修改目的地址为事先定义好的后端服务器，并送往POSTROUTING链。

  5. 最后经由POSTROUTING链发往后端服务器。

lvs特点

lvs具有以下特点：

  • ipvs工作于netfilter框架上。简单来说就是把ip加端口定义为ipvs集群服务，ipvs会为此请求定义一个或多个后端服务目标地址未必会改，但是报文会被强行转发给后端的服务器。

  • ipvs组件： ipvsadm（用户空间，用来编写规则） + ipvs（内核空间）

  • ipvs工作在第四层：

    1. 四层交换、四层路由。 做第四层转发。（osi模型中的网络层）
    2. 只能基于ip和port转发，无法在应用层，session级别转发
    3. 不用到达应用层空间，就能转发。即工作在第四层不能进行7层负载均衡，但基于4层可以不要管上层协议进行负载均衡，只要支持tcp或udp就行。
    4. lvs 性能很好，但是由于只第四层，不能到用户空间，因此不能进行更加精细的控制。 在精细控制方面，haproxy和Ngnix可以更好的实现。lvs通常作为总入口，更精细化的切割可能使用，haproxy或者Nginx实现

lvs实现方式 lvs的实现方法为实现模型和负载均衡调度算法

实现模型为：
        1、NAT
        2、DR
        3、TUN
        4、FULLNAT
负载均衡调度算法分为两种：静态和动态
        静态：
            RR
            WRR
            SH
            DH
        动态：
            LC
            WLC
            SED
            NQ
            LBLC
            LBLCR

lvs实现方式之nat模型

详解图

如图实现过程如下：

  1. 客户端将请求发往前端的负载均衡器，请求报文源地址是CIP(客户端IP),后面统称为CIP)，目标地址为VIP(负载均衡器前端地址，后面统称为VIP)。
  2. 负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的目标地址改为了后端服务器的RIP地址并将报文根据算法发送出去。
  3. 报文送到Real Server后，由于报文的目标地址是自己，所以会响应该请求，并将响应报文返还给LVS。
  4. 然后lvs将此报文的源地址修改为本机并发送给客户端。注意：在NAT模式中，RealServer的网关必须指向LVS，否则报文无法送达客户端。

NAT模型其实就是一个多路的DNAT,客户端对VIP进行请求,Director通过事先指定好的调度算法计算出应该转发到哪台RS上, 并修改请求报文的目标地址为RIP,通过DIP送往RS. 当RS响应客户端报文给CIP,经过Director时,Director又会修改源地址为VIP并将响应报文发给客户端. 这段过程对于用户来说是透明的.

关于nat模型有几点需要注意：

  • RS和Director必须要在同一个IP网段中
  • RS的网关必须指向DIP
  • 可以实现端口映射
  • 请求报文和响应报文都会经过Director
  • RS可以是任意操作系统
  • DIP和RIP只能是内网IP

lvs实现方式之dr

详解图

如图过程如下：

  1. 客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP。
  2. 负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的源MAC地址改为自己DIP的MAC地址，目标MAC改为了RIP的MAC地址，并将此包发送给RS。
  3. RS发现请求报文中的目的MAC是自己，就会将次报文接收下来，处理完请求报文后，将响应报文通过lo接口送给eth0网卡直接发送给客户端。注意：需要设置lo接口的VIP不能响应本地网络内的arp请求。DR模型是一个较为复杂的模型。

DR模型比较诡异,因为VIP在Director和每一个RS上都存在，客户端对VIP(Director)请求时,Director接收到请求会将请求报文的源MAC地址和目标MAC地址修改为本机DIP所在网卡的MAC地址和指定的RS的RIP所在网卡的MAC地址, RS接收到请求报文后直接对CIP发出响应报文, 而不需要通过Director

实现DR模型有一个最为关键的问题,大家都知道Linux主机配置一个IP地址会向本网络进行广播来通告其他主机或网络设备IP地址对应的MAC地址,那么VIP分别存在于Director和RS,IP不就冲突了么,我们该如何解决这个问题？

事实上LVS并不能帮助我们解决这个麻烦的问题，我们有很多种方法可以解决上面的问题: 网络设备中设置VIP地址和Director的MAC地址进行绑定,Linux系统中有一个软件可以实现对ARP广播进行过滤, arptables可以修改内核参数来实现, arp_ignore, arp_announce

实现DR模型需要注意的: 1、RS和Director可以不在同一IP网段中, 但是一定要在同一物理网络中 2、请求报文必须经过Director, 但是响应报文一定不能通过Director 3、RS的网关不能是Director 4、不能实现端口映射 5、RS可以是大部分操作系统 6、DIP和RIP可以是公网地址

lvs实现方式之tun

详解图

如图tun工作流程如下：

    1、客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP。

    2、负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将在客户端请求报文的首部再封装一层IP报文,将源地址改为DIP，目标地址改为RIP,并将此包发送给RS。

    3、RS收到请求报文后，会首先拆开第一层封装,然后发现里面还有一层IP首部的目标地址是自己lo接口上的VIP，所以会处理次请求报文，并将响应报文通过lo接口送给eth0网卡直接发送给客户端。注意：需要设置lo接口的VIP不能在共网上出现。

tun模型原理如下：

    TUN模型通过隧道的方式在公网中实现请求报文的转发,客户端请求VIP(Director),Director不修改请求报文的源IP和目标IP,而是在IP首部前附加DIP和对应RIP的地址并转发到RIP上,RS收到请求报文, 本地的接口上也有VIP, 遂直接响应报文给CIP。

需要注意的要点是：

  • RIP,DIP,VIP都是公网地址
  • RS的网关不能指向DIP
  • 请求报文必须通过Director, 响应报文一定不能经过Director
  • 不支持端口映射
  • RS的操作系统必须支持隧道功能

lvs实现方式之FULLNAT

FULLNAT实现原理: FULLNAT是近几年才出现的,客户端请求VIP(Director),Director修改请求报文的源地址(DIP)和目标地址(RIP)并转发给RS, FULLNAT模型一般是Director和RS处在复杂的内网环境中的实现。

LVS FULLNAT特性：

  • FULLNAT模式也不需要DIP和RIP在同一网段
  • FULLNAT和NAT相比的话：会保证RS的回包一定可到达LVS
  • FULLNAT需要更新源IP，所以性能正常比NAT模式下降10%

实现FULLNAT模型需要注意的:

    1、VIP是公网地址, DIP和RIP是内网地址, 但是无需在同一网络中
    2、请求报文需要经过Director, 响应报文也要通过Director
    3、RIP接收到的请求报文的源地址为DIP,目标地址为RIP
    4、支持端口映射
    5、RS可以是任意的操作系统

lvs之算法

调度算法分为两种：静态算法和动态算法。

静态调度算法: 根据算法本身进行调度, 不考虑RS的状态
动态调度算法: 根据算法和RS的实时负载进行调度

静态算法

  1. RR：轮询调度（Round Robin）

调度器通过”轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载｡

  1. WRR：加权轮询（Weight RR）

调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求。这样可以保证处理能力强的服务器处理更多的访问流量。调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。

  1. DH：目标地址散列调度（Destination Hash ）

根据请求的目标IP地址，作为散列键(HashKey)从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空。

  1. SH：源地址 hash（Source Hash）

源地址散列”调度算法根据请求的源IP地址，作为散列键(HashKey)从静态分配的散列表找出对应的服务器，若该服务器是可用的且未超载，将请求发送到该服务器，否则返回空｡

动态算法

  1. LC：最少链接（Least Connections）

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

  1. WLC：加权最少连接(默认采用的就是这种)（Weighted Least Connections）

在集群系统中的服务器性能差异较大的情况下，调度器采用“加权最少链接”调度算法优化负载均衡性能，具有较高权值的服务器将承受较大比例的活动连接负载｡调度器可以自动问询真实服务器的负载情况,并动态地调整其权值。

  1. SED：最短延迟调度（Shortest Expected Delay ）

在WLC基础上改进，Overhead =（ACTIVE+1）*256/加权，不再考虑非活动状态，把当前处于活动状态的数目+1来实现，数目最小的，接受下次请求，+1的目的是为了考虑加权的时候，非活动连接过多缺陷：当权限过大的时候，会倒置空闲服务器一直处于无连接状态。

  1. NQ永不排队/最少队列调度（Never Queue Scheduling NQ）

无需队列。如果有台 realserver的连接数＝0就直接分配过去，不需要再进行sed运算，保证不会有一个主机很空间。在SED基础上无论+几，第二次一定给下一个，保证不会有一个主机不会很空闲着，不考虑非活动连接，才用NQ，SED要考虑活动状态连接，对于DNS的UDP不需要考虑非活动连接，而httpd的处于保持状态的服务就需要考虑非活动连接给服务器的压力。

  1. LBLC：基于局部性的最少链接（locality-Based Least Connections）

基于局部性的最少链接”调度算法是针对目标IP地址的负载均衡，目前主要用于Cache集群系统｡该算法根据请求的目标IP地址找出该目标IP地址最近使用的服务器，若该服务器是可用的且没有超载，将请求发送到该服务器;若服务器不存在，或者该服务器超载且有服务器处于一半的工作负载，则用“最少链接”的原则选出一个可用的服务器，将请求发送到该服务器｡

  1. LBLCR：带复制的基于局部性最少连接（Locality-Based Least Connections with Replication）

带复制的基于局部性最少链接”调度算法也是针对目标IP地址的负载均衡，目前主要用于Cache集群系统｡它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射｡该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组，按”最小连接”原则从服务器组中选出一台服务器，若服务器没有超载，将请求发送到该服务器；若服务器超载，则按“最小连接”原则从这个集群中选出一台服务器，将该服务器加入到服务器组中，将请求发送到该服务器｡同时，当该服务器组有一段时间没有被修改，将最忙的服务器从服务器组中删除，以降低复制的程度。

参考文章1 参考文章2

avatar
文章
阅读
粉丝