運營商網(wǎng)絡(luò)監(jiān)控系統(tǒng)高可用性設(shè)計及應(yīng)用①

吳 舸,袁守正,孫 鼎

(中國電信上海理想信息產(chǎn)業(yè)(集團)有限公司,上海 201315)

中國電信NetCare 服務(wù),是利用中國電信統(tǒng)一建立的基于通用網(wǎng)絡(luò)監(jiān)控技術(shù)和專用探針技術(shù)的監(jiān)控平臺,對包括客戶端網(wǎng)絡(luò)設(shè)備、云端應(yīng)用及虛擬資源、專線及互聯(lián)網(wǎng)線路提供端到端監(jiān)控和管理的業(yè)務(wù),其界面如圖1、圖2所示.該業(yè)務(wù)面向中國電信政企客戶提供服務(wù),監(jiān)控了大量的客戶設(shè)備以及相關(guān)的線路資源,對于系統(tǒng)的可用性要求為99.99%.基于安全方面的考慮,企業(yè)的網(wǎng)絡(luò)監(jiān)控系統(tǒng)基本采用自建的方式,其架構(gòu)設(shè)計是以有限的監(jiān)控對象為基礎(chǔ)設(shè)計的,所以其系統(tǒng)的監(jiān)控容量是有限的[1];中國電信NetCare 服務(wù)基于電信級的安全服務(wù)構(gòu)建,以SaaS 的方式提供服務(wù),在監(jiān)控的設(shè)備數(shù)量、動態(tài)的監(jiān)控數(shù)據(jù)體量、系統(tǒng)性能、系統(tǒng)可用性方面有著更高的要求,整個系統(tǒng)采用分布式分層架構(gòu)模式,底層使用成熟的分布式數(shù)據(jù)庫系統(tǒng)、消息隊列系統(tǒng),相對于傳統(tǒng)封閉式的監(jiān)控系統(tǒng),NetCare 系統(tǒng)能夠通過底層分布式系統(tǒng)的資源的動態(tài)擴展更好地滿足業(yè)務(wù)的發(fā)展需要[2].一個系統(tǒng)的可用性是由多方面的因素共同決定的,通常會涉及硬件、網(wǎng)絡(luò)、操作系統(tǒng)、數(shù)據(jù)庫、中間件、應(yīng)用本身等[3],NetCare 系統(tǒng)的高可用性方案中一方面在硬件、網(wǎng)絡(luò)、操作系統(tǒng)、數(shù)據(jù)庫、中間件方面引進(jìn)了相應(yīng)廠商的高可用性解決方案,另一方面通過設(shè)計與實踐提升了應(yīng)用系統(tǒng)自身的高可用性.

圖1 NetCare 系統(tǒng)首頁界面

圖2 NetCare 系統(tǒng)監(jiān)控板界面

1 影響系統(tǒng)高可用性的因素分析

1.1 NetCare 系統(tǒng)邏輯架構(gòu)

如圖3,NetCare 系統(tǒng)架構(gòu)主要由數(shù)據(jù)采集子系統(tǒng)、數(shù)據(jù)處理子系統(tǒng)、業(yè)務(wù)管理子系統(tǒng)、消息隊列、數(shù)據(jù)緩存、數(shù)據(jù)存儲6 大部分組成.為了分散系統(tǒng)的采集壓力數(shù)據(jù)采集子系統(tǒng)部署多臺采集機,系統(tǒng)實測數(shù)據(jù):每臺采集機在采集頻率為10 s 的情況下可以承擔(dān)2000 臺設(shè)備的數(shù)據(jù)采集工作.數(shù)據(jù)處理子系統(tǒng)采用多臺數(shù)據(jù)處理機+數(shù)據(jù)緩存的方式提高數(shù)據(jù)歸并、計算的性能,系統(tǒng)實測數(shù)據(jù):每臺數(shù)據(jù)處理機在采集頻率為10 s 的情況下可以同時支持20 000 臺設(shè)備的采集數(shù)據(jù)的計算、歸并,并將數(shù)據(jù)寫入分布式數(shù)據(jù)庫中[4].

