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