Комментарии 22
«Незаметный» снимок. Или «ленивый» снимок.
Боюсь эти варианты не совсем отражают суть quiesced снапшота. Дословный перевод выглядит как «замороженный снимок», что впрочем гораздо хуже чем ваши переводы :)
«Замороженный» вполне нормальный перевод — как пример аналогия с «горячими» данными
Сейчас подумал, что «консистентный снимок» подходит по смыслу. К примеру даже «quiesce guest file system» можно будет перевести как «обеспечить консистентность гостевой файловой системы». «Заморозить файловую систему» в данном контексте, впрочем, тоже подойдет, но лично мне этот вариант не нравится.
по мне так снимок без quiesced называть «моментальным», а с quiesced называть консистентным, без аналогов в русском языке.
А что происходит в случае гостей на Линуксе?
Все Линуксы по дефолту снапшотятся в crash-consistent состоянии, однако существует драйвер vmsync от VMware (входит в состав VMware Tools для Линуксов), который позволяет обеспечивать file-system консистентность при создании quiesced снапшотов. Про приложения, конечно, говорить не приходится и для них используются pre-freeze/post-thaw скрипты, которые можно запускать через те же VMware Tools для координации со снапшотом. Подробнее можно почитать тут — нашел только на английском и на неофициальном ресурсе, т.к. у самой VMware данная тема достаточно скудно раскрыта в публичных ресурсах.
USN-Rollback будет возникать даже со включеным VSS, потому что природа этой ошибки ну совершенно не связана с VSS. VSS- это сервис, который всего навсего перед бэкапом заставляет базу данных записать все транзакции на диск, далее БД приостанавливает свою работу, затем создаётся теневая копия тома, на что уходит несколько секунд, Далее БД продолжает свою работу в обычном режиме, а бэкап сливается уже с теневой копии. В VMWare теневая копия не создаётся, а создаётся delta vdmk, при этом исходный vdmk становится доступным на чтение и содержит консистентные данные, что позволяет его скопировать в качестве бэкапа. USN-rollback возникает совершенно в других обстоятельствах и никакх не связан с неконсистентностью базы данных АД. USN-rollback можно получить при использовании бэкапа снятого с выключеной машины. Очень важное условие для возникновения данной ошибки — после бэкапа между двумя КД обязательно должна пройти репликация, для этого достаточно создать учётную запись на одном из них. Если этого не сделать, ошибка не появится. Если после этого восстановить один из КД, то он будет с меньшим значением USN, чем USN, который знает оставшийся КД. В итоге будет ошибка. Причём я эту ошибку миллион раз симулировал используя снепшоты VMWare. Избежать этой ошибки можно только одним способом — сделать неавторитетное восстановление, что умеет делать только спец софт, а вот снепшоты VMWare даже с поддержкой VSS этого делать не умеют.
Ждал этого комментария: мы изначально думали примерно в том же ключе, считая что необходимо выполнять дополнительные приседания при восстановлении, и специально проводили тесты, создавая снапшоты с и без опции quiesced на ВМке с домен контроллером внутри (естественно при наличии как минимум второго DC). В итоге USN rollback воспроизводился, при одних и тех же остальных действиях на одном и том же окружении (и запись в AD создавали и юзеров удаляли), только в случае восстановления из non-quiesced снапшота. Все попытки воспроизвести проблему при нормально работающем VSS и использовании опции quiesced ни к чему не привели. Никаких дополнительных действий именно на ресторе не потребовалось. ВАЖНО: главным пунктом здесь является не столько сама опция quiescing, сколько тот факт, что VSS действительно используется, а не просто молча создается снапшот.
Возможно у вас есть какие-нибудь сценарии восстановления, которые мы не покрыли — это было бы очень интересно выяснить (т.е. дополнительный тестовый сценарий). Если же есть окружение где проблема воспроизводится — еще лучше. Напишите тогда, пожалуйста, в личку, и я думаю мы сможем докопаться до сути.
Возможно у вас есть какие-нибудь сценарии восстановления, которые мы не покрыли — это было бы очень интересно выяснить (т.е. дополнительный тестовый сценарий). Если же есть окружение где проблема воспроизводится — еще лучше. Напишите тогда, пожалуйста, в личку, и я думаю мы сможем докопаться до сути.
VSS гарантирует консистентность горячего бэкапа, т.е. если не поставить указанную галочку, можно получить в бэкапе битую базу. На этом функции VSS заканчиваются. А ошибка USN RollBack не связана с тем, битая база или нет, ошибка связана с данными внутри базы, конкретно, с неккоретным значением USN. Т.е. чтобы при восстановлении из снепшота ошибка не возникала, vsphere должен выполнить некие дополнительные манипуляции по контролю USN, не связанные с технологией VSS. Я проводил свои тесты на vSphere 4.1 с windows 2003, возможно, с тех пор что-то поменялось и был предусмотрен некий функционал по контролю USN при восстановлении из снепшота. Если это так, то мне кажется, было бы правильно рассмотреть это в статье, иначе описание получается неполным, не понятно, как это работает.
Мы использовали vSphere 5.0 и 2 машины Win2k8R2 SP1 в качестве домен контроллеров (возможно и на других конфигурациях, но сейчас не могу найти точную информацию). В результате в ивент логе отресторенной машине было следующее сообщение:
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.
USN rollback при этом не наблюдалось, но он легко воспроизводился, если создавать бэкап при отключенных VMware Tools (просто выключали сервис). Подозреваю, что VMware Tools делают дополнительные приседания на стадии бэкапа помимо использования VSS, но точно этого выяснить не удалось (копаться в чужом коде не этично, да и не особо законно :)). Другой вариант это то, что в VSS райтере AD заложены инструкции по восстановлению из такого снапшота — я думаю, что этот вариант более вероятный, т.к. иначе зачем этот VSS райтер нужен, если не за тем, чтобы обеспечить нормальное восстановление?
Попробуем vSphere 4.1 + Win2k3 на всякий случай — по результатам отпишусь. Проверять будем бэкап + восстановление при помощи Acronis vmProtect 9 (бэкап с опцией application-aware для проверки консистентности VSS внутри ВМки).
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.
USN rollback при этом не наблюдалось, но он легко воспроизводился, если создавать бэкап при отключенных VMware Tools (просто выключали сервис). Подозреваю, что VMware Tools делают дополнительные приседания на стадии бэкапа помимо использования VSS, но точно этого выяснить не удалось (копаться в чужом коде не этично, да и не особо законно :)). Другой вариант это то, что в VSS райтере AD заложены инструкции по восстановлению из такого снапшота — я думаю, что этот вариант более вероятный, т.к. иначе зачем этот VSS райтер нужен, если не за тем, чтобы обеспечить нормальное восстановление?
Попробуем vSphere 4.1 + Win2k3 на всякий случай — по результатам отпишусь. Проверять будем бэкап + восстановление при помощи Acronis vmProtect 9 (бэкап с опцией application-aware для проверки консистентности VSS внутри ВМки).
А windows 2008 не может этого делать сам? Работать это может следующим образом — когда галку ставим, через VSS, контроллер домена узнаёт, что его бэкапят и делает необходимые манипуляции. Галка не стоит — KD не в курсе, что его бэкапят, в итоге ошибка. Я смутно припоминаю, что где-то читал, что данную проблему пофиксили в более новых ОС, к сожалению, точно уже не помню, возможно ошибаюсь.
Windows Server 2012 и старше уже могут понять что виртуализированы и проблемы не возникает technet.microsoft.com/en-us/library/hh831734.aspx
На Win2008 R2, как мы выяснили тоже работает, хотя в статье явно упоминается, что улучшения валидны только для Win2012 и выше. Странно это :) В любом случае Win2k3 отдельно проверим.
Долговато конечно проверяли (сказались затянувшиеся праздники и накопившиеся задачи), но наконец подтвердили факт, что Win2k3 ведет себя так же как и Win2k8: восстановление из снапшота сделанного без VSS приводит к USN rollback, в то время как восстановление из правильно сделанного quiesced снапшота позволяет домен контроллерам нормально функционировать.
Почему не спросить в Microsoft или VMware об особенностях работы из продуктов?
походу для «quiesce» больше всего подходит русский аналог «заморозка, замораживание»:
www.multitran.ru/c/m.exe?CL=1&s=quiesce&l1=1
www.microsoft.com/Language/en-US/Search.aspx
звыняйте за некропостинг
www.multitran.ru/c/m.exe?CL=1&s=quiesce&l1=1
www.microsoft.com/Language/en-US/Search.aspx
звыняйте за некропостинг
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
VMware: «To quiesce or not to quiesce?», бэкапим вирутальные машины правильно