インスタンスの移行

Red Hat OpenStack Platform 8

OpenStack 環境のハイパーバイザー間でのインスタンスの移行

OpenStack Documentation Team

法律上の通知

Copyright © 2016 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.

概要

本書では、ライブ (稼働中) または静的な (保存状態) インスタンスを 2 つのハイパーバイザー間で移行する手順を説明します。

前書き

本書では、ライブ (稼働中) または静的な (保存状態) インスタンスを 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 トンネリングも可能ですが、通常、静的 (コールド) マイグレーションにのみ使用されます。

環境内の全コンピュートノードで以下の手順を行います。

  1. 適切なストラテジーを決定して、その設定を行う際には、ネットワーク管理者に問い合わせてください (『Red Hat Enterprise Linux 7 仮想化の導入および管理ガイド』の libvirt のドキュメントも参照してください)。
  2. ストラテジーに応じて、/etc/libvirt/libvirtd.conf ファイルの以下のパラメーターを更新してください。

    1. 暗号化には 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 経由のリモート管理」を参照してください。

    2. 認証および暗号化には 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」を参照してください。

    3. 暗号化には TLS、認証には Kerberos

      listen_tls = 1
      listen_tcp = 0
      auth_tls = "sasl"
      sasl_allowed_username_list = ["Kerberos principal name pattern"]

      同様に、Kerberos principal name pattern は、サーバー向けに発行した Kerberos チケットと一致するパターンに置き換えます。

  3. /etc/sysconfig/libvirtd ファイルを編集して、以下の行を追記します。

    LIBVIRTD_ARGS="--listen"
  4. 決定したストラテジーに合わせて、/etc/nova/nova.conf のアクセス URI の文字列を更新します。

    live_migration_uri=qemu+ACCESSTYPE://USER@%s/system

    ここで、

    • ACCESSTYPEtcp (暗号化なし) または tls (暗号化あり) に指定することができます。
    • USER はコンピュートのユーザーを指定します (ファイルパーミッションが適切に設定されるようにします)。問題が発生した場合は、'%s' (root ユーザーにデフォルト設定) のみを使用してみてください。

      例: TLS の使用
      live_migration_uri=qemu+tls://nova@%s/system
  5. 設定が完了したら libvirt を再起動します。

    # systemctl restart libvirtd.service

1.2.2. NFS 共有ストレージの設定

以下の共有ストレージの手順 (ブロックベースの移行では必要なし) では、Compute サービスのインスタンスディレクトリーを 2 つのノードにエクスポートし、ノードがアクセスできることを確認します。ディレクトリーのパスは、/etc/nova/nova.conf ファイルの state_path および instances_path パラメーターで設定されます。

