theme: github

DPDK

DPDK是一组用于快速数据包处理的库和驱动程序，用于加速在各种CPU架构上运行的数据包处理工作负载。

DPDK架构图

DPDK的优势

• 任务都是在用户空间实现的，DPDK通过驱动程序直接操作硬件
• per-CPU(关键数据无锁化)，每个CPU核心只处理自己本地的数据，不需要访问其他CPU的数据，这样就可以避免加锁
• 网卡队列/CPU 绑定（避免上下文切换），利用DPDK 的 API 实现一个网卡的一个收发队列对应一个CPU核心和一个Worker进程，实现一一对应和绑定，从而实现了处理能力随CPU核心、网卡队列数的增加而线性增长，并且很好地实现了并行处理和线性扩展；

转发模式

DR

工作原理

• LVS调度器修改请求报文的目标MAC地址为所选真实服务器的MAC地址，但源地址和目标地址不变。这样请求报文直接通过二层网络就可发送给选定的后端member；
• 后端Member接收到请求后，处理请求并生成响应数据，直接将响应数据发送回客户端。此时源IP是VIP，目标IP为CIP(客户端IP)。
• 由于响应数据不经过LVS调度器，所有并发访问量大时使用效率很高；

特点

• DR模式仅修改数据包的目标MAC地址，只有请求数据包通过LVS，所有DR模式不支持对端口的转换；
• 要求负载均衡与真实服务器必须在同一个网段下下，且VIP地址不能真实服务器的为默认网关；
• 后端Member需要配置loopback地址，真实服务器需要更改ARP协议，“隐藏” lo 接口上的 VIP；
  • net.ipv4.conf.lo.arp_ignore/net.ipv4.conf.all.arp_ignore=1：控制服务器如何响应ARP请求，设置为1，这样服务器就只会响应那些目标IP地址与本机网络接口（网卡）IP地址相同，且源IP地址也在同一子网段内的ARP查询请求
  • net.ipv4.conf.lo.arp_announce/net.ipv4.conf.all.arp_announce=2：控制服务器在发出ARP请求时的行为，设置为2，这样服务器在发送ARP请求时，总是使用最佳的源IP地址，而不是VIP。这有助于避免ARP广播冲突

生产环境中遇到的问题

• 造成IP地址浪费，一个端口需要绑定一个VIP；
• 在服务器混部的场景下，Loopback管理难度大，重启服务器后loopback地址容易丢失；

为什么需要配置Loopback 地址？ 为了实现负载均衡器和真实服务器之间的直接通信，而不需要经过任何网关或路由器。当客户端发送请求到负载均衡器时，负载均衡器将请求转发给真实服务器，并使用Loopback地址作为源地址和目的地址，从而实现了负载均衡器和真实服务器之间的直接通信

TUN

特点

• 不改变请求数据包，在请求数据包上新增一层IP首部信息。因此负载均衡器不能对端口进行转发，但可以和真实服务器不在同一网段内，且真实服务器需要支持解析两层IP首部信息，即需要支持IP Tunnneling或IP Encapsulation协议
• 真实服务器中的VIP，只能被自己看见，其他设备不可见。因此需要在真实服务器上绑定Loopback地址，并且不允许将此网卡信息经过ARP协议对外通告；
• 请求的数据包经过负载均衡器后，响应真数据直接由实服务器返回给客户端，响应数据包不需要再经过负载均衡器

依赖条件

• 安装ipip模块：modprobe ipip
• 修改ARP协议：net.ipv4.conf.tunl0/all.arp_ignore=1、net.ipv4.conf.tunl0/all.arp_announce=2
• 关闭数据包源地址校验：net.ipv4.conf.tunl0.rp_filter=0、net.ipv4.conf.all.rp_filter=0

案例

对耗时严格的场景，优化手段：

• 由Full NAT模式改为TUN模式；
• 改变了TCP算法，使用BBR算法

TCP 控制算法 BBR 自从 Linux 内核 4.9 开始已经封装了这个新的 TCP 控制算法 BBR。 BBR 算法由 Google 提出，原先主要用于 Google 内部网络的速度提升，现在 Google 把它提交到了 Linux 内核，所有人都可以使用了。从 Google 的报告来看，这一新的算法可以明显降低网络延迟。Youtube 全球的延迟比之前的 CUBIC 算法下降了 50% 以上。 QUIC是应用层协议，用户可以插拔式选择像Cubic、BBR、Reno等拥塞控制算法，也可以根据具体的场景定制私有算法。 作用：

1. 在有一定丢包率的网络链路上充分利用带宽；
2. 降低网络链路上的 buffer 占用率，从而降低延迟。

NAT

特点

• 修改数据包的目标IP地址或源IP地址，所有请求数据包、响应数据包都经过负载均衡，所有NAT模式支持对端口的转换
• 真实服务器的默认网关为负载均衡器，所有必须在同一网段下

FullNAT

特点

• 同时修改目标IP地址和源IP地址，支持对端口进行转发
• 负载均衡器不需要以网关形式存在，允许不在同一网段下
• 真实服务器最终建立的连接是 DIP ➡️ RIP，无法获取真实客户端的 IP 地址
• 请求数据包、响应数据包都经过负载均衡

toa模块工作原理

通过toa模块获取客户端真实IP地址。

• 客户端请求数据包到达LVS时，LVS会在数据包的tcp option中插入src ip和src port信息
• 数据包到达装有toa模块的后端服务器后，应用程序正常调用getpeername系统函数来获取连接的源端 IP 地址
• 由于在toa代码中hook（修改）了inet_getname函数（getpeername 系统调用对应的内核处理函数），该函数会从 tcp option中获取lvs填充的src信息。