Я сталкивался с ситуациями, когда живые миграции никогда не завершались или не выходили из строя.
Вот как мне удалось воспроизвести проблему.
Вот экземпляр, который я переношу:
[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
... 12 мая, 20:10:41 по Гринвичу 2016 г. Сейчас пятница, 13 мая, 17:13:46 по Гринвичу 2016 года, и живая миграция все еще продолжается. Он завершится успешно, как только я убью "стресс" на экземпляре.
В производственных средах у меня есть экземпляры, которые по той или иной причине перегреваются, и я хотел бы мигрировать их в реальном времени, не вызывая сбоев приложений, убивая те приложения, которые вызывают высокую нагрузку.
Есть ли какой-то элемент конфигурации, который я могу настроить, или какой-то трюк с 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 команда правильно:
На моем вычислительном узле, где живет моя виртуальная машина. Показываю, что у меня хорошая версия qemu:
[root@osc1-net-002 ~]# qemu-io --version
qemu-io version 2.1.2
Теперь я делаю virsh list чтобы получить имя экземпляра виртуальной машины, на которой я хочу жить, выполните миграцию следующим образом:
[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. Майкл вернулся ко мне и подтвердил, что 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 что заставляет меня думать, что если моя виртуальная машина регулируется, она недостаточно регулируется.
ОБНОВЛЕНИЕ IV:
Мне удалось успешно перенести в реальном времени виртуальную машину, которая испытывала большую нагрузку. На вычислительном сервере, с которого я мигрировал, я выполнил:
[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 |
...
Приостановка работы виртуальной машины, похоже, не помешала ни одному из процессов, запущенных на виртуальной машине. Может, я просто недостаточно внимательно посмотрел.
Затем на конечном вычислительном сервере 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
Неудачная миграция из-за слишком загруженных виртуальных машин была признана проблемой. К сожалению, хотя qemu предоставляет решение, оно не предоставляется через libvirt API и поэтому недоступно для OpenStack.
Решение Qemu называется автосходимостью. Это означает, что, если виртуальная машина настолько занята, что прогнозируется, что миграция никогда не завершится, выполнение виртуальной машины будет ограничено, чтобы, возможно, позволить завершиться миграции.
Автосогласование доступно начиная с версии qemu 1.6, которая должна присутствовать в вашей установке OpenStack Juno. В этой версии количество троттлинга фиксировано. Начиная с qemu 2.5 (который на данный момент является совершенно новым, и у вас его еще не будет), регулирование является динамическим, и если виртуальная машина занята, его можно регулировать в любом месте до 99% динамически, но только настолько, насколько необходимо для позвольте миграции завершиться.
Поскольку эта команда монитора не отображается в API libvirt, OpenStack не может ею воспользоваться. На данный момент вам придется вручную применить автоматическую конвергенцию к работающей виртуальной машине. Например, войдите как 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 ## которые устанавливают начальный процент регулирования и приращение дополнительного регулирования, которое будет использоваться, если миграция по-прежнему не будет завершена, соответственно.
Надеюсь, они в конечном итоге будут добавлены в API libvirt, чтобы будущая версия OpenStack могла управлять этим напрямую.