NFV规模部署不可忽略三大要素

燚先生

在电信基础设施项目（TIP）成立后，今年的OCP峰会有很多电信运营商参加：AT&T、德国电信和SK电信等通信服务供应商（CSP）都希翼吸引更多设备供应商为其下一代网络构建设备。

当大家谈到电信技术，大家必然要谈到NFV。NFV是CSP社区的重要举措，它旨在带来更灵活和高效的基础设施，降低成本、提高效率以及加快服务创新。CSP希翼基础设施可提供快速的服务，就像OTT网络服务和云服务提供商那样快。

但在NFV出现三年半后，大家还没有看到其被广泛部署。NFV可从OCP（开放计算项目）以及超大规模供应商中学习一些经验，因为他们已经将OCP解决方案组件投入到大规模部署中。

鼓励硬件不断创新

超大规模网络和云服务巨头创建了OCP，他们也在努力推动OCP向前发展。2011年Marc Andreessen宣称App正在吃掉这个世界，现在每个企业都是App企业，每个企业都有以网络为中心的业务。

快进到2015年，这个趋势进一步发展成：如果说App正在吃掉这个世界，那么开源将会吞掉这个世界。App驱动企业正越来越多地使用开源模块作为组件化功能，在更短的时间内将服务推向市场。在OCP峰会上，MicroSoft宣布将开源化其Azure Cloud交换机App，并将其称为SONiC。其结果是，专有交换机系统供应商Arista的股票下跌。

这些Web服务App巨头的做法并不是巧合。OCP的使命是关于重新构建硬件，让其更有效、更灵活以及具备可扩展性，以带来更多选择、自定义和节约成本。对于超大规模供应商而言，白盒的概念并不只是带来便宜的硬件，而且它可灵活地分解和重新组装，为Web服务行业带来优化的硬件。电信行业也开始行动，在世界移动大会上宣布成立的OCP电信基础设施项目的目的就是为设计和构建电信网络基础设施带来新的方法。

NFV社区已经明确选择了App的路线，并拥抱了开源和其他开源举措。下一步是什么？肯定是对硬件的重新关注。适用于Web服务的不一定适用于网络服务，它们有对数据包性能（特别是小数据包性能）、延迟性和数据包分类、排列及加密/解密等功能的独特要求。NFV必须想办法鼓励硬件创新。

API极其重要

非常明确的一点是，App开发人员不想写针对硬件的代码，在现实中，他们应该不需要这样做。在理想世界中，最有效的解决方案是App独立于硬件，硬件为即插即用。

在NFV中，大家经常听到的是，由于虚拟网络功能（VNF）想要独立于硬件，它们通常会在App中完成一切工作，包括常规数据包转发。实际上，App一直在定义数据包如何转发，但App并不能实际移动数据包。

在App中转发数据包意味着在x86硬件中进行数据包转发，尽管x86硬件性能增强且有所优化，但对于数据转发和处理，仍然无法与网络处理器或多核ARM处理器相媲美。那么，CSP如何使用不同的硬件来构建用于通信应用的基础设施，同时避免管理多种类型硬件的麻烦？

这里的关键是API，在OCP网络社区，这个问题通过交换机抽象接口（SAI）完美解决，这个标准C语言API可编程各种类型的交换机ASIC。

存储不可忽视

如果没有快速I/O访问你的存储介质，超快存储将没有任何意义。快速存储需要快速的网络，对于通信行业最热门的技术趋势尤其如此：移动边缘计算（MEC）和云本地NFV。

MEC让移动运营商感到兴奋，因为它可为他们提供显著的差异化，与现有云服务提供商（例如AMAZON云计算服务和MicroSoftAzure）相竞争，后者构建了大规模区域数据中心来支撑其运营以及差异化云产品。展望未来，新一代应用（物联网、自动驾驶汽车、虚拟现实等）通常需要访问本地内容以及有关本地接入网络情况的实时信息。这为移动运营商提供了很好的机会来利用他们已有的分布式基础设施，包括基站。通过这种已经部署到位的基础设施，移动运营商可在移动网络边缘实现低延迟性和实时处理，而不需要触动主干网络——这会增加不必要的延迟性。

另一个热门话题是云计算本地NFV。实现NFV云本地的关键步骤包括：将单片VNF分成微服务，并从交易处理解耦状态（即无状态应用）。无状态意味着你需要在持久存储中存储状态，并能够获取状态，即使你的虚拟机或容器实例不在运行。这是云本地应用的关键属性之一，当工作负载增加以及扩展时，你可以启动尽可能多的VM或容器实例，并可始终确保可靠性，当一个或多个虚拟机或容器实例终止，其他实例可从持久存储获取状态，并继续运作。

为了实现MEC和云本地NFV的低延迟性目标，重要的是研究整体基础设施设计以尽量减小访问数据和实行数据分析的延迟性。当大家从传统硬盘驱动器（HDD）转移到固态硬盘（SSD）以及现在的固定存储器，存储介质访问带来的延迟性已经显著缩短。