译者简介：喻晶洁，毕业于北京邮电大学通信工程专业，现于国内一家通信设备供应商担任RD工程师。

MANO（管理和网络编排）在ETSI ISG NFV架构中定义为由多个功能实体所组合而成的一个层，这些功能实体负责管理和编排云基础设施、资源以及服务等。

NFVOrchestrator（编排器）负责管理“网络服务生命周期管理”和“总体资源管理”等功能模块。服务管理或编排通过组合不同虚拟网络功能（VNF）来实现服务的创建和端到端的管理。资源管理有助于保证NFV的基础架构资源被完全抽离开（独立于VIM），从而能够更好的支持调用这个资源的服务。

VNF Manager（管理器）负责监视VNF实例的整个生命周期（通常涉及配置、扩展和终止）。通常假设每个VNF将与将管理该特定VNF生命周期的VNFM相关联。 VNFM可以管理相同类型的VNF或不同类型的VNF的多个实例。

虚拟化基础架构管理器（VIM）控制和管理NFVI中的计算，存储和网络资源。这是NFV-MANO最关键的组件，因此它受到业界最多的关注。

总之，当MANO被视为单一实体时，典型的功能包括（a）基础设施自动化，并提供一致、准确和全球资源视图，（b）网络集成，（c）VNF生命周期管理及其在在NFVI，（d）服务管理，（e）性能监测，分析和管理（审计，合规性）支持。

VIM组件已经获得了巨大的关注和各种开源解决方案，如OpenStack等，并已被用于实现MANO的虚拟化基础设施管理功能。

从上图可以看出，为了使MANO正常工作，它必须与现有系统中的一组优选地并对外打开的接口集成。根据ETSI定义，MANO负责部署和连接宿主机元素或虚拟网络功能。

电信行业也看到了MANO所带来的巨大好处，如实现更大的灵活性和运营功能; 电信行业必须正确地对待MANO。

正如许多专家所提到的，NFV MANO是一个开放的，可以广泛的让设备商扩展的部分。例如，德国电信的开放网络基金会董事会成员Axel Clauberg指出，在那里有一个“协调者” - 指的是不同供应商对NFV参考架构中弱定义组件的解释：NFV 管理和编排（MANO）堆栈。

此外，Clauberg补充说，每个供应商似乎都标榜他们的解决方案为“开放”，但是当进一步细想时，很难理解什么是真正的“开放”。开放APIs究竟算不算真的开放，这是令人怀疑的。

一个已经提出很久且仍然存在的问题是：OpenStack是否应该增强以涵盖MANO的所有方面？虽然一些专家认为OpenStack足以满足MANO的要求，但其他人认为OpenStack作为云VIM的一个元素，应该只是NFV MANO中的一个工具。

总体而言，大多数行业专家反对仅使用OpenStack作为MANO的想法，主要是考虑到传统设备的存在和基于传统设备解决方案的因素。OpenStack缺少特定的机制来支持现在使用传统网络设备部署的许多服务和服务组件。此外，由于许多传统元素具有管理和编排工具，实现MANO功能，因此OpenStack不需要超越其管理云基础架构和云的使命。

另一方面，由于几乎所有的NFV部署都源于云，因此在管理这样的虚拟化基础设施方面非常流行的OpenStack可以被增强以支持所有NFV需求。这将使OpenStack更加强大，并可能促进NFV部署的增长。

此外，OpenStack应该提供更快的方法来部署MANO，特别是如果当前大家在OpenStack中启动NFV的努力已经产生了更广泛的类MANO功能集。总之，虽然趋势是使用OpenStack开发额外的编排器和管理器，但如果这种编排器/管理器不能保持真正的“开放”，情况可能会改变。

OASIS标准TOSCA（云应用程序的拓扑和编排规范）旨在标准化如何描述软件应用程序以及在云环境中运行该应用程序所需的一切。 TOSCA旨在促进云服务的“可移植性”和“生命周期管理”。 TOSCA支持许多云编排工具，如OpenStack Heat，Cloudify，SeaClouds，Alien4Cloud等。

1.3 目前面临的实施挑战

Heavy Reading的一项深入研究的指出，在实践中，大多数实现者不是按照ETSI NFV ISG对MANO协议栈中的三个功能层的描述来分开进行部署。此外，Heavy Reading还强调了在VIM和NFVO之间分配资源管理责任造成的混乱。因此，截至今天，考虑到不同的VIM（开源和商业）和VNF-M / NFVO供应商，为了克服设备商的封闭性，运营商（如Telefonica和AT＆T）可能更好地构建一些元素，或者启动开放项目来应对挑战。

我们将开源MANO解决方案分为两类：（a）集成项目，提供完整MANO解决方案，（b）子集项目，实现MANO的一些部分。

2.1 集成项目——完整的MANO解决方案

