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

Обновление Gluster возможно?, Proxmox Виртуальная Среда

_dist

Guest

01.08.2014 21:06:00

Сначала позвольте кратко объяснить мою конфигурацию. У нас запущен 3-узловой кластер (сейчас HA отключён). Все три узла используют том Gluster replicate для хранения ВМ. Причина, по которой я выбрал proxmox — это то, что на момент выбора это был единственный UI с полной поддержкой libgfapi. Всё работает довольно хорошо, но есть две серьёзные проблемы, связанные с багами Gluster:

1) Статус восстановления (heal) отображается некорректно для больших занятых файлов (особенно виртуальных машин). Это связано с парой проблем, которые исправлены в версии 3.5*.

2) Изменение структуры тома (добавление, замена, удаление bricks) в версии 3.4* работает нестабильно, например — https://bugzilla.redhat.com/show_bug.cgi?id=1104861.

Меня уже пару раз «жгло» (пока обошлось без серьёзных последствий) из-за обеих этих проблем с момента запуска, и сейчас я сражаюсь с очередным пожаром, вызванным проблемой №2.

http://download.proxmox.com/debian/dists/wheezy/pve-no-subscription/binary-amd64/ — там есть версия 3.4.2-1 (самая свежая). У меня нет корпоративной подписки, поэтому не знаю, есть ли там что-то свежее или с backport-фиксами. Я не уверен, какие параметры конфигурации использовались при компиляции qemu/gluster (но, кстати, очень бы хотелось дебаг-версии пакетов).

Понимаю, что сборки Proxmox, скорее всего, проходят проверку, и, возможно, уже ведётся проверка версии 3.5.2. Но проблема №1 особенно критична для платформы, которая хостит ВМ.

Пожалуйста, дайте знать, если я где-то ошибаюсь или если есть что-то, чем могу помочь.

dietmar Guest	#2 0 21.08.2014 10:03:00 Завтра загружу пакет glusterfs 3.5.2 на pvetest (для тестирования).

dietmar Guest	#3 0 21.08.2014 19:27:00 Я смог воспроизвести эту ошибку — буду проводить дополнительные тесты...

mir Guest	#4 0 21.08.2014 19:35:00 Может ли эта ошибка быть связана с моими проблемами при выполнении живой миграции контейнера (CT), работающего на GlusterFS?

Frank77 Guest	#5 0 21.08.2014 21:28:00 Да, конечно. Вот почему я пока оставил на своих серверах Proxmox последнюю версию gluster из ветки 3.4.

mir Guest	#6 0 22.08.2014 00:07:00 CT — 64-битный. Установить 32-битный CT на glusterfs можно, но это полностью провалится. Подробнее смотрите https://bugzilla.openvz.org/show_bug.cgi?id=3036

mir

Guest

21.08.2014 23:18:00

Я только что скачал последнюю версию glusterfs с git.proxmox.com, собрал и установил пакеты:

glusterd -V
glusterfs 3.5.2, собран 21 августа 2014, 23:10:43
Репозиторий: git://git.gluster.com/glusterfs.git
Copyright © 2006-2013 Red Hat, Inc. <http://www.redhat.com/>
GlusterFS поставляется БЕЗ КАКИХ-ЛИБО ГАРАНТИЙ. Лицензируется по вашему выбору либо по GNU Lesser General Public License версии 3 или новее (LGPLv3 или позже), либо по GNU General Public License версии 2 (GPLv2), во всех случаях опубликованной Free Software Foundation.

Затем попытался мигрировать CT и получил следующий результат:

21 авг 23:15:08 начало миграции CT 137 на узел 'esx2' (172.16.3.9)
21 авг 23:15:08 контейнер работает — используется онлайн-миграция
21 авг 23:15:08 данные контейнера на общем хранилище 'gfs1'
21 авг 23:15:08 запуск живой миграции — приостановка контейнера
21 авг 23:15:08 сохранение состояния контейнера
21 авг 23:15:09 # vzctl --skiplock chkpnt 137 --dump --dumpfile /mnt/pve/gfs1/dump/dump.137
21 авг 23:15:08 настройка контрольной точки...
21 авг 23:15:08 объединение контекста...
21 авг 23:15:08 дамп...
21 авг 23:15:09 Не удаётся сохранить дамп контейнера: неверный аргумент
21 авг 23:15:09 Ошибка: BUG: no socket index
21 авг 23:15:09 ОШИБКА: не удалось сохранить состояние контейнера: контрольная точка не удалась
21 авг 23:15:09 прерывание фазы 1 — очистка ресурсов
21 авг 23:15:09 начало окончательной очистки
21 авг 23:15:09 ОШИБКА: миграция прервана (длительность 00:00:01): не удалось сохранить состояние контейнера: контрольная точка не удалась
TASK ERROR: миграция прервана

