Tacker/UseCase

Tacker 解决的问题？

NFV 和 MANO 的挑战

为了最大化使用 NFV 进行虚拟化的效果，运营商应在初始阶段和扩展阶段解决挑战，以便在商业上引入 NFV。

在初始阶段，运营商应解决 VNF 和 NFVI 之间的“集成”问题，因为 VNF 和 NFVI 紧密耦合以确保运营商 SLA。根据 VNF 和 NFVI 的特性，运营商应使用各种虚拟化支持技术调整性能，确定 NFVI 故障点的 VM 分配规则，考虑 VNF 和 MANO 的 O&M，以及集成 VNFM 和 VIM 以实现它们。这些集成工作对运营商和 MANO 及 3GPP 系统的提供商来说负担过重，因为他们需要在没有参考实现的情况下讨论所有用例。

在扩展阶段，运营商面临 VNF、NFVI、VIM 和 VNFM 之间的“组合”问题，随着 VNF 实例和 NFVI 实例数量的增加而增加。由于 IA 服务器、SDN、存储、VNF 的 APL、VIM 和 VNFM 的产品生命周期不同，运营商应考虑测试组合、迁移模式以及每个产品版本的依赖关系。这种升级持续需要大量的努力来以非常大的组合方式集成它们。

技术问题

可视化虚拟资源和物理服务器进行分析

将软件从硬件上解耦也需要更精细的根本原因分析工具。缺乏此类工具使我们不得不维护虚拟化和物理资源之间的详细映射，例如哪个 VM 在哪里运行以及它们如何内部连接，并使用内部详细的 ID 方案。我们必须可视化 NFVI 中的所有内容，才能对操作充满信心。这是一个相当繁琐的维护过程，需要自动化。OpenStack Blazar 项目预计可以缓解电信行业所需的资源保证问题。

处理虚拟资源的方式差异

不同的 VNF 消耗基础设施资源的方式（例如，启动、QoS 控制点、亲和性规则、创建维护网络、配置方法等）不同。我们不得不为每个 VNF 创建操作程序文档，以减少这些过程中的错误。由于 VNF 与 MANO 的交互方式不同，实例化、更新/升级 - 所有与 VNF 相关的操作也不同。这些过程也需要自动化。我们已经将我们在详细文档过程中的发现贡献给了 ETSI NFV 标准化 - 从在商业网络中运行多厂商 VNF 中获得的知识。一旦 VNF 厂商基于 ETSI NFV 标准开发其产品，这种 VNF 操作程序的差异预计将会消失。

将现有功能重构为容器化

容器化技术需要对运营商的传统网络进行重大更改，而运营商无法在运营中进行重大跳跃。运营商的网络一直保持着高 SLA，这些网络基于点对点的详细设计和丰富的 VNF APL 功能，基于有状态。运营商将更改这些架构以使用容器，同时以低成本保持运营商 SLA。

方面	虚拟化	容器化
网络	基于 VLAN 和静态 IP 地址的点对点	基于 DNS 和 QoS 的扁平网络
状态	每个 VM 在内存和共享存储中都有状态。	解耦处理和数据库，具有高功能存储。
监控	VNF APL 收集有关故障、性能的信息。	外部功能收集有关故障、性能的信息。
配置	EMS 和 VNF 管理大量配置以提供服务。	VNF APL 将从外部功能获取配置。
操作	使用静态设计进行白盒操作，例如 IP 地址、配置、状态、故障和性能	使用 DHCP 和外部功能进行黑盒操作。