25.4. SR-IOV ネットワークデバイスの設定


クラスターで Single Root I/O Virtualization (SR-IOV) デバイスを設定できます。

25.4.1. SR-IOV ネットワークノード設定オブジェクト

SR-IOV ネットワークノードポリシーを作成して、ノードの SR-IOV ネットワークデバイス設定を指定します。ポリシーの API オブジェクトは sriovnetwork.openshift.io API グループの一部です。

以下の YAML は SR-IOV ネットワークノードポリシーを説明しています。

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name> 1
  namespace: openshift-sriov-network-operator 2
spec:
  resourceName: <sriov_resource_name> 3
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true" 4
  priority: <priority> 5
  mtu: <mtu> 6
  needVhostNet: false 7
  numVfs: <num> 8
  externallyManaged: false 9
  nicSelector: 10
    vendor: "<vendor_code>" 11
    deviceID: "<device_id>" 12
    pfNames: ["<pf_name>", ...] 13
    rootDevices: ["<pci_bus_id>", ...] 14
    netFilter: "<filter_string>" 15
  deviceType: <device_type> 16
  isRdma: false 17
  linkType: <link_type> 18
  eSwitchMode: "switchdev" 19
  excludeTopology: false 20
1
カスタムリソースオブジェクトの名前。
2
SR-IOV Network Operator がインストールされている namespace。
3
SR-IOV ネットワークデバイスプラグインのリソース名。1 つのリソース名に複数の SR-IOV ネットワークポリシーを作成できます。

名前を指定するときは、resourceName で使用できる構文式 ^[a-zA-Z0-9_]+$ を必ず使用してください。

4
ノードセレクターは設定するノードを指定します。選択したノード上の SR-IOV ネットワークデバイスのみが設定されます。SR-IOV Container Network Interface (CNI) プラグインおよびデバイスプラグインは、選択したノードにのみデプロイされます。
重要

SR-IOV Network Operator は、ノードネットワーク設定ポリシーを順番にノードに適用します。ノードネットワーク設定ポリシーを適用する前に、SR-IOV Network Operator は、ノードのマシン設定プール (MCP) が Degraded または Updating などの正常ではない状態にないか確認します。ノード正常ではない MCP にある場合、ノードネットワーク設定ポリシーをクラスター内のすべての対象ノードに適用するプロセスは、MCP が正常な状態に戻るまで一時停止します。

正常でない MCP 内にあるノードが、他のノード (他の MCP 内のノードを含む) にノードネットワーク設定ポリシーを適用することを阻害しないようにするには、MCP ごとに別のノードネットワーク設定ポリシーを作成する必要があります。

5
オプション: 優先度は 0 から 99 までの整数値で指定されます。値が小さいほど優先度が高くなります。たとえば、10 の優先度は 99 よりも高くなります。デフォルト値は 99 です。
6
オプション: Virtual Function の最大転送単位 (MTU)。MTU の最大値は、複数の異なるネットワークインターフェイスコントローラー (NIC) に応じて異なります。
7
オプション: /dev/vhost-net デバイスを Pod にマウントするには、needVhostNettrue に設定します。Data Plane Development Kit(DPDK) と共にマウントされた /dev/vhost-net デバイスを使用して、トラフィックをカーネルネットワークスタックに転送します。
8
SR-IOV 物理ネットワークデバイス用に作成する Virtual Function (VF) の数。Intel ネットワークインターフェイスコントローラー (NIC) の場合、VF の数はデバイスがサポートする VF の合計よりも大きくすることはできません。Mellanox NIC の場合、VF の数は 127 よりも大きくすることはできません。
9
externallyManagedtrue に設定すると、SR-IOV Network Operator が外部管理の Virtual Function (VF) のすべてまたは一部を使用し、それらを Pod に割り当てることができるようになります。値を false に設定すると、SR-IOV Network Operator は割り当てられたすべての VF を管理および設定します。
注記

