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

PVESR - Том уже существует, Proxmox Виртуальная Среда

CharlesErickT

Guest

03.11.2017 21:17:00

Здравствуйте, я недавно настроил 2 узла (5.1). Один из них является мастером, который использует PVESR для репликации на другой узел-работник. Всё работало неделю, но теперь один из KVM не может реплицироваться на узел-работник. Я получаю ошибку, что объем уже существует, но, как я понимаю, это нормально, поскольку он должен переписать его. Вот логи моей задачи Код: 2017-11-03 16:04:01 128-0: запуск задачи репликации 2017-11-03 16:04:01 128-0: гость => VM 128, работает => 6216 2017-11-03 16:04:01 128-0: объемы => local-zfs:vm-128-disk-1 2017-11-03 16:04:02 128-0: заморозка файловой системы гостя 2017-11-03 16:04:10 128-0: создание снимка '__replicate_128-0_1509739441__' на local-zfs:vm-128-disk-1 2017-11-03 16:04:10 128-0: разморозка файловой системы гостя 2017-11-03 16:04:14 128-0: полная синхронизация 'local-zfs:vm-128-disk-1' (__replicate_128-0_1509739441__) 2017-11-03 16:04:15 128-0: полная отправка rpool/data/vm-128-disk-1@__replicate_128-0_1509739441__ предполагаемый размер 79.8G 2017-11-03 16:04:15 128-0: общий предполагаемый размер 79.8G 2017-11-03 16:04:15 128-0: ВРЕМЯ ОТПРАВКИ СНИМКИ 2017-11-03 16:04:15 128-0: rpool/data/vm-128-disk-1 имя rpool/data/vm-128-disk-1 - 2017-11-03 16:04:15 128-0: объем 'rpool/data/vm-128-disk-1' уже существует 2017-11-03 16:04:15 128-0: предупреждение: не удается отправить 'rpool/data/vm-128-disk-1@__replicate_128-0_1509739441__': получен сигнал 2017-11-03 16:04:15 128-0: не удается отправить 'rpool/data/vm-128-disk-1': ошибка ввода-вывода 2017-11-03 16:04:15 128-0: команда 'zfs send -Rpv -- rpool/data/vm-128-disk-1@__replicate_128-0_1509739441__' завершилась неудачей: код выхода 1 2017-11-03 16:04:15 128-0: удалить предыдущий снимок репликации '__replicate_128-0_1509739441__' на local-zfs:vm-128-disk-1 2017-11-03 16:04:16 128-0: завершение задачи репликации с ошибкой: команда 'set -o pipefail && pvesm export local-zfs:vm-128-disk-1 zfs - -with-snapshots 1 -snapshot __replicate_128-0_1509739441__ | /usr/bin/ssh -o 'BatchMode=yes' -o 'HostKeyAlias=dev-proxmox-2' root@192.168.1.173 -- pvesm import local-zfs:vm-128-disk-1 zfs - -with-snapshots 1' завершилась неудачей: код выхода 255. Судя по всему, он пытается отправить весь диск снова (который уже существует на целевом узле), вместо того чтобы просто отправить снимок. А вот и моя версия pve -v Код: proxmox-ve: 5.1-25 (работает ядро: 4.13.4-1-pve) pve-manager: 5.1-35 (работающая версия: 5.1-35/722cc488) pve-kernel-4.13.4-1-pve: 4.13.4-25 libpve-http-server-perl: 2.0-6 lvm2: 2.02.168-pve6 corosync: 2.4.2-pve3 libqb0: 1.0.1-1 pve-cluster: 5.0-15 qemu-server: 5.0-17 pve-firmware: 2.0-3 libpve-common-perl: 5.0-20 libpve-guest-common-perl: 2.0-13 libpve-access-control: 5.0-7 libpve-storage-perl: 5.0-16 pve-libspice-server1: 0.12.8-3 vncterm: 1.5-2 pve-docs: 5.1-12 pve-qemu-kvm: 2.9.1-2 pve-container: 2.0-17 pve-firewall: 3.0-3 pve-ha-manager: 2.0-3 ksm-control-daemon: 1.2-2 glusterfs-client: 3.8.8-1 lxc-pve: 2.1.0-2 lxcfs: 2.0.7-pve4 criu: 2.11.1-1~bpo90 novnc-pve: 0.6-4 smartmontools: 6.5+svn4324-1 zfsutils-linux: 0.7.2-pve1~bpo90 У вас есть идеи, что может это вызывать? Также есть ли способ получить уведомление по электронной почте о сбое синхронизации задач? Спасибо.

rholighaus

Guest

03.03.2018 15:05:00

