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

Как известно, бэкапы нужно делать, мало того, нужно делать их так, чтобы потом с них можно было развернутся. Особенно это касается виртуальных машин (ВМ). Рассмотрим, как можно сделать бэкап виртуальных дисков машины в среде 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 надо править исходные коды соответствующих продуктов, что выходит за рамки этой статьи.

Допустим, мы нашли способ (например, самописным скриптом), “замораживать” ФС гостя перед снятием снэпшота. Теперь перед нами стоит следующая задача — оповестить гостевое ПО непосредственно перед заморозкой. 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.

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

У каждого способа есть свои полюсы и минусы. Так, способ «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, поскольку хоть агент и «замораживает» все смонтированные ФС за одну команду, однако делает это не одновременно, а последовательно, так что возможна рассинхронизация между томами.

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

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

Автор: lovecraft

Источник