externallyManagedtrue に設定した場合、ポリシーを適用する前に Virtual Function (VF) を作成する必要があります。そうでない場合、Webhook がリクエストをブロックします。externallyManagedfalse に設定した場合、SR-IOV Network Operator が、必要に応じて VF をリセットするなど、VF の作成と管理を処理します。したがって、ホストシステム上で VF を使用するには、VF を手動で作成する必要があり、nicSelector ポリシーで定義されていない PF および VF に対して SR-IOV Network Operator がアクションを実行しないように、externallyManaging を true に設定する必要があります。

10
NIC セレクターは、Operator が設定するデバイスを特定します。すべてのパラメーターの値を指定する必要はありません。意図せずにデバイスを選択しないように、ネットワークデバイスを極めて正確に特定することが推奨されます。

rootDevices を指定する場合、vendordeviceID、または pfNames の値も指定する必要があります。pfNames および rootDevices の両方を同時に指定する場合、それらが同一のデバイスを参照していることを確認します。netFilter の値を指定する場合、ネットワーク ID は一意の ID であるためにその他のパラメーターを指定する必要はありません。

11
オプション: SR-IOV ネットワークデバイスのベンダーの 16 進数コード。許可される値は 8086 および 15b3 のみになります。
12
オプション: SR-IOV ネットワークデバイスのデバイスの 16 進数コード。たとえば、101b は Mellanox ConnectX-6 デバイスのデバイス ID です。
13
オプション: 1 つ以上のデバイスの物理機能 (PF) 名の配列。
14
オプション: デバイスの PF 用の 1 つ以上の PCI バスアドレスの配列。以下の形式でアドレスを指定します: 0000:02:00.1
15
オプション: プラットフォーム固有のネットワークフィルター。サポートされるプラットフォームは Red Hat OpenStack Platform (RHOSP) のみです。許可される値は、openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx の形式を使用します。xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx を、/var/config/openstack/latest/network_data.json メタデータファイルの値に置き換えます。
16
オプション: Virtual Function のドライバータイプ。許可される値は netdevice および vfio-pci のみです。デフォルト値は netdevice です。

Mellanox NIC をベアメタルノードの DPDK モードで機能させるには、netdevice ドライバータイプを使用し、isRdmatrue に設定します。

17
オプション: Remote Direct Memory Access (RDMA) モードを有効にするかどうかを設定します。デフォルト値は false です。

isRdma パラメーターが true に設定される場合、引き続き RDMA 対応の VF を通常のネットワークデバイスとして使用できます。デバイスはどちらのモードでも使用できます。

isRdmatrue に設定し、追加の needVhostNettrue に設定して、Fast Datapath DPDK アプリケーションで使用する Mellanox NIC を設定します。

注記

Intel NIC の場合、isRdma パラメーターを true に設定することはできません。

18
オプション: VF のリンクタイプ。イーサネットのデフォルト値は eth です。InfiniBand の場合、この値を 'ib' に変更します。

linkTypeib に設定されている場合、SR-IOV Network Operator Webhook によって isRdmatrue に自動的に設定されます。linkTypeib に設定されている場合、deviceTypevfio-pci に設定できません。

SriovNetworkNodePolicy の linkType を eth に設定しないでください。デバイスプラグインによって報告される使用可能なデバイスの数が正しくなくなる可能性があります。

19
オプション: ハードウェアオフロードを有効にするには、eSwitchMode フィールドを "switchdev" に設定する必要があります。
20
オプション: SR-IOV ネットワークリソースの NUMA ノードを Topology Manager にアドバタイスする場合を除外するには、値を true に設定します。デフォルト値は false です。

25.4.1.1. SR-IOV ネットワークノードの設定例

以下の例は、InfiniBand デバイスの設定を示しています。

InfiniBand デバイスの設定例

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-ib-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: ibnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 4
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    rootDevices:
      - "0000:19:00.0"
  linkType: ib
  isRdma: true

以下の例は、RHOSP 仮想マシンの SR-IOV ネットワークデバイスの設定を示しています。

