张 晨 黄 韬 张 娇 刘 江
编排一词最早出现在艺术领域,指的是按照一定目的对音乐、舞蹈等表现元素进行排列,以达到最佳的艺术效果。而网络中的编排一词则指的是对于服务器、存储设备、网络转发与网络服务设备进行排列,以满足网络用户或管理员的需求。网络中的编排可以分为底层资源的编排以及高层业务的编排,其中资源编排侧重于对设备进行调度,业务编排侧重于对工作流程的规范,业务编排往往要依赖于资源编排来实现。
传统网络中,编排的工作主要由管理人员手工完成。在实际生产环境中,一个业务的开通往往需要不同领域的专业人员投入大量时间,短则一周半个月,长则数月半年。这不仅造成大量的运维开销,而且设备配置上的变更也难以跟上需求的快速变更,导致新业务迟迟不能上线。现网中,运营商的运营支撑系统(Operation Support System, OSS)具备对高层业务进行编排的能力,不过由于传统网络设备的能力不够开放,OSS对网络设备只能进行一些简单的管理和操作,业务的最终交付仍需要网络专业人员进行配置和调测。
网络自动化编排技术的变革首先发生在云计算领域。近年来,云计算的商业模式逐渐成熟,一切即服务(Everything as a Service, XaaS)的愿景要求IT基础设施能够按需地为云用户提供服务。在此背景下,虚拟化技术也得到飞速发展。虚拟化技术通过对服务器、存储设备、网络设备的能力进行抽象,将硬件设备软化为计算、存储、网络的资源池,这些资源都能够通过开放接口进行灵活调度,为实现物理资源的编排提供技术基础。同时,基于对物理资源的调度,在云中能够实现丰富的高层业务编排逻辑。目前,以Vmware、Microsoft为代表的IT服务商都形成了较为完整的云解决方案[1-2],开源社区也紧跟厂商的脚步,以OpenStack[3]为代表的开源云管理平台自推出以来迅速风靡全球。
然而在云中,网络资源的开放性仍然有所欠缺,相比于计算、存储虚拟化的纵深式发展,网络即服务(Network as a Service, NaaS)的发展则相对滞后。为填补网络资源在开放性上的不足,软件定义网络(Software Defined Networking, SDN)成为了网络界近几年来的焦点。SDN将传统网络设备中本地嵌入的控制逻辑提取到远端,并提倡通过开放的接口实现网络的可编程性[4]。自2008年提出以来,SDN的概念已经在云数据中心中得到广泛应用,SDN搭配OpenStack已经成为云数据中心的主流趋势。云数据中心是SDN的典型应用场景,但SDN不限于用作云数据中心网络,在企业网、广域网中SDN也正在逐步落地。
SDN侧重于对L2~L3中的网络连接进行虚拟化,而网络功能虚拟化(Network Function Virtualization, NFV)则侧重于对L4~L7中的网络服务(如防火墙、负载均衡等)进行虚拟化。NFV提出将专用硬件设施进行软件化,运行在通用服务器、通用存储和通用转发设备中,从而实现网络功能服务的灵活部署,并降低CAPEX和OPEX[5]。如果说SDN结合云管理平台提供了对计算、存储、网络连接的编排调度能力,那么NFV则提供了对于网络服务的编排调度能力。三者的有机结合,将共同描绘一张端到端、全程全网编排管理的新一代网络蓝图。
基于上述愿景,业界正在完善云、SDN和NFV相关技术,对于全自动化的网络编排进行着不断尝试。
云计算的一个典型特点是集中式管理与控制。云中的各类资源和模块都实现了数据和控制层面的分离,云管理平台对底层的计算、存储、网络资源进行统一调度,以实现底层资源的编排。在此基础上,云管理平台往往通过提供标准、开放的模板来简化业务部署、业务交付和新型业务的设计,从而实现高层业务的编排。
vCloud Suite[1]是Vmware公司提供的云数据中心解决方案,能够实现数据中心的自动化控制,硬件配置通过软件系统进行维护。vCloud目前已经更新至6.0版本,其产品架构如图1所示。其中,vSphere组件负责进行服务器虚拟化和对虚拟计算资源的管理调度,Virtual SAN组件负责对存储进行虚拟化和对虚拟存储资源的管理调度,Site Recovery Manager组件负责提供基于策略的云高可用性。在网络虚拟化技术方面,vCloud自研的虚拟分布式交换机(Virtual Distuibuted Switch, VDS)使用了VLAN技术,在收购SDN创业公司Nicira后,Vmware将Nicira的网络虚拟化平台(Network Virtualization Platform, NVP)和开源虚拟交换机(OpenvSwitch, OVS)集成为目前vCloud中的NSX组件,基于Overlay技术实现网络虚拟化并对虚拟网络资源进行管理调度,在不同的租户间提供安全策略和隔离性。上述组件共同提供云数据中心的基础设施即服务(Infrastructure as a Service, IaaS)的能力。在此基础上,vRealize Automation/Operations/Business共同提供了云管理能力,其中vRealize Automation提供一个安全门户,已授权的管理员、开发人员或业务用户可以请求新的云服务,vRealize Automation会触发vRealize Orchestrator,Orchestrator支持对云中的工作流程进行标准化,并通过调用IaaS接口来自动部署云服务,实现Vmware中的高层业务编排。vCloud是Vmware的商用产品,并提供与OpenStack等开源云平台项目的对接。
图1 Vmware Cloud Suite v6.0架构图[1]
OpenStack是一个开源的云计算平台,可以大规模地管理计算资源、存储资源、网络资源等基础架构。OpenStack是由Rackspace Cloud和NASA在2010年发起的,自成立以来,OpenStack已经获得业界广泛认可,目前,已经迭代到第12个发行版本—Liberty。OpenStack Liberty的组件结构如图2所示,其中Nova对计算资源进行编排,提供虚拟机的全生命周期管理功能,Cinder和Swift对存储资源进行编排,分别提供块存储和对象存储的能力,Neutron对网络资源进行编排,以插件的形式支持多类网络资源的互联互通。其它组件如Horizon提供面板控制、Keystone提供身份认证、Glance提供镜像等等。Heat是OpenStack中的业务编排组件,通过接收面板的调用,或者根据模板文件中的描述,将服务请求解析为对各种类型资源的请求,然后通过调用Nova、Neutron等组件的接口来完成部署。Heat还支持资源的弹性伸缩,以按需服务于云用户。
图2 OpenStack组件结构图
目前,在Liberty版本中,Neutron作为OpenStack中管理网络的组件,能够接收前端传送过来的业务请求,或者接收开放的Neutron API的调用,据此对计算节点HyperVisor中的虚拟转发设备(如Linux Bridge和OpenvSwitch)进行控制,OpenStack在设计之初采用Nova-network对网络进行管理,支持简单的Flat DHCP 2层网络以及VLAN网络,不过不提供面向租户的开放API,后续OpenStack在Folsom版本中推出了专用的网络组件Quantum,支持Overlay技术,并提供面向租户的开放式API。Quantum还支持厂商开发各家的设备驱动,不过一些基本功能(如租户网络的数据库)也需要各个厂商自己独立开发。Openstack在Havana版本上将Quantum更名为Neutron,并开发了ML2(Modular Layer 2,模块化的2层网络)插件记录租户网络的一些基本信息(如网络类型是VLAN还是VxLAN等),各个厂家基于ML2进行设备驱动的插件开发。
CloudStack[6]是一个开源云计算解决方案,最初由Cloud.com公司开发,Citrix公司在2011年收购Cloud.com后,将全部代码开源,目前已经发布了4.6版本。CloudStack的架构如图3所示,可以看到它与OpenStack的主要功能类似,通过Orchestration Engine对业务进行编排,Orchestration Engine通过与Compute Controller、Network Controller和Storage Controller进行交互来编排底层的资源。不过与OpenStack的分布式服务架构不同,CloudStack采用了集中式的单体架构,整个平台只有一个项目,不同模块之间通过本地调用进行交互,在一台主机上就可以完成平台的部署。CloudStack中的Network Controller支持基于VLAN、Overlay等技术实现网络虚拟化。
图3 CloudStack架构图
SDN中控制平面与转发平面分离,设备的转发逻辑由远端集中式的控制器实现,解决了传统网络设备的嵌入式控制不够灵活、分布式控制无法全局最优等问题。SDN中编排的概念很广泛,控制器通过南向协议控制设备的转发可以看做是对底层资源进行编排,应用程序通过北向接口调用控制器的功能可以看做是对业务的编排。关于控制器如何对底层资源进行编排,本节不做详细的描述,下面主要对SDN中的业务编排进行介绍。
计算机编程语言的发展经历了晦涩的机器语言、汇编语言等阶段,最终发展出易于理解的高级语言。同样,对于SDN来说,高度用户化的编程语言能够屏蔽底层设备接口的复杂性,使得SDN应用开发人员可以注重于业务逻辑,而非底层硬件实现,是推动SDN发展的重要技术。普林斯顿大学和康奈尔大学的研究人员分别在2011年和2013年提出Frentic[7]和Pyretic[8],这两个语言的研发都在Frenetic Project的整体框架中进行,主要在网络流量监测、转发策略指定、一致性策略更新和服务质量等方面进行了高层业务逻辑的抽象。Frenetic提供了并行的模型,进入控制器的每一个数据包都由一个对应的策略模块处理,多个条件组合形成的策略也是并行执行的。Pyretic则在Frenetic的基础上支持策略的串行执行,以及串行并行相结合的混合模型。耶鲁大学的研究人员在2013年提出了Maple[9],相比于Frentic和Pyretic对策略模型的关注,Maple则能够通过高效的算法将集中式的业务策略映射为分布式部署的流表,并支持多核处理,提高了编译的性能。
P4[10]是斯坦福大学和普林斯顿大学于2015年发布的SDN编程语言项目,起源于2014年的一篇Sigcomm论文。P4是一种数据平面的编程语言,旨在彻底打破现有协议对于网络的限制,基于P4的用户可以任意地指定字段的解析、匹配与处理动作,这也是目前能够看到的SDN最为理想的形态。除了底层的数据平面编程,P4也提供了高层的逻辑,编程者能够方便地指定与设备类型无关的转发表匹配范式。P4直接打通了高层业务逻辑和底层转发资源,被寄希望作为OpenFlow 2.0,不过P4这种接近于终极的灵活性也对芯片的设计要求极高,短期内还很难进行商用。
上述的SDN编程语言均采用自底向上模型驱动的设计方式,虽然用户无需关注底层资源,但语言本身仍关注网络配置和实现的细节。相比之下,SDN编程语言还可以采用自顶向下业务驱动的设计方式,从业务行为和应用需求的角度出发,语言本身无需关注底层实现细节,从而使得北向接口和南向协议能够完全解耦。开源项目ONOS[11]的Intent设计,OpenDaylight[12]的GBP、NEMO设计均采用了这种思路。
ACI[13](Application Centric Infrastructure,以应用为中心)是思科推出的SDN解决方案,通过应用驱动型策略模式简化自动化工作,同时能够利用实时的应用运行状况监控实现集中式可视性。ACI策略引擎实现了应用程序需求策略的具体要求,管理着整个ACI网络,包括基础架构、验证授权、安全、服务、应用和故障排查等,ACI策略引擎的模型如图4所示。APIC作为控制器在ACI网络中自动将策略部署到ACI设备中,对包括应用程序设置、安全策略、租户子网等进行自动化实现。ACI改变了思科传统以硬件为核心的产品和服务策略,它的核心基础是以软件方式管理和运营网络,不过ACI的实现仍主要基于思科硬件设备如Nexus交换机和定制化的ASIC商用芯片。
图4 ACI策略引擎模型[13]
Netmatrix[14]是华为2013年推出的SDN/NFV编排系统,它独立于SDN控制器存在,向上提供了与运营商OSS的集成能力,支持OpenStack、CloudStack等多种主流云平台的接口,向下通过Netconf、REST API等接口协议与SDN控制器互通,负责业务模版定义和业务发放,同时Netmatrix支持通过Netconf、SNMP、CLI、XML等接口协议与传统设备互通。通过上述技术,Netmatrix希望提供端到端的跨域SDN控制器协同,SDN和传统网络协同,网络和DC业务协同。Netmatrix屏蔽了网络技术的细节和设备差异,并提供模型驱动的可编程框架,以期快速适应新需求改变。
在ETSI提出的NFV架构中[5],MANO(Management&Orchestration)负责对NFV网络进行管理。MANO又分为NFVO(NFV Orchestrator)、VNFM(VNF Management)和VIM(Virtualised Infrastructure Management)。VIM和VNFM联合对资源进行编排,其中VIM负责对通用物理设备进行虚拟化,VNFM负责对虚拟网元VNF(Virtual Network Function)进行生命周期的管理,而NFVO负责对NFV网络中的业务进行编排。本章将对MANO的一些具体实现进行简要的介绍。
NFV Director[15]是惠普推出的MANO产品,实现了ESTI提出的NFV架构中的NFVO和VNFM。HP NFV Director的模块如图5所示。
图5 HP NFV Director的组成模块[15]
其中,策略管理模块通过北向接口接收服务的描述和需求,目录和列表模块负责对服务和网元进行存放和记录,执行模块包括服务执行、VNF执行和全局资源执行,负责服务开通与一些具体的网络配置,监测模块包括服务监测、VNF监测和全局资源监测,负责对NFV网络进行多个层次的保障。HP NFV Director采用模块化的设计,能够支持第三方VNFM扩展,能够对多厂商的物理基础设施和虚拟网元进行联合的编排与调度。
NSO[16](Network Service Orchestration,网络服务编排器)和AO[17](Application Orchestrator,应用编排器)分别是Oracle基于ESTI的NFV架构开发的NFVO和VNFM产品,如图6所示。NSO由三个组件构成:UIM负责记录VNF和网络服务的目录清单,ASAP负责与AO进行交互以对VNF进行管理,Design Studio负责定义VNF和网络服务的部署方式、属性和配置信息。AO由六个组件构成:Virtual Image Archive负责管理VNF虚拟机的镜像,Orchestration Engines负责与VIM进行交互以管理VNF虚拟机,Virtual Machine Group负责维护具有相同策略的VNF虚拟机,Cloud Administration负责权限管理,KPI Thresholds负责记录VNF关键性能指标的阈值信息,Monitor负责对VNF关键性能指标进行周期性的监测。NSO的设计与AO是解耦的,能够支持第三方VNFM扩展。
图6 Oracle的NFV产品NSO和AO[16]
OPNFV[18]是目前全球最大的NFV开源组织,它是一个运营商级的、集成的平台,旨在加速引入NFV产品和服务。2015年6月,OPNFV发布了首个版本Arno,这个版本基于OpenStack和SDN开源控制器OpenDaylight进行集成开发,提供了ESTI的NFV架构中基础设施层的NFVI和VIM,但目前仍缺乏VNFM和NFVO的实现。据OPNFV项目组计划,在2016年2月发布的第二个版本Brahmaputra中将对VNFM和NFVO进行简单的实现。
云管理平台主要通过其专门负责网络的Neutron组件来完成对计算、存储、网络三维资源的编排及与SDN的混合编排。当厂家为Neutron提供的是虚拟转发设备的插件时(如OpenvSwitch在Neutron中的插件),此时Neutron直接控制设备的转发,即可将Neutron看做是SDN控制器;当厂家为Neutron提供的是控制器的插件时(如Nicira NVP、OpenDaylight、ONOS在Neutron中的插件),Neutron不直接控制虚拟转发设备,而是由SDN控制器在接收Neutron的调用后通过南向协议(如OpenFlow、OVSDB等)对设备进行控制,此时Neutron可以看做是网络的服务编排器,而SDN控制器可以看做是网络的资源编排器。上述两种云管理平台与SDN混合编排的模式分别示意为图7中(a)与(b)。
N F V的基本思想是将硬件设备软件化,在NFV框架中包括基础设施层、虚拟功能实例层和NFV编排层,而云中管理平台(如OpenStack)可以看做是NFV的一个特殊的实现。目前,NFV开源项目OPNFV中即使用OpenStack作为NFVI对物理基础设施进行虚拟化。另外,OpenStack除了能够对物理基础设施进行虚拟化以外,也能够作为虚拟功能实例层(如通过Celimetor组件对虚拟机进行生命周期监测),还能够作为NFV编排层(如通过Heat组件对服务进行模板化设计),OpenStack项目组也正在积极准备一个名为Tracker的项目,以对虚拟功能实例层和NFV编排层进行更好的实现。上述云管理平台与NFV混合编排的架构如图8(a)所示。
在云中,一些V N F(如Firewalls、vRouter等)可以看做是为租户提供增值业务的设备,一些VNF可以在云管理平台中的网络组件(如OpenStack的Neutron)中实现,并通过对其接口进行扩展以实现对VNF资源的编排,此时云管平台从系统建设角度来看也不再附属于NFV,对NFV服务链的编排依赖于云管平台的服务编排组件进行实现(如OpenStack Heat)。上述两种云管理平台与NFV混合编排的架构如图8(b)所示。
图7 云管理平台与SDN混合编排
图8 云管理平台与NFV混合编排
当SDN在ETSI提出的NFV架构下进行部署时,SDN不再进行单独的系统建设,包括SDN控制器、SDN转发设备都可能有不同的部署位置。如图9(a)所示,橙色和绿色的方框分别为SDN控制器、SDN转发设备可能的部署位置。其中,当控制器部署在a点即VIM中时,转发设备可以部署在d点作为硬件网络资源,也可以部署在通用硬件虚拟化层中的e点作为虚拟网络资源;当控制器部署在通用硬件虚拟化层中的虚拟计算资源即b点时,转发设备以VNF转发实例的形式部署在c点;当控制器部署在VNF SDN Controller实例时,转发设备同样以VNF转发实例的形式部署在c点。SDN编排器的功能在该架构中可以集成在NFVO和VNFM中,其编排主要功能包括服务链的标签分配,服务链的流量引导,SLA策略等等。另外,在这种混合部署模式中,由NFVO完成与传统网络OSS系统的对接。业务入口可以为OSS系统,其对于SDN服务的需求传递给NFVO来完成。业务入口也可以为MANO,其对于传统网络服务的需求由NFVO传递给OSS来完成。
SDN网络在某些场景下是不依赖于NFV的,网络中除了包括NFV虚拟转发设备以外,还很有可能包括一些硬件转发设备。此时,SDN系统与NFV系统将独立建设,由SDN负责对虚拟、物理设备的转发进行控制,而NFV则扮演类似于SDN网管的角色,负责虚拟转发设备的实例化和配置等,两套系统并行工作,协同完成对网络的编排工作,如图9(b)所示。
图9 SDN与NFV混合编排
云、SDN、NFV都是近年来业界比较重视的新型网络技术,它们沿着虚拟化、软件化的路线正在对灵活性差、自动化能力弱的传统网络进行着深刻的变革。本文对云、SDN、NFV中的网络编排原理进行描述,并选择有代表性的产品和开源项目进行了介绍。网络的自动化编排能力正是虚拟化和软件化所追求的理想结果,目前,云管理平台在自动化编排能力上已经获得业界的广泛认可,而SDN和NFV在自动化编排方面仍缺乏相关标准,三类技术混合编排的部署方式也有待进一步的探索。
参考文献
[1]Vmware.vCloud Suite[EB/OL].[2016-01-20].http://www.vmware.com/cn/products/vcloud-suite/
[2]Microsoft.Windows Azure[EB/OL].[2016-01-20].http://www.windowsazure.cn/zh-cn/
[3]OpenStack.Official Website[EB/OL].[2016-01-20].http://openstack.org/
[4] ONF.SDN_ARCH_1.0[EB/OL].[2016-01-20].https://www.opennetworking.org/images/stories/downloads/ sdnresources/technical-reports/TR_SDN_ARCH_1.0_06062014.pdf
[5]ESTI.NFV Witepaper[EB/OL].[2016-01-20].http://www.etsi.org/deliver/etsi_gs/NFV/001_099/002/ 01.02.01_60/gs_NFV002v010201p.pdf
[6 CloudStack.Official Website[EB/OL].[2016-01-20].http://cloudstack.apache.org/
[7]Nate Foster, Arjun Guha, Mark Reitblatt, et al.Languages for software-defined networks[J].Communications Magazine,IEEE, 2013, 51(2): 128-134
[8]Joshua Reich, Christopher Monsanto, Nate Foster, et al.Modular sdn programming with pyretic[J].Technical Reprot of USENIX, 2013
[9]Andreas Voellmy, Junchang Wang, Yang Y, et al.Maple:Simplifying SDN programming using algorithmic policies[C]//ACM SIGCOMM Computer Communication Review.ACM,2013, 43(4): 87-98
[10] Pat Bosshart, Dan Daly, Glen Gibb, et al.P4: Programming protocol-independent packet processors[J].ACM SIGCOMM Computer Communication Review, 2014, 44(3): 87-95
[11] Pankaj Berde, Matteo Gerola, Jonathan Hart, et al.ONOS: towards an open, distributed SDN OS[C]//Proceedings of the third workshop on Hot topics in software defined networking.ACM, 2014: 1-6
[12]Jan Medved, Robert Varga, Anton Tkacik, et al.Opendaylight: Towards a model-driven sdn controller architecture[C]//2014 IEEE 15th International Symposium on.IEEE, 2014: 1-6
[13]Cisco.Application Based Infrastructure[EB/OL].[2016-01-20].http://www.cisco.com/web/CN/solutions/datacenter/aci.html?CAMPAIGN=Insieme&COUNTRY_SITE=cn&POSITION=sl&REFERRING_SITE=Cisco.co m+homepage&CREATIVE=homepage+spotlight+to+AC I+launch+landing
[14]Huawei.NetMatrix[EB/OL].[2016-01-20].http://www.huawei.com/ilink/cn/about-huawei/newsroom/pr essrelease/HW_310988
[15]HP.NFV Director[EB/OL].[2016-01-20].http://www8.hp.com/uk/en/pdf/NFV_Director_customer_prese ntation_tcm_183_1541136.pdf
[16]Oracle.Network Service Orchestartor[EB/OL].[2016-01-20].http://www.oracle.com/us/products/ applications/communications/service-orchestration/index.html
[17]Oracle.Application Orchestrator[EB/OL].[2016-01-20].http://www.oracle.com/us/products/applications /communications/application-orchestrator/index.html
[18]OPNFV[EB/OL].[2016-01-20].https://www.opnfv.org/