1.2. パフォーマンスおよびスケーラビリティー
Red Hat Advanced Cluster Management for Kubernetes は、特定のスケーラビリティーおよびパフォーマンスデータを判断するのにテストされています。テストしたエリアは、主にクラスターのスケーラビリティーと検索パフォーマンスです。
この情報を使用すると、お使いの環境のプランニングに役立ちます。
注記: データは、テスト時のラボ環境から取得した結果をもとにしています。結果は、お使いの環境、ネットワークの速度、および製品への変更により、異なる可能性があります。
1.2.1. マネージドクラスターの最大数
Red Hat Advanced Cluster Management が管理できるクラスターの最大数は、以下のような複数の要因により異なります。
- クラスター内のリソース数。この数はデプロイするポリシーやアプリケーションの数などの要素により異なります。
- スケーリングに使用する Pod 数など、ハブクラスターの設定。
以下の表は、今回のテストに使用した Amazon Web Services クラウドプラットフォームのクラスターの設定情報を示しています。
| ノード | フレーバー | vCPU | RAM (GiB) | ディスクタイプ | ディスクサイズ (GiB) | 数 | リージョン |
|---|---|---|---|---|---|---|---|
| マスター | m5.2xlarge | 8 | 32 | gp2 | 100 | 3 | us-east-1 |
| ワーカーまたはインフラストラクチャー | m5.2xlarge | 8 | 32 | gp2 | 100 | ノード 3 つまたは 5 つ | us-east-1 |
インフラストラクチャーノードの詳細は、インフラストラクチャーノードへの Red Hat Advanced Cluster Management ハブクラスターのインストール を参照してください。インフラストラクチャーマシンセットの作成 も参照してください。
1.2.2. スケーラビリティーの検索
検索コンポーネントのスケーラビリティーは、データストアのパフォーマンスにより異なります。検索パフォーマンスの分析には、以下の変数が重要です。
- 物理メモリー
- 書き込みスループット (キャッシュのリカバリー時間)
- クエリー実行時間
1.2.2.1. 物理メモリー
検索は、データをインメモリーに保持し、応答時間を早めます。必要なメモリーは、クラスター内の Kubernetes リソース数とその関係に比例します。
| クラスター | Kubernetes リソース | 関係 | 確認済みのサイズ (シミュレーションデータあり) |
|---|---|---|---|
| medium 1 台 | 5000 | 9500 | 50 Mi |
| medium 5 台 | 25,000 | 75,000 | 120 Mi |
| medium 15 台 | 75,000 | 20,0000 | 492 Mi |
| medium 30 台 | 150,000 | 450,000 | 1 Gi |
| medium 50 台 | 250,000 | 750,000 | 2 Gi |
検索コンポーネントに使用するメモリー量を変更する方法については、再ディスグラフメモリーを増やすためのオプション を参照してください。
1.2.2.2. 書き込みスループット (キャッシュのリカバリー時間)
安定状態のクラスターの多くは、少数のリソース更新を生成します。RedisGraph データの消去時には、更新の割合が高くなり、その結果、ほぼ同時にリモートのコレクターが完全な状態を同期します。データストアの消去時に、さまざまな数のマネージドクラスターの復元時間が測定されます。
| クラスター | Kubernetes リソース | 関係 | シミュレーションからの平均リカバリー時間 |
|---|---|---|---|
| medium 1 台 | 5000 | 9500 | 2 秒未満 |
| medium 5 台 | 25,000 | 75,000 | 15 秒未満 |
| medium 15 台 | 75,000 | 200,000 | 2 分 40 秒 |
| medium 30 台 | 150,000 | 450,000 | 5 ~ 8 分 |
注記: ハブへのネットワーク接続の速度が遅いクラスターの場合は、所要時間が伸びる可能性があります。前述の書き込みスループットの情報は、persistence が無効の場合にのみ適用されます。
1.2.2.3. クエリー実行に関する考慮事項
クエリーを実行して結果が返されるまでの所要時間に、影響を与える事項が複数あります。環境のプランニングおよび設定時に、以下の項目を考慮してください。
キーワードの検索は効率的ではない。
多数のクラスターを管理している場合に
RedHatと検索すると、検索結果を受け取るのに時間がかかる場合があります。- 最初の検索は、ユーザーロールベースのアクセス制御ルールを収集するのに時間が余計にかかるため、2 番目以降の検索よりも時間がかかる。
要求の完了にかかる時間は、ユーザーのアクセスが許可されている namespace とリソースの数に比例する。
注記: 検索クエリーを保存して他のユーザーと共有する場合に、返される結果は、対象のユーザーのアクセスレベルにより異なります。ロールアクセスの詳細は、OpenShift Container Platform ドキュメント の RBAC の仕様によるパーミッションの定義および適用 を参照してください。
- 要求が全 namespace または全マネージドクラスターにアクセス権限のある非管理者ユーザーからの場合に、最も悪いパフォーマンスが確認された。
1.2.3. 可観測性のスケーリング
可観測性サービスを有効にして使用する場合は、環境のプランニングが必要です。可観測性コンポーネントのインストール先である OpenShift Container Platform プロジェクトで、後ほど消費するリソースを確保します。使用予定の値は、可観測性コンポーネント全体での使用量合計です。
注記: データは、テスト時のラボ環境から取得した結果をもとにしています。結果は、お使いの環境、ネットワークの速度、および製品への変更により、異なる可能性があります。
1.2.3.1. 可観測性環境の例
このサンプル環境では、Amazon Web Service クラウドプラットフォームにハブクラスターとマネージドクラスターが配置されており、以下のトポロジーおよび設定が指定されています。
| ノード | フレーバー | vCPU | RAM (GiB) | ディスクタイプ | ディスクサイズ (GiB) | 数 | リージョン |
|---|---|---|---|---|---|---|---|
| マスターノード | m5.4xlarge | 16 | 64 | gp2 | 100 | 3 | sa-east-1 |
| ワーカーノード | m5.4xlarge | 16 | 64 | gp2 | 100 | 3 | sa-east-1 |
高可用性環境用に、可観測性のデプロイメントを設定します。高可用性環境の場合は、Kubernetes デプロイメントごとにインスタンスが 2 つ、StatefulSet ごとにインスタンスが 3 つ含まれます。
サンプルテストでは、さまざまな数のマネージドクラスターがメトリクスのプッシュをシミュレーションし、各テストは 24 時間実行されます。以下のスループットを参照してください。
1.2.3.2. 書き込みスループット
| Pod | 間隔 (分) | 時系列 (分) |
|---|---|---|
| 400 | 1 | 83000 |
1.2.3.3. CPU 使用率 (ミリコア)
テスト時の CPU の使用率は安定しています。
| サイズ | CPU の使用率 |
|---|---|
| 10 x クラスター | 400 |
| 20 x クラスター | 800 |
1.2.3.4. RSS およびワーキングセットメモリー
RSS およびワーキングセットメモリーに関する以下の説明を参照してください。
-
メモリー使用量 RSS:
container_memory_rssのメトリクスから取得。テスト時の安定性を維持します。 -
メモリー使用量のワーキングセット:
container_memory_working_set_bytesのメトリクスから取得。テストの進捗に合わせて増加します。
24 時間のテストで、以下の結果が得られました。
| サイズ | メモリー使用量 RSS | メモリー使用量のワーキングセット |
|---|---|---|
| 10 x クラスター | 9.84 | 4.93 |
| 20 x クラスター | 13.10 | 8.76 |
1.2.3.5. thanos-receive コンポーネントの永続ボリューム
重要: メトリクスは、保持期間 (4 日) に達するまで thanos-receive に保管されます。他のコンポーネントでは、thanos-receive コンポーネントと同じボリューム数は必要ありません。
ディスクの使用量は、テストが進むに連れて増加します。データは 1 日経過後のディスク使用量であるため、最終的なディスク使用量は 4 倍にします。
以下のディスク使用量を参照してください。
| サイズ | ディスク使用量 (GiB) |
|---|---|
| 10 x クラスター | 2 |
| 20 x クラスター | 3 |
1.2.3.6. ネットワーク転送
テスト中、ネットワーク転送で安定性を確保します。サイズおよびネットワーク転送の値を確認します。
| サイズ | 受信ネットワーク転送 | 送信ネットワーク転送 |
|---|---|---|
| 10 x クラスター | 1 秒あたり 6.55 MB | 1 秒あたり 5.80 MB |
| 20 x クラスター | 1 秒あたり 13.08 MB | 1 秒あたり 10.9 MB |
1.2.3.7. Amazon Simple Storage Service (S3)
Amazon Simple Storage Service (S3) の合計使用量は増加します。メトリクスデータは、デフォルトの保持期間 (5 日) に達するまで S3 に保存されます。以下のディスク使用量を参照してください。
| サイズ | ディスク使用量 (GiB) |
|---|---|
| 10 x クラスター | 16.2 |
| 20 x クラスター | 23.8 |
1.2.4. ハブクラスターのサイジング
Red Hat Advanced Cluster Management for Kubernetes クラスターは一意で、以下のガイドラインは一意のデプロイメントサイズを提供します。推奨事項は、サイズと目的で分類されています。Red Had Advanced Cluster Management は、サポートサービスのサイジングおよび配置に以下の条件が適用されます。
- クラスター全体で障害の発生する可能性のあるドメインを分離するアベイラビリティーゾーン。通常のクラスターには、3 つ以上のアベイラビリティーゾーンでほぼ同等の容量のワーカーノードが必要です。
- vCPU の予約と制限をもとに、コンテナーに割り当てるワーカーノードの vCPU 容量が確立されます。vCPU は Kubernetes のコンピュートユニットと同じです。詳細は、Kubernetes の Meaning of CPU を参照してください。
- メモリーの予約と制限。コンテナーに割り当てるワーカーノードのメモリー容量を確立します。
- 製品によって管理され、Kubernetes が使用する etcd クラスターに保存される永続データ。
重要: OpenShift Container Platform では、3 つのアベイラビリティーゾーンにクラスターのマスターノードを分散させてください。
1.2.4.1. 製品環境
注記: 以下の要件は、最小要件ではありません。
| ノードのタイプ | アベイラビリティーゾーン | etcd | 総予約メモリー | 予約済み CPU の合計 |
| マスター | 3 | 3 | OpenShift Container Platform のサイジングガイドライン別 | OpenShift Container Platform のサイジングガイドライン別 |
| ワーカーまたはインフラストラクチャー | 3 | 1 | 12 GB | 6 |
OpenShift Container Platform クラスターは、Red Hat Advanced Cluster Management for Kubernetes に加え、追加のサービスを実行してクラスター機能をサポートします。詳細は、インフラストラクチャーノードへの Red Hat Advanced Cluster Management ハブクラスターのインストール を参照してください。
1.2.4.1.1. Amazon Web Services 上の OpenShift Container Platform
詳細は、OpenShift Container Platform 製品ドキュメントの Amazon Web Services の情報 を参照してください。
また、マシンタイプ についても確認してください。
- ノード数: 3
- アベイラビリティーゾーン: 3
インスタンスサイズ: m5.xlarge
- vCPU: 4
- メモリー: 16 GB
- ストレージサイズ: 120 GB
1.2.4.1.2. Google Cloud Platform での OpenShift クラスター
クォータの詳細は、Google Cloud Platform の製品ドキュメント を参照してください。
また、マシンタイプ についても確認してください。
- ノード数: 3
- アベイラビリティーゾーン: 3
インスタンスサイズ: N1-standard-4 (0.95–6.5 GB)
- vCPU: 4
- メモリー: 15 GB
- ストレージサイズ: 120 GB
1.2.4.1.3. Microsoft Azure での OpenShift クラスター
詳細は、以下の 製品ドキュメント を参照してください。
- ノード数: 3
- アベイラビリティーゾーン: 3
インスタンスサイズ: Standard_D4_v3
- vCPU: 4
- メモリー: 16 GB
- ストレージサイズ: 120 GB
1.2.4.1.4. VMware vSphere でのクラスター
詳細は、以下の 製品ドキュメント を参照してください。
- ノード数: 3
- アベイラビリティーゾーン: 3
インスタンスサイズ:
- メモリー: 16 GB
- ストレージサイズ: 120 GB
- vCPUs: 4
- ソケットごとのコア: 2
1.2.4.1.5. IBM Z システムの OpenShift Container Platform
詳細は、OpenShift Container Platform ドキュメントの クラスターの IBM Z システムへのインストール を参照してください。
- ノード数: 3
- アベイラビリティーゾーン: 3
インスタンスサイズ:
- メモリー: 16 GB
- ストレージサイズ: 100 GB
vCPU: 10
IBM Z システムには、同時マルチスレッド (SMT) を設定する機能があり、各コアで実行できる vCPU の数を拡張します。SMT を設定している場合は、1 つの物理コア (IFL) は 2 つの論理コア (スレッド) を提供します。ハイパーバイザーは、2 つ以上の vCPU を提供できます。
1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効になっていると、数式 (コアごとのスレッド × コア数) × ソケット数 = vCPU を使用して対応する比率を計算します。
SMT の詳細は、Simultaneous multithreading を参照してください。
1.2.4.1.6. IBM Power Systems 上の OpenShift Container Platform
詳細は、OpenShift Container Platform ドキュメントの クラスターの Power システムへのインストール を参照してください。
- ノード数: 3
- アベイラビリティーゾーン: 3
インスタンスサイズ:
- メモリー: 16 GB
- ストレージサイズ: 120 GB
vCPU: 16
IBM Power システムには、同時マルチスレッド (SMT) を設定する機能があり、各コアで実行できる vCPU の数を拡張します。SMT を設定した場合、その SMT レベルでは vCPU 16 個という要件を満たす方法が決まります。以下は、最も一般的な設定です。
- SMT-8 (IBM PowerVM を実行しているシステムのデフォルト設定) で実行しているコア 2 つでは、必要とされる 16 個の vCPU を提供します。
SMT-4 で実行しているコア 4 つでは、必要とされる 16 個の vCPU を提供します。
SMT の詳細は、Simultaneous multithreading を参照してください。
1.2.4.1.7. ベアメタルアセット上の OpenShift Container Platform クラスター
詳細は、以下の 製品ドキュメント を参照してください。
Red Hat Advanced Cluster Management for Kubernetes ハブクラスターは、OpenShift Container Platform ベアメタルにインストールし、サポートできます。ハブクラスターは、スケジュール可能な 3 つのコントロールプレーンノードがあり、追加のワーカーが 0 の、コンパクトなベアメタルトポロジーで実行できます。
- ノード数: 3
- アベイラビリティーゾーン: 3
インスタンスサイズ:
- メモリー: 16 GB
- ストレージサイズ: 120 GB
- vCPUs: 4
1.2.4.1.8. 単一ノードの OpenShift Container Platform クラスターの作成および管理
2200 の単一ノードの OpenShift Container Platform クラスターの作成および管理の要件例を参照してください。Red Hat Advanced Cluster Management を使用して単一ノード OpenShift (SNO) クラスター (230 以上を同時にプロビジョニング) を作成し、ハブクラスターで SNO クラスターを管理する最小要件を示しています。
マスター (スケジュール可能)
- ノード数: 3
- メモリー: 289 GB (クラスターの最大値)
- メモリー: 110 GB (単一ノードの最大値)
- CPU クラスターの最大値: 90
- CPU 単一ノードの最大値: 44
注記: 複数のクラスターが同時に作成された間、CPU 使用率の値はピーク化されます。
