5.10. ハブクラスターのストレージ要件
管理ハブクラスターに必要なストレージの合計量は、クラスターにデプロイされる各アプリケーションのストレージ要件によって異なります。高可用性を持つ PersistentVolume リソースを介したストレージを必要とする主なコンポーネントについては、次のセクションで説明します。
基盤となる OpenShift Container Platform インストールに必要なストレージは、以下の要件とは別です。
5.10.1. Assisted Service リンクのコピーリンクがクリップボードにコピーされました!
Assisted Service は、マルチクラスターエンジンと Red Hat Advanced Cluster Management (RHACM) とともにデプロイされます。
| 永続ボリュームリソース | 容量 (GB) |
|---|---|
|
| 50 |
|
| 700 |
|
| 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%) を加算してください。
| 容量計画に使用する入力値 | データソース | 値の例 |
|---|---|---|
| コントロールプレーンノードの数 | ハブクラスター 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 で紹介されているサイズ計算ツールで使用すると、次のストレージ要件が明らかになります。
alertmanager PV | thanos receive PV | thanos compact PV | |||
|---|---|---|---|---|---|
| レプリカ 1 つあたり | 合計 | レプリカ 1 つあたり | 合計 | 合計 | |
| 10 GiB | 30 GiB | 10 GiB | 30 GiB | 100 GiB | |
thanos rule PV | thanos 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 によって使用されます。