3.2. Red Hat OpenShift
通常、サブスクリプションサービスでは、Red Hat OpenShift の使用状況を物理システムおよび仮想システム上のクラスターサイズとして追跡します。クラスターサイズ は、サブスクライブしたすべてのノードの合計となります。サブスクライブされたノード は、ワークロードを実行するコンピュートノードまたはワーカーノードであり、クラスターを管理するコントロールプレーンまたはインフラストラクチャーノードとは異なります。
ただし、この一般的なルール以外に、追跡はいくつかの要因に依存しています。
- Red Hat OpenShift 製品
- 対象製品に対して購入されたサブスクリプションの種類
- 対象製品のバージョン
- サブスクリプションで定義された製品の測定単位に従って、製品のクラスターサイズや全体の使用量を計算し、その結果として示される測定単位
- ノードの構造 (ノードのロールの割り当てに使用されるラベルや、ノード上の Pod の配置を制御するためのスケジューリングの設定など)
3.2.1. Red Hat OpenShift トラッキングに対するさまざまな要因の影響
サブスクリプションサービスは、物理環境と仮想化環境の両方で、完全に管理された Red Hat OpenShift 製品とセルフマネージド Red Hat OpenShift 製品の使用状況を追跡し、レポートします。Red Hat OpenShift メジャーバージョン 3 と 4 の間でレポートモデルが変更されたため、バージョン 3 の使用状況データはノードレベルでレポートされ、バージョン 4 の使用状況データはクラスターレベルでレポートおよび集計されます。次の情報は、データがクラスターレベルで集約されたバージョン 4 のレポートモデルに適しています。
Red Hat OpenShift の使用状況をカウントする操作の多くは、モニタリングスタックツールと OpenShift Cluster Manager で行われます。これらのツールは、必要に応じてコア数または vCPU 数のデータをサブスクリプションサービスに送信し、使用状況レポートを作成します。コアと vCPU のデータは、ワークロードを処理しているクラスターノードから取得されるサブスクライブされたクラスターサイズに基づいています。
Red Hat OpenShift Dedicated や Red Hat OpenShift AI などの完全に管理された Red Hat OpenShift 製品の場合、使用量のカウントは通常、コア時間や vCPU 時間などの単位で測定され、時間ベースで行われます。モニタリングスタックツールや OpenShift Cluster Manager など、Red Hat が管理する環境のインフラストラクチャーは、Red Hat にとってより一貫して利用可能になります。サブスクライブされたノード (ワークロードを受け入れることができるノード) のデータは、サブスクリプションサービスの使用状況データに寄与するコア、vCPU、その他のファクトに関するデータと同様に、簡単に検出できます。
Red Hat OpenShift Container Platform Annual や Red Hat OpenShift Container Platform On-Demand などのセルフマネージド Red Hat OpenShift 製品の場合、使用量のカウントは通常コア数に基づいて行われます。お客様が設計した環境のインフラストラクチャーは予測しにくく、特に仮想化された x86 ベースの環境では、使用量の計算に関連するファクトにアクセスしにくい場合があります。
ファクトによってはアクセスしにくい可能性があるため、使用状況のカウントプロセスには、x86 アーキテクチャー用の仮想化された Red Hat OpenShift クラスターの使用状況データを分析およびレポートするときに適用される同時マルチスレッド (ハイパースレッディングとも呼ばれる) に関する前提を考慮しています。一部のベンダーは同時マルチスレッドに関するデータをゲストに公開しないハイパーバイザーを提供しているため、これらの前提が必要になります。
継続的な分析とお客様からのフィードバックにより、サブスクリプションサービスと関連データパイプラインの両方が段階的に改善され、ハイパースレッディングの使用例における使用状況のカウント精度が向上しました。サブスクリプションサービスのレポートで現在使用されている基本的な前提は、同時マルチスレッドがコアあたり 2 スレッドの係数で発生するというものです。社内調査により、この要素は最も一般的な設定であり、大多数のお客様に適用可能であることが分かりました。したがって、コアあたり 2 つのスレッドを想定した場合、一般的なマルチスレッドのベストプラクティスに従い、マルチスレッドを使用していない少数のお客様 (約 10%) に有利になっていますが、これは誤りです。確認されたスレッド数からコア数を導き出す場合、すべてのお客様にとって最も公平な決定となります。
数に限りはありますが、セルフマネージド Red Hat OpenShift サービスがソケットベースのサブスクリプションとして利用できます。ソケットベースのサブスクリプションの場合、ハイパーバイザーはソケットの数をオペレーティングシステム (通常は Red Hat Enterprise Linux CoreOS) に報告し、使用状況を追跡するためにそのソケット数がサブスクリプションサービスに送信されます。サブスクリプションサービスは、RHEL で使用されるソケットペア方式を使用して、ソケットベースのサブスクリプションを追跡および報告します。
3.2.2. セルフマネージド Red Hat OpenShift 製品のコアベースの使用量カウントワークフロー
Red Hat OpenShift Container Platform Annual や Red Hat OpenShift Container Platform On-Demand などのセルフマネージド Red Hat OpenShift 製品の場合、モニタリングスタックツールと OpenShift Cluster Manager によって開始されるカウントプロセスは次のように機能します。
- クラスターの場合、ノードタイプとノードラベルがチェックされ、どのノードがサブスクリプションのあるノードであるかが判別されます。サブスクリプションのあるノード は、ワークロードを受け入れることができるノードです。サブスクリプションのあるノードのみが、サブスクリプションサービスの使用状況にカウントされます。
ノードのチップアーキテクチャーは、アーキテクチャーが x86 ベースであるかどうかを判別するためにチェックされます。アーキテクチャーが x86 ベースの場合、使用状況のカウント中に同時マルチスレッド (ハイパースレッディングとも呼ばれます) を考慮する必要があります。
- チップアーキテクチャーが x86 ベースでない場合、モニタリングスタックが、サブスクリプションのあるノードに紐づけられたコアをもとに使用状況をカウントし、そのコア数をサブスクリプションサービスに送信します。
- チップアーキテクチャーが x86 ベースの場合、モニタリングスタックは、サブスクリプションのあるノード上のスレッド数をもとに、使用量をカウントします。Red Hat の vCPU の定義によれば、スレッドは vCPU に相当します。マルチスレッドデータを正確に検出できる場合、マルチスレッドデータがあいまいまたは欠落している場合、またはマルチスレッドデータがノード上で明示的に false の値に設定されている場合にも、このカウントの方法が適用されます。マルチスレッド化の係数が 2 であるという全体的な仮定に基づいて、スレッド数を 2 で割ってコア数を決定します。その後、コア数はサブスクリプションサービスに送信されます。
3.2.3. サブスクライブしたクラスターサイズ (クラスターサイズ合計との比較) の理解
Red Hat OpenShift の場合、サブスクリプションサービスはクラスターとクラスター内のノードの合計サイズのみに焦点を当てているわけではありません。サブスクリプションサービスは、クラスターのサブスクライブされた部分、つまりワークロードを処理しているクラスターノードに焦点を当てます。したがって、サブスクリプションサービスのレポートは、クラスター全体のサイズではなく、サブスクライブされたクラスターサイズ に関するものです。
3.2.4. サブスクライブされたクラスターサイズの決定
データ収集ツールとサブスクリプションサービスは、サブスクライブされたクラスターサイズを決定するため、ノードタイプとノードラベルの両方を調べます。サブスクリプションサービスはこのデータを使用して、ワークロードを受け入れるノードを決定します。すべての非インフラストラクチャーノードとスケジュール可能なマスターノードの合計が、ワークロードに使用できるとみなされます。ワークロードに使用できるノードは、サブスクライブされたノードとしてカウントされ、サブスクライブされたクラスターサイズにカウントされ、サブスクリプションサービスの使用状況レポートに表示されます。
次の情報は、ノードラベルがノードの可算性にどのように影響し、さらにサブスクライブされたクラスターサイズに影響を与えるかについて詳細に説明します。内部環境と顧客環境の両方を分析すると、これらのラベルとラベルの組み合わせが顧客の設定の大部分を表していることがわかります。
ノードラベル | 使用量のカウント | 例外 |
---|---|---|
worker | はい | ワーカーラベルとインフララベルの組み合わせがない場合のみ |
worker + infra | いいえ | 注記 を参照してください。 |
custom label | はい | カスタムラベルとマスター、インフラ、またはコントロールプレーンのラベルの組み合わせがある場合を除く |
custom label + master, infra, control plane (任意の組み合わせ) | いいえ | |
master + infra + control plane (任意の組み合わせ) | いいえ | マスターラベルが存在し、さらに ノードがスケジュール可能としてマークされている場合を除く |
schedulable master + infra, control plane (任意の組み合わせ) | はい |
Red Hat OpenShift モニタリングスタックツールの既知の問題により、Red Hat OpenShift Container Platform バージョン 4.12 より前のバージョンでは予期しないコア数が発生する可能性があります。これらのバージョンでは、ワーカーノードの数を人為的に増やすことができます。
OpenShift Container Platform バージョン 4.12 より前のバージョンでは、Machine Config Operator はノード上のインフラとワーカーロールの二重割り当てをサポートしていません。OpenShift Container Platform では、サブスクライブされたノードのカウントの原則に従ってワーカーノードのカウントが正しく行われ、このカウントは OpenShift Container Platform Web コンソールに正しく表示されます。
ただし、モニタリングスタックツールがこのデータを分析し、Hybrid Cloud Console のサブスクリプションサービスやその他のサービスに送信すると、Machine Config Operator は二重のロールを無視し、ノードのロールをワーカーに設定します。したがって、サブスクリプションサービスと OpenShift Cluster Manager ではワーカーノードの数が増加します。
3.2.5. 従来の年間サブスクリプションがある Red Hat OpenShift Container Platform
サブスクリプションサービスは、クラスターの CPU コアまたはソケット別で Red Hat OpenShift Container Platform の使用状況を追跡し、以下のバージョンサポートによって改良されているように、このデータをアカウントビューに集約します。
- RHOCP 4.1 以降で、Red Hat Enterprise Linux CoreOS ベースのノード、または Red Hat Enterprise Linux CoreOS と RHEL ベースのノードの混合環境
- RHOCP 3.11
RHOCP サブスクリプションの使用については、メジャーバージョン 3 とバージョン 4 の間でレポートモデルに変更がありました。バージョン 3 はノードレベルで、バージョン 4 はクラスターレベルでの使用を想定しています。
RHOCP メジャーバージョンのレポートモデルに相違点があるため、Cloud Services プラットフォームのサブスクリプションサービスと関連サービスの使用量の計算方法にも若干の違いがあります。RHOCP バージョン 4 の場合、サブスクリプションサービスは、サブスクライブされたクラスターサイズの決定 で説明されているように、ノードタイプとノードラベルを検査するルールに従って、サブスクライブされたクラスターサイズを計算します。サブスクリプションサービスは、オーバーヘッドタスクを実行し、ワークロードを受け入れないクラスターの部分を認識し、無視します。サブスクリプションサービスは、ワークロードを受け入れるクラスターの部分のみを認識し、追跡します。
ただし、RHOCP バージョン 3.11 の場合、バージョン 3 のレポートモデルは、オーバーヘッドタスクを実行し、ワークロードを受け入れないクラスターの部分を区別できないため、レポートモデルはサブスクライブされたノードとサブスクライブされていないノードを見つけることができません。したがって、RHOCP バージョン 3.11 では、サブスクリプションサービスが報告するサブスクリプションデータの約 15% が、インフラストラクチャー関連のタスクを実行するサブスクライブされていないノードのオーバーヘッドであると想定できます。この割合は、RHOCP バージョン 3 のインストールにおけるクラスターのオーバーヘッドの分析に基づいています。この特定のケースでは、最大 15 % の容量超過を示す使用結果があっても、コンプライアンスに準拠している可能性が高いです。
3.2.6. 従量課金オンデマンド型サブスクリプションがある Red Hat OpenShift Container Platform または Red Hat OpenShift Dedicated
- RHOCP または OpenShift Dedicated 4.7 以降
サブスクリプションサービスは、RHOCP または OpenShift Dedicated 4.7 以降の使用量は、従量課金制のオンデマンド型サブスクリプションからコア時間 (一定期間における CPU コアのクラスターサイズの測定値) で追跡します。OpenShift Dedicated オンデマンド型サブスクリプションの場合は、コントロールプレーンリソースの消費量 (サービスインスタンスの可用性) がインスタンス時間で追跡されます。サブスクリプションサービスは、最終的にアカウント内のすべてのクラスターコア時間とインスタンス時間のデータを月ごとの合計値に集計します。これは、Red Hat Marketplace の課金サービスで使用される時間の単位です。
RHOCP 4.1 以降の情報に記載されているように、サブスクリプションサービスは、コンピュートノード (一般にワーカーノードとも呼ばれる) を含むクラスターの一部のみを認識し、追跡します。
3.2.7. AWS Hosted Control Plane 上の Red Hat OpenShift サービス (プリペイドおよびオンデマンドサブスクリプション付き)
サブスクリプションサービスは、前払いプラスオンデマンドサブスクリプションからの Red Hat OpenShift Service on AWS Hosted Control Plane (ROSA Hosted Control Plane) の使用状況を vCPU 時間とコントロールプレーン時間で追跡します。
- 仮想 CPU 時間 とは、1 つの仮想コア (サブスクリプション条件で定義) における合計 1 時間の計算活動への使用可能率を、使用するメーターの粒度に合わせて測定したものです。ROSA Hosted Control Plane の場合、計算アクティビティーの可用性は、時間の経過に伴う ROSA Hosted Control Plane にサブスクライブされたクラスターの仮想 CPU の可用性です。サブスクライブされたクラスターは、サブスクライブされたノード (非インフラストラクチャーノードと、該当する場合はワークロードに使用できるスケジュール可能なマスターノード) で構成されます。ROSA Hosted Control Plane の場合、この測定を使用する他の製品とは異なり、スケジュール可能なマスターノードは該当しない点に注意してください。サブスクライブされたクラスターのワークロード実行に使用できる vCPU は、vCPU 時間カウントに加算されます。
- コントロールプレーンの時間は、コントロールプレーンの可用性の測定値です。ROSA Hosted Control Plane では、各クラスターに専用のコントロールプレーンがあり、Red Hat が所有する ROSA Hosted Control Plane サービスアカウントで分離されています。