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

4.4. RAN DU 使用モデルのエンジニアリングに関する考慮事項

RAN DU 使用モデルは、RAN 分散ユニット (DU) ワークロードをホストする、コモディティーハードウェア上で実行される OpenShift Container Platform クラスターを設定するものです。モデルおよびシステムレベルの考慮事項は、以下で説明します。個々のコンポーネントの具体的な制限、要件、およびエンジニアリングに関する考慮事項は、後のセクションで詳しく説明します。

注記

通信事業者 RAN DU RDS KPI テスト結果の詳細は、telco RAN DU 4.19 reference design specification KPI test results を参照してください。この情報は顧客とパートナーのみが利用できます。

クラスタートポロジー

RAN DU ワークロードに推奨されるトポロジーは、シングルノードの OpenShift です。DU ワークロードは、必要に応じて、3 ノードコンパクトクラスター、高可用性 (3 つのコントロールプレーン + n 個のワーカーノード)、SNO+1 など、他のクラスタートポロジーでも実行できます。SNO+1 トポロジーよりも、複数の SNO クラスター、または可用性の高い 3 ノードコンパクトクラスターが推奨されます。

リモートワーカーノード (RWN) クラスタートポロジーは、このリファレンス設計仕様では推奨されておらず、設計仕様の対象外です。RWN は、RAN DU などのサービスレベルアグリーメント要件が厳しいワークロードにとって次の欠点があるため、検討対象から除外されています。

  • イメージベースのアップグレードと、その機能によって提供される高速アップグレードやロールバック機能などのメリットがサポートされていない。
  • Day 2 Operator への更新がすべての RWN に同時に影響し、ローリング更新を実行することができない。
  • コントロールプレーンの損失 (障害シナリオ) が発生すると、コントロールプレーンによってサービスが提供されるサイトの数が多いため、全体的なサービスの可用性に非常に大きな影響が及ぶ。
  • 監視猶予期間および toleration のタイムアウトを超える期間にわたり、RWN とコントロールプレーン間のネットワーク接続が失われると、Pod のエビクションが発生し、サービス停止につながる可能性がある。
  • コンテナーイメージの事前キャッシュがサポートされていない。
  • ワークロードアフィニティーの複雑さの増大。
ワークロード
  1. DU ワークロードは、通信事業者 RAN DU アプリケーションワークロード で説明されています。
  2. DU ワーカーノードは、最大のパフォーマンスが得られるようにチューニングされたホストファームウェアを備えた Intel 第 3 世代 Xeon (IceLake) 2.20 GHz 以上です。
リソース
システム内で実行中の Pod の最大数 (アプリケーションワークロードと OpenShift Container Platform Pod を含む) は 120 です。
リソース使用量

OpenShift Container Platform のリソース使用量は、以下のアプリケーションワークロードの特性など、さまざまな要因によって異なります。

  • Pod 数
  • プローブの種類と頻度
  • カーネルネットワークを使用したプライマリーまたはセカンダリー CNI のメッセージングレート
  • API アクセスレート
  • ロギングレート
  • ストレージ IOPS

リソース使用量は、次のように設定されたクラスターを対象に測定されます。

  1. クラスターは、シングルノードの OpenShift がインストールされた 1 台のホストです。
  2. クラスターは、「リファレンスアプリケーションワークロードの特性」で説明されている代表的なアプリケーションワークロードを実行します。
  3. クラスターは、「ハブクラスター管理の特性」で詳述されている制約下で管理されます。
  4. 使用モデル設定で "任意" と記載されているコンポーネントは対象外です。
注記

これらの基準を満たさない RAN DU RDS の範囲外の設定では、リソース使用量と KPI 目標の達成能力への影響を判断するために、追加の分析が必要です。これらの要件を満たすには、追加のクラスターリソースを割り当てる必要がある場合があります。

リファレンスアプリケーションワークロードの特性
  1. 管理および制御機能を含む vRAN アプリケーションに 15 個の Pod と 30 個のコンテナーを使用します。
  2. Pod あたり平均 2 つの ConfigMap CR と 4 つの Secret CR を使用します。
  3. 10 秒以上の頻度で最大 10 個の exec プローブを使用します。

  4. kube-apiserver のアプリケーション負荷増分は、クラスタープラットフォーム使用量の 10% 以下です。

    注記

    プラットフォームメトリクスから CPU 負荷を抽出できます。以下に例を示します。 

    $ query=avg_over_time(pod:container_cpu_usage:sum{namespace="openshift-kube-apiserver"}[30m])
    Copy to Clipboard Toggle word wrap
  5. アプリケーションログは、プラットフォームのログコレクターによって収集されません。
  6. プライマリー CNI 上の総トラフィックは 8 Mbps 未満です。
ハブクラスター管理の特性

RHACM は推奨されるクラスター管理ソリューションであり、次の制限に従って設定されています。

  1. 最大 10 個の RHACM 設定ポリシーを使用します。これは、Red Hat が提供する 5 個のポリシーと、準拠評価間隔が 10 分以上の最大 5 個のカスタム設定ポリシーで構成されます。
  2. クラスターポリシーで、最小限の数 (最大 10 個) のマネージドクラスターテンプレートを使用します。ハブ側のテンプレーティングを使用します。
  3. policyController を除いて RHACM アドオンを無効にし、デフォルト設定で可観測性を設定します。

次の表に、リファレンスアプリケーションの負荷時のリソース使用量を示します。

Expand
表4.1 リファレンスアプリケーションの負荷時のリソース使用量
メトリクス制限注記

OpenShift プラットフォームの CPU 使用量

4000 mc 未満 - 2 コア (4HT)

プラットフォームの CPU は、各予約済みコアの両方のハイパースレッドを含む予約済みコアにピニングされます。このシステムは、定期的なシステムタスクとスパイクに対応できるように、安定状態で 3 つの CPU (3000 mc) を使用するように設計されています。

OpenShift プラットフォームのメモリー

16 G 未満

 
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat