Red Hat OpenStack Platform 10 では、director を使用して SR-IOV および OVS-DPDK インストールの NFV デプロイメントがサポートされます。Red Hat OpenStack Platform 10 director で利用可能なコンポーザブルロール機能を使用して、カスタムのデプロイメントロールを作成できます。今回のリリースではサポートが制限されていますが、ハイパーコンバージドインフラストラクチャー (HCI) が提供されており、分散型の NFV 向けにコンピュートノードと Red Hat Ceph Storage ノードを同じ場所に配置することができます。HCI のパフォーマンスを向上させるために、CPU ピニングが使用されます。HCI モデルでは、NFV のユースケースにおいてより効率的な管理を行うことができます。また、今回のリリースでは、テクノロジープレビュー機能として OpenDaylight および Real-Time KVM が提供されています。OpenDaylight とは、Software-Defined Network (SDN) デプロイメントに向けた、オープンソースのモジュール型マルチプロトコルコントローラーです。テクノロジープレビューと記した機能のサポート範囲についての詳細は、「テクノロジープレビュー機能のサポート範囲」を参照してください。

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

ネットワークアダプターの完全な一覧については、「Network Adapter Feature Support in Red Hat Enterprise Linux」を参照してください。

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

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

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

「The Red Hat Ecosystem」を使用し、カテゴリーを選んでから製品バージョンを選択して、認定済みハードウェア、ソフトウェア、クラウドプロバイダー、コンポーネントの一覧を確認することができます。

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

NFV 向けのテスト済み NIC の一覧は、「Network Adapter Fast Datapath Feature Support Matrix」を参照してください。(カスタマーポータルのログインが必要です)

デプロイメントを計画する際には、最高のパフォーマンスが得られるように、コンピュートノードの NUMA トポロジーを理解して CPU およびメモリーのリソースを分割する必要があります。NUMA 情報を把握するには、ハードウェアイントロスペクションを有効にして、ベアメタルノードからこの情報を取得することができます。

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

この情報を取得するには、ベアメタルノードの 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
    }
  ]
}

以下のリストには、NFV に必要な BIOS 設定を記載します。

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

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

以下の図には、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 ノードで構成されます。

5.2.2. HCI を使用する NFV SR-IOV

以下の図には、NFV ユースケース向けの HCI を使用する SR-IOV のトポロジーを示しています。この環境は、1 または 10 Gbps の NIC を搭載したコンピュート OSD ノード (HCI を使用) およびコントローラーノード、ならびに director ノードで構成されます。

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

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

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

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

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

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

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

OvsDpdkSocketMemory: “1024,1024”

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

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

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

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

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

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

以下に示す理由により、3.5 mpps を超える高いパケットレートではパケット喪失が生じる場合があります。

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

前提条件

手順

テスト

RHOSP 10 メンテナンスリリース RHSA-2018:2102 以降、DPDK vHost ユーザーポートは 必ず dpdkvhostuserclient モードで作成され、この動作を変更するオプションはありません。既存のインスタンスに対する dpdkvhostuser モードの使用は引き続きサポートされますが、dpdkvhostuserclient モードに移行することを推奨します。

オーバークラウドを OVS 2.9 に更新した後に、既存のインスタンスを別のホストにコールドマイグレーションし、インスタンスで新しい dpdkvhostuserclient モードに変更します。

openstack server migrate <server_id>
openstack server resize --confirm <server id>

インスタンスの vHost ユーザーポートが dpdkvhostuserclient モードに設定されていることを確認することができます。インスタンスが存在するハイパーバイザーノードを特定してログインします。

以下のコマンドを実行します。

compute-0# virsh dumpxml <instance name> | less

種別が vhostuser のインターフェースを特定し、モードがサーバーに設定されていることを確認します。

...
<interface type='vhostuser'>
<model type='virtio'/>
<source type='unix' path='<path-to-socket>' mode='<client|server>'/>
</interface>
...