天訊瑞達(dá)通信技術(shù)有限公司 黃俊濤

0 引言

NFV(Network Function Virtualization)網(wǎng)絡(luò)功能虛擬化技術(shù)是當(dāng)前運(yùn)營(yíng)商爭(zhēng)相追捧的熱點(diǎn)技術(shù)，其目標(biāo)是將網(wǎng)元功能與廠商昂貴的專用硬件解耦，使其運(yùn)行在通用廉價(jià)的x86基礎(chǔ)設(shè)施上，降低設(shè)備采購(gòu)成本并提高網(wǎng)絡(luò)資源利用率[1]。

歐洲電信標(biāo)準(zhǔn)化協(xié)會(huì)ETSI于2012年發(fā)起組織NFV ISG(NFV Industry Specification Group)來(lái)完成了NFV管理和編排(MANO)相關(guān)標(biāo)準(zhǔn)化的制定工作。NFV MANO國(guó)際標(biāo)準(zhǔn)[2]是NFV系統(tǒng)實(shí)現(xiàn)的重要參考依據(jù)，全球NFV軟件提供商和開(kāi)源社區(qū)多采用該標(biāo)準(zhǔn)來(lái)構(gòu)建NFV分層化的平臺(tái)架構(gòu)。

ONAP(Open Network Automation Platform)[3]正是基于ETSI NFV國(guó)際標(biāo)準(zhǔn)來(lái)打造的開(kāi)源NFV系統(tǒng)。DCAE(Data Collection, Analytics, and Events)是ONAP平臺(tái)的、完整的、開(kāi)源的智慧運(yùn)營(yíng)與監(jiān)控系統(tǒng)，它以大數(shù)據(jù)技術(shù)為支撐，從數(shù)據(jù)采集、數(shù)據(jù)分析到策略控制形成一個(gè)自動(dòng)運(yùn)行的閉環(huán)，實(shí)現(xiàn)智慧化運(yùn)營(yíng)。

1 DCAE基本原理

DCAE(Data Collection, Analytics, and Events)是集數(shù)據(jù)收集（故障數(shù)據(jù)、配置數(shù)據(jù)和性能數(shù)據(jù)等）、數(shù)據(jù)分析和告警生成的系統(tǒng)，其分析結(jié)果為ONAP其它模塊（如Policy，MSO或Controllers）提供決策支持，觸發(fā)適當(dāng)?shù)奶幚韯?dòng)作（如彈性伸縮、更新和終止等）。

DCAE系統(tǒng)由平臺(tái)組件和服務(wù)組件組成，并擁有一套完善的內(nèi)部機(jī)制實(shí)現(xiàn)平臺(tái)自身的自動(dòng)化控制。平臺(tái)組件是承載DCAE服務(wù)組件的基礎(chǔ)運(yùn)行環(huán)境；服務(wù)組件是滿足特定業(yè)務(wù)需要對(duì)業(yè)務(wù)數(shù)據(jù)進(jìn)行處理的功能組件。這些不同服務(wù)組件通過(guò)DMaaP來(lái)完成數(shù)據(jù)共享和消息傳遞，DMaaP實(shí)質(zhì)是封裝了Rest接口服務(wù)的Kafka消息隊(duì)列。

DCAE平臺(tái)組件包括如下：

(1)Cloudify Manager是DCAE各組件的生命周期管理引擎，完成組件配置、部署和變更等功能；

(2)Consul是集分布式故障檢測(cè)技術(shù)、以Key-Value形式存儲(chǔ)的服務(wù)發(fā)現(xiàn)和配置技術(shù)；

(3)Service Infrastructure是DCAE平臺(tái)支持的兩種基礎(chǔ)架構(gòu)：Docker容器主機(jī)和CDAP+Hadoop平臺(tái)。前者是容器化的應(yīng)用程序；后者是基于CDAP+Hadoop集群的大數(shù)據(jù)處理平臺(tái)；

