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

Red Hat OpenStack Platform 16.0

ネットワーク機能仮想化 (NFV) の OpenStack デプロイメントのプランニングと設定

概要

本ガイドでは、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 Input/Output Virtualization (SR-IOV) および Data Plane Development Kit 対応 Open vSwitch (OVS-DPDK) のプランニングおよび設定を行う方法について説明します。

第1章 NFV の概要
リンクのコピー

ネットワーク機能仮想化 (NFV) とは、汎用のクラウドベースのインフラストラクチャー上でネットワーク機能 (ネットワークスイッチ等) を仮想化するソフトウェアソリューションです。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 ファイル形式の概要は、『Getting Started with Kubernetes』の「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

上記の情報を取得するには、<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 設定をまとめます。

Expand

表2.1 BIOS 設定
パラメーター	設定
`C3 Power State`	Disabled
`C6 Power State`	Disabled
`MLC Streamer`	Enabled
`MLC Spacial Prefetcher`	Enabled
`DCU Data Prefetcher`	Enabled
`DCA`	Enabled
`CPU Power and Performance`	Performance
`Memory RAS and Performance Config → NUMA Optimized`	Enabled
`Turbo Boost`	Disabled
`VT-d`	Intel カードで VFIO 機能が必要な場合には Enabled

第3章ソフトウェア要件
リンクのコピー

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

3.1. リポジトリーの登録と有効化
リンクのコピー

Red Hat OpenStack Platform をインストールするには、Red Hat OpenStack Platform director を Red Hat サブスクリプションマネージャーで登録して、必要なチャンネルをサブスクライブします。詳しくは、『director のインストールと使用方法』の「システムの登録」を参照してください。

手順

コンテンツ配信ネットワークにシステムを登録します。プロンプトが表示されたら、カスタマーポータルのユーザー名とパスワードを入力します。
```
[stack@director ~]$ sudo subscription-manager register
```

Red Hat OpenStack Platform director のエンタイトルメントプール ID を確認します (たとえば、以下のコマンド出力の {Pool ID})。

[stack@director ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
Subscription Name:   Name of SKU
Provides:            Red Hat Single Sign-On
                     Red Hat Enterprise Linux Workstation
                     Red Hat CloudForms
                     Red Hat OpenStack
                     Red Hat Software Collections (for RHEL Workstation)
                     Red Hat Virtualization
SKU:                 SKU-Number
Contract:            Contract-Number
Pool ID:             {Pool-ID}-123456
Provides Management: Yes
Available:           1
Suggested:           1
Service Level:       Support-level
Service Type:        Service-Type
Subscription Type:   Sub-type
Ends:                End-date
System Type:         Physical

以下のコマンドで Pool ID の値を指定して、Red Hat OpenStack Platform 16.1 のエンタイトルメントをアタッチします。
```
[stack@director ~]$ sudo subscription-manager attach --pool={Pool-ID}-123456
```
デフォルトのリポジトリーを無効にします。
```
subscription-manager repos --disable=*
```

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

$ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-eus-rpms \
--enable=rhel-8-for-x86_64-appstream-eus-rpms \
--enable=rhel-8-for-x86_64-highavailability-eus-rpms \
--enable=ansible-2.8-for-rhel-8-x86_64-rpms \
--enable=openstack-16-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

システムを更新して、ベースシステムパッケージが最新の状態になるようにします。
```
[stack@director ~]$ sudo dnf update -y
[stack@director ~]$ sudo reboot
```

注記

リアルタイム KVM 用の rhel-8-server-nfv-rpms リポジトリーにアクセスするには、別途 Red Hat OpenStack Platform for Real Time SKU のサブスクリプションが必要です。

注記

オーバークラウドノードを登録するには、「 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)

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

注記

Red Hat の組み込み OpenDaylight SDN ソリューションは、RHOSP 14 で非推奨になりました。バグ修正を含む Red Hat の OpenDaylight に対するサポートは、RHOSP 13 のライフサイクルと共に終了します (計画では 2021 年 6 月 27 日)。

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

手順

containers-prepare-parameter.yaml ファイルを修正し、neutron_driver パラメーターを null に設定します。
```
parameter_defaults:
  ContainerImagePrepare:
  - push_destination: true
    set:
     neutron_driver: null
     ...
```

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

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

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

3.3. サポートされているドライバー
リンクのコピー

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

Red Hat OpenStack Platform デプロイメントと NFV の組み合わせ向けにテスト済みの NIC の一覧は、「テスト済み NIC」を参照してください。

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

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

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

第4章ネットワークの考慮事項
リンクのコピー

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

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

最小限のオーバークラウドのネットワーク構成には、以下の 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 で高パフォーマンスを実現するには、ホストとゲストの間でリソースを分割します。

標準的なトポロジーでは、デュアルコアソケットのコンピュートノード上の 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 を DPDK にボンディングして、高可用性を確保します。VNF は DPDK ライブラリーを使用してデータプレーンインターフェースをボンディングするためです。この図には、冗長性を確保するための 2 つのプロバイダーネットワークも示されています。コンピュートノードには 2 つの標準 NIC がボンディングされ、VNF 管理と Red Hat OpenStack Platform API 管理の間で共有されています。

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

5.2.1. HCI を使用しない NFV SR-IOV のトポロジー
リンクのコピー

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

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

Red Hat OpenStack Platform NFV デプロイメントでは、仮想リソースを通じたインスタンスから共有 PCIe リソースへの直接アクセスを設定した場合、Single Root I/O Virtualization (SR-IOV) を使用してより高いパフォーマンスが得られます。

6.1. 前提条件
リンクのコピー

オーバークラウドのデプロイ前にアンダークラウドをインストールおよび設定する方法の詳細は、『 director のインストールと使用方法』を参照してください。

注記

director heat テンプレートが変更する /etc/tuned/cpu-partitioning-variables.conf の値を、手動で編集しないでください。

6.2. SR-IOV の設定
リンクのコピー

注記

以下に示す CPU 割り当て、メモリーの確保、および NIC の設定は一例であり、実際のユースケースとは異なる場合があります。

