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. Любая операция по удалению снэпшотов требует создания промежуточного образа, поэтому:
      • требует наличия свободного места не меньше чем размер диска, с которого удаляются снэпшоты для промежуточного образа
      • сопровождается повышенной нагрузкой на подсистему хранения при чтении из старых образов и записи в промежуточный
      • может занять значительное время, так как зачастую копируются десятки гигабайт

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

    1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 5,00 out of 5)
    Loading...

    Метки: , , ,

    Comments (1) »


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

    1. nurbek:

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

    Leave a comment

    *