电信基础设施正在虚拟化和容器化，并需要降低部署多个应用程序的集成和验证成本。为此，NTT、KDDI和NEC采用了Tacker，这是一个符合ETSI NFV标准的G-VNFM（通用VNF管理器），是OpenStack中最活跃的项目之一。
正如在2020年的开放基础设施峰会上提出的那样，Tacker现在正处于与ETSI NFV建立牢固关系的阶段。它正在创建一个开发过程，使用ETSI-NFV TST010和Zuul自动化IF和spec与ETSI-NFV的合规性测试，并将推广使用ETSI-NFV的CNF控制解决方案。该合作将促进与其他产品的互操作性。
网络运营商面临的挑战
电信运营商面临着共同的挑战。KDDI和NTT是日本大型股份公司。虽然我们的服务系统是为每家公司单独开发的，但我们意识到，应该分享一些共同的问题，并通过相互合作来解决这些问题，以快速开发具有最新虚拟化技术的大规模电信服务。
在实现最新的网络服务方面，我们面临着两大挑战。
挑战1：同时运维VNF和CNF
基于CNF的技术，即云原生应用程序或5GC已经出现。是否可以为所有应用程序从VNF切换到CNF？
答案是否定的。对于某些应用程序，例如U-plain功能或遗留应用程序，VNF更适合。我们需要同时部署VNF和CNF。
挑战2：高SLA的多供应商集成
NFV的成本不断增加是一个问题。其中最关键的部分是VNFM。
VNFM成本高昂的原因有：VNFM有许多接口；它需要一些可选的实现；所有供应商都不符合标准；标准本身并不是所有用例的万能工具。要满足我们的要求需要额外的费用。
除了VNFM之外，我们还需要满足系统范围内高级别服务的需求。因此，集成和验证成本大大增加。
OpenStack Tacker
作为一个开源的G-VNFM，Tacker正试图解决这些挑战。Tacker的开发由NTT、NEC和Fujitsu主导，他们拥有电信运营商/供应商的丰富经验。
为什么是Tacker？
Tacker提供基于ETSI NFV标准的VNFM和NFVO作为NFV的主要组件。2014年，它开始作为NFV编排框架在OpenStack上开发。一些网络供应商和运营商已经加入到Tacker中来实现他们的需求。
现在，Tacker是将NFV系统部署为面向多供应商的开源G-VNFM的主要候选方案之一。它针对5GC的用例，除了OpenStack之外，还引入了CISM（容器基础设施服务管理）和Kubernetes，以实现CNF和VNF的共存。
对于挑战1，Tacker涵盖了广泛的用例，包括通过引用ETSI NFV标准集成VNF和CNF。Kubernetes支持是Tacker项目的最新热点之一，目前正在积极开发中。
对于挑战2，Tacker不仅提供符合ETSI NFV的功能，还提供许多作为单元和功能测试的测试用例。测试场景也是基于ETSI-NFV中的用例设计的。
社区发展
以NFV需求为背景，Tacker的开发比以前的版本更加活跃。例如，建议的补丁总数增加了37%，活跃贡献者的数量是26个。
在最近的版本中，Tacker更加关注ETSI-NFV兼容特性，以满足VNF和CNF共存环境的要求。在Victoria发布中，Tacker团队发布了ETSI NFV的11个基本功能：
——在Tacker中增强VNF生命周期管理
——支持基于ETSI NFV-SOL的错误处理
——支持基于ETSI NFV-SOL规范的VNF LCM通知
——支持基于ETSI NFV-SOL规范的VNF缩放操作
——支持ETSI NFV SOL003与第三方NFVO互操作
——支持基于ETSI NFV-SOL规范的VNF更新操作
——由Action Driver自定义VNF工作流
——为vnf包添加工件支持
——通过警报类型策略支持事件触发报警和vdu_autoheal
——采用Robot Framework以使用ETSI NFV-TST API测试代码
——带VNFM和CISM的CNF
商业服务网络中的Tacker
KDDI是提供固定和移动网络服务的大型公司，用户超过6000万。KDDI采用Tacker作为固定网络的VNFM。
从一些使用专用或特定VNFM的经验来看，我们意识到它提供了相当多的功能和漂亮的GUI，但其中许多是不需要的。它不灵活，不稳定，使用困难。
KDDI使用Tacker有以下几个原因：
——轻巧简约
——ETSI NFV标准的兼容性
——用于多供应商集成的开源软件
——成熟的基于OpenStack的产品
特别是对于VNFM：
——支持HOT（热编排模板）和VRD。VNF供应商能够在没有Vnfm的情况下验证Vi-Vnfm接口。
——OpenStack Heat比TOSCA VNFD更受欢迎，而且更灵活。
——实现最新的ETSI NFV标准功能和Kubernetes支持。
KDDI和NEC已经提出了一些功能，以填补当前实现和实际用例的空白：
——使用商业VNF中所需的部署风格的多种HOT部署风格。
——支持LCM资源回滚处理意外错误。
与ETSI NFV合作
为了实现高质量的符合标准的G-VNFM，如果没有ETSI-NFV的反馈，仅仅开发Tacker是不够的。因此，合作是成功的关键之一。
ETSI NFV TST
NEC率先引入了ETSI NFV TST（测试）中定义的测试框架。从开发人员的角度来看，我们希望使用OpenAPI和Robot可以大大提高Tacker与第三方产品的连接性。
我们认为相互合作对双方都有好处。对于ETSI-NFV-TST，来自Tacker的增强测试代码的反馈必须有助于提高互操作性和确认可行性。另一方面，对于Tacker，我们可以获得自动化的API测试代码，并确保MANO符合标准。使用TST的范围不仅是给ETSI NFV提供反馈，而且还创造了一个反馈周期，以便一次又一次地继续这样的改进。
在Tacker中引入ETSI NFV TST
我们已经开始与ETSI NFV TST讨论。有几个关键主题：
——响应代码、HTTP响应头检查和请求输入参数的增强测试覆盖率。
——测试代码管理，如分支或存储库上的命名、版本控制或在规范中提供测试覆盖率的描述。
作为将ETSI-NFV-TST引入Tacker的第一步，我们的目标是在Zuul测试中启用名为TST010的API一致性测试规范。通过评估，我们发现，需要澄清如何实施“前提条件”。我们目前没有任何“前提条件”的实现，尽管它可以被称为规范。还需要进一步的工作来包括测试Tacker，以便实现和维护测试代码。应该如何开发测试代码，或者为测试制作一些场景？
下一步是完成自动化API测试。我们的计划只是通过从ETSI NFV存储库和Tacker的support API列表下载测试代码来执行合规性测试。这个测试是由ETSI NFV开发的，Tacker提供了支持的API，这些API以最小的工作量自动测试。
