TECS資源池上報(bào)網(wǎng)絡(luò)流程異常告警的問題處理

某資源池TECS上報(bào)網(wǎng)絡(luò)流程異常告警，告警單次持續(xù)15秒-4分鐘之間。

涉及UDM/PCF網(wǎng)元OMU虛機(jī)和ISBG網(wǎng)元的OMP虛機(jī)，不間斷出現(xiàn)“網(wǎng)絡(luò)流量異?！备婢?/p>

問題分析如下：

1.告警發(fā)生在多個(gè)網(wǎng)元環(huán)境，涉及不通的主機(jī)以及主機(jī)集合，以及多個(gè)業(yè)務(wù)TOR，按照問題發(fā)生的規(guī)律性排除單臺(tái)的硬件故障。

2.在線TECS版本和硬件組合已在多個(gè)站點(diǎn)使用，未發(fā)生相關(guān)情況，排除軟件版本和硬件的兼容性問題。

3.結(jié)合具體現(xiàn)場(chǎng)情況，上層業(yè)務(wù)多為測(cè)試版本，需要重點(diǎn)定位在上層業(yè)務(wù)和TECS的配合。

4.按照問題發(fā)生的嚴(yán)重度，優(yōu)先選擇告警最頻繁的網(wǎng)元虛擬機(jī)做抓包定位分析，同時(shí)結(jié)合歷史數(shù)據(jù)做規(guī)律性排查。

本次網(wǎng)絡(luò)流量異常告警涉及網(wǎng)絡(luò)虛機(jī)多，但問題原因類似，以下涉及的TECS以排查一個(gè)網(wǎng)元虛機(jī)為例。

1.通過告警詳情，TECS檢查虛機(jī)對(duì)應(yīng)端口性能統(tǒng)計(jì)，如下圖所示。



2.從告警詳情中得知虛機(jī)NFV-R-xxx-56OMP_L的vhu599f535d-1f端口在接收的21859個(gè)包中，丟了380個(gè)包，丟包率為1.7%。隨即統(tǒng)計(jì)了該虛機(jī)端口指標(biāo)，發(fā)現(xiàn)虛機(jī)端口流入有丟包，端口流出沒有丟包。

3.TECS網(wǎng)絡(luò)流量異常告警產(chǎn)生機(jī)制，如圖5所示。



a.虛擬機(jī)的每一個(gè)虛口，對(duì)應(yīng)DVS虛交換都有兩個(gè)隊(duì)列緩存，用于DVS和該虛口收發(fā)包的處理。一個(gè)收隊(duì)列（VM--->DVS方向，默認(rèn)隊(duì)列長(zhǎng)度1024），一個(gè)發(fā)隊(duì)列（DVS--->VM方向，默認(rèn)隊(duì)列長(zhǎng)度1024）。該告警是對(duì)應(yīng)DVS的發(fā)隊(duì)列，即DVS發(fā)送報(bào)文給虛擬機(jī)的方向（圖中紅線示例部分）。

b.DVS收到物理口進(jìn)來的報(bào)文后，根據(jù)相應(yīng)的轉(zhuǎn)發(fā)規(guī)則，將對(duì)應(yīng)的報(bào)文向不同的虛擬機(jī)的虛口轉(zhuǎn)發(fā)，發(fā)送的報(bào)文會(huì)進(jìn)入發(fā)送隊(duì)列。

c.DVS根據(jù)隊(duì)列的標(biāo)志位狀態(tài)決定是否產(chǎn)生中斷信號(hào)，通知虛擬機(jī)接收發(fā)送隊(duì)列的包（隊(duì)列標(biāo)志位狀態(tài)由虛擬機(jī)內(nèi)部收包進(jìn)程維護(hù)：當(dāng)虛擬機(jī)內(nèi)正在處理收包時(shí)，置標(biāo)志位狀態(tài)標(biāo)記DVS為不需要發(fā)送中斷信號(hào)通知虛擬機(jī)處理收包；當(dāng)虛擬機(jī)內(nèi)沒有處理收包時(shí)，置標(biāo)志位標(biāo)記DVS為需要立即發(fā)送中斷信號(hào)通知虛擬機(jī)處理收包）。

d.當(dāng)虛擬機(jī)沒能及時(shí)取走隊(duì)列的數(shù)據(jù)，DVS發(fā)向虛擬機(jī)虛口的報(bào)文填滿隊(duì)列時(shí)，則會(huì)出現(xiàn)隊(duì)列消息積壓，超過了隊(duì)列的長(zhǎng)度，后續(xù)多余的報(bào)文就會(huì)因?yàn)闊o法入隊(duì)列而被丟棄，丟棄的報(bào)文數(shù)統(tǒng)計(jì)在overrun中。

