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

["Илья Кучмин" <ikuchmin@gmail.com>]

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