云计算时代催生下一代网络变革-软件定义的网络之集成应用篇

■ 文/ 天云软件 任曙光

本文将对SDN与云平台集成方案、主流应用场景进行进一步讨论以及典型应用案例的分享。

在云计算环境中,最核心的几个特点:资源池化、按需分配、弹性伸缩、自助服务。因此SDN是云化网络资源的必由之路。对于云平台与SDN的集成可以利用SDN控制器的北向接口API进行对接,若云平台网络是基于OpenStack-Neutron,则众多厂商已经开发/开源了与之对接的插件,可以作为多种异构SDN产品统一网路适配平台。

OpenStack-Neutron 与 SDN

Neutron是OpenStack生态中必不可少的虚拟化网络解决方案,那么它到底属不属于SDN,我们可以对照前文(基础篇)对SDN的定义评判一下:

  1. Neutron网络由Neutron Server集中式控制;
  2. 对网络可编程;
  3. 提供统一开放的网络操作API。

除了没有看到关于控制平面与转发平面之类术语之外,似乎都满足SDN的定义。其实Neutron通过易扩展的开放的插件式架构可以集成其他SDN控制器来完全地满足SDN的要求。

Neutron的架构

sdn301

图1. OpenStack Neutron架构

Neutron架构可以分为Neutron Server、Neutron DB、Message Queue、Agent四个组件。

  • Neutron Server:运行于网络控制节点上,由三个模块构成:REST服务、RPC服务以及服务插件。Neutron Server通过HTTP接受用户的请求,最终与计算节点或者网络节点上的Agent进行执行。
  • REST API服务:对外提供统一的逻辑网络资源访问接口,如网络、子网、端口、路由等,它是用Python开发的基于WSGI的REST应用。
  • 服务插件:可以理解为一组对底层设备操作接口的标准化封装,来提供统一的逻辑网络访问功能,可以分为核心插件以及服务插件。核心插件包含L2/L3网络、IP地址管理等,而其他的如LBaaS、FWaaS、VPNaaS等属于服务插件。
  • RPC服务:插件通过RPC与Agent进行双向的通信。

核心插件的L2网络主要是由ML2插件进行抽象。ML2解耦了网络拓扑类型与底层网络实现机制,并分别通过Driver来进行高扩展,其中不同的网络拓扑类型对应着不同的Type Driver,由Type Manager管理;而不同的网络实现机制则对应Mechanism Driver,由Mechanism Manager管理。

sdn302

图2. ML2驱动

Neutron与SDN有三种集成架构模式

1. Neutron as App:将Neutron作为申请SDN网络资源的App,Neutron调用SDN控制器北向API来控制网络资源。

  • 优点:Neutron为底层不同的SDN提供统一标准的API,屏蔽了底层实现细节;同时主流SDN厂商多数提供原厂的Neutron插件。
  • 缺点:只能提供Neutron API定义的功能和资源消费方式,如需要额外的功能需要通过调用SDN的API来实现,这样将需要维护多套API。

2. Neutron as Controller:将Neutron作为SDN控制器的中实现的一部分,上层应用通过调用SDN控制器的北向接口来控制Neutron,实现对底层网络资源的申请和使用。

  • 优点:应用只需要调用SDN控制器的API,没有API兼容性问题,底层网络可以替换也可以不替换。
  • 缺点:部署时需要考虑Neutron和SDN控制器的对等关系。

3. Neutron as Underlay:将Neutron作为底层承载网络,通过Neutron API对接SDN控制器的南向接口,上层应用通过SDN控制器来申请和使用网络资源,再通过南向接口对Neutron的网络资源的调度与分配。

  • 优点:部署容易。
  • 缺点:有新功能需求时,改造Neutron较为复杂。

在OpenStack环境中,作者较为推崇方案一,即Neutron利用其强大灵活的插件结构,提供集成SDN控制器到OpenStack的能力。多种SDN控制器(ODL、ONOS等)已经积极地参与其中,运用对应的Mechanism Driver机制,使用指定的插件实现Neutron和SDN控制器之间通信。

