VMware: «To quiesce or not to quiesce?», бэкапим вирутальные машины правильно



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

    Так зачем нужны «quiesced»* снапшоты, с чем их едят, и какие типичные проблемы с ними возникают? Взгляд на снапшоты будет представлен в первую очередь с точки зрения резервного копирования, но постараюсь в какой-то мере раскрыть и другие аспекты использования.


    * Если кто готов подсказать подходящий русскоязычный термин — милости прошу в комментарии, будет хороший вариант — заменю в тексте англицизм.


    Использование снапшотов для резервного копирования


    В окружении VMware vSphere процесс создания снапшота контролируется двумя опциями:
    • Снапшот включающий состояние памяти виртуальной машины
    • Снапшот предваряемый так называемым quiescing-ом гостевой файловой системы

    В случае резервного копирования виртуальной машины посредством VMware vStorage API for Data Protection первая опция просто не используется, и основная причина этого поведения такова: если у виртуальной машины большое количество RAM (а вируталки по 8-16ГБ RAM уже давно не редкость), то при включении данной опции время создания и размер инкрементального бэкапа будет существенным (каждый инкрементальный бэкап будет дополнительно включать размер RAM). Помимо этого есть ещё ряд технических сложностей, но сегодня они нас мало интересуют, т.к. мы рассматриваем альтернативный вариант развития событий.

    Собственно, альтернативный вариант и есть наша вторая опция — 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 переходит в запущенное, а затем в остановленное состояние.

    В-третьих, одной из типичных проблем настройки quiescing'а является параметр disk.EnableUUID=true в конфигурации .vmx виртуальной машины.

    Эта настройка имеет смысл только для гостевых систем под управлением 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 внутри гостевой машины. Это основной пункт вызывающий тонны негодования и обращений в техподдержку VMware. Часто люди, видящие неудачный снапшот, грешат на VMware, хотя винить стоит совсем другого гиганта мысли — Microsoft. Примерно такую картину я получил при попытке создать quiesced снапшот машины после неудачной установки новой базы SQL (виртуальный .iso привод был отмонтирован в процессе установки, что очень не понравилось установщику. :-\



    Данная проблема была решена банальной перезагрузкой виртуальной машины, и хотя такой метод помогает очень часто, бывают запущенные случаи, когда 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.

    Не забывайте подписываться на наш Хаб, у нас запланировано огромное количество статей на тему бэкапа и восстановления данных, быть может, именно наши статьи помогут вам решить определённые проблемы (а лучше — избежать их). Спасибо за внимание. :)
    Acronis
    143,00
    Компания
    Поделиться публикацией

    Похожие публикации

    Комментарии 22

      –1
      «Незаметный» снимок. Или «ленивый» снимок.
        0
        Боюсь эти варианты не совсем отражают суть quiesced снапшота. Дословный перевод выглядит как «замороженный снимок», что впрочем гораздо хуже чем ваши переводы :)
          0
          «Замороженный» вполне нормальный перевод — как пример аналогия с «горячими» данными
            +1
            Сейчас подумал, что «консистентный снимок» подходит по смыслу. К примеру даже «quiesce guest file system» можно будет перевести как «обеспечить консистентность гостевой файловой системы». «Заморозить файловую систему» в данном контексте, впрочем, тоже подойдет, но лично мне этот вариант не нравится.
              0
              Именно консистентный и подходит, поскольку основная цель этого типа снапшота — подготовка ВМ к резервному копированию, а значит обеспечение последующего корректного восстановления.
        +1
        по мне так снимок без quiesced называть «моментальным», а с quiesced называть консистентным, без аналогов в русском языке.
          0
          На минуту опередили :)
            0
            :)
            ну еще как вариант «целостный» снимок, но мне кажется что консистентный будет самый раз.
            0
            Проблема может быть в том что галка стояла, а снэпшот всё равно не консистентный…
            0
            А что происходит в случае гостей на Линуксе?
              +2
              Все Линуксы по дефолту снапшотятся в crash-consistent состоянии, однако существует драйвер vmsync от VMware (входит в состав VMware Tools для Линуксов), который позволяет обеспечивать file-system консистентность при создании quiesced снапшотов. Про приложения, конечно, говорить не приходится и для них используются pre-freeze/post-thaw скрипты, которые можно запускать через те же VMware Tools для координации со снапшотом. Подробнее можно почитать тут — нашел только на английском и на неофициальном ресурсе, т.к. у самой VMware данная тема достаточно скудно раскрыта в публичных ресурсах.
              0
              USN-Rollback будет возникать даже со включеным VSS, потому что природа этой ошибки ну совершенно не связана с VSS. VSS- это сервис, который всего навсего перед бэкапом заставляет базу данных записать все транзакции на диск, далее БД приостанавливает свою работу, затем создаётся теневая копия тома, на что уходит несколько секунд, Далее БД продолжает свою работу в обычном режиме, а бэкап сливается уже с теневой копии. В VMWare теневая копия не создаётся, а создаётся delta vdmk, при этом исходный vdmk становится доступным на чтение и содержит консистентные данные, что позволяет его скопировать в качестве бэкапа. USN-rollback возникает совершенно в других обстоятельствах и никакх не связан с неконсистентностью базы данных АД. USN-rollback можно получить при использовании бэкапа снятого с выключеной машины. Очень важное условие для возникновения данной ошибки — после бэкапа между двумя КД обязательно должна пройти репликация, для этого достаточно создать учётную запись на одном из них. Если этого не сделать, ошибка не появится. Если после этого восстановить один из КД, то он будет с меньшим значением USN, чем USN, который знает оставшийся КД. В итоге будет ошибка. Причём я эту ошибку миллион раз симулировал используя снепшоты VMWare. Избежать этой ошибки можно только одним способом — сделать неавторитетное восстановление, что умеет делать только спец софт, а вот снепшоты VMWare даже с поддержкой VSS этого делать не умеют.
                0
                Ждал этого комментария: мы изначально думали примерно в том же ключе, считая что необходимо выполнять дополнительные приседания при восстановлении, и специально проводили тесты, создавая снапшоты с и без опции quiesced на ВМке с домен контроллером внутри (естественно при наличии как минимум второго DC). В итоге USN rollback воспроизводился, при одних и тех же остальных действиях на одном и том же окружении (и запись в AD создавали и юзеров удаляли), только в случае восстановления из non-quiesced снапшота. Все попытки воспроизвести проблему при нормально работающем VSS и использовании опции quiesced ни к чему не привели. Никаких дополнительных действий именно на ресторе не потребовалось. ВАЖНО: главным пунктом здесь является не столько сама опция quiescing, сколько тот факт, что VSS действительно используется, а не просто молча создается снапшот.

                Возможно у вас есть какие-нибудь сценарии восстановления, которые мы не покрыли — это было бы очень интересно выяснить (т.е. дополнительный тестовый сценарий). Если же есть окружение где проблема воспроизводится — еще лучше. Напишите тогда, пожалуйста, в личку, и я думаю мы сможем докопаться до сути.
                  0
                  VSS гарантирует консистентность горячего бэкапа, т.е. если не поставить указанную галочку, можно получить в бэкапе битую базу. На этом функции VSS заканчиваются. А ошибка USN RollBack не связана с тем, битая база или нет, ошибка связана с данными внутри базы, конкретно, с неккоретным значением USN. Т.е. чтобы при восстановлении из снепшота ошибка не возникала, vsphere должен выполнить некие дополнительные манипуляции по контролю USN, не связанные с технологией VSS. Я проводил свои тесты на vSphere 4.1 с windows 2003, возможно, с тех пор что-то поменялось и был предусмотрен некий функционал по контролю USN при восстановлении из снепшота. Если это так, то мне кажется, было бы правильно рассмотреть это в статье, иначе описание получается неполным, не понятно, как это работает.
                    0
                    Мы использовали 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 внутри ВМки).
                      0
                      А windows 2008 не может этого делать сам? Работать это может следующим образом — когда галку ставим, через VSS, контроллер домена узнаёт, что его бэкапят и делает необходимые манипуляции. Галка не стоит — KD не в курсе, что его бэкапят, в итоге ошибка. Я смутно припоминаю, что где-то читал, что данную проблему пофиксили в более новых ОС, к сожалению, точно уже не помню, возможно ошибаюсь.
                        0
                        Windows Server 2012 и старше уже могут понять что виртуализированы и проблемы не возникает technet.microsoft.com/en-us/library/hh831734.aspx
                          0
                          На Win2008 R2, как мы выяснили тоже работает, хотя в статье явно упоминается, что улучшения валидны только для Win2012 и выше. Странно это :) В любом случае Win2k3 отдельно проверим.
                            0
                            Долговато конечно проверяли (сказались затянувшиеся праздники и накопившиеся задачи), но наконец подтвердили факт, что Win2k3 ведет себя так же как и Win2k8: восстановление из снапшота сделанного без VSS приводит к USN rollback, в то время как восстановление из правильно сделанного quiesced снапшота позволяет домен контроллерам нормально функционировать.
                        0
                        Почему не спросить в Microsoft или VMware об особенностях работы из продуктов?
                          0
                          Спросить — это одно, а воочию пощупать руками и убедиться на практике — другое :)
                  0
                  походу для «quiesce» больше всего подходит русский аналог «заморозка, замораживание»:
                  www.multitran.ru/c/m.exe?CL=1&s=quiesce&l1=1
                  www.microsoft.com/Language/en-US/Search.aspx

                  звыняйте за некропостинг

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

                  Самое читаемое