Резервное копирование виртуальных машин в среде гипервизора QEMU/KVM

  • Tutorial
image

Как известно, бэкапы нужно делать, мало того, нужно делать их так, чтобы потом с них можно было развернуться. Особенно это касается виртуальных машин (ВМ). Рассмотрим, как можно сделать бэкап виртуальных дисков машины в среде QCOW/KVM. Основных проблем здесь две: во-первых, нужно получить консистентый (целостный) бэкап, т.е. если у нас есть СУБД или другое ПО, которое активно использует собственный кэш на запись, то перед бэкапом его нужно попросить сбросить кэш и заморозить запись на диск, иначе данные-то в снэпшот попадут, но не те, и при восстановлении СУБД может не понять такой финт. Второй вопрос — производительность ВМ в режиме снэпшота, неплохо было бы, что бы ВМ не слишком тормозила, когда мы снимаем копию, и не зависала бы, когда мы удаляем снэпшот.

Сразу дам ответ на первый вопрос — чтобы получить консистентный бэкап, нужно перед созданием бэкапа выключить ВМ средствами гостевой ОС, тогда бэкап точно получится целостным. Если вас устраивает такая ситуация — статью можно дальше не читать. Если же нет — прошу под кат.

Итак, чтобы получить консистентный бэкап, не выключая ВМ, нужно использовать гостевой агент для QEMU (не путать с гостевым агентом для QEMU SPICE и паравиртуальными драйверами для QEMU вообще). В репозитории Debian Jessie это пакет qemu-guest-agent, в Wheezy пакет доступен только через wheezy-backports. QEMU guest agent — это небольшая утилита, которая принимает команды от хоста через virio-канал с именем org.qemu.guest_agent.0 и исполняет их в контекста гостя. На стороне гипервизора канал заканчивается unix-сокетом, в который можно писать текстовые команды с помощью утилиты socat. Libvirt, правда, любит сама занимает этот канал, так что в случае, если вы для управления гипервизором используйте Libvirt, общаться с гостем придется через команду “virsh qemu-agent-command”. Команды QEMU guest agent умеет разные, вот, например, мой список:

  • guest-set-vcpus
  • guest-get-vcpus
  • guest-network-get-interfaces
  • guest-suspend-hybrid
  • guest-suspend-ram
  • guest-suspend-disk
  • guest-fstrim
  • guest-fsfreeze-thaw
  • guest-fsfreeze-freeze
  • guest-fsfreeze-status
  • guest-file-flush
  • guest-file-seek
  • guest-file-write
  • guest-file-read
  • guest-file-close
  • guest-file-open
  • guest-shutdown
  • guest-info
  • guest-set-time
  • guest-get-time
  • guest-ping
  • guest-sync
  • guest-sync-delimited

Краткое описание команд есть в файле qga/qapi-schema.josn в исходниках QEMU, а полное можно получить путем анализа файлов qga/commands-posix.c и qga/commands-win32.c. Из анализа можно, например, узнать, что команды guest-set-vcpus, guest-get-vcpus, guest-network-get-interfaces, guest-suspend-hybrid, guest-suspend-ram, guest-suspend-disk под Windows не поддерживаются, а команды guest-fsfreeze-freeze/guest-fsfreeze-thaw пытаются под Windows использовать теневое копирование тома — VSS. Однако, поскольку в статье речь пойдет о Linux в качестве гостя, нас эти тонкости касаться не будут.

Среди всего списка команд нас интересуют guest-fsfreeze-freeze и guest-fsfreeze-thaw. Как следует из названия, первая из них “замораживает” файловую систему гостя, а вторая “размораживает” ее. Команда (точнее IOCTL) fsfreeze — это не фича QEMU, а способность виртуальной файловой системы гостя, которая появиласть в ядре Linux довольно давно. То есть, замораживать ФС можно не только в виртуальной среде, но и на реальном железе, достаточно воспользоваться утилитой fsfreeze из пакета util-linux. В man-е fsfreeze сказано, что поддерживаются Ext3/4, ReiserFS, JFS, XFS, но у меня fsfreeze “заморозил” и Btrfs. Перед собственно “заморозкой”, но уже после того, как отработали все потоки записи, кодом ядра вызвается sync() (файл fs/super.c, строка 1329), так что за целостность данных можно не беспокоиться. Вообще, “заморозка” ФС нужна ядру для получения целостных снэпшотов LVM-томов, а не для сомнительных забав с системами виртуализации.

