Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 53
спасибо, полезно.
Обширный материал по функции, спасибо.
К сведению: Снэпшоты нельзя использовать на виртуализованном Exchange
К сведению: Снэпшоты нельзя использовать на виртуализованном Exchange
Нельзя — в смысле, нельзя технически, или рекомендуется? Технических запретов я вроде не видел, да и не слышал. Ну а насчет рекомендуется — это как раз я и говорил про «не использовать в продакшне».
Конечно, слепок снимется, жестких ограничений нет, ведь снэпшоты, это не сервис уровня приложений (application aware). Чтобы сократить операции I/O, Exchange производит чтение и запись не напрямую в базу, а работает с кэшем в оперативной памяти. От сюда прослеживаются две проблемы: либо потеря данных, либо inconsistent database, а может быть всё сразу.
В онлайновых снапшотах (то есть снятых на запущенной виртуалке) происходит дамп оперативки в файл — то же, что и при Save State. Так что кэш не потеряется. Хотя, разумеется, я с Вами соглашусь — снапшотить контроллеры доменов AD, Exchange и SQL-сервера — крайне не рекомендуется, именно поэтому в продакшн-среде снапшоты — unsupported solution.
Насчет онлайновых да, согласен. Еще проблема в скорости работы с разностным диском, возможно это и есть первопричина «неподдерживаемости» решения в продакшене.
Это да, особенно — если мы имеем цепочку из десятка-другого снапшотов, и, соответственно — разностных дисков — при высоких нагрузках на дисковую подсистему она просто просядет. С другой стороны, MS не рекомендует такие сервисы (это СУБД, Exchange Server, а конкретно — роль Mailbox Server) — виртуализировать вообще.
«С другой стороны, MS не рекомендует такие сервисы (это СУБД, Exchange Server, а конкретно — роль Mailbox Server) — виртуализировать вообще.»
А можно источник такой рекомендации?
А можно источник такой рекомендации?
Говорили люди на семинарах, так что пруфлинка не будет. Такие рекомендации вполне обоснованы — потому что дисковая система хуже всех поддается виртуализации, в отличие от процессоров и памяти, поэтому высоконагруженные сервисы лучше всего держать на выделенных серверах, особенно — когда критична именно дисковая подсистема.
Пруфлинка не будет, но все равно «рекомендации обоснованы» :)
Давайте все же в таком случае говорить не о «рекомендациях Microsoft», а о частном мнении некоторых ведущих семинары сотрудников.
Давайте все же в таком случае говорить не о «рекомендациях Microsoft», а о частном мнении некоторых ведущих семинары сотрудников.
Никто не мешает для 'высоконагруженных' сред использовать RDM диски.
Официально:
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.
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.
Чёрт, я сначала прочитал «ментальных снимков». Подумал, что я весь прогресс проспал.
А еще можно делать снапшоты средствами самого NTFS
При этом производительность никак не страдает.
А вообще лучшим решением будет размещение например, по iSCSI на отдельной СХД данных
и выполнение снапшотов средствами самой СХД. можно применять и на продакшене и для бэкапов.
При этом производительность никак не страдает.
А вообще лучшим решением будет размещение например, по iSCSI на отдельной СХД данных
и выполнение снапшотов средствами самой СХД. можно применять и на продакшене и для бэкапов.
При использовании SCOM и при установленых агентах в гостевых системах все происходит корректно. Даже MSSQL c Exchange корректно снапшотятся.
Вы имели в виду SCDPM? SCOM ведь, если мне не изменяет память — осуществляет мониторинг, а SCDPM — бэкапит.
SCVMM + DPM если быть точнее.
Не надо путать божий дар с яичницей. Бэкапы, то есть то, что Вы предлагаете и снапшоты виртуальных машин — это немного разные вещи. Те снапшоты, о которых говорится в статье — это всего лишь save game на случай ошибки, чтобы не повторять сначала установку софта, и, возможно, ОС. В частности, это будет удобно для системных программистов, которые из-за бага в своей программе могут так угробить ОС на тестовой виртуалке, что придется переустанавливать ее с нуля, либо же — откатиться на снапшот. Кстати, снапшоты средствами ФС тоже могут повлиять на производительность — по той же причине, что и дифференциальные диски, ибо снапшоты средствами ОС — это те же дифференциальные диски, только не на уровне файлов, а на уровне самой ФС.
Кроме этого, снапшот виртуальной машины позволяет так же сохранить и содержимое памяти, то есть позволит откатиться ровно к тому состоянию, которое было до снапшота.
Кроме этого, снапшот виртуальной машины позволяет так же сохранить и содержимое памяти, то есть позволит откатиться ровно к тому состоянию, которое было до снапшота.
Ну, например, VMware уже пришел к тому, что использует shapshot'ы как часть технологии резервного копирования виртуальных машин (VMware Data Recovery). Возможно, MS тоже рано или поздно к этому придет, например в DPM, если изменит схему удаления snapshot'ов.
У VMware, кстати, та же проблема с удалением снапшотов. То есть при удалении снапшоты последовательно сливаются увеличиваясь в размерах порой в десятки раз, а потом, слившись, вливаются в actual state. Если при этом еще не забился полостью диск datastore :-]
Так что тоже не славбогу.
Юзайте снапшоты стораджа.
Так что тоже не славбогу.
Юзайте снапшоты стораджа.
По-видимому, уже пришли — ведь каким-то образом этот самый DPM умеет бэкапить виртуалки «на лету».
Снапшоты стораджа — гуд, но это не то же самое, что и снапшоты виртуалки, увы и ах.
Снапшоты стораджа — гуд, но это не то же самое, что и снапшоты виртуалки, увы и ах.
«В-третьих, как уже было сказано – снапшоты не рекомендуется использовать в производственной среде.»
Хотел бы уточнить формулировку: «не рекомендуется использовать в производственной среде» именно снапшоты MS Hyper-V (и VMware ESX).
Дело в том, что существует множество разных реализаций снапшотов, в частности, «аппаратная» реализация силами системы хранения. Многие из этих реализаций не имеют описанных проблем и могут успешно применяться и в продакшне.
Пример — реализация снапшотов в системах хранения NetApp FAS, где они являются одной из основ решения вообще.
Так что не все снапшоты «одинаково полезны».
Хотел бы уточнить формулировку: «не рекомендуется использовать в производственной среде» именно снапшоты MS Hyper-V (и VMware ESX).
Дело в том, что существует множество разных реализаций снапшотов, в частности, «аппаратная» реализация силами системы хранения. Многие из этих реализаций не имеют описанных проблем и могут успешно применяться и в продакшне.
Пример — реализация снапшотов в системах хранения NetApp FAS, где они являются одной из основ решения вообще.
Так что не все снапшоты «одинаково полезны».
Тема статьи — «Использование моментальных снимков (Snapshots) в Hyper-V».
Тем не менее когда вы используете широкораспространенное в индустрии, и появившееся задолго до Hyper-V понятие, в применении к узкочастному случаю конкретной его реализации, то имеет смысл все же уточнять, что речь идет о проблемах конкретной реализации, а не о понятии вобще, чтобы не путать в головах менее подготовленных чем вы читателей.
Вот именно поэтому я и написал в заголовке — «в Hyper-V». И по идее этого должно быть достаточно, чтобы даже самый неподготовленный читатель понял, что речь идет именно о Hyper-V, а не о СХД и бэкапах. Что, по-вашему, я еще должен был сделать?
Я бы это написал в форме
«В-третьих, как уже было сказано – снапшоты Hyper-V не рекомендуется использовать в производственной среде.»
Добавлено «Hyper-V».
Нет, я нисколько не настаиваю, если вы принципиально против, это же ваша статья, но так, по-моему, будет яснее.
«В-третьих, как уже было сказано – снапшоты Hyper-V не рекомендуется использовать в производственной среде.»
Добавлено «Hyper-V».
Нет, я нисколько не настаиваю, если вы принципиально против, это же ваша статья, но так, по-моему, будет яснее.
Я совсем не против, более того — я даже приветствую конструктивную критику — ведь комментарии сделали тут именно для этого ;)
Просто я думал, что то, что в статье идет речь о Hyper-V — самоочевидно.
Просто я думал, что то, что в статье идет речь о Hyper-V — самоочевидно.
В общем и целом — все отлично, и статья хорошая…
Однако по моему горькому опыту, инфраструктурные статьи на Хабре практически не пользуются спросом, и с этим ничего нельзя поделать.
Однако по моему горькому опыту, инфраструктурные статьи на Хабре практически не пользуются спросом, и с этим ничего нельзя поделать.
Добавлю только одно.
ВНИМАНИЕ!!! ВАЖНО!!!
Перед объединением (merge) обязательно убедитесь, что на диске с исходным VHD достаточно свободного места по схеме VHD + все последующие AVHD. Иначе потеряете виртуалку. То есть когда кончается место при объединении, вы получаете зависший процесс объединения, и убитый VHD, в который прописалась только часть AVHD.
Так же, http://www.networkfoo.org/server-infrastructure/recovering-your-virtual-machine-how-manually-merge-hyper-v-snapshots-back-one-, что делать, если у вас протерялись файлы конфигурациии машины/снепшотов.
ВНИМАНИЕ!!! ВАЖНО!!!
Перед объединением (merge) обязательно убедитесь, что на диске с исходным VHD достаточно свободного места по схеме VHD + все последующие AVHD. Иначе потеряете виртуалку. То есть когда кончается место при объединении, вы получаете зависший процесс объединения, и убитый VHD, в который прописалась только часть AVHD.
Так же, http://www.networkfoo.org/server-infrastructure/recovering-your-virtual-machine-how-manually-merge-hyper-v-snapshots-back-one-, что делать, если у вас протерялись файлы конфигурациии машины/снепшотов.
давайте ссылки на остальные статьи
itband.ru/category/virtual/
Начать можно с самых первых статей в разделе — автор Александр Косивченко, это я.
А тут — четыре (пока что) моих скринкаста на тему Hyper-V:
www.techdays.ru/speaker/Alexander_Kosivchenko.html
Начать можно с самых первых статей в разделе — автор Александр Косивченко, это я.
А тут — четыре (пока что) моих скринкаста на тему Hyper-V:
www.techdays.ru/speaker/Alexander_Kosivchenko.html
Добавлю 5 копеек.
При откате на снапшот необходимо учитывать несколько моментов:
1. Если виртуальная машина является членом домена, то с момента создания снапшота могли устареть тикеты Kerberos и пароль учётной записи компьютера. Поэтому в лабораторных условиях можно отключать смену паролей учётных записей.
2. Нельзя откатывать назад контроллеры домена! Вообще с контроллерами домена много тонких моментов в виртуальной среде, поэтому рекомендую почитать support.microsoft.com/kb/888794
При откате на снапшот необходимо учитывать несколько моментов:
1. Если виртуальная машина является членом домена, то с момента создания снапшота могли устареть тикеты Kerberos и пароль учётной записи компьютера. Поэтому в лабораторных условиях можно отключать смену паролей учётных записей.
2. Нельзя откатывать назад контроллеры домена! Вообще с контроллерами домена много тонких моментов в виртуальной среде, поэтому рекомендую почитать support.microsoft.com/kb/888794
Кстати да, с AD там очень много заморочек.
Насчет устаревания тикетов — это правда, именно поэтому снапшоты не рассчитаны на длительное хранение — и в частности поэтому их не рекомендуется использовать вместо бэкапов.
Да, контроллеры домена нельзя откатывать, более того — их не рекомендуется даже переводить в Save State, только Shutdown.
Насчет устаревания тикетов — это правда, именно поэтому снапшоты не рассчитаны на длительное хранение — и в частности поэтому их не рекомендуется использовать вместо бэкапов.
Да, контроллеры домена нельзя откатывать, более того — их не рекомендуется даже переводить в Save State, только Shutdown.
Привет из будущего.
… и спасибо за полезные статьи по Hyper-V.
… и спасибо за полезные статьи по Hyper-V.
Хорошая статья, только жалко, что картинки отвалились
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование моментальных снимков (Snapshots) в Hyper-V