Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

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

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

次のドキュメントのタスクを実行する前に、SR-IOV Network Operator がインストールされている ことを確認してください。

17.2.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
Copy to Clipboard
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
オプション: Physical Function とそのす Virtual Function すべての最大転送単位 (MTU)。MTU の最大値は、複数の異なるネットワークインターフェイスコントローラー (NIC) に応じて異なります。
重要

デフォルトのネットワークインターフェイス上に仮想機能を作成する場合は、MTU がクラスター MTU と一致する値に設定されていることを確認してください。

Pod に割り当てられている 1 つの Virtual Function の MTU を変更する場合は、SR-IOV ネットワークノードポリシーで MTU 値を空白のままにします。そうしない場合、SR-IOV Network Operator により Virtual Function の MTU が SR-IOV ネットワークノードポリシーで定義された MTU 値に戻され、ノードドレインがトリガーされる可能性があります。

7
オプション: /dev/vhost-net デバイスを Pod にマウントするには、needVhostNet を true に設定します。Data Plane Development Kit(DPDK) と共にマウントされた /dev/vhost-net デバイスを使用して、トラフィックをカーネルネットワークスタックに転送します。
8
SR-IOV 物理ネットワークデバイス用に作成する Virtual Function (VF) の数。Intel ネットワークインターフェイスコントローラー (NIC) の場合、VF の数はデバイスがサポートする VF の合計よりも大きくすることはできません。Mellanox NIC の場合、VF の数は 127 よりも大きくすることはできません。
9
externallyManaged フィールドは、SR-IOV Network Operator が Virtual Function (VF) のすべてを管理するか、またはサブセットのみを管理するかを示します。値を false に設定すると、SR-IOV Network Operator が PF 上のすべての VF を管理および設定します。
注記

externallyManaged を true に設定した場合、SriovNetworkNodePolicy リソースを適用する前に、物理機能 (PF) 上に仮想機能 (VF) を手動で作成する必要があります。VF が事前に作成されていないと、SR-IOV Network Operator の Webhook によってポリシー要求がブロックされます。

externallyManaged を false に設定した場合、SR-IOV Network Operator が、VF を自動的に作成および管理し、必要に応じて VF のリセットなどを実行します。

ホストシステムで VF を使用するには、NMState を通じて VF を作成し、externallyManaged を true に設定する必要があります。このモードでは、SR-IOV Network Operator は、ポリシーの nicSelector フィールドで明示的に定義されている VF を除き、PF または手動で管理される VF を変更しません。ただし、SR-IOV Network Operator は、Pod のセカンダリーインターフェイスとして使用される VF を引き続き管理します。

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

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

11
オプション: SR-IOV ネットワークデバイスの 16 進数ベンダー識別子。許可される値は 8086 (Intel) と 15b3 (Mellanox) のみです。
12
オプション: SR-IOV ネットワークデバイスの 16 進数デバイス識別子。たとえば、101b は Mellanox ConnectX-6 デバイスのデバイス ID です。
13
オプション: リソースを適用する必要がある 1 つ以上の物理機能 (PF) 名の配列。
14
オプション: リソースを適用する必要がある 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 メタデータファイルの値に置き換えます。このフィルターにより、VF が特定の OpenStack ネットワークに確実に関連付けられます。Operator はこのフィルターを使用して、OpenStack プラットフォームによって提供されるメタデータに基づき、VF を適切なネットワークにマッピングします。
16
オプション: このリソースから作成される VF 用に設定するドライバー。許可される値は netdevice および vfio-pci のみです。デフォルト値は netdevice です。

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

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

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

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

注記

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

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

linkType が ib に設定されている場合、SR-IOV Network Operator Webhook によって isRdma は true に自動的に設定されます。linkType が ib に設定されている場合、deviceType は vfio-pci に設定できません。

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

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

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

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

InfiniBand デバイスの設定例

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name>
  namespace: openshift-sriov-network-operator
spec:
  resourceName: <sriov_resource_name>
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: <num>
  nicSelector:
    vendor: "<vendor_code>"
    deviceID: "<device_id>"
    rootDevices:
      - "<pci_bus_id>"
  linkType: <link_type>
  isRdma: true
# ...
Copy to Clipboard

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

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

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name>
  namespace: openshift-sriov-network-operator
