Menu Close
Settings Close

Language and Page Formatting Options

Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

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

Red Hat OpenStack Platform 10

Red Hat OpenStack Platform 10 での NFV のプランニング

OpenStack Documentation Team

概要

本ガイドは、Red Hat OpenStack Platform 10 への NFV の実装をプランニングする際に役立ちます。また、本書には、NFV 対応の Red Hat OpenStack Platform 10 を正しく設定、インストールできるようにするための情報が含まれます。

第1章 はじめに

ネットワーク機能仮想化 (NFV: Network Functions Virtualization) とは、通信事業者 (CSP) が従来のプロプライエタリーハードウェアの範囲を超えて、運用コストを抑えつつ、効率性および俊敏性を向上させる上で役立つソフトウェアベースのソリューションのことです。

NFV の概念に関する俯瞰的な情報は、『ネットワーク機能仮想化 (NFV) の製品ガイド』を参照してください。

Red Hat OpenStack Platform 10 director での SR-IOV および OVS-DPDK 設定に関する情報は、『ネットワーク機能仮想化 (NFV) の設定ガイド』を参照してください。

第2章 ソフトウェア要件

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

2.1. NFV デプロイメントでサポートされている構成

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) デプロイメントに向けた、オープンソースのモジュール型マルチプロトコルコントローラーです。テクノロジープレビューと記した機能のサポート範囲についての詳細は、「テクノロジープレビュー機能のサポート範囲」を参照してください。

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

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

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

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

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

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

2.4. サブスクリプションの基本情報

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

手順

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

    subscription-manager repos --disable=*
  2. Red Hat OpenStack Platform で NFV を使用するのに必要なリポジトリーを有効にします。

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

オーバークラウドノードを登録するには、「オーバークラウドの登録」を参照してください。

第3章 ハードウェア

本章では、認定ハードウェア、ハードウェア機能、トポロジー等、NFV に必要なハードウェアの詳細情報について説明します。

3.1. 認定ハードウェア

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

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

3.2. テスト済み NIC

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

3.3. ハードウェアイントロスペクションによる NUMA ノードトポロジーの把握

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

注記

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

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

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

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

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

この情報を取得するには、ベアメタルノードの UUID を指定して、openstack baremetal introspection data save _UUID_ | jq .numa_topology コマンドを実行します。

取得されるベアメタルノードの NUMA 情報の例を以下に示します。

{
  "cpus": [
    {
      "cpu": 1,
      "thread_siblings": [
        1,
        17
      ],
      "numa_node": 0
    },
    {
      "cpu": 2,
      "thread_siblings": [
        10,
        26
      ],
      "numa_node": 1
    },
    {
      "cpu": 0,
      "thread_siblings": [
        0,
        16
      ],
      "numa_node": 0
    },
    {
      "cpu": 5,
      "thread_siblings": [
        13,
        29
      ],
      "numa_node": 1
    },
    {
      "cpu": 7,
      "thread_siblings": [
        15,
        31
      ],
      "numa_node": 1
    },
    {
      "cpu": 7,
      "thread_siblings": [
        7,
        23
      ],
      "numa_node": 0
    },
    {
      "cpu": 1,
      "thread_siblings": [
        9,
        25
      ],
      "numa_node": 1
    },
    {
      "cpu": 6,
      "thread_siblings": [
        6,
        22
      ],
      "numa_node": 0
    },
    {
      "cpu": 3,
      "thread_siblings": [
        11,
        27
      ],
      "numa_node": 1
    },
    {
      "cpu": 5,
      "thread_siblings": [
        5,
        21
      ],
      "numa_node": 0
    },
    {
      "cpu": 4,
      "thread_siblings": [
        12,
        28
      ],
      "numa_node": 1
    },
    {
      "cpu": 4,
      "thread_siblings": [
        4,
        20
      ],
      "numa_node": 0
    },
    {
      "cpu": 0,
      "thread_siblings": [
        8,
        24
      ],
      "numa_node": 1
    },
    {
      "cpu": 6,
      "thread_siblings": [
        14,
        30
      ],
      "numa_node": 1
    },
    {
      "cpu": 3,
      "thread_siblings": [
        3,
        19
      ],
      "numa_node": 0
    },
    {
      "cpu": 2,
      "thread_siblings": [
        2,
        18
      ],
      "numa_node": 0
    }
  ],
  "ram": [
    {
      "size_kb": 66980172,
      "numa_node": 0
    },
    {
      "size_kb": 67108864,
      "numa_node": 1
    }
  ],
  "nics": [
    {
      "name": "ens3f1",
      "numa_node": 1
    },
    {
      "name": "ens3f0",
      "numa_node": 1
    },
    {
      "name": "ens2f0",
      "numa_node": 0
    },
    {
      "name": "ens2f1",
      "numa_node": 0
    },
    {
      "name": "ens1f1",
      "numa_node": 0
    },
    {
      "name": "ens1f0",
      "numa_node": 0
    },
    {
      "name": "eno4",
      "numa_node": 0
    },
    {
      "name": "eno1",
      "numa_node": 0
    },
    {
      "name": "eno3",
      "numa_node": 0
    },
    {
      "name": "eno2",
      "numa_node": 0
    }
  ]
}

