网络功能虚拟化规划和配置指南

Red Hat OpenStack Platform 16.1

规划和配置网络功能虚拟化 (NFV) OpenStack 部署

OpenStack Documentation Team

摘要

本指南包含重要的规划信息,并描述了在 Red Hat OpenStack Platform 部署中用于网络功能虚拟化基础架构(NFVi)的单一根输入/输出虚拟化(SR-IOV)和数据平面开发套件(DPDK)的配置程序。

使开源包含更多

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。详情请查看 CTO Chris Wright 的信息

对红帽文档提供反馈

我们感谢您对文档提供反馈信息。与我们分享您的成功秘诀。

使用直接文档反馈(DDF)功能

使用 添加反馈 DDF 功能,用于特定句子、段落或代码块上的直接注释。

  1. Multi-page HTML 格式查看文档。
  2. 请确定您看到文档右上角的 反馈 按钮。
  3. 用鼠标指针高亮显示您想评论的文本部分。
  4. 添加反馈
  5. 添加反馈项中输入您的意见。
  6. 可选:添加您的电子邮件地址,以便文档团队可以联系您以讨论您的问题。
  7. Submit

第 1 章 NFV 概述

网络功能虚拟化(NFV)是一种在通用基础架构上虚拟化网络功能(如网络交换机)的软件解决方案。NFV 允许通信服务提供商脱离传统或专有硬件。

有关 NFV 概念的高级概述,请参阅 网络功能虚拟化产品指南

注意

OVS-DPDK 和 SR-IOV 配置取决于您的硬件和拓扑。本指南提供了 CPU 分配、内存分配和 NIC 配置可能因拓扑和用例而异的示例。

使用 Red Hat OpenStack Platform director 隔离特定的网络类型,如外部、项目、内部 API 等。您可以在一个网络接口上部署网络,或者通过多个主机网络接口进行分发。通过 Open vSwitch,您可以通过为单个网桥分配多个接口来创建绑定。使用模板文件在 Red Hat OpenStack Platform 安装中配置网络隔离。如果没有提供模板文件,则服务网络会在 provisioning 网络上部署。模板配置文件有两种类型:

  • network-environment.yaml - 此文件包含 overcloud 节点的子网和 IP 地址范围等网络详细信息。此文件还包含不同的设置,用于覆盖不同场景的默认值。
  • 主机网络模板,如 compute.yamlcontroller.yaml - 定义 overcloud 节点的网络接口配置。网络详情的值由 network-environment.yaml 文件提供。

这些 heat 模板文件位于 undercloud 节点上的 /usr/share/openstack-tripleo-heat-templates/

硬件要求和软件要求部分提供了有关如何使用 Red Hat OpenStack Platform director 为 NFV 计划和配置 heat 模板文件的更多详细信息。

注意

您可以编辑 YAML 文件来配置 NFV。有关 YAML 文件格式的介绍,请参阅 Nutshell 中的 YAML

第 2 章 硬件要求

本节介绍 NFV 的硬件要求。

有关 Red Hat OpenStack Platform 认证硬件的完整列表,请参阅 Red Hat OpenStack Platform 认证硬件

2.1. 测试的 NIC

有关 NFV 测试的 NIC 列表,请参阅红帽知识库解决方案 网络适配器 Fast Datapath 功能支持列表

如果您在 Mellanox ConnectX-4 或 ConnectX-5 网络接口上配置 OVS-DPDK,您必须在 compute-ovs-dpdk.yaml 文件中设置对应的内核驱动程序:

members
 - type: ovs_dpdk_port
    name: dpdk0
    driver: mlx5_core
    members:
    - type: interface
      name: enp3s0f0

2.2. 发现 NUMA 节点拓扑

在计划部署时,您必须了解 Compute 节点的 NUMA 拓扑,以对 CPU 和内存资源进行分区以获得最佳性能。要确定 NUMA 信息,请执行以下任务之一:

  • 启用硬件内省以从裸机节点中检索此信息。
  • 登录每个裸机恢复节点,以手动收集信息。
注意

您必须安装并配置 undercloud,然后才能通过硬件内省来检索 NUMA 信息。有关 undercloud 配置的更多信息,请参阅 Director 安装和使用指南

获取硬件内省详细信息

裸机服务 hardware-inspection-extras 功能默认启用,您可以使用它来检索 overcloud 配置的硬件详情。有关 undercloud.conf 文件中的 inspection_extras 参数的更多信息,请参阅配置 Director

例如,numa_topology 收集程序就是硬件检查额外功能的一部分,包括每个 NUMA 节点的以下信息:

  • RAM(单位为 KB)
  • 物理 CPU 内核数和同级线程数
  • 和 NUMA 节点关联的 NIC

要获得以上列出的信息,请使用裸机节点的 UUID 替换 <UUID> 来完成以下命令:

# openstack baremetal introspection data save <UUID> | jq .numa_topology

以下示例显示获取的裸机节点 NUMA 信息:

{
  "cpus": [
    {
      "cpu": 1,
      "thread_siblings": [
        1,
        17
      ],
      "numa_node": 0
    },
    {
      "cpu": 2,
      "thread_siblings": [
        10,
        26
      ],
      "numa_node": 1
    },
    {
      "cpu": 0,
      "thread_siblings": [
        0,
        16
      ],
      "numa_node": 0
    },
    {
      "cpu": 5,
      "thread_siblings": [
        13,
        29
      ],
      "numa_node": 1
    },
    {
      "cpu": 7,
      "thread_siblings": [
        15,
        31
      ],
      "numa_node": 1
    },
    {
      "cpu": 7,
      "thread_siblings": [
        7,
        23
      ],
      "numa_node": 0
    },
    {
      "cpu": 1,
      "thread_siblings": [
        9,
        25
      ],
      "numa_node": 1
    },
    {
      "cpu": 6,
      "thread_siblings": [
        6,
        22
      ],
      "numa_node": 0
    },
    {
      "cpu": 3,
      "thread_siblings": [
        11,
        27
      ],
      "numa_node": 1
    },
    {
      "cpu": 5,
      "thread_siblings": [
        5,
        21
      ],
      "numa_node": 0
    },
    {
      "cpu": 4,
      "thread_siblings": [
        12,
        28
      ],
      "numa_node": 1
    },
    {
      "cpu": 4,
      "thread_siblings": [
        4,
        20
      ],
      "numa_node": 0
    },
    {
      "cpu": 0,
      "thread_siblings": [
        8,
        24
      ],
      "numa_node": 1
    },
    {
      "cpu": 6,
      "thread_siblings": [
        14,
        30
      ],
      "numa_node": 1
    },
    {
      "cpu": 3,
      "thread_siblings": [
        3,
        19
      ],
      "numa_node": 0
    },
    {
      "cpu": 2,
      "thread_siblings": [
        2,
        18
      ],
      "numa_node": 0
    }
  ],
  "ram": [
    {
      "size_kb": 66980172,
      "numa_node": 0
    },
    {
      "size_kb": 67108864,
      "numa_node": 1
    }
  ],
  "nics": [
    {
      "name": "ens3f1",
      "numa_node": 1
    },
    {
      "name": "ens3f0",
      "numa_node": 1
    },
    {
      "name": "ens2f0",
      "numa_node": 0
    },
    {
      "name": "ens2f1",
      "numa_node": 0
    },
    {
      "name": "ens1f1",
      "numa_node": 0
    },
    {
      "name": "ens1f0",
      "numa_node": 0
    },
    {
      "name": "eno4",
      "numa_node": 0
    },
    {
      "name": "eno1",
      "numa_node": 0
    },
    {
      "name": "eno3",
      "numa_node": 0
    },
    {
      "name": "eno2",
      "numa_node": 0
    }
  ]
}

2.3. BIOS 设置

下表描述了 NFV 所需的 BIOS 设置:

注意

您必须在 BIOS 中启用 SR-IOV 全局和 NIC 设置,否则带有 SR-IOV Compute 节点的 Red Hat OpenStack Platform (RHOSP)部署将失败。

表 2.1. BIOS 设置

参数设置

C3 Power State

已禁用。

C6 Power State

已禁用。

MLC Streamer

已启用。

MLC Spacial Prefetcher

已启用。

DCU Data Prefetcher

已启用。

DCA

已启用。

CPU Power 和性能

性能。

内存 RAS 和 Performance Config → NUMA Optimized

已启用。

turbo Boost

在需要确定性能的 NFV 部署中禁用。
在所有其他场景中启用。

VT-d

如果需要 VFIO 功能,则启用了 Intel 卡。

NUMA 内存交集

Disabled

在使用 intel_idle 驱动程序的处理器上,Red Hat Enterprise Linux 可以忽略 BIOS 设置并重新启用处理器 C-state。

您可以通过在内核引导命令行中指定键值对 intel_idle .max_cstate=0 来禁用 intel_idle,而是使用 acpi_ idle 驱动程序。

通过检查 current_driver 的内容来确认处理器正在使用 acpi_idle 驱动程序:

# cat /sys/devices/system/cpu/cpuidle/current_driver
acpi_idle
注意

更改驱动程序后会出现一些延迟,因为它需要时间进行 Tuned 守护进程启动。但是,在 Tuned 加载后,处理器不使用更深入的 C-state。

第 3 章 软件要求

本节介绍 NFV 所需的受支持配置和驱动程序以及订阅详情。

3.1. 注册并启用软件仓库

要安装 Red Hat OpenStack Platform,您必须使用 Red Hat Subscription Manager 注册 Red Hat OpenStack Platform director,并订阅所需的频道。有关注册和更新 undercloud 的更多信息,请参阅 注册您的系统

流程

  1. 在 Content Delivery Network 中注册您的系统,在提示时输入您的客户门户网站用户名和密码。

    [stack@director ~]$ sudo subscription-manager register
  2. 确定 Red Hat OpenStack Platform director 的权利池 ID,例如来自以下命令和输出的 {Pool ID}:

    [stack@director ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
    Subscription Name:   Name of SKU
    Provides:            Red Hat Single Sign-On
                         Red Hat Enterprise Linux Workstation
                         Red Hat CloudForms
                         Red Hat OpenStack
                         Red Hat Software Collections (for RHEL Workstation)
                         Red Hat Virtualization
    SKU:                 SKU-Number
    Contract:            Contract-Number
    Pool ID:             {Pool-ID}-123456
    Provides Management: Yes
    Available:           1
    Suggested:           1
    Service Level:       Support-level
    Service Type:        Service-Type
    Subscription Type:   Sub-type
    Ends:                End-date
    System Type:         Physical
  3. 在以下命令中包括 池 ID 值来附加 Red Hat OpenStack Platform 16.1 权利。

    [stack@director ~]$ sudo subscription-manager attach --pool={Pool-ID}-123456
  4. 禁用默认存储库。

    subscription-manager repos --disable=*
  5. 使用 NFV 为 Red Hat OpenStack Platform 启用所需的存储库。

    $ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-eus-rpms \
    --enable=rhel-8-for-x86_64-appstream-eus-rpms \
    --enable=rhel-8-for-x86_64-highavailability-eus-rpms \
    --enable=ansible-2.9-for-rhel-8-x86_64-rpms \
    --enable=openstack-16.1-for-rhel-8-x86_64-rpms \
    --enable=rhel-8-for-x86_64-nfv-rpms \
    --enable=advanced-virt-for-rhel-8-x86_64-rpms \
    --enable=fast-datapath-for-rhel-8-x86_64-rpms
  6. 更新您的系统,以便具有最新的基本系统软件包。

    [stack@director ~]$ sudo dnf update -y
    [stack@director ~]$ sudo reboot
注意

要注册 overcloud 节点,请参阅 基于 Ansible 的注册

3.2. NFV 部署支持的配置

Red Hat OpenStack Platform (RHOSP)支持以下 NFV 部署,使用 director:

  • 单根 I/O 虚拟化(SR-IOV)
  • Open vSwitch 带有 Data Plane Development Kit (OVS-DPDK)

另外,您可以使用以下任何功能部署 RHOSP:

不支持使用 Open Virtual Network (OVN)作为默认软件定义型网络(SDN)解决方案进行 RHOSP NFV 部署。RHOSP 16.1.4 中通常提供以下 RHOSP NFV OVN 配置:

  • OVN 和 OVS-DPDK 共存 SR-IOV
  • 带有 OVS TC 流卸载的 OVN

3.2.1. 使用 OVS 机制驱动程序部署 RHOSP

使用 OVS 机制驱动程序部署 RHOSP:

流程

  1. 修改 containers-prepare-parameter.yaml 文件,使 neutron_driver 参数设置为 ovs

    parameter_defaults:
      ContainerImagePrepare:
      - push_destination: true
        set:
         neutron_driver: ovs
         ...
  2. neutron-ovs.yaml 环境文件包含在 /usr/share/openstack-tripleo-heat-templates/environments/services 目录中。

    TEMPLATES=/usr/share/openstack-tripleo-heat-templates
    
    openstack overcloud deploy --templates \
    -e ${TEMPLATES}/environments/network-environment.yaml \
    -e ${TEMPLATES}/environments/network-isolation.yaml \
    -e ${TEMPLATES}/environments/services/neutron-ovs.yaml \
    -e ${TEMPLATES}/environments/services/neutron-ovs-dpdk.yaml \
    -e ${TEMPLATES}/environments/services/neutron-sriov.yaml \
    -e /home/stack/containers-prepare-parameter.yaml

3.2.2. 使用 OVS-DPDK 和 SR-IOV 部署 OVN

注意

此 RHOSP NFV OVN 配置在 RHOSP 16.1.4 中正式发布。

在与 OVN 相同的节点上部署 DPDK 和 SRIOV 虚拟机:

流程

  1. 生成 ComputeOvsDpdkSriov 角色:

    openstack overcloud roles generate -o roles_data.yaml Controller ComputeOvsDpdkSriov
  2. OS::TripleO::Services::OVNMetadataAgent 添加到 Controller 角色。
  3. 使用 resource_registry 参数添加 OVS-DPDK 的自定义资源:

    resource_registry:
        # Specify the relative/absolute path to the config files you want to use for override the default.
        OS::TripleO::ComputeOvsDpdkSriov::Net::SoftwareConfig:
          nic-configs/computeovsdpdksriov.yaml
        OS::TripleO::Controller::Net::SoftwareConfig:
          nic-configs/controller.yaml
  4. 在 parameter_defaults 部分中,将隧道类型参数的值编辑为 geneve

    NeutronTunnelTypes: 'geneve'
    NeutronNetworkType: ['geneve', 'vlan']
  5. 可选:如果您使用集中式路由模型,禁用分布式虚拟路由(DVR):

    NeutronEnableDVR: false
  6. parameters_defaults 下,设置网桥映射:

     # The OVS logical-to-physical bridge mappings to use.
      NeutronBridgeMappings: "datacentre:br-ex,data1:br-link0,data2:br-link1"
  7. computeovsdpdksriov.yaml 文件中配置网络接口:

      - type: ovs_user_bridge
        name: br-link0
        use_dhcp: false
        ovs_extra:
         - str_replace:
           template: set port br-link0 tag=_VLAN_TAG_
           params:
            _VLAN_TAG_:
             get_param: TenantNetworkVlanID
        addresses:
         - ip_netmask:
           get_param: TenantIpSubnet
        members:
        - type: ovs_dpdk_port
          name: br-link0-dpdk-port0
          rx_queue: 1
          members:
          - type: interface
            name: eno3
      - type: sriov_pf
        name: eno4
        use_dhcp: false
        numvfs: 5
        defroute: false
        nm_controlled: true
        hotplug: true
        promisc: false
  8. 在部署脚本中包含以下 yaml 文件:

    • neutron-ovn-dpdk.yaml
    • neutron-ovn-sriov.yaml
注意

Open Virtual Networking (OVN)是 Red Hat OpenStack Platform 16.1 中的默认网络机制驱动程序。如果要将 OVN 与分布式虚拟路由 (DVR) 搭配使用,则必须在 openstack overcloud deploy 命令中包含 environments/services/neutron-ovn-dvr-ha.yaml 文件。如果要在没有 DVR 的情况下使用 OVN,则必须在 openstack overcloud deploy 命令中包含 environment/services/neutron-ovn-ha.yaml 文件,并将 NeutronEnableDVR 参数设置为 false。如果要将 OVN 与 SR-IOV 搭配使用,则必须包括 environments/services/neutron-ovn-sriov.yaml 文件作为 openstack overcloud deploy 命令中的最后一个 OVN 环境文件。

3.2.3. 使用 OVS TC 流卸载部署 OVN

在与 OVN 相同的节点上部署 OVS TC Flower 卸载。

注意

此 RHOSP NFV OVN 配置在 RHOSP 16.1.4 中正式发布。

注意

Red Hat Enterprise Linux 流量控制(TC)子系统不支持连接跟踪(conntrack)帮助程序或应用程序层网关(ALG)。因此,如果您使用 ALG,则必须禁用 TC Flower 卸载。

流程

  1. 生成 ComputeOvsDpdkSriov 角色:

    openstack overcloud roles generate -o roles_data.yaml ControllerSriov ComputeSriov
  2. 配置与部署相关的 physical_network 参数设置。

    • 对于 VLAN,请在部署后将 physical_network 参数设置为您在 neutron 中创建的网络名称。将此值用于 NeutronBridgeMappings 参数。
    • 在特定于角色的参数下,如 ComputeSriovOffloadParameters,请确保 OvsHwOffload 参数的值为 true

      parameter_defaults:
        NeutronBridgeMappings: 'datacentre:br-ex,tenant:br-offload'
        NeutronNetworkVLANRanges: 'tenant:502:505'
        NeutronFlatNetworks: 'datacentre,tenant'
        NeutronPhysicalDevMappings:
          - tenant:ens1f0
          - tenant:ens1f1
      
        NovaPCIPassthrough:
        - address: "0000:17:00.1"
          physical_network: "tenant"
        - address: "0000:3b:00.1"
          physical_network: "tenant"
        NeutronTunnelTypes: ''
        NeutronNetworkType: 'vlan'
        ComputeSriovOffloadParameters:
          OvsHwOffload: True
          KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32 intel_iommu=on iommu=pt isolcpus=1-11,13-23"
          IsolCpusList: "1-11,13-23"
          NovaReservedHostMemory: 4096
          NovaComputeCpuDedicatedSet: ['1-11','13-23']
          NovaComputeCpuSharedSet: ['0','12']
  3. computeovsdpdksriov.yaml 文件中配置网络接口:

     - type: ovs_bridge
      name: br-offload
      mtu: 9000
      use_dhcp: false
      addresses:
      - ip_netmask:
         get_param: TenantIpSubnet
      members:
      - type: linux_bond
        name: bond-pf
        bonding_options: "mode=active-backup miimon=100"
        members:
        - type: sriov_pf
          name: ens1f0
          numvfs: 3
          primary: true
          promisc: true
          use_dhcp: false
          defroute: false
          link_mode: switchdev
        - type: sriov_pf
          name: ens1f1
          numvfs: 3
          promisc: true
          use_dhcp: false
          defroute: false
          link_mode: switchdev
  4. 在部署脚本中包含以下 yaml 文件:

    • ovs-hw-offload.yaml
    • neutron-ovn-sriov.yaml

       TEMPLATES_HOME=”/usr/share/openstack-tripleo-heat-templates”
          CUSTOM_TEMPLATES=”/home/stack/templates”
      
          openstack overcloud deploy --templates \
            -r ${CUSTOM_TEMPLATES}/roles_data.yaml \
            -e ${TEMPLATES_HOME}/environments/services/neutron-ovn-sriov.yaml \
            -e ${TEMPLATES_HOME}/environments/ovs-hw-offload.yaml \
            -e ${CUSTOM_TEMPLATES}/network-environment.yaml

3.3. 支持的驱动程序

有关支持的驱动程序的完整列表,请参阅 Red Hat OpenStack Platform 中的组件、插件和驱动程序支持

有关使用 NFV 的 Red Hat OpenStack Platform 部署测试的 NIC 列表,请参阅测试的 NIC

3.4. 与第三方软件兼容

有关与 Red Hat OpenStack Platform 执行的已测试、支持和认证的完整产品和服务列表,请参阅 与 Red Hat OpenStack Platform 兼容的第三方软件。您可以根据产品版本和软件类别过滤列表。

有关与 Red Hat Enterprise Linux 一起执行测试、支持和认证的完整产品和服务列表,请参阅与 Red Hat Enterprise Linux 兼容的第三方软件。您可以根据产品版本和软件类别过滤列表。

第 4 章 网络注意事项

undercloud 主机至少需要以下网络:

  • Provisioning 网络 - 提供 DHCP 和 PXE 引导功能,以帮助发现要在 overcloud 中使用的裸机系统。
  • 外部网络 - 单独的网络,用于远程连接所有节点。连接到此网络的接口需要可路由 IP 地址(静态定义)或者从外部 DHCP 服务动态生成。

最小 overcloud 网络配置包括以下 NIC 配置:

  • 单 NIC 配置 - 一个 NIC 在原生 VLAN 中用于 Provisioning 网络,并用于 tagged VLAN(使用子网处理不同的 overcloud 网络类型)。
  • dual NIC 配置 - 一个 NIC 用于 provisioning 网络,另一个用于外部网络的 NIC。
  • dual NIC 配置 - 一个 NIC 用于原生 VLAN 上的 provisioning 网络,另一个用于使用子网进行不同 overcloud 网络类型的 VLAN 的 NIC。
  • 多 NIC 配置 - 每个 NIC 都使用一个子网来分别处理 overcloud 中不同的网络类型。

有关网络要求的更多信息,请参阅 网络要求

第 5 章 规划 SR-IOV 部署

根据您的 Compute 节点硬件设置单个参数,为 NFV 优化单根 I/O 虚拟化(SR-IOV)部署。

请参阅 发现您的 NUMA 节点拓扑,以评估您的硬件对 SR-IOV 参数的影响。

5.1. SR-IOV 部署的硬件分区

要使用 SR-IOV 实现高性能,请在主机和客户机之间分区资源。

OpenStack NFV Hardware Capacities 464931 0118 SR IOV

典型的拓扑包括每个 NUMA 节点的 14 个核心,位于双插槽 Compute 节点上。支持超线程(HT)和非HT 内核。每个内核都有两个同级线程。个核心专用于每个 NUMA 节点上的主机。虚拟网络功能(VNF)处理 SR-IOV 接口绑定。所有中断请求(IRQ)在主机内核上路由。VNF 内核专用于 VNF。它们提供与其他 VNF 隔离以及与主机分开的隔离。每个 VNF 都必须在单个 NUMA 节点上使用资源。VNF 使用的 SR-IOV NIC 还必须与同一 NUMA 节点关联。此拓扑没有虚拟化开销。主机、OpenStack Networking (neutron)和计算(nova)配置参数在单一文件中公开,以简化、一致性,并避免严重隔离造成的,从而导致抢占和数据包丢失。主机和虚拟机隔离取决于 调优配置集,它根据隔离 CPU 列表定义引导参数和任何 Red Hat OpenStack Platform 修改。

5.2. NFV SR-IOV 部署的拓扑

以下镜像有两个 VNF,各自带有 mgt 和 data plane 接口代表的管理接口。管理界面可以管理 ssh 访问,以此类推。data plane 接口将 VNF 绑定到 DPDK,以确保高可用性,因为 VNF 使用 DPDK 库绑定 data plane 接口。该镜像还有两个提供商网络用于冗余。Compute 节点有两个常规 NIC 绑定在一起,并在 VNF 管理和红帽 OpenStack Platform API 管理间共享。

NFV SR-IOV 部署

该镜像显示了在应用级别使用 DPDK 的 VNF,并可访问 SR-IOV 虚拟功能(VF)和物理功能(PF),以便根据 fabric 配置获得更高的可用性或性能。DPDK 提高了性能,而 VF/PF DPDK 绑定支持故障转移和高可用性。VNF 供应商必须确保 DPDK 轮询模式驱动程序(PMD)支持作为 VF/PF 公开的 SR-IOV 卡。管理网络使用 OVS,因此 VNF 会使用标准 virtIO 驱动程序查看 mgmt 网络设备。您可以使用该设备最初连接到 VNF,并确保 DPDK 应用绑定两个 VF/PF。

5.2.1. 没有 HCI 的 NFV SR-IOV 拓扑

在以下镜像中观察没有超融合基础架构(HCI)的 SR-IOV 的拓扑。它由具有 1 Gbps NIC 和 director 节点的计算和控制器节点组成。

没有 HCI 的 NFV SR-IOV 拓扑

第 6 章 部署 SR-IOV 技术

在 Red Hat OpenStack Platform NFV 部署中,通过单一根 I/O 虚拟化(SR-IOV)配置从实例直接访问到通过虚拟资源的共享 PCIe 资源时,您可以通过单个根 I/O 虚拟化(SR-IOV)实现更高的性能。

6.1. 前提条件

注意

不要手动编辑 director heat 模板修改的 /etc/tuned/cpu-partitioning-variables.conf 中的任何值。

6.2. 配置 SR-IOV

要使用单一根 I/O 虚拟化(SR-IOV)部署 Red Hat OpenStack Platform (RHOSP),配置具有实例可以请求直接访问的 SR-IOV 功能的共享 PCIe 资源。

注意

以下 CPU 分配、内存分配和 NIC 配置是示例,可能与您的用例不同。

流程

  1. stack 用户的身份登录 undercloud。
  2. Source stackrc 文件:

    [stack@director ~]$ source ~/stackrc
  3. 生成名为 roles_data_compute_sriov.yaml 的新角色数据文件,其中包含 ControllerComputeSriov 角色:

    (undercloud)$ openstack overcloud roles \
     generate -o /home/stack/templates/roles_data_compute_sriov.yaml \
     Controller ComputeSriov

    ComputeSriov 是您的 RHOSP 安装提供的自定义角色,除了默认的计算服务外,还包括 NeutronSriovAgentNeutronSriovHostConfig 服务。

  4. 要准备 SR-IOV 容器,在生成 overcloud_images.yaml 文件时包括 neutron-sriov.yamlroles_data_compute_sriov.yaml 文件。

    $ sudo openstack tripleo container image prepare \
      --roles-file ~/templates/roles_data_compute_sriov.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-sriov.yaml \
      -e ~/containers-prepare-parameter.yaml \
      --output-env-file=/home/stack/templates/overcloud_images.yaml

    如需有关容器镜像准备的更多信息,请参阅 Director 安装和使用指南中的准备容器镜像

  5. 在环境文件目录中,创建 /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml 文件的副本:

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml /home/stack/templates/network-environment-sriov.yaml
  6. 在您的 network-environment-sriov.yaml 文件的 parameter_defaults 下添加以下参数,为您的集群和硬件配置 SR-IOV 节点:

      NeutronNetworkType: 'vlan'
      NeutronNetworkVLANRanges:
        - tenant:22:22
        - tenant:25:25
      NeutronTunnelTypes: ''
  7. 要确定每个 PCI 设备类型的 vendor_idproduct_id,请在具有 PCI 卡的物理服务器上使用以下命令之一:

    • 要从部署的 overcloud 返回 vendor_idproduct_id,请使用以下命令:

      # lspci -nn -s  <pci_device_address>
      3b:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ [<vendor_id>: <product_id>] (rev 02)
    • 如果您还没有部署 overcloud,要返回物理功能(PF)的 vendor_idproduct_id,请使用以下命令:

      (undercloud) [stack@undercloud-0 ~]$ openstack baremetal introspection data save <baremetal_node_name> | jq '.inventory.interfaces[] | .name, .vendor, .product'
  8. network-environment-sriov.yaml 文件中为 SR-IOV 计算节点配置特定于角色的参数:

      ComputeSriovParameters:
        IsolCpusList: "1-19,21-39"
        KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=1-19,21-39"
        TunedProfileName: "cpu-partitioning"
        NeutronBridgeMappings:
          - tenant:br-link0
        NeutronPhysicalDevMappings:
          - tenant:p7p1
        NovaComputeCpuDedicatedSet: '1-19,21-39'
        NovaReservedHostMemory: 4096
    注意

    NovaVcpuPinSet 参数现已弃用,它被用于专用固定工作负载的 NovaComputeCpuDedicatedSet 替代。

  9. network-environment-sriov.yaml 文件中为 SR-IOV 计算节点配置 PCI 透传设备:

      ComputeSriovParameters:
        ...
        NovaPCIPassthrough:
          - vendor_id: "<vendor_id>"
            product_id: "<product_id>"
            address: <NIC_address>
            physical_network: "<physical_network>"
        ...
    • <vendor_id > 替换为 PCI 设备的供应商 ID。
    • <product_id > 替换为 PCI 设备的产品 ID。
    • <NIC_address > 替换为 PCI 设备的地址。有关如何配置 address 参数的详情,请参考 Configuring the Compute Service for Instance Creation 指南中的 Guidelines for configuring NovaPCIPassthrough 部分。
    • 使用 PCI 设备所在物理网络的名称替换 <physical_network>

      注意

      当您配置 PCI 透传时,不要使用 devname 参数,因为 NIC 的设备名称可能会改变。要在 PF 上创建网络服务(neutron)端口,请指定 vendor_idproduct_id,以及 NovaPCIPassthrough 中的 PCI 设备地址,并使用 --vnic-type direct-physical 选项创建端口。要在虚拟功能(VF)上创建网络服务端口,请在 NovaPCIPassthrough 中指定 vendor_idproduct_id,并使用 --vnic-type direct 选项创建端口。vendor_idproduct_id 参数的值可能会在物理功能(PF)和 VF 上下文之间有所不同。有关如何配置 NovaPCIPassthrough 的更多信息,请参阅 Configuring the Compute Service for Instance Creation 指南中的 Guidelines for configuring NovaPCIPassthrough

  10. compute.yaml 网络配置模板中配置启用的 SR-IOV 接口。要创建 SR-IOV VF,将接口配置为独立 NIC:

                 - type: sriov_pf
                    name: p7p3
                    mtu: 9000
                    numvfs: 10
                    use_dhcp: false
                    defroute: false
                    nm_controlled: true
                    hotplug: true
                    promisc: false
    
                  - type: sriov_pf
                    name: p7p4
                    mtu: 9000
                    numvfs: 10
                    use_dhcp: false
                    defroute: false
                    nm_controlled: true
                    hotplug: true
                    promisc: false
    注意

    numvfs 参数替换网络配置 模板中的 NeutronSriovNum VFs 参数。部署后,红帽不支持修改 NeutronSriovNumVFs 参数或 numvfs 参数。如果在部署后修改任何参数,则可能会导致在该 PF 上有 SR-IOV 端口的运行实例中断。在这种情况下,您必须硬重启这些实例,使 SR-IOV PCI 设备再次可用。

  11. 确保默认过滤器列表包含值 AggregateInstanceExtraSpecsFilter

    NovaSchedulerDefaultFilters: ['AvailabilityZoneFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','AggregateInstanceExtraSpecsFilter']
  12. 运行 overcloud_deploy.sh 脚本。

6.3. NIC 分区

此功能通常通过 Red Hat OpenStack Platform (RHOSP) 16.1.2 提供,并在 Intel Fortville NIC 和 Mellanox CX-5 NIC 上进行验证。

您可以配置单个根 I/O 虚拟化(SR-IOV),以便 RHOSP 主机可以使用虚拟功能(VF)。

当您将单个高速 NIC 分区到多个 VF 时,您可以将 NIC 用于 control 和 data plane 流量。

流程

  1. 为您选择的角色打开 NIC 配置文件。
  2. 为接口类型 sriov_pf 添加条目以配置主机可以使用的物理功能:

            - type: sriov_pf
                name: <interface name>
                use_dhcp: false
                numvfs: <number of vfs>
                promisc: <true/false> #optional (Defaults to true)
    注意

    numvfs 参数替换网络配置 模板中的 NeutronSriovNum VFs 参数。部署后,红帽不支持修改 NeutronSriovNumVFs 参数或 numvfs 参数。如果在部署后修改任何参数,则可能会导致在该物理功能(PF)上运行 SR-IOV 端口的实例中断。在这种情况下,您必须硬重启这些实例,使 SR-IOV PCI 设备再次可用。

  3. 为接口类型 sriov_vf 添加条目来配置主机可以使用的虚拟功能:

     - type: <bond_type>
       name: internal_bond
       bonding_options: mode=<bonding_option>
       use_dhcp: false
       members:
       - type: sriov_vf
           device: <pf_device_name>
           vfid: <vf_id>
       - type: sriov_vf
           device:  <pf_device_name>
           vfid: <vf_id>
    
     - type: vlan
       vlan_id:
         get_param: InternalApiNetworkVlanID
       spoofcheck: false
       device: internal_bond
       addresses:
       - ip_netmask:
           get_param: InternalApiIpSubnet
       routes:
         list_concat_unique:
         - get_param: InternalApiInterfaceRoutes
    • <bond_type > 替换为所需的绑定类型,例如 linux_bond。您可以为其他绑定应用 VLAN 标签,如 ovs_bond
    • <bonding_option > 替换为以下支持的绑定模式之一:

      • active-backup
      • balance-slb

        注意

        不支持 LACP 绑定。

    • members 部分中,将 sriov_vf 指定为到 bond 的接口类型。

      注意

      如果您使用 OVS 网桥作为接口类型,您可以在 sriov_pf 设备的 sriov_vf 上配置一个 OVS 网桥。单个 sriov_pf 设备中的多个 OVS 网桥可能会导致 VF 间的数据包重复,并降低性能。

    • <pf_device_name > 替换为 PF 设备的名称。
    • 如果使用 linux_bond,则必须分配 VLAN 标签。
    • <vf_id > 替换为 VF 的 ID。适用的 VF ID 范围从零开始,结尾是 VFs减一的最大数量。
  4. 禁用 spoof 检查,并在 sriov_vf for linux_bond 通过 VF 应用 VLAN 标签。
  5. 要为实例保留 VF,请在环境文件中包括 NovaPCIPassthrough 参数,例如:

    NovaPCIPassthrough:
     - address: "0000:19:0e.3"
       trusted: "true"
       physical_network: "sriov1"
     - address: "0000:19:0e.0"
       trusted: "true"
       physical_network: "sriov2"

    director 识别主机 VF,并生成可供实例可用的 VF 的 PCI 地址。

  6. 在所有需要 NIC 分区的节点上启用 IOMMU。例如,如果要将 NIC 分区用于 Compute 节点,请使用该角色的 KernelArgs 参数启用 IOMMU。

    parameter_defaults:
      ComputeParameters:
        KernelArgs: "intel_iommu=on iommu=pt"
  7. 将角色文件和环境文件添加到堆栈中与其他环境文件一起部署 overcloud:

    (undercloud)$ openstack overcloud deploy --templates \
      -r os-net-config.yaml
      -e [your environment files] \
      -e /home/stack/templates/<compute_environment_file>.yaml

NIC 分区配置示例

  • 要通过 VF 配置 Linux 绑定,禁用 spoofcheck,并将 VLAN 标签应用到 sriov_vf

    - type: linux_bond
      name: bond_api
      bonding_options: "mode=active-backup"
      members:
        - type: sriov_vf
          device: eno2
          vfid: 1
          vlan_id:
            get_param: InternalApiNetworkVlanID
          spoofcheck: false
        - type: sriov_vf
          device: eno3
          vfid: 1
          vlan_id:
            get_param: InternalApiNetworkVlanID
          spoofcheck: false
      addresses:
        - ip_netmask:
          get_param: InternalApiIpSubnet
      routes:
        list_concat_unique:
        - get_param: InternalApiInterfaceRoutes
  • 使用以下示例在 VF 上配置 OVS 网桥:

    - type: ovs_bridge
      name: br-bond
      use_dhcp: true
      members:
        - type: vlan
          vlan_id:
          get_param: TenantNetworkVlanID
      addresses:
      - ip_netmask:
        get_param: TenantIpSubnet
      routes:
        list_concat_unique:
          - get_param: ControlPlaneStaticRoutes
      - type: ovs_bond
        name: bond_vf
        ovs_options: "bond_mode=active-backup"
        members:
          - type: sriov_vf
            device: p2p1
            vfid: 2
          - type: sriov_vf
            device: p2p2
            vfid: 2
  • 要在 VF 上配置 OVS 用户桥接,请将 VLAN 标签应用到 ovs_user_bridge 参数:

    - type: ovs_user_bridge
      name: br-link0
      use_dhcp: false
      mtu: 9000
      ovs_extra:
        - str_replace:
            template: set port br-link0 tag=_VLAN_TAG_
            params:
              _VLAN_TAG_:
                get_param: TenantNetworkVlanID
      addresses:
        - ip_netmask:
            get_param: TenantIpSubnet
      routes:
        list_concat_unique:
          - get_param: TenantInterfaceRoutes
      members:
        - type: ovs_dpdk_bond
          name: dpdkbond0
          mtu: 9000
          ovs_extra:
            - set port dpdkbond0 bond_mode=balance-slb
          members:
            - type: ovs_dpdk_port
              name: dpdk0
              members:
                - type: sriov_vf
                  device: eno2
                  vfid: 3
            - type: ovs_dpdk_port
              name: dpdk1
              members:
                - type: sriov_vf
                  device: eno3
                  vfid: 3

验证

  1. 检查 VF 的数量。

    [root@overcloud-compute-0 heat-admin]# cat /sys/class/net/p4p1/device/sriov_numvfs
    10
    [root@overcloud-compute-0 heat-admin]# cat /sys/class/net/p4p2/device/sriov_numvfs
    10
  2. 检查 Linux 绑定。

    [root@overcloud-compute-0 heat-admin]# cat /proc/net/bonding/intapi_bond
    Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
    
    Bonding Mode: fault-tolerance (active-backup)
    Primary Slave: None
    Currently Active Slave: p4p1_1
    MII Status: up
    MII Polling Interval (ms): 0
    Up Delay (ms): 0
    Down Delay (ms): 0
    
    Slave Interface: p4p1_1
    MII Status: up
    Speed: 10000 Mbps
    Duplex: full
    Link Failure Count: 0
    Permanent HW addr: 16:b4:4c:aa:f0:a8
    Slave queue ID: 0
    
    Slave Interface: p4p2_1
    MII Status: up
    Speed: 10000 Mbps
    Duplex: full
    Link Failure Count: 0
    Permanent HW addr: b6:be:82:ac:51:98
    Slave queue ID: 0
    [root@overcloud-compute-0 heat-admin]# cat /proc/net/bonding/st_bond
    Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
    
    Bonding Mode: fault-tolerance (active-backup)
    Primary Slave: None
    Currently Active Slave: p4p1_3
    MII Status: up
    MII Polling Interval (ms): 0
    Up Delay (ms): 0
    Down Delay (ms): 0
    
    Slave Interface: p4p1_3
    MII Status: up
    Speed: 10000 Mbps
    Duplex: full
    Link Failure Count: 0
    Permanent HW addr: 9a:86:b7:cc:17:e4
    Slave queue ID: 0
    
    Slave Interface: p4p2_3
    MII Status: up
    Speed: 10000 Mbps
    Duplex: full
    Link Failure Count: 0
    Permanent HW addr: d6:07:f8:78:dd:5b
    Slave queue ID: 0
  3. 列出 OVS 绑定。

    [root@overcloud-compute-0 heat-admin]# ovs-appctl bond/show
    ---- bond_prov ----
    bond_mode: active-backup
    bond may use recirculation: no, Recirc-ID : -1
    bond-hash-basis: 0
    updelay: 0 ms
    downdelay: 0 ms
    lacp_status: off
    lacp_fallback_ab: false
    active slave mac: f2:ad:c7:00:f5:c7(dpdk2)
    
    slave dpdk2: enabled
      active slave
      may_enable: true
    
    slave dpdk3: enabled
      may_enable: true
    
    ---- bond_tnt ----
    bond_mode: active-backup
    bond may use recirculation: no, Recirc-ID : -1
    bond-hash-basis: 0
    updelay: 0 ms
    downdelay: 0 ms
    lacp_status: off
    lacp_fallback_ab: false
    active slave mac: b2:7e:b8:75:72:e8(dpdk0)
    
    slave dpdk0: enabled
      active slave
      may_enable: true
    
    slave dpdk1: enabled
      may_enable: true
  4. 显示 OVS 连接。

    [root@overcloud-compute-0 heat-admin]# ovs-vsctl show
    cec12069-9d4c-4fa8-bfe4-decfdf258f49
        Manager "ptcp:6640:127.0.0.1"
            is_connected: true
        Bridge br-tenant
            fail_mode: standalone
            Port br-tenant
                Interface br-tenant
                    type: internal
            Port bond_tnt
                Interface "dpdk0"
                    type: dpdk
                    options: {dpdk-devargs="0000:82:02.2"}
                Interface "dpdk1"
                    type: dpdk
                    options: {dpdk-devargs="0000:82:04.2"}
        Bridge "sriov2"
            Controller "tcp:127.0.0.1:6633"
                is_connected: true
            fail_mode: secure
            Port "phy-sriov2"
                Interface "phy-sriov2"
                    type: patch
                    options: {peer="int-sriov2"}
            Port "sriov2"
                Interface "sriov2"
                    type: internal
        Bridge br-int
            Controller "tcp:127.0.0.1:6633"
                is_connected: true
            fail_mode: secure
            Port "int-sriov2"
                Interface "int-sriov2"
                    type: patch
                    options: {peer="phy-sriov2"}
            Port br-int
                Interface br-int
                    type: internal
            Port "vhu93164679-22"
                tag: 4
                Interface "vhu93164679-22"
                    type: dpdkvhostuserclient
                    options: {vhost-server-path="/var/lib/vhost_sockets/vhu93164679-22"}
            Port "vhu5d6b9f5a-0d"
                tag: 3
                Interface "vhu5d6b9f5a-0d"
                    type: dpdkvhostuserclient
                    options: {vhost-server-path="/var/lib/vhost_sockets/vhu5d6b9f5a-0d"}
            Port patch-tun
                Interface patch-tun
                    type: patch
                    options: {peer=patch-int}
            Port "int-sriov1"
                Interface "int-sriov1"
                    type: patch
                    options: {peer="phy-sriov1"}
            Port int-br-vfs
                Interface int-br-vfs
                    type: patch
                    options: {peer=phy-br-vfs}
        Bridge br-vfs
            Controller "tcp:127.0.0.1:6633"
                is_connected: true
            fail_mode: secure
            Port phy-br-vfs
                Interface phy-br-vfs
                    type: patch
                    options: {peer=int-br-vfs}
            Port bond_prov
                Interface "dpdk3"
                    type: dpdk
                    options: {dpdk-devargs="0000:82:04.5"}
                Interface "dpdk2"
                    type: dpdk
                    options: {dpdk-devargs="0000:82:02.5"}
            Port br-vfs
                Interface br-vfs
                    type: internal
        Bridge "sriov1"
            Controller "tcp:127.0.0.1:6633"
                is_connected: true
            fail_mode: secure
            Port "sriov1"
                Interface "sriov1"
                    type: internal
            Port "phy-sriov1"
                Interface "phy-sriov1"
                    type: patch
                    options: {peer="int-sriov1"}
        Bridge br-tun
            Controller "tcp:127.0.0.1:6633"
                is_connected: true
            fail_mode: secure
            Port br-tun
                Interface br-tun
                    type: internal
            Port patch-int
                Interface patch-int
                    type: patch
                    options: {peer=patch-tun}
            Port "vxlan-0a0a7315"
                Interface "vxlan-0a0a7315"
                    type: vxlan
                    options: {df_default="true", in_key=flow, local_ip="10.10.115.10", out_key=flow, remote_ip="10.10.115.21"}
        ovs_version: "2.10.0"

如果您使用 NovaPCIPassthrough 将 VF 传递给实例,请通过 部署 SR-IOV 实例 来测试。

6.4. 配置 OVS 硬件卸载

OVS 硬件卸载配置的步骤共享许多与配置 SR-IOV 相同的步骤。

流程

  1. 根据 Compute 角色,为 OVS 硬件卸载生成 overcloud 角色:

    openstack overcloud roles generate -o roles_data.yaml Controller Compute:ComputeOvsHwOffload
  2. 可选:更改 HostnameFormatDefault: '%stackname%-compute-%index%' 名称作为 ComputeOvsHwOffload 角色。
  3. OvsHwOffload 参数添加到特定于角色的参数下,值为 true
  4. 要将 neutron 配置为使用 iptables/hybrid 防火墙驱动程序实现,请包括: NeutronOVSFirewallDriver: iptables_hybrid。有关 NeutronOVSFirewallDriver 的更多信息,请参阅高级 Overcloud 自定义指南中的 使用 Open vSwitch 防火墙
  5. 配置 physical_network 参数以匹配您的环境。

    • 对于 VLAN,请在部署后将 physical_network 参数设置为您在 neutron 中创建的网络名称。此值也应位于 NeutronBridgeMappings 中。
    • 对于 VXLAN,将 physical_network 参数设置为 null

      例如:

      parameter_defaults:
        NeutronOVSFirewallDriver: iptables_hybrid
        ComputeSriovParameters:
          IsolCpusList: 2-9,21-29,11-19,31-39
          KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=128 intel_iommu=on iommu=pt"
          OvsHwOffload: true
          TunedProfileName: "cpu-partitioning"
          NeutronBridgeMappings:
            - tenant:br-tenant
          NovaPCIPassthrough:
            - vendor_id: <vendor-id>
              product_id: <product-id>
              address: <address>
              physical_network: "tenant"
            - vendor_id: <vendor-id>
              product_id: <product-id>
              address: <address>
              physical_network: "null"
          NovaReservedHostMemory: 4096
          NovaComputeCpuDedicatedSet: 1-9,21-29,11-19,31-39
    • <vendor-id > 替换为物理 NIC 的供应商 ID。
    • <product-id > 替换为 NIC VF 的产品 ID。
    • < address> 替换为物理 NIC 的地址。

      有关如何配置 NovaPCIPassthrough 的更多信息,请参阅有关 配置 NovaPCIPassthrough的指南

  6. 确保默认过滤器列表包含 NUMATopologyFilter

      NovaSchedulerDefaultFilters: [\'AvailabilityZoneFilter',\'ComputeFilter',\'ComputeCapabilitiesFilter',\'ImagePropertiesFilter',\'ServerGroupAntiAffinityFilter',\'ServerGroupAffinityFilter',\'PciPassthroughFilter',\'NUMATopologyFilter']
  7. compute-sriov.yaml 配置文件中配置用于硬件卸载的一个或多个网络接口:

      - type: ovs_bridge
        name: br-tenant
        mtu: 9000
        members:
        - type: sriov_pf
          name: p7p1
          numvfs: 5
          mtu: 9000
          primary: true
          promisc: true
          use_dhcp: false
          link_mode: switchdev
    注意
    • 在配置 Open vSwitch 硬件卸载时,不要使用 NeutronSriovNumVFs 参数。虚拟功能的数量使用 os-net-config 使用的网络配置文件中的 numvfs 参数指定。红帽不支持在更新或重新部署过程中修改 numvfs 设置。
    • 不要将 Mellanox 网络接口配置为 nic-config 接口类型 ovs-vlan,因为这会阻止 VXLAN 等隧道端点会因为驱动程序限制而传递流量。
  8. overcloud deploy 命令中包含 ovs-hw-offload.yaml 文件:

    TEMPLATES_HOME=”/usr/share/openstack-tripleo-heat-templates”
    CUSTOM_TEMPLATES=”/home/stack/templates”
    
    openstack overcloud deploy --templates \
      -r ${CUSTOM_TEMPLATES}/roles_data.yaml \
      -e ${TEMPLATES_HOME}/environments/ovs-hw-offload.yaml \
      -e ${CUSTOM_TEMPLATES}/network-environment.yaml \
      -e ${CUSTOM_TEMPLATES}/neutron-ovs.yaml

6.4.1. 验证 OVS 硬件卸载

  1. 确认 PCI 设备处于 switchdev 模式:

    # devlink dev eswitch show pci/0000:03:00.0
    pci/0000:03:00.0: mode switchdev inline-mode none encap enable
  2. 验证 OVS 中是否启用了卸载:

    # ovs-vsctl get Open_vSwitch . other_config:hw-offload
    “true”

6.5. 调整 OVS 硬件卸载示例

要获得最佳性能,您必须完成其他配置步骤。

为每个网络接口调整频道数以提高性能

频道包含一个中断请求(IRQ),以及触发 IRQ 的队列集合。当您将 mlx5_core 驱动程序设置为 switchdev 模式时,mlx5_core 驱动程序默认为一个组合频道,它可能无法提供最佳性能。

流程

  • 在 PF 表示器上,输入以下命令来调整主机可用的 CPU 数量。使用您要提供的 CPU 数量替换 $(nproc):

    $ sudo ethtool -L enp3s0f0 combined $(nproc)

CPU 固定

为防止性能下降,请在同一 NUMA 节点中查找 NIC、应用程序、VF 客户机和 OVS。如需更多信息,请参阅配置实例创建指南中的在 Compute 节点上配置 CPU 固定

6.6. OVS 硬件卸载的组件

用于配置和排除使用 Mellanox 智能 NIC 的 OVS HW Offload 组件的引用。

Nova

将 Nova 调度程序配置为使用 NovaPCIPassthrough 过滤器及 NUMATopologyFilterDerivePciWhitelistEnabled 参数。当您启用 OVS HW Offload 时,Nova 调度程序与生成实例的 SR-IOV 透传相似。

Neutron

启用 OVS HW Offload 时,使用 devlink cli 工具将 NIC e-switch 模式设置为 switchdevSwitchdev 模式建立 NIC 上的代表器端口,这些端口映射到 VF。

流程

  1. 要从启用了 switchdev-enabled NIC 分配端口,请创建一个 neutron 端口,其 绑定 配置集为 capabilities,并禁用端口安全性:

    $ openstack port create --network private --vnic-type=direct --binding-profile '{"capabilities": ["switchdev"]}' direct_port1 --disable-port-security

在创建实例时传递此端口信息。您可以将代表器端口与实例 VF 接口关联,并将代表端口连接到 OVS 网桥 br-int 以进行一次性 OVS 数据路径处理。VF 端口代表器功能,如物理"patch 面板"前端的软件版本。有关新实例创建的更多信息,请参阅: 为 SR-IOV 部署实例

OVS

在配置了硬件卸载的环境中,传输的第一个数据包会遍历 OVS 内核路径,此数据包则为实例流量的传入和传出流量建立 ml2 OVS 规则。建立流量流后,OVS 会使用流量控制(TC)流程序实用程序在 NIC 硬件上推送这些流。

流程

  1. 使用 director 在 OVS 上应用以下配置:

    $ sudo ovs-vsctl set Open_vSwitch . other_config:hw-offload=true
  2. 重启 以启用 HW Offload。

流量控制(TC)子系统

当您启用 hw-offload 标志时,OVS 将使用 TC 数据路径。TC Flower 是一个 iproute2 实用程序,用于在硬件上写入数据路径流。这样可确保在硬件和软件数据路径中编程了网络流,以实现冗余。

流程

  1. 应用以下配置。如果您没有显式配置 tc-policy,则这个选项:

    $ sudo ovs-vsctl set Open_vSwitch . other_config:tc-policy=none
  2. 重启 OVS。

NIC PF 和 VF 驱动程序

Mlx5_core 是 Mellanox ConnectX-5 NIC 的 PF 和 VF 驱动程序。mlx5_core 驱动程序执行以下任务:

  • 在硬件上创建路由表。
  • 管理网络流管理。
  • 配置以太网交换机设备驱动程序模型 switchdev
  • 创建块设备。

流程

  • 使用以下 devlink 命令查询 PCI 设备的模式。

    $ sudo devlink dev eswitch set pci/0000:03:00.0 mode switchdev
    $ sudo devlink dev eswitch show pci/0000:03:00.0
    pci/0000:03:00.0: mode switchdev inline-mode none encap enable

NIC 固件

NIC 固件执行以下任务:

  • 维护路由表和规则。
  • 修复表的管道。
  • 管理硬件资源。
  • 创建 VF。

固件可用于驱动程序来获得最佳性能。

虽然 NIC 固件不是易失性,但在重新引导后保留,但您可以在运行时修改配置。

流程

  • 在接口和代表端口上应用以下配置,以确保 TC 流器在端口级别推送流编程:

     $ sudo ethtool -K enp3s0f0 hw-tc-offload on
注意

请确定您更新固件。Yumdnf 更新可能无法完成固件更新。如需更多信息,请参阅您的厂商文档。

6.7. OVS 硬件卸载故障排除

先决条件

  • Linux Kernel 4.13 或更新版本
  • OVS 2.8 或更新版本
  • RHOSP 12 或更新版本
  • iproute 4.12 或更新版本
  • Mellanox NIC 固件,如 FW ConnectX-5 16.21.0338 或更新版本

有关支持的先决条件的更多信息,请参阅红帽知识库解决方案网络适配器 Fast Datapath 功能支持列表

在 OVS HW 卸载部署中配置网络

在 HW 卸载部署中,您可以根据您的要求选择以下网络配置情况之一:

  • 您可以使用附加到绑定的同一组接口或每种类型的不同 NIC 集在 VXLAN 和 VLAN 上基本客户机虚拟机。
  • 您可以使用 Linux 绑定绑定 Mellanox NIC 的两个端口。
  • 您可以在 Mellanox Linux 绑定之上的 VLAN 接口托管租户 VXLAN 网络。

确保单个 NIC 和绑定是 ovs-bridge 的成员。

请参考以下示例网络配置:

             - type: ovs_bridge
                name: br-offload
                mtu: 9000
                use_dhcp: false
                members:
                - type: linux_bond
                  name: bond-pf
                  bonding_options: "mode=active-backup miimon=100"
                  members:
                  - type: sriov_pf
                    name: p5p1
                    numvfs: 3
                    primary: true
                    promisc: true
                    use_dhcp: false
                    defroute: false
                    link_mode: switchdev
                  - type: sriov_pf
                    name: p5p2
                    numvfs: 3
                    promisc: true
                    use_dhcp: false
                    defroute: false
                    link_mode: switchdev

              - type: vlan
                vlan_id:
                  get_param: TenantNetworkVlanID
                device: bond-pf
                addresses:
                - ip_netmask:
                    get_param: TenantIpSubnet

请参考以下验证的绑定配置:

  • active-backup - mode=1
  • active-active or balance-xor - mode=2
  • 802.3ad (LACP) - mode=4

验证接口配置

通过以下步骤验证接口配置。

流程

  1. 在部署期间,使用主机网络配置工具 os-net-config 启用 hw-tc-offload
  2. 在重启 Compute 节点时,在 sriov_config 服务中启用 hw-tc-offload
  3. 对于附加到绑定的 NIC,将 hw-tc-offload 参数设置为 on

    [root@overcloud-computesriov-0 ~]# ethtool -k ens1f0 | grep tc-offload
    hw-tc-offload: on

验证接口模式

通过以下步骤验证接口模式。

流程

  1. 将用于 HW 卸载接口的 eswitch 模式设置为 switchdev
  2. 使用主机网络配置工具 os-net-config 在部署期间启用 eswitch
  3. 在您重新引导 Compute 节点时,在 sriov_config 服务中启用 eswitch

    [root@overcloud-computesriov-0 ~]# devlink dev eswitch show pci/$(ethtool -i ens1f0 | grep bus-info | cut -d ':' -f 2,3,4 | awk '{$1=$1};1')
注意

PF 接口的驱动程序设置为 "mlx5e_rep",以显示它是 e-switch uplink 端口的代表器。这不会影响功能。

验证 OVS 中的卸载状态

通过以下步骤,验证 OVS 中的卸载状态。

  • 在 Compute 节点中启用 OVS 中的硬件卸载。

    [root@overcloud-computesriov-0 ~]# ovs-vsctl get Open_vSwitch . other_config:hw-offload
    "true"

验证 VF 代表或端口的名称

为确保 VF 表示器端口的一致性命名,os-net-config 使用 udev 规则以 <PF-name>_<VF_id> 格式重命名端口。

流程

  • 部署后,验证 VF 代表器端口是否正确命名。

    root@overcloud-computesriov-0 ~]# cat /etc/udev/rules.d/80-persistent-os-net-config.rules
    # This file is autogenerated by os-net-config
    
    SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}!="", ATTR{phys_port_name}=="pf*vf*", ENV{NM_UNMANAGED}="1"
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNELS=="0000:65:00.0", NAME="ens1f0"
    SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}=="98039b7f9e48", ATTR{phys_port_name}=="pf0vf*", IMPORT{program}="/etc/udev/rep-link-name.sh $attr{phys_port_name}", NAME="ens1f0_$env{NUMBER}"
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", KERNELS=="0000:65:00.1", NAME="ens1f1"
    SUBSYSTEM=="net", ACTION=="add", ATTR{phys_switch_id}=="98039b7f9e49", ATTR{phys_port_name}=="pf1vf*", IMPORT{program}="/etc/udev/rep-link-name.sh $attr{phys_port_name}", NAME="ens1f1_$env{NUMBER}"

