IDC網(wǎng)絡(luò)資源集中監(jiān)控方案研究

1 IDC集中監(jiān)控研究背景

近年來數(shù)據(jù)中心業(yè)務(wù)發(fā)展迅猛，IDC機(jī)樓投產(chǎn)速度也越來越快，一個(gè)IDC機(jī)樓的投產(chǎn)周期已從幾年縮短至半年。同時(shí)，為了加快機(jī)架資源的儲(chǔ)備，搶占市場(chǎng)份額，電信運(yùn)營商越來越青睞與第三方發(fā)展合作共建模式，由第三方負(fù)責(zé)數(shù)據(jù)中心基礎(chǔ)設(shè)施的建設(shè)，運(yùn)營商負(fù)責(zé)提供網(wǎng)絡(luò)出口和傳輸配套。

傳統(tǒng)數(shù)據(jù)中心通常使用DCIM等系統(tǒng)對(duì)基礎(chǔ)設(shè)施進(jìn)行集中監(jiān)控管理，往往只部署在一棟機(jī)樓或園區(qū)之內(nèi)。運(yùn)營商更關(guān)注于對(duì)網(wǎng)絡(luò)出口和資源的管控，隨著運(yùn)營商管理的數(shù)據(jù)中心日益增多，需考慮一套對(duì)多個(gè)數(shù)據(jù)中心進(jìn)行網(wǎng)絡(luò)和資源集中化管理的整體解決方案。

電信運(yùn)營商傳統(tǒng)的網(wǎng)管建設(shè)周期較長，難以滿足IDC共建機(jī)房的緊急需求，為支撐客戶業(yè)務(wù)快速上線，IDC機(jī)房的網(wǎng)絡(luò)監(jiān)控靠數(shù)據(jù)中心運(yùn)維部門自己搭建部署來實(shí)現(xiàn)，一般采用開源軟件進(jìn)行部署，結(jié)合業(yè)務(wù)部門的需求進(jìn)行二次開發(fā)來實(shí)現(xiàn)。

為此，結(jié)合筆者自身工作實(shí)踐，對(duì)IDC機(jī)房的網(wǎng)絡(luò)資源集中監(jiān)控方案進(jìn)行了研究與探索。

2 研究主要內(nèi)容

運(yùn)營商對(duì)數(shù)據(jù)中心的網(wǎng)絡(luò)集中監(jiān)控主要考慮以下方面。

（1）選取集中監(jiān)控中心。影響集中監(jiān)控中心選擇的因素有IDC機(jī)樓的業(yè)務(wù)規(guī)模、其所處的地理位置、各IDC機(jī)樓間相互的距離以及機(jī)樓附近的傳輸資源等。一般選擇業(yè)務(wù)規(guī)模較大、地理位置較好的數(shù)據(jù)中心作為集中監(jiān)控中心，各機(jī)樓的網(wǎng)絡(luò)設(shè)備的網(wǎng)管信息采集通過傳輸中繼傳送到集中監(jiān)控中心進(jìn)行統(tǒng)一管理，一般通過公網(wǎng)可以實(shí)現(xiàn)數(shù)據(jù)的采集傳送，對(duì)于安全性要求較高的組網(wǎng)，可通過網(wǎng)管網(wǎng)絡(luò)來傳輸數(shù)據(jù)。

（2）部署一套集中監(jiān)控系統(tǒng)。監(jiān)控軟件可使用Host Monitor、PRTG、CactiEZ等業(yè)界流行的監(jiān)控軟件進(jìn)行部署。在建設(shè)初期，硬件使用一般的x86服務(wù)器進(jìn)行配置即可，但隨著運(yùn)營商需要集中管理的機(jī)樓數(shù)量的增多，以及網(wǎng)絡(luò)設(shè)備數(shù)量的增加，需要關(guān)注監(jiān)控服務(wù)器的運(yùn)行性能，及時(shí)對(duì)服務(wù)器進(jìn)行升級(jí)與擴(kuò)容。