e.DVS每隔5秒檢測(cè)一次overrun的統(tǒng)計(jì)和本周期內(nèi)收包總數(shù)的比值，如果連續(xù)3次檢測(cè)，overrun的報(bào)文占比達(dá)到告警門限（丟包超過千分之一），就會(huì)上報(bào)告警。

f.計(jì)算節(jié)點(diǎn)上可以使用統(tǒng)計(jì)命令dvs show-dpifstats，采集所有虛擬機(jī)虛口和物理網(wǎng)口的收發(fā)包歷史統(tǒng)計(jì)信息，命令需要通過多次采集后，根據(jù)采集的結(jié)果，觀察虛口是否存在tx_overrun的統(tǒng)計(jì)增加。如果存在虛口在采集的周期內(nèi)增加現(xiàn)象，說明虛擬機(jī)處理DVS發(fā)送隊(duì)列的報(bào)文不及時(shí)（或者處理能力不足），無法及時(shí)消費(fèi)隊(duì)列的報(bào)文導(dǎo)致報(bào)文overrun。 g.DVS處理能力如下，本次問題的核心不是DVS的處理能力，而是在于業(yè)務(wù)虛擬機(jī)的處理能力。

25G網(wǎng)卡帶寬分配比例為0.24（DVS最大處理能力為12Gbps）。

10G網(wǎng)卡帶寬分配比例為0.35（DVS最大處理能力為 7Gbps）。

4.由于網(wǎng)絡(luò)流量異常告警不止一個(gè)種類的虛機(jī)，統(tǒng)計(jì)了4個(gè)月非凌晨操作時(shí)間的“網(wǎng)絡(luò)流量異?！钡臍v史告警，結(jié)果如下圖所示。



5.采集觀察每一類虛機(jī)指標(biāo)發(fā)現(xiàn)，丟包均為DVS 發(fā)送報(bào)文給虛擬機(jī)的方向。且同類型虛機(jī)都是入向到端口有丟包，可以判定是上層網(wǎng)元虛機(jī)原因，需要上層業(yè)務(wù)虛機(jī)側(cè)協(xié)助排查。

6.UDM/PCF網(wǎng)元OMU虛機(jī)：

a.現(xiàn)場(chǎng)停止OMU虛機(jī)的端到端信令跟蹤任務(wù)后，告警不再出現(xiàn)。

b.現(xiàn)網(wǎng)OMU創(chuàng)建大量端到端信令跟蹤任務(wù)，未及時(shí)進(jìn)行清理，會(huì)出現(xiàn)該現(xiàn)象，原因?yàn)椋含F(xiàn)場(chǎng)OMU 有N個(gè)SC。

c.當(dāng)前信令跟蹤任務(wù)同步機(jī)制為：每條信令跟蹤任務(wù)數(shù)據(jù)約4K記錄，需要全表同步，即每次信令跟蹤任務(wù)激活，都會(huì)把所有信令跟蹤任務(wù)數(shù)據(jù)全量同步至前臺(tái)。

d.此外，MP向SC同步數(shù)據(jù)時(shí)，要乘以SC個(gè)數(shù)，即每次要同步N*4K*300的數(shù)據(jù)。大包需要進(jìn)行分包，造成一次往前臺(tái)同步的數(shù)據(jù)量很大，造成虛機(jī)流量過大，出現(xiàn)告警。

e.TIPI是立刻重傳，只要接收方發(fā)現(xiàn)接收的消息不連續(xù)，會(huì)給發(fā)送消息方請(qǐng)求重傳，請(qǐng)求方接收到重傳請(qǐng)求，會(huì)立刻重傳。

7.ISBG網(wǎng)元的OMP虛機(jī)：

針對(duì)資源池DVS進(jìn)行抓包分析，發(fā)現(xiàn)存在瞬間大量包集中收發(fā)情況，5秒內(nèi)瞬時(shí)沖高收發(fā)27000個(gè)包，之后立即恢復(fù)正常，如下圖所示。



a.收發(fā)包峰值時(shí)刻深入分析確定，峰值收發(fā)包均由網(wǎng)元性能統(tǒng)計(jì)采集數(shù)據(jù)產(chǎn)生。

b.以日志采集為例，該時(shí)刻約產(chǎn)生27000個(gè)包，其中“SCSCF 用戶數(shù)按模塊統(tǒng)計(jì)”性能統(tǒng)計(jì)任務(wù)瞬間產(chǎn)生12596個(gè)包；“內(nèi)存庫占用按模塊統(tǒng)計(jì)”性能統(tǒng)計(jì)任務(wù)瞬間產(chǎn)生13617個(gè)包。

