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

4.6. 通信事業者 RAN DU リファレンス設計のコンポーネント

以下のセクションでは、RAN DU ワークロードを実行するためにクラスターを設定およびデプロイするのに使用するさまざまな OpenShift Container Platform コンポーネントと設定を説明します。

図4.2 通信事業者 RAN DU リファレンス設計のコンポーネント

通信事業者 RAN DU リファレンス設計のコンポーネントを示す図
注記

通信事業者 RAN DU プロファイルで指定されていない追加コンポーネントが、ワークロードアプリケーションに割り当てられた CPU リソースに影響を与えないことを確認してください。

重要

ツリー外のドライバーはサポートされていません。5G RAN アプリケーションコンポーネントは、RAN DU プロファイルに含まれておらず、アプリケーションに割り当てられたリソース (CPU) に合わせて設計する必要があります。

4.6.1. ホストファームウェアのチューニング

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明

初期クラスターデプロイメント中に最適なパフォーマンスが得られるようにホストファームウェア設定を調整します。詳細は、「vDU アプリケーションのワークロードに推奨されるシングルノード OpenShift クラスター設定」を参照してください。初期デプロイ時にホストファームウェアにチューニング設定を適用します。詳細は、「GitOps ZTP によるホストファームウェア設定の管理」を参照してください。マネージドクラスターホストのファームウェア設定は、ハブクラスターで個別の BareMetalHost カスタムリソース (CR) として使用できます。この CR は、ClusterInstance CR と GitOps ZTP を使用してマネージドクラスターをデプロイするときに作成されます。

注記

ClusterInstance CR は、指定のリファレンス CR example-sno.yaml に基づいて作成してください。

制限と要件
  • ホストファームウェア設定でハイパースレッディングを有効にする必要があります。
エンジニアリングに関する考慮事項
  • パフォーマンスを最大限に高めるために、すべてのファームウェア設定を調整します。
  • 省電力用に調整されていない限り、すべての設定は最大のパフォーマンスが得られるものと予想されます。
  • 必要に応じて、省電力用にパフォーマンスを犠牲にしてホストファームウェアを調整できます。
  • Secure Boot を有効にします。セキュアブートを有効にすると、署名されたカーネルモジュールのみがカーネルによってロードされます。ツリー外のドライバーはサポートされていません。

関連情報

4.6.2. CPU パーティショニングとパフォーマンスチューニング

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
RAN DU 使用モデルには、低レイテンシーのパフォーマンスを実現する PerformanceProfile CR によるクラスターパフォーマンスチューニングが含まれています。PerformanceProfile CR は、Node Tuning Operator によって調整されます。RAN DU ユースケースでは、低レイテンシーのパフォーマンスを実現するためにクラスターをチューニングする必要があります。PerformanceProfile CR を使用したノードのチューニングの詳細は、「パフォーマンスプロファイルによる低レイテンシーを実現するためのノードのチューニング」を参照してください。
制限と要件

Node Tuning Operator は、PerformanceProfile CR を使用してクラスターを設定します。通信事業者 RAN DU プロファイル PerformanceProfile CR で次の設定を指定する必要があります。

  • 次のいずれかの CPU に対して、4 つのハイパースレッド (2 コア) に相当する 4 つ以上の予約済み cpuset を設定します。

    • 最大のパフォーマンスが得られるようにチューニングされたホストファームウェアを備えた Intel 第 3 世代 Xeon (IceLake) 2.20 GHz 以上の CPU

    • AMD EPYC Zen 4 CPU (Genoa、Bergamo、またはそれ以降)

      注記

      AMD EPYC Zen 4 CPU (Genoa、Bergamo、またはそれ以降) は完全にサポートされています。現在、電力消費の評価が進められています。パフォーマンスへの潜在的な影響を判断するために、Pod ごとの電源管理などの機能を評価することを推奨します。

  • 予約済み cpuset を設定し、含まれる各コアの両方のハイパースレッドシブリングを含めます。予約されていないコアは、ワークロードのスケジュールに割り当て可能な CPU として使用できます。
  • ハイパースレッドシブリングが予約済みコアと分離されたコアに分割されていないことを確認します。
  • 予約済みおよび分離された CPU に、CPU 内の全コアの全スレッドが含まれていることを確認します。
  • 予約済み CPU セットに各 NUMA ノードの Core 0 を含めます。
  • huge page のサイズを 1G に設定します。
  • デフォルトで管理ワークロードパーティションの一部として設定されている OpenShift Container Platform Pod のみを予約済みコアにピニングします。
