子网服务类型

RFE: https://bugs.launchpad.net/neutron/+bug/1544768

Launchpad 蓝图: https://blueprints.launchpad.net/neutron/+spec/service-subnets

当前为外部网络端口分配 IP 地址的方法，采用与内部网络相同的策略——从与网络关联的子网中选择一个 IP 地址。在这种情况下，所有子网都是平等的，无法给予一个子网比其他子网更高的优先级。

由于这些 IP 地址通常是可路由到互联网的，或者至少可以在它们所使用的数据中心内路由，因此应该被认为是稀缺资源，并谨慎分配。

此蓝图旨在更改分配策略，以更好地利用这种稀缺资源，仅将其用于必须具有可路由到互联网的 IP 地址的端口，并使用辅助子网为其他端口分配 IP 地址。

问题描述

在 Neutron 中，每个具有连接到外部网络的接口的路由器都会消耗外部网络上配置的子网中的一个（或多个）IP 地址。例如，在网络节点上，会为项目（也称为租户）的路由器分配一个 IP 地址，以便实例可以使用此单个 SNAT IP 地址访问外部网络。

在分布式（计算）节点上的路由器的情况下，如果它也连接到外部网络，则会创建一个单个浮动 IP (FIP) 命名空间，以便每个具有浮动 IP 地址的实例可以直接访问外部网络。浮动 IP 命名空间还会消耗外部子网中的一个 IP 地址，用于驻在该节点上的所有租户路由器，即使它从未使用于南北方向的流量路由——它主要用于可达性测试（例如——我能否访问该分布式路由器）。

在这种第二种情况下，没有理由不能使用来自不同辅助子网的 IP 地址作为 FIP 命名空间内的主要 IP 地址，以便仍然可以确认可达性，但不会影响公共 IP 地址的消耗。

此外，当路由器只是将数据包转发到传输网络，由另一个设备（例如运营商级的 NAT）进行进一步处理时，路由器无需执行 NAT，数据包只需遵循标准转发数据路径。因此，使用仅存在于数据中心内的子网是可行的。

在所有这些情况下，能够选择用于 IP 地址分配的子网，是运营商们非常希望的。

提议的变更

此规范建议向 Neutron 中的 Subnet 类对象添加一个新的逻辑项，称为“service_type”，这是一个列表属性，可以指定子网的使用类型。该类型必须是 Port 模型中“device_owner”字段的当前有效值之一（port[‘device_owner’]），例如

  • ‘network:floatingip_agent_gateway’

  • ‘network:router_gateway’

  • …

由于它是一个列表，因此可以包含多个值，以便为应从同一子网分配 IP 地址的多个 device_owner 类型指定 IP 地址。

此列表将实例化为包含 (subnet_id, service_type) 值行的新表，以便可以从 Subnets.id 进行连接，以确定与子网关联的 service_types。

当执行 IP 地址分配时，例如，当添加外部网关时，并且插件支持“service-type”扩展时，IPAM 驱动程序将从具有与端口的 device_owner 字段匹配的“service-type”的子网返回一个地址。

如果对于端口的 device_owner，不存在具有给定“service-type”的子网，或者所有匹配子网的 IP 地址池已耗尽，则回退到使用没有类型的子网进行 IP 地址分配。这保留了与现有部署的向后兼容性。

当所有子网都使用“service-type”创建时，由于不存在没有类型的子网，因此没有回退策略。这可用于强制仅从 device_owner 匹配的子网分配 IP 地址。

如果存在多个具有给定“service-type”的子网，或者既有匹配的子网，又有没有类型的子网，则将按照顺序进行尝试，首先尝试具有“service-type”匹配的子网。例如，对于浮动 IP 代理网关端口，优先级顺序将是 [‘network:floatingip_agent_gateway’, None]。

如果在端口创建或更新请求中明确指定了子网，则将跳过上述选择候选子网的逻辑。无论其“service-type”如何，指定的子网将是唯一的候选子网。

使用建议的数据模型，只需正确排序所有匹配的子网，将“service-type”子网放在前面，然后是无“service-type”子网，即可在一个查询中完成所有这些操作。

数据模型影响

  1. 添加了服务类型子网扩展

  2. 创建了一个新表，将子网 ID 与服务类型关联。它将具有列 (subnet_id, service_type)，其中 subnet_id 具有对 Subnets.id 的外键约束。

  3. 主键将是 (subnet_id, service_type)，以提供索引和唯一性。

REST API 影响

  • “service_type”将通过扩展 API 向用户公开。

  • 创建或更新具有 service-type 的子网的能力将

    限制为管理员用户，因为它只会影响外部网络上的 IP 分配。将进行验证以将值限制为扩展支持的已知值集。

  • 列出给定 service-type 的子网。

示例 REST 调用

POST /v2.0/subnets
{
      'subnet': {
          'network_id': '<NETWORK-ID>',
          'ip_version': 4,
          'cidr': '10.0.3.0/24',
          'allocation_pools': [{'start': '10.0.3.20', 'end': '10.0.3.150'}],
          'service_type': ['network:floatingip_agent_gateway']
      }
}

PUT /v2.0/subnets/SUBNET-ID/service_types/
{
    'service_type': ['network:floatingip_agent_gateway']
}

GET /v2.0/subnets?service_type='network:floatingip_agent_gateway'

命令行客户端影响

openstackclient 将添加一个新选项，例如

$ openstack subnet create {ARGS} –service-type SERVICE-TYPE SUBNET-NAME

安全影响

无。

通知影响

无。

其他最终用户影响

Horizon 需要至少在子网上公开 service_type 属性。

性能影响

几乎不会有性能影响，因为这应该只是 IPAM 代码中的一个额外的表连接。

IPv6 影响

此更改将平等地考虑 IPv4 和 IPv6。

其他部署者影响

升级代码时，部署者无需执行任何操作，直到他们希望使用此规范提供的功能为止。

升级代码后，新的或现有的部署可以通过将新的 Neutron 子网添加到现有的外部网络，或者根据需要更改该网络上现有子网的“service-type”来使用此新功能。

他们可能需要在机架顶部的交换机中更改配置，或者在现有的物理网络上进行辅助子网所需的其他操作。这项工作不在本规范的范围内。

开发人员影响

此更改将影响开发人员。此蓝图包含插件提供商需要查看并实施的 API 和模型更改。

社区影响

是的。此更改已在 ML 上讨论，在 Neutron 会议（尤其是 L3）上讨论，在中间周期以及设计峰会上讨论。

备选方案

另一种选择是不使用公共 IP 地址作为浮动 IP 地址，而是使用可路由到数据中心基础设施的 IP 地址。然后通过位于这两个网络之间的运营商级 NAT 设备来实现对公共互联网的访问。

实现

负责人

主要负责人

其他贡献者

请在此处添加您的姓名，并参加 L3 子团队会议，如果您想做出贡献。如果您的姓名在此处，但您没有时间做出贡献，请告诉我。本部分实际上只是我用来记录可以参与这项工作贡献者的便签。

工作项

  1. 子网扩展

    • 对于 ML2，使用多提供程序扩展数据模型。

    • 添加新的“Subnet_service_types”表

    • 将逻辑 service_type 值添加到 Subnet

    • API测试

  2. 客户端支持

  3. IPAM 支持

    • 在选择要分配给端口的 IP 地址时，IPAM 需要在选择子网时考虑 device_owner。

依赖项

无。

测试

Tempest 测试

未知

功能测试

未知

API 测试

  • 子网服务类型资源 (CRUD)

文档影响

是

用户文档

记录 Subnet 中该值的用法

开发人员文档

是

参考资料