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 にマウントするには、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
をtrue
に設定すると、SR-IOV Network Operator が外部管理の Virtual Function (VF) のすべてまたは一部を使用し、それらを Pod に割り当てることができるようになります。値をfalse
に設定すると、SR-IOV Network Operator は割り当てられたすべての VF を管理および設定します。注記externallyManaged
をtrue
に設定した場合、ポリシーを適用する前に Virtual Function (VF) を作成する必要があります。そうでない場合、Webhook がリクエストをブロックします。externallyManaged
をfalse
に設定した場合、SR-IOV Network Operator が、必要に応じて VF をリセットするなど、VF の作成と管理を処理します。したがって、ホストシステム上で VF を使用するには、VF を手動で作成する必要があり、nicSelector
ポリシーで定義されていない PFおよび
VF に対して SR-IOV Network Operator がアクションを実行しないように、externallyManaging をtrue
に設定する必要があります。- 10
- NIC セレクターは、Operator が設定するデバイスを特定します。すべてのパラメーターの値を指定する必要はありません。意図せずにデバイスを選択しないように、ネットワークデバイスを極めて正確に特定することが推奨されます。
rootDevices
を指定する場合、vendor
、deviceID
、または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
ドライバータイプを使用し、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
です。
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
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
の範囲にある必要があります。たとえば、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
ポリシー 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 ネットワークデバイス設定についてコントロールプレーンノードを選択していない。
手順
-
SriovNetworkNodePolicy
オブジェクトを作成してから、YAML を<name>-sriov-node-network.yaml
ファイルに保存します。<name>
をこの設定の名前に置き換えます。 -
オプション: SR-IOV 対応のクラスターノードにまだラベルが付いていない場合は、
SriovNetworkNodePolicy.Spec.NodeSelector
でラベルを付けます。ノードのラベル付けの詳細は、「ノードのラベルを更新する方法について」を参照してください。 SriovNetworkNodePolicy
オブジェクトを作成します。$ oc create -f <name>-sriov-node-network.yaml
ここで、
<name>
はこの設定の名前を指定します。設定の更新が適用された後に、
sriov-network-operator
namespace のすべての Pod がRunning
ステータスに移行します。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 をサポートするハードウェアがあることを確認します。
手順
SriovNetworkPoolConfig
リソースを作成します。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
ロールを持つすべてのノードをプールに追加します。
次のコマンドを実行して、
SriovNetworkPoolConfig
リソースを作成します。$ oc create -f sriov-nw-pool.yaml
次のコマンドを実行して、
sriov-test
namespace を作成します。$ oc create namespace sriov-test
SriovNetworkNodePolicy
リソースを作成します。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
次のコマンドを実行して、
SriovNetworkNodePolicy
リソースを作成します。$ oc create -f sriov-node-policy.yaml
SriovNetwork
リソースを作成します。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" }'
次のコマンドを実行して、
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
ロールを持つすべてのノードが含まれています。
前の手順のサンプルシナリオを使用してノードドレインプロセスをデモンストレーションするには、次の手順を実行します。
クラスター内のワークロードのドレインをトリガーするには、
SriovNetworkNodePolicy
リソース内の Virtual Function の数を更新します。$ oc patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'
次のコマンドを実行して、ターゲットクラスターのドレインステータスを監視します。
$ 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 STATUS
がSucceeded
に変わり、DESIRED SYNC STATE
とCURRENT 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 クラスターにログインします。
手順
追加の 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 }
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 ネットワーク割り当てが接続されていることを確認するには、以下を実行します。
- VRF CNI を使用する SR-IOV ネットワークを作成します。
- ネットワークを Pod に割り当てます。
Pod のネットワーク割り当てが SR-IOV の追加ネットワークに接続されていることを確認します。Pod にリモートシェルを実行し、以下のコマンドを実行します。
$ ip vrf show
出力例
Name Table ----------------------- red 10
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 ノード (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 ノードに配置しようとします。
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 がインストールされている。
手順
SriovNetworkNodePolicy
CR を作成します。次の 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
注記複数の
SriovNetworkNodePolicy
リソースが同じ SR-IOV ネットワークリソースをターゲットとする場合、SriovNetworkNodePolicy
リソースの値はexcludeTopology
仕様と同じである必要があります。そうでない場合、矛盾するポリシーは拒否されます。次のコマンドを実行して、
SriovNetworkNodePolicy
リソースを作成します。$ oc create -f sriov-network-node-policy.yaml
出力例
sriovnetworknodepolicy.sriovnetwork.openshift.io/policy-for-numa-0 created
SriovNetwork
CR を作成します。次の 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>", }
次のコマンドを実行して、
SriovNetwork
リソースを作成します。$ oc create -f sriov-network.yaml
出力例
sriovnetwork.sriovnetwork.openshift.io/sriov-numa-0-network created
Pod を作成し、前の手順で作成した SR-IOV ネットワークリソースを割り当てます。
次の 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
リソースの名前です。
次のコマンドを実行して、
Pod
リソースを作成します。$ oc create -f sriov-network-pod.yaml
出力例
pod/example-pod created
検証
次のコマンドを実行して、Pod のステータスを確認します。その場合、
<pod_name>
は Pod の名前に置き換えます。$ oc get pod <pod_name>
出力例
NAME READY STATUS RESTARTS AGE test-deployment-sriov-76cbbf4756-k9v72 1/1 Running 0 45h
ターゲット Pod とのデバッグセッションを開き、SR-IOV ネットワークリソースがメモリーおよび CPU リソースとは異なるノードにデプロイされていることを確認します。
次のコマンドを実行して、Pod とのデバッグセッションを開きます。その場合、<pod_name> はターゲット Pod の名前に置き換えます。
$ oc debug pod/<pod_name>
/host
をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の/host
にホストからのルートファイルシステムをマウントします。ルートディレクトリーを/host
に変更すると、ホストファイルシステムからのバイナリーを実行できます。$ chroot /host
次のコマンドを実行して、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 ノードに存在する可能性があります。
関連情報