Что такое snapshot vmware
Функционал снапшотов виртуальных машин в программе VMware Workstation
В числе возможностей функционального гипервизора для Windows, программы VMware Workstation – создание снапшотов виртуальных машин. Это функционал сохранения состояний машин и возможность отката к таким состояниям. Функционал снапшотов всерьёз облегчает работу с гостевыми операционными системами (ОС) : он предлагает сохранение их эталонного рабочего состояния, к которому мы можем в любой момент вернуться, если что-то пойдёт не так.
И он, соответственно, позволяет нам легко соглашаться на самые смелые эксперименты. Нам не нужно использовать ни штатные механизмы, ни профильное стороннее ПО внутри гостевых ОС для создания системного бэкапа. Простой и эффективный страховочный механизм нам может предложить сам гипервизор. Как устроен функционал снапшотов виртуальных машин в VMware Workstation?
Что такое снапшоты VMware Workstation
Как создать снапшот
Создать снапшот виртуальной машины в программе VMware Workstation можно через меню.
А можно с помощью кнопок на панели инструментов. Для создания снимка служит кнопка в виде часов с плюсиком. В форме создания снапшота можем ввести описание, поясняющее состояние машины, оно пригодится, если снапшотов будет много. Либо же можем в самих именах снапшотов делать какие-то идентифицирующие указки, называя их по-своему, а не так, как по умолчанию «Снимок 1, 2, 3 и т.д.».
Если мы снапшот создали при работающей машине, можем с ней тотчас же продолжить работу, сохранение будет происходить в фоне. Прогресс создания снапшота будет виден на панели программы внизу.
Как откатиться к снапшоту
Откатиться к снапшоту можно с помощью кнопки в виде часов и стрелочки на панели инструментов программы. Но эта кнопка позволяет осуществить откат только к последнему снимку.
Если нужно вернуться к предшествующему или ещё ранее созданному снапшоту, можем сделать это в меню VMware Workstation.
Откат к снапшоту также можем осуществить из диспетчера снимков состояния, он запускается кнопкой в виде часов и гаечного ключа на панели инструментов программы. И здесь, в диспетчере можем в принципе лицезреть на карте расклад созданных снимков, их ответвления от узловых снимков. Для отката выбираем на карте снапшот и жмём кнопку «Переход». Или просто делаем на снимке двойной клик.
Удаление снапшотов
Ненужные снапшоты удаляются в диспетчере. Кликаем снимок и жмём кнопку «Удалить».
Функция автозащиты
Создание снапшотов можно автоматизировать, для этого у VMware Workstation есть функция автозащиты. Это автоматическое создание снимков виртуальной машины в её рабочем состоянии. В диспетчере жмём кнопку «Автозащита».
И оказываемся в разделе параметров виртуальной машины, где эта функция включается и настраивается. Для включения ставим галочку «Включить автоматическую защиту». И настраиваем – выбираем интервал автоматического создания снимков и их максимальное количество.
Интервал можно выбрать получасовой, почасовой и ежедневно. Поскольку автоматические снапшоты создаются только в процессе работы машин, то, соответственно, и в плане интервалов имеется в виду, что это отрезки времени активности машин. При достижении указанного максимального количества снимков старые удаляются, но это происходит не линейно – старый удалился, а новый создался, а выборочно, с сохранением возможности отката к более ранним снимкам. Например, если выбран получасовой интервал, то будет храниться как минимум один снимок, созданный час назад и день назад. А при ежедневном интервале будет храниться снимок, созданный неделю назад и месяц назад.
Клоны виртуальных машин из снапшотов
Помимо возможности создания веток снапшотов с различными состояниями виртуальных машин, VMware Workstation позволяет на базе снимков создавать клоны машин. Но только на базе снапшотов, созданных при выключенном состоянии машины. Такие клоны могут быть полными, т.е. полностью самостоятельными машинами, со своими файлами конфигурации и виртуальным жёстким диском. А могут быть связанными клонами, т.е. несамостоятельными, зависимыми от оригинальной машины в части основы – виртуального диска с данными. Связанные клоны будут базироваться на виртуальном диске оригинальной машины, лишнее место им потребуется только для хранения файлов конфигурации и данных, отличных от базового виртуального диска. Связанный клон можно настраивать как отдельную машину, проводить эксперименты с гостевой ОС, но такой клон, соответственно, не будет работоспособен при удалении оригинальной машины.
Для создания клона машины из снапшота в диспетчере жмём «Клонировать».
Запускаем мастер клонирования виртуальной машины.
Выбираем снимок для клона.
Выбираем тип клонирования – полный или связанный. В нашем случае выбран последний.
Можем сменить имя машины и путь её хранения на диске компьютера.
И всё: связанный клон создаётся за считанные секунды.
Весит такой клон немногим больше 20 Мб.
Удаляется связанный клон так, как и обычная машина.
Полное удаление машин, которое включает удаление их файлов на диске, предусмотрено в меню программы.
Что такое snapshot vmware
Для создания снапшота по расписанию нам нужно в vCenter перейти на вкладку Home. Тут нас будет интересовать пункт Sheduled Tasks
Как создать snapshot виртуальной машины по расписанию в VMware vCenter 5.5-01
Создаем новую задачу, жмем new.
Как создать snapshot виртуальной машины по расписанию в VMware vCenter 5.5-02
Выбираем Create a snapshot of a virtual machine
Как создать snapshot виртуальной машины по расписанию в VMware vCenter 5.5-03
далее нужно указать какая виртуальная машина будет создавать snapshot по расписанию
Как создать snapshot виртуальной машины по расписанию в VMware vCenter 5.5-04
Задаем имя в описании снапшота
Как создать snapshot виртуальной машины по расписанию в VMware vCenter 5.5-05
Теперь зададим имя самого задания и частоту выполнения
Как создать snapshot виртуальной машины по расписанию в VMware vCenter 5.5-06
Я буду в своем примере делать каждый день в 1-35
Как создать snapshot виртуальной машины по расписанию в VMware vCenter 5.5-07
При желании можно поставить уведомление по почте о выполнении задания, для этого поставьте галку Send email to the following adress when the task is complete
Как создать snapshot виртуальной машины по расписанию в VMware vCenter 5.5-08
Как создать snapshot виртуальной машины по расписанию в VMware vCenter 5.5-09
Видим в назначенное время стартовало наше задание.
Как создать snapshot виртуальной машины по расписанию в VMware vCenter 5.5-10
Проверяем в snapsot manager нашей виртуальной машине, и видим, что снапшот создан.
Как создать snapshot виртуальной машины по расписанию в VMware vCenter 5.5-11
Вот так вот просто создать snapshot виртуальной машины по расписанию в VMware vCenter 5.5.
Как правильно работать со снапшотами виртуальных машин
«Snapshot» в переводе с английского означает «выстрел» или «мгновенный фотоснимок». Снапшот — это своего рода фотоснимок виртуальной машины (ВМ), слепок её конкретного состояния. Виртуальная машина может использоваться для различного рода экспериментов, или в нее могут вноситься изменения, которые затем нужно быстро откатить назад. Именно для того, чтобы каждый раз не мучиться восстановлением предыдущего состояния ВМ и существуют снапшоты, возвращающие ВМ к исходному состоянию. Снапшоты — не такая уж простая операция, во всяком случае, делаться она должна по правилам, о которых мы сегодня и расскажем.
Что такое снапшот?
Снапшот сохраняет состояние виртуальной машины и данные по ней в определенный момент времени.
Лучшие практики
Чтобы получить максимальную пользу от снапшотов, необходимо следовать нескольким правилам, которые позволят использовать снапшоты по максимуму и предотратить возникновение проблем.
Используйте отдельные инструменты для резервного копирования. Делайте снапшот, вносите изменения в виртуальную машину и удаляйте снапшот, как только будет подтверждено ее корректное состояние.
2) Снапшоты образуют цепочки или деревья.
VMware советует делать в одной цепочке только 2–3 снапшота:
a. Большее число снапшотов или снапшоты большого размера могут вызвать уменьшение производительности виртуальной машины и хоста.
b. Создание большого файла снапшота может заполнить доступное пространство хранилища, отключив таким обазом все виртуальные машины до тех пор, пока не будут внесены коррективы. Другими словами, снапшот на каждом отдельно взятом хосте может оказывать влияние на все виртуальные машины, использующее данное устройство хранения.
c. Файл снапшота может оказаться поврежденным.
d. Размер диска снапшотов оказывает непосредственное влияние на продолжительность времени, которое потребуется на удаление снапшота, относящегося к данной виртуальной машине.
Деревья снапшотов на Windows и Linux
3) Не делайте снапшотов памяти виртуальной машины:
a. Продолжительность времени, которое занимает у ESX хоста запись памяти на диск, коррелирует с объемом памяти, на использование которого настроена виртуальная машина. Это может увеличить время на завершение операции, что в свою очередь может замедлить производительность виртуальной машины.
b. Если нет острой потребности в возвращении виртуальной машины к конкретному состоянию памяти, отключите опцию «Память». Состояние памяти редко может потребоваться.
4) Используйте более одного снапшота для промежутка времени в 24–72 часа.
Хотя 2–3 дня — это рекомендуемый период, иногда снапшот хранится 5 дней, а затем автоматически удаляется:
a. Это предотвращает снапшоты от разрастания до такого большого размера, который может вызвать проблемы при удалении его с диска виртуальной машины.
b. Сделайте снапшот и удалите его сразу после того, как внесете необходимые коррективы.
c. Будьте аккуратны со снапшотами высокозагруженных виртуальных машин, таких как серверы баз данных и почтовые серверы. Такие снапшоты могут быстро увеличиваться в размерах, заполняя пространство хранилища. Удаляйте снапшоты с виртуальных машин, как только они перестают быть необходимыми.
5) Виртуальные машины с несколькими дисками:
a. Снапшот может повлиять на дочерний или резервный диск: чем больше операций совершается с диском, тем больше он становится.
b. Требования к свободному пространству дочернего диска дополняют требования к родительскому диску, от которого он зависит.
c. Дочерний диск может вырасти до такого размера, что заполнит все пространство для хранения.
d. Существует правило «Без снапшотов» для дополнительных дисков размером 100 Гб и больше, поскольку есть вероятность заполнения хранилища данных и прекращения работы всех виртуальных машин, которые используют одно и то же хранилище.
e. Дополнительные диски более 100 Гб размером считаются независимыми — это предотвращает переход влияние снапшота с родительского диска на дочерний.
Вместо заключения
Снапшот позволяет запечатлеть состояние виртуальной машины в конкретный момент времени. Снапшоты полезны в том случае, если требуется вернуться к одному состоянию виртуальной машин без необходимости создавать новые.
Снапшот несет следующую информацию:
VMware: «To quiesce or not to quiesce?», бэкапим вирутальные машины правильно
Про моментальные снимки (снапшоты) виртуальных машин было написано великое множество статей, где чрезмерно подробно описана теоретическая часть сего действа. В своей статье я сфокусируюсь на практической стороне вопроса и исключительно на платформе VMware vSphere.
Так зачем нужны «quiesced» * снапшоты, с чем их едят, и какие типичные проблемы с ними возникают? Взгляд на снапшоты будет представлен в первую очередь с точки зрения резервного копирования, но постараюсь в какой-то мере раскрыть и другие аспекты использования.
* Если кто готов подсказать подходящий русскоязычный термин — милости прошу в комментарии, будет хороший вариант — заменю в тексте англицизм.
Использование снапшотов для резервного копирования
Собственно, альтернативный вариант и есть наша вторая опция — quiescing. Она представляет намного больший интерес и суть её в том, чтобы подготовить гостевую операционную систему (файловую систему в первую очередь) к снятию бэкапа.
Что же представляет из себя quiescing?
«Это процесс приведения данных на виртуальном диске в состояние „подходящее“ для резервного копирования. Данный процесс может включать в себя операции по „сливу грязных буферов“ (flushing dirty buffers) из памяти операционной системы на диск или другие высокоуровневые операции специфичные для конкретных приложений.»
Из данного описания о том, что с виртуальномй машиной происходит на самом деле понятнее не стало. Давайте разбираться сами.
Сначала VMware Tools через свой сервис VMware Snapshot Provider инициируют создание VSS снапшота внутри гостевой ОС. Далее все зарегистрированные VSS writers (посмотреть их можно командой «vssadmin list writers«) в гостевой ОС получают запрос и подготавливают соответствующие приложения к бэкапу (происходит запись всех транзакций из памяти на диск). Когда все VSS writers заканчивают работу, они рапортуют об этом сервису VMware Tools (опять же, через сервис VMware Snapshot Provider), который, в свою очередь, говорит VMware о том, что снапшот можно снять.
Таким образом все приложения резервного копирования для VMware vSphere используют следующие комбинации при отдании команды на создание снапшота VMware (заметьте, что процесс непосредственно создания снапшота целиком и полностью контроллируется самой VMware):
Quiesced = ON, Memory = OFF
Quiesced = OFF, Memory = OFF
Вторую комбинацию мы рассматривать в данной статье не будем и сфокусируемся на процессе quiescing.
Зачем нужен quiescing?
Самый наглядный пример — это проблема USN rollback при восстановлении домен контроллера из бэкапа. Возникает она, если виртуализованный домен контроллер был забэкаплен без использования VSS (то есть без опции quiescing или других средств, которые обеспечивают запись транзакций на диск).
Никаких дополнительных действий и танцев с бубном производить не потребуется, если восстанавливать бэкап, сделанный с опцией quiescing. InvocationID будет корректно сброшен и вы увидите следующую запись в Event Log на загруженном после восстановления домен контроллере:
Event ID 1109: Active Directory has been restored from backup media, or has been configured to host an application partition. The invocationID attribute for this domain controller has been changed.
Поодобное корректное поведение можно наблюдать при использовании Acronis vmProtect 9. Собственно, его мы специально тестировали в рамках резервного копирования и восстановления виртуальных машин с домен контроллером внутри.
USN rollback, очевидно, не единственная возможная проблема при использовании «сырых» снапшотов и другие приложения (например Exchange/SQL — приложения в явном виде поддерживающие VSS) могут быть подвержены сбоям при восстановлении из таких снапшотов.
Как проверить, что снапшот создается корректно с использованием VSS?
Существует несколько способов определения корректности создания консистентного (до уровня приложения) снапшота:
Самый простой способ: войти в гостевую операционную систему и проверить «Просмотр Событий» (надо же было так перевести бедный Event Viewer). После создания снапшота с опциями quiesced=ON, snapshot memory=OFF (см скриншот в начале статьи) должны присутствовать события от соответствующих VSS writers в логах приложений:
Прим.: Ошибка от VSS с Event ID 12289, которую можно заметить на скриншоте, в реальности не является проблемой. Она относится к 3.5» диску и, чтобы от нее избавиться, достаточно убрать флопик из конфигурации виртуальной машины:
Способ посложнее: использовать компонент Datastore Browser из vSphere клиента: в папке виртуальной машины на датасторе после создания quiesced снапшота должен появиться файл***vss_manifests*.zip.
Внутри файла содержится backup.xml с описанием всех найденных VSS writers в гостевой системе + метаданные по каждому райтеру в writerX.xml.
ВАЖНО: если в vss_manifests.zip содержится только backup.xml — это как правило означает, что снапшот по факту был сделан без использования VSS. Таким образом мы плавно подходим к самому интересному: исследованию проблем со снапшотами. Ниже я перечислю основные причины неработающих снапшотов. Стоит отметить, что основную опасность представляют не неработающие снапшоты (их легко детектировать), а именно те, которые VMware рапортует как успешные, в то время как данные снапшоты не являются таковыми.
Требования к окружению
Если с полезностью опции quiescing все более менее понятно, то при практическом использовании часто возникают проблемы, как правило связанные с некорректностью изначальной конфигурации окружения. Официальное описание части требований находится здесь, и я попытаюсь раскрыть их более наглядно, чтобы было понятно куда смотреть, когда вы столкнетесь с проблемами на практике:
Во-первых, убедитесь, что ваша комбинация vSphere + гостевой ОСи поддерживается для снапшотинга с консистентностью на уровне приложений по данной табличке (взята отсюда).
Данные актуальны для vSphere 5.0 и выше. Как вы можете заметить, для самых популярных на данный момент ОС (Windows 2008 и выше) стоят звездочки — в них то и зарыта главная собака, раскопками которой мы сейчас займемся.
Во-вторых, для того, чтобы quiescing реально работал, необходимо убедиться, что VSS компоненты VMware Tools действительно установлены (и естественно VMware Tools должны быть самой актуальной версии).
На старых версиях vSphere (3.5 и ранее) для quiescing использовался в том числе Legato Sync Driver, который гарантировал консистентность на уровне файловой системы, но не на уровне приложений (для чего как раз и нужны VSS компоненты). В настоящее время этот драйвер практически не используется и повсеместно заменен на VMware Snapshot Provider. Корректность установки можно проверить в гостевой операционной системе (на виртуальной машине) по наличию сервиса VMware Snapshot Provider + соответствующего COM+ компонента.
Какие могут быть косяки на данном этапе?
Если сервис VMware Snapshot Provider отключен, либо совсем не установлен, то VMware при снятии снапшота с опциями quiescing = ON, snapshot memory = OFF отрапортует, что он успешен, однако по факту снапшот будет произведен без использования VSS внутри системы, то есть посредством Legato Sync драйвера.
Заметьте, что в случае Windows 2008 и выше поведение отличается — там подобных событий в логе не наблюдается, а просто сервис Volume Shadow Copy переходит в запущенное, а затем в остановленное состояние.
Эта настройка имеет смысл только для гостевых систем под управлением Windows 2008 и выше (для Windows 2003 настройка игнорируется). Дополнительной особенностью является тот факт, что данный параметр автоматически прописывается при создании новой виртуальной машины только начиная с vSphere 4.1. Другими словами если виртуальная машина была смигрирована с более старой версии vSphere, то настройки может и не быть.
При отсутствии параметра, или же если он выставлен в «false», поведение при создании снапшота будет аналогично предыдущему случаю: снапшот создастся успешно, но по факту VSS будет не задействован и в результате мы можем получить неконсистентный бэкап. Второй симптом отключенного параметра — это пустой backup.xml (без описания VSS райтеров) в vss_manifests.zip.
В-четвёртых, проверьте наличие динамических дисков внутри гостевой машины. Если внутри гостевой системы будет присутствовать хоть один динамический диск — не важно системный он или нет, то VSS задействован не будет. Снапшот будет создаваться успешно, но vss_manifests.zip будет пустым, как и логи событий внутри гостевой ОСи. Это правило действует для гостевых ОСей Windows 2008 и выше.
То же самое касается IDE дисков — их не должно быть в конфигурации виртуальной машины (но наличие IDE CD-ROM устройств допустимо и на снапшоты не влияет). При этом надо учитывать, что количество свободных SCSI слотов на одном SCSI контроллере должно быть равно количеству дисков. Например: если на SCSI1 уже присутствуют 8 SCSI дисков, то слотов не хватит.
Данная проблема была решена банальной перезагрузкой виртуальной машины, и хотя такой метод помогает очень часто, бывают запущенные случаи, когда VSS внутри сломан чуть менее, чем полностью. В этих случаях самый простой способ выяснить, действительно ли Microsoft виноват — это запустить Windows Backup и сделать резервную копию системного состояния (Backup of System State, если кто привык к английским терминам). Windows Backup (или NTBackup) работает — то проблема на стороне VMware, не работает — косяк Microsoft.
У VMware на эту тему есть несколько официальных статей: например тут и тут. Но есть интересная особенность — для упрощения себе жизни (возможно есть и какие-нибудь другие причины) во второй статье VMware в явном виде рекомендует выставить disk.EnableUUID в «false», что означает отказ от использования VSS при создании quiesced снапшота («quiesced-то не настоящий!»). В общем случае такой метод является не решением, а только временным обходным путем, так как последствия подобного подхода могут проявить себя при восстановлении, то есть именно тогда, когда консистентность приложений является ключевой (вспомнить хотя бы тот же USN rollback).
Подводим итоги
По моему опыту, самыми частыми проблемами при создании снапшотов (их неконсистентность) являются пункты 2, 3 и 5, в то время как IDE или динамические диски встречаются гораздо реже.
Конечно же, не исключены и совершенно мистические случаи: например снапшот не создавался (VMware рапортовала невнятную ошибку) по причине того, что iSCSI LUN (датастор), на котором располагалась проблемная виртуальная машина, был подключен физически через 2 сетевые карты в режиме teaming и при этом одна работала на 100MBit, а вторая на 1Gbit.
Тему quiesced снапшотов можно копать чуть ли не вечность — чего стоит хотя бы факт того, что Windows 2008 при создании quiesced снапшота создает не одну, а две дельты на датасторе и по факту пишет в уже созданный снапшот (это, кстати, одна из корневых причин звездочек напротив данных ОСей в табличке выше); или наличие возможности отключать определенные VSS райтеры через конфигурацию vmbackup.conf на гостевой системе. Мир чудесен и удивителен, но граблей хватит на всех. Если будет желание — я с радостью напишу что-нибудь ещё на эту тему. Как обычно, комментарии привествуются, уточнения — тоже, об ошибках и опечатках — в личку, на вопросы постараюсь ответить asap.
Не забывайте подписываться на наш Хаб, у нас запланировано огромное количество статей на тему бэкапа и восстановления данных, быть может, именно наши статьи помогут вам решить определённые проблемы (а лучше — избежать их). Спасибо за внимание. 🙂