周 博
(中國電信遼寧省分公司 網管中心,遼寧 沈陽 110168)
彩鈴平臺屬于傳統的增值業務平臺,在2G、3G、4G時代屬于雙呼業務,不參與話路接續。但是隨著Volte時代的到來,Volte彩鈴采用的是兩個業務嵌套的方式實現的。Parlay48業務負責接續被叫及呼叫雙呼彩鈴業務,parlay42是雙呼彩鈴業務負責彩鈴業務邏輯處理及媒體交互,Volte彩鈴業務流程大體如圖1所示。這使得整個彩鈴平臺的重要性增強了,彩鈴平臺的穩定運行以及某些功能模塊異常時,實現自動應急十分必要。
從運維角度看,應急的目標是短時間內恢復業務功能,減少呼損時間,保障用戶的基本通話功能不受影響。本文就彩鈴各網元設備故障時的應急方法做簡要分析,同時對數據庫異常情況下的自動應急進行分析改進,實現自動應急,進行說明。
Volte彩鈴的組網,外部信令接口為sipproxy設備和核心網s-cscf設備對接,進行sip信令交互,彩鈴媒體設備通過核心路由器與各個核心網的媒體設備進行互通,路由可達放音正常。
Volte彩鈴平臺收到用戶的呼叫請求后,會先建立話路接續,同時觸發放音流程,放音過程中彩鈴平臺內部首先進行數據庫查詢被叫的鈴音設置數據,查詢完成后SCP通知媒體服務器播放用戶設置的鈴音,媒體服務器調取鈴音文件,播放給核心網媒體設備,用戶聽到彩鈴音。正常情況下,流程可以順利完成,但是當個別網元出現異常,會對業務造成影響,下面我們針對不同網元異常及應急方法做以分析說明。
單臺SCP設備宕機屬于較為常見的應急場景,一般現網都是N+1的組網方式。當故障發生時,SIPPROXY會將呼叫分發至其它工作正常的SCP,因此僅會影響SIPPROXY已分發至故障設備上的少量呼叫。
SIPPROXY會自動檢測與所有SCP的鏈路,當SIPPROXY檢測不到某一個SCP的響應時,不會再把新的呼叫分發給這個設備。所以當單個SCP發生異常時,不需要人工干預,可以自動進入應急流程,這種情況下,用戶的彩鈴鈴音是可以正常播放的,用戶基本無感知。
一個彩鈴平臺所有SCP設備宕機不是常見的設備問題,當這種故障發生時,會影響核心網已分發至彩鈴設備的所有呼叫,新的呼叫不受影響。
SIPPROXY會自動檢測與所有SCP的鏈路,當SIPPROXY發現所有SCP宕機時,停止響應核心網發送的鏈路檢測消息。當核心網檢測不到彩鈴網元時,停止向彩鈴發送新的呼叫,后續呼叫由核心網直接接續,不經過彩鈴平臺。這種情況下,主叫用戶聽不到被叫彩鈴,但是可以聽到核心網提供正常的普通回鈴音,對用戶正常通話沒有影響。
同樣,對于彩鈴平臺SIPPROXY全部故障發生時,Sipproxy不在和SCSCF進行信令交互,這種情況下會影響核心網已分發至彩鈴平臺的呼叫。當核心網檢測不到彩鈴網元,停止向彩鈴發送新的呼叫,后續呼叫由核心網直接接續,不經過彩鈴網元,對用戶正常通話沒有影響。對于以上兩種應急情況,經過現網驗證測試,可以實現自動應急,滿足用戶正常通話使用。
圖1
圖2
圖3
圖4
數據庫異常是較為常見的應急場景,當故障發生時,會影響所有該設備上的用戶的使用,導致SCP無法查詢到用戶鈴音設置情況。由于數據庫無法及時響應SCP發起的SDF查詢請求,SCP無法通知媒體服務器播放具體的鈴音,因此也就出現用戶打電話給彩鈴用戶,聽不到被叫彩鈴音而且也聽不到普通的嘟嘟回鈴音,對用戶的感知非常不好。出現這種故障情況,平臺最開始實現的應急方法是需要人為操作-手動啟動應急流程。
由Volte彩鈴信令流程圖分析,采用parlay48引導業務提供緊急流程,緊急流程情況下不發送invite消息觸發雙呼彩鈴,只作簡單的呼叫信令透傳功能。這個時候不攜帶p-early-media頭部或者攜帶p-early-media:inactive。出現異常情況為了保障呼叫正常,需要臨時跳過彩鈴放音流程時。
具體操作方法,需要手工登錄現網的所有SCP通過執行命令啟用緊急流程(注:此處執行命令僅做示范說明,現網應急執行命令需結合現網設備確定):
ostool send 1 12345 servicekey啟用應急
ostool send 2 12346 servicekey取消應急
綜上,從我們整理了幾種Volte彩鈴常見網元故障應急流程可知,對于單個SCP故障、全部SCP故障,或者SIPPROXY雙機故障等情況,系統都能實現自動應急,對用戶正常通話基本沒有影響。但是對于DB數據庫故障的時候,按照應急方案,從網管系統檢測到數據庫異常,網管系統發送告警信息,維護人員接收告警信息,到維護人員登錄系統,通過手工干預,人為操作實現應急,是需要一定時間的,如果是業務忙時出現數據庫異常,對用戶的影響都會比較大,有需要改進的空間。
由上述手工應急方法分析可知,如果SCP查詢DB正常,系統可以正常放音,但是如果SCP查詢DB異常,則無法返回用戶的鈴音設置情況,這時SCP無法通知媒體服務器播放具體的鈴音,導致的現象就是主叫撥打被叫后,被叫振鈴,但是主叫聽不到任何鈴音(靜音狀態),如果被叫選擇接聽,話路可以正常建立。出現這種情況,給主叫的感知非常不好,可能以為電話沒有撥通。
對于數據庫異常時的手動應急方案,從應急及操作流程分析對業務是有一定影響的,為了解決這個問題,我們先從縮短故障恢復時間上,考慮引入第三方網管廠家進行數據庫雙機狀態監控,如果數據庫雙機異常(通過主備切換無法恢復數據庫業務),通過第三方網管設備進行監控發現異常后,通過授權網管賬號登錄SCP業務處理機,自動執行腳本,來實現自動“一鍵應急”。
圖5
現網的組網及具體實施方法:
◆一套SUSE 11 SP3雙機+新支點雙機+SYBASE15.03作為數據庫主機
◆4臺SUSE11 SP3單機作為SCP業務處理機
應急描述(數據庫異常)
◆ 設備信息:數據庫虛擬機雙機(雙機集群在一臺設備上執行命令即可)
◆ 系統信息:SUSE 11 SP3
◆ 狀態監控命令:cli命令行界面
◆ 輸出結果:正常狀態如圖5所示
◆ 判斷條件:
如果圖5中所示的smp133-1和smp133-2節點的狀態,其中有一個必須是running狀態為正常。當數據庫雙機異常時,主備節點的狀態都是stop或者都是unknown,沒有running狀態,可以啟動一鍵應急。
◆ 啟用應急業務:
(1)網管程序登錄SCP1-SCP4共4臺主機;
(2)使用業務賬戶登錄并啟動VOLTE彩鈴業務應急:ostool send 1 12345 servicekey啟用應急
(3)用戶聽到正常嘟嘟回鈴音,話路接續正常,應急完畢。
方案總結,通過第三方網管程序監控、實施快速應急,在數據庫雙機異常情況下可以提綱應急響應速度,減少對現網業務的影響。不過這種應急方案也存在一定的弊端,比如需要依賴第三方網管廠家配合,需要通過檢測數據庫雙機運行狀態作為數據庫運行狀態的判斷依據也不是很準確,雙機正常倒換過程中,也會存在1-2分鐘無running正常狀態的標識,可能誤觸發應急流程,這時還需要人為手工取消應急。因此該種應急方案不是最佳方案,還需要繼續優化。
我們繼續深入分析Volte彩鈴信令流程,當彩鈴數據庫異常的時候,SCP發起的SDF查詢無法查詢到結果,SCP一直處于等待狀態,無法通知媒體服務器正常播放鈴音,這時候用戶聽不到鈴音,感知不好。那么我們是否可以考慮在SCP處理放音查詢的時候增加一個查詢定時器,如果SCP查詢數據庫超時達到設定時間,比如1-2秒鐘,SCP放棄等待,直接進入放音流程,可以播放一首默認的彩鈴鈴音,這樣不會對主叫通話感知造成很大影響,也最大限度地保障通話的正常進行。這樣通過SCP的放音業務邏輯來檢測DB是否正常實現了自動應急,無論是數據庫雙機異常,還是數據庫查詢異常,都可以實現自動應急,這種方案大大優于3.1節的第三方網元的應急方案。
經過協調廠家,最終的實施方案如下:
彩鈴Volte局點當數據庫出席異常時,可以在無需人工干預的情況下實現播放保護音的應急流程,不影響放音和通話接續。
在SCP的放音業務流程parlay42中增加SDF數據庫查詢超時判定條件,設定超時定時器延時時長2s。
在SCP的放音業務流程parlay42中增加播放應急鈴音功能,比如準備yingji.wav。
通過修改Volte的parlay42放音業務的配置參數來實現數據庫異常時自動應急。
上述配置修改完成后,點擊加載,使配置生效。生效后當數據庫異常時候,會自動播放設置的保護鈴音,不會產生其他影響。
現網經過配置后,進行數據庫異常應急業務測試。手工停掉數據庫雙機,撥打測試,SCP查詢數據庫超時,定時器生效,自動播放預先配置好的yingji.wav的鈴音內容,主叫聽到彩鈴音,被叫接通,整個流程都是在沒有數據庫參與下實現的。當數據庫恢復正常之后,SCP查詢數據庫返回正常結果后,可以播放用戶設定的鈴音,無需對SCP的配置進行調整修改。經過這樣實際測試驗證1-2秒鐘的延時放音,用戶基本無感知,達到了自動應急的預期效果。
通過上面各個網元自動應急流程分析及業務實際測試后,Volte彩鈴的穩定性得到了很大提升,除了正常的雙機保護、N+1保護,同時是也實現了雙機異常時的業務自動保護,而且這些自動應急功能的實現,對后續的網絡維護提供了很大便利,比如要實現某些新功能需要停掉SCP和數據庫連接,手工升級數據庫的時候,由于SCP自動應急功能的實現,就不會出現數據庫升級期間無法放音的情況,提高了彩鈴不間斷工作運行能力。
通過對Volte彩鈴業務流程的深入分析,采取合理的應急方案,可以提升系統應急能力。隨著5G時代的到來,運維工作也需要不斷向精細化發展,提高系統運行穩定性,提高系統不間斷運行能力,是我們每個運維人需要去思考,去努力的。