（3）設(shè)置基于用戶和業(yè)務(wù)的監(jiān)控。數(shù)據(jù)中心機(jī)房內(nèi)組網(wǎng)由多臺(tái)接入交換機(jī)，匯聚交換機(jī)或出口路由器組成，網(wǎng)絡(luò)設(shè)備端口較多，一般需要按用戶進(jìn)行端口捆綁，除一般端口告警監(jiān)控之外，還應(yīng)設(shè)置基于用戶維度的業(yè)務(wù)質(zhì)量監(jiān)控；另外，根據(jù)不同用戶級(jí)別設(shè)置不同告警分級(jí)，對(duì)于重要出口鏈路應(yīng)有告警推送，及時(shí)知會(huì)運(yùn)維主管進(jìn)行故障處理督辦。

3 具體實(shí)現(xiàn)方案

本課題在廣州公司數(shù)據(jù)中心機(jī)房開展了集中監(jiān)控部署研究，具體方案介紹如下。

3.1 IDC監(jiān)控中心選址

由于廣州公司數(shù)據(jù)中心大多集中在黃埔區(qū)科學(xué)城一帶，因此選取其中一棟標(biāo)準(zhǔn)機(jī)樓作為集中監(jiān)控中心，在該機(jī)樓部署集中監(jiān)控平臺(tái)，其余機(jī)樓的網(wǎng)絡(luò)設(shè)備數(shù)據(jù)采集通過傳輸鏈路傳送到該機(jī)房監(jiān)控平臺(tái)。如圖1所示。

圖1 集中監(jiān)控物理架構(gòu)

3.2 集中監(jiān)控系統(tǒng)部署

監(jiān)控平臺(tái)采用zabbix軟件進(jìn)行搭建。zabbix是目前業(yè)內(nèi)最流行的分布式圖形化開源監(jiān)控系統(tǒng)解決方案，它具有健全靈活的監(jiān)控?cái)?shù)據(jù)采集、存儲(chǔ)、告警規(guī)則配置以及圖形化展示界面。通過SNMP、ping，端口監(jiān)視等方法配置zabbix server服務(wù)器可以對(duì)各種遠(yuǎn)端網(wǎng)絡(luò)設(shè)備進(jìn)行數(shù)據(jù)采集和監(jiān)視。

Zabbix有3種架構(gòu)：直接連接架構(gòu)（server-client）、Node架構(gòu)（master-node-client）和proxy架構(gòu)（serverproxy-client）。本方案根據(jù)本地?cái)?shù)據(jù)中心實(shí)際生產(chǎn)環(huán)境、網(wǎng)絡(luò)結(jié)構(gòu)、監(jiān)控規(guī)模等因素，采用了直接連接架構(gòu)與proxy架構(gòu)相結(jié)合的方式，這2種架構(gòu)的區(qū)別在于：①直接連接架構(gòu)：該架構(gòu)是zabbix最簡單的架構(gòu)，監(jiān)控服務(wù)器和被監(jiān)控設(shè)備之間不經(jīng)過任何代理，直接在zabbix server（監(jiān)控服務(wù)器）和被監(jiān)控設(shè)備之間進(jìn)行數(shù)據(jù)交互，適用于網(wǎng)絡(luò)比較簡單，設(shè)備較少的監(jiān)控環(huán)境。②Proxy架構(gòu)：proxy是server、client之間溝通的一個(gè)橋梁，proxy本身沒有前端，而且其本身不存放數(shù)據(jù)，只是將被監(jiān)控設(shè)備發(fā)來的數(shù)據(jù)暫時(shí)存放，而后再提交給服務(wù)器端。該架構(gòu)一般適用于跨機(jī)房、跨網(wǎng)絡(luò)的中型網(wǎng)絡(luò)架構(gòu)的監(jiān)控。

本方案對(duì)于設(shè)備數(shù)量較少的數(shù)據(jù)中心采用直連架構(gòu)進(jìn)行部署，另外在業(yè)務(wù)量大、設(shè)備數(shù)量較多的數(shù)據(jù)中心采用proxy架構(gòu)。proxy架構(gòu)下需各部署1臺(tái)proxy服務(wù)器，用于該機(jī)樓內(nèi)網(wǎng)絡(luò)設(shè)備的信息數(shù)據(jù)采集。

