ネットワーク機能仮想化 (NFV) のプランニングおよび設定ガイド
ネットワーク機能仮想化(NFV)Red Hat OpenStack Platform デプロイメントのプランニングおよび設定
概要
はじめに
Red Hat OpenStack Platform は、Red Hat Enterprise Linux 上にプライベートまたはパブリッククラウドを構築するための基盤を提供します。これにより、スケーラビリティーが極めて高く、耐障害性に優れたプラットフォームをクラウド対応のワークロード開発に利用できます。
本ガイドでは、Red Hat OpenStack Platform director を使用して、ネットワーク機能仮想化 (NFV) デプロイメント向けに Single Root I/O Virtualization (SR-IOV) および Data Plane Development Kit 対応 Open vSwitch (OVS-DPDK) のプランニングおよび設定を行う方法について説明します。
第1章 概要
ネットワーク機能仮想化(NFV: Network Functions Virtualization)とは、汎用のクラウドベースのインフラストラクチャー上でネットワーク機能を仮想化するソフトウェアソリューションです。NFV により、通信事業者 (CSP) は従来のハードウェアから離れることができます。
NFV の概念の概要は、『 ネットワーク機能仮想化(NFV)の製品ガイド』 を参照してください。
OVS-DPDK および SR-IOV の設定は、ハードウェアとトポロジーに依存します。本ガイドでは、CPU の割り当て、メモリーの確保、NIC の設定の例を紹介します。これらは、トポロジーとユースケースによって異なる場合があります。
Red Hat OpenStack Platform director を使用して、特定のネットワーク種別 (外部、テナント、内部 API 等) を分離します。ネットワークは、単一のネットワークインターフェース上に、または複数のホストネットワークインターフェースに分散してデプロイすることができます。Open vSwitch により、複数のインターフェースを単一のブリッジに割り当てて、ボンディングを作成することができます。Red Hat OpenStack Platform インストール環境でネットワークの分離を設定するには、テンプレートファイルを使用します。テンプレートファイルを指定しない場合、サービスネットワークはプロビジョニングネットワーク上にデプロイされます。テンプレートの設定ファイルには、2 つの種類があります。
-
network-environment.yaml
: このファイルには、サブネットおよび IP アドレス範囲などの、オーバークラウドノードのネットワーク情報が含まれます。このファイルには、さまざまなシナリオで使用できるように、デフォルトのパラメーター値を上書きする別の設定も含まれます。 -
compute.yaml
およびcontroller.yaml
等のホストのネットワークテンプレート: オーバークラウドノードのネットワークインターフェース設定が定義されます。ネットワーク情報の値は、network-environment.yaml
ファイルで指定します。
これらの Heat テンプレートファイルは、アンダークラウドノードの /usr/share/openstack-tripleo-heat-templates/
にあります。
「ハードウェア要件」および「ソフトウェア要件」の項では、Red Hat OpenStack Platform director を使用した NFV 用 Heat テンプレートファイルのプランニングおよび設定の方法について説明します。
YAML ファイルを編集して NFV を設定することができます。YAML ファイル形式の概要は、「 YAML in a Nutshell 」を参照してください。
第2章 ハードウェア要件
本項では、NFV のハードウェア要件について説明します。
Red Hat Technologies Ecosystem を使用して、認定済みハードウェア、ソフトウェア、クラウドプロバイダー、およびコンポーネントの一覧を確認することができます。
Red Hat OpenStack Platform の認定済みハードウェアの完全一覧については、Red Hat OpenStack Platform certified hardware を参照してください。
2.1. テスト済み NIC
NFV 向けのテスト済み NIC の一覧は、「Network Adapter Fast Datapath Feature Support Matrix」を参照してください。
Mellanox ConnectX-4 または ConnectX-5 ネットワークインターフェース上に OVS-DPDK を設定する場合には、compute-ovs-dpdk.yaml ファイルで該当するカーネルドライバーを設定する必要があります。
members - type: ovs_dpdk_port name: dpdk0 driver: mlx5_core members: - type: interface name: enp3s0f0
2.2. NUMA ノードのトポロジーについての理解
デプロイメントを計画する際には、最高のパフォーマンスが得られるように、コンピュートノードの NUMA トポロジーを理解して CPU およびメモリーのリソースを分割する必要があります。NUMA 情報を確認するには、以下のいずれかのタスクを実行します。
- ハードウェアイントロスペクションを有効にして、ベアメタルノードからこの情報を取得する。
- 各ベアメタルノードにログオンして、手動で情報を収集する。
ハードウェアイントロスペクションで NUMA 情報を取得するには、アンダークラウドのインストールと設定が完了している必要があります。アンダークラウド設定についての詳しい情報は、『 director のインストールと使用方法』 を参照してください。
ハードウェアイントロスペクション情報の取得
Bare Metal サービスのハードウェア検査の追加は、デフォルトで、ハードウェア情報の取得に有効になっています。これらのハードウェア情報を使って、オーバークラウドを設定することができます。undercloud.conf ファイル の inspection_extras パラメーターについての詳しい情報は、『director のインストールと使用方法』の「director の設定」を参照し てください。
たとえば、numa_topology コレクターは、このハードウェア検査の追加部分で、各 NUMA ノードに関する以下の情報が含まれます。
- RAM (キロバイト単位)
- 物理 CPU コアおよびそのシブリングスレッド
- NUMA ノードに関連付けられた NIC
手順
- 上記の情報を取得するには、<UUID> をベアメタルノードの UUID に置き換えて、以下のコマンドを実行します。
$ openstack baremetal introspection data save <UUID> | jq .numa_topology
取得されるベアメタルノードの NUMA 情報の例を以下に示します。
{ "cpus": [ { "cpu": 1, "thread_siblings": [ 1, 17 ], "numa_node": 0 }, { "cpu": 2, "thread_siblings": [ 10, 26 ], "numa_node": 1 }, { "cpu": 0, "thread_siblings": [ 0, 16 ], "numa_node": 0 }, { "cpu": 5, "thread_siblings": [ 13, 29 ], "numa_node": 1 }, { "cpu": 7, "thread_siblings": [ 15, 31 ], "numa_node": 1 }, { "cpu": 7, "thread_siblings": [ 7, 23 ], "numa_node": 0 }, { "cpu": 1, "thread_siblings": [ 9, 25 ], "numa_node": 1 }, { "cpu": 6, "thread_siblings": [ 6, 22 ], "numa_node": 0 }, { "cpu": 3, "thread_siblings": [ 11, 27 ], "numa_node": 1 }, { "cpu": 5, "thread_siblings": [ 5, 21 ], "numa_node": 0 }, { "cpu": 4, "thread_siblings": [ 12, 28 ], "numa_node": 1 }, { "cpu": 4, "thread_siblings": [ 4, 20 ], "numa_node": 0 }, { "cpu": 0, "thread_siblings": [ 8, 24 ], "numa_node": 1 }, { "cpu": 6, "thread_siblings": [ 14, 30 ], "numa_node": 1 }, { "cpu": 3, "thread_siblings": [ 3, 19 ], "numa_node": 0 }, { "cpu": 2, "thread_siblings": [ 2, 18 ], "numa_node": 0 } ], "ram": [ { "size_kb": 66980172, "numa_node": 0 }, { "size_kb": 67108864, "numa_node": 1 } ], "nics": [ { "name": "ens3f1", "numa_node": 1 }, { "name": "ens3f0", "numa_node": 1 }, { "name": "ens2f0", "numa_node": 0 }, { "name": "ens2f1", "numa_node": 0 }, { "name": "ens1f1", "numa_node": 0 }, { "name": "ens1f0", "numa_node": 0 }, { "name": "eno4", "numa_node": 0 }, { "name": "eno1", "numa_node": 0 }, { "name": "eno3", "numa_node": 0 }, { "name": "eno2", "numa_node": 0 } ] }
2.3. BIOS 設定
以下の表に NFV に必要な BIOS 設定をまとめます。
パラメーター | 設定 |
---|---|
| Disabled |
| Disabled |
| 有効 |
| 有効 |
| 有効 |
| 有効 |
| パフォーマンス |
| 有効 |
| Disabled |
| Intel カードで VFIO 機能が必要な場合には Enabled |
第3章 ソフトウェア要件
本項では、サポートされている設定とドライバー、および NFV に必要なサブスクリプションの詳細について説明します。
3.1. リポジトリーの登録と有効化
Red Hat OpenStack Platform をインストールするには、Red Hat サブスクリプションマネージャーを使用して Red Hat OpenStack Platform director を登録し、必要なリポジトリーを有効にする必要があります。詳しくは、「 director のインストールの準備 」を参照してください。
手順
コンテンツ配信ネットワークにシステムを登録し、プロンプトが表示されたらカスタマーポータルのユーザー名とパスワードを入力します。
[stack@director ~]$ sudo subscription-manager register
Red Hat OpenStack Platform director のエンタイトルメントプール ID を決定します。以下に例を示します。
[stack@director ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack" Subscription Name: Name of SKU Provides: Red Hat Single Sign-On Red Hat Enterprise Linux Workstation Red Hat CloudForms Red Hat OpenStack Red Hat Software Collections (for RHEL Workstation) Red Hat Virtualization SKU: SKU-Number Contract: Contract-Number Pool ID: {Pool-ID}-123456 Provides Management: Yes Available: 1 Suggested: 1 Service Level: Support-level Service Type: Service-Type Subscription Type: Sub-type Ends: End-date System Type: Physical
以下のコマンドで
Pool ID
の値を指定して、Red Hat OpenStack Platform 16.1 のエンタイトルメントをアタッチします。[stack@director ~]$ sudo subscription-manager attach --pool={Pool-ID}-123456
デフォルトのリポジトリーを無効にします。
subscription-manager repos --disable=*
Red Hat OpenStack Platform で NFV を使用するのに必要なリポジトリーを有効にします。
$ sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms \ --enable=rhel-8-for-x86_64-appstream-rpms \ --enable=rhel-8-for-x86_64-highavailability-rpms \ --enable=ansible-2.8-for-rhel-8-x86_64-rpms \ --enable=openstack-15-for-rhel-8-x86_64-rpms \ --enable=rhel-8-for-x86_64-nfv-rpms \ --enable=advanced-virt-for-rhel-8-x86_64-rpms \ --enable=fast-datapath-for-rhel-8-x86_64-rpms
最新のベースシステムパッケージに対してシステムで更新を実行します。
[stack@director ~]$ sudo dnf update -y [stack@director ~]$ sudo reboot
オーバークラウドノードを登録するには、「 Ansible ベースの登録 」を参照してください。
3.2. NFV デプロイメントでサポートされている構成
Red Hat OpenStack Platform (RHOSP) では、director を使用して以下の NFV デプロイメントがサポートされます。
- Single Root I/O Virtualization (SR-IOV)
- Data Plane Development Kit 対応 Open vSwitch (OVS-DPDK)
また、以下のどの機能と共に Red Hat OpenStack Platform をデプロイすることもできます。
- コンポーザブルロール
- ハイパーコンバージドインフラストラクチャー (サポートは限定的です)
- Real-time Compute の設定
- OVS ハードウェアオフロード (テクノロジープレビュー)
Red Hat の組み込み OpenDaylight SDN ソリューションは、RHOSP 14 で非推奨になりました。Red Hat は OpenDaylight のサポートおよびバグ修正を継続して提供しますが、すべてのサポートは 2021 年 6 月 27 日に RHOSP 13 のライフサイクルと共に終了します。
デフォルトの SDN ソリューションとして Open Virtual Network(OVN)を使用する RHOSP 15 NFV デプロイメントはサポートされません。OVS メカニズムドライバーと共に RHOSP をデプロイするには、以下の手順を使用します。
手順
containers-prepare-parameter.yaml
ファイルでneutron_driver
パラメーターをnull
に設定します。parameter_defaults: ContainerImagePrepare: - push_destination: true set: neutron_driver: openvswitch ...
/usr/share/openstack-tripleo-heat-templates/environments/services
ディレクトリーのneutron-ovs.yaml
環境ファイルを、デプロイメント用スクリプトに追加します。TEMPLATES=/usr/share/openstack-tripleo-heat-templates openstack overcloud deploy --templates \ -e ${TEMPLATES}/environments/network-environment.yaml \ -e ${TEMPLATES}/environments/network-isolation.yaml \ -e ${TEMPLATES}/environments/host-config-and-reboot.yaml \ -e ${TEMPLATES}/environments/services/neutron-ovs.yaml \ -e ${TEMPLATES}/environments/services/neutron-ovs-dpdk.yaml \ -e ${TEMPLATES}/environments/services/neutron-sriov.yaml \ -e /home/stack/containers-prepare-parameter.yaml
3.3. サポートされているドライバー
サポートされるドライバーの完全な一覧は「Component, Plug-In, and Driver Support in Red Hat OpenStack Platform」を参照してください。
Red Hat OpenStack の NFV デプロイメント向けにテスト済みの NIC の一覧は、「ネットワークアダプターのサポート」を参照してください。
3.4. サードパーティー製のソフトウェアとの互換性
Red Hat OpenStack Platform で機能することを検証、サポート、認定済みの製品およびサービスの完全な一覧は、Red Hat OpenStack Platform と互換性のあるサードパーティー製のソフトウェア の情報を参照してください。製品バージョンやソフトウェアカテゴリー別に一覧をフィルタリングすることができます。
Red Hat Enterprise Linux で機能することを検証、サポート、認定済みの製品およびサービスの完全な一覧は、Red Hat Enterprise Linux と互換性のあるサードパーティー製のソフトウェア の情報を参照してください。製品バージョンやソフトウェアカテゴリー別に一覧をフィルタリングすることができます。
第4章 ネットワークの考慮事項
アンダークラウドのホストには、最低でも以下のネットワークが必要です。
- プロビジョニングネットワーク: オーバークラウドで使用できるベアメタルシステムの検出に役立つ DHCP および PXE ブート機能を提供します。
- 外部ネットワーク: 全ノードへのリモート接続に使用する別個のネットワーク。このネットワークに接続するインターフェースには、静的または外部の DHCP サービスを介して動的に定義された、ルーティング可能な IP アドレスが必要です。
最小限のオーバークラウドのネットワーク構成には、以下の NIC 構成が含まれます。
- シングル NIC 構成: ネイティブ VLAN 上のプロビジョニングネットワークと、オーバークラウドネットワークの種別ごとのサブネットを使用するタグ付けされた VLAN 用に NIC を 1 つ。
- デュアル NIC 構成: プロビジョニングネットワーク用の NIC を 1 つと、外部ネットワーク用の NIC を 1 つ。
- デュアル NIC 構成: ネイティブ VLAN 上のプロビジョニングネットワーク用に NIC を 1 つと、オーバークラウドネットワークの種別ごとのサブネットを使用するタグ付けされた VLAN 用の NIC を 1 つ。
- 複数 NIC 構成: 各 NIC は、オーバークラウドネットワークの種別ごとのサブセットを使用する。
ネットワーク要件の詳しい情報は、「ネットワーク要件」を参照 し てください。
第5章 SR-IOV デプロイメントのプランニング
コンピュートノードのハードウェアに応じて個別のパラメーターを設定し、NFV 向けの Single Root I/O Virtualization (SR-IOV) デプロイメントを最適化します。
SR-IOV パラメーターに対するハードウェアの影響を評価するには、「NUMA ノードのトポロジーについての理解」を参照してください。
5.1. SR-IOV デプロイメント向けのハードウェアの分割
SR-IOV で高パフォーマンスを実現するには、ホストとゲストの間でリソースを分割します。
標準的なトポロジーでは、デュアルコアソケットのコンピュートノード上の NUMA ノードにはそれぞれ 14 のコアが実装されます。HT (ハイパースレッド) および非 HT のコアがサポートされています。各コアには 2 つのシブリングスレッドがあります。1 つのコアは、各 NUMA ノード上のホスト専用です。VNF は SR-IOV インターフェースのボンディングを処理します。すべての割り込み要求 (IRQ) はホストのコア上でルーティングされます。VNF コアは VNF 専用です。これらのコアは、他の VNF からの分離と、ホストからの分離を提供します。各 VNF は単一の NUMA ノード上のリソースを使用する必要があります。VNF によって使用される SR-IOV NIC はその同じ NUMA ノードに関連付ける必要もあります。このトポロジーでは、仮想化のオーバーヘッドはありません。ホスト、OpenStack Networking(neutron)、および Compute(nova)の設定パラメーターは単一のファイルで公開されるので、管理が簡単で、整合性を保つことができます。また、プリエンプションやパケットロスの原因となり、分離を適切に行うにあたって致命的となる一貫性の欠如を回避します。ホストと仮想マシンの分離は、tuned
プロファイルに依存します。このプロファイルは、分離する CPU の一覧に基づいて、ブートパラメーターや Red Hat OpenStack Platform の変更を管理します。
5.2. NFV SR-IOV デプロイメントのトポロジー
以下の図には、2 つの仮想ネットワーク機能 (VNF) が示されています。各 VNF には、mgt
で示された管理インターフェースおよびデータプレーンインターフェースがあります。管理インターフェースは ssh
アクセスおよびその他の管理機能を管理します。データプレーンインターフェースは VNF を Data Plane Development Kit(DPDK)にボンディングして高可用性を確保します。VNF は、DPDK ライブラリーを使用してデータプレーンインターフェースをボンディングします。この図には、2 つの冗長プロバイダーネットワークも示されています。コンピュートノードには 2 つの標準 NIC がボンディングされ、VNF 管理と Red Hat OpenStack Platform API 管理の間で共有されています。
この図は、アプリケーションレベルで DPDK を活用し、SR-IOV Virtual Function(VF)および Physical Function(PF)へのアクセスが可能な VNF を示しています。これにより、ファブリックの設定に応じて可用性やパフォーマンスが向上します。DPDK はパフォーマンスを向上させる一方、VF/PF DPDK のボンディングはフェイルオーバー/可用性に対応します。VNF ベンダーは、DPDK Poll Mode Driver(PMD)が VF/PF として公開される SR-IOV カードを必ずサポートするようにする必要があります。VNF は標準の virtIO ドライバーを使用して「mgmt」ネットワークデバイスにアクセスするため、管理ネットワークは Open vSwitch(OVS)を使用します。オペレーターは、VNF への初回の接続にそのデバイスを使用して、DPDK アプリケーションに 2 つの VF/PF を適切にボンディングさせることができます。
5.2.1. HCI を使用しない NFV SR-IOV のトポロジー
以下の図には、NFV ユースケース向けのハイパーコンバージドインフラストラクチャー(HCI)を使用しない Single Root I/O Virtualization(SR-IOV)のトポロジーを示しています。この環境は、1 Gbps の NIC を搭載したコンピュートノードおよびコントローラーノードと、director ノードで構成されます。
第6章 SR-IOV テクノロジーのデプロイ
OpenStack のインスタンスが仮想リソースを通じて共有 PCIe リソースに直接アクセスできるため、Single Root I/O Virtualization(SR-IOV)でベアメタルのパフォーマンスに近いパフォーマンスが得られます。
6.1. 前提条件
- オーバークラウドをデプロイする前に、アンダークラウドをインストールおよび設定していること。詳しくは、『 director のインストールと使用方法』を参照し てください。
director Heat テンプレートによって変更される /etc/tuned/cpu-partitioning-variables.conf
の値を手動で編集しないでください。
6.2. SR-IOV の設定
以下の例の CPU の割り当て、メモリーの割り当て、および NIC の設定は、お使いのトポロジーとユースケースとは異なる場合があります。
NeutronSriovAgent
、NeutronSriovHostConfig
、およびデフォルトの Compute サービスを実行する OpenStack クラスターのノードを定義するために、ビルトインのComputeSriov
を生成します。# openstack overcloud roles generate \ -o /home/stack/templates/roles_data.yaml \ Controller ComputeSriov
SR-IOV コンテナーを準備するには、
overcloud_images.yaml
ファイルを生成する際にneutron-sriov.yaml
およびroles_data.yaml
ファイルを含めます。SERVICES=\ /usr/share/openstack-tripleo-heat-templates/environments/services openstack tripleo container image prepare \ --namespace=registry.redhat.io/rhosp15-rhel8 \ --push-destination=192.168.24.1:8787 \ --prefix=openstack- \ --tag-from-label {version}-{release} \ -e ${SERVICES}/neutron-sriov.yaml \ --roles-file /home/stack/templates/roles_data.yaml \ --output-env-file=/home/stack/templates/overcloud_images.yaml \ --output-images-file=/home/stack/local_registry_images.yaml
注記push-destination の IP アドレスは、前のステップで
undercloud.conf
設定ファイルのlocal_ip
パラメーターで設定したアドレスです。コンテナーイメージの準備に関する詳細な情報は、『 director のインストールと使用方法』 を参照してください。
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 \ ...
実際のクラスターおよびハードウェア構成に合わせて、
parameter_defaults
セクションで SR-IOV ノードのパラメーターを適切に設定します。これらの設定は、通常network-environment.yaml
ファイルに含まれます。NeutronNetworkType: 'vlan' NeutronNetworkVLANRanges: - tenant:22:22 - tenant:25:25 NeutronTunnelTypes: ''
同じファイルで、SR-IOV コンピュートノードのロール固有のパラメーターを設定します。
注記numvfs
パラメーターは、ネットワーク設定テンプレートのNeutronSriovNumVFs
パラメーターに代わるものです。Red Hat では、デプロイ後のNeutronSriovNumVFs
パラメーターまたはnumvfs
パラメーターの変更をサポートしません。デプロイ後にいずれかのパラメーターを変更すると、その Physical Function (PF) 上に SR-IOV ポートを持つ実行中のインスタンスが使用できなくなる可能性があります。この場合、これらのインスタンスをハードリブートして、SR-IOV PCI デバイスを再び利用可能にする必要があります。ComputeSriovParameters: IsolCpusList: "1-19,21-39" KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=1-19,21-39" TunedProfileName: "cpu-partitioning" NeutronBridgeMappings: - tenant:br-link0 NeutronPhysicalDevMappings: - tenant:p7p1 - tenant:p7p2 NeutronSriovNumVFs: - p7p1:5 - p7p2:5 NovaPCIPassthrough: - devname: "p7p1" physical_network: "tenant" - devname: "p7p2" physical_network: "tenant" NovaVcpuPinSet: '1-19,21-39' NovaReservedHostMemory: 4096
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
デフォルトフィルターの一覧に、値
AggregateInstanceExtraSpecsFilter
が含まれる状態にします。NovaSchedulerDefaultFilters: ['AvailabilityZoneFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','AggregateInstanceExtraSpecsFilter']
- オーバークラウドをデプロイします。
TEMPLATES_HOME="/usr/share/openstack-tripleo-heat-templates" CUSTOM_TEMPLATES="/home/stack/templates" openstack overcloud deploy --templates \ -r ${CUSTOM_TEMPLATES}/roles_data.yaml \ -e ${TEMPLATES_HOME}/environments/host-config-and-reboot.yaml \ -e ${TEMPLATES_HOME}/environments/services/neutron-ovs.yaml \ -e ${TEMPLATES_HOME}/environments/services/neutron-sriov.yaml \ -e ${CUSTOM_TEMPLATES}/network-environment.yaml
6.3. NIC のパーティション設定(テクノロジープレビュー)
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビュー機能についての詳しい情報は、「対象範囲の詳細」を参照してください。
Red Hat OpenStack Platform ホストが Virtual Function (VF) を使用できるように、Single Root I/O Virtualization (SR-IOV) を設定することができます。
1 つの高速 NIC を複数の VF に分割する場合、NIC をコントロールプレーンおよびデータプレーントラフィックの両方に使用することができます。その後、必要に応じて QoS (Quality of Service) 優先度の値を VF インターフェースに適用することができます。
手順
オーバークラウドデプロイメント用のテンプレートを作成する際に、以下の手順を実施するようにしてください。
os-net-config
ロールファイルでインターフェース種別sriov_pf
を使用して、ホストが使用できる Physical Function(PF)を設定します。- type: sriov_pf name: <interface name> use_dhcp: false numvfs: <number of vfs> promisc: <true/false> #optional (Defaults to true)
注記numvfs
パラメーターは、ネットワーク設定テンプレートのNeutronSriovNumVFs
パラメーターに代わるものです。Red Hat では、デプロイ後のNeutronSriovNumVFs
パラメーターまたはnumvfs
パラメーターの変更をサポートしません。デプロイメント後にいずれかのパラメーターを変更すると、その PF に SR-IOV ポートを持つ実行中のインスタンスが中断する可能性があります。この場合、これらのインスタンスをハードリブートして、SR-IOV PCI デバイスを再び利用可能にする必要があります。
インターフェース種別
sriov_pf
を使用して、ホストが使用できるボンディングで VF を設定します。- type: linux_bond name: internal_bond bonding_options: mode=active-backup use_dhcp: false members: - type: sriov_vf device: nic7 vfid: 1 - type: sriov_vf device: nic8 vfid: 1 - type: vlan vlan_id: get_param: InternalApiNetworkVlanID device: internal_bond addresses: - ip_netmask: get_param: InternalApiIpSubnet
VLAN タグは、共通の PF デバイスに属するすべての VF を通じて一意でなければなりません。VLAN タグをインターフェース種別に割り当てる必要があります。
- linux_bond
- ovs_bridge
- ovs_dpdk_port
- 適用可能な VF ID の範囲はゼロで始まり、VF の合計数から 1 を引いた数値で終了します。
仮想マシンに VF を確保するには、
NovaPCIPassthrough
パラメーターを使用します。ホストではなく仮想マシンインスタンスが使用する VF を特定するには、正規表現の値をaddress
パラメーターに割り当てる必要があります。これらの値は
lspci
から取得できます。この情報を取得するには、事前にコンピュートノードを Linux 環境で起動する必要がある場合があります。lspci
コマンドは、各デバイスのアドレスを<bus>:<device>:<slot>
の形式で返します。これらのアドレスの値を、以下の形式でNovaPCIPassthrough
パラメーターに入力します。NovaPCIPassthrough: - physical_network: "sriovnet2" address: {"domain": ".*", "bus": "06", "slot": "11", "function": "[5-7]"} - physical_network: "sriovnet2" address: {"domain": ".*", "bus": "06", "slot": "10", "function": "[5]"}
NIC の分割が必要なすべてのノードで
IOMMU
を有効にします。たとえば、コンピュートノードに NIC 分割を設定する場合は、そのロールの KernelArgs パラメーターを使用して IOMMU を有効にします。parameter_defaults: ComputeParameters: KernelArgs: "intel_iommu=on iommu=pt"
検証
VF の数を確認します。
[root@overcloud-compute-0 heat-admin]# cat /sys/class/net/p4p1/device/sriov_numvfs 10 [root@overcloud-compute-0 heat-admin]# cat /sys/class/net/p4p2/device/sriov_numvfs 10
Linux ボンディングを確認します。
[root@overcloud-compute-0 heat-admin]# cat /proc/net/bonding/intapi_bond Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: p4p1_1 MII Status: up MII Polling Interval (ms): 0 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: p4p1_1 MII Status: up Speed: 10000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 16:b4:4c:aa:f0:a8 Slave queue ID: 0 Slave Interface: p4p2_1 MII Status: up Speed: 10000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: b6:be:82:ac:51:98 Slave queue ID: 0 [root@overcloud-compute-0 heat-admin]# cat /proc/net/bonding/st_bond Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011) Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: p4p1_3 MII Status: up MII Polling Interval (ms): 0 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: p4p1_3 MII Status: up Speed: 10000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: 9a:86:b7:cc:17:e4 Slave queue ID: 0 Slave Interface: p4p2_3 MII Status: up Speed: 10000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: d6:07:f8:78:dd:5b Slave queue ID: 0
OVS ボンディングを一覧表示します。
[root@overcloud-compute-0 heat-admin]# ovs-appctl bond/show ---- bond_prov ---- bond_mode: active-backup bond may use recirculation: no, Recirc-ID : -1 bond-hash-basis: 0 updelay: 0 ms downdelay: 0 ms lacp_status: off lacp_fallback_ab: false active slave mac: f2:ad:c7:00:f5:c7(dpdk2) slave dpdk2: enabled active slave may_enable: true slave dpdk3: enabled may_enable: true ---- bond_tnt ---- bond_mode: active-backup bond may use recirculation: no, Recirc-ID : -1 bond-hash-basis: 0 updelay: 0 ms downdelay: 0 ms lacp_status: off lacp_fallback_ab: false active slave mac: b2:7e:b8:75:72:e8(dpdk0) slave dpdk0: enabled active slave may_enable: true slave dpdk1: enabled may_enable: true
OVS の接続を表示します。
[root@overcloud-compute-0 heat-admin]# ovs-vsctl show cec12069-9d4c-4fa8-bfe4-decfdf258f49 Manager "ptcp:6640:127.0.0.1" is_connected: true Bridge br-tenant fail_mode: standalone Port br-tenant Interface br-tenant type: internal Port bond_tnt Interface "dpdk0" type: dpdk options: {dpdk-devargs="0000:82:02.2"} Interface "dpdk1" type: dpdk options: {dpdk-devargs="0000:82:04.2"} Bridge "sriov2" Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure Port "phy-sriov2" Interface "phy-sriov2" type: patch options: {peer="int-sriov2"} Port "sriov2" Interface "sriov2" type: internal Bridge br-int Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure Port "int-sriov2" Interface "int-sriov2" type: patch options: {peer="phy-sriov2"} Port br-int Interface br-int type: internal Port "vhu93164679-22" tag: 4 Interface "vhu93164679-22" type: dpdkvhostuserclient options: {vhost-server-path="/var/lib/vhost_sockets/vhu93164679-22"} Port "vhu5d6b9f5a-0d" tag: 3 Interface "vhu5d6b9f5a-0d" type: dpdkvhostuserclient options: {vhost-server-path="/var/lib/vhost_sockets/vhu5d6b9f5a-0d"} Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port "int-sriov1" Interface "int-sriov1" type: patch options: {peer="phy-sriov1"} Port int-br-vfs Interface int-br-vfs type: patch options: {peer=phy-br-vfs} Bridge br-vfs Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure Port phy-br-vfs Interface phy-br-vfs type: patch options: {peer=int-br-vfs} Port bond_prov Interface "dpdk3" type: dpdk options: {dpdk-devargs="0000:82:04.5"} Interface "dpdk2" type: dpdk options: {dpdk-devargs="0000:82:02.5"} Port br-vfs Interface br-vfs type: internal Bridge "sriov1" Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure Port "sriov1" Interface "sriov1" type: internal Port "phy-sriov1" Interface "phy-sriov1" type: patch options: {peer="int-sriov1"} Bridge br-tun Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure Port br-tun Interface br-tun type: internal Port patch-int Interface patch-int type: patch options: {peer=patch-tun} Port "vxlan-0a0a7315" Interface "vxlan-0a0a7315" type: vxlan options: {df_default="true", in_key=flow, local_ip="10.10.115.10", out_key=flow, remote_ip="10.10.115.21"} ovs_version: "2.10.0"
NovaPCIPassthrough
を使用して VF をインスタンスに渡した場合には、SR-IOV インスタンスをデプロイして テストを行います。
6.4. ハードウェアオフロードの設定 (テクノロジープレビュー)
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビュー機能についての詳しい情報は、「対象範囲の詳細」を参照してください。
Open vSwitch(OVS)ハードウェアオフロードには Single Root I/O Virtualization(SR-IOV)が組み込まれ、同様の設定手順が含まれます。
6.4.1. OVS ハードウェアオフロードの有効化
OVS ハードウェアオフロードを有効にするには、以下の手順を実施します。
ComputeSriov
ロールを作成します。openstack overcloud roles generate -o roles_data.yaml Controller ComputeSriov
ご自分の環境に合わせて、
physical_network
パラメーターを設定します。-
VLAN の場合には、
physical_network
パラメーターをデプロイメント後に neutron で作成するネットワークの名前に設定します。この値は、NeutronBridgeMappings
にも設定する必要があります。 -
VXLAN の場合には、
physical_network
パラメーターを文字列の値null
に設定します。 ロール固有のパラメーターセクションの
OvsHwOffload
パラメーターの値がtrue
となるようにします。以下に例を示します。
parameter_defaults: ComputeSriovParameters: IsolCpusList: 2-9,21-29,11-19,31-39 KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=128 intel_iommu=on iommu=pt" OvsHwOffload: true TunedProfileName: "cpu-partitioning" NeutronBridgeMappings: - tenant:br-tenant NeutronPhysicalDevMappings: - tenant:p7p1 - tenant:p7p2 NovaPCIPassthrough: - devname: "p7p1" physical_network: "null" - devname: "p7p2" physical_network: "null" NovaReservedHostMemory: 4096 NovaVcpuPinSet: 1-9,21-29,11-19,31-39
-
VLAN の場合には、
デフォルトフィルターの一覧に、値
NUMATopologyFilter
が含まれる状態にします。NovaSchedulerDefaultFilters: [\'RetryFilter',\'AvailabilityZoneFilter',\'ComputeFilter',\'ComputeCapabilitiesFilter',\'ImagePropertiesFilter',\'ServerGroupAntiAffinityFilter',\'ServerGroupAffinityFilter',\'PciPassthroughFilter',\'NUMATopologyFilter']
compute-sriov.yaml
設定ファイルで、ハードウェアオフロードに使用するネットワークインターフェースを 1 つまたは複数設定します。注記Open vSwitch ハードウェアオフロードを設定する場合には、
NeutronSriovNumVFs
パラメーターを使用しないでください。Virtual Function の数は、os-net-config
で使用されるネットワーク設定ファイルのnumvfs
パラメーターを使用して指定します。- type: ovs_bridge name: br-tenant mtu: 9000 members: - type: sriov_pf name: p7p1 numvfs: 5 mtu: 9000 primary: true promisc: true use_dhcp: false link_mode: switchdev
注記Mellanox ネットワークインターフェースの nic-config インターフェース種別を
ovs-vlan
に設定しないでください。ドライバーの制約により、VXLAN 等のトンネルエンドポイントがトラフィックを渡さなくなるためです。オーバークラウドのデプロイメント時に、以下のファイルを追加します。
- ovs-hw-offload.yaml
host-config-and-reboot.yaml
TEMPLATES_HOME=”/usr/share/openstack-tripleo-heat-templates” CUSTOM_TEMPLATES=”/home/stack/templates” openstack overcloud deploy --templates \ -r ${CUSTOME_TEMPLATES}/roles_data.yaml \ -e ${TEMPLATES_HOME}/environments/ovs-hw-offload.yaml \ -e ${TEMPLATES_HOME}/environments/host-config-and-reboot.yaml \ -e ${CUSTOME_TEMPLATES}/network-environment.yaml \ -e ${CUSTOME_TEMPLATES}/neutron-ovs.yaml
6.4.2. OVS ハードウェアオフロードの確認
pci デバイスのモードが switchdev に設定されていることを確認します。
# devlink dev eswitch show pci/0000:03:00.0 pci/0000:03:00.0: mode switchdev inline-mode none encap enable
OVS でオフロードが有効であることを確認します。
# ovs-vsctl get Open_vSwitch . other_config:hw-offload “true”
6.5. SR-IOV 用インスタンスのデプロイ
Red Hat は、ホストアグリゲートを使用して、高パフォーマンスのコンピュートホストを分離することを推奨します。ホストアグリゲートの作成およびスケジューリング用 の関連フレーバーに関する情報は、「ホストアグリゲート の作成」を参照してください。
CPU ピニングされたインスタンスをピニングされていないインスタンスと分けるには、ホストアグリゲートを使用すべきです。CPU ピニングを使用していないインスタンスは、CPU ピニングを使用するインスタンスのリソース要件に対応しません。
Single Root I/O Virtualization(SR-IOV)用インスタンスをデプロイするには、以下の手順を実施します。
フレーバーを作成します。
# openstack flavor create <flavor> --ram <MB> --disk <GB> --vcpus <#>
ネットワークを作成します。
# openstack network create net1 --provider-physical-network tenant --provider-network-type vlan --provider-segment <VLAN-ID> # openstack subnet create subnet1 --network net1 --subnet-range 192.0.2.0/24 --dhcp
ポートを作成します。
SR-IOV Virtual Function (VF) ポートを作成するには、vnic-type に
direct
を使用します。# openstack port create --network net1 --vnic-type direct sriov_port
ハードウェアオフロードを有効にして Virtual Function を作成するには、以下のコマンドを使用します。
# openstack port create --network net1 --vnic-type direct --binding-profile '{"capabilities": ["switchdev"]} sriov_hwoffload_port
SR-IOV PF ポートを作成するには、vnic-type に
direct-physical
を使用します。# openstack port create --network net1 --vnic-type direct-physical sriov_port
インスタンスをデプロイします。
# openstack server create --flavor <flavor> --image <image> --nic port-id=<id> <instance name>
6.6. ホストアグリゲートの作成
パフォーマンスを向上させるために、Red Hat は、CPU ピニングおよびヒュージページを使用してゲストをデプロイすることを推奨します。アグリゲートメタデータをフレーバーメタデータに一致させることで、ホストのサブセット上にハイパフォーマンスインスタンスをスケジュールすることができます。
AggregateInstanceExtraSpecsFilter
の値がnova.conf
設定ファイルのscheduler_default_filters
パラメーターに追加されていることを確認します。この設定は、デプロイの前にロール固有のパラメーターセクションの heat パラメーターNovaSchedulerDefaultFilters
で設定できます。ComputeOvsDpdkSriovParameters: NovaSchedulerDefaultFilters: ['AggregateInstanceExtraSpecsFilter', 'RetryFilter','AvailabilityZoneFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','ServerGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','NUMATopologyFilter']
注記このパラメーターを heat テンプレートに追加することができます。オリジナルのデプロイメント用スクリプトを再度実行して、この設定を既存クラスターの設定に追加します。
Single Root I/O Virtualization(SR-IOV)用のアグリゲートグループを作成し、適切なホストを追加します。定義するフレーバーメタデータに一致するメタデータを定義します (例:
sriov=true
)。# openstack aggregate create sriov_group # openstack aggregate add host sriov_group compute-sriov-0.localdomain # openstack aggregate set sriov_group sriov=true
フレーバーを作成します。
# openstack flavor create <flavor> --ram <MB> --disk <GB> --vcpus <#>
追加のフレーバー属性を設定します。定義したメタデータ (
sriov=true
) と SR-IOV アグリゲートで定義したメタデータが一致している点に注意してください。openstack flavor set --property sriov=true --property hw:cpu_policy=dedicated --property hw:mem_page_size=1GB <flavor>
第7章 OVS-DPDK デプロイメントのプランニング
NFV 向けの Data Plane Development Kit 対応 Open vSwitch(OVS-DPDK)デプロイメントを最適化するには、OVS-DPDK が CPU、NUMA ノード、メモリー、NIC などのコンピュートノードのハードウェアをどのように使用するか、およびコンピュートノードに応じた OVS-DPDK の各パラメーターを決定する際の考慮事項を理解する必要があります。
CPU と NUMA トポロジーの概要は、『NFV の製品ガイド』の「 NFV のパフォーマンスの考慮事項 」を参照してください。
7.1. CPU 分割と NUMA トポロジーを使用する OVS-DPDK
OVS-DPDK は、ホスト、ゲスト、および OVS-DPDK 用のハードウェアリソースを分割します。OVS-DPDK Poll Mode Driver (PMD) は、専用のコアを必要とする DPDK アクティブループを実行します。これは、CPU の一覧とヒュージページが OVS-DPDK 専用であることを意味します。
サンプルの分割では、デュアルソケットのコンピュートノード上の 1 NUMA ノードにつき 16 コアが含まれます。NIC はホストと OVS-DPDK 間で共有できないため、トラフィックには追加の NIC が必要です。
NUMA ノードに DPDK NIC が関連付けられていない場合でも、両方の NUMA ノードで DPDK PMD スレッドを確保する必要があります。
OVS-DPDK パフォーマンスには、NUMA ノードにローカルなメモリーブロックの予約も必要です。メモリーと CPU ピニングに使用する同じ NUMA ノードに関連付けられた NIC を使用してください。ボンディング内の両方のインターフェースが同じ NUMA ノード上の NIC から取得されるようにしてください。
7.2. ワークフローと派生パラメーターについての概要
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビュー機能についての詳しい情報は、「対象範囲の詳細」を参照してください。
OpenStack Workflow (mistral) サービスを使用すると、利用可能なベアメタルノードのケイパビリティーに基づいてパラメーターを派生することができます。Red Hat OpenStack Platform ワークフローでは、yaml ファイルで実行するタスクおよびアクションのセットを定義します。tripleo-common/workbooks/
ディレクトリーにある derive_params.yaml
という事前定義済みのワークブックを使用することができます。このワークブックは、ベアメタルのイントロスペクションで取得した結果から、サポートされる各パラメーターを派生するワークフローを提供します。derive_params.yaml
のワークフローは、tripleo-common/workbooks/derive_params_formulas.yaml
の計算式を使用して、派生パラメーターを計算します。
derive_params_formulas.yaml
の計算式は、お使いの環境に応じて変更することができます。
derive_params.yaml
ワークブックは、特定のコンポーザブルロール用の全ノードのハードウェア仕様が同じであることを前提としています。ワークフローは、フレーバーとプロファイルの関連付けと、nova の配置スケジューラーを考慮して、ロールに関連付けられたノードを照合し、そのロールと一致する最初のノードのイントロスペクションデータを使用します。
Red Hat OpenStack Platform ワークフローの詳細は、「ワークフロー および実行に関するトラブルシューティング」を 参照してください。
-p または --plan-environment-file オプションを使用して、カスタムの plan_environment.yaml
ファイルを openstack overcloud deploy コマンドに追加することができます。カスタムの plan_environment.yaml
ファイルは、ワークブックの一覧と、ワークブックに渡す値を指定します。トリガーされるワークフローは派生パラメーターをマージしてカスタムの plan_environment.yaml
に戻し、オーバークラウドのデプロイメントに利用できるようになります。これらの派生パラメーターの結果を使用して、オーバークラウドのイメージを準備することができます。
デプロイメントでの --plan-environment-file オプションの使用方法に関する詳しい情報は、『オーバークラウドの高度なカスタマイズ』の「 プランの環境メタデータ」を 参照してください。
7.3. OVS-DPDK の派生パラメーター
derive_params.yaml
のワークフローは、ComputeNeutronOvsDpdk サービスを使用する、対応するロールに関連付けられた DPDK パラメーターを派生します。
ワークフローによって自動的に派生できる OVS-DPDK のパラメーターの一覧は以下のとおりです。
- IsolCpusList
- KernelArgs
- NovaReservedHostMemory
- NovaVcpuPinSet
- OvsDpdkCoreList
- OvsDpdkSocketMemory
- OvsPmdCoreList
OvsDpdkMemoryChannels
パラメーターは、イントロスペクションのメモリーバンクデータからは派生できません。これは、メモリースロット名の形式がハードウェア環境によって異なるためです。
多くの場合、OvsDpdkMemoryChannels
のデフォルト値は 4 です。ハードウェアのマニュアルを参照して 1 ソケットあたりのメモリーチャネル数を確認し、この値を使用してデフォルト値を上書きします。
設定の詳細は、「ワークフローを使用した DPDK パラメーターの算出」 を参照してください。
7.4. 手動で計算した OVS-DPDK のパラメーターについての概要
本項では、Data Plane Development Kit 対応 Open vSwitch(OVS-DPDK)が director の network_environment.yaml
heat テンプレート内のパラメーターを使用して CPU とメモリーを設定し、パフォーマンスを最適化する方法について説明します。この情報を使用して、コンピュートノードでのハードウェアサポートを評価すると共に、そのハードウェアを分割して OVS-DPDK デプロイメントを最適化する最も有効な方法を評価します。
これらの値を自動的に生成する必要がある場合は、derived_parameters.yaml
ワークフローを使用できます。詳細は、「 ワークフローと派生パラメーターの概要」を参照してください。
CPU コアを割り当てる際には必ず、論理 CPU と呼ばれる CPU シブリングスレッドをペアにして、物理コアの CPU シブリングスレッドをペアにします。
コンピュートノード上の CPU と NUMA ノードを特定するには、「 NUMA ノードのトポロジーについての理解」を 参照してください。この情報を使用して、CPU と他のパラメーターをマッピングして、ホスト、ゲストインスタンス、OVS-DPDK プロセスのニーズに対応します。
7.4.1. CPU パラメーター
OVS-DPDK は以下の CPU パーティション設定パラメーターを使用します。
- OvsPmdCoreList
DPDK Poll Mode Driver (PMD) に使用する CPU コアを提供します。DPDK インターフェースのローカルの NUMA ノードに関連付けられた CPU コアを選択します。
OvsPmdCoreList
は、Open vSwitch のpmd-cpu-mask
の値に使用されます。OvsPmdCoreList
パラメーターを使用して、以下の設定を設定します。- シブリングスレッドをペアにします。
-
OvsDpdkCoreList
のコアをすべて除外します。 -
両方の NUMA ノード上の 1 番目の物理コアの論理 CPU または両方のスレッドシブリングが割り当てられないようにしてください。これらは
OvsDpdkCoreList
パラメーターに使用する必要があります。 - パフォーマンスは、この PMD コアリストに割り当てられる物理コア数によって異なります。DPDK NIC に関連付けられた NUMA ノードで、必要なコアを割り当てます。
DPDK 用の NIC が 1 つある NUMA ノードの場合:
- パフォーマンス要件に基づいて必要な物理コア数を決定し、各物理コアのシブリングスレッドまたは論理 CPU を組み込みます。
DPDK 用の NIC がない NUMA ノードの場合:
- NUMA ノードの最初の物理コアを除く、1 つの物理コアのシブリングスレッド(論理 CPU)を割り当てます。
NUMA ノードに DPDK NIC が関連付けられていない場合でも、両方の NUMA ノードで DPDK PMD スレッドを確保する必要があります。
- NovaVcpuPinSet
CPU ピニング用のコアを設定します。コンピュートノードは、ゲストインスタンスにこれらのコアを使用します。
NovaVcpuPinSet
はnova.conf
ファイルのvcpu_pin_set
値として使用されます。NovaVcpuPinSet
パラメーターを使用して、以下の設定を設定します。-
OvsPmdCoreList
とOvsDpdkCoreList
のコアをすべて除外します。 - 残りのコアをすべて追加します。
- シブリングスレッドをペアにします。
-
- NovaComputeCpuSharedSet
-
エミュレータースレッドに使用するコアを設定します。これにより、nova.conf のパラメータ
cpu_shared_set
の値が定義されます。このパラメータの値とOvsDpdkCoreList
に設定した値を一致させることを推奨します。 - IsolCpusList
ホストのプロセスから分離される CPU コアのセット。このパラメーターは、
tuned-profiles-cpu-partitioning
コンポーネント用のcpu-partitioning-variable.conf
ファイルのisolated_cores
値として使用されます。IsolCpusList
パラメーターを使用して、以下の設定を設定します。-
OvsPmdCoreList
とNovaVcpuPinSet
のコア一覧が一致するようにします。 - シブリングスレッドをペアにします。
-
- OvsDpdkCoreList
handler および revalidator スレッドなどの、データパス以外の OVS-DPDK プロセス用の CPU コアを提供します。このパラメーターは、マルチ NUMA ノードハードウェア上でのデータパスの全体的なパフォーマンスには影響を与えません。このパラメーターは OVS の
dpdk-lcore-mask
値に使用され、それらのコアはホストと共有されます。OvsDpdkCoreList
パラメーターを使用して、以下の設定を設定します。- NUMA ノードに DPDK NIC が関連付けられていない場合でも、各 NUMA ノードから 1 番目の物理コアおよびシブリングスレッドを割り当てます。
-
これらのコアは、
OvsPmdCoreList
およびNovaVcpuPinSet
のコアの一覧と相互に排他的である必要があります。
7.4.2. メモリーパラメーター
OVS-DPDK は、以下のメモリーパラメーターを使用します。
- OvsDpdkMemoryChannels
NUMA ノードごとに、CPU 内のメモリーチャネルをマッピングします。
OvsDpdkMemoryChannels
パラメーターは Open vSwitch(OVS)によりother_config:dpdk-extra="-n <value>" 値として使用され
ます。OvsDpdkMemoryChannels
に必要な値を算出するには、以下の手順に従います。-
dmidecode -t memory
のコマンドを使用するか、お使いのハードウェアのマニュアルを参照して、利用可能なメモリーチャネルの数を確認します。 -
ls /sys/devices/system/node/node* -d
のコマンドで NUMA ノードの数を確認します。 - 利用可能なメモリーチャネル数を NUMA ノード数で除算します。
-
- NovaReservedHostMemory
-
ホスト上のタスク用にメモリーを MB 単位で確保します。この値は、コンピュートノードにより
nova.conf
のreserved_host_memory_mb
値として使用されます。静的な推奨値は 4096 MB です。 - OvsDpdkSocketMemory
NUMA ノードごとにヒュージページプールから事前に割り当てるメモリーの容量を MB 単位で指定します。この値は、OVS が
other_config:dpdk-socket-mem
値として使用されます。OvsDpdkSocketMemory
に必要な値を算出するには、以下の手順に従います。-
コンマ区切りリストで指定します。NUMA ノード上の各 NIC の MTU 値から、
OvsDpdkSocketMemory
の値を計算します。 - DPDK NIC のない NUMA ノードの場合は、推奨される静的な値である 1024 MB(1GB)を使用します。
OvsDpdkSocketMemory
の値は、以下の式で概算します。MEMORY_REQD_PER_MTU = (ROUNDUP_PER_MTU + 800) x (4096 x 64) バイト
- 800 はオーバーヘッドの値です。
- 4096 x 64 は mempool 内のパケット数です。
- NUMA ノードで設定される各 MTU 値の MEMORY_REQD_PER_MTU を追加し、バッファーとして 512 MB をさらに加算します。その値を 1024 の倍数に丸めます。
-
コンマ区切りリストで指定します。NUMA ノード上の各 NIC の MTU 値から、
計算例: MTU 2000 および MTU 9000
DPDK NIC dpdk0 と dpdk1 は同じ NUMA ノード 0 上にあり、それぞれ MTU 9000 と MTU 2000 で設定されています。必要なメモリーを算出する計算例を以下に示します。
MTU 値を 1024 バイトの倍数に丸めます。
The MTU value of 9000 becomes 9216 bytes. The MTU value of 2000 becomes 2048 bytes.
それらの丸めたバイト値に基づいて、各 MTU 値に必要なメモリーを計算します。
Memory required for 9000 MTU = (9216 + 800) * (4096*64) = 2625634304 Memory required for 2000 MTU = (2048 + 800) * (4096*64) = 746586112
それらを合わせた必要なメモリーの合計を計算します (バイト単位)。
2625634304 + 746586112 + 536870912 = 3909091328 bytes.
この計算は、(MTU 値 9000 に必要なメモリー) + (MTU 値 2000 に必要なメモリー) + (512 MB バッファー) を示しています。
必要合計メモリーを MB に変換します。
3909091328 / (1024*1024) = 3728 MB.
この値を 1024 の倍数に丸めます。
3724 MB rounds up to 4096 MB.
この値を使用して
OvsDpdkSocketMemory
を設定します。OvsDpdkSocketMemory: “4096,1024”
計算例: MTU 2000
DPDK NIC dpdk0 と dpdk1 は同じ NUMA ノード 0 上にあり、それぞれ MTU 2000 と MTU 2000 で設定されています。必要なメモリーを算出する計算例を以下に示します。
MTU 値を 1024 バイトの倍数に丸めます。
The MTU value of 2000 becomes 2048 bytes.
それらの丸めたバイト値に基づいて、各 MTU 値に必要なメモリーを計算します。
Memory required for 2000 MTU = (2048 + 800) * (4096*64) = 746586112
それらを合わせた必要なメモリーの合計を計算します (バイト単位)。
746586112 + 536870912 = 1283457024 bytes.
この計算は、(MTU 値 2000 に必要なメモリー) + (512 MB バッファー) を示しています。
必要合計メモリーを MB に変換します。
1283457024 / (1024*1024) = 1224 MB.
この値を 1024 の倍数に丸めます。
1224 MB rounds up to 2048 MB.
この値を使用して
OvsDpdkSocketMemory
を設定します。OvsDpdkSocketMemory: “2048,1024”
7.4.3. ネットワークパラメーター
- NeutronDpdkDriverType
-
DPDK によって使用されるドライバーの種別を設定します。
vfio-pci
のデフォルト値を使用してください。 - NeutronDatapathType
-
OVS ブリッジ用のデータパスの種別を設定します。DPDK は
netdev
のデフォルト値を使用してください。 - NeutronVhostuserSocketDir
-
OVS 向けに vhost-user ソケットディレクトリーを設定します。vhost クライアントモード用の
/var/lib/vhost_sockets
を使用してください。
7.4.4. その他のパラメーター
- NovaSchedulerDefaultFilters
- 要求されたゲストインスタンスに対してコンピュートノードが使用するフィルターの順序付きリストを指定します。
- VhostuserSocketGroup
-
vhost-user ソケットディレクトリーのグループを設定します。デフォルト値は
qemu
です。VhostuserSocketGroup
はhugetlbfs
に設定する必要があります。これにより、ovs-vswitchd および qemu プロセスが、virtio-net デバイスを設定するのに使用する共有ヒュージページおよび unix ソケットにアクセスすることができます。この値はロールに固有で、OVS-DPDK を利用するすべてのロールに適用する必要があります。 - KernelArgs
コンピュートノードのブート時用に、複数のカーネル引数を
/etc/default/grub
に指定します。設定に応じて、以下のパラメーターを追加します。hugepagesz
: CPU 上のヒュージページのサイズを設定します。この値は、CPU のハードウェアによって異なります。OVS-DPDK デプロイメントには 1G に指定します (default_hugepagesz=1GB hugepagesz=1G
)。以下のコマンドを使用して、pdpe1gb
CPU フラグが出力されるかどうかをチェックして、CPU が 1G をサポートしていることを確認します。lshw -class processor | grep pdpe1gb
-
hugepages count
: 利用可能なヒュージページの数を設定します。この値は、ホストの使用可能なメモリーの量によって異なります。利用可能なメモリーの大半を使用してください(NovaReservedHostMemory
を除く)。ヒュージページ数の値は、お使いのコンピュートノードに関連付けられた Red Hat OpenStack Platform フレーバーの範囲内で設定する必要もあります。 -
iommu
: Intel CPU の場合は、"intel_iommu=on iommu=pt"
を追加します。 -
isolcpus
: チューニングされる CPU コアを設定します。この値はIsolCpusList
と一致します。
7.4.5. インスタンスの追加仕様
NFV 環境でインスタンスをデプロイする前に、CPU ピニング、ヒュージページ、およびエミュレータースレッドピニングを活用するフレーバーを作成します。
- hw:cpu_policy
-
ゲストがピニングされた CPU を使用するように、このパラメーターの値を
dedicated
に設定します。このパラメーターセットのフレーバーから作成したインスタンスの有効オーバーコミット比は、1 : 1 です。デフォルトはshared
です。 - hw:mem_page_size
このパラメーターの値を、特定の値と標準の単位からなる有効な文字列に設定します(例:
4KB
、8MB
、または1GB
)。hugepagesz ブートパラメーターに一致させるには、1GB を使用します。仮想マシンで使用可能なヒュージページの数は、ブートパラメーターからOvsDpdkSocketMemory
を引いた値です。以下の値有効です。- small (デフォルト): 最少のページサイズが使用されます。
- large: 大型のページサイズだけを使用します。x86 アーキテクチャーでは、ページサイズは 2 MB または 1 GB です。
- any: コンピュートドライバーは大型ページの使用を試みますが、利用できるページがない場合にはデフォルトの小型ページが使用されます。
- hw:emulator_threads_policy
-
heat パラメーター
NovaComputeCpuSharedSet
で識別した CPU にエミュレータースレッドが固定されるように、このパラメーターの値をshare
に設定します。エミュレータースレッドが Poll Mode Driver (PMD) またはリアルタイム処理に使用されている vCPU 上で実行されている場合には、パケットロスまたはデッドラインの超過が生じる場合があります。
7.5. 2 NUMA ノード構成の OVS-DPDK デプロイメントの例
この例のコンピュートノードには、以下の 2 つの NUMA ノードが含まれます。
- NUMA 0 にはコア 0 - 7 があり、シブリングスレッドペアは (0,1)、(2,3)、(4,5)、および (6,7) の構成。
- NUMA 1 にはコア 8 - 15 があり、シブリングスレッドペアは (8,9)、(10,11)、(12,13)、および (14,15) の構成。
- 各 NUMA ノードが物理 NIC (NUMA 0 上の NIC1 と NUMA 1 上の NIC2) に接続されている。
各 NUMA ノード上の 1 番目の物理コア(あるいは両スレッドペア)(0,1 および 8,9)は、データパス以外の DPDK プロセス(OvsDpdkCoreList
)用に確保します。
この例では、MTU が 1500 に設定されており、全ユースケースで OvsDpdkSocketMemory
が同じであることも前提です。
OvsDpdkSocketMemory: “1024,1024”
NIC 1 は DPDK 用で、1 つの物理コアは PMD 用
このユースケースでは、NUMA 0 の物理コアの 1 つを PMD 用に割り当てます。NUMA 1 の NIC では DPDK は有効化されていませんが、その NUMA ノードの物理コアの 1 つも割り当てる必要があります。OvsDpdkCoreList
用に確保されていない残りのコアは、ゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。
OvsPmdCoreList: “2,3,10,11” NovaVcpuPinSet: “4,5,6,7,12,13,14,15”
NIC 1 は DPDK 用で、2 つの物理コアは PMD 用
このユースケースでは、NUMA 0 の物理コアの 2 つを PMD 用に割り当てます。NUMA 1 の NIC では DPDK は有効化されていませんが、その NUMA ノードの物理コアの 1 つも割り当てる必要があります。OvsDpdkCoreList
用に確保されていない残りのコアは、ゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。
OvsPmdCoreList: “2,3,4,5,10,11” NovaVcpuPinSet: “6,7,12,13,14,15”
NIC 2 は DPDK 用で、1 つの物理コアは PMD 用
このユースケースでは、NUMA 1 の物理コアの 1 つを PMD 用に割り当てます。NUMA 0 の NIC では DPDK は有効化されていませんが、その NUMA ノードの物理コアの 1 つも割り当てる必要があります。残りのコア (OvsDpdkCoreList
用に確保されていないコア) はゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。
OvsPmdCoreList: “2,3,10,11” NovaVcpuPinSet: “4,5,6,7,12,13,14,15”
NIC 2 は DPDK 用で、2 つの物理コアは PMD 用
このユースケースでは、NUMA 1 の物理コアの 2 つを PMD 用に割り当てます。NUMA 0 の NIC では DPDK は有効化されていませんが、その NUMA ノードの物理コアの 1 つも割り当てる必要があります。残りのコア (OvsDpdkCoreList
用に確保されていないコア) はゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。
OvsPmdCoreList: “2,3,10,11,12,13” NovaVcpuPinSet: “4,5,6,7,14,15”
NIC 1 と NIC2 は DPDK 用で、2 つの物理コアは PMD 用
このユースケースでは、各 NUMA ノードの物理コアの 2 つを PMD 用に割り当てます。残りのコア (OvsDpdkCoreList
用に確保されていないコア) はゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。
OvsPmdCoreList: “2,3,4,5,10,11,12,13” NovaVcpuPinSet: “6,7,14,15”
7.6. NFV OVS-DPDK デプロイメントのトポロジー
以下のデプロイメント例は、2 つの仮想ネットワーク機能(VNF)からなる Data Plane Development Kit 対応 Open vSwitch(OVS-DPDK)の構成を示しています。各 VNF には、2 つのインターフェース( mgt
で示された管理インターフェースおよびデータプレーンインターフェース)があります。OVS-DPDK デプロイメントでは、VNF は、物理インターフェースをサポートする組み込みの DPDK で稼働します。OVS-DPDK は、vSwitch レベルでボンディングを管理します。OVS-DPDK デプロイメントでは、カーネルと OVS-DPDK の NIC を混在させないでください。これにより、パフォーマンスが低下する可能性があるためです。仮想マシン向けのベースプロバイダーネットワークに接続された管理(mgt
)ネットワークを分離するには、追加の NIC があることを確認します。コンピュートノードは、Red Hat OpenStack Platform(RHOSP)API 管理向けの標準 NIC 2 つで構成されます。これは、Ceph API で再利用できますが、RHOSP テナントとは一切共有できません。
NFV OVS-DPDK のトポロジー
以下の図には、NFV ユースケース向けの OVS_DPDK のトポロジーを示しています。この環境は、1 または 10 Gbps の NIC を搭載したコンピュートノードおよびコントローラーノードと、director ノードで構成されます。
第8章 OVS-DPDK デプロイメントの設定
本項では、Red Hat OpenStack Platform(RHOSP)環境内で Open vSwitch(OVS-DPDK)対応の DPDK をデプロイする方法について説明します。オーバークラウドは、通常コントローラーノードやコンピュートノードなどの事前定義済みロールのノードと、異なる種別のストレージノードで構成されます。これらのデフォルトロールにはそれぞれ、director ノード上のコア heat テンプレートで定義されている一式のサービスが含まれます。
オーバークラウドをデプロイする前に、アンダークラウドのインストールと設定が完了している必要があります。詳しくは、『 director のインストールと使用方法』を参照し てください。
OVS-DPDK 向けの RHOSP ネットワークを最適化するには、network-environment.yaml
ファイルに設定する OVS-DPDK パラメーターの最も適切な値を決定する必要があります。
これらの director Heat テンプレートによって変更される etc/tuned/cpu-partitioning-variables.conf
の isolated_cores
またはその他の値は編集/変更しないでください。
8.1. ワークフローを使用した DPDK パラメーターの算出
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビュー機能についての詳しい情報は、「対象範囲の詳細」を参照してください。
DPDK 向けの Mistral ワークフローに関する概要は、「ワークフローと派生パラメーターについての概要」 を参照してください。
前提条件
このワークフローで取得されるデータを生成するには、ハードウェア inspection_extras
を含むベアメタルのイントロスペクションを有効化しておく必要があります。ハードウェア検査の追加パラメーターはデフォルトで有効化されます。「 ノードのハードウェアの検査 」を参照してください。
DPDK 向けのワークフローと入力パラメーターの定義
OVS-DPDK ワークフローで指定することができる入力パラメーターの一覧を以下に示します。
- num_phy_cores_per_numa_node_for_pmd
- この入力パラメーターは、DPDK NIC に関連付けられた NUMA ノードの必要最小限のコア数を指定します。DPDK NIC に関連付けられていないその他の NUMA ノードには、物理コアが 1 つ割り当てられます。このパラメーターは 1 に設定するようにしてください。
- huge_page_allocation_percentage
-
この入力パラメーターは、ヒュージページとして設定可能な合計メモリー中 (
NovaReservedHostMemory
を除く) の必要なパーセンテージを指定します。KernelArgs
パラメーターは、指定したhuge_page_allocation_percentage
に基づいて計算されたヒュージページを使用して派生されます。このパラメーターは 50 に設定するようにしてください。
ワークフローは、これらの入力パラメーターとベアメタルのイントロスペクション情報を使用して、適切な DPDK パラメーターの値を算出します。
DPDK のワークフローおよび入力パラメーターを定義するには、以下の手順を実施します。
usr/share/openstack-tripleo-heat-templates/plan-samples/plan-environment-derived-params.yaml
ファイルをローカルディレクトリーにコピーし、ご自分の環境に合わせて入力パラメーターを設定します。workflow_parameters: tripleo.derive_params.v1.derive_parameters: # DPDK Parameters # # Specifies the minimum number of CPU physical cores to be allocated for DPDK # PMD threads. The actual allocation will be based on network config, if # the a DPDK port is associated with a numa node, then this configuration # will be used, else 1. num_phy_cores_per_numa_node_for_pmd: 1 # Amount of memory to be configured as huge pages in percentage. Ouf the # total available memory (excluding the NovaReservedHostMemory), the # specified percentage of the remaining is configured as huge pages. huge_page_allocation_percentage: 50
以下のオプションを指定して
openstack overcloud deploy
コマンドを実行します。-
update-plan-only
オプション - ロールファイルおよびご自分の環境に固有の全環境ファイル
plan-environment-derived-parms.yaml
ファイル (--plan-environment-file
オプションの引数)$ openstack overcloud deploy --templates --update-plan-only \ -r /home/stack/roles_data.yaml \ -e /home/stack/<environment-file> \ ... #repeat as necessary ... -p /home/stack/plan-environment-derived-params.yaml
-
このコマンドの出力には、派生した結果が表示されます。これは、plan-environment.yaml
ファイルにもマージされます。
Started Mistral Workflow tripleo.validations.v1.check_pre_deployment_validations. Execution ID: 55ba73f2-2ef4-4da1-94e9-eae2fdc35535 Waiting for messages on queue 472a4180-e91b-4f9e-bd4c-1fbdfbcf414f with no timeout. Removing the current plan files Uploading new plan files Started Mistral Workflow tripleo.plan_management.v1.update_deployment_plan. Execution ID: 7fa995f3-7e0f-4c9e-9234-dd5292e8c722 Plan updated. Processing templates in the directory /tmp/tripleoclient-SY6RcY/tripleo-heat-templates Invoking workflow (tripleo.derive_params.v1.derive_parameters) specified in plan-environment file Started Mistral Workflow tripleo.derive_params.v1.derive_parameters. Execution ID: 2d4572bf-4c5b-41f8-8981-c84a363dd95b Workflow execution is completed. result: ComputeOvsDpdkParameters: IsolCpusList: 1,2,3,4,5,6,7,9,10,17,18,19,20,21,22,23,11,12,13,14,15,25,26,27,28,29,30,31 KernelArgs: default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=1,2,3,4,5,6,7,9,10,17,18,19,20,21,22,23,11,12,13,14,15,25,26,27,28,29,30,31 NovaReservedHostMemory: 4096 NovaVcpuPinSet: 2,3,4,5,6,7,18,19,20,21,22,23,10,11,12,13,14,15,26,27,28,29,30,31 OvsDpdkCoreList: 0,16,8,24 OvsDpdkMemoryChannels: 4 OvsDpdkSocketMemory: 1024,1024 OvsPmdCoreList: 1,17,9,25
OvsDpdkMemoryChannels
パラメーターをイントロスペクションの情報から派生することはできません。大半の場合、この値は 4 に設定すべきです。
派生パラメーターを使用したオーバークラウドのデプロイ
これらの派生パラメーターを使用してオーバークラウドをデプロイするには、以下の手順を実施します。
派生パラメーターをデプロイコマンドの出力から
network-environment.yaml
ファイルにコピーします。# DPDK compute node. ComputeOvsDpdkParameters: KernelArgs: default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on TunedProfileName: "cpu-partitioning" IsolCpusList: "1,2,3,4,5,6,7,9,10,17,18,19,20,21,22,23,11,12,13,14,15,25,26,27,28,29,30,31" NovaVcpuPinSet: ['2,3,4,5,6,7,18,19,20,21,22,23,10,11,12,13,14,15,26,27,28,29,30,31'] NovaReservedHostMemory: 4096 OvsDpdkSocketMemory: "1024,1024" OvsDpdkMemoryChannels: "4" OvsDpdkCoreList: "0,16,8,24" OvsPmdCoreList: "1,17,9,25"
注記これらのパラメーターは、特定のロール ComputeOvsDpdk に適用されます。これらのパラメーターはグローバルに適用することはできますが、ロール固有のパラメーターはグローバルパラメーターを上書きします。
- ロールファイルおよびご自分の環境に固有の全環境ファイルを使用して、オーバークラウドをデプロイします。詳しい情報は、『 Deploying the Overcloud 』を参照してください。
Compute、ComputeOvsDpdk、および ComputeSriov が設定されたクラスターでは、既存のワークフローで、パラメーターを派生する既存のワークフローにより、ComputeOvsDpdk ロールだけに式が適用されます。
8.2. OVS-DPDK のトポロジー
Red Hat OpenStack Platform では、コンポーザブルロール機能を使用し、各ロールにサービスを追加/削除してカスタムのデプロイメントロールを作成できます。コンポーザブルロールの詳細は、『オーバークラウドの高度なカスタマイズ』の「 コンポーザブルサービスと カスタムロール」を参照してください。
以下の図は、コントロールプレーンとデータプレーン用にポートが 2 つボンディングされている Data Plane Development Kit 対応 Open vSwitch(OVS-DPDK)トポロジーの例を示しています。
OVS-DPDK を設定するには、以下のタスクを実行します。
-
コンポーザブルロールを使用する場合には、
roles_data.yaml
ファイルをコピーして編集し、OVS-DPDK 用のカスタムロールを追加します。 -
適切な
network-environment.yaml
ファイルを更新して、カーネル引数と DPDK 引数のパラメーターを追加します。 -
compute.yaml
ファイルを更新して、DPDK インターフェース用のブリッジを追加します。 -
controller.yaml
ファイルを更新して、DPDK インターフェースパラメーター用の同じブリッジ情報を追加します。 -
overcloud_deploy.sh
スクリプトを実行して、DPDK パラメーターを使用してオーバークラウドをデプロイします。
本ガイドでは、CPU の割り当て、メモリーの確保、NIC の設定の例を紹介します。これらは、トポロジーとユースケースによって異なる場合があります。ハードウェアと設定オプションの詳細は、『 ネットワーク機能仮想化(NFV)の製品ガイド』 および「 2章ハードウェア要件 」を参照してください。
前提条件
- OVS 2.10
- DPDK 17
- テスト済み NIC。NFV 向けのテスト済み NIC の一覧は、「テスト済み NIC」を参照してください。
Red Hat OpenStack Platform は、OVS-DPDK デプロイメントでは OVS クライアントモードで動作します。
8.3. OVS-DPDK インターフェースの MTU 値の設定
Red Hat OpenStack Platform は Data Plane Development Kit 対応 Open vSwitch (OVS-DPDK) 向けにジャンボフレームをサポートしています。ジャンボフレーム用の最大伝送単位 (MTU) 値を設定するには、以下の操作を行う必要があります。
-
network-environment.yaml
ファイルで、ネットワークのグローバル MTU 値を設定する。 -
compute.yaml
ファイルで、物理 DPDK ポートの MTU 値を設定する。この値は、vhost のユーザーインターフェースでも使用されます。 - コンピュートノード上の任意のゲストインスタンスで MTU 値を設定し、設定内でエンドツーエンドに同等の MTU 値が設定されるようにする。
VXLAN パケットには追加で 50 バイトがヘッダーに含まれます。MTU の必要値は、ヘッダーの追加バイト値に基づいて計算してください。たとえば、MTU 値 が 9000 の場合には、これらの追加バイト値を計算に入れると、VXLAN トンネルの MTU 値は 8950 となります。
物理 NIC は DPDK PMD によって制御され、compute.yaml
ファイルで設定されているのを同じ MTU 値が適用されるので、特別な設定は必要ありません。MTU 値には、物理 NIC でサポートされているよりも高い値を設定することはできません。
OVS-DPDK インターフェースの MTU 値を設定するには、以下の手順を実行します。
network-environment.yaml
ファイルでNeutronGlobalPhysnetMtu
パラメーターを設定します。parameter_defaults: # MTU global configuration NeutronGlobalPhysnetMtu: 9000
注記network-environment.yaml
ファイルの NeutronDpdkSocketMemory の値がジャンボフレームをサポートするのに十分に大きな値であることを確認します。詳しくは、「メモリーパラメーター」を参照してください。controller.yaml
ファイルでコンピュートノードへのブリッジ上の MTU 値を設定します。- type: ovs_bridge name: br-link0 use_dhcp: false members: - type: interface name: nic3 mtu: 9000
compute.yaml
ファイルで OVS-DPDK ボンディング用の MTU 値を設定します。- type: ovs_user_bridge name: br-link0 use_dhcp: false members: - type: ovs_dpdk_bond name: dpdkbond0 mtu: 9000 rx_queue: 2 members: - type: ovs_dpdk_port name: dpdk0 mtu: 9000 members: - type: interface name: nic4 - type: ovs_dpdk_port name: dpdk1 mtu: 9000 members: - type: interface name: nic5
8.4. セキュリティーグループのファイアウォールの設定
データプレーンインターフェースのステートフルファイアウォールには、高いパフォーマンスが要求されます。これらのインターフェースを保護するためには、仮想ネットワーク機能 (VNF) として通信業界グレードのファイアウォールをデプロイすることを検討してください。
コントロールプレーンのインターフェースを設定するには、NeutronOVSFirewallDriver
パラメーターを openvswitch
に設定します。これにより、Red Hat OpenStack Platform Networking がフローベースの OVS ファイアウォールドライバーを使用するように設定します。この設定は、network-environment.yaml
ファイルの parameter_defaults
セクションで行います。
以下に例を示します。
parameter_defaults: NeutronOVSFirewallDriver: openvswitch
該当する場合は、データプレーンインターフェースの OVS ファイアウォールドライバーを無効にすることが重要です。そのためには、openstack port set
コマンドを使用します。
以下に例を示します。
openstack port set --no-security-group --disable-port-security ${PORT}
8.5. OVS-DPDK インターフェース向けのマルチキューの設定
コンピュートノード上の Data Plane Development Kit 対応 Open vSwitch(OVS-DPDK)のインターフェースに同じ数のキューを設定するには、compute.yaml
ファイルを変更します。
- type: ovs_user_bridge
name: br-link0
use_dhcp: false
members:
- type: ovs_dpdk_bond
name: dpdkbond0
mtu: 9000
rx_queue: 2
members:
- type: ovs_dpdk_port
name: dpdk0
mtu: 9000
members:
- type: interface
name: nic4
- type: ovs_dpdk_port
name: dpdk1
mtu: 9000
members:
- type: interface
name: nic5
8.6. オーバークラウドのデプロイ
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"
openstack overcloud deploy
コマンドを使用して、オーバークラウドをデプロイします。- ロールファイルおよびご自分の環境に固有の全環境ファイルを追加します。
/usr/share/openstack-tripleo-heat-templates/environments
からのhost-config-and-reboot.yaml
ファイルをデプロイメントスクリプトに追加して、KernelAgs
およびTunedProfile
パラメーターを適用します。TEMPLATES_HOME=”/usr/share/openstack-tripleo-heat-templates” CUSTOM_TEMPLATES=”/home/stack/templates” openstack overcloud deploy --templates \ -r ${CUSTOM_TEMPLATES}/roles_data.yaml \ -e ${TEMPLATES_HOME}/environments/host-config-and-reboot.yaml \ -e ${CUSTOM_TEMPLATES}/network-environment.yaml \ -e ${CUSTOM_TEMPLATES}/controller.yaml -e ${CUSTOM_TEMPLATES}/computeovsdpdk.yaml \ ...
8.7. 既知の制限
NFV のユースケース向けに Red Hat OpenStack Platform で OVS-DPDK を設定する場合には制限事項があります。
- コントロールプレーンのネットワークには、Linux ボンディングを使用します。パフォーマンスを最適化するには、Linux ボンディングの PCI デバイスが同じ NUMA ノード上にあることを確認してください。Red Hat では、Neutron Linux ブリッジ設定をサポートしません。
- OVS-DPDK を使用するホスト上で実行される各インスタンスにはヒュージページが必要です。ゲストのヒュージページがない場合には、インターフェースは表示されても機能しません。
- OVS-DPDK を使用する場合には、分散仮想ルーター (DVR) 等の TAP デバイスを使用するサービスのパフォーマンスが低下します。得られるパフォーマンスは、実稼働環境に適するものではありません。
-
OVS-DPDK を使用する場合には、同じコンピュートノード上の全ブリッジが
ovs_user_bridge
の種別でなければなりません。director は設定を受け入れることができますが、Red Hat は同じノード上でovs_bridge
とovs_user_bridge
が混在する構成はサポートしていません。
8.8. OVS-DPDK 用のフレーバーの作成とインスタンスのデプロイ
NFV を実装する Red Hat OpenStack Platform デプロイメント向けに Data Plane Development Kit 対応 Open vSwitch(OVS-DPDK)を設定したら、以下の手順に従ってフレーバーを作成してインスタンスをデプロイすることができます。
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 ピニングが設定されたインスタンスの再ソース要件が異なります。
フレーバーを作成します。
# openstack flavor create <flavor> --ram <MB> --disk <GB> --vcpus <#>
追加のフレーバー属性を設定します。定義したメタデータ (
dpdk=true
) と DPDK アグリゲートで定義したメタデータが一致している点に注意してください。# openstack flavor set <flavor> --property dpdk=true --property hw:cpu_policy=dedicated --property hw:mem_page_size=1GB --property hw:emulator_threads_policy=isolate
この例では、
m1.medium_huge_4cpu
はフレーバー名で、残りはそのフレーバーの他の属性を設定しています。パフォーマンス向上のためのエミュレータースレッドポリシーについての詳しい情報は、「 専用の物理 CPU で実行されるエミュレータースレッドの設定」を参照 してください。
ネットワークを作成します。
# openstack network create net1 --provider-physical-network tenant --provider-network-type vlan --provider-segment <VLAN-ID> # openstack subnet create subnet1 --network net1 --subnet-range 192.0.2.0/24 --dhcp
インスタンスをデプロイします。
# openstack server create --flavor <flavor> --image <glance image> --nic net-id=<network ID>
OVS-DPDK と共に multi-queue を使用するには、フレーバーで
属性を設定する前に、イメージで hw_vif_multiqueue_enabled 属性を設定します。
hw.vif_multiqueue_enabled
イメージの属性を設定します。
# openstack image set --property hw_vif_multiqueue_enabled=true <image>
追加のフレーバー属性を設定します。
# openstack flavor set --property hw:vif_multiqueue_enabled=true <flavor>
8.9. 設定のトラブルシューティング
本項では、Data Plane Development Kit 対応 Open vSwitch (OVS-DPDK) 設定のトラブルシューティングの手順を説明します。
ブリッジの設定を見直して、ブリッジが
datapath_type=netdev
で作成されたことを確認します。# ovs-vsctl list bridge br0 _uuid : bdce0825-e263-4d15-b256-f01222df96f3 auto_attach : [] controller : [] datapath_id : "00002608cebd154d" datapath_type : netdev datapath_version : "<built-in>" external_ids : {} fail_mode : [] flood_vlans : [] flow_tables : {} ipfix : [] mcast_snooping_enable: false mirrors : [] name : "br0" netflow : [] other_config : {} ports : [52725b91-de7f-41e7-bb49-3b7e50354138] protocols : [] rstp_enable : false rstp_status : {} sflow : [] status : {} stp_enable : false
docker コンテナー
neutron_ovs_agent
が自動的に起動するように設定されていることを確認します。# docker inspect neutron_ovs_agent | grep -A1 RestartPolicy "RestartPolicy": { "Name": "always",
コンテナーに起動に問題がある場合には、関連するメッセージを表示できます。
# less /var/log/containers/neutron/openvswitch-agent.log
ovs-dpdk
の PMD CPU マスクが CPU にピニングされていることを確認します。HT の場合には、シブリング CPU を使用します。たとえば、CPU 4 を確認します。
# cat /sys/devices/system/cpu/cpu4/topology/thread_siblings_list 4,20
CPU 4 および 20 を使用します。
# ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x100010
ステータスを表示します。
# tuna -t ovs-vswitchd -CP thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 3161 OTHER 0 6 765023 614 ovs-vswitchd 3219 OTHER 0 6 1 0 handler24 3220 OTHER 0 6 1 0 handler21 3221 OTHER 0 6 1 0 handler22 3222 OTHER 0 6 1 0 handler23 3223 OTHER 0 6 1 0 handler25 3224 OTHER 0 6 1 0 handler26 3225 OTHER 0 6 1 0 handler27 3226 OTHER 0 6 1 0 handler28 3227 OTHER 0 6 2 0 handler31 3228 OTHER 0 6 2 4 handler30 3229 OTHER 0 6 2 5 handler32 3230 OTHER 0 6 953538 431 revalidator29 3231 OTHER 0 6 1424258 976 revalidator33 3232 OTHER 0 6 1424693 836 revalidator34 3233 OTHER 0 6 951678 503 revalidator36 3234 OTHER 0 6 1425128 498 revalidator35 *3235 OTHER 0 4 151123 51 pmd37* *3236 OTHER 0 20 298967 48 pmd38* 3164 OTHER 0 6 47575 0 dpdk_watchdog3 3165 OTHER 0 6 237634 0 vhost_thread1 3166 OTHER 0 6 3665 0 urcu2
第9章 Red Hat OpenStack Platform 環境の調整
9.1. エミュレータースレッドの固定
エミュレータースレッドは、仮想マシンのハードウェアエミュレーションの割り込み要求およびノンブロッキングプロセスを処理します。これらのスレッドは、ゲストが処理に使用する vCPU 全体で共有されます。Poll Mode Driver(PMD)またはリアルタイム処理に使用されるスレッドがこれらの仮想 CPU で実行される場合、パケットロスまたはデッドラインの超過が生じる可能性があります。
スレッドを独自の vCPU に固定して、エミュレータースレッドを仮想マシン処理タスクから分離することができます。その結果、パフォーマンスが向上します。
9.1.1. エミュレータースレッドをホストする CPU の設定
パフォーマンスを向上させるために、エミュレータースレッドをホストするために pCPU のサブセットを確保します。Red Hat は、OvsDpdkCoreList
パラメーターで識別される pCPUs を使用することを推奨します。
手順
特定のロールに
NovaComputeCpuSharedSet
を定義してオーバークラウドをデプロイします。NovaComputeCpuSharedSet
の値は、そのロール内のホストの nova.conf ファイルのcpu_shared_set
パラメーターに適用されます。parameter_defaults: ComputeOvsDpdkParameters: OvsDpdkCoreList: “0-1,16-17” NovaComputeCpuSharedSet: “0-1,16-17”
エミュレータースレッドが共有プールに分離されたインスタンスをビルドするためのフレーバーを作成します。
openstack flavor create --ram <size_mb> --disk <size_gb> --vcpus <vcpus> <flavor>
hw:emulator_threads_policy
追加仕様を追加し、値をshare
に設定します。このフレーバーで作成されたインスタンスは、nova.conf ファイルのcpu_share_set
パラメーターで定義された仮想 CPU を使用します。openstack flavor set <flavor> --property hw:emulator_threads_policy=share
nova.conf ファイルの cpu_share_set
パラメーターを手動で設定するか、heat を使用してこの追加仕様の共有ポリシーを有効にする必要があります。
9.1.2. エミュレータースレッドが固定されていることの確認
手順
指定したインスタンスのホストとインスタンス名を特定します。
openstack server show <instance_id>
SSH を使用して、特定したホストに heat-admin としてログインします。
ssh heat-admin@compute-1 [compute-1]$ sudo virsh dumpxml instance-00001 | grep `'emulatorpin cpuset'`
9.2. NFV ワークロード向けの RT-KVM の有効化
本項では、Red Hat OpenStack Platform 向けに Red Hat Enterprise Linux 8.0 Real Time KVM(RT-KVM)をインストールおよび設定する手順を説明します。Red Hat OpenStack Platform は、リアルタイムに Red Hat Enterprise Linux をプロビジョニングするリアルタイムコンピュートノードロールと、追加の RT-KVM カーネルモジュール、およびコンピュートノードの自動設定を提供します。
9.2.1. RT-KVM コンピュートノードのプランニング
RT-KVM コンピュートノードには、Red Hat 認定済みサーバーを使用する必要があります。詳しくは、Red Hat Enterprise Linux for Real Time 7 用認定サーバー を参照してください。
RT-KVM 用の rhel-8-server-nfv-rpms
リポジトリーを有効にしてシステムを最新の状態に維持する方法についての詳細は、『director のインストールと使用方法』の「 アンダークラウドの登録と更新」を 参照してください。
このリポジトリーにアクセスするには、別途 Red Hat OpenStack Platform for Real Time
SKU のサブスクリプションが必要です。
real-time のイメージのビルド
Real-time コンピュートノード用のオーバークラウドイメージをビルドするには、以下のステップを実行します。
アンダークラウドに libguestfs-tools パッケージをインストールして、virt-customize ツールを取得します。
(undercloud) [stack@undercloud-0 ~]$ sudo dnf install libguestfs-tools
重要アンダークラウドに
libguestfs-tools
パッケージをインストールする場合は、アンダークラウドのtripleo_iscsid
サービスとのポートの競合を避けるためにiscsid.socket
を無効にします。$ sudo systemctl disable --now iscsid.socket
イメージを抽出します。
(undercloud) [stack@undercloud-0 ~]$ tar -xf /usr/share/rhosp-director-images/overcloud-full.tar (undercloud) [stack@undercloud-0 ~]$ tar -xf /usr/share/rhosp-director-images/ironic-python-agent.tar
デフォルトのイメージをコピーします。
(undercloud) [stack@undercloud-0 ~]$ cp overcloud-full.qcow2 overcloud-realtime-compute.qcow2
イメージを登録して、カスタマイズに適切な Red Hat のリポジトリーを有効にします。以下の例の
[username]
および[password]
を有効な認証情報に置き換えてください。virt-customize -a overcloud-realtime-compute.qcow2 --run-command \ 'subscription-manager register --username=[username] --password=[password]'
注記コマンドプロンプトで認証情報を使用したら、そのつど履歴ファイルから削除してください。
history -d
コマンドの後に行番号を指定して、履歴内の個々の行を削除することができます。アカウントのサブスクリプションからプール ID の一覧を取得し、適切なプール ID をイメージにアタッチします。
sudo subscription-manager list --all --available | less ... virt-customize -a overcloud-realtime-compute.qcow2 --run-command \ 'subscription-manager attach --pool [pool-ID]'
Red Hat OpenStack Platform で NFV を使用するのに必要なリポジトリーを追加します。
virt-customize -a overcloud-realtime-compute.qcow2 --run-command \ 'sudo subscription-manager repos --enable=rhel-8-for-x86_64-baseos-rpms \ --enable=rhel-8-for-x86_64-appstream-rpms \ --enable=rhel-8-for-x86_64-highavailability-rpms \ --enable=ansible-2.8-for-rhel-8-x86_64-rpms \ --enable=openstack-15-for-rhel-8-x86_64-rpms \ --enable=rhel-8-for-x86_64-nfv-rpms \ --enable=advanced-virt-for-rhel-8-x86_64-rpms \ --enable=fast-datapath-for-rhel-8-x86_64-rpms'
イメージ上でリアルタイム機能を設定するためのスクリプトを作成します。
(undercloud) [stack@undercloud-0 ~]$ cat <<'EOF' > rt.sh #!/bin/bash set -eux dnf -v -y --setopt=protected_packages= erase kernel.$(uname -m) dnf -v -y install kernel-rt kernel-rt-kvm tuned-profiles-nfv-host EOF
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」というエラー
が表示される場合があります。このエラーは無視しても問題ありません。パッケージが正しくインストールされていることを確認するには、以前のコマンドで作成した
virt-customize.log
ファイルを調べます。(undercloud) [stack@undercloud-0 ~]$ cat virt-customize.log | grep Verifying Verifying : kernel-3.10.0-957.el7.x86_64 1/1 Verifying : 10:qemu-kvm-tools-rhev-2.12.0-18.el7_6.1.x86_64 1/8 Verifying : tuned-profiles-realtime-2.10.0-6.el7_6.3.noarch 2/8 Verifying : linux-firmware-20180911-69.git85c5d90.el7.noarch 3/8 Verifying : tuned-profiles-nfv-host-2.10.0-6.el7_6.3.noarch 4/8 Verifying : kernel-rt-kvm-3.10.0-957.10.1.rt56.921.el7.x86_64 5/8 Verifying : tuna-0.13-6.el7.noarch 6/8 Verifying : kernel-rt-3.10.0-957.10.1.rt56.921.el7.x86_64 7/8 Verifying : rt-setup-2.0-6.el7.x86_64 8/8
SELinux の再ラベル付けをします。
(undercloud) [stack@undercloud-0 ~]$ virt-customize -a overcloud-realtime-compute.qcow2 --selinux-relabel
vmlinuz および initrd を抽出します。
(undercloud) [stack@undercloud-0 ~]$ mkdir image (undercloud) [stack@undercloud-0 ~]$ guestmount -a overcloud-realtime-compute.qcow2 -i --ro image (undercloud) [stack@undercloud-0 ~]$ cp image/boot/vmlinuz-3.10.0-862.rt56.804.el7.x86_64 ./overcloud-realtime-compute.vmlinuz (undercloud) [stack@undercloud-0 ~]$ cp image/boot/initramfs-3.10.0-862.rt56.804.el7.x86_64.img ./overcloud-realtime-compute.initrd (undercloud) [stack@undercloud-0 ~]$ guestunmount image
注記vmlinuz
およびinitramfs
のファイル名に含まれるソフトウェアバージョンは、カーネルバージョンによって異なります。イメージをアップロードします。
(undercloud) [stack@undercloud-0 ~]$ openstack overcloud image upload --update-existing --os-image-name overcloud-realtime-compute.qcow2
これで、選択したコンピュートノード上の ComputeOvsDpdkRT
コンポーザブルロールで使用することのできる real-time イメージの準備ができました。
RT-KVM コンピュートノード上での BIOS 設定の変更
RT-KVM コンピュートノードのレイテンシーを短縮するには、BIOS 設定を変更します。コンピュートノードの BIOS 設定で、以下の機能のオプションをすべて無効にします。
- 電源管理
- ハイパースレッディング
- CPU のスリープ状態
- 論理プロセッサー
これらの設定に関する説明は、「 BIOS パラメーターの設定」を 参照してください。BIOS 設定の変更方法に関する詳しい情報は、ハードウェアの製造会社のドキュメントを参照してください。
9.2.2. RT-KVM 対応の OVS-DPDK の設定
OVS-DPDK 向けの OpenStack ネットワークを最適化するには、network-environment.yaml ファイルで設定する OVS-DPDK パラメーターの最適な値を判断します。詳細は、「ワークフローを使用した DPDK パラメーターの算出」 を参照してください。
9.2.2.1. ComputeOvsDpdk コンポーザブルロールの生成
ComputeOvsDpdkRT
ロールを使用して、real-time の Compute イメージを使用するコンピュートノードを指定します。
ComputeOvsDpdkRT ロール向けに
roles_data.yaml
を生成します。# (undercloud) [stack@undercloud-0 ~]$ openstack overcloud roles generate -o roles_data.yaml Controller ComputeOvsDpdkRT
9.2.2.2. OVS-DPDK パラメーターの設定
不適切な値で Data Plane Development Kit(DPDK)をデプロイすると、デプロイメントが失敗したり、不安定になる可能性があります。OVS-DPDK 向けの Red Hat OpenStack Platform ネットワークを最適化するには、network-environment.yaml
ファイルで設定する OVS-DPDK パラメーターの最適な値を判断します。詳細は、「ワークフローを使用した DPDK パラメーターの算出」 を参照してください。
resource_registry
セクションに、使用する OVS-DPDK ロールの nic 設定を追加します。resource_registry: # Specify the relative/absolute path to the config files you want to use for override the default. OS::TripleO::ComputeOvsDpdkRT::Net::SoftwareConfig: nic-configs/compute-ovs-dpdk.yaml OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml
parameter_defaults
セクションで、OVS-DPDK および RT-KVM のパラメーターを設定します。# DPDK compute node. ComputeOvsDpdkRTParameters: KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=1-7,17-23,9-15,25-31" TunedProfileName: "realtime-virtual-host" IsolCpusList: "1,2,3,4,5,6,7,9,10,17,18,19,20,21,22,23,11,12,13,14,15,25,26,27,28,29,30,31" NovaVcpuPinSet: ['2,3,4,5,6,7,18,19,20,21,22,23,10,11,12,13,14,15,26,27,28,29,30,31'] NovaReservedHostMemory: 4096 OvsDpdkSocketMemory: "1024,1024" OvsDpdkMemoryChannels: "4" OvsDpdkCoreList: "0,16,8,24" OvsPmdCoreList: "1,17,9,25" VhostuserSocketGroup: "hugetlbfs" ComputeOvsDpdkRTImage: "overcloud-realtime-compute"
9.2.2.2.1. オーバークラウドのデプロイ
ML2-OVS 向けのオーバークラウドをデプロイします。
(undercloud) [stack@undercloud-0 ~]$ openstack overcloud deploy \ --templates \ -r /home/stack/ospd-15-vlan-dpdk-ctlplane-bonding-rt/roles_data.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs-dpdk.yaml \ -e /home/stack/ospd-15-vxlan-dpdk-data-bonding-rt-hybrid/containers-prepare-parameter.yaml \ -e /home/stack/ospd-15-vxlan-dpdk-data-bonding-rt-hybrid/network-environment.yaml
9.2.3. RT-KVM インスタンスの起動
リアルタイム対応のコンピュートノードで RT-KVM インスタンスを起動するには、以下の手順を実行します。
オーバークラウド上に RT-KVM フレーバーを作成します。
# openstack flavor create r1.small 99 4096 20 4 # openstack flavor set --property hw:cpu_policy=dedicated 99 # openstack flavor set --property hw:cpu_realtime=yes 99 # openstack flavor set --property hw:mem_page_size=1GB 99 # openstack flavor set --property hw:cpu_realtime_mask="^0-1" 99 # openstack flavor set --property hw:cpu_emulator_threads=isolate 99
RT-KVM インスタンスを起動します。
# openstack server create --image <rhel> --flavor r1.small --nic net-id=<dpdk-net> test-rt
(オプション) インスタンスが割り当てられたエミュレータースレッドを使用していることを確認します。
# virsh dumpxml <instance-id> | grep vcpu -A1 <vcpu placement='static'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='1'/> <vcpupin vcpu='1' cpuset='3'/> <vcpupin vcpu='2' cpuset='5'/> <vcpupin vcpu='3' cpuset='7'/> <emulatorpin cpuset='0-1'/> <vcpusched vcpus='2-3' scheduler='fifo' priority='1'/> </cputune>
9.3. 信頼済み Virtual Function
Virtual Function (VF) が特権を必要とする操作を実施できるように、VF を信頼するように Physical Function (PF) を設定することができます。たとえば、この設定を使用して、VF がプロミスキャスモードを有効にすることやハードウェアアドレスを変更することを許可することができます。
9.3.1. 信頼の付与
前提条件
- Red Hat OpenStack Platform director を使用した稼働中のインストール
手順
Physical Function が Virtual Function を信頼するのを有効にするのに必要なパラメーターを使用してオーバークラウドをデプロイするには、以下の手順を実施します。
parameter_defaults
セクションにNeutronPhysicalDevMappings
パラメーターを追加して、論理ネットワーク名と物理インターフェース間のリンクを作成します。parameter_defaults: NeutronPhysicalDevMappings: "sriov2:p5p2"
SR-IOV に関する既存のパラメーターに、新たな属性「trusted」を追加します。
parameter_defaults: NeutronPhysicalDevMappings: "sriov2:p5p2" NeutronSriovNumVFs: ["p5p2:8"] NovaPCIPassthrough: - devname: "p5p2" physical_network: "sriov2" trusted: "true"
注記値 true を二重引用符で囲む必要があります ("true")。
重要以下のステップは、安全な環境でのみ実施してください。この手順では、非管理者アカウントで信頼済みポートをバインドできるようにします。
権限を変更し、ユーザーがポートのバインディングを作成および更新するのを許可します。
parameter_defaults: NeutronApiPolicies: { operator_create_binding_profile: { key: 'create_port:binding:profile', value: 'rule:admin_or_network_owner'}, operator_get_binding_profile: { key: 'get_port:binding:profile', value: 'rule:admin_or_network_owner'}, operator_update_binding_profile: { key: 'update_port:binding:profile', value: 'rule:admin_or_network_owner'} }
9.3.2. 信頼済み VF の活用
信頼済み VF を使用するには、完全にデプロイされたオーバークラウドで以下の手順を実施します。
信頼済み VF ネットワークの作成
種別 vlan のネットワークを作成します。
openstack network create trusted_vf_network --provider-network-type vlan \ --provider-segment 111 --provider-physical-network sriov2 \ --external --disable-port-security
サブネットを作成します。
openstack subnet create --network trusted_vf_network \ --ip-version 4 --subnet-range 192.168.111.0/24 --no-dhcp \ subnet-trusted_vf_network
vnic-type
オプションを direct に、binding-profile
オプションを true に、それぞれ設定してポートを作成します。openstack port create --network sriov111 \ --vnic-type direct --binding-profile trusted=true \ sriov111_port_trusted
インスタンスを作成し、それを前のステップで作成した信頼済みポートにバインドします。
openstack server create --image rhel --flavor dpdk --network internal --port trusted_vf_network_port_trusted --config-drive True --wait rhel-dpdk-sriov_trusted
ハイパーバイザー上での信頼済み 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.4. 受信/送信キューサイズの設定
以下に示す理由により、3.5 百万パケット毎秒 (mpps) を超える高いパケットレートでは、パケットロスが生じる場合があります。
- ネットワークの中断
- SMI
- 仮想ネットワーク機能におけるパケット処理のレイテンシー
パケットロスを防ぐには、キューサイズをデフォルトの 512 から最大の 1024 に増やします。
前提条件
- 受信キューサイズを設定するには、libvirt v2.3 および QEMU v2.7 が必要です。
- 送信キューサイズを設定するには、libvirt v3.7 および QEMU v2.10 が必要です。
手順
受信および送信キューサイズを増やすには、該当する director ロールの
parameter_defaults:
セクションに以下の行を追加します。ComputeOvsDpdk ロールにおける例を以下に示します。parameter_defaults: ComputeOvsDpdkParameters: -NovaLibvirtRxQueueSize: 1024 -NovaLibvirtTxQueueSize: 1024
テスト
nova.conf ファイルで、受信キューサイズおよび送信キューサイズの値を確認することができます。
[libvirt] rx_queue_size=1024 tx_queue_size=1024
コンピュートホストの libvirt により生成された仮想マシンインスタンスの XML ファイルで、受信キューサイズおよび送信キューサイズの値を確認することができます。
<devices> <interface type='vhostuser'> <mac address='56:48:4f:4d:5e:6f'/> <source type='unix' path='/tmp/vhost-user1' mode='server'/> <model type='virtio'/> <driver name='vhost' rx_queue_size='1024' tx_queue_size='1024' /> <address type='pci' domain='0x0000' bus='0x00' slot='0x10' function='0x0'/> </interface> </devices>
受信キューサイズおよび送信キューサイズの値を検証するには、KVM ホストで以下のコマンドを使用します。
$ virsh dumpxml <vm name> | grep queue_size
- パフォーマンスの向上を確認することができます (例: 3.8 mpps/コアのレートでフレーム損失なし)。
9.5. NUMA 対応 vSwitch の設定
この機能は、本リリースでは テクノロジープレビュー として提供しているため、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.6. NFVi 環境における Quality of Service (QoS) の設定
QoS の設定に関する詳細は、「Quality of Service(QoS) の設定」を参照してください。SR-IOV および OVS-DPDK 送信インターフェースでサポートされる QoS ルールタイプは、bandwidth-limit
に限定されます。
第10章 例: OVS-DPDK および SR-IOV ならびに VXLAN トンネリングの設定
本項では、OVS-DPDK および SR-IOV インターフェースの両方を持つコンピュートノードをデプロイする方法について説明します。クラスターは、ML2/OVS および VXLAN トンネリングと共にインストールされます。
OVS-DPDK 用の OpenStack ネットワークを最適化するには、network-environment.yaml
ファイルに設定する OVS-DPDK パラメーターの最適な値を判断する必要があります。詳しくは、「ワークフローを使用した DPDK パラメーターの 算出」を参照してください。
10.1. ロールデータの設定
Red Hat OpenStack Platform では、roles_data.yaml
ファイルにデフォルトロールのセットが用意されています。独自の roles_data.yaml
ファイルを作成して、必要なロールをサポートすることができます。
以下の例では、ComputeOvsDpdkSriov ロールを作成します。Red Hat OpenStack Platform でのロール作成に関する情報は、『オーバークラウドの 高度なカスタマイズ』 を参照してください。以下の例で使用する特定のロールの詳細については、「roles_data.yaml」を参照してください。
10.2. OVS-DPDK パラメーターの設定
OVS-DPDK 用の OpenStack ネットワークを最適化するには、network-environment.yaml
ファイルに設定する OVS-DPDK パラメーターの最適な値を判断する必要があります。詳しくは、「 ワークフローを使用した DPDK パラメーターの算出」を 参照してください。
resource_registry
セクションに OVS-DPDK 用のカスタムリソースを追加します。resource_registry: # Specify the relative/absolute path to the config files you want to use for override the default. OS::TripleO::ComputeOvsDpdkSriov::Net::SoftwareConfig: nic-configs/computeovsdpdksriov.yaml OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml
parameter_defaults
セクションで、トンネルの種別をvxlan
に、ネットワーク種別をvxlan,vlan
に設定します。NeutronTunnelTypes: 'vxlan' NeutronNetworkType: 'vxlan,vlan'
parameters_defaults
セクションで、ブリッジマッピングを設定します。# The OVS logical->physical bridge mappings to use. NeutronBridgeMappings: - dpdk-mgmt:br-link0
parameter_defaults
セクションで、ComputeOvsDpdkSriov
ロール向けにロール固有のパラメーターを設定します。########################## # OVS DPDK configuration # ########################## ComputeOvsDpdkSriovParameters: KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=2-19,22-39" TunedProfileName: "cpu-partitioning" IsolCpusList: "2-19,22-39" NovaVcpuPinSet: ['4-19,24-39'] NovaReservedHostMemory: 4096 OvsDpdkSocketMemory: "3072,1024" OvsDpdkMemoryChannels: "4" OvsDpdkCoreList: "0,20,1,21" OvsPmdCoreList: "2,22,3,23" NovaComputeCpuSharedSet: [0,20,1,21] NovaLibvirtRxQueueSize: 1024 NovaLibvirtTxQueueSize: 1024
注記ゲストインスタンス作成の失敗を避けるために、DPDK PMD 用の DPDK NIC の有無にかかわらず、各 NUMA ノード上で少なくとも 1 つの CPU を (シブリングスレッドと共に) 割り当てる必要があります。これは、
OvsPmdCoreList
パラメーターで示され、NUMA 1 からコア 2 および 22 を持ち、NUMA 2 からコア 3 および 23 になります。注記本手順に示したとおり、これらのヒュージページは仮想マシンと、
OvsDpdkSocketMemory
パラメーターを使用する OVS-DPDK によって消費されます。仮想マシンで利用可能なヒュージページの数は、ブート
パラメーターからOvsDpdkSocketMemory
を引いた値です。DPDK インスタンスに関連付けるフレーバーに
hw:mem_page_size=1GB
も追加する必要があります。注記OvsDPDKCoreList
とOvsDpdkMemoryChannels
は、本手順では必須の設定です。適切な値を設定せずに DPDK をデプロイする場合、デプロイメントが失敗したり、不安定になる可能性があります。SR-IOV 向けにロール固有のパラメーターを設定します。
NovaPCIPassthrough: - devname: "p7p3" trusted: "true" physical_network: "sriov-1" - devname: "p7p4" trusted: "true" physical_network: "sriov-2"
10.3. コントローラーノードの設定
分離ネットワーク用のコントロールプレーンの Linux ボンディングを作成します。
- type: linux_bond name: bond_api bonding_options: "mode=active-backup" use_dhcp: false dns_servers: get_param: DnsServers members: - type: interface name: nic2 primary: true
この Linux ボンディングに VLAN を割り当てます。
- type: vlan vlan_id: get_param: InternalApiNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: InternalApiIpSubnet - type: vlan vlan_id: get_param: StorageNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: StorageIpSubnet - type: vlan vlan_id: get_param: StorageMgmtNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: StorageMgmtIpSubnet - type: vlan vlan_id: get_param: ExternalNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: ExternalIpSubnet routes: - default: true next_hop: get_param: ExternalInterfaceDefaultRoute
neutron-dhcp-agent および neutron-metadata-agent サービスにアクセスするための OVS ブリッジを作成します。
- type: ovs_bridge name: br-link0 use_dhcp: false mtu: 9000 members: - type: interface name: nic3 mtu: 9000 - type: vlan vlan_id: get_param: TenantNetworkVlanID mtu: 9000 addresses: - ip_netmask: get_param: TenantIpSubnet
10.4. DPDK および SR-IOV 用コンピュートノードの設定
デフォルトの compute.yaml
ファイルから computeovsdpdksriov.yaml
ファイルを作成し、以下のように変更します。
分離ネットワーク用のコントロールプレーンの Linux ボンディングを作成します。
- type: linux_bond name: bond_api bonding_options: "mode=active-backup" use_dhcp: false dns_servers: get_param: DnsServers members: - type: interface name: nic3 primary: true - type: interface name: nic4
この Linux ボンディングに VLAN を割り当てます。
- type: vlan vlan_id: get_param: InternalApiNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: InternalApiIpSubnet - type: vlan vlan_id: get_param: StorageNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: StorageIpSubnet
コントローラーにリンクする DPDK ポートを備えたブリッジを設定します。
- type: ovs_user_bridge name: br-link0 use_dhcp: false ovs_extra: - str_replace: template: set port br-link0 tag=_VLAN_TAG_ params: _VLAN_TAG_: get_param: TenantNetworkVlanID addresses: - ip_netmask: get_param: TenantIpSubnet members: - type: ovs_dpdk_bond name: dpdkbond0 mtu: 9000 rx_queue: 2 members: - type: ovs_dpdk_port name: dpdk0 members: - type: interface name: nic7 - type: ovs_dpdk_port name: dpdk1 members: - type: interface name: nic8
注記複数の DPDK デバイスを含めるには、追加する DPDK デバイスごとに
type
のコードセクションを繰り返します。注記OVS-DPDK を使用する場合には、同じコンピュートノード上の全ブリッジが
ovs_user_bridge
の種別でなければなりません。director は設定を受け入れることができますが、Red Hat OpenStack Platform は同じノード上でovs_bridge
とovs_user_bridge
が混在する構成はサポートしていません。
10.5. オーバークラウドのデプロイ
-
overcloud_deploy.sh
スクリプトを実行してオーバークラウドをデプロイします。
openstack overcloud deploy \ --templates \ -r /home/stack/ospd-15-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/roles_data.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-ovs.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-ovs-dpdk.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/collectd-environment.yaml \ -e /home/stack/ospd-15-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/api-policies.yaml \ -e /home/stack/ospd-15-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/network-environment.yaml \ -e /home/stack/overcloud_images.yaml \ --log-file overcloud_install.log &> overcloud_install.log
第11章 NFV を実装した Red Hat OpenStack Platform のアップグレード
OVS-DPDK が設定された Red Hat OpenStack Platform のアップグレードには、追加の考慮事項とステップが必要です。詳しくは、『Director Installation and Usage』の「 Preparing an NFV-Configured Overcloud 」を参照してください。
第12章 NFV パフォーマンス
Red Hat OpenStack Platform director は、ゲスト仮想ネットワーク機能 (VNF) 用にラインレートパフォーマンスを実現するために、リソースの分割および微調整を実施するようにコンピュートノードを設定します。NFV のユースケースにおける主要なパフォーマンス要素は、スループット、レイテンシー、およびジッターです。
Data Plane Development Kit(DPDK)で高速化した仮想マシンを使用して、物理 NIC と仮想マシンの間で高パフォーマンスのパケット切り替えを有効にすることができます。OVS 2.10 は、DPDK 17 に対応しており、vhost-user
のマルチキューをサポートしているので、スケーラブルなパフォーマンスを実現できます。OVS-DPDK は、ゲスト VNF 用のラインレートパフォーマンスを提供します。
Single Root I/O Virtualization (SR-IOV) ネットワークでは、特定ネットワークや仮想マシンのスループット向上など、強化されたパフォーマンス特性が提供されます。
パフォーマンスチューニングの他の重要な機能には、ヒュージページ、NUMA 調整、ホストの分離、CPU ピニングなどが挙げられます。VNF フレーバーには、パフォーマンス向上のためにヒュージページとエミュレータースレッドの分離が必要です。ホストの分離や CPU ピニングにより、NFV パフォーマンスが向上され、擬似パケットロスが回避されます。
CPU と NUMA トポロジーの概要は、『ネットワーク機能仮想化(NFV)の製品ガイド』の「 NFV のパフォーマンスの考慮事項 」および『インスタンス &イメージガイド』の「専用の物理 CPU で実行されるエミュレータースレッドの設定 」を参照してください。
第13章 その他の参考資料
以下の表には、参考となるその他の Red Hat ドキュメントの一覧を記載しています。
Red Hat OpenStack Platform のドキュメントスイートは Red Hat OpenStack Platform の製品ドキュメントスイート から参照してください。
コンポーネント | 参考情報 |
---|---|
Red Hat Enterprise Linux | Red Hat OpenStack Platform は Red Hat Enterprise Linux 8.0 でサポートされています。Red Hat Enterprise Linux のインストールに関する情報は、Red Hat Enterprise Linux のドキュメント から対応するインストールガイドを参照してください。 |
Red Hat OpenStack Platform | Red Hat OpenStack Platform(RHOSP)のコンポーネントおよびその依存関係をインストールするには、Red Hat OpenStack Platform director を使用します。director は、基本的な RHOSP 環境をアンダークラウドとして使用して、最終的なオーバークラウド内の RHOSP ノードをインストール、設定、および管理します。アンダークラウドのインストールには、デプロイするオーバークラウドに必要な環境に加えて、追加のホストマシンが 1 台必要です。詳しい手順は、『 Red Hat OpenStack Platform director のインストールと使用方法』 を参照してください。 Red Hat OpenStack Platform director を使用して、ネットワーク分離、ストレージ設定、SSL 通信、一般的な設定方法など、Red Hat OpenStack Platform のエンタープライズ環境の高度な機能設定に関する情報は、『オーバークラウドの 高度なカスタマイズ』 を参照してください。 |
NFV のドキュメント | NFV の概念の概要は、『 ネットワーク機能仮想化(NFV)の製品ガイド』 を参照してください。 |
付録A DPDK SR-IOV YAML ファイルのサンプル
本項では、同じコンピュートノードに Single Root I/O Virtualization (SR-IOV) および Data Plane Development Kit (DPDK) インターフェースを追加する際の参考として、YAML ファイルの例を示します。
これらのテンプレートは、完全に設定された環境から取得したもので、NFV とは関係のないパラメーターが含まれています。
A.1. VXLAN DPDK SRIOV YAML ファイルのサンプル
A.1.1. roles_data.yaml
############################################################################### # File generated by TripleO ############################################################################### ############################################################################### # Role: Controller # ############################################################################### - name: Controller description: | Controller role that has all the controller services loaded and handles Database, Messaging and Network functions. CountDefault: 1 tags: - primary - controller networks: - External - InternalApi - Storage - StorageMgmt - Tenant # For systems with both IPv4 and IPv6, you may specify a gateway network for # each, such as ['ControlPlane', 'External'] default_route_networks: ['External'] HostnameFormatDefault: '%stackname%-controller-%index%' # Deprecated & backward-compatible values (FIXME: Make parameters consistent) # Set uses_deprecated_params to True if any deprecated params are used. uses_deprecated_params: True deprecated_param_extraconfig: 'controllerExtraConfig' deprecated_param_flavor: 'OvercloudControlFlavor' deprecated_param_image: 'controllerImage' deprecated_nic_config_name: 'controller.yaml' ServicesDefault: - OS::TripleO::Services::Aide - OS::TripleO::Services::AodhApi - OS::TripleO::Services::AodhEvaluator - OS::TripleO::Services::AodhListener - OS::TripleO::Services::AodhNotifier - OS::TripleO::Services::AuditD - OS::TripleO::Services::BarbicanApi - OS::TripleO::Services::BarbicanBackendSimpleCrypto - OS::TripleO::Services::BarbicanBackendDogtag - OS::TripleO::Services::BarbicanBackendKmip - OS::TripleO::Services::BarbicanBackendPkcs11Crypto - OS::TripleO::Services::CACerts - OS::TripleO::Services::CeilometerAgentCentral - OS::TripleO::Services::CeilometerAgentNotification - OS::TripleO::Services::CephExternal - OS::TripleO::Services::CephMds - OS::TripleO::Services::CephMgr - OS::TripleO::Services::CephMon - OS::TripleO::Services::CephRbdMirror - OS::TripleO::Services::CephRgw - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::CinderApi - OS::TripleO::Services::CinderBackendDellPs - OS::TripleO::Services::CinderBackendDellSc - OS::TripleO::Services::CinderBackendDellEMCUnity - OS::TripleO::Services::CinderBackendDellEMCVMAXISCSI - OS::TripleO::Services::CinderBackendDellEMCVNX - OS::TripleO::Services::CinderBackendDellEMCXTREMIOISCSI - OS::TripleO::Services::CinderBackendNetApp - OS::TripleO::Services::CinderBackendScaleIO - OS::TripleO::Services::CinderBackendVRTSHyperScale - OS::TripleO::Services::CinderBackendNVMeOF - OS::TripleO::Services::CinderBackup - OS::TripleO::Services::CinderHPELeftHandISCSI - OS::TripleO::Services::CinderScheduler - OS::TripleO::Services::CinderVolume - OS::TripleO::Services::Clustercheck - OS::TripleO::Services::Collectd - OS::TripleO::Services::Congress - OS::TripleO::Services::ContainerImagePrepare - OS::TripleO::Services::DesignateApi - OS::TripleO::Services::DesignateCentral - OS::TripleO::Services::DesignateProducer - OS::TripleO::Services::DesignateWorker - OS::TripleO::Services::DesignateMDNS - OS::TripleO::Services::DesignateSink - OS::TripleO::Services::Docker - OS::TripleO::Services::Ec2Api - OS::TripleO::Services::Etcd - OS::TripleO::Services::ExternalSwiftProxy - OS::TripleO::Services::Fluentd - OS::TripleO::Services::GlanceApi - OS::TripleO::Services::GlanceRegistry - OS::TripleO::Services::GnocchiApi - OS::TripleO::Services::GnocchiMetricd - OS::TripleO::Services::GnocchiStatsd - OS::TripleO::Services::HAproxy - OS::TripleO::Services::HeatApi - OS::TripleO::Services::HeatApiCloudwatch - OS::TripleO::Services::HeatApiCfn - OS::TripleO::Services::HeatEngine - OS::TripleO::Services::Horizon - OS::TripleO::Services::Ipsec - OS::TripleO::Services::IronicApi - OS::TripleO::Services::IronicConductor - OS::TripleO::Services::IronicInspector - OS::TripleO::Services::IronicPxe - OS::TripleO::Services::IronicNeutronAgent - OS::TripleO::Services::Iscsid - OS::TripleO::Services::Keepalived - OS::TripleO::Services::Kernel - OS::TripleO::Services::Keystone - OS::TripleO::Services::LoginDefs - OS::TripleO::Services::ManilaApi - OS::TripleO::Services::ManilaBackendCephFs - OS::TripleO::Services::ManilaBackendIsilon - OS::TripleO::Services::ManilaBackendNetapp - OS::TripleO::Services::ManilaBackendUnity - OS::TripleO::Services::ManilaBackendVNX - OS::TripleO::Services::ManilaBackendVMAX - OS::TripleO::Services::ManilaScheduler - OS::TripleO::Services::ManilaShare - OS::TripleO::Services::Memcached - OS::TripleO::Services::MetricsQdr - OS::TripleO::Services::MistralApi - OS::TripleO::Services::MistralEngine - OS::TripleO::Services::MistralExecutor - OS::TripleO::Services::MistralEventEngine - OS::TripleO::Services::MongoDb - OS::TripleO::Services::MySQL - OS::TripleO::Services::MySQLClient - OS::TripleO::Services::NeutronApi - OS::TripleO::Services::NeutronBgpVpnApi - OS::TripleO::Services::NeutronSfcApi - OS::TripleO::Services::NeutronCorePlugin - OS::TripleO::Services::NeutronDhcpAgent - OS::TripleO::Services::NeutronL2gwAgent - OS::TripleO::Services::NeutronL2gwApi - OS::TripleO::Services::NeutronL3Agent - OS::TripleO::Services::NeutronLbaasv2Agent - OS::TripleO::Services::NeutronLbaasv2Api - OS::TripleO::Services::NeutronLinuxbridgeAgent - OS::TripleO::Services::NeutronMetadataAgent - OS::TripleO::Services::NeutronML2FujitsuCfab - OS::TripleO::Services::NeutronML2FujitsuFossw - OS::TripleO::Services::NeutronOvsAgent - OS::TripleO::Services::NeutronVppAgent - OS::TripleO::Services::NovaApi - OS::TripleO::Services::NovaConductor - OS::TripleO::Services::NovaConsoleauth - OS::TripleO::Services::NovaIronic - OS::TripleO::Services::NovaMetadata - OS::TripleO::Services::NovaPlacement - OS::TripleO::Services::NovaScheduler - OS::TripleO::Services::NovaVncProxy - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::OctaviaApi - OS::TripleO::Services::OctaviaDeploymentConfig - OS::TripleO::Services::OctaviaHealthManager - OS::TripleO::Services::OctaviaHousekeeping - OS::TripleO::Services::OctaviaWorker - OS::TripleO::Services::OpenDaylightApi - OS::TripleO::Services::OpenDaylightOvs - OS::TripleO::Services::OVNDBs - OS::TripleO::Services::OVNController - OS::TripleO::Services::Pacemaker - OS::TripleO::Services::PankoApi - OS::TripleO::Services::OsloMessagingRpc - OS::TripleO::Services::OsloMessagingNotify - OS::TripleO::Services::Redis - OS::TripleO::Services::Rhsm - OS::TripleO::Services::RsyslogSidecar - OS::TripleO::Services::SaharaApi - OS::TripleO::Services::SaharaEngine - OS::TripleO::Services::Securetty - OS::TripleO::Services::SensuClient - OS::TripleO::Services::SkydiveAgent - OS::TripleO::Services::SkydiveAnalyzer - OS::TripleO::Services::Snmp - OS::TripleO::Services::Sshd - OS::TripleO::Services::SwiftProxy - OS::TripleO::Services::SwiftDispersion - OS::TripleO::Services::SwiftRingBuilder - OS::TripleO::Services::SwiftStorage - OS::TripleO::Services::Tacker - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Tuned - OS::TripleO::Services::Vpp - OS::TripleO::Services::Zaqar - OS::TripleO::Services::Ptp - OS::TripleO::Services::Xinetd ############################################################################### # Role: ComputeOvsDpdkSriov # ############################################################################### - name: ComputeOvsDpdkSriov description: | Compute OvS DPDK Role CountDefault: 1 networks: - InternalApi - Tenant - Storage RoleParametersDefault: VhostuserSocketGroup: "hugetlbfs" TunedProfileName: "cpu-partitioning" ServicesDefault: - OS::TripleO::Services::Aide - OS::TripleO::Services::AuditD - OS::TripleO::Services::BootParams - OS::TripleO::Services::CACerts - OS::TripleO::Services::CephClient - OS::TripleO::Services::CephExternal - OS::TripleO::Services::CertmongerUser - OS::TripleO::Services::Collectd - OS::TripleO::Services::ComputeCeilometerAgent - OS::TripleO::Services::ComputeNeutronCorePlugin - OS::TripleO::Services::ComputeNeutronL3Agent - OS::TripleO::Services::ComputeNeutronMetadataAgent - OS::TripleO::Services::ComputeNeutronOvsDpdk - OS::TripleO::Services::NeutronSriovAgent - OS::TripleO::Services::NeutronSriovHostConfig - OS::TripleO::Services::Docker - OS::TripleO::Services::Fluentd - OS::TripleO::Services::Ipsec - OS::TripleO::Services::Iscsid - OS::TripleO::Services::Kernel - OS::TripleO::Services::LoginDefs - OS::TripleO::Services::MetricsQdr - OS::TripleO::Services::MySQLClient - OS::TripleO::Services::NeutronBgpVpnBagpipe - OS::TripleO::Services::NovaCompute - OS::TripleO::Services::NovaLibvirt - OS::TripleO::Services::NovaLibvirtGuests - OS::TripleO::Services::NovaMigrationTarget - OS::TripleO::Services::Ntp - OS::TripleO::Services::ContainersLogrotateCrond - OS::TripleO::Services::OpenDaylightOvs - OS::TripleO::Services::OVNMetadataAgent - OS::TripleO::Services::Rhsm - OS::TripleO::Services::RsyslogSidecar - OS::TripleO::Services::Securetty - OS::TripleO::Services::SensuClient - OS::TripleO::Services::SkydiveAgent - OS::TripleO::Services::Snmp - OS::TripleO::Services::Sshd - OS::TripleO::Services::Timezone - OS::TripleO::Services::TripleoFirewall - OS::TripleO::Services::TripleoPackages - OS::TripleO::Services::Ptp
A.1.2. network-environment.yaml
resource_registry: # Specify the relative/absolute path to the config files you want to use for override the default. OS::TripleO::ComputeOvsDpdkSriov::Net::SoftwareConfig: nic-configs/computeovsdpdksriov.yaml OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml parameter_defaults: # Customize all these values to match the local environment InternalApiNetCidr: 10.10.10.0/24 TenantNetCidr: 10.10.2.0/24 StorageNetCidr: 10.10.3.0/24 StorageMgmtNetCidr: 10.10.4.0/24 ExternalNetCidr: 172.20.12.112/28 # CIDR subnet mask length for provisioning network ControlPlaneSubnetCidr: '24' InternalApiAllocationPools: [{'start': '10.10.10.10', 'end': '10.10.10.200'}] TenantAllocationPools: [{'start': '10.10.2.100', 'end': '10.10.2.200'}] StorageAllocationPools: [{'start': '10.10.3.100', 'end': '10.10.3.200'}] StorageMgmtAllocationPools: [{'start': '10.10.4.100', 'end': '10.10.4.200'}] # Use an External allocation pool which will leave room for floating IPs ExternalAllocationPools: [{'start': '172.20.12.114', 'end': '172.20.12.125'}] # Set to the router gateway on the external network ExternalInterfaceDefaultRoute: 172.20.12.126 # Gateway router for the provisioning network (or Undercloud IP) ControlPlaneDefaultRoute: 192.168.24.1 # Generally the IP of the Undercloud EC2MetadataIp: 192.168.24.1 InternalApiNetworkVlanID: 10 TenantNetworkVlanID: 11 StorageNetworkVlanID: 12 StorageMgmtNetworkVlanID: 13 ExternalNetworkVlanID: 14 # Define the DNS servers (maximum 2) for the overcloud nodes DnsServers: ["8.8.8.8","8.8.4.4"] # May set to br-ex if using floating IPs only on native VLAN on bridge br-ex NeutronExternalNetworkBridge: "''" # The tunnel type for the tenant network (vxlan or gre). Set to '' to disable tunneling. NeutronTunnelTypes: 'vxlan' # The tenant network type for Neutron (vlan or vxlan). NeutronNetworkType: 'vxlan,vlan' # The OVS logical->physical bridge mappings to use. NeutronBridgeMappings: 'dpdk-mgmt:br-link0' # The Neutron ML2 and OpenVSwitch vlan mapping range to support. NeutronNetworkVLANRanges: 'dpdk-mgmt:22:22,dpdk-mgmt:25:25,sriov-1:600:600,sriov-2:601:601' # Nova flavor to use. OvercloudControllerFlavor: controller OvercloudComputeOvsDpdkSriovFlavor: compute # Number of nodes to deploy. ControllerCount: 3 ComputeOvsDpdkSriovCount: 2 # NTP server configuration. NtpServer: clock.redhat.com # MTU global configuration NeutronGlobalPhysnetMtu: 9000 # Configure the classname of the firewall driver to use for implementing security groups. NeutronOVSFirewallDriver: openvswitch SshServerOptions: UseDns: 'no' ControllerHostnameFormat: 'controller-%index%' ComputeOvsDpdkSriovHostnameFormat: 'compute-%index%' # Collectd server that will gather information from overcloud deployment - Service Assurance CollectdServer: 192.0.90.1 CollectdConnectionType: "network" ########################## # OVS DPDK configuration # ########################## ComputeOvsDpdkSriovParameters: KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=2-19,22-39" TunedProfileName: "cpu-partitioning" IsolCpusList: "2-19,22-39" NovaVcpuPinSet: ['4-19,24-39'] NovaReservedHostMemory: 4096 OvsDpdkSocketMemory: "3072,1024" OvsDpdkMemoryChannels: "4" OvsDpdkCoreList: "0,20,1,21" OvsPmdCoreList: "2,22,3,23" NovaComputeCpuSharedSet: [0,20,1,21] # below lines are for history - now this is resolved and we are not # required to pass extra hiera data variables - refer BZ - # https://bugzilla.redhat.com/show_bug.cgi?id=1617927 NovaLibvirtRxQueueSize: 1024 NovaLibvirtTxQueueSize: 1024 NovaPCIPassthrough: - devname: "p7p3" trusted: "true" physical_network: "sriov-1" - devname: "p7p4" trusted: "true" physical_network: "sriov-2" NeutronPhysicalDevMappings: "sriov-1:p7p3,sriov-2:p7p4" NeutronSriovNumVFs: "p7p3:5,p7p4:5"
A.1.3. controller.yaml
heat_template_version: rocky description: > Software Config to drive os-net-config to configure VLANs for the controller role. parameters: ControlPlaneIp: default: '' description: IP address/subnet on the ctlplane network type: string ExternalIpSubnet: default: '' description: IP address/subnet on the external network type: string ExternalInterfaceRoutes: default: [] description: > Routes for the external network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless the default is changed, the parameter is automatically resolved from the subnet host_routes attribute. type: json InternalApiIpSubnet: default: '' description: IP address/subnet on the internal_api network type: string InternalApiInterfaceRoutes: default: [] description: > Routes for the internal_api network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless the default is changed, the parameter is automatically resolved from the subnet host_routes attribute. type: json StorageIpSubnet: default: '' description: IP address/subnet on the storage network type: string StorageInterfaceRoutes: default: [] description: > Routes for the storage network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless the default is changed, the parameter is automatically resolved from the subnet host_routes attribute. type: json StorageMgmtIpSubnet: default: '' description: IP address/subnet on the storage_mgmt network type: string StorageMgmtInterfaceRoutes: default: [] description: > Routes for the storage_mgmt network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless the default is changed, the parameter is automatically resolved from the subnet host_routes attribute. type: json TenantIpSubnet: default: '' description: IP address/subnet on the tenant network type: string TenantInterfaceRoutes: default: [] description: > Routes for the tenant network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless the default is changed, the parameter is automatically resolved from the subnet host_routes attribute. type: json ManagementIpSubnet: # Only populated when including environments/network-management.yaml default: '' description: IP address/subnet on the management network type: string ManagementInterfaceRoutes: default: [] description: > Routes for the management network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless the default is changed, the parameter is automatically resolved from the subnet host_routes attribute. type: json BondInterfaceOvsOptions: default: 'bond_mode=active-backup' description: The ovs_options string for the bond interface. Set things like lacp=active and/or bond_mode=balance-slb using this option. type: string ExternalNetworkVlanID: default: 10 description: Vlan ID for the external network traffic. type: number InternalApiNetworkVlanID: default: 20 description: Vlan ID for the internal_api network traffic. type: number StorageNetworkVlanID: default: 30 description: Vlan ID for the storage network traffic. type: number StorageMgmtNetworkVlanID: default: 40 description: Vlan ID for the storage_mgmt network traffic. type: number TenantNetworkVlanID: default: 50 description: Vlan ID for the tenant network traffic. type: number ManagementNetworkVlanID: default: 60 description: Vlan ID for the management network traffic. type: number ExternalInterfaceDefaultRoute: default: '10.0.0.1' description: default route for the external network type: string ControlPlaneSubnetCidr: default: '' description: > The subnet CIDR of the control plane network. (The parameter is automatically resolved from the ctlplane subnet's cidr attribute.) type: string ControlPlaneDefaultRoute: default: '' description: The default route of the control plane network. (The parameter is automatically resolved from the ctlplane subnet's gateway_ip attribute.) type: string DnsServers: # Override this via parameter_defaults default: [] description: > DNS servers to use for the Overcloud (2 max for some implementations). If not set the nameservers configured in the ctlplane subnet's dns_nameservers attribute will be used. type: comma_delimited_list EC2MetadataIp: default: '' description: The IP address of the EC2 metadata server. (The parameter is automatically resolved from the ctlplane subnet's host_routes attribute.) type: string resources: OsNetConfigImpl: type: OS::Heat::SoftwareConfig properties: group: script config: str_replace: template: get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh params: $network_config: network_config: - type: interface name: nic1 use_dhcp: false addresses: - ip_netmask: list_join: - / - - get_param: ControlPlaneIp - get_param: ControlPlaneSubnetCidr routes: - ip_netmask: 169.254.169.254/32 next_hop: get_param: EC2MetadataIp - type: linux_bond name: bond_api bonding_options: "mode=active-backup" use_dhcp: false dns_servers: get_param: DnsServers members: - type: interface name: nic2 primary: true - type: vlan vlan_id: get_param: InternalApiNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: InternalApiIpSubnet - type: vlan vlan_id: get_param: StorageNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: StorageIpSubnet - type: vlan vlan_id: get_param: StorageMgmtNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: StorageMgmtIpSubnet - type: vlan vlan_id: get_param: ExternalNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: ExternalIpSubnet routes: - default: true next_hop: get_param: ExternalInterfaceDefaultRoute - type: ovs_bridge name: br-link0 use_dhcp: false mtu: 9000 members: - type: interface name: nic3 mtu: 9000 - type: vlan vlan_id: get_param: TenantNetworkVlanID mtu: 9000 addresses: - ip_netmask: get_param: TenantIpSubnet outputs: OS::stack_id: description: The OsNetConfigImpl resource. value: get_resource: OsNetConfigImpl
A.1.4. compute-ovs-dpdk.yaml
heat_template_version: rocky description: > Software Config to drive os-net-config to configure VLANs for the compute role. parameters: ControlPlaneIp: default: '' description: IP address/subnet on the ctlplane network type: string ExternalIpSubnet: default: '' description: IP address/subnet on the external network type: string ExternalInterfaceRoutes: default: [] description: > Routes for the external network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless the default is changed, the parameter is automatically resolved from the subnet host_routes attribute. type: json InternalApiIpSubnet: default: '' description: IP address/subnet on the internal_api network type: string InternalApiInterfaceRoutes: default: [] description: > Routes for the internal_api network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless the default is changed, the parameter is automatically resolved from the subnet host_routes attribute. type: json StorageIpSubnet: default: '' description: IP address/subnet on the storage network type: string StorageInterfaceRoutes: default: [] description: > Routes for the storage network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless the default is changed, the parameter is automatically resolved from the subnet host_routes attribute. type: json StorageMgmtIpSubnet: default: '' description: IP address/subnet on the storage_mgmt network type: string StorageMgmtInterfaceRoutes: default: [] description: > Routes for the storage_mgmt network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless the default is changed, the parameter is automatically resolved from the subnet host_routes attribute. type: json TenantIpSubnet: default: '' description: IP address/subnet on the tenant network type: string TenantInterfaceRoutes: default: [] description: > Routes for the tenant network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless the default is changed, the parameter is automatically resolved from the subnet host_routes attribute. type: json ManagementIpSubnet: # Only populated when including environments/network-management.yaml default: '' description: IP address/subnet on the management network type: string ManagementInterfaceRoutes: default: [] description: > Routes for the management network traffic. JSON route e.g. [{'destination':'10.0.0.0/16', 'nexthop':'10.0.0.1'}] Unless the default is changed, the parameter is automatically resolved from the subnet host_routes attribute. type: json BondInterfaceOvsOptions: default: 'bond_mode=active-backup' description: The ovs_options string for the bond interface. Set things like lacp=active and/or bond_mode=balance-slb using this option. type: string ExternalNetworkVlanID: default: 10 description: Vlan ID for the external network traffic. type: number InternalApiNetworkVlanID: default: 20 description: Vlan ID for the internal_api network traffic. type: number StorageNetworkVlanID: default: 30 description: Vlan ID for the storage network traffic. type: number StorageMgmtNetworkVlanID: default: 40 description: Vlan ID for the storage_mgmt network traffic. type: number TenantNetworkVlanID: default: 50 description: Vlan ID for the tenant network traffic. type: number ManagementNetworkVlanID: default: 60 description: Vlan ID for the management network traffic. type: number ExternalInterfaceDefaultRoute: default: '10.0.0.1' description: default route for the external network type: string ControlPlaneSubnetCidr: default: '' description: > The subnet CIDR of the control plane network. (The parameter is automatically resolved from the ctlplane subnet's cidr attribute.) type: string ControlPlaneDefaultRoute: default: '' description: The default route of the control plane network. (The parameter is automatically resolved from the ctlplane subnet's gateway_ip attribute.) type: string DnsServers: # Override this via parameter_defaults default: [] description: > DNS servers to use for the Overcloud (2 max for some implementations). If not set the nameservers configured in the ctlplane subnet's dns_nameservers attribute will be used. type: comma_delimited_list EC2MetadataIp: default: '' description: The IP address of the EC2 metadata server. (The parameter is automatically resolved from the ctlplane subnet's host_routes attribute.) type: string resources: OsNetConfigImpl: type: OS::Heat::SoftwareConfig properties: group: script config: str_replace: template: get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh params: $network_config: network_config: - type: interface name: nic1 use_dhcp: false defroute: false - type: interface name: nic2 use_dhcp: false addresses: - ip_netmask: list_join: - / - - get_param: ControlPlaneIp - get_param: ControlPlaneSubnetCidr routes: - ip_netmask: 169.254.169.254/32 next_hop: get_param: EC2MetadataIp - default: true next_hop: get_param: ControlPlaneDefaultRoute - type: linux_bond name: bond_api bonding_options: "mode=active-backup" use_dhcp: false dns_servers: get_param: DnsServers members: - type: interface name: nic3 primary: true - type: interface name: nic4 - type: vlan vlan_id: get_param: InternalApiNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: InternalApiIpSubnet - type: vlan vlan_id: get_param: StorageNetworkVlanID device: bond_api addresses: - ip_netmask: get_param: StorageIpSubnet - type: ovs_user_bridge name: br-link0 use_dhcp: false ovs_extra: - str_replace: template: set port br-link0 tag=_VLAN_TAG_ params: _VLAN_TAG_: get_param: TenantNetworkVlanID addresses: - ip_netmask: get_param: TenantIpSubnet members: - type: ovs_dpdk_bond name: dpdkbond0 mtu: 9000 rx_queue: 2 members: - type: ovs_dpdk_port name: dpdk0 members: - type: interface name: nic7 - type: ovs_dpdk_port name: dpdk1 members: - type: interface name: nic8 - type: interface name: p7p3 mtu: 9000 use_dhcp: false defroute: false nm_controlled: true hotplug: true - type: interface name: p7p4 mtu: 9000 use_dhcp: false defroute: false nm_controlled: true hotplug: true outputs: OS::stack_id: description: The OsNetConfigImpl resource. value: get_resource: OsNetConfigImpl
A.1.5. overcloud_deploy.sh
#!/bin/bash openstack overcloud deploy \ --templates \ -r /home/stack/ospd-15-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/roles_data.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-ovs-dpdk.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/collectd-environment.yaml \ -e /home/stack/ospd-15-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/api-policies.yaml \ -e /home/stack/ospd-15-vxlan-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/network-environment.yaml \ -e /home/stack/overcloud_images.yaml \ --log-file overcloud_install.log &> overcloud_install.log