第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 では、以下のプラットフォームを使用できます。
- オンプレミスのベアメタルサーバー。OpenShift Virtualization で使用するベアメタルクラスターの計画 を参照してください。
IBM Cloud® ベアメタルサーバー。Deploy OpenShift Virtualization on IBM Cloud® Bare Metal nodes を参照してください。
重要IBM Cloud® ベアメタルサーバーへの OpenShift Virtualization のインストールは、テクノロジープレビュー機能としてのみ提供されます。テクノロジープレビュー機能は、Red Hat 製品サポートのサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではない場合があります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
他のクラウドプロバイダーが提供するベアメタルインスタンスまたはサーバーはサポートされていません。
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 クラスターでもサポートされています。
クラスターを設定する前に、サポート対象の機能と制限に関する以下の要約を確認してください。
- インストール
installer-provisioned infrastructure を使用してクラスターをインストールできます。その際に、
install-config.yamlファイルを編集してワーカーノードのベアメタルインスタンスタイプを確実に指定してください。たとえば、x86_64 アーキテクチャーをベースとするマシンのc5n.metalタイプの値を使用できます。詳細は、AWS へのインストールに関する OpenShift Container Platform ドキュメントを参照してください。
- 仮想マシン (VM) へのアクセス
-
virtctlCLI ツールまたは 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)を使用すると、パフォーマンスと機能の制限が発生する可能性があります。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-launcherPod で実行されるプロセスに必要です。- 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) オプションのいずれかを設定できます。
nstaller-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>を実行します。注記外部モニタリングシステムまたは資格のある人材によるノードの正常性の監視が行われない場合、仮想マシンは高可用性を失います。