本方案的直連架構(gòu)和proxy架構(gòu)共用一套服務(wù)器系統(tǒng)，在集中監(jiān)控中心進(jìn)行部署。服務(wù)器系統(tǒng)的軟件架構(gòu)為Linux+PHP+Web Service+Database，分別安裝在4臺(tái)機(jī)架式服務(wù)器上，其中1臺(tái)提供zabbix server服務(wù)，1臺(tái)提供web服務(wù)（安裝Apache服務(wù)器軟件），2臺(tái)提供數(shù)據(jù)庫服務(wù)（安裝MySQL數(shù)據(jù)庫軟件）。Zabbix server服務(wù)器通過MySQL數(shù)據(jù)庫進(jìn)行數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)讀取，通過網(wǎng)頁的方式對(duì)zabbix采集的數(shù)據(jù)和告警閥值進(jìn)行展示。數(shù)據(jù)庫服務(wù)器設(shè)置2臺(tái)是考慮了主備冗余備份，用于提高數(shù)據(jù)的可靠性，web服務(wù)器單獨(dú)設(shè)置主要是考慮接入公網(wǎng)來提高系統(tǒng)的安全性。

由于廣州IDC數(shù)據(jù)中心主要監(jiān)控網(wǎng)絡(luò)設(shè)備，所以該系統(tǒng)主要通過SNMP方式對(duì)設(shè)備數(shù)據(jù)進(jìn)行采集。廣州IDC數(shù)據(jù)中心不同機(jī)房采用了不同的SNMP團(tuán)體名，該監(jiān)控系統(tǒng)通過設(shè)置不同模板群組，來實(shí)現(xiàn)數(shù)據(jù)采集。

集中監(jiān)控系統(tǒng)的部署架構(gòu)如圖2所示，規(guī)模較小的數(shù)據(jù)中心的設(shè)備采用直連架構(gòu)進(jìn)行配置，而規(guī)模較大的數(shù)據(jù)中心的設(shè)備采用了proxy架構(gòu)。

圖2 集中監(jiān)控系統(tǒng)部署架構(gòu)

通過zabbix proxy組件的方式做到分布式部署，proxy端進(jìn)行信息數(shù)據(jù)采集，server端進(jìn)行數(shù)據(jù)的分析和告警，可以提高信息數(shù)據(jù)采集效率，降低server端的壓力。各服務(wù)均配置在Linux平臺(tái)上運(yùn)行。

3.3 監(jiān)控基本功能設(shè)置

Zabbix可以通過多種方式進(jìn)行告警呈現(xiàn)，或通過郵件、短信、微信等報(bào)警方式發(fā)送到指定人。由于郵件接收不及時(shí)甚至容易被忽視，而在大規(guī)模告警消息產(chǎn)生時(shí)，通過調(diào)用短信網(wǎng)關(guān)實(shí)現(xiàn)的短信告警方式對(duì)于消息接收者來說體驗(yàn)并不友好，越來越多運(yùn)維人員開始使用zabbix的微信告警功能作為主要的告警方式，這樣可以及時(shí)有效地把告警信息推送到接收人，方便告警的及時(shí)處理。

本方案的集中監(jiān)控告警呈現(xiàn)分為平臺(tái)告警和微信告警兩種。

（1）平臺(tái)告警，平臺(tái)告警為網(wǎng)頁訪問，分為統(tǒng)一平臺(tái)監(jiān)控告警和分支機(jī)房監(jiān)控告警。使用統(tǒng)一平臺(tái)監(jiān)控告警，所有IDC機(jī)房的警告以上的告警信息都在統(tǒng)一平臺(tái)監(jiān)控告警界面進(jìn)行展示，而分支機(jī)房監(jiān)控告警則是分支機(jī)房的告警信息在對(duì)應(yīng)機(jī)房的賬號(hào)平臺(tái)上進(jìn)行展示。分支機(jī)房的運(yùn)維人員一般只關(guān)注查看本機(jī)房內(nèi)的告警即可，集中監(jiān)控中心的監(jiān)控人員則可看到所有機(jī)房的告警，對(duì)于一些高等級(jí)告警須知會(huì)分支機(jī)房及時(shí)處理，做到對(duì)數(shù)據(jù)中心生產(chǎn)網(wǎng)監(jiān)控的雙備份，防止漏看和未及時(shí)處理故障告警。如圖3所示。

