Neutron 中可插拔 IPAM 子系统¶
Launchpad 蓝图： https://blueprints.launchpad.net/neutron/+spec/neutron-ipam
此蓝图引入了 Neutron 中的可插拔 IPAM 子系统，该子系统允许灵活控制网络资源（如下所示）的生命周期
分配给 Neutron 端口的固定 IP 地址
浮动 IP 地址
网络地址范围，即子网
问题描述¶
用户需要将 OpenStack 集成到其使用外部 IPAM 的现有基础设施中。
目前，大多数（如果不是全部）Neutron 插件都利用嵌入在 db_base_plugin 实现中的 IPAM 实现。虽然这在自包含系统中运行良好，但它使得与外部 IPAM 后端集成变得困难或不可能，而无需进行糟糕的修改。
Neutron 的当前架构不允许用户以任何其他方式实现自己的 IPAM 机制，除非引入自己的核心插件。也就是说，虽然可以更改 DHCP 提供程序，但实际的分配逻辑无法更改。
提议的变更¶
概述¶
提议的更改是添加一个定义明确的抽象 IPAM 接口，并重构现有的 NeutronDbPluginV2 以利用该接口，而不是直接执行 IPAM 操作。 相关的蓝图 [1] 建议实现一个参考 IPAM 驱动程序，以捕获当前行为。
IPAM 接口¶
IPAM 子系统架构概述如下。 定义了一个抽象基类，IPAMDriver。 将有一个参考实现该类 - NeutronIPAM - 它将封装当前行为。 IPAMDriver 可以被第三方子类化以实现不同的 IPAM 行为，例如不同的子网或 IP 分配策略，或访问外部 IPAM 系统。
Neutron 插件将调用驱动程序以获取 IPAM 功能。
驱动程序接口将是同步的。
IPAM 实现将定义用于子网和地址的抽象请求类。 这些类使调用者可以使用显式子网或地址以外的标准请求子网或 IP 分配，但实施除现有行为以外的请求标准不在此蓝图的范围内。
请参阅 [2] 以获取接口定义。 此接口的细节不属于此规范的一部分，并且对该接口的工作可能会在批准此规范之后继续进行。
交互示例¶
以下图表显示了 Neutron 插件和 IPAM 之间的交互示例。 在此图表和下图中，“可插拔 IPAM”代表可选的外部 IPAM 系统。 这些图表仅作为示例；每个流程的特定细节将在实施期间定义。
这是演示调用以创建端口的另一个流程。 在这种情况下，调用 IPAM 驱动程序以检索子网，*或*如果未找到则分配子网。 也就是说，“get_subnet”调用可以简单地从 Neutron 数据库检索现有的子网，或者可以转到外部 IPAM 系统以查询或分配子网。 行为由驱动程序自行决定。
IPAMSubnet 对象用于 IP 分配。
驱动程序创建¶
IPAMDriver 将包含一个工厂方法来生成特定的驱动程序实例。 将为每个 SubnetPool 提供一个驱动程序实例（请参阅 [3]）。 但是，在此版本中，仅支持部署中的单个驱动程序。
请注意，此 BP 不会提供 SubnetPool 的任何数据库或 API。 作为此 BP 的一部分，将仅创建一个最小的实现。
通过配置文件 /etc/neutron/neutron.conf 指定用于 SubnetPool 的 IPAM 驱动程序。 默认值将指向参考 NeutronIPAM 驱动程序。
重构¶
必须重构现有的 NeutronDbPluginV2 以利用新的 IPAM 接口。 几个核心插件对 NeutronDbPluginV2 中的 IPAM 相关私有方法进行调用。 必须保留这些方法的存根版本，并重构以利用 IPAM 接口，或者插件本身必须重构以避免调用基类的私有方法。 当前这些方法中的实现将被移动到参考驱动程序。
虽然驱动程序将使外部 IPAM 系统提供关于是否分配新地址或子网的权威响应，但 Neutron 数据库仍然需要对当前分配的子网和 IP 地址进行准确的表示。 对现有分配的查询仍然会访问本地数据库，而不是通过驱动程序调用。 外部 IPAM 和 Neutron 在初始迁移和持续验证期间的同步是驱动程序作者的责任，无论是在驱动程序内部还是外部。
NeutronDbPluginV2 中当前完成的 DB 活动最好通过组合而不是继承来处理。 基插件可以有一个数据库处理程序对象来执行这些函数。 这将允许在外部系统做出寻址决策之后（）执行数据库事务。 这避免了涉及 I/O 的调用在打开的事务中，这可能由于 MySQL 连接器缺陷导致死锁问题。
这超越了 IPAM 函数，当然。 这里的想法是，所有插件仍然需要 Neutron DB 中的核心数据，即使他们可能需要在这些调用期间存储其他数据或执行其他操作。
不在范围内的项目¶
已经讨论了与此蓝图相关的几个函数。
DHCP 选项，例如名称服务器和主机路由，有意与 IPAM 实现分离。 可插拔 DHCP 需要单独的努力，或者必须在各个驱动程序中解决。
同样，IPAM 活动期间与 Designate 或其他外部 DNS 服务的集成不在范围内。
IPAM 区域互联网注册管理机构 (RIR) 生命周期管理和自动化超出了此蓝图的范围。
数据模型影响¶
此实现不会进行任何数据模型更改，只会添加接口和非持久类。 而是，相关的数据模型更新在 [4] 中捕获，尽管这对于此蓝图来说不是严格必需的。
REST API 影响¶
无。
安全影响¶
无。
通知影响¶
无。
其他最终用户影响¶
无。
性能影响¶
IPAM 子系统默认 Neutron 驱动程序的实现应具有与当前 Neutron IPAM 相似的性能。 外部 IPAM 驱动程序的性能影响不在本文档的范围内。
IPv6 影响¶
对 IPv6 的支持是此规范的要求。
其他部署者影响¶
将在 neutron.conf 文件中提供一个用于指定所需的 IPAM 驱动程序的新配置选项。 如果未指定此值，Neutron Server 将回退到默认 Neutron IPAM 驱动程序在默认位置。 做出此选择是为了支持与较旧的 neutron.conf 文件向后兼容，这些文件未指定此选项。
开发人员影响¶
默认情况下，Neutron 应该像今天一样工作。 提供的参考 IPAM 驱动程序应封装当前功能。
由于核心插件会覆盖基插件类中的几个方法，我们将评估 IPAM 更改对这些插件的影响。
社区影响¶
此更改在 Juno 和 Kilo 设计峰会上进行了讨论。 有支持可插拔 IPAM，请参阅文档参考部分中的 Etherpad 链接。
备选方案¶
无。
开发人员影响¶
实现¶
负责人¶
- 主要负责人
John Belamaric (jbelamaric)
- 其他贡献者
Salvatore Orlando (salvatore-orlando) Carl Baldwin (carl-baldwin) Ryan Tidwell (ryan-tidwell) Hosung Hwang (hhwang-2) Yue Ko (yko) Pavel Bondar (pasha117)
工作项¶
创建 IPAM 抽象接口。
为 db_base_plugin_v2 创建可插拔 IPAM。
将所有 IPAM 相关功能从 db_base_plugin_v2 移动到 Neutron IPAM 插件。
依赖项¶
测试¶
在适当的情况下将使用现有的单元测试，并将扩展单元测试覆盖范围以涵盖重构的 Neutron IPAM 代码。
功能测试¶
在适当的情况下将使用现有的功能测试，IPAM 的重构可能需要额外的或重构的功能测试。
Tempest 测试¶
现有的 Neutron Tempest 测试将用于测试将开发的默认 Neutron IPAM。
API 测试¶
没有提议的 API 更改。
文档影响¶
用户文档¶
将更新管理员指南。
开发人员文档¶
将更新 API 指南。
