开源MANO软件盘点:管理和编排有多重要-搜狐

　　本文描述了ETSINFVMANO的概况，以及在该领域的概况。

　　MANO致力于“管理和编排”，是ETSI NFV定义的架构框架的功能模块的一部分。OSM即开源MANO。

　　NFV MANO涵盖了支持基础设施虚拟化的物理/软件资源的编排和生命周期管理，以及VNFs的生命周期管理。NFV管理和编排专注于NFV架构中所有的特定虚拟管理任务，主要由以下3个模块构成：

　　Fig 1 – ETSI NFV Architectural Framework

　　■ VIM，虚拟基础设施管理，管理NFVI（网络功能虚拟化基础设施），这是例如OpenStack等组件的典型应用环境。

　　■ VNMF，VNF生命周期管理（如实例化，更新，查询，缩放，终止等），他们可能是多个VNF Manager管理一个VNF或者多个VNF，或者一组VNF Manager管理多个VNF，或者一个通用的VNF Manager管理所有的VNF生命周期。根据MANO架构报告，ETSI NFV根据GS/NFV-IF009定义提供VNF Manager的相应的多种开放能力。

　　■ NFVO，NFV编排器负责NFV基础设施、软件资源和NFVI层面的网络服务的编排和管理。

　　但是除了这些功能模块，ETSI NFV还定义了这些模块中的以下开放接口，如：

　　■ Nf-Vi：介于VIM和NFVI之间Or-Vi：介于NFVO和VIM之间=>ETSI GS NFV-IFA 005

　　■ Vi-Vnfm：介于VNFM和VIM之间=> ETSI GS NFV-IFA 006

　　■ Or-Vnfm：介于VNF Managers和NFVO之间=> ETSI GS NFV-IFA 007

　　■ Ve-Vnfm：介于NFV-EM网络功能和VNFM（s）之间=> ETSI GS NFV-IFA 008

　　■ Os-Ma：介于NFVO和OSS/BSS之间=> ETSI GS NFV-IFA 0013/0012

　　■ 这些接口在ETSI NFV发布的第二个版本中指定了不同的规范，目前在ETSI NFV的门户网站上可以下载到该版本的内容，该版本的工作情况也同时在ETSI NFV的网站上公开。

　　Fig 2 – ETSI NFV Release 2 Interface &Architecture (IFA)

　　与ETSI NFV规范并行的是其他的一些开源项目，开源项目有不同的需求，他们或由开源社区主导，或由单一的实体公司主导，他们有不同的许可证，也会选择做一些容易实现的架构或者语言等。本文重点涉及到的是开源NFV-MANO项目（图2所示的蓝框部分）。

　　下表是一个MANO开源项目的列表

　　值得注意的是这个表格可能不够详尽，像一些在Github上发布代码的实验室和公司可能不在其中。一些合作项目或者子项目也不在其中，如Riftware和Juju项目作为ETSI OSM项目的子项目。本文的目的不是来比较这些项目的不同，项目的列表也不详尽，只是为了说明ETSI NFV MANO和一些生活中已经实现和演示的这些项目。

　　在深入这个话题之前，我们去理解这些项目在ETSI NFV发布第2个版本的同时这些并行的项目所做的事将极为重要。他们中的绝大多数所进行的工作是基于ETSI NFV发布的第一个版本的规范进行的，这意味着功能架构、参考点和一般概念有很大的相似。他们也有不同的运作模式，通常有下面所描述的3类方式，ETSI OSM采用的是第一个模式，由官方主导的开源社区。Open-O选择ETSI OSM的组件，然后选择第二种开放模式。

　　Fig 3 – Opensource project modelsOpenStack Tacker

　　OpenStack Tacker项目已经运行了好几年了，它是Neutron项目的延续，并被剥离出来成为了Tacker项目，并且在2015年温哥华OpenStack峰会上首次面世。最初包括惠普在内的几家公司推动，该项目最初一直很低调，直到OPNFV和其他项目将它的代码作为锻炼基础设施项目的工具去实现才火起来，如OPNFV的SFC，ETSI NFV VNFM功能映射。

　　Tacker项目由OpenStack管理，因此它遵循OpenStack社区项目的指导方针和管理模式。Tacker目前正在逐步成为独立于OpenStack之外的项目，目前已经成为OpenStack Mitaka版本中的一部分。

