Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
А почему бы не делать суспенд гостя (все содержимое оперативной памяти, значения регистров ЦП и прочее записывается файлом на диск), потом сделать снапшот диска гостя, скопировать образ оперативной памяти и опять включить гостя?
Суспенд занимает около 5-10 сек., столько же на выход из него. В это время естественно гость будет не доступен, но после включения продолжит работать как ни в чем не бывало (только время нужно будет подкорректировать). В данном случае не важно какой гость, т.к. все делается на стороне QEMU. При восстановлении ВМ будет восстановлена в том же состоянии, в котором снимался бэкап.
Суспенд занимает около 5-10 сек., столько же на выход из него. В это время естественно гость будет не доступен, но после включения продолжит работать как ни в чем не бывало (только время нужно будет подкорректировать). В данном случае не важно какой гость, т.к. все делается на стороне QEMU. При восстановлении ВМ будет восстановлена в том же состоянии, в котором снимался бэкап.
Qemu умеет делать атомарный снимок всех дисков + память в живом режиме, без суспенда гостя — фича называется external snaphshot. После резервирования необходимо влить изменения в снапшоте обратно в основные диски — это тоже делается в живом режиме (blockcommit). Все это поддерживается и в libvirt'e, правда нормально оно стало работать только в самых свежих версиях (по-моему с 1.2.7). Также libvirt'у можно указать опцию --quiesce — она как раз и вызовет заморозку ФС всех дисков на госте при создании атомарного снапшота.
Как я понимаю эта фича поддерживается только с qcow2 дисками?
Нет, с любыми. Процесс создания external snapshot выглядит так: вместо основных дисков (любых, LVM, raw, ceph и т.д.) создаются временные qcow2 диски, в которые с момента создания снапшота начинает идти вся запись, а оригинальные диски на это время становятся read-only. Их можно монтировать, копировать и т.д. После завершения резервирования выполняется команда blockcommit, которая в живом режиме мержит изменения из временных qcow2 дисков обратно в основные. После мержа всех дисков временные диски и снапшот можно удалять. Мерж идет быстро, т.к. копируются только изменения.
Спасибо за --quiesce, добавил в статью
Единственный минус таких бекапов — наличие кривого софта, который не поддерживает функцию принудительного сброса данных на диск перед фризом, и бекап для него может оказаться все-равно неконсистентным несмотря на все фризы и атомарность. Единственный выход для такого софта — это корректное завершение работы гостя, и бекап уже отмонтированных дисков. Раз qemu умеет создавать снапшоты с памятью, неплохо было бы создавать клон гостя, отключать ему сеть, «пробуждать», корректно делать shutdown, и бекапить отмонтированные диски. Но qemu напрямую такой возможностью не обладает. Чисто в теории можно сделать костыль — копировать (или монтировать, если общий сторадж) диски на другую машину (в случае монтирования делать повторный снапшот, чтобы не повредить оригинал), копировать туда образ памяти, убедиться, что сеть для гостя работать не будет, делать virsh resume <файл_с_памятью>, делать shutdown и бекапить. Но на практике это не проверял, да и выглядит геморройно.
Проблема не в производительности, проблема в консистентности данных. При вашем подходе запросто может оказаться, что в момент снятия снапшота часть новых данных в БД уже записана на диск, а часть еще в кэше. В итоге мы в бэкапе имеем неконсистентую базу данных. В худшем случае данные могут быть повреждены до полной бесполезности.
Автор поста как раз и говорит о способе сказать приложениям в госте, что нужно сброситьь кэши и приготовится к снятию снапшота, другой способ я описал в первом комментарии.
А чем снимать снапшот дело десятое.
Автор поста как раз и говорит о способе сказать приложениям в госте, что нужно сброситьь кэши и приготовится к снятию снапшота, другой способ я описал в первом комментарии.
А чем снимать снапшот дело десятое.
Вообще-то чем снимать снапшот — дело далеко не десятое, собственно одна из основных проблем «стандартного» KVM — отсутствие возможности снимать live снапшоты без заморозки I/O.
Как раз дело десятое в случае правильных снапшотов (когда нет заморозки I/O и очень быстро делаются) получить консистентные данные на одной VM.
BTRFS рекомендовать — сродни «вредных советов», она не готова для production никоим образом (нет даже утилит которые могли бы ее починить в случае сбоев).
При этом в статье вообще не учитывается что консистентность нужна далеко не только для одной VM, но для групп VM (если у вас есть SQL сервера + приложения, то снятие консистентного снапшота с одной VM совершенно не решает проблемы рассинхронизации данных между VM)
И да, Nutanix поддерживает consistensy groups — группы VM для одновременного снятия снапшотов.
По поводу таблички замечание совершенно корректное, ввиду того Nutanix сейчас занимает уже наибольшую часть рынка конвергентных систем, и приведенные параметры в таблице по снапшотам просто неполные.
Как обычно, вместо того чтобы учиться новому, наступает агрессивная реакция ;) Именно поэтому в РФ все доходит с опозданием в 2-3 года.
Как раз дело десятое в случае правильных снапшотов (когда нет заморозки I/O и очень быстро делаются) получить консистентные данные на одной VM.
BTRFS рекомендовать — сродни «вредных советов», она не готова для production никоим образом (нет даже утилит которые могли бы ее починить в случае сбоев).
При этом в статье вообще не учитывается что консистентность нужна далеко не только для одной VM, но для групп VM (если у вас есть SQL сервера + приложения, то снятие консистентного снапшота с одной VM совершенно не решает проблемы рассинхронизации данных между VM)
И да, Nutanix поддерживает consistensy groups — группы VM для одновременного снятия снапшотов.
По поводу таблички замечание совершенно корректное, ввиду того Nutanix сейчас занимает уже наибольшую часть рынка конвергентных систем, и приведенные параметры в таблице по снапшотам просто неполные.
Как обычно, вместо того чтобы учиться новому, наступает агрессивная реакция ;) Именно поэтому в РФ все доходит с опозданием в 2-3 года.
Все равно это все реализуется в опенсорсе, а покупать кусочек стека за xxx денег видимо, хотят не все. С Windows разве что подмораживать ФС в общем случае чуть сложнее, вот и все. Да, и приведенный пример с несколькими VM — это реально сферический конь, ACID там ничему не позволит развалиться, поэтому что снимать снимок с одной VM, что с нескольких — разницы никакой нет, надо только попросить БД приостановить записи на время снятия, соответственно, к технологиям бекапа это не имеет отношения, это фича оркестровки.
Учится чему то новому никто не против. Но создалось впечатление, что ваш коллега не читал стать и быстренько накатал рекламный коммент.
Еще раз: проблема в консистентности данных на диске. Снапшот позволяет получить консистентые данные на уровне блочного устройства или ФС, но это совершенно не значит, что данные будут консистентны на уровне приложения. Что бы они были консистентны приложение нужно оповестить о снятии снапшота (как это делает VSS), что бы оно сбросило кэши и тд. Собственно об этом и статья.
Консистентность для групп ВМ это хорошо, но сначала бы с одной ВМ разобраться.
Если мы друг друга не поняли и у вас эта проблема решена, то будет интересно узнать как.
если у нас есть СУБД или другое ПО, которое активно использует собственный кэш на запись, то перед бэкапом его нужно попросить сбросить кэш и заморозить запись на диск, иначе данные-то в снэпшот попадут, но не те
Еще раз: проблема в консистентности данных на диске. Снапшот позволяет получить консистентые данные на уровне блочного устройства или ФС, но это совершенно не значит, что данные будут консистентны на уровне приложения. Что бы они были консистентны приложение нужно оповестить о снятии снапшота (как это делает VSS), что бы оно сбросило кэши и тд. Собственно об этом и статья.
Консистентность для групп ВМ это хорошо, но сначала бы с одной ВМ разобраться.
Если мы друг друга не поняли и у вас эта проблема решена, то будет интересно узнать как.
Согласитесь, что у QEMU и Nutanix общее только то, что оба они применяются в виртуализации. Начнем с того, что Nutanix — это (опуская частности) СХД-платформа + механизм управления гипервизором, а QEMU/KVM — собственно гипервизор, поэтому сравнивать их «в лоб» как-то неправильно, слишком это разные вещи. Обратите внимание, я не говорю, что Nutanix хуже QEMU (или лучше), я просто отмечаю, что они разные.
Вы говорите, что не останавливаете IO при снятии снэпшота, можно ли получить ссылку не документацию, где это говориться прямым текстом? Как тогда решается задача консистентности файловых систем гостевых машин?
Я посчитал, что даже в случае одной ВМ и локальной СХД статья и так получается сложной. Но две последние колонки в таблице как раз подразумевают заморозку всего хранилища, так что мы получаем одновременную копию всех ВМ. Опять же, Nutanix использует кластерную СХД, а сравнивать ее с LVM не совсем корректно. Сравнивайте лучше с Ceph, OCFS2 и т.п.
В Facebook с вами не согласны, в Novell — тоже
Опять же, я писал в статье, что «Btrfs — относительно новая ФС и, возможно, она менее надежна, чем связка LVM и ext4», но все-таки «пациент скорее жив, чем мертв».
Однако, агрессивный у вас маркетинг…
Вы говорите, что не останавливаете IO при снятии снэпшота, можно ли получить ссылку не документацию, где это говориться прямым текстом? Как тогда решается задача консистентности файловых систем гостевых машин?
При этом в статье вообще не учитывается что консистентность нужна далеко не только для одной VM
Я посчитал, что даже в случае одной ВМ и локальной СХД статья и так получается сложной. Но две последние колонки в таблице как раз подразумевают заморозку всего хранилища, так что мы получаем одновременную копию всех ВМ. Опять же, Nutanix использует кластерную СХД, а сравнивать ее с LVM не совсем корректно. Сравнивайте лучше с Ceph, OCFS2 и т.п.
BTRFS рекомендовать — сродни «вредных советов», она не готова для production никоим образом (нет даже утилит которые могли бы ее починить в случае сбоев).
В Facebook с вами не согласны, в Novell — тоже
Опять же, я писал в статье, что «Btrfs — относительно новая ФС и, возможно, она менее надежна, чем связка LVM и ext4», но все-таки «пациент скорее жив, чем мертв».
По поводу таблички замечание совершенно корректное, ввиду того Nutanix сейчас занимает уже наибольшую часть рынка конвергентных систем, и приведенные параметры в таблице по снапшотам просто неполные.
Однако, агрессивный у вас маркетинг…
Выполнять на стороне гостя любые процедуры прерывания записи особенно на высоко нагруженных виртуальных машинах это гораздо большее зло, чем простые онлайн снапшоты LVM на стороне хоста. Потому описанный метод далеко не всегда панацея и более того, имеет смысл в крайне редких случаях.
В упомянутом выше Proxmox, архивация по умолчанию использует мгновенные снимки и позволяет выполнять архивацию без остановок гостевой системы.
После восстановления из такого образа система возвращается к жизни ровно так-же как после сбоя питания.
Однозначно сказать, что большее зло — периодические переключения рабочих режимов ПО на уровне ОС гостя или гарантированное невмешательство в работу гостевой системы и прозрачная архивация средствами хоста, сказать сложно.
Но думаю в 90% случаев мгновенные снапшоты средствами LVM без остановки гостя и параллельной архивацией будут достаточны.
А из статьи создается ощущение для не посвещенных, что существует такая проблема как архивация виртульных машин без остановки её работы, и её решение чрезвычайно сложное.
В упомянутом выше Proxmox, архивация по умолчанию использует мгновенные снимки и позволяет выполнять архивацию без остановок гостевой системы.
После восстановления из такого образа система возвращается к жизни ровно так-же как после сбоя питания.
Однозначно сказать, что большее зло — периодические переключения рабочих режимов ПО на уровне ОС гостя или гарантированное невмешательство в работу гостевой системы и прозрачная архивация средствами хоста, сказать сложно.
Но думаю в 90% случаев мгновенные снапшоты средствами LVM без остановки гостя и параллельной архивацией будут достаточны.
А из статьи создается ощущение для не посвещенных, что существует такая проблема как архивация виртульных машин без остановки её работы, и её решение чрезвычайно сложное.
Выполнять на стороне гостя любые процедуры прерывания записи особенно на высоко нагруженных виртуальных машинах это гораздо большее зло, чем простые онлайн снапшоты LVM на стороне хоста.
Вы будете удивлены, но механизм fsfreeze (с предварительным sync, подробности — в исходниках ядра, файл fs/super.c) создан как раз для того, чтобы снимать снапшоты через LVM и при этом не получить вместо метаданных ФС на томе тыкву.
Просто мы делаем fsfreeze не при вызове lvcreate, а раньше.
А из статьи создается ощущение для не посвященных, что существует такая проблема как архивация виртуальных машин без остановки её работы, и её решение чрезвычайно сложное.
Да нет, сделать архив просто, но не факт, что с такого архива можно потом развернуться. Вот, например, товарищи из Acronis тоже статьи на эту тему пишут: habrahabr.ru/company/acronis/blog/207472/
,
Описанный подход прекрасно работает, если совмещать его с дисковым бекендом, позволяющим делать атомарные снимки — у нас в Flops.ru бекапы создаются именно таким образом, при этом использование открытых компонент позволяет получить желаемое бесплатно. Единственный недостаток такого подхода — файловые системы, которые отказываются фризиться по каким-то причинам, в БД-ориентированном шаблоне это может обходиться выносом datastore БД на отдельную (эксклюзивную) точку монтирования.
Отличная статья, лично я дожидаюсь когда уже заработает blockpull, а то blockcommit усложняет управление образами.
Альтернативный, и по настоящему хороший, на мой взгляд, подход, был бы не бекап как таковой, а живая миграция в бекап-образ, состоящий из domxml+disk images+memstate. Тогда рестор получился бы таким же как результат живой миграции с дисками на destination host, нет проблем с консистентностью, т.к. все что не на дисках найдется в memstate, короче сплошные плюсы. Правда надо при таких раскладах больше места чтоб хранить дампы памяти и с инкрементальными бекапами придется повозиться.
libvirt, к сожалению, пока такому не научили, хотя оба Даниэля вроде как не против идеи.
Альтернативный, и по настоящему хороший, на мой взгляд, подход, был бы не бекап как таковой, а живая миграция в бекап-образ, состоящий из domxml+disk images+memstate. Тогда рестор получился бы таким же как результат живой миграции с дисками на destination host, нет проблем с консистентностью, т.к. все что не на дисках найдется в memstate, короче сплошные плюсы. Правда надо при таких раскладах больше места чтоб хранить дампы памяти и с инкрементальными бекапами придется повозиться.
libvirt, к сожалению, пока такому не научили, хотя оба Даниэля вроде как не против идеи.
Нюанс в том, что все вариации на эту тему очень небыстрые, для промышленного флоу их использовать сложновато. Плюс корка сейчас на лету без простоя не снимается, что ведет к еще большим потерям :).
Вариации могут быть настолько быстры насколько способно железо, а с быстрым железом, там где гоняют большие кластеры проблем обычно не бывает.
Корка на лету срывается с той же задержкой что и живая миграция, собственно в любой живой миграции задержка — ключевой момент. Мы (наигравшись в ассасинов наверное) называли этот момент «leap of faith». Если бекап делается локально, то задержки практически нет. Я как раз и вижу такую систему бекапа как софт на хосте. При надобности снять бекап, ВМ мигрирует на хост, сбрасывает набор domxml+disk images+memstate на локальные staging диски, и улетает дальше, вместо нее приходит другая. Можно это делать в несколько потоков.
Корка на лету срывается с той же задержкой что и живая миграция, собственно в любой живой миграции задержка — ключевой момент. Мы (наигравшись в ассасинов наверное) называли этот момент «leap of faith». Если бекап делается локально, то задержки практически нет. Я как раз и вижу такую систему бекапа как софт на хосте. При надобности снять бекап, ВМ мигрирует на хост, сбрасывает набор domxml+disk images+memstate на локальные staging диски, и улетает дальше, вместо нее приходит другая. Можно это делать в несколько потоков.
Мигрирует блочной миграцией? Вообще описанный вариант про корку из коробки недоступен, хотя его можно сделать минимальными силами, и опять же пока дисковый снимок отклеивается (если в этом есть необходимость), все может тормозить. И зачем в любом случае мигрировать машину для снятия бекапа?
Ну да, конечно блочной миграцией. Она в принципе ничем не медленнее чем просто копия диска под снепшотом. throttling можно делать опять же. Тормозить все может даже при представленном выше варианте — копирование диска будет жрать ресурсы хоста.
> И зачем в любом случае мигрировать машину для снятия бекапа?
бекап виртуалки можно делать четырьмя основными методами на сегодняшний день. Все что есть на рынке и гитхабе — вариации на тему:
1. бекап классический — агент внутри VM, все как будто VM ничем не отличается от физической машины. этот вариант не интересен
2. бекап со стороны СХД — снепшот снимается средствами снепшота СХД, хост где бегает машина и собственно система виртуализации никакого отношения к этому не имеет. Конечно возможна интеграция, quiesce и всяческая оркестрация, но не в этом суть. Самим СХД могут быть не обязательно монстры от ЕМС, но и тот же LVM/ZFS/…
3. бекап в виртуальный appliance. VM бекапер бежит параллельно с VM которую надо забекапить. В режиме r/o к бекаперу цепляются диски которые надо сохранить, и апплаенс перетягивает инфу к себе, после чего отключается от дисков. Так работает основная масса решений под vmware. да и в oVirt для этого есть api.
4. бекап на самом гипервизоре — это или снепшот/запись, но снепшот средствами гипервизора, или то что описал я.
Ставить 4-й вариант на всех хостах, имхо, глупо. Особенно если staging диски у него локальные. Гораздо проще мигрировать на хост нужную VM, снять с нее нужный датасет прямо в staging, и угнать ее на обычный хост.
> И зачем в любом случае мигрировать машину для снятия бекапа?
бекап виртуалки можно делать четырьмя основными методами на сегодняшний день. Все что есть на рынке и гитхабе — вариации на тему:
1. бекап классический — агент внутри VM, все как будто VM ничем не отличается от физической машины. этот вариант не интересен
2. бекап со стороны СХД — снепшот снимается средствами снепшота СХД, хост где бегает машина и собственно система виртуализации никакого отношения к этому не имеет. Конечно возможна интеграция, quiesce и всяческая оркестрация, но не в этом суть. Самим СХД могут быть не обязательно монстры от ЕМС, но и тот же LVM/ZFS/…
3. бекап в виртуальный appliance. VM бекапер бежит параллельно с VM которую надо забекапить. В режиме r/o к бекаперу цепляются диски которые надо сохранить, и апплаенс перетягивает инфу к себе, после чего отключается от дисков. Так работает основная масса решений под vmware. да и в oVirt для этого есть api.
4. бекап на самом гипервизоре — это или снепшот/запись, но снепшот средствами гипервизора, или то что описал я.
Ставить 4-й вариант на всех хостах, имхо, глупо. Особенно если staging диски у него локальные. Гораздо проще мигрировать на хост нужную VM, снять с нее нужный датасет прямо в staging, и угнать ее на обычный хост.
А какие плюсы этот подход дает? Если продолжать держать информацию о снимках в образе, чтобы получать дифференциальные детачнутые копии, то это будет растить размер блок-бекенда, который еще по замыслу катается между машинами, если снимать каждый раз полный дамп — проще воспользоваться drive-backup или чем-то схожим по смыслу и ничего никуда не мигрировать (похоже вариант 3, если имелось в виду то же). В любом случае, двойная блочная миграция в процессе не выглядит продакшеном :)
я же писал — полная консистентность за счет снимка памяти. рестор с т.з. VM выглядит как завершение живой миграции. Проблемы со временем конечно будут, но где их нет?
Уточню, акцент на ресурсоемкости такого флоу в целом.
с этим я и не спорил. за все надо платить. тут уже упоминали проблемы консистентности даже в случае использования quiesce, с моим решением таких проблем не будет. и рестор будет максимально гладким. стоит ли это потраченного времени и дискового пространства — решать тем кто решение выбирает
Хорошо, заменяем фриз на отслаивание памяти (не прямым дампом, а мигратоподобным вариантом или его аналогом, как выше) и снимком на хранилище из п.2, получаем тот же простой в районе долей секунды и ту же «абсолютную консистентность». Месседж с моей стороны таков, что попытка сделать указанные вещи на обычных локальных образах, raw или cow, приведет к очень высокому оверхеду из-за необходимости прокачивать большой объем данных в первом случае и потенциальной необходимости отслаивать снимки и также прокачивать много байтов во втором, без отслоения надо либо их ротировать, либо все затормозит. Впрочем, такой подход вполне себе имеет право на жизнь, если время доступности бекапа с момента его создания может сильно варьироваться и не регламентировано жестко (доступность = выкачанность на другую физическую сущность).
В любом случае, для этой ниши существует state replication и вмваре, прыгать вокруг целостного стейта с текущим состоянием дел в qemu слишком дорого.
В любом случае, для этой ниши существует state replication и вмваре, прыгать вокруг целостного стейта с текущим состоянием дел в qemu слишком дорого.
> заменяем фриз на отслаивание памяти (не прямым дампом, а мигратоподобным вариантом или его аналогом, как выше)
это главное в данном случае. virsh save выполняет тот самый live migrate в файл. С дисками можно развлекаться и другими способами. Для моего подхода две основных причины (миграция вообще всего в бекап файл одним махом)
1. все происходит в составе одного flow, что упрощает алгоритм с одной стороны а с другой, при падении сразу понятно что надо чистить за собой.
2. полная синхронизация дампа памяти и дампа дисков, которая может оказаться нетривиальной если использовать для них два разных подхода.
> В любом случае, для этой ниши существует state replication и вмваре, прыгать вокруг целостного стейта с текущим состоянием дел в qemu слишком дорого
а вот это не верно. vmware не панацея от всего, это очень дорогое удовольствие, которое в принципе вполне можно забросить совсем, благо опенсорса хватает, и он мало где отстает, а во многом даже обгоняет vmware. Весь этот функционал уже есть в qemu-kvm, в либвирт еще не сделали удобную оркестрацию для некоторых шагов, но над этим я намереваюсь поработать.
это главное в данном случае. virsh save выполняет тот самый live migrate в файл. С дисками можно развлекаться и другими способами. Для моего подхода две основных причины (миграция вообще всего в бекап файл одним махом)
1. все происходит в составе одного flow, что упрощает алгоритм с одной стороны а с другой, при падении сразу понятно что надо чистить за собой.
2. полная синхронизация дампа памяти и дампа дисков, которая может оказаться нетривиальной если использовать для них два разных подхода.
> В любом случае, для этой ниши существует state replication и вмваре, прыгать вокруг целостного стейта с текущим состоянием дел в qemu слишком дорого
а вот это не верно. vmware не панацея от всего, это очень дорогое удовольствие, которое в принципе вполне можно забросить совсем, благо опенсорса хватает, и он мало где отстает, а во многом даже обгоняет vmware. Весь этот функционал уже есть в qemu-kvm, в либвирт еще не сделали удобную оркестрацию для некоторых шагов, но над этим я намереваюсь поработать.
Да, безусловно, с довольно давних времен консистентный дамп всего в qemu стал делаться быстро для cow образов, но из использования такого блокбекенда вытекает масса явных и неявных проблем при масштабировании одной виртуалки или при масштабировании их группы. Синхронизировать состояния для двух разных механизмов для хранилки и для памяти из коробки сейчас тоже невозможно, но там доделки на два рубля. Все же мы обсуждаем очень нишевое решение, процент пользователей, которым действительно необходим полный стейт, а фриза фс внутри недостаточно, очень невелик и у них как правило есть возможность раскошелиться на коробочный вариант.
ну во первых qcow2 сам по себе вполне неплохо работает. проблемы начинаются когда он используется по назначению — с цепочкой снепшотов. Но если послушать тех же vmware, у них те же проблемы, и использование цепочек категорически не рекомендуется в production и под нагрузкой. Это не проблема QEMU а проблема COW как технологии, в любой реализации. best practice для kvm это raw image. с него можно снять cow снепшот, и когда надобность в снепшоте отпадает (бекап или тестирование патча например) надо сделать blockcommit.
> Синхронизировать состояния для двух разных механизмов для хранилки и для памяти из коробки сейчас тоже невозможно
а как же тогда работает живая блочная миграция?
> Все же мы обсуждаем очень нишевое решение, процент пользователей, которым действительно необходим полный стейт, а фриза фс внутри недостаточно, очень невелик и у них как правило есть возможность раскошелиться на коробочный вариант
имхо не факт. KVM сейчас везде, во всех нишах, и конечно же я бы и сам предпочел бы использовать только достаточно консистентный дамп диска в большинстве случаев. Но и на полный бекап вообще всего найдется желающий — было бы готовое решение. С KVM на самом деле ведь что радует, так это то что на хосте — линукс, а значит иснтрументов и возможностей полным полно. Не нужно извращаться как в вмвари или ставить непонятно что непонятно от кого, как в винде. А значит можно не только реализовать возможности, но и предоставить более чем одну, для более чем одного юз-кейса
> Синхронизировать состояния для двух разных механизмов для хранилки и для памяти из коробки сейчас тоже невозможно
а как же тогда работает живая блочная миграция?
> Все же мы обсуждаем очень нишевое решение, процент пользователей, которым действительно необходим полный стейт, а фриза фс внутри недостаточно, очень невелик и у них как правило есть возможность раскошелиться на коробочный вариант
имхо не факт. KVM сейчас везде, во всех нишах, и конечно же я бы и сам предпочел бы использовать только достаточно консистентный дамп диска в большинстве случаев. Но и на полный бекап вообще всего найдется желающий — было бы готовое решение. С KVM на самом деле ведь что радует, так это то что на хосте — линукс, а значит иснтрументов и возможностей полным полно. Не нужно извращаться как в вмвари или ставить непонятно что непонятно от кого, как в винде. А значит можно не только реализовать возможности, но и предоставить более чем одну, для более чем одного юз-кейса
> а как же тогда работает живая блочная миграция?
имелся в виду вариант без нее, п.2
Все же непонятно, почему fsfreeze вам не хватает, есть реальные случаи для этого? Да, cow плох, когда он не обеспечивается большой хранилкой, переваривающей операции со снимками без потерь, цеф там будет или нетапп — уже вторично, поэтому его использование в большом продакшене отпадает. Остается (для вашего случая) драйвмиррор или драйвбекап, которые будут очень сильно грузить в горлышке одной вычноды.
имелся в виду вариант без нее, п.2
Все же непонятно, почему fsfreeze вам не хватает, есть реальные случаи для этого? Да, cow плох, когда он не обеспечивается большой хранилкой, переваривающей операции со снимками без потерь, цеф там будет или нетапп — уже вторично, поэтому его использование в большом продакшене отпадает. Остается (для вашего случая) драйвмиррор или драйвбекап, которые будут очень сильно грузить в горлышке одной вычноды.
> имелся в виду вариант без нее, п.2
ааа, ну тогда я и говорю, если гонять один механизм для всего, то и синхронизация будет на месте.
> Все же непонятно, почему fsfreeze вам не хватает, есть реальные случаи для этого?
ну во первых не для всех гостей есть qemu-ga. что делать с теми где его нет? во вторых, что делать на системах где все бегает уже много лет, а qemu изрядно устарел? ну и в третьих, конечно же те самые линуксовые апликации которые даже упомянутым в статье хуком не зацепить. честно говоря вот так от фонаря не возьмусь привести пример (да и домой уже пора бежать) но при наличии возможности, и желающие подтянутся.
> Остается (для вашего случая) драйвмиррор или драйвбекап, которые будут очень сильно грузить в горлышке одной вычноды
на самом деле не должны, иначе тот же lvm mirror или drbd (я уже молчу о zerto и veeam) никто бы не использовал. оверхед есть, но он на хосте, и при дОлжном планировании на VM влиять не должен никак.
ааа, ну тогда я и говорю, если гонять один механизм для всего, то и синхронизация будет на месте.
> Все же непонятно, почему fsfreeze вам не хватает, есть реальные случаи для этого?
ну во первых не для всех гостей есть qemu-ga. что делать с теми где его нет? во вторых, что делать на системах где все бегает уже много лет, а qemu изрядно устарел? ну и в третьих, конечно же те самые линуксовые апликации которые даже упомянутым в статье хуком не зацепить. честно говоря вот так от фонаря не возьмусь привести пример (да и домой уже пора бежать) но при наличии возможности, и желающие подтянутся.
> Остается (для вашего случая) драйвмиррор или драйвбекап, которые будут очень сильно грузить в горлышке одной вычноды
на самом деле не должны, иначе тот же lvm mirror или drbd (я уже молчу о zerto и veeam) никто бы не использовал. оверхед есть, но он на хосте, и при дОлжном планировании на VM влиять не должен никак.
Для примера «не зацепить» можно взять работающий докер. Проблема оверхеда в том, что он создается в рамках одной ноды и влияет на нее же. LVM миррор и DRBD в современном мире действительно, никто не использует :)
оверхед можно отделить от рабочих нагрузок, например при помощи cgroups, о чем я и писал. оверхед не должен влиять на продакшен
Безусловно, отделить можно, просто он тут на ровном месте и большой. Допустим, однократная процедура бекапа 200гбайт-образа выльется, при скорости блочной миграции ну 200мбайт/с, в 40+ минут только на переезды плюс ну полчаса минимум (в реальности скорее 2-3 часа) на отслаивание образа, даже если не брать его сжатие. Процедура восстановления займет, с учетом спиноффа прямо на бекап-сервере и последующего переезда, минут 20. Теперь ухудшаем ситуацию до двух-трех таких операций в параллель и получаем насыщение на уровне очередности операций, при этом принимая допущение, что бекап-сервер обладает как минимум десятигигабитным интерфейсом, у него хватает на все задачи процессора и нет вероятности появления более срочной и приоритетной операции.
Принимая во внимание тот факт, что вы отстраиваете решение на локальном хранилище, непонятно, зачем использовать блочную миграцию для бекапов вместо операции drive_backup, это втрое уменьшит объем сетевого трафика. Ну из из топорной калькуляции выше видно, что проблемы наступают очень рано, примерно на уровне пары-тройки компьют в расчете на один бекапсервер (бекап раз в 3..7 дней, компьюты содержат ну пусть 2Тб данных каждая).
Принимая во внимание тот факт, что вы отстраиваете решение на локальном хранилище, непонятно, зачем использовать блочную миграцию для бекапов вместо операции drive_backup, это втрое уменьшит объем сетевого трафика. Ну из из топорной калькуляции выше видно, что проблемы наступают очень рано, примерно на уровне пары-тройки компьют в расчете на один бекапсервер (бекап раз в 3..7 дней, компьюты содержат ну пусть 2Тб данных каждая).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Резервное копирование виртуальных машин в среде гипервизора QEMU/KVM