劉 寒，張 奎，趙以爽，康 凱（.中訊郵電咨詢設(shè)計(jì)院有限公司鄭州分公司，河南鄭州 450007；.中國聯(lián)合網(wǎng)絡(luò)通信集團(tuán)有限公司，北京 00033）

0 前言

隨著云計(jì)算技術(shù)不斷演進(jìn)，市場蓬勃發(fā)展，針對不同業(yè)務(wù)場景，各公司推出差異化云計(jì)算產(chǎn)品，如大數(shù)據(jù)云、行業(yè)云、通用IT 云和通信云等。各個(gè)云資源池安全穩(wěn)定運(yùn)行是業(yè)務(wù)發(fā)展的基本條件，在出現(xiàn)故障時(shí)能及時(shí)處理，在性能達(dá)到瓶頸時(shí)能及時(shí)擴(kuò)容，同時(shí)云資源池資源利用率是重要的運(yùn)營衡量標(biāo)準(zhǔn)，這些都需要云池監(jiān)控?cái)?shù)據(jù)的支撐和分析，監(jiān)控方式的差異、數(shù)據(jù)采集的效果以及對監(jiān)控?cái)?shù)據(jù)的展現(xiàn)都會影響故障處理和數(shù)據(jù)分析的效率和準(zhǔn)確性。因此，針對多業(yè)務(wù)場景云資源池的監(jiān)控?cái)?shù)據(jù)采集方式和統(tǒng)一展現(xiàn)的研究是非常重要且有意義的。

1 不同方式采集云資源數(shù)據(jù)的原理與差異

隨著云計(jì)算技術(shù)的演進(jìn)，云計(jì)算涉及的功能組件也越來越多，這些功能組件可能是不同團(tuán)隊(duì)使用不同編程語言開發(fā)實(shí)現(xiàn)的，同時(shí)云計(jì)算的分布式架構(gòu)涉及到的物理計(jì)算、網(wǎng)絡(luò)、存儲設(shè)備可能有成千上萬臺，橫跨多個(gè)不同數(shù)據(jù)中心。

隨著業(yè)務(wù)的發(fā)展，云資源池規(guī)模還在不斷擴(kuò)大，資源池上承載的業(yè)務(wù)類型和容量也在不斷地增加。業(yè)務(wù)的頻繁調(diào)整使資源池也需要頻繁調(diào)整。這就帶一系列的問題：如何判斷故障產(chǎn)生原因？如何界定故障所影響的范圍？如何分析性能使用情況？如何確定容量使用情況從而進(jìn)行后期建設(shè)規(guī)劃？

解決上述問題需要監(jiān)控?cái)?shù)據(jù)進(jìn)行支撐，目前主流監(jiān)控方式分為帶內(nèi)監(jiān)控和帶外監(jiān)控。

1.1 云資源池帶內(nèi)監(jiān)控原理

監(jiān)控?cái)?shù)據(jù)與業(yè)務(wù)數(shù)據(jù)在同一物理通道上傳輸，即為帶內(nèi)監(jiān)控。帶內(nèi)監(jiān)控是目前的主流監(jiān)控方式，分布式探針監(jiān)控系統(tǒng)則是帶內(nèi)監(jiān)控中常見的監(jiān)控系統(tǒng)，其系統(tǒng)的主要功能模塊有展示模塊、采集模塊、發(fā)送模塊、收集模塊和存儲模塊。

采集模塊將收集到的監(jiān)控信息通過發(fā)送模塊傳遞至收集模塊，收集模塊進(jìn)行存儲，最終由前端展示模塊進(jìn)行展示和查詢，流程如圖1所示。

圖1 分布式探針監(jiān)控流程圖

除上述流程外，對于帶內(nèi)監(jiān)控還有以下幾點(diǎn)基本技術(shù)要求。

a）帶內(nèi)探針系統(tǒng)的性能消耗：探針組件的影響應(yīng)當(dāng)做到足夠小，本身探針在采集監(jiān)控?cái)?shù)據(jù)時(shí)會消耗主機(jī)性能，所以需要對數(shù)據(jù)采集的方式和頻率周期進(jìn)行配置優(yōu)化，以保證業(yè)務(wù)的正常運(yùn)行。在一些高度敏感和易受環(huán)境波動影響的云計(jì)算組件或業(yè)務(wù)組件中，即使輕微損耗波動也會對系統(tǒng)造成可見影響，會迫使維護(hù)團(tuán)隊(duì)關(guān)閉或刪除探針軟件。

