本文地址:https://www.ebpf.top/post/cilium-standalone-L4LB-XDP-zh

Seznam.cz 是一家捷克技术公司,开发定制搜索引擎、广告平台、在线地图、内容管理系统,以及私有云服务、定制硬件和数据中心。

1. 架构

Seznam 的基础设施早期采用 F5 硬件负载平衡器,但几年前我们切换到了软件负载均衡器。到目前为止,我们一直在使用 多层 架构:

不幸的是,随着流量的增加,并且由于 COVID,我们开始出现硬件供应短缺,我们迫切需要寻找更优的方案来更有效地使用硬件。

我们一直在密切关注 Cilium 并注意到 Cilium 1.10 版本中的独立 L4LB XDPCilium 关于 maglev 的说明。XDP 钩子(hook)以有效利用 CPU 而著称,具有极高的性能。这对我们的团队来说非常有趣,因为我们的流量峰值高达 20M 活动连接,这大大增加了 IPVS 节点的 CPU 使用率。

我们的负载均衡器设置将外部流量接入到 Kubernetes 和 OpenStack 集群,IPVS 用于经典的 “负载均衡器” 场景。简单架构看起来如下所示:

Seznam.cz architecture

由于我们一直在使用 maglev 调度程序(自 v4.18 以来,它是 Linux 内核中 netfilter 的一部分),那么独立 L4LB XDP 将是一个完美的选择,因为其支持我们的所有主要功能诉求,包括 IPIP、DSR、maglev。

我们在 IPVS 节点上使用了 25GbE NIC,因此在 XDP 驱动程序层运行 L4LB 没有问题,因为大多数现代 NIC 都支持它。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# ethtool -i eth0
driver: i40e
version: 2.8.20-k
firmware-version: 6.02 0x80003621 1.1747.0
expansion-rom-version:
bus-info: 0000:c1:00.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: yes
# lspci | grep Ether
c1:00.0 Ethernet controller: Intel Corporation Ethernet Controller XXV710 for 25GbE SFP28 (rev 02)

2. 启动独立 L4LB

Cilium 本身使用 Docker 镜像发布,我们尝试直接在 IPVS 节点本身上运行。为了在 Cilium 容器重新启动/升级时正常工作,我们使用 systemd 服务来挂载 bpf 文件系统:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# cat /etc/systemd/system/sys-fs-bpf.mount
[Unit]
Description=BPF mounts
DefaultDependencies=no
Before=local-fs.target umount.target
After=swap.target
 
[Mount]
What=bpffs
Where=/sys/fs/bpf
Type=bpf
 
[Install]
WantedBy=multi-user.target
 

然后我们仅以载均衡器模式启动 Cilium:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
systemctl start sys-fs-bpf.mount; docker run \
--cap-add NET_ADMIN \
--cap-add SYS_MODULE \
--cap-add CAP_SYS_ADMIN \
--network host \
--privileged \
-v /sys/fs/bpf:/sys/fs/bpf \
-v /lib/modules \
--name l4lb \
<our_private_docker_repo>/cilium cilium-agent \
--bpf-lb-algorithm=maglev \
--bpf-lb-mode=dsr \
--bpf-lb-acceleration=native \
--bpf-lb-dsr-dispatch=ipip \
--devices=eth0 \
--datapath-mode=lb-only \
--enable-l7-proxy=false \
--tunnel=disabled \
--install-iptables-rules=false \
--enable-bandwidth-manager=false \
--enable-local-redirect-policy=false \
--enable-hubble=false \
--enable-l7-proxy=false \
--preallocate-bpf-maps=false \
--disable-envoy-version-check=true \
-auto-direct-node-routes=false \
--enable-ipv4=true \
--enable-ipv6=true

我们提供大约 3k 个服务并使用 30+ 个 L7 节点,因此我们很快就达到了 lbmap 的默认值。 因此,我们添加了 --bpf-lb-map-max 512000 选项进行调整。

3. 设置服务

Cilium 提供了 API 来设置 lbmaps,这里我们使用以下命令来配置服务:

1
cilium service update --id $idx --frontend "$svc" --backends "$backends" --k8s-node-port

其中:

  • frontend 代表每个 VIP 服务
  • backends 代表 L7 节点

完整设置样例如下所示:

1
2
3
4
5
6
$ cilium service update --id 1 \
			--frontend "10.248.11.13:7047" \ 
			--backends "10.246.3.34:7047, \
								  10.246.39.33 :7047, \
								  10.246.39.34:7047"  \
			--k8s-node-port

对于 BGP 公告,我们使用 BIRD, 所以这部分相当简单:

1
2
# systemctl start bird
# systemctl start bird6

4. 负载对比

测试工具和场景设置如下:

