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

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

download PDF
Red Hat OpenStack Platform 13

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

OpenStack Documentation Team

概要

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

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

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ をご覧ください。

Red Hat ドキュメントへのフィードバック (英語のみ)

弊社ドキュメントに対するご意見をお聞かせください。ドキュメントの改善点があればお知らせください。

ドキュメントへのダイレクトフィードバック (DDF) 機能の使用 (英語版のみ)

特定の文章、段落、またはコードブロックに対して直接コメントを送付するには、DDF の Add Feedback 機能を使用してください。なお、この機能は英語版のドキュメントでのみご利用いただけます。

  1. Multi-page HTML 形式でドキュメントを表示します。
  2. ドキュメントの右上隅に Feedback ボタンが表示されていることを確認してください。
  3. コメントするテキスト部分をハイライト表示します。
  4. Add Feedback をクリックします。
  5. Add Feedback フィールドにコメントを入力します。
  6. (オプション) ドキュメントチームが連絡を取り問題についてお伺いできるように、ご自分のメールアドレスを追加します。
  7. Submit をクリックします。

第1章 ネットワーク機能仮想化の概要

ネットワーク機能仮想化 (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
これらのファイルには、オーバークラウドノードのホストネットワークインターフェイス設定が含まれます。
host-config-and-reboot.yaml
このファイルは非推奨になった first-boot.yaml ファイルに置き換わるもので、ホストのインストールの設定が含まれます。

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

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

注記

NFV 設定の定義には、YAML ファイルを使用します。YAML ファイル形式に関する詳細な情報は、Red Hat Enterprise Linux Atomic Host 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. ネットワークアダプターのサポート

NFV 向けのテスト済み NIC の一覧は、カスタマーポータルにログインして Network Adapter Fast Datapath Feature Support Matrix のページの Network Adapter Support セクションを参照してください。

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 ノードのトポロジーについての理解

デプロイメントを計画する際には、最高のパフォーマンスが得られるように CPU およびメモリーのリソースを分割できるように、コンピュートノードの NUMA トポロジーを理解する必要があります。NUMA 情報を特定するには、以下のオプションのいずれかを使用することができます。

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

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

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

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

たとえば、numa_topology コレクターは、この追加ハードウェアイントロスペクションの一部で、各 NUMA ノードに関する以下の情報が含まれます。

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

この情報を取得するには、ベアメタルノードの 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 設定を記載します。

  • 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

2.4. ネットワークアダプター Fast Datapath 機能のサポートマトリックス

サポートされる FDP のバージョンの一覧は、カスタマーポータルにログインして Network Adapter Fast Datapath Feature Support Matrix のアーティクルを参照してください。

第3章 ソフトウェア要件

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

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

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

手順

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

    subscription-manager repos --disable=*

  2. Red Hat OpenStack Platform でネットワーク機能仮想化 (NFV) を使用するのに必要なリポジトリーを有効にします。 

    sudo subscription-manager repos \
--enable=rhel-7-server-rpms \
--enable=rhel-7-server-extras-rpms \
--enable=rhel-7-server-rh-common-rpms \
--enable=rhel-ha-for-rhel-7-server-rpms \
--enable=rhel-7-server-openstack-13-rpms \
--enable=rhel-7-server-nfv-rpms
注記

オーバークラウドノードを登録するには、オーバークラウドの高度なカスタマイズの オーバークラウドの登録 を参照してください。

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

Red Hat OpenStack Platform では、director を使用して以下のネットワーク機能仮想化 (NFV) デプロイメントがサポートされます。

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

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

注記

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

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

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

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

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

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

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

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

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

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

最小のオーバークラウドの設定は、以下のとおりです。

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

ネットワーク要件の詳しい情報は、director のインストールと使用方法の ネットワーク要件 を参照してください。

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

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

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

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

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

OpenStack NFV Hardware Capacities 464931 0118 SR IOV

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

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

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

NFV SR-IOV deployment

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

5.2.1. HCI を使用しない NFV SR-IOV

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

NFV SR-IOV Topology without HCI

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

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

6.1. 前提条件

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

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

6.2. SR-IOV の設定

注記

以下の例で説明する CPU の割り当て、確保するメモリー、および NIC の設定は、ご自分のトポロジーおよびユースケースとは異なる場合があります。

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

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

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

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

openstack overcloud container image prepare \
--namespace=registry.redhat.io/rhosp13 \
--push-destination=192.168.24.1:8787 \
--prefix=openstack- \
--tag-from-label {version}-{release} \
-e ${SERVICES}/neutron-sriov.yaml \
--roles-file /home/stack/templates/roles_data.yaml \
--output-env-file=/home/stack/templates/overcloud_images.yaml \
--output-images-file=/home/stack/local_registry_images.yaml
    注記

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

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

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

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

  4. クラスターでの要求およびハードウェア設定に基づき、parameter_defaults セクションで SR-IOV ノードのパラメーターを設定します。これらの設定は、通常 network-environment.yaml ファイルに追加されます。 

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

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

    注記

    ネットワーク設定テンプレートの numvfs 属性が優先されるため、NeutronSriovNumVFs パラメーターは間もなく非推奨になります。Red Hat では、デプロイ後の NeutronSriovNumVFs パラメーターおよび numvfs パラメーターの変更をサポートしません。動作中の環境でどちらのパラメーターを変更しても、PF の SR-IOV ポートを持つ実行中のインスタンスがすべて使用できなくなることが知られています。これらのインスタンスをハードリブートしない限り、インスタンスは SR-IOV PCI デバイスを認識しません。 

      ComputeSriovParameters:
    IsolCpusList: "1-19,21-39"
    KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=1-19,21-39"
    TunedProfileName: "cpu-partitioning"
    NeutronBridgeMappings:
      - tenant:br-link0
    NeutronPhysicalDevMappings:
      - tenant:p7p1
      - tenant:p7p2
    NeutronSriovNumVFs:
      - p7p1:5
      - p7p2:5
    NovaPCIPassthrough:
      - vendor_id: "8086"
        product_id: "1528"
        address: "0000:06:00.0"
        physical_network: "tenant"
      - vendor_id: "8086"
        product_id: "1528"
        address: "0000:06:00.1"
        physical_network: "tenant"
    NovaVcpuPinSet: '1-19,21-39'
    NovaReservedHostMemory: 4096
    注記

    NIC のデバイス名は変更される可能性があるため、PCI パススルーを設定する場合は devname パラメーターを使用しないでください。代わりに、vendor_id と product_id の方が安定しているため使用するか、NIC の address を使用してください。NovaPCIPassthrough の設定方法の詳細は、NovaPCIPassthrough 設定のガイドライン を参照してください。

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

                 - type: interface
                name: p7p3
                mtu: 9000
                use_dhcp: false
                defroute: false
                nm_controlled: true
                hotplug: true

              - type: interface
                name: p7p4
                mtu: 9000
                use_dhcp: false
                defroute: false
                nm_controlled: true
                hotplug: true

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

    NovaSchedulerDefaultFilters: ['AvailabilityZoneFilter','RamFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','AggregateInstanceExtraSpecsFilter']
  8. オーバークラウドをデプロイします。 
TEMPLATES_HOME="/usr/share/openstack-tripleo-heat-templates"
CUSTOM_TEMPLATES="/home/stack/templates"

openstack overcloud deploy --templates \
  -r ${CUSTOM_TEMPLATES}/roles_data.yaml \
  -e ${TEMPLATES_HOME}/environments/host-config-and-reboot.yaml \
  -e ${TEMPLATES_HOME}/environments/services/neutron-sriov.yaml \
  -e ${CUSTOM_TEMPLATES}/network-environment.yaml

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

Openv Switch (OVS) ハードウェアオフロードはテクノロジープレビューであり、実稼働環境のデプロイメントでの使用は推奨されせん。テクノロジープレビュー機能についての詳しい情報は、対象範囲の詳細 を参照してください。

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

手順

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

    openstack overcloud roles generate -o roles_data.yaml Controller ComputeSriov
  2. ロール固有のパラメーターセクションに OvsHwOffload パラメーターを追加し、値を true に設定してます。
  3. neutron が iptables/ハイブリッドのファイアウォールドライバーの実装を使用するように設定するには、NeutronOVSFirewallDriver: iptables_hybrid の行を追加します。NeutronOVSFirewallDriver の詳細は、オーバークラウドの高度なカスタマイズ の Open vSwitch ファイアウォールの使用 を参照してください。

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

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

    • VXLAN の場合には、physical_network パラメーターを null に設定します。

      例: 

      parameter_defaults:
  NeutronOVSFirewallDriver: iptables_hybrid
  ComputeSriovParameters:
    IsolCpusList: 2-9,21-29,11-19,31-39
    KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=128 intel_iommu=on iommu=pt"
    OvsHwOffload: true
    TunedProfileName: "cpu-partitioning"
    NeutronBridgeMappings:
      - tenant:br-tenant
    NovaPCIPassthrough:
      - vendor_id: <vendor-id>
        product_id: <product-id>
        address: <address>
        physical_network: "tenant"
      - vendor_id: <vendor-id>
        product_id: <product-id>
        address: <address>
        physical_network: "null"
    NovaReservedHostMemory: 4096
    NovaComputeCpuDedicatedSet: 1-9,21-29,11-19,31-39
    • <vendor-id> は、物理 NIC のベンダー ID に置き換えます。
    • <product-id> は、NIC VF のプロダクト ID に置き換えます。

    • <address> は、物理 NIC のアドレスに置き換えます。

      NovaPCIPassthrough の設定方法の詳細は、NovaPCIPassthrough 設定のガイドライン を参照してください。

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

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

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

      - type: ovs_bridge
    name: br-tenant
    mtu: 9000
    members:
    - type: sriov_pf
      name: p7p1
      numvfs: 5
      mtu: 9000
      primary: true
      promisc: true
      use_dhcp: false
      link_mode: switchdev
    注記
    • Open vSwitch ハードウェアオフロードを設定する場合には、NeutronSriovNumVFs パラメーターを使用しないでください。Virtual Function の数は、os-net-config で使用されるネットワーク設定ファイルの numvfs パラメーターを使用して指定します。Red Hat では、更新または再デプロイ時の numvfs 設定の変更をサポートしません。
    • Mellanox ネットワークインターフェイスの nic-config インターフェイス種別を ovs-vlan に設定しないでください。ドライバーの制約により、VXLAN 等のトンネルエンドポイントがトラフィックを渡さなくなるためです。

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

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

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

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

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

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

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

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

  3. NIC でハードウェアオフロードが有効であることを確認します。 

    # ethtool -k $NIC | grep tc-offload
hw-tc-offload: on

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

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

注記

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

手順

  1. デプロイメントの前に、nova.conf 設定ファイルの parameter_defaults の下にある heat パラメーター NovaSchedulerDefaultFilters を使用して、AggregateInstanceExtraSpecsFilter の値およびその他の必要なフィルターを設定することができます。 

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

    AggregateInstanceExtraSpecsFilter 設定を既存クラスターに追加するには、このパラメーターを heat テンプレートに追加して、元のデプロイメントスクリプトを再度実行します。

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

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

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

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

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

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

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

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

重要

OVS-DPDK および OVS ネイティブファイアウォール (conntrack に基づくステートフルファイアウォール) を使用する場合、追跡することができるのは ICMPv4、ICMPv6、TCP、および UDP プロトコルを使用するパケットだけです。OVS は、その他すべてのネットワークトラフィック種別を無効と識別します。

CPU と NUMA トポロジーの概要は、ネットワーク機能仮想化 (NFV) の製品ガイドの NFV のパフォーマンスの考慮事項 を参照してください。

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

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

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

OpenStack NFV NUMA 9 0219
注記

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

OVS-DPDK のパフォーマンスは、NUMA ノードにローカルなメモリーブロックの確保にも左右されます。メモリーと CPU ピニングに使用する同じ NUMA ノードに関連付けられた NIC を使用してください。また、ボンディングを設定する両方のインターフェイスには、同じ NUMA ノード上の NIC を必ず使用してください。

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

重要

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

OpenStack Workflow (mistral) サービスを使用すると、利用可能なベアメタルノードのケイパビリティーに基づいてパラメーターを派生することができます。Openstack Workflow は .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 の配置スケジューラーを考慮して、ロールに関連付けられたノードを照合し、そのロールと一致する最初のノードのイントロスペクションデータを使用します。

OpenStack のワークフローに関する詳細は、director のインストールと使用方法の ワークフローおよび実行に関するトラブルシューティング を参照してください。

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

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

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

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

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

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

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

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

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

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

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

注記

derived_parameters.yaml ワークフローを使用してこれらのパラメーターの値を自動生成した場合には、手動で計算する必要はありません。ワークフローと派生パラメーターについての概要 を参照してください。

注記

CPU コアを割り当てる際には必ず、同じ物理コア上の CPU シブリングスレッド (論理 CPU) をペアにしてください。

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

7.4.1. CPU パラメーター

OVS-DPDK は以下の CPU 分割パラメーターを使用します。

OvsPmdCoreList

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

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

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

    • パフォーマンス要件に基づいて、必要な物理コア数を決定し、各物理コアに全シブリングスレッド (論理 CPU) を追加します。

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

    • 1 つの物理コアのシブリングスレッド (論理 CPU) を割り当てます (NUMA ノードの 1 番目の物理コアを除く)。
注記

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

NovaVcpuPinSet

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

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

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

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

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

  • 各 NUMA ノードから、1 番目の物理コア (およびシブリングスレッド) を割り当てます (NUMA に関連付けられている DPDK 用の NIC がない場合も)。
  • これらのコアは、OvsPmdCoreList および NovaVcpuPinSet のコアの一覧と相互に排他的である必要があります。
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 パラメーターは Open vSwitch により other_config:dpdk-extra="-n <value>" 値として使用されます。

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

ホスト上のタスク用にメモリーを MB 単位で確保します。この値は、コンピュートノードにより nova.conf の reserved_host_memory_mb 値として使用されます。

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

NUMA ノードごとにヒュージページプールから事前に割り当てるメモリーの容量を MB 単位で指定します。この値は、Open vSwitch により other_config:dpdk-socket-mem 値として使用されます。

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

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

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

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

MTU サイズが 1500 でない場合は、/var/log/messages に Failed to create memory pool エラーメッセージが表示されることがあります。インスタンスの起動時にこのエラーメッセージが表示された場合は、無視できます。このメッセージを回避するには、OvsDpdkSocketMemory の計算に 1500 MTU の余分な OvsDpdkSocketMemory 量を追加します。

計算例: MTU 2000 および MTU 9000

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

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

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

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

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

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

    2625634304 + 746586112 + 536870912 = 3909091328 bytes.

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

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

    3909091328 / (1024*1024) = 3728 MB.

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

    3724 MB rounds up to 4096 MB.

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

        OvsDpdkSocketMemory: “4096,1024”

計算例: MTU 2000

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

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

    The MTU value of 2000 becomes 2048 bytes.

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

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

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

    746586112 + 536870912 = 1283457024 bytes.

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

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

    1283457024 / (1024*1024) = 1224 MB.

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

    1224 MB rounds up to 2048 MB.

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

        OvsDpdkSocketMemory: “2048,1024”

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

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

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

NovaSchedulerDefaultFilters
要求されたゲストインスタンスに対してコンピュートノードが使用するフィルターの順序付きリストを指定します。
VhostuserSocketGroup
vhost-user ソケットディレクトリーのグループを設定します。デフォルト値は qemu です。*VhostuserSocketGroup* は、ovs-vswitchd および qemu プロセスが virtio-net デバイスの設定に使用される共有ヒュージページおよび unix ソケットにアクセスできるように、hugetlbfs に設定する必要があります。この値はロールに固有で、OVS-DPDK を利用するすべてのロールに適用する必要があります。
KernelArgs

コンピュートノードのブート時用に、複数のカーネル引数を /etc/default/grub に指定します。設定に応じて、以下のパラメーターを追加します。

  • hugepagesz: CPU 上のヒュージページのサイズを設定します。この値は、CPU のハードウェアによって異なります。OVS-DPDK デプロイメントには 1G に指定します (default_hugepagesz=1GB hugepagesz=1G)。pdpe1gb CPU フラグが出力されるかどうかをチェックして、CPU が 1G をサポートしていることを確認してください。 

    lshw -class processor | grep pdpe1gb
  • hugepages count: ヒュージページの数を設定します。この値は、ホストの使用可能なメモリーの量によって異なります。利用可能なメモリーの大半を使用してください (NovaReservedHostMemory を除く)。ヒュージページ数の値は、お使いのコンピュートノードに関連付けられている OpenStack フレーバーの範囲内で設定する必要もあります。
  • iommu: Intel CPU の場合は、"intel_iommu=on iommu=pt" を追加します。
  • isolcpus: チューニングされる CPU コアを設定します。この値は IsolCpusList と一致します。

7.4.5. インスタンスの追加仕様

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

hw:cpu_policy
ゲストがピニングされた CPU を使用するように、このパラメーターの値を dedicated に設定します。このパラメーターセットのフレーバーから作成したインスタンスの有効オーバーコミット比は、1 : 1 です。デフォルトは shared です。
hw:mem_page_size

このパラメーターの値を、特定の値と標準の単位からなる有効な文字列に設定します (例: 4KB、8MB、または 1GB)。hugepagesz ブートパラメーターに一致させるには、1GB を使用します。仮想マシンで使用可能なヒュージページの数は、ブートパラメーターから OvsDpdkSocketMemory を引いた値です。これ以外の有効なパラメーター値を以下に示します。

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

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

本項に例示するコンピュートノードは、以下のような 2 つの NUMA ノードで設定されます。

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

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

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

OvsDpdkSocketMemory: “1024,1024”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Red Hat では、NUMA ノードごとに 1 つの物理コアを使用することを推奨します。

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 deployment

NFV OVS-DPDK のトポロジー

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

NFV OVS-DPDK Topology

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

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

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

重要

OVS-DPDK 用の OpenStack を最適化するには、network-environment.yaml ファイルに設定する OVS-DPDK パラメーターの最適な値を判断する必要があります。

注記

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

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

重要

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

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

前提条件

このワークフローで取得されるデータを提供するには、ハードウェア検査で追加情報を取得するための追加のパラメーター (inspection_extras) を含むベアメタルのイントロスペクションを有効化しておく必要があります。ハードウェア検査の追加パラメーターはデフォルトで有効化されます。director のインストールと使用方法の ノードのハードウェアの検査 を参照してください。

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

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

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

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

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

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

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

  2. openstack overcloud deploy コマンドを実行し、以下の項目を追加します。

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

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

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

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

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

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

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

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

  1. 派生パラメーターを plan-environment.yaml ファイルから network-environment.yaml ファイルにコピーします。 

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

    これらのパラメーターは、唯一ロール ComputeOvsDpdk に適用され、同じクラスター上に存在する Compute または ComputeSriov 等の他のロールには適用されません。これらのパラメーターはグローバルに適用可能ですが、グローバルパラメーターはロール固有のパラメーターによってオーバーライドされます。

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

8.2. OVS-DPDK のトポロジー

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

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

OpenStack NFV Config Guide Topology 450694 0617 ECE OVS DPDK

OVS-DPDK の設定は、以下の作業で設定されます。

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

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

手順を開始する前に、少なくとも以下の項目が揃っていることを確認します。

注記

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

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

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

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

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

注記

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

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

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

    parameter_defaults:
  # MTU global configuration
  NeutronGlobalPhysnetMtu: 9000
    注記

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

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

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

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

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

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

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

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

例: 

parameter_defaults:
  NeutronOVSFirewallDriver: openvswitch

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

例: 

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

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

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

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

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

  1. DPDK Compute ロールのパラメーターが network-environment.yaml に反映されていることを確認します。必要であれば、これらのパラメーターは 派生 OVS-DPDK パラメーターからコピーすることができます。 

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

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

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

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

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

openstack overcloud deploy --templates \
-r ${CUSTOM_TEMPLATES}/roles_data.yaml \
-e ${TEMPLATES_HOME}/environments/host-config-and-reboot.yaml \
-e ${CUSTOM_TEMPLATES}/network-environment.yaml \
-e ${CUSTOM_TEMPLATES}/controller.yaml
-e ${CUSTOM_TEMPLATES}/computeovsdpdk.yaml \
...

8.7. 既知の制限

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  5. オプション: OVS-DPDK と共にマルチキューを使用する場合、インスタンスの作成に使用するイメージで hw_vif_multiqueue_enabled 属性を設定します。 

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

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

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

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

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

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

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

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

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

    コンテナーが起動しない場合には、関連する何らかのメッセージが表示されるはずです。 

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

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

    CPU4 の例を以下に示します。 

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

    CPU 4 と 20 を使用します。 

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

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

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

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

9.1. 信頼済み Virtual Function

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

9.1.1. 信頼の付与

前提条件
  • Red Hat OpenStack Platform director のインストールが稼働していること。
手順

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

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

    parameter_defaults:
  NeutronPhysicalDevMappings:
    - sriov2:p5p2

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

    parameter_defaults:
  NeutronPhysicalDevMappings:
    - sriov2:p5p2
  NeutronSriovNumVFs: ["p5p2:8"]
  NovaPCIPassthrough:
    - vendor_id: "8086"
      product_id: "1572"
      physical_network: "sriov2"
      trusted: "true"
    注記

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

    重要

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

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

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

9.1.2. 信頼済み Virtual Function の活用

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

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

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

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

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

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

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

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

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

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

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

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

# 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

ip link コマンドの出力を表示し、Virtual Function の信頼ステータスが trust on であることを確認します。上記の出力例には、2 つのポートが含まれる環境の詳細が示されています。vf 6 に trust on のテキストが含まれている点に注意してください。

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

以下に示す理由により、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.3. NFV ワークロードに向けた RT-KVM の有効化

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

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

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

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

注記

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

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

Real-time コンピュートノード用のオーバークラウドイメージをビルドするには、以下の手順を使用します。

  1. stack ユーザーを初期化して director のコマンドラインツールを使用するには、以下のコマンドを実行します。 

    [stack@undercloud-0 ~]$ source ~/stackrc

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

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

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

    $ sudo systemctl disable --now iscsid.socket

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

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

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

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

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

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

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

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

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

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

    virt-customize -a overcloud-realtime-compute.qcow2 --run-command \
'subscription-manager repos --enable=rhel-7-server-nfv-rpms \
--enable=rhel-7-server-rpms \
--enable=rhel-7-server-rh-common-rpms \
--enable=rhel-7-server-extras-rpms \
--enable=rhel-7-server-openstack-13-rpms'

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

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

  set -eux

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

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

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

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

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

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

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

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

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

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

    注記

    vmlinuz および initramfs のファイル名に含まれるソフトウェアバージョンは、カーネルバージョンによって異なります。ファイル名に適切なソフトウェアバージョンを使用してください。たとえば image/boot/vmlinuz-3.10.0-862.rt56.804.el7x86_64。あるいは、代わりにワイルドカードの記号 * を使用してください。 

    (undercloud) [stack@undercloud-0 ~]$ mkdir image
(undercloud) [stack@undercloud-0 ~]$ guestmount -a overcloud-realtime-compute.qcow2 -i --ro image
(undercloud) [stack@undercloud-0 ~]$ cp image/boot/vmlinuz-*.x86_64 ./overcloud-realtime-compute.vmlinuz
(undercloud) [stack@undercloud-0 ~]$ cp image/boot/initramfs-*.x86_64.img ./overcloud-realtime-compute.initrd
(undercloud) [stack@undercloud-0 ~]$ guestunmount image

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

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

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

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

RT-KVM コンピュートノードのレイテンシーを短縮するために、BIOS 設定を変更する必要があります。コンピュートノードの BIOS 設定で、以下のセクションの全オプションを無効にする必要があります。

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

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

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

注記

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

9.3.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.3.2.2. OVS-DPDK パラメーターの設定
重要

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

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

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

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

      # DPDK compute node.
  ComputeOvsDpdkRTParameters:
    KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=1-7,17-23,9-15,25-31"
    TunedProfileName: "realtime-virtual-host"
    IsolCpusList: "1-7,17-23,9-15,25-31"
    NovaVcpuPinSet: ['2-7,18-23,10-15,26-31']
    NovaReservedHostMemory: 4096
    OvsDpdkSocketMemory: "1024,1024"
    OvsDpdkMemoryChannels: "4"
    OvsDpdkCoreList: "0,16,8,24"
    OvsPmdCoreList: "1,17,9,25"
    VhostuserSocketGroup: "hugetlbfs"
  ComputeOvsDpdkRTImage: "overcloud-realtime-compute"
9.3.2.3. コンテナーイメージの準備

コンテナーイメージを準備します。 

(undercloud) [stack@undercloud-0 ~]$ openstack overcloud container image prepare --namespace=192.0.40.1:8787/rhosp13 --env-file=/home/stack/ospd-13-vlan-dpdk/docker-images.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-ovs-dpdk.yaml -e /home/stack/ospd-13-vlan-dpdk/network-environment.yaml --roles-file /home/stack/ospd-13-vlan-dpdk/roles_data.yaml --prefix=openstack- --tag=2018-03-29.1 --set ceph_namespace=registry.redhat.io/rhceph --set ceph_image=rhceph-3-rhel7 --set ceph_tag=latest
9.3.2.4. オーバークラウドのデプロイ

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

(undercloud) [stack@undercloud-0 ~]$ openstack overcloud deploy \
--templates \
-r /home/stack/ospd-13-vlan-dpdk-ctlplane-bonding-rt/roles_data.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-ovs-dpdk.yaml \
-e /home/stack/ospd-13-vxlan-dpdk-data-bonding-rt-hybrid/docker-images.yaml \
-e /home/stack/ospd-13-vxlan-dpdk-data-bonding-rt-hybrid/network-environment.yaml

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

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

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

    # openstack flavor create --ram 4096 --disk 20 --vcpus 4 <flavor-name>
# openstack flavor set --property hw:cpu_policy=dedicated <flavor-name>
# openstack flavor set --property hw:cpu_realtime=yes <flavor-name>
# openstack flavor set --property hw:mem_page_size=1GB <flavor-name>
# openstack flavor set --property hw:cpu_realtime_mask="^0-1" <flavor-name>
# openstack flavor set --property hw:emulator_threads_policy=isolate <flavor-name>

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

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

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

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

9.4. NUMA 対応 vSwitch の設定 (テクノロジープレビュー)

重要

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

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

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

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

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

重要

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

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

前提条件
  • フィルター NUMATopologyFilter を有効にしていること
手順
  • 新たに 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.5. NFVi 環境における Quality of Service (QoS) の設定

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

9.6. HCI および DPDK を使用するオーバークラウドのデプロイ

ハイパーコンバージドノードと共に NFV インフラストラクチャーをデプロイするには、リソースの使用率を最適化するために Compute サービスと Ceph Storage サービスを共存させて設定します。

ハイパーコンバージドインフラストラクチャー (HCI) についての詳しい情報は、ハイパーコンバージドインフラストラクチャーガイド を参照してください。

前提条件
  • Red Hat OpenStack Platform 13.12 メンテナーンスリリース (2019 年 12 月 19 日) またはそれ以降
  • Ceph 12.2.12-79 (luminous) またはそれ以降
  • Ceph-ansible 3.2.38 またはそれ以降
手順

  1. アンダークラウドに ceph-ansible をインストールします。 

    $ sudo yum install ceph-ansible -y

  2. ComputeHCI ロール用に roles_data.yaml ファイルを生成します。 

    $ openstack overcloud roles generate -o ~/<templates>/roles_data.yaml Controller \
 ComputeHCIOvsDpdk
  3. openstack flavor create および openstack flavor set コマンドを使用して、新規フレーバーを作成および設定します。フレーバー作成についての詳細は、Advanced Overcloud Customization Guideの Creating a new role を参照してください。

  4. 生成したカスタムの roles_data.yaml ファイルを使用して、オーバークラウドをデプロイします。 

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

9.6.1. NUMA ノード設定の例

パフォーマンスを向上させるために、テナントネットワークおよび Ceph オブジェクトサービスデーモン (OSD) を 1 つの NUMA ノード (例: NUMA-0) に配置し、VNF および NFV 以外の仮想マシンを別の NUMA ノード (例: NUMA-1) に配置します。

CPU の割り当て
NUMA-0NUMA-1

Ceph OSD 数 * 4 HT

VNF および NFV 以外の仮想マシン用のゲスト仮想 CPU

DPDK lcore - 2 HT

DPDK lcore - 2 HT

DPDK PMD - 2 HT

DPDK PMD - 2 HT

CPU 割り当ての例
 NUMA-0NUMA-1

Ceph OSD

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

 

DPDK-lcore

0,44

1,45

DPDK-pmd

2,46

3,47

nova

 

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

9.6.2. ceph 設定ファイルの例

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

以下のパラメーターを使用して、ceph OSD プロセスの CPU リソースを割り当てます。ワークロードおよびこのハイパーコンバージド環境のハードウェアに基づいて、値を調整します。

1
ceph_osd_docker_cpuset_cpus: SSD ディスクの場合は、OSD ごとに 4 つの CPU スレッドを割り当てます。HDD ディスクの場合は、OSD ごとに 1 つの CPU を割り当てます。ceph に関連付けられた NUMA ノードからのコアおよびシブリングスレッド、ならびに 3 つの一覧 NovaVcpuPinSet、OvsDpdkCoreList、および OvsPmdCoreList に記載されていない CPU の一覧を含めます。
2
ceph_osd_docker_cpu_limit: ceph OSD を ceph_osd_docker_cpuset_cpus からの CPU 一覧にピニングするには、この値を 0 に設定します。
3
ceph_osd_numactl_opts: 念のため、複数 NUMA にまたがる操作用にこの値を preferred に設定します。

9.6.3. DPDK 設定ファイルの例

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

    OvsPmdCoreList: "2,46,3,47"                                 # 4
    OvsDpdkCoreList: "0,44,1,45"                                # 5
    NumDpdkInterfaceRxQueues: 1
1
KernelArgs: hugepages を算出するには、合計メモリーから NovaReservedHostMemory パラメーターの値を減算します。
2
IsolCpusList: このパラメーターを使用して、ホストプロセスから分離する CPU コアのセットを割り当てます。IsolCpusList パラメーターの値を算出するには、NovaVcpuPinSet パラメーターの値に OvsPmdCoreList パラメーターの値を加えます。
3
OvsDpdkSocketMemory: OvsDpdkSocketMemory パラメーターを使用して、NUMA ノードごとにヒュージページプールから事前に割り当てるメモリー容量を指定します (MB 単位)。OVS-DPDK パラメーターの計算についての詳しい情報は、ovsdpdk パラメーター に関する説明を参照してください。
4
OvsPmdCoreList: このパラメーターを使用して、DPDK Poll Mode Driver (PMD) に使用される CPU コアを指定します。DPDK インターフェイスのローカルの NUMA ノードに関連付けられた CPU コアを選択します。OvsPmdCoreList パラメーターの値を算出するには、NUMA ノードごとに 2 つの HT シブリングスレッドを割り当てます。
5
OvsDpdkCoreList: このパラメーターを使用して、handler および revalidator スレッド等のデータパス以外の OVS-DPDK プロセス用の CPU コアを指定します。OvsDpdkCoreList パラメーターの値を算出するには、NUMA ノードごとに 2 つの HT シブリングスレッドを割り当てます。

9.6.4. nova 設定ファイルの例

parameter_defaults:
  ComputeHCIExtraConfig:
    nova::cpu_allocation_ratio: 16 # 2
    NovaReservedHugePages:                                         # 1
        - node:0,size:1GB,count:4
        - node:1,size:1GB,count:4
  NovaReservedHostMemory: 123904                                   # 2
  # All left over cpus from NUMA-1
  NovaVcpuPinSet:                                                  # 3
  ['5','7','9','11','13','15','17','19','21','23','25','27','29','31','33','35','37','39','41','43','49','51','|
  53','55','57','59','61','63','65','67','69','71','73','75','77','79','81','83','85','87
1
NovaReservedHugePages: NovaReservedHugePages パラメーターを使用して、ヒュージページプールからメモリーを事前に割り当てます (MB 単位)。これは、OvsDpdkSocketMemory パラメーターの値と同じ合計メモリーです。
2
NovaReservedHostMemory: NovaReservedHostMemory パラメーターを使用して、ホスト上のタスク用にメモリーを確保します (MB 単位)。確保しなければならないメモリー容量を算出するには、以下のガイドラインを使用します。
  • OSD ごとに 5 GB
  • 仮想マシンごとに 0.5 GB のオーバーヘッド
  • 一般的なホストプロセス用に 4 GB。複数 NUMA にまたがる OSD 操作によって生じるパフォーマンスの低下を防ぐために、十分なメモリーを割り当てるようにしてください。
3
NovaVcpuPinSet: NovaVcpuPinSet パラメーターを使用して、OvsPmdCoreList、OvsDpdkCoreList、または Ceph_osd_docker_cpuset_cpus に記載されていない CPU の一覧を指定します。CPU は DPDK NIC と同じ NUMA ノードになければなりません。

9.6.5. HCI-DPDK デプロイメントに推奨される設定

表9.1 HCI デプロイメント用の調整可能なパラメーター
ブロックデバイスの種別メモリー、デバイスごとの OSD および仮想 CPU

NVMe

メモリー : OSD ごとに 5 GB
デバイスごとの OSD 数: 4
デバイスごとの仮想 CPU 数: 3

SSD

メモリー : OSD ごとに 5 GB
デバイスごとの OSD 数: 1
デバイスごとの仮想 CPU 数: 4

HDD

メモリー : OSD ごとに 5 GB
デバイスごとの OSD 数: 1
デバイスごとの仮想 CPU 数: 1

以下の機能には、同じ NUMA ノードを使用します。

  • ディスクコントローラー
  • ストレージネットワーク
  • ストレージ CPU およびメモリー

DPDK プロバイダーネットワークの以下の機能には、別の NUMA ノードを割り当てます。

  • NIC
  • PMD CPU
  • ソケットメモリー

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

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

重要

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

10.1. ロールの設定

/usr/share/openstack-tripleo-heat-templates にあるデフォルトの roles_data.yaml ファイルをコピーし、それを編集してカスタムロールを設定します。

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

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

重要

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

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

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

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

    NeutronTunnelTypes: 'vxlan'
NeutronNetworkType: 'vxlan'

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

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

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

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

    ゲストの作成時にエラーが発生するのを防ぐためには、各 NUMA ノードで少なくとも 1 つの CPU を (シブリングスレッドと共に) 割り当てます。上記の例では、OvsPmdCoreList パラメーターの値は NUMA 0 からのコア 2 および 22 ならびに NUMA 1 からのコア 3 および 23 です。

    注記

    ヒュージページは、仮想マシンにより消費されます。また、OvsDpdkSocketMemory パラメーターを使用すると OVS-DPDK により消費されます。仮想マシンが利用可能なヒュージページ数を計算するには、ブートパラメーターの値から OvsDpdkSocketMemory の値を減算します。DPDK インスタンスに関連付けるフレーバーに hw:mem_page_size=1GB を追加する必要もあります。

    注記

    OvsDPDKCoreList および OvsDpdkMemoryChannels はこの手順に必須の設定なので、エラーを防ぐために正しく設定する必要があります。

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

      ##########################
  #  SR-IOV configuration  #
  ##########################
  NeutronMechanismDrivers: ['openvswitch','sriovnicswitch']
  NovaSchedulerDefaultFilters: ['RetryFilter','AvailabilityZoneFilter','RamFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','NUMATopologyFilter']
  NovaSchedulerAvailableFilters: ["nova.scheduler.filters.all_filters","nova.scheduler.filters.pci_passthrough_filter.PciPassthroughFilter"]
  NovaPCIPassthrough:
    - vendor_id: "8086"
      product_id: "1528"
      address: "0000:06:00.0"
      trusted: "true"
      physical_network: "sriov-1"
    - vendor_id: "8086"
      product_id: "1528"
      address: "0000:06:00.1"
      trusted: "true"
      physical_network: "sriov-2"

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

  1. 分離ネットワーク用のコントロールプレーンの Linux ボンディングを作成します。 

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

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

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

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

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

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

  3. neutron-dhcp-agent および neutron-metadata-agent サービスにアクセスするための OVS ブリッジを作成します。 

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

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

デフォルトの compute.yaml ファイルから computeovsdpdksriov.yaml ファイルを作成し、以下のように変更します。

  1. 分離ネットワーク用のコントロールプレーンの Linux ボンディングを作成します。 

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

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

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

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

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

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

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

    注記

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

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

overcloud_deploy.sh スクリプトを実行してオーバークラウドをデプロイします。 

#!/bin/bash

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

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

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

第12章 パフォーマンス

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

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

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

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

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

第13章 その他の参考資料

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

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

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

Red Hat Enterprise Linux

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

Red Hat OpenStack Platform

OpenStack のコンポーネントとそれらの依存関係をインストールするには、Red Hat OpenStack Platform director を使用します。director は、基本的な OpenStack 環境をアンダークラウドとして使用して、最終的なオーバークラウド内の OpenStack ノードをインストール、設定、管理します。アンダークラウドのインストールには、デプロイしたオーバークラウドに必要な環境に加えて、アンダークラウドのインストールには、追加のホストマシンが必要となる点に注意してください。詳しい手順は、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 SR-IOV YAML ファイルのサンプル

A.1.1. roles_data.yaml

###############################################################################
# File generated by TripleO                                                   #
###############################################################################
###############################################################################
# Role: Controller                                                            #
###############################################################################
- name: Controller
  description: |
    Controller role that has all the controler services loaded and handles
    Database, Messaging and Network functions.
  CountDefault: 1
  tags:
    - primary
    - controller
  networks:
    - External
    - InternalApi
    - Storage
    - StorageMgmt
    - Tenant
  # For systems with both IPv4 and IPv6, you may specify a gateway network for
  # each, such as ['ControlPlane', 'External']
  default_route_networks: ['External']
  HostnameFormatDefault: 'controller-%index%'
  # Deprecated & backward-compatible values (FIXME: Make parameters consistent)
  # Set uses_deprecated_params to True if any deprecated params are used.
  uses_deprecated_params: True
  deprecated_param_extraconfig: 'controllerExtraConfig'
  deprecated_param_flavor: 'OvercloudControlFlavor'
  deprecated_param_image: 'controllerImage'
  deprecated_nic_config_name: 'controller.yaml'
  ServicesDefault:
    - OS::TripleO::Services::Aide
    - OS::TripleO::Services::AodhApi
    - OS::TripleO::Services::AodhEvaluator
    - OS::TripleO::Services::AodhListener
    - OS::TripleO::Services::AodhNotifier
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::BarbicanApi
    - OS::TripleO::Services::BarbicanBackendSimpleCrypto
    - OS::TripleO::Services::BarbicanBackendDogtag
    - OS::TripleO::Services::BarbicanBackendKmip
    - OS::TripleO::Services::BarbicanBackendPkcs11Crypto
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CeilometerApi
    - OS::TripleO::Services::CeilometerCollector
    - OS::TripleO::Services::CeilometerExpirer
    - OS::TripleO::Services::CeilometerAgentCentral
    - OS::TripleO::Services::CeilometerAgentNotification
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CephMds
    - OS::TripleO::Services::CephMgr
    - OS::TripleO::Services::CephMon
    - OS::TripleO::Services::CephRbdMirror
    - OS::TripleO::Services::CephRgw
    - OS::TripleO::Services::CertmongerUser
    - OS::TripleO::Services::CinderApi
    - OS::TripleO::Services::CinderBackendDellPs
    - OS::TripleO::Services::CinderBackendDellSc
    - OS::TripleO::Services::CinderBackendDellEMCUnity
    - OS::TripleO::Services::CinderBackendDellEMCVMAXISCSI
    - OS::TripleO::Services::CinderBackendDellEMCVNX
    - OS::TripleO::Services::CinderBackendDellEMCXTREMIOISCSI
    - OS::TripleO::Services::CinderBackendNetApp
    - OS::TripleO::Services::CinderBackendScaleIO
    - OS::TripleO::Services::CinderBackendVRTSHyperScale
    - OS::TripleO::Services::CinderBackup
    - OS::TripleO::Services::CinderHPELeftHandISCSI
    - OS::TripleO::Services::CinderScheduler
    - OS::TripleO::Services::CinderVolume
    - OS::TripleO::Services::Clustercheck
    - OS::TripleO::Services::Collectd
    - OS::TripleO::Services::Congress
    - OS::TripleO::Services::Docker
    - OS::TripleO::Services::Ec2Api
    - OS::TripleO::Services::Etcd
    - OS::TripleO::Services::ExternalSwiftProxy
    - OS::TripleO::Services::Fluentd
    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GlanceRegistry
    - OS::TripleO::Services::GnocchiApi
    - OS::TripleO::Services::GnocchiMetricd
    - OS::TripleO::Services::GnocchiStatsd
    - OS::TripleO::Services::HAproxy
    - OS::TripleO::Services::HeatApi
    - OS::TripleO::Services::HeatApiCloudwatch
    - OS::TripleO::Services::HeatApiCfn
    - OS::TripleO::Services::HeatEngine
    - OS::TripleO::Services::Horizon
    - OS::TripleO::Services::Ipsec
    - OS::TripleO::Services::IronicApi
    - OS::TripleO::Services::IronicConductor
    - OS::TripleO::Services::IronicPxe
    - OS::TripleO::Services::Iscsid
    - OS::TripleO::Services::Keepalived
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Keystone
    - OS::TripleO::Services::LoginDefs
    - OS::TripleO::Services::ManilaApi
    - OS::TripleO::Services::ManilaBackendCephFs
    - OS::TripleO::Services::ManilaBackendIsilon
    - OS::TripleO::Services::ManilaBackendNetapp
    - OS::TripleO::Services::ManilaBackendUnity
    - OS::TripleO::Services::ManilaBackendVNX
    - OS::TripleO::Services::ManilaBackendVMAX
    - OS::TripleO::Services::ManilaScheduler
    - OS::TripleO::Services::ManilaShare
    - OS::TripleO::Services::Memcached
    - OS::TripleO::Services::MistralApi
    - OS::TripleO::Services::MistralEngine
    - OS::TripleO::Services::MistralExecutor
    - OS::TripleO::Services::MistralEventEngine
    - OS::TripleO::Services::MongoDb
    - OS::TripleO::Services::MySQL
    - OS::TripleO::Services::MySQLClient
    - OS::TripleO::Services::NeutronApi
    - OS::TripleO::Services::NeutronBgpVpnApi
    - OS::TripleO::Services::NeutronSfcApi
    - OS::TripleO::Services::NeutronCorePlugin
    - OS::TripleO::Services::NeutronDhcpAgent
    - OS::TripleO::Services::NeutronL2gwAgent
    - OS::TripleO::Services::NeutronL2gwApi
    - OS::TripleO::Services::NeutronL3Agent
    - OS::TripleO::Services::NeutronLbaasv2Agent
    - OS::TripleO::Services::NeutronLbaasv2Api
    - OS::TripleO::Services::NeutronLinuxbridgeAgent
    - OS::TripleO::Services::NeutronMetadataAgent
    - OS::TripleO::Services::NeutronML2FujitsuCfab
    - OS::TripleO::Services::NeutronML2FujitsuFossw
    - OS::TripleO::Services::NeutronOvsAgent
    - OS::TripleO::Services::NeutronVppAgent
    - OS::TripleO::Services::NovaApi
    - OS::TripleO::Services::NovaConductor
    - OS::TripleO::Services::NovaConsoleauth
    - OS::TripleO::Services::NovaIronic
    - OS::TripleO::Services::NovaMetadata
    - OS::TripleO::Services::NovaPlacement
    - OS::TripleO::Services::NovaScheduler
    - OS::TripleO::Services::NovaVncProxy
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::ContainersLogrotateCrond
    - OS::TripleO::Services::OctaviaApi
    - OS::TripleO::Services::OctaviaDeploymentConfig
    - OS::TripleO::Services::OctaviaHealthManager
    - OS::TripleO::Services::OctaviaHousekeeping
    - OS::TripleO::Services::OctaviaWorker
    - OS::TripleO::Services::OVNDBs
    - OS::TripleO::Services::OVNController
    - OS::TripleO::Services::Pacemaker
    - OS::TripleO::Services::PankoApi
    - OS::TripleO::Services::RabbitMQ
    - OS::TripleO::Services::Redis
    - OS::TripleO::Services::Rhsm
    - OS::TripleO::Services::RsyslogSidecar
    - OS::TripleO::Services::SaharaApi
    - OS::TripleO::Services::SaharaEngine
    - OS::TripleO::Services::Securetty
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::SkydiveAgent
    - OS::TripleO::Services::SkydiveAnalyzer
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::SwiftProxy
    - OS::TripleO::Services::SwiftDispersion
    - OS::TripleO::Services::SwiftRingBuilder
    - OS::TripleO::Services::SwiftStorage
    - OS::TripleO::Services::Tacker
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::Tuned
    - OS::TripleO::Services::Vpp
    - OS::TripleO::Services::Zaqar
    - OS::TripleO::Services::Ptp
###############################################################################
# Role: ComputeOvsDpdkSriov                                                   #
###############################################################################
- name: ComputeOvsDpdkSriov
  description: |
    Compute OvS DPDK+SR-IOV Role
  CountDefault: 1
  networks:
    - InternalApi
    - Tenant
    - Storage
  HostnameFormatDefault: 'compute-%index%'
  disable_upgrade_deployment: True
  ServicesDefault:
    - OS::TripleO::Services::Aide
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CertmongerUser
    - OS::TripleO::Services::Collectd
    - OS::TripleO::Services::ComputeCeilometerAgent
    - OS::TripleO::Services::ComputeNeutronCorePlugin
    - OS::TripleO::Services::ComputeNeutronL3Agent
    - OS::TripleO::Services::ComputeNeutronMetadataAgent
    - OS::TripleO::Services::ComputeNeutronOvsDpdk
    - OS::TripleO::Services::Docker
    - OS::TripleO::Services::Fluentd
    - OS::TripleO::Services::Ipsec
    - OS::TripleO::Services::Iscsid
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::LoginDefs
    - OS::TripleO::Services::MySQLClient
    - OS::TripleO::Services::NeutronBgpVpnBagpipe
    - OS::TripleO::Services::NeutronSriovAgent
    - OS::TripleO::Services::NeutronSriovHostConfig
    - OS::TripleO::Services::NeutronVppAgent
    - OS::TripleO::Services::NovaCompute
    - OS::TripleO::Services::NovaLibvirt
    - OS::TripleO::Services::NovaMigrationTarget
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::ContainersLogrotateCrond
    - OS::TripleO::Services::OVNMetadataAgent
    - OS::TripleO::Services::Rhsm
    - OS::TripleO::Services::RsyslogSidecar
    - OS::TripleO::Services::Securetty
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::SkydiveAgent
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Timezone
  # Currently when attempting to deploy firewall service it notifies that it was specified multiple times
  # - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::Ptp
    - OS::TripleO::Services::Vpp
    - OS::TripleO::Services::OVNController

A.1.2. network-environment.yaml

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

parameter_defaults:
  # Customize all these values to match the local environment
  InternalApiNetCidr: 10.10.10.0/24
  TenantNetCidr: 10.10.2.0/24
  StorageNetCidr: 10.10.3.0/24
  StorageMgmtNetCidr: 10.10.4.0/24
  ExternalNetCidr: 172.20.12.112/28
  # CIDR subnet mask length for provisioning network
  ControlPlaneSubnetCidr: '24'
  InternalApiAllocationPools: [{'start': '10.10.10.10', 'end': '10.10.10.200'}]
  TenantAllocationPools: [{'start': '10.10.2.100', 'end': '10.10.2.200'}]
  StorageAllocationPools: [{'start': '10.10.3.100', 'end': '10.10.3.200'}]
  StorageMgmtAllocationPools: [{'start': '10.10.4.100', 'end': '10.10.4.200'}]
  # Use an External allocation pool which will leave room for floating IPs
  ExternalAllocationPools: [{'start': '172.20.12.114', 'end': '172.20.12.125'}]
  # Set to the router gateway on the external network
  ExternalInterfaceDefaultRoute: 172.20.12.126
  # Gateway router for the provisioning network (or Undercloud IP)
  ControlPlaneDefaultRoute: 192.168.24.1
  # Generally the IP of the Undercloud
  EC2MetadataIp: 192.168.24.1
  InternalApiNetworkVlanID: 10
  TenantNetworkVlanID: 11
  StorageNetworkVlanID: 12
  StorageMgmtNetworkVlanID: 13
  ExternalNetworkVlanID: 14
  # Define the DNS servers (maximum 2) for the overcloud nodes
  DnsServers: ["8.8.8.8","8.8.4.4"]
  # May set to br-ex if using floating IPs only on native VLAN on bridge br-ex
  NeutronExternalNetworkBridge: "''"
  # The tunnel type for the project network (vxlan or gre). Set to '' to disable tunneling.
  NeutronTunnelTypes: 'vxlan'
  # The project network type for Neutron (vlan or vxlan).
  NeutronNetworkType: 'vxlan,vlan'
  # The OVS logical->physical bridge mappings to use.
  NeutronBridgeMappings: 'dpdk-mgmt:br-link0'
  # The Neutron ML2 and OpenVSwitch vlan mapping range to support.
  NeutronNetworkVLANRanges: 'dpdk-mgmt:22:22,dpdk-mgmt:25:25,sriov-1:600:600,sriov-2:601:601'
  # Nova flavor to use.
  OvercloudControllerFlavor: controller
  OvercloudComputeOvsDpdkSriovFlavor: compute
  #Number of nodes to deploy.
  ControllerCount: 3
  ComputeOvsDpdkSriovCount: 2
  # NTP server configuration.
  NtpServer: clock.redhat.com
  # MTU global configuration
  NeutronGlobalPhysnetMtu: 9000
  # Configure the classname of the firewall driver to use for implementing security groups.
  NeutronOVSFirewallDriver: openvswitch
  SshServerOptions:
    UseDns: 'no'

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

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

A.1.3. controller.yaml

heat_template_version: queens

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

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

resources:
  OsNetConfigImpl:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template:
            get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
          params:
            $network_config:
              network_config:
              - type: interface
                name: nic1
                use_dhcp: false
                addresses:
                - ip_netmask:
                    list_join:
                    - /
                    - - get_param: ControlPlaneIp
                      - get_param: ControlPlaneSubnetCidr
                routes:
                - ip_netmask: 169.254.169.254/32
                  next_hop:
                    get_param: EC2MetadataIp

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

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

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

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

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

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

outputs:
  OS::stack_id:
    description: The OsNetConfigImpl resource.
    value:
      get_resource: OsNetConfigImpl

A.1.4. compute-ovs-dpdk.yaml

heat_template_version: queens

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

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

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

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

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

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

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

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

              - type: interface
                name: p7p3
                mtu: 9000
                use_dhcp: false
                defroute: false
                nm_controlled: true
                hotplug: true

              - type: interface
                name: p7p4
                mtu: 9000
                use_dhcp: false
                defroute: false
                nm_controlled: true
                hotplug: true

outputs:
  OS::stack_id:
    description: The OsNetConfigImpl resource.
    value:
      get_resource: OsNetConfigImpl

A.1.5. overcloud_deploy.sh

#!/bin/bash

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

付録B Revision History

改訂履歴
改訂 1.6-0March 07 2019 
Revision of Chapter 6 for more detail on SR-IOV configuration.
改訂 1.5-0January 14 2019 
Sample templates are replaced with DPDK/SR-IOV with OVS/ML2
改訂 1.4-0August 23 2018 
Fixed parameter alignment for step 4 of `Configuring SR-IOV with OVS Hardware Offload with VLAN`.
改訂 1.3-0August 20 2018 
Added note about SKU requirement for RT-KVM repository.
改訂 1.2-0July 31 2018 
Updated network creation steps to use OSC parameters. Added description of BIOS settings.
改訂 1.1-0July 12 2018 
Added sample DPDK ODL yaml files and procedures.
改訂 1.0-0June 27 2018 
Initial version for Red Hat OpenStack 13 GA release. Includes procedures for RT-KVM and OVS HW offload. Supports ovs 2.9.

法律上の通知

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

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.