b）監(jiān)控的侵入性：監(jiān)控組件作為云計(jì)算組件的一部分，應(yīng)盡可能少入侵或不入侵其他組件或承載業(yè)務(wù)系統(tǒng)，同時(shí)作為業(yè)務(wù)使用方不需要知道或發(fā)現(xiàn)監(jiān)控探針的存在。

c）可擴(kuò)展性：一個(gè)完備的監(jiān)控系統(tǒng)必須支持分布式部署，具有良好的可擴(kuò)展性。

d）數(shù)據(jù)分析：數(shù)據(jù)分析系統(tǒng)必須盡快分析采集到的監(jiān)控?cái)?shù)據(jù)，并且分析的維度也要盡可能的多。監(jiān)控系統(tǒng)需要盡快反饋信息，這樣就可以對生產(chǎn)環(huán)境下的故障或異?，F(xiàn)象及時(shí)響應(yīng)。

1.2 云資源池帶外監(jiān)控原理

監(jiān)控系統(tǒng)通過單獨(dú)的物理鏈路對已使用管理接口聯(lián)網(wǎng)的物理設(shè)備采集監(jiān)控?cái)?shù)據(jù)，這種監(jiān)控方式被稱為帶外監(jiān)控，帶外監(jiān)控除了能采集到硬件設(shè)備的配置信息、部分性能信息和健康狀態(tài)外，在帶內(nèi)網(wǎng)絡(luò)故障或主機(jī)操作系統(tǒng)故障，導(dǎo)致SSH、VNC等通過帶內(nèi)方式連接無法使用時(shí)，可以通過帶外通路遠(yuǎn)程登錄帶外管理模塊，查看、控制設(shè)備狀態(tài)，處理故障等。

目前業(yè)界都是通過適配的接口協(xié)議對硬件設(shè)備進(jìn)行監(jiān)控和管理，主流的協(xié)議有IPMI 協(xié)議（Intellgent Platform Management Interface）、Redfish 協(xié)議、MCTP 協(xié)議（Management Component Transport Protocol）、帶外管理標(biāo)準(zhǔn)協(xié)議（Desktop and mobile Architecture for Sys?tem Hardware）等。

監(jiān)控系統(tǒng)通過帶外管理接口不僅可以獲得設(shè)備資產(chǎn)信息，還可以通過SNMP 接口監(jiān)聽方式對設(shè)備硬件告警進(jìn)行監(jiān)控。相較帶內(nèi)監(jiān)控方式，帶外管理接口獲取的硬件告警信息更加詳細(xì)，故障點(diǎn)更為精確。

1.3 帶內(nèi)、帶外監(jiān)控的差異

如表1 所示，帶內(nèi)、帶外監(jiān)控定位不同，帶內(nèi)監(jiān)控主要獲取操作系統(tǒng)層級以上的監(jiān)控?cái)?shù)據(jù)，而帶外監(jiān)控主要獲取資產(chǎn)信息和硬件監(jiān)控信息，因此帶內(nèi)、帶外監(jiān)控并不是二選一，而是1+1 互補(bǔ)的關(guān)系。云資源池同時(shí)具備帶內(nèi)、帶外監(jiān)控的情況下，采集到的監(jiān)控?cái)?shù)據(jù)會更加全面，故障定位會更加迅速，數(shù)據(jù)分析也更加全面。

表1 帶內(nèi)帶外監(jiān)控差異

2 不同云池場景采集方案

根據(jù)所承載業(yè)務(wù)不同，云資源分為多種產(chǎn)品，如承載IT 系統(tǒng)的IT 云、承載大數(shù)據(jù)業(yè)務(wù)的大數(shù)據(jù)云、承載網(wǎng)絡(luò)能力虛擬化的通信云等，不同類型的云也需要不同的云資源監(jiān)控方案，以下列舉2 類典型場景的監(jiān)控方式。

2.1 IT/大數(shù)據(jù)云資源監(jiān)控

目前行業(yè)內(nèi)IT 云資源池常用的監(jiān)控手段是帶內(nèi)監(jiān)控為主，帶外監(jiān)控為輔的監(jiān)控方案?，F(xiàn)在主流的帶內(nèi)監(jiān)控產(chǎn)品有很多，如zabbix、Prometheus、Span等。通過帶內(nèi)監(jiān)控對主機(jī)操作系統(tǒng)、網(wǎng)絡(luò)設(shè)備性能等進(jìn)行監(jiān)控，可以采集主機(jī)資源實(shí)時(shí)利用情況、操作系統(tǒng)健康狀態(tài)等，同時(shí)通過帶外管理接口采集硬件的資產(chǎn)信息、健康狀態(tài)以及設(shè)備的功耗、進(jìn)風(fēng)口溫度等信息，同時(shí)也可以通過端口監(jiān)聽的方式獲取設(shè)備的故障告警信息。

