[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/