仮想マシンの SR-IOV デバイスの設定例

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-sriov-net-openstack-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: sriovnic1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 1 1
  nicSelector:
    vendor: "15b3"
    deviceID: "101b"
    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509" 2

1
仮想マシンのノードネットワークポリシーを設定する際に、numVfs フィールドは常に 1 に設定されます。
2
netFilter フィールドは、仮想マシンが RHOSP にデプロイされる際にネットワーク ID を参照する必要があります。netFilter の有効な値は、SriovNetworkNodeState オブジェクトから選択できます。

25.4.1.2. SR-IOV デバイスの Virtual Function (VF) パーティション設定

Virtual Function (VF) を同じ物理機能 (PF) から複数のリソースプールに分割する必要がある場合があります。たとえば、VF の一部をデフォルトドライバーで読み込み、残りの VF を vfio-pci ドライバーで読み込む必要がある場合などです。このようなデプロイメントでは、SriovNetworkNodePolicy カスタムリソース (CR) の pfNames セレクターは、以下の形式を使用してプールの VF の範囲を指定するために使用できます: <pfname>#<first_vf>-<last_vf>

たとえば、以下の YAML は、VF が 2 から 7 まである netpf0 という名前のインターフェイスのセレクターを示します。

pfNames: ["netpf0#2-7"]
  • netpf0 は PF インターフェイス名です。
  • 2 は、範囲に含まれる最初の VF インデックス (0 ベース) です。
  • 7 は、範囲に含まれる最後の VF インデックス (0 ベース) です。

以下の要件を満たす場合、異なるポリシー CR を使用して同じ PF から VF を選択できます。

  • numVfs の値は、同じ PF を選択するポリシーで同一である必要があります。
  • VF インデックスは、0 から <numVfs>-1 の範囲にある必要があります。たとえば、numVfs8 に設定されているポリシーがある場合、<first_vf> の値は 0 よりも小さくすることはできず、<last_vf>7 よりも大きくすることはできません。
  • 異なるポリシーの VF の範囲は重複しないようにしてください。
  • <first_vf><last_vf> よりも大きくすることはできません。

以下の例は、SR-IOV デバイスの NIC パーティション設定を示しています。

ポリシー policy-net-1 は、デフォルトの VF ドライバーと共に PF netpf0 の VF 0 が含まれるリソースプール net-1 を定義します。ポリシー policy-net-1-dpdk は、vfio VF ドライバーと共に PF netpf0 の VF 8 から 15 までが含まれるリソースプール net-1-dpdk を定義します。

ポリシー policy-net-1:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#0-0"]
  deviceType: netdevice

ポリシー policy-net-1-dpdk:

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-net-1-dpdk
  namespace: openshift-sriov-network-operator
spec:
  resourceName: net1dpdk
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 16
  nicSelector:
    pfNames: ["netpf0#8-15"]
  deviceType: vfio-pci

インターフェイスが正常にパーティショニングされていることを確認します

次のコマンドを実行して、インターフェイスが SR-IOV デバイスの Virtual Function (VF) にパーティショニングされていることを確認します。

$ ip link show <interface> 1
1
<interface> を、SR-IOV デバイスの VF にパーティショニングするときに指定したインターフェイス (例: ens3f1) に置き換えます。

出力例

5: ens3f1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 3c:fd:fe:d1:bc:01 brd ff:ff:ff:ff:ff:ff

vf 0     link/ether 5a:e7:88:25:ea:a0 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 1     link/ether 3e:1d:36:d7:3d:49 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 2     link/ether ce:09:56:97:df:f9 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 3     link/ether 5e:91:cf:88:d1:38 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
vf 4     link/ether e6:06:a1:96:2f:de brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

25.4.2. SR-IOV ネットワークデバイスの設定

SR-IOV Network Operator は SriovNetworkNodePolicy.sriovnetwork.openshift.io CustomResourceDefinition を OpenShift Container Platform に追加します。SR-IOV ネットワークデバイスは、SriovNetworkNodePolicy カスタムリソース (CR) を作成して設定できます。

注記

SriovNetworkNodePolicy オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。

設定の変更が適用されるまでに数分かかる場合があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • SR-IOV Network Operator がインストールされている。
  • ドレイン (解放) されたノードからエビクトされたワークロードを処理するために、クラスター内に利用可能な十分なノードがある。
  • SR-IOV ネットワークデバイス設定についてコントロールプレーンノードを選択していない。

手順

  1. SriovNetworkNodePolicy オブジェクトを作成してから、YAML を <name>-sriov-node-network.yaml ファイルに保存します。<name> をこの設定の名前に置き換えます。
  2. オプション: SR-IOV 対応のクラスターノードにまだラベルが付いていない場合は、SriovNetworkNodePolicy.Spec.NodeSelector でラベルを付けます。ノードのラベル付けの詳細は、「ノードのラベルを更新する方法について」を参照してください。
  3. SriovNetworkNodePolicy オブジェクトを作成します。

    $ oc create -f <name>-sriov-node-network.yaml

    ここで、<name> はこの設定の名前を指定します。

    設定の更新が適用された後に、sriov-network-operator namespace のすべての Pod が Running ステータスに移行します。

  4. SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。<node_name> を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。

    $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'

25.4.2.1. SR-IOV ネットワークポリシーの更新中に並列ノードドレインを設定する

デフォルトでは、SR-IOV Network Operator は、ポリシーを変更するたびに、ノードからワークロードをドレイン (解放) します。Operator は、再設定によってワークロードが影響を受けないように、一度に 1 つのノードに対してこのアクションを実行します。

大規模なクラスターでは、ノードを順番にドレインするには時間がかかり、数時間または数日かかることもあります。時間に敏感な環境では、SriovNetworkPoolConfig カスタムリソース (CR) で並列ノードドレインを有効にして、SR-IOV ネットワーク設定のロールアウトを高速化できます。

並列ドレインを設定するには、SriovNetworkPoolConfig CR を使用してノードプールを作成します。次に、プールにノードを追加し、Operator が並行してドレインできるプール内のノードの最大数を定義できます。このアプローチでは、実行中のワークロードを処理するために十分なノードがプール内に残っていることを確認しながら、並列ドレインを有効にして再設定を高速化できます。

注記

ノードは 1 つの SR-IOV ネットワークプール設定にのみ属することができます。ノードがプールの一部でない場合は、一度に 1 つのノードのみをドレインするように設定された仮想のデフォルトプールに追加されます。

ドレイン処理中にノードが再起動する可能性があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • SR-IOV Network Operator をインストールします。
  • ノードに SR-IOV をサポートするハードウェアがあることを確認します。

手順

  1. SriovNetworkPoolConfig リソースを作成します。

    1. SriovNetworkPoolConfig リソースを定義する YAML ファイルを作成します。

      sriov-nw-pool.yaml ファイルの例

      apiVersion: v1
      kind: SriovNetworkPoolConfig
      metadata:
        name: pool-1 1
        namespace: openshift-sriov-network-operator 2
      spec:
        maxUnavailable: 2 3
        nodeSelector: 4
          matchLabels:
            node-role.kubernetes.io/worker: ""

      1
      SriovNetworkPoolConfig オブジェクトの名前を指定します。
      2
      SR-IOV Network Operator がインストールされている namespace を指定します。
      3
      更新中にプール内で使用できなくなるノードの整数値またはパーセンテージ値を指定します。たとえば、ノードが 10 個あり、使用不可の最大値を 2 に設定した場合は、一度に並列ドレインできるノードは 2 個だけとなり、ワークロードの処理には 8 個のノードが残ります。
      4
      ノードセレクターを使用して、プールを追加するノードを指定します。この例では、worker ロールを持つすべてのノードをプールに追加します。
    2. 次のコマンドを実行して、SriovNetworkPoolConfig リソースを作成します。

      $ oc create -f sriov-nw-pool.yaml
  2. 次のコマンドを実行して、sriov-test namespace を作成します。

    $ oc create namespace sriov-test
  3. SriovNetworkNodePolicy リソースを作成します。

    1. SriovNetworkNodePolicy リソースを定義する YAML ファイルを作成します。

      sriov-node-policy.yaml ファイルの例

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetworkNodePolicy
      metadata:
        name: sriov-nic-1
        namespace: openshift-sriov-network-operator
      spec:
        deviceType: netdevice
        nicSelector:
          pfNames: ["ens1"]
        nodeSelector:
          node-role.kubernetes.io/worker: ""
        numVfs: 5
        priority: 99
        resourceName: sriov_nic_1

    2. 次のコマンドを実行して、SriovNetworkNodePolicy リソースを作成します。

      $ oc create -f sriov-node-policy.yaml
  4. SriovNetwork リソースを作成します。

    1. SriovNetwork リソースを定義する YAML ファイルを作成します。

      sriov-network.yaml ファイルの例

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetwork
      metadata:
        name: sriov-nic-1
        namespace: openshift-sriov-network-operator
      spec:
        linkState: auto
        networkNamespace: sriov-test
        resourceName: sriov_nic_1
        capabilities: '{ "mac": true, "ips": true }'
        ipam: '{ "type": "static" }'

    2. 次のコマンドを実行して、SriovNetwork リソースを作成します。

      $ oc create -f sriov-network.yaml

検証

  • 次のコマンドを実行して、作成したノードプールを表示します。

    $ oc get sriovNetworkpoolConfig -n openshift-sriov-network-operator

    出力例

    NAME     AGE
    pool-1   67s 1

    1
    この例では、pool-1 にはworker ロールを持つすべてのノードが含まれています。

前の手順のサンプルシナリオを使用してノードドレインプロセスをデモンストレーションするには、次の手順を実行します。

  1. クラスター内のワークロードのドレインをトリガーするには、SriovNetworkNodePolicy リソース内の Virtual Function の数を更新します。

    $ oc patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'
  2. 次のコマンドを実行して、ターゲットクラスターのドレインステータスを監視します。

    $ oc get sriovNetworkNodeState -n openshift-sriov-network-operator

    出力例

    NAMESPACE                          NAME       SYNC STATUS   DESIRED SYNC STATE   CURRENT SYNC STATE   AGE
    openshift-sriov-network-operator   worker-0   InProgress    Drain_Required       DrainComplete        3d10h
    openshift-sriov-network-operator   worker-1   InProgress    Drain_Required       DrainComplete        3d10h

    ドレインプロセスが完了すると、SYNC STATUSSucceeded に変わり、DESIRED SYNC STATECURRENT SYNC STATE の値が IDLE に戻ります。

    出力例

    NAMESPACE                          NAME       SYNC STATUS   DESIRED SYNC STATE   CURRENT SYNC STATE   AGE
    openshift-sriov-network-operator   worker-0   Succeeded     Idle                 Idle                 3d10h
    openshift-sriov-network-operator   worker-1   Succeeded     Idle                 Idle                 3d10h

25.4.3. SR-IOV 設定のトラブルシューティング

SR-IOV ネットワークデバイスの設定の手順を実行した後に、以下のセクションではエラー状態の一部に対応します。

ノードの状態を表示するには、以下のコマンドを実行します。

$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>

ここで、<node_name> は SR-IOV ネットワークデバイスを持つノードの名前を指定します。

エラー出力: Cannot allocate memory

"lastSyncError": "write /sys/bus/pci/devices/0000:3b:00.1/sriov_numvfs: cannot allocate memory"

ノードがメモリーを割り当てることができないことを示す場合は、以下の項目を確認します。

  • ノードの BIOS でグローバル SR-IOV 設定が有効になっていることを確認します。
  • ノードの BIOS で VT-d が有効であることを確認します。