3.4. BIOS 設定の確認

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

  • C3 Power State: Disabled
  • C6 Power State: Disabled
  • MLC Streamer: Enabled
  • MLC Spacial Prefetcher: Enabled
  • DCU Data Prefetcher: Enabled
  • DCA: Enabled
  • CPU Power and Performance: Performance
  • Memory RAS and Performance Config → NUMA Optimized: Enabled
  • Turbo Boost: Disabled

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

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

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

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

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

プロビジョニングネットワークは、ネイティブ VLAN だけ を使用します。

NFV SR-IOV トポロジーと Ceph (HCI) を組み合わせたオーバークラウドのネットワーク構成 (「HCI を使用する NFV SR-IOV」を参照) には、以下の要素が含まれます。

  • 3 x 1 G ポート: director およびプロビジョニング OVS 用 (SR-IOV の場合は分離)
  • 6 x 10 G ポートおよび 2 x 10 G ポート: Ceph および DPDK SR-IOV 用
注記

Red Hat OpenStack Platform 10 では、Ceph HCI はテクノロジープレビュー機能です。テクノロジープレビューと記した機能のサポート範囲についての詳細は、「テクノロジープレビュー機能のサポート範囲」を参照してください。

ネットワーク要件の詳しい情報は、「ネットワーク要件」を参照してください。

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

NFV 向けの SR-IOV デプロイメントを最適化するには、コンピュートノードのハードウェアに応じて個別の OVS-DPDK パラメーターを設定する方法を理解する必要があります。

SR-IOV パラメーターに対するハードウェアの影響を評価するには、「ハードウェアイントロスペクションによる NUMA ノードトポロジーの把握」を参照してください。

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

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

OpenStack NFV Hardware Capacities 464931 0118 SR IOV

標準的なトポロジーでは、デュアルコアソケットのコンピュートノード上の NUMA ノードにはそれぞれ 14 のコアが実装されます。HT (ハイパースレッド) および非 HT のコアがサポートされています。各コアには 2 つのシブリングスレッドがあります。1 つのコアは、各 NUMA ノード上のホスト専用です。VNF は SR-IOV インターフェースのボンディングを処理します。すべての割り込み要求 (IRQ) はホストのコア上でルーティングされます。VNF コアは VNF 専用です。これらのコアは、他の VNF からの分離と、ホストからの分離を提供します。各 VNF は単一の NUMA ノードに適合し、ローカルの SR-IOV NIC を使用する必要があります。このトポロジーでは、仮想化のオーバーヘッドはありません。ホスト、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 管理の間で共有されています。

NFV SR-IOV deployment

この図は、アプリケーションレベルで 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 ノードで構成されます。

NFV SR-IOV Topology without HCI

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

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

NFV SR-IOV Topology with HCI

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

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

CPU と NUMA トポロジーの概要は、「NFV Performance Considerations」を参照してください。

6.1. OVS-DPDK が CPU 分割と NUMA トポロジーを使用する仕組み

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

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

OpenStack NFV NUMA 9 0219
注記

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

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

6.2. OVS-DPDK パラメーターの概要

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

注記

論理 CPU を特定のタスクに割り当てる際には、シブリングスレッドをペアにして割り当ててください。

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

6.2.1. CPU パラメーター

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

NeutronDpdkCoreList

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

  • シブリングスレッドをペアにします。
  • HostCpusList のコアをすべて除外します。
  • 両方の NUMA ノード上の 1 番目の物理コアの論理 CPU (両方のスレッドシブリング) が割り当てられないようにしてください。これらは、HostCpusList パラメーターに使用する必要があります。
  • パフォーマンスは、この 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 ピニング用のコアを設定します。コンピュートノードは、ゲストインスタンスにこれらのコアを使用します。NovaVcpuPinSetnova.conf ファイルの vcpu_pin_set 値として使用されます。

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

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

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

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

  • 各 NUMA ノードから、1 番目の物理コア (およびシブリングスレッド) を割り当てます (NUMA に関連付けられている DPDK 用の NIC がない場合も)。
  • これらのコアは、NeutronDpdkCoreList および NovaVcpuPinSet のコアの一覧と相互に排他的である必要があります。

6.2.2. メモリーパラメーター

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

NovaReservedHostMemory

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

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

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

  • コンマ区切りリストで指定します。NeutronDpdkSocketMemory の値は、NUMA ノード上の各 DPDK NIC の MTU 値から計算されます。
  • それぞれの MTU 値を 1024 バイトの倍数に丸めます (ROUNDUP_PER_MTU)。
  • DPDK NIC のない NUMA ノードの場合は、推奨される静的な値である 1024 MB (1 GB) を使用します。
  • NeutronDpdkSocketMemory の値は、以下の式で概算します。

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

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

計算例: MTU 2000 および MTU 9000

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

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

    The MTU value of 9000 becomes 9216 bytes.
    The MTU value of 2000 becomes 2048 bytes.
  2. それらの丸めたバイト値に基づいて、各 MTU 値に必要なメモリーを計算します。

    Memory required for 9000 MTU = (9216 + 800) * (4096*64) = 2625634304
    Memory required for 2000 MTU = (2048 + 800) * (4096*64) = 746586112
  3. それらを合わせた必要なメモリーの合計を計算します (バイト単位)。

    2625634304 + 746586112 + 536870912 = 3909091328 bytes.

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

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

    3909091328 / (1024*1024) = 3728 MB.
  5. この値を 1024 の倍数に丸めます。

    3724 MB rounds up to 4096 MB.
  6. この値を使用して NeutronDpdkSocketMemory を設定します。

        NeutronDpdkSocketMemory: “4096,1024”

サンプルの計算: MTU 2000

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

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

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

    Memory required for 2000 MTU = (2048 + 800) * (4096*64) = 746586112
  3. それらを合わせた必要なメモリーの合計を計算します (バイト単位)。

    746586112 + 536870912 = 1283457024 bytes.

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

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

    1283457024 / (1024*1024) = 1224 MB.
  5. この値を 1024 の倍数に丸めます。

    1224 MB rounds up to 2048 MB.
  6. この値を使用して NeutronDpdkSocketMemory を設定します。

        NeutronDpdkSocketMemory: “2048,1024”

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

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

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

NovaSchedulerDefaultFilters
要求されたゲストインスタンスに対してコンピュートノードが使用するフィルターの順序付きリストを指定します。
ComputeKernelArgs

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

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

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

6.3. 2 NUMA ノード構成の OVS-DPDK デプロイメントの例

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

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

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

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

OvsDpdkSocketMemory: “1024,1024”

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

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

NeutronDpdkCoreList: “'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 つも割り当てる必要があります。残りのコア (HostCpusList 用に確保されていないコア) はゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。

NeutronDpdkCoreList: “'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 つも割り当てる必要があります。残りのコア (HostCpusList 用に確保されていないコア) はゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。

NeutronDpdkCoreList: “'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 つも割り当てる必要があります。残りのコア (HostCpusList 用に確保されていないコア) はゲストインスタンスに割り当てられます。その結果、パラメーターの設定は以下のようになります。

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

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

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

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

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

6.4. NFV OVS-DPDK デプロイメントのトポロジー

以下の 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 テナントとは一切共有できません。

NFV OVS-DPDK deployment

NFV OVS-DPDK のトポロジー

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

NFV OVS-DPDK Topology

第7章 パフォーマンス

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

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

SR-IOV ネットワークでは、固有なネットワークや仮想マシンのスループットの向上など、強化されたパフォーマンス特性が提供されます。

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

NFV に関するこれらの機能およびパフォーマンスチューニングについての詳細は、「NFV Performance Considerations」を参照してください。

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

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

  • ネットワークの中断
  • SMI
  • 仮想ネットワーク機能におけるパケット処理のレイテンシー

パケットロスを防ぐには、キューサイズをデフォルトの 256 から最大の 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/コアのレートでフレーム損失なし)。

第8章 vHost ユーザーポート

vHost ユーザーポートは DPDK に基づくインスタンス用のデータパスで、以下の 2 つのモードがあります。

  • dpdkvhostuser
  • dpdkvhostuserclient

dpdkvhostuser モードでは、Open vSwitch (OVS) は vHost ユーザーソケットを作成するサーバーとして機能します。OVS はクライアントである QEMU とソケットを共有します。このモードでは、OVS が再起動した場合、接続された仮想マシンインスタンスが再び接続を確立するには、仮想マシンをリブートする必要があります。

OVS 2.9 の時点では、dpdkvhostuser ではなく dpdkvhostuserclient が使用されます。このモードでは、QEMU がサーバーとして vHost ソケットを作成および共有し、OVS がクライアントとして接続します。このモードで OVS が再起動した場合、すべての既存仮想マシンに自動的に再接続します。

8.1. 手動による vHost ユーザーポートモードの変更

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

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

注記

インスタンスに CPU ピニングを設定している場合、nova.confcpu_pinning_migration_quick_fail パラメーターを false に設定します。これにより CPU ピニングの再計算が可能になり、移行に成功する可能性が高くなります。CPU ピニングを設定したインスタンスのライブマイグレーションを試みる場合は、事前に Red Hat サポートにお問い合わせください。

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

RHOSP10 メンテナンスリリース RHBA-2019:0074 までは、nova.conf の NovaSchedulerDefaultFilters パラメーターに NUMATopologyFilter の値が含まれていると、コールドマイグレーションに失敗する場合があります。Nova の cpu_pinning_migration_quick_fail オプションが含まれる最新のメンテナンスリリースを使用することで、この動作を防ぐことができます。詳しくは、『Red Hat OpenStack Platform 10 リリースノート』を参照してください。

インスタンスの 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>
...

第9章 技術サポート

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

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

表9.1 参考資料一覧

コンポーネント参考情報

Red Hat Enterprise Linux

Red Hat OpenStack Platform は Red Hat Enterprise Linux 7.3 でサポートされています。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 のインストールと使用方法』を参照してください。

ネットワークの分離、ストレージ設定、SSL 通信など、Red Hat OpenStack Platform director を使用して Red Hat OpenStack Platform エンタープライズ環境に高度な機能を設定する方法、および一般的な設定方法については、『オーバークラウドの高度なカスタマイズ』を参照してください。

Red Hat OpenStack Platform コンポーネントを手動でインストールすることもできます。『手動インストール手順』を参照してください。

NFV のドキュメント

NFV の概念に関する俯瞰的な情報は、『ネットワーク機能仮想化 (NFV) の製品ガイド』を参照してください。

Red Hat OpenStack Platform 10 director での SR-IOV および OVS-DPDK 設定に関する情報は、『ネットワーク機能仮想化 (NFV) の設定ガイド』を参照してください。

法律上の通知

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