之前在科院的时候做了很久的NFV。现在回过头来看,其实根本没懂啥是NFV,或者当时的思考过于局限了。所里做的,其实更多的是一种软件开发,和所谓的“网工”差别很大。这里说下对这玩意的一个阶段性思考。

首先顾名思义,网络功能虚拟化,网络功能其实好理解,无非是网元设备(nat/fw/lb/rate limiter/epc/…),当然往大的方向思考,提供connectivity的都叫网络功能,但是那已经是网络虚拟化的概念了,NFV基本还是围绕middlebox的一系列技术。难点在于虚拟化。按照以前的说法,所谓虚拟化就是把网络功能往虚拟机里实现,于是我们就虚拟化了。哇,真的是easy,但是虚拟机转发性能不行啊,一堆人开始吭哧吭哧的优化转发性能,改qemu/kvm,搞vhost-user,SR-IOV,最后发现都不行,那咋办?只能上智能网卡了,搞了一对牛逼哄哄的技术,成功的提高了这个行业的门槛,造就一堆NFV工程师。

但是回过头来想想,NFV不是倡导使用高性能标准化(commodity)的server来实现网元功能嘛,咋到最后你还得用智能网卡这种specific的硬件来解决吞吐问题了呢?那不是有点本末倒置。如果我用DPDK+通用网卡能够大幅提升网络处理的性能,咋上了你的NFV之后,网络性能反而下降了呢?那我还干NFV干嘛,就是为了虚拟化而虚拟化?

NF跑虚拟机的好处是什么?反正我一直没太想明白。Nicira的人在一篇NSDI中讲过一个观点:某些大型企业,其内部的IT系统就是围绕着一些专用的网元设备构建的,迁移到云上去之后,他的系统还得为云的API重新打造,费时费力,如果这个时候能够直接把某些虚拟机变成专用的网元设备,就能安心迁移,省心上云。于是Cisco出了ASR1k的VM Image,JUNIPER/HW/H3C也紧随其后。这个观点,我理解。但我觉得,这个不能作为把网络处理软件放在虚拟机的主要理由,因为显然这是一个过渡性技术,只不过方便客户上云而存在。而且设备厂商出这些Image并不仅仅只是为了这个而已。

如果说虚拟化能够让网络设备被Cloud系统得到管理,也被作为一种资源进行调用。那把NF放在虚拟机里面,显然是一种偷懒的做法。因为资源这种东西,不同的业务,有很多不一样的地方。表面上NF处理也是靠CPU,但是你能把这玩意等同于web处理吗?也许未来可以,但现在,我觉得不行。但是有一点,好像说清楚了,虚拟化,是为了更好的管理和调度。

说到这个,就不得不说服务链。其实这玩意根本不新鲜,只是以前没人叫服务链而已。我就问,难道以前的互联网公司没有服务链吗?通过控制路由,让流量依次经过lb/NAT/rate limiter,不叫服务链吗?企业里面的上网行为管理+FW+IDS,不叫服务链吗?那今天又提服务链是新瓶装旧酒吗?

我个人觉得,NFV的真正价值,在于把以前大家都觉得ok的事情拿出来批斗了一番:自动化标准化

啥是自动化?以前我们也有服务链,但是那个服务链是网工设计、运维手动搭建的,是一根根网线,一条条命令敲出来的。每次上下线网元设备,升级,流量导入导出,全部手动操作,网络设备直接command line,哇,真的是硬核摇滚式的网工时代。很多人说服务链的编排,服务链怎么编?我们首先得有个"博古通今"的控制器(controller),上能用存在了20年的netconf跟网络设备扯淡,下能用最新最酷的restful(其实对web来说也不酷了)跟管理端调情,中间什么ospf,bgp,ovsdb,了如指掌,跟谁都能谈笑风生。

把这些打通了,还仅仅是“术”,道是什么?是统一的模型,我现在想把A和B连起来,A是物理网关,B是一台虚拟机,我点两下鼠标就把这活给做了,中间跑了什么bgp协议,什么openflow,我不care。我现在想把两个service node下线了,也是鼠标点下就搞定了。所以说,得有个模型,没有模型,肯定搞不出来。

有了自动化的编排技术,我想把流量怎么引就怎么引,想让谁上线就让谁上线,然后就开始路由进行验证,检查服务链的流表规则会不会把那些不该丢的包给丢了,然后开始玩流的调度,保护客户体验,玩些细活。这是NFV的一种价值。

另一个点,我觉得很遥远,那就是标准化。什么是标准化,其实,把网元放虚拟机只是偷懒,是所谓IaaS的NFV,PaaS的NFV应该是把所有模块都标准化了,搭积木的干NF。这不是什么新鲜观点了,Click多少年前就号称是模块化的Router了,今天NFV的新意在哪?是假设网络中所有的硬件设备已经全部跑Click了。

想象一下,如果所有的设备都是一个相同的框架,会有那些有意思的事情发生?首先,迁移标准化了。网元设备的迁移是一个插件的拷贝,之前这有一台NAT设备,现在我把nat.so拷贝到另一台设备上,于是nat集群扩容了。第二,session同步标准化了,所有的集群设备自动化进行session同步,互为主备,自带多活,只要在写代码的时候写好流的状态信息,跑到时候自动互相备份流状态,哪一台crash了,都不会有啥问题。第三,调度细腻化了,我要下线某个NF,我只用下线某个模块,下线某个so,下线之后,设备上还有流量,只是流量会过别的so不会过这个NF。升级方便了,控制简单了。

觉得是胡说八道?其实很多老外lab已经做了,什么流迁移(flow migration),什么用编译器实现自动流状态管理(NSDI,paving the way to NFV),还有如何更好的code reuse,网络处理更高级的抽象,(NSDI, mOS,OSDI,netbricks,softNIC/Bess),也就是这几年冒出来的文章,这些都是NFV研究的一部分,也是NFV走向落地的一个信号。

所以说,NFV的价值在于,自动化的编排+标准化的代码。前者我认为已经在路上了,有了SDN的一些积累,编排是可能的,标准化应该也要开始了。只是这次标准化,应该是软件产品先行的,这次可能没有spec给厂商了,因为谁也不知道这个软件怎么写。这次,应该是先写一个框架,然后实现可迁移、模块可以随意调度,等到确实稳定可靠了,最后形成spec。

等到这一天,NFV就真的实现了。