VIM的参考实现。它非常类似于OpenStack，与NFV基础设施中的计算节点以及提供计算和网络功能以及部署虚拟机的OpenFlow控制器接口。它提供了一个基于REST的北向接口。OpenVIM是EPA感知的，包括功能支持，如CPU和NUMA固定，PCI传输等。
OpenMANO是NFV-O（网络功能虚拟化编排器）的参考实现。它通过其API与NFV VIM接口，并提供基于REST（OpenMANO API）的北向接口，其中提供NFV服务，包括VNF模板，VNF实例，网络服务模板和网络服务实例的创建和删除。此外，NFV编排器包括VNF和NS描述符，并且利用平台感知字段来增强，而VNFM是相当通用的并且是DSL使能的。

截至今天，OpenMANO是一个非常基本的实现，不适合商业部署。OpenMANO的源代码可以在这里找到。

RIFT.io在8月的英特尔开发者论坛上向全世界推出了RIFT.ware，并在2015年年底向开源社区宣称发布了RIFT.ware 4.0（一种用于NFV管理和编排的完整解决方案）。然而，并不是完全准确的 - 根据网站，RIFT.ware通过早期访问计划（EAP）在有限的时间内可用于合格的网络应用和解决方案构建者。

OSM（开源MANO）是由ETSI托管的一个项目，用于开发一个开源的NFV MANO软件堆栈，这与其提出的架构相一致。该项目首次在2016年移动世界大会上作为运营商用例展示。有趣的是，OSM同时使用了上述两个项目——OpenMANO和RIFT.io——以及OpenStack和Ubuntu JuJu（下述）。考虑到这些项目的重用，OSM得到电信公司（如Telefonica，英国电信，奥地利电信，韩国电信和Telenor）的支持，以及英特尔，Mirantis，RIFT.io，博科，戴尔，RADware等设备商的支持。

Cloudify是一个开源，云编排软件（或者说是框架）。由于Cloudify允许人们对应用程序和服务进行建模，并使其整个生命周期自动化，因此已经成功地探索将其用作MANO解决方案的一部分。Cloudify声称可以方便在任何数据中心环境中部署“应用/服务”，监控部署的应用程序的所有方面 - 例如检测问题和故障，手动或自动修复它们。与许多其他MANO解决方案一样，Cloudify也可以与OpenStack完美集成，并且它不受OpenStack（或任何特定的VIM解决方案）限制。

Canonical的Juju是开源的通用VNF管理器。但是，它更多的是服务建模系统，其中服务，相互关系和规模可以建模。这种服务导向使Juju特别适合于VNFM的作用。使用Juju提供的模型，更高级别的编排器可以做出必要的业务决策。 Juju模型服务由一组单元组成，该单元的计数定义服务的可扩展性，而单元的数量及其与心跳的关系定义服务的可用性。

此外，此单元可以位于物理机器，虚拟机或容器中。 Juju，为满足对VNF服务不可知的Ve-VNFM参考点的要求，对传递到服务的信息使用标准键值格式。最后，Juju特别擅长服务组合——多个服务组合成单个功能系统，这使其成为VNFM的良好候选者。

MANO架构框架，提供VNF的端到端解决方案。Tacker的VNFM部分可以管理VNF的基本生命周期，包括停止/启动，监视，配置和VNF的自动修复。而NFVO组件可以执行端到端网络服务部署，VNF布局控制，VNF的服务功能链接，通过VIM的管理资源分配以及跨多个VIM协调VNF

Gohan是一个由NTT开发的开源软件，提出了一个“SDN / NFV编排的服务开发引擎”。它支持使用JSON模式和策略定义和配置资源（服务定义）。使用这种JSON模式，Gohan实现了他们称为“基于模式的服务部署”，并包括基于REST的API服务器，数据库后端，命令行界面和Web用户界面。 NTT的Gohan的一个强大的用例可以在这里找到。

NFV开放平台（OPNFV）是一个协作项目，涉及服务提供商如AT＆T，中国移动，NTT DOCOMO，意大利电信和沃达丰以及IT供应商如博科，思科，戴尔，爱立信，惠普，华为，，英特尔，瞻博网络，NEC，诺基亚网络和红帽。 OPNFV最初的重点是虚拟化基础设施和相应的管理员。

号外号外，SDNLAB译者计划在火热招募中

• 优质的英文原材料，最直接的提升英语能力
• 提高社区影响力，国内极具影响力的SDN交流平台
• 最优的内容传播途径，认可才是硬道理
• 社区福利免费拿，一手的学习资料
• 分享推动SDN发展，提供国内新鲜的技术资料

什么样的人才能成为译者？
热爱分享、热爱社区；喜爱SDN等网络创新技术；

填写下面的表格吧，微信请阅读原文哦：

编译类仅出于传递更多信息之目的，系对海外相关站点最新信息的翻译稿，仅供参考，不代表证实其描述或赞同其观点，投资者据此操作，风险自担；翻译质量问题请指正。