中子路由网络

https://blueprints.launchpad.net/nova/+spec/neutron-routed-networks

在中子中，支持路由网络是一项重要的工作。 在这里，路由网络是指物理网络基础设施，它通过路由而不是大型 L2 广播域来实现扩展的网络。 例如，部署者可能在每个机架顶部配备路由器。 与覆盖整个部署的单个 VLAN 不同，每个机架将拥有自己的 VLAN，并且路由器将通过 L3 提供对其他机架的可访问性。 运营商希望中子将此建模为单个网络。 这对 Nova 调度和可能的迁移有影响。

问题描述

中子有一个规范，说明如何在其中处理此问题。 每个 L2 网络都称为一个 segment（分段）。 其他术语在规范中讨论中。

对于 Nova 来说，这有几个具体的含义。 首先，IP 子网将与特定的网络 segment 具有亲和性。 其次，计算主机将仅对网络中的一个 segment（通常）具有 L2 可达性。 这意味着分配给端口的 IP 地址被限制为潜在的小型计算主机子集。

目前，Nova 需要端口上的 IP 地址。 如果保留此要求，并且该 IP 地址被限制为小型计算主机子集，那么调度程序将不得不将调度限制在该子集上。 这对调度程序来说是一个非常严重的人为约束。 为了避免这种情况，中子需要能够在主机绑定之后才分配 IP 地址。 在主机绑定后，Nova 仍然可以为延迟 IP 端口在未分配 IP 的情况下使构建失败。

一个相关的但不太严重的约束是跨 segment 的 IP 可用性。 某些 segment 可能会耗尽，这应由调度程序考虑。 这是一种由中子控制的资源，因此需要 创建资源提供程序 来管理它以供 Nova 调度程序使用。

对于涉及调度程序（例如，实时迁移）的移动操作，虚拟机已经具有 IP 地址。 为了使该 IP 地址继续工作，虚拟机必须迁移到另一个具有相同网络 segment 可达性的主机。 绕过调度程序的强制移动操作，如果新主机上不可用该 segment，则可能在绑定时导致失败。

用例

