Facebook 宣布开源 Katran，高性能第4层负载均衡器

编译自：https://code.facebook.com/posts/1906146702752923

全球数十亿人在使用Facebook服务，为此我们的基础设施工程师开发了一系列系统来优化流量，并为每个人确保快速可靠的访问。今近日Facebook宣布：开源 Katran，一个可扩展的网络负载均衡器，并概述了其工具来自动化网络工作流程。

网络负载均衡器 Katran

授权协议：GPLv2

开发语言：C/C++

开发厂商：Facebook

操作系统：跨平台

GitHub地址：https://github.com/facebookincubator/katran

Katran：重新设计转发平面

Katran是我们的第二代L4LB，采用了完全重新设计的转发平面，比前一个版本有了显著改进。内核界最近的两个创新助力这种新设计：

XDP提供了一种快速的可编程网络数据路径，无需采用全面的内核旁路方法，可与Linux网络堆栈结合使用。（XDP详细介绍：https://www.iovisor.org/technology/xdp）

eBPF虚拟机在内核的特定区域运行用户空间提供的程序，因而提供了一种灵活、高效、更可靠的方法与Linux内核进行交互，并扩展功能。eBPF已在几个方面带来了显著的改进，包括追踪和过滤。

该系统的总体架构与第一代L4LB相似：首先，ExaBGP向外界通告某一个Katran实例负责哪个VIPS。其次，发往VIP的数据包使用ECMP机制发送到Katran实例。最后，Katran选择一个后端，将数据包转发到正确的后端服务器。主要区别在于最后一步。

及早高效的数据包处理：Katran结合使用XDP与BPF程序来转发数据包。XDP在驱动程序模式下被启用后，数据包处理例程（BPF程序）在网卡（NIC）收到数据包之后、内核截获之前立即运行。面对每个入站数据包，XDP一律调用BPF程序。如果网卡有多个队列，为每一个队列并行调用该程序。用于处理数据包的BPF程序是无锁的，使用每个CPU特有的BPF映射。由于这种并行机制，性能可以随网卡的RX队列的数量呈线性扩展。Katran还支持“通用XDP”操作模式（而不是驱动程序模式），但性能受到影响。

成本低廉但更稳定的哈希：Katran使用Maglev哈希的扩展版来选择后端服务器。扩展版哈希的几项功能是，遇到后端服务器故障后可迅速恢复，更均匀地分配负载以及能够为不同的后端服务器设置不等的权重。这最后一项是重要功能，让我们得以轻松处理入网点和数据中心的硬件更新：我们只要设置适当的权重就可以兼容新一代硬件。尽管计算这个哈希的代码更具表达力，但很小巧，足以完全装入到L1缓存中。

更有弹性的本地状态：Katran处理数据包和计算哈希方面很高效，因而与本地状态表有了有趣的交互。我们发现，对后端服务器选择组件而言，计算哈希从运算方面来看常常比查找5元组的本地状态表来得容易。在本地状态表查找一路遍历到共享的最后一级缓存这种情况下，这个现象来得更明显。为了自然地充分利用这种现象，我们将查找表实施成LRU驱逐缓存。LRU缓存大小在启动时可加以配置，充当可调参数，在计算和查找之间求得平衡。我们凭经验选择了这些值，针对pps进行优化。此外，Katran提供了一个运行时“仅计算”开关，那样万一主机遇到灾难性的内存压力，就完全忽略LRU缓存。

对RSS友好的封装：接收端扩展（RSS）是网卡中的一个重要优化，旨在通过将来自每路数据流的数据包转发到单独的CPU，从而在CPU之间均匀地分配负载。Katran设计的封装技术可与RSS结合使用。不是为每个IP-in-IP数据包使用同样的外部源，而是使用不同的外部源IP来封装不同数据流中的数据包（比如有不同的5元组），但同一数据流中的数据包始终被分配同样的外部源IP。

图4：Katran为高速处理数据包提供了一条快速路径，无需借助全面的内核旁路。请注意，数据包通过内核/用户空间边界只有一次。这让我们得以在不牺牲性能的情况下，将L4LB和后端应用程序放在一起。

这些功能显著增强了L4LB的性能、灵活性和可扩展性。如果没有入站数据包，Katran的设计还消除了几乎不耗用任何CPU的接收路径上的繁忙循环。相比全面的内核旁路解决方案（比如DPDK），使用XDP便于我们在同一个主机上让Katran与任何应用程序一起运行，性能不会出现任何下降。今天Katran在我们的入网点上与后端服务器一起运行，L4LB与后端之比得到了改进。这还增强了面对负载猛增、主机故障和维护的适应能力。重新设计的转发平面是这一转变的核心。我们认为，若使用我们的转发平面，其他系统也能从中得益，于是我们开源了代码，并附有如何用它来设计L4LB的几个例子。

其他注意事项

Katran在实现性能提升的某些假设和约束条件下运行。实际上，我们发觉这些约束条件相当合理，没有阻止我们的部署。我们认为，使用我们库的大多数用户会发现它们易于满足。我们在下面逐一列出：

● Katran只在直接服务返回（DSR）模式下工作。

● Katran是决定发往VIP的数据包的最终目的地的组件，所以网络需要先将数据包路由发送到Katran。这要求网络拓扑结构基于L3，比如数据包由IP路由发送，而不是由MAC地址路由发送。

● Katran无法转发分段的数据包，也无法自行对数据库分段。这可以通过增加网络内部的最大传输单元（MTU）或更改来自后端的通告TCPMSS来缓解。（即使你增加了MTU，还是建议采取后一个措施。）

● Katran不支持带有IP选项集的数据包。最大数据包大小不得超过3.5 KB。

● Katran当初在构建时假设它将用于“一体化负载均衡系统”这个场景，即单一接口将用于“从用户到L4LB（入口）”的流量和“从L4LB到L7LB（出口）”的流量。

尽管存在上述这些限制，我们还是认为Katran为希望利用XDP和eBPF这两项卓越创新来构建高效负载均衡系统的用户和组织提供了一种出色的转发平面。

●本文编号276，以后想阅读这篇文章直接输入276即可

●输入m获取文章目录