ネットワーク機能仮想化の設定

手順

1. 設定する Mellanox NIC を備えた RHOSP デプロイメントの Compute ノードにログインします。

2. mstflintユーティリティーを使用して、ESWITCH_IPV4_TTL_MODIFY_ENABLE Mellanox ファームウェアパラメーターを照会します。

   [root@compute-1 ~]# yum install -y mstflint
   [root@compute-1 ~]# mstconfig -d <PF PCI BDF> q ESWITCH_IPV4_TTL_MODIFY_ENABLE

3. ESWITCH_IPV4_TTL_MODIFY_ENABLEパラメーターが有効で1に設定されている場合は、値を0に設定して無効にします。

   [root@compute-1 ~]# mstconfig -d <PF PCI BDF> s ESWITCH_IPV4_TTL_MODIFY_ENABLE=0`

4. ノードを再起動します。

手順

1. コンテンツ配信ネットワークにシステムを登録します。プロンプトが表示されたら、カスタマーポータルのユーザー名とパスワードを入力します。

   [stack@director ~]$ sudo subscription-manager register

2. Red Hat OpenStack Platform director のエンタイトルメントプール ID を確認します (たとえば、以下のコマンド出力の {Pool ID})。

   [stack@director ~]$ sudo subscription-manager list --available --all --matches="Red Hat OpenStack"
   Subscription Name:   Name of SKU
   Provides:            Red Hat Single Sign-On
                        Red Hat Enterprise Linux Workstation
                        Red Hat CloudForms
                        Red Hat OpenStack
                        Red Hat Software Collections (for RHEL Workstation)
   SKU:                 SKU-Number
   Contract:            Contract-Number
   Pool ID:             {Pool-ID}-123456
   Provides Management: Yes
   Available:           1
   Suggested:           1
   Service Level:       Support-level
   Service Type:        Service-Type
   Subscription Type:   Sub-type
   Ends:                End-date
   System Type:         Physical

3. 次のコマンドに Pool ID の値を含めて、Red Hat OpenStack Platform 17.1 のエンタイトルメントをアタッチします。

   [stack@director ~]$ sudo subscription-manager attach --pool={Pool-ID}-123456

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

   subscription-manager repos --disable=*

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

   $ sudo subscription-manager repos --enable=rhel-9-for-x86_64-baseos-eus-rpms \
   --enable=rhel-9-for-x86_64-appstream-eus-rpms \
   --enable=rhel-9-for-x86_64-highavailability-eus-rpms \
   --enable=ansible-2.9-for-rhel-9-x86_64-rpms \
   --enable=openstack-17.1-for-rhel-9-x86_64-rpms \
   --enable=rhel-9-for-x86_64-nfv-rpms \
   --enable=fast-datapath-for-rhel-9-x86_64-rpms

6. システムを更新して、ベースシステムパッケージが最新の状態になるようにします。

   [stack@director ~]$ sudo dnf update -y
   [stack@director ~]$ sudo reboot

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. ControllerとComputeSriovのロールを含むroles_data_compute_sriov.yamlという名前の新しいロールデータファイルを生成します。

   $  openstack overcloud roles \
    generate -o /home/stack/templates/roles_data_compute_sriov.yaml \
    Controller ComputeSriov

   注記

   RHOSP 環境で OVS-DPDK、SR-IOV、および OVS ハードウェアオフロードなどの複数のテクノロジーを使用している場合は、すべてのロールを含めるために 1 つのロールデータファイルを生成します。

   $ openstack overcloud roles generate -o /home/stack/templates/\
   roles_data.yaml Controller ComputeOvsDpdk ComputeOvsDpdkSriov \
   Compute:ComputeOvsHwOffload

4. イメージファイルを生成するには、openstack tripleo container image prepare コマンドを実行します。以下の入力が必要です。

   • 前の手順で生成したロールデータファイル (例: roles_data_compute_sriov.yaml)。

   • Networking サービスメカニズムドライバーに適した SR-IOV 環境ファイル:

     • ML2/OVN 環境

       /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-sriov.yaml

     • ML2/OVS 環境

       /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-sriov.yaml

       例

       この例では、overcloud_images.yaml ファイルが ML2/OVN 環境用に生成されています。

       $ sudo openstack tripleo container image prepare \
         --roles-file ~/templates/roles_data_compute_sriov.yaml \
         -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-sriov.yaml \
         -e ~/containers-prepare-parameter.yaml \
         --output-env-file=/home/stack/templates/overcloud_images.yaml

5. 作成したロールデータファイルとイメージファイルのパスとファイル名をメモします。これらのファイルは、後でオーバークラウドをデプロイするときに使用します。

手順

1. PCI カードを備えた物理サーバーで、次のコマンドのいずれかを使用します。

   • オーバークラウドがデプロイされている場合:

     $ lspci -nn -s  <pci_device_address>

     出力例

     3b:00.0 Ethernet controller [0200]: Intel Corporation Ethernet
     Controller X710 for 10GbE SFP+ [<vendor_id>: <product_id>] (rev 02)

   • オーバークラウドがデプロイされていない場合:

     $ openstack baremetal introspection data save <baremetal_node_name> | jq '.inventory.interfaces[] | .name, .vendor, .product'

2. SR-IOV コンピュートノード上の PCI パススルーデバイスのベンダー ID と製品 ID を保持します。これらの ID は後の手順で必要になります。
3. アンダークラウドに stack ユーザーとしてログインします。

4. stackrc ファイルを取得します。

   $ source ~/stackrc

5. カスタム環境 YAML ファイル (例: sriov-overrides.yaml) を作成します。次の内容をファイルに追加して、SR-IOV コンピュートノードの PCI パススルーデバイスを設定します。

   parameter_defaults:
     ComputeSriovParameters:
       ...
       NovaPCIPassthrough:
         - vendor_id: "<vendor_id>"
           product_id: "<product_id>"
           address: <NIC_address>
           physical_network: "<physical_network>"
       ...

   • <vendor_id> を PCI デバイスのベンダー ID に置き換えます。
   • <product_id> を PCI デバイスの製品 ID に置き換えます。
   • <NIC_address> を PCI デバイスのアドレスに置き換えます。

   • <physical_network> を、PCI デバイスが配置されている物理ネットワークの名前に置き換えます。

     注記

     NIC のデバイス名は変更される可能性があるため、PCI パススルーを設定する場合は devname パラメーターを使用しないでください。PF で Networking サービス (neutron) ポートを作成するには、NovaPCIPassthrough に vendor_id、product_id、および PCI デバイスアドレスを指定し、--vnic-type direct-physical オプションでポートを作成します。Virtual Function (VF) に Networking サービスのポートを作成するには、NovaPCIPassthrough で vendor_id と product_id を指定し、--vnic-type direct オプションを使用してポートを作成します。vendor_id および product_id パラメーターの値は、Physical Function (PF) コンテキストと VF コンテキストの間で異なる場合があります。

6. また、カスタム環境ファイルで、Compute サービス (nova) がノードをフィルター処理するために使用する NovaSchedulerEnabledFilters パラメーター用のフィルターのリストに PciPassthroughFilter と AggregateInstanceExtraSpecsFilter が含まれていることを確認します。

   parameter_defaults:
     ComputeSriovParameters:
       ...
       NovaPCIPassthrough:
         - vendor_id: "<vendor_id>"
           product_id: "<product_id>"
           address: <NIC_address>
           physical_network: "<physical_network>"
       ...
     NovaSchedulerEnabledFilters:
       - AvailabilityZoneFilter
       - ComputeFilter
       - ComputeCapabilitiesFilter
       - ImagePropertiesFilter
       - ServerGroupAntiAffinityFilter
       - ServerGroupAffinityFilter
       - PciPassthroughFilter
       - AggregateInstanceExtraSpecsFilter

7. 作成したカスタム環境ファイルのパスとファイル名をメモします。このファイルは、後でオーバークラウドをデプロイするときに使用します。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. 「SR-IOV 用の PCI パススルーデバイスの設定」 に作成したカスタム環境 YAML ファイルを開くか、新しいものを作成します。

4. SR-IOV Compute ノードのロール固有のパラメーターをカスタム環境ファイルに追加します。

   例

     ComputeSriovParameters:
       IsolCpusList: 9-63,73-127
       KernelArgs: default_hugepagesz=1GB hugepagesz=1G hugepages=100 amd_iommu=on iommu=pt numa_balancing=disable processor.max_cstate=0 isolcpus=9-63,73-127
       NovaReservedHostMemory: 4096
       NovaComputeCpuSharedSet: 0-8,64-72
       NovaComputeCpuDedicatedSet: 9-63,73-127

5. RHOSP director が SR-IOV を設定するために使用する設定のデフォルトを確認します。これらのデフォルトはファイルで提供されており、メカニズムドライバーによって異なります。

   • ML2/OVN

     /usr/share/openstack-tripleo-heat-templates/environment/services/neutron-ovn-sriov.yaml

   • ML2/OVS

     /usr/share/openstack-tripleo-heat-templates/environment/services/neutron-sriov.yaml

6. 設定のデフォルトをオーバーライドする必要がある場合は、オーバーライドをカスタム環境ファイルに追加します。

   たとえば、このカスタム環境ファイルでは、Nova PCI ホワイトリスト値を追加したり、ネットワークタイプを設定したりできます。

   例

   この例では、ネットワークサービス (neutron) ネットワークタイプが VLAN に設定され、テナントの範囲が追加されます。

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

7. 新しいカスタム環境ファイルを作成した場合は、そのパスとファイル名をメモします。このファイルは、後でオーバークラウドをデプロイするときに使用します。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのベアメタルノードのプロビジョニング の指示に従って、overcloud-baremetal-deploy.yaml などのベアメタルノード定義ファイルを作成します。

4. ベアメタルノード定義ファイルで、Ansible の Playbook cli-overcloud-node-kernelargs.yaml に宣言を追加します。

   Playbook には、ベアメタルノードをプロビジョニングするときに使用するカーネル引数が含まれています。

   - name: ComputeSriov
   ...
     ansible_playbooks:
       - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-kernelargs.yaml
   ...

5. Playbook の実行時に追加の Ansible 変数を設定する場合は、extra_vars プロパティーを使用して設定します。

   注記

   extra_vars に追加する変数は、「ロール固有のパラメーターと設定のオーバーライドの追加」 でカスタム環境ファイルに追加した SR-IOV Compute ノードのロール固有のパラメーターと同じである必要があります。

   例

   - name: ComputeSriov
   ...
     ansible_playbooks:
       - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-kernelargs.yaml
         extra_vars:
           kernel_args: 'default_hugepagesz=1GB hugepagesz=1G hugepages=100 amd_iommu=on iommu=pt isolcpus=9-63,73-127'
           tuned_isolated_cores: '9-63,73-127'
           tuned_profile: 'cpu-partitioning'
           reboot_wait_timeout: 1800

6. 作成したベアメタルノード定義ファイルのパスとファイル名をメモします。このファイルは、後で NIC を設定するときに使用し、ノードをプロビジョニングするときに overcloud node provision コマンドの入力ファイルとして使用します。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. サンプルネットワーク設定テンプレートをコピーします。

   /usr/share/ansible/roles/tripleo_network_config/templates/ ディレクトリー内の例から NIC 設定 Jinja2 テンプレートをコピーします。NIC 要件に最も近いものを選択してください。必要に応じて変更してください。

4. NIC 設定テンプレート (たとえば、single_nic_vlans.j2) に、PF インターフェイスと VF インターフェイスを追加します。SR-IOV VF を作成するには、インターフェイスをスタンドアロン NIC として設定します。

   例

   ...
   - type: sriov_pf
     name: enp196s0f0np0
     mtu: 9000
     numvfs: 16
     use_dhcp: false
     defroute: false
     nm_controlled: true
     hotplug: true
     promisc: false
   ...

   注記

   numvfs パラメーターは、ネットワーク設定テンプレートの NeutronSriovNumVFs パラメーターに代わるものです。Red Hat では、デプロイ後の NeutronSriovNumVFs パラメーターまたは numvfs パラメーターの変更をサポートしません。デプロイメント後にいずれかのパラメーターを変更すると、その PF 上に SR-IOV ポートを持つ実行中のインスタンスに中断が発生する可能性があります。この場合、これらのインスタンスをハードリブートして、SR-IOV PCI デバイスを再び利用可能にする必要があります。

5. 「SR-IOV 用のベアメタルノード定義ファイルの作成」 に作成したベアメタルノード定義ファイルにカスタムネットワーク設定テンプレートを追加します。

   例

   - name: ComputeSriov
     count: 2
     hostname_format: compute-%index%
     defaults:
       networks:
         - network: internal_api
           subnet: internal_api_subnet
         - network: tenant
           subnet: tenant_subnet
         - network: storage
           subnet: storage_subnet
       network_config:
         template: /home/stack/templates/single_nic_vlans.j2
   ...

6. 作成した NIC 設定テンプレートのパスとファイル名をメモします。後で NIC をパーティション分割する場合は、このファイルを使用します。

次のステップ

1. NIC をパーティション分割したい場合は、「NIC パーティションの設定」 に進んでください。

2. それ以外の場合は、次の手順を実行します。

   1. director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのネットワーク定義の設定とプロビジョニング
   2. director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのネットワーク仮想 IP の設定とプロビジョニング
   3. director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのベアメタルノードのプロビジョニング
   4. 「SR-IOV オーバークラウドのデプロイ」

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. 「SR-IOV 用の NIC 設定テンプレートの作成」 で作成した NIC 設定テンプレート (例: single_nic_vlans.j2) を開きます。

   ヒント

   このセクションの手順を完了したら、「NIC パーティションの設定例」 を参照してください。

4. インターフェイス種別 sriov_pf のエントリーを追加して、ホストが使用できる Physical Function を設定します。

      - type: sriov_pf
        name: <interface_name>
        use_dhcp: false
        numvfs: <number_of_vfs>
        promisc: <true/false>

   • <interface_name> は、インターフェイスの名前に置き換えます。
   • <number_of_vfs> は VF の数に置き換えます。
   • オプション: <true/false> を true に置き換えてプロミスキャスモードを設定するか、false に置き換えてプロミスキャスモードを無効にします。デフォルト値は true です。
   注記

   numvfs パラメーターは、ネットワーク設定テンプレートの NeutronSriovNumVFs パラメーターに代わるものです。Red Hat では、デプロイ後の NeutronSriovNumVFs パラメーターまたは numvfs パラメーターの変更をサポートしません。デプロイ後にいずれかのパラメーターを変更すると、その Physical Function (PF) 上に SR-IOV ポートを持つ実行中のインスタンスが使用できなくなる可能性があります。この場合、これらのインスタンスをハードリブートして、SR-IOV PCI デバイスを再び利用可能にする必要があります。

5. インターフェイス種別 sriov_vf のエントリーを追加して、ホストが使用できる Virtual Function を設定します。

    - type: <bond_type>
      name: internal_bond
      bonding_options: mode=<bonding_option>
      use_dhcp: false
      members:
      - type: sriov_vf
          device: <pf_device_name>
          vfid: <vf_id>
      - type: sriov_vf
          device:  <pf_device_name>
          vfid: <vf_id>
   
    - type: vlan
      vlan_id:
        get_param: InternalApiNetworkVlanID
      spoofcheck: false
      device: internal_bond
      addresses:
      - ip_netmask:
          get_param: InternalApiIpSubnet
      routes:
        list_concat_unique:
        - get_param: InternalApiInterfaceRoutes

   • <bond_type> を必要なボンディング種別 (例: linux_bond) に置き換えます。ovs_bond 等の他のボンディング種別のボンディングに VLAN タグを適用することができます。

   • <bonding_option> を、以下のサポートされるボンディングモードのいずれかに置き換えます。

     • active-backup

     • Balance-slb

       注記

       LACP ボンディングはサポートされません。

   • members セクションで、ボンディングのインターフェイス種別として sriov_vf を指定します。

     注記

     インターフェイス種別として OVS ブリッジを使用している場合は、sriov_pf デバイスの sriov_vf に OVS ブリッジを 1 つだけ設定することができます。単一の sriov_pf デバイス上に複数の OVS ブリッジがあると、VF 間でパケットが重複し、パフォーマンスが低下する可能性があります。

   • <pf_device_name> を PF デバイスの名前に置き換えます。
   • linux_bond を使用する場合は、VLAN タグを割り当てる必要があります。VLAN タグを設定する場合は、1 つの sriov_pf デバイスに関連付けられた各 VF に一意のタグを設定するようにしてください。同じ VLAN 上の同じ PF の VF を 2 つ指定できません。
   • <vf_id> を VF の ID に置き換えます。適用可能な VF ID の範囲は、ゼロから VF の最大数から 1 を引いた数値までです。
   • スプーフィングチェックを無効にします。
   • VF 上の linux_bond の sriov_vf に VLAN タグを適用します。

6. インスタンスに VF を確保するには、環境ファイルに NovaPCIPassthrough パラメーターを追加します。

   例

   NovaPCIPassthrough:
    - address: "0000:19:0e.3"
      trusted: "true"
      physical_network: "sriov1"
    - address: "0000:19:0e.0"
      trusted: "true"
      physical_network: "sriov2"

   RHOSP director はホストの VF を把握し、インスタンスで利用可能な VF の PCI アドレスを派生します。

7. NIC の分割が必要なすべてのノードで IOMMU を有効にします。

   例

   たとえば、Compute ノードに NIC 分割を設定する場合は、そのロールの KernelArgs パラメーターを使用して IOMMU を有効にします。

   parameter_defaults:
     ComputeParameters:
       KernelArgs: "intel_iommu=on iommu=pt"

   注記

   KernelArgs パラメーターをロールの設定に初めて追加すると、オーバークラウドノードが自動的に再起動されます。必要に応じて、ノードの自動再起動を無効にし、代わりに各オーバークラウドのデプロイ後にノードの再起動を手動で実行できます。

8. この NIC 設定テンプレート (例: single_nic_vlans.j2) を、「SR-IOV 用のベアメタルノード定義ファイルの作成」 で作成したベアメタルノード定義ファイルに追加してください。

次のステップ

1. director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのネットワーク定義の設定とプロビジョニング
2. director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのネットワーク仮想 IP の設定とプロビジョニング
3. director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのベアメタルノードのプロビジョニング
4. 「SR-IOV オーバークラウドのデプロイ」

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. openstack overcloud deploy コマンドを実行します。

   openstack overcloud deploy コマンドへの入力を特定の順序でリストすることが重要です。一般的なルールは、デフォルトの heat テンプレートファイルを最初に指定し、次にカスタム環境ファイルと、デフォルトプロパティーのオーバーライドなどのカスタム設定を含むカスタムテンプレートを指定することです。

   次の順序で、openstack overcloud deploy コマンドに入力を追加します。

   1. オーバークラウド上の SR-IOV ネットワークの仕様が含まれるカスタムネットワーク定義ファイル (例: network-data.yaml)。

      詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの ネットワーク定義ファイル設定のオプション を参照してください。

   2. RHOSP director が OVS ハードウェアオフロード環境をデプロイするために使用する Controller および ComputeOvsHwOffload ロールを含むロールファイル。

      例: roles_data_compute_sriov.yaml

      詳細は、「SR-IOV のロールとイメージファイルの生成」 を参照してください。

   3. オーバークラウドネットワークのプロビジョニングからの出力ファイル。

      例: overcloud-networks-deployed.yaml

      詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのネットワーク定義の設定とプロビジョニング を参照してください。

   4. オーバークラウド仮想 IP のプロビジョニングからの出力ファイル。

      例: overcloud-vip-deployed.yaml

      詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのネットワーク仮想 IP の設定とプロビジョニング を参照してください。

   5. ベアメタルノードのプロビジョニングからの出力ファイル。

      たとえば、overcloud-baremetal-deployed.yaml です。

      詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのベアメタルノードのプロビジョニング を参照してください。

   6. コンテナーイメージを取得する場所と保存方法を決定するためにディレクターが使用するイメージファイル。

      例: overcloud_images.yaml

      詳細は、「SR-IOV のロールとイメージファイルの生成」 を参照してください。

   7. 環境が使用する Networking サービス (neutron) メカニズムドライバーとルータースキームの環境ファイル:

      • ML2/OVN

        • 分散仮想ルーティング (DVR): neutron-ovn-dvr-ha.yaml
        • 集中型仮想ルーティング: neutron-ovn-ha.yaml

      • ML2/OVS

        • 分散仮想ルーティング (DVR): neutron-ovs-dvr.yaml
        • 集中型仮想ルーティング: neutron-ovs.yaml

   8. メカニズムドライバーに応じた SR-IOV の環境ファイル:

      • ML2/OVN

        • neutron-ovn-sriov.yaml

      • ML2/OVS

        • neutron-sriov.yaml

          注記

          OVS-DPDK 環境もあり、OVS-DPDK インスタンスと SR-IOV インスタンスを同じノードに配置する場合は、デプロイメントスクリプトに次の環境ファイルを含めます。

          • ML2/OVN

            neutron-ovn-dpdk.yaml

          • ML2/OVS

            neutron-ovs-dpdk.yaml

   9. 以下の設定を含む 1 つ以上のカスタム環境ファイル:

      • SR-IOV ノード用の PCI パススルーデバイス。
      • SR-IOV ノードのロール固有のパラメーター。

      • SR-IOV 環境のデフォルト設定値をオーバーライドします。

        例: sriov-overrides.yaml

        詳細は以下を参照してください。

      • 「SR-IOV 用の PCI パススルーデバイスの設定」。

      • 「ロール固有のパラメーターと設定のオーバーライドの追加」。

        例

        サンプルの openstack overcloud deploy コマンドからのこの抜粋は、DVR を使用する SR-IOV、ML2/OVN 環境のコマンド入力の適切な順序を示しています。

        $ openstack overcloud deploy \
        --log-file overcloud_deployment.log \
        --templates /usr/share/openstack-tripleo-heat-templates/ \
        --stack overcloud \
        -n /home/stack/templates/network_data.yaml \
        -r /home/stack/templates/roles_data_compute_sriov.yaml \
        -e /home/stack/templates/overcloud-networks-deployed.yaml \
        -e /home/stack/templates/overcloud-vip-deployed.yaml \
        -e /home/stack/templates/overcloud-baremetal-deployed.yaml \
        -e /home/stack/templates/overcloud-images.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/\
        neutron-ovn-dvr-ha.yaml
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/\
        neutron-ovn-sriov.yaml \
        -e /home/stack/templates/sriov-overrides.yaml

4. openstack overcloud deploy コマンドを実行します。

   オーバークラウドの作成が完了すると、RHOSP director は、オーバークラウドへのアクセスに役立つ詳細を提供します。

検証

1. director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのデプロイメントの検証 のステップを実行します。