圖3 集中監(jiān)控平臺(tái)web界面

（2）微信告警。本方案啟用了微信告警功能。微信告警通過微信企業(yè)號(hào)設(shè)置不同的分組，對(duì)不同的用戶組發(fā)送不同的告警。機(jī)房現(xiàn)場(chǎng)運(yùn)維團(tuán)隊(duì)分組能夠接收對(duì)應(yīng)機(jī)房的一般告警以上的告警信息，如端口中斷等，而對(duì)于如出口線路中斷、設(shè)備宕機(jī)等嚴(yán)重告警，除機(jī)房現(xiàn)場(chǎng)運(yùn)維團(tuán)隊(duì)接收外，也需推送到運(yùn)營商IDC運(yùn)維主管進(jìn)行督辦處理。微信告警的分組設(shè)置如圖4所示。本方案申請(qǐng)了一個(gè)有發(fā)送信息接口的微信公眾號(hào)，編寫腳本調(diào)用微信的API，腳本示例如圖5所示。

圖4 微信告警平臺(tái)分組設(shè)置圖

圖5 微信告警平臺(tái)腳本模板

微信告警效果呈現(xiàn)如圖6所示。

圖6 手機(jī)微信告警效果圖

3.4 監(jiān)控功能優(yōu)化配置

3.4.1 告警分級(jí)

數(shù)據(jù)中心對(duì)不同客戶的網(wǎng)絡(luò)保障有著不同的SLA要求，尤其是重大客戶對(duì)機(jī)房網(wǎng)絡(luò)丟包、抖動(dòng)等質(zhì)量問題十分敏感，需要重點(diǎn)關(guān)注。為了提高機(jī)房故障發(fā)現(xiàn)及時(shí)率和故障處理效率，本方案對(duì)集中監(jiān)控平臺(tái)的告警做了分級(jí)設(shè)置。不同等級(jí)的故障，將會(huì)產(chǎn)生不同的告警。

Zabbix軟件既提供了模板默認(rèn)配置的的告警等級(jí)，又可根據(jù)實(shí)際需要進(jìn)行人工調(diào)整。告警等級(jí)可分為信息、警告、一般嚴(yán)重、嚴(yán)重、災(zāi)難5個(gè)等級(jí)的告警。本方案根據(jù)廣州數(shù)據(jù)中心運(yùn)維工作的實(shí)際情況，對(duì)不同程度的設(shè)備故障，網(wǎng)絡(luò)異?；驑I(yè)務(wù)質(zhì)量劣化進(jìn)行了相應(yīng)的告警分級(jí)，5個(gè)等級(jí)的告警設(shè)置說明如表1所示。

表1 告警分級(jí)定義表

3.4.2 鏈路匯聚

數(shù)據(jù)中心的運(yùn)營需要定期給運(yùn)維管理部門提交運(yùn)維報(bào)告，作為機(jī)房容量管控和網(wǎng)絡(luò)規(guī)劃的重要參考，也需要定期為業(yè)務(wù)部門提供基礎(chǔ)數(shù)據(jù)，作為客戶流量收費(fèi)以及后續(xù)業(yè)務(wù)拓展的依據(jù)，因各數(shù)據(jù)中心出口鏈路和設(shè)備端口較多，若采用人工方式導(dǎo)出zabbix端口流量報(bào)表再逐個(gè)統(tǒng)計(jì)，會(huì)增加大量的工作，也難以確保數(shù)據(jù)的準(zhǔn)確性。

通過zabbix的整合監(jiān)控項(xiàng)可以把數(shù)據(jù)中心跨設(shè)備的所需要的監(jiān)控項(xiàng)整合到一起。整合型監(jiān)控項(xiàng)是指對(duì)已經(jīng)存儲(chǔ)在數(shù)據(jù)庫中的監(jiān)控指標(biāo)數(shù)值進(jìn)行二次計(jì)算，從而形成新的監(jiān)控指標(biāo)，利用這個(gè)功能，可以很容易做到對(duì)一組或多組已有的監(jiān)控項(xiàng)數(shù)值進(jìn)行再次統(tǒng)計(jì)計(jì)算，如計(jì)算多組網(wǎng)絡(luò)設(shè)備的端口流量使用總帶寬等。