25.4.4. SR-IOV ネットワークの VRF への割り当て

クラスター管理者は、CNI VRF プラグインを使用して、SR-IOV ネットワークインターフェイスを VRF ドメインに割り当てることができます。

これを実行するには、VRF 設定を SriovNetwork リソースのオプションの metaPlugins パラメーターに追加します。

注記

VRF を使用するアプリケーションを特定のデバイスにバインドする必要があります。一般的な使用方法として、ソケットに SO_BINDTODEVICE オプションを使用できます。SO_BINDTODEVICE は、渡されるインターフェイス名で指定されているデバイスにソケットをバインドします (例: eth1)。SO_BINDTODEVICE を使用するには、アプリケーションに CAP_NET_RAW 機能がある必要があります。

ip vrf exec コマンドを使用した VRF の使用は、OpenShift Container Platform Pod ではサポートされません。VRF を使用するには、アプリケーションを VRF インターフェイスに直接バインドします。

25.4.4.1. CNI VRF プラグインを使用した追加 SR-IOV ネットワーク割り当ての作成

SR-IOV Network Operator は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、SR-IOV Network Operator は NetworkAttachmentDefinition カスタムリソース (CR) を自動的に作成します。

注記

SR-IOV Network Operator が管理する NetworkAttachmentDefinition カスタムリソースは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。

CNI VRF プラグインで追加の SR-IOV ネットワーク割り当てを作成するには、以下の手順を実行します。

前提条件

  • OpenShift Container Platform CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインします。

手順

  1. 追加の SR-IOV ネットワーク割り当て用の SriovNetwork カスタムリソース (CR) を作成し、以下のサンプル CR のように metaPlugins 設定を挿入します。YAML を sriov-network-attachment.yaml ファイルとして保存します。

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetwork
    metadata:
      name: example-network
      namespace: additional-sriov-network-1
    spec:
      ipam: |
        {
          "type": "host-local",
          "subnet": "10.56.217.0/24",
          "rangeStart": "10.56.217.171",
          "rangeEnd": "10.56.217.181",
          "routes": [{
            "dst": "0.0.0.0/0"
          }],
          "gateway": "10.56.217.1"
        }
      vlan: 0
      resourceName: intelnics
      metaPlugins : |
        {
          "type": "vrf", 1
          "vrfname": "example-vrf-name" 2
        }
    1
    typevrf に設定する必要があります。
    2
    vrfname は、インターフェイスが割り当てられた VRF の名前です。これが Pod に存在しない場合は作成されます。
  2. SriovNetwork リソースを作成します。

    $ oc create -f sriov-network-attachment.yaml

NetworkAttachmentDefinition CR が正常に作成されることの確認

  • 以下のコマンドを実行して、SR-IOV Network Operator が NetworkAttachmentDefinition CR を作成していることを確認します。

    $ oc get network-attachment-definitions -n <namespace> 1
    1
    <namespace> を、ネットワーク割り当ての設定時に指定した namespace に置き換えます (例: additional-sriov-network-1)。

    出力例

    NAME                            AGE
    additional-sriov-network-1      14m

    注記

    SR-IOV Network Operator が CR を作成するまでに遅延が生じる可能性があります。

追加の SR-IOV ネットワーク割り当てが正常であることの確認

VRF CNI が正しく設定され、追加の SR-IOV ネットワーク割り当てが接続されていることを確認するには、以下を実行します。

  1. VRF CNI を使用する SR-IOV ネットワークを作成します。
  2. ネットワークを Pod に割り当てます。
  3. Pod のネットワーク割り当てが SR-IOV の追加ネットワークに接続されていることを確認します。Pod にリモートシェルを実行し、以下のコマンドを実行します。

    $ ip vrf show

    出力例

    Name              Table
    -----------------------
    red                 10

  4. VRF インターフェイスがセカンダリーインターフェイスのマスターであることを確認します。

    $ ip link

    出力例

    ...
    5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode
    ...

