3.3. 通信事業者コアリファレンス設計仕様
3.3.1. Telco core 4.18 リファレンス設計の概要 リンクのコピーリンクがクリップボードにコピーされました!
通信事業者向けコア参照デザイン仕様 (RDS) は、通信事業者向けコアワークロードをホストするために、コモディティーハードウェア上で実行する OpenShift Container Platform クラスターを設定します。
3.3.1.1. OpenShift Container Platform 4.15 の Telco Core 向け機能 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform 4.15 に含まれ、Telco Core リファレンスデザイン仕様 (RDS) で活用される次の機能が追加または更新されました。
| 機能 | 説明 |
|---|---|
| IPv6 ネットワークのマルチネットワークポリシーのサポート | IPv6 ネットワーク用のマルチネットワークポリシーを作成できるようになりました。詳細は、IPv6 ネットワークでの multi-network ポリシーのサポート を参照してください。 |
3.3.2. 通信事業者向けコア 4.18 使用モデルの概要 リンクのコピーリンクがクリップボードにコピーされました!
通信事業者コアリファレンス設計仕様 (RDS) は、シグナリングやアグリゲーションなどのコントロールプレーン機能を含む大規模な通信事業者アプリケーションを支えるプラットフォームを表したものです。また、ユーザープレーン機能 (UPF) などの集中型データプレーン機能もいくつか含まれています。これらの機能には通常、スケーラビリティー、複雑なネットワークサポート、耐障害性の高いソフトウェア定義ストレージ、および RAN などの遠端デプロイメントよりも厳格で制約の少ないパフォーマンス要件のサポートが必要です。
通信事業者向けコア使用モデルアーキテクチャー
通信事業者向けコア機能のネットワークの前提条件は多岐にわたり、さまざまなネットワーク属性とパフォーマンスベンチマークが含まれます。IPv6 は必須であり、デュアルスタック設定が普及しています。特定の機能では、最大のスループットとトランザクションレートが要求されるため、DPDK などのユーザープレーンネットワークサポートが必要になります。その他の機能は従来のクラウドネイティブパターンに準拠しており、OVN-K、カーネルネットワーキング、負荷分散などのソリューションを使用できます。
Telco コアクラスターは、標準の 3 つのコントロールプレーンクラスターとして設定され、ワーカーノードは標準の非リアルタイム (RT) カーネルで設定します。さまざまなネットワークとパフォーマンスの要件を持つワークロードをサポートするために、ワーカーノードは MachineConfigPool CR を使用してセグメント化されます。たとえば、これは非ユーザーデータプレーンノードを高スループットノードから分離するために行われます。必要な通信事業者向け運用機能をサポートするために、クラスターには Operator Lifecycle Manager (OLM) Day 2 Operator の標準セットがインストールされています。
3.3.2.1. 共通ベースラインモデル リンクのコピーリンクがクリップボードにコピーされました!
以下の設定と使用モデルの説明は、すべての通信事業者向けコア使用事例に適用できます。
- クラスター
クラスターは次の要件に準拠しています。
- 高可用性 (3 つ以上のスーパーバイザノード) コントロールプレーン
- スケジュールできないスーパーバイザーノード
- ストレージ
- コアユースケースでは、外部の OpenShift Data Foundation によって提供される永続ストレージが必要です。詳細は、「参照コア設計コンポーネント」の「ストレージ」を参照してください。
- ネットワーク
通信事業者向けコアクラスターネットワークは次の要件に準拠します。
- デュアルスタック IPv4/IPv6
- 完全に切断されています。クラスターは、ライフサイクルのどの時点でもパブリックネットワークにアクセスできません。
- 複数のネットワーク: セグメント化されたネットワークにより、OAM、シグナリング、およびストレージトラフィックが分離されます。
- クラスターネットワークタイプ: IPv6 のサポートには OVN-Kubernetes が必要です。
コアクラスターには、基盤となる RHCOS、SR-IOV Operator、ロードバランサー、および次の「ネットワーク」セクションで詳述するその他のコンポーネントによってサポートされる複数のネットワークレイヤーがあります。大まかに言えば、これらのレイヤーには次のものが含まれます。
クラスターネットワーク: クラスターネットワーク設定は、インストール設定を通じて定義および適用されます。設定の更新は、NMState Operator を通じて 2 日目に実行できます。初期設定では次のことを確立できます。
- ホストインターフェイスの設定
- A/A ボンディング (リンクアグリゲーション制御プロトコル (LACP))
セカンダリーまたは追加のネットワーク: OpenShift CNI は、Network
additionalNetworksまたは NetworkAttachmentDefinition CR を通じて設定されます。- MACVLAN
- アプリケーションワークロード: ユーザープレーンネットワークは、Cloud-native Network Functions (CNF) で実行しています。
- Service Mesh
- 通信事業者向け CNF による Service Mesh の使用は非常に一般的です。すべてのコアクラスターに Service Mesh 実装が含まれることが予想されます。Service Mesh の実装と設定は、この仕様の範囲外です。
3.3.2.1.1. エンジニアリングの考慮事項共通使用モデル リンクのコピーリンクがクリップボードにコピーされました!
共通使用モデルには、次のエンジニアリング上の考慮事項が関連します。
- ワーカーノード
- ワーカーノードは、Intel 第 3 世代 Xeon (IceLake) プロセッサー以降で実行します。あるいは、Skylake またはそれ以前のプロセッサーを使用している場合は、Spectre などのシリコンセキュリティー脆弱性の緩和策を無効にする必要があります。無効にしないと、トランザクションパフォーマンスが 40% も大幅に低下する可能性があります。
-
ワーカーノードで IRQ バランシングが有効になっています。
PerformanceProfileは、globallyDisableIrqLoadBalancing: falseを設定します。保証された QoS Pod には、「参照コア設計コンポーネント」セクションの「CPU パーティショニングとパフォーマンスチューニング」サブセクションで説明されているように、分離を保証するためのアノテーションが付けられます。
- 全ノード
- ハイパースレッディングがすべてのノードで有効になっている
-
CPU アーキテクチャーは
x86_64のみ - ノードは標準 (非 RT) カーネルを実行している
- ノードはワークロード分割用に設定されていない
電源管理と最大パフォーマンスの間のノード設定のバランスは、クラスター内の MachineConfigPools によって異なります。この設定は、MachineConfigPool 内のすべてのノードに対して一貫しています。
- CPU パーティション設定
-
CPU パーティショニングは PerformanceProfile を使用して設定され、
MachineConfigPoolごとに適用されます。「参照コア設計コンポーネント」の「CPU パーティショニングとパフォーマンスチューニング」サブセクションを参照してください。
3.3.2.1.2. アプリケーションワークロード リンクのコピーリンクがクリップボードにコピーされました!
コアクラスターで実行しているアプリケーションワークロードには、高性能ネットワーク CNF と従来のベストエフォート型またはバースト可能な Pod ワークロードが混在している場合があります。
保証された QoS スケジューリングは、パフォーマンスまたはセキュリティーの要件により CPU を排他的または専用に使用する必要がある Pod で利用できます。通常、DPDK を使用したユーザープレーンネットワークを利用する、高性能で低レイテンシーに敏感なクラウドネイティブ関数 (CNF) をホストする Pod では、CPU 全体を排他的に使用する必要があります。これは、ノードのチューニングと保証されたサービス品質 (QoS) スケジューリングを通じて実現されます。CPU の排他的使用を必要とする Pod の場合は、ハイパースレッドシステムの潜在的な影響に注意し、コア全体 (2 つのハイパースレッド) を Pod に割り当てる必要がある場合は 2 の倍数の CPU を要求するように設定します。
高スループットと低レイテンシーのネットワークを必要としないネットワーク機能を実行する Pod は、通常、ベストエフォートまたはバースト可能な QoS でスケジュールされ、専用または分離された CPU コアを必要としません。
- 制限の説明
- CNF アプリケーションは、Red Hat Best Practices for Kubernetes ガイドの最新バージョンに準拠する必要があります。
ベストエフォート型とバースト型 QoS Pod の組み合わせ用。
-
保証された QoS Pod が使用される可能性がありますが、
PerformanceProfileで予約済みおよび分離された CPU を正しく設定する必要があります。 - 保証された QoS Pod には、CPU を完全に分離するためのアノテーションを含める必要があります。
- ベストエフォートおよびバースト可能な Pod では、CPU の排他的使用は保証されません。ワークロードは、他のワークロード、オペレーティングシステムデーモン、またはカーネルタスクによってプリエンプトされる可能性があります。
-
保証された QoS Pod が使用される可能性がありますが、
実行可能な代替手段がない限り、exec プローブは回避する必要があります。
- CNF が CPU ピンニングを使用している場合は、exec プローブを使用しないでください。
-
httpGet/tcpSocketなどの他のプローブ実装を使用する必要があります。
注記起動プローブは、定常状態の動作中に最小限のリソースしか必要としません。exec プローブの制限は、主に liveness および readiness プローブに適用されます。
- シグナリング作業負荷
- シグナリングワークロードでは通常、SCTP、REST、gRPC、または同様の TCP プロトコルまたは UDP プロトコルが使用されます。
- MACVLAN または SR-IOV として設定されたセカンダリー CNI (multus) を使用すると、1 秒あたりのトランザクション数 (TPS) は数十万単位になります。
- シグナリングワークロードは、保証された QoS またはバースト可能な QoS のいずれかを備えた Pod で実行されます。
3.3.3. 通信事業者向けコア参照設計コンポーネント リンクのコピーリンクがクリップボードにコピーされました!
以下のセクションでは、通信事業者向けコアワークロードを実行するためにクラスターを設定およびデプロイするために使用するさまざまな OpenShift Container Platform コンポーネントと設定を説明します。
3.3.3.1. CPU パーティショニングとパフォーマンスチューニング リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
-
CPU パーティショニングにより、機密性の高いワークロードを一般的な目的、補助プロセス、割り込み、およびドライバー作業キューから分離して、パフォーマンスとレイテンシーを向上させることができます。これらの補助プロセスに割り当てられた CPU は、次のセクションでは
reservedと呼ばれます。ハイパースレッドシステムでは、CPU は 1 つのハイパースレッドです。 - 制限と要件
オペレーティングシステムでは、カーネルネットワークを含むすべてのサポートタスクを実行するために、一定量の CPU が必要です。
- ユーザープレーンネットワーキングアプリケーション (DPDK) のみを備えたシステムでは、オペレーティングシステムとインフラストラクチャーコンポーネント用に少なくとも 1 つのコア (有効な場合は 2 つのハイパースレッド) が予約されている必要があります。
- ハイパースレッディングが有効になっているシステムでは、常にすべてのコアシブリングスレッドを同じ CPU プールに配置する必要があります。
- 予約済みコアと分離されたコアのセットには、すべての CPU コアが含まれている必要があります。
- 各 NUMA ノードのコア 0 は、予約済み CPU セットに含める必要があります。
分離されたコアは割り込みによって影響を受ける可能性があります。保証された QoS Pod で CPU をフルに使用する必要がある場合は、次のアノテーションを Pod に添付する必要があります。
cpu-load-balancing.crio.io: "disable" cpu-quota.crio.io: "disable" irq-load-balancing.crio.io: "disable"
cpu-load-balancing.crio.io: "disable" cpu-quota.crio.io: "disable" irq-load-balancing.crio.io: "disable"Copy to Clipboard Copied! Toggle word wrap Toggle overflow PerformanceProfile.workloadHints.perPodPowerManagementを使用して Pod ごとの電源管理を有効にすると、保証された QoS Pod で CPU をフルに使用する必要がある場合は、次のアノテーションも Pod に添付する必要があります。cpu-c-states.crio.io: "disable" cpu-freq-governor.crio.io: "performance"
cpu-c-states.crio.io: "disable" cpu-freq-governor.crio.io: "performance"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- エンジニアリングに関する考慮事項
-
必要な最小予約容量 (
systemReserved) は、"Which amount of CPU and memory are recommended to reserve for the system in OpenShift 4 nodes?" のガイダンスに従ってください。 - 実際に必要な予約済み CPU 容量は、クラスターの設定とワークロードの属性によって異なります。
- この予約済み CPU 値は、フルコア (2 ハイパースレッド) の配置に切り上げられる必要があります。
- CPU パーティショニングを変更すると、MCP 内のノードがドレインされ、再起動されます。
- 予約された CPU は OpenShift ノードの割り当て可能な容量から削除されるため、Pod 密度が低下します。
- ワークロードがリアルタイム対応である場合は、リアルタイムワークロードヒントを有効にする必要があります。
- Interrupt Request (IRQ) アフィニティーをサポートしていないハードウェアは、分離された CPU に影響を与えます。CPU QoS が保証された Pod が割り当てられた CPU を最大限に活用できるようにするには、サーバー内のすべてのハードウェアが IRQ アフィニティーをサポートする必要があります。
-
OVS は、ネットワークトラフィックのニーズに合わせて
cpuset設定を動的に管理します。プライマリー CNI で高いネットワークスループットを処理するために追加の CPU を予約する必要はありません。
-
必要な最小予約容量 (
3.3.3.2. Service Mesh リンクのコピーリンクがクリップボードにコピーされました!
- 説明
- 通常、通信事業者向けコア CNF にはサービスメッシュの実装が必要です。必要な特定の機能とパフォーマンスはアプリケーションによって異なります。Service Mesh の実装と設定の選択は、このドキュメントの範囲外です。Pod ネットワーキングに導入される追加のレイテンシーなど、Service Mesh がクラスターリソースの使用率とパフォーマンスに与える影響は、全体的なソリューションエンジニアリングで考慮する必要があります。
3.3.3.3. ネットワーク リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform のネットワーキングは、1 つまたは複数のハイブリッドクラスターのネットワークトラフィックを管理するためにクラスターが必要とする高度なネットワーク関連機能で Kubernetes ネットワーキングを拡張する機能、プラグイン、高度なネットワーク機能のエコシステムです。
3.3.3.3.1. Cluster Network Operator (CNO) リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの新機能
- このリリースではリファレンス設計の更新はありません。
- 説明
CNO は、OpenShift Container Platform クラスターのインストール中に、デフォルトの OVN-Kubernetes ネットワークプラグインを含むクラスターネットワークコンポーネントをデプロイおよび管理します。これにより、プライマリーインターフェイスの MTU 設定、Pod の Egress にノードルーティングテーブルを使用するための OVN ゲートウェイモード、および MACVLAN などの追加のセカンダリーネットワークを設定できます。
ネットワークトラフィックの分離をサポートするために、CNO を通じて複数のネットワークインターフェイスが設定されます。これらのインターフェイスへのトラフィックステアリングは、NMState Operator を使用して適用される静的ルートを通じて設定されます。Pod トラフィックが適切にルーティングされるように、OVN-K は
routingViaHostオプションを有効にして設定されます。この設定では、Pod の Egress トラフィックに OVN ではなくカーネルルーティングテーブルと適用された静的ルートを使用します。Whereabouts CNI プラグインは、DHCP サーバーを使用せずに、追加の Pod ネットワークインターフェイスに動的な IPv4 および IPv6 アドレス指定を提供するために使用されます。
- 制限と要件
- IPv6 サポートには OVN-Kubernetes が必要です。
- 大規模 MTU クラスターをサポートするには、接続されたネットワーク機器を同じ値またはそれ以上の値に設定する必要があります。
- エンジニアリングに関する考慮事項
-
Pod の Egress トラフィックは、
routingViaHostオプションを使用してカーネルルーティングテーブルによって処理されます。ホストに適切な静的ルートを設定する必要があります。
-
Pod の Egress トラフィックは、
3.3.3.3.2. ロードバランサー リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの新機能
- このリリースではリファレンス設計の更新はありません。
- 説明
MetalLB は、標準ルーティングプロトコルを使用するベアメタル Kubernetes クラスターのロードバランサー実装です。これにより、Kubernetes サービスは外部 IP アドレスを取得できるようになり、その IP アドレスはクラスターのホストネットワークにも追加されます。
一部のユースケースでは、ステートフルロードバランシングなど、MetalLB では利用できない機能が必要になる場合があります。必要に応じて、外部のサードパーティーロードバランサーを使用できます。外部ロードバランサーの選択と設定は、この仕様の範囲外です。外部のサードパーティーロードバランサーを使用する場合、統合作業には、すべてのパフォーマンスとリソース使用率の要件が満たされていることを確認するための十分な分析を含める必要があります。
- 制限と要件
- ステートフルロードバランシングは MetalLB ではサポートされていません。これがワークロード CNF の要件である場合は、代替ロードバランサー実装を使用する必要があります。
- ネットワークインフラストラクチャーでは、外部 IP アドレスがクライアントからクラスターのホストネットワークにルーティング可能であることを保証する必要があります。
- エンジニアリングに関する考慮事項
- MetalLB は、コアユースケースモデルの BGP モードでのみ使用されます。
-
コア使用モデルの場合、MetalLB は、ローカルゲートウェイモードで使用される OVN-Kubernetes ネットワークプロバイダーでのみサポートされます。「Cluster Network Operator」セクションの
routingViaHostを参照してください。 - MetalLB での BGP 設定は、ネットワークとピアの要件によって異なります。
- アドレスプールは必要に応じて設定でき、アドレス、集約長、自動割り当て、その他の関連パラメーターを変更できます。
- 双方向転送検出 (BFD) プロファイルのパラメーターの値は、デフォルトに近い値に維持する必要があります。値が短いと、誤検出が発生し、パフォーマンスに影響する可能性があります。
3.3.3.3.3. SR-IOV リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
-
MultiNetworkPolicyリソースを SR-IOV ネットワークに適用して、ネットワーク到達可能性ポリシーを適用できるようになりました。
-
- QinQ が SR-IOV Network Operator でサポートされるようになりました。これはテクニカルプレビュー機能です。
SR-IOV VF は、CNI を調整するときに、'allmulti' フラグを介してすべてのマルチキャストトラフィックを受信できるようになりました。これにより、Pod の Security Context Constraints (SCC) に
NET_ADMIN機能を追加する必要がなくなり、Pod の潜在的な脆弱性を最小限に抑えてセキュリティーが強化されます。- 説明
- SR-IOV を使用すると、物理ネットワークインターフェイス (PF) を複数の Virtual Function (VF) に分割できます。その後、VF を複数の Pod に割り当てることで、Pod を分離したまま、より高いスループットパフォーマンスを実現できます。SR-IOV Network Operator は、SR-IOV CNI、ネットワークデバイスプラグイン、および SR-IOV スタックのその他のコンポーネントをプロビジョニングおよび管理します。
- 制限と要件
- サポートされているネットワークインターフェイスコントローラーは、サポートされているデバイス に記載されています。
- BIOS での SR-IOV および IOMMU の有効化: SR-IOV Network Operator は、カーネルコマンドラインで IOMMU を自動的に有効にします。
- SR-IOV VF は PF からリンク状態の更新を受信しません。リンクダウンの検出が必要な場合は、プロトコルレベルで実行する必要があります。
MultiNetworkPolicyCR は、netdeviceネットワークにのみ適用できます。これは、実装ではvfioインターフェイスを管理できないiptablesツールが使用されるためです。- エンジニアリングに関する考慮事項
-
vfioモードの SR-IOV インターフェイスは通常、高スループットまたは低レイテンシーを必要とするアプリケーション用に追加のセカンダリーネットワークを有効にするために使用されます。
3.3.3.3.4. NMState Operator リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
- NMState Operator は、クラスターのノード全体でネットワーク設定を実行するための Kubernetes API を提供します。これにより、ネットワークインターフェイス設定、静的 IP と DNS、VLAN、トランク、ボンディング、静的ルート、MTU、およびセカンダリーインターフェイスでの無差別モードの有効化が可能になります。クラスターノードは、各ノードのネットワークインターフェイスの状態を API サーバーに定期的に報告します。
- 制限と要件
- 該当なし
- エンジニアリングに関する考慮事項
-
初期ネットワーク設定は、インストール CR の
NMStateConfigコンテンツを使用して適用されます。NMState Operator は、ネットワーク更新に必要な場合にのみ使用されます。 -
SR-IOV Virtual Function がホストネットワークに使用される場合は、
NodeNetworkConfigurationPolicyを使用する NMState Operator を使用して、VLAN や MTU などの VF インターフェイスが設定されます。
-
初期ネットワーク設定は、インストール CR の
3.3.3.4. ロギング リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
- Cluster Logging Operator を使用すると、リモートアーカイブと分析のために、ノードからログを収集して送信できます。参照設定では、Kafka を使用して監査ログとインフラストラクチャーログをリモートアーカイブに送信します。
- 制限と要件
- 該当なし
- エンジニアリングに関する考慮事項
- クラスターの CPU 使用率の影響は、生成されるログの数またはサイズと、設定されたログフィルタリングの量によって決まります。
- 参照設定には、アプリケーションログの送信は含まれません。設定にアプリケーションログを含めるには、アプリケーションのログ記録レートを評価し、予約セットに十分な追加の CPU リソースを割り当てる必要があります。
3.3.3.5. 電源管理 リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
パフォーマンスプロファイル を使用して、クラスターを高電力モード、低電力モード、または混合モードで設定できます。電源モードの選択は、クラスター上で実行しているワークロードの特性、特にレイテンシーに対する敏感さによって異なります。Pod ごとの電源管理 C ステート機能を使用して、低レイテンシー Pod の最大遅延を設定します。
詳細は、ノードの省電力設定 を参照してください。
- 制限と要件
- 電源設定は、C ステートや P ステートの有効化など、適切な BIOS 設定に依存します。設定はハードウェアベンダーによって異なります。
- エンジニアリングに関する考慮事項
-
レイテンシー: レイテンシーの影響を受けやすいワークロードが要件を満たすようにするには、高電力設定または Pod ごとの電源管理設定のいずれかが必要になります。Pod ごとの電源管理は、専用の固定 CPU を備えた
GuaranteedQoS Pod でのみ使用できます。
-
レイテンシー: レイテンシーの影響を受けやすいワークロードが要件を満たすようにするには、高電力設定または Pod ごとの電源管理設定のいずれかが必要になります。Pod ごとの電源管理は、専用の固定 CPU を備えた
3.3.3.6. ストレージ リンクのコピーリンクがクリップボードにコピーされました!
- 概要
クラウドネイティブストレージサービスは、Red Hat またはサードパーティーの OpenShift Data Foundation を含む複数のソリューションによって提供できます。
OpenShift Data Foundation は、コンテナー向けの Ceph ベースのソフトウェア定義ストレージソリューションです。ブロックストレージ、ファイルシステムストレージ、オンプレミスオブジェクトストレージを提供し、永続的および非永続的なデータ要件の両方に合わせて動的にプロビジョニングできます。通信事業者向けコアアプリケーションには永続的なストレージが必要です。
注記すべてのストレージデータが転送中に暗号化されるとは限りません。リスクを軽減するには、ストレージネットワークを他のクラスターネットワークから分離します。ストレージネットワークは、他のクラスターネットワークからアクセス可能またはルーティング可能であってはなりません。ストレージネットワークに直接接続されているノードのみがストレージネットワークにアクセスできるようにする必要があります。
3.3.3.6.1. OpenShift Data Foundation リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの新機能
- このリリースではリファレンス設計の更新はありません。
- 説明
- Red Hat OpenShift Data Foundation は、コンテナー向けのソフトウェア定義ストレージサービスです。通信事業者向けコアクラスターの場合、ストレージサポートは、アプリケーションワークロードクラスターの外部で実行する OpenShift Data Foundation ストレージサービスによって提供されます。OpenShift Data Foundation は、セカンダリー CNI ネットワークを使用したストレージトラフィックの分離をサポートします。
- 制限と要件
- IPv4/IPv6 デュアルスタックネットワーク環境では、OpenShift Data Foundation は IPv4 アドレスを使用します。詳細は、IPv4 を使用した OpenShift Data Foundation による OpenShift デュアルスタックのサポート を参照してください。
- エンジニアリングに関する考慮事項
- OpenShift Data Foundation ネットワークトラフィックは、VLAN 分離などを使用して、専用ネットワーク上の他のトラフィックから分離する必要があります。
3.3.3.6.2. その他のストレージ リンクのコピーリンクがクリップボードにコピーされました!
他のストレージソリューションを使用して、コアクラスターに永続的なストレージを提供することもできます。これらのソリューションの設定と統合は、通信事業者向けコア RDS の範囲外です。ストレージソリューションをコアクラスターに統合する場合は、ストレージが全体的なパフォーマンスとリソース使用率の要件を満たしていることを確認するために、適切なサイズ設定とパフォーマンス分析を行う必要があります。
3.3.3.7. モニタリング リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
Cluster Monitoring Operator (CMO) は、すべての OpenShift クラスターにデフォルトで含まれており、プラットフォームコンポーネントとオプションでユーザープロジェクトのモニタリング (メトリクス、ダッシュボード、アラート) を提供します。
モニタリング Operator の設定では、次のようなカスタマイズが可能です。
- デフォルトの保存期間
- カスタムアラートルール
Pod の CPU とメモリーのメトリクスのデフォルトの処理は、アップストリームの Kubernetes
cAdvisorに基づいており、メトリクスの精度よりも古いデータの処理を優先するトレードオフが行われます。これにより、データが急激に変化し、ユーザーが指定したしきい値を超えると、誤ってアラートがトリガーされることになります。OpenShift は、スパイク動作の影響を受けない Pod CPU およびメモリーメトリクスの追加セットを作成する、オプトインの専用サービスモニター機能をサポートしています。詳細は、このソリューションガイド を参照してください。デフォルト設定に加えて、Telco コアクラスターには次のメトリクスが設定されていることが想定されます。
- ユーザーワークロードの Pod CPU とメモリーのメトリクスとアラート
- 制限と要件
- モニタリング設定では、Pod メトリクスを正確に表現するために専用のサービスモニター機能を有効にする必要があります。
- エンジニアリングに関する考慮事項
- Prometheus の保持期間はユーザーによって指定されます。使用される値は、クラスター上の履歴データを維持するための運用要件と、CPU およびストレージリソースとの間のトレードオフです。保持期間が長くなると、ストレージの必要性が高まり、データのインデックス管理に追加の CPU が必要になります。
3.3.3.8. スケジューリング リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
- スケジューラーは、特定のワークロードに対して適切なノードを選択するロールを担う、クラスター全体のコンポーネントです。これはプラットフォームの中核部分であり、一般的なデプロイメントシナリオでは特別な設定は必要ありません。ただし、次のセクションで説明する具体的な使用例はほとんどありません。NUMA 対応スケジューリングは、NUMA リソース Operator を通じて有効にできます。詳細は、「NUMA 対応ワークロードのスケジューリング」を参照してください。
- 制限と要件
デフォルトのスケジューラーはワークロードの NUMA 局所性を理解しません。ワーカーノード上のすべての空きリソースの合計のみを認識します。これにより、Topology Manager ポリシー が
single-numa-nodeまたはrestrictedに設定されているノードにスケジュールされた場合にワークロードが拒否される可能性があります。- たとえば、6 個の CPU を要求し、NUMA ノードごとに 4 個の CPU を持つ空のノードにスケジュールされている Pod を考えてみましょう。ノードの割り当て可能な合計容量は 8 CPU であり、スケジューラーはそこに Pod を配置します。ただし、各 NUMA ノードで使用できる CPU は 4 つしかないため、ノードのローカルアドミッションは失敗します。
-
複数の NUMA ノードを持つすべてのクラスターでは、NUMA Resources Operator を使用する必要があります。NUMA リソース Operator の
machineConfigPoolSelectorは、NUMA 調整スケジューリングが必要なすべてのノードを選択する必要があります。
- すべてのマシン設定プールは、一貫したハードウェア設定を持つ必要があります。たとえば、すべてのノードは同じ NUMA ゾーン数を持つことが期待されます。
- エンジニアリングに関する考慮事項
- Pod では、正しいスケジュールと分離のためにアノテーションが必要になる場合があります。アノテーションの詳細は、CPU パーティショニングとパフォーマンスチューニング を参照してください。
-
SriovNetworkNodePolicyCR のexcludeTopologyフィールドを使用して、スケジューリング中に SR-IOV Virtual Function NUMA アフィニティーを無視するように設定できます。
3.3.3.9. インストール リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点, 説明
通信事業者向けコアクラスターは、Agent Based Installer (ABI) を使用してインストールできます。この方法により、ユーザーはインストールを管理するための追加のサーバーや仮想マシンを必要とせずに、ベアメタルサーバーに OpenShift Container Platform をインストールできます。ABI インストーラーは、ラップトップなどの任意のシステムで実行して、ISO インストールイメージを生成できます。この ISO は、クラスタースーパーバイザーノードのインストールメディアとして使用されます。進行状況は、スーパーバイザーノードの API インターフェイスにネットワーク接続できる任意のシステムから ABI ツールを使用して監視できます。
- 宣言型 CR からのインストール
- インストールをサポートするために追加のサーバーは必要ありません
- 非接続環境でのインストールをサポート
- 制限と要件
- 切断されたインストールには、必要なすべてのコンテンツがミラーリングされたアクセス可能なレジストリーが必要です。
- エンジニアリングに関する考慮事項
- ネットワーク設定は、NMState Operator を使用した Day-2 設定よりも優先して、インストール中に NMState 設定として適用する必要があります。
3.3.3.10. セキュリティー リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの新機能
- このリリースではリファレンス設計の更新はありません。
- 説明
通信事業者向け Operator はセキュリティーを重視しており、複数の攻撃ベクトルに対してクラスターを強化する必要があります。OpenShift Container Platform 内には、クラスターのセキュリティー保護を担当する単一のコンポーネントや機能はありません。このセクションでは、この仕様でカバーされている使用モデルのセキュリティー指向の機能と設定の詳細を説明します。
- SecurityContextConstraints: すべてのワークロード Pod は、restricted-v2 または制限付き SCC を使用して実行する必要があります。
-
Seccomp: すべての Pod は、
RuntimeDefault(またはより強力な) seccomp プロファイルを使用して実行する必要があります。 - ルートレス DPDK Pod: 多くのユーザープレーンネットワーキング (DPDK) CNF では、Pod をルート権限で実行する必要があります。この機能を使用すると、ルート権限がなくても、準拠した DPDK Pod を実行できます。ルートレス DPDK Pod は、ルートレス Pod 内にタップデバイスを作成し、DPDK アプリケーションからカーネルにトラフィックを挿入します。
- ストレージ: ストレージネットワークは分離されており、他のクラスターネットワークにルーティングできないようにする必要があります。詳細は、「ストレージ」セクションを参照してください。
- 制限と要件
ルートレス DPDK Pod には、次の追加の設定手順が必要です。
-
container_tSELinux コンテキストを使用して TAP プラグインを設定します。 -
ホスト上で
container_use_devicesSELinux ブール値を有効にします。
-
- エンジニアリングに関する考慮事項
-
ルートレス DPDK Pod のサポートの場合、TAP デバイスを作成するには、ホスト上で SELinux ブール値
container_use_devicesを有効にする必要があります。これにより、短期から中期の使用では許容できるセキュリティーリスクが発生します。他の解決策も検討されます。
-
ルートレス DPDK Pod のサポートの場合、TAP デバイスを作成するには、ホスト上で SELinux ブール値
3.3.3.11. スケーラビリティー リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの変更点
- このリリースではリファレンス設計の更新はありません。
- 説明
クラスターは、制限と要件のセクションに記載されているサイズに合わせてスケーリングされます。
ワークロードのスケーリングについては、使用モデルのセクションで説明します。
- 制限と要件
- クラスターは少なくとも 120 ノードまで拡張可能
- エンジニアリングに関する考慮事項
- 該当なし
3.3.3.12. 追加の設定 リンクのコピーリンクがクリップボードにコピーされました!
3.3.3.12.1. 非接続環境 リンクのコピーリンクがクリップボードにコピーされました!
- 説明
通信事業者向けコアクラスターは、インターネットに直接アクセスできないネットワークにインストールされることが想定されています。クラスターのインストール、設定、および Operator に必要なすべてのコンテナーイメージは、切断されたレジストリーで利用できる必要があります。これには、OpenShift Container Platform イメージ、Day 2 Operator Lifecycle Manager (OLM) Operator イメージ、およびアプリケーションワークロードイメージが含まれます。非接続環境を使用すると、次のような複数の利点が得られます。
- セキュリティーのためにクラスターへのアクセスを制限する
- キュレーションされたコンテンツ: レジストリーは、クラスターのキュレーションされ承認された更新に基づいて作成されます。
- 制限と要件
- すべてのカスタム CatalogSources には一意の名前が必要です。デフォルトのカタログ名を再利用しないでください。
- 有効なタイムソースは、クラスターのインストールの一部として設定する必要があります。
- エンジニアリングに関する考慮事項
- 該当なし
3.3.3.12.2. カーネル リンクのコピーリンクがクリップボードにコピーされました!
- このリリースの新機能
- このリリースではリファレンス設計の更新はありません。
- 説明
ユーザーは、
MachineConfigを使用して次のカーネルモジュールをインストールし、CNF に拡張カーネル機能を提供できます。- sctp
- ip_gre
- ip6_tables
- ip6t_REJECT
- ip6table_filter
- ip6table_mangle
- iptable_filter
- iptable_mangle
- iptable_nat
- xt_multiport
- xt_owner
- xt_REDIRECT
- xt_statistic
- xt_TCPMSS
- 制限と要件
- これらのカーネルモジュールを通じて利用可能な機能の使用は、CPU 負荷、システムパフォーマンス、および KPI を維持する能力への影響を判断するためにユーザーが分析する必要があります。
注記ツリー外のドライバーはサポートされていません。
- エンジニアリングに関する考慮事項
- 該当なし
3.3.4. 通信事業者向けコア 4.18 参照設定 CR リンクのコピーリンクがクリップボードにコピーされました!
以下のカスタムリソース (CR) を使用して、通信事業者コアプロファイルを使用して OpenShift Container Platform クラスターを設定およびデプロイします。特に指定がない限り、CR を使用して、すべての特定の使用モデルで使用される共通のベースラインを形成します。
3.3.4.1. リソース調整参照 CR リンクのコピーリンクがクリップボードにコピーされました!
| コンポーネント | 参照 CR | 任意 | このリリースの新機能 |
|---|---|---|---|
| システム予約容量 | はい | いいえ | |
| システム予約容量 | はい | いいえ |
3.3.4.2. ストレージのリファレンス CR リンクのコピーリンクがクリップボードにコピーされました!
| コンポーネント | 参照 CR | 任意 | このリリースの新機能 |
|---|---|---|---|
| 外部 ODF 設定 | いいえ | はい | |
| 外部 ODF 設定 | いいえ | いいえ | |
| 外部 ODF 設定 | いいえ | いいえ | |
| 外部 ODF 設定 | いいえ | いいえ |
3.3.4.3. ネットワークのリファレンス CR リンクのコピーリンクがクリップボードにコピーされました!
| コンポーネント | 参照 CR | 任意 | このリリースの新機能 |
|---|---|---|---|
| Baseline | いいえ | いいえ | |
| ベースライン | はい | はい | |
| ロードバランサー | いいえ | いいえ | |
| ロードバランサー | いいえ | いいえ | |
| ロードバランサー | いいえ | いいえ | |
| ロードバランサー | いいえ | いいえ | |
| ロードバランサー | いいえ | いいえ | |
| ロードバランサー | はい | いいえ | |
| ロードバランサー | はい | いいえ | |
| ロードバランサー | いいえ | いいえ | |
| Multus - ルートレス DPDK Pod 用の CNI をタップ | いいえ | いいえ | |
| NMState Operator | はい | はい | |
| NMState Operator | はい | はい | |
| NMState Operator | はい | はい | |
| NMState Operator | はい | はい | |
| SR-IOV Network Operator | はい | いいえ | |
| SR-IOV Network Operator | いいえ | はい | |
| SR-IOV Network Operator | いいえ | はい | |
| SR-IOV Network Operator | いいえ | いいえ | |
| SR-IOV Network Operator | いいえ | いいえ | |
| SR-IOV Network Operator | いいえ | いいえ |
3.3.4.4. スケジューリングのリファレンス CR リンクのコピーリンクがクリップボードにコピーされました!
| コンポーネント | 参照 CR | 任意 | このリリースの新機能 |
|---|---|---|---|
| NUMA 対応スケジューラー | いいえ | いいえ | |
| NUMA 対応スケジューラー | いいえ | いいえ |
3.3.4.5. その他の参照 CR リンクのコピーリンクがクリップボードにコピーされました!
| コンポーネント | 参照 CR | 任意 | このリリースの新機能 |
|---|---|---|---|
| 追加のカーネルモジュール | はい | いいえ | |
| 追加のカーネルモジュール | はい | いいえ | |
| 追加のカーネルモジュール | はい | いいえ | |
| クラスターロギング | いいえ | いいえ | |
| クラスターロギング | いいえ | いいえ | |
| クラスターロギング | いいえ | いいえ | |
| クラスターロギング | いいえ | いいえ | |
| クラスターロギング | いいえ | はい | |
| 非接続設定 | いいえ | いいえ | |
| 切断設定 | いいえ | いいえ | |
| 非接続設定 | いいえ | いいえ | |
| 監視および可観測性 | はい | いいえ | |
| 電源管理 | いいえ | いいえ |
3.3.4.6. YAML リファレンス リンクのコピーリンクがクリップボードにコピーされました!
3.3.4.6.1. リソースチューニング参照 YAML リンクのコピーリンクがクリップボードにコピーされました!
control-plane-system-reserved.yaml
pid-limits-cr.yaml
3.3.4.6.2. ストレージ参照 YAML リンクのコピーリンクがクリップボードにコピーされました!
01-rook-ceph-external-cluster-details.secret.yaml
02-ocs-external-storagecluster.yaml
odfNS.yaml
odfOperGroup.yaml
3.3.4.6.3. ネットワーク参照 YAML リンクのコピーリンクがクリップボードにコピーされました!
Network.yaml
networkAttachmentDefinition.yaml
addr-pool.yaml
bfd-profile.yaml
bgp-advr.yaml
bgp-peer.yaml
metallb.yaml
metallbNS.yaml
metallbOperGroup.yaml
metallbSubscription.yaml
mc_rootless_pods_selinux.yaml
NMState.yaml
apiVersion: nmstate.io/v1
kind: NMState
metadata:
name: nmstate
spec: {}
apiVersion: nmstate.io/v1
kind: NMState
metadata:
name: nmstate
spec: {}
NMStateNS.yaml
NMStateOperGroup.yaml
NMStateSubscription.yaml
sriovNetwork.yaml
sriovNetworkNodePolicy.yaml
SriovOperatorConfig.yaml
SriovSubscription.yaml
SriovSubscriptionNS.yaml
SriovSubscriptionOperGroup.yaml
3.3.4.6.4. スケジュール参照 YAML リンクのコピーリンクがクリップボードにコピーされました!
nrop.yaml
sched.yaml
3.3.4.6.5. その他の参照 YAML リンクのコピーリンクがクリップボードにコピーされました!
control-plane-load-kernel-modules.yaml
sctp_module_mc.yaml
worker-load-kernel-modules.yaml
ClusterLogForwarder.yaml
ClusterLogging.yaml
ClusterLogNS.yaml
ClusterLogOperGroup.yaml
ClusterLogSubscription.yaml
catalog-source.yaml
icsp.yaml
operator-hub.yaml
monitoring-config-cm.yaml
PerformanceProfile.yaml