圖3 NetCare 系統(tǒng)邏輯架構(gòu)

1.2 應(yīng)用層高可用性影響分析

故障綜合影響級別的定義見表1.

表1 故障綜合影響級別

嚴(yán)重:嚴(yán)重故障對系統(tǒng)有著較高影響且有較高發(fā)生可能性,嚴(yán)重故障會導(dǎo)致系統(tǒng)長時間(一般以天為時間單位)的故障停機,對客戶和運營單位造成巨大損失.

高危:高優(yōu)先級別故障對系統(tǒng)有著較高影響和中等發(fā)生可能性,或中等影響和較高發(fā)生可能性.高優(yōu)先級別故障會導(dǎo)致系統(tǒng)較長時間(一般以小時為時間單位)的故障停機,對客戶和運營單位造成較大損失.

中危:中優(yōu)先級別故障對系統(tǒng)有著較高影響和較低發(fā)生可能性,或中等影響和中等發(fā)生可能性,或較低影響和較高可能性.中優(yōu)先級別故障會導(dǎo)致系統(tǒng)短時間(一般以分鐘為時間單位)的故障停機,對客戶和運營單位造成中度損失.

低危:低優(yōu)先級別故障對系統(tǒng)有著中等影響和較低發(fā)生可能性,或較低影響和中等發(fā)生可能性.低優(yōu)先級別故障會導(dǎo)致系統(tǒng)較短時間(一般以秒為時間單位)的故障停機,對客戶和運營單位造成輕微損失.

根據(jù)NetCare 系統(tǒng)架構(gòu)分析可以得到影響系統(tǒng)可用性的應(yīng)用層分析表2.表2中羅列了影響NetCare 系統(tǒng)可用性的應(yīng)用層方面的主要因素[5],細(xì)分的因素數(shù)量會更多,為了后續(xù)高可用性的設(shè)計描述更加清晰,本文對于各子系統(tǒng)架構(gòu)的風(fēng)險進(jìn)行了概括的總結(jié);對于消息隊列、數(shù)據(jù)存儲、數(shù)據(jù)緩存由于采用了成熟的開源軟件且其架構(gòu)中都具有高可用性的設(shè)計及實現(xiàn),所以故障發(fā)生的可能性定為低.

表2 影響系統(tǒng)可用性的應(yīng)用層分析表格

2 系統(tǒng)高可用性設(shè)計與實踐

2.1 網(wǎng)絡(luò)層面的高可用實踐

NetCare 系統(tǒng)使用SD-WAN 服務(wù)為客戶提供多通道高可用性技術(shù),可以在小于1 s 的時間內(nèi)切換通道,保障網(wǎng)絡(luò)的高可用性.

2.2 硬件層面的高可用實踐

NetCare 系統(tǒng)部署在采用VMWare 構(gòu)建的私有云上,通過vSphere 建立包括DRS、HA 功能的集群,HA 技術(shù)最高靈敏度可以在30 s 內(nèi)檢測到虛擬機故障,并重置虛擬機;DRS 可以將虛擬機從負(fù)載較重的主機遷移到負(fù)載較輕的主機上.

2.3 中間件、數(shù)據(jù)存儲、數(shù)據(jù)緩存的高可用實踐

