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 ネットワークノードポリシーを説明しています。
- 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です。
25.4.1.1. SR-IOV ネットワークノードの設定例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例は、InfiniBand デバイスの設定を示しています。
InfiniBand デバイスの設定例
以下の例は、RHOSP 仮想マシンの SR-IOV ネットワークデバイスの設定を示しています。
仮想マシンの SR-IOV デバイスの設定例
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"]
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:
ポリシー policy-net-1-dpdk:
インターフェイスが正常にパーティショニングされていることを確認します
次のコマンドを実行して、インターフェイスが SR-IOV デバイスの Virtual Function (VF) にパーティショニングされていることを確認します。
ip link show <interface>
$ ip link show <interface>
- 1
<interface>を、SR-IOV デバイスの VF にパーティショニングするときに指定したインターフェイス (例:ens3f1) に置き換えます。
出力例
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
$ oc create -f <name>-sriov-node-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ここで、
<name>はこの設定の名前を指定します。設定の更新が適用された後に、
sriov-network-operatornamespace のすべての Pod がRunningステータスに移行します。SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。
<node_name>を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'$ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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ファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
SriovNetworkPoolConfigオブジェクトの名前を指定します。- 2
- SR-IOV Network Operator がインストールされている namespace を指定します。
- 3
- 更新中にプール内で使用できなくなるノードの整数値またはパーセンテージ値を指定します。たとえば、ノードが 10 個あり、使用不可の最大値を 2 に設定した場合は、一度に並列ドレインできるノードは 2 個だけとなり、ワークロードの処理には 8 個のノードが残ります。
- 4
- ノードセレクターを使用して、プールを追加するノードを指定します。この例では、
workerロールを持つすべてのノードをプールに追加します。
次のコマンドを実行して、
SriovNetworkPoolConfigリソースを作成します。oc create -f sriov-nw-pool.yaml
$ oc create -f sriov-nw-pool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
次のコマンドを実行して、
sriov-testnamespace を作成します。oc create namespace sriov-test
$ oc create namespace sriov-testCopy to Clipboard Copied! Toggle word wrap Toggle overflow SriovNetworkNodePolicyリソースを作成します。SriovNetworkNodePolicyリソースを定義する YAML ファイルを作成します。sriov-node-policy.yamlファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
SriovNetworkNodePolicyリソースを作成します。oc create -f sriov-node-policy.yaml
$ oc create -f sriov-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
SriovNetworkリソースを作成します。SriovNetworkリソースを定義する YAML ファイルを作成します。sriov-network.yamlファイルの例Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
SriovNetworkリソースを作成します。oc create -f sriov-network.yaml
$ oc create -f sriov-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、作成したノードプールを表示します。
oc get sriovNetworkpoolConfig -n openshift-sriov-network-operator
$ oc get sriovNetworkpoolConfig -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME AGE pool-1 67s
NAME AGE pool-1 67s1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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 patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、ターゲットクラスターのドレインステータスを監視します。
oc get sriovNetworkNodeState -n openshift-sriov-network-operator
$ oc get sriovNetworkNodeState -n openshift-sriov-network-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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
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 3d10hCopy to Clipboard Copied! Toggle word wrap Toggle overflow ドレインプロセスが完了すると、
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
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 3d10hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
25.4.3. SR-IOV 設定のトラブルシューティング リンクのコピーリンクがクリップボードにコピーされました!
SR-IOV ネットワークデバイスの設定の手順を実行した後に、以下のセクションではエラー状態の一部に対応します。
ノードの状態を表示するには、以下のコマンドを実行します。
oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name>
$ 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"
"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ファイルとして保存します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow SriovNetworkリソースを作成します。oc create -f sriov-network-attachment.yaml
$ oc create -f sriov-network-attachment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
NetworkAttachmentDefinition CR が正常に作成されることの確認
以下のコマンドを実行して、SR-IOV Network Operator が
NetworkAttachmentDefinitionCR を作成していることを確認します。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<namespace>を、ネットワーク割り当ての設定時に指定した namespace に置き換えます (例:additional-sriov-network-1)。
出力例
NAME AGE additional-sriov-network-1 14m
NAME AGE additional-sriov-network-1 14mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 注記SR-IOV Network Operator が CR を作成するまでに遅延が生じる可能性があります。
追加の SR-IOV ネットワーク割り当てが正常であることの確認
VRF CNI が正しく設定され、追加の SR-IOV ネットワーク割り当てが接続されていることを確認するには、以下を実行します。
- VRF CNI を使用する SR-IOV ネットワークを作成します。
- ネットワークを Pod に割り当てます。
Pod のネットワーク割り当てが SR-IOV の追加ネットワークに接続されていることを確認します。Pod にリモートシェルを実行し、以下のコマンドを実行します。
ip vrf show
$ ip vrf showCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Name Table ----------------------- red 10
Name Table ----------------------- red 10Copy to Clipboard Copied! Toggle word wrap Toggle overflow VRF インターフェイスがセカンダリーインターフェイスのマスターであることを確認します。
ip link
$ ip linkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
... 5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode ...
... 5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 がインストールされている。
手順
SriovNetworkNodePolicyCR を作成します。次の YAML を
sriov-network-node-policy.yamlファイルに保存し、環境に合わせて YAML 内の値を置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記複数の
SriovNetworkNodePolicyリソースが同じ SR-IOV ネットワークリソースをターゲットとする場合、SriovNetworkNodePolicyリソースの値はexcludeTopology仕様と同じである必要があります。そうでない場合、矛盾するポリシーは拒否されます。次のコマンドを実行して、
SriovNetworkNodePolicyリソースを作成します。oc create -f sriov-network-node-policy.yaml
$ oc create -f sriov-network-node-policy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
sriovnetworknodepolicy.sriovnetwork.openshift.io/policy-for-numa-0 created
sriovnetworknodepolicy.sriovnetwork.openshift.io/policy-for-numa-0 createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
SriovNetworkCR を作成します。次の YAML を
sriov-network.yamlファイルに保存します。その場合、YAML 内の値は環境に合わせて置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、
SriovNetworkリソースを作成します。oc create -f sriov-network.yaml
$ oc create -f sriov-network.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
sriovnetwork.sriovnetwork.openshift.io/sriov-numa-0-network created
sriovnetwork.sriovnetwork.openshift.io/sriov-numa-0-network createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Pod を作成し、前の手順で作成した SR-IOV ネットワークリソースを割り当てます。
次の YAML を
sriov-network-pod.yamlファイルに保存します。その場合、YAML 内の値は環境に合わせて置き換えます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- これは、
SriovNetworkNodePolicyリソースを使用するSriovNetworkリソースの名前です。
次のコマンドを実行して、
Podリソースを作成します。oc create -f sriov-network-pod.yaml
$ oc create -f sriov-network-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
pod/example-pod created
pod/example-pod createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
次のコマンドを実行して、Pod のステータスを確認します。その場合、
<pod_name>は Pod の名前に置き換えます。oc get pod <pod_name>
$ oc get pod <pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
NAME READY STATUS RESTARTS AGE test-deployment-sriov-76cbbf4756-k9v72 1/1 Running 0 45h
NAME READY STATUS RESTARTS AGE test-deployment-sriov-76cbbf4756-k9v72 1/1 Running 0 45hCopy to Clipboard Copied! Toggle word wrap Toggle overflow ターゲット Pod とのデバッグセッションを開き、SR-IOV ネットワークリソースがメモリーおよび CPU リソースとは異なるノードにデプロイされていることを確認します。
次のコマンドを実行して、Pod とのデバッグセッションを開きます。その場合、<pod_name> はターゲット Pod の名前に置き換えます。
oc debug pod/<pod_name>
$ oc debug pod/<pod_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow /hostをデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の/hostにホストからのルートファイルシステムをマウントします。ルートディレクトリーを/hostに変更すると、ホストファイルシステムからのバイナリーを実行できます。chroot /host
$ chroot /hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow 次のコマンドを実行して、CPU 割り当てに関する情報を表示します。
lscpu | grep NUMA
$ lscpu | grep NUMACopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
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,...
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,...Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat /proc/self/status | grep Cpus
$ cat /proc/self/status | grep CpusCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
Cpus_allowed: aa Cpus_allowed_list: 1,3,5,7
Cpus_allowed: aa Cpus_allowed_list: 1,3,5,7Copy to Clipboard Copied! Toggle word wrap Toggle overflow cat /sys/class/net/net1/device/numa_node
$ cat /sys/class/net/net1/device/numa_nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
0
0Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、CPU 1、3、5、7 が
NUMA node1に割り当てられていますが、SR-IOV ネットワークリソースはNUMA node0の NIC を使用できます。
excludeTopology 仕様が True に設定されている場合、必要なリソースが同じ NUMA ノードに存在する可能性があります。