Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    Репликация хранилища регулярно останавливается

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Репликация хранилища регулярно останавливается, Proxmox Виртуальная Среда
     
    FastLaneJB
    Guest
    #1
    0
    06.08.2017 03:34:00
    Это отличная функция, и я понимаю, что она пока экспериментальная, но у меня регулярно перестает синхронизироваться весь мой список виртуальных машин. Мне приходится перезапускать сервис pvesr, после чего всё снова работает день или два, а потом снова перестает. Мне кажется, что она просто застревает на операции заморозки файловой системы у некоторых контейнеров, и из-за этого перестают работать все.

    Например, сейчас 2017-08-06, когда я это пишу, и вот последний лог-файл, который я вижу:

    Код:
    2017-08-03 05:30:01 700-0: start replication job  
    2017-08-03 05:30:01 700-0: guest => CT 700, running => 1  
    2017-08-03 05:30:01 700-0: volumes => main:subvol-700-disk-1  
    2017-08-03 05:30:02 700-0: freeze guest filesystem  

    Думаю, проблема возникает, когда репликация совпадает с задачей резервного копирования, поскольку этот контейнер настроен на бэкап ровно в 05:30 каждый день.

    Конфиг replication.cfg для этого контейнера такой:

    Код:  
    local: 700-0  
    target kt-proxmox-02  
    rate 10  

    То есть репликация запускается каждые 15 минут по умолчанию. Думаю, в коде репликации нужно проверить, не выполняется ли в этот момент резервное копирование, и если да — пропускать репликацию. Или ещё лучше — чтобы репликация запускалась одновременно с бэкапом, но с каким-то алгоритмом, который не замораживает файловую систему в одно и то же время, а просто немного задерживает репликацию, пока завершится заморозка у резервного копирования.
     
     
     
    le_top
    Guest
    #2
    0
    25.10.2017 00:02:00
    У меня примерно такой же опыт. Это может быть связано с "перезагрузками" целевой машины, из-за чего приходится удалять все zfsStorageCopies перед тем, как снова запустить репликацию (используя команду типа "zfs destroy vmpool/subvol-102-disk-1"). Очень раздражает, и было бы здорово, если бы был какой-то автоматический механизм восстановления.
     
     
     
    dendi
    Guest
    #3
    0
    25.10.2017 10:31:00
    Привет! Мой кластер из 4 узлов отлично работает с репликацией ZFS. Даже после перезагрузки целевой машины всё нормально. Я использую KVM.
     
     
     
    le_top
    Guest
    #4
    0
    25.10.2017 13:04:00
    Хорошо, что где-то это работает ;-). У меня стоит Proxmox 5.0-33. Сейчас у меня один LXC синхронизируется на ZFS уже 7 часов по центральноевропейскому времени, сейчас 13:00 CET (машины синхронизируются каждые 15 минут, остальные машины в последний раз синхронизировались в 6:45). Предыдущая синхронизация заняла 6,8 секунд согласно таблице репликации. Лог показывает, что один бэкап (не репликация) начался примерно в 6:00 и закончился спустя 3,5 минуты, а другой бэкап начался в 7:00:01 и длился примерно 13 минут для той машины (удалённое хранилище, поэтому медленнее). Получается, что именно бэкап негативно влияет на репликацию. Думаю, что снапшот для бэкапа создаётся не полностью независимо от репликации. Настроить расписание так, чтобы этого не происходило, сложно, ведь бэкап всех машин занимает несколько часов. Поэтому всегда есть вероятность, что снапшот для бэкапа создаётся в критический для репликации момент (когда бы он ни был). Репликацию нужно останавливать на время бэкапа. Определить подходящее расписание для cron — тоже не простая задача, как мне кажется. Есть идеи, как этого избежать?
     
     
     
    dendi
    Guest
    #5
    0
    25.10.2017 13:36:00
    Резервное копирование не делает снимок на уровне хранилища, оно использует функцию kvm для "заморозки" виртуальной машины и перехвата записей во время резервного копирования. Я не пользуюсь резервными копиями, потому что дополнительно применяю pve-zsync ночью для удалённого хранилища, где хранятся снимки за последние несколько дней.
     
     
     
    le_top
    Guest
    #6
    0
    25.10.2017 14:38:00
    Окей, в моём отчёте по бэкапу написано «режим бэкапа: snapshot». Вот транскрипт (время начала: 07:00 CEST). Названия серверов изменены на example.com для конфиденциальности:

    INFO: запускаю новую задачу бэкапа: vzdump --compress gzip --mailto support@example.com --mailnotification failure --node p4 --storage p4BackupFtp --mode snapshot --quiet 1 --exclude 200 --all 1  
    INFO: Начинаю бэкап ВМ 102 (lxc)  
    INFO: статус = running  
    INFO: имя контейнера: example.com  
    INFO: режим бэкапа: snapshot  
    INFO: приоритет ionice: 7  
    INFO: создаю снапшот хранилища 'vzdump'  
    INFO: создаю архив '/mnt/pve/p4BackupFtp/dump/vzdump-lxc-102-2017_10_25-05_00_01.tar.gz'  
    INFO: Всего записано байт: 17194987520 (17ГиБ, 22МиБ/с)  
    INFO: размер файла архива: 8.09ГБ  
    INFO: удаляю старый бэкап '/mnt/pve/p4BackupFtp/dump/vzdump-lxc-102-2017_10_24-05_00_01.tar.gz'  
    INFO: удаляю снапшот vzdump  
    INFO: Бэкап ВМ 102 завершён (00:12:55)
     
     
     
    le_top
    Guest
    #7
    0
    25.10.2017 19:35:00
    Согласно WebGui, VM102 всё ещё синхронизируется в 19:30 по центральноевропейскому летнему времени. Пока не нашёл команду, чтобы это исправить. Заметил, что можно получить лог синхронизации — она застряла на шаге «freeze»:

    2017-10-25 05:00:00 102-0: старт задачи репликации  
    2017-10-25 05:00:00 102-0: гостевая система => CT 102, запущена => 1  
    2017-10-25 05:00:00 102-0: тома => ZfsStorage:subvol-102-disk-1  
    2017-10-25 05:00:00 102-0: заморозка гостевой файловой системы
     
     
     
    FastLaneJB
    Guest
    #8
    0
    25.10.2017 20:01:00
    Безусловно, для резервных копий LXC используются снимки на уровне хранилища. KVM — это только половина Proxmox.
     
     
     
    le_top
    Guest
    #9
    0
    26.10.2017 10:35:00
    У меня теперь сбой резервного копирования. Думаю, это связано с тем, что репликация, которая началась вчера, до сих пор идёт, судя по WebGUI (вероятно, в состоянии «заморозить файловую систему гостевой ОС»). Вот текст письма, которое я получил: не могу получить блокировку '/var/run/vzdump.lock' — время ожидания истекло. VMID NAME STATUS TIME SIZE FILENAME TOTAL 00:00:00 0KB Подробные логи резервного копирования: vzdump --mode snapshot --storage p4BackupFtp --mailto support@example.com --quiet 1 --exclude 200 --node p4 --all 1 --mailnotification failure --compress gzip Это содержимое лога резервного копирования: Task viewer: Backup OutputStatus Stop INFO: пытаюсь получить глобальную блокировку — жду... ERROR: не могу получить блокировку '/var/run/vzdump.lock' — время ожидания истекло.
     
     
     
    le_top
    Guest
    #10
    0
    26.10.2017 12:01:00
    Ок, я сделал «lsof» по файлу блокировки:  
    # lsof /var/run/vzdump.lock  
    COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME  
    task U 9077 root    5wW  REG   0,23        0 1923 /run/vzdump.lock  

    Потом я поискал процессы:  
    # ps -edalf | grep 9077  
    5 S root      9077  8930  0  80   0 - 81338 poll_s 04:00 ?        00:00:00 task  
    UPID 4:00002375:0474C324:59F15DC1:vzdump::root@pam:  
    4 S root      9094  9077  0  80   0 - 10441 hrtime 04:00 ?        00:00:01 /usr/bin/lxc-freeze -n 102  
    0 S root     32156  8075  0  80   0 -  3197 pipe_w 09:28 pts/10   00:00:00 grep 9077  

    Так что ‘lxc-freeze’ всё ещё работает, и его запустил ‘task’.

    Это помогло понять, как запускаются задачи — я изучил perl-скрипты в /usr/share/perl5/PVE и выяснил, что есть «чистый» способ остановить бэкап, который у меня не сработал:  
    # vzdump --stop 1  
    stopping backup process 9077 failed  

    (Кстати, в слове «stopping» опечатка, как и в некоторых других местах в документации vzdump, например «runing»).

    Поскольку это не сработало, я поискал информацию про «lxc-freeze» и обнаружил, что существует противоположная команда — «lxc-unfreeze», которую и попробовал:  
    lxc-unfreeze -n 102  

    В документации к lxc-freeze сказано, что она замораживает все процессы внутри контейнера, но процессы внутри всё равно продолжали нормально работать. В итоге после unfreeze процесс 9077 (lxc-freeze) исчез.

    По номеру задачи из списка процессов и поиску я нашёл лог этой задачи и его содержимое:  
    # cat /var/log/pve/tasks/1/UPID 4:00002375:0474C324:59F15DC1:vzdump::root@pam: |& more  
    INFO: starting new backup job: vzdump --mailto support@example.com --compress lzo --mode snapshot --exclude 200,108 --storage bigdisk_archive --mailnotification failure --all 1 --quiet 1  
    INFO: Starting Backup of VM 102 (lxc)  
    INFO: status = running  
    INFO: CT Name: example.com  
    INFO: backup mode: snapshot  
    INFO: ionice priority: 7  
    INFO: create storage snapshot 'vzdump'  
    snapshot create failed: starting cleanup no lock found trying to remove 'backup' lock  
    ERROR: Backup of VM 102 failed - command '/usr/bin/lxc-freeze -n 102' failed: interrupted by signal [...]

    Итого, именно задача бэкапа ожидала завершения lxc-freeze.

    С этой информацией я проверил системные логи:  
    daemon.log:Oct 26 09:41:56 p4 vzdump[9077]: ERROR: Backup of VM 102 failed - command '/usr/bin/lxc-freeze -n 102' failed: interrupted by signal
    /var/log# grep freeze *  
    daemon.log:Oct 26 09:41:56 p4 vzdump[9077]: ERROR: Backup of VM 102 failed - command '/usr/bin/lxc-freeze -n 102' failed: interrupted by signal
    daemon.log.1:Oct 21 23:25:19 p4 pvesr[23835]: lxc-freeze: 102: freezer.c: do_freeze_thaw: 64 Failed to get new freezer state for /var/lib/lxc:102
    daemon.log.1:Oct 21 23:25:19 p4 pvesr[23835]: lxc-freeze: 102: tools/lxc_freeze.c: main: 107 Failed to freeze /var/lib/lxc:102

    В общем, ничего необычного: команда не сработала из-за того, что 21 октября не удалось заморозить контейнер, а потом мы получили уведомление о сбое vzdump из-за моего lxc-unfreeze.

    Вывод: на мой взгляд, тут две проблемы:  
    1. ‘lxc-freeze’ не возвращается из состояния заморозки, не замораживает по некоторым причинам и не фиксирует эту ошибку. Возможно, это произошло из-за одновременных попыток заморозки (бэкап/репликация).  
    2. Процессы бэкапа и репликации мешают друг другу. Кажется, им стоит хотя бы на этапе заморозки подождать друг друга.
     
     
     
    le_top
    Guest
    #11
    0
    26.10.2017 12:13:00
    Я забыл проверить GUI, который показывает, что я ещё не закончил: Поэтому, хотя остановка 'lxc-freeze' с помощью 'lxc-unfreeze' останавливала задачу резервного копирования, статус репликации оставался "синхронизация". В отчёте указана продолжительность 23,0 часа, но разморозка произошла более чем через 23 часа после начала репликации. То, что в "Next Sync" стоит ожидание, связано с тем, что я отключил эту репликацию. Включение её заново запустило репликацию, и она завершилась успешно.
     
     
     
    le_top
    Guest
    #12
    0
    27.10.2017 10:41:00
    Проблема снова повторилась сегодня утром. Это подтверждает, что она системная и связана с моментом создания резервной копии. На этот раз команда 'lxc-unfreeze' не помогла — пришлось убивать сам процесс 'lxc-freeze'. Сейчас я сдвинул время репликации на одну минуту, что, вероятно, уменьшит сбои, но полностью их не исключит.
     
     
     
    fabian
    Guest
    #13
    0
    27.10.2017 11:26:00
    Спасибо, что занялись этой проблемой — пожалуйста, создайте баг-репорт и прикрепите ссылку на эту ветку! Это должно решаться добавлением большей взаимной блокировки для репликации и создания снимков.
     
     
     
    le_top
    Guest
    #14
    0
    27.10.2017 12:18:00
    Я открыл отчёт: https://bugzilla.proxmox.com/show_bug.cgi?id=1538.
     
     
     
    le_top
    Guest
    #15
    0
    05.11.2017 12:15:00
    Есть еще одна причина, по которой репликация останавливается, но я пока не знаю, где искать проблему. На данный момент решение — уничтожить ZFS-файловые системы на целевом сервере, но это плохое и небезопасное решение (человеческая ошибка вполне возможна):  
    # zfs destroy -r vmpool/subvol-103-disk-1  
    # zfs destroy -r vmpool/subvol-105-disk-1  

    Я сделал это, потому что в отчете говорится, что том 'vmpool/subvol-103-disk-1' уже существует (то же самое для другой ВМ, которая больше не реплицируется).  

    Одна из трех ВМ на этой машине продолжает реплицироваться.  

    Лог репликации  
    2017-11-05 12:04:00 103-0: старт задания репликации  
    2017-11-05 12:04:00 103-0: гость => CT 103, состояние => 1  
    2017-11-05 12:04:00 103-0: тома => ZfsStorage:subvol-103-disk-1  
    2017-11-05 12:04:01 103-0: заморозка файловой системы гостя  
    2017-11-05 12:04:02 103-0: создание снимка '__replicate_103-0_1509879840__' на ZfsStorage:subvol-103-disk-1  
    2017-11-05 12:04:02 103-0: разморозка файловой системы гостя  
    2017-11-05 12:04:02 103-0: полная синхронизация 'ZfsStorage:subvol-103-disk-1' (__replicate_103-0_1509879840__)  
    2017-11-05 12:04:02 103-0: полный отправляемый объем vmpool/subvol-103-disk-1@__replicate_103-0_1509879840__ оценивается в 1.88G  
    2017-11-05 12:04:02 103-0: общий оцениваемый размер — 1.88G  
    2017-11-05 12:04:02 103-0: ВРЕМЯ        ОТПРАВЛЕНО   СНЯТИЕ СНИМКА  
    2017-11-05 12:04:02 103-0: vmpool/subvol-103-disk-1    имя    vmpool/subvol-103-disk-1    -  
    2017-11-05 12:04:02 103-0: том 'vmpool/subvol-103-disk-1' уже существует  
    2017-11-05 12:04:02 103-0: предупреждение: невозможно отправить 'vmpool/subvol-103-disk-1@__replicate_103-0_1509879840__': получен сигнал  
    2017-11-05 12:04:02 103-0: нельзя отправить 'vmpool/subvol-103-disk-1': ошибка ввода/вывода  
    2017-11-05 12:04:02 103-0: команда 'zfs send -Rpv -- vmpool/subvol-103-disk-1@__replicate_103-0_1509879840__' завершилась с кодом 1  
    2017-11-05 12:04:02 103-0: удаление предыдущего снимка репликации '__replicate_103-0_1509879840__' на ZfsStorage:subvol-103-disk-1  
    2017-11-05 12:04:02 103-0: завершение задания репликации с ошибкой: команда 'set -o pipefail && pvesm export ZfsStorage:subvol-103-disk-1 zfs - -with-snapshots 1 -snapshot __replicate_103-0_1509879840__ | /usr/bin/ssh -o 'BatchMode=yes' -o 'HostKeyAlias=p4' root@10.0.0.4 -- pvesm import ZfsStorage:subvol-103-disk-1 zfs - -with-snapshots 1' завершилась с кодом 255
     
     
     
    le_top
    Guest
    #16
    0
    07.11.2017 21:53:00
    Сейчас у меня проблема с бэкапом, возможно, связанная с той же самой корневой проблемой: частичный результат от "pct list" такой: 104        running    snapshot-delete www. Репликация, похоже, работает. Я выполнил "pct unlock 104", чтобы разблокировать ВМ — посмотрю, заработает ли бэкап снова.
     
     
     
    le_top
    Guest
    #17
    0
    13.11.2017 19:34:00
    После очередного сбоя (возможно, ошибка оборудования) работающий бэкап прервался. В итоге машина осталась заблокирована (снял блокировку командой 'pct unlock 109'), и в GUI всё ещё отображался снимок (snapshot). Я запросил удаление этого снимка. Теперь снимка в системе уже нет, но GUI всё равно говорит, что он есть. При попытке удалить его снова вылетает ошибка, что нечего удалять. (Кстати, обычно в приложениях для одной и той же операции используют одно и то же слово, а здесь "Remove", "Destroy" и "Delete" — все для удаления снимков.)  
     
     

    Это подтверждает команда 'zfs list -t snapshot':  
    # zfs list -t snapshot  
    NAME                                                      USED  AVAIL  REFER  MOUNTPOINT  
    vmpool/subvol-100-disk-1@__replicate_100-0_1510597320__   745M      -  38.9G  -  
    vmpool/subvol-102-disk-1@__replicate_102-0_1510596960__   114M      -  16.9G  -  
    vmpool/subvol-103-disk-1@__replicate_103-0_1510597020__   952K      -  2.12G  -  
    vmpool/subvol-104-disk-1@__replicate_104-0_1510597560__  6.04M      -  4.58G  -  
    vmpool/subvol-105-disk-1@__replicate_105-0_1510597023__  97.9M      -  8.05G  -  
    vmpool/subvol-109-disk-1@__replicate_109-0_1510597565__  1.12M      -  1.09G  -  
    vmpool/subvol-120-disk-1@__replicate_120-0_1510596965__  5.53M      -  5.46G  -  
    vmpool/subvol-150-disk-1@__replicate_150-0_1510596968__  55.1M      -  3.59G  -  
    vmpool/subvol-223-disk-1@__replicate_223-0_1510596973__  2.41M      -  1.14G  -  
    vmpool/subvol-224-disk-1@__replicate_224-0_1510596976__  6.98M      -  1.40G  -  

    Удаление этого статуса из GUI будет ещё одним «удовольствием».  
    [Редактирование:] Нашёл, в чём дело: информация о снимке хранится в конфигурации контейнера, у меня это файл '/etc/pve/nodes/p4/lxc/109.conf'. Я выяснил это после изучения https://pve.proxmox.com/wiki/Linux_Container и поиска файла командой 'locate 109 | grep conf | xargs grep vzdump'.  
    Удалил информацию о снимке из конфигурационного файла (предварительно сделав бэкап), и теперь GUI уже ничего не показывает.  

    Надеюсь, теперь бэкап заработает.
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

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