c.兩個(gè)性能統(tǒng)計(jì)任務(wù)瞬間合計(jì)產(chǎn)生26213個(gè)包（12596+13617=26213），說明資源池產(chǎn)生流量峰值與“SCSCF 用戶數(shù)按模塊統(tǒng)計(jì)”、“內(nèi)存庫占用按模塊統(tǒng)計(jì)”兩個(gè)性能統(tǒng)計(jì)任務(wù)有關(guān)聯(lián)。

8.S-CSCF用戶數(shù)按模塊統(tǒng)計(jì)，如下圖所示。



9.內(nèi)存庫占用按模塊統(tǒng)計(jì)，如下圖所示。



10.查看“SCSCF 用戶數(shù)按模塊統(tǒng)計(jì)”、“內(nèi)存庫占用按模塊統(tǒng)計(jì)”性能統(tǒng)計(jì)任務(wù)發(fā)現(xiàn)：

a.兩性能統(tǒng)計(jì)任務(wù)勾選全量模塊對(duì)象，實(shí)際應(yīng)用中只需勾選真實(shí)激活的SMP模塊即可（CDB、OMP以及未激活SMP模塊無需勾選），按真實(shí)應(yīng)用只需勾選47個(gè)SMP測(cè)量對(duì)象。

b.其余勾選的測(cè)量對(duì)象（CDB、OMP以及未激活SMP模塊）為無效對(duì)象，導(dǎo)致處理性能統(tǒng)計(jì)上報(bào)的網(wǎng)卡上流量突增，流量突增時(shí)會(huì)影響底層資源池產(chǎn)生瞬時(shí)流量告警。

c.性能統(tǒng)計(jì)與外部信令交互區(qū)分通道執(zhí)行，此性能統(tǒng)計(jì)流量瞬時(shí)突增不會(huì)波及VoLTE業(yè)務(wù)流程，對(duì)業(yè)務(wù)無影響。

d.此性能統(tǒng)計(jì)流量突增產(chǎn)生少量丟包情況。由于性能統(tǒng)計(jì)數(shù)據(jù)上報(bào)有重傳機(jī)制保障，不會(huì)影響性能統(tǒng)計(jì)數(shù)據(jù)整粒度采集，所以對(duì)性能統(tǒng)計(jì)數(shù)據(jù)呈現(xiàn)無影響。此外，由于流量沖高是瞬時(shí)行為，因此對(duì)網(wǎng)元自身CPU影響不大。

11.“SCSCF 用戶數(shù)按模塊統(tǒng)計(jì)”、“內(nèi)存庫占用按模塊統(tǒng)計(jì)”兩個(gè)統(tǒng)計(jì)任務(wù)勾選了大量的無效性能統(tǒng)計(jì)測(cè)量對(duì)象，導(dǎo)致性能統(tǒng)計(jì)數(shù)據(jù)采集異常，單個(gè)網(wǎng)卡流量短暫沖高，偶發(fā)性造成短時(shí)間少量丟包，導(dǎo)致底層資源池產(chǎn)生端口流量異常告警，但不會(huì)影響網(wǎng)元業(yè)務(wù)及性能統(tǒng)計(jì)。

1.通過如下方式暫時(shí)規(guī)避該問題：

a.UDM / PCF：現(xiàn)場(chǎng)測(cè)試階段，盡量控制信令跟蹤任務(wù)在30個(gè)以下，完成測(cè)試后刪除測(cè)試號(hào)碼的跟蹤任務(wù)。

b.ISBG：“SCSCF 用戶數(shù)按模塊統(tǒng)計(jì)”、“內(nèi)存庫占用按模塊統(tǒng)計(jì)”兩個(gè)統(tǒng)計(jì)任務(wù)去除測(cè)量對(duì)象勾選。

2.網(wǎng)絡(luò)流量異常告警是監(jiān)控上層網(wǎng)元運(yùn)行正常的重要告警之一，例如當(dāng)上層網(wǎng)元虛機(jī)有下電或者重啟都會(huì)產(chǎn)生網(wǎng)絡(luò)流量異常告警，可通過告警信息判斷涉及網(wǎng)元、對(duì)應(yīng)虛機(jī)及端口。

3.本次網(wǎng)絡(luò)流量異常告警主要是因?yàn)樯蠈泳W(wǎng)元有抓包或信令跟蹤導(dǎo)致，告警本身無業(yè)務(wù)影響。