Neutron/nsx-integrated-services

范围

此蓝图是关于使 Nicira 插件能够处理 NSX 平台直接提供的 dhcp 和 metadata proxy 服务。 功能完成后，使用 NSX 的 Neutron 部署不再需要安装和管理一个或多个 dhcp 和 metadata proxy 代理。 Dhcp 和 metadata proxy 服务将由 NSX 4.x 引入的 Logical Services Nodes（逻辑服务节点）提供。Logical Services Node 的引入是为了表示在逻辑空间（例如逻辑网络）中提供一个或多个服务（例如 dhcp）的逻辑实体。

用例

• 使用 Neutron/NSX 作为网络引擎的现有 OpenStack 部署：这些现有的部署使用 dhcp 和 metadata proxy 代理来为租户 VM 提供 dhcp 服务，并在某些条件下代理对 Nova metadata 服务器的请求。 功能完成后，将实现以下用例

1. 租户创建一个启用 dhcp 的网络/子网：在网络上创建的端口的 IP 地址将由 NSX 运行和管理的 dhcp 服务分配。
2. 租户将子网连接到路由器：metadata 请求将通过由 NSX 运行和管理的 metadata proxy 服务进行代理。
3. 管理员可以迁移现有网络，这些网络的 dhcp 和 metadata proxy 服务由 neutron-dhcp-agent 和 neutron-metadata-proxy 组件提供，迁移到由 NSX 管理的各自实体。

• 使用 Neutron/NSX 作为网络引擎的新 OpenStack 部署：这些现有的部署将使用 NSX Logical Services Nodes 来提供 dhcp 和 metadata proxy 服务，并且将实现上述 1 和 2。

实现概述

已引入以下实体

• LsnManager：此类管理与 neutron 网络关联的 LSN（Logical Services Node）实体。 每个 Neutron 网络与 NSX 中存在的 1-1 映射的 LSN 节点相关联。 LSN 节点可以提供 dhcp 和 metadata proxy 服务。 这些服务通过将代表 neutron 网络的 NSX 逻辑交换机通过 NSX 逻辑交换机端口和 LSN 端口之间的补丁连接连接到 LSN 节点来提供。 每个 LSN 节点可以有多个 LSN 端口，但只能将一个 LSN 端口连接到单个 NSX 逻辑交换机。 LSN 端口配置保存了用于提供 dhcp 服务（分配池、IP 和 MAC 映射等）的 dhcp 选项。 目前，只能将单个逻辑交换机端口补丁连接到 LSN 端口。 这意味着每个 neutron 网络只能创建一个子网。 此限制将来可能会解除。 总体而言，此类别负责以下操作

1. NSX 中 LSN 实体的 CRUD 操作
2. NSX 中 LSN 端口实体的 CRUD 操作
3. 在 neutron 网络上启用/禁用逻辑服务
4.  LSN 端口的 DHCP 和 Metadata 配置

• PersistentLsnManager：此类从 LsnManager 继承，并向 LsnManager 添加持久性功能，以便卸载对 NSX 的访问。 此类还添加了通过按需从 NSX 拉取 LSN 状态来从本地数据存储丢失中恢复的能力。
• MigrationManager：此类管理为在可用此功能之前创建的 neutron 网络的迁移过程。 它验证网络是否符合迁移条件，并在符合条件时执行迁移。
• DhcpMetadataBuilder：此类处理正在迁移的网络中旧 dhcp 和 metadata proxy 资源的释放，并分配所需的 NSX LSN 资源。
• nvp.DhcpAgentNotifyAPI：此类处理当 NSX 提供 DHCP 和 Metadata proxy 服务时，子网和端口的生命周期事件。
• combined.DhcpAgentNotifyAPI：此类处理子网和端口的生命周期事件，无论 DHCP 和 Metadata proxy 服务是由 NSX（仅新网络）提供的，还是由 dhcp 和 metadata proxy 代理（现有网络）提供的。

数据模型变更

无。 已进行了两项补充