Итак, мы знаем, что для получения целостного снэпшота нам нужно из гостя с помощью QEMU guest agent вызвать функцию guest-fsfreeze-freeze. Однако, быть может, мы зря волнуемся и эта функция вызвается при создании снэпшота? Увы, и для Libvirt (2.9), и для Proxmox (ветка pvetest), и для Openstack это не так, а значить, чтобы автоматизировать вызов функции guest-fsfreeze-freeze надо править исходные коды соответствующих продуктов, что выходит за рамки этой статьи.

Libvirt все-таки умеет замораживать гостевую ФС
Как подсказывает уважаемый Infod, оболочке virsh из состава Libvirt можно при создании снэпшота передать параметр --quiesce, который вызовет guest-fsfreeze-freeze при создании снэпшота:
virsh snapshot-create-as myvm snapshot1 "snapshot1 description" --disk-only --atomic --quiesce

Допустим, мы нашли способ (например, самописным скриптом), “замораживать” ФС гостя перед снятием снэпшота. Теперь перед нами стоит следующая задача — оповестить гостевое ПО непосредственно перед заморозкой. QEMU guest agent поддерживает параметр -F, который говорит о том, что перед “заморозкой” и после “разморозки” нужно вызвать скрипт /etc/qemu/fsfreeze-hook и параметрами freeze и thaw соответственно. Поэтому в Debian скрипт запуска агента (/etc/init.d/qemu-guest-agent) придется поправить: DAEMON_ARGS=”-F”. Имейте в виду, что если скрипт завершится с ошибкой, “заморозки” ФС не произойдет.

Для MySQL сервера первый пришедший на ум, но неработающий скрипт может выглядеть примерно так:

#!/bin/bash

USER="<Пользователь>"
PASSWORD="<Пароль>"


case "$1" in
  freeze  ) 
            /usr/bin/mysql -u $USER -p$PASSWORD -e "FLUSH TABLES WITH READ LOCK;"
            exit $?
            ;;

  thaw    ) 
            /usr/bin/mysql -u $USER -p$PASSWORD -e "UNLOCK TABLES;"
            exit $?
            ;;

  *       ) 
            logger Fsfreeze script has activated with unknown parameter: $1
            exit 1
            ;;
esac

exit 1


На самом деле блокировка с базы будет снята сразу по завершении команды
mysql -u $USER -p$PASSWORD -e "FLUSH TABLES WITH READ LOCK"
из-за того, что все блокировки в MySQL работают лишь пока пользователь, поставивший их, присутствует в системе. Для правильного бэкапа придется писать дополнительный небольшой сервис (например, на Python) который будет открывать базу MySQL и ставить блокировку по команде freeze, а затем не закрывать базу и ждать команду thaw.

А как обстоят дела с Windows в роли гостя?
Надо сказать, что для Windows и MS SQL эта же процедура не требует никаких теложвижений — QEMU guest agent автоматически вызывает соответствующую функцию службы теневого копирования тома VSS, VSS информирует всех подписчиков о том, что вот-вот начнется бэкап и неполохо было бы “сброситься” на диск и т.п.


Итак, мы заблокировали MySQL-таблицы и “заморозили” ФС гостя, пришла пора снимать бэкап. Предположим, что мы храним образа дисков ВМ в файлах формата qcow2, а не, например, в виде LVM-томов. Даже в этом случае нам предлагается множество вариантов, неплохо бы в них разобраться.

Internal QEMU snapshot External QEMU snapshot QEMU backup Снэпшот LVM-тома с файлами qcow2 Снэпшот ФС Brtfs с файлами qcow2
Средство QEMU QEMU QEMU ОС ОС
Команда QEMU savevm/snapshot_blkdev_internal snapshot_blkdev drive_backup
Команда libvirt/virsh snapshot-create/snapshot-create-as snapshot-create/snapshot-create-as
Команда ОС lvcreate btrfs subvolume snapshot
Вид Записи внутри образа диска Отдельный файл — образ диска Отдельный файл — образ диска Блочное устройство ФС (каталог) с образами дисков
Область действия Конкретная ВМ Конкретная ВМ Конкретная ВМ Всё хранилище Всё хранилище
Технология Перенаправление записи в другую область того же файла Перенаправление записи в другой файл Полное копирование дисков машины в другой файл Копирование оригинальных данных на устройство снэпшота при их изменении Перенаправление записи в другую область файловой системы
Копирование снэпшота в хранилище резервных копий qemu-nbd/nbd-client Копирование файла Копирование файла Монтирование снэпшота, копирование файла Копирование файла
Быстродействие дисков ВМ на запись, когда снэпшот создан Среднее (на каждую запись нужно сделать два sync(), опция qcow2:lazy refcounts улучшает ситуацию) Высокое Высокое Ниже обычного примерно в 2 раза Высокое
Нагрузка на хранилище при удалении (commit) снэпшота Ниже средней (нужно перезаписать метаданные) Высокая (нужно скопировать данные в исходный образ и перезаписать метаданные) Низкая (нужно удалить файл) Низкая (нужно удалить блочное устройство) Ниже средней (нужно перезаписать метаданные)
Нагрузка на хранилище при откате (rollback) на снэпшот Ниже средней (нужно перезаписать метаданные) Низкая (нужно удалить файл) Низкая для Libvirt (нужно заменить файл), высокая для Proxmox (нужно распаковать файл из архива) Высокая (нужно скопировать данные на исходное блочное устройство) Ниже средней (нужно перезаписать метаданные)

