Nicira为什么放弃了OpenFlow硬件交换机

42 阅读 0 评论 28 点赞

我是靠谱客的博主可爱未来，最近开发中收集的这篇文章主要介绍Nicira为什么放弃了OpenFlow硬件交换机，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

5年前，当Nicira创始人Martin Casado在斯坦福攻读计算机科学博士学位的时候，就开始着手于转换网络的操作模式，以适应服务器虚拟化给数据中心带来的自动化问题。

Casado以为他的发明（Open Flow）本身应该可以解决这个问题，但是现在，他说他做错了。OpenFlow硬件控制（如今在业界掀起了巨大的波澜）并不是问题的答案。尽管Vmware高度评价花费了12亿美金购买Nicira的战略，他依然决定在网络虚拟化的Overlay软件上采取不同的方式。

"问题是我们做错了，而且我想业界还没有真正认识到错的有多厉害。"本周他在Vmware剑桥Mass办公室里举办的一次跟几位记者的白板会谈上谈到。

控制平面与转发平面分离，把控制功能集中到一个中央大脑（OpenFlow控制器），Casado以这样的方式创造了OpenFlow。这个创新使得网络可编程并完全改变了网络的运行操作。"这本来是我在斯坦福的论文，可以用这种方式来使得网络自动化"他说，"因此，Nicira的最早三位工程师编写了协议……在理解SDN（软件定义网络）的局限性方面，我们做了很多早期工作。"

他说，在许多用户案例中，特别在流量工程方面，OpenFlow依然有效。Google实施的数据中心互联就是一个极佳的案例。但对于数据中心的网络虚拟化，OpenFlow用来控制硬件转发是一个错误的方向。

虚拟交换机而不是OpenFlow硬件交换机

"在头一年里，我们认识到有很重要的事情发生，" Casado说。服务器虚拟化改变了数据中心的访问层。内嵌在hypervisor的虚拟交换机尤其是Vmware的vSwitch，成为了新的网络边缘。如果新的边缘是服务器里的软件的话，那为什么我们还要费心费力地用OpenFlow来控制实际的交换机呢？一个虚拟的交换机对于数据中心来说是绝对完美的，这里有两个原因。"首先，它运行在x86上，而x86是超级弹性化的。我们懂得如何给它编程。它不需要你在某些私有的ASIC上苦心研究算法。如果我需要在转发上做更改，我直接写段程序就是了。"

"第二，它更靠近边缘。在试图猜测机器里正在发生什么上，网络有着冗长悲催的历史。不过，如果你就在那儿（服务器里）的话，你可以前所未有、事无巨细地了解边缘。什么地址正在被监听？哪个用户连接到了这台机器？这种程度的可视性绝对是网络专家们梦寐以求的。"

这些现实使得Casado和他的小组重新审视并开始采用另外的方式。"那一瞬间，俺们大彻大悟。"他说。

Nicira可能还会采用OpenFlow来做网络虚拟化，但重心将会从硬件转移到软件控制。可能会控制虚拟交换机。对于Casado来说，这样其实不错。毕竟在今天的网络里，数据转发不是什么问题。在如何把数据包运送到正确目的上，已有网络其实已经做的超酷。完全是传统网络顶端的策略和操作层导致问题发生并降低了运行效率。具体而言，以往在静态的环境里，对于访问控制列表（ACL）、VLAN、网络隔离、计费和统计等功能的实施，网络专家们完全可以设置之后就束之高阁不予理睬。而当服务器虚拟化加速了新计算负载业务开通并带来了虚拟机器移动性的时候，手动的处理方式一夜之间就变得笨拙不堪。

Casado认为这些操作难题不一定会发生在实际的交换机上，但是很有可能转移到那些易于由软件控制的虚拟交换机上。这就是Nicira的"网络虚拟平台"的由来，也是为什么"虚拟网络覆盖"会成为随同着SDN的另一个炙手可热的话题。

直接控制OpenFlow硬件交换机的问题

