这个关于SDN&NFV的博客已经写了有一年了，竟然一直在写SDN，从来没有写过NFV。今天终于打算开始写第一篇关于NFV的文章，主要是因为个人觉着NFV已经箭在弦上，离落地不远了。关于NFV的文章有很多，但国内外都是软文居多，看了也不知道在说什么，主要是因为实在没有什么干货可写，于是就只能堆砌概念了。
在笔者看来，让NFV落地的种种条件直到最近这半年才基本成熟。估计再过半年或者一年市场上就会出现比较靠谱的NFV解决方案，等明年这个时候可能就会有比较有说服力的案例出现了。
在这里我就不花笔墨科普NFV了，目前为止见到的最好的解释NFV以及NFV和SDN关系的文章是sigcomm 2014的OpenNF，特别是它的前两章，建议做SDN和NFV的兄弟们都读一下。这篇文章的结论之一是没有SDN，NFV是玩儿不转的。但这仅仅是故事的一部分，今天会把我眼中那些决定NFV落地的关键因素搭个框架出来，细节会在之后的文章陆续展开。
需求：
NFV (Network Function Virtualization，网络功能虚拟化)，如果非要用一句话解释就是：把在传统网络中只在专门硬件上跑着的功能放到虚拟机里跑，比较典型的例子是把防火墙跑在虚拟机上。这样做有很多好处：省钱；升级虚拟机比升级硬件方便；根据业务需求弹性部署；易于管理等等。总之那些主机虚拟化的好处对于NFV同样适用。对NFV最大的需求来自两类大金主：运营商和云。
运营商会在网络中部署各种各样的middlebox (Network Function的又一种说法，真不明白人们为什么花精力编造不同的名词来描述同一个东西...)，middlebox种类之繁杂让人一度目瞪口呆，sigcomm 2012的APLOMB说运营商管理的middlebox的数量比他们管理的路由器加交换机的总和还多。面对如此庞杂的middlebox，运营商对于NFV的需求也最为旺盛。
对于NFV的另外一个需求大户是云，特别是在多租户大行其道的今天。每一个租户都要在自己的网络入口部署防火墙和负载均衡。云服务提供商不可能为每一个租户购买专门的硬件设备来完成这些功能。把这些功能跑在虚拟机里几乎是唯一的选择。
对NFV的需求如此强烈，为什么迟迟没有落地呢？因为一些关键的技术问题直到最近才有比较靠谱的解决方案。
技术：
NFV最大的技术难题是性能。还是拿防火墙来举例：防火墙是有状态的，它要追踪每一个TCP链接并且根据规则做出判断。人们为防火墙设计专门的芯片就是为了能够线速处理网络流量。于是从2000左右开始，硬件防火墙就一直统治着市场。如果把所有这些功能都放到虚拟机，放到软件上来做，就意味着中断，数据拷贝，要达到线速非常困难。伴随着基于DPDK，SR-IOV的一系列方案的不断完善，这个问题得到了比较好的解决。解决思路就是用最少的中断，寻址和数据拷贝将数据包搬运于网卡和防火墙虚拟机之间。我会写专门的文章比较这两个技术流派，目前更倾向于认为DPDK会得到更广泛的应用(事实上在大型互联网企业里，基于的DPDK的应用已经走得很远了)。
以SR-IOV为代表的网卡技术有两个硬伤我还没想清楚怎么破：
1) 没有HA，一个网卡挂了，它所有的virtual function全挂。SR-IOV没有bond的概念。
2) 产品升级困难，唯一的方法就是换网卡，重新部署，重新配置。
NFV面临的第二个难题是根据middlebox的功能和在网络中的位置，高度动态的计算路径，将流量正确的转发入/出middlebox。这个问题伴随着SDN的落地开花，不少SDN厂家都有了比较靠谱的解决方案。
部署：
直到上面的两个技术问题得到解决，谈NFV的部署才有意义。NFV的部署其实和虚拟机的编排没有太本质的区别。最大的不同是需要为middlebox分配专属的硬件资源，比如一个防火墙的CPU都应该处于一个NUMA上。这些接口在过去半年里也终于被openstack支持了。
讲到这里，大家也就明白为什么笔者会认为NFV离落地不远了：需求旺盛，技术难题已经得到了比较好的解决，部署方式和现有的编排系统高度相似。NFV真的要来了。
本文转自d1net（转载）