韓明 彭琦
摘? ?要:文章提出了一種針對業(yè)務(wù)平臺進行云化改造的研究方法,分析了系統(tǒng)現(xiàn)狀和業(yè)務(wù)需求,設(shè)計了云化改造方案,構(gòu)建了云化網(wǎng)絡(luò)結(jié)構(gòu),實現(xiàn)了短彩信業(yè)務(wù)平臺的虛擬化。目前,運營商傳統(tǒng)的短彩信業(yè)務(wù)漸漸萎縮,業(yè)務(wù)數(shù)量和利潤均明顯下降。改造之后的云化平臺能夠提高網(wǎng)絡(luò)質(zhì)量和資源利用率,降低生產(chǎn)投入和維護成本,達到了降本增效的目的。
關(guān)鍵詞:虛擬化;短彩信業(yè)務(wù);降本增效;云化平臺
隨著移動互聯(lián)網(wǎng)技術(shù)的`飛速發(fā)展,各類移動互聯(lián)網(wǎng)公司和“互聯(lián)網(wǎng)+”業(yè)務(wù)也在不斷更新,移動、聯(lián)通、電信等運營商受到了巨大的沖擊,特別是手機終端及其系統(tǒng)軟件向智能化、信息化的不斷轉(zhuǎn)變,使得運營商的短信、彩信等傳統(tǒng)業(yè)務(wù)明顯萎縮。短彩信業(yè)務(wù)忙時、閑時的負荷差距巨大,尤其在短彩信空閑時,業(yè)務(wù)平臺的資源利用率較低,出現(xiàn)一定程度的資源浪費。
隨著各大運營商整體業(yè)務(wù)的更新和發(fā)展,以及各個業(yè)務(wù)平臺虛擬化改造的不斷推進,近年來出現(xiàn)了越來越多的云化平臺。將業(yè)務(wù)平臺進行虛擬化改造,一方面,可以結(jié)合云資源池的特性對現(xiàn)有系統(tǒng)的軟件結(jié)構(gòu)進行優(yōu)化;另一方面,可以節(jié)約系統(tǒng)資源,并達到降低維護成本、實現(xiàn)節(jié)能減排的目標。
1? ? 系統(tǒng)現(xiàn)狀
根據(jù)工業(yè)和信息化部近幾年公布的統(tǒng)計結(jié)果,短彩信收發(fā)的數(shù)量在逐年下降,特別是彩信數(shù)量下降的更為明顯。下面以某公司彩信業(yè)務(wù)為例,進行虛擬云化改造的分析和研究。
1.1? 網(wǎng)絡(luò)結(jié)構(gòu)現(xiàn)狀
彩信中心業(yè)務(wù)平臺網(wǎng)絡(luò)結(jié)構(gòu)如圖1所示,一套完整的彩信中心包括2臺以上的業(yè)務(wù)處理機、數(shù)據(jù)庫服務(wù)器雙機、計費話單服務(wù)器雙機、核心交換機雙機、負載均衡器雙機、防火墻雙機(雙機均互為冗余容災(zāi))以及報表呈現(xiàn)服務(wù)器、日志查詢服務(wù)器、安全接口服務(wù)器、垃圾彩信接口服務(wù)器、客服管理服務(wù)器、操作維護服務(wù)器、備份服務(wù)器等[1]。
1.2? 系統(tǒng)結(jié)構(gòu)現(xiàn)狀
彩信中心于2008年新建了第一期工程,第一期彩信中心的系統(tǒng)處理能力為忙時平均20條/s,實現(xiàn)了彩信業(yè)務(wù)的基本功能。2008年的年底開始向天翼189用戶提供彩信服務(wù),并于2009年8月全面開通彩信業(yè)務(wù)。2010年對彩信中心的業(yè)務(wù)功能進行了升級,彩信中心的處理能力擴容至忙時平均50條/s。2011年工程改造后,彩信中心的軟件處理能力擴容至忙時平均120條/s。2012年工程改造后,彩信中心軟件處理能力再次擴容至忙時平均160條/s,同時,對系統(tǒng)軟件繼續(xù)升級,以滿足集團和本地的相關(guān)功能需求。2014年工程改造后,彩信中心滿足集團統(tǒng)一版本升級需求,并對彩信中心信息安全的相關(guān)接口和功能進行了改造。2015年工程根據(jù)集團統(tǒng)一版本升級要求,新增垃圾彩信攔截功能模塊,攔截各類垃圾彩信和違規(guī)彩信,有效凈化了網(wǎng)絡(luò)環(huán)境。目前彩信中心的處理能力為180條/s。
1.3? 平臺設(shè)備現(xiàn)狀
彩信中心系統(tǒng)平臺自從2008年建成之后,僅在2015年工程中增加了2臺ZXA1000服務(wù)器部署垃圾彩信攔截模塊,未新增其他硬件。目前,彩信平臺業(yè)務(wù)處理機為Sun Fire T2000服務(wù)器,在網(wǎng)運行時間較長,性能條件老化,服務(wù)器在系統(tǒng)忙時CPU占用率約為50%,內(nèi)存占用率約為50%,業(yè)務(wù)忙時內(nèi)存占用率接近80%,并且系統(tǒng)已占用約20%的虛擬內(nèi)存(硬盤空間),系統(tǒng)負荷較高。此外,平臺中部分型號的服務(wù)器已經(jīng)停產(chǎn),并且無法增加CPU和內(nèi)存,當(dāng)設(shè)備硬件出現(xiàn)故障之后再去采購新的硬件也比較困難。
2? ? 業(yè)務(wù)需求分析
根據(jù)虛擬化技術(shù)對現(xiàn)網(wǎng)系統(tǒng)及設(shè)備的分析研究,計劃對彩信平臺進行云化改造,具體的改造要求如下:
(1)將彩信業(yè)務(wù)平臺全部云化,包括對所有的處理機、網(wǎng)絡(luò)設(shè)備、存儲設(shè)備等全部進行云化,云化所需計算存儲和網(wǎng)絡(luò)資源均由資源池分配。
(2)在彩信業(yè)務(wù)平臺進行云化改造的過程中,彩信業(yè)務(wù)不中斷,改造之后彩信平臺的業(yè)務(wù)處理能力不低180條/s。
3? ? 云化改造部署方案
3.1? 方案相關(guān)簡介
彩信中心的擴容改造工程采用云化部署的方案,將彩信業(yè)務(wù)平臺部署在云資源池上,并將所有的處理機、網(wǎng)絡(luò)設(shè)備、存儲設(shè)備等在資源池中進行統(tǒng)一劃分。
云化改造之后系統(tǒng)的硬件容量仍為180條/s,至少需要2臺虛擬機設(shè)備。從N+1容災(zāi)的角度考慮,需要3臺4 C 32 G的虛擬機,并加載Suse Linux11 sp3操作系統(tǒng)。
3.2? 配置計算
3.2.1? 話務(wù)模型
對關(guān)鍵服務(wù)器設(shè)備進行配置時,按照平均每條彩信50 KB計算,對存儲容量和系統(tǒng)帶寬配置時也按照平均50 KB計算。
忙時彩信業(yè)務(wù)量占全天彩信業(yè)務(wù)量的比例為10%,忙天彩信業(yè)務(wù)量占全月彩信業(yè)務(wù)量的比例為5%。
彩信中心系統(tǒng)license限制容量是180條/s,計算如下:
忙時彩信業(yè)務(wù)量:180×3 600=648 000。
忙天彩信業(yè)務(wù)量:180×3 600÷10%=648 000 0。
忙月彩信業(yè)務(wù)量:180×3 600÷10%/5%=129 600 000。
3.2.2? 彩信業(yè)務(wù)存儲空間
(1)當(dāng)業(yè)務(wù)處理機采用N+1方式時,內(nèi)容存儲設(shè)備采用網(wǎng)絡(luò)附屬存儲(Network Attached Storage,NAS)架構(gòu),各個業(yè)務(wù)處理服務(wù)器共享內(nèi)容存儲設(shè)備上的彩信消息內(nèi)容。
(2)各個業(yè)務(wù)處理機的服務(wù)器與內(nèi)容存儲設(shè)備相連接,當(dāng)需要配置多套內(nèi)容存儲設(shè)備時,與各服務(wù)器的連接方式采用業(yè)務(wù)處理機服務(wù)器分組式,每組連接一個內(nèi)容存儲設(shè)備。
(3)當(dāng)有多套內(nèi)容存儲設(shè)備時,可以進行疊加使用,整體處理性能也按照線性增加。
內(nèi)容存儲采用NAS磁陣,根據(jù)工業(yè)和信息化部出臺的多媒體消息業(yè)務(wù)規(guī)范,彩信消息需要在系統(tǒng)內(nèi)有3天的存儲時間。按照平均每條彩信消息的大小50 K計算,每天10 h的忙時系數(shù),則存儲3天總計需要的磁盤空間為(考慮到30%的冗余)=3×180條/s×3 600×10%×10×50 K÷1 024÷1 024÷ 0.7=133 G
3.2.3? 用戶數(shù)據(jù)存儲
彩信數(shù)據(jù)庫存儲需要兩部分的空間,其中,Sybase數(shù)據(jù)庫需要占用一部分基本空間,用戶信息占用另外一部分數(shù)據(jù)庫空間。通常Sybase數(shù)據(jù)庫占用的基本空間大約為40 G;每用戶的開戶信息大小為4 KBytes,需要的磁盤空間=(40+4 K ×用戶數(shù)÷1 024÷1 024)÷0.7
當(dāng)用戶數(shù)為1 100萬的時候,計算出磁盤空間需求為89 G。
3.2.4? 計費話單存儲
每一條彩信消息都會產(chǎn)生1條O CDR計費話單和1條T CDR計費話單(暫不考慮投遞報告話單和響應(yīng)報告話單)。按照每條CDR計費話單長度220 Bytes計算,話單在線保存4倍忙月,取30%空間冗余[2],需要的話單空間=180條/s× 3 600÷10%÷5%×2×220×4÷0.7÷1 024÷ 1 024÷1 024
=304 G
3.2.5? 日志存儲
在日志服務(wù)器上數(shù)據(jù)的保存分為兩部分:日志文件(包括接口日志和話單日志)的保存,話單日志的入庫保存。根據(jù)規(guī)范要求,對于日志查詢功能所需要的存儲空間,要求應(yīng)滿足2個月時長的查詢需求。取30%空間冗余,保存2個月日志需=180條/s×3 600÷10%÷5%×3 K×2÷1 024÷1 024÷0.7=1 060 G
3.2.6? 報表存儲
根據(jù)規(guī)范要求,報表原始數(shù)據(jù)需要在線保存3個月,生成的所有報表數(shù)據(jù)需要在線保存24個月。
在報表呈現(xiàn)服務(wù)器上的數(shù)據(jù)主要是對來自多個數(shù)據(jù)源的數(shù)據(jù)進行統(tǒng)一處理,并將中間結(jié)果保存,空間使用情況如下。
對數(shù)據(jù)庫、各類配置數(shù)據(jù)導(dǎo)入報表服務(wù)器,大約預(yù)留50 G[2]。一條彩信業(yè)務(wù)對應(yīng)的報表原始數(shù)據(jù)大小為1 KB,每月產(chǎn)生的報表原始數(shù)據(jù)大小為:忙月彩信業(yè)務(wù)量×1 KB,報表處理的原始數(shù)據(jù)保留3個月,共需:
3.3? 局域網(wǎng)寬帶計算
3.3.1彩信中心Relay/Server業(yè)務(wù)處理機服務(wù)器帶寬計算
彩信中心系統(tǒng)內(nèi)部的各個網(wǎng)元與以太網(wǎng)交換機之間,網(wǎng)卡出口處產(chǎn)生流量最大的設(shè)備為彩信中心Relay/Server業(yè)務(wù)處理機,對于帶寬的要求如下:
在彩信的整個流程中,每臺彩信中心Relay/Server產(chǎn)生的流量大小為彩信的3倍,另外,包括日志流量(3 KB/條)、內(nèi)部信令(1 K)、外部信令(1 K)、投遞報告(2 K)、計費流量(2 K)、網(wǎng)管采集流量(2 KB/條),總計每條彩信業(yè)務(wù)需要的流量=3×50 KB+3 KB+1 KB+2 KB+1 KB+2 KB+2 KB=161 KB
彩信中心Relay/Server業(yè)務(wù)處理機端口上承受的總的帶寬流量=180條/s×161 KB×8(bit)÷70%÷1 024=323 M
3.3.2? 廣域網(wǎng)帶寬計算
廣域網(wǎng)帶寬主要需要考慮彩信中心與移動網(wǎng)增值業(yè)務(wù)經(jīng)營許可證(Service Provider,SP)之間、與彩信網(wǎng)關(guān)(Multimedia Message Service? Gateway,MMSG)之間、與ENUM DNS之間、與網(wǎng)管系統(tǒng)之間、與彩信終端之間的雙向通信,其他細小流量均可忽略不計,因此,可取以下話務(wù)模型:
(1)廣域網(wǎng)以太網(wǎng)利用率為70%。
(2)平均每條彩信的大小為50 K Byte。
(3)點對點業(yè)務(wù)比例30%,SP業(yè)務(wù)比例為70%。
(4)全網(wǎng)SP業(yè)務(wù)比例40%,本地SP業(yè)務(wù)比例60%。
(5)每條業(yè)務(wù)與 綜合業(yè)務(wù)管理平臺(Integrated Services Management Platform,ISMP),ENUM DNS之間的查詢信令流量大約2 K。
3.3.3? 彩信中心系統(tǒng)與SP之間的帶寬計算
彩信中心需要對每個接收方查詢一次ENUM DNS。其中,到ENUM DNS每次請求、應(yīng)答的雙向數(shù)據(jù)傳送為0.7 KB左右(查詢消息0.2 KB,響應(yīng)消息0.5 KB),由于彩信中心具有將ENUM DNS查詢數(shù)據(jù)本地存儲功能,因此,按照更新本地數(shù)據(jù)比例為10%計算。
(1)流入帶寬的計算。
流入帶寬=每秒提交消息中接收方總數(shù)×每次與ENUM DNS交互應(yīng)答消息大小×8×10%÷1 024÷70%
(2)流出帶寬的計算。
彩信中心需要對每個收費方查詢一次ISMP/DRM。其中,到ISMP/DRM每次請求、應(yīng)答消息大小為1 KB左右,則彩信中心與ISMP/DRM帶寬=每秒提交消息中接收方總數(shù)×每次與ISMP÷DRM交互應(yīng)答消息大小×8÷1 024÷70%
3.3.7? 彩信中心下發(fā)MM帶寬計算
投遞報告大小以2 K計算,考慮一定的冗余(假定網(wǎng)絡(luò)帶寬利用率為70%),流出防火墻的流量=180條/s×(80 K+2 K)×8÷1 024÷70%=165 Mbps
3.3.8? 廣域網(wǎng)帶寬匯總
與專網(wǎng)連接帶寬考慮70%的利用率后所需要的流入帶寬(Mb/s),考慮70%的利用率流出總帶寬(Mb/s):
4? ? 云化改造的優(yōu)點
(1)規(guī)范性:嚴格遵守集團公司相關(guān)的業(yè)務(wù)規(guī)范和技術(shù)規(guī)范的要求,由集團進行整體規(guī)劃安排和統(tǒng)一建設(shè)維護。
(2)開放性:系統(tǒng)根據(jù)開放性的原則,采用開放的接口協(xié)議和開發(fā)平臺,為用戶提供開放的業(yè)務(wù)接口;設(shè)備維護和業(yè)務(wù)發(fā)展不再依賴于設(shè)備廠商,方便添加增減模塊和實時升級系統(tǒng)[3]。
(3)成本低:相比于以前傳統(tǒng)的維護平臺,云化平臺所需的現(xiàn)網(wǎng)設(shè)備要更少,因此云化平臺無論是建設(shè)部署,還是維護使用的成本都很低,此外,云化平臺的更新周期和使用時間也都延長了,大大降低日后的改造成本。
(4)效益高:降低了短彩信業(yè)務(wù)維護對網(wǎng)絡(luò)和系統(tǒng)的消耗,提升了網(wǎng)絡(luò)效能和利用率,穩(wěn)定了系統(tǒng)的使用負荷,經(jīng)濟效益顯著。
(5)自主性:隨著業(yè)務(wù)的不斷發(fā)展,系統(tǒng)平臺的需求也越來越大,云化系統(tǒng)可以自主地增加、刪除各類模塊及其功能,方便系統(tǒng)的管理和維護。另外,雖然業(yè)務(wù)在不斷發(fā)展,但是總有部分系統(tǒng)不能完全下線,而云化系統(tǒng)中各模塊相對獨立、方便集成,可以用最小的成本與原有系統(tǒng)進行對接及維護。
(6)安全性:云化系統(tǒng)按照電信級的應(yīng)用進行設(shè)計和維護,從整體系統(tǒng)運行的安全策略和保密機制來設(shè)計系統(tǒng)的軟硬件架構(gòu),采用多種安全方法、安全技術(shù),為用戶提供完善的安全保障系統(tǒng)[4]。
5? ? 云化之后平臺網(wǎng)絡(luò)結(jié)構(gòu)
云化之后彩信中心業(yè)務(wù)平臺網(wǎng)絡(luò)結(jié)構(gòu)如圖2所示。
互聯(lián)網(wǎng)應(yīng)用范圍越來越廣泛,通信設(shè)備自身功耗增加的同時,也增加了機房空調(diào)、電源等設(shè)施的功耗,不但提高了運營商初期的網(wǎng)絡(luò)建設(shè)成本,而且提高了運營商日后的維護運營成本。將傳統(tǒng)業(yè)務(wù)平臺進行虛擬化之后,不再單獨新增硬件設(shè)備,能有效降低能耗,節(jié)省機房空間與資源,綠色環(huán)保。
此外,云化改造之后,一方面,節(jié)約了系統(tǒng)資源和運維成本;另一方面,也提升了短彩信業(yè)務(wù)的效能。通過精細化管理提高綜合業(yè)務(wù)的接入能力和維護能力,為網(wǎng)絡(luò)精確運營和市場精確營銷提供了服務(wù)與保障。
6? ? 網(wǎng)絡(luò)安全與信息安全要求
(1)有DCN網(wǎng)地址或者外網(wǎng)IP地址的系統(tǒng)應(yīng)該納入到網(wǎng)絡(luò)安全和信息安全管理中,安全管理部門提供資產(chǎn)管理、主機合規(guī)掃描、漏洞掃描、配置核查等功能模塊,要對系統(tǒng)進行定期檢查及安全評估。
(2)所有平臺及其系統(tǒng)(系統(tǒng)資源和應(yīng)用資源)的網(wǎng)絡(luò)設(shè)備配置應(yīng)滿足基線配置規(guī)范。系統(tǒng)的端口和服務(wù)等基礎(chǔ)安全信息須進行備案,對于必須的端口要對其進行應(yīng)用軟件和功能用途的登記和報備,嚴禁開放非必要端口的開放。對操作系統(tǒng)、網(wǎng)絡(luò)設(shè)備、數(shù)據(jù)庫等進行安全基線配置,包括安全審計管理、系統(tǒng)賬號管理、密碼復(fù)雜度策略、關(guān)閉危險服務(wù)等,確保系統(tǒng)配置及使用的安全性[5]。
(3)最小化服務(wù)端口管理,對于所有系統(tǒng)的網(wǎng)絡(luò)服務(wù)設(shè)置,必須遵循最小化服務(wù)原則,關(guān)閉不需要服務(wù),減小互聯(lián)網(wǎng)暴露面,對于危險端口,嚴禁對外網(wǎng)開放。對于必須開啟的網(wǎng)絡(luò)服務(wù),要通過配置策略限制遠程主機源地址。
(4)將所有業(yè)務(wù)平臺及其系統(tǒng)(系統(tǒng)資源和應(yīng)用資源)納入集中監(jiān)控系統(tǒng),及時發(fā)現(xiàn)系統(tǒng)告警及故障等。通過部署流量檢測系統(tǒng),建立異常流量的監(jiān)控及預(yù)警,防止流量攻擊。
(5)安裝專業(yè)的防病毒軟件,及時更新病毒庫,定期對系統(tǒng)做全面的病毒掃描,及時發(fā)現(xiàn)并消滅病毒。建議設(shè)置為每天自動更新病毒庫,以及每周對系統(tǒng)做全面的病毒掃描。
(6)系統(tǒng)的物理安全,系統(tǒng)線纜布放整齊合理,符合公司機房規(guī)范。各種標簽齊全,標簽內(nèi)容應(yīng)該打印,不能手寫;新建機架的配電模塊應(yīng)使用空氣開關(guān),嚴禁在集裝架內(nèi)隨意串接、復(fù)接電源插線板或設(shè)備等。
(7)雙路由雙節(jié)點,系統(tǒng)重要傳輸節(jié)點要有雙路由、雙節(jié)點備份,滿足災(zāi)難發(fā)生后數(shù)據(jù)恢復(fù)的要求,并且必須滿足可以在規(guī)定時間內(nèi)完成倒換轉(zhuǎn)接業(yè)務(wù)的要求。
(8)系統(tǒng)信息安全,網(wǎng)站接入系統(tǒng)時要嚴格落實“先備案 后接入”的管理規(guī)定,嚴禁自用、自營、合作網(wǎng)站出現(xiàn)未備案先接入或備案信息不準的現(xiàn)象。對外發(fā)布內(nèi)容時要嚴格落實“先審核 后發(fā)布”的管理規(guī)定,建立定期檢查制度,避免不良信息的產(chǎn)生。
7? ? 結(jié)語
隨著QQ、微信等各種社交軟件的不斷出現(xiàn),運營商以前傳統(tǒng)的短彩信業(yè)務(wù)漸漸萎縮,再加上國家“降本增效”“提速降費”等政策性的壓力,運營商的利潤也被不斷地壓縮,唯有減少投入、節(jié)約成本才能可持續(xù)的發(fā)展。
將傳統(tǒng)業(yè)務(wù)平臺進行虛擬化之后,既能節(jié)約系統(tǒng)的運維成本,又能提高短彩信業(yè)務(wù)的效能。創(chuàng)新了網(wǎng)絡(luò)支撐業(yè)務(wù)的思路,完善了業(yè)務(wù)系統(tǒng)平臺的框架,在提高網(wǎng)絡(luò)質(zhì)量的同時也提高了用戶的滿意度。
[參考文獻]
[1]鄧云松.海南電信中興ITV2.0平臺升級到3.0平臺部署[J].電腦知識與技術(shù),2016(15):33-36.
[2]孫旻姝.關(guān)于新建多媒體消息業(yè)務(wù)網(wǎng)關(guān)系統(tǒng)方案的研究[D].長春:吉林大學(xué),2010.
[3]陳錦娟.寬帶多媒體終端管理和業(yè)務(wù)發(fā)放平臺[D].廣州:華南理工大學(xué),2012.
[4]黃根華,鐘聲偉.分布式存儲系統(tǒng)在通信運營商云計算資源池的應(yīng)用研究[J].通訊世界,2017(16):48-49.
[5]黃筱芬.重慶銀行短信業(yè)務(wù)系統(tǒng)的設(shè)計與實現(xiàn)[D].成都:電子科技大學(xué),2014.
Abstract:In this paper, a research method for the transformation of the business platform is proposed. The present situation of the system and the business requirement are analyzed, and the cloud-based transformation scheme is designed, and the cloud-based network structure is constructed, and the virtualization of the short-message service platform is realized. At present, the traditional short multimedia message service of the operator is gradually shrinking, and the number and profit of the service are obviously reduced. After the transformation, the cloud-based platform can improve the network quality and the resource utilization ratio, reduce the production investment and the maintenance cost, and achieve the purpose of reducing the cost and increasing efficiency.
Key words:virtualization; short and multimedia message service; cost reduction and efficiency increase; cloud-based platform