web-dev-qa-db-ja.com

OpenStack JunoLive-高負荷でサイズが64GBを超えるインスタンスの移行が完了しない

ライブマイグレーションが完了していない、またはエラーが発生していないように見える状況に遭遇しました。

これが私が問題を再現することができた方法です。

これが私が移行しているインスタンスです：

[root@osc1-mgmt-001 tmp]# nova show gb72-net-002-org-001
+--------------------------------------+---------------------------------------------------------------------+
| Property                             | Value                                                               |
+--------------------------------------+---------------------------------------------------------------------+
| OS-DCF:diskConfig                    | MANUAL                                                              |
| OS-EXT-AZ:availability_zone          | nova                                                                |
| OS-EXT-SRV-ATTR:Host                 | osc1-net-002.example.com                                          |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | osc1-net-002.example.com                                          |
| OS-EXT-SRV-ATTR:instance_name        | gb72-net-002-org-001                                                |
| OS-EXT-STS:power_state               | 1                                                                   |
| OS-EXT-STS:task_state                | migrating                                                           |
| OS-EXT-STS:vm_state                  | active                                                              |
| OS-SRV-USG:launched_at               | 2016-05-12T20:01:23.000000                                          |
| OS-SRV-USG:terminated_at             | -                                                                   |
| accessIPv4                           |                                                                     |
| accessIPv6                           |                                                                     |
| config_drive                         |                                                                     |
| created                              | 2016-05-12T20:00:58Z                                                |
| flavor                               | gb72_vm (668ca3b4-a7c0-4309-a11e-4fb5377e4180)                      |
| hostId                               | 44206a2390a038b0ede2a4375f1239b0cef917149bd5976fcada6781            |
| id                                   | 3b176ee2-fcf3-41a6-b658-361ffd19639e                                |
| image                                | CentOS-7-x86_64-GenericCloud (588e035d-2e1e-4720-94c4-8b000bf9d2ef) |
| key_name                             | nk                                                                  |
| metadata                             | {}                                                                  |
| name                                 | gb72-net-002-org-001                                                |
| os-extended-volumes:volumes_attached | [{"id": "16afe52c-31b0-4a3a-b718-aa1789df2852"}]                    |
| public-47 network                    | 10.29.105.13                                                        |
| security_groups                      | default                                                             |
| status                               | MIGRATING                                                           |
| tenant_id                            | 9d011b7c8d104af1b887e229cee436d2                                    |
| updated                              | 2016-05-13T17:07:48Z                                                |
| user_id                              | fa8b956c89304124967bb4bcea54124b                                    |
+--------------------------------------+---------------------------------------------------------------------+

フレーバーgb72_vmは私が作成したもので、次のようになります。

[root@osc1-mgmt-001 tmp]# nova flavor-show gb72_vm
+----------------------------+--------------------------------------+
| Property                   | Value                                |
+----------------------------+--------------------------------------+
| OS-FLV-DISABLED:disabled   | False                                |
| OS-FLV-EXT-DATA:ephemeral  | 0                                    |
| disk                       | 20                                   |
| extra_specs                | {}                                   |
| id                         | 668ca3b4-a7c0-4309-a11e-4fb5377e4180 |
| name                       | gb72_vm                              |
| os-flavor-access:is_public | True                                 |
| ram                        | 72000                                |
| rxtx_factor                | 1.0                                  |
| swap                       | 16000                                |
| vcpus                      | 8                                    |
+----------------------------+--------------------------------------+

インスタンスを起動した後、stressをインストールし、次のようにインスタンスにストレスをかけています。

[centos@gb72-net-002-org-001 stress-1.0.4]$ stress -c 6 -m 4 --vm-bytes 512M

インスタンスでtopも実行していますが、次のようになります。

top - 17:17:02 up 21:15,  1 user,  load average: 10.11, 10.08, 10.06
Tasks: 149 total,  12 running, 137 sleeping,   0 stopped,   0 zombie
%Cpu(s): 62.0 us, 38.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 72323392 total, 70503632 free,  1344768 used,   474988 buff/cache
KiB Swap: 16383996 total, 16383996 free,        0 used. 70740048 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
10273 centos    20   0    7260     96      0 R  86.7  0.0   1008:21 stress
10276 centos    20   0    7260     96      0 R  84.7  0.0   1008:22 stress
10271 centos    20   0    7260     96      0 R  84.1  0.0   1008:00 stress
10275 centos    20   0    7260     96      0 R  82.1  0.0   1009:28 stress
10270 centos    20   0  531552 218716    176 R  80.7  0.3   1011:42 stress
10272 centos    20   0  531552 142940    176 R  80.4  0.2   1012:40 stress
10269 centos    20   0    7260     96      0 R  78.7  0.0   1008:38 stress
10274 centos    20   0  531552 333404    176 R  73.1  0.5   1012:32 stress
10267 centos    20   0    7260     96      0 R  70.4  0.0   1008:41 stress
10268 centos    20   0  531552  38452    176 R  65.8  0.1   1011:29 stress
    1 root      20   0  191352   6652   3908 S   0.0  0.0   0:06.00 systemd
    2 root      20   0       0      0      0 S   0.0  0.0   0:00.02 kthreadd
    3 root      20   0       0      0      0 S   0.0  0.0   0:01.45 ksoftirqd/0
    5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:0H
    6 root      20   0       0      0      0 S   0.0  0.0   0:00.12 kworker/u16:0
    7 root      rt   0       0      0      0 S   0.0  0.0   0:00.62 migration/0
    8 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_bh
    9 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/0
   10 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/1
   11 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/2
   12 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/3
   13 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/4
   14 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/5
   15 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/6
   16 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/7
   17 root      20   0       0      0      0 R   0.0  0.0   0:02.42 rcu_sched
   18 root      20   0       0      0      0 S   0.0  0.0   0:00.44 rcuos/0
   19 root      20   0       0      0      0 S   0.0  0.0   0:00.29 rcuos/1
   20 root      20   0       0      0      0 S   0.0  0.0   0:00.32 rcuos/2

コマンドを発行しました...

# nova live-migration gb72-net-002-org-001 osc6-net-001.example.com

... 2016年5月12日20：10：41GMTです。現在は2016年5月13日金曜日17：13：46GMTであり、ライブマイグレーションはまだ進行中です。インスタンスの「ストレス」を殺すとすぐに正常に完了します。

実稼働環境では、何らかの理由でホットになっているインスタンスがあり、高負荷を引き起こしているアプリケーションを強制終了することで、アプリケーションの停止を引き起こさずにそれらをライブマイグレーションしたいと思います。

最初にインスタンスの負荷を軽減せずにインスタンスを移行するために使用できる、tweekできる構成アイテムやvirshトリックはありますか？

更新：Qemuのどのバージョンがありますか？

素晴らしい答えをありがとうマイケル。私は自分が持っているqemuのバージョンを理解しようとしています：

# rpm -qa | grep qemu
ipxe-roms-qemu-20130517-8.gitc4bce43.el7_2.1.noarch
libvirt-daemon-driver-qemu-1.2.17-13.el7_2.3.x86_64
qemu-img-rhev-2.1.2-23.el7_1.4.x86_64
qemu-kvm-common-rhev-2.1.2-23.el7_1.4.x86_64
qemu-kvm-rhev-2.1.2-23.el7_1.4.x86_64
[root@osc1-net-002 ~]# virsh -v
1.2.17

アップデートII：

virshコマンドを正しく発行していることを確認したいだけです。

私のVMが住んでいる計算ノードで。私はqemuの良いバージョンを持っていることを示しています：

[root@osc1-net-002 ~]# qemu-io --version
qemu-io version 2.1.2

次に、virsh listを実行して、VMのインスタンス名を取得します。次のようにライブマイグレーションしたい：

[root@osc1-net-002 ~]# virsh list
 Id    Name                           State
----------------------------------------------------
 50    gb72-net-002-org-001           running

したがって、それに基づいて、計算サーバーocs1-net-002でこのコマンドを実行し、gb72-net-002-org-002を抑制します。

[root@osc1-net-002 ~]# virsh qemu-monitor-command gb72-net-002-org-002 --hmp migrate_set_capability auto-converge on

次に、次のようにライブマイグレーションを実行しようとします。

[root@osc1-mgmt-001 ~]# nova live-migration gb72-net-002-org-002 osc6-net-001.example.com

発行するコマンドのセットを修正するためですか？

アップデートIII。 Michaelが私に戻ってきて、virshコマンドが正常に見えることを確認しました。ありがとうマイケル！

上記のようにライブマイグレーションを発行しましたが、これは/etc/nova/nova-compute.logのosc1-net-002で確認できます。

DEBUG nova.virt.libvirt.driver [-] [instance: bf616c8b-0054-47ee-a547-42c2a946be2e] Migration running for 2405 secs, memory 2% remaining; (bytes processed=2520487990540, remaining=1604055040, total=75515105280) _live_migration_monitor /usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py:5721

私が気付いたのは、ライブマイグレーションが40分間実行されていることです。また、bytes processed=2525969442377はtotal=75515105280よりも大きいため、VMが調整されている場合、十分に調整されていないと思います。

