Menu Close

네트워크 기능 가상화 계획 및 구성 가이드

Red Hat OpenStack Platform 16.2

NFV(Network Functions Virtualization) OpenStack 배포 계획 및 구성

초록

이 가이드에는 중요한 계획 정보가 포함되어 있으며 Red Hat OpenStack Platform 배포의 NFVi(네트워크 기능 가상화 인프라)를 위한 단일 루트 입/출력 가상화(SR-IOV) 및 DPDK(Dataplane Development Kit)에 대한 구성 절차를 설명합니다.

preface

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견을 보내 주십시오. Red Hat이 어떻게 더 나은지 알려주십시오.

직접 문서 피드백(DDF) 기능 사용

피드백 추가 DDF 기능을 사용하여 특정 문장, 단락 또는 코드 블록에 대한 직접 의견을 제출할 수 있습니다.

  1. 다중 페이지 HTML 형식으로 문서를 봅니다.
  2. 문서의 오른쪽 상단에 피드백 버튼이 표시되는지 확인합니다.
  3. 주석 처리하려는 텍스트 부분을 강조 표시합니다.
  4. 피드백 추가를 클릭합니다.
  5. 코멘트를 사용하여 피드백 추가 필드를 완료합니다.
  6. 선택 사항: 문서 팀이 문제에 대한 자세한 설명을 위해 연락을 드릴 수 있도록 이메일 주소를 추가합니다.
  7. Submit(제출)을 클릭합니다.

1장. NFV 개요

NFV(Network Functions Virtualization)는 범용 클라우드 기반 인프라에서 네트워크 스위치와 같은 네트워크 기능을 가상화하는 소프트웨어 솔루션입니다. NFV를 통해 통신 서비스 공급자는 기존의 하드웨어 또는 독점형 하드웨어에서 벗어날 수 있습니다.

NFV 개념에 대한 개괄적인 개요는 네트워크 기능 가상화 제품 가이드 를 참조하십시오.

참고

OVS-DPDK 및 SR-IOV 구성은 하드웨어 및 토폴로지에 따라 다릅니다. 이 가이드에서는 토폴로지 및 사용 사례와 다를 수 있는 CPU 할당, 메모리 할당 및 NIC 구성에 대한 예를 제공합니다.

Red Hat OpenStack Platform director를 사용하여 특정 네트워크 유형(예: external, project, 내부 API 등)을 분리합니다. 단일 네트워크 인터페이스에 네트워크를 배포하거나 다중 호스트 네트워크 인터페이스를 통해 배포할 수 있습니다. Open vSwitch를 사용하면 단일 브리지에 여러 인터페이스를 할당하여 본딩을 만들 수 있습니다. 템플릿 파일을 사용하여 Red Hat OpenStack Platform 설치에서 네트워크 격리를 구성합니다. 템플릿 파일을 제공하지 않으면 서비스 네트워크가 provisioning 네트워크에 배포됩니다. 템플릿 구성 파일의 유형은 다음과 같습니다.

  • network-environment.yaml - 이 파일에는 오버클라우드 노드의 서브넷 및 IP 주소 범위와 같은 네트워크 세부 정보가 포함되어 있습니다. 이 파일에는 다양한 시나리오의 기본 매개 변수 값을 재정의하는 다양한 설정도 포함되어 있습니다.
  • 호스트 네트워크 템플릿(예: compute.yamlcontroller.yaml )은 Overcloud 노드의 네트워크 인터페이스 구성을 정의합니다. 네트워크 세부 정보 값은 network-environment.yaml 파일에서 제공합니다.

이러한 heat 템플릿 파일은 언더클라우드 노드의 /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 목록은 Red Hat Knowledgebase 솔루션 Network Adapter 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. 하드웨어 오프로드 문제 해결

RHOSP(Red Hat OpenStack Platform) 16.2 배포에서 OVS 하드웨어 오프로드가 switchdev가능 포트 및 Mellanox ConnectX5 NIC를 사용하여 VM의 흐름을 오프로드하지 않을 수 있습니다. 이 시나리오의 오프로드 흐름 문제를 해결하고 구성하려면 ESWITCH_IPV4_TTL_MODIFY_ENABLE Mellanox 펌웨어 매개 변수를 비활성화합니다. RHOSP 16.2의 OVS 하드웨어 오프로드에 대한 자세한 문제 해결 정보는 OpenStack Platform 16.2의 Mellanox NIC를 사용한 Red Hat Knowledgebase 솔루션 OVS 하드웨어 오프로드를 참조하십시오.

절차

  1. RHOSP 배포의 Compute 노드에 구성하려는 Mellanox NIC가 있습니다.
  2. mstflint 유틸리티를 사용하여 ESWITCH_IPV4_TTL_MODIFY_ENABLE Mellanox 펌웨어 매개 변수를 쿼리합니다.

    [root@compute-1 ~]# yum install -y mstflint
    [root@compute-1 ~]# mstconfig -d <PF PCI BDF> q ESWITCH_IPV4_TTL_MODIFY_ENABLE
  3. ESWITCH_IPV4_TTL_MODIFY_ENABLE 매개 변수가 활성화되어 1 로 설정된 경우 값을 0 으로 설정하여 비활성화합니다.

    [root@compute-1 ~]# mstconfig -d <PF PCI BDF> s ESWITCH_IPV4_TTL_MODIFY_ENABLE=0`
  4. 노드를 재부팅합니다.

2.3. NUMA 노드 토폴로지 검색

배포를 계획할 때 최적의 성능을 위해 Compute 노드의 NUMA 토폴로지를 이해하여 CPU 및 메모리 리소스를 분할해야 합니다. NUMA 정보를 확인하려면 다음 작업 중 하나를 수행합니다.

  • 하드웨어 인트로스펙션을 활성화하여 베어 메탈 노드에서 이 정보를 검색합니다.
  • 각 베어 메탈 노드에 로그인하여 정보를 수동으로 수집합니다.
참고

하드웨어 인트로스펙션을 통해 NUMA 정보를 검색하려면 먼저 언더클라우드를 설치하고 구성해야 합니다. 언더클라우드 구성에 대한 자세한 내용은 다음을 참조하십시오. Director 설치 및 사용 가이드.

하드웨어 인트로스펙션 세부 정보 검색

기본적으로 Bare Metal 서비스 하드웨어 검사 추가 기능이 활성화되므로 이 기능을 사용하여 오버클라우드 구성의 하드웨어 세부 정보를 검색할 수 있습니다. undercloud.conf 파일의 inspection_extras 매개변수에 관한 자세한 내용은 Configuring the 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.4. NFV BIOS 설정

다음 표에서는 NFV에 필요한 BIOS 설정을 설명합니다.

표 2.1. BIOS 설정

매개변수설정

C3 전원 상태

비활성화됨.

C6 전원 상태

비활성화됨.

MLC Streamer

활성화됨.

MLC Spatial Prefetcher

활성화됨.

DCU Data Prefetcher

활성화됨.

DCA

활성화됨.

CPU 전원 및 성능

성능.

메모리 RAS 및 성능 구성 → NUMA 최적화

활성화됨.

Turbo Boost

비활성화됨.

VT-d

VFIO 기능이 필요한 경우 Intel 카드로 활성화됩니다.

NUMA 메모리 인터리브

비활성화됨.

3장. 소프트웨어 요구 사항

이 섹션에서는 지원되는 구성 및 드라이버와 NFV에 필요한 서브스크립션 세부 정보에 대해 설명합니다.

3.1. 리포지토리 등록 및 활성화

Red Hat OpenStack Platform을 설치하려면 Red Hat 서브스크립션 관리자를 사용하여 Red Hat OpenStack Platform director를 등록하고 필요한 채널을 구독해야 합니다. 언더클라우드 등록 및 업데이트에 대한 자세한 내용은 시스템 등록을 참조하십시오.

절차

  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. Red Hat OpenStack Platform 16.2 인타이틀먼트를 연결하려면 다음 명령에 Pool ID 값을 포함합니다.

    [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.2-for-rhel-8-x86_64-rpms \
    --enable=rhel-8-for-x86_64-nfv-rpms \
    --enable=fast-datapath-for-rhel-8-x86_64-rpms
  6. 시스템을 업데이트하여 기본 시스템 패키지를 최신 상태로 유지합니다.

    [stack@director ~]$ sudo dnf update -y
    [stack@director ~]$ sudo reboot
참고

오버클라우드 노드를 등록하려면 Ansible 기반 등록을 참조하십시오.

3.2. NFV 배포에 지원되는 구성

RHOSP(Red Hat OpenStack Platform)는 director를 사용하여 다음과 같은 NFV 배포를 지원합니다.

  • SR-IOV(단일 루트 I/O 가상화)
  • 데이터 플레인 개발 키트(OVS-DPDK)를 사용하여 Open vSwitch

또한 다음 기능을 사용하여 RHOSP를 배포할 수 있습니다.

3.2.1. OVS 메커니즘 드라이버를 사용하여 RHOSP 배포

OVS 메커니즘 드라이버를 사용하여 RHOSP를 배포합니다.

절차

  1. neutron_driver 매개변수가 null 로 설정되도록 containers-prepare-parameter.yaml 파일을 수정합니다.

    parameter_defaults:
      ContainerImagePrepare:
      - push_destination: true
        set:
         neutron_driver: null
         ...
  2. 배포 스크립트를 사용하여 /usr/share/openstack-tripleo-heat-templates/environments/services 디렉터리에 neutron- ovs.yaml 환경 파일을 추가합니다.

    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 배포

OVN과 동일한 노드에 DPDK 및 SRIOV VM을 배포합니다.

절차

  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 섹션에서 tunnel type 매개 변수 값을 cal ve로 편집합니다.

    NeutronTunnelTypes: 'geneve'
    NeutronNetworkType: ['geneve', 'vlan']
  5. 선택 사항: 중앙 집중식 라우팅 모델을 사용하는 경우 VR(Distributed Virtual Routing)을 비활성화합니다.

    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
참고

OVN(Open Virtual Networking)은 Red Hat OpenStack Platform 16.2의 기본 네트워킹 메커니즘 드라이버입니다. DVR(분산 가상 라우팅)로 OVN을 사용하려면 openstack overcloud deploy 명령에 environments/services/neutron-ovn-dvr-ha.yaml 파일을 포함해야 합니다. DVR 없이 OVN을 사용하려면 openstack overcloud deploy 명령에 environments/services/neutron-ovn-ha.yaml 파일을 포함하고 NeutronEnableDVR 매개변수를 false 로 설정해야 합니다. SR-IOV와 함께 OVN을 사용하려면 openstack overcloud deploy 명령에 environments/services/neutron-ovn-sriov.yaml 파일을 마지막 OVN 환경 파일로 포함해야 합니다.

3.2.3. OVS TC Flower 오프로드를 사용하여 OVN 배포

OVN과 동일한 노드에 OVS TC Flower 오프로드를 배포합니다.

절차

  1. ComputeOvsDpdkSriov 역할을 생성합니다.

    openstack overcloud roles generate -o roles_data.yaml ControllerSriov ComputeSriov
  2. 배포와 관련된 physical_network 매개 변수 설정을 구성합니다.

    • VLAN의 경우 배포 후 neutron에서 생성한 네트워크의 이름으로 physical_network 매개 변수를 설정합니다. NeutronBridgeMappings 매개변수에도 이 값을 사용합니다.
    • ComputeSriovOffloadParameters와 같은 역할별 매개 변수에서 Ovs HwOffload 매개 변수의 값이 true 인지 확인합니다.

      parameter_defaults:
        NeutronBridgeMappings: 'datacentre:br-ex,tenant:br-offload'
        NeutronNetworkVLANRanges: 'tenant:502:505'
        NeutronFlatNetworks: 'datacentre,tenant'
        NeutronPhysicalDevMappings:
          - tenant:ens1f0
          - tenant:ens1f1
      
        NovaPCIPassthrough:
        - devname: "ens1f0"
          physical_network: "tenant"
        - devname: "ens1f1"
          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. 지원되는 드라이버

지원되는 드라이버의 전체 목록은 Component, Plug-In 및 Driver Support in 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장. 네트워크 고려 사항

언더클라우드 호스트에는 최소한 다음 네트워크가 필요합니다.

  • 프로비저닝 네트워크 - 오버클라우드에서 사용할 베어 메탈 시스템을 검색하는 데 도움이 되는 DHCP 및 PXE 부팅 기능을 제공합니다.
  • 외부 네트워크 - 모든 노드에 대한 원격 연결을 위한 별도의 네트워크입니다. 이 네트워크에 연결된 인터페이스에는 정적으로 정의되거나 외부 DHCP 서비스에서 동적으로 생성된 라우팅 가능한 IP 주소가 필요합니다.

최소 오버클라우드 네트워크 설정에는 다음과 같은 NIC 구성이 포함됩니다.

  • 단일 NIC 구성 - 기본 VLAN과 다른 오버클라우드 네트워크 유형에 서브넷을 사용하는 태그된 VLAN에서 프로비저닝 네트워크용 NIC 1개
  • 듀얼 NIC 구성 - 프로비저닝 네트워크용 NIC 1개와 외부 네트워크용 다른 NIC 1개
  • 듀얼 NIC 구성 - 기본 VLAN에서 provisioning 네트워크용 NIC 1개, 다른 오버클라우드 네트워크 유형에 서브넷을 사용하는 태그가 지정된 VLAN의 NIC 1개입니다.
  • 다중 NIC 구성 - 각 NIC에서 다른 오버클라우드 네트워크 유형에 서브넷 사용

네트워킹 요구 사항에 대한 자세한 내용은 네트워킹 요구 사항을 참조하십시오.

5장. SR-IOV 배포 계획

컴퓨팅 노드 하드웨어에 따라 개별 매개변수를 설정하여 NFV에 대한 단일 루트 I/O 가상화(SR-IOV) 배포를 최적화합니다.

SR-IOV 매개변수에 미치는 하드웨어 영향을 평가 하려면 NUMA 노드 토폴로지 검색을 참조하십시오.

5.1. SR-IOV 배포를 위한 하드웨어 파티셔닝

SR-IOV를 사용하여 고성능을 달성하려면 호스트와 게스트 간에 리소스를 분할합니다.

OpenStack NFV Hardware Capacities 464931 0118 SR IOV

일반적인 토폴로지에는 듀얼 소켓 컴퓨팅 노드의 NUMA 노드당 14개의 코어가 포함됩니다. HTC(하이퍼 스레딩) 및 비 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 수정을 정의하는 tuned 프로필에 따라 달라집니다.

5.2. NFV SR-IOV 배포 토폴로지

다음 이미지에는 각각 mgt 로 표시된 관리 인터페이스와 데이터 플레인 인터페이스가 있는 두 개의 VNF가 있습니다. 관리 인터페이스는 ssh 액세스를 관리합니다. VNF는 DPDK 라이브러리를 사용하여 데이터 플레인 인터페이스를 결합하므로, 데이터 플레인 인터페이스는 VNF를 DPDK에 바인딩하여 고가용성을 보장합니다. 이미지에 중복성을 위한 두 개의 프로바이더 네트워크도 있습니다. 컴퓨팅 노드에는 VNF 관리와 Red Hat OpenStack Platform API 관리 간에 결합되고 공유되는 두 개의 일반 NIC가 있습니다.

NFV SR-IOV 배포

이 이미지는 애플리케이션 수준에서 DPDK를 사용하는 VNF를 나타내며 패브릭 구성에 따라 가용성 또는 성능을 향상시키기 위해 SR-IOV VF(가상 기능) 및 PF(물리 기능)에 액세스할 수 있습니다. 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의 토폴로지

아래 이미지에서 NFV의 하이퍼컨버지드 인프라(HCI) 없이 SR-IOV의 토폴로지를 관찰합니다. 1Gbps NIC와 director 노드가 있는 compute 및 controller 노드로 구성됩니다.

HCI가 없는 NFV SR-IOV 토폴로지

6장. SR-IOV 기술 배포

Red Hat OpenStack Platform NFV 배포에서는 가상 리소스를 통해 인스턴스에서 직접 액세스할 수 있는 경우 SR-IOV(단일 루트 I/O 가상화)로 더 높은 성능을 얻을 수 있습니다.

6.1. SR-IOV 기술 배포를 위한 필수 조건

  • 오버클라우드를 배포하기 전에 Undercloud를 설치하고 구성하는 방법에 대한 자세한 내용은 Director 설치 및 사용 가이드 를 참조하십시오.
참고

director heat 템플릿이 수정하는 /etc/tuned/cpu-partitioning-variables.conf 의 값을 수동으로 편집하지 마십시오.

6.2. SR-IOV 구성

단일 루트 I/O 가상화(SR-IOV)를 사용하여 RHOSP(Red Hat OpenStack Platform)를 배포하려면 인스턴스에 직접 액세스를 요청할 수 있는 SR-IOV 기능이 있는 공유 PCIe 리소스를 구성합니다.

참고

다음 CPU 할당, 메모리 할당, NIC 구성은 예제이며 사용 사례와 다를 수 있습니다.

절차

  1. stack 사용자로 언더클라우드에 로그인합니다.
  2. stackrc 파일을 소싱합니다.

    [stack@director ~]$ source ~/stackrc
  3. ControllerComputeSriov 역할을 포함하는 roles_data_compute_sriov.yaml 이라는 새 역할 데이터 파일을 생성합니다.

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

    ComputeSriov 는 기본 컴퓨팅 서비스 외에도 NeutronSriovAgent,NeutronSriovHostConfig 서비스를 포함하는 RHOSP 설치에 제공되는 사용자 지정 역할입니다.

  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 카드가 있는 물리적 서버에서 다음 명령 중 하나를 사용합니다.

    • 배포된 오버클라우드에서 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)
    • 오버클라우드를 아직 배포하지 않은 경우 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 가이드의 NovaPCIPassthrough에 대한 지침을 참조하십시오.
    • <physical_network> 를 PCI 장치가 있는 물리적 네트워크의 이름으로 바꿉니다.

      참고

      NIC의 장치 이름이 변경될 수 있으므로 PCI 패스스루를 구성할 때 devname 매개변수를 사용하지 마십시오. PF에서 네트워킹 서비스(neutron) 포트를 생성하려면 NovaPCIPassthrough 에서 vendor _id, product _id 및 PCI 장치 주소를 지정하고 --vnic-type direct-physical 옵션을 사용하여 포트를 만듭니다. 가상 기능(VF)에서 네트워킹 서비스 포트를 생성하려면 NovaPCIPassthrough 에서 vendor_idproduct_id 를 지정하고 --vnic-type direct 옵션을 사용하여 포트를 생성합니다. vendor_idproduct_id 매개변수 값은 물리적 기능(PF)과 VF 컨텍스트마다 다를 수 있습니다. NovaPCIPassthrough 구성 방법에 대한 자세한 내용은 인스턴스 생성 용 Compute 서비스 구성 가이드의 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 매개변수는 네트워크 구성 템플릿의 NeutronSriovNumVFs 매개변수를 대체합니다. Red Hat은 배포 후 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 파티션 설정

이 기능은 일반적으로 RHOSP(Red Hat OpenStack Platform) 16.1.2에서 사용할 수 있으며 Intel Fortville NIC 및 Mellanox CX-5 NIC에서 검증됩니다.

RHOSP 호스트에서 VF(가상 기능)를 사용할 수 있도록 SR-IOV(단일 루트 I/O 가상화)를 구성할 수 있습니다.

단일 고속 NIC를 여러 VF로 분할하면 컨트롤 및 데이터 플레인 트래픽 모두에 NIC를 사용할 수 있습니다.