spec:
  resourceName: <sriov_resource_name>
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true"
  numVfs: 1
1 

  nicSelector:
    vendor: "<vendor_code>"
    deviceID: "<device_id>"
    netFilter: "openstack/NetworkID:ea24bd04-8674-4f69-b0ee-fa0b3bd20509"
2 

# ...
Copy to Clipboard

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

17.2.1.2. SR-IOV ネットワークデバイスの自動検出

SR-IOV Network Operator は、クラスターでワーカーノード上の SR-IOV 対応ネットワークデバイスを検索します。Operator は、互換性のある SR-IOV ネットワークデバイスを提供する各ワーカーノードの SriovNetworkNodeState カスタムリソース (CR) を作成し、更新します。

CR にはワーカーノードと同じ名前が割り当てられます。status.interfaces リストは、ノード上のネットワークデバイスに関する情報を提供します。

重要

SriovNetworkNodeState オブジェクトは変更しないでください。Operator はこれらのリソースを自動的に作成し、管理します。

17.2.1.2.1. SriovNetworkNodeState オブジェクトの例

以下の YAML は、SR-IOV Network Operator によって作成される SriovNetworkNodeState オブジェクトの例です。

SriovNetworkNodeState オブジェクト

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodeState
metadata:
  name: node-25
1 

  namespace: openshift-sriov-network-operator
  ownerReferences:
  - apiVersion: sriovnetwork.openshift.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: SriovNetworkNodePolicy
    name: default
spec:
  dpConfigVersion: "39824"
status:
  interfaces:
2 

  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f0
    pciAddress: "0000:18:00.0"
    totalvfs: 8
    vendor: 15b3
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f1
    pciAddress: "0000:18:00.1"
    totalvfs: 8
    vendor: 15b3
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f0
    pciAddress: 0000:81:00.0
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f1
    pciAddress: 0000:81:00.1
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens803f0
    pciAddress: 0000:86:00.0
    totalvfs: 64
    vendor: "8086"
  syncStatus: Succeeded
Copy to Clipboard

1
name フィールドの値はワーカーノードの名前と同じです。
2
interfaces スタンザには、ワーカーノード上の Operator によって検出されるすべての SR-IOV デバイスのリストが含まれます。

17.2.1.3. セキュアブートが有効な場合における Mellanox カードでの SR-IOV Network Operator の設定

SR-IOV Network Operator は、Mellanox デバイスのファームウェア設定をスキップするオプションをサポートしています。このオプションを使用すると、システムでセキュアブートが有効になっていれば、SR-IOV Network Operator を使用して Virtual Function を作成できます。システムをセキュアブートに切り替える前に、ファームウェアで Virtual Function の数を手動で設定して割り当てる必要があります。

注記

ファームウェア内の Virtual Function の数は、ポリシーで要求できる Virtual Function の最大数です。

手順

  1. sriov-config デーモンを使用するときにシステムにセキュアブートがない場合、次のコマンドを実行して Virtual Function (VF) を設定します。 

    $ mstconfig -d -0001:b1:00.1 set SRIOV_EN=1 NUM_OF_VFS=16
    1
    2
    Copy to Clipboard
    1
    SRIOV_EN 環境変数は、Mellanox カードでの SR-IOV Network Operator サポートを有効にします。
    2
    NUM_OF_VFS 環境変数は、ファームウェアで有効にする Virtual Function の数を指定します。

  2. Mellanox プラグインを無効にして SR-IOV Network Operator を設定します。次の SriovOperatorConfig 設定例を参照してください。 

    apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  configDaemonNodeSelector: {}
  configurationMode: daemon
  disableDrain: false
  disablePlugins:
  - mellanox
  enableInjector: true
  enableOperatorWebhook: true
  logLevel: 2
    Copy to Clipboard
  3. システムを再起動して、Virtual Function と設定を有効にします。

  4. 次のコマンドを実行して、システムの再起動後に Virtual Function (VF) を確認します。 

    $ oc -n openshift-sriov-network-operator get sriovnetworknodestate.sriovnetwork.openshift.io worker-0 -oyaml
    Copy to Clipboard

    出力例

    - deviceID: 101d
    driver: mlx5_core
    eSwitchMode: legacy
    linkSpeed: -1 Mb/s
    linkType: ETH
    mac: 08:c0:eb:96:31:25
    mtu: 1500
    name: ens3f1np1
    pciAddress: 0000:b1:00.1
    1 
    
    totalvfs: 16
    vendor: 15b3
    Copy to Clipboard

    1
    totalvfs 値は、手順の前半の mstconfig コマンドで使用した数値と同じです。

  5. セキュアブートを有効にすると、デバイスの起動プロセス中に不正なオペレーティングシステムや悪意のあるソフトウェアが読み込まれるのを防ぐことができます。

    1. BIOS (Basic Input/Output System) を使用してセキュアブートを有効にします。 

      Secure Boot: Enabled
