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

第4章 インストール

4.1. OpenShift Virtualization のクラスターの準備

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

重要
インストール方法の考慮事項
ユーザープロビジョニング、インストーラープロビジョニング、またはアシステッドインストーラーなど、任意のインストール方法を使用して、OpenShift Container Platform をデプロイできます。ただし、インストール方法とクラスタートポロジーは、スナップショットや ライブマイグレーション などの OpenShift Virtualization 機能に影響を与える可能性があります。
Red Hat OpenShift Data Foundation
Red Hat OpenShift Data Foundation を使用して OpenShift Virtualization をデプロイする場合は、Windows 仮想マシンディスク用の専用ストレージクラスを作成する必要があります。詳細は Windows VM の ODF PersistentVolumes の最適化 を参照してください。
IPv6
シングルスタックの IPv6 クラスターで OpenShift Virtualization は実行できません。

FIPS モード

クラスターを FIPS モード でインストールする場合、OpenShift Virtualization に追加の設定は必要ありません。

4.1.1. サポート対象のプラットフォーム

OpenShift Virtualization では、以下のプラットフォームを使用できます。

他のクラウドプロバイダーが提供するベアメタルインスタンスまたはサーバーはサポートされていません。

4.1.1.1. AWS ベアメタル上の OpenShift Virtualization

OpenShift Virtualization は、Amazon Web Services (AWS) ベアメタル OpenShift Container Platform クラスターで実行できます。

注記

OpenShift Virtualization は、AWS ベアメタルクラスターと同じ設定要件を持つ Red Hat OpenShift Service on AWS (ROSA) Classic クラスターでもサポートされています。

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

インストール

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

    詳細は、AWS へのインストールに関する OpenShift Container Platform ドキュメントを参照してください。

仮想マシン (VM) へのアクセス
  • virtctl CLI ツールまたは OpenShift Container Platform Web コンソールを使用して仮想マシンにアクセスする方法に変更はありません。

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

    • OpenShift Container Platform は AWS でロードバランサーを自動的に作成し、そのライフサイクルを管理するため、ロードバランサーのアプローチが推奨されます。また、セキュリティーグループはロードバランサー用にも作成され、アノテーションを使用して既存のセキュリティーグループをアタッチできます。サービスを削除すると、OpenShift Container Platform はロードバランサーとそれに関連付けられたリソースを削除します。
ネットワーク
  • Single Root I/O Virtualization (SR-IOV) またはブリッジ Container Network Interface (CNI) ネットワーク (仮想 LAN (VLAN) を含む) は使用できません。アプリケーションにフラットレイヤー 2 ネットワークが必要な場合や、IP プールを制御する必要がある場合は、OVN-Kubernetes セカンダリーオーバーレイネットワークを使用することを検討してください。
ストレージ

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

    重要

    AWS ベアメタルクラスターと ROSA クラスターでは、サポートされているストレージソリューションが異なる場合があります。ストレージベンダーにサポートを確認してください。

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

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

    gp2

    gp3

    io2

    		  

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

    利用不可

    利用不可

    利用可能

    利用可能

    利用可能

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

    利用可能

    利用不可

    利用可能

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

    利用可能

    利用不可

    利用可能

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

Hosted Control Plane (HCP)
  • OpenShift Virtualization の HCP は現在、AWS インフラストラクチャーではサポートされていません。

関連情報

4.1.2. ハードウェアとオペレーティングシステムの要件

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

4.1.2.1. CPU の要件

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

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

    注記

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

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

  • AMD および Intel 64 ビットアーキテクチャー (x86-64-v2) のサポート。
  • Intel 64 または AMD64 CPU 拡張機能のサポート。
  • Intel VT または AMD-V ハードウェア仮想化拡張機能が有効化されている。
  • NX (実行なし) フラグが有効。

4.1.2.2. オペレーティングシステム要件

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

    詳細は、RHCOS について を参照してください。

    注記

    RHEL ワーカーノードはサポートされていません。

4.1.2.3. ストレージ要件

  • OpenShift Container Platform によるサポート。ストレージの最適化 を参照してください。
  • デフォルトの OpenShift Virtualization または OpenShift Container Platform ストレージクラスを作成する必要があります。これは、仮想マシンワークロード固有のストレージニーズに対応し、最適化されたパフォーマンス、信頼性、ユーザーエクスペリエンスを提供することを目的としています。OpenShift Virtualization と OpenShift Container Platform の両方にデフォルトのストレージクラスが存在する場合、仮想マシンディスクの作成時には OpenShift Virtualization のクラスが優先されます。
注記

ストレージクラスを仮想化ワークロードのデフォルトとしてマークするには、アノテーション storageclass.kubevirt.io/is-default-virt-class を "true" に設定します。

  • ストレージプロビジョナーがスナップショットをサポートしている場合は、VolumeSnapshotClass オブジェクトをデフォルトのストレージクラスに関連付ける必要があります。