在以下用例中，假设中子中的所有 segment 都可以通过 新提出的 openstack resource-pool create 和 openstack resource-pool add aggregate` 命令以及相关的 REST API 与 Nova 中的一个或多个 aggregate 关联。

  1. 用户有一个未绑定到 segment 的端口，并将其提供给 nova boot。 此端口在调度程序将实例放置并端口绑定到该主机后才会有 IP 地址。 然后，中子可以从计算主机可以访问的 segment 分配 IP 地址。

    在此用例中，调度程序必须考虑每个 segment 中 IP 地址的可用性。 例如，网络中的某些 segment 可能完全没有地址。

    • 一个类似的用例是向现有实例添加额外的端口。 在这种情况下，新端口的 segment 和 IP 地址将在新端口绑定到计算主机时设置。 由于端口最初未绑定，因此不应有任何限制。

      如果主机可用的所有 segment 都没有 IP 地址，则绑定可能会失败。

  2. 用户有一个具有 IP 地址的端口，因此实际上已连接到 segment（但未绑定到主机）。 他/她将其提供给 nova boot。 Nova 将要求中子获取端口绑定的 segment，方法是获取端口的详细信息。 鉴于该 segment，调度程序应将实例放置到属于相应 aggregate 的计算主机上。

    • 一个类似的用例是向现有实例添加额外的端口。 在这种情况下，新端口的 segment 必须与实例的主机可用的 segment 匹配。 如果没有，则将端口添加到实例应该失败。

  3. 用户调用 Nova boot 并传递网络 ID。 Nova 调度程序将调用中子以创建端口，将放置实例，然后调用中子以使用绑定详细信息更新端口。 中子将使用主机绑定来设置 segment 并分配 IP。

  4. 任何调用调度程序的移动操作。 在这种情况下，端口已经具有 IP 地址。 该 IP 地址仅在相同的 segment 中有效。 调度程序仅应考虑属于相同 segment（或 aggregate）的目标主机。

提议的变更

中子将成为如 通用资源池规范及其依赖项中所述的资源提供程序。 我认为中子将创建并维护与 segment 对应的 aggregate，以便 Nova 具有与中子相同的从主机到 segment 的映射。

接下来，中子为每个 segment 创建一个 resource_pool。 该池具有与其他 resource pool 共同的资源类（例如“IPV4_ADDRESS”或“IPV6_ADDRESS”），但每个池特定于 segment ID。 通过将 resource pool 的 UUID 设置为中子中 segment 的 UUID 来设置链接。 资源池链接到主机 aggregate。

资源池在 inventories 表中有一条记录，用于将 IP 作为资源类。 它有效地从 Nova 的角度提供了池的容量

capacity = (total - reserved) * allocation_ratio

中子将调用 Nova 的 REST API 将“total”设置为子网上的分配池的大小。 这将保持大部分静态，但如果子网更新调用中更新了分配池，则可能会更改。 在这种情况下，allocation_ratio 始终为 1.0。

中子将 reserved 设置为 Nova 范围之外消耗的所有地址的总数。 这包括来自子网分配池的开销，例如 dhcp 和 dns，中子与 Nova 共享。 这预计将保持大部分不变，但如果中子中分配了新的开销端口，则可能会比 total 稍有变化。

allocations 表指示 Nova 消耗了多少容量。

对于任何给定 segment，可能会出现争用 IP 资源。 在当前的 Nova 中，声明在完成调度后在计算节点上进行。 如果 IP 资源即将耗尽，这可能会导致争用 IP。 由于声明是在计算节点上进行的，因此未能收集声明代价高昂，因为计算节点已经开始声明和消耗其他资源的过程。

为了降低失败声明的成本，此规范依赖于 John G 的规范，用于在调度之前预分配并将端口更新移动到 conductor。

关于用户拥有端口并将其带到 Nova 以创建实例（或将其添加到现有实例）的用例，乍一看它们似乎相同

nova boot --nic port_id=$PORT_ID

Nova 将调用中子以获取或创建端口，并在响应中接收端口的详细信息。 在这些详细信息中，中子将包含端口上每个 fixed_ip 的 segment_id（如果它绑定到 segment）。 此 segment_id 将用于查找 segment 上的 IP 地址的资源提供程序。

为了允许中子延迟分配端口上的 IP 地址，将在中子端口中添加一个名为 ip_allocation 的新属性。 它将具有三个值之一：“immediate”（立即）、“deferred”（延迟）或“none”（无）。 具有“immediate”ip_allocation 的端口像今天的端口一样工作：预计将在端口创建时分配 IP。 具有“deferred”ip_allocation 的端口将在提供主机绑定信息时在端口更新时分配 IP 地址。 具有“none”ip_allocation 的端口不打算分配 IP 地址。 处理具有“none”的端口不在此补丁的范围内。

备选方案

考虑了一种替代方案，即尝试消除 Nova 和中子之间的 IP 资源竞争。 它涉及对资源提供程序上 reserved 字段进行更积极的维护，并且需要根据场景有条件地记录分配。

由于其复杂性，该方法被拒绝，转而采用当前提案。

数据模型影响

无

REST API 影响

无

安全影响

无

通知影响

无

其他最终用户影响

  1. 创建带有中子的端口并将其带到 Nova 的用户会注意到，当网络是路由网络时，端口没有 IP 地址。

  2. 运营商会注意到主机 aggregate 的使用，这些 aggregate 对应于中子 segment 及其相应的资源提供程序。

性能影响

先前的规范 为网络感知做好准备有一些性能影响，应该在此处注意，尽管此规范并未增加这些影响。 它将端口 get/create 移动到调度程序之前，这会增加一些开销。 它还将端口更新移动到 conductor，这将大大减少由于 IP 地址资源耗尽而导致端口更新失败时产生的开销。

其他部署者影响

由于这项工作依赖于中子中的工作，因此有一些升级注意事项。 如果中子中未使用路由网络，则没有问题。 现有的网络和新的非路由网络将像今天一样工作。 由于路由网络是一项可选的新功能，因此只有希望利用它的运营商才会受到影响。

最好的做法是，在尝试配置路由提供程序网络之前，同时升级两个服务。 但是，我将讨论滚动升级的影响。

如果升级了中子 API 而 Nova 没有升级，则中子将没有可用的通用资源提供程序 API 端点。 中子需要通过利用 Nova API 中的微版本化来优雅地处理此问题。 中子将不频繁地轮询以发现 Nova 何时已升级，并在 API 可用时使用它。

与此同时，可以在中子中创建路由网络，但调度将不会意识到 IP 资源。 因此，如果 segment 耗尽了地址，当 Nova 尝试创建端口时，启动失败会发生到这些 segment。

最后，延迟 IP 分配用例将无法工作，因为 Nova 将拒绝使用在升级之前没有 IP 地址的端口。 不涉及延迟 IP 分配的用例将正常工作，直到遇到上述 IP 耗尽问题。

如果 Nova 升级而中子没有升级，则没有问题，因为路由提供程序网络和延迟 IP 地址端口是不可能的。

开发人员影响

无

实现

负责人

工作项

  • 在预调度阶段在 conductor 上从端口获取 segment_id（如果可用）。 使用该 segment_id 查找 IP 地址的资源提供程序。

  • 通过查看端口上的 ip_allocation 属性来允许延迟或无 IP 地址的端口。

  • 中子将管理 Nova 中的主机 aggregate 和资源池。 （中子是否充当 Nova API 的客户端？ 因此，它实际上不是 Nova 的工作项。）

依赖项

这依赖于上述 中子规范。 还依赖于 资源提供程序，这些资源提供程序已合并到 Nova 中，以及新创建的 为网络感知调度做准备的规范。

测试

所有新功能都将通过单元测试覆盖。 我们将着眼于创建一个多节点作业，该作业将在中子和 Nova 上运行，以测试路由网络。 它将包括专门针对此规范中提到的用例的测试。

文档影响

OpenStack 管理员指南将更新。

参考资料

历史

无