DeepFlow 電信運營商5G核心網可靠性監控運維最佳實踐

　　事件回顧：加拿大Rogers大規模斷網

　　當地時間2021年4月18日，加拿大第一大移動通信網絡運營商Rogers Wireless及旗下Fido Solutions發生超大規模斷網，造成嚴重的社會影響。此次大規模斷網事件波及加拿大全國范圍及近千萬用戶、持續時間長、造成影響大，對Rogers帶了巨大的直接經濟損失和間接品牌損失，對加拿大經濟產生了重大負面影響。這也是5G網絡有史以來最大的事故。 此次事件產生的直接原因是5GC設備商軟件升級，觸發隱性軟件Bug。經過分析，該事故的深層次原因是5GC NFV化，帶來了核心網云網絡黑盒化問題，導致5GC運維技術難度高，故障定界定責定位難度高，難以發現網元故障征兆，出現故障之后難以快速確定問題界面，難以快速確定故障源。

　　015GC運維痛點

　　隨著CT與IT技術的融合以及5GC NFV化的發展，逐漸暴露出IT技術對通信網絡可靠性的影響。云計算技術可以為通信網絡帶來硬件通用化、彈性化、資源池化，業務迭代加速等好處，但原有專用設備的可靠性、易維護性在新的云架構中面臨巨大挑戰。

　　在實際的5GC運維過程中，已經暴露出系統“黑盒化”、運維技術難度高、故障定責定界難、面向業務保障難等一系列挑戰。

　　正是由于NFV化帶來的網絡可靠性問題和運維保障困難，各大運營商在現階段只能退而求其次，暫緩5GC三層解耦工作，只推進硬件層解耦，或者硬件層與虛擬層、網元層廠商綁定，由5GC廠商來確保網絡運行可靠性，但實際工作中，5GC廠商在對現網進行運維保障時面臨與運營商同樣的技術挑戰和跨技術部門協同的困境。

　　02DeepFlow云網絡流量監控運維管理平臺

　　DeepFlow是由云杉網絡開發，面向云數據中心、用于業務可靠性保障的一款云網絡流量監控運維管理平臺。

　　DeepFlow基于云原生的軟探針流量采集技術、智能流量分析技術，實現對5GC云資源池硬件層網絡接口、虛擬層網絡接口、VNF層網絡接口的全棧流量采集和分析，搭建5GC網絡智能監控分析平臺。

圖1 DeepFlow 5GC網絡監控架構

　　03方案要點

　　兼容性強：與各廠商5GC方案全兼容。

　　低資源消耗：1%的CPU資源、1%的內存資源、1‱~1%的網絡帶寬資源。

　　跨層跨域：硬件層、虛擬化層、容器層全棧流量采集和網絡性能分析，準確、客觀反映網元/網絡狀態，不依賴廠商日志。

　　秒級定位：智能分析、關聯展現任意資源點間端到端、逐跳性能指標，實現故障秒級定界、定責、定位。

　　運維場景：有效支撐丟包、時延、傳輸層異常、應用層異常、網絡風暴、信令風暴等場景的監控、運維、故障定位。

　　04使用案例

　　2020年在某電信運營商網絡云測試資源池進行了DeepFlow系統的部署，納管宿主機、虛擬機、容器POD、IP，實現對5GC的納管覆蓋和可視化監測分析。

　　通過在網絡云測試資源池的部署使用，充分證明了DeepFlow的產品能力，能夠打開5GC云資源池“網絡黑盒”，實現對所有5GC網元(VNF)不同層次、不同維度的拓撲可視化及性能指標智能分析;建立面向宿主機、虛擬機、容器、5GC網元的多維度網絡監測視圖，建立跨硬件層、虛擬層、網元層的統一可視化監控運維能力，降低各技術專業運維難度;通過跨層的可視化能力，解決了故障快速定界、定責的難題，快速定位故障源，提升解決時效;解決業務保障、網元運維、云資源運維、網絡運維的協同難題;為5GC云資源池提供針對性的安全觀測手段(信令風暴、網絡風暴、DDoS攻擊、非法IP訪問等)。

　　05故障定位案例

　　場景1：網元微服務DNS異�？焖侔l現及快速定位

