精品国产一级在线观看,国产成人综合久久精品亚洲,免费一级欧美大片在线观看

開源MANO軟件盤點

責任編輯:editor005

作者:崔佰貴

2016-07-19 15:27:38

摘自:SDNLAB

MANO致力于“管理和編排”,是ETSI NFV定義的架構框架的功能模塊的一部分。

本文描述了ETSI NFV MANO的概況,以及在該領域的概況。

MANO致力于“管理和編排”,是ETSI NFV定義的架構框架的功能模塊的一部分。OSM即開源MANO。

Fig 1 – ETSI NFV Architectural Framework

NFV MANO涵蓋了支持基礎設施虛擬化的物理/軟件資源的編排和生命周期管理,以及VNFs的生命周期管理。NFV管理和編排專注于NFV架構中所有的特定虛擬管理任務,主要由以下3個模塊構成:

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 005Vi-Vnfm:介于VNFM和VIM之間=> ETSI GS NFV-IFA 006Or-Vnfm:介于VNF Managers和NFVO之間=> ETSI GS NFV-IFA 007Ve-Vnfm:介于NFV-EM網絡功能和VNFM(s)之間=> ETSI GS NFV-IFA 008Os-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 descriptors

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開源的發展仍然處于非常早期的階段。

下表列舉了一些主要的通用組件及差異:

原文鏈接:http://sdn.ieee.org/newsletter/july-2016/opensource-mano

鏈接已復制,快去分享吧

企業網版權所有?2010-2024 京ICP備09108050號-6京公網安備 11010502049343號

  • <menuitem id="jw4sk"></menuitem>

    1. <form id="jw4sk"><tbody id="jw4sk"><dfn id="jw4sk"></dfn></tbody></form>
      主站蜘蛛池模板: 乡城县| 新巴尔虎右旗| 宁国市| 杂多县| 响水县| 石柱| 大名县| 武川县| 阿尔山市| 普兰店市| 蒙自县| 益阳市| 苍梧县| 来凤县| 南溪县| 永兴县| 古交市| 巴东县| 视频| 瓦房店市| 阳谷县| 宝丰县| 中牟县| 临沭县| 湘阴县| 日照市| 蚌埠市| 霍林郭勒市| 祁阳县| 延津县| 马鞍山市| 明光市| 岢岚县| 岚皋县| 绥阳县| 云安县| 西乌| 来凤县| 盐池县| 呼伦贝尔市| 西畴县|