Network Data v2 - node ports and node network config

使用“Network Data v2”的目标是将网络资源的管理从 heat 堆栈中移出。模式规范 [1] 讨论了 network_data.yaml 格式以及管理网络、段和子网。本规范在此基础上，为可组合网络添加节点端口，并将节点网络配置操作移动到 baremetal/网络配置工作流中。

问题描述

目前，在 day 2 应用网络更改需要完整的堆栈更新，因为网络资源（如端口）由 heat 管理。为大规模部署创建端口也存在问题；单个节点 undercloud 上的 neutron 会不堪重负，并且难以限制 Heat 中的端口创建速率。作为使用建议的 ansible 模块进行端口创建性能的早期指标

性能统计：100 个节点 x 3 个网络 = 300 个端口

        4xCPU 1.8 GHz (8GB)             8x CPU 2.6 GHz (12GB)
        -------------------  --------------------------------
Concurr:                 10          20         10          4
........     ..............   .........  .........  .........
Create       real 5m58.006s   1m48.518s  1m51.998s  1m25.022s
Delete:      real 4m12.812s   0m47.475s  0m48.956s  1m19.543s
Re-run:      real 0m19.386s    0m4.389s   0m4.453s   0m4.977s

提议的变更

扩展 baremetal 配置工作流，该工作流在 overcloud 部署之前运行，以创建可组合网络的端口。baremetal 配置步骤已经为配置网络创建端口。将可组合网络的端口管理移动到此工作流将把所有端口管理整合到一个工作流中。

同时，让 baremetal 配置工作流执行 tripleo-ansible tripleo_network_config 角色，在节点配置完成后配置节点网络。

部署工作流将是

1. 操作员在 network data YAML 文件中定义可组合网络。

2. 操作员通过运行 openstack overcloud network provision 命令配置可组合网络，并将 network data YAML 文件作为输入提供。

3. 操作员在 baremetal 部署 YAML 文件中定义角色和节点。此 YAML 还定义了每个角色的网络。

4. 操作员通过运行 openstack overcloud node provision 命令部署 baremetal 节点。此步骤在 neutron 中创建端口，并使用 ansible 角色通过 os-net-config 应用网络配置（包括可组合网络）[2]。

5. 操作员通过运行 openstack overcloud deploy 命令部署 heat 堆栈，包括之前步骤执行的命令生成的环境文件。

6. 操作员执行 config-download 以在 overcloud 节点上安装和配置 openstack。（可选 - 仅当 overcloud 部署命令使用 ``-stack-only`` 执行时）

实现

负责人

主要负责人

Harald Jensås <hjensas@redhat.com>

Approver(s)

主要审批人

TODO

Implementation Details

baremetal YAML 定义将被扩展，在角色 defaults 以及每个实例中添加 networks 和 network_config 键，以支持 fixed_ip 寻址、手动预创建的端口资源以及每个节点的网络配置模板。

networks 将取代当前的 nic 键，直到 nic 键被弃用，两者可以同时使用，但不能同时使用两者。networks 中的网络将支持一个布尔键 vif，指示端口是否应附加到 Ironic。如果未指定带有 vif: true 的网络，将附加一个控制平面的隐式网络

- network: ctlplane
  vif: true

对于具有 vif: true 的网络，端口将由 metalsmith 创建。对于具有 vif: false（或未指定 vif）的网络，工作流将根据 YAML 定义在 neutron 中创建端口。

neutron 端口最初将标记有堆栈名称和实例主机名，这些标签用于幂等性。管理端口的 ansible 模块将获取所有带有相关标签的端口，然后根据 Baremetal YAML 定义中扩展的角色添加/删除端口。（主机名和堆栈名称标签也添加到此 tripleo-heat-templates 更改中创建的 heat 中的端口 [4]，以便在升级场景中采用 neutron 端口。）

此外，当可用时，端口将标记有 ironic 节点 uuid。完整的标签集如下所示。

{
  "port": {
    "name": "controller-1-External",
    "tags": ["tripleo_ironic_uuid=<IRONIC_NODE_UUID>",
             "tripleo_hostname=controller-1",
             "tripleo_stack_name=overcloud"],
  }
}

注意