NetCare 系統(tǒng)在實踐中選取了開源的ActiveMQ、MySQL、HBase、Redis 分別作為消息隊列、數(shù)據(jù)存儲、數(shù)據(jù)緩存的組件,對應(yīng)的高可用性設(shè)計也采用了開源軟件自身的高可用性方案.ActiveMQ 采用了Zookeeper+LevelDB 的部署方式.MySQL 采用了Master-Slave 的部署方式.HBase 本身為高可用的分布式數(shù)據(jù)庫.Rdeis 采用了Redis-Cluster 的部署方式.數(shù)據(jù)存儲選用了MySQL 和HBase 兩種類型的數(shù)據(jù)庫,主要是基于如下考慮:關(guān)系型數(shù)據(jù)庫用來存儲設(shè)備、客戶、服務(wù)包等基本信息,這類信息數(shù)據(jù)量較小,相對變動不大;分布式數(shù)據(jù)庫主要用來存儲采集的動態(tài)數(shù)據(jù),這類信息的數(shù)據(jù)量巨大,不適合采用關(guān)系型數(shù)據(jù)庫存儲[6].

2.4 數(shù)據(jù)采集子系統(tǒng)的高可用實踐

NetCare 系統(tǒng)的數(shù)據(jù)采集子系統(tǒng)主要用于從設(shè)備或其他API 接口采集動態(tài)的性能數(shù)據(jù)(主要包括:線路通斷、端口流量、CPU、內(nèi)存等),采集機支持的最短采集頻率為10 s/次.為了減少對采集對象的影響,每個采集對象的數(shù)據(jù)僅由一臺采集機進(jìn)行采集.

為了確保采集的高可用性,首先在線路上需要設(shè)置兩條互相備份的采集鏈路(Active-Standby 模式),當(dāng)一條鏈路不可用時,采集機通過備份的鏈路進(jìn)行數(shù)據(jù)采集.

由于單臺采集機可以采集的對象的數(shù)量是有限的,所以數(shù)據(jù)采集子系統(tǒng)中部署有多臺采集機,分散采集壓力,增強系統(tǒng)的可用性[7]:當(dāng)一臺采集機出現(xiàn)故障時,影響范圍僅限于在該采集機上進(jìn)行數(shù)據(jù)采集的設(shè)備.表3是NetCare 系統(tǒng)需要部署的采集機的數(shù)量實踐數(shù)據(jù),其中數(shù)據(jù)是在單臺采集機CPU、內(nèi)存均小于等于60%前提下的測試結(jié)果.

整個系統(tǒng)需要的采集機數(shù)量計算如下:

其中,Ceil為進(jìn)位取整函數(shù),MAX 為取最大數(shù)函數(shù);M是系統(tǒng)總的監(jiān)控設(shè)備數(shù)量;M1 為單臺采集機測試的監(jiān)控設(shè)備數(shù)量上限;F為單臺被監(jiān)控設(shè)備實際每秒上報的Netflow 的flow 數(shù)量;F1 為單臺采集機測試的每秒上報的Netflow 的flow 數(shù)量;S為單臺被監(jiān)控設(shè)備實際每秒上報的SNMP Trap 包數(shù)量;S1 為單臺采集機實際每秒上報的SNMP Trap 包數(shù)量.

表3 單臺采集機上限測試數(shù)據(jù)

系統(tǒng)對采集機的狀態(tài)進(jìn)行持續(xù)監(jiān)控,當(dāng)采集機發(fā)生故障時,可以從業(yè)務(wù)管理子系統(tǒng)將該采集機負(fù)責(zé)的設(shè)備轉(zhuǎn)移到其他采集機上;另外采集機上部署有關(guān)系型數(shù)據(jù)庫,當(dāng)消息隊列發(fā)生故障時,可以臨時存儲采集上來的數(shù)據(jù),增強了數(shù)據(jù)采集子系統(tǒng)的可用性.數(shù)據(jù)采集子系統(tǒng)的應(yīng)用層故障時間主要取決于采集機監(jiān)控頻率且重新分配設(shè)備的所屬采集機的時間.

2.5 數(shù)據(jù)處理子系統(tǒng)的高可用實踐

