+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Надежность живой миграции, Proxmox Виртуальная Среда

FinnTux

Guest

06.10.2011 21:08:00

Кто-нибудь уже пробовал live migration? У меня проблемы с надёжностью миграции. Особенно с ubuntu 11.10 beta2 (и xubuntu 11.10 beta2) всё кажется довольно капризным. Миграция часто проходит успешно, иногда ВМ зависает после миграции, но довольно часто виртуальная машина просто отключается на целевом хосте. Веб-интерфейс во всех случаях показывает «TASK OK». Понижение скорости миграции немного помогает, так же как и установка времени простоя миграции в 0 (по умолчанию 1 секунда). Разницы между virtio и ide или virtio и e1000, кажется, нет. У меня кластер из двух нод и два типа общего хранилища: Drbd и iSCSI target, оба используются как бекенд для логических томов. Проблема одинаковая с обоими. Хост-машины довольно разные: одна на AMD Athlon X4, другая — Dual Core 2 E8500. Я понимаю, что лучше всего использовать одинаковые машины, но с другой стороны, миграция должна работать между процессорами разных производителей (и да — работает, но ненадёжно). Не уверен, что это исключительно проблема Proxmox, потому что заметил то же самое, когда разрабатывал свой скрипт управления. Короче, может кто-то попробует (лучше ubuntu 11.10 beta2) и расскажет, как у него идёт live migration? Спасибо!

ksosez Guest	#2 0 09.01.2012 20:12:00 Можем ли мы проверить и внести это исправление? Это очень помогло бы многим из нас.

e100 Guest	#3 0 09.01.2012 20:36:00 sleep(1); похоже, тоже работает нормально.

Frido Roose

Guest

04.01.2012 23:37:00

Привет, я тоже изредка сталкиваюсь с ненадёжными онлайн-миграциями. Гостевая машина — SLES 11 SP1. Пробовал запускать без прикреплённого сетевого адаптера, но результат тот же: веб-интерфейс говорит, что миграция прошла успешно, а через 10 секунд виртуальная машина либо зависает (в этот момент я видел 100% загрузку CPU гостя), либо просто перестаёт работать. В логах на целевом хосте особо информации нет, кроме сообщений ниже, выделенных красным. Есть ли способ включить более подробное логирование или добавить какой-то дополнительный файл логов?

Тест онлайн-миграции, который завершился неудачей:

Лог задачи в Proxmox webgui:
Jan 04 16:50:17 начало миграции VM 100 на узел 'raiti' (192.168.110.55)
Jan 04 16:50:17 копирование дисковых образов
Jan 04 16:50:17 запуск VM 100 на удалённом узле 'raiti'
Jan 04 16:50:17 запуск туннеля миграции
Jan 04 16:50:18 запуск онлайн/живой миграции на порту 60000
Jan 04 16:50:20 статус миграции: активна (перенесено 116894КБ, осталось 154184КБ), всего 541056КБ)
Jan 04 16:50:22 статус миграции: завершена
Jan 04 16:50:22 скорость миграции: 128.00 МБ/с
Jan 04 16:50:23 миграция успешно завершена (длительность 00:00:07)
ЗАДАЧА ОК

daemon.log:
Jan 4 16:50:33 raiti pmxcfs[1805]: [status] получен лог
Jan 4 16:50:34 raiti qm[3153]: <root@pam> запуск задачи UPID:raiti:00000C52:0002C08B:4F04754A:qmstart:100:root@pam:
Jan 4 16:50:34 raiti qm[3154]: запуск VM 100: UPID:raiti:00000C52:0002C08B:4F04754A:qmstart:100:root@pam:
Jan 4 16:50:34 raiti multipathd: dm-4: добавлена карта (uevent)
Jan 4 16:50:34 raiti qm[3153]: <root@pam> окончание задачи UPID:raiti:00000C52:0002C08B:4F04754A:qmstart:100:root@pam: ОК
Jan 4 16:50:40 raiti pmxcfs[1805]: [status] получен лог

syslog:
Jan 4 16:50:33 raiti pmxcfs[1805]: [status] получен лог
Jan 4 16:50:34 raiti qm[3153]: <root@pam> запуск задачи UPID:raiti:00000C52:0002C08B:4F04754A:qmstart:100:root@pam:
Jan 4 16:50:34 raiti qm[3154]: запуск VM 100: UPID:raiti:00000C52:0002C08B:4F04754A:qmstart:100:root@pam:
Jan 4 16:50:34 raiti multipathd: dm-4: добавлена карта (uevent)
Jan 4 16:50:34 raiti kernel: устройство tap100i0 вошло в промискуитетный режим
Jan 4 16:50:34 raiti kernel: vmbr0: порт 2 (tap100i0) переходит в состояние пересылки
Jan 4 16:50:34 raiti qm[3153]: <root@pam> окончание задачи UPID:raiti:00000C52:0002C08B:4F04754A:qmstart:100:root@pam: ОК
Jan 4 16:50:38 raiti kernel: vmbr0: порт 2 (tap100i0) переходит в отключённое состояние
Jan 4 16:50:38 raiti kernel: vmbr0: порт 2 (tap100i0) переходит в отключённое состояние
Jan 4 16:50:40 raiti pmxcfs[1805]: [status] получен лог

