サポートコンソール開発者トライアルの開始お問い合わせ

14.3. リアルタイムおよび低レイテンシーワークロードのプロビジョニング

多くの組織、特に金融業界や通信業界では、ハイパフォーマンスコンピューティングと予測可能な低レイテンシーが求められます。

OpenShift Container Platform は、OpenShift Container Platform アプリケーションの低レイテンシーパフォーマンスと一貫した応答時間を実現するための自動チューニングを実装する Node Tuning Operator を提供します。このような変更を行うには、パフォーマンスプロファイル設定を使用します。kernel-rt へのカーネルの更新、Pod インフラコンテナーを含むクラスターおよびオペレーティングシステムのハウスキーピング作業用 CPU の予約、アプリケーションコンテナーがワークロードを実行するための CPU の分離、未使用の CPU の無効化による電力消費削減を行うことができます。

注記

アプリケーションを作成するときは、RHEL for Real Time プロセスおよびスレッド に記載されている一般的な推奨事項に従ってください。

関連情報

14.3.1. リアルタイム機能を備えたワーカーに低レイテンシーのワークロードをスケジュールする

リアルタイム機能を設定するパフォーマンスプロファイルを適用したワーカーノードに、低レイテンシーのワークロードをスケジュールできます。

注記

特定のノードでワークロードをスケジュールするには、Pod カスタムリソース (CR) でラベルセレクターを使用します。ラベルセレクターは、Node Tuning Operator によって低レイテンシー用に設定されたマシン設定プールに割り当てられているノードと一致している必要があります。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • cluster-admin 権限を持つユーザーとしてログインしている。
  • 低レイテンシーのワークロード向けにワーカーノードをチューニングするパフォーマンスプロファイルをクラスターに適用した。

手順

  1. 低レイテンシーのワークロード用の Pod CR を作成し、クラスターに適用します。次に例を示します。

    リアルタイム処理を使用するように設定した Pod 仕様の例

    apiVersion: v1
kind: Pod
metadata:
  name: dynamic-low-latency-pod
  annotations:
    cpu-quota.crio.io: "disable" 1
    cpu-load-balancing.crio.io: "disable" 2
    irq-load-balancing.crio.io: "disable" 3
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: dynamic-low-latency-pod
    image: "registry.redhat.io/openshift4/cnf-tests-rhel8:v4.16"
    command: ["sleep", "10h"]
    resources:
      requests:
        cpu: 2
        memory: "200M"
      limits:
        cpu: 2
        memory: "200M"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  nodeSelector:
    node-role.kubernetes.io/worker-cnf: "" 4
  runtimeClassName: performance-dynamic-low-latency-profile 5
# ...

    1
    Pod の実行時に CPU Completely Fair Scheduler (CFS) のクォータを無効にします。
    2
    CPU 負荷分散を無効にします。
    3
    ノード上の Pod を割り込み処理から除外します。
    4
    nodeSelector ラベルは、Node CR で指定したラベルと一致している必要があります。
    5
    runtimeClassName は、クラスターで設定したパフォーマンスプロファイルの名前と一致している必要があります。
  2. Pod の runtimeClassName を performance-<profile_name> の形式で入力します。<profile_name> は PerformanceProfile YAML の name です。上記の例では、name は performance-dynamic-low-latency-profile です。

  3. Pod が正常に実行されていることを確認します。ステータスが running であり、正しい cnf-worker ノードが設定されている必要があります。 

    $ oc get pod -o wide

    予想される出力

    NAME                     READY   STATUS    RESTARTS   AGE     IP           NODE
dynamic-low-latency-pod  1/1     Running   0          5h33m   10.131.0.10  cnf-worker.example.com

  4. IRQ の動的負荷分散向けに設定された Pod が実行される CPU を取得します。 

    $ oc exec -it dynamic-low-latency-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"

    予想される出力

    Cpus_allowed_list:  2-3

検証

ノードの設定が正しく適用されていることを確認します。

  1. ノードにログインして設定を確認します。 

    $ oc debug node/<node-name>

  2. ノードのファイルシステムを使用できることを確認します。 

    sh-4.4# chroot /host

    予想される出力

    sh-4.4#

  3. デフォルトのシステム CPU アフィニティーマスクに、CPU 2 や 3 などの dynamic-low-latency-pod CPU が含まれていないことを確認します。 

    sh-4.4# cat /proc/irq/default_smp_affinity

    出力例

    33

  4. システムの IRQ が dynamic-low-latency-pod CPU で実行されるように設定されていないことを確認します。 

    sh-4.4# 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

警告

低レイテンシー用にノードをチューニングするときに、保証された CPU を必要とするアプリケーションと組み合わせて実行プローブを使用すると、レイテンシーが急上昇する可能性があります。代わりに、適切に設定されたネットワークプローブのセットなど、他のプローブを使用してください。

関連情報

14.3.2. Guaranteed QoS クラスを持つ 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:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: qos-demo-ctr
    image: <image-pull-spec>
    resources:
      limits:
        memory: "200Mi"
        cpu: "1"
      requests:
        memory: "200Mi"
        cpu: "1"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]

  1. Pod を作成します。 

    $ oc  apply -f qos-pod.yaml --namespace=qos-example

  2. 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 要求が自動的に割り当てられます。

14.3.3. Pod の CPU 負荷分散の無効化

CPU 負荷分散を無効または有効にする機能は CRI-O レベルで実装されます。CRI-O のコードは、以下の要件を満たす場合にのみ CPU の負荷分散を無効または有効にします。

  • Pod は performance-<profile-name> ランタイムクラスを使用する必要があります。以下に示すように、パフォーマンスプロファイルのステータスを確認して、適切な名前を取得できます。 

    apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
...
status:
  ...
  runtimeClass: performance-manual

Node Tuning Operator は、関連ノード下での高性能ランタイムハンドラー config snippet の作成と、クラスター下での高性能ランタイムクラスの作成を担当します。このスニペットには、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 負荷分散を無効にすると、クラスター内の他のコンテナーのパフォーマンスに影響する可能性があります。

14.3.4. 優先度の高い Pod の省電力モードの無効化

ワークロードが実行されるノードの省電力を設定するときに、優先度の高いワークロードが影響を受けないように Pod を設定できます。

省電力設定でノードを設定するときは、優先度の高いワークロードを Pod レベルのパフォーマンス設定で設定する必要があります。つまり、Pod で使用されるすべてのコアにその設定が適用されます。

Pod レベルで P ステートと C ステートを無効にすることで、優先度の高いワークロードを設定して、最高のパフォーマンスと最小の待機時間を実現できます。

表14.5 優先度の高いワークロードの設定
アノテーション設定可能な値説明

cpu-c-states.crio.io:

  • "enable"
  • "disable"
  • "max_latency:microseconds"

このアノテーションを使用すると、各 CPU の C ステートを有効または無効にすることができます。あるいは、C ステートの最大レイテンシーをマイクロ秒単位で指定することもできます。たとえば、cpu-c-states.crio.io: "max_latency:10" を設定して、最大レイテンシー 10 マイクロ秒の C ステートを有効にします。Pod に最高のパフォーマンスを提供するには、値を "disable" に設定します。

cpu-freq-governor.crio.io:

サポートされている cpufreq governor。

各 CPU の cpufreq ガバナーを設定します。"performance" ガバナーは、優先度の高いワークロードに推奨されます。

前提条件

  • 優先度の高いワークロード Pod がスケジュールされているノードのパフォーマンスプロファイルで省電力を設定した。

手順

  1. 優先度の高いワークロード Pod に必要なアノテーションを追加します。このアノテーションは default 設定をオーバーライドします。

    優先度の高いワークロードアノテーションの例

    apiVersion: v1
kind: Pod
metadata:
  #...
  annotations:
    #...
    cpu-c-states.crio.io: "disable"
    cpu-freq-governor.crio.io: "performance"
    #...
  #...
spec:
  #...
  runtimeClassName: performance-<profile_name>
  #...

  2. Pod を再起動してアノテーションを適用します。

関連情報

高優先度のワークロードと低優先度のワークロードを同じ場所で実行するノードの省電力設定

14.3.5. CPU CFS クォータの無効化

ピニングされた Pod の CPU スロットリングを除外するには、cpu-quota.crio.io: "disable" アノテーションを使用して Pod を作成します。このアノテーションは、Pod の実行時に CPU Completely Fair Scheduler (CFS) のクォータを無効にします。

cpu-quota.crio.io を無効にした Pod 仕様の例

apiVersion: v1
kind: Pod
metadata:
  annotations:
      cpu-quota.crio.io: "disable"
spec:
    runtimeClassName: performance-<profile_name>
#...

注記

CPU CFS のクォータは、CPU マネージャーの静的ポリシーが有効になっている場合、および CPU 全体を使用する Guaranteed QoS を持つ Pod の場合にのみ無効にしてください。たとえば、CPU ピニングされたコンテナーを含む Pod などです。これ以外の場合に CPU CFS クォータを無効にすると、クラスター内の他のコンテナーのパフォーマンスに影響を与える可能性があります。

関連情報

14.3.6. ピニングされたコンテナーが実行されている CPU の割り込み処理の無効化

ワークロードの低レイテンシーを実現するために、一部のコンテナーでは、コンテナーのピニング先の CPU がデバイス割り込みを処理しないようにする必要があります。Pod アノテーション irq-load-balancing.crio.io を使用して、ピニングされたコンテナーが実行されている CPU でデバイス割り込みを処理するかどうかを定義します。設定すると、CRI-O により、Pod コンテナーが実行されているデバイスの割り込みが無効にされます。

個々の Pod に属するコンテナーがピニングされている CPU の割り込み処理を無効にするには、パフォーマンスプロファイルで globallyDisableIrqLoadBalancing が false に設定されていることを確認します。次に、Pod 仕様で、irq-load-balancing.crio.io Pod アノテーションを disable に設定します。

次の Pod 仕様には、このアノテーションが含まれています。 

apiVersion: performance.openshift.io/v2
kind: Pod
metadata:
  annotations:
      irq-load-balancing.crio.io: "disable"
spec:
    runtimeClassName: performance-<profile_name>
...

関連情報

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.