19.9. DPDK および RDMA の使用
コンテナー化された Data Plane Development Kit (DPDK) アプリケーションは OpenShift Container Platform でサポートされています。Single Root I/O Virtualization (SR-IOV) ネットワークハードウェアは、Data Plane Development Kit (DPDK) および Remote Direct Memory Access (RDMA) で利用できます。
次のドキュメントのタスクを実行する前に、SR-IOV Network Operator がインストールされている ことを確認してください。
19.9.1. Intel NIC を使用した DPDK モードでの Virtual Function の使用
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - SR-IOV Network Operator をインストールします。
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
以下の
SriovNetworkNodePolicy
オブジェクトを作成してから、YAML をintel-dpdk-node-policy.yaml
ファイルに保存します。apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: intel-dpdk-node-policy namespace: openshift-sriov-network-operator spec: resourceName: intelnics nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" priority: <priority> numVfs: <num> nicSelector: vendor: "8086" deviceID: "158b" pfNames: ["<pf_name>", ...] rootDevices: ["<pci_bus_id>", "..."] deviceType: vfio-pci 1
- 1
- Virtual Function のドライバータイプを
vfio-pci
に指定します。
注記SriovNetworkNodePolicy
の各オプションに関する詳細は、Configuring SR-IOV network devices
セクションを参照してください。SriovNetworkNodePolicy
オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。設定の変更が適用されるまでに数分の時間がかかる場合があります。エビクトされたワークロードを処理するために、クラスター内に利用可能なノードが十分にあることを前もって確認します。設定の更新が適用された後に、
openshift-sriov-network-operator
namespace のすべての Pod がRunning
ステータスに変更されます。以下のコマンドを実行して
SriovNetworkNodePolicy
オブジェクトを作成します。$ oc create -f intel-dpdk-node-policy.yaml
以下の
SriovNetwork
オブジェクトを作成してから、YAML をintel-dpdk-network.yaml
ファイルに保存します。apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: intel-dpdk-network namespace: openshift-sriov-network-operator spec: networkNamespace: <target_namespace> ipam: |- # ... 1 vlan: <vlan> resourceName: intelnics
- 1
- IPAM CNI プラグインの設定オブジェクトを YAML ブロックスケーラーとして指定します。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。
注記SriovNetwork
の各オプションに関する詳細は、「SR-IOV の追加ネットワークの設定」セクションを参照してください。オプションのライブラリー app-netutil は、コンテナーの親 Pod に関するネットワーク情報を収集するための複数の API メソッドを提供します。
以下のコマンドを実行して、
SriovNetwork
オブジェクトを作成します。$ oc create -f intel-dpdk-network.yaml
以下の
Pod
仕様を作成してから、YAML をintel-dpdk-pod.yaml
ファイルに保存します。apiVersion: v1 kind: Pod metadata: name: dpdk-app namespace: <target_namespace> 1 annotations: k8s.v1.cni.cncf.io/networks: intel-dpdk-network spec: containers: - name: testpmd image: <DPDK_image> 2 securityContext: runAsUser: 0 capabilities: add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 3 volumeMounts: - mountPath: /mnt/huge 4 name: hugepage resources: limits: openshift.io/intelnics: "1" 5 memory: "1Gi" cpu: "4" 6 hugepages-1Gi: "4Gi" 7 requests: openshift.io/intelnics: "1" memory: "1Gi" cpu: "4" hugepages-1Gi: "4Gi" command: ["sleep", "infinity"] volumes: - name: hugepage emptyDir: medium: HugePages
- 1
SriovNetwork
オブジェクトのintel-dpdk-network
が作成される同じtarget_namespace
を指定します。Pod を異なる namespace に作成する場合、target_namespace
をPod
仕様およびSriovNetwork
オブジェクトの両方で変更します。- 2
- アプリケーションとアプリケーションが使用する DPDK ライブラリーが含まれる DPDK イメージを指定します。
- 3
- hugepage の割り当て、システムリソースの割り当て、およびネットワークインターフェイスアクセス用のコンテナー内のアプリケーションに必要な追加機能を指定します。
- 4
- hugepage ボリュームを
/mnt/huge
の下の DPDK Pod にマウントします。hugepage ボリュームは、メディアがHugepages
に指定されている emptyDir ボリュームタイプでサポートされます。 - 5
- オプション: DPDK Pod に割り当てられる DPDK デバイスの数を指定します。このリソース要求および制限は、明示的に指定されていない場合、SR-IOV ネットワークリソースインジェクターによって自動的に追加されます。SR-IOV ネットワークリソースインジェクターは、SR-IOV Operator によって管理される受付コントローラーコンポーネントです。これはデフォルトで有効にされており、デフォルト
SriovOperatorConfig
CR でenableInjector
オプションをfalse
に設定して無効にすることができます。 - 6
- CPU の数を指定します。DPDK Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これは、CPU マネージャーポリシーを
static
に設定し、Guaranteed
QoS を持つ Pod を作成して実行されます。 - 7
- hugepage サイズ
hugepages-1Gi
またはhugepages-2Mi
を指定し、DPDK Pod に割り当てられる hugepage の量を指定します。2Mi
および1Gi
hugepage を別々に設定します。1Gi
hugepage を設定するには、カーネル引数をノードに追加する必要があります。たとえば、カーネル引数default_hugepagesz=1GB
、hugepagesz=1G
およびhugepages=16
を追加すると、16*1Gi
hugepage がシステムの起動時に割り当てられます。
以下のコマンドを実行して DPDK Pod を作成します。
$ oc create -f intel-dpdk-pod.yaml
19.9.2. Mellanox NIC を使用した DPDK モードでの Virtual Function の使用
Mellanox NIC で DPDK モードの Virtual Function を使用して、ネットワークノードポリシーを作成し、Data Plane Development Kit (DPDK) Pod を作成できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - Single Root I/O Virtualization (SR-IOV) Network Operator がインストールされている。
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
次の
SriovNetworkNodePolicy
YAML 設定をmlx-dpdk-node-policy.yaml
ファイルに保存します。apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: mlx-dpdk-node-policy namespace: openshift-sriov-network-operator spec: resourceName: mlxnics nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" priority: <priority> numVfs: <num> nicSelector: vendor: "15b3" deviceID: "1015" 1 pfNames: ["<pf_name>", ...] rootDevices: ["<pci_bus_id>", "..."] deviceType: netdevice 2 isRdma: true 3
注記SriovNetworkNodePolicy
オブジェクトの各オプションの詳細な説明は、SR-IOV ネットワークデバイスの設定 を参照してください。SriovNetworkNodePolicy
オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。設定の変更が適用されるまでに数分かかる場合があります。エビクトされたワークロードを処理するために、クラスター内に利用可能なノードが十分にあることを前もって確認します。設定の更新が適用された後に、
openshift-sriov-network-operator
namespace のすべての Pod がRunning
ステータスに変更されます。以下のコマンドを実行して
SriovNetworkNodePolicy
オブジェクトを作成します。$ oc create -f mlx-dpdk-node-policy.yaml
次の
SriovNetwork
YAML 設定をmlx-dpdk-network.yaml
ファイルに保存します:apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: mlx-dpdk-network namespace: openshift-sriov-network-operator spec: networkNamespace: <target_namespace> ipam: |- 1 ... vlan: <vlan> resourceName: mlxnics
- 1
- IP アドレス管理 (IPAM) コンテナーネットワークインターフェイス (CNI) プラグインの設定オブジェクトを YAML ブロックスカラーとして指定します。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。
注記SriovNetwork
オブジェクトの各オプションの詳細な説明は、SR-IOV ネットワークデバイスの設定 を参照してください。app-netutil
オプションライブラリーには、コンテナーの親 Pod に関するネットワーク情報を収集するための API メソッドが複数あります。以下のコマンドを実行して、
SriovNetwork
オブジェクトを作成します。$ oc create -f mlx-dpdk-network.yaml
次の
Pod
YAML 設定をmlx-dpdk-pod.yaml
ファイルに保存します。apiVersion: v1 kind: Pod metadata: name: dpdk-app namespace: <target_namespace> 1 annotations: k8s.v1.cni.cncf.io/networks: mlx-dpdk-network spec: containers: - name: testpmd image: <DPDK_image> 2 securityContext: runAsUser: 0 capabilities: add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 3 volumeMounts: - mountPath: /mnt/huge 4 name: hugepage resources: limits: openshift.io/mlxnics: "1" 5 memory: "1Gi" cpu: "4" 6 hugepages-1Gi: "4Gi" 7 requests: openshift.io/mlxnics: "1" memory: "1Gi" cpu: "4" hugepages-1Gi: "4Gi" command: ["sleep", "infinity"] volumes: - name: hugepage emptyDir: medium: HugePages
- 1
SriovNetwork
オブジェクトのmlx-dpdk-network
が作成される同じtarget_namespace
を指定します。別の namespace で Pod を作成するには、Pod
仕様とSriovNetwork
オブジェクトの両方でtarget_namespace
を変更します。- 2
- アプリケーションとアプリケーションが使用する DPDK ライブラリーが含まれる DPDK イメージを指定します。
- 3
- hugepage の割り当て、システムリソースの割り当て、およびネットワークインターフェイスアクセス用のコンテナー内のアプリケーションに必要な追加機能を指定します。
- 4
- hugepage ボリュームを
/mnt/huge
の下の DPDK Pod にマウントします。hugepage ボリュームは、メディアがHugepages
に指定されているemptyDir
ボリュームタイプでサポートされます。 - 5
- オプション: DPDK Pod に割り当てられる DPDK デバイスの数を指定します。このリソース要求および制限は、明示的に指定されていない場合、SR-IOV ネットワークリソースインジェクターによって自動的に追加されます。SR-IOV ネットワークリソースインジェクターは、SR-IOV Operator によって管理される受付コントローラーコンポーネントです。これはデフォルトで有効にされており、デフォルト
SriovOperatorConfig
CR でenableInjector
オプションをfalse
に設定して無効にすることができます。 - 6
- CPU の数を指定します。DPDK Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これを行うには、CPU マネージャーポリシーを
static
に設定し、サービス品質 (QoS) がGuaranteed
の Pod を作成します。 - 7
- hugepage サイズ
hugepages-1Gi
またはhugepages-2Mi
を指定し、DPDK Pod に割り当てられる hugepage の量を指定します。2Mi
および1Gi
hugepage を別々に設定します。1Gi
hugepage を設定するには、カーネル引数をノードに追加する必要があります。
以下のコマンドを実行して DPDK Pod を作成します。
$ oc create -f mlx-dpdk-pod.yaml
19.9.3. TAP CNI を使用したカーネルアクセスでのルートレス DPDK ワークロード実行
DPDK アプリケーションは、ログメッセージなどの特定の種類のパケットを処理のためにカーネルに挿入するための例外パスとして virtio-user
を使用できます。この機能の詳細は、例外パスとしての Virtio_user を参照してください。
OpenShift Container Platform バージョン 4.14 以降では、非特権 Pod を使用して、tap CNI プラグインと一緒に DPDK アプリケーションを実行できます。この機能を有効にするには、SriovNetworkNodePolicy
オブジェクト内で needVhostNet
パラメーターを true
に設定して、vhost-net
デバイスをマウントする必要があります。
図19.1 DPDK と TAP の設定例
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - SR-IOV Network Operator がインストールされている。
-
cluster-admin
権限を持つユーザーとしてログインしている。 すべてのノードで
setsebools container_use_devices=on
が root として設定されていることを確認します。注記Machine Config Operator を使用して、この SELinux ブール値を設定します。
手順
次の例のような内容を含むファイル (
test-namespace.yaml
など) を作成します。apiVersion: v1 kind: Namespace metadata: name: test-namespace labels: pod-security.kubernetes.io/enforce: privileged pod-security.kubernetes.io/audit: privileged pod-security.kubernetes.io/warn: privileged security.openshift.io/scc.podSecurityLabelSync: "false"
次のコマンドを実行して、
Namespace
オブジェクトを新規作成します。$ oc apply -f test-namespace.yaml
次の例のようなコンテンツを含むファイル (
sriov-node-network-policy.yaml
など) を作成します。apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: sriovnic namespace: openshift-sriov-network-operator spec: deviceType: netdevice 1 isRdma: true 2 needVhostNet: true 3 nicSelector: vendor: "15b3" 4 deviceID: "101b" 5 rootDevices: ["00:05.0"] numVfs: 10 priority: 99 resourceName: sriovnic nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true"
- 1
- これは、プロファイルが Mellanox ネットワークインターフェイスコントローラー (NIC) 専用に調整されていることを示します。
- 2
isRdma
をtrue
に設定する必要があるのは、Mellanox NIC の場合のみです。- 3
- これにより、
/dev/net/tun
および/dev/vhost-net
デバイスがコンテナーにマウントされ、アプリケーションがタップデバイスを作成し、タップデバイスを DPDK ワークロードに接続できるようになります。 - 4
- SR-IOV ネットワークデバイスのベンダーの 16 進数コード。値 15b3 は Mellanox NIC に関連付けられています。
- 5
- SR-IOV ネットワークデバイスのデバイスの 16 進数コード。
以下のコマンドを実行して
SriovNetworkNodePolicy
オブジェクトを作成します。$ oc create -f sriov-node-network-policy.yaml
次の
SriovNetwork
オブジェクトを作成し、YAML をsriov-network-attachment.yaml
ファイルに保存します。apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: sriov-network namespace: openshift-sriov-network-operator spec: networkNamespace: test-namespace resourceName: sriovnic spoofChk: "off" trust: "on"
注記SriovNetwork
の各オプションに関する詳細は、「SR-IOV の追加ネットワークの設定」セクションを参照してください。オプションのライブラリー
app-netutil
は、コンテナーの親 Pod に関するネットワーク情報を収集するための複数の API メソッドを提供します。以下のコマンドを実行して、
SriovNetwork
オブジェクトを作成します。$ oc create -f sriov-network-attachment.yaml
次の例のような内容を含む、ネットワーク割り当て定義を指定するファイル (
tap-example.yaml
など) を作成します。apiVersion: "k8s.cni.cncf.io/v1" kind: NetworkAttachmentDefinition metadata: name: tap-one namespace: test-namespace 1 spec: config: '{ "cniVersion": "0.4.0", "name": "tap", "plugins": [ { "type": "tap", "multiQueue": true, "selinuxcontext": "system_u:system_r:container_t:s0" }, { "type":"tuning", "capabilities":{ "mac":true } } ] }'
- 1
SriovNetwork
オブジェクトが作成されるのと同じtarget_namespace
を指定します。
次のコマンドを実行して、
NetworkAttachmentDefinition
オブジェクトを作成します。$ oc apply -f tap-example.yaml
次の例のような内容を含むファイル
(dpdk-pod-rootless.yaml
など) を作成します。apiVersion: v1 kind: Pod metadata: name: dpdk-app namespace: test-namespace 1 annotations: k8s.v1.cni.cncf.io/networks: '[ {"name": "sriov-network", "namespace": "test-namespace"}, {"name": "tap-one", "interface": "ext0", "namespace": "test-namespace"}]' spec: nodeSelector: kubernetes.io/hostname: "worker-0" securityContext: fsGroup: 1001 2 runAsGroup: 1001 3 seccompProfile: type: RuntimeDefault containers: - name: testpmd image: <DPDK_image> 4 securityContext: capabilities: drop: ["ALL"] 5 add: 6 - IPC_LOCK - NET_RAW #for mlx only 7 runAsUser: 1001 8 privileged: false 9 allowPrivilegeEscalation: true 10 runAsNonRoot: true 11 volumeMounts: - mountPath: /mnt/huge 12 name: hugepages resources: limits: openshift.io/sriovnic: "1" 13 memory: "1Gi" cpu: "4" 14 hugepages-1Gi: "4Gi" 15 requests: openshift.io/sriovnic: "1" memory: "1Gi" cpu: "4" hugepages-1Gi: "4Gi" command: ["sleep", "infinity"] runtimeClassName: performance-cnf-performanceprofile 16 volumes: - name: hugepages emptyDir: medium: HugePages
- 1
SriovNetwork
オブジェクトが作成されるのと同じtarget_namespace
を指定します。Pod を別の namespace に作成する場合は、target_namespace
をPod
仕様とSriovNetwork
オブジェクトの両方で変更します。- 2
- ボリュームにマウントされたディレクトリーおよびそれらのボリューム内に作成されたファイルのグループ所有権を設定します。
- 3
- コンテナーの実行に使用するプライマリーグループ ID を指定します。
- 4
- アプリケーションを含む DPDK イメージとアプリケーションで使用される DPDK ライブラリーを指定します。
- 5
- コンテナーの securityContext からすべての機能 (
ALL
) を削除すると、通常の操作に必要とされる権限以上の特権がコンテナーからなくなります。 - 6
- hugepage の割り当て、システムリソースの割り当て、およびネットワークインターフェイスアクセス用のコンテナー内のアプリケーションに必要な追加機能を指定します。これらの機能は、
setcap
コマンドを使用してバイナリーファイルでも設定する必要があります。 - 7
- Mellanox ネットワークインターフェイスコントローラー (NIC) には、
NET_RAW
機能が必要です。 - 8
- コンテナーの実行に使用するユーザー ID を指定します。
- 9
- この設定で、Pod 内のコンテナー (複数可) にホストシステムへの特権アクセスを許可しないように指定します。
- 10
- この設定を使用すると、コンテナーは、割り当てられている初期の root 以外の権限を超えて権限を昇格できます。
- 11
- また、この設定により、コンテナーは root 以外のユーザーで実行されます。これにより、最小特権の原則が適用され、コンテナーが不正アクセスされる可能性を最小限に抑えるとともに、攻撃対象領域を減少させます。
- 12
- hugepage ボリュームを
/mnt/huge
の下の DPDK Pod にマウントします。hugepage ボリュームは、メディアがHugepages
に指定されている emptyDir ボリュームタイプでサポートされます。 - 13
- オプション: DPDK Pod に割り当てられる DPDK デバイスの数を指定します。このリソース要求および制限は、明示的に指定されていない場合、SR-IOV ネットワークリソースインジェクターによって自動的に追加されます。SR-IOV ネットワークリソースインジェクターは、SR-IOV Operator によって管理される受付コントローラーコンポーネントです。これはデフォルトで有効にされており、デフォルト
SriovOperatorConfig
CR でenableInjector
オプションをfalse
に設定して無効にすることができます。 - 14
- CPU の数を指定します。DPDK Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これは、CPU マネージャーポリシーを
static
に設定し、Guaranteed
QoS を持つ Pod を作成して実行されます。 - 15
- hugepage サイズ
hugepages-1Gi
またはhugepages-2Mi
を指定し、DPDK Pod に割り当てられる hugepage の量を指定します。2Mi
および1Gi
hugepage を別々に設定します。1Gi
hugepage を設定するには、カーネル引数をノードに追加する必要があります。たとえば、カーネル引数default_hugepagesz=1GB
、hugepagesz=1G
およびhugepages=16
を追加すると、16*1Gi
hugepage がシステムの起動時に割り当てられます。 - 16
- パフォーマンスプロファイルの名前が
cnf-performance profile
でない場合は、その文字列を正しいパフォーマンスプロファイル名に置き換えます。
以下のコマンドを実行して DPDK Pod を作成します。
$ oc create -f dpdk-pod-rootless.yaml
19.9.4. 特定の DPDK ラインレート達成に関する概要
特定の Data Plane Development Kit (DPDK) ラインレートを実現するには、Node Tuning Operator をデプロイし、Single Root I/O Virtualization (SR-IOV) を設定します。次のリソースの DPDK 設定も調整する必要があります。
- 分離された CPU
- hugepage
- トポロジースケジューラー
OpenShift Container Platform の以前のバージョンでは、パフォーマンスアドオン Operator を使用して自動チューニングを実装し、OpenShift Container Platform アプリケーションの低レイテンシーパフォーマンスを実現していました。OpenShift Container Platform 4.11 以降では、この機能は Node Tuning Operator の一部です。
DPDK テスト環境
次の図は、トラフィックテスト環境のコンポーネントを示しています。
- トラフィックジェネレーター: 大量のパケットトラフィックを生成できるアプリケーション。
- SR-IOV 対応 NIC: SR-IOV に対応したネットワークインターフェイスカードです。カードは、物理インターフェイス上で多数の Virtual Function を実行します。
- Physical Function (PF): SR-IOV インターフェイスをサポートするネットワークアダプターの PCI Express (PCIe) 機能。
- Virtual Function (VF): SR-IOV をサポートするネットワークアダプター上の軽量の PCIe 機能。VF は、ネットワークアダプターの PCIe PF に関連付けられています。VF は、ネットワークアダプターの仮想化されたインスタンスを表します。
- スイッチ: ネットワークスイッチ。ノードは中断なしに接続することもできます。
-
testpmd
: DPDK に含まれるサンプルアプリケーション。testpmd
アプリケーションを使用して、パケット転送モードで DPDK をテストできます。testpmd
アプリケーションは、DPDK ソフトウェア開発キット (SDK) を使用して本格的なアプリケーションを構築する方法の例でもあります。 - worker 0 および worker 1: OpenShift Container Platform ノード。
19.9.5. SR-IOV と Node Tuning Operator を使用した DPDK ラインレートの実現
Node Tuning Operator を使用して、分離された CPU、ヒュージページ、およびトポロジースケジューラーを設定できます。その後、Node Tuning Operator と Single Root I/O Virtualization (SR-IOV) を使用して、特定の Data Plane Development Kit (DPDK) ラインレートを実現できます。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - SR-IOV Network Operator がインストールされている。
-
cluster-admin
権限を持つユーザーとしてログインしている。 スタンドアロン Node Tuning Operator をデプロイしている。
注記OpenShift Container Platform の以前のバージョンでは、パフォーマンスアドオン Operator を使用して自動チューニングを実装し、OpenShift アプリケーションの低レイテンシーパフォーマンスを実現していました。OpenShift Container Platform 4.11 以降では、この機能は Node Tuning Operator の一部です。
手順
次の例に基づいて
PerformanceProfile
オブジェクトを作成します。apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: globallyDisableIrqLoadBalancing: true cpu: isolated: 21-51,73-103 1 reserved: 0-20,52-72 2 hugepages: defaultHugepagesSize: 1G 3 pages: - count: 32 size: 1G net: userLevelNetworking: true numa: topologyPolicy: "single-numa-node" nodeSelector: node-role.kubernetes.io/worker-cnf: ""
- 1
- システムでハイパースレッディングが有効になっている場合は、関連するシンボリックリンクを
isolated
およびreserved
の CPU グループに割り当てます。システムに複数の Non-Uniform Memory Access (NUMA) ノードが含まれている場合は、両方の NUMA から両方のグループに CPU を割り当てます。このタスクには Performance Profile Creator を使用することもできます。詳細は、コントロールプレーンプロファイルの作成 を参照してください。 - 2
- キューが予約済みの CPU 数に設定されているデバイスのリストを指定することもできます。詳細は、Node Tuning Operator を使用した NIC キューの削減 を参照してください。
- 3
- 必要なヒュージページの数とサイズを割り当てます。ヒュージページの NUMA 設定を指定できます。デフォルトでは、システムは、そのシステムにあるすべての NUMA ノードに偶数分を割り当てます。必要に応じて、ノードのリアルタイムカーネルの使用をリクエストできます。詳細は、リアルタイム機能を備えたワーカーのプロビジョニング を参照してください。
-
yaml
ファイルをmlx-dpdk-perfprofile-policy.yaml
として保存します。 次のコマンドを使用して、パフォーマンスプロファイルを適用します。
$ oc create -f mlx-dpdk-perfprofile-policy.yaml
19.9.5.1. Virtual Function の SR-IOV Network Operator の例
Single Root I/O Virtualization (SR-IOV) ネットワーク Operator を使用して、ノード上の SR-IOV をサポートする Physical Function NIC から Virtual Function (VF) を割り当てて設定できます。
Operator のデプロイの詳細は、SR-IOV Network Operator のインストール を参照してください。SR-IOV ネットワークデバイスの設定の詳細は、SR-IOV ネットワークデバイスの設定 を参照してください。
Intel VF と Mellanox VF での Data Plane Development Kit (DPDK) ワークロードの実行にはいくつかの違いがあります。このセクションでは、両方の VF タイプのオブジェクト設定の例を示します。以下は、Intel NIC で DPDK アプリケーションを実行するために使用される sriovNetworkNodePolicy
オブジェクトの例です。
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: dpdk-nic-1 namespace: openshift-sriov-network-operator spec: deviceType: vfio-pci 1 needVhostNet: true 2 nicSelector: pfNames: ["ens3f0"] nodeSelector: node-role.kubernetes.io/worker-cnf: "" numVfs: 10 priority: 99 resourceName: dpdk_nic_1 --- apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: dpdk-nic-1 namespace: openshift-sriov-network-operator spec: deviceType: vfio-pci needVhostNet: true nicSelector: pfNames: ["ens3f1"] nodeSelector: node-role.kubernetes.io/worker-cnf: "" numVfs: 10 priority: 99 resourceName: dpdk_nic_2
以下は、Mellanox NIC の sriovNetworkNodePolicy
オブジェクトの例です。
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: dpdk-nic-1 namespace: openshift-sriov-network-operator spec: deviceType: netdevice 1 isRdma: true 2 nicSelector: rootDevices: - "0000:5e:00.1" nodeSelector: node-role.kubernetes.io/worker-cnf: "" numVfs: 5 priority: 99 resourceName: dpdk_nic_1 --- apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: dpdk-nic-2 namespace: openshift-sriov-network-operator spec: deviceType: netdevice isRdma: true nicSelector: rootDevices: - "0000:5e:00.0" nodeSelector: node-role.kubernetes.io/worker-cnf: "" numVfs: 5 priority: 99 resourceName: dpdk_nic_2
19.9.5.2. SR-IOV Network Operator の例
以下は、sriovNetwork
オブジェクトの定義例です。この場合、Intel と Mellanox の設定は同じです。
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: dpdk-network-1 namespace: openshift-sriov-network-operator spec: ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.1.0/24"}]],"dataDir": "/run/my-orchestrator/container-ipam-state-1"}' 1 networkNamespace: dpdk-test 2 spoofChk: "off" trust: "on" resourceName: dpdk_nic_1 3 --- apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: dpdk-network-2 namespace: openshift-sriov-network-operator spec: ipam: '{"type": "host-local","ranges": [[{"subnet": "10.0.2.0/24"}]],"dataDir": "/run/my-orchestrator/container-ipam-state-1"}' networkNamespace: dpdk-test spoofChk: "off" trust: "on" resourceName: dpdk_nic_2
- 1
- Whereabouts など、別の IP Address Management (IPAM) 実装を使用できます。詳細は、Whereabouts を使用した動的 IP アドレス割り当ての設定 を参照してください。
- 2
- ネットワーク接続定義が作成される
networkNamespace
を要求する必要があります。openshift-sriov-network-operator
namespace でsriovNetwork
CR を作成する必要があります。 - 3
resourceName
の値は、sriovNetworkNodePolicy
で作成されたresourceName
の値と一致する必要があります。
19.9.5.3. DPDK ベースワークロードの例
以下は、Data Plane Development Kit (DPDK) コンテナーの例です。
apiVersion: v1 kind: Namespace metadata: name: dpdk-test --- apiVersion: v1 kind: Pod metadata: annotations: k8s.v1.cni.cncf.io/networks: '[ 1 { "name": "dpdk-network-1", "namespace": "dpdk-test" }, { "name": "dpdk-network-2", "namespace": "dpdk-test" } ]' irq-load-balancing.crio.io: "disable" 2 cpu-load-balancing.crio.io: "disable" cpu-quota.crio.io: "disable" labels: app: dpdk name: testpmd namespace: dpdk-test spec: runtimeClassName: performance-performance 3 containers: - command: - /bin/bash - -c - sleep INF image: registry.redhat.io/openshift4/dpdk-base-rhel8 imagePullPolicy: Always name: dpdk resources: 4 limits: cpu: "16" hugepages-1Gi: 8Gi memory: 2Gi requests: cpu: "16" hugepages-1Gi: 8Gi memory: 2Gi securityContext: capabilities: add: - IPC_LOCK - SYS_RESOURCE - NET_RAW - NET_ADMIN runAsUser: 0 volumeMounts: - mountPath: /mnt/huge name: hugepages terminationGracePeriodSeconds: 5 volumes: - emptyDir: medium: HugePages name: hugepages
SLEEP
状態の Pod を起動し、その Pod で exec 操作を実行して testpmd または DPDK ワークロードを開始しないでください。これにより、exec
プロセスがどの CPU にも固定されていないため、割り込みが追加される可能性があります。
19.9.5.4. testpmd スクリプトの例
以下は、testpmd
を実行するスクリプトの例です。
#!/bin/bash set -ex export CPU=$(cat /sys/fs/cgroup/cpuset/cpuset.cpus) echo ${CPU} dpdk-testpmd -l ${CPU} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_1} -a ${PCIDEVICE_OPENSHIFT_IO_DPDK_NIC_2} -n 4 -- -i --nb-cores=15 --rxd=4096 --txd=4096 --rxq=7 --txq=7 --forward-mode=mac --eth-peer=0,50:00:00:00:00:01 --eth-peer=1,50:00:00:00:00:02
この例では、2 つの異なる sriovNetwork
CR を使用しています。環境変数には、Pod に割り当てられた Virtual Function (VF) PCI アドレスが含まれています。Pod 定義で同じネットワークを使用する場合は、pciAddress
を分割する必要があります。トラフィックジェネレータの正しい MAC アドレスを設定することが重要です。この例では、カスタム MAC アドレスを使用しています。
19.9.6. Mellanox NIC を使用した RDMA モードでの Virtual Function の使用
RoCE (RDMA over Converged Ethernet) はテクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
RoCE (RDMA over Converged Ethernet) は、OpenShift Container Platform で RDMA を使用する場合に唯一サポートされているモードです。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - SR-IOV Network Operator をインストールします。
-
cluster-admin
権限を持つユーザーとしてログインしている。
手順
以下の
SriovNetworkNodePolicy
オブジェクトを作成してから、YAML をmlx-rdma-node-policy.yaml
ファイルに保存します。apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: mlx-rdma-node-policy namespace: openshift-sriov-network-operator spec: resourceName: mlxnics nodeSelector: feature.node.kubernetes.io/network-sriov.capable: "true" priority: <priority> numVfs: <num> nicSelector: vendor: "15b3" deviceID: "1015" 1 pfNames: ["<pf_name>", ...] rootDevices: ["<pci_bus_id>", "..."] deviceType: netdevice 2 isRdma: true 3
注記SriovNetworkNodePolicy
の各オプションに関する詳細は、Configuring SR-IOV network devices
セクションを参照してください。SriovNetworkNodePolicy
オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。設定の変更が適用されるまでに数分の時間がかかる場合があります。エビクトされたワークロードを処理するために、クラスター内に利用可能なノードが十分にあることを前もって確認します。設定の更新が適用された後に、
openshift-sriov-network-operator
namespace のすべての Pod がRunning
ステータスに変更されます。以下のコマンドを実行して
SriovNetworkNodePolicy
オブジェクトを作成します。$ oc create -f mlx-rdma-node-policy.yaml
以下の
SriovNetwork
オブジェクトを作成してから、YAML をmlx-rdma-network.yaml
ファイルに保存します。apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: mlx-rdma-network namespace: openshift-sriov-network-operator spec: networkNamespace: <target_namespace> ipam: |- 1 # ... vlan: <vlan> resourceName: mlxnics
- 1
- IPAM CNI プラグインの設定オブジェクトを YAML ブロックスケーラーとして指定します。プラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。
注記SriovNetwork
の各オプションに関する詳細は、「SR-IOV の追加ネットワークの設定」セクションを参照してください。オプションのライブラリー app-netutil は、コンテナーの親 Pod に関するネットワーク情報を収集するための複数の API メソッドを提供します。
以下のコマンドを実行して
SriovNetworkNodePolicy
オブジェクトを作成します。$ oc create -f mlx-rdma-network.yaml
以下の
Pod
仕様を作成してから、YAML をmlx-rdma-pod.yaml
ファイルに保存します。apiVersion: v1 kind: Pod metadata: name: rdma-app namespace: <target_namespace> 1 annotations: k8s.v1.cni.cncf.io/networks: mlx-rdma-network spec: containers: - name: testpmd image: <RDMA_image> 2 securityContext: runAsUser: 0 capabilities: add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 3 volumeMounts: - mountPath: /mnt/huge 4 name: hugepage resources: limits: memory: "1Gi" cpu: "4" 5 hugepages-1Gi: "4Gi" 6 requests: memory: "1Gi" cpu: "4" hugepages-1Gi: "4Gi" command: ["sleep", "infinity"] volumes: - name: hugepage emptyDir: medium: HugePages
- 1
SriovNetwork
オブジェクトのmlx-rdma-network
が作成される同じtarget_namespace
を指定します。Pod を異なる namespace に作成する場合は、target_namespace
をPod
仕様およびSriovNetwork
オブジェクトの両方で変更します。- 2
- アプリケーションとアプリケーションが使用する RDMA ライブラリーが含まれる RDMA イメージを指定します。
- 3
- hugepage の割り当て、システムリソースの割り当て、およびネットワークインターフェイスアクセス用のコンテナー内のアプリケーションに必要な追加機能を指定します。
- 4
- hugepage ボリュームを
/mnt/huge
の下の RDMA Pod にマウントします。hugepage ボリュームは、メディアがHugepages
に指定されている emptyDir ボリュームタイプでサポートされます。 - 5
- CPU の数を指定します。RDMA Pod には通常、kubelet から排他的 CPU を割り当てる必要があります。これは、CPU マネージャーポリシーを
static
に設定し、Guaranteed
QoS を持つ Pod を作成して実行されます。 - 6
- hugepage サイズ
hugepages-1Gi
またはhugepages-2Mi
を指定し、RDMA Pod に割り当てられる hugepage の量を指定します。2Mi
および1Gi
hugepage を別々に設定します。1Gi
hugepage を設定するには、カーネル引数をノードに追加する必要があります。
以下のコマンドを実行して RDMA Pod を作成します。
$ oc create -f mlx-rdma-pod.yaml
19.9.7. OpenStack で OVS-DPDK を使用するクラスター用のテスト Pod テンプレート
次の testpmd
Pod では、ヒュージページ、予約済み CPU、および SR-IOV ポートを使用したコンテナーの作成を紹介します。
testpmd
Pod の例
apiVersion: v1 kind: Pod metadata: name: testpmd-dpdk 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/dpdk1: 1 1 limits: hugepages-1Gi: 1Gi cpu: '2' memory: 1000Mi openshift.io/dpdk1: 1 volumeMounts: - mountPath: /mnt/huge name: hugepage readOnly: False runtimeClassName: performance-cnf-performanceprofile 2 volumes: - name: hugepage emptyDir: medium: HugePages
19.9.8. 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
- 1
- パフォーマンスプロファイルの名前が
cnf-performance profile
でない場合は、その文字列を正しいパフォーマンスプロファイル名に置き換えます。
19.9.9. 関連情報
- サポートされるデバイス
- パフォーマンスプロファイルの作成
- パフォーマンスプロファイルによる NIC キューの調整
- リアルタイムおよび低レイテンシーワークロードのプロビジョニング
- SR-IOV Network Operator のインストール
- SR-IOV ネットワークデバイスの設定
- Whereabouts を使用した動的 IP アドレス割り当ての設定
- 個別の Pod の割り込み処理の無効化
- SR-IOV イーサネットネットワーク割り当ての設定
- app-netutil library ライブラリーは、コンテナーの親 Pod に関するネットワーク情報を収集するための複数の API メソッドを提供します。