NeutronSriovAgent、NeutronSriovHostConfig、およびデフォルトの Compute サービスを実行する OpenStack クラスターのノードを定義するために、ビルトインの ComputeSriov ロールを生成します。
```
# openstack overcloud roles generate \
-o /home/stack/templates/roles_data.yaml \
Controller ComputeSriov
```
SR-IOV コンテナーを準備するには、overcloud_images.yaml ファイルを生成する際に neutron-sriov.yaml および roles_data.yaml ファイルを含めます。
```
sudo openstack tripleo container image prepare \
  --roles-file ~/templates/roles_data.yaml \
  -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-sriov.yaml \
  -e ~/containers-prepare-parameter.yaml \
  --output-env-file=/home/stack/templates/overcloud_images.yaml
```
コンテナーイメージの準備に関する詳細な情報は、『 director のインストールと使用方法』を参照してください。
実際のクラスターおよびハードウェア構成に合わせて、parameter_defaults セクションで SR-IOV ノードのパラメーターを適切に設定します。通常、以下の設定を network-environment.yaml ファイルに追加します。
```
  NeutronNetworkType: 'vlan'
  NeutronNetworkVLANRanges:
    - tenant:22:22
    - tenant:25:25
  NeutronTunnelTypes: ''
```
同じファイルで、SR-IOV コンピュートノードのロール固有のパラメーターを設定します。
注記
numvfs パラメーターは、ネットワーク設定テンプレートの NeutronSriovNumVFs パラメーターに代わるものです。Red Hat では、デプロイ後の NeutronSriovNumVFs パラメーターまたは numvfs パラメーターの変更をサポートしません。デプロイ後にいずれかのパラメーターを変更すると、その Physical Function (PF) 上に SR-IOV ポートを持つ実行中のインスタンスが使用できなくなる可能性があります。この場合、これらのインスタンスをハードリブートして、SR-IOV PCI デバイスを再び利用可能にする必要があります。NovaVcpuPinSet パラメーターは非推奨となり、専用の固定されたワークフロー用の NovaComputeCpuDedicatedSet に置き換えられています。
```
  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
    NovaPCIPassthrough:
      - devname: "p7p1"
        physical_network: "tenant"
      - devname: "p7p2"
        physical_network: "tenant"
    NovaComputeCpuDedicatedSet: '1-19,21-39'
    NovaReservedHostMemory: 4096
```

compute.yaml ネットワーク設定テンプレートで、SR-IOV が有効なインターフェースを設定します。SR-IOV Virtual Function (VF) を作成するには、インターフェースをスタンドアロンの NIC として設定します。

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

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

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

NovaSchedulerDefaultFilters: ['AvailabilityZoneFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','AggregateInstanceExtraSpecsFilter']

overcloud_deploy.sh スクリプトを実行します。

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 インターフェースに適用することができます。

手順

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

os-net-config ロールファイルでインターフェース種別 sriov_pf を使用して、ホストが使用できる Physical Function を設定します。
```
        - 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 パラメーターの変更をサポートしません。デプロイ後にいずれかのパラメーターを変更すると、その Physical Function (PF) 上に SR-IOV ポートを持つ実行中のインスタンスが使用できなくなる可能性があります。この場合、これらのインスタンスをハードリブートして、SR-IOV PCI デバイスを再び利用可能にする必要があります。

インターフェース種別 sriov_vf を使用して、ホストが使用できるボンドの Virtual Function を設定します。

               - 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 を引いた数値までです。

仮想マシンに Virtual Function を確保するには、NovaPCIPassthrough パラメーターを使用します。ホストではなく仮想マシンで使用するために Nova にパススルーする 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]"}
```
NIC の分割が必要なすべてのノードで IOMMU を有効にします。たとえば、コンピュートノードに NIC 分割を設定する場合は、そのロールの KernelArgs パラメーターを使用して IOMMU を有効にします。
```
parameter_defaults:
  ComputeParameters:
    KernelArgs: "intel_iommu=on iommu=pt"
```

検証

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

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

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

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 インスタンスをデプロイしてテストを行います。

以下のボンディングモードがサポートされます。

balance-slb
active-backup

6.4. OVS ハードウェアオフロードの設定
リンクのコピー

OVS ハードウェアオフロードを設定する手順と SR-IOV を設定する手順は、多くの部分が共通です。

手順

ComputeSriov ロールを作成します。

openstack overcloud roles generate -o roles_data.yaml Controller ComputeSriov

ご自分の環境に合わせて、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
    NovaComputeCpuDedicatedSet: 1-9,21-29,11-19,31-39

デフォルトフィルターの一覧に NUMATopologyFilter が含まれるようにします。

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

compute-sriov.yaml 設定ファイルで、ハードウェアオフロードに使用するネットワークインターフェースを 1 つまたは複数設定します。
注記
Open vSwitch ハードウェアオフロードを設定する場合には、NeutronSriovNumVFs パラメーターを使用しないでください。os-net-config で使用されるネットワーク設定ファイルの numvfs パラメーターで、VF の数を指定します。
```
  - 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 等のトンネルエンドポイントがトラフィックを渡さなくなるためです。

overcloud deploy コマンドに ovs-hw-offload.yaml ファイルを追加します。

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

openstack overcloud deploy --templates \
  -r ${CUSTOM_TEMPLATES}/roles_data.yaml \
  -e ${TEMPLATES_HOME}/environments/ovs-hw-offload.yaml \
  -e ${CUSTOM_TEMPLATES}/network-environment.yaml \
  -e ${CUSTOM_TEMPLATES}/neutron-ovs.yaml

6.4.1. OVS ハードウェアオフロードの確認
リンクのコピー

PCI デバイスが switchdev モードにあることを確認します。

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

OVS でオフロードが有効かどうかを確認します。

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

6.5. SR-IOV 用インスタンスのデプロイ
リンクのコピー

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

注記

CPU ピニングを設定したインスタンスと設定していないインスタンスを、同じコンピュートノードに配置することができます。詳しくは、『インスタンス＆イメージガイド』の「コンピュートノードでの CPU ピニングの設定」を参照してください。

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

フレーバーを作成します。
```
# openstack flavor create <flavor> --ram <MB> --disk <GB> --vcpus <#>
```
ヒント
フレーバーに追加スペック hw:pci_numa_affinity_policy を追加して、PCI パススルーデバイスおよび SR-IOV インターフェースの NUMA アフィニティーポリシーを指定することができます。詳しくは、『 インスタンス＆イメージガイド』の「フレーバーのメタデータの更新」を参照し てください。

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

# 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

ポートを作成します。
- 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

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

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

6.6. ホストアグリゲートの作成
リンクのコピー

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

手順

AggregateInstanceExtraSpecsFilter の値が nova.conf ファイルの scheduler_default_filters パラメーターに追加されていることを確認します。この設定は、デプロイの前にロール固有のパラメーターセクションの heat パラメーター NovaSchedulerDefaultFilters で定義することができます。
```
  ComputeOvsDpdkSriovParameters:
    NovaSchedulerDefaultFilters: ['AggregateInstanceExtraSpecsFilter', 'RetryFilter','AvailabilityZoneFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','NUMATopologyFilter']