sdn303

图3. OpenStack Neutron 与 SDN 集成

Neutron支持的各厂商的Plugin包括:

  • Open vSwitch
  • VMware NSX
  • Cisco UCS/Nexus
  • Cisco Nexus1000v
  • Linux Bridge
  • Modular Layer 2
  • Nicira Network Virtualization Platform (NVP)
  • Ryu OpenFlow Controller
  • NEC OpenFlow
  • Big Switch Controller
  • Cloudbase Hyper-V
  • MidoNet
  • Brocade Brocade
  • PLUMgrid
  • Mellanox Mellanox
  • Embrane
  • IBM SDN-VE
  • CPLANE NETWORKS CPLANE NETWORKS
  • Nuage Networks
  • OpenContrail OpenContrail
  • Lenovo Networking
  • Avaya Avaya
  • Extreme Networks
  • Ruijie Networks
  • Juniper Networks
  • Calico
  • BNC
  • 其他

SDN目前主流的应用场景

1、数据中心内部网络

SDN最初是以IDC企业作为主要推动力而发展起来的,SDN的核心思想很好地契合数据中心网络的集中管理、灵活组网、可控转发,适应大规模的虚拟化部署等方面的需求,因此在数据中心网络也成为SDN最成熟的应用场景之一。同时SDN也是传统数据中心向云数据中心转型过程中必不可少的支撑技术之一,不仅不再依赖于垄断厂商的高性能网络设备,而是用廉价的白盒交换机作为替代品,这样大大降低了大规模设备采购的CAPEX;而且由于SDN网络集中控制、开放接口、可编程,为业务部署提供了极大的便捷性,有利于提升运维效率、降低OPEX。

2、数据中心互联网络

数据中心之间的网络通畅承载着大量数据的同步和异地访问等业务,因此呈现出大流量、高突发的特点,往往成为跨数据中心业务的主要资源瓶颈。SDN网络通过集中的控制器对个数据中心的网络资源进行全局监控,对流量统一规划和调度,对多路径转发进行智能地负载均衡,对不同优先级的业务按需分配带宽,最大程度低优化网络资源、提升资源利用率。

3、多云/混合云互联互通

云计算经过多年的演进,目前市场上呈现出百花齐放的态势,多个异构的私有云或者私有云与公有云之间混合部署,但要确保业务负载能够在不同云之间进行无缝地迁移,或者业务之间的安全高效地互访。而实现多云/混合云的互联互通场景,SDN是网络组件的核心技术。而在多云/混合云的对接中,不能再依赖多个云提供商之间分别进行人工配置,与运营商协商开通新的带宽需求等,SDN可以提供网络的统一、灵活、弹性的管理配置能力,保证互联互通配置的便捷性以及安全策略的一致性。

4、云计算自服务式的网络资源配置

在云计算环境中,租户需要创建、操作自己的网络,并按照自己的业务需求进行配置。既要保证成千上万的用户之间的隔离性和安全性,又要满足网络配置的灵活性和自主性的要求,显然传统网络操作的复杂性往往难以支撑。SDN突破传统网络只能支持4095个子网的限制,可以满足上千万用户的支持,并且一切网络操作配置都可以在软件自动化来实现,简化了IT运维的同时,将底层实现细节进行抽象,用户只需在业务层面灵活的网络资源的请求和操作。

5、电信运营商网络

除了运营商发展新兴IDC或者云计算业务之外,OTT业务日益挑战着电信传统业务领域的网络(如接入网、核心网等)提供广域网的互联服务。为了适应业务的飞速的增长,迫使网元能够像IT应用一样快速部署、快速伸缩,而SDN与NFV完美结合能够提供一站式的ICT服务。CPE、OLT和BNG等接入网传统一体式设备率先接受在x86服务器上进行SDN/NFV改造,从专用设备到通用平台,不仅降低设备采购成本、提升业务的横向扩展能力,而且开放的通用平台也为业务的创新提供有利条件。如正在兴起的边缘计算领域,接入网设备是运营商离客户最近的网络设备,经过通用性平台改造之后,不仅可以提升了常规的网络传输业务、灵活性、性能、资源使用率等,而且可以在通用的x86框架上承载新兴的边缘计算任务。

