Пауза виртуальной машины kvm

ты ещё о passthrough девайсах подумай.

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

время же как-то синхронизуется из вне, например: по ntp. Последствия: некие данные записались в базу с временной меткой n. а на самом деле это n + 15 секунд в реальном времени.

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

Самому ораклу по идее плевать, не рассыпится

подтверждаю.
после паузы ораклу пофиг.

Очково конечно на паузу ставить, но и выключать виртуалку тогда не понятно как. Вот как мне её выключить из скрипта? virsh shutdown? После чего мне грепать вывод virsh list и ждать пока она исчезнет из вывода? Костыли какие-то... Может можно как-то умнее?

по другому я тоже не знаю.
можно грепать статусы всех. у list есть --all, который покажет и активные и не очень.

Это же жесть...

http://libvirt.org/html/libvirt-libvirt.html#virDomainGetState

никакие снапшоты ни lvm, ни zfs, ни qcow2 (в основе которых положен общий механизм копирования при записи, но с разной реализацией) не служат в качестве механизма бекапирования sql, для этого нужно использовать внутренние возможности БД или специализированные утилиты. Для бекапов sql можно пойти разными путями:

1. Сделать дамп БД, а затем уже снапшот виртуалки;

2. Остановить БД и сделать снапшот vm;

3. Залочить таблицы БД и сделать снапшот;

4. Реплецировать БД на вторичный сервер/сервера и с них дампить БД.

в 99,99% никак

Ковыряюсь я тут со снепшотами qcow2.
нужна пауза vm на 15 секунд,

только zfs имеет человеческую реализацию Copy-on-write и позволяет получать действительно мгновенные снапшоты.

только zfs имеет человеческую реализацию Copy-on-write и позволяет получать действительно мгновенные снапшоты.

А чем qcow/lvm/btrfs снапшоты хуже?

Снапшот уровня файловой системы, расположен ниже снапшота уровня виртуальной машины. Для файловой системы, меня и lvm устроит. А вот для вирт. машины...

А вот для вирт. машины...

про виртуалки и говорю, у zfs есть тома, такие же как и у lvm, вот такие тома и отдаю в виде виртуального блочного устройства (диска) виртуалке, и делая снапшот zfs тома (zvol) на выходе получаю снапшот виртуалки. здесь более наглядно - Очередной тред выбора бакапов (комментарий)

Слишком мудрёно. Файлы qcow2 проще и понятнее.

Я пока тестирую следующую схему:

lvm - drbd - ext4 - qcow2. Снепшоты от qcow2 мне позволят подняться на любое время назад. Бекапы делаю так: на другой ноде принимаю drbd diff за сутки, и имею парочку снепшотов от lvm. Таким образом - в случае повреждения файлов qcow2, я смогу их вытащить с другого узла, в случае поврежедений уровнем выше - запускаю vm из снепшота на qcow2. - Такая схема мне позволит держать образы вирт. машин объёмами по 500 и выше гб. Пока я не придумал ничего более умнее и быстрее в плане резервных копий.

В описанном способе с zfs - не понятно, куда девать дальше потом эти снепшоты. По сети сливать куда то? Каждый день по 100 гб? А там чего с ними? Тоже надо снепшоты, вдруг во время слива повредится что-то...

Или мы делаем снепшот от qcow2, но нам нужна пауза vm на 15 секунд

вроде уже показали что это не так

или мы делаем снепшот на внешний диск, но тогда нам потом нужен будет downtime для blockpull

и это тоже опровергли

что происходит когда VM (kvm), становится на паузу

емнип процесс замораживается, адреса в памяти тоже. при разморозке, машина может изрядно удивиться изменению по времени, но обычно ntp все исправляет.

нет, не только.

В описанном способе с zfs - не понятно, куда девать дальше потом эти снепшоты. По сети сливать куда то? Каждый день по 100 гб?

слить 100Гб нужно лишь единожды, потом передается только разница между соседними снапшотами. Очень быстро и удобно.

