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


Red Hat OpenStack Platform 13

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

초록

이 안내서에는 중요한 계획 정보가 포함되어 있으며 Red Hat OpenStack Platform 배포의 네트워크 기능 가상화 인프라(NFVi)를 위한 SR-IOV(root input/output virtualization) 및 DPDK(Dataplane development Kit)에 대한 구성 절차를 설명합니다.

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

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

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

문서 개선을 위한 의견을 보내 주십시오. 어떻게 하면 더 잘할 수 있는지 알려주십시오.

DDF( Direct Documentation Feedback) 기능 사용

특정 문장, 단락 또는 코드 블록에 대한 직접 의견을 받으려면 피드백 DDF 추가 기능을 사용하십시오.

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

1장. 네트워크 기능 가상화 개요

NFV(Network Functions Virtualization)는 일반적인 목적의 클라우드 기반 인프라에서 네트워크 기능을 가상화하는 소프트웨어 솔루션입니다. NFV를 사용하면 통신 서비스 공급자가 기존 하드웨어에서 벗어날 수 있습니다.

NFV 개념에 대한 높은 수준 개요는 Network Functions Virtualization 제품 가이드 를 참조하십시오.

참고

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

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

network-environment.yaml
이 파일에는 오버클라우드 노드의 서브넷 및 IP 주소 범위와 같은 네트워크 세부 정보가 포함되어 있습니다. 이 파일에는 다양한 시나리오에 대한 기본 매개변수 값을 덮어쓰는 다양한 설정도 포함되어 있습니다.
compute.yaml and controller.yaml
이러한 파일에는 오버클라우드 노드의 호스트 네트워크 인터페이스 구성이 포함되어 있습니다.
host-config-and-reboot.yaml
이 파일은 더 이상 사용되지 않는 first-boot.yaml 파일을 교체하고 호스트 설치에 대한 구성이 포함되어 있습니다.

이러한 heat 템플릿 파일은 언더클라우드 노드의 /usr/share/openstack-tripleo-heat-templates/ 에 있습니다.

하드웨어 요구 사항 및 소프트웨어 요구 사항 섹션에서는 Red Hat OpenStack Platform director를 사용하여 NFV용 Heat 템플릿 파일을 계획 및 구성하는 방법에 대한 자세한 내용을 제공합니다.

참고

YAML 파일을 사용하여 NFV 구성을 간략하게 설명합니다. YAML 파일 형식에 대한 자세한 내용은 grtshell 의 YAML을 참조하십시오.

2장. 하드웨어 요구 사항

이 섹션에서는 NFV에 필요한 하드웨어 세부 정보에 대해 설명합니다.

Red Hat technical Ecosystem 을 사용하여 카테고리를 선택한 다음 제품 버전을 선택하여 인증된 하드웨어, 소프트웨어, 클라우드 공급자, 구성 요소 목록을 확인할 수 있습니다.

Red Hat OpenStack Platform 인증 하드웨어의 전체 목록은 Red Hat OpenStack Platform 인증 하드웨어를 참조하십시오.

2.1. 네트워크 어댑터 지원

NFV에 대해 테스트된 NIC 목록을 보려면 고객 포털의 네트워크 어댑터 지원 페이지에 로그인합니다.

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
Copy to Clipboard Toggle word wrap

2.2. NUMA 노드 토폴로지 검색

배포를 계획할 때 최적의 성능을 위해 CPU 및 메모리 리소스를 파티션할 수 있도록 Compute 노드의 NUMA 토폴로지를 이해해야 합니다. NUMA 정보를 확인하기 위해 다음 옵션 중 하나를 선택할 수 있습니다.

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

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

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

Bare Metal 서비스 하드웨어 검사 추가 기능(inspection_extras)은 기본적으로 활성화되어 하드웨어 세부 정보를 검색합니다. 이러한 하드웨어 세부 정보를 사용하여 오버클라우드를 구성할 수 있습니다. undercloud.conf 파일의 inspection_extras 매개변수에 대한 자세한 내용은 Director 설치 및 사용 가이드의 Director 설정을 참조하십시오.

예를 들어 numa_topology 수집기는 이러한 하드웨어 검사의 추가 기능의 일부이며 각 NUMA 노드에 대해 다음 정보를 포함합니다.

  • RAM(KB)
  • 물리적 CPU 코어 및 시블링 스레드
  • NUMA 노드와 연결된 NIC

openstack baremetal introspection data save _UUID_ | jq .numa_topology 명령을 사용하여 베어 메탈 노드의 UUID 로 이 정보를 검색합니다.

다음 예제는 베어 메탈 노드에 대해 검색된 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
    }
  ]
}
Copy to Clipboard Toggle word wrap

2.3. BIOS 설정 확인

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

  • C3 전원 상태: 비활성화됨.
  • C6 전원 상태: 비활성화됨.
  • MLC Streamer: 활성화됨.
  • MLC Spacial Prefetcher: 활성화됨.
  • DCU 데이터 사전 실행: 활성화됨.
  • DCA: 활성화됨.
  • CPU 성능 및 성능: 성능.
  • 메모리 RAS 및 성능 구성 → NUMA 최적화: 활성화됨.
  • 9000 Boost: 비활성화됨.
  • VT-d: VFIO 기능이 필요한 경우 Intel 카드에 대해 활성화됩니다.

2.4. 네트워크 어댑터 Fast Datapath 기능 지원 매트릭스

지원되는 FDP 버전 목록을 보려면 고객 포털의 Fast Datapath 개요 페이지에 로그인합니다.

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

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

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

Red Hat OpenStack Platform을 설치하려면 Red Hat Subscription Manager를 사용하여 Red Hat OpenStack Platform director를 등록하고 필요한 채널을 구독해야 합니다. 자세한 내용은 시스템 등록을 참조하십시오.

절차

  1. 기본 리포지토리를 비활성화합니다.

    subscription-manager repos --disable=*
    Copy to Clipboard Toggle word wrap
  2. NFV(네트워크 기능 가상화)를 사용하여 Red Hat OpenStack Platform에 필요한 리포지토리를 활성화합니다.

    sudo subscription-manager repos \
    --enable=rhel-7-server-rpms \
    --enable=rhel-7-server-extras-rpms \
    --enable=rhel-7-server-rh-common-rpms \
    --enable=rhel-ha-for-rhel-7-server-rpms \
    --enable=rhel-7-server-openstack-13-rpms \
    --enable=rhel-7-server-nfv-rpms
    Copy to Clipboard Toggle word wrap
참고

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

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

Red Hat OpenStack Platform은 director를 사용하여 다음과 같은 NFV(네트워크 기능 가상화) 배포를 지원합니다.

  • SR-IOV(Single Root I/O virtualization)
  • OVS-DPDK(Data Plane Development Kit)를 사용하여 Open vSwitch

또한 다음 기능을 사용하여 Red Hat OpenStack Platform을 배포할 수 있습니다.

참고

Red Hat의 임베디드 OpenDaylight SDN 솔루션은 OpenStack Platform(OSP) 14에서 더 이상 사용되지 않습니다. Red Hat은 OpenDaylight에 대한 지원 및 버그 수정을 계속 제공하며 OSP 13 라이프사이클(2021년 7월 27일)으로 종료되는 모든 지원이 제공됩니다.

3.3. 지원되는 드라이버

지원되는 드라이버의 전체 목록은 Component, Plug-In, and Driver Support in Red Hat OpenStack Platform 에서 참조하십시오.

Red Hat OpenStack을 사용한 NFV 배포에 대해 테스트된 NIC 목록은 테스트된 NIC 테스트를 참조하십시오.

3.4. 타사 소프트웨어와의 호환성

Red Hat 기술(Red Hat OpenStack Platform)에서 테스트, 지원 및 인증된 제품 및 서비스의 전체 목록은 Red Hat OpenStack Platform과 호환되는 타사 소프트웨어를 참조하십시오. 제품 버전 및 소프트웨어 카테고리별로 목록을 필터링할 수 있습니다.

Red Hat 기술(Red Hat Enterprise Linux)에서 테스트, 지원 및 인증된 제품 및 서비스의 전체 목록은 Red Hat Enterprise Linux와 호환되는 타사 소프트웨어를 참조하십시오. 제품 버전 및 소프트웨어 카테고리별로 목록을 필터링할 수 있습니다.

4장. 네트워크 고려 사항

언더클라우드 호스트에는 적어도 다음 네트워크가 필요합니다.

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

최소한의 오버클라우드 네트워크 설정에는 다음이 포함됩니다.

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

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

5장. SR-IOV 배포 계획

컴퓨팅 노드 하드웨어에 따라 개별 매개변수를 설정하여 NFV에 대해 SR-IOV(Single Root I/O Virtualization) 배포를 최적화합니다.

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

5.1. SR-IOV 배포의 하드웨어 파티션

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

일반적인 토폴로지에는 듀얼 소켓 Compute 노드의 NUMA 노드당 14개의 코어가 포함됩니다. 하이퍼 스레딩(HT) 및 비HT 코어 둘 다 지원됩니다. 각 코어에는 두 개의 형제 스레드가 있습니다. 각 NUMA 노드의 호스트에는 하나의 코어가 사용됩니다. VNF는 SR-IOV 인터페이스 본딩을 처리합니다. 모든 인터럽트 요청(IRQ)은 호스트 코어에서 라우팅됩니다. VNF 코어는 VNF 전용입니다. 다른 VNF와 호스트와의 격리를 제공합니다. 각 VNF는 단일 NUMA 노드에서 리소스를 사용해야 합니다. VNF에서 사용하는 SR-IOV NIC도 동일한 NUMA 노드와 연결되어야 합니다. 이 토폴로지에는 가상화 오버헤드가 없습니다. 호스트, OpenStack Networking(neutron) 및 Compute(nova) 구성 매개변수는 쉽고 일관성을 높이기 위해 단일 파일에 노출되고 적절한 격리에 치명적인 불일치를 방지하기 위해 호스트, 선점 및 패킷 손실이 발생합니다. 호스트 및 가상 머신 격리는 분리할 CPU 목록을 기반으로 부팅 매개변수 및 OpenStack 수정을 처리하는 tuned 프로필에 따라 다릅니다.

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

다음 이미지에는 각각 mgt 및 데이터 플레인 인터페이스가 표시되는 두 개의 가상 네트워크 기능(VNF)이 있습니다. 관리 인터페이스는 ssh 액세스를 관리하는 등의 작업을 수행합니다. 데이터 플레인 인터페이스는 VNF를 DPDK(Data Plane Development Kit)에 연결하여 고가용성 (VNFs)이 DPDK 라이브러리를 사용하여 데이터 플레인 인터페이스를 연결하도록 합니다. 이미지에는 두 개의 중복 공급자 네트워크도 있습니다. 컴퓨팅 노드에는 두 개의 일반 NIC가 함께 연결되고 VNF 관리와 Red Hat OpenStack Platform API 관리 간에 공유됩니다.

이미지에는 애플리케이션 수준에서 DPDK를 활용하고 단일 루트 I/O 가상화(SR-IOV) 가상 기능(VF) 및 물리적 기능(PF)에 대한 액세스 권한이 있는 VNF를 표시합니다. DPDK는 성능을 개선하지만 VF/PF DPDK 본딩은 장애 조치(고가용성)를 지원합니다. VNF 벤더는 DPDK poll 모드 드라이버(PMD)가 VF/PF로 노출되는 SR-IOV 카드를 지원하는지 확인해야 합니다. 관리 네트워크는 OVS(Open vSwitch)를 사용하므로 VNF는 표준 virtIO 드라이버를 사용하여 " team" 네트워크 장치를 확인합니다. Operator는 해당 장치를 사용하여 처음에 VNF에 연결하고 DPDK 애플리케이션이 두 개의 VF/PF를 올바르게 연결하도록 할 수 있습니다.

5.2.1. HCI 없이 NFV SR-IOV

아래 이미지에서 NFV 사용 사례에 대한 HCI(하이퍼 컨버지드 인프라) 없이 SR-IOV(Single Root I/O Virtualization)의 토폴로지를 확인할 수 있습니다. 1Gbps NIC와 Director 노드가 있는 compute 및 controller 노드로 구성됩니다.

6장. SR-IOV 기술 배포

SR-IOV(Single Root I/O virtualization)를 사용하면 OpenStack의 인스턴스가 가상 리소스를 통해 공유 PCIe 리소스에 직접 액세스할 수 있으므로 베어 메탈 성능이 거의 없습니다.

6.1. 사전 요구 사항

참고

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

6.2. SR-IOV 구성

참고