Та же самая ошибка, что и с gluster-3.4.2!! Что делать?

kobuki Guest	#8 0 21.08.2014 23:57:00 Возможно, это имеет значение, а возможно и нет, но мигрированная CT — 64-битная или 32-битная?

_dist

Guest

19.08.2014 02:05:00

Спасибо, как виртуальный хост хранения, мы очень хотим перейти на 3.5.x, потому что информация о восстановлении тома просто не работает в 3.4.x. Проблема не в том, что вы, возможно, компилировали glusterfs-server (хорошо, что вы использовали стандартные deb-пакеты), а в том, что, я подозреваю, вы должны были компилировать qemu (и его придется перекомпилировать с новыми файлами api/src в gluster 3.5.x). Вместо того чтобы самому методом проб и ошибок разбираться, не могли бы вы предоставить опции ./configure, которые использовались при компиляции? http://download.proxmox.com/debian/...ion/binary-amd64/pve-qemu-kvm_1.7-8_amd64.deb Которые, насколько я понимаю из kvm --version, взяты отсюда: http://wiki.qemu-project.org/download/qemu-1.7.1.tar.bz2 (и никаких изменений в исходниках не вносилось?) Конечно, я мог бы просто попробовать перекомпилировать из исходников, когда появится gluster 3.5.2, но мне было бы спокойнее знать, что моя перекомпиляция максимально близка к стоку proxmox. Спасибо!

_dist

Guest

#10

20.08.2014 00:12:00

Итак, вот моя сегодняшняя конфигурация:
Node 1 (запущен glusterfs 3.4.2 и qemu 1.7.1 стандартный)
Node 2 (то же самое)
Node 3 (запущен glusterfs 3.5.2 из репозитория gluster, но qemu 1.7.1 стандартный)

Моё лучшее предположение — что qemu libgfapi указывает на сервер (в моём случае я использую localhost), потому что на Node 1 и 2 qemu без проблем запускает виртуальные машины на томе, который полностью расположен на gluster Node 3. Однако Node 3 даже с собственным локальным томом не может нормально стартовать ВМ.

Моя теория — что proxmox qemu libgfapi устарел и несовместим с новым серверным API. Но это лишь предположение, чтобы проверить, мне нужно собрать свою версию на основе новых api/src файлов. Думаю, что простая компиляция будет достаточно, но если у кого-то есть идеи, дайте знать, я буду держать эту тему в курсе.

Дополнение: Забейте, я только что нашёл https://git.proxmox.com/?p=pve-qemu-kvm.git;a=shortlog — спасибо!

dietmar Guest	#11 0 20.08.2014 07:50:00 Я только что заметил, что мы собираем собственную версию пакетов clusterfs. Мы делаем бэкапорт из Debian Sid в Wheezy: https://git.proxmox.com/?p=glusterfs.git;a=summary. Извиняюсь за вводящую в заблуждение информацию.

_dist

Guest

#12

20.08.2014 21:16:00

Я точно не понимаю, в чём именно проблема, но симптомы таковы: QM сообщает о тайм-ауте, хотя машина запускается нормально. Эта проблема мешает и живой миграции. В этом сообщении была что-то очень похожее (но не совсем такая же ошибка) http://forum.proxmox.com/threads/18526-The-problem-with-the-disk-migration-on-glusterfs Ошибка, которую я получаю, звучит так: "failed: got timeout". Если я запускаю команду kvm точно так, как её выдает qm, всё работает нормально (как и машина нормально запускается через QM; но всё равно выдает ошибку). Почему QM решает, что произошёл "failed: got timeout"? Может, это просто проблема с конфигурацией? Редактирование: может, стоит объединить это с http://forum.proxmox.com/threads/18486-qm-start-fails-with-timeout-error-but-vm-is-actually-started <-- именно эта проблема у меня и есть.

