3.7. 通信事業者コアクラスターの共通使用モデルのエンジニアリングに関する考慮事項


  • クラスターのワークロードの詳細は、「アプリケーションワークロード」を参照してください。
  • ワーカーノードは、次のいずれかの CPU で実行する必要があります。

    • OpenShift Container Platform でサポートされている場合は、Intel 第 3 世代 Xeon (IceLake) CPU 以上、またはシリコンセキュリティーバグ (Spectre など) の軽減策が無効になっている CPU。Skylake およびそれ以前の CPU では、Spectre や同様の軽減策を有効にすると、トランザクションパフォーマンスが 40% 低下する可能性があります。Skylake およびそれ以前の CPU が電源状態を変更すると、レイテンシーが発生する可能性があります。
    • AMD EPYC Zen 4 CPU (Genoa、Bergamo)。
    • ワーカーノードで IRQ バランシングを有効にします。PerformanceProfile CR は globallyDisableIrqLoadBalancing パラメーターの値を false に設定します。Guaranteed QoS Pod には、「CPU のパーティショニングとパフォーマンスチューニング」の説明のとおり、分離を実現するためのアノテーションが付けられます。
  • すべてのクラスターノードが次の条件を満たしている必要があります。

    • ハイパースレッディングが有効である
    • x86_64 CPU アーキテクチャーを備えている
    • 標準の (非リアルタイム) カーネルが有効である
    • ワークロードパーティショニング用に設定されていない
  • クラスター内のマシン設定プールによって、電源管理と最大パフォーマンスのバランスが異なります。マシン設定プールグループ内のすべてのノードで、次の設定が一貫している必要があります。

    • クラスターのスケーリング。詳細は、「スケーラビリティー」を参照してください。
    • 少なくとも 120 ノードまでクラスターをスケーリングできる必要があります。
  • CPU パーティショニングは PerformanceProfile CR を使用して設定され、MachineConfigPool ごとにノードに適用されます。「CPU パーティショニングとパフォーマンスチューニング」で関連する考慮事項を参照してください。
  • 設定された機能セットとアプリケーションのワークロード特性によって、OpenShift Container Platform の CPU 要件が異なります。リファレンス設定に基づいて設定されたクラスターの場合、次の CPU 要件が検証済みです。リファレンス設定では、kube-burner ノード密度テストによって作成される 3000 個の Pod からなるシミュレートされたワークロードを実行します。

    • コントロールプレーンとワーカーノードの予約済み CPU の最小数は、NUMA ノードあたり 2 CPU (4 ハイパースレッド) です。
    • DPDK 以外のネットワークトラフィックに使用する NIC は、最大 32 個の RX/TX キューを使用するように設定する必要があります。
    • 多数の Pod やその他のリソースを持つノードでは、追加の予約済み CPU が必要になる場合があります。残りの CPU はユーザーのワークロードに使用できます。
    注記

    OpenShift Container Platform の設定、ワークロードのサイズ、およびワークロードの特性の変動により、OpenShift プラットフォームに必要な CPU 数にどのような影響があるかを判断するには、追加の分析が必要です。

3.7.1. アプリケーションワークロード

通信事業者コアクラスターで実行されるアプリケーションワークロードには、高パフォーマンスのクラウドネイティブネットワーク機能 (CNF) と従来の Best-effort または Burstable Pod ワークロードが混在している場合があります。

パフォーマンスまたはセキュリティーの要件により CPU を排他的または専用に使用する必要がある Pod では、Guaranteed QoS スケジューリングを利用できます。通常、ユーザープレーンネットワーク (DPDK など) を使用して高パフォーマンス CNF またはレイテンシーの影響を受けやすい CNF を実行する Pod では、ノードのチューニングと Guaranteed QoS スケジューリングによって実現される専用の CPU 全体を排他的に使用する必要があります。専用の CPU を必要とする Pod 設定を作成する場合は、ハイパースレッドシステムの潜在的な影響に注意してください。コア全体 (2 つのハイパースレッド) を Pod に割り当てる必要がある場合、Pod は 2 の倍数の CPU 数を要求する必要があります。

高スループットまたは低レイテンシーのネットワークを必要としないネットワーク機能を実行する Pod は、Best-effort または Burstable QoS Pod を使用してスケジュールする必要があります。専用または分離された CPU コアは必要ありません。

エンジニアリングに関する考慮事項

次の情報を使用して、通信事業者コアワークロードとクラスターリソースを計画してください。

  • OpenShift Container Platform 4.19 以降、cgroup v1 がサポートされなくなり、削除されました。すべてのワークロードは cgroup v2 と互換性がある必要があります。詳細は、Red Hat Enterprise Linux 9 changes in the context of Red Hat OpenShift workloads を参照してください。
  • CNF アプリケーションを、最新バージョンの Red Hat Best Practices for Kubernetes に準拠させる必要があります。
  • アプリケーションの要求に応じて、Best-effort および Burstable QoS Pod を組み合わせて使用します。

    • ノードを設定する PerformanceProfile CR で予約済みまたは分離された CPU を適切に設定して、Guaranteed QoS Pod を使用します。
    • Guaranteed QoS Pod には、CPU を完全に分離するためのアノテーションを含める必要があります。
    • Best-effort および Burstable Pod では、CPU の排他的使用が保証されません。ワークロードが、他のワークロード、オペレーティングシステムデーモン、またはカーネルタスクによるプリエンプションの対象になる可能性があります。
  • exec プローブは、他に適切な選択肢がない場合にのみ、慎重に使用してください。

    • CNF が CPU ピニングを使用する場合は、exec プローブを使用しないでください。httpGettcpSocket などの他のプローブ実装を使用します。
    • exec プローブを使用する必要がある場合は、exec プローブの頻度と量を制限します。exec プローブの最大数は 10 未満に維持し、頻度は 10 秒以上にする必要があります。
    • startup プローブは、安定状態の動作時には大量のリソースを使用しないため、使用できます。exec プローブの制限は、主に liveness および readiness プローブに適用されます。exec プローブはプロセスのフォークを必要とするため、他のプローブタイプと比較して管理コアの CPU 使用率が大幅に高くなります。

3.7.2. シグナリングワークロード

シグナリングワークロードでは通常、SCTP、REST、gRPC、または同様の TCP または UDP プロトコルが使用されます。シグナリングワークロードは、MACVLAN または SR-IOV インターフェイスとして設定されたセカンダリー Multus CNI を使用して、数十万のトランザクション毎秒 (TPS) に対応します。このワークロードは、Guaranteed または Burstable のいずれかの QoS を持つ Pod で実行できます。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat