Omdia深入解讀電信運營商云原生遷移之旅

C114訊 1月23日消息（艾斯）來自市場研究公司Omdia的最新報告寫到，對于電信業來說，采用云原生架構具有多重重要的考量因素和影響。正如下一代移動網絡聯盟（NGMN）所闡釋的，云原生并不僅僅是將工作負載容器化：它實際上改變了電信運營商的運營環境。

傳統上，電信運營商依賴網絡設備供應商來構建和部署其網絡功能。這種依賴供應商的模式使其未能充分準備好應對云原生轉型帶來的復雜性和運營挑戰。至關重要的是，電信運營商需要合適的工具來應對這些變化。

Omdia資深分析師Inderpreet Kaur在這篇文章中重點介紹了思博倫的Landslide測試套件如何簡化電信運營商的云遷移之旅。

電信網絡正向云基礎設施遷移

據Omdia估計，2024年全球電信運營商在網絡功能云化方面的支出約為157億美元。這占電信運營商網絡基礎設施設備資本支出的23%，約占移動網絡和固網行業總資本支出的5%。

Omdia預測，電信網絡云市場將從2025年的174億美元增長至2030年的248億美元，復合年增長率為7.3%。如圖1所示，Omdia預計在整個預測期內將保持中高個位數的增長。

圖1：電信網絡云市場到2030年將達到248億美元，資料來源：Omdia。

Omdia估計，電信運營商在網絡云方面的支出在2025年將增長12%，是2024年6%增長率的兩倍。電信運營商對5G核心網、IMS以及無線接入網（RAN）基礎設施現代化改造持續表現出濃厚興趣。運營商在更新現有供應商合同時，正傾向于選擇云原生部署。

云原生遷移面臨諸多挑戰

云原生與5G核心網設計原則使電信運營商能夠選擇模塊化和分解式架構，從而更好地實現網絡功能軟件與硬件平臺之間的解耦。雖然這種解耦使得水平云技術供應商（如Red Hat、SUSE、博通旗下VMware、Wind River）更容易參與進來，但也引入了新的運營挑戰。電信運營商在網絡轉型過程中必須克服諸多障礙。

·解決應用性能與可靠性問題

云原生網絡功能（CNF）必須滿足3GPP規范要求的安全、彈性及性能標準，并達到與基于專用設備的網絡功能同等的水平。與傳統設備不同，云原生部署涉及多供應商系統，其中CNF、容器即服務（CaaS）以及云基礎設施由不同供應商提供。在垂直解決方案中，網絡功能供應商負責評估應用（CNF、虛擬網絡功能/VNF）的性能與可靠性。這在多供應商系統中很難實現。

此外，CNF利用微服務架構，將網絡功能的各種功能分解并分發為獨立的微服務，每個服務通常作為一個或多個容器實現，并分組到Kubernetes Pod中。Pod是Kubernetes實現中的基本調度單元。Kubernetes將每個容器置于一個Pod中，這一Pod作為該容器的上下文，擁有其獨立的命名空間、存儲卷和配置數據。

理論上，這種微服務架構使CNF在應對故障時更具彈性，因為修復問題只需處理單個或一組受影響的服務進程/Pod，而無需重啟或調試整個應用。然而，這種優勢的代價是復雜性的增加，因為系統現在必須理解映射到多個微服務的CNF分解結構，其中包含大量交互和隱藏的依賴關系。精確定位導致性能下降的具體Pod成為一項復雜的任務。

CNF的可靠性與彈性相關，即自動修復故障Pod的能力。一個關鍵挑戰在于確保每個CNF的設計和構建都能提供所需的彈性。目前，并非所有CNF都基于云原生原則設計；許多仍是單體式架構，只是將相同的VNF代碼封裝在容器包裝器中而非虛擬機中交付。因此，運營商根據這些要求評估CNF的就緒度變得至關重要。

·確保云資源高效利用