```
注記
このパラメーターを既存クラスターの設定に追加するには、パラメーターを heat テンプレートに追加し、元のデプロイメント用スクリプトを再度実行します。
SR-IOV 用のアグリゲートグループを作成し、適切なホストを追加します。定義するフレーバーメタデータに一致するメタデータを定義します (例: sriov=true)。
```
# openstack aggregate create sriov_group
# openstack aggregate add host sriov_group compute-sriov-0.localdomain
# openstack aggregate set --property sriov=true sriov_group
```

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

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

追加のフレーバー属性を設定します。定義したメタデータ (sriov=true) と SR-IOV アグリゲートで定義したメタデータが一致している点に注意してください。
```
openstack flavor set --property aggregate_instance_extra_specs:sriov=true --property hw:cpu_policy=dedicated --property hw:mem_page_size=1GB <flavor>
```

第7章 OVS-DPDK デプロイメントのプランニング
リンクのコピー

OVS-DPDK デプロイメントを最適化するには、コンピュートノードのハードウェアに関する OVS-DPDK パラメーターの設定方法を理解する必要があります。CPU および NUMA トポロジーについての詳しい情報は、『ネットワーク機能仮想化(NFV)の製品ガイド』の「 NFV のパフォーマンスの考慮事項」を参照してください。

7.1. CPU 分割と NUMA トポロジーを使用する OVS-DPDK
リンクのコピー

OVS-DPDK は、ホスト、ゲスト、およびそれ自体用にハードウェアリソースを分割します。OVS-DPDK Poll Mode Driver (PMD) は、専用の CPU コアを必要とする DPDK アクティブループを実行します。したがって、一部の CPU およびヒュージページを OVS-DPDK に割り当てる必要があります。

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

注記

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

最高の OVS-DPDK パフォーマンスを得るためには、NUMA ノードにローカルなメモリーブロックを確保します。メモリーと CPU ピニングに使用する同じ NUMA ノードに関連付けられた NIC を選択してください。ボンディングを構成する両方のインターフェースには、同じ NUMA ノード上の NIC を使用するようにしてください。

7.2. ワークフローと派生パラメーター
リンクのコピー

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

注記

実際の環境に応じて derive_params_formulas.yaml を変更することができます。

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

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

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

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

7.3. OVS-DPDK の派生パラメーター
リンクのコピー

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

ワークフローは、OVS-DPDK の以下のパラメーターを自動的に派生することができます。NovaVcpuPinSet パラメーターは非推奨となり、専用の固定されたワークフロー用の NovaComputeCpuDedicatedSet に置き換えられています。

IsolCpusList
KernelArgs
NovaReservedHostMemory
NovaComputeCpuDedicatedSet
OvsDpdkCoreList
OvsDpdkSocketMemory
OvsPmdCoreList

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

多くの場合、OvsDpdkMemoryChannels のデフォルト値は 4 です。ハードウェアのマニュアルを参照して 1 ソケットあたりのメモリーチャネル数を確認し、デフォルト値をその値で更新してください。

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

7.4. OVS-DPDK パラメーターの手動計算
リンクのコピー

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

注記

上記の方法によらず、derived_parameters.yaml ワークフローを使用してこれらの値を生成する方法の詳細は、「ワークフローと派生パラメーター」を参照してください。

注記

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 コアを選択します。OVS の pmd-cpu-mask の値に OvsPmdCoreList を使用します。OvsPmdCoreList に関する以下の推奨事項を確認してください。

シブリングスレッドをペアにします。
OvsDpdkCoreList のコアをすべて除外します。
1 番目の物理コア上の両方のスレッドシブリングの論理 CPU を両方の NUMA ノードに割り当てないでください。これらは OvsDpdkCoreList パラメーターに使用する必要があります。
パフォーマンスは、この PMD コアリストに割り当てられている物理コアの数によって異なります。DPDK NIC に関連付けられている NUMA ノードで、必要なコアを割り当てます。
DPDK NIC を持つ NUMA ノードの場合には、パフォーマンス要件に基づいて、必要な物理コア数を決定し、各物理コアの全シブリングスレッド (あるいは論理 CPU) を追加します。
DPDK NIC を持たない NUMA ノードの場合には、任意の物理コア (ただし NUMA ノードの 1 番目の物理コアを除く) のシブリングスレッド (あるいは論理 CPU) を割り当てます。DPDK NIC がない場合、ゲストインスタンスを正常に作成するために、NUMA ノード上に最小限の DPDK Poll Mode Driver が必要です。

注記

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

NovaComputeCpuDedicatedSet

ピニングされたインスタンス CPU のプロセスをスケジューリングできる物理ホスト CPU 番号のコンマ区切りリストまたは範囲。たとえば、NovaComputeCpuDedicatedSet: [4-12,^8,15] は、コア 4 - 12 の範囲 (ただし 8 を除く) および 15 を確保します。

OvsPmdCoreList と OvsDpdkCoreList のコアをすべて除外します。
残りのコアをすべて追加します。
シブリングスレッドをペアにします。

NovaComputeCpuSharedSet

物理ホスト CPU 番号のコンマ区切りリストまたは範囲。インスタンスエミュレータースレッド用のホスト CPU を決定するのに使用します。このパラメータの値と OvsDpdkCoreList に設定した値を一致させることを推奨します。

IsolCpusList

ホストのプロセスから分離される CPU コアのセット。IsolCpusList は、tuned-profiles-cpu-partitioning コンポーネント用の cpu-partitioning-variable.conf ファイルの isolated_cores の値として使用されます。IsolCpusList に関する以下の推奨事項を確認してください。

OvsPmdCoreList および NovaComputeCpuDedicatedSet のコア一覧と一致するようにします。
シブリングスレッドをペアにします。

OvsDpdkCoreList

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

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

DerivePciWhitelistEnabled

仮想マシン用に Virtual Function (VF) を確保するには、NovaPCIPassthrough パラメーターを使用して Nova に渡される VF の一覧を作成します。一覧から除外された VF は、引き続きホスト用に利用することができます。

Red Hat では、DerivePciWhitelistEnabled の値をデフォルトの true から false に変更してから、NovaPCIPassthrough パラメーターの一覧を手動で設定することを推奨します。

一覧内の VF ごとに、アドレス値に解決する正規表現でアドレスパラメーターを反映させます。

手動で一覧を作成するプロセスの例を以下に示します。eno2 という名前のデバイスで NIC の分割が有効な場合は、以下のコマンドで VF の PCI アドレスを一覧表示します。

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

この場合、VF 0、4、および 6 が NIC の分割用に eno2 で使用されます。以下の例に示すように、NovaPCIPassthrough を手動で設定して VF 1 - 3、5、および 7 を含めます。したがって、VF 0、4、および 6 は除外します。

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

7.4.2. メモリーパラメーター
リンクのコピー

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

OvsDpdkMemoryChannels

NUMA ノードごとに、CPU 内のメモリーチャネルをマッピングします。OvsDpdkMemoryChannels は、OVS の other_config:dpdk-extra="-n <value>" の値に使用されます。OvsDpdkMemoryChannels に関する以下の推奨事項を確認してください。

dmidecode -t memory のコマンドを使用するか、お使いのハードウェアのマニュアルを参照して、利用可能なメモリーチャネルの数を確認します。
ls /sys/devices/system/node/node* -d のコマンドで NUMA ノードの数を確認します。
利用可能なメモリーチャネル数を NUMA ノード数で除算します。

NovaReservedHostMemory

ホスト上のタスク用にメモリーを MB 単位で確保します。NovaReservedHostMemory は、コンピュートノードの nova.conf の reserved_host_memory_mb の値に使用されます。NovaReservedHostMemory に関する以下の推奨事項を確認してください。

静的な推奨値 4096 MB を使用します。

OvsDpdkSocketMemory

NUMA ノードごとにヒュージページプールから事前に割り当てるメモリーの容量を MB 単位で指定します。OvsDpdkSocketMemory は、OVS の other_config:dpdk-socket-mem の値に使用されます。OvsDpdkSocketMemory に関する以下の推奨事項を確認してください。

コンマ区切りリストで指定します。
DPDK NIC のない NUMA ノードの場合は、推奨される静的な値である 1024 MB (1 GB) を使用します。
NUMA ノード上の各 NIC の MTU 値から、OvsDpdkSocketMemory の値を計算します。
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 9000 および MTU 2000

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

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

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

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

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

それらを合わせた必要なメモリーの合計を計算します (バイト単位)。
```
2625634304 + 746586112 + 536870912 = 3909091328 bytes.
```
この計算は、(MTU 値 9000 に必要なメモリー) + (MTU 値 2000 に必要なメモリー) + (512 MB バッファー) を示しています。
必要合計メモリーを MB に変換します。
```
3909091328 / (1024*1024) = 3728 MB.
```
この値を 1024 の倍数に丸めます。
```
3724 MB rounds up to 4096 MB.
```
この値を使用して OvsDpdkSocketMemory を設定します。
```
    OvsDpdkSocketMemory: “4096,1024”
```

計算例: MTU 2000

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

MTU 値を 1024 バイトの倍数に丸めます。
```
The MTU value of 2000 becomes 2048 bytes.
```
それらの丸めたバイト値に基づいて、各 MTU 値に必要なメモリーを計算します。
```
Memory required for 2000 MTU = (2048 + 800) * (4096*64) = 746586112
```
それらを合わせた必要なメモリーの合計を計算します (バイト単位)。
```
746586112 + 536870912 = 1283457024 bytes.
```
この計算は、(MTU 値 2000 に必要なメモリー) + (512 MB バッファー) を示しています。
必要合計メモリーを MB に変換します。
```
1283457024 / (1024*1024) = 1224 MB.
```
この値を 1024 の倍数に丸めます。
```
1224 MB rounds up to 2048 MB.
```
この値を使用して 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 が 1 G をサポートしていることを確認してください。
```
lshw -class processor | grep pdpe1gb
```
hugepages count: 利用可能なホストメモリーに基づいてヒュージページの数を設定します。利用可能なメモリーの大半を使用してください (NovaReservedHostMemory を除く)。ヒュージページ数の値は、コンピュートノードのフレーバーの範囲内で設定する必要もあります。
iommu: Intel CPU の場合は、"intel_iommu=on iommu=pt" を追加します。
isolcpus: チューニングする CPU コアを設定します。この値は IsolCpusList と一致します。

7.4.5. インスタンスの追加仕様
リンクのコピー

NFV 環境でインスタンスをデプロイする前に、CPU ピニング、ヒュージページ、およびエミュレータースレッドピニングを活用するフレーバーを作成します。

hw:cpu_policy

このパラメーターを dedicated に設定すると、ゲストはピニングされた CPU を使用します。このパラメーターセットのフレーバーから作成したインスタンスの有効オーバーコミット比は、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) またはリアルタイム処理用の仮想 CPU 上で実行されている場合には、パケットロスなどの悪影響が生じる場合があります。

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) に接続されている。

注記

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

この例では、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”
NovaComputeCpuDedicatedSet: “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”
NovaComputeCpuDedicatedSet: “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”
NovaComputeCpuDedicatedSet: “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”
NovaComputeCpuDedicatedSet: “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”
NovaComputeCpuDedicatedSet: “6,7,14,15”

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

以下のデプロイメント例は、2 つの仮想ネットワーク機能 (VNF) からなる OVS-DPDK 構成を示しています。それぞれの NVF は、次の 2 つのインターフェースを持ちます。

mgt で表される管理インターフェース
データプレーンインターフェース

OVS-DPDK デプロイメントでは、VNF は物理インターフェースをサポートする組み込みの DPDK で動作します。OVS-DPDK は、vSwitch レベルでボンディングを有効にします。OVS-DPDK デプロイメントでのパフォーマンスを向上させるには、カーネルと OVS-DPDK NIC を分離することを推奨します。仮想マシン向けのベースプロバイダーネットワークに接続された管理 (mgt) ネットワークを分離するには、追加の NIC を利用できるようにします。コンピュートノードは、Red Hat OpenStack Platform API 管理向けの標準 NIC 2 つで構成されます。これは、Ceph API で再利用できますが、OpenStack プロジェクトとは一切共有できません。

NFV OVS-DPDK のトポロジー

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

第8章 OVS-DPDK デプロイメントの設定
リンクのコピー

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

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

重要

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

注記

etc/tuned/cpu-partitioning-variables.conf の isolated_cores や他の値を手動で編集したり変更したりしないでください。これらは director の heat テンプレートにより変更されます。

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

重要

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 用のワークフローと入力パラメーターを定義するには、以下の手順を実行します。

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

openstack overcloud deploy コマンドを実行し、以下の情報を追加します。
- update-plan-only オプション
- ロールファイルおよびご自分の環境に固有の全環境ファイル
- plan-environment-derived-parms.yaml ファイル (--plan-environment-file オプションの引数)
  $ openstack overcloud deploy --templates --update-plan-only \ -r /home/stack/roles_data.yaml \ -e /home/stack/<environment-file> \ ... _#repeat as necessary_ ... **-p /home/stack/plan-environment-derived-params.yaml**

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

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

注記

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

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

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

派生パラメーターをデプロイコマンドの出力から network-environment.yaml ファイルにコピーします。
```
  # DPDK compute node.
  ComputeOvsDpdkParameters:
    KernelArgs: default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on
    TunedProfileName: "cpu-partitioning"
    IsolCpusList: "1,2,3,4,5,6,7,9,10,17,18,19,20,21,22,23,11,12,13,14,15,25,26,27,28,29,30,31"
    NovaComputeCpuDedicatedSet: ['2,3,4,5,6,7,18,19,20,21,22,23,10,11,12,13,14,15,26,27,28,29,30,31']
    NovaReservedHostMemory: 4096
    OvsDpdkSocketMemory: "1024,1024"
    OvsDpdkMemoryChannels: "4"
    OvsDpdkCoreList: "0,16,8,24"
    OvsPmdCoreList: "1,17,9,25"
