[room] Разработка механизма резервирования виртуальных машин.

[room] Разработка механизма резервирования виртуальных машин.

[Илья Кучмин]

Задумался об автоматизации процесса резервирования виртуальных машин
на платформах openvz, kvm. Так как backup HN не требуется то
возникает, вполне законное желание, осуществлять перекрестный backup.
Особенно если учесть, что винчестеры нынче дешевые, да и raid обычно
нулевой используется.
Процесс резервирования видится следующим: Имеется два компонента
Сервер и Клиент. Сервер выполняет процесс резервирования для
виртуальных машин которые на нем хостятся. В зависимости от типа
виртуализации процесс резервирования может отличаться, соответственно
должны использоваться утилиты предоставленные авторами механизма
виртуализации, либо инструмент который пожелает использовать
администратор. После того как процесс снятия резервных копий окончен,
сервер рассылает(клиентам) уведомления, после чего клиенты
осуществляют процедуру выгрузки копий зарезервированных на сервере
виртуальных машин. Также клиенты должны с определенной периодичностью
проверять наличие последних обновлений доступных на сервере. Таким
образом решается проблема потерявшихся в пути уведомлений. По
истечении таймаута клиент самостоятельно спросит сервер и выгрузит
последние копии машин. Понятие Клиент и Сервер существуют в рамках
одной сессии передачи данных, так как для одних VPS, HW является
клиентам(выгружая их с другой машины) для других сервером(предоставляя
свои ресурсы гостям). В случае если в дальнейшем появиться желание
выделить отдельный сервер для хранения резервных копий, будет
достаточно обозначить его как клиента для всех VPS.

Примечания:
Уведомления должны передаваться не только в рамках одной
широковещательной сети. Гарантии что промежуточные маршрутизаторы
поддерживают multicast также нет.
Механизм передачи должен позволять контролировать использование
пропускной способности сети, на стадии старта
Имеется Архив. В него складываются данные которые снимаются единожды и
в дальнейшем не требуют обновления. Должна присутствовать возможность
сказать клиенту, что он хранит архив, который он самостоятельно
синхронизирует согласно представленной выше схеме.

Прошу читателей покритиковать предложенную схему backup.
Также если вы знаете об инструментах которые полностью или частично
реализуют необходимый функционал, прошу указать их.

На данный момент видятся следующие задачи:
Передача файлов между несколькими ВМ, с проверкой контрольных сумм
Запус задачи начала процесса резервирования по графику
Рассылка и прием notify сообщений

Премного благодарен за любую критику и наводку на инструменты.

Re: [room] Разработка механизма резервирования виртуальных машин

[Michael Shigorin]

On Sun, Jan 01, 2012 at 04:59:29PM +0400, Илья Кучмин wrote:
> Задумался об автоматизации процесса резервирования виртуальных
> машин на платформах openvz, kvm. Так как backup HN не требуется
> то возникает, вполне законное желание, осуществлять
> перекрестный backup.

Есть такое.

> Особенно если учесть, что винчестеры нынче дешевые, да и raid
> обычно нулевой используется.

Тот, кто с дешёвыми винчестерами использует raid0 для данных,
испытывает судьбу даже и с бэкапами.  Да и с дорогими тоже...

> Процесс резервирования видится следующим: Имеется два компонента
> Сервер и Клиент. Сервер выполняет процесс резервирования для
> виртуальных машин которые на нем хостятся.

Целиком?

> В зависимости от типа виртуализации процесс резервирования
> может отличаться, соответственно должны использоваться утилиты
> предоставленные авторами механизма виртуализации, либо
> инструмент который пожелает использовать администратор.

Вы про снапшоты?  Лучше по возможности конкретизировать то,
что крутится в голове, поскольку фразу можно понимать сразу
на нескольких уровнях :)

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

