对于云计算和 NFV，ASAP 在三个方面战胜 DPDK

admin

电信服务提供商对云计算和网络功能虚拟化 (NFV) 等技术加大投入，改造他们的基础架构，以便能够在新服务创建上更敏捷，在按需服务扩展上更有弹性，在基础架构扩建上获得更好的经济性。难怪一些领先的服务提供商也是 NFV 技术的最强支持者和开发者，包括中国移动、中国电信、NTT、AT&T、德国电信、Verizon、Vodafone 等等，不胜枚举。
电信云和 NFV 的一项关键功能是转移，即从在专用装置（比如运行防火墙并且仅限防火墙的机盒）上运行网络功能转移到在高容量、一般用途的服务器、存储和交换平台上运行，这些平台有时也称为 COTS（商用现货）设备。自然地，设计带有合适 COTS 硬件的基础架构为 NFV 应用程序提供最佳支持，这一点是实现总体 NFV 性能和效率的关键，也是最终 NFV 可以在多长时间内越过概念证明阶段实现真正大规模部署的关键。
对来源于 NFV 应用 – 虚拟化网络功能 (VNF) 的计算和网络基础架构有一些独特的要求。在本博客文章中，我们关注最基本的一个要求：数据包性能，因为直观地说无论是物理上的还是虚拟化的网络功能都要处理网络流量。VNF 查看数据包，了解它们，并根据预先配置的规则和政策进行处理。数据包性能通常以每秒百万个数据包 (Mpps) 衡量。注意，这与吞吐量不同，后者衡量 I/O 系统传输比特流的速度。吞吐量通常以每秒千兆比特 (Gbps) 衡量。对于相同的吞吐量，数据包性能可能有很大差异。例如，对于 10Gbps 的吞吐量，理论上，64 字节数据包流的最大数据包性能可达 14.88 Mpps，而 1500 字节数据包流则为 0.82 Mpps。小数据包对 I/O 系统推动线路速率吞吐量的能力施加更高压力。
在电信级的网络中，有大量主要由小数据包组成的控制流量。此外，实时语音流量的数据包也只有 100 字节左右。为了确保以太网网络能够支持各种服务（如 VoIP、视频等），并满足高可用性要求，IETF 定义的 RFC2544 使用七个预定义的帧大小（64、128、256、512、1024、1280 和 1518 字节）来模拟各种流量情况，并在服务开通时执行全面的以太网测试。一般认为，RFC2544 和小数据包性能对确保服务质量和提高客户满意度至关重要。遗憾的是，有一些交换机无法通过 RFC 2544，但是，架构良好的交换机能以零丢包率交换任意大小的数据包。
但对于 NFV，目标是用一般用途的 CPU 构建的服务器来换出已经通过 RFC2544 的系统。这些一般用途的 CPU 和运行于该 CPU 上的操作系统不是为执行高速数据包处理任务而设计的。如果我们要查看关于路由器等网络设备如何构建的历史记录，CPU 一直都是关键组件。从历史上说，路由器始于在通用处理器上运行的软件。Cisco 在 1986 年推出了第一台商用多协议路由器 AGS（先进网关服务器），它基于 Motorola 68000 系列的 CPU (M68k)。由于此处理器的速度限制和其他因素，数据包交换性能即使采用快速交换，速度也仅限于每秒 7,000 到 14,000 个数据包 (pps) 的范围，按今天的标准衡量，那是相当疲软。经过 30 年的快速发展，知名路由器供应商不再使用 CPU 执行包数据路径转发。所有供应商都改用自定义 ASIC、商用芯片或配备更好的网络处理器来支持路由器线卡需要推送的数十或数百千兆比特的吞吐量。路由器上的 CPU 只对运行控制和管理层面的路由处理器发挥重要作用。
为增强 CPU 处理数据包的能力，Intel 和其他有贡献的公司创建了数据平面开发套件 (DPDK)，这是一组旨在快速处理数据包的数据平面库和网络接口控制器驱动程序。除优化缓冲区管理和其他增强之外，DPDK 还改变了数据包接收操作，从推送模式改为轮询模式，消除 Linux 网络栈中的一些中断、上下文切换和缓冲区复制，实现数据包性能成倍提高。但缺点也显而易见，部署 DPDK 的人需要专门拿出一定数量的 CPU 内核，只是用于数据包处理。这些昂贵的 CPU 内核以 GHz 速率反复轮流运行，什么都不做，只是等待数据包到达。
作为高性能服务器互连领域的领先者，Mellanox 网卡包含对 DPDK 的轮询模式驱动程序 (PMD) 支持，在 ConnectX-4 100G 网卡方面，我们创下了大于 90 Mpps 的 DPDK 性能记录。不过我们有一个更好的方法，能更好地解决 NFV 数据包性能问题。我们称之为加速的交换和数据包处理 (ASAP)。它结合了服务器/存储网络硬件、网卡（网络接口卡）的性能和效率以及虚拟交换软件的灵活性，为软件定义的网络提供最高的基础架构效率、部署灵活性和操作简单性。
从 Mellanox ConnectX-3 Pro 系列网卡开始，Mellanox 在其网卡芯片中设计了内嵌式交换机 (eSwitch)。此 eSwitch 是基于流的交换引擎，能够以更高的性能级别和更好的安全性和隔离性，为服务器上运行的不同虚拟机执行 2 层 (L2) 交换。随着我们转向当前这代 ConnectX-4 网卡执行数据包分类和叠加虚拟网络隧道协议处理，尤其是 VXLAN 封装和解封装，eSwitch 功能已得到增强。在最新的 ConnectX-5 网卡中，eSwitch 能够处理诸如包头重写之类的 3 层 (L3) 操作、诸如标签推送/弾出之类的 MPLS 操作，甚至是灵活的客户定义的解析以及供应商特定标头的包头重写。ASAP 加速器构建于 eSwitch 网卡硬件之上，允许整个虚拟交换机或者虚拟交换机的重要部分或分布式虚拟路由器 (DVR) 操作能够卸载到 Mellanox 网卡，以实现数据包性能的极大提高，并显著降低 CPU 开销。同时，ASAP 保持 SDN 控制层面完好无损，SDN 控制器仍与虚拟交换机通信，传递网络控制信息。这正是现代网络设备的构建方式，一个软件控制和管理层面以及一个硬件数据层面。
ASAP 在 3 个关键方面轻松战胜 DPDK：

更高的数据包性能
更低的 CPU 开销（更高的基础架构效率）
无隐性成本

1. 更高的数据包性能
人们从直觉上知道硬件比软件表现好，但好多少？我们对比了 ASAP 情形与 DPDK 加速的 OVS 情形下的数据包性能，对于前者，Open vSwitch (OVS) 的数据路径被卸载到 Mellanox Connect-X 4 Lx 网卡，对于后者，通过使用 DPDK 库在用户空间内完全运行 OVS，绕过 hypervisor 内核来提升数据包性能。
在数据包性能方面出现了强烈的对比：对于少量的数据流：64 字节数据包流，ASAP 在 25G 接口上达到了 33 Mpps，其理论上最大数据包性能是 37.2 Mpps。而对于 DPDK 加速的 OVS，最佳性能为 8-9 Mpps，还不到 ASAP 所达到性能的 30%。
我们按比例增加数据流的数量时，对比甚至更加明显：ASAP 可以达到的数据包性能大约是 DPDK 加速的 OVS 的 10 倍。对于 60,000 字节的数据流，以及在 ConnectX-4 Lx eSwitch 中处理的 VXLAN 封装/解封装，ASAP 达到 18 Mpps。对于相同数量的数据流，OVS over DPDK 达到 1.9 Mpps。值得一提的是，OVS over DPDK 配置使用的是标准 VLAN，因为对 OVS over DPDK 配置 VXLAN 并不简单。我们预计，如果使用 VXLAN，OVS over DPDK 性能甚至更低。

2. 更低的 CPU 开销（更高的基础架构效率）
在以上所有情形中，DPDK 加速的 OVS 消耗 4 个 CPU 内核，而 ASAP 零消耗，实现 CPU内核零占用，通过软件定义的 OVS 控制层达到高得多的性能。当我们转移到 25G、50G 或 100G 服务器连接时，DPDK 的 CPU 开销将变得无法忍受，您愿意拿出 10 或 15 个 CPU 内核专门用于数据包处理吗？那您就没有多余的 CPU 内核来做其他事情了。对于云服务提供商，这直接影响他们的总收入，因为对他们来说，在他们的服务器上能运行的虚拟机或容器越多，他们挣的钱越多。如果他们为 DPDK 分配大量的 CPU 内核，那么在其服务器上运行的虚拟机就少了，这样挣钱就少了！
3. 无隐性成本
Linux 网络协议栈的主要维护者 David Miller 在他的 Netdev 会议主题演讲快速可编程网络和封装协议中，让他的听众重复三遍“DPDK 不是 Linux”。他想要确保人们了解运行 DPDK 需要单独的 BSD 许可证。如果要使用商用 DPDK 加速的虚拟交换机解决方案，就有额外的成本。
相反，ASAP 就不涉及任何附加费用。ConnectX-4 Lx 是我们向我们的超大规模客户大量推出的高容量网卡，与其他高容量网卡相比，它的定价非常有竞争力。与 OVS 卸载（使用 ASAP 将 OVS 数据层面卸载到网卡硬件）相关的所有变化都上溯到开放源社区，包括 OVS 和 Linux。OVS 卸载对应用程序是透明的，在应用层不需要任何改动就能利用 ASAP。Mellanox 对 ASAP 加速器不收一分钱，它是我们最新几代 ConnectX 网卡的标准配置。
获得 Mellanox ConnectX-4 Lx 毫不费力，我们的多个服务器 OEM 合作伙伴都在其产品中随带该网卡，包括惠普、戴尔、联想、华为、曙光和浪潮。尽快尝试 ASAP 吧，立即增强您的 NFV 性能和效率！
声明:本文转载自网络。版权归原作者所有,如有侵权请联系删除。