電信基礎(chǔ)設(shè)施正在虛擬化和容器化，并需要降低部署多個應(yīng)用程序的集成和驗證成本。為此，NTT、KDDI和NEC采用了Tacker，這是一個符合ETSI NFV標(biāo)準(zhǔn)的G-VNFM（通用VNF管理器），是OpenStack中最活躍的項目之一。
正如在2020年的開放基礎(chǔ)設(shè)施峰會上提出的那樣，Tacker現(xiàn)在正處于與ETSI NFV建立牢固關(guān)系的階段。它正在創(chuàng)建一個開發(fā)過程，使用ETSI-NFV TST010和Zuul自動化IF和spec與ETSI-NFV的合規(guī)性測試，并將推廣使用ETSI-NFV的CNF控制解決方案。該合作將促進(jìn)與其他產(chǎn)品的互操作性。
網(wǎng)絡(luò)運營商面臨的挑戰(zhàn)
電信運營商面臨著共同的挑戰(zhàn)。KDDI和NTT是日本大型股份公司。雖然我們的服務(wù)系統(tǒng)是為每家公司單獨開發(fā)的，但我們意識到，應(yīng)該分享一些共同的問題，并通過相互合作來解決這些問題，以快速開發(fā)具有最新虛擬化技術(shù)的大規(guī)模電信服務(wù)。
在實現(xiàn)最新的網(wǎng)絡(luò)服務(wù)方面，我們面臨著兩大挑戰(zhàn)。
挑戰(zhàn)1：同時運維VNF和CNF
基于CNF的技術(shù)，即云原生應(yīng)用程序或5GC已經(jīng)出現(xiàn)。是否可以為所有應(yīng)用程序從VNF切換到CNF？
答案是否定的。對于某些應(yīng)用程序，例如U-plain功能或遺留應(yīng)用程序，VNF更適合。我們需要同時部署VNF和CNF。
挑戰(zhàn)2：高SLA的多供應(yīng)商集成
NFV的成本不斷增加是一個問題。其中最關(guān)鍵的部分是VNFM。
VNFM成本高昂的原因有：VNFM有許多接口；它需要一些可選的實現(xiàn)；所有供應(yīng)商都不符合標(biāo)準(zhǔn)；標(biāo)準(zhǔn)本身并不是所有用例的萬能工具。要滿足我們的要求需要額外的費用。
除了VNFM之外，我們還需要滿足系統(tǒng)范圍內(nèi)高級別服務(wù)的需求。因此，集成和驗證成本大大增加。
OpenStack Tacker
作為一個開源的G-VNFM，Tacker正試圖解決這些挑戰(zhàn)。Tacker的開發(fā)由NTT、NEC和Fujitsu主導(dǎo)，他們擁有電信運營商/供應(yīng)商的豐富經(jīng)驗。
為什么是Tacker？
Tacker提供基于ETSI NFV標(biāo)準(zhǔn)的VNFM和NFVO作為NFV的主要組件。2014年，它開始作為NFV編排框架在OpenStack上開發(fā)。一些網(wǎng)絡(luò)供應(yīng)商和運營商已經(jīng)加入到Tacker中來實現(xiàn)他們的需求。
現(xiàn)在，Tacker是將NFV系統(tǒng)部署為面向多供應(yīng)商的開源G-VNFM的主要候選方案之一。它針對5GC的用例，除了OpenStack之外，還引入了CISM（容器基礎(chǔ)設(shè)施服務(wù)管理）和Kubernetes，以實現(xiàn)CNF和VNF的共存。
對于挑戰(zhàn)1，Tacker涵蓋了廣泛的用例，包括通過引用ETSI NFV標(biāo)準(zhǔn)集成VNF和CNF。Kubernetes支持是Tacker項目的最新熱點之一，目前正在積極開發(fā)中。
對于挑戰(zhàn)2，Tacker不僅提供符合ETSI NFV的功能，還提供許多作為單元和功能測試的測試用例。測試場景也是基于ETSI-NFV中的用例設(shè)計的。
社區(qū)發(fā)展
以NFV需求為背景，Tacker的開發(fā)比以前的版本更加活躍。例如，建議的補丁總數(shù)增加了37%，活躍貢獻(xiàn)者的數(shù)量是26個。
在最近的版本中，Tacker更加關(guān)注ETSI-NFV兼容特性，以滿足VNF和CNF共存環(huán)境的要求。在Victoria發(fā)布中，Tacker團(tuán)隊發(fā)布了ETSI NFV的11個基本功能：
——在Tacker中增強VNF生命周期管理
——支持基于ETSI NFV-SOL的錯誤處理
——支持基于ETSI NFV-SOL規(guī)范的VNF LCM通知
——支持基于ETSI NFV-SOL規(guī)范的VNF縮放操作
——支持ETSI NFV SOL003與第三方NFVO互操作
——支持基于ETSI NFV-SOL規(guī)范的VNF更新操作
——由Action Driver自定義VNF工作流
——為vnf包添加工件支持
——通過警報類型策略支持事件觸發(fā)報警和vdu_autoheal
——采用Robot Framework以使用ETSI NFV-TST API測試代碼
——帶VNFM和CISM的CNF
商業(yè)服務(wù)網(wǎng)絡(luò)中的Tacker
KDDI是提供固定和移動網(wǎng)絡(luò)服務(wù)的大型公司，用戶超過6000萬。KDDI采用Tacker作為固定網(wǎng)絡(luò)的VNFM。
從一些使用專用或特定VNFM的經(jīng)驗來看，我們意識到它提供了相當(dāng)多的功能和漂亮的GUI，但其中許多是不需要的。它不靈活，不穩(wěn)定，使用困難。
KDDI使用Tacker有以下幾個原因：
——輕巧簡約
——ETSI NFV標(biāo)準(zhǔn)的兼容性
——用于多供應(yīng)商集成的開源軟件
——成熟的基于OpenStack的產(chǎn)品
特別是對于VNFM：
——支持HOT（熱編排模板）和VRD。VNF供應(yīng)商能夠在沒有Vnfm的情況下驗證Vi-Vnfm接口。
——OpenStack Heat比TOSCA VNFD更受歡迎，而且更靈活。
——實現(xiàn)最新的ETSI NFV標(biāo)準(zhǔn)功能和Kubernetes支持。
KDDI和NEC已經(jīng)提出了一些功能，以填補當(dāng)前實現(xiàn)和實際用例的空白：
——使用商業(yè)VNF中所需的部署風(fēng)格的多種HOT部署風(fēng)格。
——支持LCM資源回滾處理意外錯誤。
與ETSI NFV合作
為了實現(xiàn)高質(zhì)量的符合標(biāo)準(zhǔn)的G-VNFM，如果沒有ETSI-NFV的反饋，僅僅開發(fā)Tacker是不夠的。因此，合作是成功的關(guān)鍵之一。
ETSI NFV TST
NEC率先引入了ETSI NFV TST（測試）中定義的測試框架。從開發(fā)人員的角度來看，我們希望使用OpenAPI和Robot可以大大提高Tacker與第三方產(chǎn)品的連接性。
我們認(rèn)為相互合作對雙方都有好處。對于ETSI-NFV-TST，來自Tacker的增強測試代碼的反饋必須有助于提高互操作性和確認(rèn)可行性。另一方面，對于Tacker，我們可以獲得自動化的API測試代碼，并確保MANO符合標(biāo)準(zhǔn)。使用TST的范圍不僅是給ETSI NFV提供反饋，而且還創(chuàng)造了一個反饋周期，以便一次又一次地繼續(xù)這樣的改進(jìn)。
在Tacker中引入ETSI NFV TST
我們已經(jīng)開始與ETSI NFV TST討論。有幾個關(guān)鍵主題：
——響應(yīng)代碼、HTTP響應(yīng)頭檢查和請求輸入?yún)?shù)的增強測試覆蓋率。
——測試代碼管理，如分支或存儲庫上的命名、版本控制或在規(guī)范中提供測試覆蓋率的描述。
作為將ETSI-NFV-TST引入Tacker的第一步，我們的目標(biāo)是在Zuul測試中啟用名為TST010的API一致性測試規(guī)范。通過評估，我們發(fā)現(xiàn)，需要澄清如何實施“前提條件”。我們目前沒有任何“前提條件”的實現(xiàn)，盡管它可以被稱為規(guī)范。還需要進(jìn)一步的工作來包括測試Tacker，以便實現(xiàn)和維護(hù)測試代碼。應(yīng)該如何開發(fā)測試代碼，或者為測試制作一些場景？
下一步是完成自動化API測試。我們的計劃只是通過從ETSI NFV存儲庫和Tacker的support API列表下載測試代碼來執(zhí)行合規(guī)性測試。這個測試是由ETSI NFV開發(fā)的，Tacker提供了支持的API，這些API以最小的工作量自動測試。
