16.4. リアルタイムおよび低レイテンシーワークロードのプロビジョニング
多くの企業や組織は、非常に高性能なコンピューティングを必要としており、とくに金融業界や通信業界では、低い、予測可能なレイテンシーが必要になる場合があります。このような固有の要件を持つ業界では、OpenShift Container Platform は Performance Addon Operator を提供して、OpenShift Container Platform アプリケーションの低レイテンシーのパフォーマンスと一貫性のある応答時間を実現するための自動チューニングを実装します。
クラスター管理者は、このパフォーマンスプロファイル設定を使用することにより、より信頼性の高い方法でこれらの変更をより容易に実行することができます。管理者は、カーネルを kernel-rt (リアルタイム)、ハウスキーピング用に予約される CPU、ワークロードの実行に使用される CPU に更新するかどうかを指定できます。
保証された CPU を必要とするアプリケーションと組み合わせて実行プローブを使用すると、レイテンシースパイクが発生する可能性があります。代わりに、適切に設定されたネットワークプローブのセットなど、他のプローブを使用することをお勧めします。
16.4.1. リアルタイムの既知の制限
RT カーネルはワーカーノードでのみサポートされます。
リアルタイムモードを完全に使用するには、コンテナーを昇格した権限で実行する必要があります。権限の付与についての情報は、Set capabilities for a Container を参照してください。
OpenShift Container Platform は許可される機能を制限するため、SecurityContext
を作成する必要がある場合もあります。
この手順は、Red Hat Enterprise Linux CoreOS (RHCOS) システムを使用したベアメタルのインストールで完全にサポートされます。
パフォーマンスの期待値を設定する必要があるということは、リアルタイムカーネルがあらゆる問題の解決策ではないということを意味します。リアルタイムカーネルは、一貫性のある、低レイテンシーの、決定論に基づく予測可能な応答時間を提供します。リアルタイムカーネルに関連して、追加のカーネルオーバーヘッドがあります。これは、主に個別にスケジュールされたスレッドでハードウェア割り込みを処理することによって生じます。一部のワークロードのオーバーヘッドが増加すると、スループット全体が低下します。ワークロードによって異なりますが、パフォーマンスの低下の程度は 0% から 30% の範囲になります。ただし、このコストは決定論をベースとしています。
16.4.2. リアルタイム機能のあるワーカーのプロビジョニング
- Performance Addon Operator をクラスターにインストールします。
- オプション: ノードを OpenShift Container Platform クラスターに追加します。BIOS パラメーターの設定 について参照してください。
-
oc
コマンドを使用して、リアルタイム機能を必要とするワーカーノードにラベルworker-rt
を追加します。 リアルタイムノード用の新しいマシン設定プールを作成します。
apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfigPool metadata: name: worker-rt labels: machineconfiguration.openshift.io/role: worker-rt spec: machineConfigSelector: matchExpressions: - { key: machineconfiguration.openshift.io/role, operator: In, values: [worker, worker-rt], } paused: false nodeSelector: matchLabels: node-role.kubernetes.io/worker-rt: ""
マシン設定プール worker-rt は、
worker-rt
というラベルを持つノードのグループに対して作成されることに注意してください。ノードロールラベルを使用して、ノードを適切なマシン設定プールに追加します。
注記リアルタイムワークロードで設定するノードを決定する必要があります。クラスター内のすべてのノード、またはノードのサブセットを設定できます。Performance Addon Operator は、すべてのノードが専用のマシン設定プールの一部であることを想定します。すべてのノードを使用する場合は、Performance Addon Operator がワーカーノードのロールラベルを指すようにする必要があります。サブセットを使用する場合、ノードを新規のマシン設定プールにグループ化する必要があります。
-
ハウスキーピングコアの適切なセットと
realTimeKernel: enabled: true
を設定してPerformanceProfile
を作成します。 PerformanceProfile
でmachineConfigPoolSelector
を設定する必要があります:apiVersion: performance.openshift.io/v2 kind: PerformanceProfile metadata: name: example-performanceprofile spec: ... realTimeKernel: enabled: true nodeSelector: node-role.kubernetes.io/worker-rt: "" machineConfigPoolSelector: machineconfiguration.openshift.io/role: worker-rt
一致するマシン設定プールがラベルを持つことを確認します。
$ oc describe mcp/worker-rt
出力例
Name: worker-rt Namespace: Labels: machineconfiguration.openshift.io/role=worker-rt
- OpenShift Container Platform はノードの設定を開始しますが、これにより複数の再起動が伴う可能性があります。ノードが起動し、安定するのを待機します。特定のハードウェアの場合に、これには長い時間がかかる可能性がありますが、ノードごとに 20 分の時間がかかることが予想されます。
- すべてが予想通りに機能していることを確認します。
16.4.3. リアルタイムカーネルのインストールの確認
以下のコマンドを使用して、リアルタイムカーネルがインストールされていることを確認します。
$ oc get node -o wide
文字列 4.18.0-211.rt5.23.el8.x86_64
が含まれる、ロール worker-rt
を持つワーカーに留意してください。
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME rt-worker-0.example.com Ready worker,worker-rt 5d17h v1.22.1 128.66.135.107 <none> Red Hat Enterprise Linux CoreOS 46.82.202008252340-0 (Ootpa) 4.18.0-211.rt5.23.el8.x86_64 cri-o://1.20.0-90.rhaos4.7.git4a0ac05.el8-rc.1 [...]
16.4.4. リアルタイムで機能するワークロードの作成
リアルタイム機能を使用するワークロードを準備するには、以下の手順を使用します。
手順
-
QoS クラスの
Guaranteed
を指定して Pod を作成します。 - オプション: DPDK の CPU 負荷分散を無効にします。
- 適切なノードセレクターを割り当てます。
アプリケーションを作成する場合には、アプリケーションのチューニングとデプロイメント に記載されている一般的な推奨事項に従ってください。
16.4.5. QoS クラスの Guaranteed
を指定した Pod の作成
QoS クラスの Guaranteed
が指定されている Pod を作成する際には、以下を考慮してください。
- Pod のすべてのコンテナーにはメモリー制限およびメモリー要求があり、それらは同じである必要があります。
- Pod のすべてのコンテナーには CPU の制限と CPU 要求が必要であり、それらは同じである必要があります。
以下の例は、1 つのコンテナーを持つ Pod の設定ファイルを示しています。コンテナーにはメモリー制限とメモリー要求があり、どちらも 200 MiB に相当します。コンテナーには CPU 制限と CPU 要求があり、どちらも 1 CPU に相当します。
apiVersion: v1 kind: Pod metadata: name: qos-demo namespace: qos-example spec: containers: - name: qos-demo-ctr image: <image-pull-spec> resources: limits: memory: "200Mi" cpu: "1" requests: memory: "200Mi" cpu: "1"
Pod を作成します。
$ oc apply -f qos-pod.yaml --namespace=qos-example
Pod についての詳細情報を表示します。
$ oc get pod qos-demo --namespace=qos-example --output=yaml
出力例
spec: containers: ... status: qosClass: Guaranteed
注記コンテナーが独自のメモリー制限を指定するものの、メモリー要求を指定しない場合、OpenShift Container Platform は制限に一致するメモリー要求を自動的に割り当てます。同様に、コンテナーが独自の CPU 制限を指定するものの、CPU 要求を指定しない場合、OpenShift Container Platform は制限に一致する CPU 要求を自動的に割り当てます。
16.4.6. オプション: DPDK 用の CPU 負荷分散の無効化
CPU 負荷分散を無効または有効にする機能は CRI-O レベルで実装されます。CRI-O のコードは、以下の要件を満たす場合にのみ CPU の負荷分散を無効または有効にします。
Pod は
performance-<profile-name>
ランタイムクラスを使用する必要があります。以下に示すように、パフォーマンスプロファイルのステータスを確認して、適切な名前を取得できます。apiVersion: performance.openshift.io/v2 kind: PerformanceProfile ... status: ... runtimeClass: performance-manual
-
Pod には
cpu-load-balancing.crio.io: true
アノテーションが必要です。
Performance Addon Operator は、該当するノードで高パフォーマンスのランタイムハンドラー設定スニペットの作成や、クラスターで高パフォーマンスのランタイムクラスの作成を行います。これには、 CPU 負荷分散の設定機能を有効にすることを除くと、デフォルトのランタイムハンドラーと同じ内容が含まれます。
Pod の CPU 負荷分散を無効にするには、 Pod
仕様に以下のフィールドが含まれる必要があります。
apiVersion: v1 kind: Pod metadata: ... annotations: ... cpu-load-balancing.crio.io: "disable" ... ... spec: ... runtimeClassName: performance-<profile_name> ...
CPU マネージャーの静的ポリシーが有効にされている場合に、CPU 全体を使用する Guaranteed QoS を持つ Pod について CPU 負荷分散を無効にします。これ以外の場合に CPU 負荷分散を無効にすると、クラスター内の他のコンテナーのパフォーマンスに影響する可能性があります。
16.4.7. 適切なノードセレクターの割り当て
Pod をノードに割り当てる方法として、以下に示すようにパフォーマンスプロファイルが使用するものと同じノードセレクターを使用することが推奨されます。
apiVersion: v1 kind: Pod metadata: name: example spec: # ... nodeSelector: node-role.kubernetes.io/worker-rt: ""
ノードセレクターの詳細は、Placing pods on specific nodes using node selectors を参照してください。
16.4.8. リアルタイム機能を備えたワーカーへのワークロードのスケジューリング
Performance Addon Operator によって低レイテンシーを確保するために設定されたマシン設定プールに割り当てられるノードに一致するラベルセレクターを使用します。詳細は、Assigning pods to nodes を参照してください。
16.4.9. Huge Page の設定
ノードは、OpenShift Container Platform クラスターで使用される Huge Page を事前に割り当てる必要があります。Performance Addon Operator を使用し、特定のノードで Huge Page を割り当てます。
OpenShift Container Platform は、Huge Page を作成し、割り当てる方法を提供します。Performance Addon 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-###: ###
16.4.10. 複数の Huge Page サイズの割り当て
同じコンテナーで異なるサイズの Huge Page を要求できます。これにより、Huge Page サイズのニーズの異なる複数のコンテナーで設定されるより複雑な Pod を定義できます。
たとえば、サイズ 1G
と 2M
を定義でき、Performance Addon Operator は以下に示すようにノード上に両方のサイズを設定できます。
spec: hugepages: defaultHugepagesSize: 1G pages: - count: 1024 node: 0 size: 2M - count: 4 node: 1 size: 1G