This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.19.6. vDU アプリケーションのワークロードに推奨される単一ノードの OpenShift クラスター設定
以下の参照情報を使用して、仮想分散ユニット (vDU) アプリケーションをクラスターにデプロイするために必要な単一ノードの OpenShift 設定を理解してください。設定には、高性能ワークロードのためのクラスターの最適化、ワークロードの分割の有効化、およびインストール後に必要な再起動の回数の最小化が含まれます。
19.6.1. OpenShift Container Platform で低レイテンシーのアプリケーションを実行する リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は、いくつかのテクノロジーと特殊なハードウェアデバイスを使用して、市販の (COTS) ハードウェアで実行するアプリケーションの低レイテンシー処理を可能にします。
- RHCOS のリアルタイムカーネル
- ワークロードが高レベルのプロセス決定で処理されるようにします。
- CPU の分離
- CPU スケジューリングの遅延を回避し、CPU 容量が一貫して利用可能な状態にします。
- NUMA 対応のトポロジー管理
- メモリーと Huge Page を CPU および PCI デバイスに合わせて、保証されたコンテナーメモリーと Huge Page を不均一メモリーアクセス (NUMA) ノードに固定します。すべての Quality of Service (QoS) クラスの Pod リソースは、同じ NUMA ノードに留まります。これにより、レイテンシーが短縮され、ノードのパフォーマンスが向上します。
- Huge Page のメモリー管理
- Huge Page サイズを使用すると、ページテーブルへのアクセスに必要なシステムリソースの量を減らすことで、システムパフォーマンスが向上します。
- PTP を使用した精度同期
- サブマイクロ秒の正確性を持つネットワーク内のノード間の同期を可能にします。
19.6.2. vDU アプリケーションワークロードに推奨されるクラスターホスト要件 リンクのコピーリンクがクリップボードにコピーされました!
vDU アプリケーションワークロードを実行するには、OpenShift Container Platform サービスおよび実稼働ワークロードを実行するのに十分なリソースを備えたベアメタルホストが必要です。
プロファイル | vCPU | メモリー | ストレージ |
---|---|---|---|
最低限 | 4 ~ 8 個の vCPU コア | 32GB のメモリー | 120GB |
1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。有効にした場合には、次の式を使用して対応する比率を計算します。
- (コアあたりのスレッド数×コア)×ソケット= vCPU
仮想メディアを使用して起動する場合は、サーバーには Baseboard Management Controller (BMC) が必要です。
19.6.3. 低遅延と高パフォーマンスのためのホストファームウェアの設定 リンクのコピーリンクがクリップボードにコピーされました!
ベアメタルホストでは、ホストをプロビジョニングする前にファームウェアを設定する必要があります。ファームウェアの設定は、特定のハードウェアおよびインストールの特定の要件によって異なります。
手順
-
UEFI/BIOS Boot Mode を
UEFI
に設定します。 - ホスト起動シーケンスの順序で、ハードドライブ を設定します。
ハードウェアに特定のファームウェア設定を適用します。以下の表は、Intel FlexRAN 4G および 5G baseband PHY 参照設計をベースとした Intel Xeon Skylake または Intel Cascade Lake サーバーの典型的なファームウェア設定を説明しています。
重要ファームウェア設定は、実際のハードウェアおよびネットワークの要件によって異なります。以下の設定例は、説明のみを目的としています。
Expand 表19.6 Intel Xeon Skylake または Cascade Lake サーバーのファームウェア設定例 ファームウェア設定 設定 CPU パワーとパフォーマンスポリシー
パフォーマンス
Uncore Frequency Scaling
Disabled
パフォーマンスの制限
Disabled
Intel SpeedStep ® Tech の強化
有効
Intel Configurable TDP
有効
設定可能な TDP レベル
レベル 2
Intel® Turbo Boost Technology
有効
energy Efficient Turbo
Disabled
Hardware P-States
Disabled
Package C-State
C0/C1 の状態
C1E
Disabled
Processor C6
Disabled
ホストのファームウェアでグローバル SR-IOV および VT-d 設定を有効にします。これらの設定は、ベアメタル環境に関連します。
19.6.4. マネージドクラスターネットワークの接続の前提条件 リンクのコピーリンクがクリップボードにコピーされました!
ゼロタッチプロビジョニング (ZTP) GitOps パイプラインを使用してマネージドクラスターをインストールおよびプロビジョニングするには、マネージドクラスターホストが次のネットワーク前提条件を満たしている必要があります。
- ハブクラスター内の ZTP GitOps コンテナーとターゲットベアメタルホストの Baseboard Management Controller (BMC) の間に双方向接続が必要です。
マネージドクラスターは、ハブホスト名と
*.apps
ホスト名の API ホスト名を解決して到達できる必要があります。ハブの API ホスト名と*.apps
ホスト名の例を次に示します。-
api.hub-cluster.internal.domain.com
-
console-openshift-console.apps.hub-cluster.internal.domain.com
-
ハブクラスターは、マネージドクラスターの API および
*.apps
ホスト名を解決して到達できる必要があります。マネージドクラスターの API ホスト名と*.apps
ホスト名の例を次に示します。-
api.sno-managed-cluster-1.internal.domain.com
-
console-openshift-console.apps.sno-managed-cluster-1.internal.domain.com
-
19.6.5. 推奨されるインストール時のクラスター設定 リンクのコピーリンクがクリップボードにコピーされました!
ZTP パイプラインは、クラスターのインストール中に次のカスタムリソース (CR) を適用します。これらの設定 CR により、クラスターが vDU アプリケーションの実行に必要な機能とパフォーマンスの要件を満たしていることが保証されます。
クラスターデプロイメントに ZTP GitOps プラグインと SiteConfig
CR を使用する場合は、デフォルトで次の MachineConfig
CR が含まれます。
デフォルトで含まれる CR を変更するには、SiteConfig
の extraManifests
フィルターを使用します。詳細は、SiteConfig CR を使用した高度なマネージドクラスター設定 を参照してください。
19.6.5.1. ワークロードの分割 リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行する単一ノードの OpenShift クラスターには、ワークロードの分割が必要です。これにより、プラットフォームサービスの実行が許可されるコアが制限され、アプリケーションペイロードの CPU コアが最大化されます。
ワークロードの分割は、クラスターのインストール中にのみ有効にできます。インストール後にワークロードパーティショニングを無効にすることはできません。ただし、パフォーマンスプロファイルおよび関連する MachineConfig
カスタムリソース (CR) で定義した cpu
値を更新することで、ワークロードの分割を再設定できます。
ワークロードの分割を有効にする base64 でエンコードされた CR には、管理ワークロードが制約される CPU セットが含まれています。
crio.conf
およびkubelet.conf
のホスト固有の値を base64 でエンコードします。クラスターパフォーマンスプロファイルで指定されている CPU セットに一致するように内容を調整します。クラスターホストのコア数と一致する必要があります。推奨されるワークロードパーティショニング設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
クラスターホストで設定すると、
/etc/crio/crio.conf.d/01-workload-partitioning
の内容は次のようになります。[crio.runtime.workloads.management] activation_annotation = "target.workload.openshift.io/management" annotation_prefix = "resources.workload.openshift.io" resources = { "cpushares" = 0, "cpuset" = "0-1,52-53" }
[crio.runtime.workloads.management] activation_annotation = "target.workload.openshift.io/management" annotation_prefix = "resources.workload.openshift.io" resources = { "cpushares" = 0, "cpuset" = "0-1,52-53" }
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
CPUs
の値は、インストールによって異なります。
ハイパースレッディングが有効になっている場合は、各コアの両方のスレッドを指定します。
CPUs
の値は、パフォーマンスプロファイルで指定された予約済み CPU セットと一致する必要があります。クラスターで設定すると、
/etc/kubernetes/openshift-workload-pinning
の内容は次のようになります。{ "management": { "cpuset": "0-1,52-53" } }
{ "management": { "cpuset": "0-1,52-53"
1 } }
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cpuset
は、/etc/crio/crio.conf.d/01-workload-partitioning
のCPUs
値と一致する必要があります。
19.6.5.2. プラットフォーム管理フットプリントの削減 リンクのコピーリンクがクリップボードにコピーされました!
プラットフォームの全体的な管理フットプリントを削減するには、ホストオペレーティングシステムとは別の新しい namespace にすべての Kubernetes 固有のマウントポイントを配置する MachineConfig
カスタムリソース (CR) が必要です。次の base64 でエンコードされた MachineConfig
CR の例は、この設定を示しています。
推奨されるコンテナーマウント namespace の設定
19.6.5.3. SCTP リンクのコピーリンクがクリップボードにコピーされました!
Stream Control Transmission Protocol (SCTP) は、RAN アプリケーションで使用される主要なプロトコルです。この MachineConfig
オブジェクトは、SCTP カーネルモジュールをノードに追加して、このプロトコルを有効にします。
推奨される SCTP 設定
19.6.5.4. コンテナーの起動の高速化 リンクのコピーリンクがクリップボードにコピーされました!
次の MachineConfig
CR は、コア OpenShift プロセスとコンテナーを設定して、システムの起動とシャットダウン中に利用可能なすべての CPU コアを使用します。これにより、初回起動および再起動中のシステムリカバリーが加速されます。
推奨される高速化されたコンテナーの起動設定
19.6.5.5. kdump による自動カーネルクラッシュダンプ リンクのコピーリンクがクリップボードにコピーされました!
kdump
は、カーネルがクラッシュしたときにカーネルクラッシュダンプを作成する Linux カーネル機能です。kdump
は、次の MachineConfig
CR で有効になります。
推奨される kdump 設定
19.6.6. 推奨されるインストール後のクラスター設定 リンクのコピーリンクがクリップボードにコピーされました!
クラスターのインストールが完了すると、ZTP パイプラインは、DU ワークロードを実行するために必要な次のカスタムリソース (CR) を適用します。
GitOps ZTP v4.10 以前では、MachineConfig
CR を使用して UEFI セキュアブートを設定します。これは、GitOps ZTP v4.11 以降では不要になりました。v4.11 では、Performance プロファイル CR を使用して、単一ノードの OpenShift クラスターの UEFI セキュアブートを設定します。詳細は、パフォーマンスプロファイル を参照してください。
19.6.6.1. Operator namespace と Operator グループ リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行する単一ノードの OpenShift クラスターには、以下の OperatorGroup
および Namespace
カスタムリソース (CR) が必要です。
- Local Storage Operator
- Logging Operator
- PTP Operator
- SR-IOV Network Operator
次の YAML は、これらの CR をまとめたものです。
推奨される Operator Namespace および OperatorGroup 設定
19.6.6.2. Operator のサブスクリプション リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行する単一ノードの OpenShift クラスターには、次の Subscription
CR が必要です。サブスクリプションは、次の Operator をダウンロードする場所を提供します。
- Local Storage Operator
- Logging Operator
- PTP Operator
- SR-IOV Network Operator
推奨される Operator サブスクリプション
19.6.6.3. クラスターのロギングとログ転送 リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行する単一ノードの OpenShift クラスターでは、デバッグのためにロギングとログ転送が必要です。次の YAML の例は、必要な ClusterLogging
および ClusterLogForwarder
CR を示しています。
推奨されるクラスターログとログ転送の設定
19.6.6.4. パフォーマンスプロファイル リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行する単一ノードの OpenShift クラスターでは、リアルタイムのホスト機能とサービスを使用するために Node Tuning Operator パフォーマンスプロファイルが必要です。
OpenShift Container Platform の以前のバージョンでは、パフォーマンスアドオン Operator を使用して自動チューニングを実装し、OpenShift アプリケーションの低レイテンシーパフォーマンスを実現していました。OpenShift Container Platform 4.11 では、これらの機能は Node Tuning Operator の一部です。
次の PerformanceProfile
CR の例は、必要なクラスター設定を示しています。
推奨されるパフォーマンスプロファイル設定
- 1
name
の値が、TunedPerformancePatch.yaml
のspec.profile.data
フィールドとvalidatorCRs/informDuValidator.yaml
のstatus.configuration.source.name
フィールドで指定された値と一致することを確認します。- 2 3
- クラスターホストの UEFI セキュアブートを設定します。
- 4
- 分離された CPU を設定します。すべてのハイパースレッディングペアが一致していることを確認します。
- 5
- 予約済みの CPU を設定します。ワークロードの分割が有効になっている場合、システムプロセス、カーネルスレッド、およびシステムコンテナースレッドは、これらの CPU に制限されます。分離されていないすべての CPU を予約する必要があります。
- 6
- Huge Page の数を設定します。
- 7
- Huge Page のサイズを設定します。
- 8
- リアルタイム Linux カーネルをインストールするには、
enabled
をtrue
に設定します。
19.6.6.5. PTP リンクのコピーリンクがクリップボードにコピーされました!
単一ノードの OpenShift クラスターは、ネットワーク時間同期に Precision Time Protocol (PTP) を使用します。次の PtpConfig
CR の例は、必要な PTP スレーブ設定を示しています。
推奨される PTP 設定
- 1
- PTP クロック信号を受信するために使用されるインターフェイスを設定します。
19.6.6.6. 拡張調整済みプロファイル リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行する単一ノードの OpenShift クラスターには、高性能ワークロードに必要な追加のパフォーマンスチューニング設定が必要です。次の Tuned
CR の例では、Tuned
プロファイルを拡張しています。
推奨される拡張 Tuned プロファイル設定
19.6.6.7. SR-IOV リンクのコピーリンクがクリップボードにコピーされました!
シングルルート I/O 仮想化 (SR-IOV) は、フロントホールネットワークとミッドホールネットワークを有効にするために一般的に使用されます。次の YAML の例では、単一ノードの OpenShift クラスターの SR-IOV を設定します。
推奨される SR-IOV 設定
19.6.6.8. Console Operator リンクのコピーリンクがクリップボードにコピーされました!
console-operator は、Web コンソールをクラスターにインストールして保守します。ノードが集中管理されている場合、Operator は不要であり、アプリケーションのワークロード用のスペースを確保します。次の Console
カスタムリソース (CR) の例では、コンソールを無効にします。
推奨されるコンソール設定
19.6.6.9. Grafana と Alertmanager リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行する単一ノードの OpenShift クラスターでは、OpenShift Container Platform モニタリングコンポーネントによって消費される CPU リソースを削減する必要があります。次の ConfigMap
カスタムリソース (CR) は、Grafana と Alertmanager を無効にします。
推奨されるクラスター監視設定
19.6.6.10. ネットワーク診断 リンクのコピーリンクがクリップボードにコピーされました!
DU ワークロードを実行する単一ノードの OpenShift クラスターでは、これらの Pod によって作成される追加の負荷を軽減するために、Pod 間のネットワーク接続チェックが少なくて済みます。次のカスタムリソース (CR) は、これらのチェックを無効にします。
推奨されるネットワーク診断設定