SDN解决方案选择：OpenFlow、虚拟机和OpenStack
wuyongpeng 2015-04-28
【前言】
SDN是一个对现有网络考虑了兼容性的框架，博文博主认为，如果结合具体的业务需求，将OpenFlow的规则利用起来，必能给客户带来收益，给云计算、设备商和芯片商等企业带来发展的机会和激烈的竞争。同时鉴于OpenFlow的很多问题，作者认为其可能仅是一种过渡形态的昙花一现。以下为原文：
前面说了很多传统交换机的流程以及OpenFlow交换机的内容，并结合常用的网络功能对比了二者的差异。但是需要明白的是，OpenFlow交换机就是OpenFlow交换机，如果用OpenFlow交换机不是结合SDN的方式来使用，而是用其实现传统的基于MAC的二层转发或者基于IP的三层转发，那么就没有必要折腾了，何必哪?费力费钱还没有收益。尤其是运营商，对于OpenFlow的态度，尽管他们又各种各样的设备管理和维护问题，但是如同他们不自研网络设备，再加上钱多人懒，是不会对运营商网络做出什么SDN方面的改进的，除了某些项目名称。 OpenFlow交换机就是基于流标项的转发，可以结合SDN被用于结合业务的转发，无需考虑MAC学习，无需考虑是否有路由，而是用户或者管理员根据自己的需要来配置交换机。所以利用BMC或者MVL的传统商用交换芯片来做OpenFlow的开发，会导致表项容量小、OpenFlow标准支持不完全、对交换芯片其他处理流程组件浪费的现象。
OpenFlow
像卫峰书中讲的那样，SDN和OpenFlow关系，二者是不能划等号的。例如OpenStack中，如果Neutron下的plugin用Linux bridge，那么这个就不是SDN了吗?显然答案为仍然是SDN网络。SDN我理解的是一种思想，而不是一种方案或者功能。所以网络很多做法都是和 SDN有着扯不清的关系，但是这个绝非像某些大的互联网公司扯自己的产品硬跟SDN挂钩那样，因为他们的产品开发时研发和测试人员脑袋里连SDN的概念都没有听说过，现在国内互联网公司和很多的设备商都还只是停留在观望和接触的状态，并没有什么实质的SDN产品或者方案。并且SDN并不代表完全脱离硬件，有的云计算公司对于网络虚拟化中有一些硬件参与就不认可是SDN，难道说要全世界的人都用一台服务器，里面的每人用的虚拟机都用虚拟端口通信才算是真的 SDN吗?这个逻辑充满了荒谬。SDN只是一种思想，一种站在用户角度、站在管理员角度可以参与管理和控制网络底层转发决策需求的满足和实现。底层转发的实现是否是纯软件或者有多大程度的硬件参与并不重要。如果一个人坚持这么认为，我只能说这个人不懂SDN。而OpenFlow交换机提供的基于流标项的转发方式，正是SDN用硬件作为底层转发时所需要的，因此可以说OpenFlow交换机是SDN底层用硬件实现的一种方式，而虚拟网络里采用 OpenVswitch互通虚拟机则是用OpenFlow流表实现SDN思想的一种纯软件方案。
OpenFlow作为SDN底层实现的一个理想选择，在转发层面确实有很多优势，但是个人认为也有很多需要注意的点：
如前文所述，将控制平面和转发平面进行分离，减少了控制点，增加了控制平面的负担，需要比以往有更强的CPU计算能力的设备才能堪重负;
- SDN强调管理员在管理网络方面的能力，这些无疑对管理员的技能和对所管理的业务熟悉度有了更高一步的要求，这点与网络设备智能化、自动化、傻瓜化的发展思想多少是有点相悖的;
- OpenFlow的多表项为业务实现提供了灵活性，但是这无疑增加了设备的成本，并且为交换芯片驱动开发人员在软件中记录和维护配置表项、容错等研发工作提供相当大的复杂度;
- OpenFlow 在转发层面相比于传统方式有了很大提高，应该是先兼容以前所有的转发方式，但是现在的标准中，还有很多传统转发方式支持但是OpenFlow中不支持的，比如我要实现某个出端口中SIP=1.1.1.1的报文全丢弃，标准中暂时没有出现匹配出端口的的内容，希望OpenFlow标准尽快得到完善;
- 传统交换机中还有很多非产生直接转发意义或动作方面的功能，比如流控、队列调度、WRED等方面都要涉及交换芯片MMU，而这些OpenFlow是很难对各个厂家通过标准而统一的，所以OpenFlow标准化方面还有很多的工作要做;
虚拟机、iptables
为了提高物理服务器CPU的利用率，出现了使用虚拟机的概念，这样一台物理设备有多台虚拟机，分别“计算”处理不同的数据，如果物理服务器是多核的情况下，可以说是真正的并行计算不同的数据。当一台物理机内有很多虚拟机时，虚拟机的通信和隔离就有了需求，因为可能在一台物理机内的虚拟机承载着不同的业务，而承载相同业务的虚拟机分布在多台物理机上。打个比方，中国每个城市是一台物理机，每个城市里的企事业单位是不同虚拟机;同一台物理机的每个企事业单位之间是无法用自己的内网直接通信的，他们必须都将内网地址转化为外网地址才能在公网上交互数据;而每个企事业单位可能有很多分地，比如可能腾讯在北京有几个地方，而在广州、深圳和上海还有分地，所有腾讯的这些分地内网都是想通的，其他企事业单位在任何处的公司里都可以通过内网转换后利用外网访问腾讯提供在公网的服务，这个就是不同虚拟机之间的隔离和互通。如果阿里内网的一台设备，想SSH到腾讯的一台内网机器上，必须给腾讯的这台设备赋予一个公网的IP，且通常情况下，从阿里这台设备上发出的报文到达腾讯内网时，会通过一种功能将报文的目的IP从公网地址转成腾讯的内网IP地址，这种功能就是NAT。为了进制这种现象的发生，腾讯的内网可以通过iptables配置这台设备进制外网ssh连接。iptables是云计算中虚拟机常用的技术，NAT是 iptables的一个功能子集，就像对报文丢弃是OpenFlow规则中动作的一种一样。而云计算是把所有相关的管理节点和计算节点进行多虚一，看做是一个大的整体并进行统一的资源管理和调度;在所有的这些物理机上的虚拟机之间的通信和隔离，有很多种实现方案，但从技术方案上说基本都是二层vlan隔离或者对vlan数目要求过多时的vxlan方案及nvgre方案。拿OpenStack举例，Neutron下面的plugin仅官方支持的就有十来种之多，还有很多非官方维护的，OVS的一出现就受到关注有其道理;因为最初虚拟机之间的隔离是采用Linux bridge技术，非常的不灵活而且配置无法模板化，对于搭建复杂的虚拟网络是无法满足的;并且对于虚拟网络的调试、监控、故障定位都是非常不便的，而且搭建复杂拓扑的功能也很多无法满足;Openvswitch的出现解决了这些问题，并引入了QOS、镜像、CFM、netflow等功能，而且它还可以支持OpenFlow标准，最重要的是有一套用C语言的开源实现;导致其在网络虚拟化里得到了很大的重视。这部分内容在论文《Extending Networking into the Virtualization Layer》和《VirtualSwitching in an Era of Advanced Edges》有非常详细的介绍。
OpenStack
OpenStack现在是一个非常火的开源社区，官方有大量的资料和大牛贡献代码及文档。但是从国内的分享来看，大部分是基于如何搭建出某种简单的环境，尤其是网络这块如何搭建，以保证能建立虚拟机后在虚拟机内部可以正确的访问各种网络，但是从介绍来看绝大多数的分享者对OpenStack的底层技术并不了解，甚至出现了两台云主机在两个vlan就无法ping通的实验。因为网络虚拟化在OpenStack进行商业活动中提供服务的重要性，每年的OpenStack会议都有大量的会议在讨论网络相关的技术。而此时也是SDN体现价值的一个重要案例。OpenStack的缺点已经被各种吐槽，我个人认为OpenStack为了获取最广泛的支持，采取了吸纳百家的策略，就是现在项目众多，耦合性也越来越大;最麻烦的是，对于计算、网络和存储的虚拟化，它不是采用了一种经过考虑后慎重选择一种最有前途的然后进行专注和持续积累的方式，而是选择了每种技术都支持且经过抽象封装了一层中间层，这就导致的问题是OpenStack的专注无法集中，开发者的力量被分散，代码需要经过多次的封装，自然也就效率非常低下。商业版本除了修正其固有的BUG外，还必须解决上述问题。
VXLAN/NVGRE
