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

RSS

Виртуальные машины зависают и становятся недоступны, когда сервер резервного копирования работает медленно., Proxmox Backup Server

Luki20

Guest

19.09.2021 20:55:00

Всем привет! В последнее время замечаю странную проблему с Proxmox (6.4-13) в связке с Proxmox Backup Server (2.0-9). Резервное копирование ВМ по ночам в большинстве случаев проходит отлично и надежно, а так как это чаще всего инкрементные бэкапы, процесс достаточно быстрый. Производительность резервного копирования в среднем около 80 МБ/с тоже довольно хорошая, учитывая, что данные передаются по сети в совершенно другой дата-центр.

Однако если возникают проблемы с записью/чтением бэкапа или процесс записи на сервер бэкапов идет медленно (из-за плохой пропускной способности сети или медленного жесткого диска на сервере бэкапов), то ВМ зависает (сервисы на ней становятся недоступными), и с графическим интерфейсом (консоль не открывается — таймаут, выключение — таймаут, помогает только жесткая остановка). В основном бэкап останавливается где-то в процессе (например, на 50% или 60%) и выдает ошибку: "ERROR: VM ... qmp command 'query-backup' failed - got timeout". Симптомы, описанные в этой теме форума (https://forum.proxmox.com/threads/certain-vms-from-a-cluster-cannot-be-backed-up-and-managed.57016/), выглядят очень похожими на мои.

Теперь вопрос: нормально ли, что из-за проблем с бэкапом ВМ на короткое время становится недоступной? В идеале бэкап не должен мешать работе сервисов или самой ВМ. Это стандартное поведение или у меня что-то с сервером не так? Спасибо за помощь!

Полный лог бэкапа:

Spoiler

INFO: пытаюсь получить глобальную блокировку — жду...
INFO: получил глобальную блокировку
INFO: запускаю новую задачу бэкапа: vzdump 101 --mailnotification failure --mode snapshot --mailto ...@... --storage backup_pbs --quiet 1
INFO: начинаю бэкап ВМ 101 (qemu)
INFO: Бэкап стартовал 2021-09-15 02:52:46
INFO: статус = running
INFO: Имя ВМ: VM01
INFO: включаю диск 'sata1' 'storage2:101/vm-101-disk-0.qcow2' 500G
INFO: режим бэкапа: snapshot
INFO: приоритет ionice: 7
INFO: создаю архив Proxmox Backup Server 'vm/101/2021-09-15T00:52:46Z'
INFO: включаю шифрование
INFO: задача бэкапа запущена с ID '0c8136ea-9282-44b1-a505-1a1ae417eb88'
INFO: возобновляю работу ВМ
INFO: sata1: статус dirty-bitmap: OK (21.7 GiB из 500.0 GiB "грязных" данных)
INFO: использую быстрый инкрементальный режим (dirty-bitmap), 21.7 GiB грязных из 500.0 GiB всего

(Далее идет отчет о процентах и скорости чтения/записи с разными значениями в MiB/s и временах)

INFO: 1% (308.0 MiB из 21.7 GiB) за 3 сек, чтение: 102.7 MiB/s, запись: 101.3 MiB/s
INFO: 2% (656.0 MiB из 21.7 GiB) за 6 сек, чтение: 116.0 MiB/s, запись: 116.0 MiB/s
...
INFO: 54% (11.7 GiB из 21.7 GiB) за 17 м 18 с, чтение: 40.8 MiB/s, запись: 24.8 MiB/s
ERROR: VM 101 qmp command 'query-backup' failed - got timeout
INFO: прерываю задачу бэкапа
INFO: возобновляю работу ВМ
ERROR: Бэкап ВМ 101 не удался — VM 101 qmp command 'query-backup' failed - got timeout
INFO: ошибка зафиксирована 2021-09-15 03:22:30
INFO: задача бэкапа завершена с ошибками
TASK ERROR: job errors

danielb Guest	#2 0 25.12.2021 16:42:00 Это потребует много свободного места, ресурсов процессора и памяти, и в целом не кажется правильным способом решить проблему.

RolandK Guest	#3 0 22.10.2021 17:31:00 Это настоящая досада, ведь прерывистое соединение — это то, что всегда может случиться, особенно когда делаешь резервное копирование на удалённый сервер.

tuxick Guest	#4 0 07.12.2021 12:43:00 Значит, изменение bwlimit может помочь?

tuxick Guest	#5 0 07.12.2021 22:12:00 У меня были похожие проблемы с плохим/медленным соединением с PBS.

marcportabella Guest	#6 0 22.12.2021 22:11:00 Было бы хорошей идеей установить PBS в виде виртуальной машины на том же узле Proxmox и использовать функцию удалённой синхронизации, чтобы синхронизировать содержимое резервных копий с внешним сервером?

Faris Raouf

Guest

06.01.2022 18:38:00

Это, на мой взгляд, не просто досадная неприятность, а настоящая проблема. Зависание на несколько секунд — редкость, которую можно стерпеть, а полная немедленная заморозка до принудительной перезагрузки — это жутко. Ошибки сети — вещь неизбежная. Кроме того, если вы пользуетесь удалённым сторонним сервисом PBS (например, Tuxis), вы никак не контролируете нагрузку, доступную пропускную способность и прочее на самом сервере PBS. Судя по двум отчетам об ошибках, всё сводится к какому-то ограничению в qemu.

Тем не менее, нельзя ли сделать пользовательский настраиваемый диск-буфер (на самом узле), а не только буфер в памяти? Это помогло бы сгладить проблемы при кратковременных сбоях — гораздо лучше, чем просто буферизация в оперативке. Ещё одна постоянно задаваемая в отчётах ошибка — «насколько медленно слишком медленно?» в плане скорости записи, чтобы вызвать прерывание резервного копирования и предотвратить зависание виртуальной машины (или ещё хуже). Разве это нельзя тоже сделать настраиваемым пользователем? Если я знаю, что у меня реально медленное DSL-соединение, могу поставить низкую скорость записи. Если у меня гигабитный Ethernet — выставить высокую скорость записи. Тогда, если во время работы скорость упадёт ниже нормы, резервная копия прервётся, а виртуальная машина будет работать нормально, вместо того чтобы зависать.

Если всё это невозможно, что насчёт короткого тайм-аута (тоже настраиваемого)? Для наших виртуалок зависание дольше 10 секунд — неприемлемо. Я с удовольствием предпочту прерывание резервного копирования вместо зависания ВМ на более длительное время.

Luki20 Guest	#8 0 07.01.2022 13:29:00 Спасибо всем, кто продолжил обсуждение. Я согласен, что у пользователей не должно быть никаких возможностей для настройки.

mgiammarco

Guest

05.02.2022 10:21:00

Прежде всего хочу поблагодарить вас. Уже много лет у меня постоянные проблемы с торможением виртуальных машин во время бэкапа. Я перечитал кучу тем с такими же проблемами, и мы потеряли много дней, пытаясь понять, в чём дело, а теперь вы наконец-то показали мне причину. Я думал, что бэкап делается стандартным способом: сначала снимок диска, потом бэкап этого снимка. А теперь я узнал, что чтобы "оптимизировать" количество операций чтения и записи во время бэкапа, Proxmox "привязывает" скорость дисков виртуальной машины к скорости дисков бэкап-сервера. У меня есть заказчик с базой данных на Ceph/NVMe-дисках. Они пишут в базу круглосуточно. А на сервере бэкапа стоят диски с 5400 оборотов в минуту. Как только начинается бэкап, база данных тормозит. Обратите внимание, что это не сетевая проблема, потому что соединение Proxmox -> PBS — 10 Гбит. Повторяю: чтобы "оптимизировать" процесс бэкапа, вы считаете приемлемым связать скорость дисков виртуальной машины со скоростью дисков бэкап-сервера. Это классический пример «лучшее — враг хорошего». Знаете, сколько проблем у нас из-за этого выбора? Куда я могу подать жалобу или запрос на изменение такого поведения? По крайней мере для файловой системы Ceph. Спасибо, Марио.

mgiammarco Guest	#10 0 05.02.2022 10:22:00 Проблема в том, что даже если у вас есть 10G-соединение с PBS, но диски PBS работают медленно, вы получите ту же самую проблему!

RolandK Guest	#11 0 05.02.2022 13:18:00 Это проблема дизайна. Я не уверен, можно ли её исправить только в проекте kvm/qemu на более высоком уровне или требуется исправление в proxmox. Я не нашёл подходящего тикета на https://gitlab.com/qemu-project/qemu/-/issues. В режиме snapshot/backup записи не должны замедляться из-за производительности или нагрузки сервера резервного копирования.

Читают тему

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