我们决定在一个运行 MoonGen 的单一客户产生的合成测试/负载下比较 IPVS 和 L4LB,MoonGen 有 1 个 CPU 和 64B 的小数据包,带有 TCP SYN 选项设置。

在这个过程中,我们对 MoonGen 生成器发出的数据包(tcp 段)进行了配置,以随机化源 IP 地址和 TCP 源端口,从而使流量分布在所有接收 rx 队列中,因为我们的网卡被配置为使用 4 元组(src IP, dst IP, src TCP port, dst TCP port)散列:

1
2
3
4
5
6
# ethtool -n eth0 rx-flow-hash tcp4
TCP over IPV4 flows use these fields for computing Hash flow key:
IP SA
IP DA
L4 bytes 0 & 1 [TCP/UDP src port]
L4 bytes 2 & 3 [TCP/UDP dst port]

在测试运行期间,我们使用另一个客户端运行一个简单的 GET 请求(在 while 循环中使用 curl)来查看服务器请求处理情况。

测试设置如下图所示:

Seznam.cz testing

4.1 结果

在这两种场景(场景 #1 IPVS 和场景 #2 L4LB)中,MoonGen 客户端被配置为生成 1Mpps(每秒百万数据包)和 3Mpps。下面的每个输出屏幕截图均取自于对应的被测服务器 IPVS/L4LB 或 curl 客户端。

L4LB XDP 模式下,1Mpps 和 3Mpps 都可轻松处理,对性能没有任何影响。 从 10Mpps 开始,我们仅看到在 14.8 Mpps 流量时受到影响,但这可能是由于 NIC 而不是 L4LB 的限制。

4.1.1 1Mpps - IPVS

IPVS htop 输出 :

IPVS 1Mpps

Curl client 输出 :

IPVS 1Mpps curl

CPU 并没有完全被占用,但已接近极限,并且不时丢包。

4.1.2 3Mpps - IPVS

IPVS htop 输出 :

IPVS 3Mpps

Curl client 输出 :

IPVS 3Mpps curl

由于处理中断的所有 CPU 内核都已用尽,所有来自第二个客户端的数据包几乎都被 IPVS 节点丢弃。

4.1.3 10Mpps - L4LB XDP

L4LB htop 输出 :

L4LB 10Mpps

Curl client 输出 :

L4LB 10Mpps curl

4.1.4 14.8Mpps - L4LB XDP

L4LB htop 输出 :

L4LB 14.8Mpps

Curl client 输出 :

L4LB 14.8Mpps curl

在流量达到 14.8Mpps 时,偶尔出现数据包丢弃情况,但这是由于达到了网卡限制,这完全符合预期。

5. 生产环境流量验证

当我们将 L4LB XDP 部署到一个之前运行 IPVS 生产节点时,最大的惊喜出现了。由于我们可以完全访问节点并且能够在任何时间点启动/停止 BIRD,我们能够干净地在 L4LB XDP 节点和 IPVS 节点之间切换流量。

大约上午 11:00,我们停止了 IPVS 节点上的 BIRD,以便 L4LB XDP 节点处理所有流量,大约上午 11:14,我们切换到运行 IPVS 的 2 个节点。

Packets per second 每秒数据包数(越高越好)

上面的输出显示:

在 ~11:04 - 11:13 期间,生产流量从 750kpps 上升到 1Mpps,这是由使用 L4LB XDP 的单个主机 lb-l3-5.ko.iszn.cz 处理的。

在 ~11:16,我们切换到运行 IPVS 的 2 台主机 lb-l3-7.ko.iszn.czlb-l3-9.ko.iszn.cz(这段时间的总流量也在 1Mpps)。

当我们查看 CPU 使用率时,效果非常显著。有一次,我们不确定是否在某个地方存在错误,因为当 L4LB XDP 处理流量时 CPU 负载非常低。但仔细观察后,与 IPVS 处理流量时的 2x18 CPU 相比,它确实只消耗了单个 CPU 的一半。

当切换到 L4LB XDP 时,我们节省了 36 个 CPU。

CPU Load

注:图片取自我们的生产 Grafana 面板中的 CPU 负载(越低越好)

6. 总结

截图不言自明,但对我们来说关键是,L4LB XDP在驱动层的大部分HTTP流量节省了处理生产流量所需的大量 CPU - 我们 90% 的流量是 HTTP 请求

在我们完全切换到 L4LB XDP 之前,Cilium 中唯一缺少功能是加权后端功能,该功能我们正在开发中:maglev:支持通过新的 cmdline 参数在服务规范中设置后端的权重。该功能开发完成后,那么就没有什么能阻止我们告别 IPVS。

借此,我们要感谢 Cilium 社区构建了如此出色的项目并给予了支持!

  • 原文地址:https://cilium.io/blog/2022/04/12/cilium-standalone-L4LB-XDP/
  • 原文作者: Ondrej Blazek@ Seznam.cz