以Prometheus 監(jiān)控為例，如圖2 所示，Prometheus從主機(jī)上部署的2種exporter 獲取監(jiān)控?cái)?shù)據(jù)，帶內(nèi)監(jiān)控通過部署在主機(jī)操作系統(tǒng)上的Node-exporter 獲取操作系統(tǒng)數(shù)據(jù)，帶外監(jiān)控則通過IPMI-exporter 獲取帶外管理接口中的數(shù)據(jù)，另外由于Prometheus 并沒有傳遞告警信息的能力，帶外告警是IPMI接口發(fā)出硬件告警信息并推送至kafka進(jìn)行存儲轉(zhuǎn)發(fā)，帶內(nèi)告警則是由匯聚節(jié)點(diǎn)通過帶內(nèi)監(jiān)控?cái)?shù)據(jù)計(jì)算出告警并推送至kafka進(jìn)行存儲轉(zhuǎn)發(fā)。

圖2 IT云監(jiān)控架構(gòu)示意圖

2.2 通信云資源監(jiān)控

通信云即為承載運(yùn)營商網(wǎng)絡(luò)能力虛擬化（NFV）能力的云資源，由于運(yùn)營商業(yè)務(wù)的特殊性，通信業(yè)務(wù)對云資源的可靠性、可用性和安全性有著極高的要求。由于通信業(yè)務(wù)的極致可靠性要求，一般第三方監(jiān)控軟件探針的安全性和性能在未長時(shí)間全方位驗(yàn)證測試的情況下，是不允許部署在業(yè)務(wù)運(yùn)行的虛擬機(jī)和宿主機(jī)上的，因此IT云監(jiān)控方案不易套用在通信云上。

根據(jù)業(yè)務(wù)特性，通信云監(jiān)控分為小閉環(huán)和大閉環(huán)。如圖3所示，單個(gè)資源池建議采用小閉環(huán)，資源池?fù)碛卸壠脚_對自身進(jìn)行管理、監(jiān)控、故障維護(hù)處理等能力的邏輯閉環(huán)，監(jiān)控范圍涵蓋帶內(nèi)帶外所有網(wǎng)絡(luò)；多DC 多資源池建議形成大閉環(huán)，由一級平臺向小閉環(huán)的二級平臺采集資源池的監(jiān)控、告警等信息，一級平臺建設(shè)數(shù)據(jù)采集層，制定統(tǒng)一資源模型以消除不同廠家間北向上報(bào)的數(shù)據(jù)差異，各資源池間打通鏈路形成分布式的運(yùn)維能力，在上層構(gòu)建智能化的數(shù)據(jù)分析能力平臺，增強(qiáng)運(yùn)維能力，提高故障處理效率。

圖3 通信云一級監(jiān)控架構(gòu)示意圖

3 多場景多方案采集統(tǒng)一展示

為了消除不同云資源之間的差異，實(shí)現(xiàn)一點(diǎn)看全、全局監(jiān)控，運(yùn)營商需要在用戶側(cè)建設(shè)一個(gè)統(tǒng)一的云資源監(jiān)控門戶對不同類型云資源進(jìn)行匯總和分類展示，提高可視化能力，提供多種場景的運(yùn)維管理窗口，同時(shí)對不同角色的用戶設(shè)置不同的展示窗口和瀏覽范圍。

不同云資源監(jiān)控?cái)?shù)據(jù)格式不同，無法合理進(jìn)行統(tǒng)一展示，這種情況就需要制定各云資源上報(bào)數(shù)據(jù)格式的統(tǒng)一規(guī)范，對各類數(shù)據(jù)進(jìn)行規(guī)范化要求，對通用和核心關(guān)鍵指標(biāo)進(jìn)行集中展示，而對各類型業(yè)務(wù)云資源差異化的指標(biāo)則可以分不同場景窗口進(jìn)行分類展示。

4 結(jié)束語

本文通過分析云資源監(jiān)控的特點(diǎn)，總結(jié)了帶內(nèi)和帶外監(jiān)控的各自特點(diǎn)，深入研究云資源池的監(jiān)控方式，并給出2類典型業(yè)務(wù)場景的監(jiān)控方案，為不同業(yè)務(wù)云資源池監(jiān)控提供重要參考，從而有效提高云資源池運(yùn)維能力。