(4)Dispatcher是DCAE暴露服務(wù)的北向接口。統(tǒng)一接收上層服務(wù)請(qǐng)求，并通過(guò)Cloudify Manager調(diào)度虛擬資源的變更（部署/取消部署，更改配置等）；

(5)Inventory是DCAE資源信息庫(kù)，例如Cloudify Manager用于部署組件的各種模板和Blueprints，以及從AAI提取的DCAE虛擬網(wǎng)絡(luò)資源及其物理基礎(chǔ)設(shè)施信息；

(6)PGaaS，又稱PostgreSQL即服務(wù)，提供Inventory后端數(shù)據(jù)存儲(chǔ)能力；

(7)CDAP Broker充當(dāng)CDAP和Cloudify Manager之間的橋梁，支持Cloudify Mangager在CDAP上執(zhí)行各種操作。

DCAE服務(wù)組件是滿足特定業(yè)務(wù)需求開(kāi)發(fā)的功能組件，如用于數(shù)據(jù)收集的VES Collector、SNMP Trap Collector，用于數(shù)據(jù)分析的TCA應(yīng)用程序等。

2 DCAE工作流程

DCAE系統(tǒng)流由控制流和數(shù)據(jù)流兩部分組成，分別代表部署階段和運(yùn)行階段兩個(gè)工作流程。

部署階段，控制流負(fù)責(zé)完成DCAE各平臺(tái)組件和服務(wù)組件的配置和部署工作。控制流工作流程如下：

(1)通過(guò)Heat Template、Cloudify BluePrints或Image等方式來(lái)實(shí)例化DCAE Controller組件；

(2)DCAE Controller組件負(fù)責(zé)實(shí)例化其它DCAE組件，包括DCAE平臺(tái)組件及其承載的服務(wù)組件；

(3)DCAE Controller對(duì)實(shí)例化完畢的服務(wù)組件進(jìn)行配置，包括靜態(tài)配置或策略配置等。

運(yùn)行階段，數(shù)據(jù)流負(fù)責(zé)完成DCAE系統(tǒng)從數(shù)據(jù)收集，數(shù)據(jù)預(yù)處理，數(shù)據(jù)分析到結(jié)果輸出的一系列處理流程。數(shù)據(jù)流工作流程如下：

(1)VNF、VM通過(guò)Post接口或流形式推送流數(shù)據(jù)到VES Collector；

(2)VES Collector對(duì)收到的流數(shù)據(jù)經(jīng)過(guò)VES Scheme校驗(yàn)、過(guò)濾和打包，確認(rèn)是VES流數(shù)據(jù)后，將其發(fā)布到DMaaP模塊的Measurement Data Topic；

(3)數(shù)據(jù)分析應(yīng)用程序訂閱Measurement Data Topic，從DMaaP拉取VES流數(shù)據(jù)，并采用各種數(shù)據(jù)分析方法(TCA，Predictive analytics，AI和ML等）完成數(shù)據(jù)分析，將分析結(jié)果（即告警消息）發(fā)布到DMaaP的Event Data Topic；

(4)ONAP其它組件（如Policy，MSO）從DMaaP拉取分析結(jié)果（即告警消息），并根據(jù)預(yù)先定義的規(guī)則觸發(fā)相應(yīng)的處理動(dòng)作（如Scale out，Scale in等）。

3 DCAE平臺(tái)實(shí)踐

3.1 DCAE平臺(tái)實(shí)踐方案

DCAE DEMO由VES Collector、DMaaP和CDAP+Hadoop平臺(tái)及其TCA應(yīng)用程序組成。

(1)VES Collector是事件接收器，對(duì)接收的事件會(huì)進(jìn)行VES Scheme校驗(yàn)，校驗(yàn)通過(guò)發(fā)布到DMaaP；

(2)DMaaP是基于發(fā)布、訂閱模式的Kafka分布式消息系統(tǒng)，用于消息傳遞；

(3)CDAP平臺(tái)是Cask公司發(fā)布的開(kāi)源數(shù)據(jù)應(yīng)用平臺(tái)，構(gòu)建于CDH、Apache Ambari或Amazon EMR等大數(shù)據(jù)基礎(chǔ)平臺(tái)之上，聚焦于應(yīng)用層面，可降低大數(shù)據(jù)應(yīng)用程序的開(kāi)發(fā)復(fù)雜性；

(4)TCA（Threshold Crossing Analysis）應(yīng)用程序是基于CDAP平臺(tái)進(jìn)行開(kāi)發(fā)的數(shù)據(jù)分析應(yīng)用程序。

3.2 平臺(tái)實(shí)踐步驟

VES Collector和DMaaP通過(guò)Docker方式創(chuàng)建，CDAP+Hadoop通過(guò)Cloudera解決方案來(lái)構(gòu)建，步驟如下：

(1)安裝Docker并創(chuàng)建VES Collector容器；

(2)創(chuàng)建DMaaP應(yīng)用容器組，其中包括Zookeeper、Kafka和DMaaP容器；

(3)利用Cloudera Manager搭建Hadoop大數(shù)據(jù)服務(wù)集群，最小服務(wù)列表包括Zookeeper、Yarn、HDFS、Hive、Hbase和Spark；

(4)在Hadoop集群基礎(chǔ)上，以CSD（Custom Service Descript）形式構(gòu)建CDAP平臺(tái)；

(5)編輯配置文件信息并加載TCA應(yīng)用程序Artifacts包；(6)加載流數(shù)據(jù)驗(yàn)證結(jié)果。

3.3 平臺(tái)實(shí)踐結(jié)果分析

該平臺(tái)實(shí)踐描述了DCAE系統(tǒng)從數(shù)據(jù)收集、數(shù)據(jù)分析到產(chǎn)生告警的處理流程。VES Collector用于收集流數(shù)據(jù)并完成Scheme校驗(yàn)，校驗(yàn)通過(guò)的流數(shù)據(jù)往前傳遞到DMaaP消息隊(duì)列緩存越來(lái)。基于CDAP+Hadoop的TCA應(yīng)用程序從DMaaP拉取數(shù)據(jù)進(jìn)行數(shù)據(jù)分析，逐條檢測(cè)測(cè)量值是否超過(guò)門(mén)限值，若超過(guò)則判定為Event消息，繼續(xù)往前傳遞，然后查詢?cè)獢?shù)據(jù)信息庫(kù)并將此條Event消息進(jìn)行故障定位與關(guān)聯(lián)，最后將Event消息傳遞到DMaaP消息隊(duì)列緩存越來(lái)，數(shù)據(jù)共享給策略響應(yīng)模塊（如Policy）或外部系統(tǒng)使用。

4 結(jié)語(yǔ)

綜上所述，NFV開(kāi)源監(jiān)控系統(tǒng)——DCAE首先經(jīng)歷部署階段，完成組件的配置和部署工作，體現(xiàn)其自身自動(dòng)化控制能力；然后經(jīng)歷運(yùn)行階段，完成從數(shù)據(jù)采集、數(shù)據(jù)傳遞、數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)分析與處理以及結(jié)果輸出等一系列數(shù)據(jù)處理流程；最后將分析結(jié)果共享給策略模塊作出適當(dāng)?shù)奶幚韯?dòng)作。處理完畢后系統(tǒng)進(jìn)入新的狀態(tài)，DCAE將持續(xù)監(jiān)控系統(tǒng)狀態(tài)變化，從而形成一個(gè)循環(huán)的、有反饋的控制閉環(huán)。

[1]陽(yáng)志明,毛斌宏.NFV MANO的關(guān)鍵問(wèn)題研究與實(shí)踐.廣東通信技術(shù)[J].2016,12:21-27.

[2]ETSI GS NFV-MAN 001,“Network Functions Virtualisation(NFV);Management and Orchestration,”http://www.etsi.org/,December 2014,ETSI Industry Specification Group(ISG).

[3]ONAP Home[DB/OL].https://www.onap.org/