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

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

　　傳統(tǒng)上，電信運營商依賴網(wǎng)絡設備供應商來構(gòu)建和部署其網(wǎng)絡功能。這種依賴供應商的模式使其未能充分準備好應對云原生轉(zhuǎn)型帶來的復雜性和運營挑戰(zhàn)。至關(guān)重要的是，電信運營商需要合適的工具來應對這些變化。

　　電信網(wǎng)絡正向云基礎(chǔ)設施遷移

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

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

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

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

　　云原生遷移面臨諸多挑戰(zhàn)

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

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

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

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

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

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

　　·確保云資源高效利用

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

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

　　·使組織結(jié)構(gòu)適應運營模式

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

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

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

　　思博倫如何應對云原生網(wǎng)絡測試挑戰(zhàn)

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

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

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

　　·對象故障：指容器、Pod或節(jié)點發(fā)生故障或崩潰。

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

　　·資源限制：涉及云資源使用率或CPU、內(nèi)存、網(wǎng)絡資源的可用性。

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

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

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

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