[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