　　Fig 4 – Tacker project evolution in OpenStack

　　Tacker与OASOS TOSCA密切合作并为其CSD03版本提供必要的NFV方面的需求，目前CSD03被用来定义网络服务描述符（NSD）、VNF描述符（VNFD）以及VNF转发描述符（VNFFGD）。这些模板被解析并转译成被OpenStack Heat和Keystone接受的模板传输到相应的接口。

　　Fig 5 – TOSCA mapping to ETSI NFV deors

　　Tacker为NFVO-VNFM提供了一个集成的构建模块，因此其内部的Or-Vnfm接口没有公开，但是它可以支持外部的VNFM。作为Tacker的嵌入式VNFM，它支持以下功能：

　　■ 数据库中存在VNF描述符（VNFDs）的目录

　　■ 在Tacker中VNF实例化以及终止使用TOSCA进行热转译

　　■ 在实例化、更新、重启过程中使用可加载的VNF特定管理驱动进行VNF配置注入

　　■ 加载VNF健康监测根据VNFD策略自我恢复

　　Fig 5. OpenStack Tacker Architecture

　　在OpenStack Liberty的版本中，Tacker只能支持放置VNF单个OpenStack实例，到了Mitaka版本中，Tacker支持多OpenStack VIM站点，即便有不同的版本。

　　ETSI OSG OSM

　　ETSI目前已经创建了一个新的类型的实体叫做OSG，即开源工作组，来支持ETSI开源项目的发展。OSG的首个项目是NFV-MANO，被称为OSM（OpenSource MANO），是于2016年4月问世。它将一些已经存在了一段时间的组件聚集到一起，典型的是Telefonica的OpenMANO项目，Rift.io riftware软件和Canonical Juju charms软件。所有这些项目都已经在Github上开源，尽管ETSI一直以来致力于标准规范，但到目前为止它仍然是通过开源发展的工具如Github、Jenkins来构建模型。尽管它从一组预定义软件中产生，但是为了扩展当前项目向所有的贡献者开放。

　　ETSI NFV架构的蓝图也很清晰，还是关注功能模块和参考点级别上。

　　Fig 6 – ETSI OSM mapping to ETSI NFV architectural framework

　　与Tacker相似的是，ETSI OSM提供了NFVO+通用VNFM的集成模块，支持外部特定的VNFM，同时还支持与OpenStack VIM的集成，这使得其他VIM从中受益良多。在NFV编排功能和VIM之间，VNFM功能和VIM之间都存在集成点，但是它们目前都没有纳入到ETSI NFV规范中去。此外，集成点还存在于OSS/BSS之间，同样也不属于当前的IFA相关规范。

　　ETSI OSM利用OpenMANO实现资源编排，利用Juju实现VNF配置和管理，OSM还引入了一个Rift.io Riftware服务编排组件，目前该组件还在ETSI NFV范围之外。

　　Fig 7 - ETSI OSM architecture

　　ETSI OSM的目标是定义一个以ETSI NFV第2个版本信息模型为标准的信息模型，目前一个基于3个独立模块（OpenMANO，Riftware，JuJu）与网络服务及VNF的集成数据模型的发展蓝图将会发布，以后每6个月更新一次。

　　Open Baton

　　Open Baton是由Fraunhofer Focus和TU Berlin一起发起的一个开源项目，现在被一些欧洲项目所使用，在Github和Apache 2.0许可下使用。Open Baton是基于ETSI NFV第一阶段参考架构和MANO规范构建的，现在还没有一致的 IFA接口规范。它提供了一个NFVO构建模块，一个通用的VNFM，EMS组件，仪表盘，能够支持多个OpenStack VIM并向其他VIM提供插件支持，同样它也支持特定的VNFM。

　　Fig 8 – Open Baton architecture

　　用java实现spring.io架构，它支持VNF包定义包括VNF描述符、脚本、元数据、图像链接在内的json。它支持结合脚本和元数据的CSAR（云服务归档）包构成的TOSCA模板，NFVO读取这些包获得数据。NFVO使用RabbitMQ与AMQP协议进行通信来调用VNFM，通用EMS将调用配置新实例，然后NFVO使用Zabbix监测VNF。