Frank77

Guest

#13

21.08.2014 09:48:00

Привет. Мы обсуждали эту проблему на IRC-канале gluster. Забыл упомянуть, что пытался разобраться с помощью strace. Вот что я обнаружил. При первом запуске процесса я видел следующие системные вызовы. Команда: qm start 161, PID: 38662, Код: ...

pipe([6, 7]) = 0
pipe([8, 10]) = 0
...
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f19bef0e9d0) = 38663
...
close(7) = 0
close(8) = 0
read(6, "UPID:prox2:00009707:001037D4:53F"..., 4096) = 60
...
open("/var/log/pve/tasks/C/UPID:prox2:00009707:001037D4:53F3541C:qmstart:161:root@pam:", O_WRONLY|O_CREAT|O_EXCL, 0640) = 7
...
write(10, "OK", 2) = 2
close(10) = 0

// Затем он пытается еще раз что-то прочитать у дочернего процесса, но получает таймаут примерно 30 раз.
...
select(8, [6], NULL, NULL, {1, 0}) = 0 (Таймаут) PID : 38663 (PPID : 38662) Код: ...
write(1, "UPID:prox2:00009707:001037D4:53F"..., 60) = 60
read(8, "OK", 4096) = 2
...
pipe([15, 16])
pipe([13, 14])
...
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f19bef0e9d0) = 38666
close(14) = 0
close(16) = 0
...
select(16, [13 15], NULL, NULL, {1, 0}) = 0 (Таймаут)
select(16, [13 15], NULL, NULL, {1, 0}) = 1 (на [13], осталось {0, 412061})
--- SIGCHLD (Дочерний процесс завершился) @ 0 (0) ---
// То же примерно 30 раз
select(16, [15], NULL, NULL, {1, 0}) = 0 (Таймаут)

// Тут я не понимаю, как он должен что-то получить от уже мертвого процесса... PID : 38666 (PPID : 38663) Код: ...
execve("/usr/bin/kvm", ["/usr/bin/kvm", "-id", "161", "-chardev", "socket,id=qmp,path=/var/run/qemu"..., "-mon", "chardev=qmp,mode=control", "-vnc", "unix:/var/run/qemu-server/161.vn"..., "-pidfile", "/var/run/qemu-server/161.pid", "-daemonize", "-name", "7-test", "-smp", "sockets=1,cores=4", ...], [/* 16 vars */]) = 0

// Здесь мы уже в программе KVM.
dup2(16, 2) = 2
dup(16) = 12
fcntl(16, F_GETFD) = 0x1 (flags FD_CLOEXEC)
dup2(12, 16) = 16
fcntl(16, F_SETFD, FD_CLOEXEC) = 0
close(12) = 0
fcntl(2, F_SETFD, 0) = 0

// Мы должны что-то ждать на файловых дескрипторах 2 или 16, но пока я ничего не обнаружил...
...
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fa845e1bbd0) = 38667

// А дальше в последующих процессах я вообще не вижу вывода или операций с дескрипторами 2 или 16.

EDIT: Забываю выложить, что мы должны видеть при успешном запуске для сравнения с первым процессом. Код:

select(8, [6], NULL, NULL, {1, 0}) = 1 (на [6], осталось {0, 694391})
read(6, "TASK OK\n", 4096) = 8
write(7, "TASK OK\n", 8) = 8
select(8, [6], NULL, NULL, {1, 0}) = ? ERESTARTNOHAND (Перезапуск)
--- SIGCHLD (Дочерний процесс завершился) @ 0 (0) ---

kobuki Guest	#14 0 22.08.2014 00:13:00 Да, я в курсе. Комментировал это в вашей теме. Мне показалось, что это может как-то быть связано с той проблемой (64-битные указатели inode не всегда работают в 32-битном CT).

dietmar Guest	#15 0 22.08.2014 12:42:00 Похоже, что опция qemu -daemonize работает некорректно при использовании gluster://, не закрывая stdout... Попробую найти решение.

