Snapshots виртуальных машин

Всем известно, какие преимущества дают моментальные снимки (snapshots) виртуальных машин VMware. Например, это позволяет быстро создать точку восстановления работающей машины. После этого делать любые системные изменения или устанавливать обновления прикладного программного обеспечения, и в случаи необходимости откатить изменения к последней рабочей версии системы. Технология моментальных снимков виртуальных машин очень важна для систем резервного копирования, поэтому разработчики программного обеспечения в своих решениях предлагают различные варианты применения снапшотов.

Резервное копирование с помощью снимков VMware

Использование снимков VMware — наиболее частый на сегодня метод резервного копирования виртуальной среды. Создавая снимок ВМ средствами VMware, такие поставщики, как Veeam, обрабатывают данные с диска, предназначенного только для чтения, в то время как ВМ продолжает работать и записывает данные в журналы обновлений (redo logs). Обычный порядок использования снимков ВМ в решениях для защиты данных выглядит следующим образом:

1. Остановка записи данных на диск ВМ (*.vmdk диск), перевод диска в режим чтения, создание снимка виртуальной машины
2. Создание журнала обновлений виртуального диска для записи и чтения всех новых или измененных блоков данных. Регистрация в файле метаданных журнала изменений. Это позволяет определить, какие блоки были изменены во время создания снимка ВМ. После создания журнала обновлений сервер резервного копирования может начать обработку данных на диске, предназначенном только для чтения.
3. После обработки все новые или измененные блоки из журнала обновлений копируются на исходный диск, а журнал обновлений и снимок удаляются.

Естественно, чем дольше используется снимок ВМ, тем выше количество измененных блоков и больше размер журнала обновлений. Иногда журналы обновлений могут достичь объема исходного диска ВМ, если будет изменен каждый блок данных. Когда одновременно создается несколько снимков, то может быстро возникнуть нехватка места.
Так же в результате обновлений метаданных и журнала, совершает большое количество операций ввода-вывода, следовательно, увеличивается нагрузка на хранилище.

С учетом этой нагрузки и возможной нехватки места в хранилище не рекомендуется хранить снимки ВМ долгое время. Исходя из этих соображений, разработчики программ резервного копирования начали искать другие варианты высвобождения исходных
данных ВМ, в том числе резервное копирование с помощью аппаратных снимков, которое
позволяет выполнять копировать снимки виртуальных машин прямо в хранилище.

Резервное копирование с помощью аппаратных снимков

Разработчики таких решений для резервного копирования, как Veeam Backup, Veritas NetBackup, Commvault (Simpana) учли проблемы, связанные с моментальными снимками виртуальных машин средствами гипервизора (VMware), и доработали свои решения, с целью сокращения времени существования снимка. Для этого производители включили в свои решения поддержку резервного копирования программных снэпшотов, средствами аппаратных снимков хранилищ (иногда их называют снимками SAN или LUN). Помимо преимуществ, которые дает сокращение времени использования снимка, аппаратные снимки позволяют сократить общее время резервного копирования. По завершению работы не требуется сливать большие снимки с рабочей ВМ, поэтому система резервного копирования не использует стек гипервизора, а подключается прямо к хранилищу. Резервное копирование с помощью аппаратных снимков выполняется следующим образом:

1. Создается снимок на уровне ВМ, все операции записи, как и в первом варианте, перенаправляются на журналы обновлений, а исходные диски переводятся в состояние «только чтение».
   «Хотя резервное копирование выполняется на уровне аппаратного снимка, снимок ВМ все равно необходим для обеспечения целостности приложений операционной системы».
2. Затем создается аппаратный снимок тома LUN (-а), который содержит исходные *.vmdk диски (в состоянии «только для чтение») и вновь созданный снимок средствами гипервизора (VMware).
3. После этого, как и в первом варианте, снимок созданный средствами VMware в исходном хранилище сразу же удаляется и виртуальная машина продолжает работает в обычном режиме, без нарушения производительности и уменьшения места в хранилище.
4. В свою очередь сервер резервного копирования уже делает бэкап аппаратного снимка.
5. После завершения бэкапа, аппаратный снимок, созданный на втором этапе, также удаляется.
6. Таким образом, за счет применения аппаратных снимков, время использования программных снимков гипервизора (VMware) значительно сокращается, ровно столько сколько необходимо для создания аппаратного снимка, что как правило происходит довольно быстро. После этого снимки будут удалены.

Учитывая проблемы с производительностью и нехваткой места, а также то, что для одной ВМ можно сделать до 32 снимков, важно, чтобы система резервного копирования имела возможность удалять созданные снимки. Иногда vCenter API сообщает об успешном удалении снимка, но фактически удаление было выполнено не полностью. И не важно, являлось ли это следствием ошибки API или следствием обрыва связи. Так же иногда на диске остаются потерянные или неучтенные снимки, которые не отображаются в vCenter. Поэтому важно отслеживать наличие неучтенных снимков, которые были удалены не корректно.

Чтобы решить эту задачу, такие компании, как Veeam, реализовали функцию опроса среды, которая позволяет обеспечить успешное завершение консолидации или удаления снимка. Каждый раз, когда в ходе резервного копирования происходит слияние или удаление снимка, запускается процедура «Snapshot Hunter». При обнаружении неучтенных или фантомных снимков, «Snapshot Hunter» пытаясь удалить снимок сразу по завершению резервного копирования ВМ. Если удалить снимок при первом проходе не
удалось, «Snapshot Hunter» автоматически переходит ко второму этапу, применяя технологии рекомендованные VMware. Если и после этого снимки остались, «Snapshot Hunter» уведомит пользователя о том, что необходимо принимать дополнительные меры.