检查网络流量流

HW 卸载的网络流功能的方式类似于物理交换机或带有特定于应用程序的集成电路(ASIC)芯片的路由器。您可以访问交换机或路由器的 ASIC shell,以检查路由表并进行其他调试。以下流程使用 Cumulus Linux 交换机的 Broadcom 芯片组作为示例。替换适合您环境的值。

流程

  1. 要获取 Broadcom 芯片表内容,请使用 bcmcmd 命令。

    root@dni-7448-26:~# cl-bcmcmd l2 show
    
    mac=00:02:00:00:00:08 vlan=2000 GPORT=0x2 modid=0 port=2/xe1
    mac=00:02:00:00:00:09 vlan=2000 GPORT=0x2 modid=0 port=2/xe1 Hit
  2. 检查流量控制(TC)层。

    # tc -s filter show dev p5p1_1 ingress
    …
    filter block 94 protocol ip pref 3 flower chain 5
    filter block 94 protocol ip pref 3 flower chain 5 handle 0x2
      eth_type ipv4
      src_ip 172.0.0.1
      ip_flags nofrag
      in_hw in_hw_count 1
            action order 1: mirred (Egress Redirect to device eth4) stolen
            index 3 ref 1 bind 1 installed 364 sec used 0 sec
            Action statistics:
            Sent 253991716224 bytes 169534118 pkt (dropped 0, overlimits 0 requeues 0)
            Sent software 43711874200 bytes 30161170 pkt
            Sent hardware 210279842024 bytes 139372948 pkt
            backlog 0b 0p requeues 0
            cookie 8beddad9a0430f0457e7e78db6e0af48
            no_percpu
  3. 检查 in_hw 标志以及此输出中的统计信息。术语 硬件 表示硬件处理网络流量。如果使用 tc-policy=none,您可以检查此输出,或者在硬件或软件处理数据包时进行调查。当驱动程序无法卸载数据包时,您可以在 dmesg 中看到对应的日志消息,或者在 ovs-vswitch.log 中看到相应的日志消息。
  4. 例如,Mlanox 中的日志条目与 dmesg 中的 syndrome 信息类似。

    [13232.860484] mlx5_core 0000:3b:00.0: mlx5_cmd_check:756:(pid 131368): SET_FLOW_TABLE_ENTRY(0x936) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0x6b1266)

    在本例中,错误代码(0x6b1266)代表以下行为:

    0x6B1266 |  set_flow_table_entry: pop vlan and forward to uplink is not allowed

验证系统

使用以下流程验证您的系统。

流程

  1. 确保系统上已启用 SR-IOV 和 VT-d。
  2. 通过在内核参数中添加 intel_iommu=on 在 Linux 中启用 IOMMU,例如使用 GRUB。

限制

您不能将 OVS 防火墙驱动程序与 HW 卸载结合使用,因为 OVS 2.11 中的卸载路径不支持流跟踪属性。

6.8. 调试 HW Offload 流

如果您在 ovs-vswitch.log 文件中遇到以下消息,您可以使用以下步骤:

2020-01-31T06:22:11.257Z|00473|dpif_netlink(handler402)|ERR|failed to offload flow: Operation not supported: p6p1_5

流程

  1. 要在卸载模块上启用日志记录,并为这个失败获取额外的日志信息,请在 Compute 节点上使用以下命令:

    ovs-appctl vlog/set dpif_netlink:file:dbg
    # Module name changed recently (check based on the version used
    ovs-appctl vlog/set netdev_tc_offloads:file:dbg [OR] ovs-appctl vlog/set netdev_offload_tc:file:dbg
    ovs-appctl vlog/set tc:file:dbg
  2. 再次检查 ovs-vswitchd 日志,以查看有关此问题的更多详情。

    在以下示例中,因为不支持的属性标记,卸载会失败。

     2020-01-31T06:22:11.218Z|00471|dpif_netlink(handler402)|DBG|system@ovs-system: put[create] ufid:61bd016e-eb89-44fc-a17e-958bc8e45fda recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(7),skb_mark(0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=fa:16:3e:d2:f5:f3,dst=fa:16:3e:c4:a3:eb),eth_type(0x0800),ipv4(src=10.1.1.8/0.0.0.0,dst=10.1.1.31/0.0.0.0,proto=1/0,tos=0/0x3,ttl=64/0,frag=no),icmp(type=0/0,code=0/0), actions:set(tunnel(tun_id=0x3d,src=10.10.141.107,dst=10.10.141.124,ttl=64,tp_dst=4789,flags(df|key))),6
    
    2020-01-31T06:22:11.253Z|00472|netdev_tc_offloads(handler402)|DBG|offloading attribute pkt_mark isn't supported
    
    2020-01-31T06:22:11.257Z|00473|dpif_netlink(handler402)|ERR|failed to offload flow: Operation not supported: p6p1_5

调试 Mellanox NIC

Mellanox 提供了系统信息脚本,类似于 Red Hat SOS 报告。

https://github.com/Mellanox/linux-sysinfo-snapshot/blob/master/sysinfo-snapshot.py

运行此命令时,您要创建相关日志信息的 zip 文件,这对支持问题单非常有用。

流程

  • 您可以使用以下命令运行这个系统信息脚本:

    # ./sysinfo-snapshot.py --asap --asap_tc --ibdiagnet --openstack

您还可以安装 Mellanox Firmware Tools (MFT)、mlxconfig、mlxlink 和 OpenFabrics Enterprise Distribution (OFED)驱动程序。

有用的 CLI 命令

使用带有以下选项的 ethtool 工具来收集诊断信息:

  • ethtool -l <uplink representor> : 查看频道数
  • ethtool -I <uplink/VFs> : Check statistics
  • ethtool -i <uplink rep> : View driver information
  • ethtool -g <uplink rep> : Check ring size
  • ethtool -k <uplink/VFs> : View enabled features

在代表器和 PF 端口中使用 tcpdump 程序来类似检查流量流。

  • 您对代表或端口的链接状态进行的任何更改也会影响 VF 链接状态。
  • 代表端口统计存在 VF 统计。

使用以下命令获取有用的诊断信息:

$ ovs-appctl dpctl/dump-flows -m type=offloaded

$ ovs-appctl dpctl/dump-flows -m

$ tc filter show dev ens1_0 ingress

$ tc -s filter show dev ens1_0 ingress

$ tc monitor

6.9. 为 SR-IOV 部署实例

使用主机聚合来分隔高性能计算主机。有关创建主机聚合和相关类别的信息,请参阅创建主机聚合

注意

固定 CPU 实例可以位于与未固定实例相同的 Compute 节点上。如需更多信息,请参阅配置实例创建指南中的在 Compute 节点上配置 CPU 固定

通过执行以下步骤为单根 I/O 虚拟化(SR-IOV)部署实例:

  1. 创建类别。

    # openstack flavor create <flavor> --ram <MB> --disk <GB> --vcpus <#>
    提示

    您可以通过在类别中添加额外的 spec hw:pci_numa_affinity_policy,为 PCI 透传设备和 SR-IOV 接口指定 NUMA 关联性策略。如需更多信息,请参阅 为实例创建指南中的配置计算服务中的 类别元数据

  2. 创建网络。

    # openstack network create net1 --provider-physical-network tenant --provider-network-type vlan --provider-segment <VLAN-ID>
    # openstack subnet create subnet1 --network net1 --subnet-range 192.0.2.0/24 --dhcp
  3. 创建端口。

    • 使用 vnic-type direct 创建 SR-IOV 虚拟功能(VF)端口。

      # openstack port create --network net1 --vnic-type direct sriov_port
    • 使用以下命令创建带有硬件卸载的虚拟功能。

      # openstack port create --network net1 --vnic-type direct --binding-profile '{"capabilities": ["switchdev"]} sriov_hwoffload_port
    • 使用 vnic-type 直接物理 创建专用于单个实例的 SR-IOV 物理功能(PF)端口。此 PF 端口是一个 Networking 服务(neutron)端口,但不由网络服务控制,而且不作为网络适配器可见,因为它是传递给实例的 PCI 设备。

      # openstack port create --network net1 --vnic-type direct-physical sriov_port
  4. 部署实例。

    # openstack server create --flavor <flavor> --image <image> --nic port-id=<id> <instance name>

6.10. 创建主机聚合

为提高性能,部署带有 CPU 固定和大页的客户机。您可以通过与类别元数据匹配的聚合元数据,在主机子集上调度高性能实例。

  1. 您可以通过部署模板中的 heat 参数 NovaSchedulerDefaultFilters(在 parameter_defaults in your deployment templates. 下),配置 AggregateInstanceExtraSpecsFilter 值和其他必要的过滤。

      parameter_defaults:
        NovaSchedulerDefaultFilters: ['AggregateInstanceExtraSpecsFilter','AvailabilityZoneFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','NUMATopologyFilter']
    注意

    要在退出集群的配置中添加此参数,可以将其添加到 heat 模板中,然后再次运行原始部署脚本。

  2. 为 SR-IOV 创建聚合组,并添加相关主机。定义与定义的类别元数据匹配的 metadata,如 sriov=true

    # openstack aggregate create sriov_group
    # openstack aggregate add host sriov_group compute-sriov-0.localdomain
    # openstack aggregate set --property sriov=true sriov_group
  3. 创建类别。

    # openstack flavor create <flavor> --ram <MB> --disk <GB> --vcpus <#>
  4. 设置其他类别属性。请注意,定义的元数据 sriov=true 与 SR-IOV 聚合上定义的元数据匹配。

    # openstack flavor set --property sriov=true --property hw:cpu_policy=dedicated --property hw:mem_page_size=1GB <flavor>

第 7 章 规划 OVS-DPDK 部署

要利用 NFV 的 Data Plane Development Kit (OVS-DPDK)部署优化 Open vSwitch,您应该了解 OVS-DPDK 如何使用计算节点硬件(CPU、NUMA 节点、内存、NIC)以及决定基于 Compute 节点的各种 OVS-DPDK 参数的注意事项。