다음 예제의 CPU 할당, 메모리 할당 및 NIC 구성은 토폴로지 및 사용 사례와 다를 수 있습니다.

  1. 기본 제공 ComputeSriov 를 생성하여 NeutronSriovAgent,NeutronSriovHostConfig 및 기본 컴퓨팅 서비스를 실행할 OpenStack 클러스터에서 노드를 정의합니다.

    # openstack overcloud roles generate \
    -o /home/stack/templates/roles_data.yaml \
    Controller ComputeSriov
    Copy to Clipboard Toggle word wrap
  2. SR-IOV 컨테이너가 준비되도록 overcloud_images.yaml 을 생성할 때 neutron-sriov.yamlroles_data.yaml 파일을 포함합니다.

    SERVICES=\
    /usr/share/openstack-tripleo-heat-templates/environments/services
    
    openstack overcloud container image prepare \
    --namespace=registry.redhat.io/rhosp13 \
    --push-destination=192.168.24.1:8787 \
    --prefix=openstack- \
    --tag-from-label {version}-{release} \
    -e ${SERVICES}/neutron-sriov.yaml \
    --roles-file /home/stack/templates/roles_data.yaml \
    --output-env-file=/home/stack/templates/overcloud_images.yaml \
    --output-images-file=/home/stack/local_registry_images.yaml
    Copy to Clipboard Toggle word wrap
    참고

    push-destination IP 주소는 이전에 undercloud.conf 구성 파일에서 local_ip 매개변수로 설정한 주소입니다.

    컨테이너 이미지 준비에 대한 자세한 내용은 Director Installation and Usage 를 참조하십시오.

  3. KernelAgsTunedProfile 매개변수를 적용하려면 /usr/share/openstack-tripleo-heat-templates/environmentshost-config-and-reboot.yaml 파일을 배포 스크립트에 포함합니다.

    openstack overcloud deploy --templates \
    … \
    -e /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml \
    ...
    Copy to Clipboard Toggle word wrap
  4. 클러스터의 요구 사항 및 하드웨어 구성에 따라 parameter_defaults 아래에 SR-IOV 노드의 매개변수를 구성합니다. 이러한 설정은 일반적으로 network-environment.yaml 파일에 추가됩니다.

      NeutronNetworkType: 'vlan'
      NeutronNetworkVLANRanges:
        - tenant:22:22
        - tenant:25:25
      NeutronTunnelTypes: ''
    Copy to Clipboard Toggle word wrap
  5. 동일한 파일에서 SR-IOV 컴퓨팅 노드에 대한 역할별 매개 변수를 구성합니다.

    참고

    NeutronSriovNumVFs 매개변수는 네트워크 구성 템플릿에서 numvfs 속성 대신 더 이상 사용되지 않습니다. Red Hat은 배포 후 NeutronSriovNumVFs 매개변수 또는 numvfs 매개변수 수정을 지원하지 않습니다. 실행 중인 환경에서 두 매개 변수를 변경할 경우 해당 PF에 SR-IOV 포트가 있는 모든 실행 중인 인스턴스에 대한 영구 중단이 발생하는 것으로 알려져 있습니다. 이러한 인스턴스를 하드 재부팅하지 않으면 SR-IOV PCI 장치가 인스턴스에 표시되지 않습니다.

      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
          - tenant:p7p2
        NeutronSriovNumVFs:
          - p7p1:5
          - p7p2:5
        NovaPCIPassthrough:
          - vendor_id: "8086"
            product_id: "1528"
            address: "0000:06:00.0"
            physical_network: "tenant"
          - vendor_id: "8086"
            product_id: "1528"
            address: "0000:06:00.1"
            physical_network: "tenant"
        NovaVcpuPinSet: '1-19,21-39'
        NovaReservedHostMemory: 4096
    Copy to Clipboard Toggle word wrap
    참고

    NIC의 장치 이름이 변경될 수 있으므로 PCI 패스스루를 구성할 때 devname 매개변수를 사용하지 마십시오. 대신 vendor_idproduct_id 를 사용하는 것이 더 안정적이기 때문에 또는 NIC 주소를 사용합니다. NovaPCIPassthrough를 구성하는 방법에 대한 자세한 내용은 NovaPCIPassthrough 구성에 대한 지침을 참조하십시오.

  6. compute.yaml 네트워크 구성 템플릿에서 SR-IOV 지원 인터페이스를 구성합니다. SR-IOV 가상 기능(VF)을 생성하기 위해 인터페이스가 독립 실행형 NIC로 구성되었는지 확인합니다.

                 - type: interface
                    name: p7p3
                    mtu: 9000
                    use_dhcp: false
                    defroute: false
                    nm_controlled: true
                    hotplug: true
    
                  - type: interface
                    name: p7p4
                    mtu: 9000
                    use_dhcp: false
                    defroute: false
                    nm_controlled: true
                    hotplug: true
    Copy to Clipboard Toggle word wrap
  7. 기본 필터 목록에 AggregateInstanceExtraSpecsFilter 값이 포함되어 있는지 확인합니다.

    NovaSchedulerDefaultFilters: ['AvailabilityZoneFilter','RamFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','AggregateInstanceExtraSpecsFilter']
    Copy to Clipboard Toggle word wrap
  8. 오버클라우드를 배포합니다.
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/host-config-and-reboot.yaml \
  -e ${TEMPLATES_HOME}/environments/services/neutron-sriov.yaml \
  -e ${CUSTOM_TEMPLATES}/network-environment.yaml
Copy to Clipboard Toggle word wrap

6.3. 하드웨어 오프로드 구성 (기술 프리뷰)

OVS(Open vSwitch) 하드웨어 오프로드는 기술 프리뷰이며 프로덕션 배포에는 권장되지 않습니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.

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

절차

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

    openstack overcloud roles generate -o roles_data.yaml Controller ComputeSriov
    Copy to Clipboard Toggle word wrap
  2. true 값을 사용하여 역할별 매개변수 아래에 OvsHwOffload 매개변수를 추가합니다.
  3. iptables/hybrid 방화벽 드라이버 구현을 사용하도록 neutron을 구성하려면 다음 행을 포함합니다. NeutronOVSFirewallDriver: iptables_hybrid. NeutronOVSFirewallDriver 에 대한 자세한 내용은 Advanced Overcloud Customization 가이드의 Open vSwitch 방화벽 사용을 참조하십시오.
  4. 환경에 맞게 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
      Copy to Clipboard Toggle word wrap
    • <vendor-id> 를 물리적 NIC의 벤더 ID로 바꿉니다.
    • <product-id> 를 NIC VF의 제품 ID로 바꿉니다.
    • <address> 를 물리적 NIC의 주소로 바꿉니다.

      NovaPCIPassthrough를 구성하는 방법에 대한 자세한 내용은 NovaPCIPassthrough 구성에 대한 지침을 참조하십시오.

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

      NovaSchedulerDefaultFilters: [\'RetryFilter',\'AvailabilityZoneFilter',\'ComputeFilter',\'ComputeCapabilitiesFilter',\'ImagePropertiesFilter',\'ServerGroupAntiAffinityFilter',\'ServerGroupAffinityFilter',\'PciPassthroughFilter',\'NUMATopologyFilter']
    Copy to Clipboard Toggle word wrap
  6. 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
    Copy to Clipboard Toggle word wrap
    참고
    • Open vSwitch 하드웨어 오프로드를 구성할 때 NeutronSriovNumVFs 매개변수를 사용하지 마십시오. 가상 함수 수는 os-net-config 에서 사용하는 네트워크 구성 파일에서 numvfs 매개 변수를 사용하여 지정됩니다. Red Hat은 업데이트 또는 재배포 중에 numvfs 설정 수정을 지원하지 않습니다.
    • 드라이버 제한으로 인해 VXLAN과 같은 터널 끝점이 트래픽을 전달하지 않으므로 Mellanox 네트워크 인터페이스를 nic-config 인터페이스 유형 ovs-vlan 으로 구성하지 마십시오.
  7. overcloud deploy 명령에 ovs-hw-offload.yaml 파일을 포함합니다.

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

6.3.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
    Copy to Clipboard Toggle word wrap
  2. OVS에서 오프로드가 활성화되어 있는지 확인합니다.

    # ovs-vsctl get Open_vSwitch . other_config:hw-offload
    “true”
    Copy to Clipboard Toggle word wrap
  3. NIC에서 하드웨어 오프로드가 활성화되었는지 확인합니다.

    # ethtool -k $NIC | grep tc-offload
    hw-tc-offload: on
    Copy to Clipboard Toggle word wrap

6.4. SR-IOV의 인스턴스 배포

호스트 집계를 사용하여 고성능 컴퓨팅 호스트를 분리하는 것이 좋습니다. 예약에 대한 호스트 집계 및 관련 플레이버 생성에 대한 자세한 내용은 호스트 집계 생성 을 참조하십시오.

참고

호스트 집계를 사용하여 고정 해제된 인스턴스와 CPU 고정 인스턴스를 분리해야 합니다. CPU 고정을 사용하지 않는 인스턴스는 CPU 고정을 사용하는 인스턴스의 반복 요구 사항을 준수하지 않습니다.

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

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

    # openstack flavor create <flavor> --ram <MB> --disk <GB> --vcpus <#>
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
  3. 포트를 만듭니다.

    • vnic-type direct 를 사용하여 SR-IOV VF(가상 기능) 포트를 생성합니다.

      # openstack port create --network net1 --vnic-type direct sriov_port
      Copy to Clipboard Toggle word wrap
    • 다음을 사용하여 하드웨어 오프로드가 있는 가상 기능을 생성합니다.

      # openstack port create --network net1 --vnic-type direct --binding-profile '{"capabilities": ["switchdev"]} sriov_hwoffload_port
      Copy to Clipboard Toggle word wrap
    • vnic-type direct-physical 을 사용하여 SR-IOV PF 포트를 생성합니다.

      # openstack port create --network net1 --vnic-type direct-physical sriov_port
      Copy to Clipboard Toggle word wrap
  4. 인스턴스 배포

    # openstack server create --flavor <flavor> --image <image> --nic port-id=<id> <instance name>
    Copy to Clipboard Toggle word wrap

6.5. 호스트 집계 생성

성능 향상을 위해 cpu 고정 및 hugepages를 사용하여 게스트를 배포합니다. 집계 메타데이터를 플레이버 메타데이터와 일치시켜 호스트 하위 집합에서 고성능 인스턴스를 예약할 수 있습니다.

절차
  1. 배포 전에 nova.conf 구성 파일의 parameter_defaults 아래에 있는 heat 매개변수 NovaSchedulerDefaultFilters 를 통해 AggregateInstanceExtraSpecsFilter 값 및 기타 필요한 필터를 구성할 수 있습니다.

      parameter_defaults:
        NovaSchedulerDefaultFilters: ['AggregateInstanceExtraSpecsFilter', 'RetryFilter','AvailabilityZoneFilter','RamFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','NUMATopologyFilter']
    Copy to Clipboard Toggle word wrap
    참고

    AggregateInstanceExtraSpecsFilter 구성을 종료 클러스터에 추가하려면 이 매개변수를 heat 템플릿에 추가하고 원래 배포 스크립트를 다시 실행할 수 있습니다.

  2. SR-IOV(단일 루트 I/O 가상화)에 대한 집계 그룹을 생성하고 관련 호스트를 추가합니다. 메타데이터를 정의합니다(예: 정의된 플레이버 메타데이터와 일치하는 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
    Copy to Clipboard Toggle word wrap
  3. 플레이버를 만듭니다.

    # openstack flavor create <flavor> --ram <MB> --disk <GB> --vcpus <#>
    Copy to Clipboard Toggle word wrap
  4. 추가 플레이버 속성을 설정합니다. 정의된 metadata sriov=true 는 SR-IOV 집계의 정의된 메타데이터와 일치합니다.

    openstack flavor set --property sriov=true --property hw:cpu_policy=dedicated --property hw:mem_page_size=1GB <flavor>
    Copy to Clipboard Toggle word wrap

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 자체의 하드웨어 리소스를 파티셔닝합니다. OVS-DPDK Poll 모드 드라이버(PMD)는 전용 코어가 필요한 DPDK 활성 루프를 실행합니다. 즉, CPU 및 Huge Page 목록은 OVS-DPDK 전용입니다.

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

참고

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

OVS-DPDK 성능은 NUMA 노드에 로컬 메모리 블록을 예약하는 경우에도 달라집니다. 메모리 및 CPU 고정에 사용하는 동일한 NUMA 노드와 연결된 NIC를 사용합니다. 또한 본딩의 두 인터페이스가 동일한 NUMA 노드의 NIC에서 있는지도 확인합니다.

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

중요

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

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

참고

derive_params_formulas.yaml 에서 사용자 환경에 맞게 수식을 수정할 수 있습니다.

derive_params.yaml 워크북은 지정된 구성 가능 역할의 모든 노드에 동일한 하드웨어 사양을 가정합니다. 워크플로우에서는 flavor-profile 연결 및 nova 배치 스케줄러를 사용하여 역할과 연결된 노드와 일치하며 역할과 일치하는 첫 번째 노드의 인트로스펙션 데이터를 사용합니다.

OpenStack 워크플로우에 대한 자세한 내용은 워크플로우 및 실행 문제 해결을 참조하십시오.

-p 또는 --plan-environment-file 옵션을 사용하여 사용자 정의 plan_environment.yaml 파일을 openstack overcloud deploy 명령에 추가할 수 있습니다. 사용자 지정 plan_environment.yaml 파일은 통합 문서 목록과 통합 문서에 전달할 모든 입력 값을 제공합니다. 트리거된 워크플로우는 파생 매개 변수를 오버클라우드 배포에 사용할 수 있는 사용자 정의 plan_environment.yaml 에 다시 병합합니다. 이러한 파생 매개변수 결과를 사용하여 오버클라우드 이미지를 준비할 수 있습니다.

배포에서 --plan-environment-file 옵션을 사용하는 방법에 대한 자세한 내용은 Plan Environment Metadata 를 참조하십시오.

7.3. 파생 OVS-DPDK 매개변수

derive_params.yaml 의 워크플로우는 ComputeNeutronOvsDpdk 서비스를 사용하는 일치하는 역할과 관련된 DPDK 매개변수를 파생합니다.

다음은 OVS-DPDK에 대해 워크플로우에서 자동으로 파생할 수 있는 매개변수 목록입니다.

  • IsolCpusList
  • KernelArgs
  • NovaReservedHostMemory
  • NovaVcpuPinSet
  • OvsDpdkCoreList
  • OvsDpdkSocketMemory
  • OvsPmdCoreList

메모리 슬롯 이름 형식이 다른 하드웨어 환경에서 일관되지 않으므로 OvsDpdkMemoryChannels 매개변수는 인트로스펙션 메모리 뱅크 데이터에서 파생될 수 없습니다.

대부분의 경우 OvsDpdkMemoryChannels 는 4(기본값)이어야 합니다. 하드웨어 설명서를 사용하여 소켓당 메모리 채널 수를 확인하고 이 값을 사용하여 기본값을 덮어씁니다.

자세한 내용은 8.1절. “워크플로우를 사용하여 DPDK 매개변수 파생” 을 참조하십시오.

7.4. 수동으로 계산된 OVS-DPDK 매개변수 개요

이 섹션에서는 OVS-DPDK(Data Plane Development Kit)에서 Open vSwitch가 director network_environment.yaml HEAT 템플릿 내에서 매개변수를 사용하여 최적의 성능을 위해 CPU 및 메모리를 구성하는 방법을 설명합니다. 이 정보를 사용하여 Compute 노드에서 하드웨어 지원을 평가하고 OVS-DPDK 배포를 최적화하기 위해 해당 하드웨어를 분할하는 것이 가장 좋은 방법입니다.

참고

derived_parameters.yaml 워크플로우를 사용하여 이러한 값을 자동으로 생성하는 경우 이러한 매개변수를 수동으로 계산할 필요가 없습니다. 워크플로우 및 파생 매개변수 개요를참조하십시오.

참고

CPU 코어를 할당할 때 항상 물리적 코어에 대해 CPU 형제 스레드(logical CPUs)를 함께 연결합니다.

NUMA 노드 토폴로지 검색을 참조하여 Compute 노드 의 CPU 및 NUMA 노드를 확인합니다. 이 정보를 사용하여 CPU 및 기타 매개변수를 매핑하여 호스트, 게스트 인스턴스, OVS-DPDK 프로세스가 필요합니다.

7.4.1. CPU 매개변수

OVS-DPDK에서는 다음 CPU 파티션 매개 변수를 사용합니다.

OvsPmdCoreList

DPDK 폴링 모드 드라이버(PMD)에 사용되는 CPU 코어를 제공합니다. DPDK 인터페이스의 로컬 NUMA 노드와 연결된 CPU 코어를 선택합니다. OvsPmdCoreList 는 Open vSwitch의 pmd-cpu-mask 값에 사용됩니다.

  • 형제 스레드를 함께 연결합니다.
  • OvsDpdkCoreList에서 모든 코어 제외
  • OvsDpdkCoreList 매개변수에 사용해야 하므로 두 NUMA 노드에서 첫 번째 물리적 코어의 논리 CPU(두 스레드 형제)를 할당하지 마십시오.
  • 성능은 이 PMD 코어 목록에 할당된 물리적 코어 수에 따라 달라집니다. DPDK NIC와 연결된 NUMA 노드에서 필요한 코어를 할당합니다.
  • DPDK NIC가 있는 NUMA 노드의 경우:

    • 성능 요구 사항에 따라 필요한 물리적 코어 수를 결정하고 각 물리 코어에 대한 모든 형제 스레드(logical CPUs)를 포함합니다.
  • DPDK NIC가 없는 NUMA 노드의 경우:

    • NUMA 노드의 첫 번째 물리적 코어를 제외하고 하나의 물리적 코어에 대한 형제 스레드(logical CPUs)를 할당합니다.
참고

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

NovaVcpuPinSet

CPU 고정의 코어를 설정합니다. 컴퓨팅 노드는 게스트 인스턴스에 이러한 코어를 사용합니다. NovaVcpuPinSetnova.conf 파일에서 vcpu_pin_set 값으로 사용됩니다.

  • OvsPmdCoreListOvsDpdkCoreList 에서 모든 코어를 제외합니다.
  • 나머지 모든 코어를 포함합니다.
  • 형제 스레드를 함께 연결합니다.
NovaComputeCpuSharedSet
에뮬레이터 스레드에 사용할 코어를 설정합니다. 그러면 nova.conf 매개변수 cpu_shared_set 의 값이 정의됩니다. 이 매개 변수의 권장 값은 OvsDpdkCoreList 에 설정된 값과 일치합니다.
IsolCpusList

호스트 프로세스와 분리된 CPU 코어 세트입니다. 이 매개변수는 tuned-profiles-cpu -partitioning 구성 요소의 cpu-partitioning-Price.conf 파일에서 isolated_cores 값으로 사용됩니다.

  • OvsPmdCoreListNovaVcpuPinSet 의 코어 목록을 일치시킵니다.
  • 형제 스레드를 함께 연결합니다.
OvsDpdkCoreList

handler 및 revalidator 스레드와 같은 비 데이터 경로 OVS-DPDK 프로세스에 대한 CPU 코어를 제공합니다. 이 매개변수는 다중 NUMA 노드 하드웨어의 전체 데이터 경로 성능에 영향을 미치지 않습니다. 이 매개변수는 Open vSwitch의 dpdk-lcore-mask 값에 사용되며 이러한 코어는 호스트와 공유됩니다.

  • 각 NUMA 노드에서 첫 번째 물리 코어(및 형제 스레드)를 할당합니다( NUMA 노드에 연결된 DPDK NIC가 없는 경우에도).
  • 이러한 코어는 OvsPmdCoreListNovaVcpuPinSet 의 코어 목록에서 서로 배타적이어야 합니다.
DerivePciWhitelistEnabled

VM에 대한 VF(가상 기능)를 예약하려면 NovaPCIPassthrough 매개변수를 사용하여 Nova로 전달된 VF 목록을 생성합니다. 목록에서 제외된 VM은 호스트에서 사용 가능한 상태로 유지됩니다.

Red Hat은 DerivePciWhitelistEnabled 값을 기본값인 true 에서 false 로 변경한 다음 NovaPCIPassthrough 매개변수에서 목록을 수동으로 구성하는 것이 좋습니다.

목록의 각 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
Copy to Clipboard Toggle word wrap

이 경우 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]"}
Copy to Clipboard Toggle word wrap

7.4.2. 메모리 매개변수

OVS-DPDK에서는 다음 메모리 매개변수를 사용합니다.

OvsDpdkMemoryChannels

NUMA 노드당 CPU에 메모리 채널을 매핑합니다. OvsDpdkMemoryChannels 매개변수는 Open vSwitch에서 other_config:dpdk-extra="-n <value>" 값으로 사용합니다.

  • dmidecode -t 메모리 또는 하드웨어 설명서를 사용하여 사용 가능한 메모리 채널 수를 확인합니다.
  • ls /sys/devices/system/node/node* -d 를 사용하여 NUMA 노드 수를 결정합니다.
  • NUMA 노드 수로 사용 가능한 메모리 채널 수를 나눕니다.
NovaReservedHostMemory

호스트의 작업에 대해 메모리를 MB 단위로 예약합니다. 이 값은 Compute 노드에서 nova.confreserved_host_memory_mb 값으로 사용됩니다.

  • 권장 정적 값은 4096MB입니다.
OvsDpdkSocketMemory

NUMA 노드당 hugepage 풀에서 사전 할당할 메모리 양을 MB 단위로 지정합니다. 이 값은 Open vSwitch에서 other_config:dpdk-socket-mem 값으로 사용됩니다.

  • 쉼표로 구분된 목록으로 을 제공합니다. NUMA 노드의 각 NIC의 MTU 값에서 OvsDpdkSocketMemory 값을 계산합니다.
  • DPDK NIC가 없는 NUMA 노드의 경우 1024MB(1GB)의 정적 권장 사항을 사용하십시오.
  • 다음 방정식은 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/messages메모리 풀 오류 메시지를 생성하지 못할 수 있습니다. 인스턴스 시작 시 발생하는 경우 이 오류 메시지는 무시해도 됩니다. 이 메시지를 방지하려면 1500 MTU에 대한 추가 OvsDpdkSocketMemory 양을 OvsDpdkSocketMemory 계산에 추가합니다.

샘플 계산 - MTU 2000 및 MTU 9000

DPDK NIC dpdk0 및 dpdk1은 동일한 NUMA 노드 0에 있으며 MTUs 9000 및 2000으로 구성됩니다. 필요한 메모리를 파생하기 위한 샘플 계산은 다음과 같습니다.

  1. MTU 값을 가장 가까운 1024바이트로 반올림합니다.

    The MTU value of 9000 becomes 9216 bytes.
    The MTU value of 2000 becomes 2048 bytes.
    Copy to Clipboard Toggle word wrap
  2. 반올림된 바이트 값에 따라 각 MTU 값에 필요한 메모리를 계산합니다.

    Memory required for 9000 MTU = (9216 + 800) * (4096*64) = 2625634304
    Memory required for 2000 MTU = (2048 + 800) * (4096*64) = 746586112
    Copy to Clipboard Toggle word wrap
  3. 필요한 결합된 총 메모리(바이트)를 계산합니다.

    2625634304 + 746586112 + 536870912 = 3909091328 bytes.
    Copy to Clipboard Toggle word wrap

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

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

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

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

        OvsDpdkSocketMemory: “4096,1024”
    Copy to Clipboard Toggle word wrap

샘플 계산 - MTU 2000

DPDK NIC dpdk0 및 dpdk1은 동일한 NUMA 노드 0에 있으며 각각 MTUs 2000 및 2000으로 구성됩니다. 필요한 메모리를 파생하기 위한 샘플 계산은 다음과 같습니다.

  1. MTU 값을 가장 가까운 1024바이트로 반올림합니다.

    The MTU value of 2000 becomes 2048 bytes.
    Copy to Clipboard Toggle word wrap
  2. 반올림된 바이트 값에 따라 각 MTU 값에 필요한 메모리를 계산합니다.

    Memory required for 2000 MTU = (2048 + 800) * (4096*64) = 746586112
    Copy to Clipboard Toggle word wrap
  3. 필요한 결합된 총 메모리(바이트)를 계산합니다.

    746586112 + 536870912 = 1283457024 bytes.
    Copy to Clipboard Toggle word wrap

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

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

    1283457024 / (1024*1024) = 1224 MB.
    Copy to Clipboard Toggle word wrap
  5. 이 값을 가장 가까운 1024로 반올림합니다.

    1224 MB rounds up to 2048 MB.
    Copy to Clipboard Toggle word wrap
  6. 이 값을 사용하여 OvsDpdkSocketMemory 를 설정합니다.

        OvsDpdkSocketMemory: “2048,1024”
    Copy to Clipboard Toggle word wrap

7.4.3. 네트워킹 매개변수

OvsDpdkDriverType
DPDK에서 사용하는 드라이버 유형을 설정합니다. vfio-pci 의 기본값을 사용합니다.
NeutronDatapathType
OVS 브릿지의 datapath 유형. DPDK는 netdev 의 기본값을 사용합니다.
NeutronVhostuserSocketDir
OVS의 vhost-user 소켓 디렉터리를 설정합니다. vhost 클라이언트 모드에 /var/lib/vhost_sockets 를 사용합니다.

7.4.4. 기타 매개변수

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

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

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

    lshw -class processor | grep pdpe1gb
    Copy to Clipboard Toggle word wrap
  • Huge Page 수: 사용 가능한 대규모 페이지 수를 설정합니다. 이 값은 사용 가능한 호스트 메모리 크기에 따라 다릅니다. 사용 가능한 메모리 대부분을 사용하십시오( NovaReservedHostMemory제외). 컴퓨팅 노드와 연결된 OpenStack 플레이버 내에서 대규모 페이지 수 값을 구성해야 합니다.
  • iommu: Intel CPU의 경우 "intel_iommu=on iommu=pt"를추가합니다.
  • isolcpus: CPU 코어를 튜닝할 수 있도록 설정합니다. 이 값은 IsolCpusList 와 일치합니다.

7.4.5. 인스턴스 추가 사양

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

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

이 매개 변수의 값을 표준 접미사가 있는 특정 값의 유효한 문자열로 설정합니다(예: 4KB,8MB 또는 1GB ). 1GB 를 사용하여 hugepagesz 부팅 매개변수와 일치시킵니다. 가상 머신에 사용할 수 있는 대규모 페이지 수는 부팅 매개 변수입니다. OvsDpdkSocketMemory. 기타 유효한 매개변수 값에는 다음이 포함됩니다.

  • small(기본값) - 가장 작은 페이지 크기가 사용됩니다.
  • large - 큰 페이지 크기만 사용합니다. (2MB 또는 x86 아키텍처에서 1GB)
  • 모든 - 컴퓨팅 드라이버는 큰 페이지를 시도할 수 있지만, 사용할 수 없는 경우 기본값은 small입니다.
hw:emulator_threads_policy
에뮬레이터 스레드가 heat 매개변수 NovaComputeCpuSharedSet 에서 식별한 CPU에 고정되도록 이 매개 변수의 값을 공유 하도록 설정합니다. 폴링 모드 드라이버(PMD) 또는 실시간 처리에 사용 중인 vCPU에서 에뮬레이터 스레드가 실행 중인 경우 패킷 손실 또는 누락 기한이 발생할 수 있습니다.

7.5. OVS-DPDK 배포의 두 가지 NUMA 노드 예

이 샘플 Compute 노드에는 다음과 같이 두 개의 NUMA 노드가 포함됩니다.

  • NUMA 0에는 코어 0이 0-7입니다. 형제 스레드 쌍은 (0,1), (2,3), (4,5) 및 (6,7)
  • NUMA 1에는 코어 8-15가 있습니다. 형제 스레드 쌍은 (8,9), (10,11), (12,13), 및 (14,15)입니다.
  • 각 NUMA 노드는 물리적 NIC( NUMA 0의 NIC1 및 NUMA 1의 NIC2)에 연결됩니다.
참고

비 데이터 경로 DPDK 프로세스(OvsDpdkCoreList)의 경우 각 NUMA 노드 (0,1 및 89)에서 첫 번째 물리적 코어( 스레드 쌍 모두)를 예약합니다.

이 예에서는 1500 MTU 설정도 가정하므로 모든 사용 사례에 대해 OvsDpdkSocketMemory 가 동일합니다.

OvsDpdkSocketMemory: “1024,1024”
Copy to Clipboard Toggle word wrap

PMD 용 물리 코어가 있는 DPDK용 NIC 1

이 사용 사례에서는 PMD에 대해 NUMA 0에 하나의 물리적 코어를 할당합니다. 해당 NUMA 노드의 NIC에 DPDK가 활성화되어 있지 않은 경우에도 NUMA 1에서 하나의 물리적 코어를 할당해야 합니다. 나머지 코어( OvsDpdkCoreList용으로 예약되지 않음)가 게스트 인스턴스에 할당됩니다. 결과 매개변수 설정은 다음과 같습니다.

OvsPmdCoreList: “2,3,10,11”
NovaVcpuPinSet: “4,5,6,7,12,13,14,15”
Copy to Clipboard Toggle word wrap

PMD 용 물리적 코어 두 개가 있는 DPDK용 NIC 1

이 사용 사례에서는 PMD에 NUMA 0에 두 개의 물리적 코어를 할당합니다. 해당 NUMA 노드의 NIC에 DPDK가 활성화되어 있지 않은 경우에도 NUMA 1에서 하나의 물리적 코어를 할당해야 합니다. 나머지 코어( OvsDpdkCoreList용으로 예약되지 않음)가 게스트 인스턴스에 할당됩니다. 결과 매개변수 설정은 다음과 같습니다.

OvsPmdCoreList: “2,3,4,5,10,11”
NovaVcpuPinSet: “6,7,12,13,14,15”
Copy to Clipboard Toggle word wrap

PMD 용 물리 코어가 한 개 있는 DPDK용 NIC 2

이 사용 사례에서는 PMD에 NUMA 1개의 물리적 코어를 할당합니다. 해당 NUMA 노드의 NIC에 DPDK가 활성화되어 있지 않은 경우에도 NUMA 0에서 하나의 물리적 코어를 할당해야 합니다. 나머지 코어( OvsDpdkCoreList용으로 예약되지 않음)가 게스트 인스턴스에 할당됩니다. 결과 매개변수 설정은 다음과 같습니다.

OvsPmdCoreList: “2,3,10,11”
NovaVcpuPinSet: “4,5,6,7,12,13,14,15”
Copy to Clipboard Toggle word wrap

PMD용 물리적 코어 두 개가 있는 DPDK용 NIC 2

이 사용 사례에서는 PMD에 NUMA 1에 두 개의 물리적 코어를 할당합니다. 해당 NUMA 노드의 NIC에 DPDK가 활성화되어 있지 않은 경우에도 NUMA 0에서 하나의 물리적 코어를 할당해야 합니다. 나머지 코어( OvsDpdkCoreList용으로 예약되지 않음)가 게스트 인스턴스에 할당됩니다. 결과 매개변수 설정은 다음과 같습니다.

OvsPmdCoreList: “2,3,10,11,12,13”
NovaVcpuPinSet: “4,5,6,7,14,15”
Copy to Clipboard Toggle word wrap

DPDK용 NIC 1 및 NIC2에는 PMD 용 물리 코어 두 개가 있습니다.

이 사용 사례에서는 PMD에 대해 각 NUMA 노드에 두 개의 물리적 코어를 할당합니다. 나머지 코어( OvsDpdkCoreList용으로 예약되지 않음)가 게스트 인스턴스에 할당됩니다. 결과 매개변수 설정은 다음과 같습니다.

OvsPmdCoreList: “2,3,4,5,10,11,12,13”
NovaVcpuPinSet: “6,7,14,15”
Copy to Clipboard Toggle word wrap
참고

NUMA 노드당 하나의 물리적 코어를 사용하는 것이 좋습니다.

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의 토폴로지를 보여줍니다. 1개 또는 10Gbps NIC와 Director 노드가 있는 Compute 및 Controller 노드로 구성됩니다.

8장. OVS-DPDK 배포 구성

이 섹션에서는 Red Hat OpenStack Platform 환경 내에서 OVS-DPDK(Open vSwitch)를 사용하여 DPDK를 배포합니다. 오버클라우드는 일반적으로 컨트롤러 노드, 컴퓨팅 노드 및 다른 스토리지 노드 유형과 같은 사전 정의된 역할의 노드로 구성됩니다. 이러한 각 기본 역할에는 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)를 포함하여 Bare Metal 인트로스펙션이 활성화되어 있어야 합니다. 하드웨어 검사 추가는 기본적으로 활성화되어 있습니다. 노드 하드웨어 검사를 참조하십시오.

DPDK에 대한 워크플로우 및 입력 매개 변수 정의

다음은 OVS-DPDK 워크플로우에 제공할 수 있는 입력 매개 변수입니다.

num_phy_cores_per_numa_node_for_pmd
이 input 매개변수는 DPDK NIC와 연결된 NUMA 노드에 필요한 최소 코어 수를 지정합니다. DPDK NIC와 연결되지 않은 다른 NUMA 노드에 대해 하나의 물리적 코어가 할당됩니다. 이 매개 변수는 1로 설정해야 합니다.
huge_page_allocation_percentage
이 input 매개변수는 대규모 페이지로 구성할 수 있는 총 메모리( NovaReservedHostMemory제외)의 필요한 백분율을 지정합니다. KernelArgs 매개변수는 지정된 huge_page_allocation_percentage 를 기반으로 계산된 대규모 페이지를 사용하여 파생됩니다. 이 매개 변수는 50으로 설정해야 합니다.

워크플로우는 베어 메탈 인트로스펙션 세부 정보와 함께 이러한 입력 매개변수를 사용하여 적절한 DPDK 매개변수 값을 계산합니다.

DPDK에 대한 워크플로우 및 입력 매개변수를 정의하려면 다음을 수행합니다.

  1. /usr/share/openstack-tripleo-heat-templates/plan-environment-derived-params.yaml 파일을 로컬 디렉터리에 복사하고 사용자 환경에 맞게 입력 매개변수를 설정합니다.

      workflow_parameters:
        tripleo.derive_params.v1.derive_parameters:
          EmptyEmpty# DPDK Parameters Empty#
          # Specifices 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
    Copy to Clipboard Toggle word wrap
  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
      Copy to Clipboard Toggle word wrap

이 명령의 출력에는 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-7,17-23,9-15,25-31
 KernelArgs: default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=1-7,17-23,9-15,25-31
 NovaReservedHostMemory: 4096
 NovaVcpuPinSet: 2-7,18-23,10-15,26-31
 OvsDpdkCoreList: 0,16,8,24
 OvsDpdkMemoryChannels: 4
 OvsDpdkSocketMemory: 1024,1024
 OvsPmdCoreList: 1,17,9,25
Copy to Clipboard Toggle word wrap
참고

OvsDpdkMemoryChannels 매개변수는 인트로스펙션 세부 정보에서 파생될 수 없습니다. 대부분의 경우 이 값은 4여야 합니다.

Derived Parameters를 사용하여 오버클라우드 배포

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

  1. plan-environment.yaml 에서 network-environment.yaml 파일에 파생된 매개변수를 복사합니다.

      # DPDK compute node.
      ComputeOvsDpdkParameters:
        KernelArgs: default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=1-7,17-23,9-15,25-31
        TunedProfileName: "cpu-partitioning"
        IsolCpusList: "1-7,17-23,9-15,25-31"
        NovaVcpuPinSet: ['2-7,18-23,10-15,26-31']
        NovaReservedHostMemory: 4096
        OvsDpdkSocketMemory: "1024,1024"
        OvsDpdkMemoryChannels: "4"
        OvsDpdkCoreList: "0,16,8,24"
        OvsPmdCoreList: "1,17,9,25"
    Copy to Clipboard Toggle word wrap
    참고

    이러한 매개변수는 ComputeOvsDpdk 역할에만 적용되며 동일한 클러스터에 존재할 수 있는 Compute 또는 ComputeSriov 를 비롯한 다른 역할에는 적용되지 않습니다. 이러한 매개변수를 전역적으로 적용할 수 있지만 전역 매개변수는 역할별 매개변수를 통해 덮어씁니다.

  2. 역할 파일 및 해당 환경과 관련된 모든 환경 파일을 사용하여 오버클라우드를 배포합니다. 자세한 내용은 Overcloud 배포를 참조하십시오.

8.2. OVS-DPDK 토폴로지

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

이 이미지는 컨트롤 플레인과 데이터 플레인에 대해 두 개의 포트가 포함된 OVS-DPDK(Data Plane Development Kit) 토폴로지가 있는 샘플 Open vSwitch를 보여줍니다.

OVS-DPDK 구성은 다음 작업으로 구성됩니다.

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

이 가이드에서는 CPU 할당, 메모리 할당 및 토폴로지 및 사용 사례와 다를 수 있는 NIC 구성에 대한 예를 제공합니다. 하드웨어 및 구성 옵션을 이해하려면 Network Functions Virtualization 제품 가이드2장. 하드웨어 요구 사항 를 참조하십시오.

절차를 시작하기 전에 최소한 다음 사항이 있는지 확인하십시오.

참고

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

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

Red Hat OpenStack Platform은 OVS-DPDK(Data Plane Development Kit)를 사용하여 Open vSwitch에 대한 점보 프레임을 지원합니다. 점보 프레임에 대한 최대 전송 단위(MTU) 값을 설정하려면 다음을 수행해야 합니다.

  • network-environment.yaml 파일에서 네트워킹의 글로벌 MTU 값을 설정합니다.
  • compute.yaml 파일에 물리적 DPDK 포트 MTU 값을 설정합니다. 이 값은 vhost 사용자 인터페이스에서도 사용됩니다.
  • Compute 노드의 게스트 인스턴스 내에서 MTU 값을 설정하여 구성의 끝에 해당하는 MTU 값이 있도록 합니다.
참고

VXLAN 패킷에는 헤더에 50바이트가 추가됩니다. 이러한 추가 헤더 바이트에 따라 MTU 요구 사항을 계산합니다. 예를 들어 9000의 MTU 값은 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
    Copy to Clipboard Toggle word wrap
    참고

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

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

      -
        type: ovs_bridge
        name: br-link0
        use_dhcp: false
        members:
          -
            type: interface
            name: nic3
            mtu: 9000
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap

8.4. 보안 그룹의 방화벽 구성

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

NeutronOVSFirewallDriver 매개변수를 openvswitch 로 설정하여 controlPlane 인터페이스를 구성할 수 있습니다. 이렇게 하면 OpenStack Networking이 흐름 기반 OVS 방화벽 드라이버를 사용하도록 설정됩니다. 이는 parameter_defaultsnetwork-environment.yaml 파일에 설정되어 있습니다.

예제:

parameter_defaults:
  NeutronOVSFirewallDriver: openvswitch
Copy to Clipboard Toggle word wrap

OVS 방화벽 드라이버를 사용하는 경우 데이터 플레인 인터페이스에 대해 비활성화하는 것이 중요합니다. 이 작업은 openstack port set 명령을 사용하여 수행할 수 있습니다.

예제:

openstack port set --no-security-group  --disable-port-security ${PORT}
Copy to Clipboard Toggle word wrap

8.5. OVS-DPDK 인터페이스의 다중 대기열 설정

Compute 노드에서 OVS-DPDK(Data Plane Development Kit)를 사용하여 Open vSwitch에서 인터페이스에 대해 동일한 수의 큐를 설정하려면 다음과 같이 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
Copy to Clipboard Toggle word wrap

8.6. 오버클라우드 배포

  1. DPDK 컴퓨팅 역할의 매개변수가 network-environment.yaml 에 채워져 있는지 확인합니다. 필요한 경우 파생 OVS-DPDK 매개변수에서 복사할 수 있습니다.

     # DPDK compute node.
      ComputeOvsDpdkParameters:
        KernelArgs: default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=1-7,17-23,9-15,25-31
        TunedProfileName: "cpu-partitioning"
        IsolCpusList: "1-7,17-23,9-15,25-31"
        NovaVcpuPinSet: ['2-7,18-23,10-15,26-31']
        NovaReservedHostMemory: 4096
        OvsDpdkSocketMemory: "1024,1024"
        OvsDpdkMemoryChannels: "4"
        OvsDpdkCoreList: "0,16,8,24"
        OvsPmdCoreList: "1,17,9,25"
    Copy to Clipboard Toggle word wrap
  2. openstack overcloud deploy 명령을 사용하여 오버클라우드를 배포합니다.

    • 역할 파일 및 해당 환경과 관련된 모든 환경 파일을 포함합니다.
    • /usr/share/openstack-tripleo-heat-templates/environmentshost-config-and-reboot.yaml 파일을 배포 스크립트에 포함하여 KernelArgsTunedProfile 매개변수를 적용합니다.

      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/host-config-and-reboot.yaml \
      -e ${CUSTOM_TEMPLATES}/network-environment.yaml \
      -e ${CUSTOM_TEMPLATES}/controller.yaml
      -e ${CUSTOM_TEMPLATES}/computeovsdpdk.yaml \
      ...
      Copy to Clipboard Toggle word wrap

8.7. 알려진 제한 사항

NFV 사용 사례에 대해 Red Hat OpenStack Platform을 사용하여 OVS-DPDK를 구성할 때 몇 가지 제한 사항이 있습니다.

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

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

NFV를 사용하여 Red Hat OpenStack Platform 배포용 OVS-DPDK(Data Plane Development Kit)를 사용하여 Open vSwitch 구성을 완료한 후 다음 단계를 통해 플레이버를 생성하고 인스턴스를 배포할 수 있습니다.

  1. 집계 그룹을 생성하고 OVS-DPDK에 관련 호스트를 추가합니다. 정의된 플레이버 메타데이터와 일치하는 메타데이터(예: dpdk=true )를 정의합니다.

     # openstack aggregate create dpdk_group
     # openstack aggregate add host dpdk_group [compute-host]
     # openstack aggregate set --property dpdk=true dpdk_group
    Copy to Clipboard Toggle word wrap
    참고

    호스트 집계를 사용하여 고정 해제된 인스턴스와 CPU 고정 인스턴스를 분리해야 합니다. CPU 고정을 사용하지 않는 인스턴스는 CPU 고정을 사용하는 인스턴스의 반복 요구 사항을 준수하지 않습니다.

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

    # openstack flavor create <flavor> --ram <MB> --disk <GB> --vcpus <#>
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap

    성능 향상을 위한 에뮬레이터 스레드 정책에 대한 자세한 내용은 다음을 참조하십시오. 전용 물리적 CPU에서 실행되도록 read Threads를 구성합니다.

  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
    Copy to Clipboard Toggle word wrap
  5. 선택 사항: OVS-DPDK와 함께 multiqueue를 사용하는 경우 인스턴스를 만드는 데 사용할 이미지의 hw_vif_multiqueue_enabled 속성을 설정합니다.

    # openstack image set --property hw_vif_multiqueue_enabled=true <image>
    Copy to Clipboard Toggle word wrap
  6. 인스턴스를 배포합니다.

    # openstack server create --flavor <flavor> --image <glance image> --nic net-id=<network ID> <server_name>
    Copy to Clipboard Toggle word wrap

8.9. 구성 문제 해결

이 섹션에서는 DPDK-OVS(Data Plane Development Kit) 구성을 사용하여 Open vSwitch의 문제를 해결하는 단계를 설명합니다.

  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
    Copy to Clipboard Toggle word wrap
  2. docker 컨테이너 neutron_ovs_agent 가 자동으로 시작되도록 구성되어 있는지 확인합니다.

    # docker inspect neutron_ovs_agent | grep -A1 RestartPolicy
                "RestartPolicy": {
                    "Name": "always",
    Copy to Clipboard Toggle word wrap

    컨테이너 시작에 문제가 있는 경우 관련 메시지를 볼 수 있습니다.

    # less /var/log/containers/neutron/openvswitch-agent.log
    Copy to Clipboard Toggle word wrap
  3. ovs-dpdk 의 PMD CPU 마스크가 CPU에 고정되었는지 확인합니다. HT의 경우 형제 CPU를 사용합니다.

    예를 들어, CPU4 를 사용하십시오.

    # cat /sys/devices/system/cpu/cpu4/topology/thread_siblings_list
    4,20
    Copy to Clipboard Toggle word wrap

    CPU 4 및 20을 사용합니다.

    # ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x100010
    Copy to Clipboard Toggle word wrap

    상태를 표시합니다.

    # 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
    Copy to Clipboard Toggle word wrap

9장. Red Hat OpenStack Platform 환경 튜닝

9.1. 신뢰할 수 있는 가상 함수

VF(가상 기능)를 신뢰하도록 물리적 기능(PF)을 구성하여 VF(가상 기능)가 일부 권한이 있는 작업을 수행할 수 있습니다. 예를 들어 이 구성을 사용하여 VF에서 무차별 모드를 활성화하거나 하드웨어 주소를 변경할 수 있습니다.

9.1.1. 신뢰 제공

사전 요구 사항
  • 운영 중인 설치 Red Hat OpenStack Platform director
절차

가상 기능에 대한 물리적 기능 신뢰를 활성화하는 데 필요한 매개 변수를 사용하여 오버클라우드를 배포하려면 다음 단계를 완료합니다.

  1. 논리 네트워크 이름과 물리적 인터페이스 간의 연결을 위해 parameter_defaults 섹션에 NeutronPhysicalDevMappings 매개변수를 추가합니다.

    parameter_defaults:
      NeutronPhysicalDevMappings:
        - sriov2:p5p2
    Copy to Clipboard Toggle word wrap
  2. SR-IOV와 관련된 기존 매개변수에 새 속성 "trusted"를 추가합니다.

    parameter_defaults:
      NeutronPhysicalDevMappings:
        - sriov2:p5p2
      NeutronSriovNumVFs: ["p5p2:8"]
      NovaPCIPassthrough:
        - vendor_id: "8086"
          product_id: "1572"
          physical_network: "sriov2"
          trusted: "true"
    Copy to Clipboard Toggle word wrap
    참고

    "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'}
      }
    Copy to Clipboard Toggle word wrap

9.1.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
    Copy to Clipboard Toggle word wrap
  2. 서브넷을 만듭니다.

    openstack subnet create --network trusted_vf_network \
      --ip-version 4 --subnet-range 192.168.111.0/24 --no-dhcp \
     subnet-trusted_vf_network
    Copy to Clipboard Toggle word wrap
  3. 포트를 만들고, vnic-type 옵션을 직접 설정하고, binding-profile 옵션을 true로 설정합니다.

    openstack port create --network sriov111 \
    --vnic-type direct --binding-profile trusted=true \
    sriov111_port_trusted
    Copy to Clipboard Toggle word wrap
  4. 이전에 만든 신뢰할 수 있는 포트에 인스턴스 바인딩을 만듭니다.

    openstack server create --image rhel --flavor dpdk  --network internal --port trusted_vf_network_port_trusted --config-drive True --wait rhel-dpdk-sriov_trusted
    Copy to Clipboard Toggle word wrap

하이퍼 바이저에서 신뢰할 수 있는 가상 기능 구성 확인

새로 생성된 인스턴스를 호스팅하는 컴퓨팅 노드에서 다음 명령을 실행합니다.

# 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
Copy to Clipboard Toggle word wrap

ip link 명령의 출력을 보고 가상 함수의 신뢰 상태가 신뢰할 수 있는지 확인합니다. 예제 출력에는 두 개의 포트가 포함된 환경에 대한 세부 정보가 포함되어 있습니다. vf 6 에는 에 대한 텍스트 신뢰가 포함되어 있습니다.

9.2. RX/TX 큐 크기 구성

다음과 같은 여러 가지 이유로 초당 3.5만 패킷을 초과하는 높은 패킷 속도로 패킷 손실이 발생할 수 있습니다.

  • 네트워크 중단
  • 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
    Copy to Clipboard Toggle word wrap
테스트
  • nova.conf 파일에서 RX 큐 크기 및 TX 큐 크기에 대한 값을 확인할 수 있습니다.

    [libvirt]
    rx_queue_size=1024
    tx_queue_size=1024
    Copy to Clipboard Toggle word wrap
  • 컴퓨팅 호스트의 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>
    Copy to Clipboard Toggle word wrap

    RX 큐 크기 및 TX 큐 크기에 대한 값을 확인하려면 KVM 호스트에서 다음 명령을 사용합니다.

    $ virsh dumpxml <vm name> | grep queue_size
    Copy to Clipboard Toggle word wrap
  • 성능 향상(예: 3.8MPps/코어 0 프레임 손실)을 확인할 수 있습니다.

9.3. NFV 워크로드에 RT-KVM 활성화

이 섹션에서는 Red Hat OpenStack Platform용 Red Hat Enterprise Linux 7.5 실시간 KVM(RT-KVM)을 설치하고 구성하는 단계를 설명합니다. Red Hat OpenStack Platform은 Red Hat Enterprise Linux for Real-Time과 추가 RT-KVM 커널 모듈을 프로비저닝하고 컴퓨팅 노드의 자동 구성을 프로비저닝하는 새로운 실시간 컴퓨팅 노드 역할을 실시간 기능을 제공합니다.

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

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

RT-KVM의 rhel-7-server-nfv-rpms 리포지토리를 활성화하는 방법에 대한 자세한 내용은 언더클라우드 등록 및 업데이트를 참조하십시오.

참고

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

실시간 이미지 빌드

