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

Резервное копирование виртуальной машины vzdump не удалось — превышено время ожидания (NFS)., Proxmox Виртуальная Среда

timo-fc

Guest

11.11.2019 18:28:00

Привет, у нас такая проблема: каждые пару дней у одной из виртуалок не получается сделать бэкап. Обычно сбои случаются у разных ВМ. Хранилище для бэкапов — это NFS-сервер на отдельной машине. Причина, скорее всего, в том, что NFS-сервер не успевает вовремя отреагировать на запрос от Proxmox из-за высокой нагрузки. Можно ли как-то увеличить таймаут или добавить повторную попытку, если бэкап не удался? Бэкап следующей ВМ через пару секунд снова проходит без проблем. Насколько я понимаю, проверка, из-за которой выдает «storage 'offsite-backups' is not online», происходит через команду /sbin/showmount --no-headers --exports xxx.xxx.xxx.xxx с таймаутом 2 секунды в файле /usr/share/perl5/PVE/Storage/NFSPlugin.pm. Если это так, есть ли способ увеличить таймаут, не меняя этот файл, чтобы избежать проблем после обновлений? Proxmox 5.4-13, /etc/pve/storage.cfg, /etc/vzdump.conf — без изменений, /etc/cron.d/vzdump.

timo-fc

Guest

13.12.2019 10:30:00

Это было слишком рано, проблема всё ещё существует. Я изменил значение таймаута с 2 до 20 секунд в файле NFSPlugin.pm, перезапустил службу pvestatd, отмонтировал и снова смонтировал резервный NFS-шэр. Но всё равно получил ошибку "failed - got timeout" между двумя успешными бэкапами, которые идут с интервалом менее 10 секунд друг от друга. Может быть, есть ещё какой-то таймаут, который вызывает эту проблему, или нужны дополнительные действия, чтобы изменения в NFSPlugin.pm начали работать?

fiona Guest	#3 0 16.12.2019 12:54:00 Возможно, вам также потребуется выполнить systemctl restart pvedaemon.service pveproxy.service. После этого новый код должен загрузиться во всех соответствующих местах.

timo-fc

Guest

13.01.2020 11:55:00

К сожалению, перезапуск pvedaemon.service и pveproxy.service ситуацию не изменил. Бэкапы всё так же падают с ошибкой "ERROR: got timeout", при этом между успешными бэкапами до и после сбоя проходит около 11 секунд. Хотя таймаут в NFSPlugin.pm установлен на 20 секунд. Таймаут монтирования NFS — 60 секунд. Есть ли ещё какие-то таймауты или что-то, что я, возможно, упустил и что может влиять на эту проблему?

fiona

Guest

13.01.2020 13:42:00

Я немного поэкспериментировал и, похоже, что функция check_connection в NFSPlugin.pm вызывается только один раз в начале бэкапа, а не между самими бэкапами. Хорошая новость в том, что вам не нужно сохранять свою локальную версию этого модуля. Плохая новость — непонятно, что именно вызывает таймаут. Есть ли какие-то хуки для ВМ, на которых задача завершается с ошибкой? Судя по логам, таймаут скорее всего происходит в функции archive из PVE/VZDump/QemuServer.pm (в репозитории qemu-server). Перед вызовом этой функции выводится сообщение о создании архива, а внутри — начинается задача бэкапа (это сообщение отсутствует, когда возникает таймаут).

timo-fc

Guest

13.01.2020 18:10:00

Я проверил последние 4 виртуальные машины, у которых не удалось сделать резервное копирование, никаких хуков-скриптов нет. Проблема затронула 4 разные ВМ на 3 разных Proxmox-хостах в одном кластере, которые отправляют бэкапы на один удалённый сервер резервного копирования. У всех ВМ только один образ диска, этот образ хранится на Ceph, который управляется узлами Proxmox. Но я заметил в journalctl, что pvestatd сообщил о тайм-ауте перед началом бэкапа ВМ 109: такие сообщения о тайм-ауте появляются довольно часто, а ошибки бэкапа — всего раз в несколько дней.

fiona

Guest

14.01.2020 09:36:00

Возможно, виноват следующий фрагмент кода в функции activate_storage в файле PVE/Storage/Plugin.pm? В конце функции activate_storage из NFSPlugin.pm вызывается именно он. Код:
# этот тест пути может зависать бесконечно на неотзывчивых монтированиях
my $timeout = 2;
if (! PVE::Tools::run_fork_with_timeout($timeout, sub {-d $path})) {
die "не удалось активировать хранилище '$storeid' - " .
"директория '$path' не существует или недоступна\n";
}

Попробуйте увеличить таймаут здесь, а потом выполните systemctl restart pvedaemon.service pveproxy.service.

timo-fc

Guest

15.01.2020 10:11:00

К сожалению, это не было причиной проблемы. Я изменил таймаут в Storage/Plugin.pm на 15 секунд и перезапустил службы, но всё равно получил неудачное резервное копирование менее чем через 10 секунд между двумя успешными.

fiona

Guest

16.01.2020 11:30:00

Что насчёт функции status в PVE/Storage/Plugin.pm? Её должен периодически вызывать pvestatd. Но насколько я понимаю, она не должна влиять на код, используемый для резервного копирования. Код:

sub status {
my ($class, $storeid, $scfg, $cache) = @_;

my $path = $scfg->{path};

die "storage definition has no path\n" if !$path;

my $timeout = 2;
my $res = PVE::Tools::df($path, $timeout);

return undef if !$res || !$res->{total};

return ($res->{total}, $res->{avail}, $res->{used}, 1);
}

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

timo-fc Guest	#10 0 09.12.2019 14:53:00 Спасибо за информацию. Мы изменили значение тайм-аута в /NFSPlugin.pm. После перезапуска pvestatd, похоже, проблема с тайм-аутом при резервном копировании решилась.

Читают тему

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