1.2. パフォーマンスおよびスケーラビリティー

Red Hat Advanced Cluster Management for Kubernetes は、特定のスケーラビリティーおよびパフォーマンスデータを判断するのにテストされています。テストしたエリアは、主にクラスターのスケーラビリティーと検索パフォーマンスです。

この情報を使用すると、お使いの環境のプランニングに役立ちます。

注記: データは、テスト時のラボ環境から取得した結果をもとにしています。結果は、お使いの環境、ネットワークの速度、および製品への変更により、異なる可能性があります。

1.2.1. マネージドクラスターの最大数

Red Hat Advanced Cluster Management が管理できるクラスターの最大数は、以下のような複数の要因により異なります。

  • クラスター内のリソース数。この数はデプロイするポリシーやアプリケーションの数などの要素により異なります。
  • スケーリングに使用する Pod 数など、ハブクラスターの設定。

以下の表は、今回のテストに使用した Amazon Web Services クラウドプラットフォームのクラスターの設定情報を示しています。

ノードフレーバーvCPURAM (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 クラウドプラットフォームにハブクラスターとマネージドクラスターが配置されており、以下のトポロジーおよび設定が指定されています。

ノードフレーバーvCPURAM (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. 製品環境

注記: 以下の要件は、最小要件ではありません

表1.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. 追加サービスの OpenShift Container Platform

クラスター全体で障害の発生する可能性のあるドメインを分離する アベイラビリティーゾーン

表1.2 追加サービス

Serviceノード数アベイラビリティーゾーンインスタンスサイズvCPUメモリーストレージサイズリソース

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) を設定する機能があり、各コアで実行できる vCPU の数を拡張します。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) を設定する機能があり、各コアで実行できる vCPU の数を拡張します。SMT を設定した場合、その SMT レベルでは vCPU 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 クラスターを管理する最小要件を示しています。

表1.3 マスター (スケジュール可能)

ノード数メモリー (クラスターのピーク使用量)メモリー (シングルノードの最小値から最大値)CPU クラスターCPU シングルノード

3

289 GB

64 GB - 110 GB

90

44