12｜高性能网络实战（上）：如何开发一个负载均衡器？

倪朋飞

你好，我是倪朋飞。
上一讲，我带你一起梳理了 eBPF 的安全能力，并教你使用 eBPF 分析和阻止了容器进程的安全问题。在开篇词中我就提到，eBPF 的主要应用场景涵盖了故障诊断、性能监控、安全控制以及网络优化等。从 07 讲 进入实战进阶篇开始，我已经为你介绍了应用于前三个场景中的内核跟踪、用户态跟踪、网络跟踪以及安全控制等。那么，对于最后一个场景，网络性能优化，eBPF 是如何发挥作用的呢？
今天，我就以最常用的负载均衡器为例，带你一起来看看如何借助 eBPF 来优化网络的性能。
Nginx 负载均衡器既然要优化负载均衡器的网络性能，那么首先就需要有一个优化的目标，即初始版的负载均衡器。在今天的案例中，我们使用最常用的反向代理和 Web 服务器 Nginx 作为初始版的负载均衡器，同时也使用自定义的 Nginx 作为后端的 Web 服务器。
为了方便环境的重现，负载均衡器、 Web 服务器以及客户端都运行在容器中，它们的 IP 和 MAC 等基本信息如下图所示：
参考 Nginx 官方文档中 HTTP 负载均衡的配置方法，你可以通过以下几步来搭建上述的案例环境。
1）执行下面的命令，创建上图中的 4 个容器：
# Webserver (响应是hostname，如 http1 或 http2)
docker run -itd --name=http1 --hostname=http1 feisky/webserver
docker run -itd --name=http2 --hostname=http2 feisky/webserver
# Client
docker run -itd --name=client alpine
# Nginx
docker run -itd --name=nginx nginx

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

本文深入介绍了如何使用eBPF开发负载均衡器，并以Nginx负载均衡器为例进行讲解。作者首先介绍了搭建初始版负载均衡器的步骤，然后详细讲解了如何使用eBPF优化负载均衡性能。文章提到了eBPF程序的不同类型，包括XDP程序、TC程序、套接字程序以及cgroup程序，并分别介绍了它们的触发事件和常用场景。接着，作者以套接字和XDP两种方式为例，详细讲解了如何使用eBPF程序优化负载均衡的性能。在套接字eBPF程序的优化方法中，作者提到了创建套接字映射、在不同类型的eBPF程序中存取套接字信息以及加载并挂载eBPF程序到套接字事件等步骤。整体来说，本文通过实际案例和详细步骤，帮助读者了解了如何使用eBPF来优化负载均衡器的网络性能。文章内容涵盖了eBPF程序的不同类型及其应用场景，以及具体的优化方法，对于想要深入了解eBPF在负载均衡器中的应用的读者来说，是一篇值得阅读的技术文章。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《eBPF 核心技术与实战》，新⼈⾸单¥59

立即购买

登录后留言

全部留言(12)

最新
精选

莫名
key: ac 11 00 05 ac 11 00 01 00 00 00 50 00 00 be 12 02 00 00 00 以该 key 为例，struct sock_key 共 5 个 u32 类型的字段，每个字段四个字节，其中： ac 11 00 05 -> sip，网络字节序，源 IP 172.17.0.5，对应负载均衡器容器 IP ac 11 00 01 -> dip, 网络字节序，目的 IP 172.17.0.1，对应 Docker 网桥 docker0 IP 地址，即本机所有容器的默认网关。 00 00 00 50 -> sport, 网络字节序，源端口 80。 00 00 be 12 -> dport, 网络字节序，目的端口 48658。 02 00 00 00 -> family，主机字节序，AF_INET 协议，具体定义为： #define AF_INET 2 /* Internet IP Protocol */ 对 SKB 类型的 BPF 程序了解不多，这里想请教下倪老师，目的 IP (172.17.0.1) 为什么是 Docker 网桥的 IP ？跟 sk_msg 转发逻辑有关么？我理解正常情况下目的 IP 应该是客户端容器 IP。
作者回复: 解析的非常正确。对于你的疑问，其实你到客户端容器中执行相同的nc命令，再观察一下映射中的内容，答案自然就有了。这儿看到172.17.0.1是因为思考题中的nc命令是在主机终端中执行的。
2022-02-11
2
7
Geek9635
在实际应用sockmap时，遇到一个性能问题我的业务模型是同一个pod内，部署nginx及一个java写的api-proxy程序，两者之间通过127.0.0.1通信（长连接）想使用sockmap能力在进程之间加速，实际测试用wrk打流（通过域名）到pod的nginx，发现使用sockmap并没有带来性能的提升（从sar看pod内lo口流量是0）抓取sock_sendmsg到sock_recvmsg之间的时间分布见后： nginx是多进程单线程的，那个java程序是单进程多线程的（抓取的时间分布是两者之间的send->revc时间差，第一列是耗时区间，第二列是次数）从耗时分布情况看，sockmap并没用明显优势（业务cpu已基本打满）但如果简单用netperf tcp_rr测试，sockmap基本耗时分布在8-16usecs，无socketmap基本在16-32usecs 想请教老师，这是sockmap本身的性能问题（实现sock之间报文转发的流程也挺复杂的），还是使用方式方法不对？这种复杂模型的性能分析也非常难，老师是否有毕竟好的方法，谢谢 @normal(usecs): [4, 8) 37 | [8, 16) 131639 | [16, 32) 2206394 | [32, 64) 796467 | [64, 128) 511059 | [128, 256) 378776 | [256, 512) 294895 | [512, 1K) 140723 | [1K, 2K) 26766 | [2K, 4K) 10600 | [4K, 8K) 8053 | [8K, 16K) 2607 | [16K, 32K) 6 | @ebpf sockmap(usecs): [4, 8) 20150 | [8, 16) 1046770 | [16, 32) 1597489 | [32, 64) 574600 | [64, 128) 425788 | [128, 256) 369249 | [256, 512) 327745 | [512, 1K) 187195 | [1K, 2K) 32752 | [2K, 4K) 9646 | [4K, 8K) 7825 | [8K, 16K) 2140 | [16K, 32K) 187 |
作者回复: 这是有有可能的。如果系统本身的性能就不太好，不借助硬件offload方式的优化方法有可能收益并不明显。比如，很多应用本身就有诸如CPU、多线程或者磁盘I/O等方面的瓶颈，内核协议栈带来的性能损失在整个应用的性能中有可能很小，这时候再去优化内核协议栈，当然也很难获得很大的性能优化效果。
2022-03-17
2
3
maosd199554
老师，这种只适合LB跟服务部署同一个服务器吧？
作者回复: 嗯嗯，是的
2022-02-12
3
2
Geek9635
有人能复现老师的测试结果么？我在centos8.3上测试，性能没有太大变化（抓包确认sockmap功能生效） nsenter -t 201559 -n sar -n DEV 1 Average: IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil Average: lo 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 Average: eth0 20805.67 20663.00 1595.32 2001.95 0.00 0.00 0.00 0.00 测试过程中，nginx cpu占用非常高 Tasks: 645 total, 12 running, 633 sleeping, 0 stopped, 0 zombie %Cpu(s): 1.9 us, 31.2 sy, 0.0 ni, 65.2 id, 0.2 wa, 0.3 hi, 1.2 si, 0.0 st MiB Mem : 385191.7 total, 336110.5 free, 9242.4 used, 39838.9 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 361619.3 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 373492 101 20 0 9388 3504 2076 R 97.1 0.0 4:40.45 nginx 373493 101 20 0 9388 3508 2076 R 97.1 0.0 4:14.85 nginx 373495 101 20 0 9388 3496 2076 R 97.1 0.0 6:18.71 nginx 373496 101 20 0 9388 3476 2076 R 97.1 0.0 5:07.61 nginx 373498 101 20 0 9388 3504 2076 R 97.1 0.0 5:28.36 nginx 373501 101 20 0 9388 3480 2076 R 97.1 0.0 6:23.90 nginx 373503 101 20 0 9388 3476 2076 R 97.1 0.0 5:37.27 nginx
作者回复: 使用wrk测试的结果是多少？如果机器本身的性能不太好（比如CPU资源本身就不足的情况下），使用sockmap或者其他的eBPF技术带来的性能收益的确有可能是不明显的。
2022-03-18
2
1
piboye
要开启cgroup v2，grub修改重启才搞定😅
作者回复: 👍 谢谢分享配置的经验。你的发行版是什么？
2022-02-23
2
1
从远方过来
老师，本示例直接将msg从一个sock转发到另一个sock, 那是不是说跳过了内核处理?
作者回复: 是的
2022-03-12


牛金霖
请教一个问题，在哪儿能看到各种各类型的BPF程序的作用和生效条件。还有就是各种MAP的适用场景呢？
作者回复: 我们课程第5讲和第6讲已经介绍了很多程序类型和各种MAP使用方法
2022-02-25


Bachue Zhou
有两个问题请教下老师： 1. 为什么 skops->local_port 这个字段就要转成网络序，skops->remote_port 就不需要？ 2. 我发现在启用了这两个 BPF 程序后，如果 nginx 容器被关闭，wrk 依然无法正常工作，那 nginx 容器在 BPF 程序内扮演了什么角色？
2023-04-10归属地：上海
2
1
李清泉🍻
老师，能出视频么，我基础不好，看得不太懂
2024-03-18归属地：广东


～～
请问这里挂载到/sys/fs/cgroup是不是只对容器进程生效, 如果我用shell打开一个进程, 是不是不能生效. 我发现ops程序只能观测到容器的网络操作
2023-09-19归属地：上海



收起评论