ネットワーク機能仮想化 (NFV) のプランニングおよび設定ガイド
ネットワーク機能仮想化 (NFV) の OpenStack デプロイメントのプランニングと設定
概要
前書き
Red Hat OpenStack Platform は、Red Hat Enterprise Linux 上にプライベートまたはパブリッククラウドを構築するための基盤を提供します。これにより、スケーラビリティーが極めて高く、耐障害性に優れたプラットフォームをクラウド対応のワークロード開発にご利用いただくことができます。
本ガイドでは、Red Hat OpenStack Platform director を使用して、NFV デプロイメント向けに SR-IOV および DPDK データパス対応の Open vSwitch (OVS-DPDK) のプランニングおよび設定を行う方法について説明します。
第1章 概要
ネットワーク機能仮想化 (NFV) とは、汎用のクラウドベースのインフラストラクチャー上でネットワーク機能を仮想化するソフトウェアソリューションです。NFV により、通信事業者 (CSP) は従来のハードウェアから離れることができます。
NFV の概念に関する俯瞰的な情報は、『ネットワーク機能仮想化 (NFV) の製品ガイド』を参照してください。
OVS-DPDK および SR-IOV の設定は、ハードウェアとトポロジーに依存します。本ガイドでは、CPU の割り当て、メモリーの確保、NIC の設定の例を紹介します。これらは、トポロジーとユースケースによって異なる場合があります。
Red Hat OpenStack Platform director を使用すると、オーバークラウドのネットワークを分離することができます。この機能では、特定のネットワーク種別 (例: 外部、テナント、内部 API など) を分離ネットワークに分けることができます。ネットワークは、単一ネットワークインターフェース上または複数のネットワークインターフェースに分散してデプロイすることが可能です。Open vSwitch では、複数のインターフェースを単一のブリッジに割り当ててボンディングを作成することができます。Red Hat OpenStack Platform のインストールでは、ネットワークの分離はテンプレートファイルを使用して設定されます。テンプレートファイルを指定しない場合には、サービスネットワークはすべてプロビジョニングネットワーク上にデプロイされます。テンプレートの設定ファイルは 3 種類あります。
-
network-environment.yaml: このファイルには、オーバークラウドノードのネットワーク設定で使用するサブネット、IP アドレス範囲などのネットワークの情報が含まれます。さらに、このファイルには、さまざまなシナリオで使用できるように、デフォルトのパラメーターの値を上書きする異なる設定も含まれます。 -
ホストネットワークのテンプレート (例:
compute.yaml、controller.yaml): オーバークラウドノードのネットワークインターフェース設定を定義します。ネットワーク情報の値は、network-environment.yamlファイルによって提供されます。 インストール後の設定用のファイル (
post-install.yaml): インストール後に実行するさまざまな設定のステップを提供します。以下に例を示します。-
Tuned のインストールと設定。
tunedパッケージには、システムコンポーネントの使用状況をモニタリングして、そのモニタリング情報に基づいてシステムの設定を動的にチューニングする tuned デーモンが含まれています。OVS-DPDK および SR-IOV のデプロイメントで適切な CPU アフィニティーの設定を指定するには、tunedcpu-partitioningプロファイルを使用すべきです。このパッケージに関する詳しい情報は、『パフォーマンスチューニングガイド』を参照してください。
-
Tuned のインストールと設定。
これらの Heat テンプレートファイルは、アンダークラウドノードの /usr/share/openstack-tripleo-heat-templates/ にあります。
以下の項では、Red Hat OpenStack Platform director を使用した NFV 用 Heat テンプレートのプランニングおよび設定の方法について説明します。
NFV の設定には、YAML ファイルを使用します。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 Support」を参照してください (カスタマーポータルのログインが必要です)。
2.2. NUMA ノードのトポロジーについての理解
デプロイメントを計画する際には、コンピュートノードの NUMA トポロジーを理解した上で CPU とメモリーのリソースを分割し、パフォーマンスを最適化する必要があります。NUMA 情報の特定は、以下の手順で行うことができます。
- ベアメタルノードからこの情報を取得するには、ハードウェアイントロスペクションを有効にします。
- 各ベアメタルノードにログオンして、手動で情報を収集します。
ハードウェアイントロスペクションで NUMA 情報を取得するには、アンダークラウドのインストールと設定が完了している必要があります。詳しくは、『director のインストールと使用方法』を参照してください。
ハードウェアイントロスペクション情報の取得
Bare Metal サービスでは、ハードウェア検査時に追加のハードウェア情報を取得するためのパラメーター (inspection_extras) がデフォルトで有効になっています。これらのハードウェア情報を使って、オーバークラウドを設定することができます。undercloud.conf ファイルの inspection_extras パラメーターに関する詳細は、「director の設定」を参照してください。
たとえば、numa_topology コレクターは、このハードウェア inspection_extras の一部で、各 NUMA ノードに関する以下の情報が含まれます。
- RAM (キロバイト単位)
- 物理 CPU コアおよびそのシブリングスレッド
- NUMA ノードに関連付けられた NIC
この情報を取得するには、ベアメタルノードの UUID を指定して、openstack baremetal introspection data save _UUID_ | jq .numa_topology コマンドを実行します。
取得されるベアメタルノードの NUMA 情報の例を、以下に示します。
{
"cpus": [
{
"cpu": 1,
"thread_siblings": [
1,
17
],
"numa_node": 0
},
{
"cpu": 2,
"thread_siblings": [
10,
26
],
"numa_node": 1
},
{
"cpu": 0,
"thread_siblings": [
0,
16
],
"numa_node": 0
},
{
"cpu": 5,
"thread_siblings": [
13,
29
],
"numa_node": 1
},
{
"cpu": 7,
"thread_siblings": [
15,
31
],
"numa_node": 1
},
{
"cpu": 7,
"thread_siblings": [
7,
23
],
"numa_node": 0
},
{
"cpu": 1,
"thread_siblings": [
9,
25
],
"numa_node": 1
},
{
"cpu": 6,
"thread_siblings": [
6,
22
],
"numa_node": 0
},
{
"cpu": 3,
"thread_siblings": [
11,
27
],
"numa_node": 1
},
{
"cpu": 5,
"thread_siblings": [
5,
21
],
"numa_node": 0
},
{
"cpu": 4,
"thread_siblings": [
12,
28
],
"numa_node": 1
},
{
"cpu": 4,
"thread_siblings": [
4,
20
],
"numa_node": 0
},
{
"cpu": 0,
"thread_siblings": [
8,
24
],
"numa_node": 1
},
{
"cpu": 6,
"thread_siblings": [
14,
30
],
"numa_node": 1
},
{
"cpu": 3,
"thread_siblings": [
3,
19
],
"numa_node": 0
},
{
"cpu": 2,
"thread_siblings": [
2,
18
],
"numa_node": 0
}
],
"ram": [
{
"size_kb": 66980172,
"numa_node": 0
},
{
"size_kb": 67108864,
"numa_node": 1
}
],
"nics": [
{
"name": "ens3f1",
"numa_node": 1
},
{
"name": "ens3f0",
"numa_node": 1
},
{
"name": "ens2f0",
"numa_node": 0
},
{
"name": "ens2f1",
"numa_node": 0
},
{
"name": "ens1f1",
"numa_node": 0
},
{
"name": "ens1f0",
"numa_node": 0
},
{
"name": "eno4",
"numa_node": 0
},
{
"name": "eno1",
"numa_node": 0
},
{
"name": "eno3",
"numa_node": 0
},
{
"name": "eno2",
"numa_node": 0
}
]
}2.3. BIOS 設定の確認
以下のリストには、NFV に必要な BIOS 設定を記載します。
-
C3 Power State: 無効 -
C6 Power State: 無効 -
MLC Streamer: 有効 -
MLC Spacial Prefetcher: 有効 -
DCU Data Prefetcher: 有効 -
DCA: 有効 -
CPU Power and Performance: Performance. -
Memory RAS and Performance Config → NUMA Optimized: 有効 -
Turbo Boost: 無効
第3章 ソフトウェア要件
本項では、サポートされている設定とドライバー、および NFV に必要なサブスクリプションの詳細について説明します。
Red Hat OpenStack Platform をインストールするには、OpenStack 環境にある全システムを Red Hat サブスクリプションマネージャーで登録して、必要なチャンネルをサブスクライブします。詳しくは、「アンダークラウドの登録と更新」 を参照してください。
3.1. NFV デプロイメントでサポートされている構成
Red Hat OpenStack Platform は、director を使用した SR-IOV および OVS-DPDK のインストール向けの NFV デプロイメントをサポートしています。Red Hat OpenStack Platform director で利用可能なコンポーザブルロールを使用して、カスタムのデプロイメントロールを作成できます。今回のリリースではサポートが制限されていますが、ハイパーコンバージドインフラストラクチャー (HCI) が提供されており、分散型の NFV 向けにコンピュートノードと Red Hat Ceph Storage ノードを同じ場所に配置することができます。HCI のパフォーマンスを向上するために、CPU ピニングを使用します。HCI モデルでは、NFV のユースケースにおいてより効率的な管理を行うことができます。また、今回のリリースでは、サポート対象の機能として OpenDaylight および Real-Time KVM が提供されています。OpenDaylight とは、Software-Defined Network (SDN) デプロイメントに向けた、オープンソースのモジュール型マルチプロトコルコントローラーです。また、本リリースには OVS ハードウェアオフロードの機能がテクノロジープレビューとして含まれています。テクノロジープレビューとして提供されている機能のサポート範囲に関する詳しい情報は、「テクノロジプレビュー機能のサポート範囲」を参照してください。
3.2. サポートされているドライバー
サポートされるドライバーの完全な一覧は「Red Hat OpenStack Platform におけるコンポーネント、プラグイン、およびドライバーのサポート」を参照してください。
Red Hat OpenStack の NFV デプロイメント向けにテスト済みの NIC の一覧は、「テスト済みの NIC」を参照してください。
3.3. サードパーティー製のソフトウェアとの互換性
Red Hat のテクノロジー (Red Hat OpenStack Platform) で機能することを検証、サポート、認定済みの製品およびサービスの完全な一覧は、Red Hat OpenStack Platform と互換性のあるサードパーティー製のソフトウェア の情報を参照してください。製品バージョンやソフトウェアカテゴリー別に一覧をフィルタリングすることができます。
Red Hat のテクノロジー (Red Hat Enterprise Linux) で機能することを検証、サポート、認定済みの製品およびサービスの完全な一覧は、Red Hat Enterprise Linux と互換性のあるサードパーティー製のソフトウェア の情報を参照してください。製品バージョンやソフトウェアカテゴリー別に一覧をフィルタリングすることができます。
第4章 ネットワークの考慮事項
アンダークラウドのホストには、最低でも以下のネットワークが必要です。
- プロビジョニングネットワーク: オーバークラウドで使用できるベアメタルシステムの検出に役立つ DHCP および PXE ブート機能を提供します。
- 外部ネットワーク: 全ノードへのリモート接続に使用する別個のネットワーク。このネットワークに接続するこのインターフェースには、静的または外部の DHCP サービス経由で動的に定義された、ルーティング可能な IP アドレスが必要です。
最小のオーバークラウドの構成は、以下のとおりです。
- シングル NIC 構成: ネイティブの VLAN および異なる種別のオーバークラウドネットワークのサブネットを使用するタグ付けされた VLAN 上にプロビジョニングネットワーク用の NIC を 1 つ。
- デュアル NIC 構成: プロビジョニングネットワーク用の NIC を 1 つと、外部ネットワーク用の NIC を 1 つ。
- デュアル NIC 構成: ネイティブの VLAN 上にプロビジョニングネットワーク用の NIC を 1 つと、異なる種別のオーバークラウドネットワークのサブネットを使用するタグ付けされた VLAN 用の NIC を 1 つ。
- 複数 NIC 構成: 各 NIC は、異なる種別のオーバークラウドネットワークのサブセットを使用します。
ネットワーク要件の詳しい情報は「ネットワーク要件」を参照してください。
第5章 SR-IOV デプロイメントのプランニング
NFV 向けの SR-IOV デプロイメントを最適化するには、コンピュートノードのハードウェアに応じて、個別の OVS-DPDK パラメーターを設定する方法を理解しておく必要があります。
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 の一覧に基づいて、ブートパラメーターや OpenStack の変更を管理します。
5.2. NFV SR-IOV デプロイメントのトポロジー
以下の図には、2 つの VNF が示されています。各 VNF には、それぞれに mgt で示された管理インターフェースがあります。管理インターフェースは ssh アクセスなどを管理します。データプレーンインターフェースは VNF を DPDK にボンディングして、高可用性を確保します (VNF は DPDK ライブラリーを使用してデータプレーンインターフェースをボンディングします)。この図には、2 つの重複したプロバイダーネットワークも示されています。コンピュートノードには 2 つの標準 NIC がボンディングされ、VNF 管理と Red Hat OpenStack Platform API 管理の間で共有されています。

