吳 舸,袁守正,孫 鼎

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

中國電信NetCare 服務(wù),是利用中國電信統(tǒng)一建立的基于通用網(wǎng)絡(luò)監(jiān)控技術(shù)和專用探針技術(shù)的監(jiān)控平臺(tái),對(duì)包括客戶端網(wǎng)絡(luò)設(shè)備、云端應(yīng)用及虛擬資源、專線及互聯(lián)網(wǎng)線路提供端到端監(jiān)控和管理的業(yè)務(wù),其界面如圖1、圖2所示.該業(yè)務(wù)面向中國電信政企客戶提供服務(wù),監(jiān)控了大量的客戶設(shè)備以及相關(guān)的線路資源,對(duì)于系統(tǒng)的可用性要求為99.99%.基于安全方面的考慮,企業(yè)的網(wǎng)絡(luò)監(jiān)控系統(tǒng)基本采用自建的方式,其架構(gòu)設(shè)計(jì)是以有限的監(jiān)控對(duì)象為基礎(chǔ)設(shè)計(jì)的,所以其系統(tǒng)的監(jiān)控容量是有限的[1];中國電信NetCare 服務(wù)基于電信級(jí)的安全服務(wù)構(gòu)建,以SaaS 的方式提供服務(wù),在監(jiān)控的設(shè)備數(shù)量、動(dòng)態(tài)的監(jiān)控?cái)?shù)據(jù)體量、系統(tǒng)性能、系統(tǒng)可用性方面有著更高的要求,整個(gè)系統(tǒng)采用分布式分層架構(gòu)模式,底層使用成熟的分布式數(shù)據(jù)庫系統(tǒng)、消息隊(duì)列系統(tǒng),相對(duì)于傳統(tǒng)封閉式的監(jiān)控系統(tǒng),NetCare 系統(tǒng)能夠通過底層分布式系統(tǒng)的資源的動(dòng)態(tài)擴(kuò)展更好地滿足業(yè)務(wù)的發(fā)展需要[2].一個(gè)系統(tǒng)的可用性是由多方面的因素共同決定的,通常會(huì)涉及硬件、網(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è)計(jì)與實(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)、消息隊(duì)列、數(shù)據(jù)緩存、數(shù)據(jù)存儲(chǔ)6 大部分組成.為了分散系統(tǒng)的采集壓力數(shù)據(jù)采集子系統(tǒng)部署多臺(tái)采集機(jī),系統(tǒng)實(shí)測(cè)數(shù)據(jù):每臺(tái)采集機(jī)在采集頻率為10 s 的情況下可以承擔(dān)2000 臺(tái)設(shè)備的數(shù)據(jù)采集工作.數(shù)據(jù)處理子系統(tǒng)采用多臺(tái)數(shù)據(jù)處理機(jī)+數(shù)據(jù)緩存的方式提高數(shù)據(jù)歸并、計(jì)算的性能,系統(tǒng)實(shí)測(cè)數(shù)據(jù):每臺(tái)數(shù)據(jù)處理機(jī)在采集頻率為10 s 的情況下可以同時(shí)支持20 000 臺(tái)設(shè)備的采集數(shù)據(jù)的計(jì)算、歸并,并將數(shù)據(jù)寫入分布式數(shù)據(jù)庫中[4].

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

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

故障綜合影響級(jí)別的定義見表1.

表1 故障綜合影響級(jí)別

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

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

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

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

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

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

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

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

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

2.2 硬件層面的高可用實(shí)踐

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

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

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

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

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

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

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

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

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

表3 單臺(tái)采集機(jī)上限測(cè)試數(shù)據(jù)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4 結(jié)論與展望

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