Я продолжаю сталкиваться с одной и той же проблемой. Репликация происходит каждые 10 минут, а затем внезапно дает сбой, сообщая "том xxx уже существует", пытаясь выполнить полную репликацию, хотя это не было бы необходимо. За 10 минут до этого все работало. Я уже открыл заявку, но думаю, что это баг в PVE. Хотелось бы, чтобы была возможность ручного восстановления, чтобы избежать необходимости уничтожать целевую файловую систему/том и снова пересылать кучу данных каждый раз, когда это происходит.

Davyd

Guest

05.03.2018 08:53:00

Эта проблема возникает, когда целевое хранилище имеет определённую загрузку. Как я вижу, pvesr выполняет следующие шаги: 1. Создаёт снимок на исходном хранилище 2. Отправляет его на целевое 3. Удаляет предыдущий снимок из целевого хранилища — здесь возникла ошибка по времени в 10 секунд! Операция zfs destroy из вашего хранилища иногда занимает больше времени. 4. pvesr получил ошибку таймаута на шаге 3 и удалил все снимки, которые он создал в этой итерации, как на исходном, так и на целевом хранилище. 5. Но операция zfs destroy на шаге 3 тоже завершилась успешно (но заняла больше 10 секунд). Теперь у нас есть целевое хранилище без каких-либо снимков состояния, что мешает применению будущих инкрементальных снимков. Вам нужно удалить целевое хранилище и сделать полную синхронизацию снова.

Davyd Guest	#4 0 05.03.2018 08:57:00 Будет здорово, если команда Proxmox внесет некоторые улучшения, чтобы мы могли настраивать этот тайм-аут для хранилища.

rholighaus

Guest

05.03.2018 09:13:00

@PVE team: Высокая нагрузка на хост назначения, в результате которой репликация ломается, — это неприемлемое поведение. Необходимо пересылать сотни гигабайт данных из-за отсутствия восстановительного механизма — это явно не решение и совершенно непрактично в производственной среде. Предлагаю исправить баг, в результате которого высокая нагрузка на машину назначения может необратимо нарушить репликацию. Пожалуйста, постарайтесь найти способ восстановления после тайм-аута, а не ломать репликацию. Если на исправление потребуется время, я предлагаю срочно 1) разработать ручной механизм восстановления, который позволит избежать пересылки всего заново, или даже 2) создать механизм автоматического восстановления. Спасибо!

wolfgang Guest	#6 0 05.03.2018 09:14:00 Привет, Давид, спасибо за анализ. Я проверю и посмотрю, как мы можем справиться с этой задержкой. Можешь также открыть тикет о баге на https://bugzilla.proxmox.com/

SiriusNZ Guest	#7 0 10.03.2018 19:29:00 Та же проблема в домашней лаборатории, когда становится многолюдно, не могу найти отчет о баге в Bugzilla, кто-нибудь его оформлял (чтобы я не создавал дубликат)?

Davyd Guest	#8 0 10.03.2018 19:59:00 Я сейчас в отпуске, так что, пожалуйста, сделай это. Я добавлю, если понадобится.

SiriusNZ

Guest

10.03.2018 20:39:00

Зарегистрирован баг. https://bugzilla.proxmox.com/show_bug.cgi?id=1694 Возможно, решение заключается в реализации контрольной точки — когда репликация с номером n завершена успешно, удаляйте снимки из репликации с n-1 или даже n-2, а не n.

wolfgang Guest	#10 0 12.03.2018 07:31:00 Спасибо за отчет.

rholighaus Guest	#11 0 12.03.2018 07:37:00 Очень хорошая идея!

rholighaus

Guest

#12

19.03.2018 09:59:00

Частично связано, и, возможно, стоит подать запрос на улучшение: если репликация завершается неудачей, например, в 1:55, система пытается снова и снова выполнить полную синхронизацию, что, как видно, не удается, при этом каждый раз перезаписывая предыдущий файл журнала репликации, что делает невозможным предоставление информации журнала о причине сбоя репликации при первом возникновении проблемы из-за таймаута. Непрерывный журнал для каждой репликации, который будет вращаться с помощью logrotate, вероятно, был бы более полезным...

Rufus Ebonhawk Guest	#13 0 15.05.2018 09:32:00 Мы сталкиваемся с той же проблемой. Есть какие-то новости?

wolfgang Guest	#14 0 15.05.2018 10:28:00 Баг-трекер помечен как "Обратная связь". Это значит, что проблема исправлена и ждет отзывов. Все версии pve-guest-common > 2.0-15 исправлены.

SiriusNZ

Guest

#15