4.1.2.3.1. 仮想マシンディスクのボリュームとアクセスモードについて

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

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

  • ライブマイグレーションには ReadWriteMany (RWX) アクセスモードが必要です。

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

    たとえば、Red Hat OpenShift Data Foundation を使用する場合は、CephFS ボリュームよりも Ceph RBD ボリュームの方が推奨されます。

重要

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

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

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

4.1.3. ライブマイグレーションの要件

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

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

    注記

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

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

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

  • 仮想マシンがホストモデルの CPU を使用する場合、ノードは仮想マシンのホストモデルの CPU をサポートする必要があります。
  • ライブマイグレーション 専用の Multus ネットワーク を強く推奨します。専用ネットワークは、移行中のテナントワークロードに対するネットワークの飽和状態の影響を最小限に抑えます。

4.1.4. 物理リソースのオーバーヘッド要件

OpenShift Virtualization は OpenShift Container Platform のアドオンであり、クラスターの計画時に考慮する必要のある追加のオーバーヘッドを強要します。各クラスターマシンは、OpenShift Container Platform の要件に加えて、以下のオーバーヘッドの要件を満たす必要があります。クラスター内の物理リソースを過剰にサブスクライブすると、パフォーマンスに影響する可能性があります。

重要

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

メモリーのオーバーヘッド

以下の式を使用して、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 ≈ (1.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 を追加します。
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 の数に関する特別なルールはありません。

ストレージのオーバーヘッド

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

クラスターストレージオーバーヘッド

Aggregated storage overhead per node ≈ 10 GiB

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

仮想マシンのストレージオーバーヘッド

仮想マシンごとのストレージオーバーヘッドは、仮想マシン内のリソース割り当ての特定の要求により異なります。この要求は、クラスター内の別の場所でホストされるノードまたはストレージリソースの一時ストレージに対するものである可能性があります。OpenShift Virtualization は現在、実行中のコンテナー自体に追加の一時ストレージを割り当てていません。

例

クラスター管理者が、クラスター内の 10 台の (それぞれ 1 GiB の RAM と 2 つの vCPU の) 仮想マシンをホストする予定の場合、クラスター全体で影響を受けるメモリーは 11.68 GiB になります。クラスターの各ノードについて予想されるディスク上のストレージの影響は 10 GiB で示され、仮想マシンのワークロードをホストするワーカーノードに関する CPU の影響は最小 2 コアで示されます。

4.1.5. シングルノード OpenShift の違い

OpenShift Virtualization はシングルノード OpenShift にインストールできます。

ただし、シングルノード OpenShift は次の機能をサポートしていないことに注意してください。

  • 高可用性
  • Pod の中断
  • ライブマイグレーション
  • エビクションストラテジーが設定されている仮想マシンまたはテンプレート

関連情報

4.1.6. オブジェクトの最大値

クラスターを計画するときは、次のテスト済みオブジェクトの最大数を考慮する必要があります。

4.1.7. クラスターの高可用性オプション

クラスターには、次の高可用性 (HA) オプションのいずれかを設定できます。

  • installer-provisioned infrastructure (IPI) の自動高可用性は、マシンヘルスチェック をデプロイすることで利用できます。

    注記

    インストーラーによってプロビジョニングされたインフラストラクチャーを使用し、適切に設定された MachineHealthCheck リソースを使用してインストールされた OpenShift Container Platform クラスターでは、ノードがマシンヘルスチェックに失敗し、クラスターで使用できなくなった場合、そのノードはリサイクルされます。障害が発生したノードで実行された仮想マシンでは、一連の条件によって次に起こる動作が変わります。潜在的な結果と、実行戦略がそれらの結果にどのように影響するかに関する詳細は、戦略の実行 を参照してください。

  • IPI と非 IPI の両方の自動高可用性は、OpenShift Container Platform クラスターで Node Health Check Operator を使用して NodeHealthCheck コントローラーをデプロイすることで利用できます。コントローラーは異常なノードを特定し、Self Node Remediation Operator や Fence Agents Remediation Operator などの修復プロバイダーを使用して異常なノードを修復します。ノードの修復、フェンシング、メンテナンスの詳細は、Red Hat OpenShift のワークロードの可用性 を参照してください。

  • モニタリングシステムまたは有資格者を使用してノードの可用性をモニターすることにより、あらゆるプラットフォームの高可用性を利用できます。ノードが失われた場合は、これをシャットダウンして oc delete node <lost_node> を実行します。

    注記

    外部モニタリングシステムまたは資格のある人材によるノードの正常性の監視が行われない場合、仮想マシンは高可用性を失います。

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.