2. NIC が適切にパーティション分割されていることを確認するには、次の手順を実行します。

   1. tripleo-admin としてオーバークラウドの Compute ノードにログインし、VF の数を確認します。

      例

      この例では、p4p1 と p4p2 の両方の VF の数は 10 です。

      $ sudo cat /sys/class/net/p4p1/device/sriov_numvfs
      
      10
      
      $ sudo cat /sys/class/net/p4p2/device/sriov_numvfs
      
      10

   2. OVS 接続を表示します。

      $ sudo ovs-vsctl show

      出力例

      以下のような出力が表示されるはずです。

      b6567fa8-c9ec-4247-9a08-cbf34f04c85f
          Manager "ptcp:6640:127.0.0.1"
              is_connected: true
          Bridge br-sriov2
              Controller "tcp:127.0.0.1:6633"
                  is_connected: true
              fail_mode: secure
              datapath_type: netdev
              Port phy-br-sriov2
                  Interface phy-br-sriov2
                      type: patch
                      options: {peer=int-br-sriov2}
              Port br-sriov2
                  Interface br-sriov2
                      type: internal
          Bridge br-sriov1
              Controller "tcp:127.0.0.1:6633"
                  is_connected: true
              fail_mode: secure
              datapath_type: netdev
              Port phy-br-sriov1
                  Interface phy-br-sriov1
                      type: patch
                      options: {peer=int-br-sriov1}
              Port br-sriov1
                  Interface br-sriov1
                      type: internal
          Bridge br-ex
              Controller "tcp:127.0.0.1:6633"
                  is_connected: true
              fail_mode: secure
              datapath_type: netdev
              Port br-ex
                  Interface br-ex
                      type: internal
              Port phy-br-ex
                  Interface phy-br-ex
                      type: patch
                      options: {peer=int-br-ex}
          Bridge br-tenant
              Controller "tcp:127.0.0.1:6633"
                  is_connected: true
              fail_mode: secure
              datapath_type: netdev
              Port br-tenant
                  tag: 305
                  Interface br-tenant
                      type: internal
              Port phy-br-tenant
                  Interface phy-br-tenant
                      type: patch
                      options: {peer=int-br-tenant}
              Port dpdkbond0
                  Interface dpdk0
                      type: dpdk
                      options: {dpdk-devargs="0000:18:0e.0"}
                  Interface dpdk1
                      type: dpdk
                      options: {dpdk-devargs="0000:18:0a.0"}
          Bridge br-tun
              Controller "tcp:127.0.0.1:6633"
                  is_connected: true
              fail_mode: secure
              datapath_type: netdev
              Port vxlan-98140025
                  Interface vxlan-98140025
                      type: vxlan
                      options: {df_default="true", egress_pkt_mark="0", in_key=flow, local_ip="152.20.0.229", out_key=flow, remote_ip="152.20.0.37"}
              Port br-tun
                  Interface br-tun
                      type: internal
              Port patch-int
                  Interface patch-int
                      type: patch
                      options: {peer=patch-tun}
              Port vxlan-98140015
                  Interface vxlan-98140015
                      type: vxlan
                      options: {df_default="true", egress_pkt_mark="0", in_key=flow, local_ip="152.20.0.229", out_key=flow, remote_ip="152.20.0.21"}
              Port vxlan-9814009f
                  Interface vxlan-9814009f
                      type: vxlan
                      options: {df_default="true", egress_pkt_mark="0", in_key=flow, local_ip="152.20.0.229", out_key=flow, remote_ip="152.20.0.159"}
              Port vxlan-981400cc
                  Interface vxlan-981400cc
                      type: vxlan
                      options: {df_default="true", egress_pkt_mark="0", in_key=flow, local_ip="152.20.0.229", out_key=flow, remote_ip="152.20.0.204"}
          Bridge br-int
              Controller "tcp:127.0.0.1:6633"
                  is_connected: true
              fail_mode: secure
              datapath_type: netdev
              Port int-br-tenant
                  Interface int-br-tenant
                      type: patch
                      options: {peer=phy-br-tenant}
              Port int-br-ex
                  Interface int-br-ex
                      type: patch
                      options: {peer=phy-br-ex}
              Port int-br-sriov1
                  Interface int-br-sriov1
                      type: patch
                      options: {peer=phy-br-sriov1}
              Port patch-tun
                  Interface patch-tun
                      type: patch
                      options: {peer=patch-int}
              Port br-int
                  Interface br-int
                      type: internal
              Port int-br-sriov2
                  Interface int-br-sriov2
                      type: patch
                      options: {peer=phy-br-sriov2}
              Port vhu4142a221-93
                  tag: 1
                  Interface vhu4142a221-93
                      type: dpdkvhostuserclient
                      options: {vhost-server-path="/var/lib/vhost_sockets/vhu4142a221-93"}
          ovs_version: "2.13.2"

   3. SR-IOV コンピュートノードに tripleo-admin としてログインし、Linux ボンドを確認します。

      $ cat /proc/net/bonding/<bond_name>

      出力例

      以下のような出力が表示されるはずです。

      Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
      
      Bonding Mode: fault-tolerance (active-backup)
      Primary Slave: None
      Currently Active Slave: eno3v1
      MII Status: up
      MII Polling Interval (ms): 0
      Up Delay (ms): 0
      Down Delay (ms): 0
      Peer Notification Delay (ms): 0
      
      Slave Interface: eno3v1
      MII Status: up
      Speed: 10000 Mbps
      Duplex: full
      Link Failure Count: 0
      Permanent HW addr: 4e:77:94:bd:38:d2
      Slave queue ID: 0
      
      Slave Interface: eno4v1
      MII Status: up
      Speed: 10000 Mbps
      Duplex: full
      Link Failure Count: 0
      Permanent HW addr: 4a:74:52:a7:aa:7c
      Slave queue ID: 0

3. OVS ボンドをリストします。

   $ sudo ovs-appctl bond/show

   出力例

   以下のような出力が表示されるはずです。

   ---- dpdkbond0 ----
   bond_mode: balance-slb
   bond may use recirculation: no, Recirc-ID : -1
   bond-hash-basis: 0
   updelay: 0 ms
   downdelay: 0 ms
   next rebalance: 9491 ms
   lacp_status: off
   lacp_fallback_ab: false
   active slave mac: ce:ee:c7:58:8e:b2(dpdk1)
   
   slave dpdk0: enabled
     may_enable: true
   
   slave dpdk1: enabled
     active slave
     may_enable: true

4. NovaPCIPassthrough を使用して VF をインスタンスに渡した場合は、SR-IOV インスタンスをデプロイしてテストを行います。

手順

1. 集約グループを作成し、関連するホストを追加します。

   定義するフレーバーメタデータに一致するメタデータを定義します (例: sriov=true)。

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

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

   $ openstack flavor create <flavor> --ram <size_mb> --disk <size_gb> \
   --vcpus <number>

3. 追加のフレーバー属性を設定します。

   定義したメタデータ (sriov=true) と SR-IOV アグリゲートで定義したメタデータが一致している点に注意してください。

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

手順

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

   $ openstack flavor create <flavor_name> --ram <size_mb> \
   --disk <size_gb> --vcpus <number>

   ヒント

   フレーバーに追加スペック hw:pci_numa_affinity_policy を追加して、PCI パススルーデバイスおよび SR-IOV インターフェイスの NUMA アフィニティーポリシーを指定することができます。詳細は、インスタンス作成のための Compute サービスの設定 の フレーバーメタデータ を参照してください。

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

   $ openstack network create <network_name> \
   --provider-physical-network tenant \
   --provider-network-type vlan --provider-segment <vlan_id>
   
   $ openstack subnet create <name> --network <network_name> \
   --subnet-range <ip_address_cidr> --dhcp

3. Virtual Function (VF) ポートまたは Physical Function (PF) ポートを作成します。

   • VF ポート:

     $ openstack port create --network <network_name> \
     --vnic-type direct <port_name>

   • 単一インスタンス専用の PF ポート:

     この PF ポートは Networking サービス (neutron) ポートですが、Networking サービスによって制御されておらず、インスタンスにパススルーされる PCI デバイスであるため、ネットワークアダプターとして表示されません。

     $ openstack port create --network <network_name> \
     --vnic-type direct-physical <port_name>

4. インスタンスを作成します。

   $ openstack server create --flavor <flavor> --image <image_name> \
   --nic port-id=<id> <instance_name>

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. Compute ロールをベースとする OVS ハードウェアオフロード用のオーバークラウドロールを生成します。

   例

   この例では、コンピュートロールに基づいて、ComputeOvsHwOffload というロールが作成されます。コマンドによって生成されるロールファイルの名前は roles_data_compute_ovshwol.yaml です。

   $ openstack overcloud roles generate -o \
   roles_data_compute_ovshwol.yaml Controller Compute:ComputeOvsHwOffload

   注記

   RHOSP 環境に OVS-DPDK、SR-IOV、および OVS TC-flower ハードウェアオフロードテクノロジーが混在している場合は、すべてのロールを含めるために、roles_data.yaml などのロールデータファイルを 1 つだけ生成します。

   $ openstack overcloud roles generate -o /home/stack/templates/\
   roles_data.yaml Controller ComputeOvsDpdk ComputeOvsDpdkSriov \
   Compute:ComputeOvsHwOffload

4. (オプション): ComputeOvsHwOffload ロール向けの HostnameFormatDefault: '%stackname%-compute-%index%' の名前を変更します。

5. イメージファイルを生成するには、openstack tripleo container image prepare コマンドを実行します。以下の入力が必要です。

   • 前の手順で生成したロールデータファイル (例: roles_data_compute_ovshwol.yaml)。

   • Networking サービスメカニズムドライバーに適した SR-IOV 環境ファイル:

     • ML2/OVN 環境

       /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-sriov.yaml

     • ML2/OVS 環境

       /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-sriov.yaml

       例

       この例では、overcloud_images.yaml ファイルが ML2/OVN 環境用に生成されています。

       $ sudo openstack tripleo container image prepare \
         --roles-file ~/templates/roles_data_compute_ovshwol.yaml \
         -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-sriov.yaml \
         -e ~/containers-prepare-parameter.yaml \
         --output-env-file=/home/stack/templates/overcloud_images.yaml

6. 作成したロールデータファイルとイメージファイルのパスとファイル名をメモします。これらのファイルは、後でオーバークラウドをデプロイするときに使用します。

手順

1. PCI カードが搭載されている物理サーバー上で、次のいずれかのコマンドを使用します。

   • オーバークラウドがデプロイされている場合:

     $ lspci -nn -s  <pci_device_address>

     出力例

     3b:00.0 Ethernet controller [0200]: Intel Corporation Ethernet
     Controller X710 for 10GbE SFP+ [<vendor_id>: <product_id>] (rev 02)

   • オーバークラウドがデプロイされていない場合:

     $ openstack baremetal introspection data save <baremetal_node_name> | jq '.inventory.interfaces[] | .name, .vendor, .product'

2. ComputeOvsHwOffload ノード上の PCI パススルーデバイスのベンダー ID と製品 ID をメモします。これらの ID は後の手順で必要になります。
3. アンダークラウドに stack ユーザーとしてログインします。

4. stackrc ファイルを取得します。

   $ source ~/stackrc

5. カスタム環境 YAML ファイル (例: ovshwol-overrides.yaml) を作成します。次の内容をファイルに追加して、コンピュートノードの PCI パススルーデバイスを設定します。

   parameter_defaults:
     NeutronOVSFirewallDriver: iptables_hybrid
     ComputeOvsHwOffloadParameters:
       IsolCpusList: 2-9,21-29,11-19,31-39
       KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=128 intel_iommu=on iommu=pt"
       OvsHwOffload: true
       TunedProfileName: "cpu-partitioning"
       NeutronBridgeMappings:
         - tenant:br-tenant
       NovaPCIPassthrough:
         - vendor_id: <vendor-id>
           product_id: <product-id>
           address: <address>
           physical_network: "tenant"
         - vendor_id: <vendor-id>
           product_id: <product-id>
           address: <address>
           physical_network: "null"
       NovaReservedHostMemory: 4096
       NovaComputeCpuDedicatedSet: 1-9,21-29,11-19,31-39
       ...

   注記

   Mellanox スマート NIC を使用している場合は、ComputeOvsHwOffloadParameters パラメーターの下に DerivePciWhitelistEnabled: true を追加します。OVS ハードウェアオフロードを使用する場合、コンピュートサービス (nova) スケジューラーは、インスタンス生成の SR-IOV パススルーと同様に動作します。

   • <vendor_id> を PCI デバイスのベンダー ID に置き換えます。
   • <product_id> を PCI デバイスの製品 ID に置き換えます。
   • <NIC_address> を PCI デバイスのアドレスに置き換えます。
   • <physical_network> を、PCI デバイスが配置されている物理ネットワークの名前に置き換えます。
   • VLAN の場合には、physical_network パラメーターをデプロイメント後に neutron で作成するネットワークの名前に設定します。この値は、NeutronBridgeMappings にも設定する必要があります。

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

     注記

     NIC のデバイス名は変更される可能性があるため、PCI パススルーを設定する場合は devname パラメーターを使用しないでください。PF で Networking サービス (neutron) ポートを作成するには、NovaPCIPassthrough に vendor_id、product_id、および PCI デバイスアドレスを指定し、--vnic-type direct-physical オプションでポートを作成します。Virtual Function (VF) に Networking サービスのポートを作成するには、NovaPCIPassthrough で vendor_id と product_id を指定し、--vnic-type direct オプションを使用してポートを作成します。vendor_id および product_id パラメーターの値は、Physical Function (PF) コンテキストと VF コンテキストの間で異なる場合があります。