目前集中監(jiān)控平臺(tái)已對(duì)各數(shù)據(jù)中心的網(wǎng)絡(luò)出口流量進(jìn)行了整合，可通過圖形直接了解每個(gè)數(shù)據(jù)中心的出口實(shí)時(shí)總流量情況。圖7為旗銳數(shù)據(jù)中心兩臺(tái)出口路由器上的所有端口流量匯聚后的流量呈現(xiàn)圖。

圖7 數(shù)據(jù)中心出口流量匯總圖

3.4.3 95計(jì)費(fèi)

除了對(duì)網(wǎng)絡(luò)和業(yè)務(wù)質(zhì)量進(jìn)行一體化集中監(jiān)控外，業(yè)務(wù)部門對(duì)數(shù)據(jù)中心運(yùn)維部門也提出更多需求，希望從運(yùn)維部門獲取一些業(yè)務(wù)相關(guān)的信息，包括業(yè)務(wù)運(yùn)行情況、用戶投訴及處理情況等，尤其是以客戶為粒度的流量數(shù)據(jù)，是對(duì)客戶進(jìn)行計(jì)費(fèi)參考的重要依據(jù)。運(yùn)營商也需要掌握其在所有數(shù)據(jù)中心的客戶業(yè)務(wù)的使用情況，以便統(tǒng)一計(jì)費(fèi)，而目前數(shù)據(jù)中心還無法打造像運(yùn)營商傳統(tǒng)通信網(wǎng)那樣的BOSS計(jì)費(fèi)系統(tǒng)，因此利用集中監(jiān)控系統(tǒng)進(jìn)行95計(jì)費(fèi)研究十分有必要。

目前業(yè)界IDC數(shù)據(jù)中心常用的帶寬計(jì)費(fèi)方式有共享帶寬計(jì)費(fèi)、獨(dú)享帶寬計(jì)費(fèi)和95帶寬計(jì)費(fèi)。較為合理的計(jì)費(fèi)方式是95計(jì)費(fèi)。95計(jì)費(fèi)是通過把一個(gè)結(jié)算時(shí)間里的流量（通常為一個(gè)月），按每5分鐘取一個(gè)采樣，然后把結(jié)算時(shí)間里的最高采樣點(diǎn)的5%去掉，剩下的最高采樣值作為95計(jì)費(fèi)的計(jì)費(fèi)值。如果是每月計(jì)費(fèi)一次，每5分鐘取一個(gè)流量采樣，一個(gè)月按30天算一共有8 640個(gè)采樣點(diǎn)，然后把數(shù)值最高的5%的點(diǎn)去掉，剩下的最高流量就是95計(jì)費(fèi)的計(jì)費(fèi)值了。即需要計(jì)費(fèi)的點(diǎn)數(shù)是8 208個(gè)點(diǎn)，有432個(gè)點(diǎn)不用計(jì)費(fèi)，就是異常高流量的時(shí)間為36個(gè)小時(shí)，即每月不超過36小時(shí)的異常大流量不影響本月的計(jì)費(fèi)。

