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) へのアクセス
-
virtctlCLI ツールまたは Red Hat OpenShift Service on AWS クラシックアーキテクチャーの Web コンソールを使用して仮想マシンにアクセスする方法に変更はありません。 NodePortまたはLoadBalancerサービスを使用して、仮想マシンを公開できます。- ロードバランサー方式が推奨されます。Red Hat OpenShift Service on AWS クラシックアーキテクチャーにより、AWS 上にロードバランサーが自動的に作成され、そのライフサイクルが管理されるためです。また、ロードバランサー用のセキュリティーグループも作成され、アノテーションを使用して既存のセキュリティーグループを割り当てることができます。サービスを削除すると、Red Hat OpenShift Service on AWS クラシックアーキテクチャーによってロードバランサーとそれに関連付けられたリソースが削除されます。
- ネットワーク
- アプリケーションにフラットレイヤー 2 ネットワークが必要な場合や、IP プールを制御する必要がある場合は、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. ハードウェアとオペレーティングシステムの要件
OpenShift Virtualization の次のハードウェアおよびオペレーティングシステム要件を確認してください。
3.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 (実行なし) フラグが有効。
3.1.2.2. オペレーティングシステム要件
- ワーカーノードにインストールされた Red Hat Enterprise Linux CoreOS (RHCOS)。
3.1.2.3. ストレージ要件
- Red Hat OpenShift Service on AWS クラシックアーキテクチャーによってサポートされています。
-
ストレージプロビジョナーがスナップショットをサポートしている場合は、
VolumeSnapshotClassオブジェクトをデフォルトのストレージクラスに関連付ける必要があります。
3.1.2.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.3. ライブマイグレーションの要件
-
ReadWriteMany(RWX) アクセスモードの共有ストレージ 十分な RAM およびネットワーク帯域幅
注記ノードのドレインに伴うライブマイグレーションを実行できるように、クラスター内に十分なメモリーリクエスト容量があることを確認する必要があります。以下の計算を使用して、必要な予備のメモリーを把握できます。
Product of (Maximum number of nodes that can drain in parallel) and (Highest total VM memory request allocations across nodes)
Product of (Maximum number of nodes that can drain in parallel) and (Highest total VM memory request allocations across nodes)Copy to Clipboard Copied! Toggle word wrap Toggle overflow クラスターで 並行して実行できるデフォルトの移行数 は 5 です。
- 仮想マシンがホストモデルの CPU を使用する場合、ノードは仮想マシンのホストモデルの CPU をサポートする必要があります。
- ライブマイグレーション 専用の Multus ネットワーク を強く推奨します。専用ネットワークは、移行中のテナントワークロードに対するネットワークの飽和状態の影響を最小限に抑えます。
3.1.4. 物理リソースのオーバーヘッド要件
OpenShift Virtualization は、Red Hat OpenShift Service on AWS クラシックアーキテクチャーのアドオンであり、追加のオーバーヘッドを発生させます。クラスターを計画する際には、このオーバーヘッドを考慮する必要があります。各クラスターマシンは、Red Hat OpenShift Service on AWS クラシックアーキテクチャーの要件に加えて、次のオーバーヘッドの要件を満たす必要があります。クラスター内の物理リソースを過剰にサブスクライブすると、パフォーマンスに影響する可能性があります。
このドキュメントに記載されている数は、Red Hat のテスト方法およびセットアップに基づいています。これらの数は、独自のセットアップおよび環境に応じて異なります。
メモリーのオーバーヘッド
以下の式を使用して、OpenShift Virtualization のメモリーオーバーヘッドの値を計算します。
クラスターメモリーのオーバーヘッド
Memory overhead per infrastructure node ≈ 150 MiB
Memory overhead per infrastructure node ≈ 150 MiBMemory overhead per worker node ≈ 360 MiB
Memory overhead per worker node ≈ 360 MiBさらに、OpenShift Virtualization 環境リソースには、すべてのインフラストラクチャーノードに分散される合計 2179 MiB の RAM が必要です。
仮想マシンのメモリーオーバーヘッド
Memory overhead per virtual machine ≈ (1.002 × requested memory) \
+ 218 MiB \
+ 8 MiB × (number of vCPUs) \
+ 16 MiB × (number of graphics devices) \
+ (additional memory overhead)
Memory overhead per virtual machine ≈ (1.002 × requested memory) \
+ 218 MiB \
+ 8 MiB × (number of vCPUs) \
+ 16 MiB × (number of graphics devices) \
+ (additional memory overhead) - 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
CPU overhead for infrastructure nodes ≈ 4 coresOpenShift Virtualization は、ロギング、ルーティング、およびモニタリングなどのクラスターレベルのサービスの全体的な使用率を増加させます。このワークロードに対応するには、インフラストラクチャーコンポーネントをホストするノードに、4 つの追加コア (4000 ミリコア) の容量があり、これがそれらのノード間に分散されていることを確認します。
CPU overhead for worker nodes ≈ 2 cores + CPU overhead per virtual machine
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
Aggregated storage overhead per node ≈ 10 GiB10 GiB は、OpenShift Virtualization のインストール時にクラスター内の各ノードに関するディスク上のストレージの予想される影響に相当します。
仮想マシンのストレージオーバーヘッド
仮想マシンごとのストレージオーバーヘッドは、仮想マシン内のリソース割り当ての特定の要求により異なります。この要求は、クラスター内の別の場所でホストされるノードまたはストレージリソースの一時ストレージに対するものである可能性があります。OpenShift Virtualization は現在、実行中のコンテナー自体に追加の一時ストレージを割り当てていません。
例
クラスター管理者が、クラスター内の 10 台の (それぞれ 1 GiB の RAM と 2 つの仮想 CPU の) 仮想マシンをホストする予定の場合、クラスター全体で影響を受けるメモリーは 11.68 GiB になります。クラスターの各ノードについて予想されるディスク上のストレージの影響は 10 GiB で示され、仮想マシンのワークロードをホストするワーカーノードに関する CPU の影響は最小 2 コアで示されます。
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}