А как вы бакапите свои виртуальные машины ?

Ты мои посты когда-нибудь читать будешь? KVM Kemari, но он сдох. И remus куда лучше.

Если еще важны образы виртуалок - снимается снапшот виртуалки и сливается, квм это умеет.

А тормоза от снапшотов? Или KVM их разряжать научился?

Я про А как вы бакапите свои виртуальные машины ? (комментарий)

У VMWare всё стоит как самолет. ИМХО, дешевле команду KVM/Xen нанять.

Потом файлы соответственно сливаются в файл на zfs хранилку, где стоит сторадж демон бакулы.

А как у ZFS производительность при кучи мелких файлов?

На чем хочешь, кроме мака и винды. Во фре нормальная поддержка, под линукс она уже стабильна, а соляра само собой разумеется.

А на линуксе она уже умеет всё, что на бзде? На солярке (открытой) или бзде ставить - есть отличия? Ты пробовал на линуксе, нет никаких проблем?

А тормоза от снапшотов?
В не самой нагруженной среде

Её именно там и используют в первую очередь.

Для каких задач, и используют ли её не как файлопомойку без SSD? Насколько я знаю, у неё есть некоторые проблемы с производительность без SSD, а также при занятом больше 90% месте.

В не самой нагруженной среде

Если у тебя каждый день бекапы, то через год будет >300 снапшотов. А это лютые тормоза без SSD. Вот этот момент твоей биографии мне не понятен.

А на линуксе она уже умеет всё, что на бзде?

Да.

На солярке (открытой) или бзде ставить - есть отличия?

В бзде геморней, ибо руками надо все создавать, инсталлятор в неё не умеет.

Ты пробовал на линуксе, нет никаких проблем?

Проблема серьезная была только одна - полное разрушение массива, если создавать пул с именами /dev/sda, вместо uuid. При смене имен винчей - пул рушился.
Но это вроде как поправили, не могу найти issue свою на гитхабе про это :(

Для каких задач, и используют ли её не как файлопомойку без SSD?

Да для всех. Если на ней массивы собирать - она в разы быстрее любой другой файлухи. А для хранилищ на много-много терабайт она идеальна.

Насколько я знаю, у неё есть некоторые проблемы с производительность без SSD

Только в случае одного винча и кривых рук (а именно настроек памяти, дедупа и тд). Хотя от кривых рук в любом случае все лагать будет :)

а также при занятом больше 90% месте.

Да, место свободное надо действительно поддерживать в порядке.

А как у ZFS производительность при кучи мелких файлов?

В порядке.

А остальные вопросы и про ZFS на линуксе в продакшене?

Но вообще снапноты вызывают проблемы с часами

Если «живые» снэпшоты делаются быстро, то отставание на микросекунды довольно быстро и безболезненно компенсируется синхронизацией NTP, если снэпшоты делаются медленно, то зачем они тогда вообще нужны, придётся делать бэкап уровня прложения.
Нужно в первую очередь оценивать время дампа оперативной памяти, что зависит в первую голову от выбранной технологии виртуализации.

все норм с zfs в продакшене

А остальные вопросы и про ZFS на линуксе в продакшене?

Я ж ответил

Нужно в первую очередь оценивать время дампа оперативной памяти, что зависит в первую голову от выбранной технологии виртуализации

А vmware как COW бекапит память без остановки?

1. Как в этом маленьком проекте решалась проблема с тормозами из-за снапшотов после >100 снапшотов? qcow2 поддерживает разряжение снапшотов?
2. Именно в продакшене на линуксе ZFS ты пробовал?

все норм с zfs в продакшене

Что за тип продакшена?

1. Как в этом маленьком проекте решалась проблема с тормозами из-за снапшотов после >100 снапшотов? qcow2 поддерживает разряжение снапшотов?

У меня такого кол-ва снапшотов не было еще :)
1) старые можно удалять
2) снапшоты ничего не мешает делать и на уровне фс.

2. Именно в продакшене на линуксе ZFS ты пробовал?

В 5ый раз говорю, да! С ~200 юзверями, юзался под owncloud, занятого места было ~1tb, массив на 4. Куча мелких файлов инклудед, все пахало на wd рапторах.

1) старые можно удалять

Т.е. qcow2 умеет разряжение? Пример команды, плиз. Если ты просто удалишь снапшот, ты нарушишь цепочку,

2. Именно в продакшене на линуксе ZFS ты пробовал?

В 5ый раз говорю, да! С ~200 юзверями, юзался под owncloud, занятого места было ~1tb, массив на 4. Куча мелких файлов инклудед, все пахало на wd рапторах.

А почему SSD не было?

Что за тип продакшена?

овер 20 kvm на пуле состоящим из четырех дисков, диски попарно объединены в зеркала (аналог программного raid 10 в zfs), полный снапшот накатывается на резервный сервак

полное разрушение массива, если создавать пул с именами /dev/sda

в начале использования zfs столкнулся с такой же проблемой.

Используете qcow2? Какие-нибудь твики производительности к нему применялись?
полный снапшот накатывается на резервный сервак

В смысле просто кучка qcow2 файлов копируется на резервный сервер? Самописным скриптом?

А почему SSD не было?

Потому что зачем под это ссд тратить? :)

Если ты просто удалишь снапшот, ты нарушишь цепочку

Разве? :)

Потому что зачем под это ссд тратить? :)

Чтобы быстрее работало.

Разве? :)

Серьезно.

Чтобы быстрее работало.

Оно и так довольно быстро, при таких то потребностях.

использую raw, корневая zfs со сжатием, под каждую виртуалку создается низлежащая ФС, в которой и размещается vm.raw, скрипт заливает поочередно полные снапшоты низлежащих ФС на резерв.

виртуалку создается низлежащая ФС

Это как?

скрипт заливает поочередно полные снапшоты низлежащих ФС на резерв.

А дальше идет дедупликация данных? Но нужно же целиком весь файл многогиговый по сети передать. Почему не используются потоки ZFS, они дают возможность только инкремент передавать?

Это как?

zfs create kvmpool/vm11

Но нужно же целиком весь файл многогиговый по сети передать

большинство виртуалок не более гига, фс ведь со сжатием.

большинство виртуалок не более гига, фс ведь со сжатием.

Но по сети то будет гоняться файл в представлении копирующей программы (т.е. полного размера). Или как вы копируете его?

какой еще программы??? снапшот копируется средствами zfs по ssh, оно не работает по принципу dd, и размер снапшота будет равен размеру виртуалки на фс.

дада, а еще это ограничено для единственного ядра, малого объема памяти, требует отдельной сети и т.д. и т.п. Короче чистый маркетинг без единого реального юз кейса. Более того, мы такое делали и на Xen и на KVM и отказались от такого бесперспективного решения, пока не станет возможным синхронизировать многопроцессорные ВМ

остановка есть, только ее не видно. как и при живой миграции

qcow2 умеет консолидироваться, убирать промежуточные снепшоты или делать полный коллапс в плоский имидж

qcow2 умеет консолидироваться, убирать промежуточные снепшоты или делать полный коллапс в плоский имидж

И как же? Полной конвертацией через qemu-img? :)) Очень хочу ссылки на пруфы, т.к. мне это технически необходимо.

опции commit, rebase и snapshot qemu-img

Но это всё - крайне ресурсоёмкие операции, которые требуют наличия снапшотов в одном файле, а также прочисать и перелить все файлы. При этом, виртуальная машина должна быть на паузе.

это ограничение формата COW а не конкретно qcow2. именно поэтому LVM снепшоты не делают COW

живьем на сегодня можно снять снепшот, а значит все что под ним тоже скоро можно будет делать живьем. Но это не значит что снепшоты не есть зло, и их не надо избегать при любой возможности. Причем опять же - это не конкретно для QCOW, это касается всех систем виртуализации

Ну почему: можно же использовать ZFS-снапшоты. Тут только неудобный менеджмент, а технологически никаких проблем.

Ну почему: можно же использовать ZFS-снапшоты. Тут только неудобный менеджмент, а технологически никаких проблем.

можно. а еще можно использовать снепшоты на стороне SAN. Только какое отношение это имеет к работе непосредственно на уровне qemu?

ну и еще один момент: снятие снепшота - дело быстрое и с qcow2, а вот консолидация или перебазировка - это намного тяжелее, и тут, и в zfs, и в ЕМС-Х, и на нетаппах.

можно. а еще можно использовать снепшоты на стороне SAN.

Я знаю. Но нормального варианта в линуксе (кроме какк образы на ZFS + iSCSI/FC-target) нет, а 250+к за SAN - мой бюждет не позволяет (точнее позволяет, но жаба душит).

Только какое отношение это имеет к работе непосредственно на уровне qemu?

Никакого. Но костыль - лучше чем ничего.

ну и еще один момент: снятие снепшота - дело быстрое и с qcow2, а вот консолидация или перебазировка - это намного тяжелее, и тут, и в zfs, и в ЕМС-Х, и на нетаппах.

В ZFS это можно делать на лету, без остановки VM. А это - самое главное. И да, оно не требует кучу места для проведения операции.

снапшотами

Я знаю. Но нормального варианта в линуксе (кроме какк образы на ZFS + iSCSI/FC-target) нет, а 250+к за SAN - мой бюждет не позволяет (точнее позволяет, но жаба душит).

ну почему же? есть еще LVM

В ZFS это можно делать на лету, без остановки VM. А это - самое главное. И да, оно не требует кучу места для проведения операции.

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

перебазировка не используя третий имидж как таргет - дело очень опасное, и я честно говоря не уверен что ZFS не делает то же самое «под капотом», будет интересно проверить

ну почему же? есть еще LVM

Как-то слишком уныло его бекапить и бронировать место под снапшоты.

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

Пруфы! У гентушников всегда есть xxx/xxx-9999, так что поставить - не проблема.

перебазировка не используя третий имидж как таргет - дело очень опасное

Ага, если сменить подходящий образ на неподходящий. А если код нормально описан - в чём проблема?

Как-то слишком уныло его бекапить и бронировать место под снапшоты.

в смысле? снепшоты будут занимать место всегда, в них хранится информация

Пруфы! У гентушников всегда есть xxx/xxx-9999, так что поставить - не проблема.

сорри, мои разговоры с разработчиками qemu в корридорах или за обедом в открытом, и любом другом доступе не задокументированы.

Ага, если сменить подходящий образ на неподходящий. А если код нормально описан - в чём проблема?

какое отношение это имеет к теме?

А вообще, похоже в апстрим наши идеи все таки попали, надо посмотреть есть ли уже коммиты... http://qemu-project.org/Features/Snapshots#Live_Snapshot_Merge

в смысле? снепшоты будут занимать место всегда, в них хранится информация

в смысле в zfs не надо выделять отдельный раздел фиксированного размера под это дело. статические разделы - весьма унылая концепция, особенно если речь идёт о виртуализации.

это уже вопрос имплементации. Что намного важнее - будут лие снепшоты и манипуляции над ними работать если свободного места нет? Я очень в этом сомневаюсь

в смысле? снепшоты будут занимать место всегда, в них хранится информация

Ниже ответили.

сорри, мои разговоры с разработчиками qemu в корридорах или за обедом в открытом, и любом другом доступе не задокументированы.

Где же Вы это работаете? Когда будут коммиты, уточните у них. :) Передайте, чтобы всё комьюнити ждет. :)

А вообще, похоже в апстрим наши идеи все таки попали,
наши

Где же Вы,таки, работаете?

А вообще, похоже в апстрим наши идеи все таки попали, надо посмотреть есть ли уже коммиты... http://qemu-project.org/Features/Snapshots#Live_Snapshot_Merge

И что с коммитами? :)

это уже вопрос имплементации.

Очень даже. Вот Вы на винду посмотрите. :)

Что намного важнее - будут лие снепшоты и манипуляции над ними работать если свободного места нет? Я очень в этом сомневаюсь

В линуксе всё ломается, если нет места, поэтому умные админы ставят квоты. А когда место кончаются из зарезервированного немного выделяют и решают проблему.

Где же Вы это работаете? Когда будут коммиты, уточните у них. :) Передайте, чтобы всё комьюнити ждет. :)

в red hat, до недавних пор работал

И что с коммитами? :)

не знаю, если что попало в код то надо смотреть changelogs, или апстримовый гит