在 baremetal 节点具有多个物理 NIC 的部署中，多个网络可以具有 vif: true，以便在 ironic 中附加 VIF 并正确绑定 neutron 端口。如果 Undercloud 上的 neutron 管理交换机，这将实现 Top-of-Rack 交换机配置的自动化。

overcloud 节点的端口数据映射将进入 tripleo-heat-tempaltes 中的 NodePortMap 参数。该映射将包含每个节点的一个子映射，以节点名称为键。最初，NodePortMap 将被替代的fake-port OS::TripleO::{{role.name}}::Ports::{{network.name}}Port 资源模板消耗。在最终实现中，可以扩展创建的环境文件，并且整个 OS::TripleO::{{role.name}} 资源可以替换为引用生成环境中参数的模板，即重新实现的 puppet/role.role.j2.yaml，不带服务器和端口资源。NodePortMap 将添加到由创建 overcloud 节点端口资源的工作流创建的overcloud-baremetal-deployed.yaml 中。

对于 vif: false 网络的网络端口，将由新的 ansible 模块 tripleo_overcloud_network_ports 管理，此角色的输入将是 tripleo_baremetal_expand_roles ansible 模块生成的实例定义列表。tripleo_baremetal_expand_roles ansible 模块将被扩展，以添加来自 baremetal 部署 YAML 定义的网络/子网信息。

baremetal 配置工作流将被扩展为写入 ansible 清单，我们应该尝试扩展 tripleo-ansible-inventory，以便 baremetal 配置工作流可以重用现有代码来创建清单。该清单将用于使用 triple-ansible tripleo_network_config ansible 角色配置已配置节点的网络。

Already Deployed Servers

Baremetal YAML 定义将用于描述预部署服务器的 baremetal 部署。在这种情况下，没有要更新的 Ironic 节点，没有要添加到端口标签的 ironic UUID，也没有要附加 VIF 的 ironic 节点。

所有端口（包括 ctlplane 端口）都将由 tripleo_overcloud_network_ports ansible 模块管理。描述带有预部署服务器的 Baremetal YAML 定义必须包含每个预部署服务器的 instance 条目。此条目的 managed 键将设置为 false。

已经部署的服务器可以具有与 tripleo 管理地址完全分离的管理地址。Baremetal YAML 定义可以扩展为携带用于此目的的 management_ip 字段。如果未提供 managment 地址，预部署实例的 ctlplane 网络条目必须配置 fixed_ip。

部署工作流将短路 managed: false 实例的 baremetal 配置。Baremetal YAML 定义可以定义已部署服务器实例和应通过 metalsmith 配置的实例的混合。请参阅 Example: Baremetal YAML for Already Deployed Servers。

YAML Examples

Example: Baremetal YAML definition with defaults properties

- name: Controller
  count: 1
  hostname_format: controller-%index%
  defaults:
    profile: control
    network_config:
      template: templates/multiple_nics/multiple_nics.j2
      physical_bridge_name: br-ex
      public_interface_name: nic1
      network_deployment_actions: ['CREATE']
      net_config_data_lookup: {}
    networks:
      - network: ctlplane
        vif: true
      - network: external
        subnet: external_subnet
      - network: internal_api
        subnet: internal_api_subnet
      - network: storage
        subnet: storage_subnet
      - network: storage_mgmt
        subnet: storage_mgmt_subnet
      - network: Tenant
        subnet: tenant_subnet
- name: Compute
  count: 1
  hostname_format: compute-%index%
  defaults:
    profile: compute
    network_config:
      template: templates/multiple_nics/multiple_nics.j2
      physical_bridge_name: br-ex
      public_interface_name: nic1
      network_deployment_actions: ['CREATE']
      net_config_data_lookup: {}
    networks:
      - network: ctlplane
        vif: true
      - network: internal_api
        subnet: internal_api_subnet
      - network: tenant
        subnet: tenant_subnet
      - network: storage
        subnet: storage_subnet

Example: Baremetal YAML definition with per-instance overrides

- name: Controller
  count: 1
  hostname_format: controller-%index%
  defaults:
    profile: control
    network_config:
      template: templates/multiple_nics/multiple_nics.j2
      physical_bridge_name: br-ex
      public_interface_name: nic1
      network_deployment_actions: ['CREATE']
      net_config_data_lookup: {}
      bond_interface_ovs_options:
    networks:
      - network: ctlplane
        vif: true
      - network: external
        subnet: external_subnet
      - network: internal_api
        subnet: internal_api_subnet
      - network: storage
        subnet: storage_subnet
      - network: storage_mgmt
        subnet: storage_mgmt_subnet
      - network: tenant
        subnet: tenant_subnet
  instances:
    - hostname: controller-0
      name: node00
      networks:
        - network: ctlplane
          vif: true
        - network: internal_api:
          fixed_ip: 172.21.11.100
    - hostname: controller-1
      name: node01
      networks:
        External:
          port: controller-1-external
    - hostname: controller-2
      name: node02
- name: ComputeLeaf1
  count: 1
  hostname_format: compute-leaf1-%index%
  defaults:
    profile: compute-leaf1
    networks:
      - network: internal_api
        subnet: internal_api_subnet
      - network: tenant
        subnet: tenant_subnet
      - network: storage
        subnet: storage_subnet
  instances:
    - hostname: compute-leaf1-0
      name: node03
      network_config:
        template: templates/multiple_nics/multiple_nics_dpdk.j2
        physical_bridge_name: br-ex
        public_interface_name: nic1
        network_deployment_actions: ['CREATE']
        net_config_data_lookup: {}
        num_dpdk_interface_rx_queues: 1
      networks:
        - network: ctlplane
          vif: true
        - network: internal_api
          fixed_ip: 172.21.12.105
        - network: tenant
          port: compute-leaf1-0-tenant
        - network: storage
          subnet: storage_subnet

Example: Baremetal YAML for Already Deployed Servers

- name: Controller
  count: 3
  hostname_format: controller-%index%
  defaults:
    profile: control
    network_config:
      template: templates/multiple_nics/multiple_nics.j2
    networks:
      - network: ctlplane
      - network: external
        subnet: external_subnet
      - network: internal_api
        subnet: internal_api_subnet
      - network: storage
        subnet: storage_subnet
      - network: storage_mgmt
        subnet: storage_mgmt_subnet
      - network: tenant
        subnet: tenant_subnet
    managed: false
  instances:
    - hostname: controller-0
      networks:
        - network: ctlplane
          fixed_ip: 192.168.24.10
    - hostname: controller-1
      networks:
        - network: ctlplane
          fixed_ip: 192.168.24.11
    - hostname: controller-2
      networks:
        - network: ctlplane
          fixed_ip: 192.168.24.12
- name: Compute
  count: 2
  hostname_format: compute-%index%
  defaults:
    profile: compute
    network_config:
      template: templates/multiple_nics/multiple_nics.j2
    networks:
      - network: ctlplane
      - network: internal_api
        subnet: internal_api_subnet
      - network: tenant
        subnet: tenant_subnet
      - network: storage
        subnet: storage_subnet
  instances:
    - hostname: compute-0
      managed: false
      networks:
        - network: ctlplane
          fixed_ip: 192.168.24.100
    - hostname: compute-1
      managed: false
      networks:
        - network: ctlplane
          fixed_ip: 192.168.24.101

Example: NodeNetworkDataMappings

NodePortMap:
  controller-0:
    ctlplane:
      ip_address: 192.168.24.9 (2001:DB8:24::9)
      ip_subnet: 192.168.24.9/24 (2001:DB8:24::9/64)
      ip_address_uri: 192.168.24.9 ([2001:DB8:24::9])
    internal_api:
      ip_address: 172.18.0.9 (2001:DB8:18::9)
      ip_subnet: 172.18.0.9/24 (2001:DB8:18::9/64)
      ip_address_uri: 172.18.0.9 ([2001:DB8:18::9])
    tenant:
      ip_address: 172.19.0.9 (2001:DB8:19::9)
      ip_subnet: 172.19.0.9/24 (2001:DB8:19::9/64)
      ip_address_uri: 172.19.0.9 ([2001:DB8:19::9])
  compute-0:
    ctlplane:
      ip_address: 192.168.24.15 (2001:DB8:24::15)
      ip_subnet: 192.168.24.15/24 (2001:DB8:24::15/64)
      ip_address_uri: 192.168.24.15 ([2001:DB8:24::15])
    internal_api:
      ip_address: 172.18.0.15 (2001:DB8:18::1)
      ip_subnet: 172.18.0.15/24 (2001:DB8:18::1/64)
      ip_address_uri: 172.18.0.15 ([2001:DB8:18::1])
    tenant:
      ip_address: 172.19.0.15 (2001:DB8:19::15)
      ip_subnet: 172.19.0.15/24 (2001:DB8:19::15/64)
      ip_address_uri: 172.19.0.15 ([2001:DB8:19::15])

Example: Ansible inventory

Controller:
  vars:
    role_networks:
      - External
      - InternalApi
      - Tenant
    role_networks_lower:
      External: external
      InternalApi: internal_api
      Tenant: tenant
    networks_all:
      - External
      - InternalApi
      - Tenant
    neutron_physical_bridge_name: br-ex
    neutron_public_interface_name: nic1
    tripleo_network_config_os_net_config_mappings: {}
    network_deployment_actions: ['CREATE', 'UPDATE']
    ctlplane_subnet_cidr: 24
    ctlplane_mtu: 1500
    ctlplane_gateway_ip: 192.168.24.254
    ctlplane_dns_nameservers: []
    dns_search_domains: []
    ctlplane_host_routes: {}
    internal_api_cidr: 24
    internal_api_gateway_ip: 172.18.0.254
    internal_api_host_routes: []
    internal_api_mtu: 1500
    internal_api_vlan_id: 20
    tenant_cidr: 24
    tenant_api_gateway_ip: 172.19.0.254
    tenant_host_routes: []
    tenant_mtu: 1500
  hosts:
    controller-0:
      ansible_host: 192.168.24.9
      ctlplane_ip: 192.168.24.9
      internal_api_ip: 172.18.0.9
      tenant_ip: 172.19.0.9
Compute:
  vars:
    role_networks:
      - InternalApi
      - Tenant
    role_networks_lower:
      InternalApi: internal_api
      Tenant: tenant
    networks_all:
      - External
      - InternalApi
      - Tenant
    neutron_physical_bridge_name: br-ex
    neutron_public_interface_name: nic1
    tripleo_network_config_os_net_config_mappings: {}
    network_deployment_actions: ['CREATE', 'UPDATE']
    ctlplane_subnet_cidr: 24
    ctlplane_mtu: 1500
    ctlplane_gateway_ip: 192.168.25.254
    ctlplane_dns_nameservers: []
    dns_search_domains: []
    ctlplane_host_routes: {}
    internal_api_cidr: 24
    internal_api_gateway_ip: 172.18.1.254
    internal_api_host_routes: []
    internal_api_mtu: 1500
    internal_api_vlan_id: 20
    tenant_cidr: 24
    tenant_api_gateway_ip: 172.19.1.254
    tenant_host_routes: []
    tenant_mtu: 1500
  hosts:
    compute-0:
      ansible_host: 192.168.25.15
      ctlplane_ip: 192.168.25.15
      internal_ip: 172.18.1.15
      tenant_ip: 172.19.1.15

TODO

• 约束验证，例如 BondInterfaceOvsOptions 使用 allowed_pattern: ^((?!balance.tcp).)*$ 确保不使用 balance-tcp 绑定模式，因为它已知会导致丢包。

工作项

1. 在 baremetal 配置后编写 ansible 清单

   创建 ansible 清单，类似于 config-download 创建的清单。ansible 清单对于将网络配置应用于已部署的节点是必需的。

   我们应该尝试扩展 tripleo-ansible-inventory，以便 baremetal 配置工作流可以重用现有代码来创建清单。

   工作流也应该运行 tripleo-ansible 角色 tripleo_create_admin 以创建tripleo-admin ansible 用户，这可能是有意义的。

2. 扩展 baremetal 配置工作流以创建 neutron 端口，并使用 tripleo_networks 映射更新 ironic 节点的 extra 字段。

3. baremetal 配置工作流需要一个预部署服务器选项，该选项使其不部署 baremetal 节点，仅创建网络端口。当使用此选项时，baremetal 部署 YAML 文件还将描述已配置的节点。

4. 使用 triple-ansible tripleo_network_config ansible 角色应用和验证网络配置。此步骤将集成到配置命令中。

5. 禁用并删除 tripleo-heat-templates 中可组合网络端口的管理。

6. 更改 Undercloud 和 Standalone 部署，以便在创建临时 heat 堆栈之前使用 tripleo_network_config ansible 角色应用网络配置。

