Я в итоге написал собственный скрипт для резервного копирования, чтобы выгружать изображения из ceph на NFS-ресурс. Дай знать, если хочешь попробовать.

Есть ли обновления по этому поводу? Мы сталкиваемся с теми же проблемами, и как упомянул robhost, VMA файлы действительно необходимы, ультрамедленными можно назвать бэкапы, которые сейчас приходят с Ceph backend.

Проблема в том, что резервное копирование proxmox заблокировано размером блока 64К. Это приводит к большему количеству операций ввода-вывода к ceph (использует больше процессорного времени) плюс время на обратный сетевой переход. Я помню, кто-то проводил тест с резервным копированием qemu (это отличается от пользовательского кода резервного копирования proxmox), где можно настроить размер блока, и это действительно было быстрее. "Привет, Александр, 02.03.2016 в 15:23 Александр ДЕРЮМЬЕ: >>> Мы сейчас реализуем нашу собственную систему резервного копирования, которая использует команду drive-backup qmp для дампа qcow2. Нам не нужны конфигурационные файлы. >>> И это работает с ceph и кластером размером 4МБ. > > Как насчет производительности (64К, 4МБ) и стабильности по сравнению с форматом vma от proxmox? Мы (Стефан и я) не проводили полностью сопоставимые тесты. Мы протестировали виртуальный диск размером 100ГБ от резервного копирования ceph, загруженного на NFS: - с VMA, стандартным размером кластера 64КБ и без ограничений на чтение/запись: | | Снимок | Приостановить | Остановить | |------+----------+---------+-------| | ничего | 09:55 | 09:37 | 09:35 | | LZO | 10:24 | 10:26 | 10:20 | | GZip | 31:52 | 32:22 | | - QMP drive-backup (параметры sync => full, формат => qcow2), размер кластера 4МБ и 130 Мб/с, 215 операций/с чтение; 90 Мб/с, 155 операций/с запись: 9:15 минут. QMP drive-backup с вышеуказанными ограничениями и стандартным размером кластера 64КБ занял очень много времени, более 40 минут."

Насколько я понимаю, VMware отменил свои собственные инструменты резервного копирования, так что Proxmox VE здесь не так уж далек от этого, если я не прав, поправьте меня. VMware никоим образом не поддерживает Ceph, так что я не вижу, почему VMware здесь "впереди". Также у RHEV нет сопоставимого решения для резервного копирования. Пожалуйста, пишите по существу и не говорите сообществу, что VMware или другие значительно "впереди"... Но да, проблема известна, но не так уж легко её исправить. Мы видим около 60 Мб/сек в задачах резервного копирования Ceph, так что это не так медленно, как здесь некоторые упоминают.

Пожалуйста, не поймите меня неправильно. Я не говорю, что VMware "опережает" по технологиям, но, безусловно, по признанию, и мне бы хотелось увидеть, как Proxmox завоевывает серьезное внимание на рынке, чтобы соответствовать крупным компаниям... вот, что я пытался донести. Мы продолжаем использовать Proxmox, потому что он демонстрирует отличную производительность и стабильность. Мы никогда не были впечатлены VMware, и мы заменили нашу установку XenServer на Proxmox, чтобы показать, как мы оцениваем возможности Proxmox как платформы виртуального хостинга. Что касается резервных копий Proxmox, они всегда были одной из тех функций, которые учитываются и необходимы тем, кто его использует, поэтому ожидать функционала, который существует, как приоритетно, вполне разумно, независимо от действий конкурентов. Сказав это, платформа в целом выполняет ожидаемое и делает это очень хорошо, так что огромное "СПАСИБО!!!" заслужено, и мы его от всей души передаем. Мы не подозревали, что это "известная проблема, но не простая в решении", так как то, что видно на форумах, этого не доносит, поэтому спасибо, что прояснили этот момент. 60 MB/s – это медленно, когда вы делаете много резервных копий за ночь, и эта максимальная скорость вообще не поддерживается во время фактической резервной копии, скорее всего, в районе 30 MB/s. Они не могут завершиться к утру из-за этой медлительности. Мы используем сетевые соединения на 10Gb. С локального хранилища скорость достигает 300 MB/s – 500 MB/s, что означает, что резервные копии легко завершаются за ночь, если они с локального хранилища, поэтому для клиентов это не проблема рано утром. Но дело в том, что почти ни одна из наших виртуальных машин в данный момент не находится на локальном хранилище, они скорее на Ceph, что принесло огромное улучшение производительности и гибкости нашей клиентской базе, но это означает, что резервные копии этих десятков виртуальных машин не могут завершаться так, как должны, к утру во многих случаях (и нет, мы не делаем резервные копии стольких за ночь). Это был тот момент, который пытались донести, и не в том, чтобы сказать, что VMware "опережает". Любой, кто смотрит на эту тему в сообществе, теперь может увидеть это разъяснение и понять, что я вовсе не говорю, что VMware превосходит, так как если бы это было так, мы бы использовали его вместо Proxmox, но это просто не так. Никакого оскорбления не имелось в виду. Было бы полезно получить объяснение, что было сделано и делается для исправления ситуации с медленными резервными копиями с Ceph. Мы смиренно осознаем, что не знаем, как решить эту проблему самостоятельно, но оценили бы столь же смиренное признание со стороны разработчиков и не воспринимать наблюдения как оскорбление, а понять, что мы все хотим одного: сделать Proxmox лучшим.