开源MANO

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究竟算不算真的开放,这是令人怀疑的。

1、OpenStack困境

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

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

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

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

1.2 OASIS TOSCA及其对MANO解决方案的支持

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)可能更好地构建一些元素,或者启动开放项目来应对挑战。

2、NFV-MANO的开源软件

NFV MANO通常负责管理在云基础架构上运行的工作负载。在本节中,我们将讨论到目前可用的开源MANO解决方案。在我们讨论开源实现之前,我想为那些可能感兴趣的读者提供几个商业MANO解决方案,如下所示:

1. Alcatel-Lucent’s CloudBand Management System

2. Ericsson’s Cloud Manager

3. Nokia’s Cloud Application Manager

4. Oracle Communications’ recently announced Application Orchestrator

5. HP’s NFV Director, which spans both NFVO and VNFM realms

6. Wind River’s Carrier Grade Communications Server (extended architecture)

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

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

2.1.1 OpenMANO

OpenMANO是Telefonica发布的一个项目,由VIM(OpenVIM)、VNF管理器和Orchestrator组成,如下图所示。该图还强调了OpenMANO也可以在其架构中与OpenStack一起作为VIM。OpenVIM是NFV 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的源代码可以在这里找到。

2.1.2 RIFT.ware

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

2.1.3 Open Source MANO

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

2.1.4 Open-O

在Linux基金会下,中国移动正在推动这项计划,以开发用于NFV全球管理和自动部署的Open Orchestrator(Open O)。它专注于ETSI NFV ISG架构的VNFM(VNF Manager)和Orchestrator组件。该项目旨在与开源项目(如OPNFV,OpenStack,ODL等)兼容。该项目仍处于新兴阶段,没有太多的信息,我真诚地希望它变大!

2.2 MANO的产品化

2.2.1 Cloudify编排器

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

2.2.2 Ubuntu Juju

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

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

2.2.3 OpenStack Tacker

Tacker是OpenStack项目,专注于构建开放式NFV编排器和通用VNF管理器,以在“OpenStack管理的虚拟基础架构”中部署和运行虚拟网络功能(VNF)。它声称遵守ETSI MANO架构框架,提供VNF的端到端解决方案。Tacker的VNFM部分可以管理VNF的基本生命周期,包括停止/启动,监视,配置和VNF的自动修复。而NFVO组件可以执行端到端网络服务部署,VNF布局控制,VNF的服务功能链接,通过VIM的管理资源分配以及跨多个VIM协调VNF

2.2.4 NTT’s Gohan

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

2.2.5 基于OpenStack的OPNFV项目

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

原文发布于微信公众号 - SDNLAB(SDNLAB)

原文发表时间:2017-02-03

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Titan框架

XML是历史前进中的怪胎

人的理性是有限的,甚至拙劣的,但理性中的人却很自负。互联网本身不是被理性事先设计出来的,但是我们总是想在互联网上再次理性设计,XML和区块链都是人类理性自负地结...

830
来自专栏未闻Code

如果你不知道做什么,那就学一门杂学吧

多年以后,面对人工智能研究员那混乱不堪的代码,我会想起第一次和S君相见的那个遥远的下午。那时的B公司,还是一个仅有6个人的小团队,Mac和显示器在桌上依次排开,...

1809
来自专栏张叔叔讲互联网

【一文读懂】什么是网络爬虫,每天都在忙乎什么?

先自我介绍一下,我是一只网络爬虫,出生在计算机中,操作系统就是我的爸爸妈妈,现在都活了2000毫秒了,这个放到我们生活的世界来说,已经属于比较长寿了。我出生之后...

1942
来自专栏Java架构

程序员如何通俗易懂的给老婆解释什么是微服务?

程序员有了老婆之后就是累,上次好不容易给她解释了什么是Restful,这不,麻烦又来了…

2192
来自专栏FreeBuf

Web应用防火墙(WAF)竞品分析

* 本文原创作者:bt0sea,本文属FreeBuf原创奖励计划,未经许可禁止转载 0×00、前言 WAF(Web Application Firewall)对...

1.1K8
来自专栏BestSDK

GNU/Linux与开源文化的那些人和事

image.png 一、计算机的发明 世上本无路,走的人多了,就有了路。世上本无计算机,琢磨的人多了……没有计算机,一切无从谈起。 三个人对计算机的发明功不可没...

31010
来自专栏编程一生

架构师之路--谈架构师的基本素养和[干货]日志处理

1883
来自专栏PingCAP的专栏

TiQuery:All Diagnosis in SQL | TiDB Hackathon 优秀项目分享

“距离 Hackathon 结束已经一个多星期了,感觉心情还是没有从激情中平复过来。不过由于我读书少,这时候好像只能感慨一句,黑客马拉松真是太好玩了……”

1483
来自专栏机器人网

小型无人机飞控系统如何组成和设计?

在经历了早期的遥控飞行后,目前其导航控制方式已经发展为自主飞行和智能飞行。导航方式的改变对飞行控制计算机的精度提出了更高的要求;随着小型无人机执行任务复杂程度的...

4933
来自专栏Java架构师进阶

作为开发者犯过的两次愚蠢的错误 一定切记切记

上周我和同事们简单地聊了聊我们工作中搞砸的那些事儿。如今早已不再犯那些错了,所以想起过去就觉得很好笑。但是笑归笑,其实当时犯的这些错让我们受益颇深。

1022

扫码关注云+社区

领取腾讯云代金券