воскресенье, 17 апреля 2011 г.

VM backup with memory dump

Из переписки:
Михаил, добрый день!
Надеюсь, что следующая информация будет для Вас интересна..
В связи с ограниченным бюджетом и небольшими размерами ИТ-инфраструктуры в ближайшем будущем планируем использовать бесплатный ESXi. И сразу же столкнулись с отсутствием вменяемых средств резервного копирования. Широко известный скрипт ghettoVCB.sh выполняет бэкап дисков, но имеет недостаток - он не сохраняет состояние памяти.. Был проведён тщательный анализ различного ПО и в результате был разработана технология, позволяющая делать бэкап с сохранением состояния памяти, т.е. восстанавливается не только диски VDMK, но и дамп оперативной памяти, в итоге получаем полное состояние системы на момент создания копии. С технологией Вы можете ознакомиться по ссылке:
Бэкап ВМ на ESXi с сохранением памяти, рабочая схема

Цитата из инструкции по ссылке:
Столкнулся с тем, что для ESXi'я практически отсутствуют бесплатные решения для организации резервного копирования ВМ. Наиболее приемлемый вариант - скрипт ghettoVCB.sh, который обладает серьёзным недостатком - он лишь бэкапит виртуальные диски, память при этом не сохраняется. Восстановление с такого бэкапа равносильно тому, как будто бы работа сервера была прервана кнопкой Reset, что чревато и не всегда приемлемо.

Предлагаемая схема создания бэкапов эффективно обходит данный недостаток, позволяя создавать резервные копии вместе с сохранением состояния памяти. Восстановление с такого бэкапа равносильно восстановлению со снепшота, т.е. машина возвращается в состояние на момент создания резервной копии.

thx камрад Egros.

20 комментариев:

  1. Мой комментарий к вопросу - http://www.vm4.ru/2011/02/ghettovcb.html?showComment=1303076524244#c718462603546026477

    ОтветитьУдалить
  2. Вот это интересно. Но, существуют ли готовые средства для создания и восстановления бэкапов с памятью?
    Я уже обращался к партнерам vmware - никто о таком не знает. Хотя задача очень простая и очень нужная ( механизм то есть )
    Я рассмотрел более 10ка различных систем резервного копирования для vmware, среди них есть те, которые умеют создавать бэкапы с памятью, но восстанавливать не умееют ( не понятно зачем тогда делается бэкап ).

    ОтветитьУдалить
  3. Hober, в подавляющем большинстве случаев автоматизированные бэкапы не требуют включения памяти. Ибо просто не нужно - машина прекрасно стартует и заново, главное чтобы файловая система консистентна была. И как я уже сказал, остановка ВМ только для снятия снапшота - недопустимо в большинстве случаев.

    Главное - не состояние машины, а данные.

    Anton Zhbankov

    ОтветитьУдалить
  4. Hober, насчёт готоового решения..
    1. Если Вы внимательно читали мою статью, то я там отсылаюсь на решение Trilead VM Explorer, которое умеет сохранять и восстанавливать бэкапы вместе с памятью.
    2. На основании механизма, который я описал, очень просто сделать скрипт. В самом примитивном варианте он будет состоять максимум из 10 строк - если не выполнять проверок и не вести логов. Но в простом случае этого более чем достаточно. Создаются снепшоты командой vmsvc/snapshot.create, файлы копируются командой cp на NFS-хранилище, удаление снепшотов аналогично созданию.

    Anton Zhbankov, в первую очередь необходимо взевсить, что более критично - пауза в 10 секунд или возможность потери данных при восстановлении с бэкапа без памяти (равносильно нажатию Reset). Предлагаемое решение относится скорее к сегменту SBS, где незначительная пауза в несколько секунд абсолютно не критична. В более серьёзных средах скорее всего будут использоваться иные методы резервного копирования и скорее всего оно будет выполняться на уровне приложения, а не на уровне хоста ESXi. Для меня данный способ в первую очередь обеспечивает резервное копирование самой ОС, данные сохраняются иными способами.

    ОтветитьУдалить
  5. 1. Да, я уже тестирую Trilead. Когда я искал готовое решение - нашел только одно Ardeo Snapshots for vmware ( но почему-то оно не умеет восстанавливаться до рабочего состояния с памятью ).
    2. Согласен, буду пробовать.

    ОтветитьУдалить
  6. winengineer, скорее всего? Т.е. Вы не уверены?

    Ну значит у меня несерьезная среда была :-D

    ОтветитьУдалить
  7. Ожидаете какую-то исповедь или хотите меня в чём-то разоблачить, не очень понимаю? )) Я работаю в сегменте СБС и решаю задачи соответсвующего уровня, для нас не критична даже ежедневная часовая пауза.

    ОтветитьУдалить
  8. Всем привет.
    Пожалуйста объясните ещё раз для неразумных. Для чего так необходим бэкап с состоянием памяти?
    В общем случае в момент бэкапа будет вызваны службы VSS и все системы спокойно сбросят состояние на диск, и после восстановления всё будет в лучшем виде.
    Такой практике придерживаются при бэкапе физических машин, и насколько я знаю никто не жаловался.

    Спасибо!

    ОтветитьУдалить
  9. Насколько высоки издержки бэкапа с сохранением состояния памяти по сравнению с простым сохранением данных на дисках? На мой взгляд они минимальны. 30-секундная задержка может иметь критическое значение разве что в случае например особо загруженого SQL-кластера или веб-приложения с очень высокой посещяемостью. Но это решение другого уровня. Тут должны использоваться не бесплатные скрипты для ESXi, а специализированое ПО и оборудование. Данный способ - решение бесплатное, оттого предназначение для сегмента малого бизнеса, готового нести определёные издержки по простоям и производительности. В частности, данный способ очень хорош для бэкапа SBS-сервера или одиночного контроллера домена.

    ОтветитьУдалить
  10. Друзья, простите, но разве в скрипте ghettoVCB.sh нет возможности сохранения памяти?
    Разве параметры: VM_SNAPSHOT_MEMORY, VM_SNAPSHOT_QUIESCE
    этого не делают?

    ОтветитьУдалить
  11. Ещё раз - чем не устраивает архивация консистентного снапшота, создаваемого VSS? Восстановленная машина стартует за 1-5 минут и всё работает как ни в чём не бывало, и SBS, и DC тоже. Какие конкретные проблемы решает сохранение состояния памяти? Зато понятно, какие проблемы оно создаёт - потеря времени и места на хранилище, и потери тем больше, чем больше ОЗУ у ВМ.

    ОтветитьУдалить
  12. >>Друзья, простите, но разве в скрипте ghettoVCB.sh нет возможности сохранения памяти?
    Почти, только восстановиться потом не возможно

    >>Какие конкретные проблемы решает сохранение состояния памяти?
    Есть приложения, которые очень критичны к вырубанию машины ( никакие VSS, сбросы кешей и т.д. не помогают ). На KVM-е эта проблема легко решается - миграцией машины в файл.

    ОтветитьУдалить
  13. Огласите, пожалуйста, список приложений, которые после восстановления из консистентного архива прекращают корректно работать?

    ОтветитьУдалить
  14. Да я согласен, что не все приложения поддерживают VSS. В основном современные приложения (базы данных) работающие на сервере VSS-aware и особой нужны в памяти нет.
    Есть другой вопрос.
    В случае добавления такой машины на этот же сервер не возникнет ли конфликта MAC адресов?
    На сколько мне известно ESX его разруливает только в момент старта машины, а не в момент выхода из suspend.

    ОтветитьУдалить
  15. Hober, а FireBird 1.5 как переживает восстановление из бэкапа на физической машине?

    ОтветитьУдалить
  16. AZh>а FireBird 1.5 как переживает восстановление из бэкапа на физической машине?

    Антон, тут стОит заметить, что восстанавливается из быкапа не FB1.5 как сервер БД, а непосредственно файл(ы) БД.

    Т.е. в общем случае можно мухой установить FB начисто, сресторить штатными средствами быкап БД и вуаля!

    За ув.Hober`ом я подозреваю :) следующее - у него при работе FB может использовать режим ForceWrite=off - т.е. операция записи в БД происходит в отложенном режиме, "задерживаясь" в буферах в ОЗУ. Причём эти буферы контролируются самим FB (т.е. это не дисковый кеш ОС) и задаются как к-во кешируемых страниц БД в её параметрах. Соответственно, если мы не забыкапим ОЗУ, то содержимое буферов будет потеряно.
    Но думаю, что сам ув. Hober должен прояснить ситуацию с его FB лучше, нежели это сделают мои догадки... :)

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  17. Да правильно, настроен отложенный режим, иначе очень большие тормоза при работе с БД ( что для нас не приемлимо ).

    ОтветитьУдалить
  18. 2 Hober:

    Ну это, коллега, нормально - сам эксплуатирую FB1.5 с FW=off... :)

    С уважением,
    Umlyaut.

    ОтветитьУдалить
  19. >Друзья, простите, но разве в скрипте >ghettoVCB.sh нет возможности сохранения памяти?
    >Разве параметры: VM_SNAPSHOT_MEMORY, >VM_SNAPSHOT_QUIESCE
    >этого не делают?

    Нет, не делают. Эти параметры просто создают снепшот вместе с состоянием памяти, при этом дамп памяти скрипт не копирует. Но даже если исправить скрипт и скопировать дамп памяти, это всё равно не сработает, т.к. для восстановление дампа требует наличия delta-VDMK. А чтобы получить дельту, нужно обратиться к механизму, который я описал в статье.

    Насчёт целесобразности. Вполне возможно, что особо и не нужно сохранять память. Недостаток пока вижу только один - при сохранении памяти придётся копировать все виртуальные диски и их дельты, что не всегда приемлемо, есть задачи, требующие сохранять только часть дисков.

    ОтветитьУдалить

Примечание. Отправлять комментарии могут только участники этого блога.