《深入理解OpenStack Neutron》—1.2.2　基于SDN的应用

1.2.2　基于SDN的应用

一千个人的心中，就有一千个SDN。本文所说的SDN，指的是传统老牌设备厂商推出的SDN方案，

如图1-7所示：

图1-7所描述的应用场景，可以说是SDN浪潮大背景下的运营商与传统老牌设备商心照不宣各取所需的“创新”方案。运营商一直以来都被各个设备厂商提供的形态各异、纷繁复杂的管理接口所深深“伤害”，一直期望能有一个统一的接口。随着OpenStack的发展，Neutron接口成为不少运营商的一个选择。当然，在SDN浪潮之下，仅仅选择Neutron接口是不够的，必须得沾上SDN的仙气。于是图1-7中的SDN控制器的存在就成为一种必然。这正好也中了设备商的下怀。1.2.1节提到，基于OpenStack

的Neutron应用，其选择的基本是Host内的虚拟交换机、路由器，这是传统老牌设备商所不能接受的——如果都选择了虚拟设备，那自家生产的交换机、路由器卖给谁去？于是设备商就与运营商一拍即合，推出了自家的“SDN控制器+硬件设备（交换机、路由器）”综合解决方案，并将SDN控制器挂接在Neutron的下面，对外以Neutron的统一接口和SDN的面貌出现，其实醉翁之意不在酒，在乎销售自己的硬件设备也。

客观地说，设备商以这样的方案推销自己的硬件设备，除了在商言商无可指责以外，从技术角度而言，其实也是一个比较正确的选择，毕竟当前的虚拟交换机、路由器，其性能还是不能跟硬件设备相比，在很多场景下还是有点力不从心。

下面我们就以开源组织OPEN-O的一个用例为例来直观感受一下，如图1-8所示。

图1-8　OPEN-O Enterprise 2 DC场景解决方案

图1-8描述的是一个Enterprise 2 DC的场景，图左边的组网及“其他SDN控制器”与本文主题无关，我们先忽略。图右边是一个DC（数据中心），OPEN-O向下看到的是Neutron

接口，而DC SDN控制器挂接在Neutron之下，对DC中的硬件设备（GW、TOR）进行配置管理。

OPEN-O已经与AT&T的openECOMP合并为一个新的开源组织ONAP。

业界基于SDN的Neutron的应用案例还有很多，限于篇幅原因，这里就不一一列举。不过所有的案例、所有的解决方案，它们都有一个共同的特点：所有的SDN控制器都是挂接在Neutron之下的。这不仅因为业界期望Neutron能够成为统一的北向接口，也是源于Neutron的可扩展能力。