Secure Boot Policy: Standard
Secure Boot Mode: Mode Deployed
      Copy to Clipboard
    2. システムを再起動します。

17.2.1.4. 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"]
Copy to Clipboard
  • netpf0 は PF インターフェイス名です。
  • 2 は、範囲に含まれる最初の VF インデックス (0 ベース) です。
  • 7 は、範囲に含まれる最後の VF インデックス (0 ベース) です。

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

  • numVfs の値は、同じ PF を選択するポリシーで同一である必要があります。
  • VF インデックスは、0 から <numVfs>-1 の範囲にある必要があります。たとえば、numVfs が 8 に設定されているポリシーがある場合、<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
Copy to Clipboard

ポリシー 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
Copy to Clipboard

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

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

$ ip link show <interface>
1
Copy to Clipboard
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
Copy to Clipboard

17.2.1.5. OpenStack で SR-IOV を使用するクラスター用のテスト Pod テンプレート

次の testpmd Pod では、ヒュージページ、予約済み CPU、および SR-IOV ポートを使用したコンテナーの作成を紹介します。

testpmd Pod の例

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
# ...
spec:
  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
        openshift.io/sriov1: 1
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
        openshift.io/sriov1: 1
    volumeMounts:
      - mountPath: /dev/hugepages
        name: hugepage
        readOnly: False
  runtimeClassName: performance-cnf-performanceprofile
1 

  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
Copy to Clipboard

1
この例では、パフォーマンスプロファイルの名前が cnf-performance profile であると想定しています。

17.2.1.6. OpenStack で OVS ハードウェアオフロードを使用するクラスター用のテスト Pod テンプレート

次の testpmd Pod は、Red Hat OpenStack Platform (RHOSP) での Open vSwitch (OVS) ハードウェアオフロードを示しています。

testpmd Pod の例

apiVersion: v1
kind: Pod
metadata:
  name: testpmd-sriov
  namespace: mynamespace
  annotations:
    k8s.v1.cni.cncf.io/networks: hwoffload1
spec:
  runtimeClassName: performance-cnf-performanceprofile
1 

  containers:
  - name: testpmd
    command: ["sleep", "99999"]
    image: registry.redhat.io/openshift4/dpdk-base-rhel8:v4.9
    securityContext:
      capabilities:
        add: ["IPC_LOCK","SYS_ADMIN"]
      privileged: true
      runAsUser: 0
    resources:
      requests:
        memory: 1000Mi
        hugepages-1Gi: 1Gi
        cpu: '2'
      limits:
        hugepages-1Gi: 1Gi
        cpu: '2'
        memory: 1000Mi
    volumeMounts:
      - mountPath: /mnt/huge
        name: hugepage
        readOnly: False
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
Copy to Clipboard

1
パフォーマンスプロファイルの名前が cnf-performance profile でない場合は、その文字列を正しいパフォーマンスプロファイル名に置き換えます。

17.2.1.7. Downward API の huge page リソースの挿入

Pod 仕様に huge page のリソース要求または制限が含まれる場合、Network Resources Injector は Downward API フィールドを Pod 仕様に自動的に追加し、huge page 情報をコンテナーに提供します。

Network Resources Injector は、podnetinfo という名前のボリュームを追加し、Pod の各コンテナー用に /etc/podnetinfo にマウントされます。ボリュームは Downward API を使用し、huge page の要求および制限に関するファイルを追加します。ファイルの命名規則は以下のとおりです。

  • /etc/podnetinfo/hugepages_1G_request_<container-name>
  • /etc/podnetinfo/hugepages_1G_limit_<container-name>
  • /etc/podnetinfo/hugepages_2M_request_<container-name>
  • /etc/podnetinfo/hugepages_2M_limit_<container-name>

直前のリストで指定されているパスは、app-netutil ライブラリーと互換性があります。デフォルトで、ライブラリーは、/etc/podnetinfo ディレクトリーのリソース情報を検索するように設定されます。Downward API パス項目を手動で指定する選択をする場合、app-netutil ライブラリーは前述のリストのパスに加えて以下のパスを検索します。

  • /etc/podnetinfo/hugepages_request
  • /etc/podnetinfo/hugepages_limit
  • /etc/podnetinfo/hugepages_1G_request
  • /etc/podnetinfo/hugepages_1G_limit
  • /etc/podnetinfo/hugepages_2M_request
  • /etc/podnetinfo/hugepages_2M_limit

Network Resources Injector が作成できるパスと同様に、前述の一覧のパスの末尾にはオプションで _<container-name> 接尾辞を付けることができます。

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

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

注記

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

  • Mellanox NIC (mlx5 ドライバー) の場合、Physical Function (PF) 上の Virtual Function (VF) の数が増加するたびにノードの再起動が行われます。
  • Intel NIC の場合、カーネルパラメーターに intel_iommu=on と iommu=pt が含まれていない場合にのみ再起動が行われます。

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

前提条件

  • 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
    Copy to Clipboard

    ここで、<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}'
    Copy to Clipboard

17.2.3. Non-Uniform Memory Access (NUMA) に対応した SR-IOV Pod の作成

restricted または single-numa-node Topology Manager ポリシーを使用して、同じ NUMA ノードから割り当てられる CPU リソースと SR-IOV を制限することで、NUMA に対応した SR-IOV Pod を作成できます。

前提条件

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

  • Topology Manager ポリシーを single-numa-node に設定している。

    注記

    single-numa-node が要求を満たさない場合は、Topology Manager ポリシーを restricted にするように設定できます。より柔軟な SR-IOV ネットワークリソーススケジューリングについては、関連情報 セクションの NUMA 対応スケジューリングにおける SR-IOV ネットワークトポロジーの除外 を参照してください。

手順

  1. 以下の SR-IOV Pod 仕様を作成してから、YAML を <name>-sriov-pod.yaml ファイルに保存します。<name> をこの Pod の名前に置き換えます。

    以下の例は、SR-IOV Pod 仕様を示しています。 

    apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: <name>
    1 
    
spec:
  containers:
  - name: sample-container
    image: <image>
    2 
    
    command: ["sleep", "infinity"]
    resources:
      limits:
        memory: "1Gi"
    3 
    
        cpu: "2"
    4 
    
      requests:
        memory: "1Gi"
        cpu: "2"
    Copy to Clipboard
    1
    <name> を、SR-IOV ネットワーク割り当て定義 CR の名前に置き換えます。
    2
    <image> を sample-pod イメージの名前に置き換えます。
    3
    Guaranteed QoS を指定して SR-IOV Pod を作成するには、メモリー要求 に等しい メモリー制限 を設定します。
    4
    Guaranteed QoS を指定して SR-IOV Pod を作成するには、cpu 要求 に等しい cpu 制限 を設定します。

  2. 以下のコマンドを実行して SR-IOV Pod のサンプルを作成します。 

    $ oc create -f <filename>
    1
    Copy to Clipboard
    1
    <filename> を、先の手順で作成したファイルの名前に置き換えます。

  3. sample-pod が Guaranteed QoS を指定して設定されていることを確認します。 

    $ oc describe pod sample-pod
    Copy to Clipboard

  4. sample-pod が排他的 CPU を指定して割り当てられていることを確認します。 

    $ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
    Copy to Clipboard

  5. sample-pod に割り当てられる SR-IOV デバイスと CPU が同じ NUMA ノード上にあることを確認します。 

    $ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus
    Copy to Clipboard

17.2.4. 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 ノード (uma0 と uma1) を備えたコンピュートノード 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 ノードに配置しようとします。

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

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

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

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

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

エラー出力: Cannot allocate memory

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

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

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

17.2.6. 次のステップ

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat