Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

第3章 インストール

3.1. OpenShift Virtualization のクラスターの準備
リンクのコピー

OpenShift Virtualization をインストールする前に、このセクションを参照して、クラスターが要件を満たしていることを確認してください。

3.1.1. Red Hat OpenShift Service on AWS クラシックアーキテクチャーでの OpenShift Virtualization
リンクのコピー

OpenShift Virtualization は、Red Hat OpenShift Service on AWS クラシックアーキテクチャークラスター上で実行できます。

クラスターを設定する前に、サポート対象の機能と制限に関する以下の要約を確認してください。

インストール

  • インストーラーでプロビジョニングされるインフラストラクチャーを使用してクラスターをインストールし、ワーカーノードにベアメタルインスタンスタイプを指定する必要があります。たとえば、x86_64 アーキテクチャーをベースとするマシンの c5n.metal タイプの値を使用できます。

    詳細は、AWS へのインストールに関する Red Hat OpenShift Service on AWS クラシックアーキテクチャーのドキュメントを参照してください。

仮想マシン (VM) へのアクセス
  • virtctl CLI ツールまたは Red Hat OpenShift Service on AWS クラシックアーキテクチャーの Web コンソールを使用して仮想マシンにアクセスする方法に変更はありません。

  • NodePort または LoadBalancer サービスを使用して、仮想マシンを公開できます。

    注記

    ロードバランサー方式が推奨されます。Red Hat OpenShift Service on AWS クラシックアーキテクチャーにより、AWS 上にロードバランサーが自動的に作成され、そのライフサイクルが管理されるためです。また、ロードバランサー用のセキュリティーグループも作成され、アノテーションを使用して既存のセキュリティーグループを割り当てることができます。サービスを削除すると、Red Hat OpenShift Service on AWS クラシックアーキテクチャーによってロードバランサーとそれに関連付けられたリソースが削除されます。

ネットワーク
  • アプリケーションで Egress トラフィックを必要としないフラットなレイヤー 2 ネットワークが必要な場合は、Layer2 トポロジーで OVN-Kubernetes セカンダリーオーバーレイネットワークを使用することを検討してください。
ストレージ

  • 基盤となるプラットフォームとの連携がストレージベンダーによって認定されている任意のストレージソリューションを使用できます。

    重要

    AWS ベアメタル、Red Hat OpenShift Service on AWS、および Red Hat OpenShift Service on AWS クラシックアーキテクチャーの各クラスターで、サポートされるストレージソリューションが異なる場合があります。ストレージベンダーにサポートを確認してください。

  • OpenShift Virtualization で Amazon Elastic File System (EFS) または Amazon Elastic Block Store (EBS) を使用すると、次の表に示すようにパフォーマンスと機能の制限が発生する可能性があります。

    Expand
    表3.1 EFS と EBS のパフォーマンスと機能の制限
    機能EBS ボリュームEFS ボリューム共有ストレージソリューション
     

    gp2

    gp3

    io2

    		  

    仮想マシンライブマイグレーション

    利用不可

    利用不可

    利用可能

    利用可能

    利用可能

    クローン作成による高速仮想マシン作成

    利用可能

    利用不可

    利用可能

    スナップショットを使用した仮想マシンのバックアップと復元

    利用可能

    利用不可

    利用可能

    ライブマイグレーション、高速仮想マシンの作成、仮想マシンスナップショット機能の有効化を行うには、ReadWriteMany (RWX)、クローン作成、スナップショットをサポートする CSI ストレージの使用を検討してください。

3.1.2. ARM64 互換性
リンクのコピー

ARM64 システムにインストールされた Red Hat OpenShift Service on AWS クラシックアーキテクチャークラスターで OpenShift Virtualization を使用する機能が一般提供 (GA) されました。

ARM64 ベースのシステムで OpenShift Virtualization を使用する前に、次の制限に留意してください。

オペレーティングシステム
ライブマイグレーション
  • ARM64 ベースの Red Hat OpenShift Service on AWS クラシックアーキテクチャークラスターではライブマイグレーションは サポートされていません。
  • ホットプラグはライブマイグレーションに依存するため、ARM64 ベースのクラスターではサポートされていません。
仮想マシンの作成
  • RHEL 10 は、インスタンスタイプと設定をサポートしますが、テンプレートはサポートしていません。
  • RHEL 9 は、テンプレート、インスタンスタイプ、および設定をサポートします。

3.1.3. ハードウェアとオペレーティングシステムの要件
リンクのコピー

