第1章 ライブインスタンスの移行方法
本項には、共有ストレージまたはブロックベースの移行を使用してライブ (実行中) インスタンスを移行する方法について記載します。ライブマイグレーションは、ダウンタイムがほぼないため、実稼動環境に有用です。
本項の手順では、コントローラーノード 1 つと、コンピュートノード 2 つを使用し、この 2 つのコンピュートノード間でインスタンスを移行します。
1.1. 前提条件
Red Hat OpenStack Platform は、2 種類のライブマイグレーションをサポートします。それぞれに独自の要件があります。
- 共有ストレージ
- 共有ストレージの場合には、インスタンスは両コンピュートノードからアクセス可能なストレージを使用して移行されます。移行元/移行先のハイパーバイザーのいずれにおいても、ストレージには、分散ファイルシステムを使用する必要があります (例: NFS または Red Hat Storage)。OpenStack Block Storage ボリューム (ボリュームベースのインスタンス) も共有ストレージを使用することができます。以下の手順では、NFS 共有ストレージを設定するステップを説明します。
- ブロックベース
- ブロックベースの移行は、移行元のホストから移行先に仮想マシンのイメージ全体を移動するため、所要時間が長くなりますが、この種類の移行ではバックエンドの分散ファイルシステムは必要ありません。各コンピュートノードの設定の際には、各ノードがホストするインスタンスを格納するのに十分なディスクを使用する必要があります。
現在、CPU ピニングを使用するように設定されているインスタンスは移行できません。この問題に関する詳しい情報は、「Instance migration fails when using cpu-pinning from a numa-cell and flavor-property "hw:cpu_policy=dedicated"」のソリューションを参照してください。
1.1.1. 一般要件
両タイプの移行における一般的な要件は以下のとおりです。
管理者として、クラウド環境にコマンドラインからアクセスできること (以下の手順はすべてコマンドラインで実行します)。各種コマンドを実行するには、まずユーザーの認証変数を読み込みます。
# source ~/keystonerc_admin
- 移行元/移行先の両ノードは、同じサブネットに配置され、同じプロセッサータイプを使用する必要があります。
- コンピュートサーバー (コントローラーおよびノード) はすべて、相互で名前を解決できる必要があります。
- Compute サービスおよび libvirt ユーザーの UID および GID はコンピュートノード間で同一でなければなりません。
- コンピュートノードでは、libvirt と KVM を使用する必要があります。
1.1.2. マルチパス機能の要件
マルチパス機能が設定されたインスタンスを移行する場合は、移行元と移行先のノードでマルチパスデバイスの名前が同じである必要があります。移行先のノードで、インスタンスがマルチパスデバイスの名前を解決できない場合には、移行が失敗します。
移行元ノードと移行先ノードの両方でデバイス WWID の使用を強制することで、一貫性のあるマルチパスデバイス名を指定することができます。これには、移行先/移行元の両ノードで以下のコマンドを実行して ユーザーフレンドリーな名前 を無効にし、multipathd
を再起動する必要があります。
# mpathconf --enable --user_friendly_names n # systemctl restart multipathd
詳しい情報は、『DM Multipath ガイド』の「クラスター内では整合性のあるマルチパスデバイス名を維持する」を参照してください。
1.2. 移行の設定
以下の設定を行ってから、ライブインスタンスを移行するようにしてください。
- ノード間で libvirt がセキュアに送信できることを確認します。
- 共有ストレージを使用している場合は、全ノードへのアクセスと共有ストレージを設定します。
- ブロックベースの移行を使用する場合は、全ノードへのアクセスとローカルディレクトリーを設定します。
1.2.1. セキュアな Libvirt の設定
TCP 呼び出しを使用して、移行を行います。libvirt を正しく設定することで、ノード間の TCP 経由のリモート呼び出しをセキュアに行うことができます。ただし、これには複数の方法があり、細心の注意を払って行う必要があります。
通常ライブマイグレーションに使用される TCP 経由でのリモートアクセスには、3 つのセキュアなオプションがあります。以下の設定の libvirtd TCP ソケットを使用します。
- 暗号化には TLS、認証には X.509 クライアント証明書
- 認証および暗号化には GSSAPI/Kerberos
- 暗号化には TLS、認証には Kerberos
SSH トンネリングも可能ですが、通常、静的 (コールド) マイグレーションにのみ使用されます。
環境内の全コンピュートノードで以下の手順を行います。
- 適切なストラテジーを決定して、その設定を行う際には、ネットワーク管理者に問い合わせてください (『Red Hat Enterprise Linux 7 仮想化の導入および管理ガイド』の libvirt のドキュメントも参照してください)。
ストラテジーに応じて、
/etc/libvirt/libvirtd.conf
ファイルの以下のパラメーターを更新してください。暗号化には TLS、認証には X.509 クライアント証明書
listen_tls = 1 listen_tcp = 0 auth_tls = "none" tls_no_verify_certificate = 0 tls_allowed_dn_list = ["distinguished name pattern"]
distinguished name pattern は、サーバー向けに発行した証明書と一致する 1 つまたは複数のパターンに置き換えます (例:
C=GB,ST=London,L=London,O=Red Hat,CN=*
)。複数の識別名パターンを指定する場合には、コンマで区切ります。詳しい情報は、「TLS と SSL 経由のリモート管理」を参照してください。認証および暗号化には GSSAPI/Kerberos
listen_tls = 0 listen_tcp = 1 auth_tcp = "sasl" sasl_allowed_username_list = ["Kerberos principal name pattern"]
Kerberos principal name pattern は、サーバー向けに発行した Kerberos チケットと一致するパターンに置き換えます (例:
libvirt/*.example.com@EXAMPLE.COM
)。詳しい情報は「Using Kerberos」を参照してください。暗号化には TLS、認証には Kerberos
listen_tls = 1 listen_tcp = 0 auth_tls = "sasl" sasl_allowed_username_list = ["Kerberos principal name pattern"]
同様に、Kerberos principal name pattern は、サーバー向けに発行した Kerberos チケットと一致するパターンに置き換えます。
/etc/sysconfig/libvirtd
ファイルを編集して、以下の行を追記します。LIBVIRTD_ARGS="--listen"
決定したストラテジーに合わせて、
/etc/nova/nova.conf
のアクセス URI の文字列を更新します。live_migration_uri=qemu+ACCESSTYPE://USER@%s/system
ここで、
- ACCESSTYPE は
tcp
(暗号化なし) またはtls
(暗号化あり) に指定することができます。 USER はコンピュートのユーザーを指定します (ファイルパーミッションが適切に設定されるようにします)。問題が発生した場合は、'%s' (
root
ユーザーにデフォルト設定) のみを使用してみてください。例: TLS の使用live_migration_uri=qemu+tls://nova@%s/system
- ACCESSTYPE は
設定が完了したら libvirt を再起動します。
# systemctl restart libvirtd.service
1.2.3. ブロック移行の設定
ブロック移行を行う場合は、共有ストレージを使用できませんが、各種サービスがリモート通信用に設定されており、ローカルの /instances
のディレクトリーに正しいパーミッションが設定されている必要があります。
以下の手順では、デフォルトのディレクトリーパス /var/lib/nova/instances
を使用します。
各コンピュートノードで以下を実行します。
必要なリモートパッケージをインストールします (インストール済みでない場合)。
# yum install iptables openstack-utils openstack-nova-novncproxy -y
インスタンスに使用するディレクトリーを作成します (作成済みでない場合)。
# mkdir -p /var/lib/nova/instances
以下を
/etc/group
ファイルに追加します。nova:x:162:nova
以下を
/etc/passwd
ファイルに追加します。nova:x:162:162:OpenStack Nova Daemons:/var/lib/nova:/sbin/nologin
ディレクトリーのパーミッションを変更します。
# chown nova:nova /var/lib/nova/instances;chmod 775 /var/lib/nova/instances
ファイアウォールおよびネットワークトラフィックを設定します。libvirt がノード間で通信できるように、ファイアウォールを設定する必要があります (TCP は 16509、TLS は 16514)。可能であれば、お使いのコンピュートノードだけに、ポートへのリモートアクセスを制限します。トンネリングを使用しない限り、エフェメラルポート (49152 から 49215) も開放する必要があります。
例: TCP の使用# iptables -v -I INPUT 1 -p tcp --dport 16509 -j ACCEPT # iptables -v -I INPUT 1 -p tcp --dport 16514 -j ACCEPT # iptables -v -I INPUT -p tcp --dport 49152:49261 -j ACCEPT
ノードでインスタンスディレクトリーを表示できることを確認します。
# ls -ld /var/lib/nova/instances drwxrwxr-x. 9 nova nova 4096 Nov 5 20:37 /var/lib/nova/instances
/etc/libvirt/qemu.conf
ファイルで、qemu
設定を更新します。user="root" group="root" vnc_listen="0.0.0.0"
libvirtd
サービスを再起動して、qemu
設定の変更が反映されるようにします。# systemctl restart libvirtd
Compute サービスの設定を更新します。
# openstack-config --set /etc/nova/nova.conf DEFAULT instances_path /var/lib/nova/instances # openstack-config --set /etc/nova/nova.conf DEFAULT novncproxy_base_url http://10.64.15.100:6080/vnc_auto.html # openstack-config --set /etc/nova/nova.conf DEFAULT vncserver_listen 0.0.0.0 # openstack-config --set /etc/nova/nova.conf DEFAULT block_migration_flag VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE,VIR_MIGRATE_NON_SHARED_INC
サービスを再起動します。
# systemctl restart iptables.service; # openstack-service restart
コントローラーホスト上で以下を実行します。
OpenStack パッケージをインストールします。
# yum install openstack-utils openstack-nova-novncproxy -y
Compute 設定を更新して、サービスを再起動します。
# openstack-config --set /etc/nova/nova.conf DEFAULT vncserver_listen 0.0.0.0 # openstack-service restart
1.3. ライブインスタンスの移行
インスタンスの一覧を表示して、対象のインスタンスが表示されていることを確認します。
# nova list
どのノードでインスタンスが実行されているかを確認します。
# nova show DemoInstance +--------------------------------------+-----------------------------------+ | Property | Value | +--------------------------------------+-----------------------------------+ | ... | | | OS-EXT-SRV-ATTR:host | OpenStack2 | | OS-EXT-SRV-ATTR:hypervisor_hostname | OpenStack2 | | ... | |
利用可能な移行先ノードの一覧を表示します。
# nova service-list +------------------+------------+----------+---------+-------+- | Binary | Host | Zone | Status | State | +------------------+------------+----------+---------+-------+- | nova-compute | OpenStack2 | nova | enabled | up | | nova-compute | OpenStack3 | nova | enabled | up | | ... | | | | |
移行先を選択して、十分なリソースがあることを確認します。
# nova host-describe OpenStack3 +------------+------------------------------+-----+-----------+---------+ | HOST | PROJECT | cpu | memory_mb | disk_gb | +------------+------------------------------+-----+-----------+---------+ | OpenStack3 | (total) | 4 | 7707 | 49 | | OpenStack3 | (used_now) | 0 | 512 | 0 | | OpenStack3 | (used_max) | 0 | 0 | 0 | +------------+------------------------------+-----+-----------+---------+
インスタンスを移行します。
- 共有ストレージでの移行
# nova live-migration DemoInstance OpenStack3
- ブロックとしての移行
# nova live-migration --block-migrate DemoInstance OpenStack3
警告インスタンスの移行は、使用率が低い時に行うようにしてください。ゲストオペレーティングシステムがディスク上のブロックに書き込む速度が、ブロックの移行速度よりも早い場合には、移行は完了されません。
インスタンスのホストをチェックして、移行が完了したかどうかを確認します。
# nova show DemoInstance +--------------------------------------+------------------------------------------------+ | Property | Value | +--------------------------------------+------------------------------------------------+ | OS-DCF:diskConfig | AUTO | | OS-EXT-AZ:availability_zone | nova | | OS-EXT-SRV-ATTR:host | OpenStack3 | | OS-EXT-SRV-ATTR:hypervisor_hostname | OpenStack3 | ....
注記トラブルシューティングを行うには、(移行元/移行先両方で)
/var/log/nova/
にある以下のログファイルを参照してください。nova-api.log
nova-compute.log
nova-conductor.log
nova-scheduler.log
1.4. ライブマイグレーションの制限事項
ライブマイグレーションの準備および実行時に考慮すべき制限事項が複数あります。
- ライブマイグレーションを実行中の仮想マシンでの操作はできません。
ただし、ソースのコンピュートノードでは
virsh
を使用して、以下のような仮想マシンとの対話は可能です。ライブマイグレーションの現在の状況を表示します。
# virsh domjobinfo domain Time elapsed 110110 ms Data processed 100.500 GiB Data remaining 25.500 GiB ...[output truncated]...
domain は、名前、移行元の仮想マシンに割り当てられた数字 ID または UUID に置き換えます。
移行をキャンセルします。
# virsh domjobabort domain
仮想マシンを一時停止します。
# virsh suspend domain
- メモリーの負荷が大きい仮想マシンをライブマイグレーションするのは困難です。
- 最大ダウンタイム (ミリ秒単位) を設定します。ライブマイグレーションに対してダウンタイムを設定するには、libvirt を使用します。
# virsh migrate-setmaxdowntime domain time_in_milliseconds
QEMU によりライブマイグレーションが進行中でないと判断された場合に、自動的にメモリーの書き込み速度を 25% まで落とします。この設定には、
live_migration_flag
オプションの引数の中にVIR_MIGRATE_AUTO_CONVERGE
を含めてください。以下のコマンドを実行してこのオプションがアンコメントして、この引数を更新します。# sed -i 's/^#live_migration_flag/live_migration_flag/' /etc/nova/nova.conf # openstack-config --list --set /etc/nova/nova.conf libvirt live_migration_flag VIR_MIGRATE_AUTO_CONVERGE
- ライブマイグレーションにより、過剰なネットワークトラフィックが発生します。
ライブマイグレーションがフルスピードで実行されると、メッセージキューなど、同じネットワーク上のサービスに悪影響を及ぼす可能性があります。最大速度を下げて設定するには、以下のコマンドを使用します。
# virsh migrate-setspeed domain speed_in_MBps
または、事前に任意の速度 (MBps 単位) で設定してください。以下に例を示します。
# openstack-config --set /etc/nova/nova.conf libvirt live_migration_bandwidth 50
他にネットワークトラフィック軽減するには、送信ページと更新ページの差分のみを取り、移行先に圧縮を適用する XBZRLE 圧縮を使用する方法があります。この機能を有効にするには、
live_migration_flag
の引数にVIR_MIGRATE_COMPRESSED
を含めるようにしてください。今回も、このオプションは必ずコメント解除してください。以下のコマンドを実行して、設定を行います。# sed -i 's/^#live_migration_flag/live_migration_flag/' /etc/nova/nova.conf # openstack-config --list --set /etc/nova/nova.conf libvirt live_migration_flag VIR_MIGRATE_COMPRESSED
最後に、ライブマイグレーション専用のネットワークを使用するのも 1 つのオプションです。このソリューションを採用する場合には、まず以下のコマンドを実行して、
live_migration_uri
オプション内のホスト名のテンプレートに-lm
サフィックスを追加します。# openstack-config --set /etc/nova/nova.conf libvirt live_migration_uri qemu+tcp://nova@%s-lm/system
次に、DNS サーバーにより、このサフィックスが追加されたホスト名が、専用ネットワークの IP アドレスに対して解決されていることを確認します。
- デフォルトでは、ターゲットノードがサポートする CPU 命令がソースノードより少ない場合には、ライブマイグレーションは実行できません。
このようなターゲットに対してライブマイグレーションを実行する必要がある場合には、
/etc/nova/nova.conf
ファイルの以下のオプションを使用します。cpu_mode = custom cpu_model = model
model は、
/usr/share/libvirt/cpu_map.xml
ファイルで定義された、対応の CPU モデルの 1 つに置き換えます。- ライブマイグレーションでは、メモリーのオーバーサブスクリプションは使用しません。
- スケジューラーは、コンピューターノードから報告されたメモリー量を
ram_allocation_ratio
で乗算します。たとえば、メモリー量が 2 GB で、ram_allocation_ratio
が2
に設定されている場合は、スケジューラーは、メモリーが 4 GB と報告してしまいます。この問題を軽減するには、コンピュートノード自体に使用可能なメモリー量を定義する、reserved_host_memory_mb
を負の値に設定します。これにより、この値は使用可能なメモリーから減算されるため、コンピュートノードは実際の空きメモリーよりも多い量を報告し、スケジューラーとコンダクターはどれだけのメモリーオーバーサブスクリプションを使用するのかが分かります。
Comments