　　支持生命周期操作：初始化、配置、启动、停止、终止。

　　Fig 9 – Open Baton typical call flowOpen-O

　　Open-O是由Linux基金会在2016年6月发起的一个项目，这是最近兴起的一个项目，比较值得惊讶的是OpenStack Tacker也是由Linux基金会主办的，但Linux基金会还有其他的研究项目，如SDN控制器OpenDaylight和ONOS。不管怎样，Open-O画下了完美的蓝图，并且已经有了15个成员单位，包括推出Cloudify产品的Gigaspaces公司等开源玩家。Open-O呼吁代码贡献，因此个人代码贡献者可以和大公司一起来决定Open-O的发展走向。

　　Fig 10 – open-o current architecture/blueprint proposal

　　Open-O的计划将由ETSI NFV定义的如NFV-O等组件纳入到与EMS、VNFM、VIM、OpenStack的集成，Open-O在NFVO资源编排功能之上引入了“服务编排器”组件。

　　在数据结构方面，Open-O倡导使用GUI来管理建立公共信息和数据模型、冲突检测模型包括静态和动态的冲突，也使用TOSCA和Yang模型。

　　Open-O还计划于其他开源项目合作，如OpenStack，OPNFV，特别是如下图所示的openCORD：

　　Fig 11 – open-o collaboration with other Linux Foundation projects

　　同样有趣的是Open-O在它的架构中很明显的使用一个SDN编排器（SDNO），如上图9所示，SDNO与NFVO并列置于OPENCORD和ONOS控制器之上。虽然这有点混乱，但这就能看到MANO开源项目正在扩大SDN控制器/SDN编排和NFV编排。希望这将有助于超越ETSI NFV当前的EVE005，并为业界带来一些集成和部署模型。

　　T-NOVA TENOR

　　T-NOVA是在欧洲FP7 program之下的一个项目，目前已经完成并发布。它包括一个市场组件，一个名为TENOR的编排器，VNF（虚拟网络功能）&NS（网络服务）描述符。

　　如果我们关注编排模块，如图10所示，我们注意到这个模块包括ETSI NFV编排器（NFVO）区分成两个功能：网络服务编排器（NSO）和资源编排器（RO），嵌入式VNFM和元数据实例库。它还提供了类似于ETSI NFV的接口，如Ve-Vnfm，ViVnfm和Or-Vi。但它没有暴露其NFVO和NFVM的接口，也不提供开放的Or-Vnfm来支持外部VNFM，但是它引入了一些新的南向广域网基础设施中的Or-Tm接口，ETSI NFV在这方面有点模糊但是我们假定它是Or-Vi。T-Nova也定义一些其他的面向OSS、仪表盘等的北向接口。

　　Fig 12 – T-Nova Orchestrator Architecture

　　T-Nova在其门户网站上发布了一些成果，我们将更好的理解这个项目。与此同时，该项目的开源代码也在Github上发布。包括TENOR，T-Noca编排器，例如网络服务仅限于1 VNF，VDU限制在1 VNFC。T-Nova描述符Json模式转换成Heeat模板。其他开源组件包括描述符，VIM监控，定义了网络服务的工具，网络功能仓库，评级/计费架构，仪表盘。其中一些组件可以映射到ETSI NFV MANO中，其他的则没有纳入到ETSI NFV范围中，如评级/计费架构。

　　总结

　　总之，这些不同的开源项目有不同的结构，由一个特定的工作组或开源社区如OpenStack、Linux基金会或ETSI管理。尽管目前Apache 2.0是最普遍的许可，但是他们仍然使用不同的许可。他们所涵盖的范围也存在差异，然而他们所指向的模块都是ETSI NFV参考体系架构模块，一些参考点和高级生命周期管理操作，并且主要侧重于NFVO和VNFM，他们中很少的几个引入了一些ETSI NFV之外的元素。

　　以上这些有趣的试验提供了一些闭环验证ETSI NFV规范的方法，应该将缺失的部分尽快扩展，我们从这些处于不同成熟阶段的项目中可以看到，MANO开源的发展仍然处于非常早期的阶段。

　　下表列举了一些主要的通用组件及差异：