重要

使用 OVS-DPDK 和 OVS 原生防火墙(基于 conntrack 的有状态防火墙)时,您只能跟踪使用 ICMPv4、ICMPv6、TCP 和 UDP 协议的数据包。OVS 会将所有其他网络流量标记为无效。

有关 CPU 和 NUMA 拓扑的高级介绍,请参阅 NFV 性能注意事项

7.1. 带有 CPU 分区和 NUMA 拓扑的 OVS-DPDK

OVS-DPDK 为主机、客户机和自身分区硬件资源。OVS-DPDK 轮询模式驱动程序(PMD)运行 DPDK 活跃循环,这需要专用 CPU 内核。因此,您必须将一些 CPU 和大页面分配给 OVS-DPDK。

示例分区包括每个双插槽 Compute 节点上的每个 NUMA 节点的 16 个内核。流量需要额外的 NIC,因为您无法在主机和 OVS-DPDK 之间共享 NIC。

OpenStack NFV Hardware Capacities 464931 0118 OVS DPDK
注意

您必须在两个 NUMA 节点上保留 DPDK PMD 线程,即使 NUMA 节点没有关联的 DPDK NIC。

为了获得最佳 OVS-DPDK 性能,请为 NUMA 节点保留内存本地块。选择与用于内存和 CPU 固定的相同 NUMA 节点关联的 NIC。确保两个绑定接口都来自同一 NUMA 节点上的 NIC。

7.2. 工作流和派生参数

该功能在此发行版本中作为技术预览提供,因此不享有红帽的全面支持。它只应用于测试,不应部署在生产环境中。有关技术预览功能的更多信息,请参阅覆盖范围详细信息

您可以使用 Red Hat OpenStack Platform Workflow (mistral)服务根据可用裸机恢复节点的功能来派生参数。工作流使用 YAML 文件来定义一组要执行的任务和操作。您可以在 tripleo-common/workbooks/ 目录中使用预定义的工作簿中执行 var _params.yaml。本工作簿提供了从裸机内省结果获取每个支持的参数的工作流。derived _params.yaml 工作流使用来自 tripleo-common/workbooks/derive_params_formulas.yaml 的公式来计算派生的参数。

注意

您可以修改 derived _params_formulas.yaml 以适应您的环境。

derived_params.yaml 工作簿假定特定可组合角色的所有节点具有相同的硬件规格。工作流考虑了 flavor-profile 关联和 nova 放置调度程序,以匹配与角色关联的节点,然后使用与角色匹配的第一个节点内省数据。

有关工作流的更多信息,请参阅故障排除工作流和执行

您可以使用 -p--plan-environment-file 选项添加自定义 plan_environment.yaml 文件,该文件中包含 workbooks 和任何输入值的列表到 openstack overcloud deploy 命令中。结果工作流将派生的参数合并到自定义 plan_environment.yaml 中,它们可用于 overcloud 部署。

有关如何在部署中使用 --plan-environment-file 选项的详情,请参阅 Plan Environment Metadata

7.3. 派生的 OVS-DPDK 参数

derived _params.yaml 中的工作流派生了与使用 ComputeNeutronOvsDpdk 服务的角色关联的 DPDK 参数。

工作流可以自动生成 OVS-DPDK 的以下参数:NovaVcpuPinSet 参数现已弃用,并被用于专用、固定工作流的 NovaComputeCpuDedicatedSet 替换:

  • IsolCpusList
  • KernelArgs
  • NovaReservedHostMemory
  • NovaComputeCpuDedicatedSet
  • OvsDpdkSocketMemory
  • OvsPmdCoreList
注意

要避免错误,您必须为特定于角色的参数配置特定于角色的标签。

OvsDpdkMemoryChannels 参数无法从内省内存银行数据衍生,因为内存插槽名称的格式在不同的硬件环境中不一致。

在大多数情况下,OvsDpdkMemoryChannels 的默认数量是四。请参考硬件手册以确定每个套接字的内存通道数,并使用这个值更新默认数量。

有关工作流参数的更多信息,请参阅 第 8.1 节 “使用工作流推断 DPDK 参数”

7.4. 手动计算 OVS-DPDK 参数

本节介绍 OVS-DPDK 如何使用 director network_environment.yaml heat 模板中的参数来配置 CPU 和内存以实现最优性能。使用这些信息评估 Compute 节点上的硬件支持,以及如何对硬件进行分区以优化 OVS-DPDK 部署。

注意

如需有关如何使用 derived_parameters.yaml 工作流生成这些值的更多信息,请参阅 工作流和派生参数概述

注意

在分配 CPU 内核时,始终对 CPU 同级线程或逻辑 CPU 分组到物理内核中。

有关如何决定 Compute 节点上的 CPU 和 NUMA 节点的详情,请参考 发现您的 NUMA 节点拓扑。使用此信息映射 CPU 和其他参数,以支持主机、客户机实例和 OVS-DPDK 进程的需求。

7.4.1. CPU 参数

OVS-DPDK 为 CPU 分区使用以下参数:

OvsPmdCoreList

提供用于 DPDK 轮询模式驱动程序(PMD)的 CPU 内核。选择与 DPDK 接口本地 NUMA 节点关联的 CPU 内核。使用 OvsPmdCoreList 作为 OVS 中的 pmd-cpu-mask 值。对 OvsPmdCoreList 使用以下建议:

  • 对同级的线程连接在一起。
  • 性能取决于为此 PMD 核心列表分配的物理内核数。在与 DPDK NIC 关联的 NUMA 节点上,分配所需的内核。
  • 对于具有 DPDK NIC 的 NUMA 节点,根据性能要求确定物理内核数量,并包含每个物理内核的所有同级线程或逻辑 CPU。
  • 对于没有 DPDK NIC 的 NUMA 节点,请为任何物理内核分配同级线程或逻辑 CPU,除了 NUMA 节点的第一个物理核心除外。
注意

您必须在两个 NUMA 节点上保留 DPDK PMD 线程,即使 NUMA 节点没有关联的 DPDK NIC。

NovaComputeCpuDedicatedSet

可以调度用于固定实例 CPU 的进程的逗号分隔列表或物理主机 CPU 范围。例如,NovaComputeCpuDedicatedSet: [4-12,^8,15] 保留来自 4-12 和 15 的核心,不包括 8。

  • OvsPmdCoreList 中排除所有内核。
  • 包括所有剩余内核。
  • 对同级的线程连接在一起。
NovaComputeCpuSharedSet
用于决定实例仿真程序线程的主机 CPU 编号的逗号分隔列表或范围。
IsolCpusList

与主机进程隔离的一组 CPU 核心。IsolCpusListtuned-profiles-cpu-partitioning 组件的 cpu-partitioning-variable.conf 文件中的 isolated_cores 值。对 IsolCpusList 使用以下建议:

  • 匹配 OvsPmdCoreListNovaComputeCpuDedicatedSet 中的内核数。
  • 对同级的线程连接在一起。
DerivePciWhitelistEnabled

要为虚拟机保留虚拟功能(VF),请使用 NovaPCIPassthrough 参数创建通过 Nova 传递给 Nova 的 VF 列表。列表中排除的 VF 会为主机保留可用。

对于列表中的每个 VF,使用解析到地址值的正则表达式填充 address 参数。

以下是手动列表创建过程的示例。如果在名为 eno2 的设备中启用 NIC 分区,使用以下命令列出 VF 的 PCI 地址:

[heat-admin@compute-0 ~]$ ls -lh /sys/class/net/eno2/device/ | grep virtfn
lrwxrwxrwx. 1 root root    0 Apr 16 09:58 virtfn0 -> ../0000:18:06.0
lrwxrwxrwx. 1 root root    0 Apr 16 09:58 virtfn1 -> ../0000:18:06.1
lrwxrwxrwx. 1 root root    0 Apr 16 09:58 virtfn2 -> ../0000:18:06.2
lrwxrwxrwx. 1 root root    0 Apr 16 09:58 virtfn3 -> ../0000:18:06.3
lrwxrwxrwx. 1 root root    0 Apr 16 09:58 virtfn4 -> ../0000:18:06.4
lrwxrwxrwx. 1 root root    0 Apr 16 09:58 virtfn5 -> ../0000:18:06.5
lrwxrwxrwx. 1 root root    0 Apr 16 09:58 virtfn6 -> ../0000:18:06.6
lrwxrwxrwx. 1 root root    0 Apr 16 09:58 virtfn7 -> ../0000:18:06.7

在本例中,VF 0、4 和 6 供 eno2 用于 NIC 分区。手动配置 NovaPCIPassthrough 以包括 VF 1-3、5 和 7,因此排除 VFs 0、4 和 6,如下例所示:

NovaPCIPassthrough:
  - physical_network: "sriovnet2"
  address: {"domain": ".*", "bus": "18", "slot": "06", "function": "[1-3]"}
  - physical_network: "sriovnet2"
  address: {"domain": ".*", "bus": "18", "slot": "06", "function": "[5]"}
  - physical_network: "sriovnet2"
  address: {"domain": ".*", "bus": "18", "slot": "06", "function": "[7]"}

7.4.2. 内存参数

OVS-DPDK 使用下列内存参数:

OvsDpdkMemoryChannels

映射每个 NUMA 节点的 CPU 中的内存频道。OvsDpdkMemoryChannels 是 OVS 中的 other_config:dpdk-extra="-n <value>" 值。观察 OvsDpdkMemoryChannels 的以下建议:

  • 使用 dmidecode -t memory 或您的硬件手册来确定可用的内存通道数。
  • 使用 ls /sys/devices/system/node/node* -d 确定 NUMA 节点的数量。
  • 将可用内存通道数除以 NUMA 节点数。
NovaReservedHostMemory

以 MB 为单位保留主机上任务的内存。NovaReservedHostMemorynova.conf 中 Compute 节点的 reserved_host_memory_mb 值。观察 NovaReservedHostMemory 的以下建议:

  • 使用静态推荐值 4096 MB。
OvsDpdkSocketMemory

指定从每个 NUMA 节点预先分配巨页池的内存量(以 MB 为单位)。OvsDpdkSocketMemory 是 OVS 中的 other_config:dpdk-socket-mem 值。观察 OvsDpdkSocketMemory 的以下建议:

  • 提供 作为用逗号分开的列表。
  • 对于没有 DPDK NIC 的 NUMA 节点,请使用 1024 MB (1GB)的静态建议。
  • 从 NUMA 节点上的每个 NIC 的 MTU 值计算 OvsDpdkSocketMemory 值。
  • 以下驱除 OvsDpdkSocketMemory 的值如下:

    • MEMORY_REQD_PER_MTU = (ROUNDUP_PER_MTU + 800) * (4096 * 64) Bytes

      • 800 是开销值。
      • 4096 * 64 是 mempool 中的数据包数量。
  • 为 NUMA 节点上设置的每个 MTU 值添加 MEMORY_REQD_PER_MTU,再添加另一个 512 MB 作为缓冲区。将值设为 1024 的倍数。

Calculation 示例 - MTU 2000 和 MTU 9000

DPDK NIC dpdk0 和 dpdk1 在同一 NUMA 节点 0 上,分别使用 MTU 9000 和 2000 进行配置。生成内存所需的计算示例如下:

  1. 将 MTU 值向下舍入到最接近 1024 字节。

    The MTU value of 9000 becomes 9216 bytes.
    The MTU value of 2000 becomes 2048 bytes.
  2. 根据这些循环的字节值计算每个 MTU 值所需的内存。

    Memory required for 9000 MTU = (9216 + 800) * (4096*64) = 2625634304
    Memory required for 2000 MTU = (2048 + 800) * (4096*64) = 746586112
  3. 计算所需的总内存总量(以字节为单位)。

    2625634304 + 746586112 + 536870912 = 3909091328 bytes.

    此计算代表( MTU 为 9000 所需要的内存)+(MTU 为 2000)+(512 MB 缓冲所需的内存)。

  4. 将所需的总内存转换为 MB。

    3909091328 / (1024*1024) = 3728 MB.
  5. 将该值向上舍入到最接近的 1024。

    3724 MB rounds up to 4096 MB.
  6. 使用这个值设置 OvsDpdkSocketMemory

        OvsDpdkSocketMemory: "4096,1024"

Calculation 示例 - MTU 2000

DPDK NIC dpdk0 和 dpdk1 在同一 NUMA 节点 0 上,每个节点都配置了 2000 的 MTU。生成内存所需的计算示例如下:

  1. 将 MTU 值向下舍入到最接近 1024 字节。

    The MTU value of 2000 becomes 2048 bytes.
  2. 根据这些循环的字节值计算每个 MTU 值所需的内存。

    Memory required for 2000 MTU = (2048 + 800) * (4096*64) = 746586112
  3. 计算所需的总内存总量(以字节为单位)。

    746586112 + 536870912 = 1283457024 bytes.

    此计算代表(MTU 为 2000)+(512 MB 缓冲)所需的内存。

  4. 将所需的总内存转换为 MB。

    1283457024 / (1024*1024) = 1224 MB.
  5. 将该值向上舍入到最接近 1024 的倍数。

    1224 MB rounds up to 2048 MB.
  6. 使用这个值设置 OvsDpdkSocketMemory

        OvsDpdkSocketMemory: "2048,1024"

7.4.3. 网络参数

OvsDpdkDriverType
设置 DPDK 使用的驱动程序类型。使用 vfio-pci 的默认值。
NeutronDatapathType
OVS 网桥的数据路径类型。DPDK 使用 netdev 的默认值。
NeutronVhostuserSocketDir
为 OVS 设置 vhost-user 套接字目录。将 /var/lib/vhost_sockets 用于 vhost 客户端模式。

7.4.4. 其他参数

NovaSchedulerDefaultFilters
提供有序的过滤器列表,计算节点用于为请求的客户机实例查找匹配的 Compute 节点。
VhostuserSocketGroup
设置 vhost-user 套接字目录组。默认值为 qemu。将 VhostuserSocketGroup 设置为 hugetlbfs,以便 ovs-vswitchdqemu 进程可以访问配置 virtio-net 设备的共享巨页和 unix 套接字。此值特定于角色,应当应用到利用 OVS-DPDK 的任何角色。
KernelArgs

在引导时为 Compute 节点提供多个内核参数 /etc/default/grub。根据您的配置添加以下值:

  • hugepagesz :设置 CPU 中巨页的大小。这个值可能因 CPU 硬件而异。为 OVS-DPDK 部署(默认_hugepagesz=1GB hugepagesz=1G )设置为 1G。使用此命令检查 pdpe1gb CPU 标记,该标记确认您的 CPU 支持 1G。

    lshw -class processor | grep pdpe1gb
  • hugepages count :根据可用的主机内存设置巨页数量。使用大多数可用内存,NovaReservedHostMemory 除外。您还必须在 Compute 节点的类型中配置巨页数值。
  • IOMMU: 对于 Intel CPU,添加 "intel_iommu=on iommu=pt"
  • isolcpus :设置用于调优的 CPU 内核。这个值与 IsolCpusList 匹配。

有关 CPU 隔离的更多信息,请参阅 RHEL 8 和 RHEL 9 的红帽知识库解决方案 OpenStack CPU 隔离指导

7.4.5. 实例额外规格

在 NFV 环境中部署实例之前,先创建一个利用 CPU 固定、巨页和仿真程序线程固定的类别。

hw:cpu_policy
当此参数设为 dedicated 时,客户机使用固定 CPU。从带有此参数集的类别创建的实例具有有效的过量使用比 1:1。默认值为 共享
hw:mem_page_size

将此参数设置为带有标准后缀(例如 4KB8MB1GB)的特定值的有效字符串。使用 1GB 匹配 hugepagesz 引导参数。从 boot 参数中减去 OvsDpdkSocketMemory,计算虚拟机的巨页数量。以下值也有效:

  • small (默认)- 使用最小页面大小
  • large - 只使用大页大小。(x86 架构上的 2MB 或 1GB)
  • any - 计算驱动程序都可尝试使用大页,但如果不可用,则默认为 small。
hw:emulator_threads_policy
将此参数的值设为 share,以便仿真程序线程锁定在 heat 参数( NovaComputeCpuSharedSet 中已标识)的 CPU。如果仿真程序线程在带有轮询模式驱动程序(PMD)或实时处理的 vCPU 上运行,您可以遇到负面影响,如数据包丢失。

7.5. 两个 NUMA 节点示例 OVS-DPDK 部署

以下示例中的 Compute 节点包含两个 NUMA 节点:

  • NUMA 0 具有内核 0-7。同级线程对有(0,1)、(2,3)、(4,5)和(6,7)
  • NUMA 1 有内核 8-15。同级线程对是(8,9),(10,11)、(12,13)和(14,15)。
  • 每个 NUMA 节点连接到物理 NIC,即 NUMA 0 上的 NIC1,在 NUMA 1 上是 NIC2。
OpenStack NFV NUMA Nodes 453316 0717 ECE OVS DPDK Deployment
注意

为非数据路径 DPDK 进程保留第一个物理内核或每个 NUMA 节点(0、1 和 89)的线程对。

本例还假设一个 1500 MTU 配置,因此 OvsDpdkSocketMemory 对所有用例都相同:

OvsDpdkSocketMemory: "1024,1024"

NIC 1 用于 DPDK,对 PMD 有一个物理内核

在这种情况下,您可以为 PMD 分配 NUMA 0 上的一个物理内核。您还必须在 NUMA 1 上分配一个物理内核,即使该 NUMA 节点的 NIC 上没有启用 DPDK。为客户机实例分配剩余的内核。生成的参数设置有:

OvsPmdCoreList: "2,3,10,11"
NovaComputeCpuDedicatedSet: "4,5,6,7,12,13,14,15"

NIC 1 用于 DPDK,用于 PMD 的两个物理内核

在这种情况下,您可以为 PMD 分配两个物理内核在 NUMA 0 上。您还必须在 NUMA 1 上分配一个物理内核,即使该 NUMA 节点的 NIC 上没有启用 DPDK。为客户机实例分配剩余的内核。生成的参数设置有:

OvsPmdCoreList: "2,3,4,5,10,11"
NovaComputeCpuDedicatedSet: "6,7,12,13,14,15"

NIC 2 用于 DPDK,对 PMD 有一个物理内核

在这种情况下,您可以为 PMD 为 NUMA 1 分配一个物理内核。您还必须在 NUMA 0 上分配一个物理内核,即使该 NUMA 节点的 NIC 上没有启用 DPDK。为客户机实例分配剩余的内核。生成的参数设置有:

OvsPmdCoreList: "2,3,10,11"
NovaComputeCpuDedicatedSet: "4,5,6,7,12,13,14,15"

NIC 2 用于 DPDK,用于 PMD 的两个物理内核

在这种情况下,您可以为 PMD 在 NUMA 1 上分配两个物理内核。您还必须在 NUMA 0 上分配一个物理内核,即使该 NUMA 节点的 NIC 上没有启用 DPDK。为客户机实例分配剩余的内核。生成的参数设置有:

OvsPmdCoreList: "2,3,10,11,12,13"
NovaComputeCpuDedicatedSet: "4,5,6,7,14,15"

用于 DPDK 的 NIC 1 和 NIC2,用于 PMD 的两个物理内核

在这种情况下,您可以为 PMD 在每个 NUMA 节点上分配两个物理内核。为客户机实例分配剩余的内核。生成的参数设置有:

OvsPmdCoreList: "2,3,4,5,10,11,12,13"
NovaComputeCpuDedicatedSet: "6,7,14,15"

7.6. NFV OVS-DPDK 部署的拓扑

这个示例部署显示 OVS-DPDK 配置,它由两个虚拟网络功能(VNF)组成,各自有两个接口:

  • 管理接口,由 mgt 表示。
  • data plane 接口。

在 OVS-DPDK 部署中,VNF 使用支持物理接口的、内置 DPDK 来运行。OVS-DPDK 在 vSwitch 级别上启用绑定。为了提高 OVS-DPDK 部署的性能,建议您分隔内核和 OVS-DPDK NIC。要分隔管理(mgt)网络,连接到虚拟机的 Base 提供商网络,请确保您有额外的 NIC。Compute 节点由两个常规 NIC 组成,用于 Red Hat OpenStack Platform API 管理,它们可以被 Ceph API 使用,但不能与任何 OpenStack 项目共享。

NFV OVS-DPDK 部署

NFV OVS-DPDK 拓扑

下图显示了 NFV 的 OVS-DPDK 的拓扑。它由具有 1 个或 10 Gbps NIC 和 director 节点的 Compute 和 Controller 节点组成。

NFV OVS-DPDK 拓扑

第 8 章 配置 OVS-DPDK 部署

本节在 Red Hat OpenStack Platform 环境中部署 OVS-DPDK。overcloud 通常由预定义角色的节点组成,如 Controller 节点、计算节点和不同的存储节点类型。这些默认角色各自包含 director 节点上的核心 heat 模板中定义的一组服务。

您必须先安装和配置 undercloud,然后才能部署 overcloud。详情请查看 Director 安装和使用指南

重要

您必须确定 network-environment.yaml 文件中找到的 OVS-DPDK 参数的最佳值,以优化 OVS-DPDK 的 OpenStack 网络。

注意

不要手动编辑 director heat 模板修改的 etc/tuned/cpu-partitioning-variables.conf 中的 isolated_cores 或其他值。

8.1. 使用工作流推断 DPDK 参数

重要

该功能在此发行版本中作为技术预览提供,因此不享有红帽的全面支持。它只应用于测试,不应部署在生产环境中。有关技术预览功能的更多信息,请参阅覆盖范围详细信息

有关 DPDK 的 Mistral 工作流概述,请参阅 第 7.2 节 “工作流和派生参数”

先决条件

您必须启用裸机内省,包括硬件检查额外的(inspection_extras)来提供此工作流检索的数据。默认情况下启用硬件检查额外的功能。有关节点硬件的更多信息,请参阅: 检查节点的硬件

为 DPDK 定义工作流和输入参数

以下列表概述了您可以提供给 OVS-DPDK 工作流的输入参数:

