利用 eBPF 的高性能可编程的电信网络
利用 eBPF 的高性能可编程的电信网络
为了实现云原生，电信运营商需要一种将其工作负载与硬件细节解耦和抽象的方法。eBPF 可以提供改进的性能，简化的操作以及完整的可视性。
翻译自 Performant and Programmable Telco Networking with eBPF 。
为了保持全球联通，电信网络需要在性能和可编程性方面做出响应，以便在客户需要的时间和地点满足他们的需求，无论是实时传输世界杯的冠军进球，还是协调应对最新的自然灾害。
当交换机还由人工操作员运行时，电信公司主要关注的是定制硬件，供应商提供的“黑匣子”可以提供网络所需的速度。这些黑匣子控制网络的性能，这也使得网络性能取决于它们实际部署的位置。
随着电信运营商从传统的电话通话转向包括消息传递和移动数据等附加服务，对网络的需求推动了可能性的边界。网络功能虚拟化（NFV）试图使用“白盒”通用硬件来扩展吞吐量并增加灵活性。
像数据平面开发工具包（DPDK）等技术的开发旨在加速网络，通过在用户空间中重新实现大部分 Linux 网络堆栈，使网络靠近定制硬件的性能，从而实现更高的吞吐量、更低的数据包处理延迟，并使添加功能变得更加容易，而不是试图将其引入内核。然而，这两个趋势开始相互矛盾。
这些盒子的性能变得依赖于每个主机的微调，而在没有绝对统一的服务器的情况下，很难在规模上维护，但在规模上绝对统一也是不可能的，从而产生了运营的噩梦。电信运营商陷入了两难境地，面临云的复杂性，却没有云的灵活性和可扩展性等好处。
如今，随着消费者 24/7 在线，每家公司都在转向云以提供其服务，电信运营商需要传递的内容以及他们可以依赖的内容已经发生了巨大的变化。构建可扩展的分布式系统的云原生方法的兴起使得该行业处于一个关键的十字路口，他们需要云原生基础架构，但仍然受制于 NFV、DPDK 和其他相关技术的包袱。
能够将性能、灵活性和操作可扩展性有机地结合在一起，是电信服务提供商下一代网络所需的，但这也引发了一个问题，即我们是否能最终在各处实现性能良好且可编程的网络愿景。通过从过去的技术转变中吸取教训，我们可以看出关键在于拥有实际上无处不在的高性能技术。这就是 eBPF 的出现。
eBPF 是一种源于网络的 Linux 内核技术。它允许用户在保持安全、高性能和集成的前提下，对 Linux 内核的功能进行编程扩展。更重要的是，eBP F本身就是 Linux 内核的一部分，因此在运行半现代内核（4.18 及以上版本）的任何地方都可以使用。
与其重新路由到功能可以实现的地方不同，eBPF可以在各处实现高效的数据包处理。eBPF已经在改变电信网络，因为它提供了集成不同协议（如SCTP）、编程性能（如使用NAT46/64和SRv6减少操作复杂性）、通过XDP实现高性能负载均衡，以及完整的可观察性，以查看瓶颈所在。
有了 eBPF，电信运营商可能终于能够在不陷入操作噩梦的情况下，实现长期以来一直在努力追求的性能可编程网络。作为价值链中的关键角色，电信供应商现在在网络层面上拥有了一个独特的机会和工具集，可以使用 eBPF 将他们的网络功能现代化，使其适用于云原生世界。
将网络功能虚拟化提速
随着电信运营商从专用硬件盒子过渡到运行在“白盒”通用硬件上的 NFV，他们的性能和操作考虑需要改变，以适应这种新的范式。
使用专用设备，如数据包处理器、DSP 和 FPGA 等，关键的网络性能特征（如吞吐量、延迟和抖动）在很大程度上是一致且可预测的。当放弃“裸金属”和专用设备的性能优势时，电信运营商仍然需要保持网络性能的速度，即使在水平扩展时也需要保持与需求和客户期望的步调一致。
图1：电信运营商从硬件设备转向网络功能虚拟化以进行扩展，但在灵活性和一些性能方面做出了妥协。
现在，电信运营商需要采取补偿措施来解决这些关键的网络参数。数据平面开发工具包（DPDK）作为一个构建块集合被创造出来，以在高性能数据处理中进行组合，重点关注网络数据包处理。
Single Root I/O Virtualization（SR-IOV）允许将单个 PCI 设备“分割”为多个虚拟功能。因此，多个进程可以获得自己的原始 PCI 设备的迷你版本，而不是“共享”一个共同的设备。直接 PCI 分配允许从内核中分离 PCI 设备，并允许进程（虚拟机或容器）直接操作它。
将这三个概念结合起来，就可以构建功能强大的数据平面，其操作类似于传统数据包交换的操作。在此基础上，将它们与供应商提供的现有控制平面结合，就创建出了一个虚拟路由器（VNF）。这成为（仍然是）会议、讨论和谈话中的一个重要议题。
为 KVM 虚拟机提供高效的网络配置，包括在 KVM 本身、QEMU、Libvirt 和最终 OpenStack （通过 Neutron ML2 插件）中都具有特殊功能。还创建了 OPNFV 项目，以探索虚拟世界中的性能，提供理论参考、测量和测试套件。
NFV 运营仍然在电子表格上运行
然而，尽管这些技术在将 NFV 的性能接近裸金属方面效果显著，但它们也带来了重大的操作负担。为虚拟机提供高效的网络配置需要在规模上进行精细的编排和资源管理。
往往情况下，这种“编排”仍然不是自动化的过程，而是一个非常繁重的过程。经常可以看到使用 PCI 设备地址的 Excel 表格。在正常操作期间，这是一项手动且容易出错的任务，在网络故障期间，它变成了一个无望的迷宫，需要解决问题并恢复连接。
试图自动化这些细节导致了项目的产生，如 Open Network Automation Platform（ONAP） 和 Airship ，但仍然使网络性能依赖于哪个服务器正在运行哪个软件。即使有了这些项目，当在数千个位置的电信规模上进行操作时，还需要协调太多的细节。
为操作复杂性换取性能的做法，使电信运营商陷入了一个进退两难的境地，他们需要扩展网络以满足需求，但扩展会影响性能并引入额外的操作复杂性。大多数 NFV 是黑匣子软件的糟糕移植版本，从未设计用于云中运行。
供应商被困在后面，从头开始重写整个堆栈的成本太高昂。电信运营商需要在网络的各个位置提供高性能和可编程的解决方案，而不需要担心云原生带来的复杂性。
图2：eBPF 将操作过程从电子表格中移出
NFV 与云原生碰撞
在这个关键的转折点上，IT 世界正在发生另一个技术革命，云和云原生计算的兴起。容器和容器编排比你能说出 “Kubernetes” 这个词的速度还要快，工作负载 IP 地址的更改速度甚至比人们在手机上切换应用程序的速度还要快。
与 OpenStack 相比，Kubernetes 来自超大规模云提供商的世界，对于网络的看法与电信世界的惯常看法有根本性的不同。Kubernetes 提供了一个扁平的网络，每个 Pod 都应该能够与其他任何 Pod 通信，而无需进行 NAT。
试图将这种模型与电信网络的预期相结合，导致了项目如 Multus 和 SR-IOV 容器网络接口的出现。然而，这些技术并没有加速电信网络的转型，反而试图在云原生世界中复制 NFV 模型，使用 PCI 设备 ID 、CPU 钉扎等，从而错过了两者的好处。为了真正在其规模上进行云原生，电信运营商需要一种将其工作负载与硬件细节解耦和抽象的方法。
eBPF 登场 —— 在全球范围内加速和简化网络
如今，电信运营商需要裸金属性能，同时脱离底层硬件细节，并且需要在一个日益动态的世界中实现，而不增加操作复杂性。
并没有等待 Linux 内核的改变，eBPF 之所以出现，是因为它可以修改和加速网络，同时与 Linux 网络堆栈无缝集成 —— 最重要的是，它已经是内核的一部分，在任何运行半现代内核（4.18 及以上版本）的地方都可以使用。通过 eBPF，电信运营商可以实现多功能且高效的数据包处理，提高吞吐量和性能，而无需在操作上花费精力去找出它在哪里可用。
eBPF 不仅仍然是内核的一部分，并与之集成，而不是像 DPDK 一样绕过内核，或者使用特定 PCIs 固定 Pod 到特定节点，eBPF 还能够充分利用现有的内核网络堆栈，同时在需要时修改、加速并提高效率。
由于 eBPF 是 Linux 内核的一部分，它已经在网络中无处不在，使得电信运营商可以将网络扩展进行商品化，同时保持良好的性能。在云原生时代，eBPF 为增强网络能力提供了一个有前途的途径，同时简化了电信运营的操作，使其网络环境更易于管理和扩展。它还为电信供应商提供了一个途径，可以将其网络功能中已硬编码为 SRIOV、DPDK 甚至特定硬件的部分现代化，使它们能够在不必担心基础设施的情况下运行。
图3：eBPF 为电信网络带来了灵活性、可观测性和性能
可观测性的持续关注
由于网络始终保持在线，并且可能需要数十年才能停用，电信运营商还必须考虑到基础设施的第二天和第二十年的操作问题。物理盒子和虚拟网络功能已经适用于静态环境，并且与硬件相关，但在云原生世界中已经无法跟上步伐。在 Kubernetes 中，基础设施变得更加动态和不可预测，因此拥有良好的操作和可观测性方案从“好是有好处的”变成了必不可少的。
与以前的工具不同，eBPF 是内核本身的一部分，这意味着不需要对应用程序或基础设施进行修改，即可获得良好的系统、网络和协议可观测性。
与其要求每个供应商都对其网络功能进行仪器化或修改，不如使用 eBP F提供给电信运营商完整的可视性，从而大大降低了启动的操作障碍。而且由于 eBPF 已经在各处可用，可观测性现在可以轻松获得 —— 即使对于无法或不会更新的遗留系统。借助 eBP ，电信运营商可以逐渐摆脱复杂的专有网络和协议跟踪系统，这些系统仍然是重要的操作成本驱动因素。
对于电信网络来说，eBPF 可以为云原生需求提供性能改进、操作简化和完整可视性，同时仍然支持现有系统。
使用 eBPF 构建真实世界的电信网络
如果 eBPF 看起来过于美好，让我们看一些实际世界中的示例，说明它如何在今天的真实世界中改变网络，例如整合不同的协议、支持双栈和 IPv6，并提高负载平衡性能。
作为一种网络技术，eBPF 非常适合支持电信工作负载，因为它基于数据包而不是协议级别。基于 eBPF 的网络项目 Cilium 很容易添加对 SCTP 的支持，而且尽管 Linux 内核不完全了解 GTP/GRPS 协议本身，但 eBPF 可以进行完整的协议解析。
世界也正在从 IPv4 向 IPv6 过渡，再次通过理解数据包，eBPF 能够在 IPv4 和 IPv6 之间进行无缝转换。这还使它能够支持高级的电信网络拓扑，如 SRv6，并使它们能够为其网络增加价值。通过在内核中处理数据包，而不是将信息传输到用户空间，eBPF 还提供了低 CPU 成本的可观测性。
最后，通过在数据包进入网络堆栈之前对其进行处理，eBPF 能够提供极高性能的负载均衡。通过切换到 eBPF，Seznam 能够将 CPU 消耗减少了 72 倍，Cloudflare 使用 eBPF 进行所有的 DDoS 保护，使其能够在单个服务器上每秒丢弃超过 800 万个数据包。在 SmartNICs/DPUs 上运行的 eBPF 还使它们能够以标准化的方式进行编程，而不是被绑定到特定的供应商界面。eBPF 正在改变网络，而不仅仅是未来的承诺。
图4：eBPF 显著降低了资源消耗
使用 eBPF 构建高性能和可编程的电信网络
对于寻求增强网络能力并在云原生时代及其后续时代简化操作的电信运营商来说，采用 eBPF 提供了一个引人注目的机会。它提供了多功能和高效的数据包处理，脱离了硬件特定的细节，同时与 Linux 网络堆栈无缝集成。由于 eBPF 已经通过 Linux 内核在他们的网络中可用，电信运营商可以在今天就利用它，而不是在电子表格中搜索哪台服务器上可以使用它。他们可以实现提高吞吐量能力、减轻操作负担，并增强可视性和可观测性，这仅仅是一个开始。