Ещё один тест онлайн-миграции, который закончился неудачей:

Лог задачи в Proxmox webgui:
Jan 04 17:10:34 начало миграции VM 100 на узел 'raiti' (192.168.110.55)
Jan 04 17:10:34 копирование дисковых образов
Jan 04 17:10:34 запуск VM 100 на удалённом узле 'raiti'
Jan 04 17:10:34 запуск туннеля миграции
Jan 04 17:10:35 запуск онлайн/живой миграции на порту 60000
Jan 04 17:10:37 статус миграции: активна (перенесено 115124КБ, осталось 146652КБ), всего 541056КБ)
Jan 04 17:10:39 статус миграции: завершена
Jan 04 17:10:39 скорость миграции: 128.00 МБ/с
Jan 04 17:10:40 миграция успешно завершена (длительность 00:00:07)
ЗАДАЧА ОК

syslog:
Jan 4 17:10:50 raiti pmxcfs[1805]: [status] получен лог
Jan 4 17:10:50 raiti qm[5503]: <root@pam> запуск задачи UPID:raiti:00001580:00049BD8:4F047A0A:qmstart:100:root@pam:
Jan 4 17:10:50 raiti qm[5504]: запуск VM 100: UPID:raiti:00001580:00049BD8:4F047A0A:qmstart:100:root@pam:
Jan 4 17:10:51 raiti multipathd: dm-4: добавлена карта (uevent)
Jan 4 17:10:51 raiti qm[5503]: <root@pam> окончание задачи UPID:raiti:00001580:00049BD8:4F047A0A:qmstart:100:root@pam: ОК
Jan 4 17:10:51 raiti ntpd[1732]: bind(24) AF_INET6 fe80::c488:5fff:fe4e:ac5b%9#123 флаги 0x11 ошибка: Невозможно назначить запрошенный адрес
Jan 4 17:10:51 raiti ntpd[1732]: невозможно создать сокет на tap100i0 (12) для fe80::c488:5fff:fe4e:ac5b#123
Jan 4 17:10:51 raiti ntpd[1732]: ошибка инициализации интерфейса для адреса fe80::c488:5fff:fe4e:ac5b
Jan 4 17:10:57 raiti pmxcfs[1805]: [status] получен лог

lievenva Guest	#5 0 06.01.2012 09:38:00 Можем ли мы чем-то помочь в отладке проблемы, о которой Фридо упоминал в предыдущем сообщении? Спасибо, Ливен.

FinnTux

Guest

07.01.2012 08:04:00

Для справки, я проверял живую миграцию на том же оборудовании, используя свой скрипт, стандартное ядро Debian 2.6.32 и qemu-kvm-1.0, и ни одной миграции не провалилось. Общие хранилища, инкрементальная и полная миграция блоков работают нормально.

e100

Guest

08.01.2012 02:39:00

Я опубликовал «исправление» здесь: https://bugzilla.proxmox.com/show_bug.cgi?id=7#c3. Код Proxmox с тех пор сильно изменился, так что информация по багу уже неактуальна.
Отредактируйте файл /usr/share/perl5/PVE/AbstractMigrate.pm.
Примерно на строке 171 добавьте "sleep(2);".
Код:
# vm теперь принадлежит другому узлу
# Примечание: локально больше нет конфигурационного файла ВМ