　　在使用DeepFlow系統對5GC系統進行監控運維過程中，5GC網元(VNF)的監控視圖中發現PCF的“DNS異常均值”超出合理范圍。

圖2 PCF的“DNS異常均值”超出合理范圍

　　在DeepFlow系統中一鍵快速切換到PCF的容器POD視圖中，發現“cse-etcd-1”的“DNS異常均值”最高，快速鎖定故障源在網元容器POD-“cse-etcd-1”，指導網元運維人員介入處理故障。

圖3 PCF內的某個容器POD的“DNS異常均值”超出合理范圍

　　一鍵快速切換到“cse-etcd-2”的DNS日志視圖，發現“cse-etcd-2”的DNS請求被DNS服務器反饋“名字錯誤”，快速為PCF業務運維人提供了詳細DNS日志用于根因分析。

圖4 “cse-etcd-2”的異常DNS日志

　　通過以上過程可以發現，通過DeepFlow云網絡流量監控運維管理平臺，可以快速發現5GC VNF內的異常征兆，分鐘級界定出故障界面發生在5GC VNF層，分鐘級鎖定出現問題的具體位置在VNF的某個具體容器POD。

　　場景2：網元微服務TCP建連失敗量異常快速發現及快速定位

　　在使用DeepFlow系統對5GC系統進行監控運維過程中，5GC網元(VNF)的監控視圖中發現PCF的TCP建連失敗遠高于正常值(在5分鐘內累計55.45K個)。

圖5 PCF的TCP建連失敗總量異常

　　一鍵快速切換到PCF的容器POD視圖中，檢查“建連—失敗總量”排名，發現“vha-pod211-2”的容器POD異常，快速鎖定故障源在網元容器POD-“vha-pod211-2”，指導PCF網元運維人員介入處理故障。

圖6 PCF的vha-pod211-2容器POD建連失敗總量異常

　　一鍵快速切換到“vha-pod211-2”的流日志視圖，可以發現大量的“服務端直接重置”異常，快速為網元運維人提供流量日志用于根因分析。

圖7 PCF的TCP建連失敗流日志

　　通過以上過程可以發現，通過DeepFlow云網絡流量監控運維管理平臺，可以快速發現5GC VNF內的異常征兆，分鐘級界定出故障界面發生在5GC VNF層，分鐘級鎖定出現問題的具體位置在VNF的某個具體容器POD。

　　場景3：虛擬機時延異�？焖侔l現及快速定位

　　在Free5GC搭建的一套5GC環境中，使用DeepFlow云網絡流量監控運維管理平臺對5GC的全棧流量進行采集和可視化分析，通過模擬虛擬化層的故障，在虛擬機接口制造500ms的時延。

　　通過DeepFlow平臺，在5GC VNF的可視化視圖中，快速發現AMF->AUSF、AUSF->UDM鏈路出現HTTP時延峰值異常告警(圖8步驟1)。

　　通過DeepFlow平臺的全棧性能指標可視化視圖，可以一鍵快速查閱AUSF->UDM全路徑①-③、⑤-⑦接口的HTTP時延峰值、TCP建連客戶端時延峰值、TCP建連客戶端時延峰值，秒級鎖定問題位置在接口⑤與接口⑥之間，即UDM的宿主機與虛機間的接口導致時延異常(圖8步驟2)。

圖8 虛擬機時延故障定位過程注1：①AUSF容器接口;②AUSF虛機接口;③AUSF宿主機接口;⑤UDM宿主機接口;⑥UDM虛機接口;⑦UDM容器接口注2：步驟3-5表示HTTP時延、TCP建連客戶端時延、TCP建連客戶端時延的全棧指標圖形化解讀。

　　通過以上過程可以發現，通過DeepFlow云網絡流量監控運維管理平臺，可以快速發現5GC VNF內的異常征兆，分鐘級界定出故障界面發生在虛擬機層，分鐘級鎖定出現問題的具體位置在某臺虛擬機的某個虛接口。

　　聲明：登載此文出于傳遞更多信息之目的，并不意味著贊同其觀點或證實其描述。文章內容由客戶提供，僅供參考，讀者據此操作，風險自擔。