Как известно, бэкапы нужно делать, мало того, нужно делать их так, чтобы потом с них можно было развернуться. Особенно это касается виртуальных машин (ВМ). Рассмотрим, как можно сделать бэкап виртуальных дисков машины в среде 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"
А как обстоят дела с 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, поскольку хоть агент и «замораживает» все смонтированные ФС за одну команду, однако делает это не одновременно, а последовательно, так что возможна рассинхронизация между томами.
Если вы нашли в статье ошибку, или же вам есть, что сказать — прошу в комментарии.
Делайте бэкапы, господа!