```
注記
ゲストインスタンス作成の失敗を避けるために、DPDK PMD 用の DPDK NIC の有無にかかわらず、各 NUMA ノード上で少なくとも 1 つの CPU を (シブリングスレッドと共に) 割り当てる必要があります。
注記
これらのパラメーターは、特定のロール ComputeOvsDpdk に適用されます。これらのパラメーターをグローバルに適用することはできますが、グローバルパラメーターはロール固有のパラメーターによってオーバーライドされます。
ロールファイルおよびご自分の環境に固有の全環境ファイルを使用して、オーバークラウドをデプロイします。

 openstack overcloud deploy --templates \
 -r /home/stack/roles_data.yaml \
 -e /home/stack/<environment-file> \
... #repeat as necessary ...

注記

Compute、ComputeOvsDpdk、および ComputeSriov ロールが含まれるクラスターでは、ワークフローは ComputeOvsDpdk ロールにだけ式を適用し、Compute または ComputeSriovs には適用しません。

8.2. OVS-DPDK のトポロジー
リンクのコピー

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

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

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

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

注記

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

前提条件

OVS 2.10
DPDK 17
サポートされている NIC。NFV 向けにサポートされている NIC の一覧を表示するには、「テスト済み NIC」を参照してください。

注記

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

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

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

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

注記

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

注記

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

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

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

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

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

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 に設定します。フローベースの 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 インターフェース向けのマルチキューの設定
リンクのコピー

注記

マルチキューは実験的な機能で、サポート対象ではありません。

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

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

8.6. 既知の制限
リンクのコピー

NFV 向けに Red Hat OpenStack Platform で OVS-DPDK を設定する場合には、以下の制限事項を確認してください。

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

8.7. OVS-DPDK 用のフレーバーの作成とインスタンスのデプロイ
リンクのコピー

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

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 ピニングの設定」を参照してください。

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

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

フレーバーの属性を設定します。定義したメタデータ (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
```
パフォーマンス向上のためのエミュレータースレッドポリシーについての詳しい情報は、「専用の物理 CPU で実行されるエミュレータースレッドの設定」を参照してください。

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

# 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

オプション: OVS-DPDK と共にマルチキューを使用する場合、インスタンスの作成に使用するイメージで hw_vif_multiqueue_enabled 属性を設定します。
```
# openstack image set --property hw_vif_multiqueue_enabled=true <image>
```

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

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

8.8. 設定のトラブルシューティング
リンクのコピー

本項では、OVS-DPDK 設定のトラブルシューティングの手順を説明します。

ブリッジの詳細を調べ、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

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

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

オプションとして、コンテナーが起動に失敗したかどうかなど、エラーをログで確認することができます。
```
# less /var/log/containers/neutron/openvswitch-agent.log
```

ovs-dpdk の Poll Mode Driver CPU マスクが CPU にピニングされていることを確認します。ハイパースレッディングの場合は、シブリング CPU を使用します。

たとえば、CPU4 のシブリングを確認するには、以下のコマンドを実行します。

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

CPU4 のシブリングは CPU20 なので、続いて以下のコマンドを実行します。

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

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

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

第9章 Red Hat OpenStack Platform 環境の調整
リンクのコピー

9.1. エミュレータースレッドの固定
リンクのコピー

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

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

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

パフォーマンスを改善するために、エミュレータースレッドをホストするために OvsDpdkCoreList パラメーターで識別したホスト CPU のサブセットを確保します。

手順

特定のロールに NovaComputeCpuSharedSet を定義してオーバークラウドをデプロイします。NovaComputeCpuSharedSet の値は、そのロール内のホストの nova.conf ファイルの cpu_shared_set パラメーターに適用されます。
```
parameter_defaults:
    ComputeOvsDpdkParameters:
        OvsDpdkCoreList: “0-1,16-17”
        NovaComputeCpuSharedSet: “0-1,16-17”
        NovaComputeCpuDedicatedSet: “2-15,18-31”
```
エミュレータースレッドが共有プールに分離されたインスタンスをビルドするためのフレーバーを作成します。
```
openstack flavor create --ram <size_mb> --disk <size_gb> --vcpus <vcpus> <flavor>
```
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 パラメーターを設定する必要があります。nova.conf を手動で編集した内容は再デプロイ後は維持されないので、この設定には可能な限り heat を使用するべきです。

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

手順

対象インスタンスのホストおよび名前を特定します。
```
openstack server show <instance_id>
```

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

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

9.2. NFV ワークロードに向けた RT-KVM の有効化
リンクのコピー

Red Hat Enterprise Linux 8.0 Real Time KVM (RT-KVM) を容易にインストールおよび設定するために、Red Hat OpenStack Platform では以下の機能を使用することができます。

Red Hat Enterprise Linux for Real Time をプロビジョニングする、real-time コンピュートノードロール
追加の 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 のイメージのビルド

アンダークラウドに 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

イメージを抽出します。