if ($self->{running}) {
&$eval_int($self, sub { $self->phase2($self->{vmid}); });
my $phase2err = $@;
sleep(2);
if ($phase2err) {
$self->{errors} = 1;
$self->log('err', "ошибка онлайн-миграции — $phase2err");
}

После внесения изменений нужно перезагрузить систему. Сделайте это как минимум на двух узлах и потом протестируйте живую миграцию между ними. Я проверял на ВМ с Windows 2008 R2, которая во время миграции постоянно пинговала шлюз командой "ping -t 192.168.1.1". После правок и перезагрузки живая миграция у меня работала безупречно.

Во время тестов я заметил, что чем больше значение migrate_speed, тем чаще происходили сбои живой миграции. Первое, что пришло в голову — это состояние гонки, ведь скорость вроде влияла на частоту ошибок. Поэтому я решил, что замедление финальных этапов миграции может решить проблему.

Я не считаю это полноценным исправлением, но, возможно, это поможет выявить корень проблемы и в итоге создать правильное решение.

dietmar Guest	#8 0 08.01.2012 10:47:00 Я тоже не понимаю, чем это может помочь.

Frido Roose

Guest

09.01.2012 13:32:00

Спасибо, могу подтвердить, что обходной путь с режимом сна, предложенный e100, действительно помогает! Тест проводился с гостевыми системами Linux (SLES11 SP1). Раньше машина переставала работать после живой миграции примерно в одном из 3-4 случаев, а теперь проблема больше не возникала (пробовали до 15 живых миграций одной и той же ВМ — без проблем).

alain Guest	#10 0 09.01.2012 21:26:00 Так проблема может быть связана с патчами openvz? Поскольку у меня только KVM, а баги из-за патчей openvz случаются регулярно, я бы предпочёл обычное ядро RHEL 2.6.32 в отдельной ветке, как это было для 2.6.35... Ален

dietmar Guest	#11 0 09.01.2012 22:04:00 Поддерживать ядро — это действительно большая работа, поэтому мы не планируем заниматься поддержкой ещё одного ядра.

e100

Guest

#12

09.01.2012 22:14:00

Я пробовал добавить sleep(2); в разные места в коде. Смотрите мои комментарии ближе к концу /usr/share/perl5/PVE/QemuMigrate.pm

Код:

sub phase3_cleanup {
my ($self, $vmid, $err) = @_;

my $conf = $self->{vmconf};

# всегда останавливаем локальную ВМ
eval { PVE::QemuServer::vm_stop($self->{storecfg}, $vmid, 1, 1); };
if (my $err = $@) {
$self->log('err', "ошибка при остановке ВМ - $err");
$self->{errors} = 1;
}

# тут sleep, похоже, решает проблему
# всегда деактивируем тома — чтобы LVM-тома не были активны одновременно на нескольких узлах
eval {
my $vollist = PVE::QemuServer::get_vm_volumes($conf);
PVE::Storage::deactivate_volumes($self->{storecfg}, $vollist);
};
if (my $err = $@) {
$self->log('err', $err);
$self->{errors} = 1;
}
# тут sleep, похоже, решает проблему
# снимаем блокировку миграции
my $cmd = [ @{$self->{rem_ssh}}, 'qm', 'unlock', $vmid ];
$self->cmd_logerr($cmd, errmsg => "не удалось снять блокировку миграции");
# тут sleep, похоже, решает проблему
}

sub final_cleanup {
my ($self, $vmid) = @_;
# sleep здесь приводит к сбою
# ничего не делаем
}

1;

Сомневаюсь, что я провёл достаточно попыток, чтобы сделать окончательный вывод, возможно, кто-то ещё поможет это подтвердить. Если мы точно узнаем, в каком месте пауза действительно помогает, мы сможем понять, почему так происходит, и исправить это правильно.

e100

Guest

#13

10.01.2012 03:23:00

У меня было немного времени, чтобы провести дополнительные тесты, и теперь я гораздо увереннее в локализации проблемы. В phase3_cleanup в /usr/share/perl5/PVE/QemuMigrate.pm Код:
# снять блокировку миграции
my $cmd = [ @{$self->{rem_ssh}}, 'qm', 'unlock', $vmid ];
$self->cmd_logerr($cmd, errmsg => "не удалось снять блокировку миграции");

Если я делаю задержку (sleep) перед этим, миграция проходит нормально. Если задержка после — иногда срабатывает. Я собрал данные из syslog во время успешного и во время неудачного запуска. Есть небольшие отличия. В syslog на исходном узле при неудаче и успехе одинаково. На целевом узле — немного отличаются.

Рабочая миграция с sleep(2); до этого блока кода:
Код:
Jan 9 20:20:28 vm5 qm[11322]: <root@pam> окончание задачи UPID:vm5:00002C3B:0004B7F2:4F0B925C:qmstart:100:root@pam: OK
Jan 9 20:20:38 vm5 pmxcfs[1793]: [status] получен лог
Jan 9 20:20:38 vm5 kernel: tap100i0: отсутствуют IPv6 роутеры

Ошибка при отсутствии sleep(2); в коде:
Код:
Jan 9 20:26:16 vm5 qm[12624]: <root@pam> окончание задачи UPID:vm5:00003151:00053FC7:4F0B93B8:qmstart:100:root@pam: OK
Jan 9 20:26:23 vm5 kernel: vmbr0: порт 2(tap100i0) переходит в состояние отключён
Jan 9 20:26:23 vm5 kernel: vmbr0: порт 2(tap100i0) переходит в состояние отключён
Jan 9 20:26:24 vm5 pmxcfs[1793]: [status] получен лог

Этот блок кода изменяет конфигурационный файл виртуальной машины, снимая блокировку. Возможно, задержка в pmxcfs и вызывает сбой. pmxcfs отсутствует в стандартной системе debian у FinnTux, где живая миграция работает без проблем. pmxcfs отсутствует и на Proxmox 1.9, где живая миграция тоже проходит нормально. По моим тестам, проблема возникает спонтанно примерно в то время, когда происходит какое-то редактирование через pmxcfs.

dietmar Guest	#14 0 10.01.2012 06:14:00 Я вообще не понимаю этого. Миграция уже завершена к тому моменту, и если 'qm unlock' не сработает, мы же получим сообщение об ошибке? Есть какие-нибудь подсказки в логе задачи?

e100 Guest	#15 0 10.01.2012 10:42:00 Мы оба уже признали, что сон не имеет смысла, независимо от того, где он происходит, но факт остаётся фактом — сон, кажется, действительно это устраняет. Я потратил время, чтобы найти участок кода, который, похоже, отвечает за сбой. Если я ошибаюсь, это легко доказать. Давайте не будем зацикливаться на том, что это не имеет смысла, нам нужно найти корень проблемы и только потом попытаться в этом разобраться.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры