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