07.06.2018 12:08:00

Спасибо, Вольфганг. Извини, что не дал обратную связь — я перепрыгнул на Ceph, так как именно это используется на моей работе, и мне нужно было с этим познакомиться. Но если у меня будет возможность вернуть часть хранилища на pvesr, я попробую.

tonci

Guest

#16

23.06.2018 22:41:00

Здравствуйте всем, у меня по-прежнему та же проблема, что и у всех, кто её описывал. Я действительно рассчитываю на pvesr репликацию, ведь эта функция — настоящий шаг вперёд к "2Node-HA". Это означает, что оба хоста и хранилище могут считаться избыточными (не на 100%, но уровень избыточности очень высокий). В рамках моих клиентов я могу считать это 99% избыточным. Репликация zfs настолько быстрая и эффективная, что я запускаю её каждые 5 минут. Офлайн-миграция (я могу себе это позволить) работает, и задания синхронизации отлично настраиваются и обновляются. Для теста я создаю тестовую виртуальную машину на другом узле и запускаю её между двумя репликациями с изображением, скопированным с оригинальной ВМ; она работает корректно, я вношу некоторые изменения на диске и выключаю её. После следующей репликации эти изменения перезаписываются оригинальной формой ВМ. Всё работает, как и ожидалось, и даже лучше. Но если возникают упомянутые выше ошибки, а они, к сожалению, возникают, эта избыточность, на которую я рассчитываю, уменьшается. В моём случае мне не пришлось удалять задания синхронизации, но я был вынужден удалить все ВМ-реплики на целевом хосте. (при этом на целевом хосте не было нагрузки, он просто собирал реплики, и HA не был задействован). После этого начинается полная синхронизация, и в это время (и в тот момент, когда мы не знали, что произошли ошибки) мы не защищены так, как хотели бы. Кроме того, если мы получаем уведомление о том, что инкрементальная синхронизация не удалась, ситуация ухудшается (в терминах риска). Это не было бы так плохо, если бы полная синхронизация начиналась сама по себе, но этого не происходит, потому что она ждёт, пока мы сделаем "что-то". Честно говоря, я думаю, что улучшение сценария 2node-HA таким образом могло бы помочь нам очень сильно. Есть много малых и средних предприятий, которые слишком малы, чтобы иметь общую san-хранение или что-то подобное, но они достаточно большие, чтобы иметь больше одного сервера. Как только у них два сервера, стабильный pvesr может действительно предложить многое с точки зрения избыточности. Надеюсь, мы увидим какой-то прогресс по этому вопросу тоже. Большое спасибо за ваше понимание и поддержку. С уважением, Тончи Стипичевич.

wolfgang

Guest

#17

25.06.2018 08:23:00

В ни одном мире не существует двухузлового кластера "HA". Это невозможно сделать с двумя узлами HA. Вы можете запустить два узла без HA, но никогда с HA. Я не совсем понимаю вашу проблему, потому что вы говорите о своем сценарии, но не о самой проблеме. Вам нужно предоставить действительно отлаживаемую информацию. Также, пожалуйста, создайте новую тему, потому что, как вы сказали, ваш пул не подвержен высокой нагрузке. Эта проблема здесь касалась высокой нагрузки на zfs пулах.

tonci Guest	#18 0 25.06.2018 11:29:00 Привет, Вольфганг, не переживай из-за моей "ошибки", ты прав, конечно... нет кластера с двумя узлами, но в этом сценарии будет RPI как третий узел (узел кворума), но будет всего 2 "данных" узла. Когда я прочитал эту тему, у меня не было сомнений, подхожу ли я или нет. Я получил точно такую же ошибку, как CharlesErickT, который открыл эту тему. Вдруг, "может быть без причины" хост решил начать полную репликацию вместо инкрементальной (и после этого она проваливается). Как я уже говорил, нагрузки на приемнике не было, но результат был неудачным, как и у всех. Кстати, читая эту тему, могу задать вопрос: что заставило тебя думать, что высокая нагрузка была единственной причиной этого поведения? В моем сценарии без высокой нагрузки появилась такая же ошибка. Второй кстати, по моему мнению, было бы полезно, если бы мы оставляли еще несколько снимков после репликаций... Итак, мой сценарий: HA (или не HA) кластер из 2 узлов с pvesr между двумя узлами. Моя проблема: вдруг репликация проваливается, лог говорит, что хост пытается запустить полную репликацию, но это не удается. Я использую последние патчи без подписки. Если ты всё еще думаешь, что мне стоит открыть новую тему, пожалуйста, дай знать. С уважением и спасибо заранее, Тончи.

Читают тему

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