dietmar Guest	#16 0 22.08.2014 13:48:00 Надеюсь, это правильное исправление: https://git.proxmox.com/?p=pve-qemu-kvm.git;a=commitdiff;h=a6dc6b08d8fd141e5b176cb8910d2d7bc7e63fd5

mir Guest	#17 0 22.08.2014 16:18:00 К сожалению, у меня нет тестовой среды с glusterfs, да и я трус, поэтому не могу проверить этот патч.

Frank77

Guest

#18

23.08.2014 23:10:00

Пытаюсь скомпилировать проект pve-qemu-kvm. Не знаю, какие опции ./configure нужно задать для правильной установки. Вообще-то хотел просто сделать тест, но, похоже, не хватает зависимости. Не могу найти, где должен быть определён тип GSequence. Вот ошибка из вывода make.

Код:
qemu-img.c: В функции ‘compare_data’:
qemu-img.c:61:5: предупреждение: неявное объявление функции ‘g_strcmp0’ [-Wimplicit-function-declaration]
qemu-img.c:61:5: предупреждение: вложенное внешнее объявление ‘g_strcmp0’ [-Wnested-externs]
qemu-img.c: В функции ‘add_format_to_seq’:
qemu-img.c:71:5: ошибка: неизвестный тип ‘GSequence’
qemu-img.c:73:5: предупреждение: неявное объявление функции ‘g_sequence_insert_sorted’ [-Wimplicit-function-declaration]
qemu-img.c:73:5: предупреждение: вложенное внешнее объявление ‘g_sequence_insert_sorted’ [-Wnested-externs]
qemu-img.c: В функции ‘help’:
qemu-img.c:159:5: ошибка: неизвестный тип ‘GSequence’
qemu-img.c:162:5: предупреждение: неявное объявление функции ‘g_sequence_new’ [-Wimplicit-function-declaration]
qemu-img.c:162:5: предупреждение: вложенное внешнее объявление ‘g_sequence_new’ [-Wnested-externs]
qemu-img.c:162:9: предупреждение: присваивание указателя из целочисленного значения без преобразования типа [включено по умолчанию]
qemu-img.c:164:5: предупреждение: неявное объявление функции ‘g_sequence_foreach’ [-Wimplicit-function-declaration]
qemu-img.c:164:5: предупреждение: вложенное внешнее объявление ‘g_sequence_foreach’ [-Wnested-externs]
qemu-img.c:166:5: предупреждение: неявное объявление функции ‘g_sequence_free’ [-Wimplicit-function-declaration]
qemu-img.c:166:5: предупреждение: вложенное внешнее объявление ‘g_sequence_free’ [-Wnested-externs]
make: *** [qemu-img.o] Erreur 1

RRJ Guest	#19 0 26.08.2014 10:06:00 Та же проблема с glusterfs 3.5.2. Proxmox выдает таймаут, но ВМ на самом деле запускается. TASK ERROR: запуск не удался: команда '/usr/bin/kvm -id 127 -chardev 'socket,id=qmp,path=/var/run/qemu-server/127.qmp,server,nowait' -mon 'chardev=qmp,mode=control' -vnc unix:/var/run/qemu-server/127.vnc,x509,password -pidfile /var/run/qemu-server/127.pid -daemonize -name gfs-HD-on-114 -smp 'sockets=1,cores=2' -nodefaults -boot 'menu=on' -vga cirrus -cpu host,+x2apic -k en-us -m 1024 -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' -device 'usb-tablet,id=tablet,bus=uhci.0,port=1' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3' -drive 'if=none,id=drive-ide2,media=cdrom,aio=native' -device 'ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,bootindex=200' -drive 'file=gluster://stor1/HA-FAST-PVE1-150G/images/127/vm-127-disk-1.qcow2,if=none,id=drive-virtio0,format=qcow2,aio=native,cache=none' -device 'virtio-blk-pci,drive=drive-virtio0,id=virtio0,bus=pci.0,addr=0xa,bootindex=100' -netdev 'type=tap,id=net0,ifname=tap127i0,script=/var/lib/qemu-server/pve-bridge,vhost=on' -device 'virtio-net-pci,mac=E2:97:5E:02:25:A5,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=300'' завершилась неудачей: получен таймаут. Есть ли исправленный .deb?

Читают тему

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