中國(guó)移動(dòng)通信集團(tuán)河北有限公司 潘霞
作為移動(dòng)運(yùn)營(yíng)商的核心生產(chǎn)系統(tǒng),故障管理系統(tǒng)在日常的運(yùn)維保障中起著至關(guān)的作用。故障管理系統(tǒng)主要包含三類(lèi)基礎(chǔ)數(shù)據(jù):資源、性能和告警數(shù)據(jù)。隨著LTE的建設(shè)和無(wú)線WIFI普及的拉動(dòng),移動(dòng)的網(wǎng)絡(luò)規(guī)模不斷擴(kuò)大。其資源、性能和告警數(shù)據(jù)也隨之爆炸增長(zhǎng),這給故障管理系統(tǒng)告警數(shù)據(jù)的實(shí)時(shí)處理帶來(lái)了不小的壓力。本文從告警的處理流程入手,分析其中的性能瓶頸,并結(jié)合實(shí)際情況建立起告警數(shù)據(jù)的分布式處理機(jī)制。
故障管理系統(tǒng)每天要處理大量的告警數(shù)據(jù),這些數(shù)據(jù)有以下特點(diǎn):
1、數(shù)據(jù)量大:告警數(shù)據(jù)超400萬(wàn)條/天(含設(shè)備和性能告警);
2、數(shù)據(jù)變化非線性:存在瞬時(shí)峰值超過(guò)1000條/秒情況,超過(guò)平時(shí)處理量十倍以上;
3、數(shù)據(jù)實(shí)時(shí)性高:告警數(shù)據(jù)需要實(shí)時(shí)處理并及時(shí)呈現(xiàn)在頁(yè)面上,其中設(shè)備告警時(shí)延控制在秒級(jí);
4、處理復(fù)雜度高:?jiǎn)螚l告警要經(jīng)資源填充、標(biāo)準(zhǔn)化處理、關(guān)聯(lián)分析、派單規(guī)則匹配、預(yù)處理規(guī)則匹配等多批次長(zhǎng)流程操作;
5、數(shù)據(jù)的時(shí)序性:同一條告警內(nèi)部以及同一網(wǎng)元產(chǎn)生的新告警和清除告警都需要按照順序執(zhí)行相應(yīng)的操作。
以前,告警系統(tǒng)為了滿足數(shù)據(jù)處理的實(shí)時(shí)性、時(shí)序性和復(fù)雜度高的要求,采用了單線程的處理機(jī)制。即首先把告警消息緩存到一個(gè)消息隊(duì)列中,然后通過(guò)一個(gè)單獨(dú)的線程做后續(xù)的相關(guān)操作。由于告警數(shù)據(jù)巨大,常出現(xiàn)處理不及時(shí)導(dǎo)致入庫(kù)延時(shí)、派單延時(shí)、頁(yè)面呈現(xiàn)延時(shí)等一系列問(wèn)題。
另外,這些實(shí)時(shí)處理模塊都是部署在實(shí)體機(jī)上,且單機(jī)部署單機(jī)運(yùn)行。不僅擴(kuò)展存在成本和升級(jí)困難情況,也存在程序故障或者服務(wù)器故障多方面的安全隱患。
總結(jié)起來(lái),以前的告警處理機(jī)制存在并發(fā)數(shù)受限、處理延時(shí)較大、安全性低、不易擴(kuò)展等問(wèn)題。在數(shù)據(jù)量日益增長(zhǎng)的趨勢(shì)下,已經(jīng)不能滿足故障管理系統(tǒng)的要求。
我們以告警的處理流程為例來(lái)分析問(wèn)題所在,如圖1所示:
1、從告警隊(duì)列里邊取出一條告警,通過(guò)和資源關(guān)聯(lián)把相關(guān)必要字段填充到告警對(duì)象中;
2、根據(jù)標(biāo)準(zhǔn)化規(guī)則對(duì)告警做標(biāo)準(zhǔn)化處理;
3、根據(jù)事先定義好的關(guān)聯(lián)規(guī)則對(duì)告警做關(guān)聯(lián)分析;
4、根據(jù)事先定義好的派單規(guī)則對(duì)告警做派單匹配,如果有匹配上的規(guī)則,則在對(duì)應(yīng)的時(shí)間做自動(dòng)派單;
5、根據(jù)事先定義好的智能預(yù)處理規(guī)則對(duì)告警做匹配,如果有匹配上的規(guī)則,則把告警發(fā)給預(yù)處理模塊做智能預(yù)處理;
6、告警消息發(fā)送到各應(yīng)用模塊進(jìn)行數(shù)據(jù)消費(fèi);
7、告警入庫(kù)。
由告警處理流程圖可以看出:
每條告警中的處理步驟需要按順序執(zhí)行;
根據(jù)告警數(shù)據(jù)的特點(diǎn),同一網(wǎng)元產(chǎn)生的新告警和清除告警處理順序不能錯(cuò)亂;
由于告警數(shù)據(jù)量大,告警的入庫(kù)環(huán)節(jié)采用定時(shí)批量入庫(kù)的方式;
關(guān)鍵問(wèn)題:
告警的處理環(huán)節(jié)多,過(guò)程復(fù)雜,耗時(shí)長(zhǎng)是影響告警數(shù)據(jù)準(zhǔn)確可靠的重要問(wèn)題;
告警的數(shù)據(jù)量大,且執(zhí)行順序要求較高,是影響告警處理效率的主要原因;
上述關(guān)鍵問(wèn)題的解決點(diǎn)在于在每條告警被完整有序處理的前提下盡可能地
提高并發(fā)處理的能力。
該方案的主要目標(biāo)是為了解決兩個(gè)關(guān)鍵問(wèn)題:即每條告警被完整有序的處理,以及增加并發(fā)處理能力。
告警實(shí)時(shí)數(shù)據(jù)量大是告警處理效率低下的主要原因,因此方案中必須解決對(duì)大數(shù)據(jù)的高效處理能力,否則處理過(guò)程再優(yōu)美,邏輯再嚴(yán)謹(jǐn)也無(wú)濟(jì)于事。傳統(tǒng)的解決方案是在單一服務(wù)器上通過(guò)盡可能地增加硬件配置(如cpu、內(nèi)存等)來(lái)提高實(shí)時(shí)數(shù)據(jù)的處理能力。但事實(shí)上現(xiàn)在先進(jìn)的系統(tǒng)不僅要求處理能力出眾,還必須具有可擴(kuò)展、高容錯(cuò)、高并發(fā)等特點(diǎn)。顯然單機(jī)運(yùn)行方案已經(jīng)完全不能適應(yīng)系統(tǒng)的技術(shù)要求,尤其是移動(dòng)運(yùn)營(yíng)商的核心生產(chǎn)系統(tǒng)。
圖1 告警處理流程
基于以上原因,本方案致力于尋求一種可以對(duì)實(shí)時(shí)大量數(shù)據(jù)進(jìn)行快速處理,并能夠保證數(shù)據(jù)處理順序和完整可靠的解決手段。伴隨著近幾年互聯(lián)網(wǎng)的高速發(fā)展,應(yīng)運(yùn)而生的是海量的信息數(shù)據(jù),并且已經(jīng)出現(xiàn)一些實(shí)時(shí)處理海量數(shù)據(jù)的可靠方法。這次我們選用的是較為成熟的Storm技術(shù)。一個(gè)實(shí)時(shí)的、分布式的、具備高容錯(cuò)的計(jì)算系統(tǒng),來(lái)作為告警數(shù)據(jù)實(shí)時(shí)處理的解決方案。
Storm主要特點(diǎn):
1、可以處理大批量的數(shù)據(jù);
2、在保證高可靠性(所有的信息都會(huì)被處理)的前提下讓處理進(jìn)行的更加實(shí)時(shí);
3、易于擴(kuò)展,通過(guò)新增設(shè)備來(lái)提高系統(tǒng)處理能力;
4、具備容錯(cuò)機(jī)制,如果任務(wù)執(zhí)行失敗,Storm會(huì)重新分配再次執(zhí)行。
Storm處理邏輯,業(yè)界也稱(chēng)為流式處理。圖2是基于Storm架構(gòu)的告警實(shí)時(shí)數(shù)據(jù)處理流程圖:
圖2 基于Storm的告警處理流程
在此架構(gòu)下,所有的告警處理節(jié)點(diǎn)任務(wù)可以被平均分配在不同服務(wù)器上,并受Supervisor進(jìn)程的調(diào)度和管理。系統(tǒng)會(huì)根據(jù)事先配置好的策略來(lái)分配告警數(shù)據(jù)的流向,最終穩(wěn)定高效完成所有的處理節(jié)點(diǎn)。
對(duì)于同一個(gè)處理節(jié)點(diǎn),會(huì)部署在多臺(tái)機(jī)器上,每臺(tái)機(jī)器都可以啟動(dòng)多個(gè)線程來(lái)同時(shí)處理該節(jié)點(diǎn)的任務(wù);
一條告警在經(jīng)過(guò)第n個(gè)處理節(jié)點(diǎn)后,可以設(shè)置不同的分發(fā)策略分發(fā)給第n+1個(gè)節(jié)點(diǎn);
對(duì)于無(wú)序的兩條告警(比如兩個(gè)網(wǎng)元產(chǎn)生的不同新告警),我們可以采用混排分組策略,此種策略Storm會(huì)隨機(jī)分發(fā)給能夠處理第n+1個(gè)節(jié)點(diǎn)的多個(gè)任務(wù)中的其中一個(gè),并保證每個(gè)工作節(jié)點(diǎn)可以分配到較為平均的任務(wù)數(shù);
對(duì)于有序的告警(比如同一個(gè)網(wǎng)元和新告警和清除告警,只能先處理新告警,再處理清除告警),我們可以設(shè)置按照告警的某個(gè)字段分組,比如使用告警標(biāo)識(shí)來(lái)分組,那么Storm就會(huì)對(duì)告警標(biāo)識(shí)相同的告警分配給同一個(gè)任務(wù)來(lái)處理,從而保證了執(zhí)行的順序。
對(duì)于同一告警處理節(jié)點(diǎn)的多個(gè)任務(wù),如果有其中一個(gè)或多個(gè)任務(wù)發(fā)生了故障或者異常,Storm會(huì)記錄它的執(zhí)行狀態(tài),使未處理完成的告警重新分配給其它任務(wù)來(lái)處理,并不再發(fā)送告警數(shù)據(jù)給這些故障的任務(wù)直至故障恢復(fù);
分布式的部署和執(zhí)行,保證了系統(tǒng)的可擴(kuò)展性。隨著移動(dòng)網(wǎng)絡(luò)規(guī)模的不斷擴(kuò)大,告警數(shù)據(jù)也必然會(huì)大量增加,我們可以很容易地通過(guò)新增設(shè)備的方式來(lái)提高系統(tǒng)的處理能力;
系統(tǒng)中的一個(gè)或多個(gè)工作節(jié)點(diǎn)如果發(fā)生故障,主節(jié)點(diǎn)將不會(huì)再發(fā)送告警數(shù)據(jù)給此工作節(jié)點(diǎn),其它工作節(jié)點(diǎn)可以繼續(xù)工作并分擔(dān)故障工作節(jié)點(diǎn)的任務(wù),待故障工作節(jié)點(diǎn)恢復(fù)后再接收告警數(shù)據(jù)。
使用兩臺(tái)服務(wù)器(配置均為:CPU,AMD6100 4*16;內(nèi)存,96G,硬盤(pán),2*600G)采用分布式的方式來(lái)部署故障管理系統(tǒng),這樣系統(tǒng)將會(huì)有一個(gè)主節(jié)點(diǎn)(部署在服務(wù)器A上)和兩個(gè)工作節(jié)點(diǎn)(一個(gè)部署在服務(wù)器A上,一個(gè)部署在服務(wù)器B上)組成,它們之間通過(guò)zookeeper進(jìn)行協(xié)調(diào)通信。主節(jié)點(diǎn)的后臺(tái)程序Nimbus用于響應(yīng)分布在集群中的節(jié)點(diǎn),分配任務(wù)和監(jiān)測(cè)故障;工作節(jié)點(diǎn)的后臺(tái)程序Supervisor用于收聽(tīng)工作指派并基于要求運(yùn)行工作進(jìn)程。
隨著處理數(shù)據(jù)量的增加,依賴Storm架構(gòu)的橫向擴(kuò)展能力,系統(tǒng)可靈活增加工作節(jié)點(diǎn)。實(shí)現(xiàn)當(dāng)前大數(shù)據(jù)下的靈活橫向擴(kuò)展。
本方案從告警數(shù)據(jù)的處理過(guò)程入手,分析了告警數(shù)據(jù)處理過(guò)程中的性能瓶頸以及產(chǎn)生的原因,并采用當(dāng)前相對(duì)成熟的Storm實(shí)時(shí)計(jì)算系統(tǒng),有力提升了故障管理系統(tǒng)中實(shí)時(shí)數(shù)據(jù)的處理能力。
目前,基于Storm架構(gòu)的故障管理流式處理系統(tǒng)已經(jīng)投入使用。極大提升了運(yùn)營(yíng)商對(duì)實(shí)時(shí)告警的處理和監(jiān)控能力,使得全專(zhuān)業(yè)故障管理成為可能。并且實(shí)現(xiàn)了系統(tǒng)自身負(fù)載均衡和自身監(jiān)控的能力,減輕了使用人員的勞動(dòng)強(qiáng)度,降低了系統(tǒng)故障幾率。系統(tǒng)使用一年以來(lái),創(chuàng)造了良好的經(jīng)濟(jì)效益和社會(huì)效益。
本方案中,運(yùn)營(yíng)商可以結(jié)合自身的網(wǎng)絡(luò)狀況和硬件情況,利于方案中的技術(shù)特點(diǎn)來(lái)優(yōu)化符合自身情況的實(shí)時(shí)數(shù)據(jù)處理系統(tǒng)。