SDN三种模型解析

数十年前，计算机科学家兼网络作家Andrew S. Tanenbaum讽刺标准过多难以选择，当然现在也是如此，比如软件定义网络模型的数量也很多。但是在考虑部署软件定义网络（SDN）或者试点之前，首先需要选择要支持哪一种SDN模型。选择错误就会浪费时间和成本，甚至可能将基于SDN的产品置于不利之地。在这里云端卫士将会与大家探讨三种主要的SDN模型，阐述基本目标、机制以及每一种的缺陷。

SDN解析：网络虚拟化模型

市场上最简单的SDN模型就是网络虚拟化模型，因初创公司Nicira流行，该公司2012年被VMware收购。网络虚拟化的主要目标是消除LAN分区限制（这种限制存在于虚拟LAN（VLAN）标准中），通过在一些基于以太网的虚拟网络架构中实现多播解决可扩展性问题。

为了实现这一点，网络虚拟化平台增加了一些软件元素，通常而言是hypervisor，但是云构建软件（比如OpenStack）也要通过创建VLAN的接口被修改，这个VLAN建立在传统以太网顶部运行的隧道之上。网络设备和运营完全不受影响，理论上数以万计的虚拟网络可以通过这种形式创建。

网络虚拟化的最大好处就是支持多租户云，而且不需要改变网络自身。这种SDN模型在云网络机制中可以轻松映射流行的虚拟化接口，比如OpenStack的Quantum或者大多数支持网络分配的云DevOps工具。最终易于集成网络配置和云服务配置。

最大的劣势在于虚拟网络处于网络层之上，简单地表现为网络设备流量。这些设备无法优先考虑单独的虚拟网络或者报告他们的状态，除非进行深度包检测，来鉴定虚拟网络报头。由于作为云服务堆栈一部分的软件创建了虚拟网络，虚拟网络只能同虚拟机链接，而非用户和设备。

SDN解析：“渐进式”方法

第二种SDN模型可以称之为“渐进式”模型。这种模型的目标就是加强网络软件控制和运营，但是是在当前网络技术的边界之内。为了实现这一点，网络服务提供商可能需要对标，比如VXLAN、GRE、BGP和MPLS，并且用这些标准将网络分区，成为虚拟社群，并且管理流量和服务质量。提供商可能需要将自身的解决方案结合到一套管理接口中，这套接口可以为云环境所用，通过DevOps工具或者云虚拟接口。

实施了这种SDN模型的网络设备，完全集成网络运营、FCAPS管理和网络监控。常规流量工程原则适用，而且虚拟网络理论上可以从服务器扩展到用户，只要设备支持所选标准。

大多数SDN厂商目前实施了上面提到的所有网络标准，但是一些可能并不能在所有设备上可用。这也是这种渐进式模型缺陷中的第一点，因此提供商需要评估现有设备支持的标准。目前为止更大的问题是具体的厂商提供的渐进式SDN模型，可能并不能同其他厂商的设备完全交互。这种方法也可能需要在管理系统以及云虚拟网络或者DevOps接口之间进行特定集成，如果厂商不提供这些，运营商就会面临风险。

SDN解析：OpenFlow模型

最后这种SDN模型就是OpenFlow模型，也是和SDN属于最紧密相关的一个。OpenFlow取代了交换机或者路由器中传统的、基于发现的转发表创建，取而代之的是集中控制转发，也意味着一个集中控制器项目对应每一个设备的转发表。这样做为中央控制节点提供了完整的规则，如网络如何分段或者虚拟化，流量如何管理等。任何控制器和支持OpenFlow兼容版本的交换机的结合都可以用于这种SDN模型。

最后这种SDN模型最大的好处就是这种模型是基于SDN的概念来建立的。早起试用测试和部署认为OpenFlow能够改善网络有效性和可靠性，同时增加网络利用率，因此减少了基础架构成本和运营开支。如果OpenFlow交换机能逐渐普遍化，未来网络就可能通过开放硬件构建，成本极低。这种模式的缺陷就是目前缺少所有必备组件的功能细节。OpenFlow为大多数主流交换机和路由器所支持，但是不一定能够实现同传统协议一样的吞吐量。当然，支持OpenFlow的这种机制并不会显著降低交换机成本。

现在有开源和商用的OpenFlow控制器可用，但是能做的比发送命令到交换机创建路径、管理容量多不了多少。需要一套更高层级的管理应用。这些必须通过北向API连接到OpenFlow控制器，这些API并没有标准化。早期OpenFlow实现需要运营商集成多重组件来创造功能软件定义的网络，并没有完全的商业包可用。

三种模型哪种最佳？

云提供商纠结于VLAN的分段限制，或者面临着VLAN的多播问题，首先可能关注虚拟化网络的SDN模型。这种模型也能够覆盖渐进式SDN模型，尽管协调管理接口人存在很多问题。在数据中心网络设备中投资体量巨大的提供商可能更倾向于这种方式来避免冗余成本。未来的主流发展方向应该会倾向于OpenFlow，因此应该关注支持OpenFlow的服务和设备提供商，尤其是在部署新设备的时候。