вроде уже показали что это не так

Да где-ж опровергли? Официальный rhel об этом пишет. :(

и это тоже опровергли

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

емнип процесс замораживается, адреса в памяти тоже. при разморозке, машина может изрядно удивиться изменению по времени, но обычно ntp все исправляет.

Хотелось бы верить :)

В drbd есть инструменты которые проверяют целостность, и т.п., в zfs есть возможность сравнить базовый образ + снепшот на корректность? Я понимаю, что zfs защищена по самое не балуйся в плане целостности данных. Но всё же.

Ну и в плане zfs пугает, то, что надо много скриптовать... :(

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

Можно удалить любой.

Да где-ж опровергли? Официальный rhel об этом пишет. :(

при запуске команды паузы нет, смепшот создается без проблем.

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

а какая разница куда собирать если остаемся с плоским имиджем?

Хотелось бы верить :)

для уточнений - в рассылку qemu

а еще есть вот такая хрень: http://www.r1soft.com/free-tool-linux-hot-copy

но я ей никогда не пользовался

при запуске команды паузы нет, смепшот создается без проблем.

При выполнении внутреннего снепшота - есть. Внешнего нет.

а какая разница куда собирать если остаемся с плоским имиджем?

Так плоского имиджа нету. Будет же один base имидж, и как минимум один один файл снепшота. - До тех пор, пока не выполним blockpull. А если надо несколько снепшотов - то будет один + файлы снепшотов. Ни о какой плоскости речи нет. :( Или я реально что-то не так понял?

а еще есть вот такая хрень: http://www.r1soft.com/free-tool-linux-hot-copy

Кхм... Не очень понятно зачем оно, если есть lvm или zfs...

слить 100Гб нужно лишь единожды, потом передается только разница между соседними снапшотами. Очень быстро и удобно.

Скажите, как вы поднимаетесь потом на другом узле? virsh xmldump? virsh xmlrestore? Как синхронизируете файлы конфигурации?

Снепшоты от qcow2 мне позволят подняться на любое время назад

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

А как на другом узле подняться в таком случае? Образы, снепшоты перекинули. Дальше то чего делать? Настраивать сеть, делать xmldump? Может как-то можно быстрее и удобнее?

Как синхронизируете файлы конфигурации?

синькнуть по сети директорию с конфигами (rsync или lsyncd)

А как на другом узле подняться в таком случае?

zfs snapshot kvmpool/vm9@`date --rfc-3339=date`
zfs list -t snapshot 
zfs send kvmpool/vm9@2013-11-04 | ssh 192.168.10.12 zfs receive -vdF kvmpool
virsh create /etc/libvirt/qemu/vm9.xml

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

синькнуть по сети директорию с конфигами (rsync или lsyncd)

virsh на это смотрит неадекватно... Не нравится ему затея синкать: /etc/libvirt/qemu , /var/lib/libvirt :(

Хотя /etc/libvirt/qemu, можно синкать, но потом делать destroy/create для VMs.

Хотя конечно service libvirt-bin restart вроде как заставляет его проглатывать все конфиги.

в zfs есть возможность сравнить базовый образ + снепшот на корректность?

Насколько я понимаю в этом нет необходимости.

Ну и в плане zfs пугает, то, что надо много скриптовать... :(

Совсем немного.

#!/bin/sh

pool=«zpool242/vm»
destination=«zpool14/backup»
host=«195.x.x.x»

today=`date +«$type-%Y-%m-%d»`
#yesterday=`date -v -1d +«$type-%Y-%m-%d»`
yesterday=`date -d yesterday +"-%Y-%m-%d"`

# create today snapshot
snapshot_today=«$pool@$today»
# look for a snapshot with this name
if /sbin/zfs list -H -o name -t snapshot | sort | grep «$snapshot_today$» > /dev/null; then
echo " snapshot, $snapshot_today, already exists"
exit 1
else
echo " taking todays snapshot, $snapshot_today"
/sbin/zfs snapshot -r $snapshot_today
fi

# look for yesterday snapshot
snapshot_yesterday=«$pool@$yesterday»
if /sbin/zfs list -H -o name -t snapshot | sort | grep «$snapshot_yesterday$» > /dev/null; then
echo " yesterday snapshot, $snapshot_yesterday, exists lets proceed with backup"

/sbin/zfs send -R -i $snapshot_yesterday $snapshot_today | ssh root@$host /sbin/zfs receive -Fdu $destination
#/sbin/zfs send -R -i $snapshot_yesterday $snapshot_today | /sbin/zfs receive -Fdu $destination

echo " backup complete destroying yesterday snapshot"
#/sbin/zfs destroy -r $snapshot_yesterday
exit 0
else
echo " missing yesterday snapshot aborting, $snapshot_yesterday"
exit 1
fi

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

Можно удалять любые снапшоты, ничего мержить не нужно.

В описанном способе с zfs - не понятно, куда девать дальше потом эти снепшоты. По сети сливать куда то? Каждый день по 100 гб? А там чего с ними? Тоже надо снепшоты, вдруг во время слива повредится что-то...

в данном примере описано как используя zvol и его полный снапшот записать бекап vm в файл, из которого vm можно восстановить или в другой пул zfs, или в пул на другом сервере.

куда девать дальше потом эти снепшоты.

1. Используя полный снапшот можно создать бекап vm сохранив его в виде файла локально или залив на сетевое хранилище.

2. Снапшот можно отправить по сети в пул zfs на резервный сервер

Каждый день по 100 гб?

1. У zfs помимо полных снапшотов есть и инкрементальные.

2. У zfs есть сжатие оно применимо как к ФС так и к zvol, благодаря чему виртуалка имеющая внутри себя данных например на 20Гб по факту на zvol может занимать всего 3 Гб.

Выглядит просто потрясающе!

Может опишешь, как ты поднимаешься на другой ноде в случае чего? К примеру, тебе надо поднять VM, на трое суток назад на другом узле, и чтобы она не законфликтовала ip адресами с продуктивной VM на основном узле. :)

Можно удалять любые снапшоты, ничего мержить не нужно.

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

Да и zfs прям ну что-то сыкатно пользовать на linux... Блин. А так, очень конечно круто выглядит!

К примеру, тебе надо поднять VM, на трое суток назад на другом узле, и чтобы она не законфликтовала ip адресами с продуктивной VM на основном узле. :)

если используется бекап на основе полного снапшота:

1. создаем временную ФС(zfs)

2. восстанавливаем vm в эту ФС из бекапа.

3. делаем копию конфига для данной vm

4. правим конфиг vm указывая новый путь к диску vm, также меняем настройки сети - ставим новый мас и сажаем на другой мост не связанный с основной сеткой

5. запускаем vm меняем ей ip и стопорим

6. сажаем на общий мост и снова запускаем.

А если навернётся основной хост, и надо будет поднять сразу 10ть вирт. машин из резервной копии? ...

Или ты будешь в отпуске/уволишься? Кто в этом во всём будет разбираться? :)

А если навернётся основной хост, и надо будет поднять сразу 10ть вирт. машин из резервной копии? ...

а зачем из копии? vm на резервном хосте уже стоят и ждут отмашки для взлета. бекапы(копии) в другом месте хранятся для тройной надежности.

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

или состряпать свою следилку или заюзать heartbeat, для перезапуска vm

Может опишешь, как ты поднимаешься на другой ноде в случае чего? К примеру, тебе надо поднять VM, на трое суток назад на другом узле, и чтобы она не законфликтовала ip адресами с продуктивной VM на основном узле.

Делаю бэкап всех XML из /etc/libvirt/qemu. Если надо поднять на другом узле:
1. Кидаю нужную xml в /etc/libvirt/qemu, затем service libvirt-bin reload.
2. Так как все снапшоты readonly, то делаю клон снапшота, примерно так zfs clone zpool/vm1/vm@2014-10-20 zpool/vm2. Клон создается мгновенно, он rw, можно запускать ВМ.
3. Чтобы не конфликтовали IP достаточно в XML изменить тип сети с моста на nat.

Насколько я понял, оно таки само мержит при удалении просто, и удаление занимает время в связи с этим.

Не знаю мержит оно или нет, но удаление любого снапшота происходит мгновенно.

P.S. Если нужно автоматом поднять ВМ на узлах с бэкапами, в случае падения боевого хоста, то это довольно просто автоматизируется.

в качестве доп. информации - http://pve.proxmox.com/wiki/ZFS

Я видел это, но прекратил читать сразу после: tbd. (running zfs on Proxmox VE is not officially supported) и после :zfs mounting workaround :(

При выполнении внутреннего снепшота - есть. Внешнего нет.

внутренние снепшоты это зло. не надо их трогать

Так плоского имиджа нету. Будет же один base имидж, и как минимум один один файл снепшота. - До тех пор, пока не выполним blockpull. А если надо несколько снепшотов - то будет один + файлы снепшотов. Ни о какой плоскости речи нет. :( Или я реально что-то не так понял?

алгоритм такой:

работаем с плоским имиджем. > делаем внешний снепшот живьем > бекапим base > blockpull > снова плоский имидж, работаем дальше.

они пишут что это работает поверх ФС, быстрее чем LVM и позволяет откаты прямо на месте. наверное принцип вроде как у git, только для живой ФС, а не только для файлов с кодом. нет времени играться, но звучит заманчиво

у qcow с большими цепочками снапшотов было не все так радужно

у любого cow с большими цепочками не радужно, это проблема алгоритма а не имплементации

чтобы она не законфликтовала ip адресами с продуктивной VM на основном узле

это уже не вопрос снепшотов, а управления сетью VM. если синхронизировать domxml то как минимум mac реплицируется и будет конфликтовать.

самое простое - держать запасную и основную VM с разными настройками сети, и двумя дисками - один под ОС который у каждой VM свой, a второй с инфой которая реплицируется и откатывается

работаем с плоским имиджем. > делаем внешний снепшот живьем > бекапим base > blockpull > снова плоский имидж, работаем дальше.

Blockpull - это офлайн операция. :(

бекапим base

У меня 500G+ имидж планируется. Больно жирно каждый раз бекапить base.

внутренние снепшоты это зло. не надо их трогать

Частично согласен, ибо читал, что qcow2 уделяется меньше внимания чем raw. :(

самое простое - держать запасную и основную VM с разными настройками сети, и двумя дисками - один под ОС который у каждой VM свой, a второй с инфой которая реплицируется и откатывается

Пока мне самым вкусным в этом плане видится, держать все машины за NAT (default network который). Но там возникает ряд проблем ещё, с libvirt. Разрабы говорят, что да - через жЁпу. Пока думаю...

Blockpull - это офлайн операция. :(

но я же показал что оно работает в онлайне

У меня 500G+ имидж планируется. Больно жирно каждый раз бекапить base.

на дедуплицированный сторедж - мелочь

Частично согласен, ибо читал, что qcow2 уделяется меньше внимания чем raw. :(

чего? raw вообще не нужно внимание. qcow2 всегда использовался с внешними снепшотами, но с ним играются слишком много хакеров, поэтому и появляются лишние фичеры.

Пока мне самым вкусным в этом плане видится, держать все машины за NAT (default network который). Но там возникает ряд проблем ещё, с libvirt. Разрабы говорят, что да - через жЁпу. Пока думаю...

не, NAT это не особо удобно, в нормальной сети. так что надо или реализовать какой нибудь SBA или держать запасную VM, или городить дополнительный vlan для развлечений с восстановлением и откатами