oVirt — механизм работы снэпшотов

2014-06-21 22:26 | Автор: jekader | Filed under: FedoraMD, Jekader

В oVirt очень часто используется механизм снэпшотов, но его работа скрыта от глаз. В этой статье я постараюсь объяснить на простых примерах как это работает изнутри.


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

В oVirt они используются для многих целей, таких как:

• snapshots 🙂
• live storage migration
• templates
• snapshot preview

Так как в основе oVirt лежит QEMU, все эти операции в результате выполняются его силами, а именно посредством утилиты qemu-img. Рассмотрим следующий пример: создадим RAW диск и два снэпшота для него, а затем сотрём один из них.

1) создаём RAW диск:

$ qemu-img create -f raw base.img 1G
Formatting 'base.img', fmt=raw size=1073741824

Думаю пояснять не нужно, указывается формат, название и размер.

2) проверяем:

$ qemu-img info base.img
image: base.img
file format: raw
virtual size: 1.0G (1073741824 bytes)
disk size: 0

Видим что размер диска - 1 гигабайт. Если схематически обозначить его, то все блоки в нём будут иметь данные, то есть будут закрашены:

3) теперь создадим первый снэпшот:
$ qemu-img create -f qcow2 -b base.img snap1.img
Formatting 'snap2.img', fmt=qcow2 size=1073741824 backing_file='snap1.img' encryption=off cluster_size=65536 lazy_refcounts=off

Команда та-же, только появилась опция -b которая обозначает "backing file", то есть базовый диск. Размер в таком случае наследуется от базового диска и не указывается.

4) проверяем:
$ qemu-img info snap1.img
image: snap1.img
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 196K
cluster_size: 65536
backing file: base.img
Format specific information:
compat: 1.1
lazy refcounts: false

Видно, что физический размер этого диска всего 196 кб, а виртуальный - гигабайт. Если мы подключим этот диск к виртуальной машине и запишем какие-то блоки, то только эти изменения будут записаны в созданный диск. Остальные блоки будут читаться из базового диска:

Теперь у нас есть два состояния диска - текущее и "базовое". При желании можно подключить базовый диск к виртуальной машине чтобы вернуться в исходное состояние, либо использовать один базовый диск для нескольких виртуальных машин, каждая из которых будет иметь по собственному qcow диску.

5) теперь аналогичным образом создаём второй снэпшот относительно первого:
$ qemu-img create -f qcow2 -b snap1.img snap2.img
Formatting 'snap2.img', fmt=qcow2 size=1073741824 backing_file='snap1.img' encryption=off cluster_size=65536 lazy_refcounts=off

6) проверяем:
$ qemu-img info snap2.img
image: snap2.img
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 196K
cluster_size: 65536
backing file: snap1.img
Format specific information:
compat: 1.1
lazy refcounts: false

Как видим, ситуация аналогичная с предыдущим снэпшотом. Теперь все новые блоки будут писаться в новый файл, а отсутствующие читаться из предыдущего. Если секторов не будет в базовом файле, то будет произведена попытка чтения вниз по цепочке:

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

7) чтобы увеличить производительность нам нужно стереть первый снэпшот. Для этого нужно сначала слить базовый диск с первым снэпшотом:
$ qemu-img convert -f qcow2 -O raw snap1.img newbase.img

мы конвертируем qcow2 диск в raw

8 ) проверяем результат
$ qemu-img info newbase.img
image: newbase.img
file format: raw
virtual size: 1.0G (1073741824 bytes)
disk size: 0

как видим, получившийся диск - формата raw. Он представляет собой "сумму" base.img и snap1.img:

с точки зрения виртуальной машины диски snap1.img и newbase.img тождественны по содержимому (команда ведь была "convert").

9) теперь второй снэпшот нужно "привязать" к новому базовому диску:
$ qemu-img rebase -f qcow2 -b newbase.img snap2.img

командой rebase указываем новый базовый диск

10) проверяем:
$ qemu-img info snap2.img
image: snap2.img
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 196K
cluster_size: 65536
backing file: newbase.img
Format specific information:
compat: 1.1
lazy refcounts: false

всё ожидаемо - теперь snap2.img ссылается на newbase.img и все отсутствующие сектора будут читаться оттуда:

11) стираем ненужные файлы:
$ rm base.img
$ rm snap1.img

Итого:

1. Именно таким образом oVirt работает со снэпшотами.
2. В любой цепочке базовый диск может быть RAW или QCOW2, а все остальные - только QCOW2.
3. Сами диски могут храниться как файлы на диске (NFS/Local/Export storage domain) либо как Logical Volume на LVM (iSCSI/FiberChannel storage domain).
4. При порче любого файла в цепочке снэпшотов происходит разрушение диска. При обращении к данным на повреждённом снэпшоте виртуальная машина уйдёт в статус "Paused due to unknown storage error"
5. Любая операция по удалению снэпшотов требует создания промежуточного образа, поэтому:
• требует наличия свободного места не меньше чем размер диска, с которого удаляются снэпшоты для промежуточного образа
• сопровождается повышенной нагрузкой на подсистему хранения при чтении из старых образов и записи в промежуточный
• может занять значительное время, так как зачастую копируются десятки гигабайт

Буду рад вопросам и замечаниям в комментариях.

Метки: ovirt, qcow2, qemu, snapshot

Comments (1) »

1 комментарий

1. nurbek:
   �������� 9, 2014 8:20

   Очень пояснительный материал!Спасибо, Евгений, за Ваш труд!

Leave a comment

Имя

Mail (will not be published)

Сайт

Δ

CAPTCHA Code *