测试

具有网络隔离的多节点 OVB CI 作业将被更新以测试新的工作流。

升级影响

在升级期间切换到使用在 heat 堆栈外部管理的网络端口，PortDeletionPolicy 必须在更新/升级准备步骤期间设置为 retain，以便在运行更新/升级收敛步骤时不会删除现有的 neutron 端口（这些端口将被预 heat 端口管理工作流采用）。

将节点网络配置从 tripleo-heat-templates 中移出需要手动（或脚本化）迁移由 heat 模板参数控制的设置到用于 baremetal/网络配置的输入文件。至少受以下参数影响

• NeutronPhysicalBridge

• NeutronPublicInterface

• NetConfigDataLookup

• NetworkDeploymentActions

将被弃用的参数

• NetworkConfigWithAnsible

• {{role.name}}NetworkConfigTemplate

• NetworkDeploymentActions

• {{role.name}}NetworkDeploymentActions

• BondInterfaceOvsOptions

• NumDpdkInterfaceRxQueues

• {{role.name}}LocalMtu

• NetConfigDataLookup

• DnsServers

• DnsSearchDomains

• ControlPlaneSubnetCidr

• HypervisorNeutronPublicInterface

• HypervisorNeutronPhysicalBridge

用于选择预定义 nic 配置模板的环境文件将不再有效。要使用的模板必须在定义 baremetal/network 部署的 YAML 文件中设置。这会影响以下环境文件

• environments/net-2-linux-bonds-with-vlans.j2.yaml

• environments/net-bond-with-vlans.j2.yaml

• environments/net-bond-with-vlans-no-external.j2.yaml

• environments/net-dpdkbond-with-vlans.j2.yaml

• environments/net-multiple-nics.j2.yaml

• environments/net-multiple-nics-vlans.j2.yaml

• environments/net-noop.j2.yaml

• environments/net-single-nic-linux-bridge-with-vlans.j2.yaml

• environments/net-single-nic-with-vlans.j2.yaml

• environments/net-single-nic-with-vlans-no-external.j2.yaml

文档影响

文档工作量巨大，需要逐步更新。至少，必须创建一个单独的页面来解释新的流程。

TripleO 文档需要在许多部分进行更新，包括

• TripleO OpenStack 部署

• 在 Overcloud 部署前配置 Baremetal

• 使用自定义网络进行部署

• 配置网络隔离

• 使用 L3 路由网络部署 Overcloud

替代方案

1. 不改变端口的创建方式

   在这种情况下，我们仍然使用 heat 创建端口，作为不做任何操作的替代方案。

2. 为可组合网络端口创建一个完全独立的流程

   一个可以在节点配置之前/之后运行的独立流程。它可以读取与 baremetal 配置相同的 YAML 格式，或者它可以拥有自己的 YAML 格式。

   这种方法的问题是，我们将失去在数据库中存储 neutron 端口和 baremetal 节点之间关系的可能性。也就是说，我们需要自己的数据库（一个文件）来维护这些关系。

   注意

   我们无论如何都需要为预部署服务器场景实现此流程，但与其创建一个完全独立的流程，baremetal 部署流程可以采用一个不配置节点的选项。

3. 在 ironic 中创建端口并将 neutron 端口绑定

   不要创建 ironic 不知道的端口，而是在 baremetal 服务中为 ironic 节点创建端口。

   问题是 ironic 没有虚拟端口的概念，因此我们必须要么在 ironic 中添加此支持，要么将 TripleO 切换为使用 neutron trunk 端口，要么创建假的 ironic 端口，这些端口实际上并不反映 baremetal 节点上的 NIC。（这个被放弃的 ironic 规范 [3] 讨论了一种虚拟端口支持方法，但它被放弃，转而支持 neutron trunk 端口。）

   每次 PTG 都会出现用更轻量级的 IPAM 解决方案替换 neutron 的建议。然而，将其与 ironic 和 neutron 适当集成以实现可组合网络所需的努力可能并不值得。

参考资料

[1]

审查：网络数据 v2 格式规范.

[2]

os-net-config.

[3]

关于 VLAN 感知 Baremetal 实例的被放弃的规范.

[4]

审查：向端口添加主机名和 stack_name 标签.