Недавно мы рассматривали некоторые аспекты резервного копирования на томах VVols в среде VMware vSphere. Одна из важных составляющих этого процесса - снапшоты (snapshots). Мы упоминали, что ввиду архитектуры VVols в плане снапшотов, снимки на уровне дисковых массивов на томах VVols работают быстрее при откате к снапшоту и консолидации (удалении всех снапшотов диска VMDK).
Сегодня мы попробуем разобраться, как это работает, и почему снапшоты в инфраструктуре VVols - это уже не так плохо, как раньше.
Снапшоты на томах VMFS
Сначала посмотрим на традиционную архитектуру снапшотов виртуальных машин на томах VMFS. Когда для машины делается снапшот, создается VMDK-файл, представляющий собой redo log (назовем его лог наката). В этот момент основной диск ВМ переводится в режим только для чтения (read only), а все новые операции записи (writes) идут в новый VMDK (дельта диск), который становится активным диском в плане новых операций чтения-записи для новых блоков, а старые блоки читаются из старого базового VMDK.
Если же мы хотим удалить один из снапшотов, мы должны склеить (накатить - redo) все сделанные операции записи новых блоков из логов наката к предыдущим точкам во времени. Например, если у вас есть базовая точка PIT1 (основной VMDK-диск), а также снапшоты PIT2 и PIT3, то чтобы удалить, например, снапшот PIT2 вам надо повторить (накатить) все операции его redo log на основном VMKD (PIT1), чтобы получить стабильную итоговую цепочку PIT1-PIT3 (без PIT2). Это довольно трудозатратная операция.
Если вы хотите откатиться к одному из снапшотов (revert), например, к исходному состоянию PIT1, то работает это очень просто - следующие снапшоты в цепочке просто отбрасываются (удаляются их VMDK):
Если же вы хотите удалить все снапшоты (консолидировать диск ВМ - операция consolidate), то процедура будет очень накладной. Об этой процедуре мы детально писали вот тут. Сначала PIT2 склеивается с PIT3, а потом уже получившийся диск склеивается с PIT1.
Таким образом, операция консолидации снапшота, который обязательно создается при резервном копировании, может занять длительное время.
Снапшоты для томов VVols
Давайте теперь посмотрим, как снапшоты работают в среде VVols. Здесь базовый диск находится в режиме чтения-записи всегда и всегда хранит в себе самое актуальное состояние. При создании снапшота диска VMDK происходит создание файла VMDK, который хранит в себе отличия (трекаются изменившиеся блоки), происходившие с какого-то момента времени (можно сказать, что это undo log). При этом основной контекст чтения-записи остается на основном VMDK.
В такой схеме операция revert будет происходит довольно долго по сравнению с таковой на VMFS - надо будет откатить изменения PIT3 в базовом диске, а потом изменения PIT2 (если мы идем к состоянию PIT1), но надо помнить, что откатываться к снапшоту приходиться не так уж и часто.
А вот операция консолидации (удаление всех снапшотов) - очень частая при резервном копировании. И вот тут для такой архитектуры работает это все моментально - мы просто откидываем ненужные объекты undo log, оставляя только базовый диск, который содержит в себе самое актуальное состояние на данный момент:
При необходимости вернуться к какому-то из снапшотов в среде VVols надо будет в базовом диске откатить все те изменения блоков (undo), которые зафиксированы в VMDK-диске снапшота, отслеживаемые с нужного момента времени (например, PIT1):
RSS