本方案配置的95計(jì)費(fèi)使用了zabbix系統(tǒng)進(jìn)行配置實(shí)現(xiàn)，在zabbix中有自動(dòng)發(fā)現(xiàn)的單端口95計(jì)費(fèi)和人工匯總的95計(jì)費(fèi)兩個(gè)模塊。自動(dòng)發(fā)現(xiàn)的單端口95計(jì)費(fèi)，使用了zabbix的端口發(fā)現(xiàn)規(guī)則模板，通過新建監(jiān)控項(xiàng)原型的方式把單端口的95計(jì)費(fèi)直接通過模板部署，當(dāng)有新的端口開啟后將會(huì)直接匹配該規(guī)則模板，同時(shí)自動(dòng)開啟該端口的95計(jì)費(fèi)；而人工匯總的95計(jì)費(fèi)是通過運(yùn)維人員在某個(gè)客戶的帶寬端口變化時(shí)，人工增加或刪減可計(jì)算項(xiàng)中的條目來完成計(jì)費(fèi)數(shù)據(jù)的匯總。自動(dòng)發(fā)現(xiàn)的單端口95計(jì)費(fèi)，其優(yōu)點(diǎn)是無需人工操作即可自動(dòng)完成95計(jì)費(fèi)數(shù)據(jù)采集計(jì)算，缺點(diǎn)是由于系統(tǒng)對(duì)每個(gè)端口的計(jì)費(fèi)規(guī)則都進(jìn)行了監(jiān)視，增加了系統(tǒng)的負(fù)荷，內(nèi)存等資源利用率也會(huì)有所升高。人工匯總95計(jì)費(fèi)優(yōu)點(diǎn)只是方便數(shù)據(jù)的整體導(dǎo)出計(jì)算，缺點(diǎn)為人為的操作可能會(huì)存在可計(jì)算項(xiàng)更新不及時(shí)導(dǎo)致數(shù)據(jù)不準(zhǔn)確。兩者可以互相結(jié)合，綜合考慮其優(yōu)缺點(diǎn)來分批部署使用。Zabbix配置95計(jì)費(fèi)流程如圖8所示。端口自動(dòng)配置的95計(jì)費(fèi)樣例如圖9所示。

圖8 zabbix配置95計(jì)費(fèi)流程圖

圖9 端口自動(dòng)發(fā)現(xiàn)95計(jì)費(fèi)配置樣例

4 方案實(shí)施效果

網(wǎng)絡(luò)集中監(jiān)控方案在廣州數(shù)據(jù)中心部署以來，已成功預(yù)警出口鏈路類緊急故障十余次。同時(shí)通過對(duì)告警進(jìn)行精確分級(jí)，網(wǎng)頁監(jiān)控與微信推送相結(jié)合的方式，提高了故障發(fā)現(xiàn)效率，能夠先于客戶投訴發(fā)現(xiàn)故障并及時(shí)處理，保障了客戶的感知，大大提升了客戶的滿意度。

數(shù)據(jù)中心集中化監(jiān)控方案打破了傳統(tǒng)各IDC機(jī)樓各自監(jiān)控的模式，為運(yùn)營商提供了統(tǒng)一監(jiān)控多個(gè)IDC機(jī)樓網(wǎng)絡(luò)運(yùn)行情況的有效手段，提升了管理效能。通過整合各機(jī)樓現(xiàn)場(chǎng)運(yùn)維人員實(shí)現(xiàn)了監(jiān)控人員的復(fù)用和統(tǒng)一管理，極大降低了運(yùn)維成本。

本文探索了一套對(duì)數(shù)據(jù)中心網(wǎng)絡(luò)資源進(jìn)行集中監(jiān)控管理的綜合解決方案，既借鑒了運(yùn)營商對(duì)于傳統(tǒng)通信機(jī)樓集中監(jiān)控的運(yùn)維經(jīng)驗(yàn)，又具有IT行業(yè)快速靈活部署的特點(diǎn)，是CT與IT應(yīng)用相結(jié)合、運(yùn)營商開展數(shù)字化轉(zhuǎn)型的一次實(shí)踐嘗試。在廣州、深圳、東莞等IDC機(jī)房眾多的一類地市，目前正處于大力發(fā)展合作共建機(jī)房，加快IDC機(jī)房機(jī)柜資源儲(chǔ)備的關(guān)鍵時(shí)期，推廣自建監(jiān)控系統(tǒng)的集中部署方案有利于縮短網(wǎng)絡(luò)建設(shè)周期，加速資源投放，壓縮運(yùn)維成本。運(yùn)營商也可利用其在網(wǎng)絡(luò)管理方面的豐富經(jīng)驗(yàn)，專注于數(shù)據(jù)中心網(wǎng)絡(luò)出口的容量和質(zhì)量管理，再根據(jù)實(shí)際需要在各分支機(jī)房與合建方獨(dú)立開展基礎(chǔ)設(shè)施管理，提高合建數(shù)據(jù)中心的運(yùn)營管理效率。除此之外，對(duì)于運(yùn)營商自建的數(shù)據(jù)中心來說，也可通過集中監(jiān)控模式來加大對(duì)自有機(jī)房的管理力度，確保自身網(wǎng)絡(luò)容量質(zhì)量以及資源信息使用得到更好的管控。