典型案例:Google SD-WAN B4

背景

Google的使命愿景是整合全球信息,供大众访问,使人人受益。在此理念的指导下,Google提供搜索引擎、Google+社交、Gmail邮箱、YouTube视频门户、Google地图等多种服务,为了给全球用户提供高速、高可用的服务质量。数百条对外链路保证巨量数据在不同地域的数据中心间进行传输和复制,这包含三类数据传输:①用户数据备份,如图片视频等;②跨地域数据访问,如分布式存储的数据;③大规模的数据同步,如分布式容灾、负载均衡等,这极大地加重了WAN的负荷消耗。

问题

Google在基础架构的管理、成本和性能中,在计算和存储组件已经优化的很令人满意,但是诸多网络问题迫在眉睫,如非线性的管理复杂度,网络设备间的交互问题,非标准化的管理API,仍需大量的手工配置和管理精力等。Google急需一种具有规模经济的成本效率,更好性能,更高容错和更强的可管控性的WAN方案,将WAN管理简化成为网路结构而不是一堆设备。

方案

Google的WAN由两个大的骨干网组成:

  • 面向Internet(I-scale)的网络:承载用户的网络访问流量。
  • 面向内部(G-scale)的网络:承载数据中心之间的网络流量。

这两大骨干网在需求和网络流量特征方面有很大的不同。Google 2012年完成B4网络项目是针对G-scale网络进行了基于OpenFlow的SDN方案的改造。在此之前,Google没有任何OpenFlow的设备,所以Google用通用的商用芯片以及支持OpenFlow的开源的路由协议栈研发了自己的SDN网络设备B4,该设备包含了足够支撑Google业务需求的最少的特性集合。每个区域的网络都配备该种设备来支撑Google数兆兆级网络带宽的扩展能力以及极高容错能力,多个OpenFlow控制器确保没有单点故障。区域之间的WAN骨干网由集中式的流量工程(Traffic Engineering,TE)服务来管理和控制。它收集底层网络设备的实时利用率数据、带宽性能信息以及网络拓扑等,从而智能计算最佳网络流量转发路径。通过OpenFlow对交换机进行转发策略编程,均衡网络流量,优化设备带宽使用,使整体的网络资源使用率提高到94%,这是业界前所未有实践。

sdn304

图4. Google B4网络架构

结论

Google基于OpenFlow的SDN技术使数据中心之间WAN互联集中式管控,极大地提高了管理效率,网络性能和利用率,而且WAN成本效率也得到很大的提升。在该项目中充分地体现了SDN的优势:

  • 网络结构的统一视图:简化配置、管理和部署;
  • 资源利用效率:集中式的网络流量工程对网络资源和流量需求进行科学调配提供了全局视图,对流量路径进行了端到端的优化和管控,保证服务质量的同时也充分利用带宽资源;
  • 迅速的错误处理:集中式的设备数据收集、监控,快速地发现链路或者节点的异常情况,使及早预测故障,精准定位问题成为可能;
  • 缩短部署和发布时间:可编程的SDN极速相应业务变化的需求;
  • 灵活的弹性扩展:随着控制平面和转发平面的分离式部署,设备的计算转发能力不再成为局限,控制平面可以放在性能强大的x86服务器集群中,而转发平面设备可灵活扩展和收缩。

文中图片来源:

图1:作者自制

图2:https://thenewstack.io/sdn-controllers-and-openstack-part1/

图3:https://thenewstack.io/sdn-controllers-and-openstack-part1/

图4:https://www.sdnlab.com/sdn-guide/14868.html

【往期回顾】