0,0
рейтинг
16 апреля 2010 в 13:37

Администрирование → Использование моментальных снимков (Snapshots) в Hyper-V

Моментальные снимки: сложно о простом
Наверняка многие знакомы с достаточно полезной функцией многих продуктов виртуализации – моментальными снимками, в простонародье – «снапшоты» (snapshots). Снапшот виртуальной машины – это как сохранение в игре: в случае, если где-то сильно накосячил (патч Бармина применил, например) – можно вернуться назад и повторить все заново. В этой статье я попытаюсь более-менее подробно рассказать о работе моментальных снимках и о некоторых нюансах их применения. В статье речь пойдет о Microsoft Hyper-V, но с некоторыми натяжками материал статьи применим и для других систем виртуализации (в частности — VMWare).

Прежде, чем продолжать – вспомним, из каких компонентов состоит виртуальная машина:
Файл конфигурации – основа виртуальной машины, хранит все настройки, касающиеся виртуалки. Представляет собой XML-файл, имеющий, как ни странно, расширение XML. В VirtualPC/Virtual Server этот файл имел расширение VMC.
Файл виртуального диска. Обычно в качестве жесткого диска виртуальные машины используют специальные файлы-образы, имеющие расширение VHD. Этот формат, изначально разработанный фирмой Connectix, после приобретения ее корпорацией Microsoft стал использоваться в продуктах виртуализации, и не только в них: в частности, они используются в Microsoft Software iSCSI Target, а в ОС Windows 7 и Windows Server 2008 R2 с VHD-дисками можно работать на уровне ОС, вплоть до загрузки с них самой операционки.
Дифференциальные диски – основа технологии снапшотов. При создании снапшота запись в VHD-файл прекращается, и все последующие изменения записываются в отдельный файл, имеющий расширение VHD.
Сохранение состояния (Save State) – одна из полезных функций системы виртуализации. При сохранении состояния все содержимое памяти виртуальной машины, регистров процессора и т.д. сохраняется в специальные файлы, и виртуалка переходит в состояние «Выключено». После этого можно делать все что угодно, вплоть до перезагрузки хостовой машины, а потом снова запустить виртуалку – и она будет работать, как ни в чем не бывало, ровно в том же состоянии, в каком она была до сохранения. Примерно так же работает функция Hibernate в Microsoft Windows с единственным лишь отличием – сохранение состояния происходит на уровне самой виртуальной машины, а не на уровне гостевой ОС. В VirtualPC и Virtual Server для сохранения содержимого памяти использовался файл с расширением VSV, в Hyper-V же их стало аж целых два – BIN и VSV.
Файл экспорта. Если виртуальную машину Hyper-V нужно склонировать, или же перенести на другой хост – необходимо произвести операцию экспорта, а затем импорта. При экспорте конфигурационный XML-файл преобразуется в файл с расширением EXP. В VirtualPC и Virtual Server для этого достаточно просто скопировать файлы виртуальной машины, а в Hyper-V придумали импорт/экспорт – как они сами говорят, в целях безопасности.
Различают два типа моментальных снимков: онлайновый и оффлайновый. Онлайновым называют снапшот, сделанный на виртуальной машине с запущенной гостевой ОС. Соответственно, если виртуальная машина была в состоянии «выключено» — то снапшот будет называться оффлайновым. Для пользователя нет абсолютно никаких различий между онлайновыми и оффлайновыми снапшотами. Различаются они только по составу файлов, потому что при создании снапшота на запущенной виртуалке происходит операция Save State, и данные Save State включаются в состав снапшота

Онлайн-снапшот:
  • Копия файла конфигурации
  • Дифференциальный диск AVHD
  • Файлы Save State – BIN+VSV
Оффлайн-снапшот:
  • Копия файла конфигурации
  • Дифференциальный диск AVHD


Что можно и что нельзя делать с моментальными снимками?



Как уже было сказано, снапшоты виртуальных машин – это то же самое, что и сохранение в игре. И единственное их назначение – обеспечение точки возврата на случай возможных ошибок. Снапшоты – это не бэкап, и использовать их для аварийного восстановления не получится. Использовать моментальные снимки в production-среде не рекомендуется, потому что это может привести к падению производительности, почему это так – будет понятно далее из статьи. Если необходимо часто создавать резервные копии для защиты от ошибок пользователей – необходимо использовать другие средства, к примеру – инкрементные бэкапы или журналы транзакций, если речь идет о базах данных.
Помимо этого, необходимо помнить, что управлять снапшотами можно и нужно только через стандартные средства Hyper-V (оснастка MMC Hyper-V Manager, WMI-провайдеры, командлеты PowerShell) и сторонний софт, использующий такие средства – например Microsoft SystemCenter Virtual Machine Manager.

Итак, что же происходит при создании снапшота?
image
Для простоты представим виртуальную машину с одним жестким диском (см. рисунок). Только что мы установили на нее операционную систему, и, прежде чем двигаться дальше – хотим сделать снапшот. При выборе Create Snapshot текущая конфигурация виртуальной машины сохраняется в отдельный файл (Копия конфигурации 1), и создается файл AVHD (Дифференциальный диск AVHD 1). При этом в саму конфигурацию виртуальной машины вносятся изменения, и с этого момента из файла VHD производится только чтение, а вся запись производится только в AVHD-файл (зеленая стрелка). Диск виртуальной машины состоит уже из двух файлов: VHD и AVHD. У нас получился первый моментальный снимок, который для удобства можно назвать «OS Installed» (по умолчанию снапшотам дается имя из имени виртуальной машины с добавлением даты и времени создания).
Теперь, допустим, что мы что-то сделали (к примеру, установили приложение) и делаем еще один снапшот. Точно так же, как и до этого – конфигурация сохраняется в отдельный файл, создается новый AVHD, и запись перенаправляется уже в него (желтая стрелка). Виртуальный диск состоит уже из трех файлов: VHD и двух AVHD. Для простоты получившийся снапшот можно назвать «Apps Installed».
Допустим, мы создали один или несколько моментальных снимков. Что же теперь с ними можно сделать? Выбор тут, в принципе, не слишком богат: снапшот можно либо применить (Apply), либо удалить (Delete). По факту, это означает:
  • Apply – возвратиться к точке создания снапшота, при этом все изменения, произошедшие с момента создания снапшота и до настоящего времени будут потеряны.
  • Delete – точка возврата удалится, а все внесенные изменения сохранятся на веки вечные.

Это нужно четко для себя уяснить, чтобы потом не «наломать дров». Как говорил один специалист – «Delete means Apply, Apply means Delete», и даже еще лучше будет сказать в стиле Маяковского: «Мы говорим «Удалить» — подразумеваем «Применить», мы говорим «Применить» — подразумеваем «Удалить».
Посмотрим, как это происходит.
Хотим мы откатиться назад, к моменту окончания установки приложений. Для этого выбираем снапшот «Apps Installed» («Моментальный снимок 2»)и делаем «Apply». Как только мы это делаем – текущая конфигурация виртуалки заменяется копией из состава снапшота (т.е. «Конфигурация» перепишется из «Копии конфигурации 2»). После этого AVHD со внесенными до «отката» изменениями («Дифференциальный диск AVHD 2») удаляется, и создается новый AVHD, в который сразу же перенаправляется запись.
Теперь, допустим, мы закончили наши эксперименты, и перед вводом виртуальной машины в продакшн хотим удалить все наши снапшоты. Если мы удалим снапшот «Apps Installed» то произойдет следующее:
  • Во-первых, удаляется копия файла конфигурации, и сам снапшот исчезает из списка.
  • Если в данный момент виртуальная машина запущена – AVHD, связанный с этим снапшотом остается, и запись в него продолжается.
  • Как только виртуальная машина останавливается (шатдаун или перезагрузка) – все данные из AVHD записываются в предыдущий AVHD, или в VHD, если мы удаляем первый снапшот, а сам AVHD удаляется. Эта операция называется «Объединение» (Merging). Операция объединения может занять определенное время (в зависимости от объемов данных), в течение которого запустить виртуалку нельзя.