この図では、アプリケーションレベルで DPDK を活用し、SR-IOV VF/PF へのアクセスが可能な VNF を示しています。これらの両方を実装することにより、可用性またはパフォーマンスが向上します (ファブリックの設定に依存)。DPDK はパフォーマンスを向上させる一方、VF/PF DPDK のボンディングはフェイルオーバーに対応します (可用性)。VNF ベンダーは、DPDK PMD ドライバーが VF/PF として公開される SR-IOV カードを必ずサポートするようにする必要があります。また、管理ネットワークは OVS を使用するので、VNF は標準の VirtIO ドライバーを使用する「mgmt」ネットワークデバイスを認識します。オペレーターは、VNF への初回の接続にそのデバイスを使用して、DPDK アプリケーションが 2 つの VF/PF を適切にボンディングすることができます。
5.2.1. HCI を使用しない NFV SR-IOV
以下の図には、NFV ユースケース向けの非 HCI の SR-IOV のトポロジーを示しています。この環境は、1 Gbps の NIC を搭載したコンピュートノードおよびコントローラーノードと、director ノードで構成されます。

第6章 SR-IOV デプロイメントの設定
本項では、Red Hat OpenStack 向けの Single Root Input/Output Virtualization (SR-IOV) の設定方法について説明します。
オーバークラウドをデプロイする前に、アンダークラウドのインストールと設定が完了している必要があります。詳しくは、『director のインストールと使用方法』を参照してください。
これらの director Heat テンプレートによって変更されている etc/tuned/cpu-partitioning-variables.conf の isolated_cores またはその他の値は編集/変更しないでください。
6.1. SR-IOV 設定パラメーターについての概要
network-environment.yaml ファイルを更新して、カーネルの引数、SR-IOV ドライバー、PCI パススルーなどのパラメーターを追加します。また、compute.yaml ファイルも更新して SR-IOV インターフェースのパラメーターを追加してから、overcloud_deploy.sh スクリプトを実行して、その SR-IOV パラメーターを使用してオーバークラウドをデプロイする必要もあります。

本ガイドでは、CPU の割り当て、メモリーの確保、NIC の設定の例を紹介します。これらは、トポロジーとユースケースによって異なる場合があります。
6.2. OVS ハードウェアオフロード
OVS ハードウェアオフロードを対応の SR-IOV の設定には、ネットワーク設定テンプレートに特定の変更を加える必要はありません。本項では、OVS ハードウェアオフロードデプロイメント固有の変更について説明します。以下の手順では、一般的なネットワーク分離のデプロイメントに必要なその他のパラメーターおよびネットワーク設定テンプレートファイルについては説明していません。詳しくは、「5章SR-IOV デプロイメントのプランニング」を参照してください。
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト目的のみでご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビューについての詳しい情報は「対象範囲の詳細」を参照してください。
6.2.1. VLAN を使用した OVS ハードウェアオフロード対応の SR-IOV の設定
ComputeSriov ロールで OpenvSwitch (OVS) ハードウェアオフロードを有効化するには、以下の手順を実行します。
ComputeSriovロールを作成します。# openstack overcloud roles generate -o roles_data.yaml Controller ComputeSriov
openstack overcloud deployコマンドに環境ファイルを追加して、OVS ハードウェアオフロードとその依存関係を有効化します。# Enables OVS Hardware Offload in the ComputeSriov role /usr/share/openstack-tripleo-heat-templates/environments/ovs-hw-offload.yaml # Applies the KernelArgs and TunedProfile with a reboot /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml
以下の環境ファイルを
openstack overcloud deployコマンドに追加して、ML2-ODL を有効化します。#Enables ml2-odl with SR-IOV deployment /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml
注記The OVS ハードウェアオフロードの環境ファイルは、すべての neutron ML2 プラグインで共通しています。デプロイメント用のデフォルトの ML2 プラグインは ML2-OVS ですが、NFV デプロイメントには ML2-ODL を使用すべきです。
sriov-environment.yamlという名前の環境ファイルに SR-IOV ノードのパラメーターを設定します。parameter_defaults: NeutronTunnelTypes: '' NeutronNetworkType: 'vlan' NeutronBridgeMappings: - <network_name>:<bridge_name> NeutronNetworkVLANRanges: - <network_name>:<vlan_ranges> NeutronSriovNumVFs: - <interface_name>:<number_of_vfs>:switchdev NeutronPhysicalDevMappings: - <network_name>:<interface_name> NovaPCIPassthrough: - devname: <interface_name> physical_network: <network_name>注記SR-IOV ノードの設定および要件に応じて、<network_name>、<interface_name>、<number_of_vfs> を設定します。
ML2-ODL でデプロイする場合
THT_ROOT=”/usr/share/openstack-tripleo-heat-templates/” openstack overcloud deploy --templates \ -r roles_data.yaml \ -e $THT_ROOT/environments/ovs-hw-offload.yaml \ -e $THT_ROOT/environments/services-docker/neutron-opendaylight.yaml \ -e $THT_ROOT/environments/host-config-and-reboot.yaml \ -e sriov-environment.yaml \ -e <<network isolation and network config environment files>>
ML2-OVS でデプロイする場合
THT_ROOT=”/usr/share/openstack-tripleo-heat-templates/” openstack overcloud deploy --templates \ -r roles_data.yaml \ -e $THT_ROOT/environments/ovs-hw-offload.yaml \ -e $THT_ROOT/environments/host-config-and-reboot.yaml \ -e sriov-environment.yaml \ -e <<network isolation and network config environment files>>
6.2.2. VXLAN を使用した OVS ハードウェアオフロード対応の SR-IOV の設定
ComputeSriov ロールで OpenvSwitch (OVS) ハードウェアオフロードを有効化するには、以下の手順を実行します。
ComputeSriovロールを作成します。# openstack overcloud roles generate -o roles_data.yaml Controller ComputeSriov
openstack overcloud deployコマンドに環境ファイルを追加して、OVS ハードウェアオフロードとその依存関係を有効化します。# Enables OVS Hardware Offload in the ComputeSriov role /usr/share/openstack-tripleo-heat-templates/environments/ovs-hw-offload.yaml # Applies the KernelArgs and TunedProfile with a reboot /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml
SR-IOV インターフェース上で以下のネットワーク設定変更を適用します。
- type: interface name: <interface_name> addresses: - ip_netmask: get_param: TenantIpSubnet注記Mellanox ドライバーは、OVS ブリッジの VLAN インターフェース上の VXLAN トンネルで問題があります (single-nic-vlans ネットワーク設定を使用する VXLAN 環境と同様)。Mellanox ドライバーでこの問題が解決するまでは、(OVS ブリッジ上で VLAN インターフェースを使用する代わりに) VXLAN ネットワークをインターフェース上または OVS ブリッジ上に直接設定することができます。
以下の環境ファイルを
openstack overcloud deployコマンドに追加して、ML2-ODL を有効化します。#Enables ml2-odl with SR-IOV deployment /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight.yaml
注記The OVS ハードウェアオフロードの環境ファイルは、すべての neutron ML2 プラグインで共通しています。デプロイメント用のデフォルトの ML2 プラグインは ML2-OVS ですが、NFV デプロイメントには ML2-ODL を使用すべきです。
VXLAN デプロイメントには、
sriov-environment.yamlという名前の環境ファイルに SR-IOV ノードのパラメーターを設定します。parameter_defaults: NeutronSriovNumVFs: - <interface_name>:<number_of_vfs>:switchdev NovaPCIPassthrough: - devname: <interface_name> physical_network: null注記SR-IOV ノードの設定および要件に応じて、<network_name>、<interface_name>、<number_of_vfs> を設定します。
ML2-ODL でデプロイする場合
THT_ROOT=”/usr/share/openstack-tripleo-heat-templates/” openstack overcloud deploy --templates \ -r roles_data.yaml \ -e $THT_ROOT/environments/ovs-hw-offload.yaml \ -e $THT_ROOT/environments/services-docker/neutron-opendaylight.yaml \ -e $THT_ROOT/environments/host-config-and-reboot.yaml \ -e sriov-environment.yaml \ -e <<network isolation and network config environment files>>
ML2-OVS でデプロイする場合
THT_ROOT=”/usr/share/openstack-tripleo-heat-templates/” openstack overcloud deploy --templates \ -r roles_data.yaml \ -e $THT_ROOT/environments/ovs-hw-offload.yaml \ -e $THT_ROOT/environments/host-config-and-reboot.yaml \ -e sriov-environment.yaml \ -e <<network isolation and network config environment files>>
6.3. SR-IOV 用のフレーバーの作成とインスタンスのデプロイ
NFV を実装する Red Hat OpenStack Platform デプロイメントの SR-IOV の設定を完了した後には、以下の手順に従ってフレーバーを作成してインスタンスをデプロイします。
アグリゲートグループを作成して、SR-IOV 用にホストを追加します。
# openstack aggregate create --zone=sriov sriov # openstack aggregate add host sriov compute-sriov-0.localdomain
注記CPU ピニングされたインスタンスをピニングされていないインスタンスと分けるには、ホストアグリゲートを使用すべきです。CPU ピニングを使用していないインスタンスは、CPU ピニングを使用するインスタンスのリソース要件は順守しません。
フレーバーを作成します。
# openstack flavor create compute --ram 4096 --disk 150 --vcpus 4
compute はフレーバー名、
4096は MB 単位のメモリー容量、150は GB 単位のディスク容量 (デフォルトでは 0 G)、4は仮想 CPU 数を設定しています。フレーバーの追加のプロパティーを設定します。
# openstack flavor set --property hw:cpu_policy=dedicated --property hw:mem_page_size=1GB compute
compute はフレーバー名で、それ以外のパラメーターはそのフレーバーのその他のプロパティーを設定します。
ネットワークを作成します。
# openstack network create net1 --provider-physical-network tenant --provider-network-type vlan --provider-segment <VLAN-ID>
ポートを作成します。
vnic-typedirect を使用して SR-IOV VF ポートを作成します。# openstack port create --network net1 --vnic-type direct sriov_port
vnic-typedirect-physical を使用して SR-IOV PF ポートを作成します。# openstack port create --network net1 --vnic-type direct-physical sriov_port
インスタンスをデプロイします。
# openstack server create --flavor compute --availability-zone sriov --image rhel_7.3 --nic port-id=sriov_port sriov_vm
ここで
- compute はフレーバー名または ID です。
-
sriovはサーバーのアベイラビリティゾーンです。 -
rhel_7.3はインスタンスの作成に使用するイメージ (名前または ID) です。 -
sriov_portはサーバー上の NIC です。 -
sriov_vmはインスタンスの名前です。
これで、NFV ユースケースの SR-IOV 向けインスタンスのデプロイが完了しました。
第7章 OVS-DPDK デプロイメントのプランニング
NFV 向けの OVS-DPDK デプロイメントを最適化するには、OVS-DPDK がコンピュートーノードのハードウェア (CPU、NUMA ノード、メモリー、NIC) をどのように使用するかと、コンピュートノードに応じた OVS-DPDK の各パラメーターを決定するにあたっての考慮事項を理解しておくべきです。
CPU と NUMA トポロジーの概要は 「NFV のパフォーマンスの考慮事項」 を参照してください。
7.1. CPU 分割と NUMA トポロジーを使用する OVS-DPDK
OVS-DPDK はホスト、ゲスト、および OVS-DPDK 自体用にハードウェアリソースを分割します。OVS-DPDK Poll Mode Driver (PMD) は、専用のコアを必要とする DPDK アクティブループを実行します。これは、CPU 一覧とヒュージページが OVS-DPDK で専用であることを意味します。
サンプルの分割では、デュアルソケットのコンピュートノード上の 1 NUMA ノードにつき 16 コアが含まれます。ホストと OVS-DPDK では NIC を共有できないので、このトラフィックには追加の NIC が必要です。

NUMA ノードに DPDK NIC が関連付けられていない場合でも、両方の NUMA ノードで DPDK PMD スレッドを確保する必要があります。
OVS-DPDK のパフォーマンスは、NUMA ノードにローカルなメモリーブロックの確保にも左右されます。メモリーと CPU ピニングに使用する同じ NUMA ノードに関連付けられた NIC を使用してください。また、ボンディングを構成する両方のインターフェースには、同じ NUMA ノード上の NIC を必ず使用してください。
7.2. ワークフローと派生パラメーターについての概要
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト目的のみでご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビューについての詳しい情報は「対象範囲の詳細」を参照してください。
OpenStack Workflow (mistral) サービスを使用すると、利用可能なベアメタルノードのケイパビリティーに基づいてパラメーターを派生することができます。Openstack Workflow は .yaml ファイルを使用して実行するタスクとアクションのセットを定義します。tripleo-common/workbooks/ ディレクトリーにある derive_params.yaml という事前定義済みのワークブックを使用することができます。このワークブックは、ベアメタルのイントロスペクションで取得した結果から、サポートされる各パラメーターを派生するワークフローを提供します。derive_params.yaml のワークフローは、tripleo-common/workbooks/derive_params_formulas.yaml の計算式を使用して、派生パラメーターを計算します。
derive_params_formulas.yaml の計算式は、お使いの環境に応じて変更することができます。
derive_params.yaml ワークブックは、given composable ロール用の全ノードのハードウェア仕様が同じであることを前提としています。ワークフローは、フレーバーとプロファイルの関連付けと、nova の配置スケジューラーを考慮して、ロールに関連付けられたノードを照合し、そのロールと一致する最初のロールのイントロスペクションデータを使用します。
OpenStack のワークフローに関する詳細は、「workflow および execution のトラブルシューティング」を参照してください。
-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 のパラメーターについての概要
本項では、OVS-DPDK が director の network_environment.yaml HEAT テンプレート内のパラメーターを使用して CPU とメモリーを設定し、パフォーマンスを最適化する方法について説明します。この情報は、コンピュートノード上のハードウェアサポートと、そのハードウェアを分割して OVS-DPDK デプロイメントを最適化する最も有効な方法を評価するのに使用してください。
derived_parameters.yaml ワークフローを使用してこれらのパラメーターの値を自動生成した場合には、手動で計算する必要はありません。「ワークフローと派生パラメーターについての概要」を参照してください。
CPU コアを割り当てる際には必ず、同じ物理コア上の CPU シブリングスレッド (論理 CPU) をペアにしてください。
コンピュートノード上の CPU と NUMA ノードを特定するには、「NUMA ノードのトポロジーについての理解」を参照してください。この情報を使用して、CPU と他のパラメーターをマッピングして、ホスト、ゲストインスタンス、OVS-DPDK プロセスのニーズに対応します。
7.4.1. CPU パラメーター
OVS-DPDK は以下の CPU 分割パラメーターを使用します。
- OvsPmdCoreList
DPDK Poll Mode Driver (PMD) に使用する CPU コアを提供します。DPDK インターフェースのローカルの NUMA ノードに関連付けられた CPU コアを選択します。
OvsPmdCoreListは、Open vSwitch のpmd-cpu-maskの値に使用されます。- シブリングスレッドをペアにします。
-
OvsDpdkCoreListからすべてのコアを除外します。 -
両方の NUMA ノード上の 1 番目の物理コアの論理 CPU (両方のスレッドシブリング) が割り当てられないようにしてください。これらは、
OvsDpdkCoreListパラメーターに使用する必要があります。 - パフォーマンスは、この PMD コアリストに割り当てられている物理コアの数によって異なります。DPDK 用の NIC に関連付けられている NUMA ノードで、必要なコアを割り当てます。
DPDK 用の NIC が 1 つある NUMA ノードの場合:
- パフォーマンス要件に基づいて、必要な物理コア数を決定し、各物理コアに全シブリングスレッド (論理 CPU) を追加します。
DPDK 用の NIC がない NUMA ノードの場合:
- 1 つの物理コアのシブリングスレッド (論理 CPU) を割り当てます (NUMA ノードの 1 番目の物理コアを除く)。DPDK 用の NIC がない場合でも、ゲストインスタンス作成が失敗するのを回避するために、NUMA ノード上に最小限の DPDK Poll Mode Driver が必要です。
NUMA ノードに DPDK NIC が関連付けられていない場合でも、両方の NUMA ノードで DPDK PMD スレッドを確保する必要があります。
- NovaVcpuPinSet
CPU ピニング用のコアを設定します。コンピュートノードは、ゲストインスタンスにこれらのコアを使用します。
NovaVcpuPinSetはnova.confファイルのvcpu_pin_set値として使用されます。-
OvsPmdCoreListとOvsDpdkCoreListからすべてのコアを除外します。 - 残りのコアをすべて追加します。
- シブリングスレッドをペアにします。
-
- IsolCpusList
ホストのプロセスから分離される CPU コアのセット。このパラメーターは、
tuned-profiles-cpu-partitioningコンポーネント用のcpu-partitioning-variable.confファイルのisolated_cores値として使用されます。-
OvsPmdCoreListとNovaVcpuPinSetのコア一覧が一致するようにします。 - シブリングスレッドをペアにします。
-
- OvsDpdkCoreList
handler および revalidator スレッドなどの、データパス以外の OVS-DPDK プロセス用の CPU コアを提供します。このパラメーターは、マルチ NUMA ノードハードウェア上でのデータパスの全体的なパフォーマンスには影響は及ぼしません。このパラメーターは Open vSwitch の
dpdk-lcore-mask値に使用され、それらのコアはホストと共有されます。- 各 NUMA ノードから、1 番目のコア (およびシブリングスレッド) を割り当てます (NUMA に関連付けられている DPDK 用の NIC がない場合も)。
-
これらのコアは、
OvsPmdCoreListおよびNovaVcpuPinSetのコアの一覧と相互に排他的である必要があります。
7.4.2. メモリーパラメーター
OVS-DPDK は、以下のメモリーパラメーターを使用します。
- OvsDpdkMemoryChannels
NUMA ノードごとに、CPU 内のメモリーチャネルをマッピングします。
OvsDpdkMemoryChannelsパラメーターは Open vSwitch によりother_config:dpdk-extra=”-n <value>”値として使用されます。-
dmidecode -t memoryのコマンドを使用するか、お使いのハードウェアのマニュアルを参照して、利用可能なメモリーチャネルの数を確認します。 -
ls /sys/devices/system/node/node* -dのコマンドで NUMA ノードの数を確認します。 - 利用可能なメモリーチャネル数を NUMA ノード数で除算します。
-
- NovaReservedHostMemory
ホスト上のタスク用にメモリーを MB 単位で確保します。この値は、コンピュートノードにより
nova.confのreserved_host_memory_mb値として使用されます。- 静的な推奨値 4096 MB を使用します。
- OvsDpdkSocketMemory
NUMA ノードごとにヒュージページプールから事前に割り当てるメモリーの容量を MB 単位で指定します。この値は、Open vSwitch により
other_config:dpdk-socket-mem値として使用されます。-
コンマ区切りリストで指定します。
OvsDpdkSocketMemory値は NUMA ノード上の各 NIC の MTU 値から計算されます。 - DPDK NIC のない NUMA ノードの場合は、推奨される静的な値である 1024 MB (1GB) を使用します。
OvsDpdkSocketMemoryの値は、以下の等式で概算します。MEMORY_REQD_PER_MTU = (ROUNDUP_PER_MTU + 800) * (4096 * 64) Bytes
- 800 はオーバーヘッドの値です。
- 4096 * 64 は mempool 内のパケット数です。
- NUMA ノードで設定される各 MTU 値の MEMORY_REQD_PER_MTU を追加し、バッファーとして 512 MB をさらに加算します。その値を 1024 の倍数に丸めます。
-
コンマ区切りリストで指定します。
計算例: MTU 2000 および MTU 9000
DPDK NIC dpdk0 と dpdk1 は同じ NUMA ノード上にあり、それぞれ MTU 9000 と MTU 2000 で設定されています。必要なメモリーを算出する計算例を以下に示します。
MTU 値を 1024 バイトの倍数に丸めます。
MTU 値 9000 は、丸めると 9216 バイトになります。 MTU 値 2000 は、丸めると 2048 バイトになります。
それらの丸めたバイト値に基づいて、各 MTU 値に必要なメモリーを計算します。
MTU 値 9000 に必要なメモリー = (9216 + 800) * (4096*64) = 2625634304 MTU 値 2000 に必要なメモリー = (2048 + 800) * (4096*64) = 746586112
それらを合わせた必要なメモリーの合計を計算します (バイト単位)。
2625634304 + 746586112 + 536870912 = 3909091328 バイト
この計算は、 (MTU 値 9000 に必要なメモリー) + (MTU 値 2000 に必要なメモリー) + (512 MB バッファー) を示しています。
必要合計メモリーを MB に変換します。
3909091328 / (1024*1024) = 3728 MB
この値を 1024 の倍数に丸めます。
3724 MB を丸めると 4096 MB になります。
この値を使用して
OvsDpdkSocketMemoryを設定します。OvsDpdkSocketMemory: “4096,1024”
サンプルの計算 - MTU 2000
DPDK NIC dpdk0 と dpdk1 は同じ NUMA ノード 0 上にあり、それぞれ MTU 2000 と MTU 2000 で設定されています。必要なメモリーを算出する計算例を以下に示します。
MTU 値を 1024 バイトの倍数に丸めます。
MTU 値 2000 は 2048 バイトになります。
それらの丸めたバイト値に基づいて、各 MTU 値に必要なメモリーを計算します。
MTU 値 2000 に必要なメモリー = (2048 + 800) * (4096*64) = 746586112
それらを合わせた必要なメモリーの合計を計算します (バイト単位)。
746586112 + 536870912 = 1283457024 バイト
この計算は、(MTU 値 2000 に必要なメモリー) + (512 MB バッファー) を示しています。
必要合計メモリーを MB に変換します。
1283457024 / (1024*1024) = 1224 MB
この値を 1024 の倍数に丸めます。
1224 MB を丸めると 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
- 要求されたゲストインスタンスに対してコンピュートノードが使用するフィルターの順序付きリストを指定します。
- KernelArgs
コンピュートノードのブート時用に、複数のカーネル引数を
/etc/default/grubに指定します。設定に応じて、以下のパラメーターを追加します。hugepagesz: CPU 上のヒュージページのサイズを設定します。この値は、CPU のハードウェアによって異なります。OVS-DPDK デプロイメントには 1G に指定します (default_hugepagesz=1GB hugepagesz=1G)。pdpe1gbCPU フラグが出力されるかどうかをチェックして、CPU が 1G をサポートしていることを確認してください。lshw -class processor | grep pdpe1gb
-
hugepages count: ヒュージページの数を設定します。この値は、ホストの使用可能なメモリーの量によって異なります。利用可能なメモリーの大半を使用してください (NovaReservedHostMemoryを除く)。ヒュージページ数の値は、お使いのコンピュートノードに関連付けられている OpenStack フレーバーの範囲内で設定する必要もあります。 -
iommu: Intel CPU の場合は、“intel_iommu=on iommu=pt”`を追加します。 -
isolcpus: チューニングされる CPU コアを設定します。この値はIsolCpusListと一致します。
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 用です。
このユースケースでは、PMD 用の NUMA 0 に物理コアを 1 つ 割り当てます。NUMA 1 ノードでは NIC に DPDK が有効化されていませんが、NUMA 1 にも物理コアを 1 つ割り当てる必要があります。残りのコア (OvsDpdkCoreList 用に確保されていないコア) はゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。
OvsPmdCoreList: “2,3,10,11” NovaVcpuPinSet: “4,5,6,7,12,13,14,15”
NIC 1 は DPDK 用で、2 つの物理コアは PMD 用
このユースケースでは、PMD 用の NUMA 0 に物理コアを 2 つ 割り当てます。NUMA 1 ノードでは NIC に DPDK が有効化されていませんが、NUMA 1 にも物理コアを 1 つ割り当てる必要があります。残りのコア (OvsDpdkCoreList 用に確保されていないコア) はゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。
OvsPmdCoreList: “2,3,4,5,10,11” NovaVcpuPinSet: “6,7,12,13,14,15”
NIC 2 は DPDK 用で、1 つの物理コアは PMD 用です。
このユースケースでは、PMD 用の NUMA 1 に物理コアを 1 つ 割り当てます。NUMA 0 ノードでは NIC に DPDK が有効化されていませんが、NUMA 0 にも物理コアを 1 つ割り当てる必要があります。残りのコア (OvsDpdkCoreList 用に確保されていないコア) はゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。
OvsPmdCoreList: “2,3,10,11” NovaVcpuPinSet: “4,5,6,7,12,13,14,15”
NIC 2 は DPDK 用で、2 つの物理コアは PMD 用
このユースケースでは、PMD 用の NUMA 1 に物理コアを 2 つ 割り当てます。NUMA 0 ノードでは NIC に DPDK が有効化されていませんが、NUMA 0 にも物理コアを 1 つ割り当てる必要があります。残りのコア (OvsDpdkCoreList 用に確保されていないコア) はゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。
OvsPmdCoreList: “2,3,10,11,12,13” NovaVcpuPinSet: “4,5,6,7,14,15”
NIC 1 と NIC2 は DPDK 用で、2 つの物理コアは PMD 用
このユースケースでは、PMD 用の各 NUMA ノードに物理コアを 2 つ 割り当てます。残りのコア (OvsDpdkCoreList 用に確保されていないコア) はゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。
OvsPmdCoreList: “2,3,4,5,10,11,12,13” NovaVcpuPinSet: “6,7,14,15”
7.6. NFV OVS-DPDK デプロイメントのトポロジー
この例の OVS-DPDK デプロイメントは 2 つの VNF で構成され、それぞれに 2 つのインターフェース (mgt で示されている管理インターフェースとデータプレーンインターフェース) があります。OVS-DPDK デプロイメントでは、VNF は、物理インターフェースをサポートする組み込みの DPDK で稼働します。OVS-DPDK は、vSwitch レベルでボンディングを管理します。OVS-DPDK デプロイメントでは、カーネルと OVS-DPDK の NIC を 混在させない ことを推奨します。混在させた場合には、パフォーマンスが低下する可能性があります。仮想マシン向けのベースプロバイダーネットワークに接続された管理 (mgt) ネットワークを分離するには、追加の NIC があることを確認する必要があります。コンピュートノードは、OpenStack API 管理向けの標準の NIC 2 つで構成されます。これは、Ceph API で再利用できますが、OpenStack テナントとは一切共有できません。

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

第8章 OVS-DPDK デプロイメントの設定
本項では、DPDK (OVS-DPDK) を Open vSwitch とともに Red Hat OpenStack Platform 環境内にデプロイします。オーバークラウドは、通常コントローラーノードやコンピュートノードなどの事前定義済みロールのノードと、異なる種別のストレージノードで構成されます。これらのデフォルトロールにはそれぞれ、director ノード上のコア Heat テンプレートで定義されている一式のサービスが含まれます。
オーバークラウドをデプロイする前に、アンダークラウドのインストールと設定が完了している必要があります。詳しくは、『director のインストールと使用方法』を参照してください。
OVS-DPDK 向けの OpenStack ネットワークを最適化するには、network-environment.yaml ファイルで設定する OVS-DPDK パラメーターの最も適切な値を決定する必要があります。
これらの director Heat テンプレートによって変更されている etc/tuned/cpu-partitioning-variables.conf の isolated_cores またはその他の値は編集/変更しないでください。
8.1. ワークフローを使用した DPDK パラメーターの算出
この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト目的のみでご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビューについての詳しい情報は「対象範囲の詳細」を参照してください。
DPDK 向けの Mistral ワークフローに関する概要は、「ワークフローと派生パラメーターについての概要」を参照してください。
前提条件
このワークフローで取得されるデータを提供するには、ハードウェア検査で追加情報を取得するための追加のパラメーター (inspection_extras) を含むベアメタルのイントロスペクションを有効化しておく必要があります。ハードウェア検査の追加パラメーターはデフォルトで有効化されます。「ノードのハードウェアの検査」を参照してください。
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 用のワークフローと入力パラメーターを定義するには、以下の手順を実行します。
tripleo-heat-templates/plan-samples/plan-environment-derived-params.yamlファイルをローカルのディレクトリーにコピーして、お使いの環境に適した入力パラメーターを設定します。workflow_parameters: tripleo.derive_params.v1.derive_parameters: # DPDK Parameters # # Specifices the minimum number of CPU physical cores to be allocated for DPDK # PMD threads. The actual allocation will be based on network config, if # the a DPDK port is associated with a numa node, then this configuration # will be used, else 1. num_phy_cores_per_numa_node_for_pmd: 1 # Amount of memory to be configured as huge pages in percentage. Ouf the # total available memory (excluding the NovaReservedHostMemory), the # specified percentage of the remaining is configured as huge pages. huge_page_allocation_percentage: 50update-plan-onlyパラメーターを使用してオーバークラウドをデプロイし、派生パラメーターを計算します。$ openstack overcloud deploy --templates --update-plan-only -r /home/stack/ospd-13-sriov-dpdk-heterogeneous-cluster/roles_data.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml -e /home/stack/ospd-13-sriov-dpdk-heterogeneous-cluster/docker-images.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml -e /home/stack/ospd-13-sriov-dpdk-heterogeneous-cluster/network-environment.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-sriov.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-ovs-dpdk.yaml -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 に設定すべきです。
派生パラメーターを使用したオーバークラウドのデプロイ
これらの派生パラメーターを使用してオーバークラウドをデプロイするには、以下の手順を実行します。
派生パラメーターを
plan-environment.yamlファイルから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"注記DPDK PMD 向けに DPDK NIC のある場合またはない場合も、各 NUMA ノードで少なくとも 1 CPU を (シブリングスレッドとともに) 割り当てて、ゲストインスタンスの作成でエラーが発生するのを回避する必要があります。
注記これらのパラメーターは、特定のロール (ComputeOvsDpdk) に適用されます。これらのパラメーターは、グローバルで適用可能ですが、グローバルパラメーターはロール固有のパラメーターによってオーバーライドされます。
- オーバークラウドをデプロイします。
#!/bin/bash openstack overcloud deploy \ --templates \ -r /home/stack/ospd-13-sriov-dpdk-heterogeneous-cluster/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-sriov.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-ovs-dpdk.yaml \ -e /home/stack/ospd-13-sriov-dpdk-heterogeneous-cluster/network-environment.yaml
- 注記
- Compute、ComputeOvsDpdk、ComputeSriov で構成されるクラスターでは、既存の派生パラメーターのワークフローにより ComputeOvsDpdk ロールの計算式のみが適用され、他のロールは影響を受けません。
8.2. OVS-DPDK のトポロジー
Red Hat OpenStack Platform では、コンポーザブルロール機能を使用し、各ロールにサービスを追加/削除してカスタムのデプロイメントロールを作成できます。コンポーザブルロールの詳しい情報は「コンポーザブルサービスとカスタムロール」を参照してください。
以下の図は、コントロールプレーンとデータプレーン用にポートが 2 つボンディングされている OVS-DPDK トポロジーの例を示しています。

OVS-DPDK の設定は、以下の作業で構成されます。
-
コンポーザブルロールを使用する場合には、
roles_data.yamlファイルをコピーして編集し、OVS-DPDK 用のカスタムロールを追加します。 -
適切な
network-environment.yamlファイルを更新して、カーネル引数と DPDK 引数のパラメーターを追加します。 -
compute.yamlファイルを更新して、DPDK インターフェース用のブリッジを追加します。 -
controller.yamlファイルを更新して、DPDK インターフェースパラメーター用の同じブリッジ情報を追加します。 -
overcloud_deploy.shスクリプトを実行して、DPDK パラメーターを使用してオーバークラウドをデプロイします。
本ガイドでは、CPU の割り当て、メモリーの確保、NIC の設定の例を紹介します。これらは、トポロジーとユースケースによって異なる場合があります。ハードウェアと設定のオプションについて理解するには、『ネットワーク機能仮想化 (NFV) の製品ガイド』 と「2章ハードウェア要件」を参照してください。
手順を開始する前に、以下の項目が揃っていることを確認します。
- OVS 2.9
- DPDK 17
- テスト済み NIC。NFV 向けのテスト済み NIC の一覧は、「テスト済みの NIC」を参照してください。
OVS-DPDK デプロイメントでは、Red Hat OpenStack Platform は、OVS クライアントモードで稼働します。
8.3. OVS-DPDK インターフェースの MTU 値の設定
Red Hat OpenStack Platform は OVS-DPDK 向けにジャンボフレームをサポートしています。ジャンボフレーム用の MTU 値を設定するには、以下の作業を行う必要があります。
-
network-environment.yamlファイルで、グローバルの MTU 値を設定します。 -
compute.yamlファイルで物理 DPDK ポートの MTU 値を設定します。この値は、vhost のユーザーインターフェースでも使用されます。 - コンピュートノード上の任意のゲストインスタンスで MTU 値を設定し、設定内でエンドツーエンドに同等の MTU 値が設定されるようにします。
VXLAN パケットには追加で 50 バイトがヘッダーに含まれます。MTU の必要値は、ヘッダーの追加バイト値に基づいて計算してください。たとえば、MTU 値 が 9000 の場合には、これらの追加バイト値を計算に入れると、VXLAN トンネルの MTU 値は 8950 となります。
物理 NIC は DPDK PMD によって制御され、compute.yaml ファイルで設定されているのを同じ MTU 値が適用されるので、特別な設定は必要ありません。MTU 値には、物理 NIC でサポートされているよりも高い値を設定することはできません。
OVS-DPDK インターフェースの MTU 値を設定するには、以下の手順を実行します。
network-environment.yamlファイルでNeutronGlobalPhysnetMtuパラメーターを設定します。parameter_defaults: # MTU global configuration NeutronGlobalPhysnetMtu: 9000
注記network-environment.yamlファイルの NeutronDpdkSocketMemory の値がジャンボフレームをサポートするのに十分に大きな値であることを確認します。詳しくは、「メモリーパラメーター」を参照してください。controller.yamlファイルでコンピュートノードへのブリッジ上の MTU 値を設定します。- type: ovs_bridge name: br-link0 use_dhcp: false members: - type: interface name: nic3 mtu: 9000compute.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. セキュリティーグループの設定
Red Hat OpenStack Platform director で OVS ファイアウォールドライバーを使用するためのセキュリティーグループを設定することができます。NeutronOVSFirewallDriver パラメーターで、どのファイアウォールドライバーを使用するかを制御することができます。
-
iptables_hybrid: OpenStack Networking が iptables/ハイブリッドベースの実装を使用するように設定します。 -
openvswitch: OpenStack Networking で OVS ファイアウォールのフローベースのドライバーを使用するように設定します。
openvswitch OVS ファイアウォールドライバーはパフォーマンスがより高く、ゲストをプロジェクトネットワークに接続するためのインターフェースとブリッジの数を削減します。
iptables_hybrid オプションは、OVS-DPDK との互換性はありません。
network-environment.yaml ファイルで NeutronOVSFirewallDriver パラメーターを設定します。
# Configure the classname of the firewall driver to use for implementing security groups. NeutronOVSFirewallDriver: openvswitch
セキュリティーグループの有効化/無効化についての情報は、「Basic security group operations」を参照してください。
8.5. OVS-DPDK インターフェース向けのマルチキューの設定
コンピュートノード上の OVS-DPDK のインターフェースに同じ数のキューを設定するには、compute.yaml ファイルを以下のように変更します。
- type: ovs_user_bridge
name: br-link0
use_dhcp: false
members:
- type: ovs_dpdk_bond
name: dpdkbond0
mtu: 9000
rx_queue: 2
members:
- type: ovs_dpdk_port
name: dpdk0
mtu: 9000
members:
- type: interface
name: nic4
- type: ovs_dpdk_port
name: dpdk1
mtu: 9000
members:
- type: interface
name: nic58.6. 既知の制限事項
NFV のユースケース向けに Red Hat OpenStack Platform で OVS-DPDK を設定する場合には特定の制限事項があります。
- コントロールプレーンのネットワークには、Linux ボンディングを使用します。パフォーマンスを最適化するには、ボンディングに使用されている両方の PCI デバイスが同じ NUMA ノード上にあることを確認してください。Red Hat では、Neutron の Linux ブリッジ構成はサポートしていません。
- ヒュージページは OVS-DPDK を使用するホスト上で実行される全インスタンスに必要です。ゲストのヒュージページがない場合には、インターフェースは表示されても機能しません。
TAP デバイスは DPDK をサポートしていないため、それらのデバイスを使用するサービスのパフォーマンスが低下します。たとえば、DVR、FWaaS、LBaaS などのサービスは TAP デバイスを使用します。
-
OVS-DPDK では、
netdev datapathで DVR を有効化することができますが、パフォーマンスが低いので、実稼働環境には適していません。DVR はカーネルの名前空間と TAP デバイスを使用してルーティングを実行します。 - OVS-DPDK で DVR ルーティングのパフォーマンスを良好な状態にするには、OpenFlow ルールとしてルーティングを実装する ODL などのコントローラーを使用する必要があります。OVS-DPDK では、 OpenFlow ルーティングは、Linux カーネルインターフェースによって生じるボトルネックをなくすので、データパスの完全なパフォーマンスが維持されます。
-
OVS-DPDK では、
-
OVS-DPDK を使用する場合には、同じコンピュートノード上の すべて のブリッジが
ovs_user_bridgeの種別である必要があります。director は設定を受け入れることができますが、Red Hat OpenStack Platform は同じノード上でovs_bridgeとovs_user_bridgeが混在する構成はサポートしていません。
8.7. OVS-DPDK 用のフレーバーの作成とインスタンスのデプロイ
NFV を実装する Red Hat OpenStack Platform デプロイメントの OVS-DPDK の設定を完了した後には、以下の手順に従ってフレーバーを作成してインスタンスをデプロイすることができます。
アグリゲートグループを作成して、OVS-DPDK 用にホストを追加します。
# openstack aggregate create --zone=dpdk dpdk # openstack aggregate add host dpdk compute-ovs-dpdk-0.localdomain
注記CPU ピニングされたインスタンスをピニングされていないインスタンスと分けるには、ホストアグリゲートを使用すべきです。CPU ピニングを使用していないインスタンスは、CPU ピニングを使用するインスタンスのリソース要件は順守しません。
フレーバーを作成します。
# openstack flavor create m1.medium_huge_4cpu --ram 4096 --disk 150 --vcpus 4
このコマンドでは、
m1.medium_huge_4cpuはフレーバー名、4096は MB 単位のメモリー容量、150は GB 単位のディスク容量 (デフォルトでは 0 G)、4は仮想 CPU 数を設定しています。フレーバーの追加のプロパティーを設定します。
# openstack flavor set --property hw:cpu_policy=dedicated --property hw:mem_page_size=1GB m1.medium_huge_4cpu --property hw:emulator_threads_policy=isolate
このコマンドでは、
m1.medium_huge_4cpuはフレーバー名を指定しており、残りはそのフレーバーのその他のプロパティーを設定しています。
パフォーマンス向上のためのエミュレータースレッドポリシーについての詳しい情報は、「Configure Emulator Threads to run on a Dedicated Physical CPU」を参照してください。
ネットワークを作成します。
# openstack network create net1 --provider-physical-network tenant --provider-network-type vlan --provider-segment <VLAN-ID>
インスタンスをデプロイします。
# openstack server create --flavor m1.medium_huge_4cpu --availability-zone dpdk --image rhel_7.3 --nic net-id=net1
ここで
-
m1.medium_huge_4cpuはフレーバー名または ID です。 -
dpdkはサーバーのアベイラビリティーゾーンです。 -
rhel_7.3はインスタンスの作成に使用するイメージ (名前または ID) です。 -
net1はサーバー上の NIC です。
-
これで、NFV ユースケースの OVS-DPDK 向けインスタンスのデプロイが完了しました。
multi-queue を OVS-DPDK で使用するには、上記の手順に数ステップを追加する必要があります。フレーバーを作成する前に、以下のステップを実行してください。
イメージのプロパティーを設定します。
# openstack image set --property hw_vif_multiqueue_enabled=true <image-id>
ここで、
hw_vif_multiqueue_enabled=trueはこのイメージ上でマルチキューを有効にするためのプロパティーで、<image-id>は変更するイメージの名前または ID です。フレーバーの追加のプロパティーを設定します。
# openstack flavor set m1.vm_mq set hw:vif_multiqueue_enabled=true
ここで、
m1.vm_mqはフレーバーの ID または名前で、残りのオプションはそのフレーバーのマルチキューを有効化します。
8.8. 設定のトラブルシューティング
本項では、DPDK-OVS 設定のトラブルシューティングの手順を説明します。
ブリッジの設定を見直して、ブリッジが
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 : falseneutron-ovs-agentが自動的に起動するように設定されていることを確認して、OVS サービスをレビューします。# systemctl status neutron-openvswitch-agent.service neutron-openvswitch-agent.service - OpenStack Neutron Open vSwitch Agent Loaded: loaded (/usr/lib/systemd/system/neutron-openvswitch-agent.service; enabled; vendor preset: disabled) Active: active (running) since Mon 2015-11-23 14:49:31 AEST; 25min ago
サービスの起動に問題がある場合には、以下のコマンドを実行して関連のメッセージを表示することができます。
# journalctl -t neutron-openvswitch-agent.service
ovs-dpdkの PMD CPU マスクが CPU にピニングされていることを確認します。HT の場合には、シブリング CPU を使用します。たとえば
CPU4を例に取ります。# cat /sys/devices/system/cpu/cpu4/topology/thread_siblings_list 4,20
CPU 4 と 20 を使用します。
# ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=0x100010
ステータスを表示します。
# tuna -t ovs-vswitchd -CP thread ctxt_switches pid SCHED_ rtpri affinity voluntary nonvoluntary cmd 3161 OTHER 0 6 765023 614 ovs-vswitchd 3219 OTHER 0 6 1 0 handler24 3220 OTHER 0 6 1 0 handler21 3221 OTHER 0 6 1 0 handler22 3222 OTHER 0 6 1 0 handler23 3223 OTHER 0 6 1 0 handler25 3224 OTHER 0 6 1 0 handler26 3225 OTHER 0 6 1 0 handler27 3226 OTHER 0 6 1 0 handler28 3227 OTHER 0 6 2 0 handler31 3228 OTHER 0 6 2 4 handler30 3229 OTHER 0 6 2 5 handler32 3230 OTHER 0 6 953538 431 revalidator29 3231 OTHER 0 6 1424258 976 revalidator33 3232 OTHER 0 6 1424693 836 revalidator34 3233 OTHER 0 6 951678 503 revalidator36 3234 OTHER 0 6 1425128 498 revalidator35 *3235 OTHER 0 4 151123 51 pmd37* *3236 OTHER 0 20 298967 48 pmd38* 3164 OTHER 0 6 47575 0 dpdk_watchdog3 3165 OTHER 0 6 237634 0 vhost_thread1 3166 OTHER 0 6 3665 0 urcu2
第9章 NFV ワークロードに向けた RT-KVM の有効化
本項では、Red Hat OpenStack Platform 向けに Red Hat Enterprise Linux 7.5 Real Time KVM (RT-KVM) をインストールおよび設定する手順を説明します。Red Hat OpenStack Platform は Red Hat Enterprise Linux for Real-Time に加えて、追加の RT-KVM カーネルモジュールおよびコンピュートノードの自動設定をプロビジョニングする新しい Real-Time コンピュートノードロールを使用したリアルタイムの機能を提供します。
9.1. RT-KVM コンピュートノードのプランニング
RT-KVM コンピュートノードには、Red Hat 認定のサーバーを使用する必要があります。詳しくは、Red Hat Enterprise Linux for Real Time 7 certified servers を参照してください。
RT-KVM 用の rhel-7-server-nfv-rpms リポジトリーを有効にする方法については、「アンダークラウドの登録と更新」を参照してください。
このリポジトリーにアクセスできるようにするには、Red Hat OpenStack Platform for Real Time SKU とは別のサブスクリプションが必要となります。
正しいパッケージがインストールされていることを確認できます。
$ yum --disablerepo=beaker-tasks repo-pkgs rhel-7-server-nfv-rpms list Loaded plugins: product-id, search-disabled-repos, subscription-manager Available Packages kernel-rt.x86_64 3.10.0-693.21.1.rt56.639.el7 rhel-7-server-nfv-rpms kernel-rt-debug.x86_64 3.10.0-693.21.1.rt56.639.el7 rhel-7-server-nfv-rpms kernel-rt-debug-devel.x86_64 3.10.0-693.21.1.rt56.639.el7 rhel-7-server-nfv-rpms kernel-rt-debug-kvm.x86_64 3.10.0-693.21.1.rt56.639.el7 rhel-7-server-nfv-rpms kernel-rt-devel.x86_64 3.10.0-693.21.1.rt56.639.el7 rhel-7-server-nfv-rpms kernel-rt-doc.noarch 3.10.0-693.21.1.rt56.639.el7 rhel-7-server-nfv-rpms kernel-rt-kvm.x86_64 3.10.0-693.21.1.rt56.639.el7 rhel-7-server-nfv-rpms [ output omitted…]
real-time のイメージをビルドします。
Real-time コンピュートノードのオーバークラウドイメージをビルドするには、以下のステップを実行します。
アンダークラウドに libguestfs-tools パッケージをインストールして、virt-customize ツールを取得します。
(undercloud) [stack@undercloud-0 ~]$ sudo yum install libguestfs-tools
イメージを抽出します。
(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
- https://access.redhat.com/articles/1556833 に記載の手順に従ってサブスクリプションを設定します。現在必要なのは、NFV のサブスクリプションが 1 つです。
イメージ上で rt を設定するためのスクリプトを作成します (# END OF SCRIPT まで)。
(undercloud) [stack@undercloud-0 ~]$ cat rt.sh #!/bin/bash set -eux yum -v -y --setopt=protected_packages= erase kernel.$(uname -m) yum -v -y install kernel-rt kernel-rt-kvm tuned-profiles-nfv-host # END OF SCRIPT
RT イメージを設定するスクリプトを実行します。
(undercloud) [stack@undercloud-0 ~]$ virt-customize -a overcloud-realtime-compute.qcow2 -v --run rt.sh 2>&1 | tee virt-customize.log
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
注記The software version in the
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 のスリープ状態
- 論理プロセッサー
これらの設定に関する説明と、無効化の影響については、 「Setting BIOS parameters」を参照してください。 BIOS 設定の変更方法に関する詳しい情報は、ハードウェアの製造会社のドキュメントを参照してください。
9.2. RT-KVM 対応の OVS-DPDK の設定
OVS-DPDK 向けの OpenStack ネットワークを最適化するには、network-environment.yaml ファイルで設定する OVS-DPDK パラメーターの最も適切な値を決定する必要があります。詳しくは、「ワークフローを使用した DPDK パラメーターの算出」を参照してください。
9.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. CPU アフィニティー向けの tuned の設定
tunedの設定で CPU アフィニティーを有効にするように設定します。heat_template_version: 2014-10-16 description: > Example extra config for post-deployment parameters: servers: type: json DeployIdentifier: type: string default: '' resources: ExtraDeployments: type: OS::Heat::StructuredDeployments properties: servers: {get_param: servers} config: {get_resource: ExtraConfig} actions: ['CREATE','UPDATE'] input_values: deploy_identifier: {get_param: DeployIdentifier} ExtraConfig: type: OS::Heat::SoftwareConfig properties: group: script config: | #!/bin/bash set -x function tuned_service_dependency() { tuned_service=/usr/lib/systemd/system/tuned.service grep -q "network.target" $tuned_service if [ "$?" -eq 0 ]; then sed -i '/After=.*/s/network.target//g' $tuned_service fi grep -q "Before=.*network.target" $tuned_service if [ ! "$?" -eq 0 ]; then grep -q "Before=.*" $tuned_service if [ "$?" -eq 0 ]; then sed -i 's/^\(Before=.*\)/\1 network.target openvswitch.service/g' $tuned_service else sed -i '/After/i Before=network.target openvswitch.service' $tuned_service fi fi } if hiera -c /etc/puppet/hiera.yaml service_names | grep -q neutron_ovs_dpdk_agent; then tuned_service_dependency fi
9.2.3. 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::ComputeOvsDpdkRT::Net::SoftwareConfig: nic-configs/compute-ovs-dpdk.yaml OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml OS::TripleO::NodeExtraConfigPost: post-install.yaml
parameter_defaults下には、OVS-DPDK および RT-KVM のパラメーターを設定します。# DPDK compute node. ComputeOvsDpdkRTParameters: KernelArgs: default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on 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"
DPDK PMD 向けに DPDK NIC のある場合またはない場合も、各 NUMA ノードで少なくとも 1 CPU を (シブリングスレッドとともに) 割り当てて、ゲストインスタンスの作成でエラーが発生するのを回避する必要があります。
これらのヒュージページは、仮想マシンにより消費されます。また、本手順に示したように OvsDpdkSocketMemory パラメーターを使用すると OVS-DPDK により消費されます。仮想マシンが利用可能なヒュージページ数は、boot パラメーターから OvsDpdkSocketMemory を減算した値です。
DPDK インスタンスに関連付けたフレーバーにも hw:mem_page_size=1GB を追加する必要があります。
OvsDPDKCoreList と OvsDpdkMemoryChannels は、この手順の 必須 の設定です。適切な値なしに DPDK をデプロイしようとすると、デプロイが失敗するか、デプロイが不安定になる可能性があります。
9.2.4. コンテナーイメージの準備
コンテナーイメージを準備します。
(undercloud) [stack@undercloud-0 ~]$ openstack overcloud container image prepare --namespace=192.0.40.1:8787/rhosp13 --env-file=/home/stack/ospd-13-vlan-dpdk/docker-images.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/docker.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/docker-ha.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-ovs-dpdk.yaml -e /home/stack/ospd-13-vlan-dpdk/network-environment.yaml --roles-file /home/stack/ospd-13-vlan-dpdk/roles_data.yaml --prefix=openstack- --tag=2018-03-29.1 --set ceph_namespace=registry.access.redhat.com/rhceph --set ceph_image=rhceph-3-rhel7 --set ceph_tag=latest
9.2.5. オーバークラウドのデプロイ
ML2-OVS 向けのオーバークラウドをデプロイします。
(undercloud) [stack@undercloud-0 ~]$ openstack overcloud deploy \ --templates \ -r /home/stack/ospd-13-vlan-dpdk-ctlplane-bonding-rt/roles_data.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/host-config-and-reboot.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-ovs-dpdk.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ovs-dpdk-permissions.yaml \ -e /home/stack/ospd-13-vxlan-dpdk-data-bonding-rt-hybrid/docker-images.yaml \ -e /home/stack/ospd-13-vxlan-dpdk-data-bonding-rt-hybrid/network-environment.yaml
9.3. 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>
第10章 例: ODL および VXLAN トンネリングを使用する OVS-DPDK の設定
本項では、OVS-DPDK with ODL および VXLAN トンネリングを使用した OVS-DPDK 設定の例について説明します。
OVS-DPDK 向けの OpenStack ネットワークを最適化するには、network-environment.yaml ファイルで設定する OVS-DPDK パラメーターの最も適切な値を決定する必要があります。詳しくは、「ワークフローを使用した DPDK パラメーターの算出」を参照してください。
10.1. ComputeOvsDpdk コンポーザブルロールの生成
ComputeOvsDpdk ロール用の roles_data.yaml を生成します。
# openstack overcloud roles generate --roles-path templates/openstack-tripleo-heat-templates/roles -o roles_data.yaml Controller ComputeOvsDpdk
10.2. CPU アフィニティー向けの tuned の設定
tunedの設定で CPU アフィニティーを有効にするように設定します。heat_template_version: 2014-10-16 description: > Example extra config for post-deployment parameters: servers: type: json DeployIdentifier: type: string default: '' resources: ExtraDeployments: type: OS::Heat::StructuredDeployments properties: servers: {get_param: servers} config: {get_resource: ExtraConfig} actions: ['CREATE','UPDATE'] input_values: deploy_identifier: {get_param: DeployIdentifier} ExtraConfig: type: OS::Heat::SoftwareConfig properties: group: script config: | #!/bin/bash set -x function tuned_service_dependency() { tuned_service=/usr/lib/systemd/system/tuned.service grep -q "network.target" $tuned_service if [ "$?" -eq 0 ]; then sed -i '/After=.*/s/network.target//g' $tuned_service fi grep -q "Before=.*network.target" $tuned_service if [ ! "$?" -eq 0 ]; then grep -q "Before=.*" $tuned_service if [ "$?" -eq 0 ]; then sed -i 's/^\(Before=.*\)/\1 network.target openvswitch.service/g' $tuned_service else sed -i '/After/i Before=network.target openvswitch.service' $tuned_service fi fi } if hiera -c /etc/puppet/hiera.yaml service_names | grep -q neutron_ovs_dpdk_agent; then tuned_service_dependency fi
10.3. 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::ComputeOvsDpdk::Net::SoftwareConfig: nic-configs/computeovsdpdk.yaml OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml OS::TripleO::NodeExtraConfigPost: post-install.yamlparameter_defaults下には、トンネルの種別とテナントの種別をvxlanに設定します。NeutronTunnelTypes: 'vxlan' NeutronNetworkType: 'vxlan'
parameters_defaults下には、ブリッジマッピングを設定します。# The OVS logical->physical bridge mappings to use. NeutronBridgeMappings: 'tenant:br-link0' OpenDaylightProviderMappings: 'tenant:br-link0'
parameter_defaults下には、ComputeOvsDpdkロール向けにロール固有のパラメーターを設定します。########################## # OVS DPDK configuration # ########################## ComputeOvsDpdkParameters: 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: "4096,4096" OvsDpdkMemoryChannels: "4" OvsDpdkCoreList: "0,20,1,21" OvsPmdCoreList: "2,22,3,23" OvsEnableDpdk: true注記DPDK PMD 向けに DPDK NIC のある場合またはない場合も、各 NUMA ノードで少なくとも 1 CPU を (シブリングスレッドとともに) 割り当てて、ゲストインスタンスの作成でエラーが発生するのを回避する必要があります。
注記これらのヒュージページは、仮想マシンにより消費されます。また、本手順に示したように
OvsDpdkSocketMemoryパラメーターを使用すると OVS-DPDK により消費されます。仮想マシンが利用可能なヒュージページ数は、bootパラメーターからOvsDpdkSocketMemoryを減算した値です。DPDK インスタンスに関連付けたフレーバーにも
hw:mem_page_size=1GBを追加する必要があります。注記OvsDPDKCoreListとOvsDpdkMemoryChannelsは、この手順の 必須 の設定です。適切な値なしに DPDK をデプロイしようとすると、デプロイが失敗するか、デプロイが不安定になる可能性があります。
10.4. コントローラーノードの設定
分離ネットワーク用にコントロールプレーンの Linux ボンディングを作成します。
- type: linux_bond name: bond_api bonding_options: "mode=active-backup" use_dhcp: false dns_servers: get_param: DnsServers addresses: - ip_netmask: list_join: - / - - get_param: ControlPlaneIp - get_param: ControlPlaneSubnetCidr routes: - ip_netmask: 169.254.169.254/32 next_hop: get_param: EC2MetadataIp members: - type: interface name: eth1 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クラウドネットワークへの接続を可能にする Floating IP にアクセスするための OVS ブリッジを作成します。
- type: ovs_bridge name: br-link0 use_dhcp: false mtu: 9000 members: - type: interface name: eth2 mtu: 9000 - type: vlan vlan_id: get_param: TenantNetworkVlanID mtu: 9000 addresses: - ip_netmask: get_param: TenantIpSubnet
10.5. DPDK インターフェース用のコンピュートノードの設定
デフォルトの compute.yaml ファイルから compute-ovs-dpdk.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: nic7 primary: true - type: interface name: nic8この 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: nic3 - type: ovs_dpdk_port name: dpdk1 members: - type: interface name: nic4注記複数の DPDK デバイスが含まれるようにするには、追加する各 DPDK デバイスごとに
typeコードセクションを繰り返してください。注記OVS-DPDK を使用する場合には、同じコンピュートノード上の すべて のブリッジが
ovs_user_bridgeの種別である必要があります。director は設定を受け入れることができますが、Red Hat OpenStack Platform は同じノード上でovs_bridgeとovs_user_bridgeが混在する構成はサポートしていません。
10.6. オーバークラウドのデプロイ
overcloud_deploy.sh スクリプトを実行してオーバークラウドをデプロイします。
#!/bin/bash openstack overcloud deploy \ --templates \ -r /home/stack/ospd-13-vxlan-dpdk-odl-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/services-docker/neutron-opendaylight.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight-dpdk.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ovs-dpdk-permissions.yaml \ -e /home/stack/ospd-13-vxlan-dpdk-odl-ctlplane-dataplane-bonding-hybrid/docker-images.yaml \ -e /home/stack/ospd-13-vxlan-dpdk-odl-ctlplane-dataplane-bonding-hybrid/network-environment.yaml
第11章 NFV を実装した Red Hat OpenStack Platform のアップグレード
OVS-DPDK を設定している場合には、Red Hat OpenStack Platform のアップグレードで追加の考慮事項とステップが必要です。このステップについては、「NFV を設定したオーバークラウドの準備」で説明しています。
第12章 パフォーマンス
Red Hat OpenStack Platform director は、コンピュートノードがリソースの分割および微調整を有効にしてゲスト VNF のラインレートパフォーマンスを実現できるように設定します。NFV ユースケースの中での主要なパフォーマンス要素は、スループット、レイテンシー、ジッターです。
DPDK-accelerated OVS は、物理 NIC と仮想マシンの間で高性能のパケット切り替えを有効にします。OVS 2.7 は、DPDK 16.11 に対応しており、vhost-user のマルチキューをサポートしているので、スケーラブルなパフォーマンスを実現できます。OVS-DPDK は、ゲスト VNF のラインレートパフォーマンスを提供します。
SR-IOV ネットワークでは、固有なネットワークや仮想マシンのスループットの向上など、強化されたパフォーマンス特性が提供されます。
パフォーマンスチューニングの他の重要な機能には、ヒュージページ、NUMA 調整、ホストの分離、CPU ピニングなどが挙げられます。VNF フレーバーには、パフォーマンス向上のためにヒュージページとエミュレータースレッドの分離が必要です。ホストの分離や CPU ピニングにより、NFV パフォーマンスが向上され、擬似パケットロスが回避されます。
CPU と NUMA トポロジーに関する概要は、「NFV のパフォーマンスの考慮事項」 および 「Configure Emulator Threads to run on a Dedicated Physical CPU」を参照してください。
第13章 その他の参考資料
以下の表には、その他の参考となる Red Hat のドキュメントの一覧を記載しています。
Red Hat OpenStack Platform のドキュメントスイートは Red Hat OpenStack Platform の製品ドキュメントスイート から参照してください。
表13.1 参考資料一覧
| コンポーネント | 参考情報 |
|---|---|
|
Red Hat Enterprise Linux |
Red Hat OpenStack Platform は Red Hat Enterprise Linux 7.5 でサポートされています。Red Hat Enterprise Linux のインストールに関する情報は、Red Hat Enterprise Linux のドキュメント から対応するインストールガイドを参照してください。 |
|
Red Hat OpenStack Platform |
OpenStack のコンポーネントとそれらの依存関係をインストールするには、Red Hat OpenStack Platform director を使用します。director は、基本的な OpenStack 環境をアンダークラウドとして使用して、最終的な オーバークラウド 内の OpenStack ノードをインストール、設定、管理します。デプロイしたオーバークラウドに必要な環境に加えて、アンダークラウドをインストールするための追加のホストマシンが 1 台必要となる点に注意してください。詳しい手順は、 『Red Hat OpenStack Platform director のインストールと使用方法』を参照してください。 Red Hat OpenStack Platform director を使用して、ネットワークの分離、ストレージ設定、SSL 通信、一般的な設定方法など Red Hat OpenStack Platform のエンタープライズ環境の高度な機能設定に関する情報は『オーバークラウドの高度なカスタマイズ』を参照してください。 |
|
NFV のドキュメント |
NFV の概念に関する俯瞰的な情報は、『ネットワーク機能仮想化 (NFV) の製品ガイド』を参照してください。 |
付録A ODL DPDK YAML ファイルのサンプル
本項では、参考として ODL DPDK YAML ファイルのサンプルを紹介します。
A.1. VXLAN DPDK ODL YAML ファイルのサンプル
A.1.1. post-install.yaml
heat_template_version: 2014-10-16
description: >
Example extra config for post-deployment
parameters:
servers:
type: json
DeployIdentifier:
type: string
default: ''
resources:
ExtraDeployments:
type: OS::Heat::StructuredDeployments
properties:
servers: {get_param: servers}
config: {get_resource: ExtraConfig}
actions: ['CREATE','UPDATE']
input_values:
deploy_identifier: {get_param: DeployIdentifier}
ExtraConfig:
type: OS::Heat::SoftwareConfig
properties:
group: script
config: |
#!/bin/bash
set -x
function tuned_service_dependency() {
tuned_service=/usr/lib/systemd/system/tuned.service
grep -q "network.target" $tuned_service
if [ "$?" -eq 0 ]; then
sed -i '/After=.*/s/network.target//g' $tuned_service
fi
grep -q "Before=.*network.target" $tuned_service
if [ ! "$?" -eq 0 ]; then
grep -q "Before=.*" $tuned_service
if [ "$?" -eq 0 ]; then
sed -i 's/^\(Before=.*\)/\1 network.target openvswitch.service/g' $tuned_service
else
sed -i '/After/i Before=network.target openvswitch.service' $tuned_service
fi
fi
}
if hiera -c /etc/puppet/hiera.yaml service_names | grep -q neutron_ovs_dpdk_agent; then
tuned_service_dependency
fiA.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::ComputeOvsDpdk::Net::SoftwareConfig: nic-configs/computeovsdpdk.yaml
OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml
OS::TripleO::NodeExtraConfigPost: post-install.yaml
parameter_defaults:
# Customize all these values to match the local environment
InternalApiNetCidr: 10.10.131.0/24
TenantNetCidr: 10.10.132.0/24
StorageNetCidr: 10.10.133.0/24
StorageMgmtNetCidr: 10.10.134.0/24
ExternalNetCidr: 10.35.185.64/28
# CIDR subnet mask length for provisioning network
ControlPlaneSubnetCidr: '24'
InternalApiAllocationPools: [{'start': '10.10.131.100', 'end': '10.10.131.200'}]
TenantAllocationPools: [{'start': '10.10.132.100', 'end': '10.10.132.200'}]
StorageAllocationPools: [{'start': '10.10.133.100', 'end': '10.10.133.200'}]
StorageMgmtAllocationPools: [{'start': '10.10.134.100', 'end': '10.10.134.200'}]
# Use an External allocation pool which will leave room for floating IPs
ExternalAllocationPools: [{'start': '10.35.185.65', 'end': '10.35.185.77'}]
# Set to the router gateway on the external network
ExternalInterfaceDefaultRoute: 10.35.185.78
# Gateway router for the provisioning network (or Undercloud IP)
ControlPlaneDefaultRoute: 192.0.90.1
# Generally the IP of the Undercloud
EC2MetadataIp: 192.0.90.1
InternalApiNetworkVlanID: 531
TenantNetworkVlanID: 532
StorageNetworkVlanID: 533
StorageMgmtNetworkVlanID: 534
ExternalNetworkVlanID: 422
# Define the DNS servers (maximum 2) for the overcloud nodes
DnsServers: ["10.35.28.1","10.35.28.28"]
# 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'
# The OVS logical->physical bridge mappings to use.
NeutronBridgeMappings: 'tenant:br-link0'
OpenDaylightProviderMappings: 'tenant:br-link0'
# The Neutron ML2 and OpenVSwitch vlan mapping range to support.
NeutronNetworkVLANRanges: 'tenant:423:423,tenant:535:537'
# Nova flavor to use.
OvercloudControllerFlavor: controller
OvercloudComputeOvsDpdkFlavor: computeovsdpdk
# Number of nodes to deploy.
ControllerCount: 3
ComputeOvsDpdkCount: 2
# NTP server configuration.
NtpServer: clock.redhat.com
##########################
# OVS DPDK configuration #
##########################
ComputeOvsDpdkParameters:
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: "4096,4096"
OvsDpdkMemoryChannels: "4"
OvsDpdkCoreList: "0,20,1,21"
OvsPmdCoreList: "2,22,3,23"
OvsEnableDpdk: true
# MTU global configuration
NeutronGlobalPhysnetMtu: 9000
# Configure the classname of the firewall driver to use for implementing security groups.
SshServerOptions:
UseDns: 'no'A.1.3. controller.yaml
heat_template_version: queens
description: >
Software Config to drive os-net-config to configure VLANs for the
controller role.
parameters:
ControlPlaneIp:
default: ''
description: IP address/subnet on the ctlplane network
type: string
ExternalIpSubnet:
default: ''
description: IP address/subnet on the external network
type: string
InternalApiIpSubnet:
default: ''
description: IP address/subnet on the internal API network
type: string
StorageNetworkVlanID:
default: 30
description: Vlan ID for the storage network traffic.
type: number
StorageMgmtNetworkVlanID:
default: 40
description: Vlan ID for the storage mgmt network traffic.
type: number
StorageIpSubnet:
default: ''
description: IP address/subnet on the storage network
type: string
StorageMgmtIpSubnet:
default: ''
description: IP address/subnet on the storage mgmt network
type: string
TenantIpSubnet:
default: ''
description: IP address/subnet on the tenant network
type: string
ManagementIpSubnet: # Only populated when including environments/network-management.yaml
default: ''
description: IP address/subnet on the management network
type: string
ExternalNetworkVlanID:
default: ''
description: Vlan ID for the external network traffic.
type: number
InternalApiNetworkVlanID:
default: ''
description: Vlan ID for the internal_api network traffic.
type: number
TenantNetworkVlanID:
default: ''
description: Vlan ID for the tenant network traffic.
type: number
ManagementNetworkVlanID:
default: 23
description: Vlan ID for the management network traffic.
type: number
ExternalInterfaceDefaultRoute:
default: ''
description: default route for the external network
type: string
ControlPlaneSubnetCidr: # Override this via parameter_defaults
default: '24'
description: The subnet CIDR of the control plane network.
type: string
ControlPlaneDefaultRoute: # Override this via parameter_defaults
description: The default route of the control plane network.
type: string
DnsServers: # Override this via parameter_defaults
default: []
description: A list of DNS servers (2 max for some implementations) that will be added to resolv.conf.
type: comma_delimited_list
EC2MetadataIp: # Override this via parameter_defaults
description: The IP address of the EC2 metadata server.
type: string
resources:
OsNetConfigImpl:
type: OS::Heat::SoftwareConfig
properties:
group: script
config:
str_replace:
template:
get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
params:
$network_config:
network_config:
-
type: interface
name: eth0
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
addresses:
- ip_netmask:
list_join:
- /
- - get_param: ControlPlaneIp
- get_param: ControlPlaneSubnetCidr
routes:
- ip_netmask: 169.254.169.254/32
next_hop:
get_param: EC2MetadataIp
members:
- type: interface
name: eth1
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: eth2
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: OsNetConfigImplA.1.4. compute-ovs-dpdk.yaml
heat_template_version: queens
description: >
Software Config to drive os-net-config to configure VLANs for the
compute role.
parameters:
ControlPlaneIp:
default: ''
description: IP address/subnet on the ctlplane network
type: string
ExternalIpSubnet:
default: ''
description: IP address/subnet on the external network
type: string
InternalApiIpSubnet:
default: ''
description: IP address/subnet on the internal API network
type: string
TenantIpSubnet:
default: ''
description: IP address/subnet on the tenant network
type: string
ManagementIpSubnet: # Only populated when including environments/network-management.yaml
default: ''
description: IP address/subnet on the management network
type: string
InternalApiNetworkVlanID:
default: ''
description: Vlan ID for the internal_api network traffic.
type: number
StorageNetworkVlanID:
default: 30
description: Vlan ID for the storage network traffic.
type: number
StorageMgmtNetworkVlanID:
default: 40
description: Vlan ID for the storage mgmt network traffic.
type: number
TenantNetworkVlanID:
default: ''
description: Vlan ID for the tenant network traffic.
type: number
ManagementNetworkVlanID:
default: 23
description: Vlan ID for the management network traffic.
type: number
StorageIpSubnet:
default: ''
description: IP address/subnet on the storage network
type: string
StorageMgmtIpSubnet:
default: ''
description: IP address/subnet on the storage mgmt network
type: string
ControlPlaneSubnetCidr: # Override this via parameter_defaults
default: '24'
description: The subnet CIDR of the control plane network.
type: string
ControlPlaneDefaultRoute: # Override this via parameter_defaults
description: The default route of the control plane network.
type: string
DnsServers: # Override this via parameter_defaults
default: []
description: A list of DNS servers (2 max for some implementations) that will be added to resolv.conf.
type: comma_delimited_list
EC2MetadataIp: # Override this via parameter_defaults
description: The IP address of the EC2 metadata server.
type: string
ExternalInterfaceDefaultRoute:
default: ''
description: default route for the external network
type: string
resources:
OsNetConfigImpl:
type: OS::Heat::SoftwareConfig
properties:
group: script
config:
str_replace:
template:
get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
params:
$network_config:
network_config:
- type: interface
name: nic1
use_dhcp: false
defroute: false
- type: interface
name: nic2
use_dhcp: false
addresses:
- ip_netmask:
list_join:
- /
- - get_param: ControlPlaneIp
- get_param: ControlPlaneSubnetCidr
routes:
- ip_netmask: 169.254.169.254/32
next_hop:
get_param: EC2MetadataIp
- default: true
next_hop:
get_param: ControlPlaneDefaultRoute
- type: linux_bond
name: bond_api
bonding_options: "mode=active-backup"
use_dhcp: false
dns_servers:
get_param: DnsServers
members:
- type: interface
name: nic7
primary: true
- type: interface
name: nic8
- 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: nic3
- type: ovs_dpdk_port
name: dpdk1
members:
- type: interface
name: nic4
outputs:
OS::stack_id:
description: The OsNetConfigImpl resource.
value:
get_resource: OsNetConfigImplA.1.5. overcloud_deploy.sh
#!/bin/bash openstack overcloud deploy \ --templates \ -r /home/stack/ospd-13-vxlan-dpdk-odl-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/services-docker/neutron-opendaylight.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-opendaylight-dpdk.yaml \ -e /usr/share/openstack-tripleo-heat-templates/environments/ovs-dpdk-permissions.yaml \ -e /home/stack/ospd-13-vxlan-dpdk-odl-ctlplane-dataplane-bonding-hybrid/docker-images.yaml \ -e /home/stack/ospd-13-vxlan-dpdk-odl-ctlplane-dataplane-bonding-hybrid/network-environment.yaml \ --log-file overcloud_install.log &> overcloud_install.log
付録B 改訂履歴
| 改訂履歴 | ||
|---|---|---|
| 改訂 1.4-0 | August 23 2018 | |
| Fixed parameter alignment for step 4 of `Configuring SR-IOV with OVS Hardware Offload with VLAN`. | ||
| 改訂 1.3-0 | August 20 2018 | |
| Added note about SKU requirement for RT-KVM repository. | ||
| 改訂 1.2-0 | July 31 2018 | |
| Updated network creation steps to use OSC parameters. Added description of BIOS settings. | ||
| 改訂 1.1-0 | July 12 2018 | |
| DPDK ODL yaml ファイルのサンプルと手順を追加 | ||
| 改訂 1.0-0 | June 27 2018 | |
| Red Hat OpenStack 13 GA リリースの初期バージョン。RT-KVM および OVS HW オフロードの手順を記載しています。ovs 2.9 をサポートします。 | ||