6. カスタム環境ファイルで、PciPassthroughFilter と NUMATopologyFilter が NovaSchedulerEnabledFilters パラメーターのフィルターリストに含まれていることを確認します。コンピュートサービス (nova) は、このパラメーターを使用してノードをフィルタリングします。

   parameter_defaults:
     ...
     NovaSchedulerEnabledFilters:
       - AvailabilityZoneFilter
       - ComputeFilter
       - ComputeCapabilitiesFilter
       - ImagePropertiesFilter
       - ServerGroupAntiAffinityFilter
       - ServerGroupAffinityFilter
       - PciPassthroughFilter
       - NUMATopologyFilter
       - AggregateInstanceExtraSpecsFilter

   注記

   オプション: Mellanox ConnectX5 NIC を使用する RHOSP 17.1 での OVS ハードウェアオフロードに関する問題のトラブルシューティングと設定方法の詳細は、ハードウェアオフロードのトラブルシューティング を参照してください。

7. 作成したカスタム環境ファイルのパスとファイル名をメモします。このファイルは、後でオーバークラウドをデプロイするときに使用します。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. 「OVS TC-flower ハードウェアオフロード用の PCI パススルーデバイスの設定」 に作成したカスタム環境 YAML ファイルを開くか、新しいものを作成します。

4. カスタム環境ファイルに、ComputeOvsHwOffload ノードのロール固有のパラメーターを追加します。

   例

     ComputeOvsHwOffloadParameters:
       IsolCpusList: 9-63,73-127
       KernelArgs: default_hugepagesz=1GB hugepagesz=1G hugepages=100 amd_iommu=on iommu=pt numa_balancing=disable processor.max_cstate=0 isolcpus=9-63,73-127
       NovaReservedHostMemory: 4096
       NovaComputeCpuSharedSet: 0-8,64-72
       NovaComputeCpuDedicatedSet: 9-63,73-127
       TunedProfileName: "cpu-partitioning"

5. ロール固有のパラメーターセクションに OvsHwOffload パラメーターを追加し、値を true に設定してます。

     ComputeOvsHwOffloadParameters:
       IsolCpusList: 9-63,73-127
       KernelArgs: default_hugepagesz=1GB hugepagesz=1G hugepages=100 amd_iommu=on iommu=pt numa_balancing=disable processor.max_cstate=0 isolcpus=9-63,73-127
       NovaReservedHostMemory: 4096
       NovaComputeCpuSharedSet: 0-8,64-72
       NovaComputeCpuDedicatedSet: 9-63,73-127
       TunedProfileName: "cpu-partitioning"
       OvsHwOffload: true
     ...

6. RHOSP director が OVS ハードウェアオフロードを設定するのに使用する設定のデフォルトを確認します。これらのデフォルトはファイルで提供されており、メカニズムドライバーによって異なります。

   • ML2/OVN

     /usr/share/openstack-tripleo-heat-templates/environment/services/neutron-ovn-sriov.yaml

   • ML2/OVS

     /usr/share/openstack-tripleo-heat-templates/environment/services/neutron-sriov.yaml

7. 設定のデフォルトをオーバーライドする必要がある場合は、オーバーライドをカスタム環境ファイルに追加します。

   たとえば、このカスタム環境ファイルでは、Nova PCI ホワイトリスト値を追加したり、ネットワークタイプを設定したりできます。

   例

   この例では、ネットワークサービス (neutron) ネットワークタイプが VLAN に設定され、テナントの範囲が追加されます。

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

8. 新しいカスタム環境ファイルを作成した場合は、そのパスとファイル名をメモします。このファイルは、後でオーバークラウドをデプロイするときに使用します。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのベアメタルノードのプロビジョニング の指示に従って、overcloud-baremetal-deploy.yaml などのベアメタルノード定義ファイルを作成します。

4. ベアメタルノード定義ファイルで、Ansible の Playbook cli-overcloud-node-kernelargs.yaml に宣言を追加します。

   Playbook には、ベアメタルノードをプロビジョニングするときに使用するカーネル引数が含まれています。

   - name: ComputeOvsHwOffload
   ...
     ansible_playbooks:
       - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-kernelargs.yaml
   ...

5. Playbook の実行時に追加の Ansible 変数を設定する場合は、extra_vars プロパティーを使用して設定します。

   注記

   extra_vars に追加する変数は、「OVS TC-flower ハードウェアオフロード用のロール固有のパラメーターと設定オーバーライドの追加」 でカスタム環境ファイルに追加した ComputeOvsHwOffload ノードのロール固有のパラメーターと同じである必要があります。

   例

   - name: ComputeOvsHwOffload
   ...
     ansible_playbooks:
       - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-kernelargs.yaml
         extra_vars:
           kernel_args: 'default_hugepagesz=1GB hugepagesz=1G hugepages=100 amd_iommu=on iommu=pt isolcpus=9-63,73-127'
           tuned_isolated_cores: '9-63,73-127'
           tuned_profile: 'cpu-partitioning'
           reboot_wait_timeout: 1800

6. 作成したベアメタルノード定義ファイルのパスとファイル名をメモします。このファイルは、後で NIC を設定するときに使用し、ノードをプロビジョニングするときに overcloud node provision コマンドの入力ファイルとして使用します。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. サンプルネットワーク設定テンプレートをコピーします。

   /usr/share/ansible/roles/tripleo_network_config/templates/ ディレクトリー内の例から NIC 設定 Jinja2 テンプレートをコピーします。NIC 要件に最も近いものを選択してください。必要に応じて変更してください。

4. NIC 設定テンプレート (たとえば、single_nic_vlans.j2) に、PF インターフェイスと VF インターフェイスを追加します。VF を作成するには、インターフェイスをスタンドアロン NIC として設定します。

   例

   ...
   - type: sriov_pf
     name: enp196s0f0np0
     mtu: 9000
     numvfs: 16
     use_dhcp: false
     defroute: false
     nm_controlled: true
     hotplug: true
     promisc: false
     link_mode: switchdev
   ...

   注記

   numvfs パラメーターは、ネットワーク設定テンプレートの NeutronSriovNumVFs パラメーターに代わるものです。Red Hat では、デプロイ後の NeutronSriovNumVFs パラメーターまたは numvfs パラメーターの変更をサポートしません。デプロイメント後にいずれかのパラメーターを変更すると、その PF 上に SR-IOV ポートを持つ実行中のインスタンスに中断が発生する可能性があります。この場合、これらのインスタンスをハードリブートして、SR-IOV PCI デバイスを再び利用可能にする必要があります。

5. 「OVS TC-flower ハードウェアオフロード用のベアメタルノード定義ファイルの作成」 に作成したベアメタルノード定義ファイルにカスタムネットワーク設定テンプレートを追加します。

   例

   - name: ComputeOvsHwOffload
     count: 2
     hostname_format: compute-%index%
     defaults:
       networks:
         - network: internal_api
           subnet: internal_api_subnet
         - network: tenant
           subnet: tenant_subnet
         - network: storage
           subnet: storage_subnet
       network_config:
         template: /home/stack/templates/single_nic_vlans.j2
   ...

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

     - type: ovs_bridge
       name: br-tenant
       mtu: 9000
       members:
       - type: sriov_pf
         name: p7p1
         numvfs: 5
         mtu: 9000
         primary: true
         promisc: true
         use_dhcp: false
         link_mode: switchdev

   注記
   • OVS ハードウェアオフロードを設定するときは、NeutronSriovNumVFs パラメーターを使用しないでください。Virtual Function の数は、os-net-config で使用されるネットワーク設定ファイルの numvfs パラメーターを使用して指定します。Red Hat では、更新または再デプロイ時の numvfs 設定の変更をサポートしません。
   • Mellanox ネットワークインターフェイスの nic-config インターフェイス種別を ovs-vlan に設定しないでください。ドライバーの制約により、VXLAN 等のトンネルエンドポイントがトラフィックを渡さなくなるためです。
7. 作成した NIC 設定テンプレートのパスとファイル名をメモします。後で NIC をパーティション分割する場合は、このファイルを使用します。

次のステップ

1. オーバークラウドネットワークをプロビジョニングします。

   詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのネットワーク定義の設定とプロビジョニング を参照してください。

2. オーバークラウド仮想 IP をプロビジョニングします。

   詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのネットワーク仮想 IP の設定とプロビジョニング を参照してください。

3. ベアメタルノードをプロビジョニングする。

   詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのベアメタルノードのプロビジョニング を参照してください。

4. オーバークラウドをデプロイします。

   詳細は、「OVS TC-flower ハードウェアオフロードオーバークラウドのデプロイ」 を参照してください。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. openstack overcloud deploy コマンドを実行します。

   openstack overcloud deploy コマンドへの入力を特定の順序でリストすることが重要です。一般的なルールは、デフォルトの heat テンプレートファイルを最初に指定し、次にカスタム環境ファイルと、デフォルトプロパティーのオーバーライドなどのカスタム設定を含むカスタムテンプレートを指定することです。

   次の順序で、openstack overcloud deploy コマンドに入力を追加します。

   1. オーバークラウド上の SR-IOV ネットワークの仕様が含まれるカスタムネットワーク定義ファイル (例: network-data.yaml)。

      詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの ネットワーク定義ファイル設定のオプション を参照してください。

   2. RHOSP director が OVS ハードウェアオフロード環境をデプロイするために使用する Controller および ComputeOvsHwOffload ロールを含むロールファイル。

      例: roles_data_compute_ovshwol.yaml

      詳細は、「OVS TC-flower ハードウェアオフロード用のロールとイメージファイルの生成」 を参照してください。

   3. オーバークラウドネットワークのプロビジョニングからの出力ファイル。

      例: overcloud-networks-deployed.yaml

      詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのネットワーク定義の設定とプロビジョニング を参照してください。

   4. オーバークラウド仮想 IP のプロビジョニングからの出力ファイル。

      例: overcloud-vip-deployed.yaml

      詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのネットワーク仮想 IP の設定とプロビジョニング を参照してください。

   5. ベアメタルノードのプロビジョニングからの出力ファイル。

      たとえば、overcloud-baremetal-deployed.yaml です。

      詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのベアメタルノードのプロビジョニング を参照してください。

   6. コンテナーイメージを取得する場所と保存方法を決定するためにディレクターが使用するイメージファイル。

      例: overcloud_images.yaml

      詳細は、「OVS TC-flower ハードウェアオフロード用のロールとイメージファイルの生成」 を参照してください。

   7. 環境が使用する Networking サービス (neutron) メカニズムドライバーとルータースキームの環境ファイル:

      • ML2/OVN

        • 分散仮想ルーティング (DVR): neutron-ovn-dvr-ha.yaml
        • 集中型仮想ルーティング: neutron-ovn-ha.yaml

      • ML2/OVS

        • 分散仮想ルーティング (DVR): neutron-ovs-dvr.yaml
        • 集中型仮想ルーティング: neutron-ovs.yaml

   8. メカニズムドライバーに応じた SR-IOV の環境ファイル:

      • ML2/OVN

        • neutron-ovn-sriov.yaml

      • ML2/OVS

        • neutron-sriov.yaml

          注記

          OVS-DPDK 環境もあり、OVS-DPDK インスタンスと SR-IOV インスタンスを同じノードに配置する場合は、デプロイメントスクリプトに次の環境ファイルを含めます。

          • ML2/OVN

            neutron-ovn-dpdk.yaml

          • ML2/OVS

            neutron-ovs-dpdk.yaml

   9. 以下の設定を含む 1 つ以上のカスタム環境ファイル:

      • ComputeOvsHwOffload ノード用の PCI パススルーデバイス。
      • ComputeOvsHwOffload ノードのロール固有のパラメーター。

      • OVS ハードウェアオフロード環境のデフォルト設定値をオーバーライドします。

        例: ovshwol-overrides.yaml

        詳細は以下を参照してください。

      • 「OVS TC-flower ハードウェアオフロード用の PCI パススルーデバイスの設定」。

      • 「OVS TC-flower ハードウェアオフロード用のロール固有のパラメーターと設定オーバーライドの追加」。

        例

        サンプルの openstack overcloud deploy コマンドからのこの抜粋は、DVR を使用する SR-IOV、ML2/OVN 環境のコマンド入力の適切な順序を示しています。

        $ openstack overcloud deploy \
        --log-file overcloud_deployment.log \
        --templates /usr/share/openstack-tripleo-heat-templates/ \
        --stack overcloud \
        -n /home/stack/templates/network_data.yaml \
        -r /home/stack/templates/roles_data_compute_ovshwol.yaml \
        -e /home/stack/templates/overcloud-networks-deployed.yaml \
        -e /home/stack/templates/overcloud-vip-deployed.yaml \
        -e /home/stack/templates/overcloud-baremetal-deployed.yaml \
        -e /home/stack/templates/overcloud-images.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/\
        neutron-ovn-dvr-ha.yaml
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/\
        neutron-ovn-sriov.yaml \
        -e /home/stack/templates/ovshwol-overrides.yaml