У каждого способа есть свои плюсы и минусы. Так, способ «Internal» является, по-сути, стандартом в утилите Virt-Manager и среде Proxmox, и получение снэпшотов такого формата автоматизировано. Однако для того, чтобы «выдернуть» снэпшот из файла, нужно поднять NBD-сервер на базе qemu-nbd и подключить файл образа к нему. В способе «External» готовый для копирования файл с резервной копей получается в процессе создания снэпшота, но процесс удаления снэпшота непрост и предусматривает «возвращение» (block-commit) записанных данных из файла снэпшота в базовый образ, что сопровождается кратным увеличением нагрузки на запись в процессе удаления снэпшота. К примеру, VMWare ESXi в такой же ситуации «проседает» по производительности на запись в 5 раз.. Надо сказать, что есть еще и другой способ удаления снэпшота типа «External» — копирование всех блоков из исходного образа в снэпшот. Способ этот называется block-stream, о целесообразности применения его в продакшене судить не берусь, но, очевидно, для хранилища это будет неплохой бенчмарк.

Снэпшот LVM-тома вызвает падение производительности основного тома на запись, так что его лучше использовать тогда, когда мы уверены, что во время существования снэпшота на диск не будут интенсивно писать.

Большие перспективы открывает использование в качестве файловой системы для хранилища образов дисков файловой системы BTRFS, поскольку в этом случае снэпшоты, сжатие и дедупликация обеспечиваются самой архитектурой ФС. Минусы — Btrfs нельзя использовать в качестве разделяемой ФС в кластерной среде, кроме того, Btrfs — относительно новая ФС и, возможно, она менее надежна, чем связка LVM и ext4.

Метод получения бекапов командой drive_backup хорош тем, что можно сразу создать резервную копию на примонтированном удаленном хранилище, однако в этом случае он создает большую нагрузку на сеть. Для остальных же способов можно предусмотреть передачу только измененных блоков с помощью rsync. К сожалению, QEMU backup не поддерживает передачу только “грязных” (измененных с момента последнего бэкапа) блоков, как это реализовано, например, в механизме VMWare CBT. Обе попытки реализовать такой механизм - livebackup и in-memory dirty bitmap не были приняты в основную ветку QEMU, судя по всему, первый — из-за архитектуры (добавляется лишний демон и отдельный сетевой протокол только для этой операции), второй — из-за очевидных ограничений в применении: карта “грязных” блоков может храниться только в оперативной памяти.

В заключение рассмотрим ситуацию, при которой ВМ имеет несколько подключенных образов дисков. Очевидно, для такой ВМ нужно создавать снэпшоты всех дисков одновременно. Если вы используйте Libvirt, то волноваться вам нечего — библиотека берет все заботы по синхронизации снэпшотов на себя. Но, если вы хотите выполнить эту операцию на «чистом» QEMU, то существует два способа сделать это: остановить ВМ командой stop, получить снэпшоты, а затем продолжить исполнение ВМ командой cont или же использовать механизм транзакционного выполнения команд, имеющийся в QEMU. Нельзя использовать для этой цели только гостевой агент QEMU и команды guest-fsfreeze-freeze/guest-fsfreeze-thaw, поскольку хоть агент и «замораживает» все смонтированные ФС за одну команду, однако делает это не одновременно, а последовательно, так что возможна рассинхронизация между томами.

Если вы нашли в статье ошибку, или же вам есть, что сказать — прошу в комментарии.

Делайте бэкапы, господа!
Share post

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 34

    +4
    А почему бы не делать суспенд гостя (все содержимое оперативной памяти, значения регистров ЦП и прочее записывается файлом на диск), потом сделать снапшот диска гостя, скопировать образ оперативной памяти и опять включить гостя?
    Суспенд занимает около 5-10 сек., столько же на выход из него. В это время естественно гость будет не доступен, но после включения продолжит работать как ни в чем не бывало (только время нужно будет подкорректировать). В данном случае не важно какой гость, т.к. все делается на стороне QEMU. При восстановлении ВМ будет восстановлена в том же состоянии, в котором снимался бэкап.
      +5
      Qemu умеет делать атомарный снимок всех дисков + память в живом режиме, без суспенда гостя — фича называется external snaphshot. После резервирования необходимо влить изменения в снапшоте обратно в основные диски — это тоже делается в живом режиме (blockcommit). Все это поддерживается и в libvirt'e, правда нормально оно стало работать только в самых свежих версиях (по-моему с 1.2.7). Также libvirt'у можно указать опцию --quiesce — она как раз и вызовет заморозку ФС всех дисков на госте при создании атомарного снапшота.
        0
        Как я понимаю эта фича поддерживается только с qcow2 дисками?
          +2
          Нет, с любыми. Процесс создания external snapshot выглядит так: вместо основных дисков (любых, LVM, raw, ceph и т.д.) создаются временные qcow2 диски, в которые с момента создания снапшота начинает идти вся запись, а оригинальные диски на это время становятся read-only. Их можно монтировать, копировать и т.д. После завершения резервирования выполняется команда blockcommit, которая в живом режиме мержит изменения из временных qcow2 дисков обратно в основные. После мержа всех дисков временные диски и снапшот можно удалять. Мерж идет быстро, т.к. копируются только изменения.
          0
          Спасибо за --quiesce, добавил в статью
          0
          Единственный минус таких бекапов — наличие кривого софта, который не поддерживает функцию принудительного сброса данных на диск перед фризом, и бекап для него может оказаться все-равно неконсистентным несмотря на все фризы и атомарность. Единственный выход для такого софта — это корректное завершение работы гостя, и бекап уже отмонтированных дисков. Раз qemu умеет создавать снапшоты с памятью, неплохо было бы создавать клон гостя, отключать ему сеть, «пробуждать», корректно делать shutdown, и бекапить отмонтированные диски. Но qemu напрямую такой возможностью не обладает. Чисто в теории можно сделать костыль — копировать (или монтировать, если общий сторадж) диски на другую машину (в случае монтирования делать повторный снапшот, чтобы не повредить оригинал), копировать туда образ памяти, убедиться, что сеть для гостя работать не будет, делать virsh resume <файл_с_памятью>, делать shutdown и бекапить. Но на практике это не проверял, да и выглядит геморройно.
          –4
          Вы забыли добавить в таблицу еще один столбец :)

          Мы в Nutanix делаем снапшоты для KVM на лету (проект Acropolis — полностью своя система управления KVM), при этом никаких проседаний по производительности нет (ровно ноль). Учитывая наличие кластерной ФС (NDFS) с ультра-высокой производительностью, отсутствие центральных точек отказа и тд — можно сказать что практически все описанные в статье проблемы мы решили.

          Я делал на Highload доклад на эту тему.

          Кому интересна презентация на тему Acropolis (вторую часть можно смотреть сразу) — вот www.dropbox.com/s/rlfbwpxhb3rumuh/acropolis.pptx?dl=0
            +2
            Проблема не в производительности, проблема в консистентности данных. При вашем подходе запросто может оказаться, что в момент снятия снапшота часть новых данных в БД уже записана на диск, а часть еще в кэше. В итоге мы в бэкапе имеем неконсистентую базу данных. В худшем случае данные могут быть повреждены до полной бесполезности.
            Автор поста как раз и говорит о способе сказать приложениям в госте, что нужно сброситьь кэши и приготовится к снятию снапшота, другой способ я описал в первом комментарии.
            А чем снимать снапшот дело десятое.
              0
              Вообще-то чем снимать снапшот — дело далеко не десятое, собственно одна из основных проблем «стандартного» KVM — отсутствие возможности снимать live снапшоты без заморозки I/O.

              Как раз дело десятое в случае правильных снапшотов (когда нет заморозки I/O и очень быстро делаются) получить консистентные данные на одной VM.

              BTRFS рекомендовать — сродни «вредных советов», она не готова для production никоим образом (нет даже утилит которые могли бы ее починить в случае сбоев).

              При этом в статье вообще не учитывается что консистентность нужна далеко не только для одной VM, но для групп VM (если у вас есть SQL сервера + приложения, то снятие консистентного снапшота с одной VM совершенно не решает проблемы рассинхронизации данных между VM)

              И да, Nutanix поддерживает consistensy groups — группы VM для одновременного снятия снапшотов.

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

              Как обычно, вместо того чтобы учиться новому, наступает агрессивная реакция ;) Именно поэтому в РФ все доходит с опозданием в 2-3 года.
                0
                Все равно это все реализуется в опенсорсе, а покупать кусочек стека за xxx денег видимо, хотят не все. С Windows разве что подмораживать ФС в общем случае чуть сложнее, вот и все. Да, и приведенный пример с несколькими VM — это реально сферический конь, ACID там ничему не позволит развалиться, поэтому что снимать снимок с одной VM, что с нескольких — разницы никакой нет, надо только попросить БД приостановить записи на время снятия, соответственно, к технологиям бекапа это не имеет отношения, это фича оркестровки.
                  0
                  Учится чему то новому никто не против. Но создалось впечатление, что ваш коллега не читал стать и быстренько накатал рекламный коммент.

                  если у нас есть СУБД или другое ПО, которое активно использует собственный кэш на запись, то перед бэкапом его нужно попросить сбросить кэш и заморозить запись на диск, иначе данные-то в снэпшот попадут, но не те

                  Еще раз: проблема в консистентности данных на диске. Снапшот позволяет получить консистентые данные на уровне блочного устройства или ФС, но это совершенно не значит, что данные будут консистентны на уровне приложения. Что бы они были консистентны приложение нужно оповестить о снятии снапшота (как это делает VSS), что бы оно сбросило кэши и тд. Собственно об этом и статья.
                  Консистентность для групп ВМ это хорошо, но сначала бы с одной ВМ разобраться.
                  Если мы друг друга не поняли и у вас эта проблема решена, то будет интересно узнать как.
                    +1
                    Согласитесь, что у QEMU и Nutanix общее только то, что оба они применяются в виртуализации. Начнем с того, что Nutanix — это (опуская частности) СХД-платформа + механизм управления гипервизором, а QEMU/KVM — собственно гипервизор, поэтому сравнивать их «в лоб» как-то неправильно, слишком это разные вещи. Обратите внимание, я не говорю, что Nutanix хуже QEMU (или лучше), я просто отмечаю, что они разные.

                    Вы говорите, что не останавливаете IO при снятии снэпшота, можно ли получить ссылку не документацию, где это говориться прямым текстом? Как тогда решается задача консистентности файловых систем гостевых машин?

                    При этом в статье вообще не учитывается что консистентность нужна далеко не только для одной VM

                    Я посчитал, что даже в случае одной ВМ и локальной СХД статья и так получается сложной. Но две последние колонки в таблице как раз подразумевают заморозку всего хранилища, так что мы получаем одновременную копию всех ВМ. Опять же, Nutanix использует кластерную СХД, а сравнивать ее с LVM не совсем корректно. Сравнивайте лучше с Ceph, OCFS2 и т.п.

                    BTRFS рекомендовать — сродни «вредных советов», она не готова для production никоим образом (нет даже утилит которые могли бы ее починить в случае сбоев).

                    В Facebook с вами не согласны, в Novell — тоже
                    Опять же, я писал в статье, что «Btrfs — относительно новая ФС и, возможно, она менее надежна, чем связка LVM и ext4», но все-таки «пациент скорее жив, чем мертв».

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

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

                В упомянутом выше Proxmox, архивация по умолчанию использует мгновенные снимки и позволяет выполнять архивацию без остановок гостевой системы.
                После восстановления из такого образа система возвращается к жизни ровно так-же как после сбоя питания.
                Однозначно сказать, что большее зло — периодические переключения рабочих режимов ПО на уровне ОС гостя или гарантированное невмешательство в работу гостевой системы и прозрачная архивация средствами хоста, сказать сложно.
                Но думаю в 90% случаев мгновенные снапшоты средствами LVM без остановки гостя и параллельной архивацией будут достаточны.

                А из статьи создается ощущение для не посвещенных, что существует такая проблема как архивация виртульных машин без остановки её работы, и её решение чрезвычайно сложное.
                  0
                  Выполнять на стороне гостя любые процедуры прерывания записи особенно на высоко нагруженных виртуальных машинах это гораздо большее зло, чем простые онлайн снапшоты LVM на стороне хоста.


                  Вы будете удивлены, но механизм fsfreeze (с предварительным sync, подробности — в исходниках ядра, файл fs/super.c) создан как раз для того, чтобы снимать снапшоты через LVM и при этом не получить вместо метаданных ФС на томе тыкву.
                  Просто мы делаем fsfreeze не при вызове lvcreate, а раньше.

                  А из статьи создается ощущение для не посвященных, что существует такая проблема как архивация виртуальных машин без остановки её работы, и её решение чрезвычайно сложное.

                  Да нет, сделать архив просто, но не факт, что с такого архива можно потом развернуться. Вот, например, товарищи из Acronis тоже статьи на эту тему пишут: habrahabr.ru/company/acronis/blog/207472/

                  ,
                  0
                  Описанный подход прекрасно работает, если совмещать его с дисковым бекендом, позволяющим делать атомарные снимки — у нас в Flops.ru бекапы создаются именно таким образом, при этом использование открытых компонент позволяет получить желаемое бесплатно. Единственный недостаток такого подхода — файловые системы, которые отказываются фризиться по каким-то причинам, в БД-ориентированном шаблоне это может обходиться выносом datastore БД на отдельную (эксклюзивную) точку монтирования.
                    0
                    Отличная статья, лично я дожидаюсь когда уже заработает blockpull, а то blockcommit усложняет управление образами.

                    Альтернативный, и по настоящему хороший, на мой взгляд, подход, был бы не бекап как таковой, а живая миграция в бекап-образ, состоящий из domxml+disk images+memstate. Тогда рестор получился бы таким же как результат живой миграции с дисками на destination host, нет проблем с консистентностью, т.к. все что не на дисках найдется в memstate, короче сплошные плюсы. Правда надо при таких раскладах больше места чтоб хранить дампы памяти и с инкрементальными бекапами придется повозиться.

                    libvirt, к сожалению, пока такому не научили, хотя оба Даниэля вроде как не против идеи.
                      0
                      Нюанс в том, что все вариации на эту тему очень небыстрые, для промышленного флоу их использовать сложновато. Плюс корка сейчас на лету без простоя не снимается, что ведет к еще большим потерям :).
                        0
                        Вариации могут быть настолько быстры насколько способно железо, а с быстрым железом, там где гоняют большие кластеры проблем обычно не бывает.

                        Корка на лету срывается с той же задержкой что и живая миграция, собственно в любой живой миграции задержка — ключевой момент. Мы (наигравшись в ассасинов наверное) называли этот момент «leap of faith». Если бекап делается локально, то задержки практически нет. Я как раз и вижу такую систему бекапа как софт на хосте. При надобности снять бекап, ВМ мигрирует на хост, сбрасывает набор domxml+disk images+memstate на локальные staging диски, и улетает дальше, вместо нее приходит другая. Можно это делать в несколько потоков.
                          0
                          Мигрирует блочной миграцией? Вообще описанный вариант про корку из коробки недоступен, хотя его можно сделать минимальными силами, и опять же пока дисковый снимок отклеивается (если в этом есть необходимость), все может тормозить. И зачем в любом случае мигрировать машину для снятия бекапа?
                            0
                            Ну да, конечно блочной миграцией. Она в принципе ничем не медленнее чем просто копия диска под снепшотом. throttling можно делать опять же. Тормозить все может даже при представленном выше варианте — копирование диска будет жрать ресурсы хоста.

                            > И зачем в любом случае мигрировать машину для снятия бекапа?

                            бекап виртуалки можно делать четырьмя основными методами на сегодняшний день. Все что есть на рынке и гитхабе — вариации на тему:
                            1. бекап классический — агент внутри VM, все как будто VM ничем не отличается от физической машины. этот вариант не интересен
                            2. бекап со стороны СХД — снепшот снимается средствами снепшота СХД, хост где бегает машина и собственно система виртуализации никакого отношения к этому не имеет. Конечно возможна интеграция, quiesce и всяческая оркестрация, но не в этом суть. Самим СХД могут быть не обязательно монстры от ЕМС, но и тот же LVM/ZFS/…
                            3. бекап в виртуальный appliance. VM бекапер бежит параллельно с VM которую надо забекапить. В режиме r/o к бекаперу цепляются диски которые надо сохранить, и апплаенс перетягивает инфу к себе, после чего отключается от дисков. Так работает основная масса решений под vmware. да и в oVirt для этого есть api.
                            4. бекап на самом гипервизоре — это или снепшот/запись, но снепшот средствами гипервизора, или то что описал я.

                            Ставить 4-й вариант на всех хостах, имхо, глупо. Особенно если staging диски у него локальные. Гораздо проще мигрировать на хост нужную VM, снять с нее нужный датасет прямо в staging, и угнать ее на обычный хост.
                              0
                              А какие плюсы этот подход дает? Если продолжать держать информацию о снимках в образе, чтобы получать дифференциальные детачнутые копии, то это будет растить размер блок-бекенда, который еще по замыслу катается между машинами, если снимать каждый раз полный дамп — проще воспользоваться drive-backup или чем-то схожим по смыслу и ничего никуда не мигрировать (похоже вариант 3, если имелось в виду то же). В любом случае, двойная блочная миграция в процессе не выглядит продакшеном :)
                                0
                                я же писал — полная консистентность за счет снимка памяти. рестор с т.з. VM выглядит как завершение живой миграции. Проблемы со временем конечно будут, но где их нет?
                                  0
                                  Уточню, акцент на ресурсоемкости такого флоу в целом.
                                    0
                                    с этим я и не спорил. за все надо платить. тут уже упоминали проблемы консистентности даже в случае использования quiesce, с моим решением таких проблем не будет. и рестор будет максимально гладким. стоит ли это потраченного времени и дискового пространства — решать тем кто решение выбирает
                                      0
                                      Хорошо, заменяем фриз на отслаивание памяти (не прямым дампом, а мигратоподобным вариантом или его аналогом, как выше) и снимком на хранилище из п.2, получаем тот же простой в районе долей секунды и ту же «абсолютную консистентность». Месседж с моей стороны таков, что попытка сделать указанные вещи на обычных локальных образах, raw или cow, приведет к очень высокому оверхеду из-за необходимости прокачивать большой объем данных в первом случае и потенциальной необходимости отслаивать снимки и также прокачивать много байтов во втором, без отслоения надо либо их ротировать, либо все затормозит. Впрочем, такой подход вполне себе имеет право на жизнь, если время доступности бекапа с момента его создания может сильно варьироваться и не регламентировано жестко (доступность = выкачанность на другую физическую сущность).

                                      В любом случае, для этой ниши существует state replication и вмваре, прыгать вокруг целостного стейта с текущим состоянием дел в qemu слишком дорого.
                                        0
                                        > заменяем фриз на отслаивание памяти (не прямым дампом, а мигратоподобным вариантом или его аналогом, как выше)

                                        это главное в данном случае. virsh save выполняет тот самый live migrate в файл. С дисками можно развлекаться и другими способами. Для моего подхода две основных причины (миграция вообще всего в бекап файл одним махом)
                                        1. все происходит в составе одного flow, что упрощает алгоритм с одной стороны а с другой, при падении сразу понятно что надо чистить за собой.
                                        2. полная синхронизация дампа памяти и дампа дисков, которая может оказаться нетривиальной если использовать для них два разных подхода.

                                        > В любом случае, для этой ниши существует state replication и вмваре, прыгать вокруг целостного стейта с текущим состоянием дел в qemu слишком дорого

                                        а вот это не верно. vmware не панацея от всего, это очень дорогое удовольствие, которое в принципе вполне можно забросить совсем, благо опенсорса хватает, и он мало где отстает, а во многом даже обгоняет vmware. Весь этот функционал уже есть в qemu-kvm, в либвирт еще не сделали удобную оркестрацию для некоторых шагов, но над этим я намереваюсь поработать.
                                          0
                                          Да, безусловно, с довольно давних времен консистентный дамп всего в qemu стал делаться быстро для cow образов, но из использования такого блокбекенда вытекает масса явных и неявных проблем при масштабировании одной виртуалки или при масштабировании их группы. Синхронизировать состояния для двух разных механизмов для хранилки и для памяти из коробки сейчас тоже невозможно, но там доделки на два рубля. Все же мы обсуждаем очень нишевое решение, процент пользователей, которым действительно необходим полный стейт, а фриза фс внутри недостаточно, очень невелик и у них как правило есть возможность раскошелиться на коробочный вариант.
                                            0
                                            ну во первых qcow2 сам по себе вполне неплохо работает. проблемы начинаются когда он используется по назначению — с цепочкой снепшотов. Но если послушать тех же vmware, у них те же проблемы, и использование цепочек категорически не рекомендуется в production и под нагрузкой. Это не проблема QEMU а проблема COW как технологии, в любой реализации. best practice для kvm это raw image. с него можно снять cow снепшот, и когда надобность в снепшоте отпадает (бекап или тестирование патча например) надо сделать blockcommit.

                                            > Синхронизировать состояния для двух разных механизмов для хранилки и для памяти из коробки сейчас тоже невозможно

                                            а как же тогда работает живая блочная миграция?

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

                                            имхо не факт. KVM сейчас везде, во всех нишах, и конечно же я бы и сам предпочел бы использовать только достаточно консистентный дамп диска в большинстве случаев. Но и на полный бекап вообще всего найдется желающий — было бы готовое решение. С KVM на самом деле ведь что радует, так это то что на хосте — линукс, а значит иснтрументов и возможностей полным полно. Не нужно извращаться как в вмвари или ставить непонятно что непонятно от кого, как в винде. А значит можно не только реализовать возможности, но и предоставить более чем одну, для более чем одного юз-кейса
                                              0
                                              > а как же тогда работает живая блочная миграция?

                                              имелся в виду вариант без нее, п.2

                                              Все же непонятно, почему fsfreeze вам не хватает, есть реальные случаи для этого? Да, cow плох, когда он не обеспечивается большой хранилкой, переваривающей операции со снимками без потерь, цеф там будет или нетапп — уже вторично, поэтому его использование в большом продакшене отпадает. Остается (для вашего случая) драйвмиррор или драйвбекап, которые будут очень сильно грузить в горлышке одной вычноды.
                                                0
                                                > имелся в виду вариант без нее, п.2

                                                ааа, ну тогда я и говорю, если гонять один механизм для всего, то и синхронизация будет на месте.

                                                > Все же непонятно, почему fsfreeze вам не хватает, есть реальные случаи для этого?

                                                ну во первых не для всех гостей есть qemu-ga. что делать с теми где его нет? во вторых, что делать на системах где все бегает уже много лет, а qemu изрядно устарел? ну и в третьих, конечно же те самые линуксовые апликации которые даже упомянутым в статье хуком не зацепить. честно говоря вот так от фонаря не возьмусь привести пример (да и домой уже пора бежать) но при наличии возможности, и желающие подтянутся.

                                                > Остается (для вашего случая) драйвмиррор или драйвбекап, которые будут очень сильно грузить в горлышке одной вычноды

                                                на самом деле не должны, иначе тот же lvm mirror или drbd (я уже молчу о zerto и veeam) никто бы не использовал. оверхед есть, но он на хосте, и при дОлжном планировании на VM влиять не должен никак.
                                                  0
                                                  Для примера «не зацепить» можно взять работающий докер. Проблема оверхеда в том, что он создается в рамках одной ноды и влияет на нее же. LVM миррор и DRBD в современном мире действительно, никто не использует :)
                                                    0
                                                    оверхед можно отделить от рабочих нагрузок, например при помощи cgroups, о чем я и писал. оверхед не должен влиять на продакшен
                                                      0
                                                      Безусловно, отделить можно, просто он тут на ровном месте и большой. Допустим, однократная процедура бекапа 200гбайт-образа выльется, при скорости блочной миграции ну 200мбайт/с, в 40+ минут только на переезды плюс ну полчаса минимум (в реальности скорее 2-3 часа) на отслаивание образа, даже если не брать его сжатие. Процедура восстановления займет, с учетом спиноффа прямо на бекап-сервере и последующего переезда, минут 20. Теперь ухудшаем ситуацию до двух-трех таких операций в параллель и получаем насыщение на уровне очередности операций, при этом принимая допущение, что бекап-сервер обладает как минимум десятигигабитным интерфейсом, у него хватает на все задачи процессора и нет вероятности появления более срочной и приоритетной операции.

                                                      Принимая во внимание тот факт, что вы отстраиваете решение на локальном хранилище, непонятно, зачем использовать блочную миграцию для бекапов вместо операции drive_backup, это втрое уменьшит объем сетевого трафика. Ну из из топорной калькуляции выше видно, что проблемы наступают очень рано, примерно на уровне пары-тройки компьют в расчете на один бекапсервер (бекап раз в 3..7 дней, компьюты содержат ну пусть 2Тб данных каждая).
                                                        0
                                                        Большой, я и не спорю. Но я выше уже писал, основной набор бекапов можно делать вышеуказанным методом, или методом #2, с вызовом fsfreeze через qemu-ga. Для полного бекапа с memstate набор таргетов вряд ли будет большим.

                    Only users with full accounts can post comments. Log in, please.