14.2. パフォーマンスプロファイルによる低レイテンシーを実現するためのノードのチューニング
ノードをチューニングして低レイテンシーを実現するには、クラスターパフォーマンスプロファイルを使用します。インフラストラクチャーおよびアプリケーションコンテナーの CPU を制限したり、huge page やハイパースレッディングを設定したり、レイテンシーの影響を受けやすいプロセスの CPU パーティションを設定したりすることができます。
14.2.1. パフォーマンスプロファイルの作成
Performance Profile Creator (PPC) ツールを使用して、クラスターパフォーマンスプロファイルを作成できます。PPC は Node Tuning Operator の機能です。
PPC は、クラスターに関する情報とユーザー指定の設定を組み合わせて、ハードウェア、トポロジー、ユースケースに適したパフォーマンスプロファイルを生成します。
パフォーマンスプロファイルは、クラスターが基盤となるハードウェアリソースに直接アクセスできるベアメタル環境にのみ適用されます。シングルノード OpenShift とマルチノードクラスターの両方に対してパフォーマンスプロファイルを設定できます。
以下は、クラスターでパフォーマンスプロファイルを作成して適用するための大まかなワークフローです。
-
パフォーマンス設定の対象となるノードのマシン設定プール (MCP) を作成します。シングルノードの OpenShift クラスターでは、クラスター内にノードが 1 つしかないため、
master
MCP を使用する必要があります。 -
must-gather
コマンドを使用してクラスターに関する情報を収集します。 次のいずれかの方法で PPC ツールを使用してパフォーマンスプロファイルを作成します。
- Podman を使用して PPC ツールを実行します。
- ラッパースクリプトを使用して PPC ツールを実行します。
- ユースケースに合わせてパフォーマンスプロファイルを設定し、そのパフォーマンスプロファイルをクラスターに適用します。
Telco では、cgroups v2 サポートがないため、低レイテンシー、リアルタイム、および Data Plane Development Kit (DPDK)ワークロードに PerformanceProfile
を使用するクラスターは自動的に cgroups v1 に戻ります。PerformanceProfile
を使用している場合は、cgroup v2 を有効にすることはできません。
14.2.1.1. Performance Profile Creator の概要
Performance Profile Creator (PPC) は、Node Tuning Operator とともに提供されるコマンドラインツールで、クラスターのパフォーマンスプロファイルを作成するのに役立ちます。
最初に、PPC ツールを使用して must-gather
データを処理し、次の情報を含むクラスターの主要なパフォーマンス設定を表示できます。
- 割り当てられた CPU ID でパーティショニングされた NUMA セル
- ハイパースレッディングノード設定
この情報を使用して、パフォーマンスプロファイルを設定することができます。
PPC の実行
PPC ツールにパフォーマンス設定引数を指定して、ハードウェア、トポロジー、およびユースケースに適した提案されたパフォーマンスプロファイルを生成します。
次のいずれかの方法で PPC を実行できます。
- Podman を使用して PPC を実行する
- ラッパースクリプトを使用して PPC を実行する
ラッパースクリプトを使用すると、より細かい Podman タスクの一部が実行可能なスクリプトに抽象化されます。たとえば、ラッパースクリプトは、必要なコンテナーイメージをプルして実行したり、コンテナーにディレクトリーをマウントしたり、Podman を介してコンテナーに直接パラメーターを提供したりといったタスクを処理します。どちらの方法でも同じ結果が得られます。
14.2.1.2. パフォーマンスチューニングの対象となるノードにマシン設定プールを作成する
マルチノードクラスターの場合、マシン設定プール (MCP) を定義して、パフォーマンスプロファイルで設定するターゲットノードを識別できます。
シングルノードの OpenShift クラスターでは、クラスター内にノードが 1 つしかないため、master
MCP を使用する必要があります。シングルノードの OpenShift クラスター用に別の MCP を作成する必要はありません。
前提条件
-
cluster-admin
ロールへのアクセス権がある。 -
OpenShift CLI (
oc
) がインストールされている。
手順
次のコマンドを実行して、設定用のターゲットノードにラベルを付けます。
$ oc label node <node_name> node-role.kubernetes.io/worker-cnf="" 1
- 1
<node_name>
をノードの名前に置き換えます。この例では、worker-cnf
ラベルを適用します。
ターゲットノードを含む
MachineConfigPool
リソースを作成します。MachineConfigPool
リソースを定義する YAML ファイルを作成します。mcp-worker-cnf.yaml
ファイルの例apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: name: worker-cnf 1 labels: machineconfiguration.openshift.io/role: worker-cnf 2 spec: machineConfigSelector: matchExpressions: - { key: machineconfiguration.openshift.io/role, operator: In, values: [worker, worker-cnf], } paused: false nodeSelector: matchLabels: node-role.kubernetes.io/worker-cnf: "" 3
次のコマンドを実行して、
MachineConfigPool
リソースを適用します。$ oc apply -f mcp-worker-cnf.yaml
出力例
machineconfigpool.machineconfiguration.openshift.io/worker-cnf created
検証
次のコマンドを実行して、クラスター内のマシン設定プールを確認します。
$ oc get mcp
出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-58433c7c3c1b4ed5ffef95234d451490 True False False 3 3 3 0 6h46m worker rendered-worker-168f52b168f151e4f853259729b6azc4 True False False 2 2 2 0 6h46m worker-cnf rendered-worker-cnf-168f52b168f151e4f853259729b6azc4 True False False 1 1 1 0 73s
14.2.1.3. PPC 用のクラスターに関するデータを収集する
Performance Profile Creator (PPC) ツールには must-gather
データが必要です。クラスター管理者は、must-gather
コマンドを実行し、クラスターに関する情報を取得します。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。 - パフォーマンスプロファイルを使用して設定するターゲット MCP を特定している。
手順
-
must-gather
データを保存するディレクトリーに移動します。 次のコマンドを実行してクラスター情報を収集します。
$ oc adm must-gather
このコマンドは、
must-gather.local.1971646453781853027
のような命名形式で、ローカルディレクトリーにmust-gather
データを含むフォルダーを作成します。オプション:
must-gather
ディレクトリーから圧縮ファイルを作成します。$ tar cvaf must-gather.tar.gz <must_gather_folder> 1
- 1
must-gather
データフォルダーの名前に置き換えます。
注記Performance Profile Creator ラッパースクリプトを実行している場合は、出力を圧縮する必要があります。
関連情報
-
must-gather
ツールの詳細は、クラスターに関するデータの収集 を参照してください。
14.2.1.4. Podman を使用した Performance Profile Creator の実行
クラスター管理者は、Podman と Performance Profile Creator (PPC) を使用してパフォーマンスプロファイルを作成できます。
PPC 引数の詳細は、Performance Profile Creator の引数 のセクションを参照してください。
PPC は、クラスターからの must-gather
データを使用して、パフォーマンスプロファイルを作成します。パフォーマンス設定の対象となるノードのラベルを変更するなど、クラスターに変更を加えた場合は、PPC を再度実行する前に、must-gather
データを再作成する必要があります。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - ベアメタルハードウェアにクラスターがインストールされている。
-
podman
と OpenShift CLI (oc
) がインストールされている。 - Node Tuning Operator イメージへのアクセスがある。
- 設定のターゲットノードを含むマシン設定プールが特定されている。
-
クラスターの
must-gather
データにアクセスできる。
手順
次のコマンドを実行して、マシン設定プールを確認します。
$ oc get mcp
出力例
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-58433c8c3c0b4ed5feef95434d455490 True False False 3 3 3 0 8h worker rendered-worker-668f56a164f151e4a853229729b6adc4 True False False 2 2 2 0 8h worker-cnf rendered-worker-cnf-668f56a164f151e4a853229729b6adc4 True False False 1 1 1 0 79m
次のコマンドを実行して、Podman を使用して
registry.redhat.io
に認証します。$ podman login registry.redhat.io
Username: <user_name> Password: <password>
オプション: 次のコマンドを実行して、PPC ツールのヘルプを表示します。
$ podman run --rm --entrypoint performance-profile-creator registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.14 -h
出力例
A tool that automates creation of Performance Profiles Usage: performance-profile-creator [flags] Flags: --disable-ht Disable Hyperthreading -h, --help help for performance-profile-creator --info string Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log") --mcp-name string MCP name corresponding to the target machines (required) --must-gather-dir-path string Must gather directory path (default "must-gather") --offlined-cpu-count int Number of offlined CPUs --per-pod-power-management Enable Per Pod Power Management --power-consumption-mode string The power consumption mode. [Valid values: default, low-latency, ultra-low-latency] (default "default") --profile-name string Name of the performance profile to be created (default "performance") --reserved-cpu-count int Number of reserved CPUs (required) --rt-kernel Enable Real Time Kernel (required) --split-reserved-cpus-across-numa Split the Reserved CPUs across NUMA nodes --topology-manager-policy string Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted") --user-level-networking Run with User level Networking(DPDK) enabled
クラスターに関する情報を表示するには、次のコマンドを実行して、
log
引数を指定した PPC ツールを実行します。$ podman run --entrypoint performance-profile-creator -v <path_to_must_gather>:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.14 --info log --must-gather-dir-path /must-gather
-
--entrypoint performance-profile-creator
は、podman
への新しいエントリーポイントとして、パフォーマンスプロファイルクリエーターを定義します。 -v <path_to_must_gather>
は、次のいずれかのコンポーネントへのパスを指定します。-
must-gather
データが含まれるディレクトリー。 -
must-gather
の展開された .tar ファイルを含む既存のディレクトリー
-
--info log
は、出力形式の値を指定します。出力例
level=info msg="Cluster info:" level=info msg="MCP 'master' nodes:" level=info msg=--- level=info msg="MCP 'worker' nodes:" level=info msg="Node: host.example.com (NUMA cells: 1, HT: true)" level=info msg="NUMA cell 0 : [0 1 2 3]" level=info msg="CPU(s): 4" level=info msg="Node: host1.example.com (NUMA cells: 1, HT: true)" level=info msg="NUMA cell 0 : [0 1 2 3]" level=info msg="CPU(s): 4" level=info msg=--- level=info msg="MCP 'worker-cnf' nodes:" level=info msg="Node: host2.example.com (NUMA cells: 1, HT: true)" level=info msg="NUMA cell 0 : [0 1 2 3]" level=info msg="CPU(s): 4" level=info msg=---
-
次のコマンドを実行して、パフォーマンスプロファイルを作成します。この例では、サンプルの PPC 引数と値を使用します。
$ podman run --entrypoint performance-profile-creator -v <path_to_must_gather>:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.14 --mcp-name=worker-cnf --reserved-cpu-count=1 --rt-kernel=true --split-reserved-cpus-across-numa=false --must-gather-dir-path /must-gather --power-consumption-mode=ultra-low-latency --offlined-cpu-count=1 > my-performance-profile.yaml
-v <path_to_must_gather>
は、次のいずれかのコンポーネントへのパスを指定します。-
must-gather
データが含まれるディレクトリー。 -
must-gather
の展開された .tar ファイルを含むディレクトリー。
-
-
--mcp-name=worker-cnf
は、worker-=cnf
マシン設定プールを指定します。 -
--reserved-cpu-count=1
は、予約済みの CPU を 1 つ指定します。 -
--rt-kernel=true
は、リアルタイムカーネルを有効にします。 -
--split-reserved-cpus-across-numa=false
は、NUMA ノード間での予約済み CPU の分割を無効にします。 -
--power-consumption-mode=ultra-low-latency
は、消費電力の増加を犠牲にして、レイテンシーを最小限に抑えることを指定します。 --offlined-cpu-count=1
は、オフラインの CPU を 1 つ指定します。注記この例の
mcp-name
引数は、コマンドoc get mcp
の出力に基づいてworker-cnf
に設定されます。シングルノード OpenShift の場合は、--mcp-name=master
を使用します。出力例
level=info msg="Nodes targeted by worker-cnf MCP are: [worker-2]" level=info msg="NUMA cell(s): 1" level=info msg="NUMA cell 0 : [0 1 2 3]" level=info msg="CPU(s): 4" level=info msg="1 reserved CPUs allocated: 0 " level=info msg="2 isolated CPUs allocated: 2-3" level=info msg="Additional Kernel Args based on configuration: []"
次のコマンドを実行して、作成された YAML ファイルを確認します。
$ cat my-performance-profile.yaml
出力例
--- apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: cpu: isolated: 2-3 offlined: "1" reserved: "0" machineConfigPoolSelector: machineconfiguration.openshift.io/role: worker-cnf nodeSelector: node-role.kubernetes.io/worker-cnf: "" numa: topologyPolicy: restricted realTimeKernel: enabled: true workloadHints: highPowerConsumption: true perPodPowerManagement: false realTime: true
生成されたプロファイルを適用します。
$ oc apply -f my-performance-profile.yaml
出力例
performanceprofile.performance.openshift.io/performance created
14.2.1.5. Performance Profile Creator ラッパースクリプトの実行
ラッパースクリプトは、Performance Profile Creator (PPC) ツールを使用してパフォーマンスプロファイルを作成するプロセスを簡素化します。このスクリプトは、必要なコンテナーイメージのプルと実行、コンテナーへのディレクトリーのマウント、Podman を介してコンテナーに直接パラメーターを提供するなどのタスクを処理します。
Performance Profile Creator の引数の詳細は、Performance Profile Creator の引数 のセクションを参照してください。
PPC は、クラスターからの must-gather
データを使用して、パフォーマンスプロファイルを作成します。パフォーマンス設定の対象となるノードのラベルを変更するなど、クラスターに変更を加えた場合は、PPC を再度実行する前に、must-gather
データを再作成する必要があります。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - ベアメタルハードウェアにクラスターがインストールされている。
-
podman
と OpenShift CLI (oc
) がインストールされている。 - Node Tuning Operator イメージへのアクセスがある。
- 設定のターゲットノードを含むマシン設定プールが特定されている。
-
must-gather
tarball にアクセスできる。
手順
ローカルマシンにファイル (例:
run-perf-profile-creator.sh
) を作成します。$ vi run-perf-profile-creator.sh
ファイルに以下のコードを貼り付けます。
#!/bin/bash readonly CONTAINER_RUNTIME=${CONTAINER_RUNTIME:-podman} readonly CURRENT_SCRIPT=$(basename "$0") readonly CMD="${CONTAINER_RUNTIME} run --entrypoint performance-profile-creator" readonly IMG_EXISTS_CMD="${CONTAINER_RUNTIME} image exists" readonly IMG_PULL_CMD="${CONTAINER_RUNTIME} image pull" readonly MUST_GATHER_VOL="/must-gather" NTO_IMG="registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.14" MG_TARBALL="" DATA_DIR="" usage() { print "Wrapper usage:" print " ${CURRENT_SCRIPT} [-h] [-p image][-t path] -- [performance-profile-creator flags]" print "" print "Options:" print " -h help for ${CURRENT_SCRIPT}" print " -p Node Tuning Operator image" print " -t path to a must-gather tarball" ${IMG_EXISTS_CMD} "${NTO_IMG}" && ${CMD} "${NTO_IMG}" -h } function cleanup { [ -d "${DATA_DIR}" ] && rm -rf "${DATA_DIR}" } trap cleanup EXIT exit_error() { print "error: $*" usage exit 1 } print() { echo "$*" >&2 } check_requirements() { ${IMG_EXISTS_CMD} "${NTO_IMG}" || ${IMG_PULL_CMD} "${NTO_IMG}" || \ exit_error "Node Tuning Operator image not found" [ -n "${MG_TARBALL}" ] || exit_error "Must-gather tarball file path is mandatory" [ -f "${MG_TARBALL}" ] || exit_error "Must-gather tarball file not found" DATA_DIR=$(mktemp -d -t "${CURRENT_SCRIPT}XXXX") || exit_error "Cannot create the data directory" tar -zxf "${MG_TARBALL}" --directory "${DATA_DIR}" || exit_error "Cannot decompress the must-gather tarball" chmod a+rx "${DATA_DIR}" return 0 } main() { while getopts ':hp:t:' OPT; do case "${OPT}" in h) usage exit 0 ;; p) NTO_IMG="${OPTARG}" ;; t) MG_TARBALL="${OPTARG}" ;; ?) exit_error "invalid argument: ${OPTARG}" ;; esac done shift $((OPTIND - 1)) check_requirements || exit 1 ${CMD} -v "${DATA_DIR}:${MUST_GATHER_VOL}:z" "${NTO_IMG}" "$@" --must-gather-dir-path "${MUST_GATHER_VOL}" echo "" 1>&2 } main "$@"
このスクリプトの実行権限を全員に追加します。
$ chmod a+x run-perf-profile-creator.sh
次のコマンドを実行して、Podman を使用して
registry.redhat.io
に認証します。$ podman login registry.redhat.io
Username: <user_name> Password: <password>
オプション: 次のコマンドを実行して、PPC ツールのヘルプを表示します。
$ ./run-perf-profile-creator.sh -h
出力例
Wrapper usage: run-perf-profile-creator.sh [-h] [-p image][-t path] -- [performance-profile-creator flags] Options: -h help for run-perf-profile-creator.sh -p Node Tuning Operator image -t path to a must-gather tarball A tool that automates creation of Performance Profiles Usage: performance-profile-creator [flags] Flags: --disable-ht Disable Hyperthreading -h, --help help for performance-profile-creator --info string Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log") --mcp-name string MCP name corresponding to the target machines (required) --must-gather-dir-path string Must gather directory path (default "must-gather") --offlined-cpu-count int Number of offlined CPUs --per-pod-power-management Enable Per Pod Power Management --power-consumption-mode string The power consumption mode. [Valid values: default, low-latency, ultra-low-latency] (default "default") --profile-name string Name of the performance profile to be created (default "performance") --reserved-cpu-count int Number of reserved CPUs (required) --rt-kernel Enable Real Time Kernel (required) --split-reserved-cpus-across-numa Split the Reserved CPUs across NUMA nodes --topology-manager-policy string Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted") --user-level-networking Run with User level Networking(DPDK) enabled
注記オプションで、
-p
オプションを使用して Node Tuning Operator イメージのパスを設定できます。パスを設定しない場合、ラッパースクリプトはデフォルトのイメージ (registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.18) を使用します。クラスターに関する情報を表示するには、次のコマンドを実行して、
log
引数を指定した PPC ツールを実行します。$ ./run-perf-profile-creator.sh -t /<path_to_must_gather_dir>/must-gather.tar.gz -- --info=log
-t /<path_to_must_gather_dir>/must-gather.tar.gz
は、must-gather tarball を含むディレクトリーへのパスを指定します。これはラッパースクリプトに必要な引数です。出力例
level=info msg="Cluster info:" level=info msg="MCP 'master' nodes:" level=info msg=--- level=info msg="MCP 'worker' nodes:" level=info msg="Node: host.example.com (NUMA cells: 1, HT: true)" level=info msg="NUMA cell 0 : [0 1 2 3]" level=info msg="CPU(s): 4" level=info msg="Node: host1.example.com (NUMA cells: 1, HT: true)" level=info msg="NUMA cell 0 : [0 1 2 3]" level=info msg="CPU(s): 4" level=info msg=--- level=info msg="MCP 'worker-cnf' nodes:" level=info msg="Node: host2.example.com (NUMA cells: 1, HT: true)" level=info msg="NUMA cell 0 : [0 1 2 3]" level=info msg="CPU(s): 4" level=info msg=---
次のコマンドを実行して、パフォーマンスプロファイルを作成します。
$ ./run-perf-profile-creator.sh -t /path-to-must-gather/must-gather.tar.gz -- --mcp-name=worker-cnf --reserved-cpu-count=1 --rt-kernel=true --split-reserved-cpus-across-numa=false --power-consumption-mode=ultra-low-latency --offlined-cpu-count=1 > my-performance-profile.yaml
この例では、サンプルの PPC 引数と値を使用します。
-
--mcp-name=worker-cnf
は、worker-=cnf
マシン設定プールを指定します。 -
--reserved-cpu-count=1
は、予約済みの CPU を 1 つ指定します。 -
--rt-kernel=true
は、リアルタイムカーネルを有効にします。 -
--split-reserved-cpus-across-numa=false
は、NUMA ノード間での予約済み CPU の分割を無効にします。 -
--power-consumption-mode=ultra-low-latency
は、消費電力の増加を犠牲にして、レイテンシーを最小限に抑えることを指定します。 --offlined-cpu-count=1
は、オフラインの CPU を 1 つ指定します。注記この例の
mcp-name
引数は、コマンドoc get mcp
の出力に基づいてworker-cnf
に設定されます。シングルノード OpenShift の場合は、--mcp-name=master
を使用します。
-
次のコマンドを実行して、作成された YAML ファイルを確認します。
$ cat my-performance-profile.yaml
出力例
--- apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: cpu: isolated: 2-3 offlined: "1" reserved: "0" machineConfigPoolSelector: machineconfiguration.openshift.io/role: worker-cnf nodeSelector: node-role.kubernetes.io/worker-cnf: "" numa: topologyPolicy: restricted realTimeKernel: enabled: true workloadHints: highPowerConsumption: true perPodPowerManagement: false realTime: true
生成されたプロファイルを適用します。
$ oc apply -f my-performance-profile.yaml
出力例
performanceprofile.performance.openshift.io/performance created
14.2.1.6. Performance Profile Creator の引数
引数 | 説明 |
---|---|
|
ターゲットマシンに対応する |
| must gather ディレクトリーのパス。
この引数は、Podman を使用して PPC ツールを実行する場合にのみ必要です。ラッパースクリプトで PPC を使用する場合は、この引数を使用しないでください。代わりに、ラッパースクリプトの |
| 予約された CPU の数。ゼロより大きい自然数を使用してください。 |
| リアルタイムカーネルを有効にします。
使用できる値は |
引数 | 説明 |
---|---|
| ハイパースレッディングを無効にします。
使用できる値は
デフォルト: 警告
この引数が |
|
クラスター情報を取得します。この引数には、 以下の値を使用できます。
デフォルト: |
| オフラインの CPU の数。 注記 ゼロより大きい自然数を使用してください。十分な数の論理プロセッサーがオフラインになっていない場合、エラーメッセージがログに記録されます。メッセージは次のとおりです。 Error: failed to compute the reserved and isolated CPUs: please ensure that reserved-cpu-count plus offlined-cpu-count should be in the range [0,1] Error: failed to compute the reserved and isolated CPUs: please specify the offlined CPU count in the range [0,1] |
| 電力消費モード。 以下の値を使用できます。
デフォルト: |
|
Pod ごとの電源管理を有効にします。電力消費モードとして
使用できる値は
デフォルト: |
| 作成するパフォーマンスプロファイルの名前。
デフォルト: |
| NUMA ノード全体で予約された CPU を分割します。
使用できる値は
デフォルト: |
| 作成するパフォーマンスプロファイルの kubelet Topology Manager ポリシー。 以下の値を使用できます。
デフォルト: |
| ユーザーレベルのネットワーク (DPDK) を有効にして実行します。
使用できる値は
デフォルト: |
14.2.1.7. リファレンスパフォーマンスプロファイル
次のリファレンスパフォーマンスプロファイルをベースに、独自のカスタムプロファイルを作成してください。
14.2.1.7.1. OpenStack で OVS-DPDK を使用するクラスター用のパフォーマンスプロファイルテンプレート
Red Hat OpenStack Platform (RHOSP) で Open vSwitch と Data Plane Development Kit (OVS-DPDK) を使用するクラスターでマシンのパフォーマンスを最大化するには、パフォーマンスプロファイルを使用できます。
次のパフォーマンスプロファイルテンプレートを使用して、デプロイメント用のプロファイルを作成できます。
OVS-DPDK を使用するクラスター用のパフォーマンスプロファイルテンプレート
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: cnf-performanceprofile spec: additionalKernelArgs: - nmi_watchdog=0 - audit=0 - mce=off - processor.max_cstate=1 - idle=poll - intel_idle.max_cstate=0 - default_hugepagesz=1GB - hugepagesz=1G - intel_iommu=on cpu: isolated: <CPU_ISOLATED> reserved: <CPU_RESERVED> hugepages: defaultHugepagesSize: 1G pages: - count: <HUGEPAGES_COUNT> node: 0 size: 1G nodeSelector: node-role.kubernetes.io/worker: '' realTimeKernel: enabled: false globallyDisableIrqLoadBalancing: true
CPU_ISOLATED
キー、CPU_RESERVED
キー、および HUGEPAGES_COUNT
キーの設定に適した値を入力します。
14.2.1.7.2. 通信事業者 RAN DU 用のリファレンス設計パフォーマンスプロファイル
次のパフォーマンスプロファイルは、通信事業者の RAN DU ワークロードをホストするコモディティーハードウェア上の OpenShift Container Platform クラスターのパフォーマンス設定を指定します。
通信事業者 RAN DU 用のリファレンス設計パフォーマンスプロファイル
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name} # Also in file 'validatorCRs/informDuValidator.yaml': # name: 50-performance-${PerformanceProfile.metadata.name} name: openshift-node-performance-profile annotations: ran.openshift.io/reference-configuration: "ran-du.redhat.com" spec: additionalKernelArgs: - "rcupdate.rcu_normal_after_boot=0" - "efi=runtime" - "vfio_pci.enable_sriov=1" - "vfio_pci.disable_idle_d3=1" - "module_blacklist=irdma" cpu: isolated: $isolated reserved: $reserved hugepages: defaultHugepagesSize: $defaultHugepagesSize pages: - size: $size count: $count node: $node machineConfigPoolSelector: pools.operator.machineconfiguration.openshift.io/$mcp: "" nodeSelector: node-role.kubernetes.io/$mcp: "" numa: topologyPolicy: "restricted" # To use the standard (non-realtime) kernel, set enabled to false realTimeKernel: enabled: true workloadHints: # WorkloadHints defines the set of upper level flags for different type of workloads. # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints # for detailed descriptions of each item. # The configuration below is set for a low latency, performance mode. realTime: true highPowerConsumption: false perPodPowerManagement: false
14.2.1.7.3. 通信事業者向けコアリファレンス設計パフォーマンスプロファイル
次のパフォーマンスプロファイルは、通信事業者のコアワークロードをホストするコモディティーハードウェア上の OpenShift Container Platform クラスターのパフォーマンス設定をノードレベルで指定します。
通信事業者向けコアリファレンス設計パフォーマンスプロファイル
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name} # Also in file 'validatorCRs/informDuValidator.yaml': # name: 50-performance-${PerformanceProfile.metadata.name} name: openshift-node-performance-profile annotations: ran.openshift.io/reference-configuration: "ran-du.redhat.com" spec: additionalKernelArgs: - "rcupdate.rcu_normal_after_boot=0" - "efi=runtime" - "vfio_pci.enable_sriov=1" - "vfio_pci.disable_idle_d3=1" - "module_blacklist=irdma" cpu: isolated: $isolated reserved: $reserved hugepages: defaultHugepagesSize: $defaultHugepagesSize pages: - size: $size count: $count node: $node machineConfigPoolSelector: pools.operator.machineconfiguration.openshift.io/$mcp: "" nodeSelector: node-role.kubernetes.io/$mcp: "" numa: topologyPolicy: "restricted" # To use the standard (non-realtime) kernel, set enabled to false realTimeKernel: enabled: true workloadHints: # WorkloadHints defines the set of upper level flags for different type of workloads. # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints # for detailed descriptions of each item. # The configuration below is set for a low latency, performance mode. realTime: true highPowerConsumption: false perPodPowerManagement: false
14.2.2. サポートされているパフォーマンスプロファイルの API バージョン
Node Tuning Operator は、パフォーマンスプロファイル apiVersion
フィールドの v2
、v1
、および v1alpha1
をサポートします。v1 および v1alpha1 API は同一です。v2 API には、デフォルト値の false
が設定されたオプションのブール値フィールド globallyDisableIrqLoadBalancing
が含まれます。
デバイス割り込み処理を使用するためのパフォーマンスプロファイルのアップグレード
Node Tuning Operator パフォーマンスプロファイルのカスタムリソース定義 (CRD) を v1 または v1alpha1 から v2 にアップグレードする場合、globallyDisableIrqLoadBalancing
は true
に設定されます。
globallyDisableIrqLoadBalancing
は、IRQ ロードバランシングを分離 CPU セットに対して無効にするかどうかを切り替えます。このオプションを true
に設定すると、分離 CPU セットの IRQ ロードバランシングが無効になります。オプションを false
に設定すると、IRQ をすべての CPU 間でバランスさせることができます。
Node Tuning Operator API の v1alpha1 から v1 へのアップグレード
Node Tuning Operator API バージョンを v1alpha1 から v1 にアップグレードする場合、v1alpha1 パフォーマンスプロファイルは "None" 変換ストラテジーを使用してオンザフライで変換され、API バージョン v1 の Node Tuning Operator に提供されます。
Node Tuning Operator API の v1alpha1 または v1 から v2 へのアップグレード
古い Node Tuning Operator API バージョンからアップグレードする場合、既存の v1 および v1alpha1 パフォーマンスプロファイルは、globallyDisableIrqLoadBalancing
フィールドに true
の値を挿入する変換 Webhook を使用して変換されます。
14.2.3. ワークロードヒントを使用したノードの電力消費とリアルタイム処理の設定
手順
-
Performance Profile Creator (PPC) ツールを使用して、環境のハードウェアとトポロジーに適した
PerformanceProfile
を作成します。次の表は、PPC ツールに関連付けられたpower-consumption-mode
フラグに設定可能な値と、適用されるワークロードヒントを示しています。
Performance Profile Creator の設定 | ヒント | 環境 | 説明 |
---|---|---|---|
デフォルト |
workloadHints: highPowerConsumption: false realTime: false | レイテンシー要件のない高スループットクラスター | CPU パーティショニングのみで達成されるパフォーマンス。 |
Low-latency |
workloadHints: highPowerConsumption: false realTime: true | 地域のデータセンター | エネルギー節約と低レイテンシーの両方が望ましい: 電力管理、レイテンシー、スループットの間の妥協。 |
Ultra-low-latency |
workloadHints: highPowerConsumption: true realTime: true | ファーエッジクラスター、レイテンシークリティカルなワークロード | 消費電力の増加を犠牲にして、絶対的な最小のレイテンシーと最大の決定論のために最適化されています。 |
Pod ごとの電源管理 |
workloadHints: realTime: true highPowerConsumption: false perPodPowerManagement: true | 重要なワークロードと重要でないワークロード | Pod ごとの電源管理が可能です。 |
例
次の設定は、通信事業者向け RAN DU デプロイメントで一般的に使用されます。
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
name: workload-hints
spec:
...
workloadHints:
realTime: true
highPowerConsumption: false
perPodPowerManagement: false 1
- 1
- システムの待ち時間に影響を与える可能性のある一部のデバッグおよび監視機能を無効にします。
パフォーマンスプロファイルで realTime
ワークロードヒントフラグが true
に設定されている場合は、固定された CPU を持つすべての保証された Pod に cpu-quota.crio.io: disable
アノテーションを追加します。このアノテーションは、Pod 内のプロセスのパフォーマンスの低下を防ぐために必要です。realTime
ワークロードヒントが明示的に設定されていない場合は、デフォルトで true
になります。
電力消費とリアルタイム設定の組み合わせがレイテンシーにどのような影響を与えるかの詳細は、Understanding workload hints を参照してください。
14.2.4. 高優先度のワークロードと低優先度のワークロードを同じ場所で実行するノードの省電力設定
優先度の高いワークロードのレイテンシーやスループットに影響を与えることなく、優先度の高いワークロードと同じ場所にある優先度の低いワークロードを持つノードの省電力を有効にすることができます。ワークロード自体を変更することなく、省電力が可能です。
この機能は、Intel Ice Lake 以降の世代の Intel CPU でサポートされています。プロセッサーの機能は、優先度の高いワークロードのレイテンシーとスループットに影響を与える可能性があります。
前提条件
- BIOS の C ステートとオペレーティングシステム制御の P ステートを有効にした。
手順
per-pod-power-management
引数をtrue
に設定してPerformanceProfile
を生成します。$ podman run --entrypoint performance-profile-creator -v \ /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.14 \ --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true \ --split-reserved-cpus-across-numa=false --topology-manager-policy=single-numa-node \ --must-gather-dir-path /must-gather --power-consumption-mode=low-latency \ 1 --per-pod-power-management=true > my-performance-profile.yaml
- 1
per-pod-power-management
引数がtrue
に設定されている場合、power-consumption-mode
引数はdefault
またはlow-latency
にする必要があります。
perPodPowerManagement
を使用したPerformanceProfile
の例apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: [.....] workloadHints: realTime: true highPowerConsumption: false perPodPowerManagement: true
デフォルトの
cpufreq
ガバナーを、PerformanceProfile
カスタムリソース (CR) で追加のカーネル引数として設定します。apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: performance spec: ... additionalKernelArgs: - cpufreq.default_governor=schedutil 1
- 1
schedutil
ガバナーの使用が推奨されますが、ondemand
ガバナーやpowersave
ガバナーなどの他のガバナーを使用することもできます。
TunedPerformancePatch
CR で最大 CPU 周波数を設定します。spec: profile: - data: | [sysfs] /sys/devices/system/cpu/intel_pstate/max_perf_pct = <x> 1
- 1
max_perf_pct
は、cpufreq
ドライバーが設定できる最大周波数を、サポートされている最大 CPU 周波数のパーセンテージの形で制御します。この値はすべての CPU に適用されます。サポートされている最大周波数は/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
で確認できます。開始点として、All Cores Turbo
周波数ですべての CPU を制限する割合を使用できます。All Cores Turbo
周波数は、すべてのコアがすべて使用されているときに全コアが実行される周波数です。
14.2.5. インフラストラクチャーおよびアプリケーションコンテナーの CPU の制限
一般的なハウスキーピングおよびワークロードタスクは、レイテンシーの影響を受けやすいプロセスに影響を与える可能性のある方法で CPU を使用します。デフォルトでは、コンテナーランタイムはすべてのオンライン CPU を使用して、すべてのコンテナーを一緒に実行します。これが原因で、コンテキストスイッチおよびレイテンシーが急増する可能性があります。CPU をパーティショニングすることで、ノイズの多いプロセスとレイテンシーの影響を受けやすいプロセスを分離し、干渉を防ぐことができます。以下の表は、Node Tuning Operator を使用してノードを調整した後、CPU でプロセスがどのように実行されるかを示しています。
プロセスタイプ | Details |
---|---|
| 低レイテンシーのワークロードが実行されている場合を除き、任意の CPU で実行されます。 |
インフラストラクチャー Pod | 低レイテンシーのワークロードが実行されている場合を除き、任意の CPU で実行されます。 |
割り込み | 予約済み CPU にリダイレクトします (OpenShift Container Platform 4.7 以降ではオプション) |
カーネルプロセス | 予約済み CPU へのピン |
レイテンシーの影響を受けやすいワークロード Pod | 分離されたプールからの排他的 CPU の特定のセットへのピン |
OS プロセス/systemd サービス | 予約済み CPU へのピン |
すべての QoS プロセスタイプ (Burstable
、BestEffort
、または Guaranteed
) の Pod に割り当て可能なノード上のコアの容量は、分離されたプールの容量と同じです。予約済みプールの容量は、クラスターおよびオペレーティングシステムのハウスキーピング業務で使用するためにノードの合計コア容量から削除されます。
例 1
ノードは 100 コアの容量を備えています。クラスター管理者は、パフォーマンスプロファイルを使用して、50 コアを分離プールに割り当て、50 コアを予約プールに割り当てます。クラスター管理者は、25 コアを QoS Guaranteed
Pod に割り当て、25 コアを BestEffort
または Burstable
Pod に割り当てます。これは、分離されたプールの容量と一致します。
例 2
ノードは 100 コアの容量を備えています。クラスター管理者は、パフォーマンスプロファイルを使用して、50 コアを分離プールに割り当て、50 コアを予約プールに割り当てます。クラスター管理者は、50 個のコアを QoS Guaranteed
Pod に割り当て、1 個のコアを BestEffort
または Burstable
Pod に割り当てます。これは、分離されたプールの容量を 1 コア超えています。CPU 容量が不十分なため、Pod のスケジューリングが失敗します。
使用する正確なパーティショニングパターンは、ハードウェア、ワークロードの特性、予想されるシステム負荷などの多くの要因によって異なります。いくつかのサンプルユースケースは次のとおりです。
- レイテンシーの影響を受けやすいワークロードがネットワークインターフェイスコントローラー (NIC) などの特定のハードウェアを使用する場合は、分離されたプール内の CPU が、このハードウェアにできるだけ近いことを確認してください。少なくとも、ワークロードを同じ Non-Uniform Memory Access (NUMA) ノードに配置する必要があります。
- 予約済みプールは、すべての割り込みを処理するために使用されます。システムネットワークに依存する場合は、すべての着信パケット割り込みを処理するために、十分なサイズの予約プールを割り当てます。4.14 以降のバージョンでは、ワークロードはオプションで機密としてラベル付けできます。
予約済みパーティションと分離パーティションにどの特定の CPU を使用するかを決定するには、詳細な分析と測定が必要です。デバイスやメモリーの NUMA アフィニティーなどの要因が作用しています。選択は、ワークロードアーキテクチャーと特定のユースケースにも依存します。
予約済みの CPU プールと分離された CPU プールは重複してはならず、これらは共に、ワーカーノードの利用可能なすべてのコアに広がる必要があります。
ハウスキーピングタスクとワークロードが相互に干渉しないようにするには、パフォーマンスプロファイルの spec
セクションで CPU の 2 つのグループを指定します。
-
isolated
- アプリケーションコンテナーワークロードの CPU を指定します。これらの CPU のレイテンシーが一番低くなります。このグループのプロセスには割り込みがないため、DPDK ゼロパケットロスの帯域幅がより高くなります。 -
reserved
- クラスターおよびオペレーティングシステムのハウスキーピング業務用の CPU を指定します。reserved
グループのスレッドは、ビジーであることが多いです。reserved
グループでレイテンシーの影響を受けやすいアプリケーションを実行しないでください。レイテンシーの影響を受けやすいアプリケーションは、isolated
グループで実行されます。
手順
- 環境のハードウェアとトポロジーに適したパフォーマンスプロファイルを作成します。
infra およびアプリケーションコンテナー用に予約して分離する CPU で、
reserved
およびisolated
パラメーターを追加します。apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: infra-cpus spec: cpu: reserved: "0-4,9" 1 isolated: "5-8" 2 nodeSelector: 3 node-role.kubernetes.io/worker: ""
14.2.6. クラスターのハイパースレッディングの設定
OpenShift Container Platform クラスターのハイパースレッディングを設定するには、パフォーマンスプロファイル内の CPU スレッド数を、予約済みまたは分離された CPU プールに設定されているのと同じコア数に設定します。
パフォーマンスプロファイルを設定してからホストのハイパースレッディング設定を変更する場合は、PerformanceProfile
YAML の CPU isolated
フィールドと reserved
フィールドを新しい設定に合わせて更新してください。
以前に有効にしたホストのハイパースレッディング設定を無効にすると、PerformanceProfile
YAML にリストされている CPU コアの ID が正しくなくなる可能性があります。この設定が間違っていると、リスト表示される CPU が見つからなくなるため、ノードが利用できなくなる可能性があります。
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 - OpenShift CLI (oc) のインストール。
手順
設定する必要のあるホストのどの CPU でどのスレッドが実行されているかを確認します。
クラスターにログインして以下のコマンドを実行し、ホスト CPU で実行されているスレッドを表示できます。
$ lscpu --all --extended
出力例
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ MINMHZ 0 0 0 0 0:0:0:0 yes 4800.0000 400.0000 1 0 0 1 1:1:1:0 yes 4800.0000 400.0000 2 0 0 2 2:2:2:0 yes 4800.0000 400.0000 3 0 0 3 3:3:3:0 yes 4800.0000 400.0000 4 0 0 0 0:0:0:0 yes 4800.0000 400.0000 5 0 0 1 1:1:1:0 yes 4800.0000 400.0000 6 0 0 2 2:2:2:0 yes 4800.0000 400.0000 7 0 0 3 3:3:3:0 yes 4800.0000 400.0000
この例では、4 つの物理 CPU コアで 8 つの論理 CPU コアが実行されています。CPU0 および CPU4 は物理コアの Core0 で実行されており、CPU1 および CPU5 は物理コア 1 で実行されています。
または、特定の物理 CPU コア (以下の例では
cpu0
) に設定されているスレッドを表示するには、シェルプロンプトを開いて次のコマンドを実行します。$ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
出力例
0-4
PerformanceProfile
YAML で分離された CPU および予約された CPU を適用します。たとえば、論理コア CPU0 と CPU4 をisolated
として設定し、論理コア CPU1 から CPU3 および CPU5 から CPU7 をreserved
として設定できます。予約および分離された CPU を設定する場合に、Pod 内の infra コンテナーは予約された CPU を使用し、アプリケーションコンテナーは分離された CPU を使用します。... cpu: isolated: 0,4 reserved: 1-3,5-7 ...
注記予約済みの CPU プールと分離された CPU プールは重複してはならず、これらは共に、ワーカーノードの利用可能なすべてのコアに広がる必要があります。
ハイパースレッディングは、ほとんどの Intel プロセッサーでデフォルトで有効になっています。ハイパースレッディングが有効な場合、特定のコアで処理されるすべてのスレッドを分離するか、同じコアで処理する必要があります。
ハイパースレッディングが有効な場合、保証されたすべての Pod が、Pod の障害を引き起こす可能性がある "ノイジーネイバー" 状況を回避するために、同時マルチスレッディング (SMT) レベルの倍数を使用する必要があります。詳細は、Static policy options を参照してください。
14.2.6.1. 低レイテンシーアプリケーション用のハイパースレッディングの無効化
低レイテンシー処理用にクラスターを設定する場合は、クラスターをデプロイする前に、ハイパースレッディングを無効にするかどうかを検討してください。ハイパースレッディングを無効にするには、次の手順を実行します。
- ハードウェアとトポロジーに適したパフォーマンスプロファイルを作成します。
nosmt
を追加のカーネル引数として設定します。以下のパフォーマンスプロファイルの例は、この設定について示しています。apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: example-performanceprofile spec: additionalKernelArgs: - nmi_watchdog=0 - audit=0 - mce=off - processor.max_cstate=1 - idle=poll - intel_idle.max_cstate=0 - nosmt cpu: isolated: 2-3 reserved: 0-1 hugepages: defaultHugepagesSize: 1G pages: - count: 2 node: 0 size: 1G nodeSelector: node-role.kubernetes.io/performance: '' realTimeKernel: enabled: true
注記予約および分離された CPU を設定する場合に、Pod 内の infra コンテナーは予約された CPU を使用し、アプリケーションコンテナーは分離された CPU を使用します。
14.2.7. Guaranteed Pod の分離された CPU のデバイス割り込み処理の管理
Node Tuning Operator は、ホスト CPU を、Pod Infra コンテナーを含むクラスターとオペレーティングシステムのハウスキーピング業務用の予約 CPU と、ワークロードを実行するアプリケーションコンテナー用の分離 CPU に分割して管理することができます。これにより、低レイテンシーのワークロード用の CPU を isolated (分離された CPU) として設定できます。
デバイスの割り込みについては、Guaranteed Pod が実行されている CPU を除き、CPU のオーバーロードを防ぐためにすべての分離された CPU および予約された CPU 間で負荷が分散されます。Guaranteed Pod の CPU は、関連するアノテーションが Pod に設定されている場合にデバイス割り込みを処理できなくなります。
パフォーマンスプロファイルで、globallyDisableIrqLoadBalancing
は、デバイス割り込みが処理されるかどうかを管理するために使用されます。特定のワークロードでは、予約された CPU は、デバイスの割り込みを処理するのに常に十分な訳ではないため、デバイスの割り込みは分離された CPU でグローバルに無効化されていません。デフォルトでは、Node Tuning Operator は分離された CPU でのデバイス割り込みを無効にしません。
14.2.7.1. ノードの有効な IRQ アフィニティー設定の確認
一部の IRQ コントローラーでは IRQ アフィニティー設定がサポートされていないため、常にすべてのオンライン CPU が IRQ マスクとして公開されます。これらの IRQ コントローラーは CPU 0 で正常に実行されます。
以下は、IRQ アフィニティー設定がサポートされていないことを Red Hat が認識しているドライバーとハードウェアの例です。このリストはすべてを網羅しているわけではありません。
-
megaraid_sas
などの一部の RAID コントローラードライバー - 多くの不揮発性メモリーエクスプレス (NVMe) ドライバー
- 一部の LAN on Motherboard (LOM) ネットワークコントローラー
-
managed_irqs
を使用するドライバー
IRQ アフィニティー設定をサポートしない理由は、プロセッサーの種類、IRQ コントローラー、マザーボードの回路接続などに関連している可能性があります。
分離された CPU に有効な IRQ アフィニティーが設定されている場合は、一部のハードウェアまたはドライバーで IRQ アフィニティー設定がサポートされていないことを示唆している可能性があります。有効なアフィニティーを見つけるには、ホストにログインし、次のコマンドを実行します。
$ find /proc/irq -name effective_affinity -printf "%p: " -exec cat {} \;
出力例
/proc/irq/0/effective_affinity: 1 /proc/irq/1/effective_affinity: 8 /proc/irq/2/effective_affinity: 0 /proc/irq/3/effective_affinity: 1 /proc/irq/4/effective_affinity: 2 /proc/irq/5/effective_affinity: 1 /proc/irq/6/effective_affinity: 1 /proc/irq/7/effective_affinity: 1 /proc/irq/8/effective_affinity: 1 /proc/irq/9/effective_affinity: 2 /proc/irq/10/effective_affinity: 1 /proc/irq/11/effective_affinity: 1 /proc/irq/12/effective_affinity: 4 /proc/irq/13/effective_affinity: 1 /proc/irq/14/effective_affinity: 1 /proc/irq/15/effective_affinity: 1 /proc/irq/24/effective_affinity: 2 /proc/irq/25/effective_affinity: 4 /proc/irq/26/effective_affinity: 2 /proc/irq/27/effective_affinity: 1 /proc/irq/28/effective_affinity: 8 /proc/irq/29/effective_affinity: 4 /proc/irq/30/effective_affinity: 4 /proc/irq/31/effective_affinity: 8 /proc/irq/32/effective_affinity: 8 /proc/irq/33/effective_affinity: 1 /proc/irq/34/effective_affinity: 2
一部のドライバーは、managed_irqs
を使用します。そのアフィニティーはカーネルによって内部的に管理され、ユーザー空間はアフィニティーを変更できません。場合によっては、これらの IRQ が分離された CPU に割り当てられることもあります。manage_irqs
の詳細は、Affinity of managed interrupts cannot be changed even if they target isolated CPU を参照してください。
14.2.7.2. IRQ 動的負荷分散用ノードの設定
どのコアがデバイス割り込み要求 (IRQ) を受信できるかを制御するために、IRQ 動的負荷分散用にクラスターノードを設定します。
前提条件
- コアを分離するには、すべてのサーバーハードウェアコンポーネントが IRQ アフィニティーをサポートしている必要があります。サーバーのハードウェアコンポーネントが IRQ アフィニティーをサポートしているかどうかを確認するには、サーバーのハードウェア仕様を参照するか、ハードウェアプロバイダーに問い合わせてください。
手順
- cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインします。
-
パフォーマンスプロファイルの
apiVersion
をperformance.openshift.io/v2
を使用するように設定します。 -
globallyDisableIrqLoadBalancing
フィールドを削除するか、これをfalse
に設定します。 適切な分離された CPU と予約された CPU を設定します。以下のスニペットは、2 つの CPU を確保するプロファイルを示しています。IRQ 負荷分散は、
isolated
CPU セットで実行されている Pod について有効にされます。apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: dynamic-irq-profile spec: cpu: isolated: 2-5 reserved: 0-1 ...
注記予約および分離された CPU を設定する場合に、Pod 内の infra コンテナーは予約された CPU を使用し、アプリケーションコンテナーは分離された CPU を使用します。
排他的な CPU を使用する Pod を作成し、
irq-load-balancing.crio.io
およびcpu-quota.crio.io
アノテーションをdisable
に設定します。以下に例を示します。apiVersion: v1 kind: Pod metadata: name: dynamic-irq-pod annotations: irq-load-balancing.crio.io: "disable" cpu-quota.crio.io: "disable" spec: containers: - name: dynamic-irq-pod image: "registry.redhat.io/openshift4/cnf-tests-rhel8:v4.14" command: ["sleep", "10h"] resources: requests: cpu: 2 memory: "200M" limits: cpu: 2 memory: "200M" nodeSelector: node-role.kubernetes.io/worker-cnf: "" runtimeClassName: performance-dynamic-irq-profile ...
-
performance-<profile_name> の形式で Pod
runtimeClassName
を入力します。ここで、<profile_name> はPerformanceProfile
YAML のname
です (例:performance-dynamic-irq-profile
)。 - ノードセレクターを cnf-worker をターゲットに設定するように設定します。
Pod が正常に実行されていることを確認します。ステータスが
running
であり、正しい cnf-worker ノードが設定されている必要があります。$ oc get pod -o wide
予想される出力
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES dynamic-irq-pod 1/1 Running 0 5h33m <ip-address> <node-name> <none> <none>
IRQ の動的負荷分散向けに設定された Pod が実行される CPU を取得します。
$ oc exec -it dynamic-irq-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"
予想される出力
Cpus_allowed_list: 2-3
ノードの設定が正しく適用されていることを確認します。ノードにログインして設定を確認します。
$ oc debug node/<node-name>
予想される出力
Starting pod/<node-name>-debug ... To use host binaries, run `chroot /host` Pod IP: <ip-address> If you don't see a command prompt, try pressing enter. sh-4.4#
ノードのファイルシステムを使用できることを確認します。
sh-4.4# chroot /host
予想される出力
sh-4.4#
デフォルトのシステム CPU アフィニティーマスクに
dynamic-irq-pod
CPU(例: CPU 2 および 3) が含まれないようにします。$ cat /proc/irq/default_smp_affinity
出力例
33
システム IRQ が
dynamic-irq-pod
CPU で実行されるように設定されていないことを確認します。find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;
出力例
/proc/irq/0/smp_affinity_list: 0-5 /proc/irq/1/smp_affinity_list: 5 /proc/irq/2/smp_affinity_list: 0-5 /proc/irq/3/smp_affinity_list: 0-5 /proc/irq/4/smp_affinity_list: 0 /proc/irq/5/smp_affinity_list: 0-5 /proc/irq/6/smp_affinity_list: 0-5 /proc/irq/7/smp_affinity_list: 0-5 /proc/irq/8/smp_affinity_list: 4 /proc/irq/9/smp_affinity_list: 4 /proc/irq/10/smp_affinity_list: 0-5 /proc/irq/11/smp_affinity_list: 0 /proc/irq/12/smp_affinity_list: 1 /proc/irq/13/smp_affinity_list: 0-5 /proc/irq/14/smp_affinity_list: 1 /proc/irq/15/smp_affinity_list: 0 /proc/irq/24/smp_affinity_list: 1 /proc/irq/25/smp_affinity_list: 1 /proc/irq/26/smp_affinity_list: 1 /proc/irq/27/smp_affinity_list: 5 /proc/irq/28/smp_affinity_list: 1 /proc/irq/29/smp_affinity_list: 0 /proc/irq/30/smp_affinity_list: 0-5
14.2.8. Huge Page の設定
ノードは、OpenShift Container Platform クラスターで使用される Huge Page を事前に割り当てる必要があります。Node Tuning Operator を使用し、特定のノードで Huge Page を割り当てます。
OpenShift Container Platform は、Huge Page を作成し、割り当てる方法を提供します。Node Tuning Operator は、パフォーマンスプロファイルを使用して、これをより簡単に行う方法を提供します。
たとえば、パフォーマンスプロファイルの hugepages
pages
セクションで、size
、count
、およびオプションで node
の複数のブロックを指定できます。
hugepages:
defaultHugepagesSize: "1G"
pages:
- size: "1G"
count: 4
node: 0 1
- 1
node
は、Huge Page が割り当てられる NUMA ノードです。node
を省略すると、ページはすべての NUMA ノード間で均等に分散されます。
更新が完了したことを示す関連するマシン設定プールのステータスを待機します。
これらは、Huge Page を割り当てるのに必要な唯一の設定手順です。
検証
設定を確認するには、ノード上の
/proc/meminfo
ファイルを参照します。$ oc debug node/ip-10-0-141-105.ec2.internal
# grep -i huge /proc/meminfo
出力例
AnonHugePages: ###### ## ShmemHugePages: 0 kB HugePages_Total: 2 HugePages_Free: 2 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: #### ## Hugetlb: #### ##
新規サイズを報告するには、
oc describe
を使用します。$ oc describe node worker-0.ocp4poc.example.com | grep -i huge
出力例
hugepages-1g=true hugepages-###: ### hugepages-###: ###
14.2.8.1. 複数の Huge Page サイズの割り当て
同じコンテナーで異なるサイズの Huge Page を要求できます。これにより、Huge Page サイズのニーズの異なる複数のコンテナーで構成されるより複雑な Pod を定義できます。
たとえば、サイズ 1G
と 2M
を定義でき、Node Tuning Operator は以下に示すようにノード上に両方のサイズを設定します。
spec: hugepages: defaultHugepagesSize: 1G pages: - count: 1024 node: 0 size: 2M - count: 4 node: 1 size: 1G
14.2.9. Node Tuning Operator を使用した NIC キューの削減
Node Tuning Operator は、NIC キューを削減してパフォーマンスを向上させるのに役立ちます。パフォーマンスプロファイルを使用して調整を行い、さまざまなネットワークデバイスのキューをカスタマイズできます。
14.2.9.1. パフォーマンスプロファイルによる NIC キューの調整
パフォーマンスプロファイルを使用すると、各ネットワークデバイスのキュー数を調整できます。
サポート対象のネットワークデバイスは以下のとおりです。
- 非仮想ネットワークデバイス
- 複数のキュー (チャネル) をサポートするネットワークデバイス
サポート対象外のネットワークデバイスは以下の通りです。
- Pure Software ネットワークインターフェイス
- ブロックデバイス
- Intel DPDK Virtual Function
前提条件
-
cluster-admin
ロールを持つユーザーとしてクラスターにアクセスできる。 -
OpenShift CLI (
oc
) がインストールされている。
手順
-
cluster-admin
権限を持つユーザーとして、Node Tuning Operator を実行する OpenShift Container Platform クラスターにログインします。 - お使いのハードウェアとトポロジーに適したパフォーマンスプロファイルを作成して適用します。プロファイルの作成に関するガイダンスは、「パフォーマンスプロファイルの作成」セクションを参照してください。
この作成したパフォーマンスプロファイルを編集します。
$ oc edit -f <your_profile_name>.yaml
spec
フィールドにnet
オブジェクトを設定します。オブジェクトリストには、以下の 2 つのフィールドを含めることができます。-
userLevelNetworking
は、ブール値フラグとして指定される必須フィールドです。userLevelNetworking
がtrue
の場合、サポートされているすべてのデバイスのキュー数は、予約された CPU 数に設定されます。デフォルトはfalse
です。 devices
は、キューを予約 CPU 数に設定するデバイスのリストを指定する任意のフィールドです。デバイスリストに何も指定しないと、設定がすべてのネットワークデバイスに適用されます。設定は以下のとおりです。interfaceName
: このフィールドはインターフェイス名を指定し、正または負のシェルスタイルのワイルドカードをサポートします。-
ワイルドカード構文の例:
<string> .*
-
負のルールには、感嘆符のプリフィックスが付きます。除外リスト以外のすべてのデバイスにネットキューの変更を適用するには、
!<device>
を使用します (例:!eno1
)。
-
ワイルドカード構文の例:
-
vendorID
: 16 ビット (16 進数) として表されるネットワークデバイスベンダー ID。接頭辞は0x
です。 9
deviceID
: 16 ビット (16 進数) として表されるネットワークデバイス ID (モデル)。接頭辞は0x
です。注記deviceID
が指定されている場合は、vendorID
も定義する必要があります。デバイスエントリーinterfaceName
、vendorID
、またはvendorID
とdeviceID
のペアで指定されているすべてのデバイス識別子に一致するデバイスは、ネットワークデバイスとしての資格があります。その後、このネットワークデバイスは net キュー数が予約 CPU 数に設定されます。2 つ以上のデバイスを指定すると、net キュー数は、それらのいずれかに一致する net デバイスに設定されます。
-
このパフォーマンスプロファイルの例を使用して、キュー数をすべてのデバイスの予約 CPU 数に設定します。
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: manual spec: cpu: isolated: 3-51,55-103 reserved: 0-2,52-54 net: userLevelNetworking: true nodeSelector: node-role.kubernetes.io/worker-cnf: ""
このパフォーマンスプロファイルの例を使用して、定義されたデバイス識別子に一致するすべてのデバイスの予約 CPU 数にキュー数を設定します。
apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: manual spec: cpu: isolated: 3-51,55-103 reserved: 0-2,52-54 net: userLevelNetworking: true devices: - interfaceName: "eth0" - interfaceName: "eth1" - vendorID: "0x1af4" deviceID: "0x1000" nodeSelector: node-role.kubernetes.io/worker-cnf: ""
このパフォーマンスプロファイルの例を使用して、インターフェイス名
eth
で始まるすべてのデバイスの予約 CPU 数にキュー数を設定します。apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: manual spec: cpu: isolated: 3-51,55-103 reserved: 0-2,52-54 net: userLevelNetworking: true devices: - interfaceName: "eth*" nodeSelector: node-role.kubernetes.io/worker-cnf: ""
このパフォーマンスプロファイルの例を使用して、
eno1
以外の名前のインターフェイスを持つすべてのデバイスの予約 CPU 数にキュー数を設定します。apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: manual spec: cpu: isolated: 3-51,55-103 reserved: 0-2,52-54 net: userLevelNetworking: true devices: - interfaceName: "!eno1" nodeSelector: node-role.kubernetes.io/worker-cnf: ""
このパフォーマンスプロファイルの例を使用して、インターフェイス名
eth0
、0x1af4
のvendorID
、および0x1000
のdeviceID
を持つすべてのデバイスの予約 CPU 数にキュー数を設定します。apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: manual spec: cpu: isolated: 3-51,55-103 reserved: 0-2,52-54 net: userLevelNetworking: true devices: - interfaceName: "eth0" - vendorID: "0x1af4" deviceID: "0x1000" nodeSelector: node-role.kubernetes.io/worker-cnf: ""
更新されたパフォーマンスプロファイルを適用します。
$ oc apply -f <your_profile_name>.yaml
関連情報
14.2.9.2. キューステータスの確認
このセクションでは、さまざまなパフォーマンスプロファイルについて、変更の適用を検証する方法を複数例示しています。
例 1
この例では、サポートされている すべて のデバイスの net キュー数は、予約された CPU 数 (2) に設定されます。
パフォーマンスプロファイルの関連セクションは次のとおりです。
apiVersion: performance.openshift.io/v2 metadata: name: performance spec: kind: PerformanceProfile spec: cpu: reserved: 0-1 #total = 2 isolated: 2-8 net: userLevelNetworking: true # ...
以下のコマンドを使用して、デバイスに関連付けられたキューのステータスを表示します。
注記パフォーマンスプロファイルが適用されたノードで、以下のコマンドを実行します。
$ ethtool -l <device>
プロファイルの適用前にキューのステータスを確認します。
$ ethtool -l ens4
出力例
Channel parameters for ens4: Pre-set maximums: RX: 0 TX: 0 Other: 0 Combined: 4 Current hardware settings: RX: 0 TX: 0 Other: 0 Combined: 4
プロファイルの適用後にキューのステータスを確認します。
$ ethtool -l ens4
出力例
Channel parameters for ens4: Pre-set maximums: RX: 0 TX: 0 Other: 0 Combined: 4 Current hardware settings: RX: 0 TX: 0 Other: 0 Combined: 2 1
- 1
- チャネルを組み合わせると、すべて のサポート対象のデバイスの予約 CPU の合計数は 2 になります。これは、パフォーマンスプロファイルでの設定内容と一致します。
例 2
この例では、サポートされている すべて のネットワークデバイスの net キュー数は、予約された CPU 数 (2) に特定の vendorID
を指定して、設定されます。
パフォーマンスプロファイルの関連セクションは次のとおりです。
apiVersion: performance.openshift.io/v2 metadata: name: performance spec: kind: PerformanceProfile spec: cpu: reserved: 0-1 #total = 2 isolated: 2-8 net: userLevelNetworking: true devices: - vendorID = 0x1af4 # ...
以下のコマンドを使用して、デバイスに関連付けられたキューのステータスを表示します。
注記パフォーマンスプロファイルが適用されたノードで、以下のコマンドを実行します。
$ ethtool -l <device>
プロファイルの適用後にキューのステータスを確認します。
$ ethtool -l ens4
出力例
Channel parameters for ens4: Pre-set maximums: RX: 0 TX: 0 Other: 0 Combined: 4 Current hardware settings: RX: 0 TX: 0 Other: 0 Combined: 2 1
- 1
vendorID=0x1af4
であるサポート対象の全デバイスの合計予約 CPU 数は 2 となります。たとえば、vendorID=0x1af4
のネットワークデバイスens2
が別に存在する場合に、このデバイスも合計で 2 つの net キューを持ちます。これは、パフォーマンスプロファイルでの設定内容と一致します。
例 3
この例では、サポートされている すべて のネットワークデバイスが定義したデバイス ID のいずれかに一致する場合に、そのネットワークデバイスの net キュー数は、予約された CPU 数 (2) に設定されます。
udevadm info
コマンドで、デバイスの詳細なレポートを確認できます。以下の例では、デバイスは以下のようになります。
# udevadm info -p /sys/class/net/ens4 ... E: ID_MODEL_ID=0x1000 E: ID_VENDOR_ID=0x1af4 E: INTERFACE=ens4 ...
# udevadm info -p /sys/class/net/eth0 ... E: ID_MODEL_ID=0x1002 E: ID_VENDOR_ID=0x1001 E: INTERFACE=eth0 ...
interfaceName
がeth0
のデバイスの場合に net キューを 2 に、vendorID=0x1af4
を持つデバイスには、以下のパフォーマンスプロファイルを設定します。apiVersion: performance.openshift.io/v2 metadata: name: performance spec: kind: PerformanceProfile spec: cpu: reserved: 0-1 #total = 2 isolated: 2-8 net: userLevelNetworking: true devices: - interfaceName = eth0 - vendorID = 0x1af4 ...
プロファイルの適用後にキューのステータスを確認します。
$ ethtool -l ens4
出力例
Channel parameters for ens4: Pre-set maximums: RX: 0 TX: 0 Other: 0 Combined: 4 Current hardware settings: RX: 0 TX: 0 Other: 0 Combined: 2 1
- 1
vendorID=0x1af4
であるサポート対象の全デバイスの合計予約 CPU 数は 2 に設定されます。たとえば、vendorID=0x1af4
のネットワークデバイスens2
が別に存在する場合に、このデバイスも合計で 2 つの net キューを持ちます。同様に、interfaceName
がeth0
のデバイスには、合計 net キューが 2 に設定されます。
14.2.9.3. NIC キューの調整に関するロギング
割り当てられたデバイスの詳細を示すログメッセージは、それぞれの Tuned デーモンログに記録されます。以下のメッセージは、/var/log/tuned/tuned.log
ファイルに記録される場合があります。
正常に割り当てられたデバイスの詳細を示す
INFO
メッセージが記録されます。INFO tuned.plugins.base: instance net_test (net): assigning devices ens1, ens2, ens3
割り当てることのできるデバイスがない場合は、
WARNING
メッセージが記録されます。WARNING tuned.plugins.base: instance net_test: no matching devices available