サポートコンソール開発者トライアルの開始お問い合わせ

ネットワーク機能仮想化 (NFV) のプランニングおよび設定ガイド

Red Hat OpenStack Platform 15

ネットワーク機能仮想化(NFV)Red Hat OpenStack Platform デプロイメントのプランニングおよび設定

概要

本ガイドでは、Red Hat OpenStack Platform デプロイメントのネットワーク機能仮想化インフラストラクチャー (NFVi) 向け Single Root Input/Output Virtualization (SR-IOV) および Data Plane Development Kit (DPDK) について、プランニングに関する重要な情報を提供すると共に設定の手順を説明します。

はじめに

Red Hat OpenStack Platform は、Red Hat Enterprise Linux 上にプライベートまたはパブリッククラウドを構築するための基盤を提供します。これにより、スケーラビリティーが極めて高く、耐障害性に優れたプラットフォームをクラウド対応のワークロード開発に利用できます。

本ガイドでは、Red Hat OpenStack Platform director を使用して、ネットワーク機能仮想化 (NFV) デプロイメント向けに Single Root I/O Virtualization (SR-IOV) および Data Plane Development Kit 対応 Open vSwitch (OVS-DPDK) のプランニングおよび設定を行う方法について説明します。

第1章 概要

ネットワーク機能仮想化(NFV: Network Functions Virtualization)とは、汎用のクラウドベースのインフラストラクチャー上でネットワーク機能を仮想化するソフトウェアソリューションです。NFV により、通信事業者 (CSP) は従来のハードウェアから離れることができます。

NFV の概念の概要は、『 ネットワーク機能仮想化(NFV)の製品ガイド』 を参照してください。

注記

OVS-DPDK および SR-IOV の設定は、ハードウェアとトポロジーに依存します。本ガイドでは、CPU の割り当て、メモリーの確保、NIC の設定の例を紹介します。これらは、トポロジーとユースケースによって異なる場合があります。

Red Hat OpenStack Platform director を使用して、特定のネットワーク種別 (外部、テナント、内部 API 等) を分離します。ネットワークは、単一のネットワークインターフェース上に、または複数のホストネットワークインターフェースに分散してデプロイすることができます。Open vSwitch により、複数のインターフェースを単一のブリッジに割り当てて、ボンディングを作成することができます。Red Hat OpenStack Platform インストール環境でネットワークの分離を設定するには、テンプレートファイルを使用します。テンプレートファイルを指定しない場合、サービスネットワークはプロビジョニングネットワーク上にデプロイされます。テンプレートの設定ファイルには、2 つの種類があります。

  • network-environment.yaml: このファイルには、サブネットおよび IP アドレス範囲などの、オーバークラウドノードのネットワーク情報が含まれます。このファイルには、さまざまなシナリオで使用できるように、デフォルトのパラメーター値を上書きする別の設定も含まれます。
  • compute.yaml および controller.yaml 等のホストのネットワークテンプレート: オーバークラウドノードのネットワークインターフェース設定が定義されます。ネットワーク情報の値は、network-environment.yaml ファイルで指定します。

これらの Heat テンプレートファイルは、アンダークラウドノードの /usr/share/openstack-tripleo-heat-templates/ にあります。

「ハードウェア要件」および「ソフトウェア要件」の項では、Red Hat OpenStack Platform director を使用した NFV 用 Heat テンプレートファイルのプランニングおよび設定の方法について説明します。

注記

YAML ファイルを編集して NFV を設定することができます。YAML ファイル形式の概要は、「 YAML in a Nutshell 」を参照してください。

第2章 ハードウェア要件

本項では、NFV のハードウェア要件について説明します。

Red Hat Technologies Ecosystem を使用して、認定済みハードウェア、ソフトウェア、クラウドプロバイダー、およびコンポーネントの一覧を確認することができます。

Red Hat OpenStack Platform の認定済みハードウェアの完全一覧については、Red Hat OpenStack Platform certified hardware を参照してください。

2.1. テスト済み NIC

NFV 向けのテスト済み NIC の一覧は、「Network Adapter Fast Datapath Feature Support Matrix」を参照してください。

Mellanox ConnectX-4 または ConnectX-5 ネットワークインターフェース上に OVS-DPDK を設定する場合には、compute-ovs-dpdk.yaml ファイルで該当するカーネルドライバーを設定する必要があります。 

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

2.2. NUMA ノードのトポロジーについての理解

デプロイメントを計画する際には、最高のパフォーマンスが得られるように、コンピュートノードの NUMA トポロジーを理解して CPU およびメモリーのリソースを分割する必要があります。NUMA 情報を確認するには、以下のいずれかのタスクを実行します。

  • ハードウェアイントロスペクションを有効にして、ベアメタルノードからこの情報を取得する。
  • 各ベアメタルノードにログオンして、手動で情報を収集する。
注記

ハードウェアイントロスペクションで NUMA 情報を取得するには、アンダークラウドのインストールと設定が完了している必要があります。アンダークラウド設定についての詳しい情報は、『 director のインストールと使用方法』 を参照してください。

ハードウェアイントロスペクション情報の取得

Bare Metal サービスのハードウェア検査の追加は、デフォルトで、ハードウェア情報の取得に有効になっています。これらのハードウェア情報を使って、オーバークラウドを設定することができます。undercloud.conf ファイル の inspection_extras パラメーターについての詳しい情報は、『director のインストールと使用方法』の「director の設定」を参照し てください。

たとえば、numa_topology コレクターは、このハードウェア検査の追加部分で、各 NUMA ノードに関する以下の情報が含まれます。

  • RAM (キロバイト単位)
  • 物理 CPU コアおよびそのシブリングスレッド
  • NUMA ノードに関連付けられた NIC

手順

  1. 上記の情報を取得するには、<UUID> をベアメタルノードの UUID に置き換えて、以下のコマンドを実行します。 
$ openstack baremetal introspection data save <UUID> | jq .numa_topology

取得されるベアメタルノードの NUMA 情報の例を以下に示します。 

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

2.3. BIOS 設定

以下の表に NFV に必要な BIOS 設定をまとめます。

表2.1 BIOS 設定
パラメーター設定

C3 Power State

Disabled

C6 Power State

Disabled

MLC Streamer

有効

MLC Spacial Prefetcher

有効

DCU Data Prefetcher

有効

DCA

有効

CPU Power and Performance

パフォーマンス

Memory RAS and Performance Config → NUMA Optimized

有効

Turbo Boost

Disabled

VT-d

Intel カードで VFIO 機能が必要な場合には Enabled

第3章 ソフトウェア要件

本項では、サポートされている設定とドライバー、および NFV に必要なサブスクリプションの詳細について説明します。

3.1. リポジトリーの登録と有効化

Red Hat OpenStack Platform をインストールするには、Red Hat サブスクリプションマネージャーを使用して Red Hat OpenStack Platform director を登録し、必要なリポジトリーを有効にする必要があります。詳しくは、「 director のインストールの準備 」を参照してください。