Теперь рассмотрим более сложную ситуацию. Допустим, мы установили на нашу виртуалку приложение (скажем, MS SQL Server 2005), «поигрались» с ним, а теперь хотим поиграться с другой версией этого приложения (к примеру, MS SQL Server 2008). Если перед установкой ПО мы сделали снапшот (а мы его сделали, «OS Installed»), то мы просто откатываемся на этот снапшот и ставим уже новое приложение. В результате, у нас образуется новая ветвь снапшотов:
image
При откате к снапшоту «OS Installed» действующий на тот момент AVHD (в составе снапшота «Apps Installed») удаляется, создается новая копия конфигурации и новый AVHD(«Дифференциальный диск AVHD 3»), относящийся, в нашем случае, к самому VHD. Далее, если мы, к примеру, создадим еще один снапшот (для простоты обзовем его «New Snapshot») – то новый AVHD создастся уже на основе «Дифференциального диска AVHD 3»). Таких ветвей может быть и больше – например, от снапшота «OS Installed» может идти и три, и больше ветвей. Операции Delete/Apply при ветвлении происходят так же, как и было описано, но с некоторыми нюансами. К примеру, если мы теперь захотим удалить снапшот «OS Installed» — то он исчезнет из списка, и удалится копия конфигурации, но объединения после останова виртуальной машины не произойдет. Почему? А все очень просто: поскольку от нашего VHD образуются не один, а аж целых два AVHD – перезаписать сам VHD нельзя: если при перезаписи используется AVHD1 – то AVHD3, и соответственно – все, что на него опираются (в нашем случае это AVHD4) при возможном откате на них работать не будут.
Вот еще одно «исключение из правил»: допустим, мы удаляем снапшот «Apps Installed». Как мы видим, своего AVHD у него нет. Поэтому удален будет предыдущий по времени AVHD1.
Если же мы захотим вернуться к снапшоту «Apps Installed» — то создастся новый AVHD на основе AVHD1 (ну то есть новый AVHD2, грубо говоря), а удалится активный на данный момент AVHD4.

Ну и теперь скажу несколько слов в заключение.


Во-первых – как я уже говорил, нужно помнить про «Delete means Apply, Apply means Delete», и думать перед нажатием кнопки, дабы не потерять ничего.
Во-вторых, если виртуальная машина содержит онлайновые снапшоты – ее крайне не рекомендуется экспортировать и переносить на другой сервер. Дело в том, что онлайновый снапшот содержит состояние регистров процессора и содержимое памяти, и применение такого снапшота в другом аппаратном окружении может привести к краху гостевой ОС.
В-третьих, как уже было сказано – снапшоты не рекомендуется использовать в производственной среде. Наверняка вам известно, что для продакшна рекомендуется использовать виртуальные диски фиксированного размера – для того, чтобы избавиться от фрагментации VHD-файла. Создавая же снапшоты, мы искусственно делим наш виртуальный диск на отдельные файлы – VHD и множество AVHD. На высоконагруженных системах это может привести к некоторому падению производительности. Кроме этого, при удалении снапшотов происходит операция объединения, которая тоже может сказаться на общей производительности системы, а к тому же может повысить время простоя при перезагрузках виртуальной машины. К примеру, если вы удалили один или несколько снапшотов на виртуальной машине, а потом потребовалось ее перезагрузить (к примеру – при установке апдейтов), то загрузка ОС не начнется, пока не завершится полностью операция объединения. Поэтому снапшоты можно использовать перед вводом в продакшн, для экономии времени при установке ПО и начальной настройке. После этого все снапшоты нужно удалить, дождаться окончания объединения, и только затем вводить в продакшн.
Еще один небольшой момент: в настройках Hyper-V можно задавать отдельно путь для размещения файлов виртуальных машин и путь для размещения VHD. По умолчанию и то и другое хранится на диске C:. Если для хранения VHD планируется использовать, к примеру, высокоскоростной RAID-массив – необходимо хранить на нем не только VHD, но и файлы виртуальных машин. Дело в том, что при создании снапшотов файлы AVHD будут храниться именно в том месте, которое было выбрано для хранения виртуальных машин. И может получиться так, что сам VHD будет храниться на отдельном дисковом массиве, а куча AVHD будет на диске С:, что не есть хорошо.

На этом я закончу этот пост, и без того уже большой. Прошу прощения за некоторый сумбур, тема при кажущейся простоте немного нетривиальна для объяснения. Для лучшего понимания советую посмотреть скринкаст, с анимированной презентацией и демонстрацией: www.techdays.ru/videos/1490.html

Если хаброобщественность не будет возражать – я могу дать ссылки на другие свои скринкасты и статьи про Hyper-V, дабы не кросспостить и не копипастить. Надеюсь, кого-то моя статья заинтересовала, в любом случае – спасибо заранее.
Александр Косивченко @System32
карма
–128,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

Комментарии (52)

  • +2
    спасибо, полезно.
  • 0
    Обширный материал по функции, спасибо.
    К сведению: Снэпшоты нельзя использовать на виртуализованном Exchange
    • 0
      Нельзя — в смысле, нельзя технически, или рекомендуется? Технических запретов я вроде не видел, да и не слышал. Ну а насчет рекомендуется — это как раз я и говорил про «не использовать в продакшне».
      • 0
        Конечно, слепок снимется, жестких ограничений нет, ведь снэпшоты, это не сервис уровня приложений (application aware). Чтобы сократить операции I/O, Exchange производит чтение и запись не напрямую в базу, а работает с кэшем в оперативной памяти. От сюда прослеживаются две проблемы: либо потеря данных, либо inconsistent database, а может быть всё сразу.
        • +1
          В онлайновых снапшотах (то есть снятых на запущенной виртуалке) происходит дамп оперативки в файл — то же, что и при Save State. Так что кэш не потеряется. Хотя, разумеется, я с Вами соглашусь — снапшотить контроллеры доменов AD, Exchange и SQL-сервера — крайне не рекомендуется, именно поэтому в продакшн-среде снапшоты — unsupported solution.
          • 0
            Насчет онлайновых да, согласен. Еще проблема в скорости работы с разностным диском, возможно это и есть первопричина «неподдерживаемости» решения в продакшене.
            • 0
              Это да, особенно — если мы имеем цепочку из десятка-другого снапшотов, и, соответственно — разностных дисков — при высоких нагрузках на дисковую подсистему она просто просядет. С другой стороны, MS не рекомендует такие сервисы (это СУБД, Exchange Server, а конкретно — роль Mailbox Server) — виртуализировать вообще.
              • 0
                «С другой стороны, MS не рекомендует такие сервисы (это СУБД, Exchange Server, а конкретно — роль Mailbox Server) — виртуализировать вообще.»

                А можно источник такой рекомендации?
                • 0
                  Говорили люди на семинарах, так что пруфлинка не будет. Такие рекомендации вполне обоснованы — потому что дисковая система хуже всех поддается виртуализации, в отличие от процессоров и памяти, поэтому высоконагруженные сервисы лучше всего держать на выделенных серверах, особенно — когда критична именно дисковая подсистема.
                  • 0
                    Пруфлинка не будет, но все равно «рекомендации обоснованы» :)
                    Давайте все же в таком случае говорить не о «рекомендациях Microsoft», а о частном мнении некоторых ведущих семинары сотрудников.
                  • 0
                    Никто не мешает для 'высоконагруженных' сред использовать RDM диски.
                    • 0
                      Ох, простите, немного занесло, забыл, что в Hyper-V это называется Pass-through диски.
                  • 0
                    Официально:
                    technet.microsoft.com/en-us/library/aa996719.aspx

                    Microsoft supports Exchange 2010 in production on hardware virtualization software only when all the following conditions are true:
                    (skipped)
                    The Exchange guest virtual machine:
                    * Is running Microsoft Exchange 2010.
                    * Is deployed on the Windows Server 2008 with SP2 or Windows Server 2008 R2 operating system.
                    * Doesn't have the Unified Messaging server role installed. All Exchange 2010 server roles, except for the Unified Messaging server role, are supported in a virtualization environment.
                    This is due to the real-time response requirements associated with voice communications with the Unified Messaging server role.

  • +1
    Чёрт, я сначала прочитал «ментальных снимков». Подумал, что я весь прогресс проспал.
  • 0
    А еще можно делать снапшоты средствами самого NTFS
    При этом производительность никак не страдает.
    А вообще лучшим решением будет размещение например, по iSCSI на отдельной СХД данных
    и выполнение снапшотов средствами самой СХД. можно применять и на продакшене и для бэкапов.
    • 0
      Не совсем верно, в случае создания снимков файловой системы у запущенной ОС в снимке должны корректно сохраняться открытые файлы, т.е. средствами СХД сделать корректный снимок ФС нельзя. Будет снимок хранилища, но он не будет учитывать состояния открытых файлов, а это все равно, что в момент интенсивной работы дисков нажат RESET, эффект примерно тот же, эффект незакрытых файлов.
      Снимок средствами файловой системы более корректен, при этом файловые буфера сбрасываются, хотя файл и не закрывается, но шансов потерять данные меньше.
      • 0
        При использовании SCOM и при установленых агентах в гостевых системах все происходит корректно. Даже MSSQL c Exchange корректно снапшотятся.
        • 0
          Вы имели в виду SCDPM? SCOM ведь, если мне не изменяет память — осуществляет мониторинг, а SCDPM — бэкапит.
          • 0
            SCVMM + DPM если быть точнее.
            • 0
              Причем виртуальки можно бэкапить только бэта версией DPM2010. Рабочая, но бэта, а вот средствами СХД бэкапить нельзя, DMP не СХД.
              • 0
                Если я правильно понял докладчика на семинаре — Symantec BackupExec 2010 тоже поддерживает бэкап виртуалок Hyper-V R2 на лету.
                • 0
                  Поддерживает, с купленной за 1200уе лицензией и установленным на Hyper-V агентом. =)
                  • 0
                    Ну, DPM вроде тоже не бесплатен :)
                    К тому же цены — это немного выходит за рамки топика, ведь статья — сугубо техническая, а не маркетинговая.
                • 0
                  Опять же создание резерной копии такого рода инструментом это не создание снапшота файловой системы на СХД.
              • 0
                Если использовать VSS Provider от вендора хранилки, то можно получать консистентные snapshot'ы файлов и данных приложений.
    • 0
      Не надо путать божий дар с яичницей. Бэкапы, то есть то, что Вы предлагаете и снапшоты виртуальных машин — это немного разные вещи. Те снапшоты, о которых говорится в статье — это всего лишь save game на случай ошибки, чтобы не повторять сначала установку софта, и, возможно, ОС. В частности, это будет удобно для системных программистов, которые из-за бага в своей программе могут так угробить ОС на тестовой виртуалке, что придется переустанавливать ее с нуля, либо же — откатиться на снапшот. Кстати, снапшоты средствами ФС тоже могут повлиять на производительность — по той же причине, что и дифференциальные диски, ибо снапшоты средствами ОС — это те же дифференциальные диски, только не на уровне файлов, а на уровне самой ФС.
      Кроме этого, снапшот виртуальной машины позволяет так же сохранить и содержимое памяти, то есть позволит откатиться ровно к тому состоянию, которое было до снапшота.
      • 0
        Ну, например, VMware уже пришел к тому, что использует shapshot'ы как часть технологии резервного копирования виртуальных машин (VMware Data Recovery). Возможно, MS тоже рано или поздно к этому придет, например в DPM, если изменит схему удаления snapshot'ов.
        • 0
          У VMware, кстати, та же проблема с удалением снапшотов. То есть при удалении снапшоты последовательно сливаются увеличиваясь в размерах порой в десятки раз, а потом, слившись, вливаются в actual state. Если при этом еще не забился полостью диск datastore :-]
          Так что тоже не славбогу.
          Юзайте снапшоты стораджа.
        • 0
          По-видимому, уже пришли — ведь каким-то образом этот самый DPM умеет бэкапить виртуалки «на лету».

          Снапшоты стораджа — гуд, но это не то же самое, что и снапшоты виртуалки, увы и ах.
          • 0
            Увы и ах, он использует для этого VSS.
            • 0
              То есть есть фактически бэкапится только файловая система и все? Фигово :(
  • 0
    «В-третьих, как уже было сказано – снапшоты не рекомендуется использовать в производственной среде.»

    Хотел бы уточнить формулировку: «не рекомендуется использовать в производственной среде» именно снапшоты MS Hyper-V (и VMware ESX).
    Дело в том, что существует множество разных реализаций снапшотов, в частности, «аппаратная» реализация силами системы хранения. Многие из этих реализаций не имеют описанных проблем и могут успешно применяться и в продакшне.
    Пример — реализация снапшотов в системах хранения NetApp FAS, где они являются одной из основ решения вообще.

    Так что не все снапшоты «одинаково полезны».
    • 0
      Тема статьи — «Использование моментальных снимков (Snapshots) в Hyper-V».
      • 0
        Тем не менее когда вы используете широкораспространенное в индустрии, и появившееся задолго до Hyper-V понятие, в применении к узкочастному случаю конкретной его реализации, то имеет смысл все же уточнять, что речь идет о проблемах конкретной реализации, а не о понятии вобще, чтобы не путать в головах менее подготовленных чем вы читателей.
        • 0
          Вот именно поэтому я и написал в заголовке — «в Hyper-V». И по идее этого должно быть достаточно, чтобы даже самый неподготовленный читатель понял, что речь идет именно о Hyper-V, а не о СХД и бэкапах. Что, по-вашему, я еще должен был сделать?
          • 0
            Я бы это написал в форме
            «В-третьих, как уже было сказано – снапшоты Hyper-V не рекомендуется использовать в производственной среде.»

            Добавлено «Hyper-V».

            Нет, я нисколько не настаиваю, если вы принципиально против, это же ваша статья, но так, по-моему, будет яснее.
            • 0
              Я совсем не против, более того — я даже приветствую конструктивную критику — ведь комментарии сделали тут именно для этого ;)
              Просто я думал, что то, что в статье идет речь о Hyper-V — самоочевидно.
              • 0
                убрать
                но с некоторыми натяжками материал статьи применим и для других систем виртуализации (в частности — VMWare).
                или добавить акцент на HV
                • 0
                  В VMWare Server / ESX снапшоты работают абсолютно по-другому? Может раскроете тему в своей статье? А то я смотрю блог «Виртуализация» совсем не пользуется популярностью.
  • 0
    В общем и целом — все отлично, и статья хорошая…
    Однако по моему горькому опыту, инфраструктурные статьи на Хабре практически не пользуются спросом, и с этим ничего нельзя поделать.
    • +1
      Ну разумеется — это не «жареная тема» а-ля «запрет видеокамер» или «закрытие хостера в 125 сериях». Но, я думаю, что и таким статьям найдется место на Хабре ;)
      • 0
        Ну как знать…
  • +2
    Добавлю только одно.

    ВНИМАНИЕ!!! ВАЖНО!!!

    Перед объединением (merge) обязательно убедитесь, что на диске с исходным VHD достаточно свободного места по схеме VHD + все последующие AVHD. Иначе потеряете виртуалку. То есть когда кончается место при объединении, вы получаете зависший процесс объединения, и убитый VHD, в который прописалась только часть AVHD.

    Так же, http://www.networkfoo.org/server-infrastructure/recovering-your-virtual-machine-how-manually-merge-hyper-v-snapshots-back-one-, что делать, если у вас протерялись файлы конфигурациии машины/снепшотов.
    • 0
      извиняюсь, хабр съел тэг.
    • 0
      Мегареспект! Добавил в статью.
      • 0
        ошибка ветки
    • 0
      словами не передать как меня выручил этот комментарий!!!

      когда я его дочитал на диске оставалось 5 гб… успел :)
  • 0
    давайте ссылки на остальные статьи
  • +1
    Добавлю 5 копеек.
    При откате на снапшот необходимо учитывать несколько моментов:
    1. Если виртуальная машина является членом домена, то с момента создания снапшота могли устареть тикеты Kerberos и пароль учётной записи компьютера. Поэтому в лабораторных условиях можно отключать смену паролей учётных записей.
    2. Нельзя откатывать назад контроллеры домена! Вообще с контроллерами домена много тонких моментов в виртуальной среде, поэтому рекомендую почитать support.microsoft.com/kb/888794
    • 0
      Кстати да, с AD там очень много заморочек.
      Насчет устаревания тикетов — это правда, именно поэтому снапшоты не рассчитаны на длительное хранение — и в частности поэтому их не рекомендуется использовать вместо бэкапов.
      Да, контроллеры домена нельзя откатывать, более того — их не рекомендуется даже переводить в Save State, только Shutdown.
  • 0
    Привет из будущего.
    … и спасибо за полезные статьи по Hyper-V.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.