• 一个 Lsn 表，用于存储 neutron 网络和 LSN 之间的映射
• 一个 LsnPort 表，用于存储 LSN 和 LSN 端口之间的映射，以及一些属性，例如子网 cidr 等；

配置变量

已引入新的配置变量

• agent_mode：此选项添加了更多值

1. agentless：如果选择“agentless”（在 Icehouse 中为实验性），则插件将使用 NSX 逻辑服务来提供 DHCP 和 metadata proxy。 这简化了 Neutron 的部署模型，因为插件不再需要 RPC 代理来运行。 选择“agentless”时，config 选项 metadata_mode 将失效。 从 NVP 4.1 或更高版本开始支持“agentless”模式。
2. combined：这用于支持希望继续采用 agentless 模式的现有部署。 使用此模式，现有网络继续由现有基础设施提供服务，而新网络将由新基础设施提供服务。 提供迁移工具来“移动”一个网络从一个模型到另一个模型；但是，如果这不可能，由代理提供的网络和由 NSX 服务提供的网络可以共存于部署中。 将 agent_mode 设置为“combined”时，neutron.conf 中的选项“network_auto_schedule”将被忽略，因为新网络将不再被调度到现有的 dhcp 代理。

• default_service_cluster_uuid：默认服务集群的 UUID。 服务集群的引入是为了表示一组网关，并且为了能够在逻辑空间中使用诸如 dhcp 和 metadata 之类的逻辑服务而需要。 注意：如果将 agent_mode 设置为“agentless”，则此 config 参数*必须*设置为有效的预先存在的服务集群 uuid。
• sync_on_missing_data：设置为 True，以便在本地数据存储中缺少 LSN 信息时从 NSX 拉取 LSN 信息。 这对于服务器恢复时重建本地存储很有用。
• extra_domain_name_servers：逗号分隔的附加域名服务器列表。
• domain_name：用于构建主机名的域名。
• default_lease_time：默认 DHCP 租约时间。
• metadata_server_address：Metadata 服务器使用的 IP 地址。
• metadata_server_port：Metadata 服务器使用的 TCP 端口。
• metadata_shared_secret：在代理 metadata 请求时，Neutron 会使用共享密钥对 Instance-ID 标头进行签名，以防止欺骗。 您可以选择任何字符串作为密钥，但它*必须*与 Metadata 服务器使用的配置匹配。

API

API 扩展的以下更改发生

• 在 combined 模式下，nicira 插件支持以下扩展

1. agent：用于支持 dhcp 代理
2.  dhcp_agent_scheduler：用于支持跨多个 dhcp 代理调度 dhcp 请求
3. lsn：用于支持上述详细的迁移。

• 在 agentless 模式下，上述扩展 1 和 2 不再受支持。

插件接口

“lsn”扩展添加了以下新操作

• create_lsn：用于实现网络的迁移计划；
• get_lsn：用于检索网络使用的 lsn 资源；

CLI 要求

添加了一个名为 neutron-nsx-manage 的新工具。 这具有以下两个操作（超出 neutron 操作之外）

• net-report <net-id-or-name>：返回网络正在使用的资源。
• net-migrate <net-id-or-name>：检查网络是否可以迁移并执行迁移。

Horizon 要求

无

测试用例

已实现以下测试用例

• DhcpAgentNotifyAPITestCase：notifier 类的测试覆盖率。
• DhcpMetadataBuilderTestCase：builder 类的测试覆盖率。
• MigrationManagerTestCase：迁移管理器类的测试覆盖率。
• DhcpTestCase：与 dhcp 配置相关的操作的测试覆盖率。
• MetadataTestCase：与 metadata 配置相关的操作的测试覆盖率。
• LsnManagerTestCase：LsnManager 类的测试覆盖率。
• PersistentLsnManagerTestCase：PersistentLSNManager 类的测试覆盖率。
• lib.LSNTestCase：针对 NSX 进行的 lsn 操作的测试覆盖率。
• db.LSNTestCase：针对 db 进行的 lsn 操作的测试覆盖率。