Neutron/PNI-VNI-Pluggable-Framework
目录
蓝图贡献者
- AT&T Foundry
- PLUMgrid
- Ericsson
支持者与兴趣
- RedHat
- Cisco
- Anuta Network
- Midokura
背景
Quantum，以及其他 Openstack 服务，引入了插件的概念，这是一种可插拔的网络 API 后端实现。插件可以使用各种技术来实现逻辑 API 请求。一些 Quantum 插件可能使用基本的 Linux VLAN 和 iptables 工具，而另一些插件可能使用更先进的技术，例如 L2-in-L3 隧道或 OpenFlow，以提供类似的好处。
这些技术特定插件的范围在 Quantum 中没有定义或限制。因此，插件可以涵盖数据中心内的任何网络层，从核心层（包括汇聚层和接入层）到服务器虚拟化层，通常称为虚拟交换机。
目前 Quantum 仅支持每个部署实例化的单个插件。这是一个限制，一些开发人员通过实现重新部署现有插件的插件，以及在其他情况下同时部署多个插件来克服这个限制。例如，Cisco 插件重新部署 OVS 插件和其自身的 NXOS 插件。其他方法，例如 metaplugin，同时部署多个插件，让 Quantum API 用户可以根据 API 扩展来决定使用哪个插件。
问题定义
网络拓扑可能具有多个网络元素（物理和虚拟），这些元素可能是不同类型/技术的组合。以通用方式解决这个问题通常很困难。我们提出一个新的 Quantum 插件框架，它可以处理这些通用需求，并提供此插件框架的参考实现，以便可以扩展和自定义它。
Quantum 架构需要修改，以便根据数据中心拓扑分类来定义每个插件的范围。基本上，数据中心存在两个基础设施域，即虚拟网络基础设施 (VNI) 和物理网络基础设施 (PNI)。图 1 显示了这种分离。
很明显，PNI 和 VNI 域之间的网络配置可能共享一些通用功能，但同时这两个域都具有非常独特的功能，如果实现每个基础设施域的插件而不是仅使用一个覆盖整个系统的插件，则计算管理员可以利用这些功能。
事实上，大多数 Quantum 插件涵盖一个或另一个基础设施域，但并非完全涵盖两者。迫切需要重新定义 Quantum 架构，以考虑 PNI 和 VNI 之间的明确定义。
描述与动机
本文档提出了一种新的 Quantum 可插拔架构模型，其中不同类型的插件管理物理网络基础设施 (PNI) 和虚拟网络基础设施 (VNI)。这些插件将是技术特定的，并且其范围限制在其所属域的功能范围内。Quantum 用户将决定在他们的部署中包含哪些 PNI 和/或 VNI 插件，Quantum 应该允许每种类型使用一个插件，但可以讨论包含多个插件的可能性。图 2 显示了提议的架构。
对于这种新的可插拔架构，持久性和分段层不需要进行重大更改。但是，每个插件都可以根据公开的扩展来扩展基础 DB 模式。
PNI/VNI 子插件在 Quantum 可插拔框架下，更倾向于允许互补功能的各种技术之间的互操作性。主要优势在于 PNI 和 VNI 供应商的共存和互操作性为客户提供了更好的解决方案。此外，当前单一的互斥量子插件模型会导致 PNI 和 VNI 配置之间的错误关联，或者另一方面，导致复杂且有时是硬编码的网络编排功能。在当前设计中，正确的网络功能被强制工作，而在本提案中，Quantum 将以独立架构提供两个域的最佳功能。
Quantum API
API 也可以按域分离。随着 Quantum 的发展，一些 API 在一个域或另一个域中会更有意义。因此，分离 API 实现是合理的。
OpenStack Dashboard 集成
Dashboard 不应该受到任何更改，但它可以开始暴露以前未暴露的 PNI 信息。这将丰富云管理员将从 UI 获取的信息。
优势
- 明确定义每个插件的网络范围
- 简化新技术特定插件的开发
- 避免插件之间的冗余调用
- 通过插件扩展集成新的 PNI 和 VNI 功能
- 更容易实现新的扩展
用例
用例将由 2 个计算节点、1 个存储节点和 1 个操作节点组成，配置为多主机配置，Cisco Nexus (NXOS) ToR 交换机提供 PNI 服务，Linux Bridge (LB) VNI 提供程序。
数据模型
Quantum 插件将提供底层数据模型的抽象。PNI/VNI 实现将通过 API 进行访问和修改。任何插件特定的数据持久化都将通过 Quantum 扩展机制提供。
反馈
我们恳请社区提供反馈以完善此提案，与我们分享您的评论、建议和想法。