25.4.5. NUMA 対応スケジューリング用の SR-IOV ネットワークトポロジーを除外する場合

NUMA 対応 Pod のスケジューリングでより柔軟な SR-IOV ネットワークデプロイメントを実現するために、SR-IOV ネットワークの Non-Uniform Memory Access (NUMA) ノードを Topology Manager にアドバタイズする場合を除外できます。

一部のシナリオでは、シングル NUMA ノード上の Pod の CPU およびメモリーリソースを最大化することが優先されます。Topology Manager に Pod の SR-IOV ネットワークリソースの NUMA ノードに関するヒントを提供しないことで、Topology Manager は SR-IOV ネットワークリソースと Pod の CPU およびメモリーリソースを異なる NUMA ノードにデプロイできます。その場合、NUMA ノード間のデータ転送により、ネットワーク遅延が増加する可能性があります。ただし、ワークロードが最適な CPU とメモリーのパフォーマンスを必要とするシナリオでは許容されます。

たとえば、2 つの NUMA ノード (uma0uma1) を備えたコンピュートノード compute-1 があるとします。SR-IOV が有効な NIC は numa0 にあります。Pod のスケジューリングに使用できる CPU は、numa1 にしかありません。excludeTopology 仕様を true に設定すると、Topology Manager は Pod の CPU およびメモリーリソースを numa1 に割り当て、同じ Pod の SR-IOV ネットワークリソースを numa0 に割り当てることができます。これは、excludeTopology 仕様を true に設定した場合にのみ可能です。そうではない場合、Topology Manager はすべてのリソースを同じ NUMA ノードに配置しようとします。

25.4.5.1. NUMA 対応スケジューリングのための SR-IOV ネットワークトポロジーの除外

SR-IOV ネットワークリソースの Non-Uniform Memory Access (NUMA) ノードを Topology Manager にアドバタイズする場合を除外するには、SriovNetworkNodePolicy カスタムリソースで excludeTopology 仕様を設定できます。NUMA 対応 Pod のスケジューリングでより柔軟な SR-IOV ネットワークデプロイメントを行うには、この設定を使用します。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • CPU マネージャーのポリシーを static に設定している。CPU マネージャーの詳細は、関連情報 セクションを参照してください。
  • Topology Manager ポリシーを single-numa-node に設定している。
  • SR-IOV Network Operator がインストールされている。