以下の手順では、デフォルトのディレクトリーパス /var/lib/nova/instances を使用します。

  1. コントローラーホスト上で以下を実行します。

    1. NFS サーバーをすでに実行中でない限り、以下のパッケージをインストールする必要があります。

      # yum install nfs-utils
    2. /etc/sysconfig/nfs を更新して、NFS サーバーサービスの固定ポートを設定します。

      LOCKD_TCPPORT=32803
      LOCKD_UDPPORT=32769
    3. ファイアウォールトラフィックを更新して、NFS 通信を許可します。

      # iptables -v -I NFS -p tcp --dport 32803 -j ACCEPT
      # iptables -v -I NFS -p udp --dport 32769 -j ACCEPT
      # iptables -v -I NFS -p tcp --dport 111 -j ACCEPT
      # iptables -v -I NFS -p tcp --dport 2049 -j ACCEPT
      # iptables -v -I INPUT 1 -s 0.0.0.0/0 -p tcp -m state --state NEW,RELATED,ESTABLISHED -m tcp --dport 2049 -j ACCEPT
      # iptables -v -I OUTPUT 1 -d 0.0.0.0/0 -p tcp -m state --state RELATED,ESTABLISHED -m tcp --sport 2049 -j ACCEPT
    4. 以下を /etc/group ファイルに追加します。

      nova:x:162:nova
    5. 以下を /etc/passwd ファイルに追加します。

      nova:x:162:162:OpenStack Nova Daemons:/var/lib/nova:/sbin/nologin
    6. ディレクトリーを作成して、Compute サービスのユーザーの読み取り/書き込み権限が設定されていることを確認します (このユーザーはコントローラーおよび各ノードで同じである必要があることを念頭に置いてください)。以下のコマンドでは、Compute サービスのユーザーが nova であることが前提です。

      # mkdir -p /var/lib/nova/instances
      # chown nova:nova /var/lib/nova/instances
      # chmod 775 /var/lib/nova/instances
    7. 以下の行を /etc/exports ファイルに追加します。computeNode1_IP および computeNode2_IP は、2 つのコンピュートノードの IP アドレスに置き換えます。

      /var/lib/nova/instances computeNode1_IP(rw,sync,fsid=0,no_root_squash)
      /var/lib/nova/instances computeNode2_IP(rw,sync,fsid=0,no_root_squash)
    8. NFS サービスを起動/有効化して、iptables を再起動します。

      # systemctl start nfs-server.service
      # systemctl enable nfs-server.service
      # systemctl restart iptables.service
    9. /var/lib/nova/instances ディレクトリーをコンピュートノードにエクスポートします。

      # exportfs -avr
  2. 各コンピュートノードで以下を実行します。

    1. 必要なリモートパッケージをインストールします (インストール済みでない場合)。

      # yum install iptables openstack-utils openstack-nova-novncproxy -y
    2. NFS クライアントとして機能するように、rpcbind サービスを起動します。

      # systemctl start rpcbind.service
    3. 以下を /etc/group ファイルに追加します。

      nova:x:162:nova
    4. 以下を /etc/passwd ファイルに追加します。

      nova:x:162:162:OpenStack Nova Daemons:/var/lib/nova:/sbin/nologin
    5. ディレクトリーを作成して、パーミッションを変更します。

      # mkdir -p /var/lib/nova/instances
      # chown nova:nova /var/lib/nova/instances
      # chmod 775 /var/lib/nova/instances
    6. コントローラーのインスタンスディレクトリーをマウントします。controllerNode_IP は、コントローラーの IP アドレスに置き換えます。

      # mount -t nfs controllerNode_IP:/var/lib/nova/instances /var/lib/nova/instances
    7. ファイアウォールおよびネットワークトラフィックを設定します。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
      # iptables -v -N NFS; iptables -v -I INPUT -j NFS
    8. iptables を保存して、SELinux により NFS アクセスが妨害されないようにします。

      # service iptables save
      # setsebool -P virt_use_nfs 1
    9. ノードでインスタンスディレクトリーを表示できることを確認します。

      # ls -ld /var/lib/nova/instances
      drwxr-xr-x. 9 nova nova 4096 Nov  5 20:37 /var/lib/nova/instances
      注記

      以下のコマンドを実行して、全マウント済みデバイスを確認することもできます。

      # df -k
    10. /etc/libvirt/qemu.conf ファイルで、qemu 設定を更新します。

      user="root"
      group="root"
      vnc_listen="0.0.0.0"
    11. 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://controllerNode_IP: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 live_migration_flag VIR_MIGRATE_UNDEFINE_SOURCE,VIR_MIGRATE_PEER2PEER,VIR_MIGRATE_LIVE

      サービスを再起動します。

      # openstack-service restart
  3. コントローラーホスト上で以下を実行します。

    1. OpenStack パッケージをインストールします。

      # yum install openstack-utils openstack-nova-novncproxy -y
    2. Compute 設定を更新して、サービスを再起動します。

      # openstack-config --set /etc/nova/nova.conf DEFAULT vncserver_listen 0.0.0.0
      # openstack-service restart

1.2.3. ブロック移行の設定

ブロック移行を行う場合は、共有ストレージを使用できませんが、各種サービスがリモート通信用に設定されており、ローカルの /instances のディレクトリーに正しいパーミッションが設定されている必要があります。

以下の手順では、デフォルトのディレクトリーパス /var/lib/nova/instances を使用します。

  1. 各コンピュートノードで以下を実行します。

    1. 必要なリモートパッケージをインストールします (インストール済みでない場合)。

      # yum install iptables openstack-utils openstack-nova-novncproxy -y
    2. インスタンスに使用するディレクトリーを作成します (作成済みでない場合)。

      # mkdir -p /var/lib/nova/instances
    3. 以下を /etc/group ファイルに追加します。

      nova:x:162:nova
    4. 以下を /etc/passwd ファイルに追加します。

      nova:x:162:162:OpenStack Nova Daemons:/var/lib/nova:/sbin/nologin
    5. ディレクトリーのパーミッションを変更します。

      # chown nova:nova /var/lib/nova/instances;chmod 775 /var/lib/nova/instances
    6. ファイアウォールおよびネットワークトラフィックを設定します。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
    7. ノードでインスタンスディレクトリーを表示できることを確認します。

      # ls -ld /var/lib/nova/instances
      drwxrwxr-x. 9 nova nova 4096 Nov  5 20:37 /var/lib/nova/instances
    8. /etc/libvirt/qemu.conf ファイルで、qemu 設定を更新します。

      user="root"
      group="root"
      vnc_listen="0.0.0.0"
    9. libvirtd サービスを再起動して、qemu 設定の変更が反映されるようにします。

      # systemctl restart libvirtd
    10. 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
    11. サービスを再起動します。

      # systemctl restart iptables.service;
      # openstack-service restart
  2. コントローラーホスト上で以下を実行します。

    1. OpenStack パッケージをインストールします。

      # yum install openstack-utils openstack-nova-novncproxy -y
    2. Compute 設定を更新して、サービスを再起動します。

      # openstack-config --set /etc/nova/nova.conf DEFAULT vncserver_listen 0.0.0.0
      # openstack-service restart

1.3. ライブインスタンスの移行

  1. インスタンスの一覧を表示して、対象のインスタンスが表示されていることを確認します。

    # nova list
  2. どのノードでインスタンスが実行されているかを確認します。

    # nova show DemoInstance
    +--------------------------------------+-----------------------------------+
    | Property                             | Value                             |
    +--------------------------------------+-----------------------------------+
    | ...                                  |                                   |
    | OS-EXT-SRV-ATTR:host                 | OpenStack2                        |
    | OS-EXT-SRV-ATTR:hypervisor_hostname  | OpenStack2                        |
    | ...                                  |                                   |
  3. 利用可能な移行先ノードの一覧を表示します。

    # nova service-list
    +------------------+------------+----------+---------+-------+-
    | Binary           | Host       | Zone     | Status  | State |
    +------------------+------------+----------+---------+-------+-
    | nova-compute     | OpenStack2 | nova     | enabled | up    |
    | nova-compute     | OpenStack3 | nova     | enabled | up    |
    | ...              |            |          |         |       |
  4. 移行先を選択して、十分なリソースがあることを確認します。

    # 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       |
    +------------+------------------------------+-----+-----------+---------+
  5. インスタンスを移行します。

    共有ストレージでの移行
    # nova live-migration DemoInstance OpenStack3
    ブロックとしての移行
    # nova live-migration --block-migrate DemoInstance OpenStack3
    警告

    インスタンスの移行は、使用率が低い時に行うようにしてください。ゲストオペレーティングシステムがディスク上のブロックに書き込む速度が、ブロックの移行速度よりも早い場合には、移行は完了されません。

  6. インスタンスのホストをチェックして、移行が完了したかどうかを確認します。

    # 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_ratio2 に設定されている場合は、スケジューラーは、メモリーが 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 の プロジェクト > コンピュート > インスタンス を使用してください。

  • インスタンスが停止している場合は、下向きの三角印をクリックしてスナップショットの作成 を選択します。
  • インスタンスが実行中の場合は、スナップショットの作成 をクリックします。

作成したイメージは新規インスタンスのベースとして使用することができます。

スナップショットを作成します。

  1. インスタンスの一覧を表示して、対象のインスタンスが表示されていることを確認します。

    # 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 サービスにより、スナップショットの作成前に、全データが確実にフラッシュされます。

  2. スナップショットを作成します。以下のコマンドでは、DemoInstance-Snap が新規スナップショットの名前です。

    # nova image-create DemoInstance DemoInstance-Snap

    このスナップショットは、自動的にユーザーのプロジェクトに割り当てられます。

  3. 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 |
    +--------------------------------------+-----------------------+-------------+------------------+-----------+--------+
  4. イメージ ID を使用してスナップショットをダウンロードします。新規ファイルには、どのような名前でも使用できます。

    # glance image-download --file DemoInstance-Snap.qcow2 DemoInstance-Snap

スナップショットをインポートします。

  1. 新規ファイルを新規ホストにコピーします。
  2. 新しいクラウド環境またはプロジェクトで、スナップショットを使用して新規イメージを作成します。

    # 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                                 |
    +------------------+--------------------------------------+
  3. インスタンスの割り当てが可能なプライベートネットワークを特定します。アクセス可能なネットワークは、クラウドの環境やユーザーのパーミッションにより異なります。アクセス可能なネットワークをすべて表示するには、以下のコマンドを実行します。

    # neutron net-list
  4. 新規作成したイメージを使用して、新しいインスタンスを起動します。

    # 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
  5. 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」と設定されていることを確認してください。

コンピュートノード間でのキーペアの共有方法:

  1. 両ノード上で root として、nova をログインユーザーに設定します。

    # usermod -s /bin/bash nova
  2. 最初の 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_rsaid_rsa.pub のキーペアが /var/lib/nova/.ssh 内に生成されます。

  3. root として、2 番目のコンピュートノードに作成したキーペアをコピーします。

    # scp /var/lib/nova/.ssh/id_rsa computeNodeAddress:~/
    # scp /var/lib/nova/.ssh/id_rsa.pub computeNodeAddress:~/
  4. 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
  5. nova ユーザーが各ノードにパスワードを入力せずにログインできることを確認します。

    # su nova
    $ ssh computeNodeAddress
    $ exit
  6. 両ノード上で root として、libvirt と Compute サービスを再起動します。

    # systemctl restart libvirtd.service
    # systemctl restart openstack-nova-compute.service

2.3.2. インスタンスの移行

以下の手順のコマンドは、すべて OpenStack コントローラーノードで実行するようにしてください。

  1. インスタンスをシャットダウンします。

    # nova stop DemoInstance
  2. インスタンスを移行します。

    # nova migrate DemoInstance
    注記

    Computer サービスは、サービスの設定に基づいて (重みとフィルターのバランスを取って) 移行先のコンピュートノードを選択します。

  3. インスタンスの状態が VERIFY_RESIZE (状態の確認コマンドは nova show) に変更されるまで待機してから、以下のように移行を確定します。

    # nova resize-confirm DemoInstance