仍然有很多厂商和网络从业者醉心于OpenFlow硬件的实施，以便于在数据中心实现网络虚拟化。但有几点原因说明这样的做法并不可行，Casado说。第一个障碍就是网络厂商的生态系统。"你在要求交换机厂商们把OpenFlow放到他们的交换机里去，而根本没什么利益驱动他们这么做，因为从某些方面上来说，你实际上是在贬低他们的价值。"他说，"2007年我写了第一个OpenFlow协议，从那以后人们发布了很多东东，但是你只见到了一两台能用的OpenFlow交换机。不管谁有了一台能用的OpenFlow交换机，他肯定还有一台控制器。我可以很负责地跟你说，他们用某种绑定的方式把他们的控制器和交换机放在一起，以便维护自己在客户那里的控制地位。因为商业关系，建立一个活跃社区实在是太难了。"

许多网络厂商都在他们的交换机上支持了OpenFlow，那么Casado所指的"能用的OpenFlow交换机"到底是什么呢？他解释说，大多数厂商都不生产那种带有足够容量的通用转发表，真正能在数据中心里使用的交换机。在一个典型的交换机ASIC（专用集成电路）里，有ACL表、2层表和3层表，"这些都是专用的表"他说。所有这些表都不能处理数据中心类型的OpenFlow。

"从OpenFlow的角度来说，世界应该是这样的：你有一种能进行11位元查找的超级通用表，越多越好，" Casado说。"为了符合OpenFlow的标准，许多厂商不过是超量使用了那几种只有5000个条目的表，他们试图把OpenFlow硬塞进去，那些芯片并不是设计用来做这个的。OpenFlow试图在这些方面进行一些调整，但这将会是件很困难的事。"

今天在大多数OpenFlow交换机上可用的流转发表对于研究和试验来说是不错的，做做流量工程也能行，Casado说。"但是数据中心的流和流量的规模意味着你必须得做点类似3层的事，"他说，"至于建造数据中心交换机转发矩阵，OpenFlow就不行了。"

Nicira-Vmware解决方案里还有OpenFlow硬件交换机吗？

这是否意味着Nicira和它的母公司Vmware仅仅满足于把重心放在软件上？Casado说他的技术将在3个领域里跟硬件发生接触，而且这需要一些非OpenFlow标准的东西。"第一个是QoS（服务质量），"他说。"队列多了才好，在硬件里你拥有的越多，你就有越多的QoS层次可以提供给客户。如果我有8条队列，我只能提供8个等级的SLA（服务等级协议）。但如果我有上百万个队列，我就能给每个租户都提供一个SLA。"

对于以太网的Operations， Administration和 Management，或者说OAM，QoS和类似的基于硬件的特性将需要一个更简单的模式。这样Nicira和其他科技公司可以在物理和虚拟的工作负载上进行能力的故障排除和调试。

网络虚拟化技术也需要跟机柜顶端的交换机进行交互，以解决那些没有被虚拟化的传统工作载荷。"为了让那些物理载荷能够融入虚拟网络，你必须得控制那些机柜顶端交换机，这需要类似OpenFlow那样的接口。"

最后，网络虚拟化控制器需要跟其他网路设备（防火墙和应用交付控制器等等）交流通信，这也同样需要类似OpenFlow那样的接口。
"我认为OpenFlow对于这个来说太低级了，" Casado说，"所以，我们提出了一个新东西：OVSdb-config。我们用它来管理Open vSwitch和OpenFlow，它能够让我们管理高等级的状态，这就是我们希望大家用来干活的，不过不是那么重要。"

为什么不重要？任何只要是开放的，鼓励创新而且能解决问题的协议都行。Casado说。

转载自：https://johnyork945.wordpress.com/2013/08/01/nicira%E4%B8%BA%E4%BB%80%E4%B9%88%E6%94%BE%E5%BC%83%E4%BA%86openflow%E7%A1%AC%E4%BB%B6%E6%8E%A7%E5%88%B6%EF%BC%88%E8%AF%91%E6%96%87%EF%BC%89/

附英文原文：

http://searchnetworking.techtarget.com/news/2240174517/Why-Nicira-abandoned-OpenFlow-hardware-control，作者Shamus McGillicuddy