手順

  1. コンテンツ配信ネットワークにシステムを登録し、プロンプトが表示されたらカスタマーポータルのユーザー名とパスワードを入力します。 

    [stack@director ~]$ sudo subscription-manager register

  2. Red Hat OpenStack Platform director のエンタイトルメントプール ID を決定します。以下に例を示します。 

    [stack@director ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack"

Subscription Name:   Name of SKU
Provides:            Red Hat Single Sign-On
                     Red Hat Enterprise Linux Workstation
                     Red Hat CloudForms
                     Red Hat OpenStack
                     Red Hat Software Collections (for RHEL Workstation)
                     Red Hat Virtualization
SKU:                 SKU-Number
Contract:            Contract-Number
Pool ID:             {Pool-ID}-123456
Provides Management: Yes
Available:           1
Suggested:           1
Service Level:       Support-level
Service Type:        Service-Type
Subscription Type:   Sub-type
Ends:                End-date
System Type:         Physical

  3. 以下のコマンドで Pool ID の値を指定して、Red Hat OpenStack Platform 16.1 のエンタイトルメントをアタッチします。 

    [stack@director ~]$ sudo subscription-manager attach --pool={Pool-ID}-123456

  4. デフォルトのリポジトリーを無効にします。 

    subscription-manager repos --disable=*

  5. Red Hat OpenStack Platform で NFV を使用するのに必要なリポジトリーを有効にします。 

    $ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms \
--enable=rhel-8-for-x86_64-appstream-rpms \
--enable=rhel-8-for-x86_64-highavailability-rpms \
--enable=ansible-2.8-for-rhel-8-x86_64-rpms \
--enable=openstack-15-for-rhel-8-x86_64-rpms \
--enable=rhel-8-for-x86_64-nfv-rpms \
--enable=advanced-virt-for-rhel-8-x86_64-rpms \
--enable=fast-datapath-for-rhel-8-x86_64-rpms

  6. 最新のベースシステムパッケージに対してシステムで更新を実行します。 

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

オーバークラウドノードを登録するには、「 Ansible ベースの登録 」を参照してください。

3.2. NFV デプロイメントでサポートされている構成

Red Hat OpenStack Platform (RHOSP) では、director を使用して以下の NFV デプロイメントがサポートされます。

  • Single Root I/O Virtualization (SR-IOV)
  • Data Plane Development Kit 対応 Open vSwitch (OVS-DPDK)

また、以下のどの機能と共に Red Hat OpenStack Platform をデプロイすることもできます。

注記

Red Hat の組み込み OpenDaylight SDN ソリューションは、RHOSP 14 で非推奨になりました。Red Hat は OpenDaylight のサポートおよびバグ修正を継続して提供しますが、すべてのサポートは 2021 年 6 月 27 日に RHOSP 13 のライフサイクルと共に終了します。

デフォルトの SDN ソリューションとして Open Virtual Network(OVN)を使用する RHOSP 15 NFV デプロイメントはサポートされません。OVS メカニズムドライバーと共に RHOSP をデプロイするには、以下の手順を使用します。

手順

  1. containers-prepare-parameter.yaml ファイルで neutron_driver パラメーターを null に設定します。 

    parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
     neutron_driver: openvswitch
     ...

  2. /usr/share/openstack-tripleo-heat-templates/environments/services ディレクトリーの neutron-ovs.yaml 環境ファイルを、デプロイメント用スクリプトに追加します。 

    TEMPLATES=/usr/share/openstack-tripleo-heat-templates

openstack overcloud deploy --templates \
-e ${TEMPLATES}/environments/network-environment.yaml \
-e ${TEMPLATES}/environments/network-isolation.yaml \
-e ${TEMPLATES}/environments/host-config-and-reboot.yaml \
-e ${TEMPLATES}/environments/services/neutron-ovs.yaml \
-e ${TEMPLATES}/environments/services/neutron-ovs-dpdk.yaml \
-e ${TEMPLATES}/environments/services/neutron-sriov.yaml \
-e /home/stack/containers-prepare-parameter.yaml

3.3. サポートされているドライバー

サポートされるドライバーの完全な一覧は「Component, Plug-In, and Driver Support in Red Hat OpenStack Platform」を参照してください。

Red Hat OpenStack の NFV デプロイメント向けにテスト済みの NIC の一覧は、「ネットワークアダプターのサポート」を参照してください。

3.4. サードパーティー製のソフトウェアとの互換性

Red Hat OpenStack Platform で機能することを検証、サポート、認定済みの製品およびサービスの完全な一覧は、Red Hat OpenStack Platform と互換性のあるサードパーティー製のソフトウェア の情報を参照してください。製品バージョンやソフトウェアカテゴリー別に一覧をフィルタリングすることができます。

Red Hat Enterprise Linux で機能することを検証、サポート、認定済みの製品およびサービスの完全な一覧は、Red Hat Enterprise Linux と互換性のあるサードパーティー製のソフトウェア の情報を参照してください。製品バージョンやソフトウェアカテゴリー別に一覧をフィルタリングすることができます。

第4章 ネットワークの考慮事項

アンダークラウドのホストには、最低でも以下のネットワークが必要です。

  • プロビジョニングネットワーク: オーバークラウドで使用できるベアメタルシステムの検出に役立つ DHCP および PXE ブート機能を提供します。
  • 外部ネットワーク: 全ノードへのリモート接続に使用する別個のネットワーク。このネットワークに接続するインターフェースには、静的または外部の DHCP サービスを介して動的に定義された、ルーティング可能な IP アドレスが必要です。

最小限のオーバークラウドのネットワーク構成には、以下の NIC 構成が含まれます。

  • シングル NIC 構成: ネイティブ VLAN 上のプロビジョニングネットワークと、オーバークラウドネットワークの種別ごとのサブネットを使用するタグ付けされた VLAN 用に NIC を 1 つ。
  • デュアル NIC 構成: プロビジョニングネットワーク用の NIC を 1 つと、外部ネットワーク用の NIC を 1 つ。
  • デュアル NIC 構成： ネイティブ VLAN 上のプロビジョニングネットワーク用に NIC を 1 つと、オーバークラウドネットワークの種別ごとのサブネットを使用するタグ付けされた VLAN 用の NIC を 1 つ。
  • 複数 NIC 構成: 各 NIC は、オーバークラウドネットワークの種別ごとのサブセットを使用する。

ネットワーク要件の詳しい情報は、「ネットワーク要件」を参照 し てください。

第5章 SR-IOV デプロイメントのプランニング

コンピュートノードのハードウェアに応じて個別のパラメーターを設定し、NFV 向けの Single Root I/O Virtualization (SR-IOV) デプロイメントを最適化します。

SR-IOV パラメーターに対するハードウェアの影響を評価するには、「NUMA ノードのトポロジーについての理解」を参照してください。

5.1. SR-IOV デプロイメント向けのハードウェアの分割

SR-IOV で高パフォーマンスを実現するには、ホストとゲストの間でリソースを分割します。

OpenStack NFV Hardware Capacities 464931 0118 SR IOV

標準的なトポロジーでは、デュアルコアソケットのコンピュートノード上の NUMA ノードにはそれぞれ 14 のコアが実装されます。HT (ハイパースレッド) および非 HT のコアがサポートされています。各コアには 2 つのシブリングスレッドがあります。1 つのコアは、各 NUMA ノード上のホスト専用です。VNF は SR-IOV インターフェースのボンディングを処理します。すべての割り込み要求 (IRQ) はホストのコア上でルーティングされます。VNF コアは VNF 専用です。これらのコアは、他の VNF からの分離と、ホストからの分離を提供します。各 VNF は単一の NUMA ノード上のリソースを使用する必要があります。VNF によって使用される SR-IOV NIC はその同じ NUMA ノードに関連付ける必要もあります。このトポロジーでは、仮想化のオーバーヘッドはありません。ホスト、OpenStack Networking(neutron)、および Compute(nova)の設定パラメーターは単一のファイルで公開されるので、管理が簡単で、整合性を保つことができます。また、プリエンプションやパケットロスの原因となり、分離を適切に行うにあたって致命的となる一貫性の欠如を回避します。ホストと仮想マシンの分離は、tuned プロファイルに依存します。このプロファイルは、分離する CPU の一覧に基づいて、ブートパラメーターや Red Hat OpenStack Platform の変更を管理します。

5.2. NFV SR-IOV デプロイメントのトポロジー

以下の図には、2 つの仮想ネットワーク機能 (VNF) が示されています。各 VNF には、mgt で示された管理インターフェースおよびデータプレーンインターフェースがあります。管理インターフェースは ssh アクセスおよびその他の管理機能を管理します。データプレーンインターフェースは VNF を Data Plane Development Kit(DPDK)にボンディングして高可用性を確保します。VNF は、DPDK ライブラリーを使用してデータプレーンインターフェースをボンディングします。この図には、2 つの冗長プロバイダーネットワークも示されています。コンピュートノードには 2 つの標準 NIC がボンディングされ、VNF 管理と Red Hat OpenStack Platform API 管理の間で共有されています。

NFV SR-IOV deployment

この図は、アプリケーションレベルで DPDK を活用し、SR-IOV Virtual Function(VF)および Physical Function(PF)へのアクセスが可能な VNF を示しています。これにより、ファブリックの設定に応じて可用性やパフォーマンスが向上します。DPDK はパフォーマンスを向上させる一方、VF/PF DPDK のボンディングはフェイルオーバー/可用性に対応します。VNF ベンダーは、DPDK Poll Mode Driver(PMD)が VF/PF として公開される SR-IOV カードを必ずサポートするようにする必要があります。VNF は標準の virtIO ドライバーを使用して「mgmt」ネットワークデバイスにアクセスするため、管理ネットワークは Open vSwitch(OVS)を使用します。オペレーターは、VNF への初回の接続にそのデバイスを使用して、DPDK アプリケーションに 2 つの VF/PF を適切にボンディングさせることができます。

5.2.1. HCI を使用しない NFV SR-IOV のトポロジー

以下の図には、NFV ユースケース向けのハイパーコンバージドインフラストラクチャー(HCI)を使用しない Single Root I/O Virtualization(SR-IOV)のトポロジーを示しています。この環境は、1 Gbps の NIC を搭載したコンピュートノードおよびコントローラーノードと、director ノードで構成されます。

NFV SR-IOV Topology without HCI

第6章 SR-IOV テクノロジーのデプロイ

OpenStack のインスタンスが仮想リソースを通じて共有 PCIe リソースに直接アクセスできるため、Single Root I/O Virtualization(SR-IOV)でベアメタルのパフォーマンスに近いパフォーマンスが得られます。

6.1. 前提条件

注記

director Heat テンプレートによって変更される /etc/tuned/cpu-partitioning-variables.conf の値を手動で編集しないでください。

6.2. SR-IOV の設定

注記

以下の例の CPU の割り当て、メモリーの割り当て、および NIC の設定は、お使いのトポロジーとユースケースとは異なる場合があります。

  1. NeutronSriovAgent、NeutronSriovHostConfig、およびデフォルトの Compute サービスを実行する OpenStack クラスターのノードを定義するために、ビルトインの ComputeSriov を生成します。 

    # openstack overcloud roles generate \
-o /home/stack/templates/roles_data.yaml \
Controller ComputeSriov

  2. SR-IOV コンテナーを準備するには、overcloud_images.yaml ファイルを生成する際に neutron-sriov.yaml および roles_data.yaml ファイルを含めます。 

    SERVICES=\
/usr/share/openstack-tripleo-heat-templates/environments/services

openstack tripleo container image prepare \
--namespace=registry.redhat.io/rhosp15-rhel8 \
--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
    注記

    push-destination の IP アドレスは、前のステップで undercloud.conf 設定ファイルの local_ip パラメーターで設定したアドレスです。

    コンテナーイメージの準備に関する詳細な情報は、『 director のインストールと使用方法』 を参照してください。

  3. KernelAgs および TunedProfile パラメーターを適用するには、/usr/share/openstack-tripleo-heat-templates/environments からの host-config-and-reboot.yaml ファイルをデプロイメントスクリプトに追加します。 

    openstack overcloud deploy --templates \
… \
-e /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml \
...

  4. 実際のクラスターおよびハードウェア構成に合わせて、parameter_defaults セクションで SR-IOV ノードのパラメーターを適切に設定します。これらの設定は、通常 network-environment.yaml ファイルに含まれます。 

      NeutronNetworkType: 'vlan'
  NeutronNetworkVLANRanges:
    - tenant:22:22
    - tenant:25:25
  NeutronTunnelTypes: ''

  5. 同じファイルで、SR-IOV コンピュートノードのロール固有のパラメーターを設定します。

    注記

    numvfs パラメーターは、ネットワーク設定テンプレートの NeutronSriovNumVFs パラメーターに代わるものです。Red Hat では、デプロイ後の NeutronSriovNumVFs パラメーターまたは numvfs パラメーターの変更をサポートしません。デプロイ後にいずれかのパラメーターを変更すると、その Physical Function (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:
      - devname: "p7p1"
        physical_network: "tenant"
      - devname: "p7p2"
        physical_network: "tenant"
    NovaVcpuPinSet: '1-19,21-39'
    NovaReservedHostMemory: 4096

  6. compute.yaml ネットワーク設定テンプレートで、SR-IOV 対応インターフェースを設定します。SR-IOV Virtual Function (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

  7. デフォルトフィルターの一覧に、値 AggregateInstanceExtraSpecsFilter が含まれる状態にします。 

    NovaSchedulerDefaultFilters: ['AvailabilityZoneFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','AggregateInstanceExtraSpecsFilter']
  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-ovs.yaml \
  -e ${TEMPLATES_HOME}/environments/services/neutron-sriov.yaml \
  -e ${CUSTOM_TEMPLATES}/network-environment.yaml

6.3. NIC のパーティション設定（テクノロジープレビュー）

この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビュー機能についての詳しい情報は、「対象範囲の詳細」を参照してください。

Red Hat OpenStack Platform ホストが Virtual Function (VF) を使用できるように、Single Root I/O Virtualization (SR-IOV) を設定することができます。

1 つの高速 NIC を複数の VF に分割する場合、NIC をコントロールプレーンおよびデータプレーントラフィックの両方に使用することができます。その後、必要に応じて QoS (Quality of Service) 優先度の値を VF インターフェースに適用することができます。

手順

オーバークラウドデプロイメント用のテンプレートを作成する際に、以下の手順を実施するようにしてください。

  1. os-net-config ロールファイルでインターフェース種別 sriov_pf を使用して、ホストが使用できる Physical Function(PF)を設定します。 

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

    numvfs パラメーターは、ネットワーク設定テンプレートの NeutronSriovNumVFs パラメーターに代わるものです。Red Hat では、デプロイ後の NeutronSriovNumVFs パラメーターまたは numvfs パラメーターの変更をサポートしません。デプロイメント後にいずれかのパラメーターを変更すると、その PF に SR-IOV ポートを持つ実行中のインスタンスが中断する可能性があります。この場合、これらのインスタンスをハードリブートして、SR-IOV PCI デバイスを再び利用可能にする必要があります。

  1. インターフェース種別 sriov_pf を使用して、ホストが使用できるボンディングで VF を設定します。 

                   - type: linux_bond
                 name: internal_bond
                 bonding_options: mode=active-backup
                 use_dhcp: false
                 members:
                 - type: sriov_vf
                   device: nic7
                   vfid: 1
                 - type: sriov_vf
                   device: nic8
                   vfid: 1

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

    • VLAN タグは、共通の PF デバイスに属するすべての VF を通じて一意でなければなりません。VLAN タグをインターフェース種別に割り当てる必要があります。

      • linux_bond
      • ovs_bridge
      • ovs_dpdk_port
    • 適用可能な VF ID の範囲はゼロで始まり、VF の合計数から 1 を引いた数値で終了します。

  2. 仮想マシンに VF を確保するには、NovaPCIPassthrough パラメーターを使用します。ホストではなく仮想マシンインスタンスが使用する VF を特定するには、正規表現の値を address パラメーターに割り当てる必要があります。

    これらの値は lspci から取得できます。この情報を取得するには、事前にコンピュートノードを Linux 環境で起動する必要がある場合があります。

    lspci コマンドは、各デバイスのアドレスを <bus>:<device>:<slot> の形式で返します。これらのアドレスの値を、以下の形式で NovaPCIPassthrough パラメーターに入力します。 

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

  3. NIC の分割が必要なすべてのノードで IOMMU を有効にします。たとえば、コンピュートノードに NIC 分割を設定する場合は、そのロールの KernelArgs パラメーターを使用して IOMMU を有効にします。 

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

検証

  1. VF の数を確認します。 

    [root@overcloud-compute-0 heat-admin]# cat /sys/class/net/p4p1/device/sriov_numvfs
10
[root@overcloud-compute-0 heat-admin]# cat /sys/class/net/p4p2/device/sriov_numvfs
10

  2. Linux ボンディングを確認します。 

    [root@overcloud-compute-0 heat-admin]# cat /proc/net/bonding/intapi_bond
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: p4p1_1
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: p4p1_1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 16:b4:4c:aa:f0:a8
Slave queue ID: 0

Slave Interface: p4p2_1
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: b6:be:82:ac:51:98
Slave queue ID: 0
[root@overcloud-compute-0 heat-admin]# cat /proc/net/bonding/st_bond
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: p4p1_3
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: p4p1_3
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 9a:86:b7:cc:17:e4
Slave queue ID: 0

Slave Interface: p4p2_3
MII Status: up
Speed: 10000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: d6:07:f8:78:dd:5b
Slave queue ID: 0

  3. OVS ボンディングを一覧表示します。 

    [root@overcloud-compute-0 heat-admin]# ovs-appctl bond/show
---- bond_prov ----
bond_mode: active-backup
bond may use recirculation: no, Recirc-ID : -1
bond-hash-basis: 0
updelay: 0 ms
downdelay: 0 ms
lacp_status: off
lacp_fallback_ab: false
active slave mac: f2:ad:c7:00:f5:c7(dpdk2)

slave dpdk2: enabled
  active slave
  may_enable: true

slave dpdk3: enabled
  may_enable: true

---- bond_tnt ----
bond_mode: active-backup
bond may use recirculation: no, Recirc-ID : -1
bond-hash-basis: 0
updelay: 0 ms
downdelay: 0 ms
lacp_status: off
lacp_fallback_ab: false
active slave mac: b2:7e:b8:75:72:e8(dpdk0)

slave dpdk0: enabled
  active slave
  may_enable: true

slave dpdk1: enabled
  may_enable: true

  4. OVS の接続を表示します。 

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

NovaPCIPassthrough を使用して VF をインスタンスに渡した場合には、SR-IOV インスタンスをデプロイして テストを行います。

6.4. ハードウェアオフロードの設定 (テクノロジープレビュー)

この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビュー機能についての詳しい情報は、「対象範囲の詳細」を参照してください。

Open vSwitch(OVS)ハードウェアオフロードには Single Root I/O Virtualization(SR-IOV)が組み込まれ、同様の設定手順が含まれます。

6.4.1. OVS ハードウェアオフロードの有効化

OVS ハードウェアオフロードを有効にするには、以下の手順を実施します。

  1. ComputeSriov ロールを作成します。 

    openstack overcloud roles generate -o roles_data.yaml Controller ComputeSriov

  2. ご自分の環境に合わせて、physical_network パラメーターを設定します。

    • VLAN の場合には、physical_network パラメーターをデプロイメント後に neutron で作成するネットワークの名前に設定します。この値は、NeutronBridgeMappings にも設定する必要があります。
    • VXLAN の場合には、physical_network パラメーターを文字列の値 null に設定します。

    • ロール固有のパラメーターセクションの OvsHwOffload パラメーターの値が true となるようにします。

      以下に例を示します。 

      parameter_defaults:
  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
    NeutronPhysicalDevMappings:
      - tenant:p7p1
      - tenant:p7p2
    NovaPCIPassthrough:
      - devname: "p7p1"
        physical_network: "null"
      - devname: "p7p2"
        physical_network: "null"
    NovaReservedHostMemory: 4096
    NovaVcpuPinSet: 1-9,21-29,11-19,31-39

  3. デフォルトフィルターの一覧に、値 NUMATopologyFilter が含まれる状態にします。 

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

  4. compute-sriov.yaml 設定ファイルで、ハードウェアオフロードに使用するネットワークインターフェースを 1 つまたは複数設定します。

    注記

    Open vSwitch ハードウェアオフロードを設定する場合には、NeutronSriovNumVFs パラメーターを使用しないでください。Virtual Function の数は、os-net-config で使用されるネットワーク設定ファイルの numvfs パラメーターを使用して指定します。 

      - 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
    注記

    Mellanox ネットワークインターフェースの nic-config インターフェース種別を ovs-vlan に設定しないでください。ドライバーの制約により、VXLAN 等のトンネルエンドポイントがトラフィックを渡さなくなるためです。

  5. オーバークラウドのデプロイメント時に、以下のファイルを追加します。

    • ovs-hw-offload.yaml

    • host-config-and-reboot.yaml 

      TEMPLATES_HOME=”/usr/share/openstack-tripleo-heat-templates”
CUSTOM_TEMPLATES=”/home/stack/templates”

openstack overcloud deploy --templates \
  -r ${CUSTOME_TEMPLATES}/roles_data.yaml \
  -e ${TEMPLATES_HOME}/environments/ovs-hw-offload.yaml \
  -e ${TEMPLATES_HOME}/environments/host-config-and-reboot.yaml \
  -e ${CUSTOME_TEMPLATES}/network-environment.yaml \
  -e ${CUSTOME_TEMPLATES}/neutron-ovs.yaml

6.4.2. OVS ハードウェアオフロードの確認

  1. pci デバイスのモードが switchdev に設定されていることを確認します。 

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

  2. OVS でオフロードが有効であることを確認します。 

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

6.5. SR-IOV 用インスタンスのデプロイ

Red Hat は、ホストアグリゲートを使用して、高パフォーマンスのコンピュートホストを分離することを推奨します。ホストアグリゲートの作成およびスケジューリング用 の関連フレーバーに関する情報は、「ホストアグリゲート の作成」を参照してください。

注記

CPU ピニングされたインスタンスをピニングされていないインスタンスと分けるには、ホストアグリゲートを使用すべきです。CPU ピニングを使用していないインスタンスは、CPU ピニングを使用するインスタンスのリソース要件に対応しません。

Single Root I/O Virtualization(SR-IOV)用インスタンスをデプロイするには、以下の手順を実施します。

  1. フレーバーを作成します。 

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

  2. ネットワークを作成します。 

    # openstack network create net1 --provider-physical-network tenant --provider-network-type vlan --provider-segment <VLAN-ID>
# openstack subnet create subnet1 --network net1 --subnet-range 192.0.2.0/24 --dhcp

  3. ポートを作成します。

    • SR-IOV Virtual Function (VF) ポートを作成するには、vnic-type に direct を使用します。 

      # openstack port create --network net1 --vnic-type direct sriov_port

    • ハードウェアオフロードを有効にして Virtual Function を作成するには、以下のコマンドを使用します。 

      # openstack port create --network net1 --vnic-type direct --binding-profile '{"capabilities": ["switchdev"]} sriov_hwoffload_port

    • SR-IOV PF ポートを作成するには、vnic-type に direct-physical を使用します。 

      # openstack port create --network net1 --vnic-type direct-physical sriov_port

  4. インスタンスをデプロイします。 

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

6.6. ホストアグリゲートの作成

パフォーマンスを向上させるために、Red Hat は、CPU ピニングおよびヒュージページを使用してゲストをデプロイすることを推奨します。アグリゲートメタデータをフレーバーメタデータに一致させることで、ホストのサブセット上にハイパフォーマンスインスタンスをスケジュールすることができます。

  1. AggregateInstanceExtraSpecsFilter の値が nova.conf 設定ファイルの scheduler_default_filters パラメーターに追加されていることを確認します。この設定は、デプロイの前にロール固有のパラメーターセクションの heat パラメーター NovaSchedulerDefaultFilters で設定できます。 

      ComputeOvsDpdkSriovParameters:
    NovaSchedulerDefaultFilters: ['AggregateInstanceExtraSpecsFilter', 'RetryFilter','AvailabilityZoneFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','NUMATopologyFilter']
    注記

    このパラメーターを heat テンプレートに追加することができます。オリジナルのデプロイメント用スクリプトを再度実行して、この設定を既存クラスターの設定に追加します。

  2. Single Root I/O Virtualization(SR-IOV)用のアグリゲートグループを作成し、適切なホストを追加します。定義するフレーバーメタデータに一致するメタデータを定義します (例: sriov=true)。 

    # openstack aggregate create sriov_group
# openstack aggregate add host sriov_group compute-sriov-0.localdomain
# openstack aggregate set sriov_group sriov=true

  3. フレーバーを作成します。 

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

  4. 追加のフレーバー属性を設定します。定義したメタデータ (sriov=true) と SR-IOV アグリゲートで定義したメタデータが一致している点に注意してください。 

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

第7章 OVS-DPDK デプロイメントのプランニング

NFV 向けの Data Plane Development Kit 対応 Open vSwitch(OVS-DPDK)デプロイメントを最適化するには、OVS-DPDK が CPU、NUMA ノード、メモリー、NIC などのコンピュートノードのハードウェアをどのように使用するか、およびコンピュートノードに応じた OVS-DPDK の各パラメーターを決定する際の考慮事項を理解する必要があります。

CPU と NUMA トポロジーの概要は、『NFV の製品ガイド』の「 NFV のパフォーマンスの考慮事項 」を参照してください。

7.1. CPU 分割と NUMA トポロジーを使用する OVS-DPDK

OVS-DPDK は、ホスト、ゲスト、および OVS-DPDK 用のハードウェアリソースを分割します。OVS-DPDK Poll Mode Driver (PMD) は、専用のコアを必要とする DPDK アクティブループを実行します。これは、CPU の一覧とヒュージページが OVS-DPDK 専用であることを意味します。

サンプルの分割では、デュアルソケットのコンピュートノード上の 1 NUMA ノードにつき 16 コアが含まれます。NIC はホストと OVS-DPDK 間で共有できないため、トラフィックには追加の NIC が必要です。

OpenStack NFV Hardware Capacities 464931 0118 OVS DPDK
注記

NUMA ノードに DPDK NIC が関連付けられていない場合でも、両方の NUMA ノードで DPDK PMD スレッドを確保する必要があります。

OVS-DPDK パフォーマンスには、NUMA ノードにローカルなメモリーブロックの予約も必要です。メモリーと CPU ピニングに使用する同じ NUMA ノードに関連付けられた NIC を使用してください。ボンディング内の両方のインターフェースが同じ NUMA ノード上の NIC から取得されるようにしてください。

7.2. ワークフローと派生パラメーターについての概要

この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビュー機能についての詳しい情報は、「対象範囲の詳細」を参照してください。

OpenStack Workflow (mistral) サービスを使用すると、利用可能なベアメタルノードのケイパビリティーに基づいてパラメーターを派生することができます。Red Hat OpenStack Platform ワークフローでは、yaml ファイルで実行するタスクおよびアクションのセットを定義します。tripleo-common/workbooks/ ディレクトリーにある derive_params.yaml という事前定義済みのワークブックを使用することができます。このワークブックは、ベアメタルのイントロスペクションで取得した結果から、サポートされる各パラメーターを派生するワークフローを提供します。derive_params.yaml のワークフローは、tripleo-common/workbooks/derive_params_formulas.yaml の計算式を使用して、派生パラメーターを計算します。

注記

derive_params_formulas.yaml の計算式は、お使いの環境に応じて変更することができます。

derive_params.yaml ワークブックは、特定のコンポーザブルロール用の全ノードのハードウェア仕様が同じであることを前提としています。ワークフローは、フレーバーとプロファイルの関連付けと、nova の配置スケジューラーを考慮して、ロールに関連付けられたノードを照合し、そのロールと一致する最初のノードのイントロスペクションデータを使用します。

Red Hat OpenStack Platform ワークフローの詳細は、「ワークフロー および実行に関するトラブルシューティング」を 参照してください。

-p または --plan-environment-file オプションを使用して、カスタムの plan_environment.yaml ファイルを openstack overcloud deploy コマンドに追加することができます。カスタムの plan_environment.yaml ファイルは、ワークブックの一覧と、ワークブックに渡す値を指定します。トリガーされるワークフローは派生パラメーターをマージしてカスタムの plan_environment.yaml に戻し、オーバークラウドのデプロイメントに利用できるようになります。これらの派生パラメーターの結果を使用して、オーバークラウドのイメージを準備することができます。

デプロイメントでの --plan-environment-file オプションの使用方法に関する詳しい情報は、『オーバークラウドの高度なカスタマイズ』の「 プランの環境メタデータ」を 参照してください。

7.3. OVS-DPDK の派生パラメーター

derive_params.yaml のワークフローは、ComputeNeutronOvsDpdk サービスを使用する、対応するロールに関連付けられた DPDK パラメーターを派生します。

ワークフローによって自動的に派生できる OVS-DPDK のパラメーターの一覧は以下のとおりです。

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

OvsDpdkMemoryChannels パラメーターは、イントロスペクションのメモリーバンクデータからは派生できません。これは、メモリースロット名の形式がハードウェア環境によって異なるためです。

多くの場合、OvsDpdkMemoryChannels のデフォルト値は 4 です。ハードウェアのマニュアルを参照して 1 ソケットあたりのメモリーチャネル数を確認し、この値を使用してデフォルト値を上書きします。

設定の詳細は、「ワークフローを使用した DPDK パラメーターの算出」 を参照してください。

7.4. 手動で計算した OVS-DPDK のパラメーターについての概要

本項では、Data Plane Development Kit 対応 Open vSwitch(OVS-DPDK)が director の network_environment.yaml heat テンプレート内のパラメーターを使用して CPU とメモリーを設定し、パフォーマンスを最適化する方法について説明します。この情報を使用して、コンピュートノードでのハードウェアサポートを評価すると共に、そのハードウェアを分割して OVS-DPDK デプロイメントを最適化する最も有効な方法を評価します。

注記

これらの値を自動的に生成する必要がある場合は、derived_parameters.yaml ワークフローを使用できます。詳細は、「 ワークフローと派生パラメーターの概要」を参照してください。

注記

CPU コアを割り当てる際には必ず、論理 CPU と呼ばれる CPU シブリングスレッドをペアにして、物理コアの CPU シブリングスレッドをペアにします。

コンピュートノード上の CPU と NUMA ノードを特定するには、「 NUMA ノードのトポロジーについての理解」を 参照してください。この情報を使用して、CPU と他のパラメーターをマッピングして、ホスト、ゲストインスタンス、OVS-DPDK プロセスのニーズに対応します。

7.4.1. CPU パラメーター

OVS-DPDK は以下の CPU パーティション設定パラメーターを使用します。

OvsPmdCoreList

DPDK Poll Mode Driver (PMD) に使用する CPU コアを提供します。DPDK インターフェースのローカルの NUMA ノードに関連付けられた CPU コアを選択します。OvsPmdCoreList は、Open vSwitch の pmd-cpu-mask の値に使用されます。OvsPmdCoreList パラメーターを使用して、以下の設定を設定します。

  • シブリングスレッドをペアにします。
  • OvsDpdkCoreList のコアをすべて除外します。
  • 両方の NUMA ノード上の 1 番目の物理コアの論理 CPU または両方のスレッドシブリングが割り当てられないようにしてください。これらは OvsDpdkCoreList パラメーターに使用する必要があります。
  • パフォーマンスは、この PMD コアリストに割り当てられる物理コア数によって異なります。DPDK NIC に関連付けられた NUMA ノードで、必要なコアを割り当てます。

  • DPDK 用の NIC が 1 つある NUMA ノードの場合:

    • パフォーマンス要件に基づいて必要な物理コア数を決定し、各物理コアのシブリングスレッドまたは論理 CPU を組み込みます。

  • DPDK 用の NIC がない NUMA ノードの場合：

    • NUMA ノードの最初の物理コアを除く、1 つの物理コアのシブリングスレッド（論理 CPU）を割り当てます。
注記

NUMA ノードに DPDK NIC が関連付けられていない場合でも、両方の NUMA ノードで DPDK PMD スレッドを確保する必要があります。

NovaVcpuPinSet

CPU ピニング用のコアを設定します。コンピュートノードは、ゲストインスタンスにこれらのコアを使用します。NovaVcpuPinSet は nova.conf ファイルの vcpu_pin_set 値として使用されます。NovaVcpuPinSet パラメーターを使用して、以下の設定を設定します。

  • OvsPmdCoreList と OvsDpdkCoreList のコアをすべて除外します。
  • 残りのコアをすべて追加します。
  • シブリングスレッドをペアにします。
NovaComputeCpuSharedSet
エミュレータースレッドに使用するコアを設定します。これにより、nova.conf のパラメータ cpu_shared_set の値が定義されます。このパラメータの値と OvsDpdkCoreList に設定した値を一致させることを推奨します。
IsolCpusList

ホストのプロセスから分離される CPU コアのセット。このパラメーターは、tuned-profiles-cpu-partitioning コンポーネント用の cpu-partitioning-variable.conf ファイルの isolated_cores 値として使用されます。IsolCpusList パラメーターを使用して、以下の設定を設定します。

  • OvsPmdCoreList と NovaVcpuPinSet のコア一覧が一致するようにします。
  • シブリングスレッドをペアにします。
OvsDpdkCoreList

handler および revalidator スレッドなどの、データパス以外の OVS-DPDK プロセス用の CPU コアを提供します。このパラメーターは、マルチ NUMA ノードハードウェア上でのデータパスの全体的なパフォーマンスには影響を与えません。このパラメーターは OVS の dpdk-lcore-mask 値に使用され、それらのコアはホストと共有されます。OvsDpdkCoreList パラメーターを使用して、以下の設定を設定します。

  • NUMA ノードに DPDK NIC が関連付けられていない場合でも、各 NUMA ノードから 1 番目の物理コアおよびシブリングスレッドを割り当てます。
  • これらのコアは、OvsPmdCoreList および NovaVcpuPinSet のコアの一覧と相互に排他的である必要があります。

7.4.2. メモリーパラメーター

OVS-DPDK は、以下のメモリーパラメーターを使用します。

OvsDpdkMemoryChannels

NUMA ノードごとに、CPU 内のメモリーチャネルをマッピングします。OvsDpdkMemoryChannels パラメーターは Open vSwitch(OVS)により other_config:dpdk-extra="-n <value>" 値として使用され ます。OvsDpdkMemoryChannels に必要な値を算出するには、以下の手順に従います。

  • dmidecode -t memory のコマンドを使用するか、お使いのハードウェアのマニュアルを参照して、利用可能なメモリーチャネルの数を確認します。
  • ls /sys/devices/system/node/node* -d のコマンドで NUMA ノードの数を確認します。
  • 利用可能なメモリーチャネル数を NUMA ノード数で除算します。
NovaReservedHostMemory
ホスト上のタスク用にメモリーを MB 単位で確保します。この値は、コンピュートノードにより nova.conf の reserved_host_memory_mb 値として使用されます。静的な推奨値は 4096 MB です。
OvsDpdkSocketMemory

NUMA ノードごとにヒュージページプールから事前に割り当てるメモリーの容量を MB 単位で指定します。この値は、OVS が other_config:dpdk-socket-mem 値として使用されます。OvsDpdkSocketMemory に必要な値を算出するには、以下の手順に従います。

  • コンマ区切りリストで指定します。NUMA ノード上の各 NIC の MTU 値から、OvsDpdkSocketMemory の値を計算します。
  • DPDK NIC のない NUMA ノードの場合は、推奨される静的な値である 1024 MB(1GB)を使用します。

  • OvsDpdkSocketMemory の値は、以下の式で概算します。

    • MEMORY_REQD_PER_MTU = (ROUNDUP_PER_MTU + 800) x (4096 x 64) バイト

      • 800 はオーバーヘッドの値です。
      • 4096 x 64 は mempool 内のパケット数です。
  • NUMA ノードで設定される各 MTU 値の MEMORY_REQD_PER_MTU を追加し、バッファーとして 512 MB をさらに加算します。その値を 1024 の倍数に丸めます。

計算例: MTU 2000 および MTU 9000

DPDK NIC dpdk0 と dpdk1 は同じ NUMA ノード 0 上にあり、それぞれ MTU 9000 と MTU 2000 で設定されています。必要なメモリーを算出する計算例を以下に示します。

  1. MTU 値を 1024 バイトの倍数に丸めます。 

    The MTU value of 9000 becomes 9216 bytes.
The MTU value of 2000 becomes 2048 bytes.

  2. それらの丸めたバイト値に基づいて、各 MTU 値に必要なメモリーを計算します。 

    Memory required for 9000 MTU = (9216 + 800) * (4096*64) = 2625634304
Memory required for 2000 MTU = (2048 + 800) * (4096*64) = 746586112

  3. それらを合わせた必要なメモリーの合計を計算します (バイト単位)。 

    2625634304 + 746586112 + 536870912 = 3909091328 bytes.

    この計算は、(MTU 値 9000 に必要なメモリー) + (MTU 値 2000 に必要なメモリー) + (512 MB バッファー) を示しています。

  4. 必要合計メモリーを MB に変換します。 

    3909091328 / (1024*1024) = 3728 MB.

  5. この値を 1024 の倍数に丸めます。 

    3724 MB rounds up to 4096 MB.

  6. この値を使用して OvsDpdkSocketMemory を設定します。 

        OvsDpdkSocketMemory: “4096,1024”

計算例: MTU 2000

DPDK NIC dpdk0 と dpdk1 は同じ NUMA ノード 0 上にあり、それぞれ MTU 2000 と MTU 2000 で設定されています。必要なメモリーを算出する計算例を以下に示します。

  1. MTU 値を 1024 バイトの倍数に丸めます。 

    The MTU value of 2000 becomes 2048 bytes.

  2. それらの丸めたバイト値に基づいて、各 MTU 値に必要なメモリーを計算します。 

    Memory required for 2000 MTU = (2048 + 800) * (4096*64) = 746586112

  3. それらを合わせた必要なメモリーの合計を計算します (バイト単位)。 

    746586112 + 536870912 = 1283457024 bytes.

    この計算は、(MTU 値 2000 に必要なメモリー) + (512 MB バッファー) を示しています。

  4. 必要合計メモリーを MB に変換します。 

    1283457024 / (1024*1024) = 1224 MB.

  5. この値を 1024 の倍数に丸めます。 

    1224 MB rounds up to 2048 MB.

  6. この値を使用して OvsDpdkSocketMemory を設定します。 

        OvsDpdkSocketMemory: “2048,1024”

7.4.3. ネットワークパラメーター

NeutronDpdkDriverType
DPDK によって使用されるドライバーの種別を設定します。vfio-pci のデフォルト値を使用してください。
NeutronDatapathType
OVS ブリッジ用のデータパスの種別を設定します。DPDK は netdev のデフォルト値を使用してください。
NeutronVhostuserSocketDir
OVS 向けに vhost-user ソケットディレクトリーを設定します。vhost クライアントモード用の /var/lib/vhost_sockets を使用してください。

7.4.4. その他のパラメーター

NovaSchedulerDefaultFilters
要求されたゲストインスタンスに対してコンピュートノードが使用するフィルターの順序付きリストを指定します。
VhostuserSocketGroup
vhost-user ソケットディレクトリーのグループを設定します。デフォルト値は qemu です。VhostuserSocketGroup は hugetlbfs に設定する必要があります。これにより、ovs-vswitchd および qemu プロセスが、virtio-net デバイスを設定するのに使用する共有ヒュージページおよび unix ソケットにアクセスすることができます。この値はロールに固有で、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
  • hugepages count: 利用可能なヒュージページの数を設定します。この値は、ホストの使用可能なメモリーの量によって異なります。利用可能なメモリーの大半を使用してください（ NovaReservedHostMemory を除く）。ヒュージページ数の値は、お使いのコンピュートノードに関連付けられた Red Hat OpenStack Platform フレーバーの範囲内で設定する必要もあります。
  • 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）。hugepagesz ブートパラメーターに一致させるには、1GB を使用します。仮想マシンで使用可能なヒュージページの数は、ブートパラメーターから OvsDpdkSocketMemory を引いた値です。以下の値有効です。

  • small (デフォルト): 最少のページサイズが使用されます。
  • large: 大型のページサイズだけを使用します。x86 アーキテクチャーでは、ページサイズは 2 MB または 1 GB です。
  • any: コンピュートドライバーは大型ページの使用を試みますが、利用できるページがない場合にはデフォルトの小型ページが使用されます。
hw:emulator_threads_policy
heat パラメーター NovaComputeCpuSharedSet で識別した CPU にエミュレータースレッドが固定されるように、このパラメーターの値を share に設定します。エミュレータースレッドが Poll Mode Driver (PMD) またはリアルタイム処理に使用されている vCPU 上で実行されている場合には、パケットロスまたはデッドラインの超過が生じる場合があります。

7.5. 2 NUMA ノード構成の OVS-DPDK デプロイメントの例

この例のコンピュートノードには、以下の 2 つの NUMA ノードが含まれます。

  • NUMA 0 にはコア 0 - 7 があり、シブリングスレッドペアは (0,1)、(2,3)、(4,5)、および (6,7) の構成。
  • NUMA 1 にはコア 8 - 15 があり、シブリングスレッドペアは (8,9)、(10,11)、(12,13)、および (14,15) の構成。
  • 各 NUMA ノードが物理 NIC (NUMA 0 上の NIC1 と NUMA 1 上の NIC2) に接続されている。
OpenStack NFV NUMA Nodes 453316 0717 ECE OVS DPDK Deployment
注記

各 NUMA ノード上の 1 番目の物理コア（あるいは両スレッドペア）（0,1 および 8,9）は、データパス以外の DPDK プロセス(OvsDpdkCoreList)用に確保します。

この例では、MTU が 1500 に設定されており、全ユースケースで OvsDpdkSocketMemory が同じであることも前提です。 

OvsDpdkSocketMemory: “1024,1024”

NIC 1 は DPDK 用で、1 つの物理コアは PMD 用

このユースケースでは、NUMA 0 の物理コアの 1 つを PMD 用に割り当てます。NUMA 1 の NIC では DPDK は有効化されていませんが、その NUMA ノードの物理コアの 1 つも割り当てる必要があります。OvsDpdkCoreList 用に確保されていない残りのコアは、ゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。 

OvsPmdCoreList: “2,3,10,11”
NovaVcpuPinSet: “4,5,6,7,12,13,14,15”

NIC 1 は DPDK 用で、2 つの物理コアは PMD 用

このユースケースでは、NUMA 0 の物理コアの 2 つを PMD 用に割り当てます。NUMA 1 の NIC では DPDK は有効化されていませんが、その NUMA ノードの物理コアの 1 つも割り当てる必要があります。OvsDpdkCoreList 用に確保されていない残りのコアは、ゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。 

OvsPmdCoreList: “2,3,4,5,10,11”
NovaVcpuPinSet: “6,7,12,13,14,15”

NIC 2 は DPDK 用で、1 つの物理コアは PMD 用

このユースケースでは、NUMA 1 の物理コアの 1 つを PMD 用に割り当てます。NUMA 0 の NIC では DPDK は有効化されていませんが、その NUMA ノードの物理コアの 1 つも割り当てる必要があります。残りのコア (OvsDpdkCoreList 用に確保されていないコア) はゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。 

OvsPmdCoreList: “2,3,10,11”
NovaVcpuPinSet: “4,5,6,7,12,13,14,15”

NIC 2 は DPDK 用で、2 つの物理コアは PMD 用

このユースケースでは、NUMA 1 の物理コアの 2 つを PMD 用に割り当てます。NUMA 0 の NIC では DPDK は有効化されていませんが、その NUMA ノードの物理コアの 1 つも割り当てる必要があります。残りのコア (OvsDpdkCoreList 用に確保されていないコア) はゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。 

OvsPmdCoreList: “2,3,10,11,12,13”
NovaVcpuPinSet: “4,5,6,7,14,15”

NIC 1 と NIC2 は DPDK 用で、2 つの物理コアは PMD 用

このユースケースでは、各 NUMA ノードの物理コアの 2 つを PMD 用に割り当てます。残りのコア (OvsDpdkCoreList 用に確保されていないコア) はゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。 

OvsPmdCoreList: “2,3,4,5,10,11,12,13”
NovaVcpuPinSet: “6,7,14,15”

7.6. NFV OVS-DPDK デプロイメントのトポロジー

以下のデプロイメント例は、2 つの仮想ネットワーク機能(VNF)からなる Data Plane Development Kit 対応 Open vSwitch(OVS-DPDK)の構成を示しています。各 VNF には、2 つのインターフェース（ mgt で示された管理インターフェースおよびデータプレーンインターフェース）があります。OVS-DPDK デプロイメントでは、VNF は、物理インターフェースをサポートする組み込みの DPDK で稼働します。OVS-DPDK は、vSwitch レベルでボンディングを管理します。OVS-DPDK デプロイメントでは、カーネルと OVS-DPDK の NIC を混在させないでください。これにより、パフォーマンスが低下する可能性があるためです。仮想マシン向けのベースプロバイダーネットワークに接続された管理(mgt)ネットワークを分離するには、追加の NIC があることを確認します。コンピュートノードは、Red Hat OpenStack Platform(RHOSP)API 管理向けの標準 NIC 2 つで構成されます。これは、Ceph API で再利用できますが、RHOSP テナントとは一切共有できません。

NFV OVS-DPDK deployment

NFV OVS-DPDK のトポロジー

以下の図には、NFV ユースケース向けの OVS_DPDK のトポロジーを示しています。この環境は、1 または 10 Gbps の NIC を搭載したコンピュートノードおよびコントローラーノードと、director ノードで構成されます。

NFV OVS-DPDK Topology

第8章 OVS-DPDK デプロイメントの設定

本項では、Red Hat OpenStack Platform(RHOSP)環境内で Open vSwitch(OVS-DPDK)対応の DPDK をデプロイする方法について説明します。オーバークラウドは、通常コントローラーノードやコンピュートノードなどの事前定義済みロールのノードと、異なる種別のストレージノードで構成されます。これらのデフォルトロールにはそれぞれ、director ノード上のコア heat テンプレートで定義されている一式のサービスが含まれます。

オーバークラウドをデプロイする前に、アンダークラウドのインストールと設定が完了している必要があります。詳しくは、『 director のインストールと使用方法』を参照し てください。

重要

OVS-DPDK 向けの RHOSP ネットワークを最適化するには、network-environment.yaml ファイルに設定する OVS-DPDK パラメーターの最も適切な値を決定する必要があります。

注記

これらの director Heat テンプレートによって変更される etc/tuned/cpu-partitioning-variables.conf の isolated_cores またはその他の値は編集/変更しないでください。

8.1. ワークフローを使用した DPDK パラメーターの算出

この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビュー機能についての詳しい情報は、「対象範囲の詳細」を参照してください。

DPDK 向けの Mistral ワークフローに関する概要は、「ワークフローと派生パラメーターについての概要」 を参照してください。

前提条件

このワークフローで取得されるデータを生成するには、ハードウェア inspection_extras を含むベアメタルのイントロスペクションを有効化しておく必要があります。ハードウェア検査の追加パラメーターはデフォルトで有効化されます。「 ノードのハードウェアの検査 」を参照してください。

DPDK 向けのワークフローと入力パラメーターの定義

OVS-DPDK ワークフローで指定することができる入力パラメーターの一覧を以下に示します。

num_phy_cores_per_numa_node_for_pmd
この入力パラメーターは、DPDK NIC に関連付けられた NUMA ノードの必要最小限のコア数を指定します。DPDK NIC に関連付けられていないその他の NUMA ノードには、物理コアが 1 つ割り当てられます。このパラメーターは 1 に設定するようにしてください。
huge_page_allocation_percentage
この入力パラメーターは、ヒュージページとして設定可能な合計メモリー中 (NovaReservedHostMemory を除く) の必要なパーセンテージを指定します。KernelArgs パラメーターは、指定した huge_page_allocation_percentage に基づいて計算されたヒュージページを使用して派生されます。このパラメーターは 50 に設定するようにしてください。

ワークフローは、これらの入力パラメーターとベアメタルのイントロスペクション情報を使用して、適切な DPDK パラメーターの値を算出します。

DPDK のワークフローおよび入力パラメーターを定義するには、以下の手順を実施します。

  1. usr/share/openstack-tripleo-heat-templates/plan-samples/plan-environment-derived-params.yaml ファイルをローカルディレクトリーにコピーし、ご自分の環境に合わせて入力パラメーターを設定します。 

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

  2. 以下のオプションを指定して openstack overcloud deploy コマンドを実行します。

    • update-plan-only オプション
    • ロールファイルおよびご自分の環境に固有の全環境ファイル

    • plan-environment-derived-parms.yaml ファイル (--plan-environment-file オプションの引数) 

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

このコマンドの出力には、派生した結果が表示されます。これは、plan-environment.yaml ファイルにもマージされます。 

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

OvsDpdkMemoryChannels パラメーターをイントロスペクションの情報から派生することはできません。大半の場合、この値は 4 に設定すべきです。

派生パラメーターを使用したオーバークラウドのデプロイ

これらの派生パラメーターを使用してオーバークラウドをデプロイするには、以下の手順を実施します。

  1. 派生パラメーターをデプロイコマンドの出力から network-environment.yaml ファイルにコピーします。 

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

    これらのパラメーターは、特定のロール ComputeOvsDpdk に適用されます。これらのパラメーターはグローバルに適用することはできますが、ロール固有のパラメーターはグローバルパラメーターを上書きします。

  2. ロールファイルおよびご自分の環境に固有の全環境ファイルを使用して、オーバークラウドをデプロイします。詳しい情報は、『 Deploying the Overcloud 』を参照してください。
注記

Compute、ComputeOvsDpdk、および ComputeSriov が設定されたクラスターでは、既存のワークフローで、パラメーターを派生する既存のワークフローにより、ComputeOvsDpdk ロールだけに式が適用されます。

8.2. OVS-DPDK のトポロジー

Red Hat OpenStack Platform では、コンポーザブルロール機能を使用し、各ロールにサービスを追加/削除してカスタムのデプロイメントロールを作成できます。コンポーザブルロールの詳細は、『オーバークラウドの高度なカスタマイズ』の「 コンポーザブルサービスと カスタムロール」を参照してください。

以下の図は、コントロールプレーンとデータプレーン用にポートが 2 つボンディングされている Data Plane Development Kit 対応 Open vSwitch(OVS-DPDK)トポロジーの例を示しています。

OpenStack NFV Config Guide Topology 450694 0617 ECE OVS DPDK

OVS-DPDK を設定するには、以下のタスクを実行します。

  1. コンポーザブルロールを使用する場合には、roles_data.yaml ファイルをコピーして編集し、OVS-DPDK 用のカスタムロールを追加します。
  2. 適切な network-environment.yaml ファイルを更新して、カーネル引数と DPDK 引数のパラメーターを追加します。
  3. compute.yaml ファイルを更新して、DPDK インターフェース用のブリッジを追加します。
  4. controller.yaml ファイルを更新して、DPDK インターフェースパラメーター用の同じブリッジ情報を追加します。
  5. overcloud_deploy.sh スクリプトを実行して、DPDK パラメーターを使用してオーバークラウドをデプロイします。
注記

本ガイドでは、CPU の割り当て、メモリーの確保、NIC の設定の例を紹介します。これらは、トポロジーとユースケースによって異なる場合があります。ハードウェアと設定オプションの詳細は、『 ネットワーク機能仮想化(NFV)の製品ガイド』 および「 2章ハードウェア要件 」を参照してください。

前提条件
  • OVS 2.10
  • DPDK 17
  • テスト済み NIC。NFV 向けのテスト済み NIC の一覧は、「テスト済み NIC」を参照してください。
注記

Red Hat OpenStack Platform は、OVS-DPDK デプロイメントでは OVS クライアントモードで動作します。

8.3. OVS-DPDK インターフェースの MTU 値の設定

Red Hat OpenStack Platform は Data Plane Development Kit 対応 Open vSwitch (OVS-DPDK) 向けにジャンボフレームをサポートしています。ジャンボフレーム用の最大伝送単位 (MTU) 値を設定するには、以下の操作を行う必要があります。

  • network-environment.yaml ファイルで、ネットワークのグローバル MTU 値を設定する。
  • compute.yaml ファイルで、物理 DPDK ポートの MTU 値を設定する。この値は、vhost のユーザーインターフェースでも使用されます。
  • コンピュートノード上の任意のゲストインスタンスで MTU 値を設定し、設定内でエンドツーエンドに同等の MTU 値が設定されるようにする。
注記

VXLAN パケットには追加で 50 バイトがヘッダーに含まれます。MTU の必要値は、ヘッダーの追加バイト値に基づいて計算してください。たとえば、MTU 値 が 9000 の場合には、これらの追加バイト値を計算に入れると、VXLAN トンネルの MTU 値は 8950 となります。

注記

物理 NIC は DPDK PMD によって制御され、compute.yaml ファイルで設定されているのを同じ MTU 値が適用されるので、特別な設定は必要ありません。MTU 値には、物理 NIC でサポートされているよりも高い値を設定することはできません。

OVS-DPDK インターフェースの MTU 値を設定するには、以下の手順を実行します。

  1. network-environment.yaml ファイルで NeutronGlobalPhysnetMtu パラメーターを設定します。 

    parameter_defaults:
  # MTU global configuration
  NeutronGlobalPhysnetMtu: 9000
    注記

    network-environment.yaml ファイルの NeutronDpdkSocketMemory の値がジャンボフレームをサポートするのに十分に大きな値であることを確認します。詳しくは、「メモリーパラメーター」を参照してください。

  2. controller.yaml ファイルでコンピュートノードへのブリッジ上の MTU 値を設定します。 

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

  3. compute.yaml ファイルで OVS-DPDK ボンディング用の MTU 値を設定します。 

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

8.4. セキュリティーグループのファイアウォールの設定

データプレーンインターフェースのステートフルファイアウォールには、高いパフォーマンスが要求されます。これらのインターフェースを保護するためには、仮想ネットワーク機能 (VNF) として通信業界グレードのファイアウォールをデプロイすることを検討してください。

コントロールプレーンのインターフェースを設定するには、NeutronOVSFirewallDriver パラメーターを openvswitch に設定します。これにより、Red Hat OpenStack Platform Networking がフローベースの OVS ファイアウォールドライバーを使用するように設定します。この設定は、network-environment.yaml ファイルの parameter_defaults セクションで行います。

以下に例を示します。 

parameter_defaults:
  NeutronOVSFirewallDriver: openvswitch

該当する場合は、データプレーンインターフェースの OVS ファイアウォールドライバーを無効にすることが重要です。そのためには、openstack port set コマンドを使用します。

以下に例を示します。 

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

8.5. OVS-DPDK インターフェース向けのマルチキューの設定

コンピュートノード上の Data Plane Development Kit 対応 Open vSwitch(OVS-DPDK)のインターフェースに同じ数のキューを設定するには、compute.yaml ファイルを変更します。 

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

8.6. オーバークラウドのデプロイ

  1. DPDK Compute ロールのパラメーターが 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"

  2. openstack overcloud deploy コマンドを使用して、オーバークラウドをデプロイします。

    • ロールファイルおよびご自分の環境に固有の全環境ファイルを追加します。

    • /usr/share/openstack-tripleo-heat-templates/environments からの host-config-and-reboot.yaml ファイルをデプロイメントスクリプトに追加して、KernelAgs および TunedProfile パラメーターを適用します。 

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

8.7. 既知の制限

NFV のユースケース向けに Red Hat OpenStack Platform で OVS-DPDK を設定する場合には制限事項があります。

  • コントロールプレーンのネットワークには、Linux ボンディングを使用します。パフォーマンスを最適化するには、Linux ボンディングの PCI デバイスが同じ NUMA ノード上にあることを確認してください。Red Hat では、Neutron Linux ブリッジ設定をサポートしません。
  • OVS-DPDK を使用するホスト上で実行される各インスタンスにはヒュージページが必要です。ゲストのヒュージページがない場合には、インターフェースは表示されても機能しません。
  • OVS-DPDK を使用する場合には、分散仮想ルーター (DVR) 等の TAP デバイスを使用するサービスのパフォーマンスが低下します。得られるパフォーマンスは、実稼働環境に適するものではありません。
  • OVS-DPDK を使用する場合には、同じコンピュートノード上の全ブリッジが ovs_user_bridge の種別でなければなりません。director は設定を受け入れることができますが、Red Hat は同じノード上で ovs_bridge と ovs_user_bridge が混在する構成はサポートしていません。

8.8. OVS-DPDK 用のフレーバーの作成とインスタンスのデプロイ

NFV を実装する Red Hat OpenStack Platform デプロイメント向けに Data Plane Development Kit 対応 Open vSwitch(OVS-DPDK)を設定したら、以下の手順に従ってフレーバーを作成してインスタンスをデプロイすることができます。

  1. OVS-DPDK 用のアグリゲートグループを作成し、適切なホストを追加します。定義するフレーバーメタデータに一致するメタデータを定義します (例: dpdk=true)。 

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

    ホストアグリゲートを使用して、CPU ピニングされたインスタンスをピニングされていないインスタンスから分離します。CPU ピニングが設定されていないインスタンスには、CPU ピニングが設定されたインスタンスの再ソース要件が異なります。

  2. フレーバーを作成します。 

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

  3. 追加のフレーバー属性を設定します。定義したメタデータ (dpdk=true) と DPDK アグリゲートで定義したメタデータが一致している点に注意してください。 

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

    この例では、m1.medium_huge_4cpu はフレーバー名で、残りはそのフレーバーの他の属性を設定しています。

    パフォーマンス向上のためのエミュレータースレッドポリシーについての詳しい情報は、「 専用の物理 CPU で実行されるエミュレータースレッドの設定」を参照 してください。

  4. ネットワークを作成します。 

    # openstack network create net1 --provider-physical-network tenant --provider-network-type vlan --provider-segment <VLAN-ID>
# openstack subnet create subnet1 --network net1 --subnet-range 192.0.2.0/24 --dhcp

  5. インスタンスをデプロイします。 

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

OVS-DPDK と共に multi-queue を使用するには、フレーバーで hw.vif_multiqueue_enabled 属性を設定する前に、イメージで hw_vif_multiqueue_enabled 属性を設定します。

  1. イメージの属性を設定します。 

    # openstack image set --property hw_vif_multiqueue_enabled=true <image>

  2. 追加のフレーバー属性を設定します。 

    # openstack flavor set --property hw:vif_multiqueue_enabled=true <flavor>

8.9. 設定のトラブルシューティング

本項では、Data Plane Development Kit 対応 Open vSwitch (OVS-DPDK) 設定のトラブルシューティングの手順を説明します。

  1. ブリッジの設定を見直して、ブリッジが datapath_type=netdev で作成されたことを確認します。 

    # ovs-vsctl list bridge br0
_uuid               : bdce0825-e263-4d15-b256-f01222df96f3
auto_attach         : []
controller          : []
datapath_id         : "00002608cebd154d"
datapath_type       : netdev
datapath_version    : "<built-in>"
external_ids        : {}
fail_mode           : []
flood_vlans         : []
flow_tables         : {}
ipfix               : []
mcast_snooping_enable: false
mirrors             : []
name                : "br0"
netflow             : []
other_config        : {}
ports               : [52725b91-de7f-41e7-bb49-3b7e50354138]
protocols           : []
rstp_enable         : false
rstp_status         : {}
sflow               : []
status              : {}
stp_enable          : false

  2. docker コンテナー neutron_ovs_agent が自動的に起動するように設定されていることを確認します。 

    # docker inspect neutron_ovs_agent | grep -A1 RestartPolicy
            "RestartPolicy": {
                "Name": "always",

  3. コンテナーに起動に問題がある場合には、関連するメッセージを表示できます。 

    # less /var/log/containers/neutron/openvswitch-agent.log

  4. ovs-dpdk の PMD CPU マスクが CPU にピニングされていることを確認します。HT の場合には、シブリング CPU を使用します。

    たとえば、CPU 4 を確認します。 

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

    CPU 4 および 20 を使用します。 

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

    ステータスを表示します。 

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

第9章 Red Hat OpenStack Platform 環境の調整

9.1. エミュレータースレッドの固定

エミュレータースレッドは、仮想マシンのハードウェアエミュレーションの割り込み要求およびノンブロッキングプロセスを処理します。これらのスレッドは、ゲストが処理に使用する vCPU 全体で共有されます。Poll Mode Driver(PMD)またはリアルタイム処理に使用されるスレッドがこれらの仮想 CPU で実行される場合、パケットロスまたはデッドラインの超過が生じる可能性があります。

スレッドを独自の vCPU に固定して、エミュレータースレッドを仮想マシン処理タスクから分離することができます。その結果、パフォーマンスが向上します。

9.1.1. エミュレータースレッドをホストする CPU の設定

パフォーマンスを向上させるために、エミュレータースレッドをホストするために pCPU のサブセットを確保します。Red Hat は、OvsDpdkCoreList パラメーターで識別される pCPUs を使用することを推奨します。

手順

  1. 特定のロールに NovaComputeCpuSharedSet を定義してオーバークラウドをデプロイします。NovaComputeCpuSharedSet の値は、そのロール内のホストの nova.conf ファイルの cpu_shared_set パラメーターに適用されます。 

    parameter_defaults:
    ComputeOvsDpdkParameters:
        OvsDpdkCoreList: “0-1,16-17”
        NovaComputeCpuSharedSet: “0-1,16-17”

  2. エミュレータースレッドが共有プールに分離されたインスタンスをビルドするためのフレーバーを作成します。 

    openstack flavor create --ram <size_mb> --disk <size_gb> --vcpus <vcpus> <flavor>

  3. hw:emulator_threads_policy 追加仕様を追加し、値を share に設定します。このフレーバーで作成されたインスタンスは、nova.conf ファイルの cpu_share_set パラメーターで定義された仮想 CPU を使用します。 

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

nova.conf ファイルの cpu_share_set パラメーターを手動で設定するか、heat を使用してこの追加仕様の共有ポリシーを有効にする必要があります。

9.1.2. エミュレータースレッドが固定されていることの確認

手順

  1. 指定したインスタンスのホストとインスタンス名を特定します。 

    openstack server show <instance_id>

  2. SSH を使用して、特定したホストに heat-admin としてログインします。 

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

9.2. NFV ワークロード向けの RT-KVM の有効化

本項では、Red Hat OpenStack Platform 向けに Red Hat Enterprise Linux 8.0 Real Time KVM(RT-KVM)をインストールおよび設定する手順を説明します。Red Hat OpenStack Platform は、リアルタイムに Red Hat Enterprise Linux をプロビジョニングするリアルタイムコンピュートノードロールと、追加の RT-KVM カーネルモジュール、およびコンピュートノードの自動設定を提供します。

9.2.1. RT-KVM コンピュートノードのプランニング

RT-KVM コンピュートノードには、Red Hat 認定済みサーバーを使用する必要があります。詳しくは、Red Hat Enterprise Linux for Real Time 7 用認定サーバー を参照してください。

RT-KVM 用の rhel-8-server-nfv-rpms リポジトリーを有効にしてシステムを最新の状態に維持する方法についての詳細は、『director のインストールと使用方法』の「 アンダークラウドの登録と更新」を 参照してください。

注記

このリポジトリーにアクセスするには、別途 Red Hat OpenStack Platform for Real Time SKU のサブスクリプションが必要です。

real-time のイメージのビルド

Real-time コンピュートノード用のオーバークラウドイメージをビルドするには、以下のステップを実行します。

  1. アンダークラウドに libguestfs-tools パッケージをインストールして、virt-customize ツールを取得します。 

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

    アンダークラウドに libguestfs-tools パッケージをインストールする場合は、アンダークラウドの tripleo_iscsid サービスとのポートの競合を避けるために iscsid.socket を無効にします。 

    $ sudo systemctl disable --now iscsid.socket

  2. イメージを抽出します。 

    (undercloud) [stack@undercloud-0 ~]$ tar -xf /usr/share/rhosp-director-images/overcloud-full.tar
(undercloud) [stack@undercloud-0 ~]$ tar -xf /usr/share/rhosp-director-images/ironic-python-agent.tar

  3. デフォルトのイメージをコピーします。 

    (undercloud) [stack@undercloud-0 ~]$ cp overcloud-full.qcow2 overcloud-realtime-compute.qcow2

  4. イメージを登録して、カスタマイズに適切な Red Hat のリポジトリーを有効にします。以下の例の [username] および [password] を有効な認証情報に置き換えてください。 

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

    コマンドプロンプトで認証情報を使用したら、そのつど履歴ファイルから削除してください。history -d コマンドの後に行番号を指定して、履歴内の個々の行を削除することができます。

  5. アカウントのサブスクリプションからプール ID の一覧を取得し、適切なプール ID をイメージにアタッチします。 

    sudo subscription-manager list --all --available | less
...
virt-customize -a overcloud-realtime-compute.qcow2 --run-command \
'subscription-manager attach --pool [pool-ID]'

  6. Red Hat OpenStack Platform で NFV を使用するのに必要なリポジトリーを追加します。 

    virt-customize -a overcloud-realtime-compute.qcow2 --run-command \
'sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms \
--enable=rhel-8-for-x86_64-appstream-rpms \
--enable=rhel-8-for-x86_64-highavailability-rpms \
--enable=ansible-2.8-for-rhel-8-x86_64-rpms \
--enable=openstack-15-for-rhel-8-x86_64-rpms \
--enable=rhel-8-for-x86_64-nfv-rpms \
--enable=advanced-virt-for-rhel-8-x86_64-rpms \
--enable=fast-datapath-for-rhel-8-x86_64-rpms'

  7. イメージ上でリアルタイム機能を設定するためのスクリプトを作成します。 

    (undercloud) [stack@undercloud-0 ~]$ cat <<'EOF' > rt.sh
  #!/bin/bash

  set -eux

  dnf -v -y --setopt=protected_packages= erase kernel.$(uname -m)
  dnf -v -y install kernel-rt kernel-rt-kvm tuned-profiles-nfv-host
  EOF

  8. RT イメージを設定するスクリプトを実行します。 

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

    rt.sh スクリプトの出力に「 grubby fatal error: unable to find a suitable template」というエラー が表示される場合があります。このエラーは無視しても問題ありません。

  9. パッケージが正しくインストールされていることを確認するには、以前のコマンドで作成した virt-customize.log ファイルを調べます。 

    (undercloud) [stack@undercloud-0 ~]$ cat virt-customize.log | grep Verifying

  Verifying  : kernel-3.10.0-957.el7.x86_64                                 1/1
  Verifying  : 10:qemu-kvm-tools-rhev-2.12.0-18.el7_6.1.x86_64              1/8
  Verifying  : tuned-profiles-realtime-2.10.0-6.el7_6.3.noarch              2/8
  Verifying  : linux-firmware-20180911-69.git85c5d90.el7.noarch             3/8
  Verifying  : tuned-profiles-nfv-host-2.10.0-6.el7_6.3.noarch              4/8
  Verifying  : kernel-rt-kvm-3.10.0-957.10.1.rt56.921.el7.x86_64            5/8
  Verifying  : tuna-0.13-6.el7.noarch                                       6/8
  Verifying  : kernel-rt-3.10.0-957.10.1.rt56.921.el7.x86_64                7/8
  Verifying  : rt-setup-2.0-6.el7.x86_64                                    8/8

  10. SELinux の再ラベル付けをします。 

    (undercloud) [stack@undercloud-0 ~]$ virt-customize -a overcloud-realtime-compute.qcow2 --selinux-relabel

  11. vmlinuz および initrd を抽出します。 

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

    vmlinuz および initramfs のファイル名に含まれるソフトウェアバージョンは、カーネルバージョンによって異なります。

  12. イメージをアップロードします。 

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

これで、選択したコンピュートノード上の ComputeOvsDpdkRT コンポーザブルロールで使用することのできる real-time イメージの準備ができました。

RT-KVM コンピュートノード上での BIOS 設定の変更

RT-KVM コンピュートノードのレイテンシーを短縮するには、BIOS 設定を変更します。コンピュートノードの BIOS 設定で、以下の機能のオプションをすべて無効にします。

  • 電源管理
  • ハイパースレッディング
  • CPU のスリープ状態
  • 論理プロセッサー

これらの設定に関する説明は、「 BIOS パラメーターの設定」を 参照してください。BIOS 設定の変更方法に関する詳しい情報は、ハードウェアの製造会社のドキュメントを参照してください。

9.2.2. RT-KVM 対応の OVS-DPDK の設定

注記

OVS-DPDK 向けの OpenStack ネットワークを最適化するには、network-environment.yaml ファイルで設定する OVS-DPDK パラメーターの最適な値を判断します。詳細は、「ワークフローを使用した DPDK パラメーターの算出」 を参照してください。

9.2.2.1. ComputeOvsDpdk コンポーザブルロールの生成

ComputeOvsDpdkRT ロールを使用して、real-time の Compute イメージを使用するコンピュートノードを指定します。

  1. ComputeOvsDpdkRT ロール向けに roles_data.yaml を生成します。 

    # (undercloud) [stack@undercloud-0 ~]$ openstack overcloud roles generate -o roles_data.yaml Controller ComputeOvsDpdkRT
9.2.2.2. OVS-DPDK パラメーターの設定
重要

不適切な値で Data Plane Development Kit(DPDK)をデプロイすると、デプロイメントが失敗したり、不安定になる可能性があります。OVS-DPDK 向けの Red Hat OpenStack Platform ネットワークを最適化するには、network-environment.yaml ファイルで設定する OVS-DPDK パラメーターの最適な値を判断します。詳細は、「ワークフローを使用した DPDK パラメーターの算出」 を参照してください。

  1. resource_registry セクションに、使用する OVS-DPDK ロールの nic 設定を追加します。 

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

  2. parameter_defaults セクションで、OVS-DPDK および RT-KVM のパラメーターを設定します。 

      # DPDK compute node.
  ComputeOvsDpdkRTParameters:
    KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=1-7,17-23,9-15,25-31"
    TunedProfileName: "realtime-virtual-host"
    IsolCpusList: "1,2,3,4,5,6,7,9,10,17,18,19,20,21,22,23,11,12,13,14,15,25,26,27,28,29,30,31"
    NovaVcpuPinSet: ['2,3,4,5,6,7,18,19,20,21,22,23,10,11,12,13,14,15,26,27,28,29,30,31']
    NovaReservedHostMemory: 4096
    OvsDpdkSocketMemory: "1024,1024"
    OvsDpdkMemoryChannels: "4"
    OvsDpdkCoreList: "0,16,8,24"
    OvsPmdCoreList: "1,17,9,25"
    VhostuserSocketGroup: "hugetlbfs"
  ComputeOvsDpdkRTImage: "overcloud-realtime-compute"
9.2.2.2.1. オーバークラウドのデプロイ

ML2-OVS 向けのオーバークラウドをデプロイします。 

(undercloud) [stack@undercloud-0 ~]$ openstack overcloud deploy \
--templates \
-r /home/stack/ospd-15-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/neutron-ovs.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs-dpdk.yaml \
-e /home/stack/ospd-15-vxlan-dpdk-data-bonding-rt-hybrid/containers-prepare-parameter.yaml \
-e /home/stack/ospd-15-vxlan-dpdk-data-bonding-rt-hybrid/network-environment.yaml

9.2.3. RT-KVM インスタンスの起動

リアルタイム対応のコンピュートノードで RT-KVM インスタンスを起動するには、以下の手順を実行します。

  1. オーバークラウド上に RT-KVM フレーバーを作成します。 

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

  2. RT-KVM インスタンスを起動します。 

    # openstack server create  --image <rhel> --flavor r1.small --nic net-id=<dpdk-net> test-rt

  3. (オプション) インスタンスが割り当てられたエミュレータースレッドを使用していることを確認します。 

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

9.3. 信頼済み Virtual Function

Virtual Function (VF) が特権を必要とする操作を実施できるように、VF を信頼するように Physical Function (PF) を設定することができます。たとえば、この設定を使用して、VF がプロミスキャスモードを有効にすることやハードウェアアドレスを変更することを許可することができます。

9.3.1. 信頼の付与

前提条件
  • Red Hat OpenStack Platform director を使用した稼働中のインストール
手順

Physical Function が Virtual Function を信頼するのを有効にするのに必要なパラメーターを使用してオーバークラウドをデプロイするには、以下の手順を実施します。

  1. parameter_defaults セクションに NeutronPhysicalDevMappings パラメーターを追加して、論理ネットワーク名と物理インターフェース間のリンクを作成します。 

    parameter_defaults:
  NeutronPhysicalDevMappings: "sriov2:p5p2"

  2. SR-IOV に関する既存のパラメーターに、新たな属性「trusted」を追加します。 

    parameter_defaults:
  NeutronPhysicalDevMappings: "sriov2:p5p2"
  NeutronSriovNumVFs: ["p5p2:8"]
  NovaPCIPassthrough:
    - devname: "p5p2"
      physical_network: "sriov2"
      trusted: "true"
    注記

    値 true を二重引用符で囲む必要があります ("true")。

    重要

    以下のステップは、安全な環境でのみ実施してください。この手順では、非管理者アカウントで信頼済みポートをバインドできるようにします。

  3. 権限を変更し、ユーザーがポートのバインディングを作成および更新するのを許可します。 

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

9.3.2. 信頼済み VF の活用

信頼済み VF を使用するには、完全にデプロイされたオーバークラウドで以下の手順を実施します。

信頼済み VF ネットワークの作成

  1. 種別 vlan のネットワークを作成します。 

    openstack network create trusted_vf_network  --provider-network-type vlan \
 --provider-segment 111 --provider-physical-network sriov2 \
 --external --disable-port-security

  2. サブネットを作成します。 

    openstack subnet create --network trusted_vf_network \
  --ip-version 4 --subnet-range 192.168.111.0/24 --no-dhcp \
 subnet-trusted_vf_network

  3. vnic-type オプションを direct に、binding-profile オプションを true に、それぞれ設定してポートを作成します。 

    openstack port create --network sriov111 \
--vnic-type direct --binding-profile trusted=true \
sriov111_port_trusted

  4. インスタンスを作成し、それを前のステップで作成した信頼済みポートにバインドします。 

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

ハイパーバイザー上での信頼済み Virtual Function 設定の確認

  1. 新たに作成したインスタンスをホストするコンピュートノード上で、以下のコマンドを実行します。 
# ip link
7: p5p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether b4:96:91:1c:40:fa brd ff:ff:ff:ff:ff:ff
    vf 6 MAC fa:16:3e:b8:91:c2, vlan 111, spoof checking off, link-state auto, trust on, query_rss off
    vf 7 MAC fa:16:3e:84:cf:c8, vlan 111, spoof checking off, link-state auto, trust off, query_rss off
  1. ip link コマンドの出力を表示し、Virtual Function の信頼ステータスが trust on であることを確認します。上記の出力例には、2 つのポートが含まれる環境の詳細が示されています。vf 6 に trust on のテキストが含まれている点に注意してください。

9.4. 受信/送信キューサイズの設定

以下に示す理由により、3.5 百万パケット毎秒 (mpps) を超える高いパケットレートでは、パケットロスが生じる場合があります。

  • ネットワークの中断
  • SMI
  • 仮想ネットワーク機能におけるパケット処理のレイテンシー

パケットロスを防ぐには、キューサイズをデフォルトの 512 から最大の 1024 に増やします。

前提条件
  • 受信キューサイズを設定するには、libvirt v2.3 および QEMU v2.7 が必要です。
  • 送信キューサイズを設定するには、libvirt v3.7 および QEMU v2.10 が必要です。
手順

  1. 受信および送信キューサイズを増やすには、該当する director ロールの parameter_defaults: セクションに以下の行を追加します。ComputeOvsDpdk ロールにおける例を以下に示します。 

    parameter_defaults:
  ComputeOvsDpdkParameters:
    -NovaLibvirtRxQueueSize: 1024
    -NovaLibvirtTxQueueSize: 1024
テスト

  • nova.conf ファイルで、受信キューサイズおよび送信キューサイズの値を確認することができます。 

    [libvirt]
rx_queue_size=1024
tx_queue_size=1024

  • コンピュートホストの libvirt により生成された仮想マシンインスタンスの XML ファイルで、受信キューサイズおよび送信キューサイズの値を確認することができます。 

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

    受信キューサイズおよび送信キューサイズの値を検証するには、KVM ホストで以下のコマンドを使用します。 

    $ virsh dumpxml <vm name> | grep queue_size
  • パフォーマンスの向上を確認することができます (例: 3.8 mpps/コアのレートでフレーム損失なし)。

9.5. NUMA 対応 vSwitch の設定

重要

この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビュー機能についての詳しい情報は、「対象範囲の詳細」を参照してください。

NUMA 対応 vSwitch を実装するには、ご自分のハードウェア構成の以下のコンポーネントを確認してください。

  • 物理ネットワークの数
  • PCI カードの配置
  • サーバーの物理アーキテクチャー

PCIe NIC 等のメモリーマップト I/O (MMIO) デバイスは、特定の NUMA ノードに関連付けられます。仮想マシンと NIC が異なる NUMA ノードにあると、パフォーマンスが大幅に低下します。パフォーマンスを向上させるためには、PCIe NIC の配置とインスタンスの処理を同じ NUMA ノードに一致させます。

この機能を使用して、物理ネットワークを共有するインスタンスが同じ NUMA ノードに配置されるようにします。データセンターのハードウェアの最適化するには、複数ネットワーク、異なるネットワーク種別、またはボンディングを使用して、負荷を共有する仮想マシンを活用します。

重要

NUMA ノードの負荷共有およびネットワークアクセスを正しく設計するためには、PCIe スロットと NUMA ノードのマッピングを把握する必要があります。お使いの特定ハードウェアの詳細情報は、ベンダーのドキュメントを参照してください。

複数 NUMA にまたがる設定を防ぐためには、NIC の場所を Nova に提供して、仮想マシンを正しい NUMA ノードに配置します。

前提条件
  • フィルター「NUMATopologyFilter」を有効にしていること
手順
  1. 新たに NeutronPhysnetNUMANodesMapping パラメーターを設定して、物理ネットワークと物理ネットワークに関連付ける NUMA ノードをマッピングします。

  2. VxLAN や GRE 等のトンネルを使用する場合には、NeutronTunnelNUMANodes パラメーターも設定する必要があります。 

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

2 つの物理ネットワークを NUMA ノード 0 にトンネリングする例を以下に示します。

  • NUMA ノード 0 に関連付けられた 1 つのテナントネットワーク

  • アフィニティーが設定されていない 1 つの管理ネットワーク 

    parameter_defaults:
  NeutronBridgeMappings:
    - tenant:br-link0
  NeutronPhysnetNUMANodesMapping: {tenant: [1], mgmt: [0,1]}
  NeutronTunnelNUMANodes: 0
テスト

  • ファイル /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf の設定を確認します。 

    [neutron_physnet_tenant]
numa_nodes=1
[neutron_tunnel]
numa_nodes=1

  • lscpu コマンドで新たな設定を確認します。 

    $ lscpu
  • NIC が適切なネットワークに接続された仮想マシンを起動します。

9.6. NFVi 環境における Quality of Service (QoS) の設定

QoS の設定に関する詳細は、「Quality of Service(QoS) の設定」を参照してください。SR-IOV および OVS-DPDK 送信インターフェースでサポートされる QoS ルールタイプは、bandwidth-limit に限定されます。

第10章 例: OVS-DPDK および SR-IOV ならびに VXLAN トンネリングの設定

本項では、OVS-DPDK および SR-IOV インターフェースの両方を持つコンピュートノードをデプロイする方法について説明します。クラスターは、ML2/OVS および VXLAN トンネリングと共にインストールされます。

重要

OVS-DPDK 用の OpenStack ネットワークを最適化するには、network-environment.yaml ファイルに設定する OVS-DPDK パラメーターの最適な値を判断する必要があります。詳しくは、「ワークフローを使用した DPDK パラメーターの 算出」を参照してください。

10.1. ロールデータの設定

Red Hat OpenStack Platform では、roles_data.yaml ファイルにデフォルトロールのセットが用意されています。独自の roles_data.yaml ファイルを作成して、必要なロールをサポートすることができます。

以下の例では、ComputeOvsDpdkSriov ロールを作成します。Red Hat OpenStack Platform でのロール作成に関する情報は、『オーバークラウドの 高度なカスタマイズ』 を参照してください。以下の例で使用する特定のロールの詳細については、「roles_data.yaml」を参照してください。

10.2. OVS-DPDK パラメーターの設定

重要

OVS-DPDK 用の OpenStack ネットワークを最適化するには、network-environment.yaml ファイルに設定する OVS-DPDK パラメーターの最適な値を判断する必要があります。詳しくは、「 ワークフローを使用した DPDK パラメーターの算出」を 参照してください。

  1. resource_registry セクションに OVS-DPDK 用のカスタムリソースを追加します。 

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

  2. parameter_defaults セクションで、トンネルの種別を vxlan に、ネットワーク種別を vxlan,vlan に設定します。 

    NeutronTunnelTypes: 'vxlan'
NeutronNetworkType: 'vxlan,vlan'

  3. parameters_defaults セクションで、ブリッジマッピングを設定します。 

    # The OVS logical->physical bridge mappings to use.
NeutronBridgeMappings:
  - dpdk-mgmt:br-link0

  4. parameter_defaults セクションで、ComputeOvsDpdkSriov ロール向けにロール固有のパラメーターを設定します。 

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

    ゲストインスタンス作成の失敗を避けるために、DPDK PMD 用の DPDK NIC の有無にかかわらず、各 NUMA ノード上で少なくとも 1 つの CPU を (シブリングスレッドと共に) 割り当てる必要があります。これは、OvsPmdCoreList パラメーターで示され、NUMA 1 からコア 2 および 22 を持ち、NUMA 2 からコア 3 および 23 になります。

    注記

    本手順に示したとおり、これらのヒュージページは仮想マシンと、OvsDpdkSocketMemory パラメーターを使用する OVS-DPDK によって消費されます。仮想マシンで利用可能なヒュージページの数は、ブート パラメーターから OvsDpdkSocketMemory を引いた値です。

    DPDK インスタンスに関連付けるフレーバーに hw:mem_page_size=1GB も追加する必要があります。

    注記

    OvsDPDKCoreList と OvsDpdkMemoryChannels は、本手順では必須の設定です。適切な値を設定せずに DPDK をデプロイする場合、デプロイメントが失敗したり、不安定になる可能性があります。

  5. SR-IOV 向けにロール固有のパラメーターを設定します。 

      NovaPCIPassthrough:
    - devname: "p7p3"
      trusted: "true"
      physical_network: "sriov-1"
    - devname: "p7p4"
      trusted: "true"
      physical_network: "sriov-2"

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

  2. この Linux ボンディングに VLAN を割り当てます。 

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

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

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

  - type: vlan
    vlan_id:
      get_param: ExternalNetworkVlanID
    device: bond_api
    addresses:
    - ip_netmask:
        get_param: ExternalIpSubnet
    routes:
    - default: true
      next_hop:
        get_param: ExternalInterfaceDefaultRoute

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

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

  2. この Linux ボンディングに VLAN を割り当てます。 

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

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

  3. コントローラーにリンクする DPDK ポートを備えたブリッジを設定します。 

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

    複数の DPDK デバイスを含めるには、追加する DPDK デバイスごとに type のコードセクションを繰り返します。

    注記

    OVS-DPDK を使用する場合には、同じコンピュートノード上の全ブリッジが ovs_user_bridge の種別でなければなりません。director は設定を受け入れることができますが、Red Hat OpenStack Platform は同じノード上で ovs_bridge と ovs_user_bridge が混在する構成はサポートしていません。

10.5. オーバークラウドのデプロイ

  1. overcloud_deploy.sh スクリプトを実行してオーバークラウドをデプロイします。 
openstack overcloud deploy \
--templates \
-r /home/stack/ospd-15-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.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/neutron-ovs-dpdk.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/collectd-environment.yaml \
-e /home/stack/ospd-15-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/api-policies.yaml \
-e /home/stack/ospd-15-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/network-environment.yaml \
-e /home/stack/overcloud_images.yaml \
--log-file overcloud_install.log &> overcloud_install.log

第11章 NFV を実装した Red Hat OpenStack Platform のアップグレード

OVS-DPDK が設定された Red Hat OpenStack Platform のアップグレードには、追加の考慮事項とステップが必要です。詳しくは、『Director Installation and Usage』の「 Preparing an NFV-Configured Overcloud 」を参照してください。

第12章 NFV パフォーマンス

Red Hat OpenStack Platform director は、ゲスト仮想ネットワーク機能 (VNF) 用にラインレートパフォーマンスを実現するために、リソースの分割および微調整を実施するようにコンピュートノードを設定します。NFV のユースケースにおける主要なパフォーマンス要素は、スループット、レイテンシー、およびジッターです。

Data Plane Development Kit(DPDK)で高速化した仮想マシンを使用して、物理 NIC と仮想マシンの間で高パフォーマンスのパケット切り替えを有効にすることができます。OVS 2.10 は、DPDK 17 に対応しており、vhost-user のマルチキューをサポートしているので、スケーラブルなパフォーマンスを実現できます。OVS-DPDK は、ゲスト VNF 用のラインレートパフォーマンスを提供します。

Single Root I/O Virtualization (SR-IOV) ネットワークでは、特定ネットワークや仮想マシンのスループット向上など、強化されたパフォーマンス特性が提供されます。

パフォーマンスチューニングの他の重要な機能には、ヒュージページ、NUMA 調整、ホストの分離、CPU ピニングなどが挙げられます。VNF フレーバーには、パフォーマンス向上のためにヒュージページとエミュレータースレッドの分離が必要です。ホストの分離や CPU ピニングにより、NFV パフォーマンスが向上され、擬似パケットロスが回避されます。

CPU と NUMA トポロジーの概要は、『ネットワーク機能仮想化(NFV)の製品ガイド』の「 NFV のパフォーマンスの考慮事項 」および『インスタンス ＆イメージガイド』の「専用の物理 CPU で実行されるエミュレータースレッドの設定 」を参照してください。

第13章 その他の参考資料

以下の表には、参考となるその他の Red Hat ドキュメントの一覧を記載しています。

Red Hat OpenStack Platform のドキュメントスイートは Red Hat OpenStack Platform の製品ドキュメントスイート から参照してください。

表13.1 参考資料一覧
コンポーネント参考情報

Red Hat Enterprise Linux

Red Hat OpenStack Platform は Red Hat Enterprise Linux 8.0 でサポートされています。Red Hat Enterprise Linux のインストールに関する情報は、Red Hat Enterprise Linux のドキュメント から対応するインストールガイドを参照してください。

Red Hat OpenStack Platform

Red Hat OpenStack Platform(RHOSP)のコンポーネントおよびその依存関係をインストールするには、Red Hat OpenStack Platform director を使用します。director は、基本的な RHOSP 環境をアンダークラウドとして使用して、最終的なオーバークラウド内の RHOSP ノードをインストール、設定、および管理します。アンダークラウドのインストールには、デプロイするオーバークラウドに必要な環境に加えて、追加のホストマシンが 1 台必要です。詳しい手順は、『 Red Hat OpenStack Platform director のインストールと使用方法』 を参照してください。

Red Hat OpenStack Platform director を使用して、ネットワーク分離、ストレージ設定、SSL 通信、一般的な設定方法など、Red Hat OpenStack Platform のエンタープライズ環境の高度な機能設定に関する情報は、『オーバークラウドの 高度なカスタマイズ』 を参照してください。

NFV のドキュメント

NFV の概念の概要は、『 ネットワーク機能仮想化(NFV)の製品ガイド』 を参照してください。

付録A DPDK SR-IOV YAML ファイルのサンプル

本項では、同じコンピュートノードに Single Root I/O Virtualization (SR-IOV) および Data Plane Development Kit (DPDK) インターフェースを追加する際の参考として、YAML ファイルの例を示します。

注記

これらのテンプレートは、完全に設定された環境から取得したもので、NFV とは関係のないパラメーターが含まれています。

A.1. VXLAN DPDK SRIOV YAML ファイルのサンプル

A.1.1. roles_data.yaml

###############################################################################
# File generated by TripleO
###############################################################################
###############################################################################
# Role: Controller                                                            #
###############################################################################
- name: Controller
  description: |
    Controller role that has all the controller services loaded and handles
    Database, Messaging and Network functions.
  CountDefault: 1
  tags:
    - primary
    - controller
  networks:
    - External
    - 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: '%stackname%-controller-%index%'
  # Deprecated & backward-compatible values (FIXME: Make parameters consistent)
  # Set uses_deprecated_params to True if any deprecated params are used.
  uses_deprecated_params: True
  deprecated_param_extraconfig: 'controllerExtraConfig'
  deprecated_param_flavor: 'OvercloudControlFlavor'
  deprecated_param_image: 'controllerImage'
  deprecated_nic_config_name: 'controller.yaml'
  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::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::CinderBackendNVMeOF
    - OS::TripleO::Services::CinderBackup
    - OS::TripleO::Services::CinderHPELeftHandISCSI
    - OS::TripleO::Services::CinderScheduler
    - OS::TripleO::Services::CinderVolume
    - OS::TripleO::Services::Clustercheck
    - OS::TripleO::Services::Collectd
    - OS::TripleO::Services::Congress
    - OS::TripleO::Services::ContainerImagePrepare
    - OS::TripleO::Services::DesignateApi
    - OS::TripleO::Services::DesignateCentral
    - OS::TripleO::Services::DesignateProducer
    - OS::TripleO::Services::DesignateWorker
    - OS::TripleO::Services::DesignateMDNS
    - OS::TripleO::Services::DesignateSink
    - OS::TripleO::Services::Docker
    - OS::TripleO::Services::Ec2Api
    - OS::TripleO::Services::Etcd
    - OS::TripleO::Services::ExternalSwiftProxy
    - OS::TripleO::Services::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::IronicInspector
    - OS::TripleO::Services::IronicPxe
    - OS::TripleO::Services::IronicNeutronAgent
    - OS::TripleO::Services::Iscsid
    - OS::TripleO::Services::Keepalived
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Keystone
    - OS::TripleO::Services::LoginDefs
    - OS::TripleO::Services::ManilaApi
    - OS::TripleO::Services::ManilaBackendCephFs
    - OS::TripleO::Services::ManilaBackendIsilon
    - OS::TripleO::Services::ManilaBackendNetapp
    - OS::TripleO::Services::ManilaBackendUnity
    - OS::TripleO::Services::ManilaBackendVNX
    - OS::TripleO::Services::ManilaBackendVMAX
    - OS::TripleO::Services::ManilaScheduler
    - OS::TripleO::Services::ManilaShare
    - OS::TripleO::Services::Memcached
    - OS::TripleO::Services::MetricsQdr
    - OS::TripleO::Services::MistralApi
    - OS::TripleO::Services::MistralEngine
    - OS::TripleO::Services::MistralExecutor
    - OS::TripleO::Services::MistralEventEngine
    - OS::TripleO::Services::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::OpenDaylightApi
    - OS::TripleO::Services::OpenDaylightOvs
    - OS::TripleO::Services::OVNDBs
    - OS::TripleO::Services::OVNController
    - OS::TripleO::Services::Pacemaker
    - OS::TripleO::Services::PankoApi
    - OS::TripleO::Services::OsloMessagingRpc
    - OS::TripleO::Services::OsloMessagingNotify
    - 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
    - OS::TripleO::Services::Xinetd
###############################################################################
# Role: ComputeOvsDpdkSriov                                                   #
###############################################################################
- name: ComputeOvsDpdkSriov
  description: |
    Compute OvS DPDK Role
  CountDefault: 1
  networks:
    - InternalApi
    - Tenant
    - Storage
  RoleParametersDefault:
    VhostuserSocketGroup: "hugetlbfs"
    TunedProfileName: "cpu-partitioning"
  ServicesDefault:
    - OS::TripleO::Services::Aide
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::BootParams
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::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::NeutronSriovAgent
    - OS::TripleO::Services::NeutronSriovHostConfig
    - 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::MetricsQdr
    - OS::TripleO::Services::MySQLClient
    - OS::TripleO::Services::NeutronBgpVpnBagpipe
    - OS::TripleO::Services::NovaCompute
    - OS::TripleO::Services::NovaLibvirt
    - OS::TripleO::Services::NovaLibvirtGuests
    - OS::TripleO::Services::NovaMigrationTarget
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::ContainersLogrotateCrond
    - OS::TripleO::Services::OpenDaylightOvs
    - 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
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::Ptp

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 tenant network (vxlan or gre). Set to '' to disable tunneling.
  NeutronTunnelTypes: 'vxlan'
  # The tenant 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'

  ControllerHostnameFormat: 'controller-%index%'
  ComputeOvsDpdkSriovHostnameFormat: 'compute-%index%'

  # Collectd server that will gather information from overcloud deployment - Service Assurance
  CollectdServer: 192.0.90.1
  CollectdConnectionType: "network"

  ##########################
  # 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: 4096
    OvsDpdkSocketMemory: "3072,1024"
    OvsDpdkMemoryChannels: "4"
    OvsDpdkCoreList: "0,20,1,21"
    OvsPmdCoreList: "2,22,3,23"
    NovaComputeCpuSharedSet: [0,20,1,21]
    # below lines are for history - now this is resolved and we are not
    # required to pass extra hiera data variables - refer BZ -
    # https://bugzilla.redhat.com/show_bug.cgi?id=1617927
    NovaLibvirtRxQueueSize: 1024
    NovaLibvirtTxQueueSize: 1024

  NovaPCIPassthrough:
    - devname: "p7p3"
      trusted: "true"
      physical_network: "sriov-1"
    - devname: "p7p4"
      trusted: "true"
      physical_network: "sriov-2"

  NeutronPhysicalDevMappings: "sriov-1:p7p3,sriov-2:p7p4"
  NeutronSriovNumVFs: "p7p3:5,p7p4:5"

A.1.3. controller.yaml

heat_template_version: rocky

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

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

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

A.1.4. compute-ovs-dpdk.yaml

heat_template_version: rocky

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

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

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

A.1.5. overcloud_deploy.sh

#!/bin/bash

openstack overcloud deploy \
--templates \
-r /home/stack/ospd-15-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/neutron-sriov.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/collectd-environment.yaml \
-e /home/stack/ospd-15-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/api-policies.yaml \
-e /home/stack/ospd-15-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/network-environment.yaml \
-e /home/stack/overcloud_images.yaml \
--log-file overcloud_install.log &> overcloud_install.log
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.