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

手順

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 Open Stack Platform 16.2 のエンタイトルメントをアタッチします。

   [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-8-for-x86_64-baseos-eus-rpms \
   --enable=rhel-8-for-x86_64-appstream-eus-rpms \
   --enable=rhel-8-for-x86_64-highavailability-eus-rpms \
   --enable=ansible-2.9-for-rhel-8-x86_64-rpms \
   --enable=openstack-16.2-for-rhel-8-x86_64-rpms \
   --enable=rhel-8-for-x86_64-nfv-rpms \
   --enable=fast-datapath-for-rhel-8-x86_64-rpms

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

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

手順

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

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

   [stack@director ~]$ source ~/stackrc

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

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

   ComputeSriov は、RHOSP インストールで提供されるカスタムロールで、デフォルトの Compute サービスに加えて、NeutronSriovAgent サービスと NeutronSriovHostConfig サービスが含まれます。

4. SR-IOV コンテナーを準備するには、overcloud_images.yaml ファイルを生成するときにneutron-sriov.yamlファイルとroles_data_compute_sriov.yamlファイルを含めます。

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

   コンテナーイメージの準備に関する詳しい情報は、director のインストールと使用方法 ガイドの コンテナーイメージの準備 を参照してください。

5. 環境ファイルディレクトリーに/usr/share/openstack-tripleo-heat-templates/environments/network-environment.yamlファイルのコピーを作成します。

   $ cp /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml /home/stack/templates/network-environment-sriov.yaml

6. network-environment-sriov.yamlファイルのparameter_defaultsに次のパラメーターを追加して、クラスターとハードウェア設定の SR-IOV ノードを設定します。

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

7. 各 PCI デバイスタイプのvendor_idおよびproduct_idを確認するには、PCI カードを備えた物理サーバーで次のコマンドのいずれかを使用します。

   • デプロイされたオーバークラウドからvendor_idとproduct_idを返すには、次のコマンドを使用します。

     # 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)

   • オーバークラウドをまだデプロイしていない場合に Physical Function (PF) のvendor_idとproduct_idを返すには、次のコマンドを使用します。

     (undercloud) [stack@undercloud-0 ~]$ openstack baremetal introspection data save <baremetal_node_name> | jq '.inventory.interfaces[] | .name, .vendor, .product'

8. network-environment-sriov.yamlファイルで SR-IOV Compute ノードのロール固有のパラメーターを設定します。

     ComputeSriovParameters:
       IsolCpusList: "1-19,21-39"
       KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on isolcpus=1-19,21-39"
       TunedProfileName: "cpu-partitioning"
       NeutronBridgeMappings:
         - tenant:br-link0
       NeutronPhysicalDevMappings:
         - tenant:p7p1
       NovaComputeCpuDedicatedSet: '1-19,21-39'
       NovaReservedHostMemory: 4096

   注記

   NovaVcpuPinSetパラメーターは非推奨になり、専用の固定されたワークロード用にNovaComputeCpuDedicatedSetに置き換えられました。

9. network-environment-sriov.yamlファイルで SR-IOV Compute ノードの PCI パススルーデバイスを設定します。

     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 デバイスのアドレスに置き換えます。address パラメーターの設定方法に関する情報は、インスタンス作成のための Compute サービスの設定 ガイドの NovaPCIPassthrough の設定に関するガイドライン を参照してください。

   • <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 コンテキストの間で異なる場合があります。NovaPCIPassthrough の設定方法の詳細は、インスタンス作成のための Compute サービスの設定 ガイドの NovaPCIPassthrough の設定に関するガイドライン を参照してください。

10. compute.yaml ネットワーク設定テンプレートで、SR-IOV が有効なインターフェイスを設定します。SR-IOV VF を作成するには、インターフェイスをスタンドアロン NIC として設定します。

                 - type: sriov_pf
                    name: p7p3
                    mtu: 9000
                    numvfs: 10
                    use_dhcp: false
                    defroute: false
                    nm_controlled: true
                    hotplug: true
                    promisc: false
    
                  - type: sriov_pf
                    name: p7p4
                    mtu: 9000
                    numvfs: 10
                    use_dhcp: false
                    defroute: false
                    nm_controlled: true
                    hotplug: true
                    promisc: false

    注記

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

11. デフォルトフィルターのリストに、値 AggregateInstanceExtraSpecsFilter が含まれる状態にします。

    NovaSchedulerDefaultFilters:
    ['AvailabilityZoneFilter','ComputeFilter','ComputeCapabilitiesFilter','ImagePropertiesFilter','Serve
    rGroupAntiAffinityFilter','ServerGroupAffinityFilter','PciPassthroughFilter','AggregateInstanceExt
    raSpecsFilter']

12. overcloud_deploy.sh スクリプトを実行します。

手順

1. 選択したロールの NIC 設定ファイルを開きます。

2. インターフェイス種別 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 デバイスを再び利用可能にする必要があります。

3. インターフェイス種別 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 タグを適用します。

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

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

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

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

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

   注記

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

   詳細は、インスタンス作成のための Compute サービスの設定 ガイドの KernelArgs を定義するための手動ノード再起動の設定 を参照してください。

6. その他の環境ファイルと共にロールファイルおよび環境ファイルをスタックに追加して、オーバークラウドをデプロイします。

   (undercloud)$ openstack overcloud deploy --templates \
     -r os-net-config.yaml
     -e [your environment files] \
     -e /home/stack/templates/<compute_environment_file>.yaml

検証

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

   [heat-admin@overcloud-compute-0 heat-admin]$ sudo cat /sys/class/net/p4p1/device/sriov_numvfs
   10
   [heat-admin@overcloud-compute-0 heat-admin]$ sudo cat /sys/class/net/p4p2/device/sriov_numvfs
   10

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

   [heat-admin@overcloud-compute-0]$ 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. OVS-DPDK SR-IOV Compute ノードに heat-admin としてログインし、Linux ボンディングを確認します。

   [heat-admin@overcloud-computeovsdpdksriov-1 ~]$ 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

4. OVS ボンディングを一覧表示します。

   [heat-admin@overcloud-computeovsdpdksriov-1 ~]$ 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

手順

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

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

2. オプション: ComputeOvsHwOffload ロール向けの HostnameFormatDefault: '%stackname%-compute-%index%' の名前を変更します。
3. ロール固有のパラメーターセクションに OvsHwOffload パラメーターを追加し、値を true に設定してます。
4. neutron が iptables/ハイブリッドのファイアウォールドライバーの実装を使用するように設定するには、NeutronOVSFirewallDriver: iptables_hybrid の行を追加します。NeutronOVSFirewallDriver の詳細は、オーバークラウドの高度なカスタマイズ の Open vSwitch ファイアウォールの使用 を参照してください。

5. ご自分の環境に合わせて、physical_network パラメーターを設定します。

   • VLAN の場合には、physical_network パラメーターをデプロイメント後に neutron で作成するネットワークの名前に設定します。この値は、NeutronBridgeMappings にも設定する必要があります。

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

     以下に例を示します。

     parameter_defaults:
       NeutronOVSFirewallDriver: iptables_hybrid
       ComputeSriovParameters:
         IsolCpusList: 2-9,21-29,11-19,31-39
         KernelArgs: "default_hugepagesz=1GB hugepagesz=1G hugepages=128 intel_iommu=on iommu=pt"
         OvsHwOffload: true
         TunedProfileName: "cpu-partitioning"
         NeutronBridgeMappings:
           - tenant:br-tenant
         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

   • <vendor-id> は、物理 NIC のベンダー ID に置き換えます。
   • <product-id> は、NIC VF のプロダクト ID に置き換えます。

   • <address> は、物理 NIC のアドレスに置き換えます。

     NovaPCIPassthrough の設定方法の詳細は、インスタンス作成のための Compute サービスの設定 ガイドの NovaPCIPassthrough の設定に関するガイドライン を参照してください。

6. デフォルトフィルターのリストに NUMATopologyFilter が含まれるようにします。

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

   注記

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

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

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

8. overcloud deploy コマンドに ovs-hw-offload.yaml ファイルを追加します。

   TEMPLATES_HOME=”/usr/share/openstack-tripleo-heat-templates”
   CUSTOM_TEMPLATES=”/home/stack/templates”
   
   openstack overcloud deploy --templates \
     -r ${CUSTOM_TEMPLATES}/roles_data.yaml \
     -e ${TEMPLATES_HOME}/environments/ovs-hw-offload.yaml \
     -e ${CUSTOM_TEMPLATES}/network-environment.yaml \
     -e ${CUSTOM_TEMPLATES}/neutron-ovs.yaml

検証

1. PCI デバイスが switchdev モードにあることを確認します。

   # devlink dev eswitch show pci/0000:03:00.0
   pci/0000:03:00.0: mode switchdev inline-mode none encap enable

2. OVS でオフロードが有効かどうかを確認します。

   # ovs-vsctl get Open_vSwitch . other_config:hw-offload
   “true”

手順

1. switchdev が有効な NIC からポートを割り当てるには、admin ユーザーとしてログインし、capabilities の binding-profile 値で neutron ポートを作成し、ポートセキュリティーを無効にします。

   $ 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 用インスタンスのデプロイ を参照してください。

手順

1. director を使用して、以下の設定を OVS に適用します。

   $ sudo ovs-vsctl set Open_vSwitch . other_config:hw-offload=true

2. 再起動して HW オフロードを有効にします。

手順

1. 以下の設定を適用します。明示的に tc-policy を設定していない場合、これがデフォルトのオプションです。

   $ sudo ovs-vsctl set Open_vSwitch . other_config:tc-policy=none

2. OVS を再起動します。

手順

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

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

   [root@overcloud-computesriov-0 ~]# ethtool -k ens1f0 | grep tc-offload
   hw-tc-offload: on

手順

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

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

   [root@overcloud-computesriov-0 ~]# devlink dev eswitch show pci/$(ethtool -i ens1f0 | grep bus-info | cut -d ':' -f 2,3,4 | awk '{$1=$1};1')

手順

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

   root@dni-7448-26:~# 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. フレーバーを作成します。

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

   ヒント

   フレーバーに追加スペック hw:pci_numa_affinity_policy を追加して、PCI パススルーデバイスおよび SR-IOV インターフェイスの NUMA アフィニティーポリシーを指定することができます。詳細は、Configuring the Compute Service for Instance Creationの Flavor metadata を参照してください。

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

   $ 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

3. ポートを作成します。

   • SR-IOV Virtual Function (VF) ポートを作成するには、vnic-type に direct を使用します。

     $ openstack port create --network net1 --vnic-type direct sriov_port

   • ハードウェアオフロードを有効にして Virtual Function を作成するには、以下のコマンドを使用します。--binding-profile を設定するには、管理者ユーザーである必要があります。

     $ openstack port create --network net1 --vnic-type direct --binding-profile '{"capabilities": ["switchdev"]} sriov_hwoffload_port

   • vnic-type に direct-physical を使用して、単一のインスタンス専用の SR-IOV Physical Function (PF) ポートを作成します。この PF ポートは Networking サービス (neutron) ポートですが、Networking サービスによって制御されておらず、インスタンスにパススルーされる PCI デバイスであるため、ネットワークアダプターとして表示されません。

     $ openstack port create --network net1 --vnic-type direct-physical sriov_port

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

   $ openstack server create --flavor <flavor> --image <image> --nic port-id=<id> <instance name>

手順

1. デプロイメントテンプレートの parameter_defaults セクションで heat パラメーター NovaSchedulerEnabledFilters を使用して、AggregateInstanceExtraSpecsFilter の値およびその他の必要なフィルターを設定することができます。

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

   注記

   このパラメーターを既存のクラスターの設定に追加するには、このパラメーターをヒートテンプレートに追加して、元のデプロイメントスクリプトを再度実行します。

2. SR-IOV 用のアグリゲートグループを作成し、適切なホストを追加します。定義するフレーバーメタデータに一致するメタデータを定義します (例: 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

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

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

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

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

1. usr/share/openstack-tripleo-heat-templates/plan-samples/plan-environment-derived-params.yaml ファイルをローカルディレクトリーにコピーし、ご自分の環境に合わせて入力パラメーターを設定します。

     workflow_parameters:
       tripleo.derive_params.v1.derive_parameters:
         # DPDK Parameters #
         # Specifies the minimum number of CPU physical cores to be allocated for DPDK
         # PMD threads. The actual allocation will be based on network config, if
         # the a DPDK port is associated with a numa node, then this configuration
         # will be used, else 1.
         num_phy_cores_per_numa_node_for_pmd: 1
         # Amount of memory to be configured as huge pages in percentage. Ouf the
         # total available memory (excluding the NovaReservedHostMemory), the
         # specified percentage of the remaining is configured as huge pages.
         huge_page_allocation_percentage: 50

2. openstack overcloud deploy コマンドを実行し、以下の情報を追加します。

   • update-plan-only オプション
   • ロールファイルおよびご自分の環境に固有の全環境ファイル

   • plan-environment-derived-parms.yaml ファイル (--plan-environment-file オプションの引数)

     $ openstack overcloud deploy --templates --update-plan-only \
     -r /home/stack/roles_data.yaml \
     -e /home/stack/<environment-file> \
     ... _#repeat as necessary_ ...
     **-p /home/stack/plan-environment-derived-params.yaml**

1. 派生パラメーターをデプロイコマンドの出力から network-environment.yaml ファイルにコピーします。

     # DPDK compute node.
     ComputeOvsDpdkParameters:
       KernelArgs: default_hugepagesz=1GB hugepagesz=1G hugepages=32 iommu=pt intel_iommu=on
       TunedProfileName: "cpu-partitioning"
       IsolCpusList: "1,2,3,4,5,6,7,9,10,17,18,19,20,21,22,23,11,12,13,14,15,25,26,27,28,29,30,31"
       NovaComputeCpuDedicatedSet: ['2,3,4,5,6,7,18,19,20,21,22,23,10,11,12,13,14,15,26,27,28,29,30,31']
       NovaReservedHostMemory: 4096
       OvsDpdkSocketMemory: "1024,1024"
       OvsDpdkMemoryChannels: "4"
       OvsPmdCoreList: "1,17,9,25"

   注記

   これらのパラメーターは、特定のロール ComputeOvsDpdk に適用されます。これらのパラメーターをグローバルに適用することはできますが、グローバルパラメーターはロール固有のパラメーターによってオーバーライドされます。

2. ロールファイルおよびご自分の環境に固有の全環境ファイルを使用して、オーバークラウドをデプロイします。

1. コンポーザブルロールを使用する場合には、roles_data.yaml ファイルをコピーして編集し、OVS-DPDK 用のカスタムロールを追加します。
2. 適切な network-environment.yaml ファイルを更新して、カーネル引数と DPDK 引数のパラメーターを追加します。
3. compute.yaml ファイルを更新して、DPDK インターフェイス用のブリッジを追加します。
4. controller.yaml ファイルを更新して、DPDK インターフェイスパラメーター用の同じブリッジ情報を追加します。
5. overcloud_deploy.sh スクリプトを実行して、DPDK パラメーターを使用してオーバークラウドをデプロイします。

1. network-environment.yaml ファイルで NeutronGlobalPhysnetMtu パラメーターを設定します。

   parameter_defaults:
     # MTU global configuration
     NeutronGlobalPhysnetMtu: 9000

   注記

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

2. controller.yaml ファイルで Compute ノードへのブリッジ上の MTU 値を設定します。

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

3. compute.yaml ファイルで OVS-DPDK ボンディング用の MTU 値を設定します。

   - type: ovs_user_bridge
     name: br-link0
     use_dhcp: false
     members:
       - type: ovs_dpdk_bond
         name: dpdkbond0
         mtu: 9000
         rx_queue: 2
         members:
           - type: ovs_dpdk_port
             name: dpdk0
             mtu: 9000
             members:
               - type: interface
                 name: nic4
           - type: ovs_dpdk_port
             name: dpdk1
             mtu: 9000
             members:
               - type: interface
                 name: nic5

手順

1. baremetal_deployment.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"

2. 次の例に示すように openstack overcloud node provision コマンドにベアメタルデプロイメントファイルを追加します。

   例

    openstack overcloud node provision \
       --stack overcloud \
       --network-config \
       --templates /usr/share/openstack-tripleo-heat-templates \
       --output ~/templates/overcloud-baremetal-deployed.yaml   \
       home/stack/$OSP17REF/network/baremetal_deployment.yaml

3. dpdk-config.yaml またはカスタムファイルで、次のオーバークラウドデプロイメントパラメーターを設定します。

   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

4. dpdk-config.yaml または dpdk 設定ファイルを他の環境ファイルとともにスタックに追加し、オーバークラウドをデプロイします。

   例

   (undercloud)$ openstack overcloud deploy --templates \
   -e <your_environment_files> \
   -e /home/stack/templates/dpdk-config.yaml

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 ノードに配置することができます。詳細は、Configuring the Compute Service for Instance CreationガイドのConfiguring CPU pinning on Compute nodes を参照してください。

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-full.tar
   (undercloud) [stack@undercloud-0 ~]$ tar -xf /usr/share/rhosp-director-images/ironic-python-agent.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 8.4

   注記

   コマンドプロンプトで認証情報を使用したら、履歴ファイルから認証情報を削除してセキュリティーを確保することができます。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-8-for-x86_64-baseos-eus-rpms \
   --enable=rhel-8-for-x86_64-appstream-eus-rpms \
   --enable=rhel-8-for-x86_64-highavailability-eus-rpms \
   --enable=ansible-2.9-for-rhel-8-x86_64-rpms \
   --enable=openstack-16.2-for-rhel-8-x86_64-rpms \
   --enable=rhel-8-for-x86_64-nfv-rpms \
   --enable=fast-datapath-for-rhel-8-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 99 4096 20 4
   # openstack flavor set --property hw:cpu_policy=dedicated 99
   # openstack flavor set --property hw:cpu_realtime=yes 99
   # openstack flavor set --property hw:mem_page_size=1GB 99
   # openstack flavor set --property hw:cpu_realtime_mask="^0-1" 99
   # openstack flavor set --property hw:cpu_emulator_threads=isolate 99

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. resource_registry セクションに OVS-DPDK 用のカスタムリソースを追加します。

     resource_registry:
       # Specify the relative/absolute path to the config files you want to use for override the default.
       OS::TripleO::ComputeOvsDpdkSriov::Net::SoftwareConfig: nic-configs/computeovsdpdksriov.yaml
       OS::TripleO::Controller::Net::SoftwareConfig: nic-configs/controller.yaml

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

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

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

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

4. 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 をデプロイするようにしてください。

5. 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 の両方が同じノード上に存在する設定はサポートされません。