14.2. コンピュートノード間の仮想マシンインスタンスの移行
メンテナンスを実行する場合やワークロードのリバランスを行う場合、あるいは障害が発生した/障害が発生しつつあるノードを置き換える場合に、あるコンピュートノードからオーバークラウド内の別のコンピュートノードにインスタンスを移行しなければならない場合があります。
- コンピュートノードのメンテナンス
- ハードウェアのメンテナンスや修理、カーネルのアップグレードおよびソフトウェアの更新を行うなどの理由により、コンピュートノードを一時的に停止する必要がある場合、コンピュートノード上で実行中のインスタンスを別のコンピュートノードに移行することができます。
- 障害が発生しつつあるコンピュートノード
- コンピュートノードで障害が発生する可能性があり、ノードのサービスまたは置き換えが必要な場合、障害が発生しつつあるコンピュートノードから正常なコンピュートノードにインスタンスを移行することができます。
- 障害が発生したコンピュートノード
- コンピュートノードですでに障害が発生している場合には、インスタンスを退避させることができます。同じ名前、UUID、ネットワークアドレス、およびコンピュートノードに障害が発生する前にインスタンスに割り当てられていたその他すべてのリソースを使用して、元のイメージから別のコンピュートノードにインスタンスを再ビルドすることができます。
- ワークロードのリバランス
- ワークロードをリバランスするために、1 つまたは複数のインスタンスを別のコンピュートノードに移行することができます。たとえば、コンピュートノード上のインスタンスを 1 つにまとめて電力を節約する、他のネットワークリソースに物理的に近いコンピュートノードにインスタンスを移行してレイテンシーを低減する、インスタンスを全コンピュートノードに分散してホットスポットをなくし復元力を向上させる、等が可能です。
director は、すべてのコンピュートノードがセキュアな移行を提供するように設定します。すべてのコンピュートノードには、移行プロセス中それぞれのホストのユーザーが他のコンピュートノードにアクセスできるように、共有 SSH キーも必要です。director は、OS::TripleO::Services::NovaCompute
コンポーザブルサービスを使用してこのキーを作成します。このコンポーザブルサービスは、すべての Compute ロールにデフォルトで含まれているメインのサービスの 1 つです。詳細は、オーバークラウドの高度なカスタマイズ ガイドの コンポーザブルサービスとカスタムロール を参照してください。
バックアップの目的で正常に機能しているコンピュートノードインスタンスのコピーを作成する場合や、インスタンスを別の環境にコピーする場合は、director のインストールと使用方法の オーバークラウドへの仮想マシンのインポート の手順に従います。
14.2.1. 移行の種別
Red Hat OpenStack Platform (RHOSP) では、以下の移行種別がサポートされています。
コールドマイグレーション
コールドマイグレーション (あるいは、非ライブマイグレーション) では、動作中のインスタンスをシャットダウンしてから、移行元コンピュートノードから移行先コンピュートノードに移行すします。
コールドマイグレーションでは、インスタンスに多少のダウンタイムが発生します。移行したインスタンスは、引き続き同じボリュームおよび IP アドレスにアクセスすることができます。
コールドマイグレーションを行うためには、移行元および移行先両方のコンピュートノードが動作状態になければなりません。
ライブマイグレーション
ライブマイグレーションでは、インスタンスをシャットダウンせずに、動作状態を維持しながら移行元コンピュートノードから移行先コンピュートノードに移行します。
インスタンスのライブマイグレーションを行う場合、ダウンタイムはほとんど発生しません。ただし、ライブマイグレーションは、移行操作中のパフォーマンスに影響を及ぼします。したがって、移行中のインスタンスは重要なパスから除外する必要があります。
ライブマイグレーションは、移動されるワークロードのパフォーマンスに影響を与えます。Red Hat は、ライブマイグレーション中のパケット損失、ネットワーク遅延、メモリー遅延の増加、またはネットワーク帯域幅、メモリー帯域幅、ストレージ IO、または CPU パフォーマンスの低下をサポートしません。
ライブマイグレーションを行うためには、移行元および移行先両方のコンピュートノードが動作状態になければなりません。
状況によっては、インスタンスのライブマイグレーションを行うことができない場合があります。詳細は、移行の制約 を参照してください。
退避
コンピュートノードですでに障害が発生しているためインスタンスを移行する必要がある場合、インスタンスを退避させることができます。
14.2.2. 移行の制約
移行の制約は通常、ブロックマイグレーション、設定ディスク、またはいずれかのインスタンスがコンピュートノード上の物理ハードウェアにアクセスする場合に生じます。
CPU に関する制約
移行元および移行先コンピュートノードの CPU アーキテクチャーは、同一であることが必須です。たとえば、Red Hat では、x86_64
CPU から ppc64le
CPU へのインスタンスの移行をサポートしません。
異なる CPU モデル間の移行はサポートされていません。CPU ホストパススルーを使用するインスタンス等の場合には、移行元および移行先コンピュートノードの CPU は、完全に同一でなければなりません。すべてのケースで、移行先ノードの CPU 機能は、移行元ノードの CPU 機能の上位セットであることが必須です。
メモリーに関する制約
移行先コンピュートノードでは、十分な RAM が利用可能でなければなりません。メモリーのオーバーサブスクリプションが、移行失敗の原因となる可能性があります。
ブロックマイグレーションに関する制約
インスタンスの使用するディスクがコンピュートノード上にローカルに格納されている場合、その移行には、共有ストレージ (Red Hat Ceph Storage 等) を使用するボリュームベースのインスタンスよりもはるかに長い時間がかかります。このレイテンシーは、OpenStack Compute (nova) がコンピュートノード間でローカルディスクをブロックごとに移行するために発生します。この処理は、デフォルトではコントロールプレーンネットワークを通じて行われます。これとは対照的に、Red Hat Ceph Storage 等の共有ストレージを使用するボリュームベースのインスタンスでは、ボリュームを移行する必要がありません。それぞれのコンピュートノードが、共有ストレージにアクセスできるためです。
大量の RAM を消費するローカルディスクまたはインスタンスの移行により、コントロールプレーンネットワークに輻輳が生じ、コントロールプレーンネットワークを使用する他のシステム (RabbitMQ 等) のパフォーマンスに悪影響を及ぼす場合があります。
読み取り専用ドライブの移行に関する制約
ドライブの移行は、ドライブに読み取りおよび書き込み両方の機能がある場合に限りサポートされます。たとえば、OpenStack Compute (nova) は CD-ROM ドライブまたは読み取り専用のコンフィグドライブを移行することはできません。ただし、OpenStack Compute (nova) は、vfat
等のドライブ形式を持つコンフィグドライブなど、読み取りおよび書き込み両方の機能を持つドライブを移行することができます。
ライブマイグレーションに関する制約
インスタンスのライブマイグレーションでは、さらに制約が生じる場合があります。
ライブマイグレーションは、移動されるワークロードのパフォーマンスに影響を与えます。Red Hat は、ライブマイグレーション中のパケット損失、ネットワーク遅延、メモリー遅延の増加、またはネットワーク帯域幅、メモリー帯域幅、ストレージ IO、または CPU パフォーマンスの低下をサポートしません。
- 移行中に新しい操作を行うことができない
- 移行元および移行先ノードのインスタンスのコピー間で状態の整合性を確保するために、RHOSP ではライブマイグレーション中の新規操作を拒否する必要があります。拒否しないと、ライブマイグレーションでメモリーの状態を複製する前にメモリーへの書き込みが行われた場合、ライブマイグレーションに長い時間がかかる状況や、永久に完了しない状況が発生する可能性があります。
- NUMA を使用した CPU ピニング
-
Compute 設定の
NovaSchedulerDefaultFilters
パラメーターには、AggregateInstanceExtraSpecsFilter
およびNUMATopologyFilter
の値が含まれている必要があります。 - マルチセルクラウド
- マルチセルクラウドの場合、同じセル内の異なるホストにインスタンスのライブマイグレーションを行うことはできますが、セルをまたがる移行を行うことはできません。
- フローティングインスタンス
-
フローティングインスタンスのライブマイグレーションを行う場合、移行先コンピュートノードの
NovaComputeCpuSharedSet
の設定と移行元コンピュートノードのNovaComputeCpuSharedSet
の設定が異なると、移行先コンピュートノードでは、インスタンスは共有の (ピニングされていない) インスタンス用に設定された CPU には割り当てられません。したがって、フローティングインスタンスのライブマイグレーションを行う必要がある場合は、専用の (ピニングされた) インスタンスおよび共有の (ピニングされていない) インスタンスに関して、すべてのコンピュートノードに同じ CPU マッピングを設定する必要があります。あるいは、共有のインスタンスにホストアグリゲートを使用します。 - 移行先コンピュートノードの容量
- 移行先コンピュートノードには、移行するインスタンスをホストするのに十分な空き容量が必要です。
- SR-IOV ライブマイグレーション
- SR-IOV ベースのネットワークインターフェイスを使用するインスタンスは、ライブマイグレーションが可能です。ダイレクトモードの SR-IOV ネットワークインターフェイスを持つインスタンスのライブマイグレーションでは、ネットワークのダウンタイムが発生します。これは、移行時に、ダイレクトモードのインターフェイスの接続を解除し再び接続する必要があるためです。
- ML2/OVN デプロイでのパケット損失
ML2/OVN は、パケット損失のないライブマイグレーションをサポートしていません。これは、OVN が複数のポートバインディングを処理できないため、ポートがいつ移行されるかがわからないためです。
ライブマイグレーション中のパケット損失を最小限に抑えるには、移行が完了したら、宛先ホストでインスタンスをアナウンスするように、ML2/OVN デプロイメントを設定します。
parameter_defaults: ComputeExtraConfig: nova::config::nova_config: workarounds/enable_qemu_monitor_announce_self: value: 'True'
- ML2/OVS デプロイメントでのライブマイグレーション
ML2/OVS デプロイメントでインスタンスをライブマイグレーションする場合のパケット損失を最小限に抑えるには、ネットワーキングサービス (neutron) ライブマイグレーションイベントを有効にするように、ML2/OVS デプロイメントを設定し、移行が完了したら、宛先ホストでインスタンスをアナウンスします。
parameter_defaults: NetworkExtraConfig: neutron::config::neutron_config: nova/live_migration_events: value: 'True' ComputeExtraConfig: nova::config::nova_config: workarounds/enable_qemu_monitor_announce_self: value: 'True'
ライブマイグレーションの妨げとなる制約
以下の機能を使用するインスタンスのライブマイグレーションを行うことはできません。
- PCI パススルー
- QEMU/KVM ハイパーバイザーでは、コンピュートノード上の PCI デバイスをインスタンスにアタッチすることができます。PCI パススルーを使用すると、インスタンスは PCI デバイスに排他的にアクセスすることができ、これらのデバイスがインスタンスのオペレーティングシステムに物理的に接続されているかのように表示され、動作します。ただし、PCI パススルーには物理デバイスへの直接アクセスが必要なため、QEMU/KVM は PCI パススルーを使用するインスタンスのライブマイグレーションをサポートしません。
- ポートリソースの要求
最小帯域幅を確保する QoS ポリシーなど、リソース要求が設定されたポートを使用するインスタンスのライブマイグレーションを行うことはできません。ポートにリソース要求があるかどうかを確認するには、以下のコマンドを使用します。
$ openstack port show <port_name/port_id>
14.2.3. 移行の準備
1 つまたは複数のインスタンスを移行する前に、コンピュートノード名および移行するインスタンスの ID を把握する必要があります。
手順
移行元コンピュートノードのホスト名および移行先コンピュートノードのホスト名を特定します。
(undercloud)$ source ~/overcloudrc (overcloud)$ openstack compute service list
移行元コンピュートノード上のインスタンスをリスト表示し、移行するインスタンスの ID を特定します。
(overcloud)$ openstack server list --host <source> --all-projects
<source>
を移行元コンピュートノードの名前または ID に置き換えてください。オプション: ノードのメンテナンスを行うためにインスタンスを移行元コンピュートノードから移行する場合、ノードを無効にして、メンテナンス中にスケジューラーがノードに新規インスタンスを割り当てるのを防ぐ必要があります。
(overcloud)$ source ~/stackrc (undercloud)$ openstack compute service set <source> nova-compute --disable
<source>
を移行元コンピュートノードの名前または ID に置き換えてください。
これで移行を行う準備が整いました。Cold migrating an instance または Live migrating an instance で詳しく説明されている必須手順に従います。
14.2.4. インスタンスのコールドマイグレーション
インスタンスのコールドマイグレーションでは、インスタンスを停止して別のコンピュートノードに移動します。コールドマイグレーションは、PCI パススルーを使用するインスタンスの移行など、ライブマイグレーションでは対応することのできない移行シナリオに対応します。移行先コンピュートノードは、スケジューラーにより自動的に選択されます。詳細は、移行の制約 を参照してください。
手順
インスタンスのコールドマイグレーションを行うには、以下のコマンドを入力してインスタンスの電源をオフにして移動します。
(overcloud)$ openstack server migrate <instance> --wait
-
<instance>
を移行するインスタンスの名前または ID に置き換えてください。 -
ローカルに確保されたボリュームを移行する場合には、
--block-migration
フラグを指定します。
-
- 移行が完了するまで待ちます。インスタンスの移行が完了するのを待つ間、移行のステータスを確認することができます。詳細は、Checking migration status を参照してください。
インスタンスのステータスを確認します。
(overcloud)$ openstack server list --all-projects
ステータスが VERIFY_RESIZE と表示される場合は、移行を確認する、または元に戻す必要があることを示しています。
予想どおりに機能している場合は、移行を確認します。
(overcloud)$ openstack server resize --confirm <instance>
<instance>
を移行するインスタンスの名前または ID に置き換えてください。ステータスが ACTIVE と表示される場合は、インスタンスを使用する準備が整っていることを示しています。予想どおりに機能していない場合は、移行を元に戻します。
(overcloud)$ openstack server resize --revert <instance>
<instance>
をインスタンスの名前または ID に置き換えてください。
インスタンスを再起動します。
(overcloud)$ openstack server start <instance>
<instance>
をインスタンスの名前または ID に置き換えてください。オプション: メンテナンスのために移行元コンピュートノードを無効にした場合は、新規インスタンスがノードに割り当てられるようにノードを再度有効にする必要があります。
(overcloud)$ source ~/stackrc (undercloud)$ openstack compute service set <source> nova-compute --enable
<source>
を移行元コンピュートノードのホスト名に置き換えてください。
14.2.5. インスタンスのライブマイグレーション
ライブマイグレーションでは、ダウンタイムを最小限に抑えて、インスタンスを移行元コンピュートノードから移行先コンピュートノードに移動します。ライブマイグレーションがすべてのインスタンスに適しているとは限りません。詳細は、移行の制約 を参照してください。
手順
インスタンスのライブマイグレーションを行うには、インスタンスおよび移行先コンピュートノードを指定します。
(overcloud)$ openstack server migrate <instance> --live-migration [--host <dest>] --wait
-
<instance>
をインスタンスの名前または ID に置き換えてください。 <dest>
を移行先コンピュートノードの名前または ID に置き換えてください。注記openstack server migrate
コマンドは、共有ストレージを持つインスタンスの移行が対象です。これがデフォルトの設定です。ローカルに確保されたボリュームを移行するには、--block-migration
フラグを指定します。(overcloud)$ openstack server migrate <instance> --live-migration [--host <dest>] --wait --block-migration
-
インスタンスが移行されていることを確認します。
(overcloud)$ openstack server show <instance> +----------------------+--------------------------------------+ | Field | Value | +----------------------+--------------------------------------+ | ... | ... | | status | MIGRATING | | ... | ... | +----------------------+--------------------------------------+
- 移行が完了するまで待ちます。インスタンスの移行が完了するのを待つ間、移行のステータスを確認することができます。詳細は、Checking migration status を参照してください。
インスタンスのステータスをチェックして、移行が成功したかどうかを確認します。
(overcloud)$ openstack server list --host <dest> --all-projects
<dest>
を移行先コンピュートノードの名前または ID に置き換えてください。オプション: メンテナンスのために移行元コンピュートノードを無効にした場合は、新規インスタンスがノードに割り当てられるようにノードを再度有効にする必要があります。
(overcloud)$ source ~/stackrc (undercloud)$ openstack compute service set <source> nova-compute --enable
<source>
を移行元コンピュートノードのホスト名に置き換えてください。
14.2.6. 移行ステータスの確認
移行が完了するまでに、さまざまな移行状態を遷移します。正常な移行では、通常、移行状態は以下のように遷移します。
- Queued: Compute サービスはインスタンス移行の要求を受け入れ、移行は保留中です。
- Preparing: Compute サービスはインスタンス移行の準備中です。
- Running: Compute サービスはインスタンスを移行中です。
- Post-migrating: Compute サービスはインスタンスを移行先コンピュートノードにビルドし、移行元コンピュートノードのリソースを解放しています。
- Completed: Compute サービスはインスタンスの移行を完了し、移行元コンピュートノードのリソース解放を終了しています。
手順
インスタンスの移行 ID のリストを取得します。
$ nova server-migration-list <instance> +----+-------------+----------- (...) | Id | Source Node | Dest Node | (...) +----+-------------+-----------+ (...) | 2 | - | - | (...) +----+-------------+-----------+ (...)
<instance>
をインスタンスの名前または ID に置き換えてください。移行のステータスを表示します。
$ nova server-migration-show <instance> <migration_id>
-
<instance>
をインスタンスの名前または ID に置き換えてください。 <migration_id>
を移行の ID に置き換えてください。nova server-migration-show
コマンドを実行すると、以下の例に示すような出力が返されます。+------------------------+--------------------------------------+ | Property | Value | +------------------------+--------------------------------------+ | created_at | 2017-03-08T02:53:06.000000 | | dest_compute | controller | | dest_host | - | | dest_node | - | | disk_processed_bytes | 0 | | disk_remaining_bytes | 0 | | disk_total_bytes | 0 | | id | 2 | | memory_processed_bytes | 65502513 | | memory_remaining_bytes | 786427904 | | memory_total_bytes | 1091379200 | | server_uuid | d1df1b5a-70c4-4fed-98b7-423362f2c47c | | source_compute | compute2 | | source_node | - | | status | running | | updated_at | 2017-03-08T02:53:47.000000 | +------------------------+--------------------------------------+
ヒントOpenStack Compute サービスは、コピーする残りのメモリーのバイト数によって移行の進捗を測定します。時間が経過してもこの数字が減少しない場合、移行を完了することができず、Compute サービスは移行を中止する可能性があります。
-
インスタンスの移行に長い時間がかったり、エラーが発生したりする場合があります。詳細は、Troubleshooting migration を参照してください。
14.2.7. インスタンスの退避
インスタンスを障害の発生したコンピュートノードまたはシャットダウンしたコンピュートノードから同じ環境内の新しいホストに移動する場合、インスタンスを退避させることができます。
退避プロセスにより元のインスタンスは破棄され、元のイメージ、インスタンス名、UUID、ネットワークアドレス、およびインスタンスに割り当てられていたその他すべてのリソースを使用して、別のコンピュートノードに元のインスタンスが再ビルドされます。
インスタンスが共有ストレージを使用する場合、インスタンスのルートディスクは退避プロセス中に再ビルドされません。移行先コンピュートノードが引き続きこのディスクにアクセス可能なためです。インスタンスが共有ストレージを使用しない場合は、インスタンスのルートディスクも移行先コンピュートノードに再ビルドされます。
-
コンピュートノードがフェンシングされ、API が報告するコンピュートノードの状態が down または forced-down である場合に限り、退避を行うことができます。コンピュートノードが down または forced-down と報告されない場合、
evacuate
コマンドは失敗します。 - クラウド管理者でなければ、退避を行うことはできません。
14.2.7.1. 単一のインスタンスの退避
インスタンスを一度に 1 つずつ退避させることができます。
手順
- 障害の発生したコンピュートノードに管理者としてログインします。
コンピュートノードを無効にします。
(overcloud)[stack@director ~]$ openstack compute service set \ <host> <service> --disable
-
<host>
をインスタンスの退避元となるコンピュートノードの名前に置き換えてください。 -
<service>
を無効にするサービスの名前 (例:nova-compute
) に置き換えてください。
-
インスタンスを退避させるには、以下のコマンドを入力します。
(overcloud)[stack@director ~]$ nova evacuate [--password <pass>] <instance> [<dest>]
-
<pass>
を退避するインスタンスに設定する admin パスワードに置き換えてください。パスワードを指定しなかった場合には、無作為に生成され、退避の完了時に出力されます。 -
<instance>
を退避させるインスタンスの名前または ID に置き換えてください。 <dest>
をインスタンスの退避先となるコンピュートノードの名前に置き換えてください。退避先コンピュートノードを指定しなかった場合には、Compute のスケジューラーがノードを選択します。退避先に指定可能なコンピュートノードを確認するには、以下のコマンドを使用します。(overcloud)[stack@director ~]$ openstack hypervisor list
-
14.2.7.2. ホスト上の全インスタンスの退避
指定したコンピュートノード上の全インスタンスを退避させることができます。
手順
- 障害の発生したコンピュートノードに管理者としてログインします。
コンピュートノードを無効にします。
(overcloud)[stack@director ~]$ openstack compute service set \ <host> <service> --disable
-
<host>
をインスタンスの退避元となるコンピュートノードの名前に置き換えてください。 -
<service>
を無効にするサービスの名前 (例:nova-compute
) に置き換えてください。
-
指定したコンピュートノード上の全インスタンスを退避させます。
(overcloud)[stack@director ~]$ nova host-evacuate [--target_host <dest>] <host>
<dest>
をインスタンスの退避先となるコンピュートノードの名前に置き換えてください。退避先を指定しなかった場合には、Compute のスケジューラーがノードを選択します。退避先に指定可能なコンピュートノードを確認するには、以下のコマンドを使用します。(overcloud)[stack@director ~]$ openstack hypervisor list
-
<host>
をインスタンスの退避元となるコンピュートノードの名前に置き換えてください。
14.2.8. 移行に関するトラブルシューティング
インスタンスの移行時に、以下の問題が発生する可能性があります。
- 移行プロセスでエラーが生じる。
- 移行プロセスが終了しない。
- 移行後にインスタンスのパフォーマンスが低下する。
14.2.8.1. 移行中のエラー
以下の問題が発生すると、移行操作が error
状態に遷移します。
- 実行しているクラスターに異なるバージョンの Red Hat OpenStack Platform (RHOSP) が存在する。
- 指定したインスタンス ID が見つからない。
-
移行を試みているインスタンスが
error
状態にある。 - Compute サービスが停止している。
- 競合状態が発生する。
-
ライブマイグレーションが
failed
状態に移行する。
ライブマイグレーションが failed
状態に移行すると、通常は error
状態になります。failed
状態の原因となる可能性のある典型的な問題を以下に示します。
- 移行先コンピュートホストが利用可能な状態にない。
- スケジューラーの例外が発生する。
- コンピューティングリソースが不十分なため、再ビルドプロセスに失敗する。
- サーバーグループの確認に失敗する。
- 移行先コンピュートノードへの移行が完了する前に、移行元コンピュートノードのインスタンスが削除される。
14.2.8.2. ライブマイグレーションのスタック
ライブマイグレーションが完了せず、永久に running
状態のままになる可能性があります。ライブマイグレーションが永久に完了しない一般的な理由は、Compute サービスがインスタンスの変更を移行先コンピュートノードに複製するより早く、クライアントのリクエストにより移行元コンピュートノード上で実行中のインスタンスに変更が生じることです。
この状況に対処するには、以下のいずれかの方法を使用します。
- ライブマイグレーションを中止する。
- ライブマイグレーションを強制的に完了させる。
ライブマイグレーションの中止
移行プロセスがインスタンスの状態の変化を移行先ノードにコピーするより早くインスタンスの状態が変化する状況で、インスタンスの動作を一時的に中断したくない場合には、ライブマイグレーションを中止することができます。
手順
インスタンスの移行のリストを取得します。
$ nova server-migration-list <instance>
<instance>
をインスタンスの名前または ID に置き換えてください。ライブマイグレーションを中止します。
$ nova live-migration-abort <instance> <migration_id>
-
<instance>
をインスタンスの名前または ID に置き換えてください。 -
<migration_id>
を移行の ID に置き換えてください。
-
ライブマイグレーション完了の強制
移行プロセスがインスタンスの状態の変化を移行先ノードにコピーするより早くインスタンスの状態が変化する状況で、インスタンスの動作を一時的に中断して移行を強制的に完了させたい場合には、ライブマイグレーションの手順を強制的に完了させることができます。
ライブマイグレーションを強制的に完了させると、かなりのダウンタイムが発生する可能性があります。
手順
インスタンスの移行のリストを取得します。
$ nova server-migration-list <instance>
<instance>
をインスタンスの名前または ID に置き換えてください。ライブマイグレーションを強制的に完了させます。
$ nova live-migration-force-complete <instance> <migration_id>
-
<instance>
をインスタンスの名前または ID に置き換えてください。 -
<migration_id>
を移行の ID に置き換えてください。
-
14.2.8.3. 移行後のインスタンスパフォーマンスの低下
NUMA トポロジーを使用するインスタンスの場合、移行元および移行先コンピュートノードの NUMA トポロジーおよび設定は同一でなければなりません。移行先コンピュートノードの NUMA トポロジーでは、十分なリソースが利用可能でなければなりません。移行元および移行先コンピュートノード間で NUMA 設定が同一でない場合、ライブマイグレーションは成功するがインスタンスのパフォーマンスが低下する可能性があります。たとえば、移行元コンピュートノードは NIC 1 を NUMA ノード 0 にマッピングするが、移行先コンピュートノードは NIC 1 を NUMA ノード 5 にマッピングする場合、移行後にインスタンスはバス内の最初の CPU からのネットワークトラフィックを NUMA ノード 5 の別の CPU にルーティングし、トラフィックを NIC 1 にルーティングする可能性があります。その結果、予想されたとおりに動作はしますが、パフォーマンスが低下します。同様に、移行元コンピュートノードの NUMA ノード 0 では十分な CPU および RAM が利用可能だが、移行先コンピュートノードの NUMA ノード 0 にリソースの一部を使用するインスタンスがすでに存在する場合、インスタンスは正しく動作するがパフォーマンスが低下する可能性があります。詳細は、移行の制約 を参照してください。