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

0 引言

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

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

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

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ù)奶幚韯幼鳎ㄈ鐝椥陨炜s、更新和終止等）。

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

DCAE平臺組件包括如下：

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

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

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

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

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

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

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

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

2 DCAE工作流程

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

部署階段，控制流負(fù)責(zé)完成DCAE各平臺組件和服務(wù)組件的配置和部署工作?？刂屏鞴ぷ髁鞒倘缦拢?/p>

(1)通過Heat Template、Cloudify BluePrints或Image等方式來實例化DCAE Controller組件；

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

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

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

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

(2)VES Collector對收到的流數(shù)據(jù)經(jīng)過VES Scheme校驗、過濾和打包，確認(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)的處理動作（如Scale out，Scale in等）。

3 DCAE平臺實踐

3.1 DCAE平臺實踐方案

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

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

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

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

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

3.2 平臺實踐步驟

VES Collector和DMaaP通過Docker方式創(chuàng)建，CDAP+Hadoop通過Cloudera解決方案來構(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平臺；

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

3.3 平臺實踐結(jié)果分析

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

4 結(jié)語

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

[1]陽志明,毛斌宏.NFV MANO的關(guān)鍵問題研究與實踐.廣東通信技術(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/