(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

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

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

イメージを登録して、カスタマイズに適切な Red Hat のリポジトリーを有効にします。以下の例の [username] および [password] を有効な認証情報に置き換えてください。
```
virt-customize -a overcloud-realtime-compute.qcow2 --run-command \
'subscription-manager register --username=[username] --password=[password]' \
subscription-manager release --set 8.1
```
注記
コマンドプロンプトで認証情報を使用したら、履歴ファイルから認証情報を削除してセキュリティーを確保することができます。history -d コマンドの後に行番号を指定して、履歴内の個々の行を削除することができます。

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

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

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-eus-rpms \
--enable=rhel-8-for-x86_64-appstream-eus-rpms \
--enable=rhel-8-for-x86_64-highavailability-eus-rpms \
--enable=ansible-2.8-for-rhel-8-x86_64-rpms \
--enable=openstack-16-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'

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

(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

リアルタイムイメージを設定するスクリプトを実行します。
```
(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」という行が表示されても、このエラーは無視してかまいません。

前のステップで作成された virt-customize.log ファイルを調べ、rt.sh スクリプトによりパッケージが正しくインストールされたことを確認します。

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

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

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

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

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 のファイル名に含まれるソフトウェアバージョンは、カーネルバージョンによって異なります。

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

(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 設定で、以下のパラメーターのオプションをすべて無効にします。

電源管理
ハイパースレッディング
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 イメージ用のコンピュートノードを指定します。

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

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

9.2.2.2. OVS-DPDK パラメーターの設定
リンクのコピー

重要

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

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

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

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

9.2.2.3. オーバークラウドのデプロイ
リンクのコピー

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

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

9.2.3. RT-KVM インスタンスの起動
リンクのコピー

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

オーバークラウド上に 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

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

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

割り当てられたエミュレータースレッドをインスタンスが使用していることを確認するには、以下のコマンドを実行します。

# 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) がプロミスキャスモードの有効化やハードウェアアドレスの変更などの特権を必要とする操作を実施できるように、Physical Function (PF) と VF 間に信頼を設定することができます。

9.3.1. Virtual Function と Physical Function 間の信頼の設定
リンクのコピー

前提条件

稼働状態にある Red Hat OpenStack Platform のインストール環境 (director を含む)

手順

Physical Function と Virtual Function 間の信頼が設定されたオーバークラウドを設定およびデプロイするには、以下の手順を実施します。

parameter_defaults セクションに NeutronPhysicalDevMappings パラメーターを追加して、論理ネットワーク名と物理インターフェース間をリンクさせます。
```
parameter_defaults:
  NeutronPhysicalDevMappings:
    - sriov2:p5p2
```
SR-IOV パラメーターに新たな属性 trusted を追加します。
```
parameter_defaults:
  NeutronPhysicalDevMappings:
    - sriov2:p5p2
  NovaPCIPassthrough:
    - devname: "p5p2"
      physical_network: "sriov2"
      trusted: "true"
```
注記
"true" のように、値を二重引用符で囲む必要があります。
重要
非管理者アカウントで信頼済みポートをバインドすることができるので、以下のステップは安全な環境で実施してください。

権限を変更し、ユーザーがポートのバインディングを作成および更新できるようにします。

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 ネットワークの活用
リンクのコピー

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

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

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

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

ポートを作成します。vnic-type オプションを direct に、binding-profile オプションを true に、それぞれ設定します。
```
openstack port create --network sriov111 \
--vnic-type direct --binding-profile trusted=true \
sriov111_port_trusted
```

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

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

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

インスタンスを作成したコンピュートノード上で、以下のコマンドを実行します。

# 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

VF の信頼ステータスが 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 が必要です。

手順

受信および送信キューサイズを増やすには、該当する 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 の設定
リンクのコピー

重要

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

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

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

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

重要

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

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

前提条件

フィルター「NUMATopologyFilter」を有効にしていること

手順

新たに NeutronPhysnetNUMANodesMapping パラメーターを設定して、物理ネットワークと物理ネットワークに関連付ける NUMA ノードをマッピングします。
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 トンネリングが含まれます。

重要

10.1. ロールデータの設定
リンクのコピー

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

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

10.2. OVS-DPDK パラメーターの設定
リンクのコピー

重要

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

parameter_defaults セクションで、トンネル種別を vxlan に、ネットワーク種別を vxlan,vlan に、それぞれ設定します。
```
NeutronTunnelTypes: 'vxlan'
NeutronNetworkType: 'vxlan,vlan'
```

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

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

parameter_defaults セクションで、ComputeOvsDpdkSriov ロール向けにロール固有のパラメーターを設定します。
```
  ##########################
  # OVS DPDK configuration #
  ##########################
  ComputeOvsDpdkSriovParameters:
    KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=2-19,22-39"
    TunedProfileName: "cpu-partitioning"
    IsolCpusList: "2-19,22-39"
    NovaComputeCpuDedicatedSet: ['4-19,24-39']
    NovaReservedHostMemory: 4096
    OvsDpdkSocketMemory: "3072,1024"
    OvsDpdkMemoryChannels: "4"
    OvsDpdkCoreList: "0,20,1,21"
    OvsPmdCoreList: "2,22,3,23"
    NovaComputeCpuSharedSet: [0,20,1,21]
    NovaLibvirtRxQueueSize: 1024
    NovaLibvirtTxQueueSize: 1024
```
注記
ゲストの作成時にエラーが発生するのを防ぐためには、各 NUMA ノードで少なくとも 1 つの CPU を (シブリングスレッドと共に) 割り当てます。上記の例では、OvsPmdCoreList パラメーターの値は NUMA 0 からのコア 2 および 22 ならびに NUMA 1 からのコア 3 および 23 です。
注記
本手順に示したとおり、これらのヒュージページは仮想マシンと、OvsDpdkSocketMemory パラメーターを使用する OVS-DPDK によって消費されます。仮想マシンが利用可能なヒュージページの数は、boot パラメーターから OvsDpdkSocketMemory を減算した値です。
DPDK インスタンスに関連付けるフレーバーに hw:mem_page_size=1GB も追加する必要があります。
注記
OvsDPDKCoreList と OvsDpdkMemoryChannels は、本手順では必須の設定です。最大限の機能を得るためには、適切なパラメーターおよび値で DPDK をデプロイするようにしてください。

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

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

10.3. コントローラーノードの設定
リンクのコピー

分離ネットワーク用のコントロールプレーンの 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

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

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 ファイルを作成し、以下のように変更します。

分離ネットワーク用のコントロールプレーンの 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

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

コントローラーにリンクする 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 の種別でなければなりません。Red Hat OpenStack Platform では、ovs_bridge と ovs_user_bridge の両方が同じノード上に存在する構成はサポートされません。

10.5. オーバークラウドのデプロイ
リンクのコピー

overcloud_deploy.sh スクリプトを実行します。

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

OVS-DPDK が設定された Red Hat OpenStack Platform (RHOSP) のアップグレードについての詳しい情報は、『13 から 16.1 へのアップグレードフレームワーク』の「ネットワーク機能仮想化 (NFV) の準備」を参照してください。

第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 の製品ドキュメントスイートから参照してください。

Expand

表13.1 参考資料一覧
コンポーネント	参考情報
Red Hat Enterprise Linux	Red Hat OpenStack Platform は Red Hat Enterprise Linux 8.0 でサポートされています。Red Hat Enterprise Linux のインストールに関する情報は、Red Hat Enterprise Linux のドキュメントから対応するインストールガイドを参照してください。
Red Hat OpenStack Platform	OpenStack のコンポーネントとそれらの依存関係をインストールするには、Red Hat OpenStack Platform director を使用します。director は、基本的な OpenStack 環境をアンダークラウドとして使用して、最終的なオーバークラウド内の OpenStack ノードをインストール、設定、および管理します。アンダークラウドのインストールには、デプロイするオーバークラウドに必要な環境に加えて、追加のホストマシンが 1 台必要です。詳しい手順は、『 Red Hat OpenStack Platform director のインストールと使用方法』を参照してください。 Red Hat OpenStack Platform director を使用して、ネットワーク分離、ストレージ設定、SSL 通信、一般的な設定方法など、Red Hat OpenStack Platform のエンタープライズ環境の高度な機能設定に関する情報は、『オーバークラウドの高度なカスタマイズ』を参照してください。
NFV のドキュメント	NFV の概念の概要は、『ネットワーク機能仮想化(NFV)の製品ガイド』を参照してください。

付録A DPDK SRIOV 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
リンクのコピー

openstack overcloud roles generate コマンドを実行して、roles_data.yaml ファイルを生成します。実際の環境にデプロイするロールに応じて、コマンドにロール名を追加します (例: Controller、ComputeSriov、ComputeOvsDpdkRT、ComputeOvsDpdkSriov、またはその他のロール)。たとえば、Controller ロールおよび ComputeOvsDpdkSriov ロールが含まれる roles_data.yaml ファイルを生成するには、以下のコマンドを実行します。

 $ openstack overcloud roles generate -o roles_data.yaml Controller ComputeOvsDpdkSriov

###############################################################################
# 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::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-overrides.yaml
リンクのコピー

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

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

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

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

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

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

    # NUMA aware vswitch
    NeutronPhysnetNUMANodesMapping: {dpdk-mgmt: [0]}
    NeutronTunnelNUMANodes: [0]
    NeutronPhysicalDevMappings:
    - sriov1:enp6s0f2
    - sriov2:enp6s0f3

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

A.1.3. controller.yaml
リンクのコピー

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

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

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

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

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

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

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

A.1.4. compute-ovs-dpdk.yaml
リンクのコピー

heat_template_version: rocky

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

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

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

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

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

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

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

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

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

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

A.1.5. overcloud_deploy.sh
リンクのコピー

#!/bin/bash

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

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

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

ネットワーク機能仮想化 (NFV) の OpenStack デプロイメントのプランニングと設定

はじめにリンクのコピーリンクがクリップボードにコピーされました!

第1章 NFV の概要リンクのコピーリンクがクリップボードにコピーされました!

第2章 ハードウェア要件リンクのコピーリンクがクリップボードにコピーされました!

2.1. テスト済み NICリンクのコピーリンクがクリップボードにコピーされました!

2.2. NUMA ノードのトポロジーについての理解リンクのコピーリンクがクリップボードにコピーされました!

2.3. BIOS 設定リンクのコピーリンクがクリップボードにコピーされました!

第3章 ソフトウェア要件リンクのコピーリンクがクリップボードにコピーされました!

3.1. リポジトリーの登録と有効化リンクのコピーリンクがクリップボードにコピーされました!

3.2. NFV デプロイメントでサポートされている構成リンクのコピーリンクがクリップボードにコピーされました!

3.3. サポートされているドライバーリンクのコピーリンクがクリップボードにコピーされました!

3.4. サードパーティー製のソフトウェアとの互換性リンクのコピーリンクがクリップボードにコピーされました!

第4章 ネットワークの考慮事項リンクのコピーリンクがクリップボードにコピーされました!

第5章 SR-IOV デプロイメントのプランニングリンクのコピーリンクがクリップボードにコピーされました!

5.1. SR-IOV デプロイメント向けのハードウェアの分割リンクのコピーリンクがクリップボードにコピーされました!

5.2. NFV SR-IOV デプロイメントのトポロジーリンクのコピーリンクがクリップボードにコピーされました!

5.2.1. HCI を使用しない NFV SR-IOV のトポロジーリンクのコピーリンクがクリップボードにコピーされました!

第6章 SR-IOV テクノロジーのデプロイリンクのコピーリンクがクリップボードにコピーされました!

6.1. 前提条件リンクのコピーリンクがクリップボードにコピーされました!

6.2. SR-IOV の設定リンクのコピーリンクがクリップボードにコピーされました!

6.3. NIC の分割リンクのコピーリンクがクリップボードにコピーされました!

6.4. OVS ハードウェアオフロードの設定リンクのコピーリンクがクリップボードにコピーされました!

6.4.1. OVS ハードウェアオフロードの確認リンクのコピーリンクがクリップボードにコピーされました!

6.5. SR-IOV 用インスタンスのデプロイリンクのコピーリンクがクリップボードにコピーされました!

6.6. ホストアグリゲートの作成リンクのコピーリンクがクリップボードにコピーされました!

手順

第7章 OVS-DPDK デプロイメントのプランニングリンクのコピーリンクがクリップボードにコピーされました!

7.1. CPU 分割と NUMA トポロジーを使用する OVS-DPDKリンクのコピーリンクがクリップボードにコピーされました!

7.2. ワークフローと派生パラメーターリンクのコピーリンクがクリップボードにコピーされました!

7.3. OVS-DPDK の派生パラメーターリンクのコピーリンクがクリップボードにコピーされました!

7.4. OVS-DPDK パラメーターの手動計算リンクのコピーリンクがクリップボードにコピーされました!

7.4.1. CPU パラメーターリンクのコピーリンクがクリップボードにコピーされました!

7.4.2. メモリーパラメーターリンクのコピーリンクがクリップボードにコピーされました!

7.4.3. ネットワークパラメーターリンクのコピーリンクがクリップボードにコピーされました!

7.4.4. その他のパラメーターリンクのコピーリンクがクリップボードにコピーされました!

7.4.5. インスタンスの追加仕様リンクのコピーリンクがクリップボードにコピーされました!

7.5. 2 NUMA ノード構成の OVS-DPDK デプロイメントの例リンクのコピーリンクがクリップボードにコピーされました!

7.6. NFV OVS-DPDK デプロイメントのトポロジーリンクのコピーリンクがクリップボードにコピーされました!

第8章 OVS-DPDK デプロイメントの設定リンクのコピーリンクがクリップボードにコピーされました!

8.1. ワークフローを使用した DPDK パラメーターの算出リンクのコピーリンクがクリップボードにコピーされました!

8.2. OVS-DPDK のトポロジーリンクのコピーリンクがクリップボードにコピーされました!

前提条件

8.3. OVS-DPDK インターフェースの MTU 値の設定リンクのコピーリンクがクリップボードにコピーされました!

8.4. セキュリティーグループのファイアウォールの設定リンクのコピーリンクがクリップボードにコピーされました!

8.5. OVS-DPDK インターフェース向けのマルチキューの設定リンクのコピーリンクがクリップボードにコピーされました!

8.6. 既知の制限リンクのコピーリンクがクリップボードにコピーされました!

8.7. OVS-DPDK 用のフレーバーの作成とインスタンスのデプロイリンクのコピーリンクがクリップボードにコピーされました!

8.8. 設定のトラブルシューティングリンクのコピーリンクがクリップボードにコピーされました!

第9章 Red Hat OpenStack Platform 環境の調整リンクのコピーリンクがクリップボードにコピーされました!

9.1. エミュレータースレッドの固定リンクのコピーリンクがクリップボードにコピーされました!

9.1.1. エミュレータースレッドをホストする CPU の設定リンクのコピーリンクがクリップボードにコピーされました!

手順

9.1.2. エミュレータースレッドが固定されていることの確認リンクのコピーリンクがクリップボードにコピーされました!

手順

9.2. NFV ワークロードに向けた RT-KVM の有効化リンクのコピーリンクがクリップボードにコピーされました!

9.2.1. RT-KVM コンピュートノードのプランニングリンクのコピーリンクがクリップボードにコピーされました!

9.2.2. RT-KVM 対応の OVS-DPDK の設定リンクのコピーリンクがクリップボードにコピーされました!

9.2.2.1. ComputeOvsDpdk コンポーザブルロールの生成リンクのコピーリンクがクリップボードにコピーされました!

9.2.2.2. OVS-DPDK パラメーターの設定リンクのコピーリンクがクリップボードにコピーされました!

9.2.2.3. オーバークラウドのデプロイリンクのコピーリンクがクリップボードにコピーされました!

9.2.3. RT-KVM インスタンスの起動リンクのコピーリンクがクリップボードにコピーされました!

9.3. 信頼済み Virtual Functionリンクのコピーリンクがクリップボードにコピーされました!

9.3.1. Virtual Function と Physical Function 間の信頼の設定リンクのコピーリンクがクリップボードにコピーされました!

前提条件

手順

9.3.2. 信頼済み VF ネットワークの活用リンクのコピーリンクがクリップボードにコピーされました!

9.4. 受信/送信キューサイズの設定リンクのコピーリンクがクリップボードにコピーされました!

前提条件

手順

テスト

9.5. NUMA 対応 vSwitch の設定リンクのコピーリンクがクリップボードにコピーされました!

前提条件

手順

テスト

9.6. NFVi 環境における Quality of Service (QoS) の設定リンクのコピーリンクがクリップボードにコピーされました!

第10章 例: OVS-DPDK および SR-IOV ならびに VXLAN トンネリングの設定リンクのコピーリンクがクリップボードにコピーされました!

10.1. ロールデータの設定リンクのコピーリンクがクリップボードにコピーされました!

10.2. OVS-DPDK パラメーターの設定リンクのコピーリンクがクリップボードにコピーされました!

10.3. コントローラーノードの設定リンクのコピーリンクがクリップボードにコピーされました!

はじめに
リンクのコピー

第1章 NFV の概要
リンクのコピー

第2章ハードウェア要件
リンクのコピー

2.1. テスト済み NIC
リンクのコピー

2.2. NUMA ノードのトポロジーについての理解
リンクのコピー

2.3. BIOS 設定
リンクのコピー

第3章ソフトウェア要件
リンクのコピー

3.1. リポジトリーの登録と有効化
リンクのコピー

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

3.3. サポートされているドライバー
リンクのコピー

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

第4章ネットワークの考慮事項
リンクのコピー

第5章 SR-IOV デプロイメントのプランニング
リンクのコピー

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

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

5.2.1. HCI を使用しない NFV SR-IOV のトポロジー
リンクのコピー

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

6.1. 前提条件
リンクのコピー

6.2. SR-IOV の設定
リンクのコピー

6.3. NIC の分割
リンクのコピー

6.4. OVS ハードウェアオフロードの設定
リンクのコピー

6.4.1. OVS ハードウェアオフロードの確認
リンクのコピー

6.5. SR-IOV 用インスタンスのデプロイ
リンクのコピー

6.6. ホストアグリゲートの作成
リンクのコピー

第7章 OVS-DPDK デプロイメントのプランニング
リンクのコピー

7.1. CPU 分割と NUMA トポロジーを使用する OVS-DPDK
リンクのコピー

7.2. ワークフローと派生パラメーター
リンクのコピー

7.3. OVS-DPDK の派生パラメーター
リンクのコピー

7.4. OVS-DPDK パラメーターの手動計算
リンクのコピー

7.4.1. CPU パラメーター
リンクのコピー

7.4.2. メモリーパラメーター
リンクのコピー

7.4.3. ネットワークパラメーター
リンクのコピー

7.4.4. その他のパラメーター
リンクのコピー

7.4.5. インスタンスの追加仕様
リンクのコピー

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

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

第8章 OVS-DPDK デプロイメントの設定
リンクのコピー

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

8.2. OVS-DPDK のトポロジー
リンクのコピー

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

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

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

8.6. 既知の制限
リンクのコピー

8.7. OVS-DPDK 用のフレーバーの作成とインスタンスのデプロイ
リンクのコピー

8.8. 設定のトラブルシューティング
リンクのコピー

第9章 Red Hat OpenStack Platform 環境の調整
リンクのコピー

9.1. エミュレータースレッドの固定
リンクのコピー

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

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

9.2. NFV ワークロードに向けた RT-KVM の有効化
リンクのコピー

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

9.2.2. RT-KVM 対応の OVS-DPDK の設定
リンクのコピー

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

9.2.2.2. OVS-DPDK パラメーターの設定
リンクのコピー

9.2.2.3. オーバークラウドのデプロイ
リンクのコピー

9.2.3. RT-KVM インスタンスの起動
リンクのコピー

9.3. 信頼済み Virtual Function
リンクのコピー

9.3.1. Virtual Function と Physical Function 間の信頼の設定
リンクのコピー

9.3.2. 信頼済み VF ネットワークの活用
リンクのコピー

9.4. 受信/送信キューサイズの設定
リンクのコピー

9.5. NUMA 対応 vSwitch の設定
リンクのコピー

9.6. NFVi 環境における Quality of Service (QoS) の設定
リンクのコピー

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

10.1. ロールデータの設定
リンクのコピー

10.2. OVS-DPDK パラメーターの設定
リンクのコピー

10.3. コントローラーノードの設定
リンクのコピー

10.4. DPDK および SR-IOV 用コンピュートノードの設定
リンクのコピー

10.5. オーバークラウドのデプロイ
リンクのコピー

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

第12章 NFV のパフォーマンス
リンクのコピー

第13章その他の参考資料
リンクのコピー

付録A DPDK SRIOV YAML ファイルのサンプル
リンクのコピー

A.1. VXLAN DPDK SRIOV YAML ファイルのサンプル
リンクのコピー

A.1.1. roles_data.yaml
リンクのコピー

A.1.2. network-environment-overrides.yaml
リンクのコピー

A.1.3. controller.yaml
リンクのコピー

A.1.4. compute-ovs-dpdk.yaml
リンクのコピー

A.1.5. overcloud_deploy.sh
リンクのコピー