5.2. 移行の制約

移行の制約は通常、ブロックマイグレーション、設定ディスク、またはいずれかのインスタンスがコンピュートノード上の物理ハードウェアにアクセスする場合に生じます。

CPU に関する制約

移行元および移行先コンピュートノードの CPU アーキテクチャーは、同一であることが必須です。たとえば、Red Hat では、x86_64 CPU から ppc64le CPU へのインスタンスの移行をサポートしません。CPU ホストパススルーを使用するインスタンス等の場合には、移行元および移行先コンピュートノードの CPU は、完全に同一でなければなりません。すべてのケースで、移行先ノードの CPU 機能は、移行元ノードの CPU 機能の上位セットであることが必須です。CPU ピニングが使用されている場合には、さらに制約が生じます。詳細は、「 ライブマイグレーションの制約 」を参照してください。

メモリーに関する制約

移行先コンピュートノードでは、十分な RAM が利用可能でなければなりません。メモリーのオーバーサブスクリプションが、移行失敗の原因となる可能性があります。また、NUMA トポロジーを使用するインスタンスの場合、移行先コンピュートノードの同じ NUMA ノードで十分な RAM が利用可能でなければなりません。

ブロックマイグレーションに関する制約

インスタンスの使用するディスクがコンピュートノード上にローカルに格納されている場合、その移行には、共有ストレージ (Red Hat Ceph Storage 等) を使用するボリュームベースのインスタンスよりもはるかに長い時間がかかります。このレイテンシーは、OpenStack Compute (nova) がコンピュートノード間でローカルディスクをブロックごとに移行するために発生します。この処理は、デフォルトではコントロールプレーンネットワークを通じて行われます。これとは対照的に、Red Hat Ceph Storage 等の共有ストレージを使用するボリュームベースのインスタンスでは、ボリュームを移行する必要がありません。それぞれのコンピュートノードが、共有ストレージにアクセスできるためです。

注記

大量の RAM を消費するローカルディスクまたはインスタンスの移行により、コントロールプレーンネットワークに輻輳が生じ、コントロールプレーンネットワークを使用する他のシステム (RabbitMQ 等) のパフォーマンスに悪影響を及ぼす場合があります。

読み取り専用ドライブの移行に関する制約

ドライブの移行は、ドライブに読み取りおよび書き込み両方の機能がある場合に限りサポートされます。たとえば、OpenStack Compute (nova) は CD-ROM ドライブまたは読み取り専用のコンフィグドライブを移行することはできません。ただし、OpenStack Compute (nova) は、vfat 等のドライブ形式を持つコンフィグドライブなど、読み取りおよび書き込み両方の機能を持つドライブを移行することができます。

ライブマイグレーションに関する制約

インスタンスのライブマイグレーションでは、さらに制約が生じる場合があります。

移行中に新しい操作を行うことができない
移行元および移行先ノードのインスタンスのコピー間で状態の整合性を確保するために、RHOSP ではライブマイグレーション中の新規操作を拒否する必要があります。拒否しないと、ライブマイグレーションでメモリーの状態を複製する前にメモリーへの書き込みが行われた場合、ライブマイグレーションに長い時間がかかる状況や、永久に完了しない状況が発生する可能性があります。
NUMA、CPU ピニング、ヒュージページ、および DPDK

OpenStack Compute では、環境が以下の条件を満たしている場合に、NUMA、CPU ピニング、または DPDK を使用するインスタンスのライブマイグレーションが可能です。

  • 移行先コンピュートノードには、インスタンスが移行元コンピュートノードで使用するのと同じ NUMA ノードに十分な容量がなければなりません。たとえば、インスタンスが overcloud-compute-0 で NUMA 0 を使用している場合に、インスタンスを overcloud-compute-1 にライブマイグレーションするには、overcloud-compute-1 は NUMA 0 にインスタンスをサポートするのに十分な空き容量を確保する必要があります。
  • Compute の設定で NovaEnableNUMALiveMigration が「True」に設定されている。このパラメーターは、コンピュートホストが OVS-DPDK デプロイメント用に設定されている場合に限り、デフォルトで有効になります。
  • Compute 設定の NovaSchedulerDefaultFilters パラメーターには、AggregateInstanceExtraSpecsFilter および NUMATopologyFilter の値が含まれている必要があります。
  • CPU ピニング: フレーバーで CPU ピニングが使用される場合、フレーバーは暗黙的に NUMA トポロジーをインスタンスに適用し、その CPU およびメモリーを特定のホスト CPU およびメモリーにマッピングします。シンプルな NUMA トポロジーと CPU ピニングの違いは、NUMA では CPU コアの範囲が指定されるのに対して、CPU ピニングでは特定の CPU コアが使用される点です。詳しくは、『インスタンス＆イメージガイド』 の「NUMA ノードを使用する CPU ピニングの設定」を 参照してください。CPU ピニングを使用するインスタンスのライブマイグレーションを行うには、移行先ホストが空で、等価なハードウェアが使用されている必要があります。
  • Data Plane Development Kit (DPDK): インスタンスが DPDK を使用する場合 (Open vSwitch と dpdk-netdev を組み合わせて実行するインスタンスなど)、インスタンスはヒュージページも使用します。この場合、OpenStack Compute (nova) がインスタンスを NUMA ノードに固定するような NUMA トポロジーが適用されます。DPDK を使用するインスタンスを移行する場合、移行先コンピュートノードのハードウェア仕様と設定は、移行元コンピュートノードと同一でなければなりません。また、移行元コンピュートノードの NUMA トポロジーを維持するために、移行先コンピュートノードに実行中のインスタンスがあってはいけません。

ライブマイグレーションの妨げとなる制約

以下の機能を使用するインスタンスのライブマイグレーションを行うことはできません。

Single-root Input/Output Virtualization(SR-IOV)
SR-IOV Virtual Function(VF)をインスタンスに割り当てることができます。ただし、これによりライブマイグレーションが妨げられます。通常のネットワークデバイスとは異なり、SR-IOV VF ネットワークデバイスは、永続的な一意の MAC アドレスを持ちません。コンピュートノードがリブートするたびに、またはスケジューラーがインスタンスを新しいコンピュートノードに移行する際に、VF ネットワークデバイスには新しい MAC アドレスが割り当てられます。したがって、OpenStack Compute は SR-IOV を使用するインスタンスのライブマイグレーションを行うことができません。SR-IOV を使用するインスタンスでは、コールドマイグレーションを行う必要があります。
PCI パススルー
QEMU/KVM ハイパーバイザーでは、コンピュートノード上の PCI デバイスをインスタンスにアタッチすることができます。PCI パススルーを使用すると、インスタンスは PCI デバイスに排他的にアクセスすることができ、これらのデバイスがインスタンスのオペレーティングシステムに物理的に接続されているかのように表示され、動作します。ただし、PCI パススルーには物理アドレスが必要なため、OpenStack Compute は PCI パススルーを使用するインスタンスのライブマイグレーションをサポートしません。