5.10. ハブクラスターのストレージ要件


管理ハブクラスターに必要なストレージの合計量は、クラスターにデプロイされる各アプリケーションのストレージ要件によって異なります。高可用性を持つ PersistentVolume リソースを介したストレージを必要とする主なコンポーネントについては、次のセクションで説明します。

注記

基盤となる OpenShift Container Platform インストールに必要なストレージは、以下の要件とは別です。

5.10.1. Assisted Service

Assisted Service は、マルチクラスターエンジンと Red Hat Advanced Cluster Management (RHACM) とともにデプロイされます。

Expand
表5.2 Assisted Service のストレージ要件
永続ボリュームリソース容量 (GB)

imageStorage

50

filesystemStorage

700

dataBaseStorage

20

5.10.2. RHACM の可観測性

クラスターの可観測性は、マルチクラスターエンジンと Red Hat Advanced Cluster Management (RHACM) によって提供されます。

  • 可観測性のストレージには、メトリクスを長期保存するために、いくつかの PV リソースと S3 互換のバケットストレージが必要です。
  • ストレージ要件の計算は複雑であり、マネージドクラスター固有のワークロードと特性によって異なります。PV リソースと S3 バケットの要件は、データ保持、マネージドクラスターの数、マネージドクラスターのワークロードなど、さまざまな要素によって異なります。
  • RHACM 容量計画リポジトリーの可観測性サイズ計算ツールを使用して、可観測性に必要なストレージを見積もってください。計算ツールを使用して可観測性のストレージ要件を見積もる方法は、Red Hat ナレッジベース記事 Calculating storage need for MultiClusterHub Observability on telco environments を参照してください。以下の表では、通信事業者 RAN DU RDS とハブクラスター RDS から得られた値を参考入力値として使用しています。
注記

以下の数字は推定値です。より正確な結果を得るには、値を調整してください。推定値が不正確である可能性を考慮して、結果に設計マージン (例: +20%) を加算してください。

Expand
表5.3 クラスターの要件
容量計画に使用する入力値データソース値の例

コントロールプレーンノードの数

ハブクラスター RDS (スケール) と通信事業者 RAN DU RDS (トポロジー)

3500

追加のワーカーノードの数

ハブクラスター RDS (スケール) と通信事業者 RAN DU RDS (トポロジー)

0

データの保存日数

ハブクラスター RDS

15

クラスターあたりの Pod の総数

通信事業者 RAN DU RDS

120

namespace の数 (OpenShift Container Platform を除く)

通信事業者 RAN DU RDS

4

1 時間あたりのメトリクスサンプル数

デフォルト値

12

レシーバー永続ボリューム (PV) に保持される時間数

デフォルト値

24

これらの入力値を、Red Hat ナレッジベース記事 Calculating storage need for MultiClusterHub Observability on telco environments で紹介されているサイズ計算ツールで使用すると、次のストレージ要件が明らかになります。

Expand
表5.4 ストレージ要件
alertmanager PVthanos receive PVthanos compact PV

レプリカ 1 つあたり

合計

レプリカ 1 つあたり

合計

合計

10 GiB

30 GiB

10 GiB

30 GiB

100 GiB

Expand
表5.5 ストレージ要件
thanos rule PVthanos store PVオブジェクトバケット [1]

レプリカ 1 つあたり

合計

レプリカ 1 つあたり

合計

1 日あたり

合計

30 GiB

90 GiB

100 GiB

300 GiB

15 GiB

101 GiB

[1] オブジェクトバケットは、ダウンサンプリングが無効であると想定されています。そのため、ストレージ要件は raw データのみをもとに計算されます。

5.10.3. ストレージに関する考慮事項

制限と要件
  • OpenShift Container Platform および Red Hat Advanced Cluster Management (RHACM) の最小制限が適用されます。
  • ストレージバックエンドにより高可用性を確保する必要があります。ハブクラスターリファレンス設定では、Red Hat OpenShift Data Foundation を通じてストレージを提供します。
  • オブジェクトバケットストレージは、OpenShift Data Foundation を通じて提供されます。
エンジニアリングに関する考慮事項
  • etcd ストレージには、低レイテンシーで高スループットの SSD または NVMe ディスクを使用してください。
  • 通信事業者ハブクラスターのストレージソリューションは OpenShift Data Foundation です。

    • Local Storage Operator は、ハブクラスター上の他のコンポーネントが必要とするブロック、ファイル、およびオブジェクトストレージを提供するために、OpenShift Data Foundation で使用されるストレージクラスをサポートしています。
  • Local Storage Operator の LocalVolume 設定には、OpenShift Data Foundation を以前使用していたハブクラスターノードの再インストールをサポートするために、forceWipeDevicesAndDestroyAllData: true 設定が含まれています。

5.10.4. Git リポジトリー

通信事業者管理ハブクラスターは、さまざまな通信事業者アプリケーション用の OpenShift クラスターの設定をインストールおよび管理するために、GitOps 主導の手法をサポートしています。この手法を実現するには、クラスター定義と設定アーティファクトの信頼できる情報源として機能する、アクセス可能な Git リポジトリーが必要です。

Red Hat は商用サポート付きの Git サーバーを提供していません。実稼働環境で提供している既存の Git サーバーを利用できます。たとえば、セルフホスト型 Git サーバーの Gitea や Gogs を使用できます。

通常、Git リポジトリーはハブクラスターの外部にある実稼働ネットワークで提供されます。大規模なデプロイメントでは、複数のハブクラスターで同じ Git リポジトリーを使用することで、マネージドクラスターの定義を維持できます。この方法を使用すると、ネットワーク全体の状態を簡単に確認できます。Git リポジトリーは、クラスター定義の信頼できる情報源として、障害発生時にも高可用性を保ち、回復可能である必要があります。

注記

障害復旧とマルチハブを考慮して、Git リポジトリーはハブクラスターとは別に運用してください。

制限と要件
  • マネージドクラスターのインストール、設定、ライフサイクル管理など、ハブクラスターの GitOps ZTP 機能をサポートするには、Git リポジトリーが必要です。
  • Git リポジトリーは管理クラスターからアクセスできる必要があります。
エンジニアリングに関する考慮事項
  • Git リポジトリーは、継続的デプロイメントを実現し、適用する設定の信頼できる唯一の情報源を確保するために、GitOps Operator によって使用されます。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat