インスタンスの移行
OpenStack 環境のハイパーバイザー間でのインスタンスの移行
法律上の通知
概要
前書き
本書では、ライブ (稼働中) または静的な (保存状態) インスタンスを 2 つのハイパーバイザー間で移行する手順を説明します。
第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
を負の値に設定します。これにより、この値は使用可能なメモリーから減算されるため、コンピュートノードは実際の空きメモリーよりも多い量を報告し、スケジューラーとコンダクターはどれだけのメモリーオーバーサブスクリプションを使用するのかが分かります。
第2章 静的インスタンスの移行方法
本項には、静的なインスタンス (稼働していないインスタンス) を同じ OpenStack クラウド内にあるハイパーバイザー間、または複数の OpenStack 環境 (プロジェクト) 間で移行する手順について記載します。
2.1. 前提条件
- コマンドラインでクラウド環境へアクセスできること。移行手順のすべてを Dashboard で実行できないため、本記事での手順はすべてコマンドラインで実行します。
ユーザーおよびパスワードの情報 (管理者ユーザーまたはインスタンスのプロジェクトへのアクセス権があるエンドユーザーのいずれか)。コマンドを実行するためには、まずユーザーの認証情報の変数を読み込む必要があります。以下に例を示します。
# source ~/keystonerc_admin
デフォルトの Red Hat OpenStack Platform 設定では、エンドユーザーによるインスタンスの移行が可能です。ただし、クラウド管理者がこの設定を変更して、管理者ユーザーしかインスタンスの移行ができないようにしている可能性があります。
現在、CPU ピニングを使用するように設定されているインスタンスは移行できません。この問題に関する詳しい情報は、「Instance migration fails when using cpu-pinning from a numa-cell and flavor-property "hw:cpu_policy=dedicated"」のソリューションを参照してください。
2.2. 環境またはプロジェクト間の移行
スナップショットとは、インスタンスの特定の状態をキャプチャーしたイメージのことです。異なる OpenStack 環境間、または同じ環境内のプロジェクト間でインスタンスを移行するために、スナップショットを使用することができます。
スナップショットは、同じプロジェクト内に新規インスタンスを作成するためにテンプレートとして使用することも可能です。この操作ではスナップショットをダウンロードする必要がないため、Dashboard の プロジェクト > コンピュート > インスタンス
を使用してください。
-
インスタンスが停止している場合は、
下向きの三角印をクリックしてスナップショットの作成
を選択します。 -
インスタンスが実行中の場合は、
スナップショットの作成
をクリックします。
作成したイメージは新規インスタンスのベースとして使用することができます。
スナップショットを作成します。
インスタンスの一覧を表示して、対象のインスタンスが表示されていることを確認します。
# nova list +--------------------------------------+--------------+--------+------------+-------------+--------------------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+--------------+--------+------------+-------------+--------------------------------+ | 39e9be81-a4b9-4158-a066-0e8d32e1698a | DemoInstance | ACTIVE | - | Running | private=10.0.0.7, 10.64.19.198 | +--------------------------------------+--------------+--------+------------+-------------+--------------------------------+
注記インスタンスをシャットダウンする必要はありません。Compute サービスにより、スナップショットの作成前に、全データが確実にフラッシュされます。
スナップショットを作成します。以下のコマンドでは、DemoInstance-Snap が新規スナップショットの名前です。
# nova image-create DemoInstance DemoInstance-Snap
このスナップショットは、自動的にユーザーのプロジェクトに割り当てられます。
Image サービスクライアントを使用して、作成したスナップショットを表示します。
# glance image-list +--------------------------------------+-----------------------+-------------+------------------+-----------+--------+ | ID | Name | Disk Format | Container Format | Size | Status | +--------------------------------------+-----------------------+-------------+------------------+-----------+--------+ | 68509457-38e5-4ddc-b599-fd91ad90d0c6 | cirros | qcow2 | bare | 13147648 | active | | 36c8c18e-8af8-4e9c-bb61-2393d2df365e | RHEL6.5-Guest | qcow2 | bare | 320798720 | active | | aa058b81-812f-40bc-90c1-84e8809647c7 | DemoInstance-Snap | qcow2 | bare | 19595264 | active | +--------------------------------------+-----------------------+-------------+------------------+-----------+--------+
イメージ ID を使用してスナップショットをダウンロードします。新規ファイルには、どのような名前でも使用できます。
# glance image-download --file DemoInstance-Snap.qcow2 DemoInstance-Snap
スナップショットをインポートします。
- 新規ファイルを新規ホストにコピーします。
新しいクラウド環境またはプロジェクトで、スナップショットを使用して新規イメージを作成します。
# glance image-create --file ./DemoInstance-Snap.qcow2 --name DemoInstance-Image --container-format bare --disk-format qcow2 --is-public True +------------------+--------------------------------------+ | Property | Value | +------------------+--------------------------------------+ | checksum | c9594641975e9c21297c6eb55ed1781f | | container_format | bare | | created_at | 2014-11-03T01:01:15 | | deleted | False | | deleted_at | None | | disk_format | qcow2 | | id | ed8db035-0bd1-4ada-a122-ba4c1cb9a550 | | is_public | True | | min_disk | 0 | | min_ram | 0 | | name | DemoInstance-Image | | owner | 50e7c00643d44ec3b6c7d191b9c7e180 | | protected | False | | size | 19070976 | | status | active | | updated_at | 2014-11-03T01:01:15 | | virtual_size | None | +------------------+--------------------------------------+
インスタンスの割り当てが可能なプライベートネットワークを特定します。アクセス可能なネットワークは、クラウドの環境やユーザーのパーミッションにより異なります。アクセス可能なネットワークをすべて表示するには、以下のコマンドを実行します。
# neutron net-list
新規作成したイメージを使用して、新しいインスタンスを起動します。
# nova boot --flavor m1.small --image DemoInstance-Image --nic net-id=myNET myMigratedInstance +--------------------------------------+----------------------------------------------+ | Property | Value | +--------------------------------------+----------------------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | nova | | OS-EXT-SRV-ATTR:host | - | | OS-EXT-SRV-ATTR:hypervisor_hostname | - | | OS-EXT-SRV-ATTR:instance_name | instance-00000017 | | OS-EXT-STS:power_state | 0 | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | - | | OS-SRV-USG:terminated_at | - | | accessIPv4 | | | accessIPv6 | | | adminPass | fsAwVTNB4wiP | | config_drive | | | created | 2014-11-03T01:07:10Z | | flavor | m1.small (2) | | hostId | | | id | 7d904177-b208-489c-a95c-cb06401f207a | | image | DemoInstance-Image (ed8db035-0bd1-4ada-a122-ba4c1cb9a550) | | key_name | - | | metadata | {} | | name | myMigratedInstance | | os-extended-volumes:volumes_attached | [] | | progress | 0 | | security_groups | default | | status | BUILD | | tenant_id | 50e7c00643d44ec3b6c7d191b9c7e180 | | updated | 2014-11-03T01:07:10Z | | user_id | f0d5c7a4683a462a9946705f671be463 | +--------------------------------------+----------------------------------------------+
注記新規インスタンスには、イメージのオペレーティングシステムとデータをサポートするのに十分なストレージとメモリーが設定されたフレーバーを割り当てる必要があります。Red Hat Enterprise Linux ゲストイメージには、少なくとも m1.small が必要です。フレーバーの値を表示するには、以下のコマンドを実行します。
# nova flavor-list
Compute の一覧でインスタンスを確認します。
# nova list +--------------------------------------+--------------------+---------+------------+-------------+----------------------------------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+--------------------+---------+------------+-------------+----------------------------------------------+ | 7d904177-b208-489c-a95c-cb06401f207a | myMigratedInstance | ACTIVE | - | Running | private_network=192.168.200.19 | +--------------------------------------+--------------------+---------+------------+-------------+----------------------------------------------+
2.3. ハイパーバイザー間の移行
同じ OpenStack 環境内のコンピュートノード間で、インスタンスを移動する場合には、単に nova migrate
というコマンドを SSH 設定と合わせて使用するだけで、ノードの通信を確保できます。
2.3.1. ノード間の SSH トンネリングの設定
Red Hat では、特定の libvirt セキュリティー戦略は推奨していません。SSH トンネリングのステップは、ユーザー向けの参考情報としてのみ記載しています。SSH トンネリングを設定できるのは root アクセスのあるユーザーのみとなります。
SSH トンネリングを使用してノード間でインスタンスを移行する場合、または分散環境でインスタンスをリサイズする場合には、各ノードに SSH 鍵認証を設定し、Compute サービスが SSH を使用してディスクを他のノードに移動できるようにする必要があります。たとえば、複数のコンピュートノードで同じ SSH 鍵を使用して通信可能な状態を確保することが可能です。
Compute サービスが異なるノード間でインスタンスを移行できない場合には、そのインスタンスを元のホストに送り返すように試みます。このような移行の失敗を回避するには、/etc/nova/nova.conf
ファイルで「allow_migrate_to_same_host=True」と設定されていることを確認してください。
コンピュートノード間でのキーペアの共有方法:
両ノード上で root として、nova をログインユーザーに設定します。
# usermod -s /bin/bash nova
最初の Compute ノードで
nova
ユーザーのキーペアを生成します。# su nova $ ssh-keygen $ echo 'StrictHostKeyChecking no' >> /var/lib/nova/.ssh/config $ cat /var/lib/nova/.ssh/id_rsa.pub >> /var/lib/nova/.ssh/authorized_keys $ exit
id_rsa
とid_rsa.pub
のキーペアが/var/lib/nova/.ssh
内に生成されます。root として、2 番目のコンピュートノードに作成したキーペアをコピーします。
# scp /var/lib/nova/.ssh/id_rsa computeNodeAddress:~/ # scp /var/lib/nova/.ssh/id_rsa.pub computeNodeAddress:~/
2 番目のコンピュートノードで、root として、コピーしたキーペアのパーミッションを
nova
に戻してから、キーペアを SSH に追加します。# chown nova:nova id_rsa # chown nova:nova id_rsa.pub # su nova $ mkdir -p /var/lib/nova/.ssh $ cp id_rsa /var/lib/nova/.ssh/ $ cat id_rsa.pub >> /var/lib/nova/.ssh/authorized_keys $ echo 'StrictHostKeyChecking no' >> /var/lib/nova/.ssh/config $ exit
nova
ユーザーが各ノードにパスワードを入力せずにログインできることを確認します。# su nova $ ssh computeNodeAddress $ exit
両ノード上で root として、libvirt と Compute サービスを再起動します。
# systemctl restart libvirtd.service # systemctl restart openstack-nova-compute.service
2.3.2. インスタンスの移行
以下の手順のコマンドは、すべて OpenStack コントローラーノードで実行するようにしてください。
インスタンスをシャットダウンします。
# nova stop DemoInstance
インスタンスを移行します。
# nova migrate DemoInstance
注記Computer サービスは、サービスの設定に基づいて (重みとフィルターのバランスを取って) 移行先のコンピュートノードを選択します。
インスタンスの状態が VERIFY_RESIZE (状態の確認コマンドは
nova show
) に変更されるまで待機してから、以下のように移行を確定します。# nova resize-confirm DemoInstance
Comments