SmartNIC、DPU和SPU:优点、问题与挑战

最近围绕着卸载引擎,特别是DPU(数据处理单元),产生了很多话题,这一点并不令人惊讶。不仅有多家公司加入其中,包括VMware最新的Project Monterey的公告,而且这种话题也验证了行业正朝着一个更灵活、基于服务器的存储和网络方法转变。但是,不管你是否考虑使用卸载卡、SmartNIC、GPU、DPU还是SPU,有一点是肯定的,它们并非都是相同水平的。

好的方面

SmartNIC和DPU能够将工作负载从通用CPU中分离出来

DPU,更常见的称为数据处理单元,是一个可选设备(通常是一个PCIe卡),旨在将传统上在服务器CPU上运行的网络或存储服务转移到卡本身。为什么这样有益呢?当你考虑到传统的基于服务器的行业解决方案,比如超融合基础设施,将存储或网络服务运行在服务器CPU上意味着你正在消耗服务器CPU、网络和内存资源。仅存储服务就可能在系统启动时占用服务器资源的30%(取决于启用了哪些数据服务),而这些是本可以用于应用程序的服务器资源。另一个好处是,某些服务通过专门针对特定任务定制的硬件执行和扩展效果更好,就像GPU一样。

在过去的一段时间里,虽然网卡一直在卸载网络服务(通常称为TCP卸载),但我们注意到一种趋势,即卸载功能正在向更高级别和更复杂的网络功能上移动,包括安全功能,例如Pensando。传统上,大多数高级网络功能运行在防火墙设备上或主服务器CPU上。这些方法要么不可扩展,要么不可避免地消耗服务器资源,如上述所提到的,并引入软件依赖。通过将更高级别的网络功能移至每个服务器中均有并与之扩展的设备(而不是单个设备),并且不会给服务器CPU带来负担(与软件相比),可以提出一个很好的论点。在这种架构中,服务器的操作系统使用卡的网络服务,而无需参与管理网络流量的技术细节,并且与环境中的每个节点一起扩展。网络服务的执行由设备完成,入口和出口由主机处理。

不好的方面

你的SmartNIC或DPU是真正的网络或存储引擎,还是仅仅是可编程的加速器

事实上,DPU主要采用可编程的加速器芯片,可用于将某些服务或功能从服务器CPU上卸载。这些服务或功能取决于蚀刻在芯片上的软件。对于存储服务,生态系统相当狭窄,今天DPU本身并没有提供太多本地功能。这意味着使用DPU时,你主要会从单独加速的功能中获益,但仍会遇到与超融合基础设施或软件定义存储相同的限制,因为提供完整企业级数据服务的存储软件仍然运行在服务器上。

让我们退后一步,真正深入探讨为什么这很重要。当你仅将一些数据服务从服务器CPU上卸载到DPU上时(即硬件特性,即卡提供了什么,服务器上的软件提供了什么),你考虑的设计原则与在服务器中运行所有企业数据服务的原则非常不同。后者可以确保不会消耗任何CPU、网络或内存资源,并且应用程序运行在服务器上时没有软件依赖性或冲突。正确处理这一点很重要,因为如果你不得不在服务器上运行完整的企业数据服务软件,你必须:

在每台服务器上添加(和维护)软件,并确保它能与实际购买服务器的应用程序配合良好。

购买更多的服务器和软件许可证来弥补内存和CPU的资源开销(例如,20%的资源开销需要购买25%更多的服务器和软件许可证)。

当我们着手构建我们的SPU时,我们回顾了其它类似产品,其中之一就是AWS Nitro。AWS Nitro本质上是一个卸载引擎,但它主要在主机上运行所有内容,然后在卡上加速。由于我们看到这仍然会给服务器带来负担,我们决定不再构建另一个可编程的存储卸载引擎,而只是一个存储引擎。真正的存储引擎不仅为DPU的使用者编程来实现一些存储服务的卸载,而且还在板上拥有所有企业数据服务,包括快照、复制、加密、压缩、去重、纠删码等。构建真正的企业软件堆栈需要丰富多样的功能。公司需要在软件中投入大量的工作来开发这些功能。同时,它还需要在卡上提供相当多的硬件资源来支持这些功能。但是,如果做得正确,它将运行得非常出色。

还有一个问题是持久性,当构建一个卸载引擎时,无论是用于网络还是存储,DPU在面对数据中心的电源故障等问题时不负责处理持久性。这意味着实现中最具挑战性的一些部分留给了软件(通常需要额外的专业硬件,例如主机上的写密集型驱动器)。我们的SPU的方法在透明处理持久性模型,提供所需的企业级稳健性。

糟糕的地方

Project Monterey、Pensando等都很棒,但没有人提到管理平面

如前所述,将卡放在服务器中有助于减少该服务器上的资源消耗,同时有助于扩展。现在,每台服务器都在规模化架构中贡献整体数据服务,而不是拥有少量的防火墙设备或存储阵列。但是,你不能忘记的是,你需要管理的设备数量大大增加,简单地说,如果没有针对所有这些设备的简单管理解决方案,完全将网络和企业数据服务运行在DPU上就毫无意义。

从这个角度来看,大多数DPU供应商只提供位于企业层的带外管理解决方案,这意味着你管理解决方案的能力仅限于该单个层面,无论它是机架范围还是数据中心范围。但是,如果你有数千台服务器呢?或者多个数据中心?或者遍布全球不同地点的数据中心?随着数据平面或DPU在数据中心的每台服务器上,管理变得更加复杂。但是,你应该能够期望在整个全球部署中实现云规模的管理,对吗?

客户唯一能够在本地数据平面或DPU上获得简单的云规模管理的方法是将控制平面放在云中。但是这很难做到。将控制平面放在云中需要一定程度的弹性,即使与云断开连接,你的DPU仍然可以处理故障并保持应用程序在线,需要一种新的安全级别,以防止入侵者篡改你的本地基础设施或数据。但同时也有很大的好处。将控制权移至云中,你可以运行一个企业范围的管理模型,而不是机架或数据中心机房范围的模型,后者是传统管理模型中常见的。

另一方面,我们的解决方案由云控制平面组成,提供了自动化的、基于API的云规模管理,客户可以用于管理并获取对整个企业IT基础设施的见解。这种灵活性对于希望部署DPU模型的企业至关重要。

最后的想法

最终,如果你是正在寻找基于服务器的解决方案的团队的一部分,我们建议选择一个将所有服务都放在卡上而不是耗尽服务器资源的解决方案,并且支持在云层进行真正规模的管理。我们的方案是以服务方式提供的服务器嵌入式基础设施软件,可以为任何应用程序(容器化、虚拟化或裸金属)在核心到边缘范围内提供类似公有云的优势。