分析師Inderpreet Kaur指出，對于部署云原生網絡的電信運營商而言，云資源（計算、存儲和網絡）利用率低下是一個關鍵挑戰。造成這種情況的原因有多個方面。隨著網絡功能從物理網絡功能（PNF）遷移至VNF和CNF，供應商仍傾向于按峰值容量配置硬件基礎設施。即使對于水平云架構，運營商也會為不同的CNF設置獨立或隔離的環境，并為這些環境預留峰值容量資源。這種架構雖然更容易實現，但會導致計算、存儲和內存資源利用率嚴重不足。

英國老牌運營商英國電信（BT）在接受Omdia采訪時承認，其水平基礎設施即服務基礎設施（IaaS）仍存在這個問題。BT解釋說，CaaS與CNF的緊密捆綁使其無法對基礎設施資源進行精細化控制。此外還存在一些其他問題。BT表示，很多時候，CNF供應商會對底層云基礎設施提出特定要求，以確保應用彈性。供應商還會設置Pod的親和性與反親和性要求，這限制了可調度特定Pod的節點。

·使組織結構適應運營模式

正如德國電信（DT）向Omdia所解釋的那樣，從垂直孤島向水平層級轉變伴隨著其團隊的重組。該運營商為基礎設施、自動化及工作負載設立了獨立的團隊，并輔以敏捷規劃周期。運營團隊負責設計、構建和維護云基礎設施。該團隊將云資源作為租戶工作負載提供給應用所有者，應用所有者則負責CNF和VNF的生命周期管理。

為了實施精益運營，DT建立了統一的自動化框架。DT部署了一個通用的CI/CD流水線，以簡化云基礎設施與應用所有者之間的工作流程。它利用DevOps框架，并結合持續測試和驗證，來實現其云原生網絡的部署和升級。

此外，將各種組件整合到云堆棧中的所有權也發生了變化。在DT的案例中，運營商承擔了這項責任。對于許多小型網絡運營商而言，這是一個關鍵的制約因素。他們通常缺乏支持此類轉型所需的技能、組織結構、思維方式、工具和人力資源。

思博倫如何應對云原生網絡測試挑戰

網絡功能與底層云基礎設施的解耦帶來了額外的挑戰，需要驗證CNF在云基礎設施上的合規性、安全性及性能。思博倫Landslide平臺通過其5G CNF彈性驗證和云原生基礎設施基準測試套件，簡化了運營商的云原生部署。

思博倫（現為是德科技Keysight旗下公司）最近擴展了Landslide平臺的能力，以提供全面的云原生基礎設施基準測試。這些框架有助于確保CNF在運營商現網中交付所需的關鍵績效指標（KPI）。

如圖2所示，彈性框架旨在提高應用的性能和可靠性。它幫助電信運營商評估CNF是否具有彈性設計——在實時環境中是否能夠自我修復和自動擴展。運營商可在以下場景中運行CNF彈性測試用例：

·對象故障：指容器、Pod或節點發生故障或崩潰。

·網絡擁塞：指因丟包、網絡帶寬降低等網絡問題導致CNF無法交付所需KPI。

·資源限制：涉及云資源使用率或CPU、內存、網絡資源的可用性。

圖2：思博倫Landslide云原生測試套件。資料來源：思博倫，現為是德科技旗下公司。

云基礎設施基準測試用例旨在發現CNF是否能夠高效利用云資源。它幫助電信運營商理解CNF供應商對資源擴展和工作負載遷移所設定的依賴要求。

分析師Inderpreet Kaur寫到，電信云基礎設施團隊通常缺乏對服務KPI以及實現這些KPI所需最優資源的可見性。思博倫的云基礎設施測試用例使基礎設施團隊能夠根據定義用戶體驗質量的KPI（如延遲、丟包和抖動等），對計算、存儲和網絡資源進行基準測試。這些詳細信息有助于云基礎設施團隊合理調整CNF實例的規模。電信團隊可以更有信心地在在管理性能挑戰的同時避免云資源的過度配置。

Omdia指出，思博倫Landslide測試套件的一個關鍵亮點是其測試用例在電信運營商CI/CD/CT流水線中的可重復性與可集成性。據思博倫介紹，測試場景可在多個云環境和硬件基礎設施中復制。此功能在規劃和實施硬件升級/更換周期時非常有用。隨著CNF和CaaS升級變得越來越頻繁，電信運營商可以衡量這種升級對資源總體利用率的影響。