エンジニアリングに関する考慮事項
  • パフォーマンスメトリクスを完全に満たすには、RT カーネルを使用する必要があります。必要に応じて、パフォーマンスに相応の影響が及びますが、非 RT カーネルを使用することもできます。
  • 設定する huge page の数は、アプリケーションのワークロード要件によって異なります。このパラメーターの変動は予想され、許容されます。
  • 選択したハードウェアとシステムで使用されている追加コンポーネントに基づいて、予約済みおよび分離された CPU セットの設定が変更されることが予想されます。この変更が指定の制限を満たしている必要があります。
  • IRQ アフィニティーをサポートしていないハードウェアは、分離された CPU に影響します。CPU 全体が保証される QoS を持つ Pod で、割り当てられた CPU を最大限に活用できるようにするには、サーバー内のすべてのハードウェアが IRQ アフィニティーをサポートしている必要があります。
  • デプロイ時に cpuPartitioningMode を AllNodes に設定してワークロードパーティショニングを有効にする場合、PerformanceProfile CR でオペレーティングシステム、割り込み、および OpenShift Container Platform Pod をサポートするために十分な CPU を割り当てる必要があります。

関連情報

4.6.3. PTP Operator

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
GPS によるグランドマスタークロック (T-GM) のサポート、通常クロック (OC)、境界クロック (T-BC)、デュアル境界クロック、高可用性 (HA)、HTTP 経由のオプションの高速イベント通知などの機能を使用して、RAN DU ユースケースの PTP を PTPConfig CR でクラスターノードに設定します。PTP は、RAN 環境において正確なタイミングと信頼性を確保します。
制限と要件
  • デュアル NIC と HA を備えたノードでは境界クロックが 2 つに制限されます。
  • T-GM の Westport Channel NIC 設定は 2 つに制限されます。
エンジニアリングに関する考慮事項
  • RAN DU RDS の設定は、通常クロック、境界クロック、グランドマスタークロック、および高可用性デュアル NIC 境界クロック用に提供されています。
  • PTP 高速イベント通知は、ConfigMap CR を使用してサブスクライバーの詳細を保持します。
  • O-RAN 仕様で説明されている階層型イベントサブスクリプションは、PTP イベントではサポートされていません。
  • PTP 高速イベント REST API v2 を使用します。PTP 高速イベント REST API v1 は非推奨になりました。REST API v2 は O-RAN Release 3 に準拠しています。

4.6.4. SR-IOV Operator

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
SR-IOV Operator は、SR-IOV CNI およびデバイスプラグインをプロビジョニングおよび設定します。netdevice (カーネル VF) デバイスと vfio (DPDK) デバイスの両方がサポートされており、RAN DU 使用モデルに適用できます。
制限と要件
  • OpenShift Container Platform でサポートされているデバイスを使用します。「サポートされるデバイス」を参照してください。
  • ホストファームウェア設定での SR-IOV および IOMMU の有効化: SR-IOV Network Operator は、カーネルコマンドラインで IOMMU を自動的に有効にします。
  • SR-IOV VF は PF からリンク状態の更新を受信しません。リンクダウン検出が必要な場合は、プロトコルレベルでこれを設定する必要があります。
エンジニアリングに関する考慮事項
  • vfio ドライバータイプの SR-IOV インターフェイスは通常、高スループットまたは低レイテンシーを必要とするアプリケーションで追加のセカンダリーネットワークを有効にするために使用されます。
  • SriovNetwork および SriovNetworkNodePolicy カスタムリソース (CR) の設定と数は、顧客によって異なることが予想されます。
  • IOMMU カーネルのコマンドライン設定は、インストール時に MachineConfig CR で適用されます。これにより、SriovOperator CR がノードを追加するときにノードの再起動が発生しなくなります。
  • 並列でノードをドレインするための SR-IOV サポートは、シングルノードの OpenShift クラスターには適用されません。
  • デプロイメントに SriovOperatorConfig CR を含める必要があります。この CR は自動的に作成されません。この CR は、初期デプロイ時に適用されるリファレンス設定ポリシーに含まれています。
  • ワークロードを特定のノードにピニングまたは制限する場合、SR-IOV 並列ノードドレイン機能によって Pod の再スケジュールが行われません。このような場合、SR-IOV Operator によって並列ノードドレイン機能が無効化されます。
  • セキュアブートまたはカーネルロックダウン中のファームウェア更新をサポートしていない NIC は、アプリケーションワークロードに必要な Virtual Function (VF) の数をサポートするために十分な VF で事前に設定されている必要があります。Mellanox NIC の場合、SR-IOV Network Operator で Mellanox ベンダープラグインを無効にする必要があります。詳細は、「SR-IOV ネットワークデバイスの設定」を参照してください。

  • Pod の起動後に Virtual Function の MTU 値を変更する場合、SriovNetworkNodePolicy CR の MTU フィールドを設定しないでください。代わりに、Network Manager を設定するか、カスタムの systemd スクリプトを使用して、Physical Function の MTU を適切な値に設定します。以下に例を示します。

    Copy to Clipboard Toggle word wrap 
    # ip link set dev <physical_function> mtu 9000

関連情報

4.6.5. ロギング

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
ロギングを使用して、リモート分析のためにファーエッジのノードからログを収集します。推奨されるログコレクターは Vector です。
エンジニアリングに関する考慮事項
  • たとえば、インフラストラクチャー以外のログや、アプリケーションワークロードからの監査ログを処理するには、ロギングレートの増加に応じて CPU とネットワーク帯域幅の追加が必要になります。
  • OpenShift Container Platform 4.14 以降では、Vector がリファレンスログコレクターです。RAN 使用モデルでの fluentd の使用は非推奨です。

関連情報

4.6.6. SRIOV-FEC Operator

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
SRIOV-FEC Operator は、FEC アクセラレーターハードウェアをサポートするオプションのサードパーティー認定 Operator です。
制限と要件

  • FEC Operator v2.7.0 以降:

    • セキュアブートがサポートされています。
    • PF の vfio ドライバーでは、Pod に注入される vfio-token を使用する必要があります。Pod 内のアプリケーションは、EAL パラメーター --vfio-vf-token を使用して VF トークンを DPDK に渡すことができます。
エンジニアリングに関する考慮事項
  • SRIOV-FEC Operator は、分離された CPU セットの CPU コアを使用します。
  • たとえば、検証ポリシーを拡張することによって、アプリケーションデプロイメントの事前チェックの一部として FEC の準備を検証できます。

関連情報

4.6.7. Lifecycle Agent

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
Lifecycle Agent は、シングルノードの OpenShift クラスターにローカルのライフサイクル管理サービスを提供します。
制限と要件
  • Lifecycle Agent は、マルチノードクラスターまたは追加のワーカーを持つシングルノードの OpenShift クラスターには適用されません。
  • Lifecycle Agent には、クラスターのインストール時に作成する永続ボリュームが必要です。パーティション要件の説明については、「GitOps ZTP を使用する場合の ostree stateroot 間の共有コンテナーディレクトリーの設定」を参照してください。

関連情報

4.6.8. Local Storage Operator

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
Local Storage Operator を使用して、アプリケーションで PVC リソースとして使用できる永続ボリュームを作成できます。作成する PV リソースの数とタイプは、要件によって異なります。
エンジニアリングに関する考慮事項
  • PV を作成する前に、PV CR のバッキングストレージを作成します。これは、パーティション、ローカルボリューム、LVM ボリューム、または完全なディスクにすることができます。
  • ディスクとパーティションが正しく割り当てられていることを確認するには、各デバイスへのアクセスに使用されるハードウェアパス別に LocalVolume CR 内のデバイスリストを参照します (例: /dev/disk/by-path/<id>)。論理名 (例: /dev/sda) は、ノードの再起動後も一貫性が保たれるとは限りません。

4.6.9. Logical Volume Manager Storage

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
論理ボリュームマネージャー (LVM) ストレージはオプションのコンポーネントです。アプリケーションが永続ボリューム要求 (PVC) リソースとして使用できる論理ボリュームをローカルデバイスから作成することにより、ブロックストレージとファイルストレージの両方の動的なプロビジョニングを提供します。ボリューム拡張やスナップショットも可能です。設定例は、RDS の StorageLVMCluster.yaml ファイルで提供されています。
制限と要件
  • シングルノードの OpenShift クラスターでは、永続ストレージは LVM ストレージまたはローカルストレージのいずれかによって提供される必要があり、両方によって提供される必要はありません。
  • ボリュームスナップショットはリファレンス設定から除外されます。
エンジニアリングに関する考慮事項
  • LVM Storage は、RAN DU ユースケースのローカルストレージ実装として使用できます。LVM Storage をストレージソリューションとして使用すると、Local Storage Operator が置き換えられ、必要な CPU がプラットフォームのオーバーヘッドとして管理パーティションに割り当てられます。リファレンス設定には、これらのストレージソリューションのいずれか 1 つを含める必要がありますが、両方を含めることはできません。
  • ストレージ要件を満たす十分なディスクまたはパーティションが利用可能であることを確認します。

4.6.10. ワークロードパーティショニング

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
ワークロードパーティショニングは、DU プロファイルに含まれる OpenShift Container Platform Pod と Day 2 Operator Pod を予約済み CPU セットにピニングし、予約済み CPU をノードの計算から除外します。これにより、予約されていないすべての CPU コアがユーザーのワークロードに使用できるようになります。これにより、予約されていないすべての CPU コアがユーザーのワークロードに使用できるようになります。ワークロードパーティショニングは、インストールパラメーターの機能セット cpuPartitioningMode: AllNodes によって有効化されます。管理パーティションコアのセットは、PerformanceProfile CR で設定する予約済み CPU セットを使用して設定されます。
制限と要件
  • Pod を管理パーティションに適用できるようにするには、Namespace と Pod CR にアノテーションを付ける必要がある
  • CPU 制限のある Pod をパーティションに割り当てることはできません。これは、ミューテーションによって Pod の QoS が変わる可能性があるためです。
  • 管理パーティションに割り当てることができる CPU の最小数の詳細は、「Node Tuning Operator」を参照してください。
エンジニアリングに関する考慮事項
  • ワークロードパーティショニングは、すべての管理 Pod を予約済みコアにピニングします。オペレーティングシステム、管理 Pod、およびワークロードの開始、ノードの再起動、またはその他のシステムイベントの発生時に発生する CPU 使用率の予想される急増を考慮して、予約セットに十分な数のコアを割り当てる必要があります。

関連情報

4.6.11. クラスターのチューニング

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
説明
クラスター機能を使用して無効にできるコンポーネントの完全なリストについては、「クラスター機能」を参照してください。
制限と要件
  • インストーラーによるプロビジョニングのインストール方法では、クラスター機能は使用できません。
エンジニアリングに関する考慮事項

  • OpenShift Container Platform 4.16 以降を実行しているクラスターでは、PerformanceProfile が適用されても、クラスターは自動的に cgroup v1 に戻りません。クラスター上で実行されているワークロードに cgroup v1 が必要な場合は、クラスターを cgroup v1 用に設定する必要があります。詳細は、「Linux Control Group バージョン 1 (cgroup v1) の有効化」を参照してください。この設定は、クラスターの初期デプロイ中に行う必要があります。

    注記

    cgroup v1 のサポートは、OpenShift Container Platform 4.19 で削除される予定です。cgroup v1 を実行しているクラスターは cgroup v2 に移行する必要があります。

次の表に、必要なプラットフォームチューニング設定を示します。

表4.2 クラスター機能の設定
機能説明

オプションのクラスター機能を削除する

シングルノードの OpenShift クラスターでのみオプションのクラスター Operator を無効にすることで、OpenShift Container Platform のフットプリントを削減します。

  • Node Tuning Operator、Operator Lifecycle Manager、および Ingress Operator を除くすべてのオプションの Operator を削除します。

クラスター監視を設定する

次の手順を実行して、フットプリントを削減するようにモニタリングスタックを設定します。

  • ローカルの alertmanager コンポーネントおよび telemeter コンポーネントを無効にします。
  • RHACM の可観測性を使用する際、アラートをハブクラスターに転送するには、適切な additionalAlertManagerConfigs CR で CR を拡張する必要があります。

  • Prometheus の保持期間を 24 時間に短縮します。

    注記

    RHACM ハブクラスターは、マネージドクラスターメトリクスを集約します。

ネットワーク診断を無効にする

シングルノード OpenShift のネットワーク診断は必要ないため無効にします。

単一の OperatorHub カタログソースを設定する

RAN DU デプロイメントに必要な Operator のみを含む単一のカタログソースを使用するようにクラスターを設定します。各カタログソースにより、クラスター上の CPU 使用率が増加します。単一の CatalogSource を使用すると、プラットフォームの CPU 予算内に収まります。

Console Operator を無効にする

コンソールが無効になっている状態でクラスターがデプロイされた場合、Console CR (ConsoleOperatorDisable.yaml) は必要ありません。コンソールが有効になっている状態でクラスターがデプロイされた場合、Console CR を適用する必要があります。

関連情報

4.6.12. マシン設定

このリリースの変更点
  • このリリースではリファレンス設計の更新はありません。
制限と要件
CRI-O ワイプ無効化 MachineConfig CR は、定義されたメンテナンス期間内のスケジュールされたメンテナンス時以外は、ディスク上のイメージが静的であると想定します。イメージが静的になるように、Pod の imagePullPolicy フィールドを Always に設定することは避けてください。
表4.3 マシン設定オプション
機能説明

コンテナーランタイム

すべてのノードロールのコンテナーランタイムを crun に設定します。

Kubelet 設定とコンテナーマウント namespace の非表示

kubelet のハウスキーピングとエビクションモニタリングの頻度を減らし、CPU 使用率を削減します。

SCTP

任意の設定 (デフォルトで有効)

Kdump

オプション設定 (デフォルトで有効): カーネルパニックが発生したときに kdump がデバッグ情報をキャプチャーできるようにします。kdump を有効にするリファレンス CR では、リファレンス設定に含まれるドライバーとカーネルモジュールのセットに基づいて、メモリー予約量が増加します。

CRI-O ワイプ無効化

不正なシャットダウン後の CRI-O イメージキャッシュの自動ワイプを無効にします。

SR-IOV 関連のカーネル引数

カーネルコマンドラインに SR-IOV 関連の引数を追加します。

RCU Normal の設定

システムの起動が完了した後に rcu_normal を設定する systemd サービス

ワンショット時間同期

コントロールプレーンまたはワーカーノードに対して 1 回限りの NTP システム時間同期ジョブを実行します。

関連情報

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat, Inc.