4. openstack overcloud deploy コマンドを実行します。

   オーバークラウドの作成が完了すると、RHOSP director は、オーバークラウドへのアクセスに役立つ詳細を提供します。

次のステップ

1. NIC の e-switch モードが switchdev に設定されていることを確認します。

   switchdev モードにより、NIC 上にレプリゼンターポートが確立され、VF にマッピングされます。

   重要

   OpenFlow フローをハードウェアにオフロードするには、接続追跡 (conntrack) モジュールの switchdev ポートでセキュリティーグループとポートセキュリティーを有効にする必要があります。

   1. 次のコマンドを実行して NIC を確認します。

      例

      この例では、NIC pci/0000:03:00.0 が照会されます。

      $ sudo devlink dev eswitch show pci/0000:03:00.0

      出力例

      以下のような出力が表示されるはずです。

      pci/0000:03:00.0: mode switchdev inline-mode none encap enable

   2. NIC を switchdev モードに設定するには、次のコマンドを実行します。

      例

      この例では、NIC pci/0000:03:00.0 の e-switch モードが switchdev に設定されています。

      $ sudo devlink dev eswitch set pci/0000:03:00.0 mode switchdev

2. switchdev 対応 NIC からポートを割り当てるには、次の手順を実行します。

   1. admin ロールを持つ RHOSP ユーザーとしてログインし、binding-profile 値が capabilities の neutron ポートを作成し、ポートセキュリティーを無効にします。

      重要

      OpenFlow フローをハードウェアにオフロードするには、接続追跡 (conntrack) モジュールの switchdev ポートでセキュリティーグループとポートセキュリティーを有効にする必要があります。

      $ openstack port create --network private --vnic-type=direct --binding-profile '{"capabilities": ["switchdev"]}' direct_port1 --disable-port-security

   2. インスタンスの作成時にこのポート情報を渡します。

      レプリゼンターポートをインスタンスの VF インターフェイスに関連付け、ワンタイム OVS データパス処理のためにレプリゼンターポートを OVS ブリッジ br-int に接続します。VF ポートのレプリゼンターは、物理 “パッチパネル” フロントエンドのソフトウェアバージョンのように機能します。

      新しいインスタンスの作成の詳細は、「SR-IOV または OVS TC-flower ハードウェアオフロード環境でのインスタンスの作成」 を参照してください。

3. インターフェイスおよびレプリゼンターポートに以下の設定を適用し、TC Flower がポートレベルでフロープログラミングをプッシュするようにします。

    $ sudo ethtool -K <device-name> hw-tc-offload on

4. パフォーマンスを向上させるための、各ネットワークインターフェイスチャンネル数を調整します。

   チャンネルには、割り込み要求 (IRQ) および IRQ のトリガーとなるキューのセットが含まれます。mlx5_core ドライバーを switchdev モードに設定すると、mlx5_core ドライバーはデフォルトである単一の結合チャンネルに設定されます。この設定では、最適なパフォーマンスを得られない可能性があります。

   Physical Function (PF) マネージャーで次のコマンドを実行して、ホストで使用可能な CPU の数を調整します。

   例

   この例では、ネットワークインターフェイス eno3s0f0 の多目的チャネルの数が 3 に設定されています。

   $ sudo ethtool -L enp3s0f0 combined 3

手順

1. 集約グループを作成し、関連するホストを追加します。

   定義するフレーバーメタデータに一致するメタデータを定義します (例: sriov=true)。

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

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

   $ openstack flavor create <flavor> --ram <size_mb> --disk <size_gb> \
   --vcpus <number>

3. 追加のフレーバー属性を設定します。

   定義したメタデータ (sriov=true) と SR-IOV アグリゲートで定義したメタデータが一致している点に注意してください。

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

手順

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

   $ openstack flavor create <flavor_name> --ram <size_mb> \
   --disk <size_gb> --vcpus <number>

   ヒント

   フレーバーに追加スペック hw:pci_numa_affinity_policy を追加して、PCI パススルーデバイスおよび SR-IOV インターフェイスの NUMA アフィニティーポリシーを指定することができます。詳細は、インスタンス作成のための Compute サービスの設定 の フレーバーメタデータ を参照してください。

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

   $ openstack network create <network_name> \
   --provider-physical-network tenant \
   --provider-network-type vlan --provider-segment <vlan_id>
   
   $ openstack subnet create <name> --network <network_name> \
   --subnet-range <ip_address_cidr> --dhcp

3. admin ロールを持つ RHOSP ユーザーでない場合は、インスタンスを作成するために必要な VF または PF を RHOSP 管理者が提供できます。手順 5 に進みます。

4. admin ロールを持つ RHOSP ユーザーの場合は、VF ポートまたは PF ポートを作成できます。

   • VF ポート:

     $ openstack port create --network <network_name> --vnic-type direct \
     --binding-profile '{"capabilities": ["switchdev"]} <port_name>

   • 単一インスタンス専用の PF ポート:

     この PF ポートは Networking サービス (neutron) ポートですが、Networking サービスによって制御されておらず、インスタンスにパススルーされる PCI デバイスであるため、ネットワークアダプターとして表示されません。

     $ openstack port create --network <network_name> \
     --vnic-type direct-physical <port_name>

5. インスタンスを作成します。

   $ openstack server create --flavor <flavor> --image <image_name> \
   --nic port-id=<id> <instance_name>

手順

1. デプロイメント時に、ホストネットワーク設定ツール os-net-config を使用して hw-tc-offload を有効にします。
2. Compute ノードをリブートするたびに、sriov_config サービスで hw-tc-offload を有効にします。

3. ボンディングに接続されている NIC について、hw-tc-offload パラメーターを on に設定します。

   例

   $ ethtool -k ens1f0 | grep tc-offload
   
   hw-tc-offload: on

手順

1. HW オフロードに使用するインターフェイスの eswitch モードを switchdev に設定します。
2. ホストネットワーク設定ツール os-net-config を使用して、デプロイメント時に eswitch を有効にします。

3. Compute ノードをリブートするたびに、sriov_config サービスで eswitch を有効にします。

   例

   $ devlink dev eswitch show pci/$(ethtool -i ens1f0 | grep bus-info \
   | cut -d ':' -f 2,3,4 | awk '{$1=$1};1')

手順

1. Broadcom チップのルーティングテーブルの内容を取得するには、bcmcmd コマンドを使用します。

   $ cl-bcmcmd l2 show

   出力例

   mac=00:02:00:00:00:08 vlan=2000 GPORT=0x2 modid=0 port=2/xe1
   mac=00:02:00:00:00:09 vlan=2000 GPORT=0x2 modid=0 port=2/xe1 Hit

2. トラフィック制御 (TC) レイヤーを検査します。

   $ tc -s filter show dev p5p1_1 ingress

   出力例

   …
   filter block 94 protocol ip pref 3 flower chain 5
   filter block 94 protocol ip pref 3 flower chain 5 handle 0x2
     eth_type ipv4
     src_ip 172.0.0.1
     ip_flags nofrag
     in_hw in_hw_count 1
           action order 1: mirred (Egress Redirect to device eth4) stolen
           index 3 ref 1 bind 1 installed 364 sec used 0 sec
           Action statistics:
           Sent 253991716224 bytes 169534118 pkt (dropped 0, overlimits 0 requeues 0)
           Sent software 43711874200 bytes 30161170 pkt
           Sent hardware 210279842024 bytes 139372948 pkt
           backlog 0b 0p requeues 0
           cookie 8beddad9a0430f0457e7e78db6e0af48
           no_percpu

3. この出力で in_hw フラグおよび統計値を調べます。hardware という言葉は、ハードウェアがネットワークトラフィックを処理していることを示しています。tc-policy=none を使用する場合は、この出力または tcpdump を確認して、ハードウェアまたはソフトウェアがパケットを処理するタイミングを調べることができます。ドライバーがパケットをオフロードできない場合は、dmesg または ovs-vswitch.log に対応するログメッセージが表示されます。

4. Mellanox を例に取ると、ログエントリーは dmesg の徴候メッセージに類似しています。

   出力例

   [13232.860484] mlx5_core 0000:3b:00.0: mlx5_cmd_check:756:(pid 131368): SET_FLOW_TABLE_ENTRY(0x936) op_mod(0x0) failed, status bad parameter(0x3), syndrome (0x6b1266)

   この例では、エラーコード (0x6b1266) は以下の動作を表します。

   出力例

   0x6B1266 |  set_flow_table_entry: pop vlan and forward to uplink is not allowed

手順

1. システムで SR-IOV および VT-d が有効であることを確認します。
2. たとえば GRUB を使用して、カーネルパラメーターに intel_iommu=on を追加して Linux の IOMMU を有効にします。

手順

1. オフロードモジュールのロギングを有効にし、この障害に関する追加のログ情報を取得するには、Compute ノードで以下のコマンドを使用します。

   ovs-appctl vlog/set dpif_netlink:file:dbg
   # Module name changed recently (check based on the version used
   ovs-appctl vlog/set netdev_tc_offloads:file:dbg [OR] ovs-appctl vlog/set netdev_offload_tc:file:dbg
   ovs-appctl vlog/set tc:file:dbg

2. 再度 ovs-vswitchd ログを調べ、問題に関する追加情報を確認します。

   以下に示すログの例では、サポートされない属性マークが原因でオフロードに失敗しています。

    2020-01-31T06:22:11.218Z|00471|dpif_netlink(handler402)|DBG|system@ovs-system: put[create] ufid:61bd016e-eb89-44fc-a17e-958bc8e45fda recirc_id(0),dp_hash(0/0),skb_priority(0/0),in_port(7),skb_mark(0),ct_state(0/0),ct_zone(0/0),ct_mark(0/0),ct_label(0/0),eth(src=fa:16:3e:d2:f5:f3,dst=fa:16:3e:c4:a3:eb),eth_type(0x0800),ipv4(src=10.1.1.8/0.0.0.0,dst=10.1.1.31/0.0.0.0,proto=1/0,tos=0/0x3,ttl=64/0,frag=no),icmp(type=0/0,code=0/0), actions:set(tunnel(tun_id=0x3d,src=10.10.141.107,dst=10.10.141.124,ttl=64,tp_dst=4789,flags(df|key))),6
   
   2020-01-31T06:22:11.253Z|00472|netdev_tc_offloads(handler402)|DBG|offloading attribute pkt_mark isn't supported
   
   2020-01-31T06:22:11.257Z|00473|dpif_netlink(handler402)|ERR|failed to offload flow: Operation not supported: p6p1_5

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. Ansible Playbook YAML ファイル (例: /home/stack/cli-overcloud-tuned-maxpower-conf.yaml) を作成します。

4. cli-overcloud-tuned-maxpower-conf.yaml ファイルに次の設定を追加します。

   cat <<EOF > /home/stack/cli-overcloud-tuned-maxpower-conf.yaml
   {% raw %}
   ---
   #/home/stack/cli-overcloud-tuned-maxpower-conf.yaml
   - name: Overcloud Node set tuned power state
     hosts: compute-0 compute-1
     any_errors_fatal: true
     gather_facts: false
     pre_tasks:
       - name: Wait for provisioned nodes to boot
         wait_for_connection:
           timeout: 600
           delay: 10
         connection: local
     tasks:
       - name: Check the max power state for this system
         become: true
         block:
           - name: Get power states
             shell: "for s in /sys/devices/system/cpu/cpu2/cpuidle/*; do grep . $s/{name,latency}; done"
             register: _list_of_power_states
           - name: Print available power states
             debug:
               msg: "{{ _list_of_power_states.stdout.split('\n') }}"
           - name: Check for active tuned power-save profile
             stat:
               path: "/etc/tuned/active_profile"
             register: _active_profile
           - name: Check the profile
             slurp:
               path: "/etc/tuned/active_profile"
             when: _active_profile.stat.exists
             register: _active_profile_name
           - name: Print states
             debug:
               var: (_active_profile_name.content|b64decode|string)
           - name: Check the max power state for this system
             block:
               - name: Check if the cstate config is present in the conf file
                 lineinfile:
                   dest: /etc/tuned/cpu-partitioning-powersave-variables.conf
                   regexp: '^max_power_state'
                   line: 'max_power_state=cstate.name:C6'
                 register: _cstate_entry_check
   {% endraw %}
   EOF

5. ロールデータファイルに省電力プロファイルを追加します。

   詳細は、10.2. ロールとイメージファイルの生成 を参照してください。

6. cli-overcloud-tuned-maxpower-conf.yaml Playbook をベアメタルノード定義ファイルに追加します。

   詳細は、10.5. ベアメタルノード定義ファイルの作成 を参照してください。

7. NIC 設定テンプレートでキューサイズが設定されていることを確認します。

   詳細は、10.6. NIC 設定テンプレートの作成 を参照してください。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. Controller ロールと ComputeOvsDpdk ロールを含む新しいロールデータファイル (例: roles_data_compute_ovsdpdk.yaml) を生成します。

   $ openstack overcloud roles generate \
   -o /home/stack/templates/roles_data_compute_ovsdpdk.yaml \
   Controller ComputeOvsDpdk

   注記

   RHOSP 環境で OVS-DPDK、SR-IOV、および OVS ハードウェアオフロードなどの複数のテクノロジーを使用している場合は、すべてのロールを含めるために 1 つのロールデータファイルを生成します。

   $ openstack overcloud roles generate -o /home/stack/templates/\
   roles_data.yaml Controller ComputeOvsDpdk ComputeOvsDpdkSriov \
   Compute:ComputeOvsHwOffload

4. オプション: TuneD プロファイル cpu-partitioning-powersave を使用して、パケットが転送されていないときに OVS-DPDK がスリープモードに入るように設定できます。

   cpu-partitioning-powersave を設定するには、生成されたロールデータファイル内のデフォルトの TuneD プロファイルを省電力 TuneD プロファイル cpu-partitioning-powersave に置き換えます。

   TunedProfileName: "cpu-partitioning-powersave"

   例

   この生成されたロールデータファイル (/home/stack/templates/roles_data_compute_ovsdpdk.yaml) では、TunedProfileName のデフォルト値が cpu-partitioning-powersave に置き換えられます。

   $ sed -i \
   's/TunedProfileName:.*$/TunedProfileName: "cpu-partitioning-powersave"/' \
   /home/stack/templates/roles_data_compute_ovsdpdk.yaml

5. イメージファイルを生成するには、openstack tripleo container image prepare コマンドを実行します。以下の入力が必要です。

   • 前の手順で生成したロールデータファイル (例: roles_data_compute_ovsdpdk.yaml)。

   • Networking サービスメカニズムドライバーに適した DPDK 環境ファイル:

     • ML2/OVN 環境用の neutron-ovn-dpdk.yaml ファイル。

     • ML2/OVS 環境用の neutron-ovs-dpdk.yaml ファイル。

       例

       この例では、overcloud_images.yaml ファイルが ML2/OVN 環境用に生成されています。

       $ sudo openstack tripleo container image prepare \
         --roles-file ~/templates/roles_data_compute_ovsdpdk.yaml \
         -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovn-dpdk.yaml \
         -e ~/containers-prepare-parameter.yaml \
         --output-env-file=/home/stack/templates/overcloud_images.yaml

6. 作成したロールデータファイルとイメージファイルのパスとファイル名をメモします。これらのファイルは、後でオーバークラウドをデプロイするときに使用します。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. カスタム環境 YAML ファイル (例: ovs-dpdk-overrides.yaml) を作成します。

4. カスタム環境ファイルで、コンピュートサービス (nova) がノードをフィルタリングするために使用する NovaSchedulerEnabledFilters パラメーターのフィルターリストに AggregateInstanceExtraSpecsFilter が含まれていることを確認します。

   parameter_defaults:
     NovaSchedulerEnabledFilters:
       - AvailabilityZoneFilter
       - ComputeFilter
       - ComputeCapabilitiesFilter
       - ImagePropertiesFilter
       - ServerGroupAntiAffinityFilter
       - ServerGroupAffinityFilter
       - PciPassthroughFilter
       - AggregateInstanceExtraSpecsFilter

5. OVS-DPDK コンピュートノードのロール固有のパラメーターをカスタム環境ファイルに追加します。

   例

   parameter_defaults:
     ComputeOvsDpdkParameters:
       NeutronBridgeMappings: "dpdk:br-dpdk"
       KernelArgs: "default_hugepagesz=1GB hugepagesz=1GB hugepages=64 iommu=pt intel_iommu=on isolcpus=2,4,6,8,10,12,14,16,18,22,24,26,28,30,32,34,36,38,3,5,7,9,11,13,15,17,19,23,25,27,29,31,33,35,37,39"
       TunedProfileName: "cpu-partitioning"
       IsolCpusList: "2,4,6,8,10,12,14,16,18,22,24,26,28,30,32,34,36,38,3,5,7,9,11,13,15,17,19,23,25,27,29,31,33,35,37,39"
       NovaReservedHostMemory: 4096
       OvsDpdkSocketMemory: "4096,4096"
       OvsDpdkMemoryChannels: "4"
       OvsDpdkCoreList: "0,20,1,21"
       NovaComputeCpuDedicatedSet: "4,6,8,10,12,14,16,18,24,26,28,30,32,34,36,38,5,7,9,11,13,15,17,19,27,29,31,33,35,37,39"
       NovaComputeCpuSharedSet: "0,20,1,21"
       OvsPmdCoreList: "2,22,3,23"

6. これらのファイル内の設定デフォルトをオーバーライドする必要がある場合は、手順 3 で作成したカスタム環境ファイルにオーバーライドを追加します。

   RHOSP director は、OVS-DPDK を設定するために次のファイルを使用します。

   • ML2/OVN のデプロイメント

     /usr/share/openstack-tripleo-heat-templates/environment/services/neutron-ovn-dpdk.yaml

   • ML2/OVS のデプロイメント

     /usr/share/openstack-tripleo-heat-templates/environment/services/neutron-ovs-dpdk.yaml

7. 作成したカスタム環境ファイルのパスとファイル名をメモします。このファイルは、後でオーバークラウドをデプロイするときに使用します。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. 「OVS-DPDK カスタマイズ用の環境ファイルの作成」 に作成したカスタム環境 YAML ファイルを開くか、新しいものを作成します。

4. parameter_defaults の下に、次のキーと値のペアを追加します。

   parameter_defaults:
   ...
   
     NeutronOVSFirewallDriver: openvswitch

5. 新しいカスタム環境ファイルを作成した場合は、そのパスとファイル名をメモします。このファイルは、後でオーバークラウドをデプロイするときに使用します。

6. オーバークラウドをデプロイした後、openstack port set コマンドを実行して、データプレーンインターフェイスの OVS ファイアウォールドライバーを無効にします。

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

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのベアメタルノードのプロビジョニング の指示に従って、overcloud-baremetal-deploy.yaml などのベアメタルノード定義ファイルを作成します。

4. overcloud-baremetal-deploy.yaml ファイルで、Ansible Playbook cli-overcloud-node-kernelargs.yaml に宣言を追加します。Playbook には、ベアメタルノードをプロビジョニングするときに使用するカーネル引数が含まれています。

   - name: ComputeOvsDpdk
   ...
     ansible_playbooks:
       - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-kernelargs.yaml
   ...

5. Playbook の実行時に追加の Ansible 変数を設定する場合は、extra_vars プロパティーを使用して設定します。

   詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの ベアメタルノードのプロビジョニング属性 を参照してください。

   注記

   extra_vars に追加する変数は、先ほど OVS-DPDK カスタマイズ用の環境ファイルを作成する でカスタム環境ファイルに追加した OVS-DPDK コンピュートノードのロール固有のパラメーターと同じである必要があります。

   例

   - name: ComputeOvsDpdk
     ...
     ansible_playbooks:
     - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-kernelargs.yaml
       extra_vars:
         kernel_args: 'default_hugepagesz=1GB hugepagesz=1GB hugepages=64 iommu=pt intel_iommu=on isolcpus=2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39'
         tuned_isolated_cores: '2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39'
         tuned_profile: 'cpu-partitioning'
         reboot_wait_timeout: 1800
     - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-openvswitch-dpdk.yaml
       extra_vars:
         pmd: '2,22,3,23'
         memory_channels: '4'
         socket_mem: '4096,4096'
         pmd_auto_lb: true
         pmd_load_threshold: "70"
         pmd_improvement_threshold: "25"
         pmd_rebal_interval: "2"

6. オプション: TuneD プロファイル cpu-partitioning-powersave を使用して、パケットが転送されていないときに OVS-DPDK がスリープモードに入るように設定できます。

   cpu-partitioning-powersave を設定するには、ベアメタルノード定義ファイルに次の行を追加します。

   ...
   
   tuned_profile: "cpu-partitioning-powersave"
   
   ...
   
     - playbook: /home/stack/ospd-17.1-geneve-ovn-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/playbooks/cli-overcloud-tuned-maxpower-conf.yaml
     - playbook: /home/stack/ospd-17.1-geneve-ovn-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/playbooks/overcloud-nm-config.yaml
       extra_vars:
         reboot_wait_timeout: 900
   
   ...
   
         pmd_sleep_max: "50"
   
   ...

   例

   - name: ComputeOvsDpdk
     ...
     ansible_playbooks:
     - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-node-kernelargs.yaml
       extra_vars:
         kernel_args: default_hugepagesz=1GB hugepagesz=1GB hugepages=64 iommu=pt intel_iommu=on isolcpus=2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39
         tuned_isolated_cores: 2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39
         tuned_profile: cpu-partitioning
         reboot_wait_timeout: 1800
     - playbook: /home/stack/ospd-17.1-geneve-ovn-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/playbooks/cli-overcloud-tuned-maxpower-conf.yaml
     - playbook: /home/stack/ospd-17.1-geneve-ovn-dpdk-sriov-ctlplane-dataplane-bonding-hybrid/playbooks/overcloud-nm-config.yaml
       extra_vars:
         reboot_wait_timeout: 900
     - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-openvswitch-dpdk.yaml
       extra_vars:
         pmd: 2,22,3,23
         memory_channels: 4
         socket_mem: 4096,4096
         pmd_auto_lb: true
         pmd_load_threshold: "70"
         pmd_improvement_threshold: "25"
         pmd_rebal_interval: "2"
         pmd_sleep_max: "50"

7. 作成したベアメタルノード定義ファイルのパスとファイル名をメモします。このファイルは、後で NIC を設定するときに使用し、ノードをプロビジョニングするときに overcloud node provision コマンドの入力ファイルとして使用します。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. サンプルネットワーク設定テンプレートをコピーします。

   /usr/share/ansible/roles/tripleo_network_config/templates/ ディレクトリー内の例から NIC 設定 Jinja2 テンプレートをコピーします。NIC 要件に最も近いものを選択してください。必要に応じて変更してください。

4. NIC 設定テンプレート (例: single_nic_vlans.j2) に、DPDK インターフェイスを追加します。

   注記

   サンプル NIC 設定テンプレート single_nic_vlans.j2 では、ノードが VLAN を持つトランクとして 1 つのネットワークインターフェイスのみを使用します。ネイティブ VLAN (タグなしトラフィック) はコントロールプレーンであり、各 VLAN は RHOSP ネットワーク (内部 API、ストレージなど) の 1 つに対応します。

   例

   ...
     - type: ovs_dpdk_bond
       name: dpdkbond0
       mtu: 9000
       rx_queue: 1
       ovs_extra:
         - set Interface dpdk0 options:n_rxq_desc=4096
         - set Interface dpdk0 options:n_txq_desc=4096
         - set Interface dpdk1 options:n_rxq_desc=4096
         - set Interface dpdk1 options:n_txq_desc=4096
       members:
       - type: ovs_dpdk_port
         name: dpdk0
         driver: vfio-pci
         members:
         - type: interface
           name: nic5
       - type: ovs_dpdk_port
         name: dpdk1
         driver: vfio-pci
         members:
         - type: interface
           name: nic6
   ...

5. カスタムネットワーク設定テンプレート (例: single_nic_vlans.j2) を、「ベアメタルノード定義ファイルの作成」 で作成したベアメタルノード定義ファイル (例: overcloud-baremetal-deploy.yaml) に追加します。

   例

   - name: ComputeOvsDpdk
     count: 2
     hostname_format: compute-%index%
     defaults:
       networks:
         - network: internal_api
           subnet: internal_api_subnet
         - network: tenant
           subnet: tenant_subnet
         - network: storage
           subnet: storage_subnet
       network_config:
         template: /home/stack/templates/single_nic_vlans.j2
   ...

6. オプション: TuneD プロファイル cpu-partitioning-powersave を使用して、パケットが転送されていないときに OVS-DPDK がスリープモードに入るように設定できます。

   cpu-partitioning-powersave を設定するには、NIC 設定テンプレートでキューサイズが設定されていることを確認してください。

   例

   ...
     - type: ovs_dpdk_bond
       name: dpdkbond0
       mtu: 9000
       rx_queue: 1
       ovs_extra:
         - set Interface dpdk0 options:n_rxq_desc=4096
         - set Interface dpdk0 options:n_txq_desc=4096
         - set Interface dpdk1 options:n_rxq_desc=4096
         - set Interface dpdk1 options:n_txq_desc=4096
       members:
       - type: ovs_dpdk_port
         name: dpdk0
         driver: vfio-pci
         members:
         - type: interface
           name: nic5
       - type: ovs_dpdk_port
         name: dpdk1
         driver: vfio-pci
         members:
         - type: interface
           name: nic6
   ...

7. 作成した NIC 設定テンプレートのパスとファイル名をメモします。このファイルは、後でオーバークラウドをデプロイするときに使用します。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. 「OVS-DPDK カスタマイズ用の環境ファイルの作成」 に作成したカスタム環境 YAML ファイルを開くか、新しいものを作成します。

4. parameter_defaults の下で NeutronGlobalPhysnetMtu パラメーターを設定します。

   例

   この例では、NeutronGlobalPhysnetMtu は 9000 に設定されています。

   parameter_defaults:
     # MTU global configuration
     NeutronGlobalPhysnetMtu: 9000

   注記

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

5. 「NIC 設定テンプレートの作成」 で作成した NIC 設定テンプレート (例: single_nic_vlans.j2) を開きます。

6. ブリッジ上の MTU 値をコンピュートノードに設定します。

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

7. 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. NIC 設定テンプレートとカスタム環境ファイルのパスとファイル名をメモします。これらのファイルは、後でオーバークラウドをデプロイするときに使用します。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. 「NIC 設定テンプレートの作成」 で作成した NIC 設定テンプレート (例: single_nic_vlans.j2) を開きます。

4. コンピュートノード上の OVS-DPDK のインターフェイスのキューの数を設定します。

   - 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

5. NIC 設定テンプレートのパスとファイル名をメモします。このファイルは、後でオーバークラウドをデプロイするときに使用します。

手順

1. アンダークラウドに stack ユーザーとしてログインします。

2. stackrc ファイルを取得します。

   $ source ~/stackrc

3. 「ベアメタルノード定義ファイルの作成」 に作成したベアメタルノード定義ファイルにパラメーターを設定します (例: overcloud-baremetal-deploy.yaml)。

   pmd_auto_lb

   PMD 自動ロードバランシングを有効にするには、true に設定します。

   pmd_load_threshold

   PMD ロードバランスをトリガーする前に、1 つの PMD スレッドで一貫して使用する必要がある処理サイクルの割合。0 - 100 の範囲の整数。

   pmd_improvement_threshold

   PMD 自動ロードバランシングをトリガーする、非分離 PMD スレッド全体で評価された改善の最小パーセンテージ。0 - 100 の範囲の整数。

   推定される改善を計算するために、再割り当てのドライランを実行し、推定不可分散と現在の分散を比較します。デフォルトは 25% です。

   pmd_rebal_interval

   2 つの連続する PMD 自動ロードバランシングが実施される間の最小時間 (分単位)。範囲は 0 - 20,000 分です。

   トラフィックパターンが変更可能な場合に、再割り当てが頻繁に発生しないようにするには、この値を設定します。たとえば、10 分に 1 回、または数時間に 1 回、再割り当てをトリガーできます。

   例

   ansible_playbooks:
   …
     - playbook: /usr/share/ansible/tripleo-playbooks/cli-overcloud-openvswitch-dpdk.yaml
     extra_vars:
      …
      pmd_auto_lb: true
      pmd_load_threshold: "70"
      pmd_improvement_threshold: "25"
      pmd_rebal_interval: "2"

4. 「OVS-DPDK カスタマイズ用の環境ファイルの作成」 に作成したカスタム環境 YAML ファイルを開くか、新しいものを作成します。

5. カスタム環境ファイルに、手順 3 で設定したのと同じベアメタルノードの事前プロビジョニング値を追加します。次の同等のパラメーターを使用します。

   OvsPmdAutoLb

   pmd_auto_lb と同等の heat。

   PMD 自動ロードバランシングを有効にするには、true に設定します。

   OvsPmdLoadThreshold

   pmd_load_threshold と同等の heat。

   PMD ロードバランスをトリガーする前に、1 つの PMD スレッドで一貫して使用する必要がある処理サイクルの割合。0 - 100 の範囲の整数。

   OvsPmdImprovementThreshold

   pmd_improvement_threshold と同等の heat。

   PMD 自動ロードバランシングをトリガーする、非分離 PMD スレッド全体で評価された改善の最小パーセンテージ。0 - 100 の範囲の整数。

   推定される改善を計算するために、再割り当てのドライランを実行し、推定不可分散と現在の分散を比較します。デフォルトは 25% です。

   OvsPmdRebalInterval

   pmd_rebal_interval と同等の heat。

   2 つの連続する PMD 自動ロードバランシングが実施される間の最小時間 (分単位)。範囲は 0 - 20,000 分です。

   トラフィックパターンが変更可能な場合に、再割り当てが頻繁に発生しないようにするには、この値を設定します。たとえば、10 分に 1 回、または数時間に 1 回、再割り当てをトリガーできます。

   例

   parameter_merge_strategies:
     ComputeOvsDpdkSriovParameters:merge
   …
   parameter_defaults:
     ComputeOvsDpdkSriovParameters:
      …
      OvsPmdAutoLb: true
      OvsPmdLoadThreshold: 70
      OvsPmdImprovementThreshold: 25
      OvsPmdRebalInterval: 2

6. NIC 設定テンプレートとカスタム環境ファイルのパスとファイル名をメモします。これらのファイルは、後でベアメタルノードをプロビジョニングし、オーバークラウドをデプロイするときに使用します。

次のステップ

1. ネットワークと仮想 IP をプロビジョニングします。

2. ベアメタルノードをプロビジョニングする。

   provision コマンドを実行するための入力として、overcloud-baremetal-deploy.yaml などのベアメタルノード定義ファイルを使用するようにしてください。

3. 「OVS-DPDK オーバークラウドのデプロイ」 に進みます。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. openstack overcloud deploy コマンドを実行します。

   openstack overcloud deploy コマンドへの入力を特定の順序でリストすることが重要です。一般的なルールは、デフォルトの heat テンプレートファイルを最初に指定し、次にカスタム環境ファイルと、デフォルトプロパティーのオーバーライドなどのカスタム設定を含むカスタムテンプレートを指定することです。

   次の順序で、openstack overcloud deploy コマンドに入力を追加します。

   1. オーバークラウド上の SR-IOV ネットワークの仕様が含まれるカスタムネットワーク定義ファイル (例: network-data.yaml)。

      詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの ネットワーク定義ファイル設定のオプション を参照してください。

   2. RHOSP director が SR-IOV 環境をデプロイするために使用する Controller および ComputeOvsDpdk ロールを含むロールファイル。

      例: roles_data_compute_ovsdpdk.yaml

      詳細は、「ロールとイメージファイルの生成」 を参照してください。

   3. オーバークラウドネットワークのプロビジョニングからの出力ファイル。

      例: overcloud-networks-deployed.yaml

      詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのネットワーク定義の設定とプロビジョニング を参照してください。

   4. オーバークラウド仮想 IP のプロビジョニングからの出力ファイル。

      例: overcloud-vip-deployed.yaml

      詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのネットワーク仮想 IP の設定とプロビジョニング を参照してください。

   5. ベアメタルノードのプロビジョニングからの出力ファイル。

      たとえば、overcloud-baremetal-deployed.yaml です。

      詳細は以下を参照してください。

      • 「ノードプロビジョニング用の DPDK パラメーターの設定」。
      • director を使用した Red Hat OpenStack Platform のインストールと管理 ガイドの オーバークラウドのベアメタルノードのプロビジョニング

   6. コンテナーイメージを取得する場所と保存方法を決定するためにディレクターが使用するイメージファイル。

      例: overcloud_images.yaml

      詳細は、「ロールとイメージファイルの生成」 を参照してください。

   7. 環境が使用する Networking サービス (neutron) メカニズムドライバーとルータースキームの環境ファイル:

      • ML2/OVN

        • 分散仮想ルーティング (DVR): neutron-ovn-dvr-ha.yaml
        • 集中型仮想ルーティング: neutron-ovn-ha.yaml

      • ML2/OVS

        • 分散仮想ルーティング (DVR): neutron-ovs-dvr.yaml
        • 集中型仮想ルーティング: neutron-ovs.yaml

   8. メカニズムドライバーに応じた OVS-DPDK の環境ファイル:

      • ML2/OVN

        • neutron-ovn-dpdk.yaml

      • ML2/OVS

        • neutron-ovs-dpdk.yaml

          注記

          SR-IOV 環境もあり、SR-IOV インスタンスと OVS-DPDK インスタンスを同じノードに配置する場合は、デプロイメントスクリプトに次の環境ファイルを含めます。

          • ML2/OVN

            neutron-ovn-sriov.yaml

          • ML2/OVS

            neutron-sriov.yaml

   9. 以下の設定を含む 1 つ以上のカスタム環境ファイル:

      • OVS-DPDK 環境のデフォルト設定値を上書きします。
      • 仮想ネットワーク機能 (VNF) としてのファイアウォール。

      • ジャンボフレームの最大転送単位 (MTU) 値。

        例: ovs-dpdk-overrides.yaml

        詳細は以下を参照してください。

      • 「OVS-DPDK カスタマイズ用の環境ファイルの作成」。
      • 「セキュリティーグループのファイアウォールの設定」。

      • 「OVS-DPDK インターフェイスの MTU 値の設定」。

        例

        サンプルの openstack overcloud deploy コマンドからのこの抜粋は、DVR を使用する OVS-DPDK、ML2/OVN 環境のコマンド入力の適切な順序を示しています。

        $ openstack overcloud deploy \
        --log-file overcloud_deployment.log \
        --templates /usr/share/openstack-tripleo-heat-templates/ \
        --stack overcloud \
        -n /home/stack/templates/network_data.yaml \
        -r /home/stack/templates/roles_data_compute_ovsdpdk.yaml \
        -e /home/stack/templates/overcloud-networks-deployed.yaml \
        -e /home/stack/templates/overcloud-vip-deployed.yaml \
        -e /home/stack/templates/overcloud-baremetal-deployed.yaml \
        -e /home/stack/templates/overcloud-images.yaml \
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/\
        neutron-ovn-dvr-ha.yaml
        -e /usr/share/openstack-tripleo-heat-templates/environments/services/\
        neutron-ovn-dpdk.yaml \
        -e /home/stack/templates/ovs-dpdk-overrides.yaml

4. openstack overcloud deploy コマンドを実行します。

   オーバークラウドの作成が完了すると、RHOSP director は、オーバークラウドへのアクセスに役立つ詳細を提供します。

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

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

   注記

   CPU ピニングを設定したインスタンスと設定していないインスタンスを、同じ Compute ノードに配置することができます。詳細は、インスタンス作成のための Compute サービスの設定 の Compute ノードでの CPU ピンニングの設定 を参照してください。

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

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

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

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

   パフォーマンス向上のためのエミュレータースレッドポリシーの詳細は、インスタンス作成のための Compute サービスの設定 の エミュレータースレッドの設定 を参照してください。

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

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

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

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

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

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

1. ブリッジの詳細を調べ、datapath_type=netdev の設定を確認します。

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

2. オプションとして、コンテナーが起動に失敗したかどうかなど、エラーをログで確認することができます。

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

3. ovs-dpdk の Poll Mode Driver CPU マスクが CPU にピニングされていることを確認します。ハイパースレッディングの場合は、シブリング CPU を使用します。

   たとえば、CPU4 のシブリングを確認するには、以下のコマンドを実行します。

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

   CPU4 のシブリングは CPU20 なので、続いて以下のコマンドを実行します。

   # 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

手順

1. 特定のロールに NovaComputeCpuSharedSet を定義してオーバークラウドをデプロイします。NovaComputeCpuSharedSet の値は、そのロール内のホストの nova.conf ファイルの cpu_shared_set パラメーターに適用されます。

   parameter_defaults:
       ComputeOvsDpdkParameters:
           NovaComputeCpuSharedSet: "0-1,16-17"
           NovaComputeCpuDedicatedSet: "2-15,18-31"

2. エミュレータースレッドが共有プールに分離されたインスタンスをビルドするためのフレーバーを作成します。

   openstack flavor create --ram <size_mb> --disk <size_gb> --vcpus <vcpus> <flavor>

3. hw:emulator_threads_policy 追加仕様を追加し、値を share に設定します。このフレーバーで作成されたインスタンスは、nova.conf ファイルの cpu_share_set パラメーターで定義されたインスタンス CPU を使用します。

   openstack flavor set <flavor> --property hw:emulator_threads_policy=share

検証

1. 対象インスタンスのホストおよび名前を特定します。

   openstack server show <instance_id>

2. SSH を使用して、識別されたホストに tripleo-admin としてログオンします。

   ssh tripleo-admin@compute-1
   [compute-1]$ sudo virsh dumpxml instance-00001 | grep `'emulatorpin cpuset'`

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

   parameter_defaults:
     NeutronPhysicalDevMappings:
       - sriov2:p5p2

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

   parameter_defaults:
     NeutronPhysicalDevMappings:
       - sriov2:p5p2
     NovaPCIPassthrough:
       - vendor_id: "8086"
         product_id: "1572"
         physical_network: "sriov2"
         trusted: "true"

   注記

   "true" のように、値を二重引用符で囲む必要があります。

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

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

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

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

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

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

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

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

1. インスタンスを作成した Compute ノード上で、以下のコマンドを入力します。

   # ip link
   7: p5p2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 1000
       link/ether b4:96:91:1c:40:fa brd ff:ff:ff:ff:ff:ff
       vf 6 MAC fa:16:3e:b8:91:c2, vlan 111, spoof checking off, link-state auto, trust on, query_rss off
       vf 7 MAC fa:16:3e:84:cf:c8, vlan 111, spoof checking off, link-state auto, trust off, query_rss off

2. VF の信頼ステータスが trust on であることを確認します。上記の出力例には、2 つのポートが含まれる環境の詳細が示されています。vf 6 に trust on のテキストが含まれている点に注意してください。
3. Networking サービス (neutron) ネットワークで port_security_enabled: false を設定した場合、あるいは openstack port create コマンドの実行時に引数 --disable-port-security を含める場合には、スプーフィングの確認を無効にできます。

手順

1. アンダークラウドホストに stack ユーザーとしてログインします。

2. stackrc アンダークラウド認証情報ファイルを入手します。

   $ source ~/stackrc

3. カスタム環境 YAML ファイルを作成し、parameter_defaults の下に次の定義を追加して、RX および TX キューのサイズを増やします。

   parameter_defaults:
     NovaLibvirtRxQueueSize: 1024
     NovaLibvirtTxQueueSize: 1024

4. デプロイコマンドを実行します。コア Heat テンプレート、その他の環境ファイル、RX および TX キューサイズの変更を含む環境ファイルをコマンドに追加します。

   例

   $ openstack overcloud deploy --templates \
   -e <other_environment_files> \
   -e /home/stack/my_tx-rx_queue_sizes.yaml

検証

1. nova.conf ファイル内の RX キューサイズと TX キューサイズの値を確認します。

   $ egrep "^[rt]x_queue_size" /var/lib/config-data/puppet-generated/\
   nova_libvirt/etc/nova/nova.conf

   以下のメッセージが表示されるはずです。

   rx_queue_size=1024
   tx_queue_size=1024

2. Compute ホストの libvirt により生成された仮想マシンインスタンスの XML ファイルで、RX キューサイズと TX キューサイズの値を確認します。

   1. 新規インスタンスを作成します。

   2. Compute ホストとインスタンス名を取得します。

      $ openstack server show testvm-queue-sizes -c OS-EXT-SRV-ATTR:\
      hypervisor_hostname -c OS-EXT-SRV-ATTR:instance_name

      出力例

      以下のような出力が表示されるはずです。

      +-------------------------------------+------------------------------------+
      | Field                               | Value                              |
      +-------------------------------------+------------------------------------+
      | OS-EXT-SRV-ATTR:hypervisor_hostname | overcloud-novacompute-1.sales      |
      | OS-EXT-SRV-ATTR:instance_name       | instance-00000059                  |
      +-------------------------------------+------------------------------------+

   3. Compute ホストにログインし、インスタンス定義をダンプします。

      例

      $ podman exec nova_libvirt virsh dumpxml instance-00000059

      出力例

      以下のような出力が表示されるはずです。

      ...
         <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>
      ...

手順

1. 新たに NeutronPhysnetNUMANodesMapping パラメーターを設定して、物理ネットワークと物理ネットワークに関連付ける NUMA ノードをマッピングします。

2. VxLAN や GRE 等のトンネルを使用する場合には、NeutronTunnelNUMANodes パラメーターも設定する必要があります。

   parameter_defaults:
     NeutronPhysnetNUMANodesMapping: {<physnet_name>: [<NUMA_NODE>]}
     NeutronTunnelNUMANodes: <NUMA_NODE>,<NUMA_NODE>

   例

   2 つの物理ネットワークを NUMA ノード 0 にトンネリングする例を以下に示します。

   • NUMA ノード 0 に関連付けられた 1 つのプロジェクトネットワーク

   • アフィニティーが設定されていない 1 つの管理ネットワーク

     parameter_defaults:
       NeutronBridgeMappings:
         - tenant:br-link0
       NeutronPhysnetNUMANodesMapping: {tenant: [1], mgmt: [0,1]}
       NeutronTunnelNUMANodes: 0

   • この例では、eno2 という名前のデバイスの物理ネットワークを NUMA 番号 0 に割り当てます。

     # ethtool -i eno2
     bus-info: 0000:18:00.1
     
     # cat /sys/devices/pci0000:16/0000:16:02.0/0000:18:00.1/numa_node
     0

     heat テンプレートのサンプルで物理ネットワークの設定を確認します。

     NeutronBridgeMappings: 'physnet1:br-physnet1'
     NeutronPhysnetNUMANodesMapping: {physnet1: [0] }
     
     - type: ovs_user_bridge
                     name: br-physnet1
                     mtu: 9000
                     members:
                       - type: ovs_dpdk_port
                         name: dpdk2
                         members:
                           - type: interface
                             name: eno2

1. /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf ファイルの設定を確認します。

   [neutron_physnet_tenant]
   numa_nodes=1
   [neutron_tunnel]
   numa_nodes=1

2. lscpu コマンドで新たな設定を確認します。

   $ lscpu

3. NIC が適切なネットワークに接続された仮想マシンを起動します。

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

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

   (undercloud) [stack@undercloud-0 ~]$ sudo dnf install libguestfs-tools

   重要

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

   $ sudo systemctl disable --now iscsid.socket

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

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

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

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

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

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

   注記

   コマンドプロンプトで認証情報を使用したら、履歴ファイルから認証情報を削除してセキュリティーを確保することができます。history -d コマンドの後に行番号を指定して、履歴内の個々の行を削除することができます。

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

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

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

   virt-customize -a overcloud-realtime-compute.qcow2 --run-command \
   'sudo subscription-manager repos --enable=rhel-9-for-x86_64-baseos-eus-rpms \
   --enable=rhel-9-for-x86_64-appstream-eus-rpms \
   --enable=rhel-9-for-x86_64-highavailability-eus-rpms \
   --enable=ansible-2.9-for-rhel-9-x86_64-rpms \
   --enable=rhel-9-for-x86_64-nfv-rpms
   --enable=fast-datapath-for-rhel-9-x86_64-rpms'

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

   (undercloud) [stack@undercloud-0 ~]$ cat <<'EOF' > rt.sh
     #!/bin/bash
   
     set -eux
   
     dnf -v -y --setopt=protected_packages= erase kernel.$(uname -m)
     dnf -v -y install kernel-rt kernel-rt-kvm tuned-profiles-nfv-host
     grubby --set-default /boot/vmlinuz*rt*
     EOF

8. リアルタイムイメージを設定するスクリプトを実行します。

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

   注記

   rt.sh スクリプトの出力に "grubby fatal error: unable to find a suitable template" という行が表示されても、このエラーは無視してかまいません。

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

   (undercloud) [stack@undercloud-0 ~]$ cat virt-customize.log | grep Verifying
   
     Verifying  : kernel-3.10.0-957.el7.x86_64                                 1/1
     Verifying  : 10:qemu-kvm-tools-rhev-2.12.0-18.el7_6.1.x86_64              1/8
     Verifying  : tuned-profiles-realtime-2.10.0-6.el7_6.3.noarch              2/8
     Verifying  : linux-firmware-20180911-69.git85c5d90.el7.noarch             3/8
     Verifying  : tuned-profiles-nfv-host-2.10.0-6.el7_6.3.noarch              4/8
     Verifying  : kernel-rt-kvm-3.10.0-957.10.1.rt56.921.el7.x86_64            5/8
     Verifying  : tuna-0.13-6.el7.noarch                                       6/8
     Verifying  : kernel-rt-3.10.0-957.10.1.rt56.921.el7.x86_64                7/8
     Verifying  : rt-setup-2.0-6.el7.x86_64                                    8/8

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

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

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

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

    注記

    vmlinuz および initramfs のファイル名に含まれるソフトウェアバージョンは、カーネルバージョンによって異なります。

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

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

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

   $ openstack flavor create r1.small --id 99 --ram 4096 --disk 20 --vcpus 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

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

   $ openstack server create  --image <rhel> --flavor r1.small --nic net-id=<dpdk-net> test-rt

3. 割り当てられたエミュレータースレッドをインスタンスが使用していることを確認するには、以下のコマンドを実行します。

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

1. parameter_defaults セクションで、トンネル種別を vxlan に、ネットワーク種別を vxlan,vlan に、それぞれ設定します。

   NeutronTunnelTypes: 'vxlan'
   NeutronNetworkType: 'vxlan,vlan'

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

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

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

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

   注記

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

   注記

   本手順に示したとおり、これらのヒュージページは仮想マシンと、OvsDpdkSocketMemory パラメーターを使用する OVS-DPDK によって消費されます。仮想マシンが利用可能なヒュージページの数は、boot パラメーターから OvsDpdkSocketMemory を減算した値です。

   DPDK インスタンスに関連付けるフレーバーに hw:mem_page_size=1GB も追加する必要があります。

   注記

   OvsDpdkMemoryChannels は、この手順に必須の設定です。最大限の機能を得るためには、適切なパラメーターおよび値で DPDK をデプロイするようにしてください。

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

     NovaPCIPassthrough:
       - vendor_id: "8086"
         product_id: "1528"
         address: "0000:06:00.0"
         trusted: "true"
         physical_network: "sriov-1"
       - vendor_id: "8086"
         product_id: "1528"
         address: "0000:06:00.1"
         trusted: "true"
         physical_network: "sriov-2"

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

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

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

     - type: vlan
       vlan_id:
         get_param: InternalApiNetworkVlanID
       device: bond_api
       addresses:
       - ip_netmask:
           get_param: InternalApiIpSubnet
   
     - type: vlan
       vlan_id:
         get_param: StorageNetworkVlanID
       device: bond_api
       addresses:
       - ip_netmask:
           get_param: StorageIpSubnet
   
     - type: vlan
       vlan_id:
         get_param: StorageMgmtNetworkVlanID
       device: bond_api
       addresses:
       - ip_netmask:
           get_param: StorageMgmtIpSubnet
   
     - type: vlan
       vlan_id:
         get_param: ExternalNetworkVlanID
       device: bond_api
       addresses:
       - ip_netmask:
           get_param: ExternalIpSubnet
       routes:
       - default: true
         next_hop:
           get_param: ExternalInterfaceDefaultRoute

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

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

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

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

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

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

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

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

   注記

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

   注記

   OVS-DPDK を使用する場合には、同じ Compute ノード上の全ブリッジが ovs_user_bridge の種別でなければなりません。Red Hat OpenStack Platform では、ovs_bridge と ovs_user_bridge の両方が同じノード上に存在する設定はサポートされません。