다음 단계를 사용하여 실시간 컴퓨팅 노드의 오버클라우드 이미지를 빌드합니다.

  1. director 명령행 툴을 사용하도록 stack 사용자를 초기화하려면 다음 명령을 실행합니다.

    [stack@undercloud-0 ~]$ source ~/stackrc
    Copy to Clipboard Toggle word wrap
  2. virt-customize 툴을 얻으려면 언더클라우드에 libguestfs-tools 패키지를 설치합니다.

    (undercloud) [stack@undercloud-0 ~]$ sudo yum install libguestfs-tools
    Copy to Clipboard Toggle word wrap
    중요

    언더클라우드에서 libguestfs-tools 패키지를 설치하는 경우 iscsid.socket 을 비활성화하여 언더클라우드에서 tripleo_iscsid 서비스와의 포트 충돌을 방지합니다.

    $ sudo systemctl disable --now iscsid.socket
    Copy to Clipboard Toggle word wrap
  3. 이미지를 추출합니다.

    (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
    Copy to Clipboard Toggle word wrap
  4. 기본 이미지를 복사합니다.

    (undercloud) [stack@undercloud-0 ~]$ cp overcloud-full.qcow2 overcloud-realtime-compute.qcow2
    Copy to Clipboard Toggle word wrap
  5. 사용자 지정과 관련된 Red Hat 리포지토리를 활성화하려면 이미지를 등록합니다. [username][password] 를 다음 예에서 유효한 자격 증명으로 교체합니다.

    virt-customize -a overcloud-realtime-compute.qcow2 --run-command \
    'subscription-manager register --username=[username] --password=[password]'
    Copy to Clipboard Toggle word wrap
    참고

    명령 프롬프트에서 언제든지 기록 파일에서 자격 증명을 제거합니다. history -d 명령과 행 번호를 사용하여 기록에서 개별 행을 삭제할 수 있습니다.

  6. 계정 서브스크립션에서 풀 ID 목록을 찾아 적절한 풀 ID를 이미지에 연결합니다.

    sudo subscription-manager list --all --available | less
    ...
    virt-customize -a overcloud-realtime-compute.qcow2 --run-command \
    'subscription-manager attach --pool [pool-ID]'
    Copy to Clipboard Toggle word wrap
  7. NFV를 사용하여 Red Hat OpenStack Platform에 필요한 리포지토리를 추가합니다.

    virt-customize -a overcloud-realtime-compute.qcow2 --run-command \
    'subscription-manager repos --enable=rhel-7-server-nfv-rpms \
    --enable=rhel-7-server-rpms \
    --enable=rhel-7-server-rh-common-rpms \
    --enable=rhel-7-server-extras-rpms \
    --enable=rhel-7-server-openstack-13-rpms'
    Copy to Clipboard Toggle word wrap
  8. 이미지에서 실시간 기능을 구성하는 스크립트를 생성합니다.

    (undercloud) [stack@undercloud-0 ~]$ cat <<'EOF' > rt.sh
      #!/bin/bash
    
      set -eux
    
      yum -v -y --setopt=protected_packages= erase kernel.$(uname -m)
      yum -v -y install kernel-rt kernel-rt-kvm tuned-profiles-nfv-host
      EOF
    Copy to Clipboard Toggle word wrap
  9. 스크립트를 실행하여 RT 이미지를 구성합니다.

    (undercloud) [stack@undercloud-0 ~]$ virt-customize -a overcloud-realtime-compute.qcow2 -v --run rt.sh 2>&1 | tee virt-customize.log
    Copy to Clipboard Toggle word wrap
    참고

    rt.sh 스크립트 출력에 다음 오류가 표시될 수 있습니다. grubby fatal error: unable to find a suitable template. 이 오류는 무시해도 됩니다.

  10. 이전 명령에서 만든 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
    Copy to Clipboard Toggle word wrap
  11. SELinux의 레이블을 다시 지정합니다.

    (undercloud) [stack@undercloud-0 ~]$ virt-customize -a overcloud-realtime-compute.qcow2 --selinux-relabel
    Copy to Clipboard Toggle word wrap
  12. vmlinuz 및 initrd를 추출합니다.

    참고

    vmlinuz 및 initramfs 파일 이름의 소프트웨어 버전은 커널 버전에 따라 다릅니다. 파일 이름에 관련 소프트웨어 버전을 사용합니다(예: image/boot/vmlinuz-3.10.0-862.rt56.804.el7x86_64.el7x86_64 ).

    (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-*.x86_64 ./overcloud-realtime-compute.vmlinuz
    (undercloud) [stack@undercloud-0 ~]$ cp image/boot/initramfs-*.x86_64.img ./overcloud-realtime-compute.initrd
    (undercloud) [stack@undercloud-0 ~]$ guestunmount image
    Copy to Clipboard Toggle word wrap
  13. 이미지를 업로드합니다.

    (undercloud) [stack@undercloud-0 ~]$ openstack overcloud image upload --update-existing --os-image-name overcloud-realtime-compute.qcow2
    Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

참고

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

9.3.2.1. ComputeOvsDpdk 구성 가능 역할 생성

ComputeOvsDpdkRT 역할을 사용하여 실시간 컴퓨팅 이미지를 사용하는 컴퓨팅 노드를 지정합니다.

ComputeOvsDpdkRT 역할에 대한 roles_data.yaml 을 생성합니다.

# (undercloud) [stack@undercloud-0 ~]$ openstack overcloud roles generate -o roles_data.yaml Controller ComputeOvsDpdkRT
Copy to Clipboard Toggle word wrap
9.3.2.2. OVS-DPDK 매개변수 구성
중요

적절한 값이 없는 DPDK(Data Plane Development Kit)를 배포하려고 하면 배포가 실패하거나 불안정한 배포가 발생할 수 있습니다. OVS-DPDK에 대해 OpenStack 네트워크를 최적화하려면 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
    Copy to Clipboard Toggle word wrap
  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-7,17-23,9-15,25-31"
        NovaVcpuPinSet: ['2-7,18-23,10-15,26-31']
        NovaReservedHostMemory: 4096
        OvsDpdkSocketMemory: "1024,1024"
        OvsDpdkMemoryChannels: "4"
        OvsDpdkCoreList: "0,16,8,24"
        OvsPmdCoreList: "1,17,9,25"
        VhostuserSocketGroup: "hugetlbfs"
      ComputeOvsDpdkRTImage: "overcloud-realtime-compute"
    Copy to Clipboard Toggle word wrap
9.3.2.3. 컨테이너 이미지 준비

컨테이너 이미지를 준비합니다.

(undercloud) [stack@undercloud-0 ~]$ openstack overcloud container image prepare --namespace=192.0.40.1:8787/rhosp13 --env-file=/home/stack/ospd-13-vlan-dpdk/docker-images.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-ovs-dpdk.yaml -e /home/stack/ospd-13-vlan-dpdk/network-environment.yaml --roles-file /home/stack/ospd-13-vlan-dpdk/roles_data.yaml --prefix=openstack- --tag=2018-03-29.1 --set ceph_namespace=registry.redhat.io/rhceph --set ceph_image=rhceph-3-rhel7 --set ceph_tag=latest
Copy to Clipboard Toggle word wrap
9.3.2.4. 오버클라우드 배포

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

(undercloud) [stack@undercloud-0 ~]$ openstack overcloud deploy \
--templates \
-r /home/stack/ospd-13-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/host-config-and-reboot.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-ovs-dpdk.yaml \
-e /home/stack/ospd-13-vxlan-dpdk-data-bonding-rt-hybrid/docker-images.yaml \
-e /home/stack/ospd-13-vxlan-dpdk-data-bonding-rt-hybrid/network-environment.yaml
Copy to Clipboard Toggle word wrap

9.3.3. RT-KVM 인스턴스 시작

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

  1. 오버클라우드에 RT-KVM 플레이버를 생성합니다.

    # openstack flavor create --ram 4096 --disk 20 --vcpus 4 <flavor-name>
    # openstack flavor set --property hw:cpu_policy=dedicated <flavor-name>
    # openstack flavor set --property hw:cpu_realtime=yes <flavor-name>
    # openstack flavor set --property hw:mem_page_size=1GB <flavor-name>
    # openstack flavor set --property hw:cpu_realtime_mask="^0-1" <flavor-name>
    # openstack flavor set --property hw:emulator_threads_policy=isolate <flavor-name>
    Copy to Clipboard Toggle word wrap
  2. RT-KVM 인스턴스를 시작합니다.

    # openstack server create  --image <rhel> --flavor <flavor-name> --nic net-id=<dpdk-net> test-rt
    Copy to Clipboard Toggle word wrap
  3. 필요에 따라 인스턴스가 할당된 에뮬레이터 스레드를 사용하는지 확인합니다.Optionally, verify that the instance uses the assigned emulator threads:

    # 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>
    Copy to Clipboard Toggle word wrap

9.4. NUMA 인식 vSwitch 구성(기술 프리뷰)

중요

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

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

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

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

이 기능을 사용하여 물리적 네트워크를 공유하는 인스턴스가 동일한 NUMA 노드에 있는지 확인합니다. 데이터센터 하드웨어를 최적화하기 위해 여러 네트워크, 다양한 네트워크 유형 또는 본딩을 사용하여 부하 분산 VM을 활용할 수 있습니다.

중요

NUMA 노드 로드 공유 및 네트워크 액세스를 올바르게 설계하려면 PCIe 슬롯과 NUMA 노드의 매핑을 이해해야 합니다. 특정 하드웨어에 대한 자세한 내용은 공급 업체의 설명서를 참조하십시오.

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

사전 요구 사항
  • "NUMATopologyFilter" 필터를 활성화했습니다.
절차
  • 물리적 네트워크와 연결된 NUMA 노드에 물리적 네트워크를 매핑하도록 새 NeutronPhysnetNUMANodesMapping 매개변수를 설정합니다.
  • VxLAN 또는 GRE와 같은 터널을 사용하는 경우 NeutronTunnelNUMANodes 매개변수도 설정해야 합니다.

    parameter_defaults:
      NeutronPhysnetNUMANodesMapping: {<physnet_name>: [<NUMA_NODE>]}
      NeutronTunnelNUMANodes: <NUMA_NODE>,<NUMA_NODE>
    Copy to Clipboard Toggle word wrap

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

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

    parameter_defaults:
      NeutronBridgeMappings:
        - tenant:br-link0
      NeutronPhysnetNUMANodesMapping: {tenant: [1], mgmt: [0,1]}
      NeutronTunnelNUMANodes: 0
    Copy to Clipboard Toggle word wrap
테스트
  • /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf에서 구성을 관찰합니다.

    [neutron_physnet_tenant]
    numa_nodes=1
    [neutron_tunnel]
    numa_nodes=1
    Copy to Clipboard Toggle word wrap
  • lscpu 명령을 사용하여 새 구성을 확인합니다.

    $ lscpu
    Copy to Clipboard Toggle word wrap
  • NIC가 적절한 네트워크에 연결된 VM을 시작합니다.

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

QoS 구성에 대한 자세한 내용은 실시간 컴퓨팅 구성을 참조하십시오. SR-IOV 및 OVS -DPDK 송신 인터페이스에서 QoS 규칙 유형 대역폭 제한으로 제한됩니다.

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

최적화된 리소스 사용을 위해 컴퓨팅 및 Ceph Storage 서비스를 공동 배치 및 구성하여 하이퍼 컨버지드 노드로 NFV 인프라를 배포할 수 있습니다.

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

사전 요구 사항
  • Red Hat OpenStack Platform 13.12 유지 관리 릴리스 2019년 12월 19일 이상.
  • Ceph 12.2.12-79(라이센스) 이상.
  • ceph-ansible 3.2.38 이상.
절차
  1. 언더클라우드에 ceph- anible을 설치합니다.

    $ sudo yum install ceph-ansible -y
    Copy to Clipboard Toggle word wrap
  2. ComputeHCI 역할에 대한 roles_data.yaml 파일을 생성합니다.

    $ openstack overcloud roles generate -o ~/<templates>/roles_data.yaml Controller \
     ComputeHCIOvsDpdk
    Copy to Clipboard Toggle word wrap
  3. openstack flavor createopenstack flavor set 명령을 사용하여 새 플레이버를 생성하고 구성합니다. 플레이버 생성에 대한 자세한 내용은 Advanced Overcloud Customization 가이드새 역할 생성 을 참조하십시오.
  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 /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml \
     -e ~/<templates>/<custom environment file>
    Copy to Clipboard Toggle word wrap

9.6.1. NUMA 노드 구성의 예

성능 향상을 위해 NUMA-0과 같은 NUMA 노드 1개에 테넌트 네트워크 및 Ceph 개체 서비스 데몬(OSD)과 NUMA-1과 같은 다른 NUMA 노드의 VNFV VM을 배치합니다.

CPU 할당:
Expand
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 할당의 예:
Expand
 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.6.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
Copy to Clipboard Toggle word wrap

다음 매개 변수를 사용하여 ceph OSD 프로세스에 CPU 리소스를 할당합니다. 이 하이퍼컨버지드 환경에서 워크로드 및 하드웨어를 기반으로 값을 조정합니다.

1
ceph_osd_docker_cpuset_cpus: SSD 디스크마다 각 OSD에 4개의 CPU 스레드를 할당하거나 HDD 디스크용 각 OSD에 대해 1개의 CPU를 할당합니다. ceph와 연결된 NUMA 노드에서 코어 및 형제 스레드 목록을 포함하고 다음 세 목록에 없는 CPU를 포함합니다. NovaVcpuPinSet, OvsDpdkCoreList, and OvsPmdCoreList.
2
ceph_osd_docker_cpu_limit: ceph OSD를 ceph_osd_docker_cpuset_cpus 의 CPU 목록에 고정하려면 이 값을 0 으로 설정합니다.
3
ceph_osd_numactl_opts: 연속 작업에서는 이 값을 precaution으로 설정합니다.

9.6.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

    OvsDpdkCoreList: "0,44,1,45"                                # 
5

    NumDpdkInterfaceRxQueues: 1
Copy to Clipboard Toggle word wrap
1
KernelArgs: hugepages 를 계산하려면 총 메모리에서 NovaReservedHostMemory 매개변수 값을 뺀 값입니다.
2
IsolCpusList: 이 매개변수를 사용하여 호스트 프로세스에서 격리할 CPU 코어 세트를 할당합니다. OvsPmdCoreList 매개변수 값을 NovaVcpuPinSet 매개변수 값에 추가하여 IsolCpusList 매개변수 값을 계산합니다.
3
OvsDpdkSocketMemory: OvsDpdkSocketMemory 매개변수를 사용하여 NUMA 노드당 hugepage 풀에서 사전 할당할 메모리 양을 MB로 지정합니다. OVS-DPDK 매개변수 계산에 대한 자세한 내용은 ovsdpdk 매개변수를참조하십시오.
4
OvsPmdCoreList: 이 매개변수를 사용하여 DPDK 폴링 모드 드라이버(PMD)에 사용되는 CPU 코어를 지정합니다. DPDK 인터페이스의 로컬 NUMA 노드와 연결된 CPU 코어를 선택합니다. OvsPmdCoreList 매개변수의 값을 계산하기 위해 각 NUMA 노드에 2 HT 형제 스레드를 할당합니다.
5
OvsDpdkCoreList: 이 매개변수를 사용하여 비 데이터 경로 OVS-DPDK 프로세스(예: handler 및 revalidator 스레드)에 대해 CPU 코어를 지정합니다. OvsDpdkCoreList 매개 변수의 값을 계산하기 위해 각 NUMA 노드에 2 HT 형제 스레드를 할당합니다.

9.6.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
  NovaVcpuPinSet:                                                  # 
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
Copy to Clipboard Toggle word wrap
1
NovaReservedHugePages: NovaReservedHugePages 매개변수를 사용하여 hugepage 풀에서 메모리를 사전 할당합니다. OvsDpdkSocketMemory 매개 변수의 값과 동일한 메모리 합계입니다.
2
NovaReservedHostMemory: NovaReservedHostMemory 매개변수를 사용하여 호스트에서 메모리 예약(MB)을 예약합니다. 예약해야 하는 메모리 양을 계산하려면 다음 지침을 따르십시오.
  • 각 OSD에 대해 5GB.
  • 각 VM에 대해 0.5GB 오버헤드입니다.
  • 일반 호스트 처리를 위한 4GB. cross-NUMA OSD 작업으로 인한 잠재적인 성능 저하를 방지하기 위해 충분한 메모리를 할당해야 합니다.
3
NovaVcpuPinSet: NovaVcpuPinSet 매개변수를 사용하여 OvsPmdCoreList,OvsDpdkCoreList 또는 Ceph_osd_docker_cpuset_cpus 에서 찾을 수 없는 CPU를 나열합니다. CPU는 DPDK NIC와 동일한 NUMA 노드에 있어야 합니다.

9.6.5. HCI-DPDK 배포에 권장되는 구성

Expand
표 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 CPU
  • 소켓 메모리

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

이 섹션에서는 OVS-DPDK 및 SR-IOV 인터페이스를 둘 다 사용하여 Compute 노드를 배포하는 방법을 설명합니다. 클러스터는 ML2/OVS 및 VXLAN 터널을 사용하여 설치됩니다.

중요

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

10.1. 역할 구성

/usr/share/openstack-tripleo-heat-templates에 있는 기본 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 매개변수의 최적 값을 결정해야 합니다. 자세한 내용은 Network Functions Virtualization Planning and Configuration 을 참조하십시오.

  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
    Copy to Clipboard Toggle word wrap
  2. parameter_defaults 에서 터널 유형 및 네트워크 유형을 6443 으로 설정합니다.

    NeutronTunnelTypes: 'vxlan'
    NeutronNetworkType: 'vxlan'
    Copy to Clipboard Toggle word wrap
  3. parameters_defaults 에서 브리지 매핑을 설정합니다.

    # The OVS logical->physical bridge mappings to use.
    NeutronBridgeMappings:
      - dpdk-mgmt:br-link0
    Copy to Clipboard Toggle word wrap
  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"
        NovaVcpuPinSet: ['4-19,24-39']
        NovaReservedHostMemory: 2048
        OvsDpdkSocketMemory: "3072,1024"
        OvsDpdkMemoryChannels: "4"
        OvsDpdkCoreList: "0,20,1,21"
        OvsPmdCoreList: "2,22,3,23"
        NovaLibvirtRxQueueSize: 1024
        NovaLibvirtTxQueueSize: 1024
    Copy to Clipboard Toggle word wrap
    참고

    게스트를 생성하는 동안 오류가 발생하지 않도록 하려면 각 NUMA 노드에서 형제 스레드로 하나 이상의 CPU를 할당합니다. 이 예에서 OvsPmdCoreList 매개변수 값은 NUMA 0에서 코어 2와 22를 나타내며 NUMA 1의 코어 3 및 23을 나타냅니다.

    참고

    가상 머신과 OvsDpdkSocketMemory 매개변수를 사용하는 OVS-DPDK에서 대규모 페이지를 사용합니다. 가상 머신에서 사용할 수 있는 대규모 페이지 수를 계산하려면 부팅 매개변수 값에서 OvsDpdkSocketMemory 값을 끕니다. DPDK 인스턴스와 연결된 플레이버에 hw:mem_page_size=1GB 도 추가해야 합니다.

    참고

    OvsDPDKCoreListOvsDpdkMemoryChannels 는 이 프로세스에 대한 설정이 필요하며 실패를 방지하려면 올바르게 설정해야 합니다.

  5. SR-IOV의 역할별 매개변수를 구성합니다.

      ##########################
      #  SR-IOV configuration  #
      ##########################
      NeutronMechanismDrivers: ['openvswitch','sriovnicswitch']
      NovaSchedulerDefaultFilters: ['RetryFilter','AvailabilityZoneFilter','RamFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','NUMATopologyFilter']
      NovaSchedulerAvailableFilters: ["nova.scheduler.filters.all_filters","nova.scheduler.filters.pci_passthrough_filter.PciPassthroughFilter"]
      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"
    Copy to Clipboard Toggle word wrap

10.3. 컨트롤러 노드 구성

  1. 격리된 네트워크에 대한 컨트롤 플레인 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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
  3. neutron-dhcp-agent 및 neutron-metadata-agent 서비스에 액세스할 OVS 브리지를 만듭니다.

      - 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
    Copy to Clipboard Toggle word wrap

10.4. DPDK 및 SR-IOV의 컴퓨팅 노드 구성

기본 compute.yaml 파일에서 computeovsdpdksriov.yaml 파일을 생성하고 다음과 같이 변경합니다.

  1. 격리된 네트워크에 대한 컨트롤 플레인 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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
    참고

    여러 DPDK 장치를 포함하려면 추가하려는 각 DPDK 장치에 대해 유형 코드 섹션을 반복합니다.

    참고

    OVS-DPDK를 사용하는 경우 동일한 Compute 노드의 모든 브리지는 ovs_user_bridge 유형이어야 합니다. director는 구성을 허용할 수 있지만 Red Hat OpenStack Platform은 동일한 노드에서 ovs_bridgeovs_user_bridge 혼합을 지원하지 않습니다.

10.5. 오버클라우드 배포

overcloud_deploy.sh 스크립트를 실행하여 오버클라우드를 배포합니다.

#!/bin/bash

openstack overcloud deploy \
--templates \
-r /home/stack/ospd-13-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/roles_data.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/neutron-ovs-dpdk.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-sriov.yaml \
-e /home/stack/ospd-13-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/ovs-dpdk-permissions.yaml \
-e /home/stack/ospd-13-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/overcloud_images.yaml \
-e /home/stack/ospd-13-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/network-environment.yaml \
--log-file overcloud_install.log &> overcloud_install.log
Copy to Clipboard Toggle word wrap

11장. NFV를 사용하여 Red Hat OpenStack 플랫폼 업그레이드

OVS-DPDK가 구성된 RHOSP(Red Hat OpenStack Platform) 업그레이드에 대한 자세한 내용은 Framework for Upgrades (13 to 16.1 ) 가이드의 NFV(Network Function Virtualization) 준비를 참조하십시오. RHOSP 업그레이드에 대한 자세한 내용은 Red Hat OpenStack Platform 업그레이드 가이드를 참조하십시오.

12장. 성능

Red Hat OpenStack Platform director는 게스트 가상 네트워크 기능(VNF)에 대한 라인 속도 성능을 실현하도록 리소스 파티셔닝 및 미세 튜닝을 시행하도록 Compute 노드를 구성합니다. NFV(네트워크 기능 가상화) 사용 사례의 주요 성능 요소는 throughput, latency 및 jitter입니다.

DPDK(Data Plane Development Kit) 가속화된 OVS(Open vSwitch)를 사용하면 물리적 NIC와 가상 머신 간에 고성능 패킷을 전환할 수 있습니다. OVS 2.7에는 DPDK 16.11 지원이 포함되어 있으며 vhost-user multiqueue에 대한 지원이 포함되어 있어 확장 가능한 성능을 제공합니다. OVS-DPDK는 게스트 VNF에 대한 라인 속도 성능을 제공합니다.

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

성능 튜닝을 위한 기타 중요한 기능에는 대규모 페이지, NUMA 정렬, 호스트 격리 및 CPU 고정이 있습니다. VNF 플레이버는 성능 향상을 위해 대규모 페이지 및 에뮬레이터 스레드 격리가 필요합니다. 호스트 격리 및 CPU 고정을 통해 NFV 성능이 향상되고 심각한 패킷 손실이 발생하지 않습니다.

CPU 및 NUMA 토폴로지에 대한 고급 소개를 위해 NFV Performance ConsiderationsConfigure read Threads to run on a Dedicated physical CPU 를 참조하십시오.

13장. 더 많은 정보 찾기

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

Red Hat OpenStack Platform 설명서 모음은 여기에서 확인할 수 있습니다. Red Hat OpenStack Platform Documentation Suite

Expand
표 13.1. 사용 가능한 문서 목록
구성 요소참조

Red Hat Enterprise Linux

Red Hat OpenStack Platform은 Red Hat Enterprise Linux 7.4에서 지원됩니다. Red Hat Enterprise Linux 설치에 대한 자세한 내용은 다음 주소에 있는 해당 설치 가이드를 참조하십시오. Red Hat Enterprise Linux Documentation Suite.

Red Hat OpenStack Platform

OpenStack 구성 요소 및 종속 항목을 설치하려면 Red Hat OpenStack Platform director를 사용하십시오. director는 기본 OpenStack 설치를 언더클라우드로 사용하여 최종 오버클라우드에서 OpenStack 노드를 설치, 설정 및 관리합니다. 배포된 오버클라우드에 필요한 환경 외에도 언더클라우드를 설치하려면 하나의 추가 호스트 시스템이 필요합니다. 자세한 내용은 Red Hat OpenStack Platform Director 설치 및 사용을 참조하십시오.

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

NFV 문서

NFV 개념에 대한 높은 수준 개요는 Network Functions Virtualization 제품 가이드 를 참조하십시오.

부록 A. 샘플 DPDK SRIOV YAML 파일

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

참고

이러한 템플릿은 완전히 구성된 환경에서 가져온 것으로, 배포에 관련이 없거나 적합하지 않을 수 있는 NFV와 관련이 없는 매개 변수를 포함합니다.

A.1. VXLAN DPDK SR-IOV YAML 파일 샘플

A.1.1. roles_data.yaml

###############################################################################
# File generated by TripleO                                                   #
###############################################################################
###############################################################################
# Role: Controller                                                            #
###############################################################################
- name: Controller
  description: |
    Controller role that has all the controler services loaded and handles
    Database, Messaging and Network functions.
  CountDefault: 1
  tags:
    - primary
    - controller
  networks:
    - External
    - InternalApi
    - Storage
    - StorageMgmt
    - Tenant
  # For systems with both IPv4 and IPv6, you may specify a gateway network for
  # each, such as ['ControlPlane', 'External']
  default_route_networks: ['External']
  HostnameFormatDefault: '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'
  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::CACerts
    - OS::TripleO::Services::CeilometerApi
    - OS::TripleO::Services::CeilometerCollector
    - OS::TripleO::Services::CeilometerExpirer
    - OS::TripleO::Services::CeilometerAgentCentral
    - OS::TripleO::Services::CeilometerAgentNotification
    - OS::TripleO::Services::CephExternal
    - 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::CinderBackendDellEMCUnity
    - OS::TripleO::Services::CinderBackendDellEMCVMAXISCSI
    - OS::TripleO::Services::CinderBackendDellEMCVNX
    - OS::TripleO::Services::CinderBackendDellEMCXTREMIOISCSI
    - OS::TripleO::Services::CinderBackendNetApp
    - OS::TripleO::Services::CinderBackendScaleIO
    - OS::TripleO::Services::CinderBackendVRTSHyperScale
    - 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::Congress
    - OS::TripleO::Services::Docker
    - OS::TripleO::Services::Ec2Api
    - OS::TripleO::Services::Etcd
    - OS::TripleO::Services::ExternalSwiftProxy
    - OS::TripleO::Services::Fluentd
    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GlanceRegistry
    - 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::Ipsec
    - OS::TripleO::Services::IronicApi
    - OS::TripleO::Services::IronicConductor
    - OS::TripleO::Services::IronicPxe
    - 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::MistralApi
    - OS::TripleO::Services::MistralEngine
    - OS::TripleO::Services::MistralExecutor
    - OS::TripleO::Services::MistralEventEngine
    - OS::TripleO::Services::MongoDb
    - 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::NeutronLbaasv2Agent
    - OS::TripleO::Services::NeutronLbaasv2Api
    - 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::NovaApi
    - OS::TripleO::Services::NovaConductor
    - OS::TripleO::Services::NovaConsoleauth
    - OS::TripleO::Services::NovaIronic
    - OS::TripleO::Services::NovaMetadata
    - OS::TripleO::Services::NovaPlacement
    - OS::TripleO::Services::NovaScheduler
    - OS::TripleO::Services::NovaVncProxy
    - OS::TripleO::Services::Ntp
    - 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::OVNDBs
    - OS::TripleO::Services::OVNController
    - OS::TripleO::Services::Pacemaker
    - OS::TripleO::Services::PankoApi
    - OS::TripleO::Services::RabbitMQ
    - OS::TripleO::Services::Redis
    - OS::TripleO::Services::Rhsm
    - OS::TripleO::Services::RsyslogSidecar
    - OS::TripleO::Services::SaharaApi
    - OS::TripleO::Services::SaharaEngine
    - OS::TripleO::Services::Securetty
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::SkydiveAgent
    - OS::TripleO::Services::SkydiveAnalyzer
    - 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::Tacker
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::Tuned
    - OS::TripleO::Services::Vpp
    - OS::TripleO::Services::Zaqar
    - OS::TripleO::Services::Ptp
###############################################################################
# Role: ComputeOvsDpdkSriov                                                   #
###############################################################################
- name: ComputeOvsDpdkSriov
  description: |
    Compute OvS DPDK+SR-IOV Role
  CountDefault: 1
  networks:
    - InternalApi
    - Tenant
    - Storage
  HostnameFormatDefault: 'compute-%index%'
  disable_upgrade_deployment: True
  ServicesDefault:
    - OS::TripleO::Services::Aide
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    - OS::TripleO::Services::CephExternal
    - 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::Fluentd
    - OS::TripleO::Services::Ipsec
    - OS::TripleO::Services::Iscsid
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::LoginDefs
    - OS::TripleO::Services::MySQLClient
    - OS::TripleO::Services::NeutronBgpVpnBagpipe
    - OS::TripleO::Services::NeutronSriovAgent
    - OS::TripleO::Services::NeutronSriovHostConfig
    - OS::TripleO::Services::NeutronVppAgent
    - OS::TripleO::Services::NovaCompute
    - OS::TripleO::Services::NovaLibvirt
    - OS::TripleO::Services::NovaMigrationTarget
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::ContainersLogrotateCrond
    - OS::TripleO::Services::OVNMetadataAgent
    - OS::TripleO::Services::Rhsm
    - OS::TripleO::Services::RsyslogSidecar
    - OS::TripleO::Services::Securetty
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::SkydiveAgent
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Timezone
  # Currently when attempting to deploy firewall service it notifies that it was specified multiple times
  # - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::Ptp
    - OS::TripleO::Services::Vpp
    - OS::TripleO::Services::OVNController
Copy to Clipboard Toggle word wrap

A.1.2. network-environment.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

parameter_defaults:
  # Customize all these values to match the local environment
  InternalApiNetCidr: 10.10.10.0/24
  TenantNetCidr: 10.10.2.0/24
  StorageNetCidr: 10.10.3.0/24
  StorageMgmtNetCidr: 10.10.4.0/24
  ExternalNetCidr: 172.20.12.112/28
  # CIDR subnet mask length for provisioning network
  ControlPlaneSubnetCidr: '24'
  InternalApiAllocationPools: [{'start': '10.10.10.10', 'end': '10.10.10.200'}]
  TenantAllocationPools: [{'start': '10.10.2.100', 'end': '10.10.2.200'}]
  StorageAllocationPools: [{'start': '10.10.3.100', 'end': '10.10.3.200'}]
  StorageMgmtAllocationPools: [{'start': '10.10.4.100', 'end': '10.10.4.200'}]
  # Use an External allocation pool which will leave room for floating IPs
  ExternalAllocationPools: [{'start': '172.20.12.114', 'end': '172.20.12.125'}]
  # Set to the router gateway on the external network
  ExternalInterfaceDefaultRoute: 172.20.12.126
  # Gateway router for the provisioning network (or Undercloud IP)
  ControlPlaneDefaultRoute: 192.168.24.1
  # Generally the IP of the Undercloud
  EC2MetadataIp: 192.168.24.1
  InternalApiNetworkVlanID: 10
  TenantNetworkVlanID: 11
  StorageNetworkVlanID: 12
  StorageMgmtNetworkVlanID: 13
  ExternalNetworkVlanID: 14
  # Define the DNS servers (maximum 2) for the overcloud nodes
  DnsServers: ["8.8.8.8","8.8.4.4"]
  # May set to br-ex if using floating IPs only on native VLAN on bridge br-ex
  NeutronExternalNetworkBridge: "''"
  # 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: 'dpdk-mgmt:br-link0'
  # The Neutron ML2 and OpenVSwitch vlan mapping range to support.
  NeutronNetworkVLANRanges: 'dpdk-mgmt:22:22,dpdk-mgmt:25:25,sriov-1:600:600,sriov-2:601:601'
  # Nova flavor to use.
  OvercloudControllerFlavor: controller
  OvercloudComputeOvsDpdkSriovFlavor: compute
  #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'

  ##########################
  # 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"
    NovaVcpuPinSet: ['4-19,24-39']
    NovaReservedHostMemory: 2048
    OvsDpdkSocketMemory: "3072,1024"
    OvsDpdkMemoryChannels: "4"
    OvsDpdkCoreList: "0,20,1,21"
    OvsPmdCoreList: "2,22,3,23"
    NovaLibvirtRxQueueSize: 1024
    NovaLibvirtTxQueueSize: 1024

  ##########################
  #  SR-IOV configuration  #
  ##########################
  NeutronMechanismDrivers: ['openvswitch','sriovnicswitch']
  NovaSchedulerDefaultFilters: ['RetryFilter','AvailabilityZoneFilter','RamFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','NUMATopologyFilter']
  NovaSchedulerAvailableFilters: ["nova.scheduler.filters.all_filters","nova.scheduler.filters.pci_passthrough_filter.PciPassthroughFilter"]
  NovaPCIPassthrough:
    - vendor_id: "8086"
      product_id: "1528"
      address: "0000:06:00.0"
      physical_network: "sriov-1"
    - vendor_id: "8086"
      product_id: "1528"
      address: "0000:06:00.1"
      physical_network: "sriov-2"
  NeutronPhysicalDevMappings:
    - sriov1:p7p3
    - sriov2:p7p4
  NeutronSriovNumVFs: "p7p3:5,p7p4:5"
Copy to Clipboard Toggle word wrap

A.1.3. controller.yaml

heat_template_version: queens

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
  InternalApiIpSubnet:
    default: ''
    description: IP address/subnet on the internal API network
    type: string
  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
  StorageIpSubnet:
    default: ''
    description: IP address/subnet on the storage network
    type: string
  StorageMgmtIpSubnet:
    default: ''
    description: IP address/subnet on the storage mgmt network
    type: string
  TenantIpSubnet:
    default: ''
    description: IP address/subnet on the tenant network
    type: string
  ManagementIpSubnet: # Only populated when including environments/network-management.yaml
    default: ''
    description: IP address/subnet on the management network
    type: string
  ExternalNetworkVlanID:
    default: ''
    description: Vlan ID for the external network traffic.
    type: number
  InternalApiNetworkVlanID:
    default: ''
    description: Vlan ID for the internal_api network traffic.
    type: number
  TenantNetworkVlanID:
    default: ''
    description: Vlan ID for the tenant network traffic.
    type: number
  ManagementNetworkVlanID:
    default: 23
    description: Vlan ID for the management network traffic.
    type: number
  ExternalInterfaceDefaultRoute:
    default: ''
    description: default route for the external network
    type: string
  ControlPlaneSubnetCidr: # Override this via parameter_defaults
    default: '24'
    description: The subnet CIDR of the control plane network.
    type: string
  ControlPlaneDefaultRoute: # Override this via parameter_defaults
    description: The default route of the control plane network.
    type: string
  DnsServers: # Override this via parameter_defaults
    default: []
    description: A list of DNS servers (2 max for some implementations) that will be added to resolv.conf.
    type: comma_delimited_list
  EC2MetadataIp: # Override this via parameter_defaults
    description: The IP address of the EC2 metadata server.
    type: string

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: 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

              - 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

              - 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

outputs:
  OS::stack_id:
    description: The OsNetConfigImpl resource.
    value:
      get_resource: OsNetConfigImpl
Copy to Clipboard Toggle word wrap

A.1.4. compute-ovs-dpdk.yaml

heat_template_version: queens

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
  InternalApiIpSubnet:
    default: ''
    description: IP address/subnet on the internal API network
    type: string
  TenantIpSubnet:
    default: ''
    description: IP address/subnet on the tenant network
    type: string
  ManagementIpSubnet: # Only populated when including environments/network-management.yaml
    default: ''
    description: IP address/subnet on the management network
    type: string
  InternalApiNetworkVlanID:
    default: ''
    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: ''
    description: Vlan ID for the tenant network traffic.
    type: number
  ManagementNetworkVlanID:
    default: 23
    description: Vlan ID for the management network traffic.
    type: number
  StorageIpSubnet:
    default: ''
    description: IP address/subnet on the storage network
    type: string
  StorageMgmtIpSubnet:
    default: ''
    description: IP address/subnet on the storage mgmt network
    type: string
  ControlPlaneSubnetCidr: # Override this via parameter_defaults
    default: '24'
    description: The subnet CIDR of the control plane network.
    type: string
  ControlPlaneDefaultRoute: # Override this via parameter_defaults
    description: The default route of the control plane network.
    type: string
  DnsServers: # Override this via parameter_defaults
    default: []
    description: A list of DNS servers (2 max for some implementations) that will be added to resolv.conf.
    type: comma_delimited_list
  EC2MetadataIp: # Override this via parameter_defaults
    description: The IP address of the EC2 metadata server.
    type: string
  ExternalInterfaceDefaultRoute:
    default: ''
    description: default route for the external network
    type: string

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: interface
                name: p7p3
                mtu: 9000
                use_dhcp: false
                defroute: false
                nm_controlled: true
                hotplug: true
             
              - type: interface
                name: p7p4
                mtu: 9000
                use_dhcp: false
                defroute: false
                nm_controlled: true
                hotplug: true

outputs:
  OS::stack_id:
    description: The OsNetConfigImpl resource.
    value:
      get_resource: OsNetConfigImpl
Copy to Clipboard Toggle word wrap

A.1.5. overcloud_deploy.sh

#!/bin/bash

openstack overcloud deploy \
--templates \
-r /home/stack/ospd-13-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/roles_data.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/neutron-ovs-dpdk.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-sriov.yaml \
-e /home/stack/ospd-13-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/ovs-dpdk-permissions.yaml \
-e /home/stack/ospd-13-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/overcloud_images.yaml \
-e /home/stack/ospd-13-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/network-environment.yaml \
--log-file overcloud_install.log &> overcloud_install.log
Copy to Clipboard Toggle word wrap
맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

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

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat