История изменений
Исправление manul91, (текущая версия) :
Я так понимаю, сейчас Вы уже не работаете с proxmox? - Вы смотрели, что именно vzdump кеши забивает? :)
Proxmox-ом никогда не пользовался. Zfs (в продакшане) - тоже.
В случае когда были проблемы (на котором ссылался выше), бэкапы делались через LVM снэпшотов.
Документация vzdump ( https://pve.proxmox.com/pve-docs/vzdump.1.html ) ссылается на technical overview of the Proxmox VE live backup for QemuServer ( https://git.proxmox.com/?p=pve-qemu.git;a=blob_plain;f=backup.txt ) где написано следующее:
==Disadvantages==
* we need to define a new archive format
Note: Most existing archive formats are optimized to store small files
including file attributes. We simply do not need that for VM archives.
* archive contains data 'out of order'
If you want to access image data in sequential order, you need to
re-order archive data. It would be possible to to that on the fly,
using temporary files.
Fortunately, a normal restore/extract works perfectly with 'out of
order' data, because the target files are seekable.
* slow backup storage can slow down VM during backup
It is important to note that we only do sequential writes to the
backup storage. Furthermore one can compress the backup stream. IMHO,
it is better to slow down the VM a bit. All other solutions creates
large amounts of temporary data during backup.
- slow backup storage can slow down VM during backup
Так что ваша проблема в случае vzdump, вроде описана и известна. Либо нужно заменить backup storage на «быстрый», либо поменять стратегию для бэкапов.
И да, из того что там написано ясно, что vzdump как раз «присасывается» к процессу qemu виртуалки и тормозит его.
В случае с LVM такого нету. Снэпшот происходит практически мгновенно, потом совершенно независимо бэкапится. После того как бэкап закончен, ненужный уже снапшот удаляется. Цена этому - замедление только IO write performance виртуалки пока есть snapshot - но оно фиксированно (грубо вдвое).
vzdump - не очень продуманное решение с точки зрения scalability (цена за итоговую «экономию» в IO во время бэкапа - возможность целостного тормоза виртуалок, вплоть до «остановки» при неблагоприятных условий).
Исправление manul91, :
Я так понимаю, сейчас Вы уже не работаете с proxmox? - Вы смотрели, что именно vzdump кеши забивает? :)
Proxmox-ом никогда не пользовался. Zfs (в продакшане) - тоже.
В случае когда были проблемы (на котором ссылался выше), бэкапы делались через LVM снэпшотов.
Документация vzdump ( https://pve.proxmox.com/pve-docs/vzdump.1.html ) ссылается на technical overview of the Proxmox VE live backup for QemuServer ( https://git.proxmox.com/?p=pve-qemu.git;a=blob_plain;f=backup.txt ) где написано следующее:
==Disadvantages==
* we need to define a new archive format
Note: Most existing archive formats are optimized to store small files
including file attributes. We simply do not need that for VM archives.
* archive contains data 'out of order'
If you want to access image data in sequential order, you need to
re-order archive data. It would be possible to to that on the fly,
using temporary files.
Fortunately, a normal restore/extract works perfectly with 'out of
order' data, because the target files are seekable.
* slow backup storage can slow down VM during backup
It is important to note that we only do sequential writes to the
backup storage. Furthermore one can compress the backup stream. IMHO,
it is better to slow down the VM a bit. All other solutions creates
large amounts of temporary data during backup.
- slow backup storage can slow down VM during backup
Так что ваша проблема в случае vzdump, вроде описана и известна. Либо нужно заменить backup storage на «быстрый», либо поменять стратегию для бэкапов.
И да, из того что там написано ясно, что vzdump как раз «присасывается» к процессу qemu виртуалки и тормозит его.
В случае с LVM такого нету. Снэпшот происходит практически мгновенно, потом совершенно независимо бэкапится. После того как бэкап закончен, ненужный уже снапшот удаляется. Цена этому - замедление write performance виртуалки пока есть snapshot - но оно фиксированно (грубо вдвое). vzdump - не очень продуманное решение с точки зрения scalability (цена за итоговую «экономию» в IO во время бэкапа - возможность целостного тормоза виртуалок, вплоть до «остановки» при неблагоприятных условий).
Исходная версия manul91, :
Я так понимаю, сейчас Вы уже не работаете с proxmox? - Вы смотрели, что именно vzdump кеши забивает? :)
Proxmox-ом никогда не пользовался. Zfs (в продакшане) - тоже.
В случае когда были проблемы (на котором ссылался выше), бэкапы делались через LVM снэпшотов.
Документация vzdump ( https://pve.proxmox.com/pve-docs/vzdump.1.html ) ссылается на technical overview of the Proxmox VE live backup for QemuServer ( https://git.proxmox.com/?p=pve-qemu.git;a=blob_plain;f=backup.txt ) где написано следующее:
==Disadvantages==
* we need to define a new archive format
Note: Most existing archive formats are optimized to store small files
including file attributes. We simply do not need that for VM archives.
* archive contains data 'out of order'
If you want to access image data in sequential order, you need to
re-order archive data. It would be possible to to that on the fly,
using temporary files.
Fortunately, a normal restore/extract works perfectly with 'out of
order' data, because the target files are seekable.
* slow backup storage can slow down VM during backup
It is important to note that we only do sequential writes to the
backup storage. Furthermore one can compress the backup stream. IMHO,
it is better to slow down the VM a bit. All other solutions creates
large amounts of temporary data during backup.
- slow backup storage can slow down VM during backup
Так что ваша проблема в случае vzdump, вроде описана и известна. Либо нужно заменить backup storage на «быстрый», либо поменять стратегию для бэкапов.