(Обратите внимание, что хотя этот вопрос касается конкретно Hyper-v, на самом деле меня интересует обобщенный ответ по снимку виртуальной машины, если только конкретный ответ по Hyper-v не применим к такому общему объяснению.)
Я работаю в крупной компании с инфраструктурой VM приличного размера (несколько тысяч VM). Один из моих инженеров по серверам говорит мне, что они не позволяют сохранять снимки VM слишком долго — они разрешают делать снимок в качестве запасного варианта перед внесением существенных изменений в VM, но вскоре после этого их нужно удалить (примерно через несколько дней, как только мы убедимся, что наши изменения ничего не сломали).
Меня устраивает эта процедура — я не ожидаю, что снимки будут служить прокси для реальных резервных копий и т. д. И я могу уважать их желание экономить место в среде. С чем я не согласен, так это с его рассуждениями. Он говорит, что причина, по которой их нужно удалять впоследствии, заключается в том, что «снимки могут неограниченно разрастаться, каждый раз, когда вы записываете на жесткий диск, он записывает дополнительные данные в снимок, без ограничений. Это отличается от того, когда вы предоставляете исходный виртуальный жесткий диск, где вы можете указать максимальный размер. Вы не можете указать максимальный размер для снимка».
Насколько я понимаю, снимки образов — это ДЕЛЬТА от родительского образа диска. Например, если у меня есть блок на исходном образе, который выглядит так:
0101 0101 0101
... и затем я переписываю среднюю часть следующим образом:
0101 1111 0101
... то снимок сохраняет только РАЗНИЦУ между ними (плюс некоторые накладные расходы на структуру данных, которые, я уверен, добавляют сложности, но незначительны с точки зрения хранения). Кроме того, я понимаю, что если бы я пошелпереписатьэти блоки возвращаются в исходное состояние, дельта затем отбрасывает этот блок (чтобы будущие чтения для этого блока считывались до исходного изображения).
(Я не очень хорошо знаю, КАК снимок хранит разницу — я уверен, что для поддержания всей этой организации необходимы очень сложные структуры. Меня интересует только принцип, согласно которому снимок ХРАНИТ разницу, а не «текущую историю» изменений.)
Он говорит, что моментальные снимки так не работают. Он говорит, что если у меня есть блок данных, я изменяю его, а затем возвращаю его обратно, то КАЖДЫЙ раз, когда я это делаю, моментальный снимок будет расти, в конечном итоге занимая много места на диске.
Я понимал, что снимок никогда не может превысить размер исходного образа (например, если вы перевернете буквально каждый бит на HDD, дельта сохранит это), возможно, с некоторым постоянным размером накладных расходов. Он, похоже, думает, что это не так, что снимок виртуальной машины будет расти неограниченно по мере того, как все больше и больше записей будет сделано на виртуальный HDD.
Может быть, я что-то не понимаю в работе снимков виртуальных машин?
решение1
Ваши инженеры следуют хорошей практике, но по неправильным причинам. Вы правы в том, что VHDX (или любая другая используемая технология виртуального диска) будет:
- Повторно используйте написанные блоки при переписывании, а не пишите все заново
- Иметь жесткий предел размера, равный максимальному настроенному размеру для родительского виртуального диска. Причина, по которой вы не можете указать максимальный размер для снимка, заключается в том, что родительский VHDX уже указал его.
Однако мне неизвестен какой-либо механизм, который отбрасывал бы ранее записанные дельты, если бы блок был возвращен в исходное состояние. Накладные расходы на выполнение алгоритма разности для исходных и дельта-блоков по сравнению с сохранением простой записи записей блоков были бы существенными даже в относительно небольшом масштабе.
Однако если только виртуальная машина не перегружена дисками, вы вряд ли увидите, как ее снимок сильно разрастется.
Виртуальная машина с одним снимком также не испытывает существенной потери производительности, хотя я нигде не вижу упоминаний об этом.
У моментальных снимков есть три вполне реальные проблемы:
- Проблемы с окружающей средой могут привести к появлению бесхозных дисков AVHDX
- Каждую минуту существования снимка он перемещается по спектру от «ценного» к «обязательному».
- Данные не дублируются.
Кроме того, даже если снимок не может расти по-настоящему неограниченно сам по себе, представьте себе среду без контроля над снимками. Один снимок теоретически может вырасти до размера, вдвое превышающего выделенный размер его родителя. Я считаю, что Microsoft установила жесткий предел в 50 снимков на ВМ, но только как своего рода отказоустойчивость «ну ладно, теперь вы просто глупите», а не потому, что этого требует технология. Таким образом, теоретически верхняя граница для ВМ составляет 51x выделенный размер. Хотя это вряд ли когда-либо произойдет, вы можете видеть, как даже наличие нескольких ВМ с несколькими снимками может доставить головную боль администраторам вашего хранилища. Это, безусловно, говорит в пользу установления разумного ограничения использования снимков.
Экологические проблемы для снимков
Многое может подойти в качестве корневой причины проблем в этой категории. Все они сводятся к одной фундаментальной проблеме: если родительский VHDX изменен влюбойВ противном случае AVHDX полностью недействителен и совершенно бесполезен. Если владеющая ВМ включена, то такие изменения должны быть непозволительно сложными. Но если владеющая ВМ выключена, то родительский VHDX — это просто файл. Hyper-V или другие ваши системы не узнают, что что-то не так, пока вы не попытаетесь получить доступ к дочернему AVHDX.
Чем дольше существует снимок, тем выше вероятность, что что-то пойдет не так, особенно в среде с несколькими администраторами. Если у виртуальной машины есть несколько снимков, то проблемы потенциально усугубляются.
Эта проблема характерна не только для снимков; такие проблемы могут возникнуть в любой системе разностного копирования виртуальных дисков.
Снимки обесцениваются с возрастом
Это действительно основная причина не хранить снимки долго. Как вы правильно предположили, механизм дифференциации ненетвести историческую запись изменений; сохраняется только самое последнее изменение блока. Таким образом, у вас есть только виртуальная машина, существующая сейчас в форме после снимка, и VM, существовавшая на момент создания снимка. Вы можете либо вернуться к старой версии, либо сохранить новую. Промежуточного варианта нет.
Ради аргумента (и поскольку это уже случалось), предположим, что у вас есть небольшая среда Exchange, которая полностью работает на одной виртуальной машине. Вы делаете снимок перед обновлением с Exchange 2013 до Exchange 2016. А затем оставляете его работать в течение года. Какая польза от этого снимка? Вы бы вернулись к нему? Хотите угадать, сколько времени займет это слияние, когда вы его удалите?
Снимки не дублируют данные
Цель снимка — быстро вернуть виртуальную машину к моменту времени. Он делает это, напрямую изменяя состояние виртуальной машины. Он ни в коем случае не создает дубликат данных. Если AVHDX поврежден, то только родительский файл содержит действительную информацию, и любые изменения, внесенные с момента снимка, теряются. Если родительский VHDX поврежден, то оба файла бесполезны. Кроме того, я не знаю ни одного инструмента, который может залезть в AVHDX и извлечь только измененные данные. Поэтому для поддержания различных состояний в течение значимого периода времени резервное копирование — ваш лучший вариант. Он не такой быстрый и удобный в работе, как снимок, но он решает все остальные проблемы.