Neutron结合SDN的架构分析

编者按：Neutron 是 OpenStack 核心项目之一，提供云计算环境下的虚拟网络功能，本文将SDN与Neutron结合起来进行架构分析，比较有借鉴意义。

 

    OpenStack开源社区为云计算提供了最大平台，有多个组件分别实现计算（Nova）、存储（Cinder/Swift）、监控（Ceilometer）和网络（Neutron）等服务。随着Neutron逐渐成熟，越来越多的云计算厂家开始选用Neutron组件，并且有大量网络设备商和云计算方案厂商为Neutron提供硬件设备和网络方案，使得Neutron的发展倍受关注。

Neutron的华丽

    云计算改变了用户的业务部署方式，从而帮助用户节省设备和运营成本。例如，类似12306的火车票业务，它具有非常明显的时节性，平常的业务流量并不是特别大，但到了节假日业务量会猛增。如果采用传统的方式部署硬件设备，势必会在业务流量少时造成硬件设备资源的浪费，而在业务流量猛增时又不能及时扩展硬件资源。但如果在云上运营，则可以在业务流量少时减少云主机和网络带宽等资源，在业务流量猛增时快速部署大量虚拟机，为新业务量提供服务。理想的方式是通过SDS（Software Defined Storatge）和SDN（Software Defined Network）等方式，让业务（相当于SDN中的App，即Software）在激增时，自动调用相关接口，申请并使用满足其需求的计算资源、存储资源和网络资源。其中SDN是目前网络和云计算领域中非常火热的网络架构，它结合NFV（Network Function Virtualization）等相关技术，掀起了一场颠覆传统网络的革命。图1是Neutron的拓扑示意图。

Neutron自身无法克服的难题

    Neutron中提供了使用虚拟路由器实现租户网络的互通和隔离、安全组（Security Group）、防火墙（FWaas）、负载均衡（LBaas）和虚拟专用网（VPNaas）等服务。在Neutron网络中还可以采用VMaas（VM as a Service）的方式提供一些极易创新的网络服务，包括Neutron中不支持的接入VPN等功能。虽然Neutron的功能已经相对比较完备，但还存在一些不足之处，这也是为何Neutron需要SDN架构的部分原因。

 

    有很多的网络功能无法满足部署需求，例如基于VM网卡或IP的限速、基于路由的限速以及基于租户的限速等网络需求，至今仍没有完善的解决方案，而这些在实际物理网络中部署都是极其常见的功能。曾经有人提出用Libvirt对虚拟机网卡的inbound average和outbound average做出入方向的限速，但我认为这个方案非常不妥。部署该方案时是通过设置flavor的quota:vif_inbound_average和quota:vif_outbound_average来实现的，会导致对VM的所有网卡都做限制。而且该方案不仅限制了南北流量，还限制了东西流量，是不可用的方案。Qos功能不只是限速，还有很多诸如队列调度、流控等方面的Qos需求，当有业务需要时，Neutron却无从提供满足需求的支持。

 

    网络节点存在的单点故障问题至今依然没有完善的解决方案，DVR（Distributed Virtual Routing，分布式路由）对虚拟路由器的HA方案也存在很大的缺陷。而与传统交换机（甚至与路由器）相比，网络节点的带宽能力还存在一定差距，尤其是对单路由带宽没有分流方案，一旦带宽超过虚拟路由器的带宽能力则无能为力。

 

    对Neutron网络的监控，虽然可以通过Ceilometer组件使用Neutron的neutron-meter-agent进行采集，但除了Ceilometer组件存储采集数据持久化性能方面的问题，还存在很多监控项无法采集到的问题。

 

    在Neutron中经常使用Open vSwitch虚拟交换机，而其在计算节点和网络节点的虚拟交换机都有稳定性和性能方面的限制，尤其是使用VXLAN等隔离方式时，报文的封装和解封装很可能成为网络瓶颈。

SDN让Neutron更强大

    除了上述问题，Neutron还有很多实际部署难题需要处理。而如果采用SDN架构的话，这些问题将会有相当一部分得到解决。假设SDN控制器南向采用了OpenFlow协议，那么就能很容易控制流量转发以实现不同虚拟路由器的流量分担，通过goto tables（或者“goto entry”）来实现数据流按照OpenFlow规则进行的基于IP、虚拟路由器甚至租户的限速功能。那么Neutron在SDN架构中是如何部署的呢？大概有三种方式部署（这里说的Neutron多指neutron-server）。 

 

    Neutron as App：将Neutron作为SDN中申请网络资源的App，与使用网络资源的VM上部署的用户业务联动，实现对网络资源的控制。这种方式需要替换Neutron的底层网络架构，继而Neutron通过SDN控制器控制网络资源。如果该方案只用Neutron的API，那么Neutron之外的功能还是无法使用，只能再额外调用SDN控制器的API，这样就需要维护两套API在兼容条件下配合使用。这样，让网络资源的申请者neutron-server与网络资源的使用者VM里的App进行联动。 

 

    Neutron as Controller：将Neutron作为SDN控制器的一部分，VM上部署的用户业务直接或间接调用Neutron的接口，来申请和使用底层网络资源。这种方案里用户的业务只需要调用SDN控制器的API，没有API兼容性问题，底层网络可以替换也可以不替换，但部署时需要考虑Neutron和SDN控制器的对等关系。 

 

    Neutron as Underlay：将Neutron作为底层承载网络，为SDN控制器提供南向接口，VM上部署的用户业务直接或间接使用SDN控制器来申请和使用网络资源，然后SDN控制器再调用Neutron接口来做底层网络资源的调度与分配。这种方案部署容易，但仅用Neutron原来的底层网络结构和API，需要对Neutron做开发才能提供所需求的新功能。

 

    三种方式各有优缺点，需要结合自身的业务和厂家自身的技术积累进行选择，因为SDN本身是一种新型的网络架构，如果结合NFV的理念，使用白牌交换机等方式，那么就更能解除对设备商家的绑定。

 

结束语

    云计算是将来数据中心提供服务的新模式，也是IT技术变革的趋势之一。据估计网络研发的工作量会占有云计算研发工作量的一半以上，这也是云计算技术难点的突破之处。目前比较有名的SDN控制器OpenDaylight（图2）、OpenContrail和Ryu等，都支持Neutron与SDN架构结合。希望SDN技术能让云计算的网络技术更优雅地提供难题的解决方案，在将来的云计算网络之路上，大放光彩。 

 

作者：。从事于云计算网络的研发和架构设计工作，混迹于SDN和Openstack的网络两个圈子。 新浪微博：

  

 转载自：CSDN网站

 

      本文来源于，可点击此。如果您对本文感兴趣，可参与以下互动方式与作者近距离交流。另外我们网站也有大型企业招聘平台，里面有很多优质的岗位，有意者请查看详情。

如果您对本文感兴趣，可参与以下互动方式与作者近距离交流。

（1） 微博（）

      

（2） 微信(账号：SDNLAB)

（3） QQ群

  SDN研究群（214146842）

              OpenDaylight研究群（194240432）