절차

  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 매개변수는 네트워크 구성 템플릿의 NeutronSriovNumVFs 매개변수를 대체합니다. Red Hat은 배포 후 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 )으로 바꿉니다. ovs_bond 와 같은 다른 본딩의 본딩에 VLAN 태그를 적용할 수 있습니다.
    • <bonding_option> 을 지원되는 다음 본딩 모드 중 하나로 바꿉니다.

      • active-backup
      • balance-slb

        참고

        LACP 본딩은 지원되지 않습니다.

    • members 섹션에서 결합할 인터페이스 유형으로 sriov_vf 를 지정합니다.

      참고

      OVS 브리지를 인터페이스 유형으로 사용하는 경우 sriov_pf 장치의 sriov_vf에서 하나의 OVS 브리지만 구성할 수 있습니다. 단일 sriov_pf 장치에서 두 개 이상의 OVS 브리지를 사용하면 VF에서 패킷 중복이 발생하고 성능이 저하될 수 있습니다.

    • <pf_device_name> 을 PF 장치의 이름으로 바꿉니다.
    • linux_bond 를 사용하는 경우 VLAN 태그를 할당해야 합니다.
    • <vf_id> 를 VF의 ID로 바꿉니다. 적용 가능한 VF ID 범위는 0에서 시작되고 최대 VF 수에서 1을 뺀 값으로 끝납니다.
  4. 스푸핑 검사를 비활성화하고 VF를 통해 linux_bondsriov_vf 에 VLAN 태그를 적용합니다.
  5. 인스턴스에 VF를 예약하려면 환경 파일에 NovaPCIPassthrough 매개변수를 포함합니다. 예를 들면 다음과 같습니다.

    NovaPCIPassthrough:
     - devname: "eno3"
       trusted: "true"
       physical_network: "sriov1"
     - devname: "eno4"
       trusted: "true"
       physical_network: "sriov2"

    director는 호스트 VF를 식별하고 인스턴스에 사용할 수 있는 VF의 PCI 주소를 파생합니다.

  6. NIC 파티셔닝이 필요한 모든 노드에서 IOMMU 를 활성화합니다. 예를 들어 컴퓨팅 노드의 NIC 파티셔닝을 사용하려면 해당 역할에 KernelArgs 매개변수를 사용하여 IOMMU를 활성화합니다.

    parameter_defaults:
      ComputeParameters:
        KernelArgs: "intel_iommu=on iommu=pt"
    참고

    KernelArgs 매개변수를 역할 구성에 처음 추가하면 오버클라우드 노드가 자동으로 재부팅됩니다. 필요한 경우 노드 자동 재부팅을 비활성화하고 대신 각 오버클라우드 배포 후 노드를 수동으로 재부팅할 수 있습니다. 자세한 내용은 KernelArgs를 정의하도록 수동 노드 재부팅 구성을 참조하십시오.

  7. 다른 환경 파일을 사용하여 스택에 역할 파일 및 환경 파일을 추가하고 오버클라우드를 배포합니다.

    (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 본딩을 구성하려면 스푸핑 검사를 비활성화하고 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 본딩 확인.

    [heat-admin@overcloud-computeovsdpdksriov-1 ~]$ cat /proc/net/bonding/<bond_name>
    Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
    
    Bonding Mode: fault-tolerance (active-backup)
    Primary Slave: None
    Currently Active Slave: eno3v1
    MII Status: up
    MII Polling Interval (ms): 0
    Up Delay (ms): 0
    Down Delay (ms): 0
    Peer Notification Delay (ms): 0
    
    Slave Interface: eno3v1
    MII Status: up
    Speed: 10000 Mbps
    Duplex: full
    Link Failure Count: 0
    Permanent HW addr: 4e:77:94:bd:38:d2
    Slave queue ID: 0
    
    Slave Interface: eno4v1
    MII Status: up
    Speed: 10000 Mbps
    Duplex: full
    Link Failure Count: 0
    Permanent HW addr: 4a:74:52:a7:aa:7c
    Slave queue ID: 0
  3. OVS 본딩을 나열합니다.

    [heat-admin@overcloud-computeovsdpdksriov-1 ~]# sudo ovs-appctl bond/show
    ---- dpdkbond0 ----
    bond_mode: balance-slb
    bond may use recirculation: no, Recirc-ID : -1
    bond-hash-basis: 0
    updelay: 0 ms
    downdelay: 0 ms
    next rebalance: 9491 ms
    lacp_status: off
    lacp_fallback_ab: false
    active slave mac: ce:ee:c7:58:8e:b2(dpdk1)
    
    slave dpdk0: enabled
      may_enable: true
    
    slave dpdk1: enabled
      active slave
      may_enable: true
  4. OVS 연결을 표시합니다.

    [root@overcloud-compute-0 heat-admin]# ovs-vsctl show
    b6567fa8-c9ec-4247-9a08-cbf34f04c85f
        Manager "ptcp:6640:127.0.0.1"
            is_connected: true
        Bridge br-sriov2
            Controller "tcp:127.0.0.1:6633"
                is_connected: true
            fail_mode: secure
            datapath_type: netdev
            Port phy-br-sriov2
                Interface phy-br-sriov2
                    type: patch
                    options: {peer=int-br-sriov2}
            Port br-sriov2
                Interface br-sriov2
                    type: internal
        Bridge br-sriov1
            Controller "tcp:127.0.0.1:6633"
                is_connected: true
            fail_mode: secure
            datapath_type: netdev
            Port phy-br-sriov1
                Interface phy-br-sriov1
                    type: patch
                    options: {peer=int-br-sriov1}
            Port br-sriov1
                Interface br-sriov1
                    type: internal
        Bridge br-ex
            Controller "tcp:127.0.0.1:6633"
                is_connected: true
            fail_mode: secure
            datapath_type: netdev
            Port br-ex
                Interface br-ex
                    type: internal
            Port phy-br-ex
                Interface phy-br-ex
                    type: patch
                    options: {peer=int-br-ex}
        Bridge br-tenant
            Controller "tcp:127.0.0.1:6633"
                is_connected: true
            fail_mode: secure
            datapath_type: netdev
            Port br-tenant
                tag: 305
                Interface br-tenant
                    type: internal
            Port phy-br-tenant
                Interface phy-br-tenant
                    type: patch
                    options: {peer=int-br-tenant}
            Port dpdkbond0
                Interface dpdk0
                    type: dpdk
                    options: {dpdk-devargs="0000:18:0e.0"}
                Interface dpdk1
                    type: dpdk
                    options: {dpdk-devargs="0000:18:0a.0"}
        Bridge br-tun
            Controller "tcp:127.0.0.1:6633"
                is_connected: true
            fail_mode: secure
            datapath_type: netdev
            Port vxlan-98140025
                Interface vxlan-98140025
                    type: vxlan
                    options: {df_default="true", egress_pkt_mark="0", in_key=flow, local_ip="152.20.0.229", out_key=flow, remote_ip="152.20.0.37"}
            Port br-tun
                Interface br-tun
                    type: internal
            Port patch-int
                Interface patch-int
                    type: patch
                    options: {peer=patch-tun}
            Port vxlan-98140015
                Interface vxlan-98140015
                    type: vxlan
                    options: {df_default="true", egress_pkt_mark="0", in_key=flow, local_ip="152.20.0.229", out_key=flow, remote_ip="152.20.0.21"}
            Port vxlan-9814009f
                Interface vxlan-9814009f
                    type: vxlan
                    options: {df_default="true", egress_pkt_mark="0", in_key=flow, local_ip="152.20.0.229", out_key=flow, remote_ip="152.20.0.159"}
            Port vxlan-981400cc
                Interface vxlan-981400cc
                    type: vxlan
                    options: {df_default="true", egress_pkt_mark="0", in_key=flow, local_ip="152.20.0.229", out_key=flow, remote_ip="152.20.0.204"}
        Bridge br-int
    
            Controller "tcp:127.0.0.1:6633"
                is_connected: true
            fail_mode: secure
            datapath_type: netdev
            Port int-br-tenant
                Interface int-br-tenant
                    type: patch
                    options: {peer=phy-br-tenant}
            Port int-br-ex
                Interface int-br-ex
                    type: patch
                    options: {peer=phy-br-ex}
            Port int-br-sriov1
                Interface int-br-sriov1
                    type: patch
                    options: {peer=phy-br-sriov1}
            Port patch-tun
                Interface patch-tun
                    type: patch
                    options: {peer=patch-int}
            Port br-int
                Interface br-int
                    type: internal
            Port int-br-sriov2
                Interface int-br-sriov2
                    type: patch
                    options: {peer=phy-br-sriov2}
            Port vhu4142a221-93
                tag: 1
                Interface vhu4142a221-93
                    type: dpdkvhostuserclient
                    options: {vhost-server-path="/var/lib/vhost_sockets/vhu4142a221-93"}
        ovs_version: "2.13.2"

NovaPCIPassthrough를 사용하여 VF를 인스턴스에 전달한 경우 SR-IOV 인스턴스를 배포하여 테스트합니다.

6.4. OVS 하드웨어 오프로드 구성

OVS 하드웨어 오프로드 구성 절차는 SR-IOV 구성과 동일한 여러 단계를 공유합니다.

참고

Red Hat OpenStack Platform 16.2.3부터 OVS 하드웨어 오프로드 및 ML2/OVS를 사용하여 Compute 노드의 트래픽을 오프로드하려면 openvswitch_agent.ini 구성 파일에서 disable_packet_marking 매개 변수를 true 로 설정한 다음 neutron_ovs_agent 컨테이너를 다시 시작해야 합니다.

cat /var/lib/config-data/puppet-generated/neutron/etc/neutron/plugins/ml2/openvswitch_agent.ini
  [ovs]
  disable_packet_marking=True

절차

  1. 컴퓨팅 역할을 기반으로 OVS 하드웨어 오프로드에 대한 오버클라우드 역할을 생성합니다.

    openstack overcloud roles generate -o roles_data.yaml Controller Compute:ComputeOvsHwOffload
  2. 선택 사항: ComputeOvsHwOffload 역할에 대해 HostnameFormatDefault: '%stackname%-compute-%index%' 이름을 변경합니다.
  3. OvsHwOffload 매개 변수를 역할별 매개 변수에서 true 로 추가합니다.
  4. iptables/hybrid 방화벽 드라이버 구현을 사용하도록 neutron을 구성하려면 다음 행을 포함합니다. NeutronOVSFirewallDriver: iptables_hybrid. NeutronOVSFirewallDriver 에 대한 자세한 내용은 Advanced Overcloud Customization Guide의 Open vSwitch Firewall 사용을 참조하십시오.
  5. 사용자 환경과 일치하도록 physical_network 매개 변수를 구성합니다.

    • VLAN의 경우 배포 후 neutron에서 생성한 네트워크 이름으로 physical_network 매개 변수를 설정합니다. 이 값은 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 를 구성하는 방법에 대한 자세한 내용은 Configuring the Compute Service for Instance Creation 가이드의 NovaPCIPassthrough에 대한 지침을 참조하십시오.

  6. 기본 필터 목록에 NUMATopologyFilter 가 포함되어 있는지 확인합니다.

      NovaSchedulerDefaultFilters: [\'AvailabilityZoneFilter',\'ComputeFilter',\'ComputeCapabilitiesFilter',\'ImagePropertiesFilter',\'ServerGroupAntiAffinityFilter',\'ServerGroupAffinityFilter',\'PciPassthroughFilter',\'NUMATopologyFilter']
    참고

    선택 사항: Mellanox ConnectX5 NIC를 사용하여 RHOSP 16.2에서 OVS 하드웨어 오프로드 문제를 해결하고 구성하는 방법에 대한 자세한 내용은 2.2 섹션 Hardware Offload 를 참조하십시오.

  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 매개 변수를 사용하지 마십시오. 가상 함수의 수는 o s-net-config에서 사용하는 네트워크 구성 파일에서 numvf s 매개 변수를 사용하여 지정합니다. Red Hat은 업데이트 또는 재배포 중에 numvfs 설정 수정을 지원하지 않습니다.
    • 드라이버 제한으로 인해 VXLAN과 같은 터널 엔드포인트가 트래픽을 전달하지 못하므로 Mellanox 네트워크 인터페이스를 nic -config 인터페이스 유형 ovs-vlan 으로 구성하지 마십시오.
  8. 오버클라우드 배포 명령에 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 드라이버를 switch dev 모드로 설정하면 mlx5_core 드라이버가 기본적으로 하나의 결합된 채널로 설정되어 최적의 성능을 제공하지 못할 수 있습니다.

절차

  • PF 표시자에서 다음 명령을 입력하여 호스트에서 사용할 수 있는 CPU 수를 조정합니다. $(nproc)를 사용 가능한 CPU 수로 바꿉니다.

    $ sudo ethtool -L enp3s0f0 combined $(nproc)

CPU 고정

성능 저하가 교차 NUMA 작업을 방지하려면 동일한 NUMA 노드에서 NIC, 애플리케이션, VF 게스트 및 OVS를 찾습니다. 자세한 내용은 인스턴스 생성용 Compute 서비스 구성 가이드의 컴퓨팅 노드에 CPU 고정 구성 가이드를 참조하십시오.

6.6. OVS 하드웨어 오프로드 구성 요소

Mellanox 스마트 NIC를 사용하여 OVS HW Offload의 구성 요소를 구성하고 문제 해결하기 위한 참조입니다.

Nova

NUMATopologyFilterDerivePciWhitelistEnabled 매개변수와 함께 NovaPCIPassthrough 필터를 사용하도록 구성합니다. OVS HW Offload를 활성화하면 Nova 스케줄러는 인스턴스 생성에 대한 SR-IOV 패스스루와 유사하게 작동합니다.

Neutron

OVS HW 오프로드를 활성화하는 경우 devlink cli 도구를 사용하여 NIC e-switch 모드를 switchdev 로 설정합니다. Switchdev 모드에서는 VF에 매핑되는 NIC에 표현자 포트를 설정합니다.

절차

  1. switchdev-enabled NIC에서 포트를 할당하려면 binding-profile 값이 있는 neutron 포트를 생성하고 포트 보안을 비활성화합니다.

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

인스턴스를 만들 때 이 포트 정보를 전달합니다. 대표 포트를 인스턴스 VF 인터페이스와 연결하고 일회성 OVS 데이터 경로 처리를 위해 정수 포트를 OVS 브리지 br-int에 연결합니다. 물리적 "패치 패널" 프론트엔드의 소프트웨어 버전과 같은 VF 포트 표현자. 새 인스턴스 생성에 대한 자세한 내용은 다음을 참조하십시오. SR-IOV용 인스턴스 배포

OVS

하드웨어 오프로드가 구성된 환경에서 전송된 첫 번째 패킷은 OVS 커널 경로를 통과하며, 이 패킷은 인스턴스 트래픽에 대해 들어오고 나가는 트래픽에 대한 ml2 OVS 규칙을 설정합니다. 트래픽 스트림의 흐름이 설정되면 OVS는 트래픽 제어(TC) Flower 유틸리티를 사용하여 이러한 흐름을 NIC 하드웨어에 푸시합니다.

절차

  1. director를 사용하여 OVS에 다음 설정을 적용합니다.

    $ sudo ovs-vsctl set Open_vSwitch . other_config:hw-offload=true
  2. 를 다시 시작하여 HW 오프로드를 활성화합니다.

TC(Traffic Control) 하위 시스템

hw-offload 플래그를 활성화하면 OVS는 TC 데이터 경로를 사용합니다. TC Flower는 하드웨어에 데이터 경로 흐름을 쓰는 iproute2 유틸리티입니다. 그러면 이중화를 위해 하드웨어 및 소프트웨어 데이터 경로에 흐름이 프로그래밍됩니다.

절차

  1. 다음 구성을 적용합니다. 명시적으로 구성하지 않는 경우 기본 옵션입니다.

    $ 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 Flower가 포트 수준에서 흐름 프로그래밍을 푸시하는지 확인합니다.

     $ sudo ethtool -K enp3s0f0 hw-tc-offload on
참고

펌웨어를 최신 상태로 유지합니다.Yum 또는 dnf 업데이트가 펌웨어 업데이트를 완료하지 못할 수 있습니다. 자세한 내용은 벤더 설명서를 참조하십시오.

6.7. OVS 하드웨어 오프로드 문제 해결

사전 요구 사항

  • Linux Kernel 4.13 이상
  • OVS 2.8 이상
  • RHOSP 12 이상
  • iproute 4.12 이상
  • Mellanox NIC 펌웨어 (예: FW ConnectX-5 16.21.0338 이상)

지원되는 사전 요구 사항에 대한 자세한 내용은 Red Hat Knowledgebase 솔루션 Network Adapter Fast Datapath 기능 지원 매트릭스 를 참조하십시오.

OVS HW 오프로드 배포에서 네트워크 구성

HW 오프로드 배포에서는 요구 사항에 따라 다음 시나리오 중 하나를 선택할 수 있습니다.

  • 본딩에 연결된 동일한 인터페이스 집합 또는 각 유형에 대해 다른 NIC 세트를 사용하여 VXLAN 및 VLAN에 게스트 VM을 기반으로 할 수 있습니다.
  • 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 또는 balance-xor - mode=2
  • 802.3ad (LACP) - mode=4

다음 본딩 구성은 지원되지 않습니다.

  • xmit_hash_policy=layer3+4

인터페이스 구성 확인

다음 절차에 따라 인터페이스 구성을 확인합니다.

절차

  1. 배포하는 동안 호스트 네트워크 구성 도구 os-net-config 를 사용하여 hw-tc-offload 를 활성화합니다.
  2. 컴퓨팅 노드를 재부팅할 때마다 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. 컴퓨팅 노드를 재부팅할 때마다 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 인터페이스의 드라이버는 e-switch uplink 포트의 대표임을 표시하기 위해 "\\x5e_rep" 로 설정됩니다. 이는 기능에 영향을 미치지 않습니다.

OVS에서 오프로드 상태 확인

다음 절차를 사용하여 OVS에서 오프로드 상태를 확인합니다.

  • 컴퓨팅 노드에서 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 쉘에 액세스하여 라우팅 테이블과 다른 디버깅을 검사할 수 있습니다. 다음 절차에서는 Cumuls 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 플래그와 통계를 검사합니다. 하드웨어 라는 단어는 하드웨어에서 네트워크 트래픽을 처리함을 나타냅니다. usetc -policy=none 인 경우 하드웨어나 소프트웨어가 패킷을 처리할 때 조사할 이 출력 또는 tcpdump를 확인할 수 있습니다. 드라이버가 패킷을 오프로드할 수 없는 경우 dmesg 또는 ovs-vswitch.log 에서 해당 로그 메시지를 확인할 수 있습니다.
  4. 예를 들어 Mellanox의 경우 로그 항목은 dmesg 의 메시지와 유사합니다.

    [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 2.11의 오프로드 경로에서 흐름의 연결 추적 속성을 지원하지 않으므로 HW 오프로드와 함께 OVS 방화벽 드라이버를 사용할 수 없습니다.

6.8. HW 오프로드 흐름 디버깅

ovs-vswitch.log 파일에 다음 메시지가 표시되면 다음 절차를 사용할 수 있습니다.

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

절차

  1. offload 모듈에서 로깅을 활성화하고 이 오류에 대한 추가 로그 정보를 가져오려면 컴퓨팅 노드에서 다음 명령을 사용합니다.

    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 펌웨어 툴(MFT), mlxconfig, mlxlink 및 OFED(OpenFabrics Enterprise Distribution) 드라이버를 설치할 수 있습니다.

유용한 CLI 명령

다음 옵션과 함께 ethtool 유틸리티를 사용하여 진단 정보를 수집합니다.

  • ethtool -l <uplink representor> : 채널 수 보기
  • ethtool -I <uplink/VFs> : 통계 확인
  • ethtool -i <uplink rep> : 드라이버 정보 보기
  • ethtool -g <uplink rep> : 링 크기 확인
  • ethtool -k <uplink/VFs> : 활성화된 기능보기

표현자 및 PF 포트에서 tcpdump 유틸리티를 사용하여 트래픽 흐름을 유사하게 확인합니다.

  • 대표 포트의 링크 상태에 대한 변경 사항은 VF 링크 상태에도 영향을 줍니다.
  • Representor 포트 통계도 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 서비스 구성 가이드의 컴퓨팅 노드에 CPU 고정 구성 가이드를 참조하십시오.

다음 단계를 수행하여 SR-IOV(단일 루트 I/O 가상화)에 대한 인스턴스를 배포합니다.

  1. 플레이버를 만듭니다.

    # openstack flavor create <flavor> --ram <MB> --disk <GB> --vcpus <#>
    작은 정보

    플레이버에 hw:pci_numa_affinity_policy 를 추가하여 PCI 패스스루 장치 및 SR-IOV 인터페이스에 대한 NUMA 선호도 정책을 지정할 수 있습니다. 자세한 내용은 인스턴스 생성용 Compute 서비스 구성 가이드의 플레이버 메타데이터 를 참조하십시오.

  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 direct-physical 을 사용하여 단일 인스턴스 전용 SR-IOV 물리적 기능(PF) 포트를 만듭니다. 이 PF 포트는 Networking 서비스(neutron) 포트이지만 Networking 서비스에서 제어하지 않으며 인스턴스에 전달되는 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. 배포 템플릿의 parameter_defaults 아래의 heat 매개변수 NovaSchedulerDefault Filter를 통해 AggregateInstanceExtraSpecs Filter 및 기타 필요한 필터를 구성할 수 있습니다.

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

    이 매개변수를 기존 클러스터의 구성에 추가하려면 heat 템플릿에 추가하고 원래 배포 스크립트를 다시 실행하면 됩니다.

  2. SR-IOV의 집계 그룹을 만들고 관련 호스트를 추가합니다. 정의된 플레이버 메타데이터와 일치하는 메타데이터(예: 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를 위한 OVS-DPDK(Data Plane Development Kit) 배포를 사용하여 Open vSwitch를 최적화하려면 OVS-DPDK에서 Compute 노드 하드웨어(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 Poll Mode Drivers(PMD)는 전용 CPU 코어가 필요한 DPDK 활성 루프를 실행합니다. 따라서 일부 CPU와 대규모 페이지를 OVS-DPDK에 할당해야 합니다.

샘플 파티셔닝에는 듀얼 소켓 컴퓨팅 노드의 NUMA 노드당 16개의 코어가 포함됩니다. 호스트와 OVS-DPDK 간에 NIC를 공유할 수 없기 때문에 트래픽에 추가 NIC가 필요합니다.

OpenStack NFV Hardware Capacities 464931 0118 OVS DPDK
참고

NUMA 노드에 연결된 DPDK NIC가 없는 경우에도 두 NUMA 노드에서 DPDK PMD 스레드를 예약해야 합니다.

최적의 OVS-DPDK 성능을 위해 로컬 메모리 블록을 NUMA 노드에 예약합니다. 메모리 및 CPU 고정에 사용하는 동일한 NUMA 노드와 연관된 NIC를 선택합니다. 결합된 두 인터페이스가 모두 동일한 NUMA 노드의 NIC에서 있는지 확인합니다.

7.2. 워크플로우 및 파생 매개 변수

이 기능은 이번 릴리스에서 기술 프리뷰로 제공되므로 Red Hat에서 완전히 지원되지 않습니다. 테스트 용도로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.

Red Hat OpenStack Platform Workflow(mistral) 서비스를 사용하여 사용 가능한 베어 메탈 노드의 기능에 따라 매개변수가 파생될 수 있습니다. 워크플로는 YAML 파일을 사용하여 수행할 작업 및 작업을 정의합니다. tripleo-common/workbooks/ 디렉터리에서 사전 정의된 워크북 derive _params.yaml 을 사용할 수 있습니다. 이 워크북은 베어 메탈 인트로스펙션 결과에서 지원되는 각 매개 변수를 파생하는 워크플로를 제공합니다. derive _params.yaml 워크플로는 tripleo-common/workbooks/derive_params_formulas.yaml 의 공식을 사용하여 파생된 매개변수를 계산합니다.

참고

환경에 맞게 derive _params_formulas.yaml 을 수정할 수 있습니다.

derive _params.yaml 워크북에서는 특정 구성 가능 역할에 대한 모든 노드가 동일한 하드웨어 사양으로 가정합니다. 워크플로에서는 역할과 연결된 노드와 일치하도록 flavor-profile 연결 및 nova 배치 스케줄러를 고려한 다음 역할과 일치하는 첫 번째 노드의 인트로스펙션 데이터를 사용합니다.

워크플로에 대한 자세한 내용은 워크플로우 및 실행 문제 해결을 참조하십시오. https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/director_installation_and_usage/troubleshooting-director-errors#troubleshooting-workflows-and-executions

p 또는 --plan-environment-file 옵션을 사용하여 openstack overcloud deploy 명령에 워크북 목록과 입력 값이 포함된 사용자 지정 plan_environment.yaml 파일을 추가할 수 있습니다. 결과 워크플로는 파생된 매개변수를 사용자 지정 plan_environment.yaml로 다시 병합합니다. 여기에서 오버클라우드 배포에 사용할 수 있습니다.

배포에 --plan-environment-file 옵션을 사용하는 방법에 대한 자세한 내용은 환경 메타데이터 계획을 참조하십시오.

7.3. 파생된 OVS-DPDK 매개변수

derive _params.yaml 의 워크플로는 ComputeNeutronOvsDpdk 서비스를 사용하는 역할과 연결된 DPDK 매개변수를 파생합니다.

워크플로는 OVS-DPDK에 대해 다음 매개 변수를 자동으로 파생할 수 있습니다. NovaVcpuPinSet 매개변수는 더 이상 사용되지 않으며 고정된 전용 워크플로우의 경우 NovaComputeCpuDedicatedSet 로 교체됩니다.

  • IsolCpusList
  • KernelArgs
  • NovaReservedHostMemory
  • NovaComputeCpuDedicatedSet
  • OvsDpdkSocketMemory
  • OvsPmdCoreList
참고

오류를 방지하려면 역할별 매개 변수에 대한 역할별 태그를 구성해야 합니다.

OvsDpdkMemoryChannels 매개변수는 다양한 하드웨어 환경에서 메모리 슬롯 이름의 형식이 일치하지 않기 때문에 인트로스펙션 메모리 은행 데이터에서 파생될 수 없습니다.

대부분의 경우 기본 OvsDpdkMemoryChannels 수는 4입니다. 하드웨어 설명서를 참조하여 소켓당 메모리 채널 수를 확인하고 기본 번호를 이 값으로 업데이트합니다.

워크플로 매개 변수에 대한 자세한 내용은 8.1절. “워크플로우를 사용하여 DPDK 매개변수 비활성화” 의 내용을 참조하십시오.

7.4. OVS-DPDK 매개변수 수동 계산

이 섹션에서는 OVS-DPDK에서 director network_environment.yaml heat 템플릿 내에서 매개변수를 사용하여 최적의 성능을 위해 CPU 및 메모리를 구성하는 방법에 대해 설명합니다. 이 정보를 사용하여 컴퓨팅 노드에서 하드웨어 지원을 평가하고 OVS-DPDK 배포를 최적화하는 하드웨어를 분할하는 방법을 평가합니다.

참고

대신 drive _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 코어를 선택합니다. OVS의 pmd-cpu-mask 값으로 OvsPmdCoreList 를 사용합니다. OvsPmdCoreList 에 다음 권장 사항을 사용하십시오.

  • 스위칭 스레드를 쌍으로 연결합니다.
  • 성능은 이 PMD Core 목록에 할당된 물리적 코어 수에 따라 다릅니다. DPDK NIC와 연결된 NUMA 노드에서 필요한 코어를 할당합니다.
  • DPDK NIC가 있는 NUMA 노드의 경우 성능 요구 사항에 따라 필요한 물리적 코어 수를 확인하고 각 물리적 코어에 대해 모든 시블링 스레드 또는 논리 CPU를 포함합니다.
  • DPDK NIC가 없는 NUMA 노드의 경우 NUMA 노드의 첫 번째 물리적 코어를 제외한 모든 물리적 코어의 시블링 스레드 또는 논리적 CPU를 할당합니다.
참고

NUMA 노드에 연결된 DPDK NIC가 없는 경우에도 두 NUMA 노드에서 DPDK PMD 스레드를 예약해야 합니다.

NovaComputeCpuDedicatedSet

고정된 인스턴스 CPU 프로세스를 예약할 수 있는 쉼표로 구분된 물리적 호스트 CPU 목록 또는 범위입니다. 예를 들어, NovaComputeCpuDedicatedSet: [4-12,^8,15] 는 8을 제외하고 4-12 및 15의 코어를 예약합니다.

  • OvsPmdCoreList 에서 모든 코어를 제외합니다.
  • 나머지 코어를 모두 포함합니다.
  • 스위칭 스레드를 쌍으로 연결합니다.
NovaComputeCpuSharedSet
인스턴스 에뮬레이터 스레드의 호스트 CPU를 결정하는 데 사용되는 쉼표로 구분된 물리적 호스트 CPU 번호 목록 또는 범위입니다.
IsolCpusList

호스트 프로세스에서 격리된 CPU 코어 집합입니다. IsolCpusListtuned-profiles-cpu -partitioning 구성 요소에 대한 cpu-partitioning- variable.conf 파일의 isolated_cores 값입니다. 다음 IsolCpusList 권장 사항을 사용하십시오.

  • OvsPmdCoreListNovaComputeCpuDedicatedSet의 코어 목록을 일치시킵니다.
  • 스위칭 스레드를 쌍으로 연결합니다.
DerivePciWhitelistEnabled

VM에 VF(가상 기능)를 예약하려면 NovaPCIPassthrough 매개 변수를 사용하여 Nova에 전달된 VF 목록을 생성합니다. 목록에서 제외된 VFS는 호스트에 계속 사용할 수 있습니다.

목록의 각 VF에 대해 address 값으로 확인되는 정규식으로 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은 NIC 파티셔닝에 eno2 에서 사용됩니다. 다음 예와 같이 VF 1-3, 5, 7을 포함하도록 NovaPCIPassthrough 를 수동으로 구성하고, 결과적으로 VF 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 메모리 또는 하드웨어 설명서를 사용하여 사용 가능한 메모리 채널 수를 확인합니다.
  • ls /sys/devices/system/node/node* -d 를 사용하여 NUMA 노드 수를 확인합니다.
  • 사용 가능한 메모리 채널 수를 NUMA 노드 수로 나눕니다.
NovaReservedHostMemory

호스트의 작업을 위해 MB 단위의 메모리를 예약합니다. NovaReservedHostMemorynova.conf 의 컴퓨팅 노드의 reserved_host_memory_mb 값입니다. NovaReservedHostMemory 에 대한 다음 권장 사항을 확인합니다.

  • 정적 권장 값 4096MB를 사용합니다.
OvsDpdkSocketMemory

NUMA 노드당 hugepage 풀에서 사전 할당할 메모리 양을 지정합니다. OvsDpdkSocketMemory 는 OVS의 other_config:dpdk-socket-mem 값입니다. OvsDpdkSocketMemory 에 대한 다음 권장 사항을 확인하십시오.

  • 를 쉼표로 구분된 목록으로 제공합니다.
  • DPDK NIC가 없는 NUMA 노드의 경우 1024MB의 정적 권장 사항을 사용합니다(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를 추가하고 추가로 512MB를 버퍼로 추가합니다. 값을 1024의 배수로 반올림합니다.
참고

MTU 크기가 1500이 아닌 경우 /var/log/verify 에 메모리 풀 오류 메시지를 생성하지 못할 수 있습니다. 인스턴스 시작 시 발생하는 경우 이 오류 메시지는 무시해도 됩니다. 이 메시지를 방지하려면 1500 MTU에 대한 추가 OvsDpdkSocketMemory 양을 OvsDpdkSocketMemory 계산에 추가합니다.

샘플 계산 - MTU 2000 및 MTU 9000

DPDK NICs 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.

    이 계산은 (2000의 MTU에 필요한 메모리) + (2000의 MTU에 필요한 메모리) + (512 MB 버퍼)를 나타냅니다.

  4. 필요한 총 메모리를 MB로 변환합니다.

    3909091328 / (1024*1024) = 3728 MB.
  5. 이 값을 가장 가까운 1024로 반올림합니다.

    3724 MB rounds up to 4096 MB.
  6. 이 값을 사용하여 OvsDpdkSocketMemory 를 설정합니다.

        OvsDpdkSocketMemory: "4096,1024"

샘플 계산 - 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.

    이 계산은 (2000의 MTU에 필요한 메모리) + (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 소켓 디렉터리를 설정합니다. vhost 클라이언트 모드에 /var/lib/vhost_sockets 를 사용합니다.

7.4.4. 기타 매개변수

NovaSchedulerDefaultFilters
컴퓨팅 노드에서 요청된 게스트 인스턴스의 일치하는 컴퓨팅 노드를 찾는 데 사용하는 순서가 지정된 필터 목록을 제공합니다.
VhostuserSocketGroup
vhost-user 소켓 디렉터리 그룹을 설정합니다. 기본값은 qemu 입니다. ovs-vswitchd 및 qemu 프로세스가 virtio- net 장치를 구성하는 공유 대규모 페이지 및 unix 소켓에 액세스할 수 있도록 VhostuserSocketGrouphugetlbfs 로 설정합니다. 이 값은 역할에 따라 다르며 OVS-DPDK를 활용하는 모든 역할에 적용해야 합니다.
KernelArgs

부팅 시 컴퓨팅 노드의 /etc/default/grub 에 여러 커널 인수를 제공합니다. 구성에 따라 다음 값을 추가합니다.

  • hugepagesz: CPU에서 대규모 페이지 크기를 설정합니다. 이 값은 CPU 하드웨어에 따라 다를 수 있습니다. OVS-DPDK 배포의 경우 1G(default_hugepagesz=1GB hugepagesz=1G)로 설정합니다. 이 명령을 사용하여 CPU가 1G를 지원하는지 확인하는 the pdpe1gb CPU 플래그를 확인합니다.

    lshw -class processor | grep pdpe1gb
  • hugepages 수: 사용 가능한 호스트 메모리를 기반으로 사용 가능한 대규모 페이지 수를 설정합니다. NovaReservedHostMemory 를 제외한 대부분의 사용 가능한 메모리를 사용합니다. 또한 컴퓨팅 노드의 플레이버 내에서 대규모 페이지 수 값을 구성해야 합니다.
  • iommu: Intel CPU의 경우 "intel_iommu=on iommu=pt"를 추가합니다.
  • isolcpus: 튜닝을 위한 CPU 코어 설정. 이 값은 IsolCpusList 와 일치합니다.

CPU 격리에 대한 자세한 내용은 RHEL 8 및 RHEL 9에 대한 Red Hat Knowledgebase 솔루션 OpenStack CPU 격리 지침을참조하십시오.

7.4.5. 인스턴스 추가 사양

NFV 환경에서 인스턴스를 배포하기 전에 CPU 고정, 대규모 페이지 및 에뮬레이터 스레드 고정을 활용하는 플레이버를 만듭니다.

hw:cpu_policy
이 매개 변수가 dedicated 로 설정되면 게스트는 고정된 CPU를 사용합니다. 이 매개 변수 집합을 사용하여 플레이버에서 생성된 인스턴스는 효과적인 과다 할당 비율은 1:1입니다. 기본값은 shared 입니다.
hw:mem_page_size

이 매개변수를 표준 접미사가 있는 특정 값의 유효한 문자열로 설정합니다(예: 4KB,8MB 또는 1GB). 1GB를 사용하여 hugepagesz 부팅 매개 변수와 일치시킵니다. 부팅 매개 변수에서 OvsDpdkSocketMemory 를 제거하여 가상 시스템에 사용할 수 있는 대규모 페이지 수를 계산합니다. 다음 값도 유효합니다.

  • 작은 (기본값) - 가장 작은 페이지 크기가 사용됩니다.
  • Large - 큰 페이지 크기만 사용합니다. (2MB 또는 x86 아키텍처 기반 1GB)
  • 임의의 - 계산 드라이버는 대규모 페이지를 사용할 수 있지만 사용할 수 없는 경우 기본값은 small입니다.
hw:emulator_threads_policy
heat 매개변수인 NovaComputeCpuSharedSet 에서 확인한 CPU로 에뮬레이터 스레드가 잠길 수 있도록 이 매개변수의 값을 공유 하도록 설정합니다. 에뮬레이터 스레드가 폴링 모드 드라이버(PMD) 또는 실시간 처리가 포함된 vCPU에서 실행 중인 경우 패킷 손실과 같이 부정적인 영향을 경험할 수 있습니다.

7.5. NUMA 노드 예 OVS-DPDK 배포

다음 예제의 Compute 노드에는 두 개의 NUMA 노드가 포함되어 있습니다.

  • NUMA 0에는 코어 0-7이 있습니다. sibling 스레드 쌍은 (0,1), (2,3), (4,5) 및 (6,7)입니다.
  • NUMA 1에는 8-15 코어가 있습니다. 시블링 스레드 쌍은 (8,9), (10,11), (0,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"

DPDK의 NIC 1, PMD용 물리적 코어 1

이 사용 사례에서는 PMD에 NUMA 0에 하나의 물리적 코어를 할당합니다. 또한 해당 NUMA 노드에 대해 NIC에서 DPDK를 활성화하지 않더라도 NUMA 1에 하나의 물리적 코어를 할당해야 합니다. 나머지 코어는 게스트 인스턴스에 할당됩니다. 결과 매개변수 설정은 다음과 같습니다.

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

DPDK용 NIC 1, PMD용 물리적 코어 2개

이 사용 사례에서는 PMD에 NUMA 0에 두 개의 물리적 코어를 할당합니다. 또한 해당 NUMA 노드에 대해 NIC에서 DPDK를 활성화하지 않더라도 NUMA 1에 하나의 물리적 코어를 할당해야 합니다. 나머지 코어는 게스트 인스턴스에 할당됩니다. 결과 매개변수 설정은 다음과 같습니다.

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

DPDK의 NIC 2, PMD용 물리적 코어 1개

이 사용 사례에서는 PMD에 NUMA 1에 하나의 물리적 코어를 할당합니다. 또한 해당 NUMA 노드에 대해 NIC에서 DPDK를 활성화하지 않더라도 NUMA 0에 하나의 물리적 코어를 할당해야 합니다. 나머지 코어는 게스트 인스턴스에 할당됩니다. 결과 매개변수 설정은 다음과 같습니다.

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

DPDK의 NIC 2, PMD용 물리적 코어 2

이 사용 사례에서는 PMD에 NUMA 1에서 두 개의 물리적 코어를 할당합니다. 또한 해당 NUMA 노드에 대해 NIC에서 DPDK를 활성화하지 않더라도 NUMA 0에 하나의 물리적 코어를 할당해야 합니다. 나머지 코어는 게스트 인스턴스에 할당됩니다. 결과 매개변수 설정은 다음과 같습니다.

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

PMD용 물리적 코어 2개가 있는 DPDK의 NIC 1 및 NIC2

이 사용 사례에서는 각 NUMA 노드에서 PMD에 두 개의 물리적 코어를 할당합니다. 나머지 코어는 게스트 인스턴스에 할당됩니다. 결과 매개변수 설정은 다음과 같습니다.

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

7.6. NFV OVS-DPDK 배포의 토폴로지

이 배포 예제에서는 OVS-DPDK 구성을 보여주며 각각 두 개의 인터페이스가 있는 두 개의 VNF(가상 네트워크 기능)로 구성됩니다.

  • mgt 로 표시되는 관리 인터페이스.
  • 데이터 플레인 인터페이스입니다.

OVS-DPDK 배포에서 VNF는 물리적 인터페이스를 지원하는 기본 제공 DPDK로 작동합니다. OVS-DPDK는 vSwitch 수준에서 본딩을 활성화합니다. OVS-DPDK 배포의 성능 향상을 위해 커널과 OVS-DPDK NIC를 분리하는 것이 좋습니다. 가상 시스템의 기본 프로바이더 네트워크에 연결된 관리(mgt) 네트워크를 분리하려면 추가 NIC가 있어야 합니다. 컴퓨팅 노드는 Ceph API에서 재사용할 수 있지만 OpenStack 프로젝트와 공유할 수는 없는 Red Hat OpenStack Platform API 관리를 위한 두 개의 일반 NIC로 구성됩니다.

NFV OVS-DPDK 배포

NFV OVS-DPDK 토폴로지

다음 이미지는 NFV의 OVS-DPDK 토폴로지를 보여줍니다. 1 또는 10Gbps NIC와 director 노드가 있는 컴퓨팅 및 컨트롤러 노드로 구성됩니다.

NFV OVS-DPDK 토폴로지

8장. OVS-DPDK 배포 구성

이 섹션에서는 Red Hat OpenStack Platform 환경에 OVS-DPDK를 배포합니다. Overcloud는 일반적으로 컨트롤러 노드, 컴퓨팅 노드 및 다양한 스토리지 노드 유형과 같은 사전 정의된 역할의 노드로 구성됩니다. 이러한 각 기본 역할에는 director 노드의 코어 heat 템플릿에 정의된 서비스 세트가 포함되어 있습니다.

오버클라우드를 배포하기 전에 언더클라우드를 설치하고 구성해야 합니다. 자세한 내용은 Director 설치 및 사용 가이드 를 참조하십시오.

중요

OVS-DPDK에 OpenStack 네트워크를 최적화하려면 network-environment.yaml 파일에 있는 OVS- DPDK 매개변수에 가장 적합한 값을 결정해야 합니다.

참고

director heat 템플릿이 수정하는 etc/tuned/cpu-partitioning-variables.conf 에서 isolated_cores 또는 기타 값을 수동으로 편집하거나 변경하지 마십시오.

8.1. 워크플로우를 사용하여 DPDK 매개변수 비활성화

중요

이 기능은 이번 릴리스에서 기술 프리뷰로 제공되므로 Red Hat에서 완전히 지원되지 않습니다. 테스트 용도로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.

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-file 선택적 인수가 있는 plan-environment-derived- parms.yaml 파일

      $ 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여야 합니다.

파생 매개 변수를 사용하여 오버클라우드 배포

다음과 같은 파생 매개 변수를 사용하여 오버클라우드를 배포하려면 다음을 수행합니다.

  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가 있는 클러스터에서 워크플로는 Compute 또는 ComputeSriovs가 아닌 ComputeOvsDpdk 역할에 대해서만 공식을 적용합니다.

8.2. OVS-DPDK 토폴로지

Red Hat OpenStack Platform을 사용하면 구성 가능 역할 기능을 사용하여 각 역할에서 서비스를 추가하거나 제거할 수 있는 사용자 지정 배포 역할을 생성할 수 있습니다. Composable Roles에 대한 자세한 내용은 Advanced Overcloud CustomizationComposable Services and Custom Roles 를 참조하십시오.

이 이미지는 컨트롤 플레인 및 데이터 플레인에 대한 결합된 포트 2개가 있는 OVS-DPDK 토폴로지의 예를 보여줍니다.

OpenStack NFV Config Guide Topology 450694 0617 ECE OVS DPDK

OVS-DPDK를 구성하려면 다음 작업을 수행합니다.

  • 구성 가능 역할을 사용하는 경우 roles_data.yaml 파일을 복사하고 수정하여 OVS-DPDK에 대한 사용자 지정 역할을 추가합니다.
  • 커널 인수 및 DPDK 인수에 대한 매개변수를 포함하도록 적절한 network-environment.yaml 파일을 업데이트합니다.
  • DPDK 인터페이스 매개 변수의 브리지를 포함하도록 compute.yaml 파일을 업데이트합니다.
  • DPDK 인터페이스 매개변수에 대해 동일한 브리지 세부 정보를 포함하도록 controller.yaml 파일을 업데이트합니다.
  • overcloud_deploy.sh 스크립트를 실행하여 DPDK 매개 변수를 사용하여 오버클라우드를 배포합니다.
참고

이 가이드에서는 토폴로지 및 사용 사례와 다를 수 있는 CPU 할당, 메모리 할당 및 NIC 구성에 대한 예를 제공합니다. 하드웨어 및 구성 옵션에 대한 자세한 내용은 다음을 참조하십시오. 네트워크 기능 가상화 제품 가이드2장. 하드웨어 요구 사항 .

사전 요구 사항

참고

Red Hat OpenStack Platform은 OVS-DPDK 배포를 위한 OVS 클라이언트 모드에서 작동합니다.

8.3. OVS-DPDK 인터페이스의 MTU 값 설정

Red Hat OpenStack Platform은 OVS-DPDK의 점보 프레임을 지원합니다. 점보 프레임의 MTU(최대 전송 단위) 값을 설정하려면 다음을 수행해야 합니다.

  • network-environment.yaml 파일에서 네트워킹의 글로벌 MTU 값을 설정합니다.
  • compute.yaml 파일에서 물리적 DPDK 포트 MTU 값을 설정합니다. 이 값은 vhost 사용자 인터페이스에서도 사용합니다.
  • 컴퓨팅 노드의 게스트 인스턴스 내에서 MTU 값을 설정하여 구성에서 끝나는 것과 유사한 MTU 값이 있는지 확인합니다.
참고

VXLAN 패킷에는 헤더에 추가 50바이트가 포함됩니다. 이러한 추가 헤더 바이트에 따라 MTU 요구 사항을 계산합니다. 예를 들어 MTU 값이 9000이면 VXLAN 터널 MTU 값이 8950으로 되어 이러한 추가 바이트를 고려합니다.

참고

NIC는 DPDK PMD에서 제어되고 compute.yaml 파일에서 설정한 것과 동일한 MTU 값이 있으므로 물리적 NIC에 대한 특별한 구성이 필요하지 않습니다. 실제 NIC에서 지원하는 최대 값보다 큰 MTU 값을 설정할 수 없습니다.

OVS-DPDK 인터페이스의 MTU 값을 설정하려면 다음을 수행합니다.

  1. network-environment.yaml 파일에서 NeutronGlobalPhysnetMtu 매개변수를 설정합니다.

    parameter_defaults:
      # MTU global configuration
      NeutronGlobalPhysnetMtu: 9000
    참고

    network-environment.yaml 파일의 OvsDpdkSocketMemory 값이 jumbo 프레임을 지원할 수 있을 만큼 충분히 큰지 확인합니다. 자세한 내용은 7.4.2절. “메모리 매개변수” 를 참조하십시오.

  2. 브리지의 MTU 값을 controller.yaml 파일의 컴퓨팅 노드로 설정합니다.

      -
        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. 보안 그룹에 대한 방화벽 구성

데이터 플레인 인터페이스에는 상태 저장 방화벽에서 고성능이 필요합니다. 이러한 인터페이스를 보호하려면 telco-grade 방화벽을 VNF(가상 네트워크 기능)로 배포하는 것이 좋습니다.

ML2/OVS 배포에서 컨트롤 플레인 인터페이스를 구성하려면 NeutronOVSFirewallDriver 매개변수를 openvswitch 로 설정합니다. 흐름 기반 OVS 방화벽 드라이버를 사용하려면 parameter_defaults 에서 network-environment.yaml 파일을 수정합니다. OVN 배포에서는 ACL(액세스 제어 목록)을 사용하여 보안 그룹을 구현할 수 있습니다.

흐름의 연결 추적 속성이 오프로드 경로에서 지원되지 않으므로 HW 오프로드와 함께 OVS 방화벽 드라이버를 사용할 수 없습니다.

예제:

parameter_defaults:
  NeutronOVSFirewallDriver: openvswitch

openstack port set 명령을 사용하여 데이터 플레인 인터페이스에 대한 OVS 방화벽 드라이버를 비활성화합니다.

예제:

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

8.5. OVS-DPDK 인터페이스에 대한 멀티 큐 설정

참고

멀티 큐는 실험적이며 수동 대기열 고정에서만 지원됩니다.

절차

  • 컴퓨팅 노드의 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. OVS PMD 자동 로드 밸런서 구성

중요

이 기능은 이번 릴리스에서 기술 프리뷰로 제공되므로 Red Hat에서 완전히 지원되지 않습니다. 테스트 용도로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.

OVS(Open vSwitch) Poll Mode Driver(PMD) 스레드를 사용하여 사용자 공간 컨텍스트 전환에 대해 다음 작업을 수행할 수 있습니다.

  • 패킷의 입력 포트를 연속적으로 폴링합니다.
  • 수신된 패킷 분류.
  • 분류 후 패킷에 대한 작업 실행.

다음 매개변수를 사용하여 OVS PMD 스레드를 자동으로 로드 밸런싱하도록 RHOSP 배포를 구성할 수 있습니다.

  • OvsPmdAutoLb
  • OvsPmdLoadThreshold
  • OvsPmdImprovementThreshold
  • OvsPmdRebalInterval

절차

  1. OvsPmdAutoLb 매개변수 값을 true 로 변경하여 자동 PMD 로드 밸런싱을 활성화합니다.

    parameter_defaults:
    OvsPmdAutoLb: true
  2. OvsPmdLoadThreshold 매개변수를 사용하여 PMD 부하 분산을 트리거하는 사용된 주기의 백분율 제한을 지정합니다.

    parameter_defaults:
    OvsPmdAutoLb: true
      OvsPmdLoadThreshold: <load_threshold>

    자동 부하 분산을 트리거하는 PMD 스레드 부하의 최소 백분율을 나타내도록 <load_threshold> 를 0에서 100 사이의 숫자로 바꿉니다.

  3. PMD Auto Load Balance OvsPmprovementThreshold 매개변수를 트리거하는 비 격리 PMD 스레드에서 평가된 개선의 최소 백분율을 지정합니다.

    parameter_defaults:
    OvsPmdAutoLb: true
      OvsPmdLoadThreshold: <load_threshold>
      OvsPmdImprovementThreshold: <improvement_threshold>

    자동 로드 밸런싱을 트리거하는 평가 개선의 최소 백분율을 나타내도록 <improvement_threshold> 를 0에서 100 사이의 숫자로 바꿉니다.

  4. OvsPmdRebalInterval 매개변수를 사용하여 연속된 두 개의 자동 로드 밸런싱 작업 간 최소 시간을 지정합니다.

    parameter_defaults:
    OvsPmdAutoLb: true
      OvsPmdLoadThreshold: <load_threshold>
      OvsPmdImprovementThreshold: <improvement_threshold>
      OvsPmdRebalInterval: <interval>

    시간(분)을 표시하려면 <interval> 을 0에서 20,000 사이의 숫자로 바꿉니다.

  5. 다른 환경 파일을 사용하여 OVS PMD 환경 파일을 스택에 추가하고 오버클라우드를 배포합니다.

    (undercloud)$ openstack overcloud deploy --templates \
     -e [your environment files] \
     -e /home/stack/templates/auto_ovs_pmd.yaml

8.7. 알려진 제한 사항

Red Hat OpenStack Platform for NFV를 사용하여 OVS-DPDK를 구성할 때 다음 제한 사항을 관찰합니다.

  • 비DPDK 트래픽 및 내부, 관리, 스토리지, 스토리지 관리, 테넌트와 같은 컨트롤 플레인 네트워크에 Linux 본딩을 사용합니다. 본딩에 사용된 PCI 장치 모두 최적의 성능을 위해 동일한 NUMA 노드에 있는지 확인합니다. Neutron Linux 브리지 구성은 Red Hat에서 지원하지 않습니다.
  • OVS-DPDK를 사용하여 호스트에서 실행되는 모든 인스턴스에 대해 대규모 페이지가 필요합니다. 게스트에 대규모 페이지가 없으면 인터페이스가 표시되지만 작동하지 않습니다.
  • OVS-DPDK에서는 DVR(Distributed Virtual Routing)과 같은 탭 장치를 사용하는 서비스의 성능 저하가 있습니다. 결과 성능은 프로덕션 환경에 적합하지 않습니다.
  • OVS-DPDK를 사용하는 경우 동일한 컴퓨팅 노드의 모든 브릿지는 ovs_user_bridge 유형이어야 합니다. director에서 구성을 수락할 수 있지만 Red Hat OpenStack Platform은 동일한 노드에서 ovs_bridgeovs_user_bridge 혼합을 지원하지 않습니다.

8.8. 플레이버 생성 및 OVS-DPDK용 인스턴스 배포

NFV를 사용하여 Red Hat OpenStack Platform 배포에 대해 OVS-DPDK를 구성한 후 플레이버를 생성하고 다음 단계를 사용하여 인스턴스를 배포할 수 있습니다.

  1. 집계 그룹을 만들고 OVS-DPDK에 대한 관련 호스트를 추가합니다. 정의된 플레이버 메타데이터와 일치하는 example 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 서비스 구성 가이드의 컴퓨팅 노드에 CPU 고정 구성 가이드를 참조하십시오.

  2. 플레이버를 만듭니다.

    # openstack flavor create <flavor> --ram <MB> --disk <GB> --vcpus <#>
  3. 플레이버 속성을 설정합니다. 정의된 metadata, 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.9. 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 모드 드라이버 CPU 마스크가 CPU에 고정되어 있는지 확인합니다. 하이퍼 스레딩의 경우 sibling 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 전체에서 유동적으로 사용합니다. 이 게스트 CPU에서 폴링 모드 드라이버(PMD) 또는 실시간 처리에 사용되는 스레드가 실행되는 경우 패킷 손실 또는 누락된 데드라인이 발생할 수 있습니다.

에뮬레이터 스레드를 VM 처리 작업과 분리하여 스레드를 자체 게스트 CPU에 고정하여 성능을 향상시킬 수 있습니다.

9.1.1. 호스트 에뮬레이터 스레드로 CPU 구성

성능을 개선하려면 에뮬레이터 스레드 호스팅을 위해 호스트 CPU의 하위 집합을 예약합니다.

절차
  1. 지정된 역할에 대해 NovaComputeCpuSharedSet 을 사용하여 오버클라우드를 배포합니다. 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 매개변수를 설정해야 합니다. 이를 위해 nova.conf 를 수동으로 편집해도 재배포 시 유지되지 않을 수 있으므로 heat를 사용해야 합니다.

9.1.2. 에뮬레이터 스레드 고정 확인

절차
  1. 지정된 인스턴스의 호스트 및 이름을 식별합니다.

    openstack server show <instance_id>
  2. SSH를 사용하여 식별된 호스트에 heat-admin으로 로그인합니다.

    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를 프로비저닝하는 실시간 컴퓨팅 노드 역할.
  • 추가 RT-KVM 커널 모듈.
  • 컴퓨팅 노드의 자동 구성입니다.

9.2.1. RT-KVM 컴퓨팅 노드 계획

RT-KVM 컴퓨팅 노드에 Red Hat 인증 서버를 사용해야 합니다. 자세한 내용은 다음을 참조하십시오. Red Hat Enterprise Linux for Real Time 7 인증 서버.

RT-KVM용 rhel-8-server-nfv-rpms 리포지토리를 활성화하고 시스템이 최신 상태인지 확인하는 방법에 대한 자세한 내용은 다음을 참조하십시오. 언더클라우드 등록 및 업데이트.

참고

이 리포지토리에 액세스하려면 별도의 Red Hat OpenStack Platform for Real Time SKU 서브스크립션이 필요합니다.

실시간 이미지 빌드

  1. 언더클라우드에 libguestfs-tools 패키지를 설치하여 virt-customize 툴을 가져옵니다.

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

    언더클라우드에 libguestfs-tools 패키지를 설치하는 경우 iscsid.socket 을 비활성화하여 언더클라우드의 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. 이미지를 등록하여 사용자 지정과 관련된 Red Hat 리포지토리를 활성화합니다. [username][password] 를 다음 예에서 유효한 자격 증명으로 바꿉니다.

    virt-customize -a overcloud-realtime-compute.qcow2 --run-command \
    'subscription-manager register --username=[username] --password=[password]' \
    subscription-manager release --set 8.4
    참고

    보안을 위해 명령 프롬프트에서 사용되는 경우 기록 파일에서 자격 증명을 제거할 수 있습니다. 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.2-for-rhel-8-x86_64-rpms \
    --enable=rhel-8-for-x86_64-nfv-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 error: cannot find a suitable template" 이라는 줄이 표시되면 이 오류를 무시할 수 있습니다.

  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

이제 선택한 컴퓨팅 노드에서 ComputeOvsDpdkRT 구성 가능 역할과 함께 사용할 수 있는 실시간 이미지가 있습니다.

RT-KVM 컴퓨팅 노드에서 BIOS 설정 수정

RT-KVM 컴퓨팅 노드의 대기 시간을 줄이려면 컴퓨팅 노드 BIOS 설정에서 다음 매개변수의 모든 옵션을 비활성화합니다.

  • 전원 관리
  • 하이퍼-스레딩
  • CPU 절전 상태
  • 논리 프로세서

이러한 설정에 대한 설명 및 비활성화에 미치는 영향은 BIOS 매개 변수 설정을 참조하십시오. BIOS 설정을 변경하는 방법에 대한 자세한 내용은 하드웨어 제조업체 설명서를 참조하십시오.

9.2.2. RT-KVM을 사용하여 OVS-DPDK 구성

참고

OVS-DPDK에 대해 OpenStack 네트워크를 최적화하려면 network-environment.yaml 파일에 설정한 OVS- DPDK 매개변수에 가장 적합한 값을 결정해야 합니다. 자세한 내용은 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. 오버클라우드 배포

ML2-OVS의 오버클라우드를 배포합니다.

(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 인스턴스 시작

실시간 활성화된 컴퓨팅 노드에서 RT-KVM 인스턴스를 시작하려면 다음 단계를 수행합니다.

  1. 오버클라우드에 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. 신뢰할 수 있는 가상 함수

VF가 불규칙 모드 활성화 또는 하드웨어 주소 수정과 같은 권한 있는 작업을 수행할 수 있도록 물리적 기능(PF)과 VF(가상 기능) 간 신뢰성을 구성할 수 있습니다.

9.3.1. 가상 기능과 물리적 기능 간의 신뢰 구성

사전 요구 사항
  • director를 포함한 Red Hat OpenStack Platform의 운영 설치
절차

실제 및 가상 기능 간에 신뢰가 있는 오버클라우드를 구성하고 배포하려면 다음 단계를 완료합니다.

  1. parameter_defaults 섹션에 NeutronPhysicalDevMappings 매개변수를 추가하여 논리적 네트워크 이름과 실제 인터페이스 간에 연결합니다.

    parameter_defaults:
      NeutronPhysicalDevMappings:
        - sriov2:p5p2
  2. SR-IOV 매개 변수에 신뢰할 수 있는 새 속성을 추가합니다.

    parameter_defaults:
      NeutronPhysicalDevMappings:
        - sriov2:p5p2
      NovaPCIPassthrough:
        - vendor_id: "8086"
          product_id: "1572"
          physical_network: "sriov2"
          trusted: "true"
    참고

    "true" 값에 대해 겹따옴표가 포함되어야 합니다.

    중요

    관리자 이외의 계정에서 신뢰할 수 있는 포트 바인딩을 허용하므로 신뢰할 수 있는 환경에서 다음 단계를 완료합니다.

  3. 사용자가 포트 바인딩을 생성하고 업데이트할 수 있도록 권한을 수정합니다.

    parameter_defaults:
      NeutronApiPolicies: {
        operator_create_binding_profile: { key: 'create_port:binding:profile', value: 'rule:admin_or_network_owner'},
        operator_get_binding_profile: { key: 'get_port:binding:profile', value: 'rule:admin_or_network_owner'},
        operator_update_binding_profile: { key: 'update_port:binding:profile', value: 'rule:admin_or_network_owner'}
      }

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 인수를 포함하는 경우 스푸핑 검사를 비활성화할 수 있습니다.

9.4. RX/TX 큐 크기 구성

다음과 같은 여러 가지 이유로 초당 3,300만 개 이상의 패킷 속도로 패킷 손실이 발생할 수 있습니다.

  • 네트워크 인터럽트
  • 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
  • 0 프레임 손실 시 3.8 mpps/core와 같은 향상된 성능을 확인할 수 있습니다.

9.5. NUMA 인식 vSwitch 구성

중요

이 기능은 이번 릴리스에서 기술 프리뷰로 제공되므로 Red Hat에서 완전히 지원되지 않습니다. 테스트 용도로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.

NUMA 인식 vSwitch를 구현하기 전에 하드웨어 구성의 다음 구성 요소를 검사합니다.

  • 물리적 네트워크 수입니다.
  • PCI 카드 배치.
  • 서버의 물리적 아키텍처.

PCIe NIC와 같은 메모리 매핑 I/O(Memory 매핑 I/O) 장치는 특정 NUMA 노드와 연결됩니다. VM과 NIC가 서로 다른 NUMA 노드에 있는 경우 성능이 크게 저하됩니다. 성능을 높이기 위해 동일한 NUMA 노드에서 PCIe NIC 배치 및 인스턴스 처리를 정렬합니다.

이 기능을 사용하여 물리적 네트워크를 공유하는 인스턴스가 동일한 NUMA 노드에 있는지 확인합니다. 데이터센터 하드웨어 활용도를 최적화하려면 여러 개의 physnet을 사용해야 합니다.

주의

최적의 서버 사용률을 위해 NUMA 인식 네트워크를 구성하려면 PCIe 슬롯과 NUMA 노드의 매핑을 이해해야 합니다. 특정 하드웨어에 대한 자세한 내용은 공급업체 설명서를 참조하십시오. NUMA 인식 vSwitch를 올바르게 계획하거나 구현하지 못하면 서버에서 단일 NUMA 노드만 사용할 수 있습니다.

교차 NUMA 구성을 방지하려면 NIC 위치를 Nova에 제공하여 올바른 NUMA 노드에 VM을 배치합니다.

사전 요구 사항

  • NUMATopologyFilter필터를 활성화했습니다.

절차

  • NeutronPhysnetNUMANodesMapping 매개변수를 설정하여 물리적 네트워크를 물리적 네트워크와 연결된 NUMA 노드에 매핑합니다.
  • VxLAN 또는 GRE와 같은 터널을 사용하는 경우 NeutronTunnelNUMANodes 매개변수도 설정해야 합니다.

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

다음은 NUMA 노드 0으로 터널링된 두 개의 물리 네트워크가 있는 예입니다.

  • NUMA 노드 0과 연결된 프로젝트 네트워크 1개
  • 선호도가 없는 하나의 관리 네트워크

    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 인식 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가 적절한 네트워크에 연결되어 있는 VM을 시작합니다.

알려진 제한 사항

  • 2-노드 게스트 NUMA 토폴로지를 지정하지 않은 경우 다른 NUMA 노드에서 physnet에 연결된 두 개의 NIC가 있는 VM을 시작할 수 없습니다.
  • 2-노드 게스트 NUMA 토폴로지를 지정하지 않은 경우 physnet에 하나의 NIC와 다른 NUMA 노드에서 터널링된 네트워크에 연결된 다른 NIC가 있는 VM을 시작할 수 없습니다.
  • 2-노드 게스트 NUMA 토폴로지를 지정하지 않은 경우 다른 NUMA 노드에서 하나의 vhost 포트와 하나의 VF가 있는 VM을 시작할 수 없습니다.
  • NUMA 인식 vSwitch 매개 변수는 Overcloud 역할에 따라 다릅니다. 예를 들어 Compute 노드 1 및 Compute 노드 2에는 다른 NUMA 토폴로지가 있을 수 있습니다.
  • VM의 인터페이스에 NUMA 선호도가 있는 경우 선호도가 단일 NUMA 노드 전용인지 확인합니다. NUMA 노드에서 NUMA 선호도 없이 모든 인터페이스를 찾을 수 있습니다.
  • 관리 네트워크가 아닌 데이터 플레인 네트워크에 대한 NUMA 선호도를 구성합니다.
  • 터널링된 네트워크의 NUMA 선호도는 모든 VM에 적용되는 글로벌 설정입니다.

9.6. NFVi 환경에서 QoS(Quality of Service) 구성

QoS 구성에 대한 자세한 내용은 QoS (Quality of Service) 정책 구성을 참조하십시오. 지원은 다음 QoS 규칙 유형으로 제한됩니다.

  • 벤더가 지원하는 경우 SR-IOV의 최소 대역폭 입니다.
  • SR-IOV 및 OVS-DPDK 송신 인터페이스의 대역폭 제한.

9.7. HCI 및 DPDK를 사용하여 오버클라우드 배포

최적화된 리소스 사용을 위해 Compute 및 Ceph Storage 서비스를 함께 찾고 구성하여 하이퍼컨버지드 노드를 사용하여 NFV 인프라를 배포할 수 있습니다.

HCI(하이퍼 컨버지드 인프라)에 대한 자세한 내용은 다음을 참조하십시오. Hyper Converged Infrastructure 가이드

사전 요구 사항
  • Red Hat OpenStack Platform 16.1.
  • 최신 버전의 Red Hat Ceph Storage 4.
  • rhceph-4-tools-for-rhel-8-x86_64-rpms 리포지토리에서 제공하는 최신 버전의 ceph- ansible 4입니다.
절차
  1. 언더클라우드에 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 create 및 openstack flavor set 명령을 사용하여 새 플레이버를 생성하고 구성합니다. 플레이버 생성에 대한 자세한 내용은 Advanced Overcloud Customization Guide의 새 역할 생성 을 참조하십시오.
  4. 생성한 사용자 지정 roles_data.yaml 파일을 사용하여 오버클라우드를 배포합니다.

    # 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 노드에 배치하고 VNF 및 모든 NFV VM을 NUMA-1과 같은 다른 NUMA 노드에 배치합니다.

CPU 할당:
NUMA-0NUMA-1

Ceph OSD 수 * 4 HT

VNF 및 비 NFV VM의 게스트 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에 대해 CPU 1개를 할당합니다. ceph와 연결된 NUMA 노드의 코어 및 시블링 스레드 목록과 세 가지 목록에 없는 CPU를 포함합니다. NovaComputeCpuDedicatedSet, and OvsPmdCoreList.
2
ceph_osd_docker_cpu_limit: ceph OSD를 ceph_osd_docker_cpuset_cpus 의 CPU 목록에 고정하려면 이 값을 0 으로 설정합니다.
3
ceph_osd_numactl_opts: 이 값을 예방 조치로 cross -NUMA 작업에 사용하도록 설정합니다.

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: hugepages를 계산하려면 총 메모리에서 NovaReservedHostMemory 매개변수 값을 풉니다.
2
IsolCpusList: 이 매개변수를 사용하여 호스트 프로세스에서 격리할 CPU 코어 세트를 할당합니다. OvsPmdCoreList 매개변수 값을 NovaComputeCpuDedicatedSet 매개변수 값에 추가하여 IsolCpusList 매개변수 값을 계산합니다.
3
OvsDpdkSocketMemory: OvsDpdkSocketMemory 매개변수를 사용하여 NUMA 노드당 hugepage 풀에서 사전 할당할 메모리 양을 지정합니다. 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 매개변수를 사용하여 hugepage 풀에서 MB의 메모리를 사전 할당합니다. OvsDpdkSocketMemory 매개 변수의 값과 동일한 메모리입니다.
2
NovaReservedHostMemory: NovaReservedHostMemory 매개 변수를 사용하는 호스트에서 작업을 위해 MB 단위의 메모리를 예약합니다. 다음 지침을 사용하여 예약해야 하는 메모리 양을 계산합니다.
  • 각 OSD에 대해 5GB.
  • 각 VM에 대한 0.5GB 오버헤드.
  • 4GB: 일반 호스트 처리용. 교차 NUMA OSD 작업으로 인한 잠재적인 성능 저하를 방지하기 위해 충분한 메모리를 할당했는지 확인합니다.
3
NovaComputeCpuDedicatedSet: NovaComputeCpuDedicatedSet 매개변수가 있는 OvsPmdCoreList 또는 Ceph_osd_docker_cpuset_cpus 에서 찾을 수 없는 CPU를 나열합니다. CPU는 DPDK NIC와 동일한 NUMA 노드에 있어야 합니다.

9.7.5. HCI-DPDK 배포에 권장되는 설정

표 9.1. HCI 배포에 대한 조정 가능한 매개변수

블록 장치 유형OSD, 메모리, 장치당 vCPU

NVMe

메모리 : OSD당 5GB
장치당 OSD: 4
장치당 vCPU: 3

SSD

메모리 : OSD당 5GB
장치당 OSD: 1
장치당 vCPU: 4

HDD

메모리 : OSD당 5GB
장치당 OSD: 1
장치당 vCPU: 1

다음 기능에 동일한 NUMA 노드를 사용합니다.

  • 디스크 컨트롤러
  • 스토리지 네트워크
  • 스토리지 CPU 및 메모리

DPDK 공급자 네트워크의 다음 기능에 다른 NUMA 노드를 할당합니다.

  • NIC
  • PMD CPUs
  • 소켓 메모리

9.8. Timemaster와 컴퓨팅 노드 동기화

중요

이 기능은 이번 릴리스에서 기술 프리뷰로 제공되므로 Red Hat에서 완전히 지원되지 않습니다. 테스트 용도로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.

시간 프로토콜을 사용하여 시스템 간의 일관된 타임스탬프를 유지 관리합니다.

RHOSP(Red Hat OpenStack Platform)에는 PTP(Precision Time Protocol) 및 NTP(Network Time Protocol) 지원이 포함되어 있습니다. NTP를 사용하여 밀리초 범위의 네트워크에서 시계를 동기화할 수 있으며 PTP를 사용하여 클록을 더 높은 하위 마이크로초 단위로 동기화할 수 있습니다. PTP의 사용 사례는 더 많은 간섭 위험으로 더 높은 처리량을 제공하는 여러 개의 2)가 포함된 가상 라디오 액세스 네트워크(vRAN)입니다.

Timemaster는 chronyd 또는 ntpd 와 함께 ptp4lphc2sys 를 사용하여 시스템 클록을 NTP 및 PTP 시간 소스에 동기화하는 프로그램입니다. phc2sysptp4l 프로그램은 공유 메모리 드라이버(SHM) 참조 클록을 사용하여 PTP 시간을 chronyd 또는 ntpd 로 보내 시스템 클록을 동기화하는 시간 소스를 비교합니다.

RHEL(Red Hat Enterprise Linux) 커널에서 PTPv2 프로토콜 구현은 linuxptp 입니다. linuxptp 패키지에는 PTP 경계 클록과 일반 클록 동기화를 위한 ptp4l 프로그램과 하드웨어 타임스탬프를 위한 phc2sys 프로그램이 포함되어 있습니다. PTP에 대한 자세한 내용은 다음을 참조하십시오. Red Hat Enterprise Linux 시스템 관리자 가이드의 PTP 소개.

Chrony는 NTP 프로토콜 구현입니다. Chrony의 두 가지 주요 구성 요소는 Chrony 데몬인 chronyd 와 Chrony 명령줄 인터페이스인 chronyc 입니다. Chrony에 대한 자세한 내용은 다음을 참조하십시오. chrony를 사용하여 Red Hat Enterprise Linux System Administrator의 가이드 ntp를 구성하십시오.

다음 이미지는 PTP 구성에서 패킷 이동에 대한 개요입니다.

PTP 패킷 여행 개요

다음 이미지는 PTP 구성에서 컴퓨팅 노드에서 패킷 이동에 대한 개요입니다.

PTP 패킷 여행 세부 정보

9.8.1. Timemaster 하드웨어 요구 사항

다음과 같은 하드웨어 기능이 있는지 확인합니다.

  • 하드웨어 타임스탬프 기능을 사용하여 NIC를 구성했습니다.
  • 멀티 캐스트 패킷을 허용하도록 스위치를 구성했습니다.
  • 또한 경계 또는 투명한 시계로 작동하도록 스위치를 구성했습니다.

ethtool -T <device> 명령을 사용하여 하드웨어 타임스탬프를 확인할 수 있습니다.

$ ethtool -T p5p1
Time stamping parameters for p5p1:
Capabilities:
        hardware-transmit     (SOF_TIMESTAMPING_TX_HARDWARE)
        software-transmit     (SOF_TIMESTAMPING_TX_SOFTWARE)
        hardware-receive      (SOF_TIMESTAMPING_RX_HARDWARE)
        software-receive      (SOF_TIMESTAMPING_RX_SOFTWARE)
        software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
        hardware-raw-clock    (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 6
Hardware Transmit Timestamp Modes:
        off                   (HWTSTAMP_TX_OFF)
        on                    (HWTSTAMP_TX_ON)
Hardware Receive Filter Modes:
        none                  (HWTSTAMP_FILTER_NONE)
        ptpv1-l4-sync         (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
        ptpv1-l4-delay-req    (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
        ptpv2-event           (HWTSTAMP_FILTER_PTP_V2_EVENT)

투명성 또는 경계 클록 스위치를 사용하여 정확성과 대기 시간을 줄일 수 있습니다. 경계 클록에 업링크 스위치를 사용할 수 있습니다. 경계 클록 스위치는 PTPv2 헤더에서 8비트 수정Field 를 사용하여 지연 차이를 수정하고 최종 클록에서 더 높은 정확성을 보장합니다. 투명한 클록 스위치에서는 최종 클록이 수정Field 가 아닌 지연 변동을 계산합니다.

9.8.2. 타임마스터 설정

오버클라우드 노드에서 시간 동기화를 위한 기본 RHOSP(Red Hat OpenStack Platform) 서비스는 OS::TripleO::Services::Timesync 입니다.

알려진 제한 사항

  • 가상화된 컨트롤러에 대해 NTP를 활성화하고 베어 메탈 노드에 PTP를 활성화합니다.
  • virtio 인터페이스는 호환되지 않습니다. because ptp4l 에는 호환되는 PTP 장치가 필요합니다.
  • SR-IOV가 포함된 VM에 PF(물리 기능)를 사용합니다. VF(가상 기능)는 PTP에 필요한 레지스터를 노출하지 않으며 VM은 kvm_ptp 를 사용하여 시간을 계산합니다.
  • 여러 소스와 여러 네트워크 경로가 있는 HA(고가용성) 인터페이스는 호환되지 않습니다.

절차

  1. 선택한 역할에 속하는 노드에서 Timemaster 서비스를 활성화하려면 해당 역할의 roles_data.yaml 파일 섹션에서 OS::TripleO::Services: :Timesync 줄이 포함된 행을 OS::TripleO::Services::TimeMaster 행으로 바꿉니다.

    #- OS::TripleO::Services::Timesync
    - OS::TripleO::Services::TimeMaster
  2. 사용하는 계산 역할에 대해 heat 매개 변수를 구성합니다.

    #Example
    ComputeSriovParameters:
      PTPInterfaces: ‘0:eno1,1:eno2’
      PTPMessageTransport: ‘UDPv4’
  3. 사용자 환경과 관련된 기타 환경 파일과 함께 openstack overcloud deploy 명령에 새 환경 파일을 포함합니다.

    $ openstack overcloud deploy \
    --templates \
    
    …
    -e <existing_overcloud_environment_files> \
    -e <new_environment_file1> \
    -e <new_environment_file2> \
    …
    • <existing_overcloud_environment_files>를 기존 배포의 일부인 환경 파일 목록으로 교체합니다.
    • <new_environment_file>을 오버클라우드 배포 프로세스에 포함하려는 새 환경 파일 또는 파일로 바꿉니다.

검증

  • ptp4linux 와 함께 설치된 phc_ctl 명령을 사용하여 NIC 하드웨어 클록을 쿼리합니다.

    # phc_ctl <clock_name> get
    # phc_ctl <clock_name> cmp

9.8.3. timemaster 설정 예

$ cat /etc/timemaster.conf
# Configuration file for timemaster

#[ntp_server ntp-server.local]
#minpoll 4
#maxpoll 4

[ptp_domain 0]
interfaces eno1
#ptp4l_setting network_transport l2
#delay 10e-6

[timemaster]
ntp_program chronyd

[chrony.conf]
#include /etc/chrony.conf
server clock.redhat.com iburst minpoll 6 maxpoll 10

[ntp.conf]
includefile /etc/ntp.conf

[ptp4l.conf]
#includefile /etc/ptp4l.conf
network_transport L2

[chronyd]
path /usr/sbin/chronyd

[ntpd]
path /usr/sbin/ntpd
options -u ntp:ntp -g

[phc2sys]
path /usr/sbin/phc2sys
#options -w

[ptp4l]
path /usr/sbin/ptp4l
#options -2 -i eno1

9.8.4. timemaster 작업의 예

$ systemctl status timemaster
● timemaster.service - Synchronize system clock to NTP and PTP time sources
   Loaded: loaded (/usr/lib/systemd/system/timemaster.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2020-08-25 19:10:18 UTC; 2min 6s ago
 Main PID: 2573 (timemaster)
    Tasks: 6 (limit: 357097)
   Memory: 5.1M
   CGroup: /system.slice/timemaster.service
           ├─2573 /usr/sbin/timemaster -f /etc/timemaster.conf
           ├─2577 /usr/sbin/chronyd -n -f /var/run/timemaster/chrony.conf
           ├─2582 /usr/sbin/ptp4l -l 5 -f /var/run/timemaster/ptp4l.0.conf -H -i eno1
           ├─2583 /usr/sbin/phc2sys -l 5 -a -r -R 1.00 -z /var/run/timemaster/ptp4l.0.socket -t [0:eno1] -n 0 -E ntpshm -M 0
           ├─2587 /usr/sbin/ptp4l -l 5 -f /var/run/timemaster/ptp4l.1.conf -H -i eno2
           └─2588 /usr/sbin/phc2sys -l 5 -a -r -R 1.00 -z /var/run/timemaster/ptp4l.1.socket -t [0:eno2] -n 0 -E ntpshm -M 1

Aug 25 19:11:53 computesriov-0 ptp4l[2587]: [152.562] [0:eno2] selected local clock e4434b.fffe.4a0c24 as best master

10장. 예제: VXLAN 터널링을 사용하여 OVS-DPDK 및 SR-IOV 구성

OVS-DPDK 및 SR-IOV 인터페이스를 모두 사용하여 컴퓨팅 노드를 배포할 수 있습니다. 클러스터에는 ML2/OVS 및 VXLAN 터널링이 포함됩니다.

중요

역할 구성 파일에서 예를 들어 roles_data.yaml 은 오버클라우드 역할을 생성할 때 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에서 역할 생성에 대한 자세한 내용은 Advanced Overcloud Customization 을 참조하십시오. 이 예제에 사용된 특정 역할에 대한 자세한 내용은 roles_data.yaml 을 참조하십시오.

10.2. OVS-DPDK 매개변수 구성

중요

OVS-DPDK에 대해 OpenStack 네트워크를 최적화하려면 network-environment.yaml 파일에 설정한 OVS- DPDK 매개변수에 가장 적합한 값을 결정해야 합니다. 자세한 내용은 워크플로우를 사용하여 DPDK 매개변수 활성화 를 참조하십시오.

  1. 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
  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 노드에서 sibling 스레드를 사용하여 하나 이상의 CPU를 할당합니다. 이 예제에서 OvsPmdCoreList 매개변수의 값은 NUMA 0의 코어 2 및 22를 나타내고, NUMA 1의 코어 3과 23을 나타냅니다.

    참고

    이러한 대규모 페이지는 가상 시스템에서 사용되며 이 절차에 표시된 대로 OvsDpdkSocketMemory 매개 변수를 사용하는 OVS-DPDK에서도 사용됩니다. 가상 머신에 사용할 수 있는 대규모 페이지 수는 boot 매개 변수에서 OvsDpdkSocketMemory 를 뺀 값입니다.

    또한 DPDK 인스턴스와 연결된 플레이버에 hw:mem_page_size=1GB 를 추가해야 합니다.

    참고

    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. 이 Linux 본딩에 VLAN을 할당합니다.

      - 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.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. 이 Linux 본딩에 VLAN을 할당합니다.

      - 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를 사용하는 경우 동일한 컴퓨팅 노드의 모든 브릿지는 ovs_user_bridge 유형이어야 합니다. Red Hat OpenStack Platform은 동일한 노드에 있는 ovs_bridgeovs_user_bridge 를 모두 지원하지 않습니다.

10.5. 오버클라우드 배포

  1. overcloud_deploy.sh 스크립트를 실행합니다.

11장. NFV로 Red Hat OpenStack 플랫폼 업그레이드

OVS-DPDK가 구성된 OVS-DPDK를 사용하여 RHOSP(Red Hat OpenStack Platform) 업그레이드에 대한 자세한 내용은 Framework for Upgrades(13 ~ 16.2) 가이드의 NFV(네트워크 기능 가상화) 준비를 참조하십시오.

12장. NFV 성능

Red Hat OpenStack Platform director는 리소스 파티셔닝을 적용하고, 게스트 가상 네트워크 기능(VNF)에 대한 라인 속도 성능을 달성하기 위해 컴퓨팅 노드를 구성합니다. NFV 사용 사례의 주요 성능 요인은 처리량, 대기 시간 및 지터입니다.

DPDK(데이터 플레인 개발 키트) 가속화 가상 머신을 사용하여 물리적 NIC와 가상 머신 간에 고성능 패킷 스위칭을 활성화할 수 있습니다. OVS 2.10에는 DPDK 17에 대한 지원이 포함되며 vhost-user 다중 대기열 지원이 포함되어 성능을 확장할 수 있습니다. OVS-DPDK는 게스트 VNF에 대한 라인 속도로 성능을 제공합니다.

SR-IOV(Single Root I/O Virtualization) 네트워킹은 특정 네트워크 및 가상 머신의 처리량 향상을 비롯하여 향상된 성능을 제공합니다.

성능 튜닝을 위한 기타 중요한 기능으로는 대규모 페이지, NUMA 정렬, 호스트 격리, CPU 고정 등이 있습니다. VNF 플레이버는 성능 향상을 위해 대규모 페이지와 에뮬레이터 스레드 격리가 필요합니다. 호스트 격리 및 CPU 고정은 NFV 성능을 개선하고 가상 패킷 손실을 방지합니다.

CPU 및 NUMA 토폴로지에 대한 고급 소개는 다음을 참조하십시오. NFV 성능 고려 사항에뮬레이터 스레드 구성.

13장. 더 많은 정보 찾기

다음 표에는 참조용 추가 Red Hat 문서가 포함되어 있습니다.

Red Hat OpenStack Platform 설명서 모음은 다음과 같습니다. Red Hat OpenStack Platform Documentation Suite

표 13.1. 사용 가능한 문서 목록

구성 요소reference

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 로 사용하여 최종 오버클라우드 에서 OpenStack 노드를 설치, 구성 및 관리합니다. 배포된 Overcloud에 필요한 환경 외에도 언더클라우드 설치를 위한 추가 호스트 시스템이 하나 있는지 확인합니다. 자세한 내용은 Red Hat OpenStack Platform Director 설치 및 사용을 참조하십시오.

네트워크 격리, 스토리지 구성, SSL 통신 및 일반 설정 방법과 같은 Red Hat OpenStack Platform director를 사용하여 Red Hat OpenStack Platform 엔터프라이즈 환경의 고급 기능을 구성하는 방법에 대한 자세한 내용은 Advanced Overcloud Customization 을 참조하십시오.

NFV 문서

단일 루트 I/O 가상화(SR-IOV) 및 OVS(Data Plane Development Kit)를 사용한 Red Hat OpenStack Platform 배포를 계획 및 구성하는 방법에 대한 자세한 내용은 네트워크 기능 가상화 계획 및 구성 가이드를 참조하십시오.

부록 A. DPDK SRIOV YAML 파일 샘플

이 섹션에서는 동일한 계산 노드에서 단일 루트 I/O 가상화(SR-IOV) 및 DPDK(Data Plane Development Kit) 인터페이스를 추가하기 위한 참조로 샘플 yaml 파일을 제공합니다.

참고

이러한 템플릿은 완전히 구성된 환경에서 제공되며 배포에 적용되지 않을 수 있는 NFV와 관련이 없는 매개 변수를 포함합니다. 구성 요소 지원 수준 목록은 Red Hat Knowledgebase 솔루션 구성 요소 지원 기간을 참조하십시오.

A.1. VXLAN DPDK SRIOV YAML 파일 샘플

A.1.1. roles_data.yaml

  1. openstack overcloud roles generate 명령을 실행하여 roles_data.yaml 파일을 생성합니다. 해당 환경에 배포할 역할에 따라 Controller,ComputeSriov, ComputeOvsDpdkRT,ComputeOvsDpdk Sriov 또는 기타 역할과 같이 역할 이름을 명령에 포함합니다. 예를 들어 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 controller 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 partitioning 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:
      - devname: "enp6s0f2"
        trusted: "true"
        physical_network: "sriov-1"
      - devname: "enp6s0f3"
        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