num_phy_cores_per_numa_node_for_pmd
此输入参数指定与 DPDK NIC 关联的 NUMA 节点所需的最小内核数。为不与 DPDK NIC 关联的其他 NUMA 节点分配一个物理内核。确保此参数设置为 1。
huge_page_allocation_percentage
此输入参数指定内存所需的总内存百分比,不包括 NovaReservedHostMemory,它们可以配置为大页面。KernelArgs 参数使用基于指定的 huge_page_allocation_percentage 计算的巨页来派生。确保将此参数设置为 50。

工作流从这些输入参数和裸机内省详情中计算适当的 DPDK 参数值。

为 DPDK 定义工作流和输入参数:

  1. usr/share/openstack-tripleo-heat-templates/plan-samples/plan-environment-derived-params.yaml 文件复制到一个本地目录,再设置输入参数以适合您的环境。

      workflow_parameters:
        tripleo.derive_params.v1.derive_parameters:
          # DPDK Parameters #
          # Specifies the minimum number of CPU physical cores to be allocated for DPDK
          # PMD threads. The actual allocation will be based on network config, if
          # the a DPDK port is associated with a numa node, then this configuration
          # will be used, else 1.
          num_phy_cores_per_numa_node_for_pmd: 1
          # Amount of memory to be configured as huge pages in percentage. Ouf the
          # total available memory (excluding the NovaReservedHostMemory), the
          # specified percentage of the remaining is configured as huge pages.
          huge_page_allocation_percentage: 50
  2. 运行 openstack overcloud deploy 命令并包括以下信息:

    • update-plan-only 选项
    • 特定于您的环境的角色文件和所有环境文件
    • plan-environment-derived-parms.yaml 文件,使用 --plan-environment-file 可选参数

      $ openstack overcloud deploy --templates --update-plan-only \
      -r /home/stack/roles_data.yaml \
      -e /home/stack/<environment-file> \
      ... _#repeat as necessary_ ...
      **-p /home/stack/plan-environment-derived-params.yaml**

此命令的输出显示派生结果,结果也合并到 plan-environment.yaml 文件中。

Started Mistral Workflow tripleo.validations.v1.check_pre_deployment_validations. Execution ID: 55ba73f2-2ef4-4da1-94e9-eae2fdc35535
Waiting for messages on queue '472a4180-e91b-4f9e-bd4c-1fbdfbcf414f' with no timeout.
Removing the current plan files
Uploading new plan files
Started Mistral Workflow tripleo.plan_management.v1.update_deployment_plan. Execution ID: 7fa995f3-7e0f-4c9e-9234-dd5292e8c722
Plan updated.
Processing templates in the directory /tmp/tripleoclient-SY6RcY/tripleo-heat-templates
Invoking workflow (tripleo.derive_params.v1.derive_parameters) specified in plan-environment file
Started Mistral Workflow tripleo.derive_params.v1.derive_parameters. Execution ID: 2d4572bf-4c5b-41f8-8981-c84a363dd95b
Workflow execution is completed. result:
ComputeOvsDpdkParameters:
 IsolCpusList: 1,2,3,4,5,6,7,9,10,17,18,19,20,21,22,23,11,12,13,14,15,25,26,27,28,29,30,31
 KernelArgs: default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on
   isolcpus=1,2,3,4,5,6,7,9,10,17,18,19,20,21,22,23,11,12,13,14,15,25,26,27,28,29,30,31
 NovaReservedHostMemory: 4096
 NovaComputeCpuDedicatedSet: 2,3,4,5,6,7,18,19,20,21,22,23,10,11,12,13,14,15,26,27,28,29,30,31
 OvsDpdkMemoryChannels: 4
 OvsDpdkSocketMemory: 1024,1024
 OvsPmdCoreList: 1,17,9,25
注意

OvsDpdkMemoryChannels 参数不能从内省详情衍生。在大多数情况下,这个值应该是 4。

使用派生参数部署 overcloud

使用这些派生参数部署 overcloud:

  1. 将派生的参数从 deploy 命令输出中复制到 network-environment.yaml 文件。

      # DPDK compute node.
      ComputeOvsDpdkParameters:
        KernelArgs: default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on
        TunedProfileName: "cpu-partitioning"
        IsolCpusList: "1,2,3,4,5,6,7,9,10,17,18,19,20,21,22,23,11,12,13,14,15,25,26,27,28,29,30,31"
        NovaComputeCpuDedicatedSet: ['2,3,4,5,6,7,18,19,20,21,22,23,10,11,12,13,14,15,26,27,28,29,30,31']
        NovaReservedHostMemory: 4096
        OvsDpdkSocketMemory: "1024,1024"
        OvsDpdkMemoryChannels: "4"
        OvsPmdCoreList: "1,17,9,25"
    注意

    这些参数应用到特定的角色 ComputeOvsDpdk。您可以在全局范围内应用这些参数,但特定于角色的参数覆盖任何全局参数。

  2. 使用角色文件以及特定于您的环境的所有环境文件,部署 overcloud。
 openstack overcloud deploy --templates \
 -r /home/stack/roles_data.yaml \
 -e /home/stack/<environment-file> \
... #repeat as necessary ...
注意

在使用 Compute、ComputeOvsDpdk 和 ComputeSriov 的集群中,工作流只为 ComputeOvsDpdk 角色应用公式,而不是 Compute 或 ComputeSriovs。

8.2. OVS-DPDK 拓扑

在 Red Hat OpenStack Platform 中,您可以使用可组合角色功能创建自定义部署角色,从每个角色添加或删除服务。有关可组合角色的更多信息,请参阅高级 Overcloud 自定义中可组合服务和自定义角色

此镜像显示了一个 OVS-DPDK 拓扑,其中包含 control plane 和 data plane 两个绑定端口:

OpenStack NFV Config Guide Topology 450694 0617 ECE OVS DPDK

要配置 OVS-DPDK,请执行以下任务:

  • 如果使用可组合角色,请复制并修改 roles_data.yaml 文件,以便为 OVS-DPDK 添加自定义角色。
  • 更新适当的 network-environment.yaml 文件,使其包含内核参数和 DPDK 参数的参数。
  • 更新 compute.yaml 文件,使其包含 DPDK 接口参数的网桥。
  • 更新 controller.yaml 文件,使其包含 DPDK 接口参数的相同网桥详情。
  • 运行 overcloud_deploy.sh 脚本,以使用 DPDK 参数部署 overcloud。
注意

本指南提供了 CPU 分配、内存分配和 NIC 配置可能因拓扑和用例而异的示例。有关硬件和配置选项的更多信息,请参阅: 网络功能虚拟化产品指南和 第 2 章 硬件要求

先决条件

注意

Red Hat OpenStack Platform 在 OVS-DPDK 部署的 OVS 客户端模式中运行。

8.3. 为 OVS-DPDK 接口设置 MTU 值

红帽 OpenStack 平台支持 OVS-DPDK 的巨型帧。要为巨型帧设置最大传输单元(MTU)值:

  • network-environment.yaml 文件中为 networking 设置全局 MTU 值。
  • compute.yaml 文件中设置物理 DPDK 端口 MTU 值。vhost 用户界面也使用这个值。
  • 在 Compute 节点上的任何客户端实例中设置 MTU 值,以确保您的配置中有可比较的 MTU 值从结尾。
注意

VXLAN 数据包在标头中包含额外的 50 字节。根据这些额外标头字节计算您的 MTU 要求。例如,MTU 值为 9000,表示 VXLAN 隧道 MTU 8950 用于这些额外字节。

注意

您不需要物理 NIC 的任何特殊配置,因为 NIC 由 DPDK PMD 控制,并且具有 compute.yaml 文件设置的相同 MTU 值。您不能设置大于物理 NIC 支持的最大值的 MTU 值。

为 OVS-DPDK 接口设置 MTU 值:

  1. network-environment.yaml 文件中设置 NeutronGlobalPhysnetMtu 参数。

    parameter_defaults:
      # MTU global configuration
      NeutronGlobalPhysnetMtu: 9000
    注意

    确保 network-environment.yaml 文件中的 OvsDpdkSocketMemory 值足够大,以支持巨型帧。详情请查看 第 7.4.2 节 “内存参数”

  2. 将网桥上的 MTU 值设置为 controller.yaml 文件中的 Compute 节点。

      -
        type: ovs_bridge
        name: br-link0
        use_dhcp: false
        members:
          -
            type: interface
            name: nic3
            mtu: 9000
  3. compute.yaml 文件中为 OVS-DPDK 绑定设置 MTU 值:

    - type: ovs_user_bridge
      name: br-link0
      use_dhcp: false
      members:
        - type: ovs_dpdk_bond
          name: dpdkbond0
          mtu: 9000
          rx_queue: 2
          members:
            - type: ovs_dpdk_port
              name: dpdk0
              mtu: 9000
              members:
                - type: interface
                  name: nic4
            - type: ovs_dpdk_port
              name: dpdk1
              mtu: 9000
              members:
                - type: interface
                  name: nic5

8.4. 为安全组配置防火墙

dataPlane 接口需要有状态的防火墙的性能。为保护这些接口,请考虑将电信级防火墙部署为虚拟网络功能(VNF)。

要配置 control plane 接口,请将 NeutronOVSFirewallDriver 参数设置为 openvswitch。要使用基于流的 OVS 防火墙驱动程序,请在 parameter_defaults 下修改 network-environment.yaml 文件。

例如:

parameter_defaults:
  NeutronOVSFirewallDriver: openvswitch

使用 openstack port set 命令,为 dataplane 接口禁用 OVS 防火墙驱动程序。

例如:

openstack port set --no-security-group  --disable-port-security ${PORT}

8.5. 为 OVS-DPDK 接口设置多队列

注意

多队列是实验性的,只支持手动队列固定。

流程

  • 要为 Compute 节点上的 OVS-DPDK 中的接口设置相同的队列,修改 compute.yaml 文件:

    - type: ovs_user_bridge
      name: br-link0
      use_dhcp: false
      members:
        - type: ovs_dpdk_bond
          name: dpdkbond0
          mtu: 9000
          rx_queue: 2
          members:
            - type: ovs_dpdk_port
              name: dpdk0
              mtu: 9000
              members:
                - type: interface
                  name: nic4
            - type: ovs_dpdk_port
              name: dpdk1
              mtu: 9000
              members:
                - type: interface
                  name: nic5

8.6. 已知限制

在为 NFV 配置 OVS-DPDK 时,观察以下限制:

  • 将 Linux 绑定用于非 DPDK 流量和 control plane 网络,如内部、管理、存储、存储管理和租户。确保绑定中使用的 PCI 设备都位于同一个 NUMA 节点上,以获得最佳性能。红帽不支持 Neutron Linux 网桥配置。
  • 对于在带有 OVS-DPDK 的主机上运行的每个实例,您需要巨页。如果客户机中没有巨页,则接口会出现但无法正常工作。
  • 使用 OVS-DPDK 时,服务性能降级使用 tap 设备,如分布式虚拟路由(DVR)。生成的性能不适用于生产环境。
  • 在使用 OVS-DPDK 时,同一 Compute 节点上的所有网桥都必须是 ovs_user_bridge 类型。director 可以接受配置,但 Red Hat OpenStack Platform 不支持同一节点上的 ovs_bridgeovs_user_bridge

8.7. 创建类别并部署 OVS-DPDK 实例

在使用 NFV 的 Red Hat OpenStack Platform 部署配置了 OVS-DPDK 后,您可以使用下列步骤创建实例:

  1. 创建聚合组,并为 OVS-DPDK 添加相关主机。定义与定义的类别元数据匹配的元数据,如 dpdk=true

     # openstack aggregate create dpdk_group
     # openstack aggregate add host dpdk_group [compute-host]
     # openstack aggregate set --property dpdk=true dpdk_group
    注意

    固定 CPU 实例可以位于与未固定实例相同的 Compute 节点上。如需更多信息,请参阅配置实例创建指南中的在 Compute 节点上配置 CPU 固定

  2. 创建类别。

    # openstack flavor create <flavor> --ram <MB> --disk <GB> --vcpus <#>
  3. 设置类别属性。请注意,定义的元数据 dpdk=true 与 DPDK 聚合中定义的元数据匹配。

    # openstack flavor set <flavor> --property dpdk=true --property hw:cpu_policy=dedicated --property hw:mem_page_size=1GB --property hw:emulator_threads_policy=isolate

    有关性能改进的仿真程序线程策略的详情,请参阅配置仿真程序线程

  4. 创建网络。

    # openstack network create net1 --provider-physical-network tenant --provider-network-type vlan --provider-segment <VLAN-ID>
    # openstack subnet create subnet1 --network net1 --subnet-range 192.0.2.0/24 --dhcp
  5. 可选:如果您将多队列用于 OVS-DPDK,请在要用于创建实例的镜像上设置 hw_vif_multiqueue_enabled 属性:

    # openstack image set --property hw_vif_multiqueue_enabled=true <image>
  6. 部署实例。

    # openstack server create --flavor <flavor> --image <glance image> --nic net-id=<network ID> <server_name>

8.8. 对 OVS-DPDK 配置进行故障排除

本节介绍对 OVS-DPDK 配置进行故障排除的步骤。

  1. 检查网桥配置,并确认网桥具有 datapath_type=netdev

    # ovs-vsctl list bridge br0
    _uuid               : bdce0825-e263-4d15-b256-f01222df96f3
    auto_attach         : []
    controller          : []
    datapath_id         : "00002608cebd154d"
    datapath_type       : netdev
    datapath_version    : "<built-in>"
    external_ids        : {}
    fail_mode           : []
    flood_vlans         : []
    flow_tables         : {}
    ipfix               : []
    mcast_snooping_enable: false
    mirrors             : []
    name                : "br0"
    netflow             : []
    other_config        : {}
    ports               : [52725b91-de7f-41e7-bb49-3b7e50354138]
    protocols           : []
    rstp_enable         : false
    rstp_status         : {}
    sflow               : []
    status              : {}
    stp_enable          : false
  2. 另外,您可以查看错误的日志,如容器无法启动。

    # less /var/log/containers/neutron/openvswitch-agent.log
  3. 确认 ovs-dpdk 的 Poll Mode Driver CPU 掩码固定到 CPU。如果出现超线程,请使用同级 CPU。

    例如,要检查 CPU4 的同级,请运行以下命令:

    # cat /sys/devices/system/cpu/cpu4/topology/thread_siblings_list
    4,20

    CPU4 的同级是 CPU20,因此使用以下命令:

    # ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x100010

    显示状态:

    # tuna -t ovs-vswitchd -CP
    thread  ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary       cmd
    3161	OTHER 	0    	6	765023      	614	ovs-vswitchd
    3219   OTHER 	0    	6     	1        	0   	handler24
    3220   OTHER 	0    	6     	1        	0   	handler21
    3221   OTHER 	0    	6     	1        	0   	handler22
    3222   OTHER 	0    	6     	1        	0   	handler23
    3223   OTHER 	0    	6     	1        	0   	handler25
    3224   OTHER 	0    	6     	1        	0   	handler26
    3225   OTHER 	0    	6     	1        	0   	handler27
    3226   OTHER 	0    	6     	1        	0   	handler28
    3227   OTHER 	0    	6     	2        	0   	handler31
    3228   OTHER 	0    	6     	2        	4   	handler30
    3229   OTHER 	0    	6     	2        	5   	handler32
    3230   OTHER 	0    	6	953538      	431   revalidator29
    3231   OTHER 	0    	6   1424258      	976   revalidator33
    3232   OTHER 	0    	6   1424693      	836   revalidator34
    3233   OTHER 	0    	6	951678      	503   revalidator36
    3234   OTHER 	0    	6   1425128      	498   revalidator35
    *3235   OTHER 	0    	4	151123       	51       	pmd37*
    *3236   OTHER 	0   	20	298967       	48       	pmd38*
    3164   OTHER 	0    	6 	47575        	0  dpdk_watchdog3
    3165   OTHER 	0    	6	237634        	0   vhost_thread1
    3166   OTHER 	0    	6  	3665        	0       	urcu2

第 9 章 调优 Red Hat OpenStack Platform 环境

9.1. 固定仿真程序线程

仿真程序线程处理对虚拟机硬件模拟的中断请求和非阻塞进程。在客户机用于处理的 CPU 之间这些线程浮点数。如果用于轮询模式驱动程序(PMD)或实时处理的线程在这些客户机 CPU 上运行,您可以遇到数据包丢失或丢失的期限。

您可以将仿真程序线程与虚拟机处理任务分开,方法是将线程固定到自己的客户机 CPU,从而提高性能。

9.1.1. 将 CPU 配置为主机仿真程序线程

为提高性能,请为托管仿真程序线程保留主机 CPU 的子集。

流程
  1. 使用为给定角色定义的 NovaComputeCpuSharedSet 部署 overcloud。NovaComputeCpuSharedSet 的值适用于该角色内主机的 nova.conf 文件中的 cpu_shared_set 参数。

    parameter_defaults:
        ComputeOvsDpdkParameters:
            NovaComputeCpuSharedSet: "0-1,16-17"
            NovaComputeCpuDedicatedSet: "2-15,18-31"
  2. 创建类别,以构建独立于共享池的仿真程序线程的实例。

    openstack flavor create --ram <size_mb> --disk <size_gb> --vcpus <vcpus> <flavor>
  3. 添加 hw:emulator_threads_policy 额外规格,并将值设为 共享。使用此类别创建的实例将使用 nova.conf 文件中的 cpu_share_set 参数中定义的实例 CPU。

    openstack flavor set <flavor> --property hw:emulator_threads_policy=share
注意

您必须在 nova.conf 文件中设置 cpu_share_set 参数,以便为这个额外规格启用共享策略。您应该最好使用 heat,因为手动编辑 nova.conf 可能无法在重新部署后保留。

9.1.2. 验证仿真程序线程固定

流程
  1. 识别给定实例的主机名和名称。

    openstack server show <instance_id>
  2. 以 heat-admin 用户身份使用 SSH 登录标识的主机。

    ssh heat-admin@compute-1
    [compute-1]$ sudo virsh dumpxml instance-00001 | grep `'emulatorpin cpuset'`

9.2. 为 NFV 工作负载启用 RT-KVM

为了协助安装和配置 Red Hat Enterprise Linux 8.2 Real Time KVM (RT-KVM),Red Hat OpenStack Platform 提供了以下功能:

  • 为实时置备 Red Hat Enterprise Linux 的实时 Compute 节点角色。
  • 额外的 RT-KVM 内核模块。
  • 自动配置 Compute 节点。

9.2.1. 规划您的 RT-KVM Compute 节点

您必须使用 Red Hat 认证的服务器作为 RT-KVM Compute 节点。如需更多信息,请参阅: Red Hat Enterprise Linux for Real Time 7 认证的服务器

有关如何为 RT-KVM 启用 rhel-8-server-nfv-rpms 存储库的详细信息,并确保您的系统是最新的,请参阅: 注册和更新 undercloud

注意

您需要单独订阅 Red Hat OpenStack Platform for Real Time SKU,才能访问此软件仓库。

构建实时镜像

  1. 在 undercloud 上安装 libguestfs-tools 软件包以获取 virt-customize 工具:

    (undercloud) [stack@undercloud-0 ~]$ sudo dnf install libguestfs-tools
    重要

    如果在 undercloud 上安装 libguestfs-tools 软件包,请禁用 iscsid.socket 以避免与 undercloud 上的 tripleo_iscsid 服务冲突:

    $ sudo systemctl disable --now iscsid.socket
  2. 提取镜像:

    (undercloud) [stack@undercloud-0 ~]$ tar -xf /usr/share/rhosp-director-images/overcloud-full.tar
    (undercloud) [stack@undercloud-0 ~]$ tar -xf /usr/share/rhosp-director-images/ironic-python-agent.tar
  3. 复制默认镜像:

    (undercloud) [stack@undercloud-0 ~]$ cp overcloud-full.qcow2 overcloud-realtime-compute.qcow2
  4. 注册您的镜像,以启用与您的自定义相关的红帽软件仓库。在以下示例中,用有效的凭证替换 [username][password]

    virt-customize -a overcloud-realtime-compute.qcow2 --run-command \
    'subscription-manager register --username=[username] --password=[password]' \
    subscription-manager release --set 8.2
    注意

    为安全起见,您可以在命令提示符上使用凭据时从历史记录文件中删除凭据。您可以使用 history -d 命令(后跟行号)删除历史记录中的个别行。

  5. 从您的帐户的订阅中查找池 ID 列表,并将适当的池 ID 附加到您的镜像。

    sudo subscription-manager list --all --available | less
    ...
    virt-customize -a overcloud-realtime-compute.qcow2 --run-command \
    'subscription-manager attach --pool [pool-ID]'
  6. 使用 NFV 添加 Red Hat OpenStack Platform 所需的存储库。

    virt-customize -a overcloud-realtime-compute.qcow2 --run-command \
    'sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-eus-rpms \
    --enable=rhel-8-for-x86_64-appstream-eus-rpms \
    --enable=rhel-8-for-x86_64-highavailability-eus-rpms \
    --enable=ansible-2.9-for-rhel-8-x86_64-rpms \
    --enable=openstack-16.1-for-rhel-8-x86_64-rpms \
    --enable=rhel-8-for-x86_64-nfv-rpms \
    --enable=advanced-virt-for-rhel-8-x86_64-rpms \
    --enable=fast-datapath-for-rhel-8-x86_64-rpms'
  7. 创建一个脚本,以在镜像上配置实时功能。

    (undercloud) [stack@undercloud-0 ~]$ cat <<'EOF' > rt.sh
      #!/bin/bash
    
      set -eux
    
      dnf -v -y --setopt=protected_packages= erase kernel.$(uname -m)
      dnf -v -y install kernel-rt kernel-rt-kvm tuned-profiles-nfv-host
      grubby --set-default /boot/vmlinuz*rt*
      EOF
  8. 运行脚本以配置实时镜像:

    (undercloud) [stack@undercloud-0 ~]$ virt-customize -a overcloud-realtime-compute.qcow2 -v --run rt.sh 2>&1 | tee virt-customize.log
    注意

    如果您在 rt.sh 脚本输出中看到以下行,"grubby fatal 错误:无法找到合适的模板",您可以忽略此错误。

  9. 检查导致上一命令导致的 virt-customize.log 文件,以检查通过 rt.sh 脚本正确安装的软件包。

    (undercloud) [stack@undercloud-0 ~]$ cat virt-customize.log | grep Verifying
    
      Verifying  : kernel-3.10.0-957.el7.x86_64                                 1/1
      Verifying  : 10:qemu-kvm-tools-rhev-2.12.0-18.el7_6.1.x86_64              1/8
      Verifying  : tuned-profiles-realtime-2.10.0-6.el7_6.3.noarch              2/8
      Verifying  : linux-firmware-20180911-69.git85c5d90.el7.noarch             3/8
      Verifying  : tuned-profiles-nfv-host-2.10.0-6.el7_6.3.noarch              4/8
      Verifying  : kernel-rt-kvm-3.10.0-957.10.1.rt56.921.el7.x86_64            5/8
      Verifying  : tuna-0.13-6.el7.noarch                                       6/8
      Verifying  : kernel-rt-3.10.0-957.10.1.rt56.921.el7.x86_64                7/8
      Verifying  : rt-setup-2.0-6.el7.x86_64                                    8/8
  10. 重新标记 SELinux:

    (undercloud) [stack@undercloud-0 ~]$ virt-customize -a overcloud-realtime-compute.qcow2 --selinux-relabel
  11. 提取 vmlinuz 和 initrd:

    (undercloud) [stack@undercloud-0 ~]$ mkdir image
    (undercloud) [stack@undercloud-0 ~]$ guestmount -a overcloud-realtime-compute.qcow2 -i --ro image
    (undercloud) [stack@undercloud-0 ~]$ cp image/boot/vmlinuz-3.10.0-862.rt56.804.el7.x86_64 ./overcloud-realtime-compute.vmlinuz
    (undercloud) [stack@undercloud-0 ~]$ cp image/boot/initramfs-3.10.0-862.rt56.804.el7.x86_64.img ./overcloud-realtime-compute.initrd
    (undercloud) [stack@undercloud-0 ~]$ guestunmount image
    注意

    vmlinuzinitramfs 文件名中的软件版本因内核版本而异。

  12. 上传镜像:

    (undercloud) [stack@undercloud-0 ~]$ openstack overcloud image upload --update-existing --os-image-name overcloud-realtime-compute.qcow2

现在,您可以在所选 Compute 节点上与 ComputeOvsDpdkRT 可组合角色一起使用的实时镜像。

修改 RT-KVM Compute 节点上的 BIOS 设置

要减少 RT-KVM Compute 节点上的延迟,请在 Compute 节点 BIOS 设置中禁用以下参数所有选项:

  • 电源管理
  • 超线程
  • CPU 睡眠状态
  • 逻辑处理器

有关这些设置的描述以及禁用它们的影响,请参阅设置 BIOS 参数。有关如何更改 BIOS 设置的详情,请查看您的硬件厂商文档。

9.2.2. 使用 RT-KVM 配置 OVS-DPDK

注意

您必须确定 network-environment.yaml 文件中设置的 OVS-DPDK 参数的最佳值,以优化 OVS-DPDK 的 OpenStack 网络。如需了解更多详细信息,请参阅 第 8.1 节 “使用工作流推断 DPDK 参数”

9.2.2.1. 生成 ComputeOvsDpdk 可组合角色

使用 ComputeOvsDpdkRT 角色为实时计算镜像指定 Compute 节点。

ComputeOvsDpdkRT 角色生成 roles_data.yaml

# (undercloud) [stack@undercloud-0 ~]$ openstack overcloud roles generate -o roles_data.yaml Controller ComputeOvsDpdkRT

9.2.2.2. 配置 OVS-DPDK 参数

重要

确定 network-environment.yaml 文件中的 OVS-DPDK 参数的最佳值,以优化您的部署。更多信息请参阅 第 8.1 节 “使用工作流推断 DPDK 参数”

  1. 为您在 resource_registry 下使用的 OVS-DPDK 角色添加 NIC 配置:

    resource_registry:
      # Specify the relative/absolute path to the config files you want to use for override the default.
      OS::TripleO::ComputeOvsDpdkRT::Net::SoftwareConfig: nic-configs/compute-ovs-dpdk.yaml
      OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml
  2. parameter_defaults 下,设置 OVS-DPDK 和 RT-KVM 参数:

      # DPDK compute node.
      ComputeOvsDpdkRTParameters:
        KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=1-7,17-23,9-15,25-31"
        TunedProfileName: "realtime-virtual-host"
        IsolCpusList: "1,2,3,4,5,6,7,9,10,17,18,19,20,21,22,23,11,12,13,14,15,25,26,27,28,29,30,31"
        NovaComputeCpuDedicatedSet: ['2,3,4,5,6,7,18,19,20,21,22,23,10,11,12,13,14,15,26,27,28,29,30,31']
        NovaReservedHostMemory: 4096
        OvsDpdkSocketMemory: "1024,1024"
        OvsDpdkMemoryChannels: "4"
        OvsPmdCoreList: "1,17,9,25"
        VhostuserSocketGroup: "hugetlbfs"
      ComputeOvsDpdkRTImage: "overcloud-realtime-compute"

9.2.2.3. 部署 overcloud

为 ML2-OVS 部署 overcloud:

(undercloud) [stack@undercloud-0 ~]$ openstack overcloud deploy \
--templates \
-r /home/stack/ospd-16-vlan-dpdk-ctlplane-bonding-rt/roles_data.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs-dpdk.yaml \
-e /home/stack/ospd-16-vxlan-dpdk-data-bonding-rt-hybrid/containers-prepare-parameter.yaml \
-e /home/stack/ospd-16-vxlan-dpdk-data-bonding-rt-hybrid/network-environment.yaml

9.2.3. 启动 RT-KVM 实例

执行以下步骤在启用了实时 Compute 节点上启动 RT-KVM 实例:

  1. 在 overcloud 上创建 RT-KVM 类别:

    # openstack flavor create  r1.small 99 4096 20 4
    # openstack flavor set --property hw:cpu_policy=dedicated 99
    # openstack flavor set --property hw:cpu_realtime=yes 99
    # openstack flavor set --property hw:mem_page_size=1GB 99
    # openstack flavor set --property hw:cpu_realtime_mask="^0-1" 99
    # openstack flavor set --property hw:cpu_emulator_threads=isolate 99
  2. 启动 RT-KVM 实例:

    # openstack server create  --image <rhel> --flavor r1.small --nic net-id=<dpdk-net> test-rt
  3. 要验证实例是否使用分配的仿真程序线程,请运行以下命令:

    # virsh dumpxml <instance-id> | grep vcpu -A1
    <vcpu placement='static'>4</vcpu>
    <cputune>
      <vcpupin vcpu='0' cpuset='1'/>
      <vcpupin vcpu='1' cpuset='3'/>
      <vcpupin vcpu='2' cpuset='5'/>
      <vcpupin vcpu='3' cpuset='7'/>
      <emulatorpin cpuset='0-1'/>
      <vcpusched vcpus='2-3' scheduler='fifo'
      priority='1'/>
    </cputune>

9.3. 可信虚拟功能

您可以配置物理功能(PF)和虚拟功能(VF)之间的信任,以便 VF 能够执行特权操作,如启用混杂模式或修改硬件地址。

9.3.1. 配置虚拟功能和物理功能间的信任

先决条件
  • Red Hat OpenStack Platform 的操作安装,包括 director
流程

完成以下步骤,使用物理和虚拟功能间的信任配置和部署 overcloud:

  1. parameter_defaults 部分中添加 NeutronPhysicalDevMappings 参数,以在逻辑网络名称和物理接口之间链接。

    parameter_defaults:
      NeutronPhysicalDevMappings:
        - sriov2:p5p2
  2. 将新属性 trusted 添加到 SR-IOV 参数。

    parameter_defaults:
      NeutronPhysicalDevMappings:
        - sriov2:p5p2
      NovaPCIPassthrough:
        - vendor_id: "8086"
          product_id: "1572"
          physical_network: "sriov2"
          trusted: "true"
    注意

    您必须把值 "true" 包含双引号。

9.3.2. 使用可信 VF 网络

  1. 创建类型为 vlan 的网络。

    openstack network create trusted_vf_network  --provider-network-type vlan \
     --provider-segment 111 --provider-physical-network sriov2 \
     --external --disable-port-security
  2. 创建子网。

    openstack subnet create --network trusted_vf_network \
      --ip-version 4 --subnet-range 192.168.111.0/24 --no-dhcp \
     subnet-trusted_vf_network
  3. 创建端口。将 vnic-type 选项设置为 direct,并将 binding-profile 选项设置为 true

    openstack port create --network sriov111 \
    --vnic-type direct --binding-profile trusted=true \
    sriov111_port_trusted
  4. 创建一个实例,并将它绑定到之前创建的可信端口。

    openstack server create --image rhel --flavor dpdk  --network internal --port trusted_vf_network_port_trusted --config-drive True --wait rhel-dpdk-sriov_trusted

验证虚拟机监控程序上的可信 VF 配置

  1. 在您创建实例的计算节点上,输入以下命令:

    # ip link
    7: p5p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
        link/ether b4:96:91:1c:40:fa brd ff:ff:ff:ff:ff:ff
        vf 6 MAC fa:16:3e:b8:91:c2, vlan 111, spoof checking off, link-state auto, trust on, query_rss off
        vf 7 MAC fa:16:3e:84:cf:c8, vlan 111, spoof checking off, link-state auto, trust off, query_rss off
  2. 验证 上 VF 的信任 状态。示例输出包含包含两个端口的环境的详细信息。请注意,vf 6 包含 上的文本信任
  3. 如果您在网络服务(neutron)网络中设置了 port_security_enabled: false,或者如果您在运行 openstack port create 命令时包含参数 --disable-port-security,可以禁用 spoof 检查。

9.4. 配置 RX/TX 队列大小

出于许多原因,您可能会遇到高于每秒 350 万条数据包的数据包丢失,例如:

  • 网络中断
  • a SMI
  • 虚拟功能中的数据包处理延迟

为防止数据包丢失,将队列大小从默认 512 增加到最大 1024。

先决条件

  • 要配置 RX,请确保您有 libvirt v2.3 和 QEMU v2.7。
  • 要配置 TX,请确保您有 libvirt v3.7 和 QEMU v2.10。

流程

  • 要增加 RX 和 TX 队列大小,请在相关 director 角色的 parameter_defaults: 部分包括以下行:以下是 ComputeOvsDpdk 角色示例:

    parameter_defaults:
      ComputeOvsDpdkParameters:
        -NovaLibvirtRxQueueSize: 1024
        -NovaLibvirtTxQueueSize: 1024

测试

  • 您可以在 nova.conf 文件中观察 RX 队列大小和 TX 队列大小的值:

    [libvirt]
    rx_queue_size=1024
    tx_queue_size=1024
  • 您可以在计算主机上由 libvirt 生成的 VM 实例 XML 文件中检查 RX 队列大小和 TX 队列大小。

    <devices>
       <interface type='vhostuser'>
         <mac address='56:48:4f:4d:5e:6f'/>
         <source type='unix' path='/tmp/vhost-user1' mode='server'/>
         <model type='virtio'/>
         <driver name='vhost' rx_queue_size='1024'   tx_queue_size='1024' />
         <address type='pci' domain='0x0000' bus='0x00' slot='0x10' function='0x0'/>
       </interface>
    </devices>

    要验证 RX 队列大小和 TX 队列大小的值,请在 KVM 主机上使用以下命令:

    $ virsh dumpxml <vm name> | grep queue_size
  • 您可以检查改进的性能,比如 3.8 mpps/core 在 0 帧丢失。

9.5. 配置 NUMA 感知的 vSwitch

重要

该功能在此发行版本中作为技术预览提供,因此不享有红帽的全面支持。它只应用于测试,不应部署在生产环境中。有关技术预览功能的更多信息,请参阅覆盖范围详细信息

在实现 NUMAaware vSwitch 前,检查硬件配置的以下组件:

  • 物理网络的数量。
  • PCI 卡的放置。
  • 服务器的物理架构。

内存映射的 I/O (MMIO)设备(如 PCIe NIC)与特定 NUMA 节点相关联。当虚拟机和 NIC 位于不同的 NUMA 节点上时,性能会有很大降低。要提高性能,请在同一 NUMA 节点上对齐 PCIe NIC 放置和实例处理。

使用此功能来确保共享物理网络的实例位于同一 NUMA 节点上。要优化数据中心硬件的利用率,必须使用多个 physnet。

警告

要配置 NUMA 感知网络以实现最佳服务器利用率,您必须了解 PCIe 插槽和 NUMA 节点的映射。有关具体硬件的详情,请参考您的厂商文档。如果无法正确计划或实施 NUMA-aware vSwitch,则可能导致服务器只使用单个 NUMA 节点。

为防止跨 NUMA 配置,请将虚拟机放在正确的 NUMA 节点上,方法是向 Nova 提供 NIC 的位置。

先决条件

  • 您已启用过滤器 NUMATopologyFilter

流程

  • 设置一个新的 NeutronPhysnetNUMANodesMapping 参数,将物理网络映射到与物理网络关联的 NUMA 节点。
  • 如果使用隧道,如 VxLAN 或 GRE,还必须设置 NeutronTunnelNUMANodes 参数。

    parameter_defaults:
      NeutronPhysnetNUMANodesMapping: {<physnet_name>: [<NUMA_NODE>]}
      NeutronTunnelNUMANodes: <NUMA_NODE>,<NUMA_NODE>

下面是一个与 NUMA 节点 0 连接的两个物理网络的示例:

  • 与 NUMA 节点 0 关联的项目网络
  • 个管理网络,没有任何关联性

    parameter_defaults:
      NeutronBridgeMappings:
        - tenant:br-link0
      NeutronPhysnetNUMANodesMapping: {tenant: [1], mgmt: [0,1]}
      NeutronTunnelNUMANodes: 0
  • 在以下示例中,将名为 eno2 的设备的 physnet 分配给 NUMA 编号 0。

    # ethtool -i eno2
    bus-info: 0000:18:00.1
    
    # cat /sys/devices/pci0000:16/0000:16:02.0/0000:18:00.1/numa_node
    0

    观察以下示例 heat 模板中的 physnet 设置。

    NeutronBridgeMappings: 'physnet1:br-physnet1'
    NeutronPhysnetNUMANodesMapping: {physnet1: [0] }
    
    - type: ovs_user_bridge
                    name: br-physnet1
                    mtu: 9000
                    members:
                      - type: ovs_dpdk_port
                        name: dpdk2
                        members:
                          - type: interface
                            name: eno2

测试 NUMA-aware vSwitch

  • 观察文件 /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf 中的配置

    [neutron_physnet_tenant]
    numa_nodes=1
    [neutron_tunnel]
    numa_nodes=1
  • 使用 lscpu 命令确认新配置:

    $ lscpu
  • 启动一个虚拟机,将 NIC 附加到适当的网络

已知限制

  • 如果您没有指定双节点客户机 NUMA 拓扑,则无法启动两个 NIC 连接到不同 NUMA 节点上的 physnets。
  • 如果没有指定双节点客户机 NUMA 拓扑,则无法启动一个连接到不同 NUMA 节点上的隧道网络的 NIC。
  • 如果您没有指定双节点客户机 NUMA 拓扑,则无法启动具有一个 vhost 端口和不同 NUMA 节点上的 VF 的虚拟机。
  • NUMA 感知 vSwitch 参数特定于 overcloud 角色。例如,计算节点 1 和 Compute 节点 2 可以具有不同的 NUMA 拓扑。
  • 如果虚拟机的接口具有 NUMA 关联性,请确保关联性仅针对一个 NUMA 节点。您可以在任何 NUMA 节点上找到任何接口,无需 NUMA 关联性。
  • 为数据平面网络配置 NUMA 关联性,不管理网络。
  • 隧道网络的 NUMA 关联性是适用于所有虚拟机的全局设置。

9.6. 在 NFVi 环境中配置服务质量(QoS)

有关配置 QoS 的详情,请参阅配置服务质量(QoS)策略。支持仅限于以下 QoS 规则类型:

  • SR-IOV 上的 最小带宽 (如果受供应商支持)。
  • SR-IOV 和 OVS-DPDK 出口接口的 带宽限制

9.7. 使用 HCI 和 DPDK 部署 overcloud

您可以通过共同定位和配置 Compute 和 Ceph Storage 服务以优化资源使用量来部署 NFV 基础架构。

有关超融合基础架构(HCI)的更多信息,请参阅: Hyper Converged Infrastructure Guide

前提条件
  • Red Hat OpenStack Platform 16.1.
  • Red Hat Ceph Storage 4 的最新版本。
  • 最新版本的 ceph-ansible 4,如 rhceph-4-tools-for-rhel-8-x86_64-rpms 存储库提供。
流程
  1. 在 undercloud 上安装 ceph-ansible

    $ sudo yum install ceph-ansible -y
  2. 为 ComputeHCI 角色生成 roles_data.yaml 文件。

    $ openstack overcloud roles generate -o ~/<templates>/roles_data.yaml Controller \
     ComputeHCIOvsDpdk
  3. 使用 openstack flavor createopenstack flavor set 命令创建和配置一个新类别。有关创建类别的更多信息,请参阅高级 Overcloud 自定义指南中的创建新角色
  4. 使用您生成的自定义 roles_data.yaml 文件部署 overcloud。

    # time openstack overcloud deploy --templates \
     --timeout 360 \
     -r ~/<templates>/roles_data.yaml \
     -e /usr/share/openstack-tripleo-heat-templates/environments/ceph-ansible/ceph-ansible.yaml \
     -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
     -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-ovs-dpdk.yaml \
     -e ~/<templates>/<custom environment file>

9.7.1. NUMA 节点配置示例

为提高性能,将租户网络和 Ceph 对象服务守护进程(OSD)放在一个 NUMA-0 中,如 NUMA-0,以及 VNF 和另一个 NUMA 节点上的任何非 NFV 虚拟机,如 NUMA-1。

CPU 分配:
NUMA-0NUMA-1

Ceph OSD 数量 * 4 HT

用于 VNF 和非NFV 虚拟机的客户机 vCPU

DPDK lcore - 2 HT

DPDK lcore - 2 HT

DPDK PMD - 2 HT

DPDK PMD - 2 HT

CPU 分配示例:
 NUMA-0NUMA-1

Ceph OSD

32,34,36,38,40,42,76,78,80,82,84,86

 

DPDK-lcore

0,44

1,45

DPDK-pmd

2,46

3,47

Nova

 

5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,49,51,53,55,57,59,61,63,65,67,69,71,73,75,77,79,81,83,85,87

9.7.2. ceph 配置文件示例

parameter_defaults:
  CephPoolDefaultSize: 3
  CephPoolDefaultPgNum: 64
  CephPools:
    - {"name": backups, "pg_num": 128, "pgp_num": 128, "application": "rbd"}
    - {"name": volumes, "pg_num": 256, "pgp_num": 256, "application": "rbd"}
    - {"name": vms, "pg_num": 64, "pgp_num": 64, "application": "rbd"}
    - {"name": images, "pg_num": 32, "pgp_num": 32, "application": "rbd"}
  CephConfigOverrides:
    osd_recovery_op_priority: 3
    osd_recovery_max_active: 3
    osd_max_backfills: 1
  CephAnsibleExtraConfig:
    nb_retry_wait_osd_up: 60
    delay_wait_osd_up: 20
    is_hci: true
    # 3 OSDs * 4 vCPUs per SSD = 12 vCPUs (list below not used for VNF)
    ceph_osd_docker_cpuset_cpus: "32,34,36,38,40,42,76,78,80,82,84,86" # 1
    # cpu_limit 0 means no limit as we are limiting CPUs with cpuset above
    ceph_osd_docker_cpu_limit: 0                                       # 2
    # numactl preferred to cross the numa boundary if we have to
    # but try to only use memory from numa node0
    # cpuset-mems would not let it cross numa boundary
    # lots of memory so NUMA boundary crossing unlikely
    ceph_osd_numactl_opts: "-N 0 --preferred=0"                        # 3
  CephAnsibleDisksConfig:
    osds_per_device: 1
    osd_scenario: lvm
    osd_objectstore: bluestore
    devices:
      - /dev/sda
      - /dev/sdb
      - /dev/sdc

使用下列参数,为 ceph OSD 进程分配 CPU 资源。根据此超融合环境中的工作负载和硬件调整值。

1
ceph_osd_docker_cpuset_cpus:为 SSD 磁盘的每个 OSD 分配 4 个 CPU 线程,或者为 HDD 磁盘的每个 OSD 分配 1 个 CPU。包含与 ceph 关联的 NUMA 节点的内核数和同级线程列表,以及三个列表中未找到的 CPU: NovaComputeCpuDedicatedSetOvsPmdCoreList
2
ceph_osd_docker_cpu_limit:将此值设置为 0, 以将 ceph OSD 固定到 ceph_osd_docker_cpuset_cpus 中的 CPU 列表。
3
ceph_osd_numactl_opts:将此值设置为跨 NUMA 操作 的首选 值,作为 precaution。

9.7.3. DPDK 配置文件示例

parameter_defaults:
  ComputeHCIParameters:
    KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=240 intel_iommu=on iommu=pt                                           # 1
      isolcpus=2,46,3,47,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,49,51,53,55,57,59,61,63,65,67,69,71,73,75,77,79,81,83,85,87"
    TunedProfileName: "cpu-partitioning"
    IsolCpusList:                                               # 2
      ”2,46,3,47,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,43,49,51,
      53,55,57,59,61,63,65,67,69,71,73,75,77,79,81,83,85,87"
    VhostuserSocketGroup: hugetlbfs
    OvsDpdkSocketMemory: "4096,4096"                            # 3
    OvsDpdkMemoryChannels: "4"

    OvsPmdCoreList: "2,46,3,47"                                 # 4
    NumDpdkInterfaceRxQueues: 1
1
KernelArgs:要计算 大页,请从总内存中减去 NovaReservedHostMemory 参数的值。
2
IsolCpusList:分配您想要使用此参数与主机进程隔离的一组 CPU 核心。将 OvsPmdCoreList 参数的值添加到 NovaComputeCpuDedicatedSet 参数的值,以计算 IsolCpusList 参数的值。
3
OvsDpdkSocketMemory:指定以 MB 为单位的内存大小,以预先从每个 NUMA 节点的巨页池中分配,使用 OvsDpdkSocketMemory 参数进行预先分配。有关计算 OVS-DPDK 参数的更多信息,请参阅: ovsdpdk 参数
4
OvsPmdCoreList:指定用于 DPDK 轮询模式驱动程序(PMD)的 CPU 核心。选择与 DPDK 接口本地 NUMA 节点关联的 CPU 内核。为每个 NUMA 节点分配 2 HT 同级线程,以计算 OvsPmdCoreList 参数的值。

9.7.4. nova 配置文件示例

parameter_defaults:
  ComputeHCIExtraConfig:
    nova::cpu_allocation_ratio: 16 # 2
    NovaReservedHugePages:                                         # 1
        - node:0,size:1GB,count:4
        - node:1,size:1GB,count:4
  NovaReservedHostMemory: 123904                                   # 2
  # All left over cpus from NUMA-1
  NovaComputeCpuDedicatedSet:                                                  # 3
  ['5','7','9','11','13','15','17','19','21','23','25','27','29','31','33','35','37','39','41','43','49','51','|
  53','55','57','59','61','63','65','67','69','71','73','75','77','79','81','83','85','87
1
NovaReservedHugePages:从带有 NovaReservedHugePages 参数的巨页池中分配内存(以 MB 为单位)。它与 OvsDpdkSocketMemory 参数的值总量相同。
2
NovaReservedHostMemory:将内存(以 MB 为单位)用于带有 NovaReservedHostMemory 参数的主机上的任务。使用以下指南计算您必须保留的内存量:
  • 每个 OSD 5 GB。
  • 每个虚拟机的 0.5 GB 开销.
  • 4GB 用于常规主机处理。确保您分配足够的内存,以防止通过跨 NUMA OSD 操作导致潜在的性能下降。
3
NovaComputeCpuDedicatedSet:使用 NovaComputeCpuDedicatedSet 参数列出 OvsPmdCoreListCeph_osd_cpus 中未找到的 CPU。CPU 必须与 DPDK NIC 位于同一个 NUMA 节点。

9.7.5. 建议配置 HCI-DPDK 部署

表 9.1. 用于 HCI 部署的可调参数

块设备类型OSD、内存、vCPU 每个设备

NVMe

内存:5GB per OSD
OSDs per device: 4
vCPUs per device: 3

SSD

内存:5GB per OSD
OSDs per device: 1
vCPUs per device: 4

HDD

内存:5GB per OSD
OSDs per device: 1
vCPUs per device: 1

对以下功能使用相同的 NUMA 节点:

  • 磁盘控制器
  • 存储网络
  • 存储 CPU 和内存

为 DPDK 提供商网络的以下功能分配另一个 NUMA 节点:

  • NIC
  • PMD CPU
  • 套接字内存

第 10 章 示例:使用 VXLAN 隧道配置 OVS-DPDK 和 SR-IOV

您可以使用 OVS-DPDK 和 SR-IOV 接口部署 Compute 节点。集群包括 ML2/OVS 和 VXLAN 隧道。

重要

在角色配置文件中,如 roles_data.yaml,在生成 overcloud 角色时注释掉或删除包含 OS::TripleO::Services::Tuned 的行。

ServicesDefault:
# - OS::TripleO::Services::Tuned

当您注释掉或删除 OS::TripleO::Services::Tuned 后,您可以设置 TunedProfileName 参数以符合您的要求,例如 "cpu-partitioning "。如果您没有注释掉或删除第 OS::TripleO::Services::Tuned 行,并且重新部署,则 TunedProfileName 参数获取 "throughput-performance" 的默认值,而不是您设置的任何其他值。

10.1. 配置角色数据

Red Hat OpenStack Platform 在 roles_data.yaml 文件中提供一组默认角色。您可以创建自己的 roles_data.yaml 文件来支持所需的角色。

在本例中,会创建 ComputeOvsDpdkSriov 角色。有关在 Red Hat OpenStack Platform 中创建角色的详情,请参考 高级 Overcloud 自定义。有关本例使用的特定角色的详情,请参阅 roles_data.yaml

10.2. 配置 OVS-DPDK 参数

重要

您必须确定 network-environment.yaml 文件中设置的 OVS-DPDK 参数的最佳值,以优化 OVS-DPDK 的 OpenStack 网络。详情请参阅使用 工作流 Deriving DPDK 参数

  1. 将 OVS-DPDK 的自定义资源添加到 resource_registry 下:

      resource_registry:
        # Specify the relative/absolute path to the config files you want to use for override the default.
        OS::TripleO::ComputeOvsDpdkSriov::Net::SoftwareConfig: nic-configs/computeovsdpdksriov.yaml
        OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml
  2. parameter_defaults 下,将隧道类型设置为 vxlan,并将网络类型设置为 vxlan,vlan

    NeutronTunnelTypes: 'vxlan'
    NeutronNetworkType: 'vxlan,vlan'
  3. parameters_defaults 下,设置网桥映射:

    # The OVS logical->physical bridge mappings to use.
    NeutronBridgeMappings:
      - dpdk-mgmt:br-link0
  4. parameter_defaults 下,为 ComputeOvsDpdkSriov 角色设置特定于角色的参数:

      ##########################
      # OVS DPDK configuration #
      ##########################
      ComputeOvsDpdkSriovParameters:
        KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=2-19,22-39"
        TunedProfileName: "cpu-partitioning"
        IsolCpusList: "2-19,22-39"
        NovaComputeCpuDedicatedSet: ['4-19,24-39']
        NovaReservedHostMemory: 4096
        OvsDpdkSocketMemory: "3072,1024"
        OvsDpdkMemoryChannels: "4"
        OvsPmdCoreList: "2,22,3,23"
        NovaComputeCpuSharedSet: [0,20,1,21]
        NovaLibvirtRxQueueSize: 1024
        NovaLibvirtTxQueueSize: 1024
    注意

    要防止创建客户机期间失败,请在每个 NUMA 节点上至少分配一个具有同级线程的 CPU。在示例中,OvsPmdCoreList 参数的值代表来自 NUMA 0 的核心 2 和 22,以及来自 NUMA 1 的核心 3 和 23。

    注意

    这些大页面由虚拟机消耗,以及使用 OvsDpdkSocketMemory 参数的 OVS-DPDK,如此流程所示。虚拟机的巨页数量是 引导参数 减去 OvsDpdkSocketMemory

    您还必须将 hw:mem_page_size=1GB 添加到与 DPDK 实例关联的类别中。

    注意

    OvsDpdkMemoryChannels 是此流程所需的设置。要进行最佳操作,请确保您使用适当的参数和值部署 DPDK。

  5. 为 SR-IOV 配置特定于角色的参数:

      NovaPCIPassthrough:
        - vendor_id: "8086"
          product_id: "1528"
          address: "0000:06:00.0"
          trusted: "true"
          physical_network: "sriov-1"
        - vendor_id: "8086"
          product_id: "1528"
          address: "0000:06:00.1"
          trusted: "true"
          physical_network: "sriov-2"

10.3. 配置控制器节点

  1. 为隔离的网络创建 control-plane Linux 绑定。

      - type: linux_bond
        name: bond_api
        bonding_options: "mode=active-backup"
        use_dhcp: false
        dns_servers:
          get_param: DnsServers
        members:
        - type: interface
          name: nic2
          primary: true
  2. 将 VLAN 分配给此 Linux 绑定。

      - type: vlan
        vlan_id:
          get_param: InternalApiNetworkVlanID
        device: bond_api
        addresses:
        - ip_netmask:
            get_param: InternalApiIpSubnet
    
      - type: vlan
        vlan_id:
          get_param: StorageNetworkVlanID
        device: bond_api
        addresses:
        - ip_netmask:
            get_param: StorageIpSubnet
    
      - type: vlan
        vlan_id:
          get_param: StorageMgmtNetworkVlanID
        device: bond_api
        addresses:
        - ip_netmask:
            get_param: StorageMgmtIpSubnet
    
      - type: vlan
        vlan_id:
          get_param: ExternalNetworkVlanID
        device: bond_api
        addresses:
        - ip_netmask:
            get_param: ExternalIpSubnet
        routes:
        - default: true
          next_hop:
            get_param: ExternalInterfaceDefaultRoute
  3. 创建 OVS 网桥,以访问 neutron-dhcp-agentneutron-metadata-agent 服务。

      - type: ovs_bridge
        name: br-link0
        use_dhcp: false
        mtu: 9000
        members:
        - type: interface
          name: nic3
          mtu: 9000
        - type: vlan
          vlan_id:
            get_param: TenantNetworkVlanID
          mtu: 9000
          addresses:
          - ip_netmask:
              get_param: TenantIpSubnet

10.4. 为 DPDK 和 SR-IOV 配置 Compute 节点

从默认的 compute.yaml 文件创建 computeovsdpdksriov.yaml 文件,并进行以下更改:

  1. 为隔离的网络创建 control-plane Linux 绑定。

      - type: linux_bond
        name: bond_api
        bonding_options: "mode=active-backup"
        use_dhcp: false
        dns_servers:
          get_param: DnsServers
        members:
        - type: interface
          name: nic3
          primary: true
        - type: interface
          name: nic4
  2. 将 VLAN 分配给此 Linux 绑定。

      - type: vlan
        vlan_id:
          get_param: InternalApiNetworkVlanID
        device: bond_api
        addresses:
        - ip_netmask:
            get_param: InternalApiIpSubnet
    
      - type: vlan
        vlan_id:
          get_param: StorageNetworkVlanID
        device: bond_api
        addresses:
        - ip_netmask:
            get_param: StorageIpSubnet
  3. 使用 DPDK 端口设置网桥以链接到控制器。

      - type: ovs_user_bridge
        name: br-link0
        use_dhcp: false
        ovs_extra:
          - str_replace:
              template: set port br-link0 tag=_VLAN_TAG_
              params:
                _VLAN_TAG_:
                   get_param: TenantNetworkVlanID
        addresses:
          - ip_netmask:
              get_param: TenantIpSubnet
        members:
          - type: ovs_dpdk_bond
            name: dpdkbond0
            mtu: 9000
            rx_queue: 2
            members:
              - type: ovs_dpdk_port
                name: dpdk0
                members:
                  - type: interface
                    name: nic7
              - type: ovs_dpdk_port
                name: dpdk1
                members:
                  - type: interface
                    name: nic8
    注意

    要包含多个 DPDK 设备,请为您要添加的每个 DPDK 设备重复 类型 代码部分。

    注意

    在使用 OVS-DPDK 时,同一 Compute 节点上的所有网桥都必须是 ovs_user_bridge 类型。红帽 OpenStack 平台不支持同一节点上的 ovs_bridgeovs_user_bridge

10.5. 部署 overcloud

  1. 运行 overcloud_deploy.sh 脚本:

第 11 章 升级带有 NFV 的 Red Hat OpenStack 平台

有关使用配置 OVS-DPDK 升级 Red Hat OpenStack Platform (RHOSP)的更多信息,请参阅 框架中的准备网络功能虚拟化(NFV) 升级(13 至 16.1) 指南。

第 12 章 NFV 性能

Red Hat OpenStack Platform director 配置 Compute 节点,以强制资源分区和微调,以实现客户机虚拟网络功能(VNF)的行率性能。NFV 用例中的主要性能因素是吞吐量、延迟和jitter。

您可以使用数据平面开发套件(DPDK)加速虚拟机在物理 NIC 和虚拟机之间启用高性能数据包切换。OVS 2.10 嵌入了 DPDK 17 的支持,并包括对 vhost-user 多队列的支持,从而实现可扩展的性能。OVS-DPDK 为客户机 VNF 提供分线性能。

单根 I/O 虚拟化(SR-IOV)网络提供了增强的性能,包括为特定网络和虚拟机改进吞吐量。

性能调优的其他重要功能包括大页面、NUMA 对齐、主机隔离和 CPU 固定。VNF 类别需要巨页和仿真程序线程隔离才能提高性能。主机隔离和 CPU 固定功能可提高 NFV 性能,并防止出现大量数据包丢失。

有关 CPU 和 NUMA 拓扑的高级简介,请参阅: NFV 性能注意事项 和配置 仿真器线程

第 13 章 查找更多信息

下表提供了其他 Red Hat 文档供参考:

Red Hat OpenStack Platform 文档套件可在以下文档中找到: Red Hat OpenStack Platform 文档套件

表 13.1. 可用文档列表

组件参考

Red Hat Enterprise Linux

Red Hat OpenStack Platform 支持 Red Hat Enterprise Linux 8.0。有关安装 Red Hat Enterprise Linux 的详情,请参考相应的安装指南: Red Hat Enterprise Linux 文档套件

Red Hat OpenStack Platform

要安装 OpenStack 组件及其依赖项,请使用 Red Hat OpenStack Platform director。director 使用基本的 OpenStack 安装作为 undercloud 来安装、配置和管理最终 overcloud 中的 OpenStack 节点。除了所部署的 overcloud 所需的环境外,还需要额外安装 undercloud 的主机计算机。具体步骤请查看 Red Hat OpenStack Platform Director 安装和使用

有关使用 Red Hat OpenStack Platform director (如网络隔离、存储配置、SSL 通信和常规配置方法)为 Red Hat OpenStack Platform 环境配置高级功能的详情,请参考 高级 Overcloud 自定义

NFV 文档

有关 NFV 概念的高级概述,请参阅 网络功能虚拟化产品指南

附录 A. DPDK SRIOV YAML 文件示例

本节提供了示例 yaml 文件,作为在同一计算节点上添加单一根 I/O 虚拟化(SR-IOV)和 Data Plane Development Kit (DPDK)接口的引用。

注意

这些模板来自一个完全配置的环境,并包含与 NFV 相关的参数,它们可能不适用于您的部署。有关组件支持级别列表,请参阅红帽知识库解决方案 组件支持评测。

A.1. VXLAN DPDK SRIOV YAML 文件示例

A.1.1. roles_data.yaml

  1. 运行 openstack overcloud roles generate 命令来生成 roles_data.yaml 文件。根据您要在您的环境中部署的角色在命令中包含角色名称,如 ControllerComputeSriovComputeOvsDpdkRTComputeOvsDpdkSriov 或其他角色。例如,要生成包含 ControllerComputeHCIOvsDpdkSriov 角色的 roles_data.yaml 文件,请运行以下命令:
 $ openstack overcloud roles generate -o roles_data.yaml Controller ComputeHCIOvsDpdkSriov
###############################################################################
# File generated by TripleO
###############################################################################
###############################################################################
# Role: Controller                                                            #
###############################################################################
- name: Controller
  description: |
    Controller role that has all the controler services loaded and handles
    Database, Messaging and Network functions.
  CountDefault: 1
  tags:
    - primary
    - controller
  networks:
    External:
      subnet: external_subnet
    InternalApi:
      subnet: internal_api_subnet
    Storage:
      subnet: storage_subnet
    StorageMgmt:
      subnet: storage_mgmt_subnet
    Tenant:
      subnet: tenant_subnet
  # For systems with both IPv4 and IPv6, you may specify a gateway network for
  # each, such as ['ControlPlane', 'External']
  default_route_networks: ['External']
  HostnameFormatDefault: '%stackname%-controller-%index%'
  # Deprecated & backward-compatible values (FIXME: Make parameters consistent)
  # Set uses_deprecated_params to True if any deprecated params are used.
  uses_deprecated_params: True
  deprecated_param_extraconfig: 'controllerExtraConfig'
  deprecated_param_flavor: 'OvercloudControlFlavor'
  deprecated_param_image: 'controllerImage'
  deprecated_nic_config_name: 'controller.yaml'
  update_serial: 1
  ServicesDefault:
    - OS::TripleO::Services::Aide
    - OS::TripleO::Services::AodhApi
    - OS::TripleO::Services::AodhEvaluator
    - OS::TripleO::Services::AodhListener
    - OS::TripleO::Services::AodhNotifier
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::BarbicanApi
    - OS::TripleO::Services::BarbicanBackendSimpleCrypto
    - OS::TripleO::Services::BarbicanBackendDogtag
    - OS::TripleO::Services::BarbicanBackendKmip
    - OS::TripleO::Services::BarbicanBackendPkcs11Crypto
    - OS::TripleO::Services::BootParams
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CeilometerAgentCentral
    - OS::TripleO::Services::CeilometerAgentNotification
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CephGrafana
    - OS::TripleO::Services::CephMds
    - OS::TripleO::Services::CephMgr
    - OS::TripleO::Services::CephMon
    - OS::TripleO::Services::CephRbdMirror
    - OS::TripleO::Services::CephRgw
    - OS::TripleO::Services::CertmongerUser
    - OS::TripleO::Services::CinderApi
    - OS::TripleO::Services::CinderBackendDellPs
    - OS::TripleO::Services::CinderBackendDellSc
    - OS::TripleO::Services::CinderBackendDellEMCPowermax
    - OS::TripleO::Services::CinderBackendDellEMCPowerStore
    - OS::TripleO::Services::CinderBackendDellEMCSc
    - OS::TripleO::Services::CinderBackendDellEMCUnity
    - OS::TripleO::Services::CinderBackendDellEMCVMAXISCSI
    - OS::TripleO::Services::CinderBackendDellEMCVNX
    - OS::TripleO::Services::CinderBackendDellEMCVxFlexOS
    - OS::TripleO::Services::CinderBackendDellEMCXtremio
    - OS::TripleO::Services::CinderBackendDellEMCXTREMIOISCSI
    - OS::TripleO::Services::CinderBackendNetApp
    - OS::TripleO::Services::CinderBackendPure
    - OS::TripleO::Services::CinderBackendScaleIO
    - OS::TripleO::Services::CinderBackendVRTSHyperScale
    - OS::TripleO::Services::CinderBackendNVMeOF
    - OS::TripleO::Services::CinderBackup
    - OS::TripleO::Services::CinderHPELeftHandISCSI
    - OS::TripleO::Services::CinderScheduler
    - OS::TripleO::Services::CinderVolume
    - OS::TripleO::Services::Clustercheck
    - OS::TripleO::Services::Collectd
    - OS::TripleO::Services::ContainerImagePrepare
    - OS::TripleO::Services::DesignateApi
    - OS::TripleO::Services::DesignateCentral
    - OS::TripleO::Services::DesignateProducer
    - OS::TripleO::Services::DesignateWorker
    - OS::TripleO::Services::DesignateMDNS
    - OS::TripleO::Services::DesignateSink
    - OS::TripleO::Services::Docker
    - OS::TripleO::Services::Ec2Api
    - OS::TripleO::Services::Etcd
    - OS::TripleO::Services::ExternalSwiftProxy
    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GnocchiApi
    - OS::TripleO::Services::GnocchiMetricd
    - OS::TripleO::Services::GnocchiStatsd
    - OS::TripleO::Services::HAproxy
    - OS::TripleO::Services::HeatApi
    - OS::TripleO::Services::HeatApiCloudwatch
    - OS::TripleO::Services::HeatApiCfn
    - OS::TripleO::Services::HeatEngine
    - OS::TripleO::Services::Horizon
    - OS::TripleO::Services::IpaClient
    - OS::TripleO::Services::Ipsec
    - OS::TripleO::Services::IronicApi
    - OS::TripleO::Services::IronicConductor
    - OS::TripleO::Services::IronicInspector
    - OS::TripleO::Services::IronicPxe
    - OS::TripleO::Services::IronicNeutronAgent
    - OS::TripleO::Services::Iscsid
    - OS::TripleO::Services::Keepalived
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Keystone
    - OS::TripleO::Services::LoginDefs
    - OS::TripleO::Services::ManilaApi
    - OS::TripleO::Services::ManilaBackendCephFs
    - OS::TripleO::Services::ManilaBackendIsilon
    - OS::TripleO::Services::ManilaBackendNetapp
    - OS::TripleO::Services::ManilaBackendUnity
    - OS::TripleO::Services::ManilaBackendVNX
    - OS::TripleO::Services::ManilaBackendVMAX
    - OS::TripleO::Services::ManilaScheduler
    - OS::TripleO::Services::ManilaShare
    - OS::TripleO::Services::Memcached
    - OS::TripleO::Services::MetricsQdr
    - OS::TripleO::Services::MistralApi
    - OS::TripleO::Services::MistralEngine
    - OS::TripleO::Services::MistralExecutor
    - OS::TripleO::Services::MistralEventEngine
    - OS::TripleO::Services::Multipathd
    - OS::TripleO::Services::MySQL
    - OS::TripleO::Services::MySQLClient
    - OS::TripleO::Services::NeutronApi
    - OS::TripleO::Services::NeutronBgpVpnApi
    - OS::TripleO::Services::NeutronSfcApi
    - OS::TripleO::Services::NeutronCorePlugin
    - OS::TripleO::Services::NeutronDhcpAgent
    - OS::TripleO::Services::NeutronL2gwAgent
    - OS::TripleO::Services::NeutronL2gwApi
    - OS::TripleO::Services::NeutronL3Agent
    - OS::TripleO::Services::NeutronLinuxbridgeAgent
    - OS::TripleO::Services::NeutronMetadataAgent
    - OS::TripleO::Services::NeutronML2FujitsuCfab
    - OS::TripleO::Services::NeutronML2FujitsuFossw
    - OS::TripleO::Services::NeutronOvsAgent
    - OS::TripleO::Services::NeutronVppAgent
    - OS::TripleO::Services::NeutronAgentsIBConfig
    - OS::TripleO::Services::NovaApi
    - OS::TripleO::Services::NovaConductor
    - OS::TripleO::Services::NovaIronic
    - OS::TripleO::Services::NovaMetadata
    - OS::TripleO::Services::NovaScheduler
    - OS::TripleO::Services::NovaVncProxy
    - OS::TripleO::Services::ContainersLogrotateCrond
    - OS::TripleO::Services::OctaviaApi
    - OS::TripleO::Services::OctaviaDeploymentConfig
    - OS::TripleO::Services::OctaviaHealthManager
    - OS::TripleO::Services::OctaviaHousekeeping
    - OS::TripleO::Services::OctaviaWorker
    - OS::TripleO::Services::OpenStackClients
    - OS::TripleO::Services::OVNDBs
    - OS::TripleO::Services::OVNController
    - OS::TripleO::Services::Pacemaker
    - OS::TripleO::Services::PankoApi
    - OS::TripleO::Services::PlacementApi
    - OS::TripleO::Services::OsloMessagingRpc
    - OS::TripleO::Services::OsloMessagingNotify
    - OS::TripleO::Services::Podman
    - OS::TripleO::Services::Rear
    - OS::TripleO::Services::Redis
    - OS::TripleO::Services::Rhsm
    - OS::TripleO::Services::Rsyslog
    - OS::TripleO::Services::RsyslogSidecar
    - OS::TripleO::Services::SaharaApi
    - OS::TripleO::Services::SaharaEngine
    - OS::TripleO::Services::Securetty
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::SwiftProxy
    - OS::TripleO::Services::SwiftDispersion
    - OS::TripleO::Services::SwiftRingBuilder
    - OS::TripleO::Services::SwiftStorage
    - OS::TripleO::Services::Timesync
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::Tuned
    - OS::TripleO::Services::Vpp
    - OS::TripleO::Services::Zaqar
###############################################################################
# Role: ComputeHCIOvsDpdkSriov                                                #
###############################################################################
- name: ComputeHCIOvsDpdkSriov
  description: |
    ComputeOvsDpdkSriov Node role hosting Ceph OSD too
  networks:
    InternalApi:
      subnet: internal_api_subnet
    Tenant:
      subnet: tenant_subnet
    Storage:
      subnet: storage_subnet
    StorageMgmt:
      subnet: storage_mgmt_subnet
  # CephOSD present so serial has to be 1
  update_serial: 1
  RoleParametersDefault:
    TunedProfileName: "cpu-partitioning"
    VhostuserSocketGroup: "hugetlbfs"
    NovaLibvirtRxQueueSize: 1024
    NovaLibvirtTxQueueSize: 1024
  ServicesDefault:
    - OS::TripleO::Services::Aide
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::BootParams
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CephOSD
    - OS::TripleO::Services::CertmongerUser
    - OS::TripleO::Services::Collectd
    - OS::TripleO::Services::ComputeCeilometerAgent
    - OS::TripleO::Services::ComputeNeutronCorePlugin
    - OS::TripleO::Services::ComputeNeutronL3Agent
    - OS::TripleO::Services::ComputeNeutronMetadataAgent
    - OS::TripleO::Services::ComputeNeutronOvsDpdk
    - OS::TripleO::Services::Docker
    - OS::TripleO::Services::IpaClient
    - OS::TripleO::Services::Ipsec
    - OS::TripleO::Services::Iscsid
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::LoginDefs
    - OS::TripleO::Services::MetricsQdr
    - OS::TripleO::Services::Multipathd
    - OS::TripleO::Services::MySQLClient
    - OS::TripleO::Services::NeutronBgpVpnBagpipe
    - OS::TripleO::Services::NeutronSriovAgent
    - OS::TripleO::Services::NeutronSriovHostConfig
    - OS::TripleO::Services::NovaAZConfig
    - OS::TripleO::Services::NovaCompute
    - OS::TripleO::Services::NovaLibvirt
    - OS::TripleO::Services::NovaLibvirtGuests
    - OS::TripleO::Services::NovaMigrationTarget
    - OS::TripleO::Services::OvsDpdkNetcontrold
    - OS::TripleO::Services::ContainersLogrotateCrond
    - OS::TripleO::Services::Podman
    - OS::TripleO::Services::Rear
    - OS::TripleO::Services::Rhsm
    - OS::TripleO::Services::Rsyslog
    - OS::TripleO::Services::RsyslogSidecar
    - OS::TripleO::Services::Securetty
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Timesync
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::OVNController
    - OS::TripleO::Services::OVNMetadataAgent
    - OS::TripleO::Services::Ptp

A.1.2. network-environment-overrides.yaml

resource_registry:
  # Specify the relative/absolute path to the config files you want to use for override the default.
  OS::TripleO::ComputeOvsDpdkSriov::Net::SoftwareConfig: nic-configs/computeovsdpdksriov.yaml
  OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml

# Customize all these values to match the local environment
parameter_defaults:
  # The tunnel type for the project network (vxlan or gre). Set to '' to disable tunneling.
  NeutronTunnelTypes: 'vxlan'
  # The project network type for Neutron (vlan or vxlan).
  NeutronNetworkType: 'vxlan,vlan'
  # The OVS logical->physical bridge mappings to use.
  NeutronBridgeMappings: 'access:br-access,dpdk-mgmt:br-link0'
  # The Neutron ML2 and OpenVSwitch vlan mapping range to support.
  NeutronNetworkVLANRanges: 'access:423:423,dpdk-mgmt:134:137,sriov-1:138:139,sriov-2:138:139'
  # Define the DNS servers (maximum 2) for the overcloud nodes
  DnsServers: ["10.46.0.31","10.46.0.32"]
  # Nova flavor to use.
  OvercloudControllerFlavor: controller
  OvercloudComputeOvsDpdkSriovFlavor: computeovsdpdksriov
  # Number of nodes to deploy.
  ControllerCount: 3
  ComputeOvsDpdkSriovCount: 2
  # NTP server configuration.
  NtpServer: ['clock.redhat.com']
  # MTU global configuration
  NeutronGlobalPhysnetMtu: 9000
  # Configure the classname of the firewall driver to use for implementing security groups.
  NeutronOVSFirewallDriver: openvswitch
  SshServerOptions:
    UseDns: 'no'
  # Enable log level DEBUG for supported components
  Debug: True

  ControllerHostnameFormat: 'controller-%index%'
  ControllerSchedulerHints:
    'capabilities:node': 'controller-%index%'
  ComputeOvsDpdkSriovHostnameFormat: 'computeovsdpdksriov-%index%'
  ComputeOvsDpdkSriovSchedulerHints:
    'capabilities:node': 'computeovsdpdksriov-%index%'

  # From Rocky live migration with NumaTopologyFilter disabled by default
  # https://bugs.launchpad.net/nova/+bug/1289064
  NovaEnableNUMALiveMigration: true

  ##########################
  # OVS DPDK configuration #
  ##########################

  # In the future, most parameters will be derived by mistral plan.
  # Currently mistral derive parameters is blocked:
  # https://bugzilla.redhat.com/show_bug.cgi?id=1777841
  # https://bugzilla.redhat.com/show_bug.cgi?id=1777844
  ComputeOvsDpdkSriovParameters:
    KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=64 iommu=pt intel_iommu=on isolcpus=2-19,22-39"
    TunedProfileName: "cpu-partitioning"
    IsolCpusList: "2-19,22-39"
    NovaComputeCpuDedicatedSet: ['2-10,12-17,19,22-30,32-37,39']
    NovaReservedHostMemory: 4096
    OvsDpdkSocketMemory: "1024,3072"
    OvsDpdkMemoryChannels: "4"
    OvsPmdCoreList: "11,18,31,38"
    NovaComputeCpuSharedSet: [0,20,1,21]
    # When using NIC partioning on SR-IOV enabled setups, 'derive_pci_passthrough_whitelist.py'
    # script will be executed which will override NovaPCIPassthrough.
    # No option to disable as of now - https://bugzilla.redhat.com/show_bug.cgi?id=1774403
    NovaPCIPassthrough:
      - address: "0000:19:0e.3"
        trusted: "true"
        physical_network: "sriov1"
      - address: "0000:19:0e.0"
        trusted: "true"
        physical_network: "sriov-2"
    # NUMA aware vswitch
    NeutronPhysnetNUMANodesMapping: {dpdk-mgmt: [0]}
    NeutronTunnelNUMANodes: [0]
    NeutronPhysicalDevMappings:
    - sriov1:enp6s0f2
    - sriov2:enp6s0f3

  ############################
  #  Scheduler configuration #
  ############################
  NovaSchedulerDefaultFilters:
    - "AvailabilityZoneFilter"
    - "ComputeFilter"
    - "ComputeCapabilitiesFilter"
    - "ImagePropertiesFilter"
    - "ServerGroupAntiAffinityFilter"
    - "ServerGroupAffinityFilter"
    - "PciPassthroughFilter"
    - "NUMATopologyFilter"
    - "AggregateInstanceExtraSpecsFilter"

A.1.3. controller.yaml

heat_template_version: rocky
description: >
  Software Config to drive os-net-config to configure VLANs for the controller role.
parameters:
  ControlPlaneIp:
    default: ''
    description: IP address/subnet on the ctlplane network
    type: string
  ExternalIpSubnet:
    default: ''
    description: IP address/subnet on the external network
    type: string
  ExternalInterfaceRoutes:
    default: []
    description: >
      Routes for the external network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
      the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
    type: json
  InternalApiIpSubnet:
    default: ''
    description: IP address/subnet on the internal_api network
    type: string
  InternalApiInterfaceRoutes:
    default: []
    description: >
      Routes for the internal_api network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
      the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
    type: json
  StorageIpSubnet:
    default: ''
    description: IP address/subnet on the storage network
    type: string
  StorageInterfaceRoutes:
    default: []
    description: >
      Routes for the storage network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
      the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
    type: json
  StorageMgmtIpSubnet:
    default: ''
    description: IP address/subnet on the storage_mgmt network
    type: string
  StorageMgmtInterfaceRoutes:
    default: []
    description: >
      Routes for the storage_mgmt network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
      the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
    type: json
  TenantIpSubnet:
    default: ''
    description: IP address/subnet on the tenant network
    type: string
  TenantInterfaceRoutes:
    default: []
    description: >
      Routes for the tenant network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
      the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
    type: json
  ManagementIpSubnet: # Only populated when including environments/network-management.yaml
    default: ''
    description: IP address/subnet on the management network
    type: string
  ManagementInterfaceRoutes:
    default: []
    description: >
      Routes for the management network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
      the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
    type: json
  BondInterfaceOvsOptions:
    default: bond_mode=active-backup
    description: >-
      The ovs_options string for the bond interface. Set things like lacp=active and/or bond_mode=balance-slb using this option.
    type: string
  ExternalNetworkVlanID:
    default: 10
    description: Vlan ID for the external network traffic.
    type: number
  InternalApiNetworkVlanID:
    default: 20
    description: Vlan ID for the internal_api network traffic.
    type: number
  StorageNetworkVlanID:
    default: 30
    description: Vlan ID for the storage network traffic.
    type: number
  StorageMgmtNetworkVlanID:
    default: 40
    description: Vlan ID for the storage_mgmt network traffic.
    type: number
  TenantNetworkVlanID:
    default: 50
    description: Vlan ID for the tenant network traffic.
    type: number
  ManagementNetworkVlanID:
    default: 60
    description: Vlan ID for the management network traffic.
    type: number
  ExternalInterfaceDefaultRoute:
    default: 10.0.0.1
    description: default route for the external network
    type: string
  ControlPlaneSubnetCidr:
    default: ''
    description: >
      The subnet CIDR of the control plane network. (The parameter is automatically resolved from the ctlplane subnet's cidr
      attribute.)
    type: string
  ControlPlaneDefaultRoute:
    default: ''
    description: >-
      The default route of the control plane network. (The parameter is automatically resolved from the ctlplane subnet's
      gateway_ip attribute.)
    type: string
  DnsServers: # Override this via parameter_defaults
    default: []
    description: >
      DNS servers to use for the Overcloud (2 max for some implementations). If not set the nameservers configured in the
      ctlplane subnet's dns_nameservers attribute will be used.
    type: comma_delimited_list
  EC2MetadataIp:
    default: ''
    description: >-
      The IP address of the EC2 metadata server. (The parameter is automatically resolved from the ctlplane subnet's host_routes
      attribute.)
    type: string
  ControlPlaneStaticRoutes:
    default: []
    description: >
      Routes for the ctlplane network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
      the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
    type: json
  ControlPlaneMtu:
    default: 1500
    description: >-
      The maximum transmission unit (MTU) size(in bytes) that is guaranteed to pass through the data path of the segments
      in the network. (The parameter is automatically resolved from the ctlplane network's mtu attribute.)
    type: number
  StorageMtu:
    default: 1500
    description: >-
      The maximum transmission unit (MTU) size(in bytes) that is guaranteed to pass through the data path of the segments
      in the Storage network.
    type: number
  StorageMgmtMtu:
    default: 1500
    description: >-
      The maximum transmission unit (MTU) size(in bytes) that is guaranteed to pass through the data path of the segments
      in the StorageMgmt network.
    type: number
  InternalApiMtu:
    default: 1500
    description: >-
      The maximum transmission unit (MTU) size(in bytes) that is guaranteed to pass through the data path of the segments
      in the InternalApi network.
    type: number
  TenantMtu:
    default: 1500
    description: >-
      The maximum transmission unit (MTU) size(in bytes) that is guaranteed to pass through the data path of the segments
      in the Tenant network.
    type: number
  ExternalMtu:
    default: 1500
    description: >-
      The maximum transmission unit (MTU) size(in bytes) that is guaranteed to pass through the data path of the segments
      in the External network.
    type: number
resources:
  OsNetConfigImpl:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template:
            get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
          params:
            $network_config:
              network_config:
              - type: interface
                name: nic1
                use_dhcp: false
                addresses:
                - ip_netmask:
                    list_join:
                    - /
                    - - get_param: ControlPlaneIp
                      - get_param: ControlPlaneSubnetCidr
                routes:
                - ip_netmask: 169.254.169.254/32
                  next_hop:
                    get_param: EC2MetadataIp

              - type: ovs_bridge
                name: br-link0
                use_dhcp: false
                mtu: 9000
                members:
                - type: interface
                  name: nic2
                  mtu: 9000

                - type: vlan
                  vlan_id:
                    get_param: TenantNetworkVlanID
                  mtu: 9000
                  addresses:
                  - ip_netmask:
                      get_param: TenantIpSubnet

                - type: vlan
                  vlan_id:
                    get_param: InternalApiNetworkVlanID
                  addresses:
                  - ip_netmask:
                      get_param: InternalApiIpSubnet

                - type: vlan
                  vlan_id:
                    get_param: StorageNetworkVlanID
                  addresses:
                  - ip_netmask:
                      get_param: StorageIpSubnet

                - type: vlan
                  vlan_id:
                    get_param: StorageMgmtNetworkVlanID
                  addresses:
                  - ip_netmask:
                      get_param: StorageMgmtIpSubnet

              - type: ovs_bridge
                name: br-access
                use_dhcp: false
                mtu: 9000
                members:
                - type: interface
                  name: nic3
                  mtu: 9000
                - type: vlan
                  vlan_id:
                    get_param: ExternalNetworkVlanID
                  mtu: 9000
                  addresses:
                  - ip_netmask:
                      get_param: ExternalIpSubnet
                  routes:
                  - default: true
                    next_hop:
                      get_param: ExternalInterfaceDefaultRoute
outputs:
  OS::stack_id:
    description: The OsNetConfigImpl resource.
    value:
      get_resource: OsNetConfigImpl

A.1.4. compute-ovs-dpdk.yaml

heat_template_version: rocky

description: >
  Software Config to drive os-net-config to configure VLANs for the
  compute role.

parameters:
  ControlPlaneIp:
    default: ''
    description: IP address/subnet on the ctlplane network
    type: string
  ExternalIpSubnet:
    default: ''
    description: IP address/subnet on the external network
    type: string
  ExternalInterfaceRoutes:
    default: []
    description: >
      Routes for the external network traffic.
      JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
      Unless the default is changed, the parameter is automatically resolved
      from the subnet host_routes attribute.
    type: json
  InternalApiIpSubnet:
    default: ''
    description: IP address/subnet on the internal_api network
    type: string
  InternalApiInterfaceRoutes:
    default: []
    description: >
      Routes for the internal_api network traffic.
      JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
      Unless the default is changed, the parameter is automatically resolved
      from the subnet host_routes attribute.
    type: json
  StorageIpSubnet:
    default: ''
    description: IP address/subnet on the storage network
    type: string
  StorageInterfaceRoutes:
    default: []
    description: >
      Routes for the storage network traffic.
      JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
      Unless the default is changed, the parameter is automatically resolved
      from the subnet host_routes attribute.
    type: json
  StorageMgmtIpSubnet:
    default: ''
    description: IP address/subnet on the storage_mgmt network
    type: string
  StorageMgmtInterfaceRoutes:
    default: []
    description: >
      Routes for the storage_mgmt network traffic.
      JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
      Unless the default is changed, the parameter is automatically resolved
      from the subnet host_routes attribute.
    type: json
  TenantIpSubnet:
    default: ''
    description: IP address/subnet on the tenant network
    type: string
  TenantInterfaceRoutes:
    default: []
    description: >
      Routes for the tenant network traffic.
      JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
      Unless the default is changed, the parameter is automatically resolved
      from the subnet host_routes attribute.
    type: json
  ManagementIpSubnet: # Only populated when including environments/network-management.yaml
    default: ''
    description: IP address/subnet on the management network
    type: string
  ManagementInterfaceRoutes:
    default: []
    description: >
      Routes for the management network traffic.
      JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}]
      Unless the default is changed, the parameter is automatically resolved
      from the subnet host_routes attribute.
    type: json
  BondInterfaceOvsOptions:
    default: 'bond_mode=active-backup'
    description: The ovs_options string for the bond interface. Set things like
                 lacp=active and/or bond_mode=balance-slb using this option.
    type: string
  ExternalNetworkVlanID:
    default: 10
    description: Vlan ID for the external network traffic.
    type: number
  InternalApiNetworkVlanID:
    default: 20
    description: Vlan ID for the internal_api network traffic.
    type: number
  StorageNetworkVlanID:
    default: 30
    description: Vlan ID for the storage network traffic.
    type: number
  StorageMgmtNetworkVlanID:
    default: 40
    description: Vlan ID for the storage_mgmt network traffic.
    type: number
  TenantNetworkVlanID:
    default: 50
    description: Vlan ID for the tenant network traffic.
    type: number
  ManagementNetworkVlanID:
    default: 60
    description: Vlan ID for the management network traffic.
    type: number
  ExternalInterfaceDefaultRoute:
    default: '10.0.0.1'
    description: default route for the external network
    type: string
  ControlPlaneSubnetCidr:
    default: ''
    description: >
      The subnet CIDR of the control plane network. (The parameter is
      automatically resolved from the ctlplane subnet's cidr attribute.)
    type: string
  ControlPlaneDefaultRoute:
    default: ''
    description: The default route of the control plane network. (The parameter
      is automatically resolved from the ctlplane subnet's gateway_ip attribute.)
    type: string
  DnsServers: # Override this via parameter_defaults
    default: []
    description: >
      DNS servers to use for the Overcloud (2 max for some implementations).
      If not set the nameservers configured in the ctlplane subnet's
      dns_nameservers attribute will be used.
    type: comma_delimited_list
  EC2MetadataIp:
    default: ''
    description: The IP address of the EC2 metadata server. (The parameter
      is automatically resolved from the ctlplane subnet's host_routes attribute.)
    type: string
  ControlPlaneStaticRoutes:
    default: []
    description: >
      Routes for the ctlplane network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless
      the default is changed, the parameter is automatically resolved from the subnet host_routes attribute.
    type: json
  ControlPlaneMtu:
    default: 1500
    description: >-
      The maximum transmission unit (MTU) size(in bytes) that is guaranteed to pass through the data path of the segments
      in the network. (The parameter is automatically resolved from the ctlplane network's mtu attribute.)
    type: number
  StorageMtu:
    default: 1500
    description: >-
      The maximum transmission unit (MTU) size(in bytes) that is guaranteed to pass through the data path of the segments
      in the Storage network.
    type: number
  InternalApiMtu:
    default: 1500
    description: >-
      The maximum transmission unit (MTU) size(in bytes) that is guaranteed to pass through the data path of the segments
      in the InternalApi network.
    type: number
  TenantMtu:
    default: 1500
    description: >-
      The maximum transmission unit (MTU) size(in bytes) that is guaranteed to pass through the data path of the segments
      in the Tenant network.
    type: number

resources:
  OsNetConfigImpl:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template:
            get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
          params:
            $network_config:
              network_config:
              - type: interface
                name: nic1
                use_dhcp: false
                defroute: false

              - type: interface
                name: nic2
                use_dhcp: false
                addresses:
                - ip_netmask:
                    list_join:
                    - /
                    - - get_param: ControlPlaneIp
                      - get_param: ControlPlaneSubnetCidr
                routes:
                - ip_netmask: 169.254.169.254/32
                  next_hop:
                    get_param: EC2MetadataIp
                - default: true
                  next_hop:
                    get_param: ControlPlaneDefaultRoute

              - type: linux_bond
                name: bond_api
                bonding_options: mode=active-backup
                use_dhcp: false
                dns_servers:
                  get_param: DnsServers
                members:
                - type: interface
                  name: nic3
                  primary: true
                - type: interface
                  name: nic4

              - type: vlan
                vlan_id:
                  get_param: InternalApiNetworkVlanID
                device: bond_api
                addresses:
                - ip_netmask:
                    get_param: InternalApiIpSubnet

              - type: vlan
                vlan_id:
                  get_param: StorageNetworkVlanID
                device: bond_api
                addresses:
                - ip_netmask:
                    get_param: StorageIpSubnet

              - type: ovs_user_bridge
                name: br-link0
                use_dhcp: false
                ovs_extra:
                - str_replace:
                    template: set port br-link0 tag=_VLAN_TAG_
                    params:
                      _VLAN_TAG_:
                        get_param: TenantNetworkVlanID
                addresses:
                - ip_netmask:
                    get_param: TenantIpSubnet
                members:
                - type: ovs_dpdk_bond
                  name: dpdkbond0
                  mtu: 9000
                  rx_queue: 2
                  members:
                  - type: ovs_dpdk_port
                    name: dpdk0
                    members:
                    - type: interface
                      name: nic7
                  - type: ovs_dpdk_port
                    name: dpdk1
                    members:
                    - type: interface
                      name: nic8

              - type: sriov_pf
                name: nic9
                mtu: 9000
                numvfs: 10
                use_dhcp: false
                defroute: false
                nm_controlled: true
                hotplug: true
                promisc: false

              - type: sriov_pf
                name: nic10
                mtu: 9000
                numvfs: 10
                use_dhcp: false
                defroute: false
                nm_controlled: true
                hotplug: true
                promisc: false
outputs:
  OS::stack_id:
    description: The OsNetConfigImpl resource.
    value:
      get_resource: OsNetConfigImpl

A.1.5. overcloud_deploy.sh

#!/bin/bash

THT_PATH='/home/stack/ospd-16-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid'

openstack overcloud deploy \
--templates \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs-dpdk.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-sriov.yaml \
-e /home/stack/containers-prepare-parameter.yaml \
-r $THT_PATH/roles_data.yaml \
-e $THT_PATH/network-environment-overrides.yaml \
-n $THT_PATH/network-data.yaml

法律通告

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.