你的SDN只是一场学术笑话？

最近觉得被SDN这个词搞得很烦，因为我心中想的目标跟大家在谈的�热菀丫�开始背道而驰了。我终于可以理解Martin过去跟我说过的：“Iknow nothing about SDN”。当时我只能用惊讶去看待这个Openflow协议主要发起人之一对SDN的回应。

过去我尝试去跟我所在区域市场的朋友理清可用于生产的SDN的方向时,发现多数朋友已经进入宗教式狂热并超越我的理解范围，这种感觉就像是多年以来关于“云计算”的探讨。就算到今天为止，我相信大多数人依然无法解释什么是“云”。再过多年后，大家可能依然无法解释他们所谈的SDN到底是什么，能真正在生产环境中做些什么？

如果你要用Openflow来解释SDN，那Openflow的最早发起团队已经告诉你那是死路一条，他们只是在学术上提供一个新的控制协议，但他们并没有提供你一个网络操作系统。如果你看过我之前所写文章，我希望此时你能全部丢弃，因为在这篇文章的这一秒开始，我想完全用一个技术人员的思考模式来解释这个主题，而不是作为一个厂商代表。

关于软件定义网络这个议题，我想用一个计算机的架构来解释这部分。基本上，计算机上有几个重要的组件，如：中央处理器（CPU)、内存(DRAM)、总线(Bus) 和 I/O模块。如果把这些组件套入到SDN的范围之�染褪牵褐醒氪�理器就是Openflow控制器，I/O模块就是如日常使用的输入/输出模块，Openflow协议就如同I/O行为一样，在北向进行指令下达或是收集更新信息。以上我称之为母体，没有母体进行运算，根本不可能产生结果。但是母体产生的结果，也还是需要有组件来执行才行。内存也就是存储运算结果的地方，也就相当于网络设备的FIB(forwarding information database)，网络设备必须要有这个信息才能执行需要的工作。总线也就是元件之间通信的通道，这在网络的世界里就是线缆。

所以我们拼接一下以上的组件：

CPU <--- I/O指令---> 网络设备1 (<-内存示意)----|
                  |----------> 网络设备2------------------------|----|  网络连线
                  |----------> 网络设备3-------------------------|----|
                  |----------> 网络设备n-------------------------|----|

你可以发现：所有运算的压力全部落在CPU组件上，但是回到Openflow最初的理念，正是要优化网络设备的转发能力，才把运算单元全部放到北向去吗？就这个点来说没有错。但是就一个面来说，这个点并没有考虑运算压力的问题。不是把转发表算一算丢给设备就算了，后面还有大量的状态需要被保持或是更新或是继续演算，如果运算单元不知道这个状态，那一堆网络标准协议上的工作机制不就作废了? 我们当然希望大型网络的运作如此易于简化，不过你以为道士拿个铃铛甩一甩，行尸就会乖乖的一直跳吗？他要是没有持续维持其中的状态的话，行尸很快就变成僵尸把你吃掉。

到此为止，如果你看懂我想表达的意思，你大概可以理解现在市场上谈的SDN多半都是道行不深的神棍在招揽生意。其实回头再看这件事，这应该不是一门所谓网络技术的学问，而是一门分布式计算的科学。当你把运算单元集中化之后，如何重新分散运算单元的演算，就像我给你一颗超级CPU，可能有一百个�群耍�对你来说跟一般CPU没有两样，因为操作系统根本不支持。所以当我们再看SDN议题的时候，其实看端出来的菜，就可以判断这是道士还是神棍所为；讲的是一个不能落地的框架，还是一个有目标的场景；用的是一个符合运算科学的逻辑架构，还是一个胡说八道的市场信息，我想看官们自己需要多琢磨一下。

对不起，我有些激动了~ 因为飞机延误了，肚子咕咕叫，所以脾气不好，见谅～

作者：�建民，曾任Nicira��太�^技�g���，2012年VMware收�Nicira之後，�F任VMware  �W路��M化平台工程��，�＞�於�Y�中心基�A建�O���及�热��用安全。扫描下面的二维码订阅“中国云梦”微信公众号后，回复“10033”阅读该文。