1.2. パフォーマンスおよびスケーラビリティー
Red Hat Advanced Cluster Management for Kubernetes は、特定のスケーラビリティーおよびパフォーマンスデータを判断するのにテストされています。テストしたエリアは、主にクラスターのスケーラビリティーと検索パフォーマンスです。この情報は、環境を計画するときに使用できます。
注記: データは、テスト時のラボ環境から取得した結果をもとにしています。
Red Hat Advanced Cluster Management は、ベアメタルマシン上の 3 ノードハブクラスターを使用してテストされます。テスト時には、ソフトウェアコンポーネント制限の特定に十分な量のリソース容量 (CPU、メモリー、ディスク) が存在するようにします。結果は、お使いの環境、ネットワークの速度、および製品への変更により、異なる可能性があります。
1.2.1. マネージドクラスターの最大数
Red Hat Advanced Cluster Management が管理できるクラスターの最大数は、以下のような複数の要因により異なります。
- クラスター内のリソース数。この数はデプロイするポリシーやアプリケーションの数などの要素により異なります。
- スケーリングに使用する Pod 数など、ハブクラスターの設定。
マネージドクラスターは、Red Hat Enterprise Linux ハイパーバイザーでホストされるシングルノードの OpenShift 仮想マシンです。仮想マシンは、テストベッド内の単一のベアメタルマシンごとに高密度のクラスター数を実現するために使用されます。Sushy-emulator は、Redfish API を使用してアクセス可能なベアメタルクラスターを仮想マシンに持たせるために、libvirt とともに使用されます。次の Operator は、Topology Aware Lifecycle Manager、Local Storage Operator、および Red Hat OpenShift GitOps のテストインストールの一部です。次の表は、ラボ環境のスケーリング情報を示しています。
| ノード | 数 | オペレーティングシステム | ハードウェア | CPU コア数 | メモリー | ディスク |
|---|---|---|---|---|---|---|
| ハブクラスターのコントロールプレーン | 3 | OpenShift Container Platform | ベアメタル | 112 | 512 GiB | 446 GB SSD, 2.9 TB NVMe, 2 x 1.8 TB SSD |
| マネージドクラスター | 3500 | シングルノード OpenShift | 仮想マシン | 8 | 18 GiB | 120 GB |
インフラストラクチャーノードの詳細は、インフラストラクチャーノードへの Red Hat Advanced Cluster Management ハブクラスターのインストール を参照してください。インフラストラクチャーマシンセットの作成 も参照してください。
1.2.2. スケーラビリティーの検索
検索コンポーネントのスケーラビリティーは、データストアのパフォーマンスにより異なります。クエリーの実行時間は、検索パフォーマンスを分析する際の重要な変数です。
1.2.2.1. クエリー実行時の考慮事項
クエリーを実行して結果が返されるまでの所要時間に、影響を与える事項が複数あります。環境のプランニングおよび設定時に、以下の項目を考慮してください。
キーワードの検索は効率的ではない。
多数のクラスターを管理している場合に
RedHatと検索すると、検索結果を受け取るのに時間がかかる場合があります。- 最初の検索は、ユーザーロールベースのアクセス制御ルールを収集するのに時間が余計にかかるため、2 番目以降の検索よりも時間がかかる。
要求の完了にかかる時間は、ユーザーのアクセスが許可されている namespace とリソースの数に比例する。
注記: 検索クエリーを保存して他のユーザーと共有する場合に、返される結果は、対象のユーザーのアクセスレベルにより異なります。ロールアクセスの詳細は、OpenShift Container Platform ドキュメントの RBAC の仕様によるパーミッションの定義および適用 を参照してください。
- 要求が全 namespace または全マネージドクラスターにアクセス権限のある非管理者ユーザーからの場合に、最も悪いパフォーマンスが確認された。
1.2.3. 可観測性のスケーリング
可観測性サービスを有効にして使用する場合は、環境のプランニングが必要です。可観測性コンポーネントのインストール先である OpenShift Container Platform プロジェクトで、後ほど消費するリソースを確保します。使用予定の値は、可観測性コンポーネント全体での使用量合計です。
注記: データは、テスト時のラボ環境から取得した結果をもとにしています。結果は、お使いの環境、ネットワークの速度、および製品への変更により、異なる可能性があります。
1.2.3.1. 可観測性環境の例
このサンプル環境では、Amazon Web Service クラウドプラットフォームにハブクラスターとマネージドクラスターが配置されており、以下のトポロジーおよび設定が指定されています。
| ノード | フレーバー | 仮想 CPU | 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 クラスター | 400 |
| 20 クラスター | 800 |
1.2.3.4. RSS およびワーキングセットメモリー
RSS およびワーキングセットメモリーに関する以下の説明を参照してください。
-
メモリー使用量 RSS:
container_memory_rssのメトリックから取得。テスト時の安定性を維持します。 -
メモリー使用量のワーキングセット:
container_memory_working_set_bytesのメトリクスから取得。テストの進捗に合わせて増加します。
24 時間のテストで、以下の結果が得られました。
| サイズ | メモリー使用量 RSS | メモリー使用量のワーキングセット |
|---|---|---|
| 10 クラスター | 9.84 | 4.93 |
| 20 クラスター | 13.10 | 8.76 |
1.2.3.5. thanos-receive コンポーネントの永続ボリューム
重要: メトリックは、保持期間 (4 日) に達するまで thanos-receive に保管されます。他のコンポーネントでは、thanos-receive コンポーネントと同じボリューム数は必要ありません。
ディスクの使用量は、テストが進むに連れて増加します。データは 1 日経過後のディスク使用量であるため、最終的なディスク使用量は 4 倍にします。
以下のディスク使用量を参照してください。
| サイズ | ディスク使用量 (GiB) |
|---|---|
| 10 クラスター | 2 |
| 20 クラスター | 3 |
1.2.3.6. ネットワーク転送
テスト中、ネットワーク転送で安定性を確保します。サイズおよびネットワーク転送の値を確認します。
| サイズ | 受信ネットワーク転送 | 送信ネットワーク転送 |
|---|---|---|
| 10 クラスター | 1 秒あたり 6.55 MB | 1 秒あたり 5.80 MB |
| 20 クラスター | 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 クラスター | 16.2 |
| 20 クラスター | 23.8 |
1.2.4. クラスターのサイジング
Red Hat Advanced Cluster Management for Kubernetes クラスターは一意で、以下のガイドラインは一意のデプロイメントサイズを提供します。推奨事項は、サイズと目的で分類されています。Red Hat 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 に加え、追加のサービスを実行してクラスター機能をサポートします。詳細は、インフラストラクチャーノードへの Red Hat Advanced Cluster Management ハブクラスターのインストール を参照してください。
1.2.4.1.1. 追加サービスの OpenShift Container Platform
クラスター全体で障害の発生する可能性のあるドメインを分離する アベイラビリティーゾーン。
| サービス | ノード数 | アベイラビリティーゾーン | インスタンスサイズ | 仮想 CPU | メモリー | ストレージサイズ | リソース |
|---|---|---|---|---|---|---|---|
| Amazon Web Services 上の OpenShift Container Platform | 3 | 3 | m5.xlarge | 4 | 16 GB | 120 GB | 詳細は、OpenShift Container Platform 製品ドキュメントの Amazon Web Services の情報 を参照してください。 また、マシンタイプ についても確認してください。 |
| OpenShift Container Platform on Google Cloud Platform | 3 | 3 | N1-standard-4 (0.95–6.5 GB) | 4 | 15 GB | 120 GB | クォータの詳細は、Google Cloud Platform の製品ドキュメント を参照してください。 また、マシンタイプ についても確認してください。 |
| OpenShift Container Platform on Microsoft Azure | 3 | 3 | Standard_D4_v3 | 4 | 16 GB | 120 GB | 詳細は、以下の 製品ドキュメント を参照してください。 |
| VMware vSphere 上の OpenShift Container Platform | 3 | 3 | 4 2 ソケットごとのコア) | 16 GB | 120 GB | 詳細は、以下の 製品ドキュメント を参照してください。 | |
| IBM Z システムの OpenShift Container Platform | 3 | 3 | 10 | 16 GB | 100 GB | 詳細は、OpenShift Container Platform ドキュメントの クラスターの IBM Z システムへのインストール を参照してください。 IBM Z システムには、同時マルチスレッド (SMT) を設定する機能があり、各コアで実行できる仮想 CPU の数を拡張します。SMT を設定している場合は、1 つの物理コア (IFL) は 2 つの論理コア (スレッド) を提供します。ハイパーバイザーは、2 つ以上の vCPU を提供できます。 1 vCPU は、同時マルチスレッド (SMT) またはハイパースレッディングが有効にされていない場合に 1 つの物理コアと同等です。これが有効になっていると、数式 (コアごとのスレッド × コア数) × ソケット数 = vCPU を使用して対応する比率を計算します。 SMT の詳細は、Simultaneous multithreading を参照してください。 | |
| IBM Power Systems 上の OpenShift Container Platform | 3 | 3 | 16 | 16 GB | 120 GB | 詳細は、OpenShift Container Platform ドキュメントの クラスターの Power システムへのインストール を参照してください。 IBM Power システムには、同時マルチスレッド (SMT) を設定する機能があり、各コアで実行できる仮想 CPU の数を拡張します。SMT を設定した場合、その SMT レベルでは仮想 CPU 16 個という要件を満たす方法が決まります。以下は、最も一般的な設定です。 SMT-8 (IBM PowerVM を実行しているシステムのデフォルト設定) で実行しているコア 2 つでは、必要とされる 16 個の vCPU を提供します。 SMT-4 で実行しているコア 4 つでは、必要とされる 16 個の vCPU を提供します。 SMT の詳細は、Simultaneous multithreading を参照してください。 | |
| OpenShift Container Platform オンプレミス | 3 | 4 | 16 GB | 120 GB | 詳細は、以下の 製品ドキュメント を参照してください。 Red Hat Advanced Cluster Management for Kubernetes ハブクラスターは、OpenShift Container Platform ベアメタルにインストールし、サポートできます。ハブクラスターは、スケジュール可能な 3 つのコントロールプレーンノードがあり、追加のワーカーが 0 の、コンパクトなベアメタルトポロジーで実行できます。 |
1.2.4.1.2. シングルノードの OpenShift Container Platform クラスターの作成および管理
要件は、シングルノードへのインストール を参照してください。各クラスターは固有であるため、次のガイドラインでは、サイズと目的によって分類されたデプロイメント要件のサンプルのみを提供します。
クラスター全体で障害の発生する可能性のあるドメインを分離する アベイラビリティーゾーン。一般的なクラスターは、3 つ以上のアベイラビリティゾーンでほぼ同等のワーカーノード容量を備えています。高可用性はサポートされていません。
重要: OpenShift Container Platform の場合、クラスターのマスターノードを 3 つのアベイラビリティーゾーンに分散します。
3500 個のシングルノード OpenShift Container Platform クラスターを作成および管理するための要件の例を参照してください。Red Hat Advanced Cluster Management を使用して単一ノード OpenShift (SNO) クラスター (230 以上を同時にプロビジョニング) を作成し、ハブクラスターで SNO クラスターを管理する最小要件を示しています。
| ノード数 | メモリー (クラスターのピーク使用量) | メモリー (シングルノードの最小値から最大値) | CPU クラスター | CPU シングルノード |
|---|---|---|---|---|
| 3 | 289 GB | 64 GB - 110 GB | 90 | 44 |