Не проще ли слать их более-менее гарантированным транспортом?
Таймстампы -- относительно небольшой трафик даже относительно
метаданных.  Мультикаст относительно интересен при выливе данных,
но есть подозрение, что _закладываться_ на него -- значит как
минимум существенно усложнить себе поддержку шифрования трафика
(например, http://cseweb.ucsd.edu/~spanjwan/multicast.html).
IMHO это хорошая идея при разливе образов, но не для бэкапа...

> Понятие Клиент и Сервер существуют в рамках одной сессии
> передачи данных, так как для одних VPS, HW является
> клиентам(выгружая их с другой машины) для других
> сервером(предоставляя свои ресурсы гостям).

Резонно запихать бэкап тоже в контейнеры или виртуалки.

> Примечания:
> Уведомления должны передаваться не только в рамках одной
> широковещательной сети. Гарантии что промежуточные
> маршрутизаторы поддерживают multicast также нет.

Мало того, для уведомлений мультикаст не очень интересен.

> Прошу читателей покритиковать предложенную схему backup.

Вы знакомы с bacula?  Там достаточно гибкая и шаблонируемая
схема организации распределённого бэкапа, хотя возни при
реализации (и времени на освоение базовых вещей) прилично.

> Также если вы знаете об инструментах которые полностью или
> частично реализуют необходимый функционал, прошу указать их.

Возможно, http://wiki.openvz.org/Partners#Openwall;
ещё какие-то соображения можно попробовать почерпнуть около
http://www.virtualmin.com/documentation/cloudmin/vm/backup

(а бакулу есть мысля подружить с инструментарием управления
виртуальными окружениями и машинами, разработанным в рамках
Clustrx -- но это вряд ли дело ближайшего полугода)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [room] Разработка механизма резервирования виртуальных машин

[Илья Кучмин]

2012/1/3 Michael Shigorin <mike@osdn.org.ua>:
> On Sun, Jan 01, 2012 at 04:59:29PM +0400, Илья Кучмин wrote:
>> Задумался об автоматизации процесса резервирования виртуальных
>> машин на платформах openvz, kvm. Так как backup HN не требуется
>> то возникает, вполне законное желание, осуществлять
>> перекрестный backup.
>
> Есть такое.
>
Под словом "перекрестный" предполагаю хранение резервных копий
непосредственно на HW.
>> Особенно если учесть, что винчестеры нынче дешевые, да и raid
>> обычно нулевой используется.
>
> Тот, кто с дешёвыми винчестерами использует raid0 для данных,
> испытывает судьбу даже и с бэкапами.  Да и с дорогими тоже...
В данном случае от raid1 большоей пользы не будет. VPS в основном
используются для целей тестирования и разработки, смысл backup только
в том, чтобы в короткие сроки развернуть машину на стороннем HW. В
идеале, если требуется стабильность, имеет смысл собирать raid начиная
с 5, но в нашем случае это слишком большие затраты, не сравнимые с
однодневными потерями.
>
>> Процесс резервирования видится следующим: Имеется два компонента
>> Сервер и Клиент. Сервер выполняет процесс резервирования для
>> виртуальных машин которые на нем хостятся.
>
> Целиком?

Если речь идет именно о VPS, то да - целиком. Сохраняются диск и
метаданные о VPS.
>
>> В зависимости от типа виртуализации процесс резервирования
>> может отличаться, соответственно должны использоваться утилиты
>> предоставленные авторами механизма виртуализации, либо
>> инструмент который пожелает использовать администратор.
>
> Вы про снапшоты?  Лучше по возможности конкретизировать то,
> что крутится в голове, поскольку фразу можно понимать сразу
> на нескольких уровнях :)

Я имел ввиду, что системе должно быть возможно указать какую утилиту
использовать для выполнения резервирования. К примеру для выполнения
резервирования машин на платформе OpenVZ хорошо бы было испольлзовать
vzdump и т.д.

>
>> После того как процесс снятия резервных копий окончен,
>> сервер рассылает(клиентам) уведомления, после чего клиенты
>> осуществляют процедуру выгрузки копий зарезервированных на сервере
>> виртуальных машин. Также клиенты должны с определенной
>> периодичностью проверять наличие последних обновлений доступных
>> на сервере. Таким образом решается проблема потерявшихся в пути
>> уведомлений.
>
> Не проще ли слать их более-менее гарантированным транспортом?

Когда я говорил о не гарантированных обновлениях я предполагал
вариант, когда клиент выпал из сети. В таком случае сервер пишет в лог
что уведомление не доставленно и в дальнейшем не пытается его
доставить повторно.(По аналогии с notify в DNS

> Таймстампы -- относительно небольшой трафик даже относительно
> метаданных.  Мультикаст относительно интересен при выливе данных,
> но есть подозрение, что _закладываться_ на него -- значит как
> минимум существенно усложнить себе поддержку шифрования трафика
> (например, http://cseweb.ucsd.edu/~spanjwan/multicast.html).
> IMHO это хорошая идея при разливе образов, но не для бэкапа...
>
>> Понятие Клиент и Сервер существуют в рамках одной сессии
>> передачи данных, так как для одних VPS, HW является
>> клиентам(выгружая их с другой машины) для других
>> сервером(предоставляя свои ресурсы гостям).
>
> Резонно запихать бэкап тоже в контейнеры или виртуалки.
Об этом я думал. В принципе идея правильная.

>
>> Примечания:
>> Уведомления должны передаваться не только в рамках одной
>> широковещательной сети. Гарантии что промежуточные
>> маршрутизаторы поддерживают multicast также нет.
>
> Мало того, для уведомлений мультикаст не очень интересен.
>
>> Прошу читателей покритиковать предложенную схему backup.
>
> Вы знакомы с bacula?  Там достаточно гибкая и шаблонируемая
> схема организации распределённого бэкапа, хотя возни при
> реализации (и времени на освоение базовых вещей) прилично.
>
Про bacula читал, но не использовал. Если не сложно поясните как ее
можно применить в моем случае. Мне кажется основная проблема в том,
что в bacula процесс резервирования инициируется единым сервером,
через клиентов на HW. В тоже время я хочу обратной ситуации, чтобы
более скурпулезно управлять процессом резервирования в зависимости от
нагрузки HW и активности использования VPS. Возможно я зря этого хочу,
если вы считаете также то прошу указать на это.
>> Также если вы знаете об инструментах которые полностью или
>> частично реализуют необходимый функционал, прошу указать их.
>
> Возможно, http://wiki.openvz.org/Partners#Openwall;
Не до конца понял в какой форме они осуществляют процесс
резервирования. Если использовали прошу поделиться опытом.
> ещё какие-то соображения можно попробовать почерпнуть около
> http://www.virtualmin.com/documentation/cloudmin/vm/backup
Они предлагают обычный backup с возможностью передачи в удаленное
хранилище. Собственно немного не то, что мне надо, но все равно
спасибо за ссылку.
>
> (а бакулу есть мысля подружить с инструментарием управления
> виртуальными окружениями и машинами, разработанным в рамках
> Clustrx -- но это вряд ли дело ближайшего полугода)
Про bacula почитаю подробнее, насколько я понял это самый
распространненный инструмент.

Благодарен за любые мысли.
>
> --
>  ---- WBR, Michael Shigorin <mike@altlinux.ru>
>  ------ Linux.Kiev http://www.linux.kiev.ua/
> _______________________________________________
> smoke-room mailing list
> smoke-room@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/smoke-room

Re: [room] Разработка механизма резервирования виртуальных машин

[Michael Shigorin]

On Tue, Jan 03, 2012 at 05:50:44PM +0400, Илья Кучмин wrote:
> > Есть такое.
> Под словом "перекрестный" предполагаю хранение резервных копий
> непосредственно на HW.

Я понял как "взаимное предоставление хостами с расположенными
на них контейнерами друг другу стораджа для бэкапа".

> >> Особенно если учесть, что винчестеры нынче дешевые, да и
> >> raid обычно нулевой используется.
> > Тот, кто с дешёвыми винчестерами использует raid0 для данных,
> > испытывает судьбу даже и с бэкапами.  Да и с дорогими тоже...
> В данном случае от raid1 большоей пользы не будет. VPS в
> основном используются для целей тестирования и разработки,
> смысл backup только в том, чтобы в короткие сроки развернуть
> машину на стороннем HW.

А-аа, ну так это существенное уточнение.  Возможно, Вам лучше
посмотреть в сторону существующих систем для организации
provisioning -- насколько понимаю, сейчас в моде Puppet.
(мы работали с systemimager.org)

> В идеале, если требуется стабильность, имеет смысл собирать
> raid начиная с 5, но в нашем случае это слишком большие
> затраты, не сравнимые с однодневными потерями.

Пятёрка плоха по записи и ресурсу дисков, если что.

> >> [...] соответственно должны использоваться утилиты
> >> предоставленные авторами механизма виртуализации [...]
> > Вы про снапшоты?
> Я имел ввиду, что системе должно быть возможно указать какую
> утилиту использовать для выполнения резервирования. К примеру
> для выполнения резервирования машин на платформе OpenVZ хорошо
> бы было испольлзовать vzdump и т.д.

Если по постановке задачи делается не столько бэкап, сколько
шаблон -- может быть проще останавливать VE/VM и делать просто
копию.  VE при практически нулевой активности можно бэкапить
и на ходу, хотя риск неконсистентности при этом всё же есть.

Ещё может быть интересно эти шаблоны попросту выпекать под задачу
-- на альтовской (прямщас) пакетной базе пилю mkimage-profiles:
http://www.altlinux.org/Mkimage/Profiles/m-p -- но это требует
возможности в существенной степени формализовать задачу VE.

> > Не проще ли слать их более-менее гарантированным транспортом?
> Когда я говорил о не гарантированных обновлениях я предполагал
> вариант, когда клиент выпал из сети. В таком случае сервер
> пишет в лог что уведомление не доставленно и в дальнейшем не
> пытается его доставить повторно.(По аналогии с notify в DNS

Возможно, стоит описать собсно задачу, а не фрагмент видимой
реализации.

> >> Прошу читателей покритиковать предложенную схему backup.
> > Вы знакомы с bacula?  Там достаточно гибкая и шаблонируемая
> > схема организации распределённого бэкапа, хотя возни при
> > реализации (и времени на освоение базовых вещей) прилично.
> Про bacula читал, но не использовал. Если не сложно поясните
> как ее можно применить в моем случае.

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

> Мне кажется основная проблема в том, что в bacula процесс
> резервирования инициируется единым сервером, через клиентов на
> HW. В тоже время я хочу обратной ситуации, чтобы более
> скурпулезно управлять процессом резервирования в зависимости от
> нагрузки HW и активности использования VPS.

Да, bacula нацелена на снятие головной боли ручного управления.

> Возможно я зря этого хочу, если вы считаете также то прошу
> указать на это.

Попробуйте сделать небольшой прототип и поиграться с ним,
чтобы понять, насколько будет необходимо человеческое внимание.
Осторожно только с тем, чтоб не влопатить туда нечаянно слишком
много рабочего кода: можно попасть на "о, так у нас уже есть
решение" и прототип пойдёт в дело, к которому не готов в принципе.

У меня обычно ощущения складываются за две-четыре недели таких
экспериментов...

> >> Также если вы знаете об инструментах которые полностью или
> >> частично реализуют необходимый функционал, прошу указать их.
> > Возможно, http://wiki.openvz.org/Partners#Openwall;
> Не до конца понял в какой форме они осуществляют процесс
> резервирования. Если использовали прошу поделиться опытом.

Нет, не использовал -- ссылку дал с тем, чтобы если покажется
интересным -- связались сами.  Люди в проекте OpenWall, с которыми
довелось общаться -- крайне вменяемые, как минимум Solar Designer
ещё и русскоязычный.

> Про bacula почитаю подробнее, насколько я понял это самый
> распространненный инструмент.

Не знаю насчёт самого распространённого, но не исключено,
что самый развитый; спроектирован и реализован тоже неплохо.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [room] Разработка механизма резервирования виртуальных машин

[Илья Кучмин]

Небольшой дополнительный вброс. Одной из задач VPS - это независимость
от HW ноды. Стараемся минимизировать привязку к HW и облегчить процесс
миграции VPS. Решение должно это учитывать.

Постораюсь изложить задачу на логическом уровне чуть позже. Спасибо за отклики.

2012/1/9 Michael Shigorin <mike@osdn.org.ua>:
> On Tue, Jan 03, 2012 at 05:50:44PM +0400, Илья Кучмин wrote:
>> > Есть такое.
>> Под словом "перекрестный" предполагаю хранение резервных копий
>> непосредственно на HW.
>
> Я понял как "взаимное предоставление хостами с расположенными
> на них контейнерами друг другу стораджа для бэкапа".
>
>> >> Особенно если учесть, что винчестеры нынче дешевые, да и
>> >> raid обычно нулевой используется.
>> > Тот, кто с дешёвыми винчестерами использует raid0 для данных,
>> > испытывает судьбу даже и с бэкапами.  Да и с дорогими тоже...
>> В данном случае от raid1 большоей пользы не будет. VPS в
>> основном используются для целей тестирования и разработки,
>> смысл backup только в том, чтобы в короткие сроки развернуть
>> машину на стороннем HW.
>
> А-аа, ну так это существенное уточнение.  Возможно, Вам лучше
> посмотреть в сторону существующих систем для организации
> provisioning -- насколько понимаю, сейчас в моде Puppet.
> (мы работали с systemimager.org)
>
>> В идеале, если требуется стабильность, имеет смысл собирать
>> raid начиная с 5, но в нашем случае это слишком большие
>> затраты, не сравнимые с однодневными потерями.
>
> Пятёрка плоха по записи и ресурсу дисков, если что.
>
>> >> [...] соответственно должны использоваться утилиты
>> >> предоставленные авторами механизма виртуализации [...]
>> > Вы про снапшоты?
>> Я имел ввиду, что системе должно быть возможно указать какую
>> утилиту использовать для выполнения резервирования. К примеру
>> для выполнения резервирования машин на платформе OpenVZ хорошо
>> бы было испольлзовать vzdump и т.д.
>
> Если по постановке задачи делается не столько бэкап, сколько
> шаблон -- может быть проще останавливать VE/VM и делать просто
> копию.  VE при практически нулевой активности можно бэкапить
> и на ходу, хотя риск неконсистентности при этом всё же есть.
>
> Ещё может быть интересно эти шаблоны попросту выпекать под задачу
> -- на альтовской (прямщас) пакетной базе пилю mkimage-profiles:
> http://www.altlinux.org/Mkimage/Profiles/m-p -- но это требует
> возможности в существенной степени формализовать задачу VE.
>
>> > Не проще ли слать их более-менее гарантированным транспортом?
>> Когда я говорил о не гарантированных обновлениях я предполагал
>> вариант, когда клиент выпал из сети. В таком случае сервер
>> пишет в лог что уведомление не доставленно и в дальнейшем не
>> пытается его доставить повторно.(По аналогии с notify в DNS
>
> Возможно, стоит описать собсно задачу, а не фрагмент видимой
> реализации.
>
>> >> Прошу читателей покритиковать предложенную схему backup.
>> > Вы знакомы с bacula?  Там достаточно гибкая и шаблонируемая
>> > схема организации распределённого бэкапа, хотя возни при
>> > реализации (и времени на освоение базовых вещей) прилично.
>> Про bacula читал, но не использовал. Если не сложно поясните
>> как ее можно применить в моем случае.
>
> Как минимум там уже реализованы работающие бэкапные и стораджевые
> агенты, плюс управляющая логика.  Возможно, под Вашу задачу не
> подойдёт, но посмотреть стоит -- хотя бы ради того, чтоб не
> решать уже решённое на концептуальном уровне.
>
>> Мне кажется основная проблема в том, что в bacula процесс
>> резервирования инициируется единым сервером, через клиентов на
>> HW. В тоже время я хочу обратной ситуации, чтобы более
>> скурпулезно управлять процессом резервирования в зависимости от
>> нагрузки HW и активности использования VPS.
>
> Да, bacula нацелена на снятие головной боли ручного управления.
>
>> Возможно я зря этого хочу, если вы считаете также то прошу
>> указать на это.
>
> Попробуйте сделать небольшой прототип и поиграться с ним,
> чтобы понять, насколько будет необходимо человеческое внимание.
> Осторожно только с тем, чтоб не влопатить туда нечаянно слишком
> много рабочего кода: можно попасть на "о, так у нас уже есть
> решение" и прототип пойдёт в дело, к которому не готов в принципе.
>
> У меня обычно ощущения складываются за две-четыре недели таких
> экспериментов...
>
>> >> Также если вы знаете об инструментах которые полностью или
>> >> частично реализуют необходимый функционал, прошу указать их.
>> > Возможно, http://wiki.openvz.org/Partners#Openwall;
>> Не до конца понял в какой форме они осуществляют процесс
>> резервирования. Если использовали прошу поделиться опытом.
>
> Нет, не использовал -- ссылку дал с тем, чтобы если покажется
> интересным -- связались сами.  Люди в проекте OpenWall, с которыми
> довелось общаться -- крайне вменяемые, как минимум Solar Designer
> ещё и русскоязычный.
>
>> Про bacula почитаю подробнее, насколько я понял это самый
>> распространненный инструмент.
>
> Не знаю насчёт самого распространённого, но не исключено,
> что самый развитый; спроектирован и реализован тоже неплохо.
>
> --
>  ---- WBR, Michael Shigorin <mike@altlinux.ru>
>  ------ Linux.Kiev http://www.linux.kiev.ua/
> _______________________________________________
> smoke-room mailing list
> smoke-room@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/smoke-room

Re: [room] Разработка механизма резервирования виртуальных машин

[Michael Shigorin]

On Tue, Jan 10, 2012 at 10:09:03AM +0400, Илья Кучмин wrote:
> Одной из задач VPS - это независимость от HW ноды. Стараемся
> минимизировать привязку к HW и облегчить процесс миграции VPS.

В т.ч. потому и удивился соображению бэкапить на HN.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/