NetCare 系統(tǒng)的數(shù)據(jù)處理子系統(tǒng)主要從消息隊列中獲取最新的采集數(shù)據(jù),從緩存中獲取最近持久化的采集數(shù)據(jù),將兩種數(shù)據(jù)進(jìn)行歸并、計算,并持久化到數(shù)據(jù)存儲中,替換緩存中的數(shù)據(jù).多臺數(shù)據(jù)處理機采用競爭消費的方式從消息隊列中獲取數(shù)據(jù),當(dāng)一臺數(shù)據(jù)處理機故障時,其他數(shù)據(jù)處理機會分擔(dān)數(shù)據(jù)處理任務(wù).單臺數(shù)據(jù)處理機的實測的處理速率為近600 條/s,部署3 臺數(shù)據(jù)處理機,因而數(shù)據(jù)處理子系統(tǒng)的應(yīng)用層故障時間主要取決于消息隊列競爭的多消費者之間切換的時間.

2.6 業(yè)務(wù)管理子系統(tǒng)的高可用實踐

NetCare 系統(tǒng)的業(yè)務(wù)管理子系統(tǒng)主要面向客戶、運營人員提供可視化的監(jiān)控相關(guān)功能,主要是Web 服務(wù),采用兩臺Web 服務(wù)器負(fù)載均衡的方式對外提供服務(wù).

Web 應(yīng)用程序框架為自研的邊緣計算引擎[8],采用前后端分離的方式,該框架支持自動熱遷移,兩臺Web 服務(wù)器的前后端可以分別互作備份,當(dāng)一臺服務(wù)器的后端服務(wù)升級時,兩個前端服務(wù)可以共享依然活躍的后端服務(wù),可以有效減少系統(tǒng)維護的停機時間.

業(yè)務(wù)管理子系統(tǒng)應(yīng)用層故障時間主要取決于Web應(yīng)用容器的后端服務(wù)健康檢測時間.

2.7 IDC 層面的高可用實踐(異地災(zāi)備)

以上均為同地的可用性設(shè)計及實踐,為了防患于未然,需要設(shè)置異地的災(zāi)備系統(tǒng),由于資源限制,NetCare系統(tǒng)主要采用同市區(qū)不同機房的異地災(zāi)備方式,并未采用跨地域、跨電網(wǎng)、跨地震帶的方式.在發(fā)生機房故障時,故障時間主要取決于域名的切換時間[9].

3 NetCare 系統(tǒng)的可用性計算

基于以上分析,NetCare 系統(tǒng)的各層故障停機時間分析如表4.

表4 NetCare 系統(tǒng)應(yīng)用層停機時間分析表

NetCare 系統(tǒng)總的全年預(yù)估最長停機時間:

NetCare 系統(tǒng)的可用性為[10]:

以上為本地系統(tǒng)的可用性估算,異地災(zāi)備系統(tǒng)的切換取決于域名的生效時間(最長為48 小時),則考慮本地系統(tǒng)無法提供服務(wù),啟動異地系統(tǒng)的情況下,NetCare系統(tǒng)的可用性為:

4 結(jié)論與展望

影響系統(tǒng)的可用性主要由平均無故障時間和平均維修時間決定,NetCare 系統(tǒng)采用了本文描述的相關(guān)高可用性設(shè)計后,提升了系統(tǒng)的平均無故障工作時間,整個系統(tǒng)的分布式架構(gòu)減少了相關(guān)模塊的耦合度,單個模塊故障對整個系統(tǒng)的影響范圍得到了有效控制,縮短了故障的處理時間,整個系統(tǒng)可用性達(dá)到了99.9978%.影響系統(tǒng)可用性的因素比較多,系統(tǒng)建設(shè)時需要盡可能多的識別,提高系統(tǒng)的可用性同時也意味著成本的增加,所以對于所有影響因素要進(jìn)行綜合考慮,需要在系統(tǒng)可用性的實際需求、建設(shè)方的資金投入、系統(tǒng)建設(shè)周期之間找到一個切實的平衡點.