手順

  1. SriovNetworkNodePolicy CR を作成します。

    1. 次の YAML を sriov-network-node-policy.yaml ファイルに保存し、環境に合わせて YAML 内の値を置き換えます。

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetworkNodePolicy
      metadata:
        name: <policy_name>
        namespace: openshift-sriov-network-operator
      spec:
        resourceName: sriovnuma0 1
        nodeSelector:
          kubernetes.io/hostname: <node_name>
        numVfs: <number_of_Vfs>
        nicSelector: 2
          vendor: "<vendor_ID>"
          deviceID: "<device_ID>"
        deviceType: netdevice
        excludeTopology: true 3
      1
      SR-IOV ネットワークデバイスプラグインのリソース名。この YAML は、サンプルの resourceName 値を使用します。
      2
      NIC セレクターを使用して、Operator が設定するデバイスを特定します。
      3
      SR-IOV ネットワークリソースの NUMA ノードを Topology Manager にアドバタイスする場合を除外するには、値を true に設定します。デフォルト値は false です。
      注記

      複数の SriovNetworkNodePolicy リソースが同じ SR-IOV ネットワークリソースをターゲットとする場合、SriovNetworkNodePolicy リソースの値は excludeTopology 仕様と同じである必要があります。そうでない場合、矛盾するポリシーは拒否されます。

    2. 次のコマンドを実行して、SriovNetworkNodePolicy リソースを作成します。

      $ oc create -f sriov-network-node-policy.yaml

      出力例

      sriovnetworknodepolicy.sriovnetwork.openshift.io/policy-for-numa-0 created

  2. SriovNetwork CR を作成します。

    1. 次の YAML を sriov-network.yaml ファイルに保存します。その場合、YAML 内の値は環境に合わせて置き換えます。

      apiVersion: sriovnetwork.openshift.io/v1
      kind: SriovNetwork
      metadata:
        name: sriov-numa-0-network 1
        namespace: openshift-sriov-network-operator
      spec:
        resourceName: sriovnuma0 2
        networkNamespace: <namespace> 3
        ipam: |- 4
          {
            "type": "<ipam_type>",
          }
      1
      sriov-uma-0-network を SR-IOV ネットワークリソースの名前に置き換えます。
      2
      前の手順で作成した SriovNetworkNodePolicy CR のリソース名を指定します。この YAML は、サンプルの resourceName 値を使用します。
      3
      SR-IOV ネットワークリソースの namespace を入力します。
      4
      SR-IOV ネットワークの IP アドレス管理設定を入力します。
    2. 次のコマンドを実行して、SriovNetwork リソースを作成します。

      $ oc create -f sriov-network.yaml

      出力例

      sriovnetwork.sriovnetwork.openshift.io/sriov-numa-0-network created

  3. Pod を作成し、前の手順で作成した SR-IOV ネットワークリソースを割り当てます。

    1. 次の YAML を sriov-network-pod.yaml ファイルに保存します。その場合、YAML 内の値は環境に合わせて置き換えます。

      apiVersion: v1
      kind: Pod
      metadata:
        name: <pod_name>
        annotations:
          k8s.v1.cni.cncf.io/networks: |-
            [
              {
                "name": "sriov-numa-0-network", 1
              }
            ]
      spec:
        containers:
        - name: <container_name>
          image: <image>
          imagePullPolicy: IfNotPresent
          command: ["sleep", "infinity"]
      1
      これは、SriovNetworkNodePolicy リソースを使用する SriovNetwork リソースの名前です。
    2. 次のコマンドを実行して、Pod リソースを作成します。

      $ oc create -f sriov-network-pod.yaml

      出力例

      pod/example-pod created

検証

  1. 次のコマンドを実行して、Pod のステータスを確認します。その場合、<pod_name> は Pod の名前に置き換えます。

    $ oc get pod <pod_name>

    出力例

    NAME                                     READY   STATUS    RESTARTS   AGE
    test-deployment-sriov-76cbbf4756-k9v72   1/1     Running   0          45h

  2. ターゲット Pod とのデバッグセッションを開き、SR-IOV ネットワークリソースがメモリーおよび CPU リソースとは異なるノードにデプロイされていることを確認します。

    1. 次のコマンドを実行して、Pod とのデバッグセッションを開きます。その場合、<pod_name> はターゲット Pod の名前に置き換えます。

      $ oc debug pod/<pod_name>
    2. /host をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の /host にホストからのルートファイルシステムをマウントします。ルートディレクトリーを /host に変更すると、ホストファイルシステムからのバイナリーを実行できます。

      $ chroot /host
    3. 次のコマンドを実行して、CPU 割り当てに関する情報を表示します。

      $ lscpu | grep NUMA

      出力例

      NUMA node(s):                    2
      NUMA node0 CPU(s):     0,2,4,6,8,10,12,14,16,18,...
      NUMA node1 CPU(s):     1,3,5,7,9,11,13,15,17,19,...

      $ cat /proc/self/status | grep Cpus

      出力例

      Cpus_allowed:	aa
      Cpus_allowed_list:	1,3,5,7

      $ cat  /sys/class/net/net1/device/numa_node

      出力例

      0

      この例では、CPU 1、3、5、7 が NUMA node1 に割り当てられていますが、SR-IOV ネットワークリソースは NUMA node0 の NIC を使用できます。

注記

excludeTopology 仕様が True に設定されている場合、必要なリソースが同じ NUMA ノードに存在する可能性があります。

25.4.6. 次のステップ

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.