14.4. SR-IOV ネットワークデバイスの設定
クラスターで Single Root I/O Virtualization (SR-IOV) デバイスを設定できます。
14.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 nicSelector: 9 vendor: "<vendor_code>" 10 deviceID: "<device_id>" 11 pfNames: ["<pf_name>", ...] 12 rootDevices: ["<pci_bus_id>", ...] 13 netFilter: "<filter_string>" 14 deviceType: <device_type> 15 isRdma: false 16 linkType: <link_type> 17
- 1
- カスタムリソースオブジェクトの名前。
- 2
- SR-IOV Network Operator がインストールされている namespace を指定します。
- 3
- SR-IOV ネットワークデバイスプラグインのリソース名。1 つのリソース名に複数の SR-IOV ネットワークポリシーを作成できます。
- 4
- ノードセレクターは設定するノードを指定します。選択したノード上の SR-IOV ネットワークデバイスのみが設定されます。SR-IOV Container Network Interface (CNI) プラグインおよびデバイスプラグインは、選択したノードにのみデプロイされます。
- 5
- オプション: 優先度は
0
から99
までの整数値で指定されます。値が小さいほど優先度が高くなります。たとえば、10
の優先度は99
よりも高くなります。デフォルト値は99
です。 - 6
- オプション: Virtual Function (VF) の最大転送単位 (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 の数は
128
よりも大きくすることはできません。 - 9
- NIC セレクターは、Operator が設定するデバイスを特定します。すべてのパラメーターの値を指定する必要はありません。意図せずにデバイスを選択しないように、ネットワークデバイスを極めて正確に特定することが推奨されます。
rootDevices
を指定する場合、vendor
、deviceID
、またはpfName
の値も指定する必要があります。pfNames
およびrootDevices
の両方を同時に指定する場合、それらが同一のデバイスを参照していることを確認します。netFilter
の値を指定する場合、ネットワーク ID は一意の ID であるためにその他のパラメーターを指定する必要はありません。 - 10
- オプション: SR-IOV ネットワークデバイスのベンダーの 16 進数コード。許可される値は
8086
および15b3
のみになります。 - 11
- オプション: SR-IOV ネットワークデバイスのデバイスの 16 進数コード。たとえば、
101b
は Mellanox ConnectX-6 デバイスのデバイス ID です。 - 12
- オプション: 1 つ以上のデバイスの物理機能 (PF) 名の配列。
- 13
- オプション: デバイスの PF 用の 1 つ以上の PCI バスアドレスの配列。以下の形式でアドレスを指定します:
0000:02:00.1
- 14
- オプション: プラットフォーム固有のネットワークフィルター。サポートされるプラットフォームは Red Hat OpenStack Platform (RHOSP) のみです。許可される値は、
openstack/NetworkID:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
の形式を使用します。xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
を、/var/config/openstack/latest/network_data.json
メタデータファイルの値に置き換えます。 - 15
- オプション: Virtual Function (VF) のドライバータイプ。許可される値は
netdevice
およびvfio-pci
のみです。デフォルト値はnetdevice
です。Mellanox NIC をベアメタルノードの DPDK モードで機能させるには、
netdevice
ドライバータイプを使用し、isRdma
をtrue
に設定します。 - 16
- オプション: Remote Direct Memory Access (RDMA) モードを有効にするかどうかを設定します。デフォルト値は
false
です。isRdma
パラメーターがtrue
に設定される場合、引き続き RDMA 対応の VF を通常のネットワークデバイスとして使用できます。デバイスはどちらのモードでも使用できます。isRdma
をtrue
に設定し、追加のneedVhostNet
をtrue
に設定して、Fast Datapath DPDK アプリケーションで使用する Mellanox NIC を設定します。 - 17
- オプション: VF のリンクタイプ。イーサネットのデフォルト値は
eth
です。InfiniBand の場合は、この値をib
に変更します。linkType
がib
に設定されている場合、SR-IOV Network Operator Webhook によってisRdma
はtrue
に自動的に設定されます。linkType
がib
に設定されている場合、deviceType
はvfio-pci
に設定できません。SriovNetworkNodePolicy
のlinkType
をeth
に設定しないでください。デバイスプラグインによって報告される使用可能なデバイスの数が正しくなくなる可能性があります。
14.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
14.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
14.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}'
関連情報
14.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 が有効であることを確認します。
14.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 インターフェイスに直接バインドします。
14.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 ...