OpenShift Virtualization の次のハードウェアおよびオペレーティングシステム要件を確認してください。

3.1.3.1. CPU の要件
リンクのコピー

  • Red Hat Enterprise Linux (RHEL) 9 でサポート。

    サポートされている CPU の Red Hat Ecosystem Catalog を参照してください。

    注記

    ワーカーノードの CPU が異なる場合は、CPU ごとに機能が異なるため、ライブマイグレーションが失敗する可能性があります。この問題は、ワーカーノードに適切な容量の CPU が搭載されていることを確認し、仮想マシンのノードアフィニティールールを設定することで軽減できます。

    詳細は、ノードアフィニティーの required (必須) ルールの設定 を参照してください。

  • AMD64、Intel 64 ビット (x86-64-v2)、IBM Z® (s390x)、または ARM64 ベース (arm64 または aarch64) アーキテクチャーとそれぞれの CPU 拡張機能のサポートがある。
  • Intel VT-x、AMD-V、または ARM 仮想化拡張機能が有効になっているか、s390x 仮想化サポートが有効になっている。
  • NX (実行なし) フラグが有効になっている。
  • s390x アーキテクチャーを使用する場合、default CPU model が gen15b に設定されている。

3.1.3.2. オペレーティングシステム要件
リンクのコピー

  • ワーカーノードにインストールされた Red Hat Enterprise Linux CoreOS (RHCOS)。

3.1.3.3. ストレージ要件
リンクのコピー

  • Red Hat OpenShift Service on AWS クラシックアーキテクチャーによってサポートされています。
  • ストレージプロビジョナーがスナップショットをサポートしている場合は、VolumeSnapshotClass オブジェクトをデフォルトのストレージクラスに関連付ける必要があります。
3.1.3.3.1. 仮想マシンディスクのボリュームとアクセスモードについて
リンクのコピー

既知のストレージプロバイダーでストレージ API を使用する場合、ボリュームモードとアクセスモードは自動的に選択されます。ただし、ストレージプロファイルのないストレージクラスを使用する場合は、ボリュームとアクセスモードを設定する必要があります。

OpenShift Virtualization に対応している既知のストレージプロバイダーのリストは、Red Hat Ecosystem Catalog を参照してください。

最良の結果を得るには、ReadWriteMany (RWX) アクセスモードと Block ボリュームモードを使用してください。これは、以下の理由により重要です。

  • ライブマイグレーションには ReadWriteMany (RWX) アクセスモードが必要です。
  • Block ボリュームモードは、Filesystem ボリュームモードよりもパフォーマンスが大幅に優れています。これは、Filesystem ボリュームモードでは、ファイルシステムレイヤーやディスクイメージファイルなどを含め、より多くのストレージレイヤーが使用されるためです。仮想マシンのディスクストレージに、これらのレイヤーは必要ありません。
重要

次の設定の仮想マシンをライブマイグレーションすることはできません。

  • ReadWriteOnce (RWO) アクセスモードのストレージボリューム
  • GPU などのパススルー機能

これらの仮想マシンの evictionStrategy フィールドを None に設定します。None ストラテジーでは、ノードの再起動中に仮想マシンの電源がオフになります。

3.1.4. ライブマイグレーションの要件
リンクのコピー

  • ReadWriteMany (RWX) アクセスモードの共有ストレージ

  • 十分な RAM およびネットワーク帯域幅

    注記

    ノードの drain に伴うライブマイグレーションを実行できるように、クラスター内に十分なメモリーリクエスト容量があることを確認する必要があります。以下の計算を使用して、必要な予備のメモリーを把握できます。 

    Product of (Maximum number of nodes that can drain in parallel) and (Highest total VM memory request allocations across nodes)

    クラスターで 並行して実行できるデフォルトの移行数 は 5 です。

  • 仮想マシンがホストモデルの CPU を使用する場合、ノードは仮想マシンのホストモデルの CPU をサポートする必要があります。
注記

ライブマイグレーション 専用の Multus ネットワーク を強く推奨します。専用ネットワークは、移行中のテナントワークロードに対するネットワークの飽和状態の影響を最小限に抑えます。

3.1.5. 物理リソースのオーバーヘッド要件
リンクのコピー

OpenShift Virtualization は、Red Hat OpenShift Service on AWS クラシックアーキテクチャーのアドオンであり、追加のオーバーヘッドを発生させます。クラスターを計画する際には、このオーバーヘッドを考慮する必要があります。

各クラスターマシンは、Red Hat OpenShift Service on AWS クラシックアーキテクチャーの要件に加えて、次のオーバーヘッドの要件を満たす必要があります。クラスター内の物理リソースを過剰にサブスクライブすると、パフォーマンスに影響する可能性があります。

重要

このドキュメントに記載されている数は、Red Hat のテスト方法およびセットアップに基づいています。これらの数は、独自のセットアップおよび環境に応じて異なります。

3.1.5.1. メモリーのオーバーヘッド
リンクのコピー

以下の式を使用して、OpenShift Virtualization のメモリーオーバーヘッドの値を計算します。

クラスターメモリーのオーバーヘッド
Memory overhead per infrastructure node ≈ 150 MiB
 
Memory overhead per worker node ≈ 360 MiB

さらに、OpenShift Virtualization 環境リソースには、すべてのインフラストラクチャーノードに分散される合計 2179 MiB の RAM が必要です。

仮想マシンのメモリーオーバーヘッド
Memory overhead per virtual machine ≈ (0.002 × requested memory) \
              + 218 MiB \
1 

              + 8 MiB × (number of vCPUs) \
2 

              + 16 MiB × (number of graphics devices) \
3 

              + (additional memory overhead)
4
1
virt-launcher Pod で実行されるプロセスに必要です。
2
仮想マシンが要求する仮想 CPU の数。
3
仮想マシンが要求する仮想グラフィックスカードの数。
4
追加のメモリーオーバーヘッド:
  • お使いの環境に Single Root I/O Virtualization (SR-IOV) ネットワークデバイスまたは Graphics Processing Unit (GPU) が含まれる場合、それぞれのデバイスに 1 GiB の追加のメモリーオーバーヘッドを割り当てます。
  • Secure Encrypted Virtualization (SEV) が有効な場合は、256 MiB を追加します。
  • Trusted Platform Module (TPM) が有効な場合は、53 MiB を追加します。

3.1.5.2. CPU オーバーヘッド
リンクのコピー

以下の式を使用して、OpenShift Virtualization のクラスタープロセッサーのオーバーヘッド要件を計算します。仮想マシンごとの CPU オーバーヘッドは、個々の設定によって異なります。

クラスターの CPU オーバーヘッド
CPU overhead for infrastructure nodes ≈ 4 cores

OpenShift Virtualization は、ロギング、ルーティング、およびモニタリングなどのクラスターレベルのサービスの全体的な使用率を増加させます。このワークロードに対応するには、インフラストラクチャーコンポーネントをホストするノードに、4 つの追加コア (4000 ミリコア) の容量があり、これがそれらのノード間に分散されていることを確認します。 

CPU overhead for worker nodes ≈ 2 cores + CPU overhead per virtual machine

仮想マシンをホストする各ワーカーノードには、仮想マシンのワークロードに必要な CPU に加えて、OpenShift Virtualization 管理ワークロード用に 2 つの追加コア (2000 ミリコア) の容量が必要です。

仮想マシンの CPU オーバーヘッド
専用の CPU が要求される場合は、仮想マシン 1 台につき CPU 1 つとなり、クラスターの CPU オーバーヘッド要件に影響が出てきます。それ以外の場合は、仮想マシンに必要な CPU の数に関する特別なルールはありません。

3.1.5.3. ストレージのオーバーヘッド
リンクのコピー

以下のガイドラインを使用して、OpenShift Virtualization 環境のストレージオーバーヘッド要件を見積もります。

クラスターストレージオーバーヘッド
Aggregated storage overhead per node ≈ 10 GiB

10 GiB は、OpenShift Virtualization のインストール時にクラスター内の各ノードに関するディスク上のストレージの予想される影響に相当します。

仮想マシンのストレージオーバーヘッド
仮想マシンごとのストレージオーバーヘッドは、仮想マシン内のリソース割り当ての特定の要求により異なります。この要求は、クラスター内の別の場所でホストされるノードまたはストレージリソースの一時ストレージに対するものである可能性があります。OpenShift Virtualization は現在、実行中のコンテナー自体に追加の一時ストレージを割り当てていません。
例
クラスター管理者が、クラスター内の 10 台の (それぞれ 1 GiB の RAM と 2 つの仮想 CPU の) 仮想マシンをホストする予定の場合、クラスター全体で影響を受けるメモリーは 11.68 GiB になります。クラスターの各ノードについて予想されるディスク上のストレージの影響は 10 GiB で示され、仮想マシンのワークロードをホストするワーカーノードに関する CPU の影響は最小 2 コアで示されます。
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

Legal Notice

Theme

© 2026 Red Hatトップに戻る