本文翻译自 Facebook 在 LPC 2021 大会上的一篇分享:《From XDP to Socket: Routing of packets beyond XDP with BPF[1]》。标题可直译为《从 XDP 到 Socket 的(全路径)流量路由:XDP 不够,BPF 来凑》,因为 XDP 运行在网卡上,而且在边界和流量入口,再往后的路径(尤其是到了内核协议栈)它就管不到了,所以引入了其他一些 BPF 技术来“接力”这个路由过程。另外,这里的“路由”并非狭义的路由器三层路由,而是泛指 L3-L7 流量转发。翻译时加了一些链接和代码片段,以更方便理解。
引言
用户请求从公网到达 Facebook 的边界 L4LB 节点之后,往下会涉及到两个阶段(每个阶段都包括了 L4/L7)的流量转发:
以上两个阶段都涉及到流量的一致性路由(consistent routing of packets)问题。本文介绍这一过程中面临的挑战,以及我们如何基于最新的 BPF/XDP 特性来应对这些挑战。
前期工作
几年前也是在 LPC 大会,我们分享了 Facebook 基于 XDP 开发的几种服务,例如:
Facebook 两代软件 L4LB 对比。左:第一代,基于 IPVS,L4LB 需独占节点;右:第二代,基于 XDP,不需独占节点,与业务后端混布。
Facebook 流量基础设施
从层次上来说,如下图所示,Facebook 的流量基础设施分为两层:
从功能上来说,如下图所示:
面临的挑战
总结一下前面的内容:公网流量到达边界节点后,接下来会涉及 两个阶段的流量负载均衡(每个阶段都是 L4 + L7):
这两个阶段都涉及到流量的高效、一致性路由(consistent routing)问题。
本文介绍这一过程中面临的挑战,以及我们是如何基于最新的 BPF/XDP 特性来解决这些挑战的。具体来说,我们用到了两种类型的 BPF 程序:
选择后端主机:数据中心内流量的一致性与无状态路由(四层负载均衡)
先看第一部分,从 LB 节点转发到 backend 机器时,如何来选择主机。这是四层负载均衡问题。
Katran(L4LB)负载均衡机制
回到流量基础设施图,这里主要关注 Origin DC 内部 L4-L7 的负载均衡。
Katran 是基于 XDP 实现的四层负载均衡器,它的内部机制:
用伪代码来表示 Katran 选择后端主机的逻辑:
int pick_host(packet* pkt) {
if (is_in_local_cache(pkt))
return local_cache[pkt]
return consistent_hash(pkt) % server_ring
}
这种机制非常有效,也非常高效(highly effective and efficient)。
一致性哈希的局限性
容错性:后端故障对非相关连接的扰动
一致性哈希的一个核心特性是具备对后端变化的容错性(resilience to backend changes)。当一部分后端发生故障时,其他后端的哈希表项不受影响(因此对应的连接及主机也不受影响)。Maglev 论文中已经给出了评估这种容错性的指标,如下图:
Resilience of Maglev hashing to backend changes
Maglev: A fast and reliable software network load balancer. OSDI 2016
Google 放这张图是想说明:一部分后端发生变化时,其他后端受影响的概率非常小;但从我们的角度来说,以上这张图说明:即使后端挂掉的比例非常小,整个哈希表还是会受影响,并不是完全无感知 —— 这就会导致一部分流量被错误路由(misrouting):
TCP 长连接面临的问题
首先要说明,高效 != 100% 有效。对于 TCP 长连接来说(例如视频),有两种场景会它们被 reset:
int pick_host(packet* pkt) {
if (is_in_local_cache(pkt)) // 场景一:ECMP shuffle 时(例如 LB 节点维护或故障),这里会 miss
return local_cache[pkt]
return consistent_hash(pkt) % server_ring // 场景二:后端维护或故障时,这里的好像有(较小)概率发生变化
}
解释一下:
以上分析可以看出,“持续发布” L4 和 L7 服务会导致连接不稳定,降低整体可靠性。除了发布之外,我们随时都有大量服务器要维护,因此哈希 ring 发生变化(一致性哈希 发生扰动)是日常而非例外。任何时候发生 ECMP shuffle 和服务发布/主机维护,都会导 致一部分 active 连接受损,虽然量很小,但会降低整体的可靠性指标。
解决这个问题的一种方式是在所有 LB 节点间共享这个 local cache (类似于 L4LB 中的 session replication),但这是个很糟糕的主意,因为这就需要去解决另外一大堆分布式系统相关的问题,尤其我们不希望引入任何 会降低这个极快数据路径性能的东西。
QUIC 协议为什么不受影响
但对于 QUIC 来说,这都不是问题。
connection_id:
QUIC 规范(RFC 9000)中允许 server 将任意信息嵌入到包的 connection_id 字段。
Facebook 已经广泛使用 QUIC 协议,因此在 Facebook 内部,我们可以:
完全无状态四层路由:
这样整条链路上都可以从包中提取这个 id,无需任何哈希或 cache 查找,最终实现的是一个完全无状态的四层路由(completely stateless routing in L4)。
那能不能为 TCP 做类似的事情呢?答案是可以。这就要用到 BPF-TCP header option 了。
TCP 连接解决方案:利用 BPF 将 backend server 信息嵌入 TCP Header
原理和流程
基本思想:
以下图为例,我们来看下 LB 节点和 backend 故障时,其他 backend 上的原有连接如何做到不受影响:
假设过了一会发生故障,前面那台 L4LB 挂了(这会导致 ECMP 发生变化);另外,某些 backend hosts 也挂了(这会 影响一致性哈希,原有连接接下来有小概率会受到影响),那么接下来:
可以看到在 TCP Header 中引入了路由信息后,未发生故障的主机上的长连接就能够避免 因 L4LB 和主机挂掉而导致的 misrouting(会被直接 reset)。
开销
数据开销:TCP header 增加 6 个字节
struct tcp_opt {
uint8_t kind;
uint8_t len;
uint32_t server_id;
}; // 6-bytes total
运行时开销:不明显
需要在 L4LB 中解析 TCP header 中的 server_id 字段,理论上来说,这个开销跟代码实 现的好坏相关。我们测量了自己的实现,这个开销非常不明显。
实现细节
监听的 Socket 事件:
switch (skops->op) {
case BPF_SOCK_OPS_TCP_LISTEN_CB:
case BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB:
case BPF_SOCK_OPS_TCP_CONNECT_CB:
case BPF_SOCK_OPS_ACTIVE_ESTABLISHED_CB:
case BPF_SOCK_OPS_PARSE_HDR_OPT_CB:
case BPF_SOCK_OPS_HDR_OPT_LEN_CB:
case BPF_SOCK_OPS_WRITE_HDR_OPT_CB:
. . .
}
维护 TCP flow -> server_id 的映射:
在每个 LB 节点上用 bpf_sk_storage 来存储 per-flow server_id。也就是说:
server_id 的分配和同步:
前面还没有提到如何分配 server_id,以及如何保证这些后端信息在负 载均衡器侧的时效性和有效性。
我们有一个 offline 工作流,会给那些有业务在运行的主机随机分配 一个 id,然后将这个信息同步给 L4 和 L7 负载均衡器(Katran and Proxygen),后者拿到这些信息后会将其加载到自己的控制平面。因此这个系统不会有额外开销,只要保证 LB 的元信息同步就行了。
由于这个机制同时适用于 QUIC 和 TCP,因此 Pipeline 是同一个。
效果
下面是一次发布,可以看到发布期间 connection reset 并没有明显的升高:
限制
这种方式要求 TCP 客户端和服务端都在自己的控制之内,因此:
小结
通过将 server_id 嵌入 TCP 头中,我们实现了一种 stateless routing 机制:
选择 Socket:服务的真正优雅发布(七层负载均衡)
前面介绍了流量如何从公网经过内网 LB 到达 backend 主机。再来看在主机内,如何路由流量来保证七层服务(L7 service)发布或重启时不损失任何流量。
这部分内容在 SIGCOMM 2020 论文中有详细介绍。想了解细节的可参考:https://dl.acm.org/doi/pdf/10.1145/3387514.3405885
当前发布方式及存在的问题
L7LB Proxygen 自身也是一个七层服务,我们以它的升级为例来看一下当前发布流程。
发布流程
一般来说,只要 graceful 时间段设置比较合适,一部分甚至全部老连接能够在这个 窗口内正常退出,从而不会引起用户可见的 spike;但另一方面,如果此时仍然有老连接,那这些客户端就会收到 TCP reset。
存在的问题
很多公司都是用的以上那种发布方式,它的实现成本比较低,但也存在几个问题:
不损失容量、快速且用户无感的发布
以上分析引出的核心问题是:如何在用户无感知的前提下,不损失容量(without losing capacity)且非常快速(very high velocity)地完成发布。
早期方案:socket takeover (or zero downtime restart)
我们在早期自己实现了一个所谓的 zero downtime restart 或称 socket takeover 方案。具体细节见前面提到的 LPC 论文,这里只描述下大概原理:相比于等待老进程的连接完全退出再开始发布,我们的做法是直接创建一个新进程,然后通过一个唯 一的 local socket 将老进程中 TCP listen socket 和 UDP sockets 的文件描述符(以及 SCM rights)转移到新进程。
发布流程:
如下图所示,发布前,实例正常运行,同时提供 TCP 和 UDP 服务,其中:
接下来开始发布:
可以看到,这种方式:
那么,这种方式有什么缺点吗?
存在的问题:
一个显而易见的缺点是:这种发布方式需要更多的系统资源,因为对于每个要升级的实例,它的新老实例需要并行运行一段时间;而在之前发布模型是干掉老实例再创建新实例,不会同时运行。
但我们今天要讨论的是另一个问题:UDP 流量的分发或称解复用(de-multiplex)。
由于 Socket 迁移是在内核做的,而内核没有 QUIC 上下文(在应用层维护),因此 当新老进程同时运行时,内核无法知道对于一个现有 UDP 连接的包,应该送给哪个进程 (因为对于 QUIC 没有 listening socket 或 accepted socket 的概念),因此有些包会到老进程,有些到新进程,如下图左边所示:
为解决这个问题,我们引入了用户空间解决方案。例如在 QUIC 场景下,会查看 ConnectionID 等 QUIC 规范中允许携带的元信息,然后根据这些信息,通过另一个 local socket 转发给相应的老进程,如以上右图所示。
虽然能解决 QUIC 的问题,但可以看出,这种方式非常复杂和脆弱,涉及到大量进程间通信,需要维护许多状态。有没有简单的方式呢?
其他方案调研:SO_REUSEPORT
Socket takeover 方案复杂性和脆弱性的根源在于:为了做到客户端无感,我们在两个进程间共享了同一个 Socket。因此要解决这个问题,就要避免在多个进程之间共享 Socket。
这自然使我们想到了 SO_REUSEPORT[4]:它允许多个 socket bind 到同一个 port。但这里仍然有一个问题:UDP 包的路由过程是非一致的(no consistent routing for UDP packets),如下图所示:
如果新老实例的 UDP socket bind 到相同端口,那一个实例重启时,哈希结果就会发生变化,导致这个端口上的包发生 misrouting。
另一方面,SO_REUSEPORT 还有性能问题:
因此直接使用 SO_REUSEPORT 是不行的。
思考
我们后退一步,重新思考一下我们的核心需求是什么。有两点:
内核提供了很多功能,但并没有哪个功能是为专门这个场景设计的。因此要彻底解决问题,我们必须引入某种创新。
最终我们引入了一个 Socket 层负载均衡器 bpf_sk_reuseport。
新方案:bpf_sk_reuseport
方案设计
简单来说:
好处
这种设计的好处:
发布过程中的流量切换详解
用一个 BPF_MAP_TYPE_REUSEPORT_SOCKARRAY 类型的 BPF map 来配置转发规则,其中:
如下图所示,即使新进程已经起来,但只要还没 ready(BPF map 中仍然指向老进程):
BPF 就继续将所有流量转给老进程:
新进程 ready 后,更新 BPF map,告诉 BPF 程序它可以接收流量了:
BPF 程序就开始将流量转发给新进程了:
前面没提的一点是:我们仍然希望将 UDP 包转发到老进程上,这里实现起来其实就非常简单了:
这也解决了扩展性问题,现在可以并发接收包(one-thread-per-socket),不用担心新进程启动时的 disruptions 或 misrouting 了:
新老方案效果对比
先来看发布过程对业务流量的扰动程度。下图是我们的生产数据中心某次发布的统计,图中有两条线:
可以看到在整个升级期间,丢包数量没有明显变化。
再来看流量分发性能,分别对 socket takeover 和 bpf_sk_reuseport 两种方式加压:
小结
本节介绍了我们的基于 BPF_PROG_TYPE_SK_REUSEPORT 和 BPF_MAP_TYPE_REUSEPORT_SOCKARRAY 实现的新一代发布技术,它能实现主机内新老实例流量的无损切换,优点:
讨论
遇到的问题:CPU 毛刺(CPU spikes)甚至卡顿
生产环境遇到过一个严重问题:新老进程同时运行期间,观察到 CPU spike 甚至 host locking;但测试环境从来没出现过,而且在实现上我们也没有特别消耗 CPU 的逻辑。
排查之后发现,这个问题跟 BPF 程序没关系,直接原因是:
1、在同一个 netns 内有大量 socket。
2、新老实例同时以支持和不支持 bpf_sk_reuseport 的方式 bind 到了同一端口:
bind("[::1]:443"); /* without SO_REUSEPORT. Succeed. */
bind("[::2]:443"); /* with SO_REUSEPORT. Succeed. */
bind("[::]:443"); /* with SO_REUSEPORT. Still Succeed */
3、bind() 实现中有一个 spinlock 会遍历一个 hashtable bucket,这个哈希表只用 dst_port 作为 key 去哈希,如果有大量 http endpoints,由于它们的 dst_port 很可能都是 443 和 80,因此会导致对应哈希槽上的链表特别长,在遍历时就会导致 CPU 毛刺甚至机器卡住。这一问题下一小节专门介绍。
这个问题花了很长时间排查,因此有人在类型场景下遇到类似问题,很可能跟这个有关。相关内核代码[5],修复见 patch[6]。
Listening socket hashtable
进一步解释上一小节提到的 hashtable 导致的 CPU 毛刺甚至卡顿问题以及 Facebook 的改进。这个问题在 Cloudflare 2016 年的分享《The revenge of the listening sockets[7]》中有详细介绍。
// include/net/inet_hashtables.h
static inline struct sock *__inet_lookup(struct net *net,
struct inet_hashinfo *hashinfo,
struct sk_buff *skb, int doff,
const __be32 saddr, const __be16 sport,
const __be32 daddr, const __be16 dport,
const int dif, const int sdif,
bool *refcounted)
{
u16 hnum = ntohs(dport);
struct sock *sk;
// 查找是否有 ESTABLISHED 状态的连接
sk = __inet_lookup_established(net, hashinfo, saddr, sport, daddr, hnum, dif, sdif);
if (sk)
return sk;
// 查找是否有 LISTENING 状态的连接
return __inet_lookup_listener(net, hashinfo, skb, doff, saddr, sport, daddr, hnum, dif, sdif);
}
如以上代码所示,查找一个包对应的 Socket 时:
__inet_lookup_listener() 老代码就不看了,直接看 5.10 的新代码,这已经包含了 Facebook 的 BPF 功能:
// net/ipv4/inet_hashtables.c
struct sock *__inet_lookup_listener(struct net *net,
struct inet_hashinfo *hashinfo,
struct sk_buff *skb, int doff,
const __be32 saddr, __be16 sport,
const __be32 daddr, const unsigned short hnum,
const int dif, const int sdif)
{
struct inet_listen_hashbucket *ilb2;
struct sock *result = NULL;
unsigned int hash2;
// 如果这里 attach 了 BPF 程序,直接让 BPF 程序来选择 socket
/* Lookup redirect from BPF */
if (static_branch_unlikely(&bpf_sk_lookup_enabled)) {
result = inet_lookup_run_bpf(net, hashinfo, skb, doff, saddr, sport, daddr, hnum);
if (result)
goto done;
}
// 没有 attach BPF 程序或 BPF 程序没找到 socket:fallback 到常规的内核查找 socket 逻辑
hash2 = ipv4_portaddr_hash(net, daddr, hnum);
ilb2 = inet_lhash2_bucket(hashinfo, hash2);
result = inet_lhash2_lookup(net, ilb2, skb, doff, saddr, sport, daddr, hnum, dif, sdif);
if (result)
goto done;
/* Lookup lhash2 with INADDR_ANY */
hash2 = ipv4_portaddr_hash(net, htonl(INADDR_ANY), hnum);
ilb2 = inet_lhash2_bucket(hashinfo, hash2);
result = inet_lhash2_lookup(net, ilb2, skb, doff, saddr, sport, htonl(INADDR_ANY), hnum, dif, sdif);
done:
if (IS_ERR(result))
return NULL;
return result;
}
bpf_sk_select_reuseport vs bpf_sk_lookup
这种两种类型的 BPF 程序,分别是 Facebook 和 Cloudflare(根据各自需求)引入内核的, 功能有些相似,因此拿来对比一下。
先看一段 Cloudflare 引入 bpf_sk_lookup 时的 commit message:
This series proposes a new BPF program type named BPF_PROG_TYPE_SK_LOOKUP,
or BPF sk_lookup for short.
BPF sk_lookup program runs when transport layer is looking up a listening
socket for a new connection request (TCP), or when looking up an
unconnected socket for a packet (UDP).
This serves as a mechanism to overcome the limits of what bind() API allows
to express. Two use-cases driving this work are:
(1) steer packets destined to an IP range, fixed port to a single socket
192.0.2.0/24, port 80 -> NGINX socket
(2) steer packets destined to an IP address, any port to a single socket
198.51.100.1, any port -> L7 proxy socket
更多信息,可参考他们的论文:https://www.ccs.neu.edu/home/amislove/publications/IP-Unbound-SIGCOMM.pdf
可以看到,它也允许多个 socket bind 到同一个 port,因此与 bpf_sk_select_reuseport 功能有些重叠,因为二者都源于这样一种限制:在收包时,缺少从应用层直接命令内核选择哪个 Socket 的控制能力。
但二者也是有区别的:
相关链接:
译文链接:https://arthurchiao.art/blog/facebook-from-xdp-to-socket-zh/