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