更新IV：

大きな負荷がかかっていたVM）のライブマイグレーションを成功させることができました。移行していたコンピューティングサーバーで、次のコマンドを実行しました。

[root@osc1-net-002 ~]# virsh qemu-monitor-command gb72-net-002-org-001 -hmp stop
error: Timed out during operation: cannot acquire state change lock (held by remoteDispatchDomainMigratePerform3)
[root@osc1-net-002 ~]# virsh suspend gb72-net-002-org-001
Domain gb72-net-002-org-001 suspended

エラーが発生する理由はわかりませんが、問題ではないようです。

次に、ライブマイグレーションが完了したかどうかを確認しました。

[root@osc1-net-002 ~]# nova list
+--------------------------------------+----------------------+--------+------------+-------------+-----------------------+
| ID                                   | Name                 | Status | Task State | Power State | Networks              |
+--------------------------------------+----------------------+--------+------------+-------------+-----------------------+
| de335b04-8632-48e3-b17c-d80ac2d02983 | gb72-net-002-org-001 | ACTIVE | -          | Running     | public-47=10.29.105.9 |
| 229d8775-3a3c-46a6-8f40-7f86ca99af88 | test-net-001-org     | ACTIVE | -          | Running     | public-47=10.29.105.4 |
| 6d2ddad3-3851-4495-bf14-b787fed2ad99 | test-net-001-org-2   | ACTIVE | -          | Running     | public-47=10.29.105.7 |
+--------------------------------------+----------------------+--------+------------+-------------+-----------------------+
[root@osc1-net-002 ~]# nova show gb72-net-002-org-001
+--------------------------------------+---------------------------------------------------------------------+
| Property                             | Value                                                               |
+--------------------------------------+---------------------------------------------------------------------+
| OS-DCF:diskConfig                    | MANUAL                                                              |
| OS-EXT-AZ:availability_zone          | nova                                                                |
| OS-EXT-SRV-ATTR:Host                 | osc6-net-001.example.com                                          |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | osc6-net-001.example.com                                          |
| OS-EXT-SRV-ATTR:instance_name        | gb72-net-002-org-001                                                |
| OS-EXT-STS:power_state               | 1                                                                   |
| OS-EXT-STS:task_state                | -                                                                   |
| OS-EXT-STS:vm_state                  | active                                                              |
...

VMの一時停止は、VMで実行されているプロセスのいずれにも干渉していないようです。たぶん私は十分に見た目がよくありませんでした。

次に、宛先計算サーバーosc6-net-001.example.comで、次のコマンドを実行しました。

[root@osc6-net-001 ~]# virsh qemu-monitor-command --hmp gb72-net-002-org-001 cont


[root@osc6-net-001 ~]# virsh resume gb72-net-002-org-001
Domain gb72-net-002-org-001 resumed
libvirtopenstackvirshopenstack-nova
2
Red Cricket

VMが多すぎるために移行に失敗することは、問題として認識されています。残念ながら、qemuはソリューションを提供しますが、libvirt APIを介して公開されていないため、OpenStackでは使用できません。

Qemuのソリューションは自動収束と呼ばれます 。これは、a VMが非常にビジーで、移行が完了しないと予測される場合、VMの実行が抑制され、移行を終了させます。

自動コンバージェンスはqemu1.6以降で利用可能であり、OpenStackJunoインストールに存在する必要があります。このバージョンでは、スロットルの量が固定されています。 qemu 2.5（現時点では完全に新しく、まだ使用されていない）なので、スロットルは動的であり、VMがビジーの場合、最大99％までどこでもスロットルできます。動的に、ただし移行を完了するために必要なだけ。

このmonitorコマンドはlibvirtAPIで公開されていないため、OpenStackはそれを利用できません。現時点では、実行中のVMに手動で自動収束を適用する必要があります。たとえば、現在VMを実行している計算ノードにrootとしてログインし、次を実行します。

virsh qemu-monitor-command instance-000007e1 --hmp migrate_set_capability auto-converge on

これは何も出力せず、成功した場合は0を返します。その後、移行を開始できます。

Qemu 2.5では、モニターコマンドを使用して動的スロットルを調整できますmigrate_set_parameter x-cpu-throttle-initial ##およびmigrate_set_parameter x-cpu-throttle-increment ##これは、初期スロットリングのパーセンテージと、移行がまだ完了しない場合に使用される追加のスロットリングの増分をそれぞれ設定します。

うまくいけば、これらは最終的にlibvirt APIに追加され、OpenStackの将来のバージョンがこれを直接管理できるようになります。

3
Michael Hampton